Tag Archives: computers

The Terabytes are coming!

A few months ago, I saw a 500-gigabyte hard drive at Fry’s. That’s when I realized that terabyte* drives were not far away.

Oh, sure, you’ve been able to put together multi-terabytes of storage using RAID arrays and clusters, but we’re talking something the average consumer will be able to walk into a store and buy. Something that the slightly-above-average consumer will be able to put in his computer with just a screwdriver and a cable.

It won’t be long. CNET reports that Hitachi anticipates a 1-TB drive by the end of the year.

Naturally, anyone who installs one of these will probably fill it up within a week.

(via Slashdot)

Edit: Something just occurred to me. In light of Mezzoblue’s recent article on naming drives, I’ve come up with the perfect name for my first terabyte drive: Ivan.

*Either 1,000 gigabytes or 1,024 gigabytes, depending on which definition you’re using. Is there a consensus yet?

Ahead of their time

Remember when the web was young, and email was just gaining popularity in the mainstream, and there was a slew of virus hoaxes like the Good Times Virus, or It Takes Guts to Say Jesus, or Elf Bowling?

Remember painstakingly explaining to people that no, your computer couldn’t get a virus just by reading an email, you had to click on an attachment? That images were safe to open? Remember when the worst people had to worry about from web pages was unwanted cookies? Getting a virus just from looking at a web page? Preposterous! And a virus that ran up your credit card? Ridiculous!

It’s sad to think that all those “ridiculous” things are now possible—in fact, they’re commonplace. Look back at that link up there. It’s Snopes’ page on computer virus warnings. Way back when, they were all bogus. These days, most of them are real.

So what’s next? Well, they keep talking about Internet-aware appliances, so a future virus probably could “recalibrate your refrigerator’s coolness setting so all your ice cream goes melty.”

Browser War, OS War

It occurred to me today that if you lay out the three major players in computer operating systems and the three major players in web browsers, the results track remarkably well.

  • Windows and Internet Explorer. The dominant player. Obtained that position by being good enough, cheap enough, and promoted enough to win a protracted two-way battle. Detractors claim the victory was primarily due to marketing and business practices, not quality. Plagued by a public perception of insecurity. Currently trying to maintain that lead against an opponent unlike any they’ve faced before. Believes itself to be technically superior to the other options.
  • Linux and Firefox. Open source product with a core team and hundreds of volunteer contributors. Originally created as a replacement for a previous major player. Very extensible. Promoted as a more secure alternative, but has faced growing pains with its own security problems. Highly regarded among many computer power users, beginning to gain mainstream acceptance and challenging the dominant player. Believes itself to be technically superior to the other options.
  • Mac OS and Opera. Has been there since the beginning. Constantly innovating, pioneering ideas that get wider exposure when their competitors adopt them. Very dedicated fan base that never seems to grow enough to challenge the dominant player. Has been declared doomed time and time again, but keeps going strong. Believes itself to be technically superior to the other options.

It breaks down, of course. Traditional UNIX is missing from the OS wars, though it provides a nice analogy to Netscape for Firefox. The battle lines don’t quite track either, since the previous wars were Windows vs. Mac and IE vs. Netscape. And Safari’s missing entirely. But it’s interesting to see the same three roles in play.

Fragile Tech

I got into work this morning to find my desk’s keyboard and KVM switch non-responsive. The only way to reset the switch was to turn it off and back on, which meant disconnecting all the keyboard and mouse cables. (A KVM switch doesn’t need much power, so many of them just draw power from the computer, the same way an actual keyboard or mouse would.) It switched immediately to the Linux box, which was happily displaying its screen saver, so I switched back to the Windows box where it had been… and it got stuck again.

OK, so the Windows box had crashed. It’s been doing that lately, though usually I actually get a blue screen with the dreaded IRQL_NOT_LESS_THAN_OR_EQUAL, which could mean anything from a driver conflict to failing hardware. I haven’t taken the time to track it down, but maybe I should. I rebooted the Windows box, which seems fine for the moment, though there’s no sign of the crash—or even my forced reboot—in the system log.

Then I switched over to the Linux box, and the mouse wasn’t responding. When the mouse gets messed up, sometimes it’s enough to switch out of X into text mode and back. No luck. Sometimes closing X entirely and starting it again is enough. Not this time. I actually had to reboot the Linux box to get my mouse back. That really annoyed me.

So here are three things that went wrong.

  1. The Windows box crashed. This is probably a driver or hardware problem.
  2. The KVM switch got stuck. This should not be possible. Even if it’s getting confusing signals from one set of ports, it should be able to switch to another port.
  3. The Linux box (Fedora Core 4) could not recover from having the mouse unplugged for 10 seconds. There should be an easy way to tell it to check for the mouse again.

It’s #2 and #3 that bug me the most. Maybe it’s the man-bites-dog effect (I expect Windows to crash and/or require frequent reboots, so it’s more annoying when Linux does it), or maybe it’s just the fact that they’re simple error-recovery issues. I mean, seriously, unplugging the mouse for a few seconds makes it unusable?

Update: I forgot to check the second Windows box on the switch. It also had stopped responding to the mouse even after I reset the KVM switch. I’m beginning to think that problem #3 was in the switch itself, not the Linux mouse driver, since the non-crashed Windows box had the exact same problem.