You'll just have to use 39Ar or 42Ar, and probably need a H-fusion reaction to detonate it.

Probably, but since the quantities of those elements will be dramatically lower than argon, detecting them will likely be much more difficult.

I got the warranty info directly from WD's site and spec sheets. RPM is NOT the primary factor in determining seek time, that only affects rotational latency, which is one of at least 4 components of access time, the other three being track seek time, head settling time, and head select time. Seek time is generally the largest of those, rotational latency second largest, and the others are minor by comparison.

Amount of ECC is not only dependent upon 512/4k (AF) drive, that's one factor, but most "enterprise" drives from most manufacturers have greater ECC and most use lower track densities to allow faster positioning (faster seek). For instance, compare the data sheets for the 7200RPM desktop and Enterprise (Constellation ES) drives from Seagate. Note the "enhanced error correction" and better "non-recoverable read error" rates (which are directly related to ECC recoverablity) on the ES (enterprise) drive, and that's comparing a 512b sector ES drive to a 4K/AF desktop drive.

As I said, you analysis was generally good, you just missed a the 3 items I noted.

Good analysis, with two issues:

1. Both of the specific drives you mentioned above have 5 yr warranties, so your specific example doesn't work for costs, but in general, your analysis is valid.

2. You don't address performance differences. WD doesn't specify seek times on these, so I can't compare them. But in general, "Enterprise" drives have faster seek and/or transfer rates. This may make the enterprise drive superior for certain environments.

One final difference, many/most "enterprise" drives have higher levels of error correction, so even if the drive failure rate is the same, they're more likely to be able to read/recover data from a given sector.

I don't allow rust in my storage arrays. Aluminum, magnesium, and glass don't rust.

No, from TFA:

... the company's usage of the drives is different, with enterprise drives being used more heavily than their consumer counterparts.

, so the comparison is indeed pointless (more accurately, it's baseless).

While one designer was common to both, USB as far more in common with Apple Desktop Bus (ADB) than with SIO. ADB supported hot plugging, dynamic device driver loading, same power specifications as USB 1.1, simple cabling, very low cost, etc. ADB was much slower than USB (even low-speed), but it's design has more in common with USB than does SIO, even though it's from a completely different group of designers. SIO might be the grandfather design, with ADB more of a parent or uncle.

...where failure is rewarded, as long as you can talk a good game.

...they don't have to worry about anyone stealing them, since there is almost no market for them.

GP is correct, this isn't a "net neutrality" issue. It's a class of service issue. They offered a service with terms that you can't run your own server for a specific amount of money. The don't limit what devices you connect, what sites you access, what protocols you can run, etc. They don't give priority to their own services, or limit access to competitors, etc. You bought "consumer" access, not "provider" access, and the terms say you can't operate a publicly accessible server. If you want to operate a server and be a provider, get the correct type of account. That's not "net neutrality", it's a contractual issue.

In China, workers don't need unions, they just need to be an Apple supplier, and get China Labor Watch to give them a poor report on workplace conditions. Then, the world will force Apple to force the supplier to address the issues (or hide them better).

My Buzzword Bingo card was completed in the first 3 paragraphs of Ballmer's memo. By the end, I only had a few unmarked spaces on each card.

Maybe, the user didn't want to confuse you by sending in multiple problem reports at once. Or maybe the user's manager thought that would overload IT, or make it appear they were just complaining too much. :)

I had users who just ignored, or worked around errors, errors that had never been reported. Some were user errors (resolved by both program changes to prevent those errors and user training), some were UI errors that didn't impact the results, and some were program errors with actual consequences or impact on the data or utility of the software. I found out about these errors by watching the users, or as a side issue when they were having some other problem that they did report. I explained that reporting all errors ASAP gives the developers a broader view of the potential problem, and allows all errors to be fixed faster and more completely. I trained them to report every problem, no matter how small, and made a point of addressing those errors as quickly as practical to reinforce the behavior of reporting them. And, of course, I explained that unreported errors were very unlikely to be fixed, ever.

What? You think there is a world outside North America? Which planet are you from?