Uhhhh....
http://www.ubuntuupdates.org/package/xorg-edgers/precise/main/base/xserver-xorg-video-intel

If you're telling me it doesn't work (don't have one to verify myself), fine, sounds like it needs a bug report. KMS has nothing to do with anything. Using an older AMD driver doesn't preclude you from using a new and updated distribution. Ubuntu has had "nvidia-legacy" packages for similar reasons for years. Not sure why you don't like the radeon driver, but https://launchpad.net/~makson96/+archive/fglrx. It says 13.10 and beyond will be more of a pain, but 12.04 is supported now and will be until 2017.

What do you mean by supported, and why do you think your laptops weren't?

I think what he means is that the network transparency feature of X11 involved sending X primitive commands over the network to be rendered on the remote X server. With the modern desktop environments and toolkits this doesn't happen. Yes, you have a remote display, but it is sending pixmaps and screen buffers over the network instead of X primitives. So it is slow as hell and doesn't take full advantage of the local (client) hardware.

That's almost, but not entirely, true. ALSA had kernel-level software mixing (dmix) that any application written to use ALSA could benefit from. As long as I used 100% ALSA applications, it worked fine. The problem was, as you say, not all applications would support ALSA. They would use OSS and rely on the bridge device between /dev/dsp and the /dev/alsa devices as a compatibility layer. The mixing would still work if you were using 1 OSS application and 10 ALSA applications, but not if you were using 2 OSS applications. The solution was a higher level sound-mixing daemon that could abstract the hardware layer away from the applications. Again, the problems as you state were incompatible daemons between KDE and GNOME, until finally PulseAudio comes along which does two things. It abstracts the hardware much further (ex: it supports network sounds devices), and it hooks into everything (OSS, ALSA, ESD, artsD, Phonon), so any application written to use any sound subsystem will go through PulseAudio first. I'm not sure PulseAudio is the best solution, it has issues with latency and so forth. But getting all disparate software projects to agree on a single sound subsystem is harder, so it was never done. I believe there were a few attempts to get either ESD or artsD into a Freedesktop spec, but that never went anywhere.

a) This isn't radio. Spotify's user base isn't that large, so 2% isn't as much as it sounds.
b) The more songs you have, the better chance you have of somebody listening to it. So if you have only one song, yeah that might be hard to hit. But if you have 40, it is easier.
c) Big caveat to my calculation: I don't know what Spotify's sliding scale is. For 2% of the user base, the payout may be significantly larger and thus the required number of plays to make a reasonable income smaller.
d) Spotify's revenue comes from ads, so it makes sense to split it up based on how popular a song/group is. If only 0.01% of the user base is listening to your music, you can't expect Spotify to give you a large piece of the ad revenue generated by their service.

The entertainment industry, whether it be music, tv/movies, or sports, is about popularity. If you can't boost your popularity, it just isn't going to work out, regardless of Spotify's business model. That is the reality.

400,000 plays?

Ok, let's stop and think about that for a moment. If you are a serious enough musician that you intend to do this professionally, let's assume you have put up at least 1 album, which for the sake of argument is about 10 songs. Spotify has 24 million active users, http://press.spotify.com/us/information/. So to make the 400,000 play cut, about 2% of Spotify's user base has to listen to at least one of your ten songs per month. That does not seem unreasonable to me. If you can't make that cut, the professional music gig probably isn't going to work out for you, sorry.

Am I missing something here?

Um, no, not really.

You are right, they should do more work on the study and get more data. But any questions about statistical significance and/or experimental design should have been addressed at the peer review stage. And then after that, there is even a final decision by the editor-in-chief to actually publish the study. Bad science or no, the study made it through. It happens all the time. See the arsenic in DNA controversy, or the huge argument over a generalized mechanism for antibiotic killing by reactive oxygen species. I can pick up papers from the 80s where they didn't purify their enzyme well enough and determined the wrong kinetic mechanism. What was the response to all of these? Different groups performed different studies and refuted the original findings. Sure there was a lot of clamor as well, but ultimately it was the experiment that settled the issue.

Calling for retraction in the absence of any kind of experimental evidence is not the way to handle this. I am not surprised the authors refused. Retraction has a huge stigma associated with it, and if they weren't deliberately fraudulent, they don't deserve it. The scientific community can scorn all they want, but it means nothing without experimental evidence to back it up.

Can we say arsenic in DNA?
http://www.sciencemag.org/content/332/6034/1163

It was only a few years ago, but I guess it has already left the public memory. A group of scientists rush to a hasty conclusion because they want to make a big splash. Science publishes it because they like controversy. A large flurry of criticism from the scientific community, but ultimately a number of papers get published refuting the original findings. We can ask the question...should it have been published? A lot of people think no, but it is an illustration of the scientific process.

Sometimes bad science gets through peer review. Sometimes the science is not particularly bad, but the experimental design was missing something. Maybe they had an impurity in one of their reagents that they weren't looking for. Lots of incomplete or just outright wrong studies pass peer review and get published. But this is something the scientific community accepts as a part of the process. If you strongly disagree or suspect the conclusions of an article, do the experiments and publish a counter-study. Otherwise, you are free to make a lot of noise and be annoying, but then you might go the way of James Watson.

Uh huh, sure. Unless your "high-end enterprise product" runs on a 10 yr old copy of Slackware, what you've written is complete baloney.

As I'm sure you had to learn how to use Powershell, you will likewise have to learn how to use the command line in linux. And when you do, you will know what -e does for the most important commands. Btw, the majority of common linux commands have long-name switches along with their shortened counterparts (ex: cp -a vs. cp --archive), as well as quick --help pages to refresh you if need be.

Rail is optimal for regional distances. The faster the train, the larger the regional area it can serve. Ex: 200 mph makes serving a 600 mile area practical. Much faster than a car. Competitive with a plane when you consider time through security, comfort, etc. I used to take the Amtrak back and forth from home when I was in college. Driving might have been a bit faster, but not cheaper. And the train was a lot more comfortable.

For cross-country trips, that is the domain of air travel. No need to try to solve every problem with the same tool. Get rid of all of the crappy regional jets that are loss leaders anyway and replace with a nice train system. Bonus points if you can seamlessly connect between a flight and a train trip.

Yes, that is the definition of a shortage. When demand/supply is high enough that developers can demand salaries that many segments of the market cannot afford, then there is a shortage.

Everywhere. Maybe you have not been paying attention.
http://www.pcworld.com/article/223509/demand_for_workers_outstrips_supply_first_since_2008.html
http://www.careerbuilder.com/share/aboutus/pressreleasesdetail.aspx?id=pr645&sd=7/13/2011&ed=12/31/2011&siteid=cbpr&sc_cmp1=cb_pr645_
http://www.bankrate.com/finance/jobs-careers/biggest-worker-shortages.aspx#slide=4
https://www.nixonwilliams.com/blog/post/07/2013/Temporary-IT-worker-demand-rises-to-two-year-high

What do you think a shortage is? When crude oil tops $200/barrel, we don't say there is an abundance of high quality oil that costs more. We say there is an oil shortage. That is the nature of markets. It is a negotiation between what people are willing to work/sell for and what people are will to pay/buy for. When parties feel the balance is tipped too far in one direction, it is declared a "shortage" or a "surplus", depending on your perspective.

What peripheral drivers would you like to install? What is it about Linux that prevents you from installing them? Is it because they are not available? That would be the manufacturers fault. There really is no excuse for this. The facilities for producing userspace drivers for just about anything have been available in Linux for a long time. Manufacturers don't have to open source or submit them to upstream repositories, but they do have to write them. If they don't...who's going to write it for them? And no, just because it is bad for Aunt Tillie does not mean it is a fault with Linux, anymore than the D-Link DWA-130 not working on OS X is a problem with Apple.

Uh, one: ALSA since the 2.6 kernel. I will agree that certain desktop distributions (I'm looking at you Ubuntu) like to beta-test and screw around for no apparent reason resulting in breakage, but you can easily install a Linux desktop and have the sound work out of the box with no messing around. For a period of time that wasn't Ubuntu, though.

Define "work well." I mean we all have our own standards. Some things are just irritating because it may be bad scrollbar behavior, or something, but not everybody is bothered by these sorts of things. It's easy to criticize Ubuntu for the things they miss or break (because these irritate us the most) and forget the good things they have contributed (they were the first distribution to make a proprietary driver installer for the desktop, for example). I don't know, it's not perfect, but I've never used a desktop, Linux or otherwise, that was.

Did you happen to notice the statement,

(emphasis added)

Yes, there are a lot of genetic disorders, but no, there are not many we can identify by simply looking at the genome.

Yes, that and the quoted cost is, I'm assuming, $1000 for a single chip run, which gives you a maximum of 10 Gb or only ~3X coverage (actual will probably be less). That's usually how marketing blurbs work. Even for SNP analysis, you are going to need around 40X coverage, so the cost per genome is much higher than what they are saying, and is still at least an order of magnitude more expensive than Illumina.