Anyway, the window manager acts as an intermediary between X Windows 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 X Windows 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 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 the version of Basic 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.

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 X Windows 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 filesystem. When I want to change something about the way my system works, I edit those files. I know that if I don't keep track of every little change I've made, I won't be able to get your system back in working order after I've gotten it all messed up. Keeping hand-written logs is tedious, not to mention kind of anachronistic. But it's necessary.