Neal Stephenson - In the Beginning was the Command Line

Presumably there are godlike Unix hackers somewhere in the world who don't need to use these little scripts and options files as crutches, and who can simply pound out fantastically complex command lines without making typographical errors and without having to spend hours flipping through documentation. But I'm not one of them. Like almost all Linux users, I depend on having all of those details hidden away in thousands of little ASCII text files, which are in turn wedged into the recesses of the Unix filesystem. When I want to change something about the way my system works, I edit those files. I know that if I don't keep track of every little change I've made, I won't be able to get your system back in working order after I've gotten it all messed up. Keeping hand-written logs is tedious, not to mention kind of anachronistic. But it's necessary.

I probably could have saved myself a lot of headaches by doing business with a company called Cygnus Support, which exists to provide assistance to users of free software. But I didn't, because I wanted to see if I could do it myself. The answer turned out to be yes, but just barely. And there are many tweaks and optimizations that I could probably make in my system that I have never gotten around to attempting, partly because I get tired of being a Morlock some days, and partly because I am afraid of fouling up a system that generally works well.

Though Linux works for me and many other users, its sheer power and generality is its Achilles' heel. If you know what you are doing, you can buy a cheap PC from any computer store, throw away the Windows discs that come with it, turn it into a Linux system of mind-boggling complexity and power. You can hook it up to twelve other Linux boxes and make it into part of a parallel computer. You can configure it so that a hundred different people can be logged onto it at once over the Internet, via as many modem lines, Ethernet cards, TCP/IP sockets, and packet radio links. You can hang half a dozen different monitors off of it and play DOOM with someone in Australia while tracking communications satellites in orbit and controlling your house's lights and thermostats and streaming live video from your web-cam and surfing the Net and designing circuit boards on the other screens. But the sheer power and complexity of the system--the qualities that make it so vastly technically superior to other OSes--sometimes make it seem too formidable for routine day-to-day use.

Sometimes, in other words, I just want to go to Disneyland.

The ideal OS for me would be one that had a well-designed GUI that was easy to set up and use, but that included terminal windows where I could revert to the command line interface, and run GNU software, when it made sense. A few years ago, Be Inc. invented exactly that OS. It is called the BeOS.

Many people in the computer business have had a difficult time grappling with Be, Incorporated, for the simple reason that nothing about it seems to make any sense whatsoever. It was launched in late 1990, which makes it roughly contemporary with Linux. From the beginning it has been devoted to creating a new operating system that is, by design, incompatible with all the others (though, as we shall see, it is compatible with Unix in some very important ways). If a definition of "celebrity" is someone who is famous for being famous, then Be is an anti-celebrity. It is famous for not being famous; it is famous for being doomed. But it has been doomed for an awfully long time.

Be's mission might make more sense to hackers than to other people. In order to explain why I need to explain the concept of cruft, which, to people who write code, is nearly as abhorrent as unnecessary repetition.

If you've been to San Francisco you may have seen older buildings that have undergone "seismic upgrades," which frequently means that grotesque superstructures of modern steelwork are erected around buildings made in, say, a Classical style. When new threats arrive--if we have an Ice Age, for example--additional layers of even more high-tech stuff may be constructed, in turn, around these, until the original building is like a holy relic in a cathedral--a shard of yellowed bone enshrined in half a ton of fancy protective junk.

Analogous measures can be taken to keep creaky old operating systems working. It happens all the time. Ditching an worn-out old OS ought to be simplified by the fact that, unlike old buildings, OSes have no aesthetic or cultural merit that makes them intrinsically worth saving. But it doesn't work that way in practice. If you work with a computer, you have probably customized your "desktop," the environment in which you sit down to work every day, and spent a lot of money on software that works in that environment, and devoted much time to familiarizing yourself with how it all works. This takes a lot of time, and time is money. As already mentioned, the desire to have one's interactions with complex technologies simplified through the interface, and to surround yourself with virtual tchotchkes and lawn ornaments, is natural and pervasive--presumably a reaction against the complexity and formidable abstraction of the computer world. Computers give us more choices than we really want. We prefer to make those choices once, or accept the defaults handed to us by software companies, and let sleeping dogs lie. But when an OS gets changed, all the dogs jump up and start barking.

The average computer user is a technological antiquarian who doesn't really like things to change. He or she is like an urban professional who has just bought a charming fixer-upper and is now moving the furniture and knicknacks around, and reorganizing the kitchen cupboards, so that everything's just right. If it is necessary for a bunch of engineers to scurry around in the basement shoring up the foundation so that it can support the new cast-iron claw-foot bathtub, and snaking new wires and pipes through the walls to supply modern appliances, why, so be it--engineers are cheap, at least when millions of OS users split the cost of their services.

Likewise, computer users want to have the latest Pentium in their machines, and to be able to surf the web, without messing up all the stuff that makes them feel as if they know what the hell is going on. Sometimes this is actually possible. Adding more RAM to your system is a good example of an upgrade that is not likely to screw anything up.

Alas, very few upgrades are this clean and simple. Lawrence Lessig, the whilom Special Master in the Justice Department's antitrust suit against Microsoft, complained that he had installed Internet Explorer on his computer, and in so doing, lost all of his bookmarks--his personal list of signposts that he used to navigate through the maze of the Internet. It was as if he'd bought a new set of tires for his car, and then, when pulling away from the garage, discovered that, owing to some inscrutable side-effect, every signpost and road map in the world had been destroyed. If he's like most of us, he had put a lot of work into compiling that list of bookmarks. This is only a small taste of the sort of trouble that upgrades can cause. Crappy old OSes have value in the basically negative sense that changing to new ones makes us wish we'd never been born.

All of the fixing and patching that engineers must do in order to give us the benefits of new technology without forcing us to think about it, or to change our ways, produces a lot of code that, over time, turns into a giant clot of bubble gum, spackle, baling wire and duct tape surrounding every operating system. In the jargon of hackers, it is called "cruft." An operating system that has many, many layers of it is described as "crufty." Hackers hate to do things twice, but when they see something crufty, their first impulse is to rip it out, throw it away, and start anew.