Times have changed every character but one in Neal Stephenson's classic. That one is Linux.

I was wandering through Kepler's, the legendary bookstore, sometime late in 1999, when I spotted a thin volume with a hard-to-read title on the new book table. In the Beginning...Was the Command Line, the cover said.

The command line was new to me when I started writing for Linux Journal in 1996. I hadn't come from UNIX or from programming. My tech background was in ham radio and broadcast engineering, and nearly all my hacking was on RF hardware. It wasn't a joke when I said the only code I knew was Morse. But I was amazed at how useful and necessary the command line was, and I was thrilled to see Neal Stephenson was the author of that book. (Pro tip: you can tell the commercial worth of an author by the size of his or her name on the cover. If it's bigger than the title of the book, the writer's a big deal. Literally.)

So I bought it, and then I read it in one sitting. You can do the same. In fact, I command that you do, if you haven't already, because (IMHO) it's the most classic book ever written about both the command line and Linux itself—a two-fer of the first order.

And I say this in full knowledge (having re-read the whole thing many times, which is easy, because it's short) that much of what it brings up and dwells on is stale in the extreme. The MacOS and the Be operating systems are long gone (and the Be computer was kind of dead on arrival), along with the Windows of that time. Today Apple's OS X is BSD at its core, while Microsoft produces lots of open-source code and contributes mightily to The Linux Foundation. Some of Neal's observations and complaints about computing and the culture of the time also have faded in relevance, although some remain enduringly right-on. (If you want to read a section-by-section critique of the thing, Garrett Birkel produced one in the mid-2000s with Neal's permission. But do read the book first.)

What's great about Command Line is how well it explains the original virtues of UNIX, and of Linux as the operating system making the most of it:

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.

There are many other yummy passages. Here's one example:

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.

Commercial OSes have to adopt the same official stance towards errors as Communist countries had towards poverty. For doctrinal reasons it was not possible to admit that poverty was a serious problem in Communist countries, because the whole point of Communism was to eradicate poverty. Likewise, commercial OS companies like Apple and Microsoft can't go around admitting that their software has bugs and that it crashes all the time, any more than Disney can issue press releases stating that Mickey Mouse is an actor in a suit.

This is a problem, because errors do exist and bugs do happen. Every few months Bill Gates tries to demo a new Microsoft product in front of a large audience only to have it blow up in his face. Commercial OS vendors, as a direct consequence of being commercial, are forced to adopt the grossly disingenuous position that bugs are rare aberrations, usually someone else's fault, and therefore not really worth talking about in any detail. This posture, which everyone knows to be absurd, is not limited to press releases and ad campaigns. It informs the whole way these companies do business and relate to their customers. If the documentation were properly written, it would mention bugs, errors, and crashes on every single page. If the on-line help systems that come with these OSes reflected the experiences and concerns of their users, they would largely be devoted to instructions on how to cope with crashes and errors.

But this does not happen. Joint stock corporations are wonderful inventions that have given us many excellent goods and services. They are good at many things. Admitting failure is not one of them. Hell, they can't even admit minor shortcomings.

I could go on, but I'd rather have you read the book than give more away.

While various sources online (Wikipedia included) say Neal probably won't update the book, his own page on the book says:

This was originally just a set of musings about Graphical User Interfaces (GUIs) that gradually took on the shape of an essay. On the spur of the moment, the decision was made to post it on my publisher's website. Today we would say that it went viral, but back then we said that it had been Slashdotted. Anyway, the resulting traffic broke the publisher's servers until various readers set up mirror sites to handle the load. This essay is in need of an update, which I'm slowly working on, but there is still some material in here that many readers might find interesting.

I believe at least some of those many are Linux Journal readers.

If you want to buy the book, here's the Amazon link. If you want to read the whole thing online, look it up. (I count four complete copies in the first page of search results.)

And Neal, let us know when that update is ready. It'll be news, and we want the scoop.