 |
|
|
|
|
|
     | |||||
 |
|
 |
|||
 | |||||
|
BSD Unix: Power to the people, from the code | page 1, 2, 3, 4
"His code was ugly." -- Kirk McKusick "Bill Joy was a fabulous marketer." -- Eric Allman "Bill was superb. He was the epitome of what one would like to see in a graduate student. -- Bob Fabry "He had an infectious enthusiasm about him, where he would just get the people around him to do stuff. And he had an incredible drive to get his software out so that other people would use it." -- Kirk McKusick "Berkeley Unix was the work of many talented developers. Bill Joy's particular genius was in integrating the work of these many contributors from many different organizations." -- Rob Gurwitz "Bill's really smart." -- Sam Leffler - - - - - - - - - - - - - - - - - - - - - Gage's eyes twinkle as he recalls one of his favorite Bill Joy stories. The scene, he says, is in a boardroom high up in a building overlooking Washington, D.C. The time is the early 1980s. In attendance are some representatives from DARPA, some employees of BBN* (a Boston company that received the original DARPA contract to build the Arpanet) and a few Berkeley hackers, including Joy. At issue was an annoying problem that had been bothering DARPA. DARPA had given Berkeley a major contract to enhance Unix so that it would be suitable for DARPA's network of research sites. It had also decided that Berkeley Unix should incorporate TCP/IP,* a specification for how Arpanet machines would interconnect. Devised by Vinton Cerf and Bob Kahn, TCP/IP (Transmission Control Protocol/Internet Protocol) was -- and still is today -- the basic method by which computers talk to each other across the Internet. But DARPA had given BBN the contract to implement the TCP/IP protocol,* to write the all-important TCP/IP "stack."* Joy had been instructed to plug BBN's stack into Berkeley Unix. But Joy refused to do so. In his opinion, BBN's TCP/IP wasn't good enough. So he wrote his own high-performance TCP/IP stack. As Gage tells it, "BBN had a big contract to implement TCP/IP, but their stuff didn't work, and Joy's grad student stuff worked. So they had this big meeting and this grad student in a T-shirt shows up, and they said, 'How did you do this?' And Bill said, 'It's very simple -- you read the protocol and write the code.'" "That really frosted the BBN guys." Well, sure. In programming lingo, a flat statement like "Read the protocol and write the code" is, to borrow some modern slang, a major dis. But did Joy really say the words? And did BBN's code really not work? No and no, says Rob Gurwitz, the BBN programmer who wrote BBN's implementation of TCP/IP. Gurwitz says he was at all the DARPA steering committee meetings that handled TCP/IP matters during that era, and he doesn't remember ever hearing Joy make such a statement. Gurwitz, who says he worked closely with Joy and Sam Leffler on the integration of TCP/IP into Berkeley Unix, also says Joy's version of TCP/IP was not a direct replacement for BBN's code. Joy's stack was designed to maximize performance over local area networks that had wide bandwidth connectivity -- like an Ethernet* network designed to serve an entire university campus, for example. Gurwitz's version was built to operate on the much narrower 56Kbps telecommunication lines that made up the Arpanet's backbone. Nonetheless, the Berkeley hackers were (and are) convinced that their implementation was superior, and they continued to resist all attempts by DARPA to force them to include the BBN version in Berkeley Unix, even though, according to Gurwitz, several DARPA sites continued to use BBN's version for years. As is the case with most programming disputes, the deeper one delves into the TCP/IP spat, the more "Rashomon"-like the search for truth becomes. So why is the squabble important? For at least three reasons. First, the incorporation of TCP/IP into Berkeley Unix can be, and often is, singled out as the most important innovation that made the Internet function efficiently. Joy and other Computer Science Research Group* veterans argue that their version of TCP/IP was crucial, because only it was technically good enough to satisfy researchers who wanted to communicate with each other and get work done on their local networks as well as on the Internet. The TCP/IP stack, one could argue, was the original Promethean gift of fire to the mortals of the Net. And when the Internet suddenly boomed in the '90s, Berkeley Unix scaled up right along with it -- a testament, says Kirk McKusick, to the quality of its design. To this day, BSD advocates contend that the networking performance of BSD, which can still be traced all the way back to Joy's TCP/IP code, outclasses the best that Linux-based operating systems can do. Second, the TCP/IP stack played a deciding role in settling the legal battle between AT&T and the University of California. The breakup of the AT&T monopoly in 1984 finally permitted AT&T to commercialize Unix. For years, as Unix became the preferred language of the Net and academia, AT&T had steadily increased licensing fees from the original $99 all the way up to $250,000. But AT&T wasn't the only interested party. In the early '90s, BSDi,* a spinoff of Berkeley's CSRG, started selling its own version of Berkeley Unix, and the University of California had been selling its version for years. In 1992 AT&T sued both the University of California and BSDi, claiming that BSD Unix included proprietary AT&T code. Unfortunately for AT&T, the version of Unix that the company was then pushing, System 5, turned out to incorporate large chunks of code originally written by BSD hackers -- including the TCP/IP stack. Berkeley released all its code under an extraordinarily liberal license -- basically, users could do anything they wanted with BSD code as long as they retained the University of California copyright. But AT&T had stripped the UC copyrights and begun marketing the software as its own. Hackers like McKusick were peeved. "We had written this code and they were claiming it was theirs," says McKusick, "and that they had the rights to it, and we just flat out didn't believe it. And it pissed us off that they were basically taking our work, that they hadn't paid a penny for, but that they had made money off of because of all the damn licenses that they had sold, and they were now trying to claim it was theirs." The University of California's lawyers seized upon the opening, countersuing AT&T for copyright violation. After the requisite legal scurrying, the two sides came to a settlement, the terms of which both sides are forbidden to comment on. That settlement, along with a concerted effort by BSD hackers to rid their code of any AT&T "taint," freed the operating system of its last proprietary vestiges. Third, even if Joy did not piss off his fellow programmers by saying "Read the protocol and write the code," no one who knows him well will deny that it is the kind of thing he could easily have said. Joy's colleagues and professors are unanimous in describing him as a fundamentally nice guy. But like so many great hackers, Joy is also almost unconsciously arrogant. And that arrogance has been, historically, a key part of the BSD legend. As a general rule, programmers tend to have a high opinion of themselves. And as a class, Unix programmers are well known for demonstrating their own special blend of high-priest orneriness. But BSD Unix hackers, with some notable exceptions, are especially virulent in their self-assuredness. They aren't wrong very often, and when they are, convincing them of that fact requires several armies and quite a bit of heavy artillery. Indeed, the easiest explanation for why BSD hackers watch in dismay while Linux-based operating systems sweep the world is that, for years, subsections of the BSD community have been endlessly imitating the mulishness that marked Joy's original reluctance to compromise on TCP/IP. Of course, if anyone ever had a right to be arrogant, it would be Bill Joy. When the University of California received new computer terminals advanced enough to allow a cursor to be mapped to a particular point on the screen, Joy promptly, and speedily, wrote a text editor, vi,* that took advantage of the new capabilities. Vi is still widely used today, standard equipment on nearly all Unix installations. If the compiler Joy was using didn't satisfy him, he wrote a new one. If the backspace key didn't work correctly in Unix, he rewrote the source code. And so on. "Bill's very good at taking something," says McKusick, "saying, 'OK, this is what I have, this is where I want to get to, what's the shortest path from here to there?' His code was ugly, unmaintainable, incomprehensible, but by golly it only took him two weeks to do an incredible amount of functionality. Someone asked me once to compare myself to Bill Joy, and I said, "You know, there's really nothing that Bill's done that I couldn't have done, but what Bill did in a year would take me 10.'" "He was just very good at reading a large body of code and wrapping his mind around it," recalls Fabry. "So he could do major reorganizations of code in a single weekend. I saw him do major reorganizations of the kernel several different times. In the beginning it took him just a few days, while later on it might take him a month. It was wonderful." Joy called me once on his cellphone. It was Feb. 14, and he was in a grocery store in Monterey, Calif., stocking up on food before heading over to the annual TED (Technology, Entertainment, and Design) conference. Never one to waste a spare second, he decided to combine two chores -- my questions about his Berkeley days and his own need for sustenance. The result gave me a close glimpse at one of Joy's more famous qualities -- his ability to multitask. While answering a question from me, he would simultaneously talk to the cashier or a counter person without skipping a beat. In the middle of a sentence, out would pop the words "fruit salad" or "yogurt with raisins." Like Unix itself, famous for its ability to perform simultaneous tasks, Joy could allocate portions of his brain to separate jobs at the same time, without appearing to shortchange any of them. I learned later that his performance wasn't as awe-inspiring as I first thought. Joy, I was told, decides what he thinks about something and then rarely changes his mind; instead, he stores away his thoughts on the subject and is able to regurgitate them on demand, without wasting any fresh brain cells. People who've worked with Joy say his ability to compartmentalize made him difficult to deal with on occasion. The stories of shouted arguments ringing through the hallways of Berkeley's computer science department are legion. But Joy's stubborn single-mindedness also made him an excellent leader. Berkeley Unix thrived in large part because Joy held his code to the highest possible standard and refused to compromise. Leffler, Joy's second-in-command for most of the heavy lifting involved in pushing out the first versions of Berkeley Unix, says he and Joy had a responsibility not to compromise. The U.S. Department of Defense was paying for BSD, and its prospective users encompassed the cream of the computing-science crop. Intriguingly, Joy doesn't subscribe to the fundamental credo of the Linux movement -- the belief that the strength of open-source software is its ability to tap the energy and enthusiasm of a vast network of volunteer programmers. Linux is built on an egalitarian ethic: Perhaps not every programmer will write great code, but together, all those eyeballs and all those keyboard-pounding fingers will incrementally make their way toward greatness. But Joy doesn't believe that having more programmers equals better code. "Most people are bad programmers," says Joy. "The honest truth is that having a lot of people staring at the code does not find the really nasty bugs. The really nasty bugs are found by a couple of really smart people who just kill themselves. Most people looking at the code won't see anything ... You can't have thousands of people contributing and achieve a high standard." Joy even disputes the commonly held conception that BSD set the model for demonstrating how a large software project could be built via contributions by a widely distributed network of programmers. "Almost no fixes came in from anywhere else," says Joy, referring to Berkeley Unix. "In fact, most of the stuff I got back was not that great. Remember, there wasn't a real swift network at that time. In later years you got stuff back, but I didn't get much stuff back during that time that I was doing." Joy may be overstating the case. Leffler and McKusick, while conceding that 90 percent of outside contributions did not meet Berkeley's standards, state authoritatively that significant portions of BSD code came from outside Berkeley. And after Joy's 1982 departure to Sun, the percentage of outside contributions began to rise, in tandem with the rise of the Net. Joy may be overreacting against the new generation of open-source hackers, many of whom frequently fail to acknowledge (or even be aware of) Joy's contributions to the software ecology that underlies the entire free-software movement. Joy says that when he boots* Red Hat Linux, he sees boot-up messages scroll by that he personally wrote 20 years earlier. Joy would much rather talk about his current passions, Sun's Java and Jini, and when he's asked about Linux, he sometimes lets traces of annoyance slip through. Who are these punk hackers, some of whom weren't even alive the first time Joy rewrote the Unix kernel? "If I had to rewrite Unix from scratch, I could do it in a summer, easily," says Joy. "And it would be much better. A much, much better job. The ideas are old." But if an increase in the number of programmers doesn't ensure an increase in the quality of code, then why do Linux-based operating systems dominate the market today? And if Joy rejected most contributions from outside Berkeley, why does BSD enjoy a reputation for pioneering the model for collaborative open-source software development? |
|
||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||
Next page |