People with fevers sweat, they cough, they sneeze. Droplet transmission is a serious threat, especially in cramped conditions. No licking necessary. But then you throw children in the mix, and there will be licking and mouthing of potentially contaminated items. And sick kids that want to be held by mommy or daddy, and will sneeze directly in their face.

Not saying that we have reason to panic now, but it is fatuous to dismiss the very real challenges of effective containment once the disease becomes endemic to a particular population.

Java is going nowhere. In addition to being in most phones (Android, Jave ME), it is in every Blu-Ray player (BD-J), every cable box (OCAP), cash registers, ATMs and voting machines. And that isn't even touching on enterprise, web and desktop applications.

Take a look at most language rankings and Java remains near or at the top, whether you look at Tiobe, PyPL, RedMonk, IEEE Spectrum, or the various job surveys published by the likes of Dice.com and eWeek.

JRuby and Rubinius have been using JIT for years.

And LuneOS, and Tizen.

Java has a vast ecosystem, excellent threading and concurrency support, robust monitoring and debugging tools, and can rival (or exceed) the performance of traditional compiled languages.

This is true for both small scale and large scale problems. For example, I wrote a little tool to do LDIF transforms in perl. Six hours later, it wasn't even half finished. Rewrote it using a Java library (UnboundSDK) and it finished in about twenty-five minutes.

On the other end of spectrum, I wrote a load-testing application that scaled cleanly to tens of thousands of threads. In a couple of hours. With no experience writing anything to that scale before.

(And the idea that Java is strictly Android these days is absurd. Your cable box runs Java. So does your blu-ray player. Along with ATMs, cash registers, voting machines, any number of enterprise applications, webservices, etc, etc. It is an incredibly pervasive language.)

It also turns out you can implement everything in plain Java libraries. In fact it is a heck of a lot easier, since you don't need to wrap the C modules; everything Just Works.

How big a stack do you need to match a 1320 tape library? Even using 4TB disks you're talking 825 disks, which means 51 enclosures. And then four racks to hold those enclosures. And enough floor space to hold those racks. And enough circuits to power those racks.

At that level of scale, tape is simply a better option for archival storage.

Eh? Both T-Mobile and AT&T (and Verizon, actually) offer no-contract service. Not one or two year. No year. Now you might finance a phone through them, and be on the hook for paying that, but that is not the same thing as being under a service contract.

Erm, LLVM was around for half a decade before Apple started contributing to it.

I would think the more apt analogy is that you sold me unlimited access to your fridge (bandwidth) but Netflix (content provider) is only restocking at a rate of one six-pack per week. IOW, Netflix is the one failing to have peerage agreements in place to honor their downstream sales commitments.

Very expensive items ... like an iPad. Even if, as you stipulate, the replacement rate is significantly higher, it can afford to be. Because again, half the cost. Less once you consider the cost of keyboard and case for the iPad.

But I frankly doubt the iPad will last that much more. The batter is probably higher grade in the Apple, but the battery in many Chrome books is user-replacement and long off-AC battery life is not going to be a pre-requisite for this use case. There may be a slightly higher breakage rate with a Chromebook (given hinges, keyboard, etc), but accidental damage is likely to be similar on both and repairs on the Apple side are going to be more expensive (since they are not easily user-serviceable). Loss and theft will be more expensive on the Apple side as well, since the unit cost is higher. And separate keyboards are probably more likely to be lost or damaged than a built-in one.

Less than half the price. When buying tens or hundreds of thousands of units, the savings add up.

And applications targeting the platform have the expectation of a keyboard and pointing device, unlike iOS apps.

There are limitations, but that does not mean it is unsuitable to all markets. And those limitations become less important as applications increasingly move to the web.

It was the G4 and a considerable level of creativity in Apple's marketing department. They were not considered a "supercomputer". They were briefly subject to an export ban to some markets because they breached a arbitrary limit that had already changed by the time they hit the market.

See, for example:

The extend of their superiority over the Intel and AMD processors of the time also need to be taken with a grain of salt. As with most Apple touted benchmarks, the fine print would reveal that the "up to twice as fast" claim referred to three specific Photoshop filters that were optimized for the Altivec operations in the G4. In other words, they exploited the fact that Intel made significant performance trade-offs with their implementation of SIMD instructions in that generation. In other benchmarks (like SPEC) the P3 spanked the G4.

Ah, you must be on the Red Hat AUS update channel, which (to my understanding) provides critical bugfixes and security updates, but not enhancements. In other words, you are running 6.4 + fixes, which isn't the same as 6.5.

RHEL 6.5 is just RHEL 6.4 with all the updates already applied. Applying the updates does not change the system-release file.

Yes, it does. The centos-release package gets updated with everything else.