But not an eBook with DRM protections. One of the dead-tree variety.

Amen. I used OS/2 2.11, 3 and 4, and back then, and even now, the Workplace Shell was a beauty of a desktop interface. The fact that it was object oriented and had scripting support (back in '94-'95) was so nice to work with. Naturally, when OS/2 died it's slow painful death at the hands of IBM, I converted to Slackware 4.0 + KDE. The pinnacle there was 3.5.10 - I am still using it on my primary work computer stuck on RHEL4 - even without updates, it just works, runs fine on a 2.6GHz Core processor and only 2GB of RAM.

I have used KDE since 1.1.2 (had to bootstrap gcc and a bunch of GNU utilities onto Solaris 5.6 on an Ultra60 in order to compile it), and KDE 3.5.10 was probably the most productive desktop environment I've ever used. I am dismayed that it is getting harder and harder to maintain on newer distros (or even obsolete ones like RHEL3/4), despite the efforts of Trinity.

OSX though gets my vote for best overall desktop environment. Personally, it's not my favorite (KDE + Eterm terminals), but considering it's the one machine/interface that both my wife and I can stand to use, Apple does deserve a lot of credit there. My wife can have the Gui she likes, and I simply turn on the SSH server, and ssh into the macbook from my slackware machine or use the Terminal. Best of all worlds, except for the pricey hardware OSX typically comes on.

I upgraded to KDE-4.5 only when I upgraded my slackware distro to 13.37. This version is already quite dated, it's usable, but I still miss some kde-3.x features that still do not exist (that I am aware of) in KDE-4.

Sounds silly, but I really miss kpanel the most. It is the best virtual desktop manager I have used (from 3.5.x series), showing thumbnails of all applications (can recognize by sight), proper desktop backgrounds, and ability to move windows from desktop to desktop from inside the panel itself. KDE's (at least as of 4.5.5) panel app doesn't let me move windows, and it doesn't show image pixmaps of wallpapers or applications. Usually the text of a window doesn't fit, and it's quite unusable to be able to tell one window from another.

I also used to use Kmail heavily, but the new one seems so much more bloated, requiring SQL (is that akonadi?). Don't know why I need an SQL server running to read my email off an IMAP server (messages stored on the IMAP server, not "fetched" to the local KMAIL app).

I also don't quite get the Activities and Plasma stuff, would prefer to just have a plain virtual desktop like KDE-3.5.10.

I've thought about Trinity, but Slackware-13.37 isn't officially supported (despite being more than a year old)... maybe it would work, but I haven't had time to try yet. Probably makes more sense to try and upgrade slackware-13.37 from KDE-4.5.5 to a newer version.

I also must be one of those "older" folks who prefers the standard drop down cascaded menus. I don't need a "start" menu that isn't big enough to show me everything, and require scrolling a menu (what a stupid concept, thanks Windows7), or requires typing to find what I want. At least KDE can still be customized better than Windows7 can be.

I also prefer the older Konqueror file manager over Dolphin. Just from a user "experience", there seems to be more visual polish on KDE-4 but less functionality than KDE-3.5, in my opinion.

Is there a Subversion plugin for Konqueror or Dolphin yet (TortoiseSVN equivalent)? That's one thing that is sorely lacking from KDE-3.5.x series since SVN was only taking off about then.

At the time (mid-to-late 90s), the computer labs at college were full of ZIP drives. For a brief time, they became the best way to transfer word docs and homework from dorm computer to lab computer and back. But very short lived (2 years maybe?)

Being a /. member, I was early adopter, so naturally I already had a SCSI controller to support those new CDROM thingies that showed up in the early 90s, so it was naturally to get the SCSI/parallel port version of the ZIP drive. On my computer, SCSI speeds (40MB/sec), but parallel port compatibility with everyone else (external drive naturally). Using a DB25 connector. One problem. Iomega decided to not use a DIP switch to control the modes, but instead auto-detect the SCSI bus or parallel port. Except they screwed up the termination on the SCSI bus. So the only *approved* method of using the external device was as the SINGLE and ONLY device on the SCSI host bus adapter. Seriously? My SCSI bus was notorious for parity errors and data corruption issues with the Iomega ZIP drive. I ultimately decided my data integrity was more important (several SCSI HDDs and a CDROM burner and tape drive), and the ZIP was then dead to me.

So it wasn't just the click of death that killed it. The Parallel/SCSI combo version had potential, but that too was foobar'd.

"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)??