History of the Plague 7 Date: Wed, 10 Apr 91 08:31:33 EDT From: Olin Shivers shivers@bronto.soar.cs.cmu.edu To: UNIX-HATERS Subject: Unix evolution I was giving some thought to the general evolution (I use the term loosely, here) of Unix since its inception at Bell Labs, and I think it could be described as follows. In the early PDP-11 days, Unix programs had the following design parameters: Rule 1. It didn’t have to be good, or even correct, but: Rule 2. It had to be small. Thus the toolkit approach, and so forth. Of course, over time, computer hardware has become progressively more powerful: processors speed up, address spaces move from 16 to 32 bits, memory gets cheaper, and so forth. So Rule 2 has been relaxed. The additional genetic material continues to mutate as the virus spreads. It really doesn’t matter how the genes got there they are dutifully copied from generation to generation, with second and third cousins resembling each other about as much as Woody Allen resembles Michael Jordan. This behavior has been noted in several books. For example, Section 15.3, “Routing Information Protocol (RIP),” page 183, of an excellent book on networking called Internetworking with TCP/IP by Douglas Comer, describes how inferior genes survive and mutate in Unix’s network code (paragraph 3): Despite minor improvements over its predecessors, the popularity of RIP as an IGP does not arise from its technical merits. Instead, it has resulted because Berkeley distributed routed software along with the popular 4.X BSD UNIX systems. Thus, many Internet sites adopted and installed routed and started using RIP without even considering its technical merits or limitations. The next paragraph goes on to say:

8 Unix Perhaps the most startling fact about RIP is that it was built and widely distributed with no formal standard. Most implementations have been derived from the Berkeley code, with interoperability lim- ited by the programmer’s understanding of undocumented details and subtleties. As new versions appear, more problems arise. Like a classics radio station whose play list spans decades, Unix simulta- neously exhibits its mixed and dated heritage. There’s Clash-era graphics interfaces Beatles-era two-letter command names and systems programs (for example, ps) whose terse and obscure output was designed for slow teletypes Bing Crosby-era command editing (# and @ are still the default line editing commands), and Scott Joplin-era core dumps. Others have noticed that Unix is evolutionarily superior to its competition, rather than technically superior. Richard P. Gabriel, in his essay “The Rise of Worse-is-Better,” expounds on this theme (see Appendix A). His thesis is that the Unix design philosophy requires that all design decisions err on the side of implementation simplicity, and not on the side of correctness, consistency, or completeness. He calls this the “Worse Is Better” philoso- phy and shows how it yields programs that are technically inferior to pro- grams designed where correctness and consistency are paramount, but that are evolutionarily superior because they port more easily. Just like a virus. There’s nothing elegant about viruses, but they are very successful. You will probably die from one, in fact. A comforting thought. Sex, Drugs, and Unix While Unix spread like a virus, its adoption by so many can only be described by another metaphor: that of a designer drug. Like any good drug dealer, AT&T gave away free samples of Unix to uni- versity types during the 1970s. Researchers and students got a better high from Unix than any other OS. It was cheap, it was malleable, it ran on rela- tively inexpensive hardware. And it was superior, for their needs, to any- thing else they could obtain. Better operating systems that would soon be competing with Unix either required hardware that universities couldn’t afford, weren’t “free,” or weren’t yet out of the labs that were busily syn- thesizing them. AT&T’s policy produced, at no cost, scads of freshly minted Unix hackers that were psychologically, if not chemically, depen- dent on Unix.