I don't deny that there are certain usability problems with linux, and I don't deny that you have been frustrated at some point while using linux. But the problem with these types of discussions (this seems to be the third on/. in the last week) is characterized perfectly by your comment. Well, yours and the GP. One person claims that he/she is perfectly happy and nothing is wrong. The other says everything is broken and complete crap with no actual specific or constructive detail. Let's take a few examples from your post.
- In many cases it doesn't work out of the box.
What does this mean? What doesn't work out of the box? Is it a piece of hardware? Is it a piece of software? Is it a part of the UI? What are you talking about?
The reason this is important is because, depending on the specific problem, it may span from trivial to very difficult and likely requires different groups of people to be involved in the solution. A piece of hardware may not work out of the box. Well, there are a lot of approaches. Arguably the "best" solution would be to get that piece of hardware working, but for different reasons it may not be easy or possible (ex: hardware is complex to reverse-engineer and vendor refuses to support linux). So then what are alternate approaches. Well, picking your hardware more carefully is one. This can be done by the users, but is probably better done by the OEMs. Guess what? Almost every Windows or OS X workstation sold is put together by an OEM. They do the work to assemble the proper hardware and make sure it works with OS. If you try to install OS X on a random collection of hardware, or even if you just try to use a random piece of hardware with a mac (like a USB wifi adapter, say), there is a pretty good chance it won't work. Does that matter to most mac users? No, because they buy their mac from Apple, and all of the hardware they care about just works. Summary: hardware support is a problem for every OS. The primary solution has been OEMs selling bundled systems. So with better OEM support, this wouldn't likely be a problem on linux either. Unfortunately, there is little the linux community can do to gain OEM support. The commercial distributions have had limited success in the past (ex: Ubuntu partnering with Dell), but it's still not great.
On the other hand, a different problem warrants a different analysis. Pulseaudio doesn't work? That is purely a distribution problem, and I couldn't agree more. Distributions should not ship broken software or software with broken configurations. I have been frustrated by this in the past, with many distributions, and have become much more conservative about my choice of distribution as a result.
- Their requests for help are met with instructions to apply themselves toward learning more about how the tool is/was made and toward improving the tool itself.
Who? Where? When? Why?
It's important to know where you are asking for help. Complaining about hardware support on the kernel mailing list will likely result in exactly the response you describe. Why? Because kernel developers are busy people often employed by companies like Red Hat to hack on specific problems. It is not that they don't want to help. It is just that they aren't there to solve your problems for you. They may not be able to duplicate the problem you are experiencing on their machine, or they may not have the hardware you are having trouble with. So they will ask you to help them diagnose the problem, by doing tests and sending them logs. They may send you a patch and tell you try it out. That is how the kernel list works. It is a list for the kernel developers to communicate with each other.
On the other hand, the Ubuntu forums are usually very friendly. You will find people there who will give you step-by-step instructions for a lot of things. I would find it hard to believe that someone on the Ubuntu forums would tell you to write some code and s
These are not people who equate ease-of-use with "pretty translucent buttons" either. These are people who just want to upload their photos to the desktop, edit them, organize them, and email them to friends, for example. Or type a letter, take it to the library and print it.
Please describe exactly what about those task was difficult. Because one of Ubuntu's primary missions is to make those kinds of workflows easy. And I think they do it pretty well. Shotwell for your photo example (works almost identical to iPhoto) and LibreOffice for your letter example. Only thing I can think of that might have inhibited the latter is needing to specify the Microsoft Word file format while saving, but I don't think that is too difficult to learn.
When people complain about linux desktop usability, they aren't usually complaining about tasks like you describe. Off the top of my head, the complaints I hear the most often (and I think they are reasonably valid) are software availability, hardware support, software installation, and system administration tools, usually in that order. People are usually first looking to run software they need or already know (Microsoft Office/Adobe Photoshop) and they usually have some complaint about the alternatives offered in Linux. After that it is usually some hardware that doesn't work (a multifunction printer or wireless adapter, for example). If those two are good, the next complaint usually has something to do with software installation, and this usually boils down to some software/version not packaged in the repository of their distribution. Finally, certain system administration tasks can be awkward or difficult to some users (like configuring the graphics adapter or managing the permissions of a directory tree).
So, yeah, there are some usability problems with linux. I think most linux users are aware of them. But the solutions aren't trivial.
BtrFS has not been completed yet. ReFS is shipping. ReFS will not have all the features of the completed BtrFS, but for now ReFS offers features not available in any shipping Linux.
I don't think ZFS is production quality on Linux yet either. Storage Spaces under Windows is nor shipping.
I guess I should have qualified...many features are available and stable with BtrFS today, on Linux 3.2. If you need something more, like ZFS, it is available on BSD or one of the free Solaris distributions (if you're setting up servers, chances are you will be using a mix of the three). However, the architecture and intent of ReFS vs. BtrFS/ZFS is not really the same. And if we're talking about filesystems, one of the strengths of linux is access to unique special purpose fliesystems, like GlusterFS, NILFS, and XFS, if you have needs that are better suited by one of those. On Windows you really only have NTFS and I guess now ReFS.
Dynamic Access Control actually ups the ante for SELinux, grsecurity apparmor etc. While it still protects access to resources it does so based on potentially very fine grained policies which can express rules based on a very wide range of properties. And it brings claims based security all the way into the primary access control of an OS. Linux does not sport claims based security.
Ok, but let's see how it actually gets used. I don't know if you've actually ever used SELinux...there's a reason why almost no distribution ships with it enabled. It's a huge pain in the neck. Red Hat ships it with generic policies that kind of work, but don't really make use of its full capabilities. If you are storing military secrets, fine, but for most general purpose computing it just gets in your way. Creating even more fine-grained control just seems to me to be a feature set nobody will ever use.
Sure. I am not aware of any effort to bring something like VSS to Linux, though.
If you mean snapshotting, it is available in a number of different formats: at the block level (ZFS, NILFS), file level (BtrFS, OCFS2), volume level (ZFS, BtrFS, LVM2), and filesystem hack level (RSnapshot). I don't see what difference it makes whether it is a local or remote filesystem. It will work in both cases.
Yes, an automagic always-on, bi-directional VPN on steroids. No calling, no VPN client installations. Just take the laptop outside the perimeter and it is still connected, still secured, still managed.
Well, to be fair, you do still need to set it up. It doesn't just happen. The capability sounds a lot like IPsec to me, and this has been available on Linux for a long time. Windows too, but it seems they have added better integration with Active Directory.
Uhm, not quite. But unless you experience the new Server Manager you are not going to understand. It has this "declarative" feeling - comparable to controlling your network with declarative network policies as opposed to relying on scripts running on each node to set thing up.
Maybe you're right, I won't understand without actually using it. But based on your description, this sounds exactly like Chef. I would put this firmly in the "Microsoft playing catch-up" category, because this type of management has long been a strength on Linux.
* New resilient file system ReFS (think BtrFS when completed) * Storage Spaces (think ZFS storage pools) * Dynamic access control (claims and policy based access control). Think SELinux, grsecurity. Access control based on what application the user is running (sandboxing), from what type of device the user is accessing the resource, on other user attributes than security groups (e.g. who is the manager, what department does the user belong to etc), access control based on attributes of the file (e.g. classification, select words of a Word document)
So in other words, by your own description, things that you can already get in linux.
* SMB 3.0 - higher performance network transfer, transparent failover, SMB scaleout (multiple servers serve same shares and aggregates bandwidth), SMB Direct (efficient remote direct memory access), SMB Multichannel, Volume Shadow Service (VSS) for SMB file shares, SMB encryption, SMB Directory Leasing (negotiates and updates local caches of metadata over slow networks) * Block sized data de-duplication
Ok, things linux doesn't have yet, but are on the way.
* Hyper-V 3: ethernet cable live migration (neat trick) lets you migrate VMs off one server onto another server over the network without the servers sharing anything. Many Hyper-V manageability improvements. Crazy scalability, e.g. a 63-node Hyper-V cluster runs 4000 concurrent VMs simultaneously. Hyper-V replica.
Ok, Microsoft's own hypervisor technology. To get this on linux you would need to purchase a proprietary solution, like VMware or Xen.
* RemoteFX improvements, e.g. virtualized GPUs (can use local or remote shared GPUs during RDP sessions), remote low-latency multitouch.
An admitted weakness in linux at the moment.
* Direct Access over IPv4. Think hassle-free VPN.
I really don't understand what this is. An automagic VPN? Doesn't sound all that special. NetworkManager has been able to do system-wide VPN connections for a while now.
* Server manager: Yes, a Metro (oops - "Modern") style management app for multiple servers. Integrates with response files and powershell workflow scripts to manage multiple computers (servers/workstations) at once - e.g. install new software, perform configure actions. * PowerShell 3 with new features such as resilient remote connections (you can detach from a remote session and pick it up later/from another device), workflow scripts which can perform actions with suspend/restart/repeat semantics. No, not just "suspend process" - but actually persisting the state of a script to be continued later, e.g. after a computer restart (or from another machine). * Thousands of new PowerShell cmdlets (many/most automatically derived from WMI providers) to control virtually anything on local or remote computers.
So the equivalent of what you can already do on linux with a combination of SSH, Puppet/Chef, and Screen. Admittedly an improvement for Windows, but this has always been a strength with linux.
All in all a meh, in my opinion. If you really have a need for the high-end features, perhaps Microsoft is offering at a competitive price. But otherwise doesn't seem to offer much that you can't already get with a linux, bsd, or solaris distribution.
If you use something completely built into the operating system, it's easy. If you're using some kind of library, then you have to fuss around to make sure it's either staticaly compiled in or the.so or.dll or.dylib is shipped with your program. If it's not defined as part of the OS, you have to take care of it yourself.
Thank you. I was going to say exactly this myself. ABI-compatibility is a half-issue. Windows has some shared libraries that remain ABI compatible for years and others that don't. It wasn't very many years ago that Windows had ".dll hell", where different programs would install conflicting shared libraries and screw up everything. On OS X, (almost) every app ships with its own libraries to avoid the problem completely.
Bottom line: if you want to use dynamically-linked shared libraries on linux, it's very easy, and the advantage is you don't have to worry about distributing and keeping those libraries updated. The disadvantage is it is impractical to do this without releasing your source code to a distribution maintainer who can recompile and package it for you. If you need to keep your source closed, distribute it with its own statically-linked libraries. This makes it equivalent to Apple's "app bundles" and plenty of commercial software handles this just fine. Although, Ubuntu has been toying with their commercial partners repository for a number of years, and I can see them providing a "compile it but keep the source closed" service to software companies, but I don't think they do this currently.
That's true, but in the case of the browser wars, it was all about mindshare first, then market share.
Two things: 1) Mozilla was able to get a pretty good boost from IT departments that banned IE due to its security problems. While IE7 alleviated most of those concerns, it was a long enough window for many people to be exposed to Mozilla (to learn that it exists, to use it, to realize it works just as well as IE, and that IE is not synonymous with "the Internet").
2) Firefox, Seamonkey, Thunderbird, etc... are applications. It is not completely foreign, and for many people fairly normal, to try out various applications and find something that they like the best. Compatibility issues are usually minimal (exception: Office). So Firefox was able to gain a lot of mindshare by simply being better (faster, prettier, extensions, UI innovations). That just doesn't happen with the OS. First of all, compatibility is a huge burden. If it's not hardware, it is software that prevents people from trying something new. Second, an OS is a tool for running your favorite applications. As long as it does the job, people don't really see an OS for its own qualities. So linux can be better (in some ways it has been for a long time), but it will fall short in mindshare because software people want to run doesn't work on the hardware they own. It's just too technical to switch the OS, for the vast majority of computer users.
It depends on what that something is. In your grep situation, for example, I highly doubt there was no way to stop the command, or that a true lockup occurred. The separation of such commands into userspace is precisely to contain out of control processes. You maybe did not know how to stop the command. That is different from being unable to stop the command.
If you are programming drivers, or otherwise tweaking directly with hardware or kernel functions, you definitely can completely lockup the system. There is no way to conceivably prevent this. Some programmers need that kind of access, and with that kind of access comes the risks of lockups, race conditions, and data corruption, if you do something wrong.
You definitely can't ride your bike on the freeway, but the analogy is poor anyway....
We're not going to use something that keeps "breaking" every 12 months.
Quite a bit of an exaggeration. Thanks to (mostly) sane versioning schemes, API changes that result in breakage are usually restricted to major version numbers (ex: Gnome2 to Gnome3) not minor version numbers (ex: Gnome2.10 to Gnome2.12). Major versions are usually not rolled out every 12 months, and when they are the previous version often continues to be supported for a while as a parallel installation (Gnome being one of the exceptions). No, the breakage on linux that occurs (or seems to occur, at least) frequently is not due to a lack of backwards-compatibility. It is due to pushing out hastily developed, incomplete, alpha quality software before it's ready (ex: Pulseaudio).
Do you have a reference for that? I know plenty of techies that still use Firefox, because AddOn compatibilty is not that important. I mean, how many "Download YouTube videos" extensions do you need? If there was ever any mass exodus of techies away from Firefox, it was due to Javascript performance and memory issues (mostly solved now), not AddOn compatibility.
65% of the entire market, despite it's high cost and "horrible underpinnings". XP alone still commands 22% of the entire desktop market, and I can still run most software released for Windows on it, and vice versa.
"Fucked up right from the ground" meaning that I can install 15-year-old software on it and have it run perfectly?
Combining your comment with another in the same thread because I'm lazy. Why do you need to be able to run 15 yr old software on your computer? Certainly there are niche cases, but on my desktop machine I don't have anything more than 2 yrs old and on my servers nothing more than 5 yrs old. Quite frankly, if you're running software that old, it's most likely because it's not being developed anymore, which creates more serious issues than library compatibility.
The problem created by backwards-compatibilty, in my opinion, is that it perpetuates laziness on the part of the developer. Adobe Photoshop CS5 was the first version to actually use the Mac OS X Cocoa API, five versions and ten years after the Carbon API was officially deprecated.
Are you serious? You ran a command that pegged your CPU and that is a problem with linux? If you program an infinite loop and run it, is that a problem with linux too?
My point is that even in the non-science courses where cultures are studied and religious aspects are talked about, Christianity is rarely studied, thus failing the neutral test.
You mean the history and english courses where a large amount of time is spent studying things like the Babylon captivity, the Avignon Papacy, the Spanish Inquisition, the Church of England, the rise of Lutheranism and other Protestantism, the Puritans, the Great Awakenings, the Amish, the Shakers, the Quakers.... No siree, no Christianity at all.
Happens after arrest and before a trial. Since the arrest warrant has already been issued, arraignment (where the formal accusation is made) is the next step. This isn't an investigation anymore. It has moved into criminal proceedings.
Don't have a citation from Swedish law, but it is the procedure used in many countries and likely Sweden as well.
I don't see that it makes any difference whether the binding or inactivation reaction is rate-limiting with respect to the rate of inactivation.
Precisely what I said. It doesn't matter. What matters is that the binding step is there, which means that the rate of inactivation is dependent on the inhibitor concentration. Where you decide the concentration is insufficient depends on how long you want to wait. With a modest k,app for inactivation of 5x10^-3 uM^-1 s^-1 and a "trace concentration" of inhibitor--not sure what that is here, but let's say 2 nM, it would take 19 hrs. to inactivate half of the enzyme/receptor, assuming pseudo-first order reaction kinetics, which is uncertain (how much acetylcholine receptor do we have typically hanging around?). It would take 45 hrs. to inactivate 80% of the receptor.
This is fine if you just have your enzyme/receptor in a tube on your bench and plenty of time to waste (err, quantitate), assuming nothing else happens to it in the meantime (ex: nonspecific denaturation, oxidation, etc). But in your body, that inhibitor is being degraded over time and flushed out of your system. Not all of the inhibitor makes it to the target. The inhibitor has to compete with other ligands for the target, lowering the effective Ki. The inhibitor may react non-specifically with other targets (always a formal possibility). And, of course, the target is being turned over like you've already mentioned.
I looked up the dissociation rate of methotrexate, and the numbers I found gave a dissociation t1/2 of a minute or so. It's hard to see how that could be at all rate-limiting for a drug with a blood t1/2 on the scale of hours.
I'm not sure where you got your numbers for methotrexate, but in this paper they measure a koff of 1x10^-4 s^-1 for the human enzyme, which amounts to 2 hrs. to recover 50% active enzyme/receptor in the complete absence of additional inhibitor (ie: as soon as the inhibitor dissociates, it is infinitely diluted away). This may or may not be longer than its lifetime in the blood, I don't know, but it doesn't matter. It has an essentially diffusion-limited on rate, so if you have even, say, 100 pM floating around, it will immediately rebind to DHFR after a dissociation event takes place.
I don't think bioavailability is likely to be much of an issue with a lipophylic compound like imidacloprid.
Perhaps, it's hard to say. A lot depends on how it is administered. If it is coming in through the digestive track (ie: on contaminated food), a lot may be lost before it ever reaches the bloodstream.
An irreversible enzyme inhibitor necessarily has a binding step. There are, of course, many possible mechanisms, but the two reduced models used most often are:
E+I -> EI (non-covalent complex) -> E-I (covalent complex) [when inactivation is slower than binding] or E+I -> E-I [when inactivation is fast enough to be second order with inhibitor concentration]
Either way, there will be a concentration at which the inactivator will be ineffective as a drug. This "threshold" value may certainly be lower than is typical for a reversible inhibitor, but it is not infinitely lower.
I don't know of any clinically used reversible inhibitors that bind so tightly that dissociation is rate-limiting on duration of action
Mizoribine and methotrexate are two that come to mind. You are certainly right about chronic exposure in the bees, and I too would be wary of it. I am just trying to point out that while the binding kinetics of an inhibitor are important, they are probably the least significant factor determining the efficacy of a drug. Take methotrexate, for example. Equilibrium dissociation constants for the human dhfr have been measured in the picomolar range. Yet, a typical clinical dose is ~20 mg/m2, which is far more than is needed to completely inhibit all of the dhfr in your body at any given moment, and it must be administered daily. The bioavailability and metabolic stability turn out to be the factors that matter most.
You are assuming continuous and constant exposure to the inhibitor. And you are also assuming a high in vivo stability of the inhibitor. I'm not sure what you mean by a "threshold dose" because I'm not sure such a thing ever occurs with a drug, but there are definitely kinetic parameters that define the rate of inactivation. Lower concentrations of the inhibitor will necessarily have lower rates of inactivation unless you are saturating the binding site (unlikely). Which means, your liver has more time to clear it out of your system before it reacts with its target.
Accumulation is certainly one of the reasons why irreversible inhibitors have toxicity side effects. But quite a few are used safely clinically, so it is not an inherent problem. Also, tight-binding inhibitors are functionally equivalent to irreversible inhibitors, and there are a number of those in clinical use as well.
Well, if you want to be pedantic the HSPH study merely demonstrates that imidacloprid is a potential cause not the cause. There are likely multiple causes each making a contribution, especially considering CCD is a worldwide phenomenon and HFCS and imidacloprid are not used everywhere.
It's easy to regurgitate that "correlation is not causation", but most people don't seem to quite understand what that sentence means.
Who doesn't understand what it means? The scientists who did the study? Who published this?
Cage trials of 1–3 day old newly-emerged bees demonstrated increased mortality in the experimental group fed both N. ceranae and IIV-6 in comparison with the control group (P = 0.0001) and bees fed only N. ceranae (P = 0.04) or only IIV-6 (P = 0.04, Figure 3). As the actual infectious dose of N. ceranae or IIV that occurs in the field is currently unknown, we chose to utilize a relatively low infectious dose for both pathogens in our experiments. As is common in cage bee trials, mortality was observed in the control groups in all four biological replicates. To confirm that the controls likely died from a non-infectious cause, deceased bees from all treatment groups were further screened with MSP. The controls did not have any detectable IIVs, but did show some evidence of Nosema, which was not apparent from PCR analysis of the same samples.
It's the same standard of evidence that you applied to the pesticide study.
Because it is irreversible, it likely has a cumulative effect.
Not necessarily. Irreversible just means that the now non-functioning receptor has to be targeted for degradation. As long as the receptor gets turned over at a reasonable rate, it won't accumulate.
I think you must mean ATI. AMD has generally been pretty supportive of Linux, which is why many Linux users were happy when AMD bought ATI. The fact that the AMD driver is still a bit behind just reflects the fact that AMD basically had to start over to develop an open source driver for their cards. AMD is in fact, I think, driving much of the Xorg development around better 3D support because of their drivers (things like KMS and Gallium).
That's true, and that's why grant progress reports let you send in preliminary data instead of strictly requiring published papers. But part of the skill of being a good researcher is knowing how to break a large project up into small and significant chuncks that can be published independently. In your example above, the fourth year result is the big Nature paper/Nobel Prize, but in the process of such a large project it is highly likely that something interesting is coming out of years two and three. It's not necessarily a big splash, and it may be a bit tangential to your primary aim, but it is something novel that can be published. See some of Craig Venter's stuff, for example. One of his big projects is to create "synthetic life." He only recently reached the first stage, but spent many years publishing papers on methodology his lab has developed in pursuit of this aim.
Also, most labs do more than one thing at once. So there may be a big project you are sitting on to make the big splash, but there likely are (should be) many other smaller projects going on at the same time that can be published sooner.
Uh, Texans pay more in personal Federal income taxes than the state of Texas receives in financial aid from the Federal government. The distinction is important.
Slashdot Mirror
*sigh*
I don't deny that there are certain usability problems with linux, and I don't deny that you have been frustrated at some point while using linux. But the problem with these types of discussions (this seems to be the third on /. in the last week) is characterized perfectly by your comment. Well, yours and the GP. One person claims that he/she is perfectly happy and nothing is wrong. The other says everything is broken and complete crap with no actual specific or constructive detail. Let's take a few examples from your post.
- In many cases it doesn't work out of the box.
What does this mean? What doesn't work out of the box? Is it a piece of hardware? Is it a piece of software? Is it a part of the UI? What are you talking about?
The reason this is important is because, depending on the specific problem, it may span from trivial to very difficult and likely requires different groups of people to be involved in the solution. A piece of hardware may not work out of the box. Well, there are a lot of approaches. Arguably the "best" solution would be to get that piece of hardware working, but for different reasons it may not be easy or possible (ex: hardware is complex to reverse-engineer and vendor refuses to support linux). So then what are alternate approaches. Well, picking your hardware more carefully is one. This can be done by the users, but is probably better done by the OEMs. Guess what? Almost every Windows or OS X workstation sold is put together by an OEM. They do the work to assemble the proper hardware and make sure it works with OS. If you try to install OS X on a random collection of hardware, or even if you just try to use a random piece of hardware with a mac (like a USB wifi adapter, say), there is a pretty good chance it won't work. Does that matter to most mac users? No, because they buy their mac from Apple, and all of the hardware they care about just works.
Summary: hardware support is a problem for every OS. The primary solution has been OEMs selling bundled systems. So with better OEM support, this wouldn't likely be a problem on linux either. Unfortunately, there is little the linux community can do to gain OEM support. The commercial distributions have had limited success in the past (ex: Ubuntu partnering with Dell), but it's still not great.
On the other hand, a different problem warrants a different analysis. Pulseaudio doesn't work? That is purely a distribution problem, and I couldn't agree more. Distributions should not ship broken software or software with broken configurations. I have been frustrated by this in the past, with many distributions, and have become much more conservative about my choice of distribution as a result.
- Their requests for help are met with instructions to apply themselves toward learning more about how the tool is/was made and toward improving the tool itself.
Who? Where? When? Why?
It's important to know where you are asking for help. Complaining about hardware support on the kernel mailing list will likely result in exactly the response you describe. Why? Because kernel developers are busy people often employed by companies like Red Hat to hack on specific problems. It is not that they don't want to help. It is just that they aren't there to solve your problems for you. They may not be able to duplicate the problem you are experiencing on their machine, or they may not have the hardware you are having trouble with. So they will ask you to help them diagnose the problem, by doing tests and sending them logs. They may send you a patch and tell you try it out. That is how the kernel list works. It is a list for the kernel developers to communicate with each other.
On the other hand, the Ubuntu forums are usually very friendly. You will find people there who will give you step-by-step instructions for a lot of things. I would find it hard to believe that someone on the Ubuntu forums would tell you to write some code and s
These are not people who equate ease-of-use with "pretty translucent buttons" either. These are people who just want to upload their photos to the desktop, edit them, organize them, and email them to friends, for example. Or type a letter, take it to the library and print it.
Please describe exactly what about those task was difficult. Because one of Ubuntu's primary missions is to make those kinds of workflows easy. And I think they do it pretty well. Shotwell for your photo example (works almost identical to iPhoto) and LibreOffice for your letter example. Only thing I can think of that might have inhibited the latter is needing to specify the Microsoft Word file format while saving, but I don't think that is too difficult to learn.
When people complain about linux desktop usability, they aren't usually complaining about tasks like you describe. Off the top of my head, the complaints I hear the most often (and I think they are reasonably valid) are software availability, hardware support, software installation, and system administration tools, usually in that order. People are usually first looking to run software they need or already know (Microsoft Office/Adobe Photoshop) and they usually have some complaint about the alternatives offered in Linux. After that it is usually some hardware that doesn't work (a multifunction printer or wireless adapter, for example). If those two are good, the next complaint usually has something to do with software installation, and this usually boils down to some software/version not packaged in the repository of their distribution. Finally, certain system administration tasks can be awkward or difficult to some users (like configuring the graphics adapter or managing the permissions of a directory tree).
So, yeah, there are some usability problems with linux. I think most linux users are aware of them. But the solutions aren't trivial.
BtrFS has not been completed yet. ReFS is shipping. ReFS will not have all the features of the completed BtrFS, but for now ReFS offers features not available in any shipping Linux.
I don't think ZFS is production quality on Linux yet either. Storage Spaces under Windows is nor shipping.
I guess I should have qualified...many features are available and stable with BtrFS today, on Linux 3.2. If you need something more, like ZFS, it is available on BSD or one of the free Solaris distributions (if you're setting up servers, chances are you will be using a mix of the three). However, the architecture and intent of ReFS vs. BtrFS/ZFS is not really the same. And if we're talking about filesystems, one of the strengths of linux is access to unique special purpose fliesystems, like GlusterFS, NILFS, and XFS, if you have needs that are better suited by one of those. On Windows you really only have NTFS and I guess now ReFS.
Dynamic Access Control actually ups the ante for SELinux, grsecurity apparmor etc. While it still protects access to resources it does so based on potentially very fine grained policies which can express rules based on a very wide range of properties. And it brings claims based security all the way into the primary access control of an OS. Linux does not sport claims based security.
Ok, but let's see how it actually gets used. I don't know if you've actually ever used SELinux...there's a reason why almost no distribution ships with it enabled. It's a huge pain in the neck. Red Hat ships it with generic policies that kind of work, but don't really make use of its full capabilities. If you are storing military secrets, fine, but for most general purpose computing it just gets in your way. Creating even more fine-grained control just seems to me to be a feature set nobody will ever use.
Sure. I am not aware of any effort to bring something like VSS to Linux, though.
If you mean snapshotting, it is available in a number of different formats: at the block level (ZFS, NILFS), file level (BtrFS, OCFS2), volume level (ZFS, BtrFS, LVM2), and filesystem hack level (RSnapshot). I don't see what difference it makes whether it is a local or remote filesystem. It will work in both cases.
Yes, an automagic always-on, bi-directional VPN on steroids. No calling, no VPN client installations. Just take the laptop outside the perimeter and it is still connected, still secured, still managed.
Well, to be fair, you do still need to set it up. It doesn't just happen. The capability sounds a lot like IPsec to me, and this has been available on Linux for a long time. Windows too, but it seems they have added better integration with Active Directory.
Uhm, not quite. But unless you experience the new Server Manager you are not going to understand. It has this "declarative" feeling - comparable to controlling your network with declarative network policies as opposed to relying on scripts running on each node to set thing up.
Maybe you're right, I won't understand without actually using it. But based on your description, this sounds exactly like Chef. I would put this firmly in the "Microsoft playing catch-up" category, because this type of management has long been a strength on Linux.
Ummm...?
* New resilient file system ReFS (think BtrFS when completed)
* Storage Spaces (think ZFS storage pools)
* Dynamic access control (claims and policy based access control). Think SELinux, grsecurity. Access control based on what application the user is running (sandboxing), from what type of device the user is accessing the resource, on other user attributes than security groups (e.g. who is the manager, what department does the user belong to etc), access control based on attributes of the file (e.g. classification, select words of a Word document)
So in other words, by your own description, things that you can already get in linux.
* SMB 3.0 - higher performance network transfer, transparent failover, SMB scaleout (multiple servers serve same shares and aggregates bandwidth), SMB Direct (efficient remote direct memory access), SMB Multichannel, Volume Shadow Service (VSS) for SMB file shares, SMB encryption, SMB Directory Leasing (negotiates and updates local caches of metadata over slow networks)
* Block sized data de-duplication
Ok, things linux doesn't have yet, but are on the way.
* Hyper-V 3: ethernet cable live migration (neat trick) lets you migrate VMs off one server onto another server over the network without the servers sharing anything. Many Hyper-V manageability improvements. Crazy scalability, e.g. a 63-node Hyper-V cluster runs 4000 concurrent VMs simultaneously. Hyper-V replica.
Ok, Microsoft's own hypervisor technology. To get this on linux you would need to purchase a proprietary solution, like VMware or Xen.
* RemoteFX improvements, e.g. virtualized GPUs (can use local or remote shared GPUs during RDP sessions), remote low-latency multitouch.
An admitted weakness in linux at the moment.
* Direct Access over IPv4. Think hassle-free VPN.
I really don't understand what this is. An automagic VPN? Doesn't sound all that special. NetworkManager has been able to do system-wide VPN connections for a while now.
* Server manager: Yes, a Metro (oops - "Modern") style management app for multiple servers. Integrates with response files and powershell workflow scripts to manage multiple computers (servers/workstations) at once - e.g. install new software, perform configure actions.
* PowerShell 3 with new features such as resilient remote connections (you can detach from a remote session and pick it up later/from another device), workflow scripts which can perform actions with suspend/restart/repeat semantics. No, not just "suspend process" - but actually persisting the state of a script to be continued later, e.g. after a computer restart (or from another machine).
* Thousands of new PowerShell cmdlets (many/most automatically derived from WMI providers) to control virtually anything on local or remote computers.
So the equivalent of what you can already do on linux with a combination of SSH, Puppet/Chef, and Screen. Admittedly an improvement for Windows, but this has always been a strength with linux.
All in all a meh, in my opinion. If you really have a need for the high-end features, perhaps Microsoft is offering at a competitive price. But otherwise doesn't seem to offer much that you can't already get with a linux, bsd, or solaris distribution.
If you use something completely built into the operating system, it's easy. If you're using some kind of library, then you have to fuss around to make sure it's either staticaly compiled in or the .so or .dll or .dylib is shipped with your program. If it's not defined as part of the OS, you have to take care of it yourself.
Thank you. I was going to say exactly this myself. ABI-compatibility is a half-issue. Windows has some shared libraries that remain ABI compatible for years and others that don't. It wasn't very many years ago that Windows had ".dll hell", where different programs would install conflicting shared libraries and screw up everything. On OS X, (almost) every app ships with its own libraries to avoid the problem completely.
Bottom line: if you want to use dynamically-linked shared libraries on linux, it's very easy, and the advantage is you don't have to worry about distributing and keeping those libraries updated. The disadvantage is it is impractical to do this without releasing your source code to a distribution maintainer who can recompile and package it for you. If you need to keep your source closed, distribute it with its own statically-linked libraries. This makes it equivalent to Apple's "app bundles" and plenty of commercial software handles this just fine. Although, Ubuntu has been toying with their commercial partners repository for a number of years, and I can see them providing a "compile it but keep the source closed" service to software companies, but I don't think they do this currently.
That's true, but in the case of the browser wars, it was all about mindshare first, then market share.
Two things:
1) Mozilla was able to get a pretty good boost from IT departments that banned IE due to its security problems. While IE7 alleviated most of those concerns, it was a long enough window for many people to be exposed to Mozilla (to learn that it exists, to use it, to realize it works just as well as IE, and that IE is not synonymous with "the Internet").
2) Firefox, Seamonkey, Thunderbird, etc... are applications. It is not completely foreign, and for many people fairly normal, to try out various applications and find something that they like the best. Compatibility issues are usually minimal (exception: Office). So Firefox was able to gain a lot of mindshare by simply being better (faster, prettier, extensions, UI innovations). That just doesn't happen with the OS. First of all, compatibility is a huge burden. If it's not hardware, it is software that prevents people from trying something new. Second, an OS is a tool for running your favorite applications. As long as it does the job, people don't really see an OS for its own qualities. So linux can be better (in some ways it has been for a long time), but it will fall short in mindshare because software people want to run doesn't work on the hardware they own. It's just too technical to switch the OS, for the vast majority of computer users.
It depends on what that something is. In your grep situation, for example, I highly doubt there was no way to stop the command, or that a true lockup occurred. The separation of such commands into userspace is precisely to contain out of control processes. You maybe did not know how to stop the command. That is different from being unable to stop the command.
If you are programming drivers, or otherwise tweaking directly with hardware or kernel functions, you definitely can completely lockup the system. There is no way to conceivably prevent this. Some programmers need that kind of access, and with that kind of access comes the risks of lockups, race conditions, and data corruption, if you do something wrong.
You definitely can't ride your bike on the freeway, but the analogy is poor anyway....
We're not going to use something that keeps "breaking" every 12 months.
Quite a bit of an exaggeration. Thanks to (mostly) sane versioning schemes, API changes that result in breakage are usually restricted to major version numbers (ex: Gnome2 to Gnome3) not minor version numbers (ex: Gnome2.10 to Gnome2.12). Major versions are usually not rolled out every 12 months, and when they are the previous version often continues to be supported for a while as a parallel installation (Gnome being one of the exceptions). No, the breakage on linux that occurs (or seems to occur, at least) frequently is not due to a lack of backwards-compatibility. It is due to pushing out hastily developed, incomplete, alpha quality software before it's ready (ex: Pulseaudio).
Firefox deciding AddOn "compatibility" wasn't important.
Do you have a reference for that? I know plenty of techies that still use Firefox, because AddOn compatibilty is not that important. I mean, how many "Download YouTube videos" extensions do you need? If there was ever any mass exodus of techies away from Firefox, it was due to Javascript performance and memory issues (mostly solved now), not AddOn compatibility.
65% of the entire market, despite it's high cost and "horrible underpinnings". XP alone still commands 22% of the entire desktop market, and I can still run most software released for Windows on it, and vice versa.
"Fucked up right from the ground" meaning that I can install 15-year-old software on it and have it run perfectly?
Combining your comment with another in the same thread because I'm lazy. Why do you need to be able to run 15 yr old software on your computer? Certainly there are niche cases, but on my desktop machine I don't have anything more than 2 yrs old and on my servers nothing more than 5 yrs old. Quite frankly, if you're running software that old, it's most likely because it's not being developed anymore, which creates more serious issues than library compatibility.
The problem created by backwards-compatibilty, in my opinion, is that it perpetuates laziness on the part of the developer. Adobe Photoshop CS5 was the first version to actually use the Mac OS X Cocoa API, five versions and ten years after the Carbon API was officially deprecated.
Are you serious? You ran a command that pegged your CPU and that is a problem with linux? If you program an infinite loop and run it, is that a problem with linux too?
My point is that even in the non-science courses where cultures are studied and religious aspects are talked about, Christianity is rarely studied, thus failing the neutral test.
You mean the history and english courses where a large amount of time is spent studying things like the Babylon captivity, the Avignon Papacy, the Spanish Inquisition, the Church of England, the rise of Lutheranism and other Protestantism, the Puritans, the Great Awakenings, the Amish, the Shakers, the Quakers.... No siree, no Christianity at all.
Sweden wants to question him...and that needs to take place in Sweden legally.
Citation please. Preferably from the actual section of the Swedish legal code that compels this.
It is called Arraignment,
http://en.wikipedia.org/wiki/Arraignment
Happens after arrest and before a trial. Since the arrest warrant has already been issued, arraignment (where the formal accusation is made) is the next step. This isn't an investigation anymore. It has moved into criminal proceedings.
Don't have a citation from Swedish law, but it is the procedure used in many countries and likely Sweden as well.
Apple pulled out because they now glue their batteries to the chassis, thus making the batteries and chassis non-recyclable
Not EPEAT certified != non-recyclable
Apple has had for years (and continues to have) a free recycling program for all of their electronics.
You don't like people's lifestyles and you want to change them..
Where did you read that? He didn't say anything of the sort.
Saying that we need to rethink how we organize our cities (which is true, no doubt) is not forcing a lifestyle on anyone.
Nope. Not since IE7 and WinXP SP2. Explorer.exe and iexplore.exe are two independent processes.
That should only require a restart of the browser, not the whole OS. Plenty of other software manages this just fine.
I don't see that it makes any difference whether the binding or inactivation reaction is rate-limiting with respect to the rate of inactivation.
Precisely what I said. It doesn't matter. What matters is that the binding step is there, which means that the rate of inactivation is dependent on the inhibitor concentration. Where you decide the concentration is insufficient depends on how long you want to wait. With a modest k,app for inactivation of 5x10^-3 uM^-1 s^-1 and a "trace concentration" of inhibitor--not sure what that is here, but let's say 2 nM, it would take 19 hrs. to inactivate half of the enzyme/receptor, assuming pseudo-first order reaction kinetics, which is uncertain (how much acetylcholine receptor do we have typically hanging around?). It would take 45 hrs. to inactivate 80% of the receptor.
This is fine if you just have your enzyme/receptor in a tube on your bench and plenty of time to waste (err, quantitate), assuming nothing else happens to it in the meantime (ex: nonspecific denaturation, oxidation, etc). But in your body, that inhibitor is being degraded over time and flushed out of your system. Not all of the inhibitor makes it to the target. The inhibitor has to compete with other ligands for the target, lowering the effective Ki. The inhibitor may react non-specifically with other targets (always a formal possibility). And, of course, the target is being turned over like you've already mentioned.
I looked up the dissociation rate of methotrexate, and the numbers I found gave a dissociation t1/2 of a minute or so. It's hard to see how that could be at all rate-limiting for a drug with a blood t1/2 on the scale of hours.
I'm not sure where you got your numbers for methotrexate, but in this paper they measure a koff of 1x10^-4 s^-1 for the human enzyme, which amounts to 2 hrs. to recover 50% active enzyme/receptor in the complete absence of additional inhibitor (ie: as soon as the inhibitor dissociates, it is infinitely diluted away). This may or may not be longer than its lifetime in the blood, I don't know, but it doesn't matter. It has an essentially diffusion-limited on rate, so if you have even, say, 100 pM floating around, it will immediately rebind to DHFR after a dissociation event takes place.
I don't think bioavailability is likely to be much of an issue with a lipophylic compound like imidacloprid.
Perhaps, it's hard to say. A lot depends on how it is administered. If it is coming in through the digestive track (ie: on contaminated food), a lot may be lost before it ever reaches the bloodstream.
An irreversible enzyme inhibitor necessarily has a binding step. There are, of course, many possible mechanisms, but the two reduced models used most often are:
E+I -> EI (non-covalent complex) -> E-I (covalent complex) [when inactivation is slower than binding]
or
E+I -> E-I [when inactivation is fast enough to be second order with inhibitor concentration]
Either way, there will be a concentration at which the inactivator will be ineffective as a drug. This "threshold" value may certainly be lower than is typical for a reversible inhibitor, but it is not infinitely lower.
I don't know of any clinically used reversible inhibitors that bind so tightly that dissociation is rate-limiting on duration of action
Mizoribine and methotrexate are two that come to mind. You are certainly right about chronic exposure in the bees, and I too would be wary of it. I am just trying to point out that while the binding kinetics of an inhibitor are important, they are probably the least significant factor determining the efficacy of a drug. Take methotrexate, for example. Equilibrium dissociation constants for the human dhfr have been measured in the picomolar range. Yet, a typical clinical dose is ~20 mg/m2, which is far more than is needed to completely inhibit all of the dhfr in your body at any given moment, and it must be administered daily. The bioavailability and metabolic stability turn out to be the factors that matter most.
You are assuming continuous and constant exposure to the inhibitor. And you are also assuming a high in vivo stability of the inhibitor. I'm not sure what you mean by a "threshold dose" because I'm not sure such a thing ever occurs with a drug, but there are definitely kinetic parameters that define the rate of inactivation. Lower concentrations of the inhibitor will necessarily have lower rates of inactivation unless you are saturating the binding site (unlikely). Which means, your liver has more time to clear it out of your system before it reacts with its target.
Accumulation is certainly one of the reasons why irreversible inhibitors have toxicity side effects. But quite a few are used safely clinically, so it is not an inherent problem. Also, tight-binding inhibitors are functionally equivalent to irreversible inhibitors, and there are a number of those in clinical use as well.
Well, if you want to be pedantic the HSPH study merely demonstrates that imidacloprid is a potential cause not the cause. There are likely multiple causes each making a contribution, especially considering CCD is a worldwide phenomenon and HFCS and imidacloprid are not used everywhere.
It's easy to regurgitate that "correlation is not causation", but most people don't seem to quite understand what that sentence means.
Who doesn't understand what it means? The scientists who did the study? Who published this?
Cage trials of 1–3 day old newly-emerged bees demonstrated increased mortality in the experimental group fed both N. ceranae and IIV-6 in comparison with the control group (P = 0.0001) and bees fed only N. ceranae (P = 0.04) or only IIV-6 (P = 0.04, Figure 3). As the actual infectious dose of N. ceranae or IIV that occurs in the field is currently unknown, we chose to utilize a relatively low infectious dose for both pathogens in our experiments. As is common in cage bee trials, mortality was observed in the control groups in all four biological replicates. To confirm that the controls likely died from a non-infectious cause, deceased bees from all treatment groups were further screened with MSP. The controls did not have any detectable IIVs, but did show some evidence of Nosema, which was not apparent from PCR analysis of the same samples.
It's the same standard of evidence that you applied to the pesticide study.
Because it is irreversible, it likely has a cumulative effect.
Not necessarily. Irreversible just means that the now non-functioning receptor has to be targeted for degradation. As long as the receptor gets turned over at a reasonable rate, it won't accumulate.
No, that would be "not making it free." Open source does not have to be free, unless you want to charge to view the source instead of just to use it.
I think you must mean ATI. AMD has generally been pretty supportive of Linux, which is why many Linux users were happy when AMD bought ATI. The fact that the AMD driver is still a bit behind just reflects the fact that AMD basically had to start over to develop an open source driver for their cards. AMD is in fact, I think, driving much of the Xorg development around better 3D support because of their drivers (things like KMS and Gallium).
That's true, and that's why grant progress reports let you send in preliminary data instead of strictly requiring published papers. But part of the skill of being a good researcher is knowing how to break a large project up into small and significant chuncks that can be published independently. In your example above, the fourth year result is the big Nature paper/Nobel Prize, but in the process of such a large project it is highly likely that something interesting is coming out of years two and three. It's not necessarily a big splash, and it may be a bit tangential to your primary aim, but it is something novel that can be published. See some of Craig Venter's stuff, for example. One of his big projects is to create "synthetic life." He only recently reached the first stage, but spent many years publishing papers on methodology his lab has developed in pursuit of this aim.
Also, most labs do more than one thing at once. So there may be a big project you are sitting on to make the big splash, but there likely are (should be) many other smaller projects going on at the same time that can be published sooner.
Uh, Texans pay more in personal Federal income taxes than the state of Texas receives in financial aid from the Federal government. The distinction is important.
Errr...that's $30k per genome (human-sized), not per sequencing operation. The device advertised does not do genomes.