In the Beginning...Was the Command Line

by Neal Stephenson

  Anyway, the window manager acts as an intermediary between XWindows and whatever software you want to use. It draws the window frames, menus, and so on, while the applications themselves draw the actual content in the windows. The applications might be of any sort: text editors, web browsers, graphics packages, or utility programs—such as a clock or calculator. In other words, from this point on, you feel as if you have been shunted into a parallel universe that is quite similar to the familiar Apple or Microsoft one, but slightly and pervasively different. The premier graphics program under Apple/Microsoft is Adobe Photoshop, but under Linux it’s something called the GIMP. Instead of the Microsoft Office Suite, you can buy something called ApplixWare. Many commercial software packages, such as Mathematica, Netscape Communicator, and Adobe Acrobat, are available in Linux versions, and depending on how you set up your window manager, you can make them look and behave just as they would under MacOS or Windows.

  But there is one type of window you’ll see on Linux GUI that is rare or nonexistent under other OSes. These windows are called “xterm” and contain nothing but lines of text—this time, black text on a white background, though you can make them be different colors if you choose. Each xterm window is a separate command line interface—a tty in a window. So even when you are in full GUI mode, you can still talk to your Linux machine through a command line interface.

  There are many good pieces of Unix software that do not have GUIs at all. This might be because they were developed before XWindows was available, or because the people who wrote them did not want to suffer through all the hassle of creating a GUI, or because they simply do not need one. In any event, those programs can be invoked by typing their names into the command line of an xterm window. The whoami command, mentioned earlier, is a good example. There is another called wc (“word count”), which simply returns the number of lines, words, and characters in a text file.

  The ability to run these little utility programs on the command line is a great virtue of Unix, and one that is unlikely to be duplicated by pure GUI operating systems. The wc command, for example, is the sort of thing that is easy to write with a command line interface. It probably does not consist of more than a few lines of code, and a clever programmer could probably write it in a single line. In compiled form it takes up just a few bytes of disk space. But the code required to give the same program a graphical user interface would probably run into hundreds or even thousands of lines, depending on how fancy the programmer wanted to make it. Compiled into a runnable piece of software, it would have a large overhead of GUI code. It would be slow to launch and it would use up a lot of memory. This would simply not be worth the effort, and so wc would never be written as an independent program at all. Instead users would have to wait for a word count feature to appear in a commercial software package.

  GUIs tend to impose a large overhead on every single piece of software, even the smallest, and this overhead completely changes the programming environment. Small utility programs are no longer worth writing. Their functions, instead, tend to get swallowed up into omnibus software packages. As GUIs get more complex, and impose more and more overhead, this tendency becomes more pervasive, and the software packages grow ever more colossal. After a point they begin to merge with each other, as Microsoft Word and Excel and PowerPoint have merged into Microsoft Office: a stupendous software Wal-Mart sitting on the edge of a town filled with tiny shops that are all boarded up.

  It is an unfair analogy, because when a tiny shop gets boarded up it means that some small shopkeeper has lost his business. Of course nothing of the kind happens when wc becomes subsumed into one of Microsoft Word’s countless menu items. The only real drawback is a loss of flexibility for the user, but it is a loss that most customers obviously do not notice or care about. The most serious drawback to the Wal-Mart approach is that most users only want or need a tiny fraction of what is contained in these giant software packages. The remainder is clutter, dead weight. And yet the user in the next cubicle over will have completely different opinions as to what is useful and what isn’t.

  The other important thing to mention, here, is that Microsoft has included a genuinely cool feature in the Office package: a Visual Basic programming package. Basic is the first computer language that I learned, back when I was using the paper tape and the teletype. By using Visual Basic—a modernized version of the language that comes with Office—you can write your own little utility programs that know how to interact with all of the little doohickeys, gewgaws, bells, and whistles in Office. Basic is easier to use than the languages typically employed in Unix command line programming, and Office has reached many, many more people than the GNU tools. And so it is quite possible that this feature of Office will, in the end, spawn more hacking than GNU.

  But now I’m talking about application software, not operating systems. And as I’ve said, Microsoft’s application software tends to be very good stuff. I don’t use it very much, because I am nowhere near their target market. If Microsoft ever makes a software package that I use and like, then it really will be time to dump their stock, because I am a market segment of one.

  GEEK FATIGUE

  Over the years that I’ve been working with Linux I have filled three and a half notebooks logging my experiences. I only begin writing things down when I’m doing something complicated, like setting up XWindows or fooling around with my Internet connection, and so these notebooks contain only the record of my struggles and frustrations. When things are going well for me, I’ll work along happily for many months without jotting down a single note. So these notebooks make for pretty bleak reading. Changing anything under Linux is a matter of opening up various of those little ASCII text files and changing a word here and a character there, in ways that are extremely significant to how the system operates.

  Many of the files that control how Linux operates are nothing more than command lines that became so long and complicated that not even Linux hackers could type them correctly. When working with something as powerful as Linux, you can easily devote a full half-hour to engineering a single command line. For example, the “find” command, which searches your file system for files that match certain criteria, is fantastically powerful and general. Its “man” is eleven pages long, and these are pithy pages; you could easily expand them into a whole book. And if that is not complicated enough in and of itself, you can always pipe the output of one Unix command to the input of another, equally complicated one. The “pon” command, which is used to fire up a PPP connection to the Internet, requires so much detailed information that it is basically impossible to launch it entirely from the command line. Instead, you abstract big chunks of its input into three or four different files. You need a dialing script, which is effectively a little program telling it how to dial the phone and respond to various events; an options file, which lists up to about sixty different options on how the PPP connection is to be set up; and a secrets file, giving information about your password.

  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 file system. 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 the system back in working order after I’ve gotten it all messed up. Keeping handwritten 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 d
o it myself. The answer turned out to be yes, but just barely. 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 disks 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 on to 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.

  ETRE

  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 anticelebrity. 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 tons of fancy protective junk.

  Analogous measures can be taken to keep creaky old operating systems working. It happens all the time. Ditching a 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 Microsoft 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 cruft 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.

  If Mark Twain were brought back to San Francisco today and dropped into one of these old seismically upgraded buildings, it would look just the same to him, with all the doors and windows in the same places—but if he stepped outside, he wouldn’t recognize it. And—if he’d been brought back with his wits intact—he might question whether the building had been worth going to so much trouble to save. At some point, one must ask the question: Is this really worth it, or should we maybe just tear it down and put up a good one? Should we throw another human wave of structural engineers at stabilizing the Leaning Tower of Pisa, or should we just let the damn thing fall over and build a tower that doesn’t suck?

  Like an upgrade to an old building, cruft always seems like a good idea when the first layers of it go on—just routine maintenance, sound prudent management. This is especially true if (as it were) you never look into the cellar, or behind the drywall. But if you are a hacker who spends all his time looking at it from that point of view, cruft is fundamentally disgusting, and you can’t avoid wanting to go after it with a crowbar. Or, better yet, simply walk out of the building—let the Leaning Tower of Pisa fall over—and go make a new one that doesn’t lean.

  For a long time it was obvious to Apple, Microsoft, and their customers that the first generation of GUI operating systems was doomed, and that they would eventually need to be ditched and replaced with completely fresh ones. During the late eighties and early nineties, Apple launched a few abortive efforts to make fundamentally new post-Mac OSes, such as Pink and Taligent. When those efforts failed, they launched a new project called Copland—which also failed. In 1997 they flirted with the idea of acquiring
Be, but instead they acquired Next, which has an OS called NextStep, which is, in effect, another variant of Unix. As these efforts went on, and on, and on, and failed and failed and failed, Apple’s engineers, who were among the best in the business, kept layering on the cruft. They were gamely trying to turn the little toaster into a multitasking, Internet-savvy machine, and did an amazingly good job of it for a while—sort of like a movie hero running across a jungle river by hopping across crocodiles’ backs. But in the real world you eventually run out of crocodiles, or step on a really smart one.

  Speaking of which, Microsoft tackled the same problem in a considerably more orderly way by creating a new OS called Windows NT, which is explicitly intended to be a direct competitor of Unix. NT stands for “New Technology,” which might be read as an explicit rejection of cruft. And indeed, NT is reputed to be a lot less crufty than what MacOS eventually turned into; at one point the documentation needed to write code on the Mac filled something like twenty-four binders. Windows 95 was, and Windows 98 is, crufty because they have to be backward-compatible with older Microsoft OSes. Linux deals with the cruft problem in the same way that, according to the tales we used to be told in school, Eskimos supposedly dealt with senior citizens: if you insist on using old versions of Linux software, you will sooner or later find yourself drifting through the Bering Straits on a dwindling ice floe. They can get away with this because most of the software is free, so it costs nothing to download up-to-date versions, and because most Linux users are Morlocks.

  The great idea behind BeOS was to start from a clean sheet of paper and design an OS the right way. And that is exactly what they did. This was obviously a good idea from an aesthetic standpoint, but does not a sound business plan make. Some people I know in the GNU/Linux world are annoyed with Be for going off on this quixotic adventure when their formidable skills could have been put to work helping to promulgate Linux.