"Recall"

See FailSafe.
And of course, How I Learned to Stop Worrying and Love the Bomb (aka Dr. Strangelove).

I think it's something like over 90% of all dropped munitions these days are precision-guided. Look up JDAM. They cost significantly less than a Tomahawk.
And when precision isn't required, B-52s still do one thing better than anyone else. Carpet bombing.

While that's a very impressive trend for HDD storage, Moore's law is not applicable here. Moore's law only deals with the rate of doubling the number of transistors in an integrated circuit. HDD storage is not based on transistor density, but magnetic recording density. Now, Flash storage? That would be more closely tied to Moore's law I guess, but flash densities have not advanced as fast as magnetic media have. Flash also suffers from the more your shrink it, the more problems you run into (reliability, leakage, etc). At least with current flash technology, anyway. If reliability is a concern, you don't want cutting edge highest density or highest performance.

And the flood in Thailand has still left a huge "bump" in that $/GB curve for HDDs. Still waiting for it to "return to normal". *sigh*

It's always a bit awkward trying to explain the entire theme and characters of Disneyworld's Splash Mountain to youngsters, since almost anyone younger than me has no clue what "Song of the South" is and has never seen it.

Not quite the full story.

Most, if not all, cheap to moderately expensive SOHO NASes use software raid. And since SOHO customers typically care more about data loss than performance, Bad Sector recovery is preferable to TLER (it's "safer" as far as your bits are concerned). NAS mfrs know this, and software raid is pretty flexible, and as such have fairly long timeouts. With long timeouts (several minutes or more), it's rare for a SOHO NAS to kick a non-TLER drive out of the array, and even if it did, the drive is going to keep trying for forever to recover that bad sector. For a home user, you're rather get the pictures of Johnny back than have the drive marked "dead" in 7 seconds, and hope you know how to rebuild an array before the next drive fails in 7 seconds.

TLER/Enterprise drives are designed for HARDWARE RAID, where performance is more important. When a drive starts acting funny, the RAID controller says, to heck with you! and kicks the drive out. Put in a replacement, off you go. In Enterprise environment, you don't want to sit there watching a drive work forever to fix a bad sector when the whole point of the RAID array is to go get the bad sector from a different disk. So from a performance/Enterprise perspective of RAID, the WD drives that support TLER are rather expensive (as are any enterprise class drives, look at a Seagate Constellation vs a Barracuda). Most Enterprise environments will be using the RAID for performance and uptime, but if the array has a massive problem (multiple failures, etc), they are backed up further by tape or disk-disk replication. A typical SOHO NAS has no backup - maybe some DVD-R burns put in a drawer if you're lucky.

For the SOHO market using cheap software-based RAID arrays, the non-TLER drives work just fine in RAID configurations.
Well, except for Caviar Greens. Avoid those like the plague in ANY kind of RAID array.

This. But it doesn't carry over the album art, unless that is in a new version I have been oblivious to (haven't checked in a while). I have had to go back through my ALACs in iTunes and reapply the same album art that was in the original FLAC (album art which could nicely be embedded with shell scripts). When I moved my iTunes from one computer to another, the new iTunes install lost all the album art in ALACs, and I had to do it all over. Guessing Apple doesn't store the album art into the *.alac file itself? Embebbed image data is so much easier.... at least I only have to do it once per file creation.

You're missing a big point. Adjacent carriers in the FM band are all transmitting at comparatively the same SIGNAL STRENGTH. As such, filter design is not too hard to do. Filters are not perfect, and some adjacent channels will always leak through. If the adjacent channels are attenuated enough, you get good reception. If all the signals start out at about the same signal strength this works ok.

But a ground based transmitter adjacent to a weak satellite downlink? You're starting with the two signals many many orders of magnitudes different in signal strength (millions even). Even if you reduce the adjacent channel interference, a signal that strong, even if 0.1% of it gets through the filter, will still swamp out your intended signal.

Ever tried listening to someone whisper to you while standing next to a jet engine? Earplugs do not really help, do they?

The military versions cost even more. Want your car-based GPS to cost more than your mortgage?

I would also point out that the frequency band GPS and satellite signals are in are much cheaper than terrestrial frequencies. As such, Lightspeed abused a (poorly conceived) FCC ruling for filling in poor reception areas with local ground based transmitters, to take cheap satellite spectrum, and repurpose it for a very large and high-powered terrestrial network, without paying similar licensing fees other terrestrial providers have to pay for their spectrum.

The whole loophole started by the FCC allowing ground based transmitters in the L1 band, but the intent was to supplement poor reception of satellite signals with some ground based ones. They never intended it to be repurposed for massive scale and high powered ground transmitters everywhere.

The laws of physics don't work well with you here when you have very weak signals from space competing with local, very strong signals on the ground, and only a few MHz apart in the GHz range. That was the original reason satellite based signals have their OWN spectrum. While it stinks for Lightspeed, they should know they never should have really gotten that spectrum from the FCC in the first place. The FCC dropped the ball on this one, but perhaps that's not too surprising how much corporations can buy influence in Washington these days.

The GPS units are not faulty. The spectrum they use are reserved for SATELLITE reception, not terrestrial broadcast. The signal levels received are so incredibly weak, that it is quite difficult, certainly not cheap, to build filters to filter out a nearby signal that is several order of magnitude stronger than yours. The spectrum was reserved, by the FCC, such that the neighboring spectrum would be like weak signals, which makes building receivers with high sensitivity possible and affordable.

I am sorry, but it was lightspeed who deceptively came in, got the spectrum, then changed from a mostly satellite based service (which would have been fine in that spectrum), to one consisting of tens of thousands of TERRESTRIAL transmitters in the L1 band, that simply overpower the nearby satellite downlink signals.

You just cannot build a high sensitivity receiver with a filter strong enough to filter out that kind of interference.

The FCC never should have granted them a go ahead in that frequency band in the first place.

Wish I mod points. This is the crux of the entire problem. These satellite downlink frequencies were originally setup by the FCC for only that use. Now that the FCC messed up and allowed this to proceed we have a completely different ballgame - satellite downlink frequencies being transmitted at terrestrial locations and high power levels, but the existing receiving equipment (some 10-15 years old), is supposed to continue to work in an environment like this?

Existing receivers do not expect that kind of high power/close neighbor interfence because A> to have to filter it would reduce the received signal and sensitivity anyway (lower performance), B> any such filtering would be more expensive (power and cost), C> no filtering is required since the FCC already made sure no one would be swamping the signal by effectively keeping this area of spectrum "quiet" (or at least the received signals are all at similar power levels with sufficient guard bands).

There are other frequencies and better receivers, but these are not your cheapo handheld battery powered GPS receivers. So while technical solutions might be found going forward, the real problem is that most of the commercial GPS equipment will basically stop working - so who should pay to replace everyone's GPS (from handheld's, to in car units, iPhone's, etc)??

If your IT is anything like my IT, full virus scan scheduled to run at "night" means begin at 5pm. I cannot kill the process, but at least I can suspend it, then resume it when I really leave for the evening. (Really sucks when you try to remote in from home in the evening to get some work done and the remote connection is slow as heck because of the AV scan). Would think 2am would be a better time, but no control over it.

You give me hope. Are you saying this is just stupid IE behavior, not Windows7? Then good, I haven't gotten around to installing Firefox yet. I had to use IE on the initial install to download motherboard drivers (obviously not the Intel NIC drivers), video drivers and such (and the 64-bit slackware 13.37 iso). So as soon as I get Firefox installed I can avoid that nonsense. Of course, these days, what version of Firefox to install? 3.6? 4? 5? 6? Yeesh. That's a whole 'nother debate. Heh.

Don't replace the 9TB RAID, just add an SSD for Windows (120GB or so). Get two and RAID0 if you want and it's yet faster still (however, be warned that most likely RAID with SSDs will lose TRIM support).

Keep the 9TB RAID array. My current motherboard (ASUS P8P67 Deluxe) has 4 SATA3G ports, 2 intel SATA6G ports (raid-able) and 2 Marvell SATA6G ports (raidable). 4 or 6 HDD systems are completely possible now without having to get an add on PCIe controller - assuming your case has room for the drives.

Totally agree. This inflexibility (and surprising disk space requirements - 25GB!) forced me to scrap my 15K RPM SCSI drive as my boot drive when I upgraded my computer to a Core i7. I typically had my OSes partitioned onto the 72GB SCSI disk, and had applications on another, and user data on yet another HDD. But it was real clear early on that splitting a 72GB drive between Windows 7 and Linux was going to be too small, especially if I couldn't get ALL the user data off of C:\. Since applications' load times would benefit from an SSD, I finally caved a little and got the 120GB SSD and let windows and all its applications just go to C:\, and then went through the agreeably painful process or relocating every folder that has a "Location" tab to another disk. There's about 10 or so directories to relocate in Windows 7, per user, rather than just one "My Documents" as in XP.

On the linux side, root is on the SSD, /var is on 15K RPM SCSI, /opt and /home on my SATA 7200pm disk (750GB), and /tmp on tmpfs (16GB RAM!). It's not that hard to properly partition for performance and ease of backup on the linux side. But my Windows7 partition is just a muck of everything so I guess if I want to back Windows up, just have to concede I have to create a 30GB partition image file or larger, just because everything is all thrown into C:\. On linux, I backup user data with rsync to external drives, and make parition images of the root and boot drives so that recovering on a new bare metal drive is really fast (just restore the partition image, then boot). Then create a new /home partition and rsync the data back. The partition images are small enough to put on a USB stick or DVD-R. But my Windows7 image has to stay on the NAS until I get a BDXL burner!!!