xxvi Preface Eventually my Emacs window decides it’s time to close up for the day. What has happened? Two things, apparently. One is that when I cre- ated my custom patch to the window system, to send mouse clicks to Emacs, I created another massive 3/4 megabyte binary, which doesn’t share space with the standard Sun window applications (“tools”). This means that instead of one huge mass of shared object code run- ning the window system, and taking up space on my paging disk, I had two such huge masses, identical except for a few pages of code. So I paid a megabyte of swap space for the privilege of using a mouse with my editor. (Emacs itself is a third large mass.) The Sun kernel was just plain running out of room. Every trivial hack you make to the window system replicates the entire window system. But that’s not all: Apparently there are other behemoths of the swap volume. There are some network things with truly stupendous-sized data segments. Moreover, they grow over time, eventually taking over the entire swap volume, I suppose. So you can’t leave a Sun up for very long. That’s why I’m glad Suns are easy to boot! But why should a network server grow over time? You’ve got to realize that the Sun software dynamically allocates very complex data structures. You are supposed to call “free” on every structure you have allocated, but it’s understandable that a little garbage escapes now and then because of programmer oversight. Or pro- grammer apathy. So eventually the swap volume fills up! This leads me to daydream about a workstation architecture optimized for the creation and manipulation of large, complex, interconnected data structures, and some magic means of freeing storage without pro- grammer intervention. Such a workstation could stay up for days, reclaiming its own garbage, without need for costly booting opera- tions. But, of course, Suns are very good at booting! So good, they some- times spontaneously boot, just to let you know they’re in peak form! Well, the console just complained about the lack of memory again. Gosh, there isn’t time to talk about the other LispM features I’ve been free of for the last week. Such as incremental recompilation and loading. Or incremental testing of programs, from a Lisp Listener. Or a window system you can actually teach new things (I miss my

The UNIX-HATERS History xxvii mouse-sensitive Lisp forms). Or safe tagged architecture that rigidly distinguishes between pointers and integers. Or the Control-Meta- Suspend key. Or manuals. Time to boot! John Rose sent his email message to an internal company mailing list. Somehow it was forwarded to Michael Travers at the Media Lab. John didn’t know that Michael was going to create a mailing list for himself and his fellow Unix-hating friends and e-mail it out. But Michael did and, seven years later, John is still on UNIX-HATERS, along with hundreds of other people. At the end of flame, John Rose included this disclaimer: [Seriously folks: I’m doing my best to get our money’s worth out of this box, and there are solutions to some of the above problems. In particular, thanks to Bill for increasing my swap space. In terms of raw CPU power, a Sun can really get jobs done fast. But I needed to let off some steam, because this disappearing editor act is really get- ting my dander up.] Some disclaimer. The company in question had bought its Unix worksta- tions to save money. But what they saved in hardware costs they soon spent (and continue to spend) many times over in terms of higher costs for sup- port and lost programmer productivity. Unfortunately, now that we know better, it is too late. Lisp Machines are a fading memory at the company: everybody uses Unix. Most think of Unix as a pretty good operating sys- tem. After all, it’s better than DOS. Or is it? You are not alone If you have ever used a Unix system, you have probably had the same nightmarish experiences that we have had and heard. You may have deleted important files and gone for help, only to be told that it was your own fault, or, worse, a “rite of passage.” You may have spent hours writing a heart-wrenching letter to a friend, only to have it lost in a mailer burp, or, worse, have it sent to somebody else. We aim to show that you are not alone and that your problems with Unix are not your fault. Our grievance is not just against Unix itself, but against the cult of Unix zealots who defend and nurture it. They take the heat, disease, and pesti-