That's an in-band means.

No. The music library is outside the sandbox.

Planning? Office for Mac has been around for around 24 years.

Or they're sandboxed to an "open" Battle.Net. Like Diablo 2.

For me, it didn't survive a month. And I played D2 for ~5 years.

If you're using engine check lights as an analogy to SMART data so you know when to swap out a drive, I still disagree. Once SMART data goes bad, you can usually still get data off the drive but I wouldn't trust it to not have some corruption. I'd just yank the drive, rebuild the RAID if the machine needs high availability, or copy over from backup if it doesn't.

If recovering from backup and the backup isn't quite up to date I'd probably try some kind of data recovery, but I wouldn't want to rely on it.

From my experience when I toyed around with Gentoo a few years ago, make -j worked best when the number provided was {core count + 1}. Any more than that and it slowed down due to context switching overhead and/or disk head thrashing.

It has severe limitations. It doesn't work when you need to import TLB files, it does not work with incremental rebuilds, and it doesn't play particularly nicely with precompiled headers. The former is required for our project to build at all, and the latter 2 improve productivity more than using multiple threads (YMMV).

They only need to run 1.5 million drives for 1 hour to reach that MTBF. If 5% of them die after 2 hours they still hit the MTBF.

There's a reason people back up data rather than relying on data recovery on a broken drive.

Hard drives typically have shorter warranties than SSDs. OCZ has a bad reputation for having reliability issues compared to other SSDs yet their warranties are 3-5 years. The typical Seagate and WD warranties are now 2 years.

Warranties are typically longer on SSDs than HDDs these days. I can't comment on the specific models they used in the article however.

I've been running multiple partitions/drives on Windows for years and haven't encountered a sizeable app that I'd want to put on a different drive that wouldn't let me.

Fairly large codebase here, ~4 minute compile times, C++ with Visual Studio. Compile times were unaffected by the SSD upgrade. Searching code, however, massive speed improvement and paid itself off with productivity improvements after about a month.

I upgraded to an SSD recently and compile times didn't really change at all, which was surprising. Boot times, application load times, system responsiveness etc however are massively improved. At least on my setup (Xeon E31270, Windows 7, Visual Studio), compile times aren't particularly IO limited.

That's just asinine. You should never rely on recovery of data from a broken drive to avoid data loss. Even if you do recover data from a broken HDD you shouldn't trust it hasn't had some form of corruption. Always have a backup. If you have backups, who cares if the drive is recoverable?

Also, don't buy Sandforce SSDs. There are plenty of alternatives that are faster and more reliable.