7 The X-Windows Disaster How to Make a 50-MIPS Workstation Run Like a 4.77MHz IBM PC If the designers of X Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which fol- lowed the same principles—but you’d be able to shift gears with your car stereo. Useful feature, that. —Marcus J. Ranum Digital Equipment Corporation X Windows is the Iran-Contra of graphical user interfaces: a tragedy of political compromises, entangled alliances, marketing hype, and just plain greed. X Windows is to memory as Ronald Reagan was to money. Years of “Voodoo Ergonomics” have resulted in an unprecedented memory deficit of gargantuan proportions. Divisive dependencies, distributed deadlocks, and partisan protocols have tightened gridlocks, aggravated race condi- tions, and promulgated double standards. X has had its share of $5,000 toilet seats—like Sun’s Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn’t have enough to tell you the time. Even the vanilla X11R4 “xclock” utility con- sumes 656K to run. And X’s memory usage is increasing.

124 The X-Windows Disaster X: The First Fully Modular Software Disaster X Windows started out as one man’s project in an office on the fifth floor of MIT’s Laboratory for Computer Science. A wizardly hacker, who was familiar with W, a window system written at Stanford University as part of the V project, decided to write a distributed graphical display server. The idea was to allow a program, called a client, to run on one computer and allow it to display on another computer that was running a special program called a window server. The two computers might be VAXes or Suns, or one of each, as long as the computers were networked together and each implemented the X protocol.1 X took off in a vacuum. At the time, there was no established Unix graph- ics standard. X provided one—a standard that came with its own free implementation. X leveled the playing field: for most applications every- one’s hardware suddenly became only as good as the free MIT X Server could deliver. Even today, the X server still turns fast computers into dumb terminals. You need a fairly hefty computer to make X run fast—something that hard- ware vendors love. The Nongraphical GUI X was designed to run three programs: xterm, xload, and xclock. (The idea of a window manager was added as an afterthought, and it shows.) For the first few years of its development at MIT, these were, in fact, the only programs that ran under the window system. Notice that none of these pro- grams have any semblance of a graphical user interface (except xclock), only one of these programs implements anything in the way of cut-and- paste (and then, only a single data type is supported), and none of them requires a particularly sophisticated approach to color management. Is it any wonder, then, that these are all areas in which modern X falls down? 1We have tried to avoid paragraph-length footnotes in this book, but X has defeated us by switching the meaning of client and server. In all other client/server relation- ships, the server is the remote machine that runs the application (i.e., the server pro- vides services, such a database service or computation service). For some perverse reason that’s better left to the imagination, X insists on calling the program running on the remote machine “the client.” This program displays its windows on the “window server.” We’re going to follow X terminology when discussing graphical client/servers. So when you see “client” think “the remote machine where the appli- cation is running,” and when you see “server” think “the local machine that dis- plays output and accepts user input.”