The UNIX-HATERS History xxv Logged into a Sun for the last few days, my Meta-Point reflex has continued unabated, but it is completely frustrated. The program that I am working on has about 80 files. If I want to edit the code of a function Foo, I have to switch to a shell window and grep for named Foo in various files. Then I have to type in the name of the appropri- ate file. Then I have to correct my spelling error. Finally I have to search inside the file. What used to take five seconds now takes a minute or two. (But what’s an order of magnitude between friends?) By this time, I really want to see the Sun at its best, so I’m tempted to boot it a couple of times. There’s a wonderful Unix command called “strip,” with which you force programs to remove all their debugging information. Unix pro- grams (such as the Sun window system) are stripped as a matter of course, because all the debugging information takes up disk space and slows down the booting process. This means you can’t use the debugger on them. But that’s no loss have you seen the Unix debug- ger? Really. Did you know that all the standard Sun window applications (“tools”) are really one massive 3/4 megabyte binary? This allows the tools to share code (there’s a lot of code in there). Lisp Machines share code this way, too. Isn’t it nice that our workstations protect our memory investments by sharing code. None of the standard Sun window applications (“tools”) support Emacs. Unix applications cannot be patched either you must have the source so you can patch THAT, and then regenerate the applica- tion from the source. But I sure wanted my Sun’s mouse to talk to Emacs. So I got a cou- ple hundred lines of code (from GNU source) to compile, and link with the very same code that is shared by all the standard Sun win- dow applications (“tools”). Presto! Emacs gets mice! Just like the LispM I remember similar hacks to the LispM terminal program to make it work with Emacs. It took about 20 lines of Lisp code. (It also took less work than those aforementioned couple hundred lines of code, but what’s an order of magnitude between friends?) Ok, so I run my Emacs-with-mice program, happily mousing away. Pretty soon Emacs starts to say things like “Memory exhausted” and “Segmentation violation, core dumped.” The little Unix console is consoling itself with messages like “clntudp_create: out of memory.”

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