by Neal Stephenson
This is a selection from the book/pamphlet/series of essays
from Neal Stephenson called "In the Beginning was the
Command Line. I've excerpted the parts that are fun,
exciting, and relevant to our class discussion.
About twenty years ago Jobs and Wozniak, the founders of Apple, came up with the very strange idea of selling information processing machines for use in the home. The business took off, and its founders made a lot of money and received the credit they deserved for being daring visionaries. But around the same time, Bill Gates and Paul Allen came up with an idea even stranger and more fantastical: selling computer operating systems. This was much weirder than the idea of Jobs and Wozniak. A computer at least had some sort of physical reality to it. It came in a box, you could open it up and plug it in and watch lights blink. An operating system had no tangible incarnation at all. It arrived on a disk, of course, but the disk was, in effect, nothing more than the box that the OS came in. The product itself was a very long string of ones and zeroes that, when properly installed and coddled, gave you the ability to manipulate other very long strings of ones and zeroes. Even those few who actually understood what a computer operating system was were apt to think of it as a fantastically arcane engineering prodigy, like a breeder reactor or a U-2 spy plane, and not something that could ever be (in the parlance of high-tech) "productized."
Yet now the company that Gates and Allen founded is selling operating systems like Gillette sells razor blades. New releases of operating systems are launched as if they were Hollywood blockbusters, with celebrity endorsements, talk show appearances, and world tours. The market for them is vast enough that people worry about whether it has been monopolized by one company. Even the least technically-minded people in our society now have at least a hazy idea of what operating systems do; what is more, they have strong opinions about their relative merits. It is commonly understood, even by technically unsophisticated computer users, that if you have a piece of software that works on your Macintosh, and you move it over onto a Windows machine, it will not run. That this would, in fact, be a laughable and idiotic mistake, like nailing horseshoes to the tires of a Buick.
A person who went into a coma before Microsoft was founded, and woke up now, could pick up this morning's New York Times and understand everything in it — almost:
Item: the richest man in the world made his fortune from-what? Railways? Shipping? Oil? No, operating systems. Item: the Department of Justice is tackling Microsoft's supposed OS monopoly with legal tools that were invented to restrain the power of Nineteenth-Century robber barons. Item: a woman friend of mine recently told me that she'd broken off a (hitherto) stimulating exchange of e-mail with a young man. At first he had seemed like such an intelligent and interesting guy, she said, but then "he started going all PC-versus-Mac on me."
What the hell is going on here? And does the operating system business have a future, or only a past? Here is my view, which is entirely subjective; but since I have spent a fair amount of time not only using, but programming, Macintoshes, Windows machines, Linux boxes and the BeOS, perhaps it is not so ill-informed as to be completely worthless. This is a subjective essay, more review than research paper, and so it might seem unfair or biased compared to the technical reviews you can find in PC magazines. But ever since the Mac came out, our operating systems have been based on metaphors, and anything with metaphors in it is fair game as far as I'm concerned.
Around the time that Jobs, Wozniak, Gates, and Allen were dreaming up these unlikely schemes, I was a teenager living in Ames, Iowa. One of my friends' dads had an old MGB sports car rusting away in his garage. Sometimes he would actually manage to get it running and then he would take us for a spin around the block, with a memorable look of wild youthful exhilaration on his face; to his worried passengers, he was a madman, stalling and backfiring around Ames, Iowa and eating the dust of rusty Gremlins and Pintos, but in his own mind he was Dustin Hoffman tooling across the Bay Bridge with the wind in his hair.
In retrospect, this was telling me two things about people's relationship to technology. One was that romance and image go a long way towards shaping their opinions. If you doubt it (and if you have a lot of spare time on your hands) just ask anyone who owns a Macintosh and who, on those grounds, imagines him- or herself to be a member of an oppressed minority group.
The other, somewhat subtler point, was that interface is very important. Sure, the MGB was a lousy car in almost every way that counted: balky, unreliable, underpowered. But it was fun to drive. It was responsive. Every pebble on the road was felt in the bones, every nuance in the pavement transmitted instantly to the driver's hands. He could listen to the engine and tell what was wrong with it. The steering responded immediately to commands from his hands. To us passengers it was a pointless exercise in going nowhere — about as interesting as peering over someone's shoulder while he punches numbers into a spreadsheet. But to the driver it was an experience. For a short time he was extending his body and his senses into a larger realm, and doing things that he couldn't do unassisted.
The analogy between cars and operating systems is not half bad, and so let me run with it for a moment, as a way of giving an executive summary of our situation today.
Imagine a crossroads where four competing auto dealerships are situated. One of them (Microsoft) is much, much bigger than the others. It started out years ago selling three-speed bicycles (MS-DOS); these were not perfect, but they worked, and when they broke you could easily fix them.
There was a competing bicycle dealership next door (Apple) that one day began selling motorized vehicles — expensive but attractively styled cars with their innards hermetically sealed, so that how they worked was something of a mystery.
The big dealership responded by rushing a moped upgrade kit (the original Windows) onto the market. This was a Rube Goldberg contraption that, when bolted onto a three-speed bicycle, enabled it to keep up, just barely, with Apple-cars. The users had to wear goggles and were always picking bugs out of their teeth while Apple owners sped along in hermetically sealed comfort, sneering out the windows. But the Micro-mopeds were cheap, and easy to fix compared with the Apple-cars, and their market share waxed.
Eventually the big dealership came out with a full-fledged car: a colossal station wagon (Windows 95). It had all the aesthetic appeal of a Soviet worker housing block, it leaked oil and blew gaskets, and it was an enormous success. A little later, they also came out with a hulking off-road vehicle intended for industrial users (Windows NT) which was no more beautiful than the station wagon, and only a little more reliable.
Since then there has been a lot of noise and shouting, but little has changed. The smaller dealership continues to sell sleek Euro-styled sedans and to spend a lot of money on advertising campaigns. They have had GOING OUT OF BUSINESS! signs taped up in their windows for so long that they have gotten all yellow and curly. The big one keeps making bigger and bigger station wagons and ORVs.
On the other side of the road are two competitors that have come along more recently.
One of them (Be, Inc.) is selling fully operational Batmobiles (the BeOS). They are more beautiful and stylish even than the Euro-sedans, better designed, more technologically advanced, and at least as reliable as anything else on the market — and yet cheaper than the others.
With one exception, that is: Linux, which is right next door, and which is not a business at all. It's a bunch of RVs, yurts, tepees, and geodesic domes set up in a field and organized by consensus. The people who live there are making tanks. These are not old-fashioned, cast-iron Soviet tanks; these are more like the M1 tanks of the U.S. Army, made of space-age materials and jammed with sophisticated technology from one end to the other. But they are better than Army tanks. They've been modified in such a way that they never, ever break down, are light and maneuverable enough to use on ordinary streets, and use no more fuel than a subcompact car. These tanks are being cranked out, on the spot, at a terrific pace, and a vast number of them are lined up along the edge of the road with keys in the ignition. Anyone who wants can simply climb into one and drive it away for free.
Customers come to this crossroads in throngs, day and night. Ninety percent of them go straight to the biggest dealership and buy station wagons or off-road vehicles. They do not even look at the other dealerships.
Of the remaining ten percent, most go and buy a sleek Euro-sedan, pausing only to turn up their noses at the philistines going to buy the station wagons and ORVs. If they even notice the people on the opposite side of the road, selling the cheaper, technically superior vehicles, these customers deride them cranks and half-wits.
The Batmobile outlet sells a few vehicles to the occasional car nut who wants a second vehicle to go with his station wagon, but seems to accept, at least for now, that it's a fringe player.
The group giving away the free tanks only stays alive because it is staffed by volunteers, who are lined up at the edge of the street with bullhorns, trying to draw customers' attention to this incredible situation. A typical conversation goes something like this:
Hacker with bullhorn: "Save your money! Accept one of our free tanks! It is invulnerable, and can drive across rocks and swamps at ninety miles an hour while getting a hundred miles to the gallon!"
Prospective station wagon buyer: "I know what you say is true... but... er... I don't know how to maintain a tank!"
Bullhorn: "You don't know how to maintain a station wagon either!"
Buyer: "But this dealership has mechanics on staff. If something goes wrong with my station wagon, I can take a day off work, bring it here, and pay them to work on it while I sit in the waiting room for hours, listening to elevator music."
Bullhorn: "But if you accept one of our free tanks we will send volunteers to your house to fix it for free while you sleep!"
Buyer: "Stay away from my house, you freak!"
Bullhorn: "But..."
Buyer: "Can't you see that everyone is buying station wagons?"
The connection between cars, and ways of interacting with computers, wouldn't have occurred to me at the time I was being taken for rides in that MGB. I had signed up to take a computer programming class at Ames High School. After a few introductory lectures, we students were granted admission into a tiny room containing a teletype, a telephone, and an old-fashioned modem consisting of a metal box with a pair of rubber cups on the top ...
Note: many readers, making their way through that last sentence, probably felt an initial pang of dread that this essay was about to turn into a tedious, codgerly reminiscence about how tough we had it back in the old days; rest assured that I am actually positioning my pieces on the chessboard, as it were, in preparation to make a point about truly hip and up-to-the minute topics like Open Source Software.
The teletype was exactly the same sort of machine that had been used, for decades, to send and receive telegrams. It was basically a loud typewriter that could only produce UPPERCASE LETTERS. Mounted to one side of it was a smaller machine with a long reel of paper tape on it, and a clear plastic hopper underneath.
In order to connect this device (which was not a computer at all) to the Iowa State University mainframe across town, you would pick up the phone, dial the computer's number, listen for strange noises, and then slam the handset down into the rubber cups. If your aim was true, one would wrap its neoprene lips around the earpiece and the other around the mouthpiece, consummating a kind of informational soixante-neuf. The teletype would shudder as it was possessed by the spirit of the distant mainframe, and begin to hammer out cryptic messages.
Since computer time was a scarce resource, we used a sort of batch processing technique. Before dialing the phone, we would turn on the tape puncher (a subsidiary machine bolted to the side of the teletype) and type in our programs. Each time we depressed a key, the teletype would bash out a letter on the paper in front of us, so we could read what we'd typed; but at the same time it would convert the letter into a set of eight binary digits, or bits, and punch a corresponding pattern of holes across the width of a paper tape. The tiny disks of paper knocked out of the tape would flutter down into the clear plastic hopper, which would slowly fill up what can only be described as actual bits. On the last day of the school year, the smartest kid in the class (not me) jumped out from behind his desk and flung several quarts of these bits over the head of our teacher, like confetti, as a sort of semi-affectionate practical joke. The image of this man sitting there, gripped in the opening stages of an atavistic fight-or-flight reaction, with millions of bits (megabytes) sifting down out of his hair and into his nostrils and mouth, his face gradually turning purple as he built up to an explosion, is the single most memorable scene from my formal education.
Anyway, it will have been obvious that my interaction with the computer was of an extremely formal nature, being sharply divided up into different phases, viz.: (1) sitting at home with paper and pencil, miles and miles from any computer, I would think very, very hard about what I wanted the computer to do, and translate my intentions into a computer language — a series of alphanumeric symbols on a page. (2) I would carry this across a sort of informational cordon sanitaire (three miles of snowdrifts) to school and type those letters into a machine — not a computer — which would convert the symbols into binary numbers and record them visibly on a tape. (3) Then, through the rubber-cup modem, I would cause those numbers to be sent to the university mainframe, which would (4) do arithmetic on them and send different numbers back to the teletype. (5) The teletype would convert these numbers back into letters and hammer them out on a page and (6) I, watching, would construe the letters as meaningful symbols.
The division of responsibilities implied by all of this is admirably clean: computers do arithmetic on bits of information. Humans construe the bits as meaningful symbols. But this distinction is now being blurred, or at least complicated, by the advent of modern operating systems that use, and frequently abuse, the power of metaphor to make computers accessible to a larger audience. Along the way — possibly because of those metaphors, which make an operating system a sort of work of art — people start to get emotional, and grow attached to pieces of software in the way that my friend's dad did to his MGB.
People who have only interacted with computers through graphical user interfaces like the MacOS or Windows — which is to say, almost everyone who has ever used a computer — may have been startled, or at least bemused, to hear about the telegraph machine that I used to communicate with a computer in 1973. But there was, and is, a good reason for using this particular kind of technology. Human beings have various ways of communicating to each other, such as music, art, dance, and facial expressions, but some of these are more amenable than others to being expressed as strings of symbols. Written language is the easiest of all, because, of course, it consists of strings of symbols to begin with. If the symbols happen to belong to a phonetic alphabet (as opposed to, say, ideograms), converting them into bits is a trivial procedure, and one that was nailed, technologically, in the early nineteenth century, with the introduction of Morse code and other forms of telegraphy.
We had a human/computer interface a hundred years before we had computers. When computers came into being around the time of the Second World War, humans, quite naturally, communicated with them by simply grafting them on to the already-existing technologies for translating letters into bits and vice versa: teletypes and punch card machines.
These embodied two fundamentally different approaches to computing. When you were using cards, you'd punch a whole stack of them and run them through the reader all at once, which was called batch processing. You could also do batch processing with a teletype, as I have already described, by using the paper tape reader, and we were certainly encouraged to use this approach when I was in high school. But — though efforts were made to keep us unaware of this — the teletype could do something that the card reader could not. On the teletype, once the modem link was established, you could just type in a line and hit the return key. The teletype would send that line to the computer, which might or might not respond with some lines of its own, which the teletype would hammer out — producing, over time, a transcript of your exchange with the machine. This way of doing it did not even have a name at the time, but when, much later, an alternative became available, it was retroactively dubbed the Command Line Interface.
When I moved on to college, I did my computing in large, stifling rooms where scores of students would sit in front of slightly updated versions of the same machines and write computer programs: these used dot-matrix printing mechanisms, but were (from the computer's point of view) identical to the old teletypes. By that point, computers were better at time-sharing — that is, mainframes were still mainframes, but they were better at communicating with a large number of terminals at once. Consequently, it was no longer necessary to use batch processing. Card readers were shoved out into hallways and boiler rooms, and batch processing became a nerds-only kind of thing, and consequently took on a certain eldritch flavor among those of us who even knew it existed. We were all off the Batch, and on the Command Line, interface now — my very first shift in operating system paradigms, if only I'd known it.
A huge stack of accordion-fold paper sat on the floor underneath each one of these glorified teletypes, and miles of paper shuddered through their platens. Almost all of this paper was thrown away or recycled without ever having been touched by ink — an ecological atrocity so glaring that those machines soon replaced by video terminals — so-called "glass teletypes" — which were quieter and didn't waste paper. Again, though, from the computer's point of view these were indistinguishable from World War II-era teletype machines. In effect we still used Victorian technology to communicate with computers until about 1984, when the Macintosh was introduced with its Graphical User Interface. Even after that, the Command Line continued to exist as an underlying stratum — a sort of brainstem reflex — of many modern computer systems all through the heyday of Graphical User Interfaces, or GUIs as I will call them from now on.
Now the first job that any coder needs to do when writing a new piece of software is to figure out how to take the information that is being worked with (in a graphics program, an image; in a spreadsheet, a grid of numbers) and turn it into a linear string of bytes. These strings of bytes are commonly called files or (somewhat more hiply) streams. They are to telegrams what modern humans are to Cro-Magnon man, which is to say the same thing under a different name. All that you see on your computer screen — your Tomb Raider, your digitized voice mail messages, faxes, and word processing documents written in thirty-seven different typefaces — is still, from the computer's point of view, just like telegrams, except much longer, and demanding of more arithmetic.
The quickest way to get a taste of this is to fire up your web browser, visit a site, and then select the View/Document Source menu item. You will get a bunch of computer code that looks something like this:
<HTML>
<HEAD>
<TITLE>Welcome to the Avon Books Homepage</TITLE>
</HEAD>
<MAP NAME="left0199">
<AREA SHAPE="rect" COORDS="16,56,111,67" HREF="/bard/"> <AREA SHAPE="rect" COORDS="14,77,111,89" HREF="/eos/"> <AREA SHAPE="rect" COORDS="17,98,112,110" HREF="/twilight/"> <AREA SHAPE="rect" COORDS="18,119,112,131" HREF="/avon_user/category.html?category_id=271"> <AREA SHAPE="rect" COORDS="19,140,112,152" HREF="http://www.goners.com/"> <AREA SHAPE="rect" COORDS="18,161,111,173" HREF="http://www.spikebooks.com/"> <AREA SHAPE="rect" COORDS="2,181,112,195" HREF="/avon_user/category.html?category_id=277"> <AREA SHAPE="rect" COORDS="9,203,112,216" HREF="/chathamisland/"> <AREA SHAPE="rect" COORDS="7,223,112,236" HREF="/avon_user/search.html"> </MAP>
<BODY TEXT="#478CFF" LINK="#FFFFFF" VLINK="#000000" ALINK="#478CFF" BGCOLOR="#003399">
<TABLE BORDER="0" WIDTH="600" CELLPADDING="0" CELLSPACING="0">
<TR VALIGN=TOP>
<TD ROWSPAN="3">
<A HREF="/cgi-bin/imagemap/maps/left.gif.map"><IMG SRC="/avon/images/home/nav/left0199.gif" WIDTH="113" HEIGHT="280" BORDER="0" USEMAP="#left0199"></A></TD><TD ROWSPAN="3"><IMG SRC="/avon/images/home/homepagejan98/2ndleft.gif" WIDTH="144" HEIGHT="280" BORDER="0"></TD><TD><A HREF="/avon/about.html"><IMG SRC="/avon/images/home/homepagejan98/aboutavon.gif" ALT="About Avon Books" WIDTH="199" HEIGHT="44" BORDER="0"></A></TD><TD ROWSPAN="3"><A HREF="/avon/fiction/guides.html"><IMG SRC="/avon/images/home/feb98/right1.gif" ALT="Reading Groups" WIDTH="165" HEIGHT="121" BORDER="0"></A><BR><A HREF="/avon/feature/feb99/crook.html"><IMG SRC="/avon/images/home/feb99/crook_text.gif" ALT="The Crook Factory" WIDTH="165" HEIGHT="96" BORDER="0"></A><BR><A HREF="http://apps.hearstnewmedia.com/cgi-bin/gx.cgi/AppLogic+APPSSURVEYS Questionnaire?domain_id=182&survey_id=541"><IMG SRC="/avon/images/home/feb99/env_text.gif" ALT="The Envelope Please" WIDTH="165" HEIGHT="63" BORDER="0"></A></TD> </TR>
<TR VALIGN=TOP><TD><IMG SRC="/avon/images/home/feb98/main.gif" WIDTH="199" HEIGHT="182" BORDER="0"></TD></TR><TR VALIGN=TOP><TD><A HREF="/avon/feature/jan99/sitchin.html"><IMG SRC="/avon/images/home/jan99/sitchin_text.gif" WIDTH="199" HEIGHT="54" BORDER="0"></A></TD></TR><TR VALIGN=TOP><TD COLSPAN="4"><IMG SRC="/avon/images/home/jan99/avon_bottom_beau.gif" WIDTH="622" HEIGHT="179" BORDER="0" USEMAP="#bottom"></TD></TR><TR><TD ALIGN=CENTER VALIGN=TOP COLSPAN="4"><FONT SIZE="2" FACE="ARIAL,COURIER"><PRE>
</PRE><A HREF="/avon/ordering.html">How to order</A> | <A HREF="/avon/faq.html#manu">How to submit a Manuscript</A> | <A HREF="mailto:[email protected]">Contact us</A> | <A HREF="/avon/policy.html">Privacy Policy</A></FONT>
<P>
</FONT></TD>
</TR>
</TABLE>
</BODY>
</HTML>This crud is called HTML (HyperText Markup Language) and it is basically a very simple programming language instructing your web browser how to draw a page on a screen. Anyone can learn HTML and many people do. The important thing is that no matter what splendid multimedia web pages they might represent, HTML files are just telegrams.
When Ronald Reagan was a radio announcer, he used to call baseball games by reading the terse descriptions that trickled in over the telegraph wire and were printed out on a paper tape. He would sit there, all by himself in a padded room with a microphone, and the paper tape would eke out of the machine and crawl over the palm of his hand printed with cryptic abbreviations. If the count went to three and two, Reagan would describe the scene as he saw it in his mind's eye: "The brawny left-hander steps out of the batter's box to wipe the sweat from his brow. The umpire steps forward to sweep the dirt from home plate." and so on. When the cryptogram on the paper tape announced a base hit, he would whack the edge of the table with a pencil, creating a little sound effect, and describe the arc of the ball as if he could actually see it. His listeners, many of whom presumably thought that Reagan was actually at the ballpark watching the game, would reconstruct the scene in their minds according to his descriptions.
This is exactly how the World Wide Web works: the HTML files are the pithy description on the paper tape, and your Web browser is Ronald Reagan. The same is true of Graphical User Interfaces in general.
So an OS is a stack of metaphors and abstractions that stands between you and the telegrams, and embodying various tricks the programmer used to convert the information you're working with — be it images, e-mail messages, movies, or word processing documents — into the necklaces of bytes that are the only things computers know how to work with. When we used actual telegraph equipment (teletypes) or their higher-tech substitutes ("glass teletypes," or the MS-DOS command line) to work with our computers, we were very close to the bottom of that stack. When we use most modern operating systems, though, our interaction with the machine is heavily mediated. Everything we do is interpreted and translated time and again as it works its way down through all of the metaphors and abstractions.
The Macintosh OS was a revolution in both the good and bad senses of that word. Obviously it was true that command line interfaces were not for everyone, and that it would be a good thing to make computers more accessible to a less technical audience — if not for altruistic reasons, then because those sorts of people constituted an incomparably vaster market. It was clear the the Mac's engineers saw a whole new country stretching out before them; you could almost hear them muttering, "Wow! We don't have to be bound by files as linear streams of bytes anymore, vive la revolution, let's see how far we can take this!" No command line interface was available on the Macintosh; you talked to it with the mouse, or not at all. This was a statement of sorts, a credential of revolutionary purity. It seemed that the designers of the Mac intended to sweep Command Line Interfaces into the dustbin of history.
Unix has always lurked provocatively in the background of the operating system wars, like the Russian Army. Most people know it only by reputation, and its reputation, as the Dilbert cartoon suggests, is mixed. But everyone seems to agree that if it could only get its act together and stop surrendering vast tracts of rich agricultural land and hundreds of thousands of prisoners of war to the onrushing invaders, it could stomp them (and all other opposition) flat.
It is difficult to explain how Unix has earned this respect without going into mind-smashing technical detail. Perhaps the gist of it can be explained by telling a story about drills.
The Hole Hawg is a drill made by the Milwaukee Tool Company. If you look in a typical hardware store you may find smaller Milwaukee drills but not the Hole Hawg, which is too powerful and too expensive for homeowners. The Hole Hawg does not have the pistol-like design of a cheap homeowner's drill. It is a cube of solid metal with a handle sticking out of one face and a chuck mounted in another. The cube contains a disconcertingly potent electric motor. You can hold the handle and operate the trigger with your index finger, but unless you are exceptionally strong you cannot control the weight of the Hole Hawg with one hand; it is a two-hander all the way. In order to fight off the counter-torque of the Hole Hawg you use a separate handle (provided), which you screw into one side of the iron cube or the other depending on whether you are using your left or right hand to operate the trigger. This handle is not a sleek, ergonomically designed item as it would be in a homeowner's drill. It is simply a foot-long chunk of regular galvanized pipe, threaded on one end, with a black rubber handle on the other. If you lose it, you just go to the local plumbing supply store and buy another chunk of pipe.
During the Eighties I did some construction work. One day, another worker leaned a ladder against the outside of the building that we were putting up, climbed up to the second-story level, and used the Hole Hawg to drill a hole through the exterior wall. At some point, the drill bit caught in the wall. The Hole Hawg, following its one and only imperative, kept going. It spun the worker's body around like a rag doll, causing him to knock his own ladder down. Fortunately he kept his grip on the Hole Hawg, which remained lodged in the wall, and he simply dangled from it and shouted for help until someone came along and reinstated the ladder.
I myself used a Hole Hawg to drill many holes through studs, which it did as a blender chops cabbage. I also used it to cut a few six-inch-diameter holes through an old lath-and-plaster ceiling. I chucked in a new hole saw, went up to the second story, reached down between the newly installed floor joists, and began to cut through the first-floor ceiling below. Where my homeowner's drill had labored and whined to spin the huge bit around, and had stalled at the slightest obstruction, the Hole Hawg rotated with the stupid consistency of a spinning planet. When the hole saw seized up, the Hole Hawg spun itself and me around, and crushed one of my hands between the steel pipe handle and a joist, producing a few lacerations, each surrounded by a wide corona of deeply bruised flesh. It also bent the hole saw itself, though not so badly that I couldn't use it. After a few such run-ins, when I got ready to use the Hole Hawg my heart actually began to pound with atavistic terror.
But I never blamed the Hole Hawg; I blamed myself. The Hole Hawg is dangerous because it does exactly what you tell it to. It is not bound by the physical limitations that are inherent in a cheap drill, and neither is it limited by safety interlocks that might be built into a homeowner's product by a liability-conscious manufacturer. The danger lies not in the machine itself but in the user's failure to envision the full consequences of the instructions he gives to it.
A smaller tool is dangerous too, but for a completely different reason: it tries to do what you tell it to, and fails in some way that is unpredictable and almost always undesirable. But the Hole Hawg is like the genie of the ancient fairy tales, who carries out his master's instructions literally and precisely and with unlimited power, often with disastrous, unforeseen consequences.
Pre-Hole Hawg, I used to examine the drill selection in hardware stores with what I thought was a judicious eye, scorning the smaller low-end models and hefting the big expensive ones appreciatively, wishing I could afford one of them babies. Now I view them all with such contempt that I do not even consider them to be real drills — merely scaled-up toys designed to exploit the self-delusional tendencies of soft-handed homeowners who want to believe that they have purchased an actual tool. Their plastic casings, carefully designed and focus-group-tested to convey a feeling of solidity and power, seem disgustingly flimsy and cheap to me, and I am ashamed that I was ever bamboozled into buying such knicknacks.
It is not hard to imagine what the world would look like to someone who had been raised by contractors and who had never used any drill other than a Hole Hawg. Such a person, presented with the best and most expensive hardware-store drill, would not even recognize it as such. He might instead misidentify it as a child's toy, or some kind of motorized screwdriver. If a salesperson or a deluded homeowner referred to it as a drill, he would laugh and tell them that they were mistaken — they simply had their terminology wrong. His interlocutor would go away irritated, and probably feeling rather defensive about his basement full of cheap, dangerous, flashy, colorful tools.
Unix is the Hole Hawg of operating systems, and Unix hackers, like Doug Barnes and the guy in the Dilbert cartoon and many of the other people who populate Silicon Valley, are like contractor's sons who grew up using only Hole Hawgs. They might use Apple/Microsoft OSes to write letters, play video games, or balance their checkbooks, but they cannot really bring themselves to take these operating systems seriously.
Unix is hard to learn. The process of learning it is one of multiple small epiphanies. Typically you are just on the verge of inventing some necessary tool or utility when you realize that someone else has already invented it, and built it in, and this explains some odd file or directory or command that you have noticed but never really understood before.
For example there is a command (a small program, part of the OS) called whoami, which enables you to ask the computer who it thinks you are. On a Unix machine, you are always logged in under some name — possibly even your own! What files you may work with, and what software you may use, depends on your identity. When I started out using Linux, I was on a non-networked machine in my basement, with only one user account, and so when I became aware of the whoami command it struck me as ludicrous. But once you are logged in as one person, you can temporarily switch over to a pseudonym in order to access different files. If your machine is on the Internet, you can log onto other computers, provided you have a user name and a password. At that point the distant machine becomes no different in practice from the one right in front of you. These changes in identity and location can easily become nested inside each other, many layers deep, even if you aren't doing anything nefarious. Once you have forgotten who and where you are, the whoami command is indispensible. I use it all the time.
The file systems of Unix machines all have the same general structure. On your flimsy operating systems, you can create directories (folders) and give them names like Frodo or My Stuff and put them pretty much anywhere you like. But under Unix the highest level — the root — of the filesystem is always designated with the single character "/" and it always contains the same set of top-level directories:
/usr
/etc
/var
/bin
/proc
/boot
/home
/root
/sbin
/dev
/lib
/tmp
and each of these directories typically has its own distinct structure of subdirectories. Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river.
This is not the place to try to explain why each of the above directories exists, and what is contained in it. At first it all seems obscure; worse, it seems deliberately obscure. When I started using Linux I was accustomed to being able to create directories wherever I wanted and to give them whatever names struck my fancy. Under Unix you are free to do that, of course (you are free to do anything ) but as you gain experience with the system you come to understand that the directories listed above were created for the best of reasons and that your life will be much easier if you follow along (within /home, by the way, you have pretty much unlimited freedom).
After this kind of thing has happened several hundred or thousand times, the hacker understands why Unix is the way it is, and agrees that it wouldn't be the same any other way. It is this sort of acculturation that gives Unix hackers their confidence in the system, and the attitude of calm, unshakable, annoying superiority captured in the Dilbert cartoon. Windows 95 and MacOS are products, contrived by engineers in the service of specific companies. Unix, by contrast, is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. It is our Gilgamesh epic.
What made old epics like Gilgamesh so powerful and so long-lived was that they were living bodies of narrative that many people knew by heart, and told over and over again — making their own personal embellishments whenever it struck their fancy. The bad embellishments were shouted down, the good ones picked up by others, polished, improved, and, over time, incorporated into the story. Likewise, Unix is known, loved, and understood by so many hackers that it can be re-created from scratch whenever someone needs it. This is very difficult to understand for people who are accustomed to thinking of OSes as things that absolutely have to be bought.
Many hackers have launched more or less successful re-implementations of the Unix ideal. Each one brings in new embellishments. Some of them die out quickly, some are merged with similar, parallel innovations created by different hackers attacking the same problem, others still are embraced, and adopted into the epic. Thus Unix has slowly accreted around a simple kernel and acquired a kind of complexity and asymmetry about it that is organic, like the roots of a tree, or the branchings of a coronary artery. Understanding it is more like anatomy than physics.
...
We like plain dealings and straightforward transactions in America. If you go to Egypt and, say, take a taxi somewhere, you become a part of the taxi driver's life; he refuses to take your money because it would demean your friendship, he follows you around town, and weeps hot tears when you get in some other guy's taxi. You end up meeting his kids at some point, and have to devote all sort of ingenuity to finding some way to compensate him without insulting his honor. It is exhausting. Sometimes you just want a simple Manhattan-style taxi ride.
But in order to have an American-style setup, where you can just go out and hail a taxi and be on your way, there must exist a whole hidden apparatus of medallions, inspectors, commissions, and so forth — which is fine as long as taxis are cheap and you can always get one. When the system fails to work in some way, it is mysterious and infuriating and turns otherwise reasonable people into conspiracy theorists. But when the Egyptian system breaks down, it breaks down transparently. You can't get a taxi, but your driver's nephew will show up, on foot, to explain the problem and apologize.
Microsoft and Apple do things the Manhattan way, with vast complexity hidden behind a wall of interface. Linux does things the Egypt way, with vast complexity strewn about all over the landscape. If you've just flown in from Manhattan, your first impulse will be to throw up your hands and say "For crying out loud! Will you people get a grip on yourselves!?" But this does not make friends in Linux-land any better than it would in Egypt.
You can suck Linux right out of the air, as it were, by downloading the right files and putting them in the right places, but there probably are not more than a few hundred people in the world who could create a functioning Linux system in that way. What you really need is a distribution of Linux, which means a prepackaged set of files. But distributions are a separate thing from Linux per se.
Linux per se is not a specific set of ones and zeroes, but a self-organizing Net subculture. The end result of its collective lucubrations is a vast body of source code, almost all written in C (the dominant computer programming language). "Source code" just means a computer program as typed in and edited by some hacker. If it's in C, the file name will probably have .c or .cpp on the end of it, depending on which dialect was used; if it's in some other language it will have some other suffix. Frequently these sorts of files can be found in a directory with the name /src which is the hacker's Hebraic abbreviation of "source."
Source files are useless to your computer, and of little interest to most users, but they are of gigantic cultural and political significance, because Microsoft and Apple keep them secret while Linux makes them public. They are the family jewels. They are the sort of thing that in Hollywood thrillers is used as a McGuffin: the plutonium bomb core, the top-secret blueprints, the suitcase of bearer bonds, the reel of microfilm. If the source files for Windows or MacOS were made public on the Net, then those OSes would become free, like Linux — only not as good, because no one would be around to fix bugs and answer questions. Linux is "open source" software meaning, simply, that anyone can get copies of its source code files.
Your computer doesn't want source code any more than you do; it wants object code. Object code files typically have the suffix .o and are unreadable all but a few, highly strange humans, because they consist of ones and zeroes. Accordingly, this sort of file commonly shows up in a directory with the name /bin, for "binary."
Source files are simply ASCII text files. ASCII denotes a particular way of encoding letters into bit patterns. In an ASCII file, each character has eight bits all to itself. This creates a potential "alphabet" of 256 distinct characters, in that eight binary digits can form that many unique patterns. In practice, of course, we tend to limit ourselves to the familiar letters and digits. The bit-patterns used to represent those letters and digits are the same ones that were physically punched into the paper tape by my high school teletype, which in turn were the same one used by the telegraph industry for decades previously. ASCII text files, in other words, are telegrams, and as such they have no typographical frills. But for the same reason they are eternal, because the code never changes, and universal, because every text editing and word processing software ever written knows about this code.
Therefore just about any software can be used to create, edit, and read source code files. Object code files, then, are created from these source files by a piece of software called a compiler, and forged into a working application by another piece of software called a linker.
The triad of editor, compiler, and linker, taken together, form the core of a software development system. Now, it is possible to spend a lot of money on shrink-wrapped development systems with lovely graphical user interfaces and various ergonomic enhancements. In some cases it might even be a good and reasonable way to spend money. But on this side of the road, as it were, the very best software is usually the free stuff. Editor, compiler and linker are to hackers what ponies, stirrups, and archery sets were to the Mongols. Hackers live in the saddle, and hack on their own tools even while they are using them to create new applications. It is quite inconceivable that superior hacking tools could have been created from a blank sheet of paper by product engineers. Even if they are the brightest engineers in the world they are simply outnumbered.
In the GNU/Linux world there are two major text editing programs: the minimalist vi (known in some implementations as elvis) and the maximalist emacs. I use emacs, which might be thought of as a thermonuclear word processor. It was created by Richard Stallman; enough said. It is written in Lisp, which is the only computer language that is beautiful. It is colossal, and yet it only edits straight ASCII text files, which is to say, no fonts, no boldface, no underlining. In other words, the engineer-hours that, in the case of Microsoft Word, were devoted to features like mail merge, and the ability to embed feature-length motion pictures in corporate memoranda, were, in the case of emacs, focused with maniacal intensity on the deceptively simple-seeming problem of editing text. If you are a professional writer — i.e., if someone else is getting paid to worry about how your words are formatted and printed — emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish. For page layout and printing you can use TeX: a vast corpus of typesetting lore written in C and also available on the Net for free.
I could say a lot about emacs and TeX, but right now I am trying to tell a story about how to actually install Linux on your machine. The hard-core survivalist approach would be to download an editor like emacs, and the GNU Tools — the compiler and linker — which are polished and excellent to the same degree as emacs. Equipped with these, one would be able to start downloading ASCII source code files (/src) and compiling them into binary object code files (/bin) that would run on the machine. But in order to even arrive at this point — to get emacs running, for example — you have to have Linux actually up and running on your machine. And even a minimal Linux operating system requires thousands of binary files all acting in concert, and arranged and linked together just so.
Several entities have therefore taken it upon themselves to create "distributions" of Linux. If I may extend the Egypt analogy slightly, these entities are a bit like tour guides who meet you at the airport, who speak your language, and who help guide you through the initial culture shock. If you are an Egyptian, of course, you see it the other way; tour guides exist to keep brutish outlanders from traipsing through your mosques and asking you the same questions over and over and over again.
Some of these tour guides are commercial organizations, such as Red Hat Software, which makes a Linux distribution called Red Hat that has a relatively commercial sheen to it. In most cases you put a Red Hat CD-ROM into your PC and reboot and it handles the rest. Just as a tour guide in Egypt will expect some sort of compensation for his services, commercial distributions need to be paid for. In most cases they cost almost nothing and are well worth it.
I use a distribution called Debian (the word is a contraction of "Deborah" and "Ian") which is non-commercial. It is organized (or perhaps I should say "it has organized itself") along the same lines as Linux in general, which is to say that it consists of volunteers who collaborate over the Net, each responsible for looking after a different chunk of the system. These people have broken Linux down into a number of packages, which are compressed files that can be downloaded to an already functioning Debian Linux system, then opened up and unpacked using a free installer application. Of course, as such, Debian has no commercial arm — no distribution mechanism. You can download all Debian packages over the Net, but most people will want to have them on a CD-ROM. Several different companies have taken it upon themselves to decoct all of the current Debian packages onto CD-ROMs and then sell them. I buy mine from Linux Systems Labs. The cost for a three-disc set, containing Debian in its entirety, is less than three dollars. But (and this is an important distinction) not a single penny of that three dollars is going to any of the coders who created Linux, nor to the Debian packagers. It goes to Linux Systems Labs and it pays, not for the software, or the packages, but for the cost of stamping out the CD-ROMs.
Every Linux distribution embodies some more or less clever hack for circumventing the normal boot process and causing your computer, when it is turned on, to organize itself, not as a PC running Windows, but as a "host" running Unix. This is slightly alarming the first time you see it, but completely harmless. When a PC boots up, it goes through a little self-test routine, taking an inventory of available disks and memory, and then begins looking around for a disk to boot up from. In any normal Windows computer that disk will be a hard drive. But if you have your system configured right, it will look first for a floppy or CD-ROM disk, and boot from that if one is available.
Linux exploits this chink in the defenses. Your computer notices a bootable disk in the floppy or CD-ROM drive, loads in some object code from that disk, and blindly begins to execute it. But this is not Microsoft or Apple code, this is Linux code, and so at this point your computer begins to behave very differently from what you are accustomed to. Cryptic messages began to scroll up the screen. If you had booted a commercial OS, you would, at this point, be seeing a "Welcome to MacOS" cartoon, or a screen filled with clouds in a blue sky, and a Windows logo. But under Linux you get a long telegram printed in stark white letters on a black screen. There is no "welcome!" message. Most of the telegram has the semi-inscrutable menace of graffiti tags.
Dec 14 15:04:15 theRev syslogd 1.3-3#17: restart.
Dec 14 15:04:15 theRev kernel: klogd 1.3-3, log source = /proc/kmsg started.
Dec 14 15:04:15 theRev kernel: Loaded 3535 symbols from /System.map.
Dec 14 15:04:15 theRev kernel: Symbols match kernel version 2.0.30.
Dec 14 15:04:15 theRev kernel: No module symbols loaded.
Dec 14 15:04:15 theRev kernel: Intel MultiProcessor Specification v1.4
Dec 14 15:04:15 theRev kernel: Virtual Wire compatibility mode.
Dec 14 15:04:15 theRev kernel: OEM ID: INTEL Product ID: 440FX APIC at: 0xFEE00000
Dec 14 15:04:15 theRev kernel: Processor #0 Pentium(tm) Pro APIC version 17
Dec 14 15:04:15 theRev kernel: Processor #1 Pentium(tm) Pro APIC version 17
Dec 14 15:04:15 theRev kernel: I/O APIC #2 Version 17 at 0xFEC00000.
Dec 14 15:04:15 theRev kernel: Processors: 2
Dec 14 15:04:15 theRev kernel: Console: 16 point font, 400 scans
Dec 14 15:04:15 theRev kernel: Console: colour VGA+ 80x25, 1 virtual console (max 63)
Dec 14 15:04:15 theRev kernel: pcibios_init : BIOS32 Service Directory structure at 0x000fdb70
Dec 14 15:04:15 theRev kernel: pcibios_init : BIOS32 Service Directory entry at 0xfdb80
Dec 14 15:04:15 theRev kernel: pcibios_init : PCI BIOS revision 2.10 entry at 0xfdba1
Dec 14 15:04:15 theRev kernel: Probing PCI hardware. Dec 14 15:04:15 theRev kernel: Warning : Unknown PCI device (10b7:9001). Please read include/linux/pci.h
Dec 14 15:04:15 theRev kernel: Calibrating delay loop.. ok - 179.40 BogoMIPS
Dec 14 15:04:15 theRev kernel: Memory: 64268k/66556k available (700k kernel code, 384k reserved, 1204k data)
Dec 14 15:04:15 theRev kernel: Swansea University Computer Society NET3.035 for Linux 2.0
Dec 14 15:04:15 theRev kernel: NET3: Unix domain sockets 0.13 for Linux NET3.035.
Dec 14 15:04:15 theRev kernel: Swansea University Computer Society TCP/IP for NET3.034
Dec 14 15:04:15 theRev kernel: IP Protocols: ICMP, UDP, TCP
Dec 14 15:04:15 theRev kernel: Checking 386/387 coupling... Ok, fpu using exception 16 error reporting.
Dec 14 15:04:15 theRev kernel: Checking 'hlt' instruction... Ok.
Dec 14 15:04:15 theRev kernel: Linux version 2.0.30 (root@theRev) (gcc version 2.7.2.1) #15 Fri Mar 27 16:37:24 PST 1998
Dec 14 15:04:15 theRev kernel: Booting processor 1 stack 00002000: Calibrating delay loop.. ok - 179.40 BogoMIPS
Dec 14 15:04:15 theRev kernel: Total of 2 processors activated (358.81 BogoMIPS).
Dec 14 15:04:15 theRev kernel: Serial driver version 4.13 with no serial options enabled
Dec 14 15:04:15 theRev kernel: tty00 at 0x03f8 (irq = 4) is a 16550A
Dec 14 15:04:15 theRev kernel: tty01 at 0x02f8 (irq = 3) is a 16550A
Dec 14 15:04:15 theRev kernel: lp1 at 0x0378, (polling)
Dec 14 15:04:15 theRev kernel: PS/2 auxiliary pointing device detected — driver installed.
Dec 14 15:04:15 theRev kernel: Real Time Clock Driver v1.07
Dec 14 15:04:15 theRev kernel: loop: registered device at major 7
Dec 14 15:04:15 theRev kernel: ide: i82371 PIIX (Triton) on PCI bus 0 function 57
Dec 14 15:04:15 theRev kernel: ide0: BM-DMA at 0xffa0-0xffa7
Dec 14 15:04:15 theRev kernel: ide1: BM-DMA at 0xffa8-0xffaf
Dec 14 15:04:15 theRev kernel: hda: Conner Peripherals 1275MB - CFS1275A, 1219MB w/64kB Cache, LBA, CHS=619/64/63
Dec 14 15:04:15 theRev kernel: hdb: Maxtor 84320A5, 4119MB w/256kB Cache, LBA, CHS=8928/15/63, DMA
Dec 14 15:04:15 theRev kernel: hdc: , ATAPI CDROM drive
Dec 15 11:58:06 theRev kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Dec 15 11:58:06 theRev kernel: ide1 at 0x170-0x177,0x376 on irq 15
Dec 15 11:58:06 theRev kernel: Floppy drive(s): fd0 is 1.44M
Dec 15 11:58:06 theRev kernel: Started kswapd v 1.4.2.2 Dec 15 11:58:06 theRev kernel: FDC 0 is a National Semiconductor PC87306
Dec 15 11:58:06 theRev kernel: md driver 0.35 MAX_MD_DEV=4, MAX_REAL=8
Dec 15 11:58:06 theRev kernel: PPP: version 2.2.0 (dynamic channel allocation)
Dec 15 11:58:06 theRev kernel: TCP compression code copyright 1989 Regents of the University of California
Dec 15 11:58:06 theRev kernel: PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
Dec 15 11:58:06 theRev kernel: PPP line discipline registered.
Dec 15 11:58:06 theRev kernel: SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256).
Dec 15 11:58:06 theRev kernel: eth0: 3Com 3c900 Boomerang 10Mbps/Combo at 0xef00, 00:60:08:a4:3c:db, IRQ 10 Dec 15 11:58:06 theRev kernel: 8K word-wide RAM 3:5 Rx:Tx split, 10base2 interface.
Dec 15 11:58:06 theRev kernel: Enabling bus-master transmits and whole-frame receives.
Dec 15 11:58:06 theRev kernel: 3c59x.c:v0.49 1/2/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
Dec 15 11:58:06 theRev kernel: Partition check:
Dec 15 11:58:06 theRev kernel: hda: hda1 hda2 hda3
Dec 15 11:58:06 theRev kernel: hdb: hdb1 hdb2
Dec 15 11:58:06 theRev kernel: VFS: Mounted root (ext2 filesystem) readonly.
Dec 15 11:58:06 theRev kernel: Adding Swap: 16124k swap-space (priority -1)
Dec 15 11:58:06 theRev kernel: EXT2-fs warning: maximal mount count reached, running e2fsck is recommended Dec 15 11:58:06 theRev kernel: hdc: media changed
Dec 15 11:58:06 theRev kernel: ISO9660 Extensions: RRIP_1991A
Dec 15 11:58:07 theRev syslogd 1.3-3#17: restart.
Dec 15 11:58:09 theRev diald[87]: Unable to open options file /etc/diald/diald.options: No such file or directory
Dec 15 11:58:09 theRev diald[87]: No device specified. You must have at least one device!
Dec 15 11:58:09 theRev diald[87]: You must define a connector script (option 'connect').
Dec 15 11:58:09 theRev diald[87]: You must define the remote ip address.
Dec 15 11:58:09 theRev diald[87]: You must define the local ip address.
Dec 15 11:58:09 theRev diald[87]: Terminating due to damaged reconfigure.
The only parts of this that are readable, for normal people, are the error messages and warnings. And yet it's noteworthy that Linux doesn't stop, or crash, when it encounters an error; it spits out a pithy complaint, gives up on whatever processes were damaged, and keeps on rolling. This was decidedly not true of the early versions of Apple and Microsoft OSes, for the simple reason that an OS that is not capable of walking and chewing gum at the same time cannot possibly recover from errors. Looking for, and dealing with, errors requires a separate process running in parallel with the one that has erred. A kind of superego, if you will, that keeps an eye on all of the others, and jumps in when one goes astray. Now that MacOS and Windows can do more than one thing at a time they are much better at dealing with errors than they used to be, but they are not even close to Linux or other Unices in this respect; and their greater complexity has made them vulnerable to new types of errors.
Linux is not capable of having any centrally organized policies dictating how to write error messages and documentation, and so each programmer writes his own. Usually they are in English even though tons of Linux programmers are Europeans. Frequently they are funny. Always they are honest. If something bad has happened because the software simply isn't finished yet, or because the user screwed something up, this will be stated forthrightly. The command line interface makes it easy for programs to dribble out little comments, warnings, and messages here and there. Even if the application is imploding like a damaged submarine, it can still usually eke out a little S.O.S. message. Sometimes when you finish working with a program and shut it down, you find that it has left behind a series of mild warnings and low-grade error messages in the command-line interface window from which you launched it. As if the software were chatting to you about how it was doing the whole time you were working with it.
Documentation, under Linux, comes in the form of man (short for manual) pages. You can access these either through a GUI (xman) or from the command line (man). Here is a sample from the man page for a program called rsh:
Stop signals stop the local rsh process only;
this is arguably wrong, but currently hard to
fix for reasons too complicated to explain here.
The man pages contain a lot of such material, which reads like the terse mutterings of pilots wrestling with the controls of damaged airplanes. The general feel is of a thousand monumental but obscure struggles seen in the stop-action light of a strobe. Each programmer is dealing with his own obstacles and bugs; he is too busy fixing them, and improving the software, to explain things at great length or to maintain elaborate pretensions.
In practice you hardly ever encounter a serious bug while running Linux. When you do, it is almost always with commercial software (several vendors sell software that runs under Linux). The operating system and its fundamental utility programs are too important to contain serious bugs. I have been running Linux every day since late 1995 and have seen many application programs go down in flames, but I have never seen the operating system crash. Never. Not once. There are quite a few Linux systems that have been running continuously and working hard for months or years without needing to be rebooted.
In his book The Life of the Cosmos, which everyone should read, Lee Smolin gives the best description I've ever read of how our universe emerged from an uncannily precise balancing of different fundamental constants. The mass of the proton, the strength of gravity, the range of the weak nuclear force, and a few dozen other fundamental constants completely determine what sort of universe will emerge from a Big Bang. If these values had been even slightly different, the universe would have been a vast ocean of tepid gas or a hot knot of plasma or some other basically uninteresting thing — a dud, in other words. The only way to get a universe that's not a dud — that has stars, heavy elements, planets, and life — is to get the basic numbers just right. If there were some machine, somewhere, that could spit out universes with randomly chosen values for their fundamental constants, then for every universe like ours it would produce 10^229 duds.
Though I haven't sat down and run the numbers on it, to me this seems comparable to the probability of making a Unix computer do something useful by logging into a tty and typing in command lines when you have forgotten all of the little options and keywords. Every time your right pinky slams that ENTER key, you are making another try. In some cases the operating system does nothing. In other cases it wipes out all of your files. In most cases it just gives you an error message. In other words, you get many duds. But sometimes, if you have it all just right, the computer grinds away for a while and then produces something like emacs. It actually generates complexity, which is Smolin's criterion for interestingness.
Not only that, but it's beginning to look as if, once you get below a certain size — way below the level of quarks, down into the realm of string theory — the universe can't be described very well by physics as it has been practiced since the days of Newton. If you look at a small enough scale, you see processes that look almost computational in nature.
I think that the message is very clear here: somewhere outside of and beyond our universe is an operating system, coded up over incalculable spans of time by some kind of hacker-demiurge. The cosmic operating system uses a command-line interface. It runs on something like a teletype, with lots of noise and heat; punched-out bits flutter down into its hopper like drifting stars. The demiurge sits at his teletype, pounding out one command line after another, specifying the values of fundamental constants of physics:
universe -G 6.672e-11 -e 1.602e-19 -h 6.626e-34 -protonmass 1.673e-27....
and when he's finished typing out the command line, his right pinky hesitates above the ENTER key for an aeon or two, wondering what's going to happen; then down it comes — and the WHACK you hear is another Big Bang.
Now THAT is a cool operating system, and if such a thing were actually made available on the Internet (for free, of course) every hacker in the world would download it right away and then stay up all night long messing with it, spitting out universes right and left. Most of them would be pretty dull universes but some of them would be simply amazing. Because what those hackers would be aiming for would be much more ambitious than a universe that had a few stars and galaxies in it. Any run-of-the-mill hacker would be able to do that. No, the way to gain a towering reputation on the Internet would be to get so good at tweaking your command line that your universes would spontaneously develop life. And once the way to do that became common knowledge, those hackers would move on, trying to make their universes develop the right kind of life, trying to find the one change in the Nth decimal place of some physical constant that would give us an Earth in which, say, Hitler had been accepted into art school after all, and had ended up his days as a street artist with cranky political opinions.
Even if that fantasy came true, though, most users (including myself, on certain days) wouldn't want to bother learning to use all of those arcane commands, and struggling with all of the failures; a few dud universes can really clutter up your basement. After we'd spent a while pounding out command lines and hitting that ENTER key and spawning dull, failed universes, we would start to long for an OS that would go all the way to the opposite extreme: an OS that had the power to do everything — to live our life for us. In this OS, all of the possible decisions we could ever want to make would have been anticipated by clever programmers, and condensed into a series of dialog boxes. By clicking on radio buttons we could choose from among mutually exclusive choices (HETEROSEXUAL/HOMOSEXUAL). Columns of check boxes would enable us to select the things that we wanted in our life (GET MARRIED/WRITE GREAT AMERICAN NOVEL) and for more complicated options we could fill in little text boxes (NUMBER OF DAUGHTERS: NUMBER OF SONS:).
Even this user interface would begin to look awfully complicated after a while, with so many choices, and so many hidden interactions between choices. It could become damn near unmanageable — the blinking twelve problem all over again. The people who brought us this operating system would have to provide templates and wizards, giving us a few default lives that we could use as starting places for designing our own. Chances are that these default lives would actually look pretty damn good to most people, good enough, anyway, that they'd be reluctant to tear them open and mess around with them for fear of making them worse. So after a few releases the software would begin to look even simpler: you would boot it up and it would present you with a dialog box with a single large button in the middle labeled: LIVE. Once you had clicked that button, your life would begin. If anything got out of whack, or failed to meet your expectations, you could complain about it to Microsoft's Customer Support Department. If you got a flack on the line, he or she would tell you that your life was actually fine, that there was not a thing wrong with it, and in any event it would be a lot better after the next upgrade was rolled out. But if you persisted, and identified yourself as Advanced, you might get through to an actual engineer.
What would the engineer say, after you had explained your problem, and enumerated all of the dissatisfactions in your life? He would probably tell you that life is a very hard and complicated thing; that no interface can change that; that anyone who believes otherwise is a sucker; and that if you don't like having choices made for you, you should start making your own.
Copyright 1999 by Neal Stephenson
© 1999 The Hearst Corporation