 Just move across one, though, for the people that do arrive late. Righty-ho, it's time, so we will start right now. My great pleasure to introduce Marshall Kirk-Nakuzek, who is not doing anything about Linux. Isn't that great? BSD, something real. Please welcome him. OK, well, it does seem appropriate that you should know that there is other technology out there. And it is open source, so you can go and never come up with a good idea when you can steal a better one. This is a narrative history. Narrative means I'm not going to use my laptop. Instead, what I'm going to use is some written notes and just work off of those. So I actually made a little note on here that I should talk about the history of the history of talking about BSD. These notes were written as I was going to the first conference where I presented this, which turned out to be the Australian Unix users group meeting in Perth in 1986. Now, it turns out that in the previous decade, they had finally completed a single gauge of real line across Australia. And so the government had begun running a train, which is known as the Indian Pacific Express. It runs from the Indian Ocean, which is to say Perth, to Sydney. And we were on this train, and I was writing the notes. So it's a little bit sort of bouncy on here as we're going across the Nulliber plain. And the Nulliber plain is really boring. You can sort of see the curvature in the earth and every now and then a sagebrush or something will go by. So it was a great time to sit down and write my talk. All right, so what I'm going to do is give you the sort of abridged history here because it turns out that when I do the entire history in all the gory detail, it takes about three hours. And they didn't give me a three-hour slot, and besides which you would probably fall asleep if that were the case. So I would normally give you a lot of the sort of prehistory of Unix. The short version of this is there was a thing called Multix, which was a joint project of MIT, General Electric, and Bell Laboratories. General Electric was in the computer business at that time and was building the machine. MIT was supposed to be bringing the sort of academic expertise. And the people at the labs were supposed to be getting a certain amount of practicality into it. It was one of these systems that failed from the sense that when they were just about to get something that would work, then they'd say, all right, well, we understand that problem, so now let's do this next thing. And so it would almost get there, and then they'd completely change things. And it would almost get there, and then they'd completely change things. And finally, the folks at the labs got fed up with this and said, enough is enough. We're out of here. And so they exited this project, and the folks that had been working on that, which included Ken Thompson and Dennis Richie, were really bummed because they didn't really want to go back to punch cards on the IBM mainframe, which was the other alternative. And so they found a PDP7 sitting in a corner somewhere and pulled it out and decided to start writing little like a, well, an operating system, what we'd call an operating system today. But it didn't need a lot of functionality because all they really wanted to do was this sort of space war game. And so they needed just enough functionality to make that work. So they got that sort of going. And I mean, this is the labs, back in the days when it was the labs, and they could sort of do whatever they wanted to do. And but then they decided, all right, well, this is kind of cool, but they were pretty limited by what the PDP7 could do. And they wanted to get one of these new powerful cool machines that was coming out called a PDP11. It was a PDP11-20, actually. But they were sort of too expensive to get on the budget that they had available. And so they did what many technical people have learned to do over the years. And that is that you go find someone else within your company that has boatloads of money. That would be the legal department. Well, the legal department, they had to do all these documents and so on. And the way you would do it is you would write it out and then some secretary would type it for you. And then you'd mark that up, and you'd change three things. And then they'd retype the entire page to get those corrections in and so on. And so they said, we can automate this for you. All you need to do is buy us this computer. And so legal department's like, oh, sure, of course. That's easy. And so they had UNIX plus Roth, not N-Roth. That was the new Roth. But ROFF, which was the runoff program, which was the thing that they wrote for the legal department so that they can fulfill that piece of their mission, I must say, if you look at ROFF code, you can see that they didn't put a great deal of effort into it. They just sort of did what it minimally needed to do, which is why N-Roth had to come along later. At any rate, the real goal of this was that they could start doing this operating system. And UNIX was supposed to be everything that Maltics wasn't. And so where Maltics would have eight ways of doing things, they would try and find the minimalist one way of doing it. And you might find that hard to believe, looking at almost any UNIX system today that it was supposed to be really simple. But that truly was the goal at the time. And one of the beauties of working in a 16-bit ADVIS space is that's about 10,000 lines of C code, and then you're out of room to do anything. And so it's what a scary today. I look at some of these disc drivers, and they themselves are bigger than the entire UNIX kernel used to be. Anyway, they started originally writing an assembly language, because the belief at the time was that that's what you had to do operating systems in. But within a couple years, they realized that they could do better than that. And C was essentially written as a sort of glorified macro assembler. You could look at a line of C code and pretty much tell exactly what the code was it was going to generate. At any rate, between the version 3 and version 4 was where they converted from assembly language to C. And this was done within three years of starting, which would have made it 1973. The reason that time starts on January 1st of 1970 is because that's when they started the project. At any rate, they presented at SOSP, the Symposium on Operating System Principles, which is the sort of academic OS conference, which is held every other year. And there were, of course, a bunch of academics there. They got, you know, this looked really cool, because here's a relatively inexpensive machine that gives us interactive stuff and nothing else essentially had that other than things that ran on the mainframe, but were much too expensive to actually use. So in particular, Bob Fabry, who was a professor at Berkeley, thought this was very interesting. He talked to Ken Thompson. And within not much time, UNIX came to Berkeley. And they were able to buy at the time a PDP 1145. Unfortunately, the CS department at Berkeley couldn't afford an 1145 all to themselves. And so they had to share with math and stats. So they went to the math and stats department, which was much bigger and had more money. And so math and stat basically put up a third each. And the CS people put up a third. And then, of course, the CS people wanted to run UNIX on it. But the math stat people would have none of this experimental operating system. Hoo-ha! We had to run something real, which was the deck system that ran on that. And so then the question is, well, who gets to run? When does the CS department get to run UNIX? And when did the math stat people get to run their operating system? And so what ended up happening was it was divided into three eight-hour periods and rotating through the day. So UNIX would run from midnight to eight. And then the next day would be eight to two, or eight to four, and then four to midnight. And so it just would rotate around the clock. And you had to sort of be awake at whatever time it was that it was up and running. This was sort of untenable. And so fairly quickly, they were able to get their own PDP 1170 at that point. This was about the time that version 6 was coming out. And it turned out that Ken Thompson is an alumnus of Berkeley. And so he actually came out to personally install it. And unfortunately, this was a bigger system than any that they had had back at the lab. It had not one but two 28 megabyte disks on it. And so it turned out that the code that was supposed to let both disks operate at the same time had a few race conditions in it. It didn't work very well. So Ken Thompson had to sort of debug that stuff. Anyway, at the same time, this had been 75, another student matriculates to Berkeley named Bill Joy. And Bill Joy sort of gets excited about this stuff and starts working with Ken Thompson. Really, what we would today call as a system administrator, essentially dealing with taking care of the system and doing a lot of the stuff of that sort, but also getting a chance to get his hands in and see what's going on. Now Bill actually had the same advisor that I did. Both of us were getting our PhDs in programming languages. And so the sort of the first project he did was to write a compiler for this new language that had just come out called Pascal. And so, and then of course in trying to do that, then he would be very frustrated because the only editor we had was ED. And so he got involved in doing the I and then he didn't really like SH very much. So he did C shell. And to this day, I can't understand how someone who was getting a PhD in programming languages could have so thoroughly botched up the syntax of something like C shell, but go figure. Anyway, as Bill started doing these projects, he would make them available to the rest of the world, mostly by talking them up at conferences and things. And so people would send in tapes, these rate track tapes and he'd spool up. Then his first distribution was in 1977, which included Pascal and the ex-terminal or the ex-editor and a very early sort of version of VI that had the term cap associated with it. Term cap was because we had two different terminals types. And so instead of card coding it in there, he did term cap to differentiate them. He later told me that that was the biggest mistake he ever made because it allowed this proliferation of terminals that just all had bizarre escape sequences, et cetera, he wished he'd never done that. At any rate, that put out about 30 copies of that and it was just called BSD. It's like when a rock group puts out their first album, they just call the name of the album as the name of the rock group and then what happens when they put out their second album? So it's the same thing, it's just called BSD and so then when the next one comes out, what are we gonna call it? Well, it'll obviously have to be two BSD. Two BSD came out about a year later, had updates to Pascal, it added C-Shell at that time and about 75 copies of that went out. It led to later things like 2.9 all the way up to 2.11 which were continued releases for the PDP-11. Bill did not get involved in those releases but other people did that at Berkeley and elsewhere. Meanwhile, in 1978, the department bought a Vax. In fact, it was serial number seven and this was because there was a group there that was working on a thing called Vaxima which was this equation solving thing that basically ran on Lisp. The problem with Lisp is that you say Lisp and then by the time you get your first prompt it's already consumed like all the memory on the machine and then it's extra if you wanna do anything after that. So the PDP-11 just didn't cut it at all. The Vax however had two megabytes of memory so we could really run giant stuff on this. We got in, of course, when it came from DEC it had VMS on it and there were people like Bill that said well of course we should be running UNIX on this. There was a quick and dirty port done at the labs called 32V but it was just literally sort of the minimal port from the PDP-11 version so it didn't use any of the paging hardware on the Vax. It just did fixed processes. And the problem with that was that Vaxima needed more than two megabytes to run and so they insisted well we've gotta run VMS because it's gotta have virtual memory and Bill's like ah, he's pulling his hair out about this so he runs around the department and finds this guy named Oza Babagalu whose, his PhD is on virtual memory stuff and has sort of this prototype thing and Bill says oh good we'll just drop this into 32V and then we'll have paging. And one of the things I will say about Bill is that he's very good at sort of figuring the minimal amount of work to get from where he is to what he wants. Someone asked me once to compare myself to Bill and I said you know there's nothing that he's done that I couldn't do. It's just that it would take me like 10 years to do what he does in one year. The problem is that when he's done you can't touch it because you've changed a single line and it just collapses in a puddle. Look at VI, you know, it's like it had just to be rewritten from the ground up before you could change it. At any rate, so Bill goes in hack, hack, hack, hack, hack, and there's only the one Vax so if you're going to test stuff, the only time it can be tested is over the Christmas break. So class is in about middle of December and he has until the middle of January and if it's working by then then it's going to run and if it's not working by then it's VMS for the next six months. So I for various reasons was actually around over that Christmas trying to get work done because it was one of the few times when the machine wasn't super busy so I'd be working along and it would be running 32V at that point and then it would message machine going down to boot VM Unix, you know, and then you'd come up and VM Unix prompt, you'd log in, you'd be typing away, typing away, and then all freeze and then there'd be a little break and then 32V would come back up and so this would happen but it was more and more time running VM Unix and by the time classes were ready to start it mostly worked and it was really about another month before it really worked but we never look back. Never ran VMS again on that machine. Anyway, he put all that stuff together and this became 3BSD. So 3BSD was the first BSD which included not just some utilities and so on but it was an operating system and libraries and everything so it was the first whole and complete system and of course BSD has been that ever since. So that was 1979, about 100 copies of that got sent out and you have to understand now with 3BSD we've got a whole bunch of AT&T code in there because it's a lot of the AT&T kernel and a lot of the AT&T utilities. It's really just sort of AT&T stuff with some BSD stuff sprinkled through it. So at this point now, of course, you have to have an AT&T source license to be allowed to get the BSD. So you have to understand that Bill was a student. He was developing all this stuff and he was also the distribution coordinator. So there were several of us students sharing an office with him because that's the way it worked and the phone would ring and you would just hand the phone to Bill because he just knew it was, no one else was gonna ever call him. And so the conversation would go approximately like this. Hi, yes, you wanna get BSD, okay. Send me a tape and I will put it on there and mail it back to you. Oh, you do have an AT&T license, right? Okay, good. End of, well, the university sort of cottoned on to what was going on here and they decided this was perhaps not the optimal way to do this. And so they said, all right, enough is enough of this, you have to do real license verification. And Bill's like, I am doing license verification. I'm asking them if they have a license. They wouldn't lie to me. At any rate, the best, well, in this sort of timeframe, this is now the early 80s or 1980 really, the DARPA begins to decide that they want to start getting a little, well, they have a whole bunch of different contractors that all have different machines running, different operating systems using different programming languages. And it's almost impossible for any of their contractors to share code of anything that they do. Everything immediately has to be re-implemented. And so they wanted to pick a common hardware platform and a common software platform. And so there's a long and interesting story about, well, they picked the Vax and then the long and interesting story about whether they should run VMS or UNIX on it, but I don't have time to go through that wonderful little ditty. But in the end, they decided that it was gonna be UNIX and that Berkeley would be funded to do the base system. And then of course, one of the key things they wanted to get into it was this new networking thing that called TCP-IP that was gonna replace NCP. NCP had this sort of limitation that it could only have 256 hosts and they were fast approaching this limit. But they didn't really trust Berkeley to do TCP-IP because that was this complicated networking protocol. So that would be handed off to, who was it? BBNN, thank you. Handed off to BBNN to do. And then all that Berkeley would do would be to design the API, so the socket interface basically. And so at any rate, this money comes in and the key thing is that it now allows, first of all, Bill to get paid a salary. And more importantly, an assistant admin, or assistant admin that'd be hired, or not assistant admin, but an administrative assistant who was gonna do all of the license verification who would actually make them send a copy of their license and then call AT&T and verify the license and all this other stuff. So that Bill no longer had to do that, which was good because the number of copies just kept rising. So as a prelude to the serious DARPA work getting done, 4BSD was released, which sort of wrapped up everything that was sort of ready at that point in time. So it had things like job control, got added. The file system went from using 512 byte blocks to 1K blocks, which doubled the performance. They had auto reboot up to that point. You had to manually deal with it. FriendsLisp deliver mail, which you heard about earlier today. And that came out in October of 1980. About 150 copies of those got distributed. Remember that one copy goes to like a university and gets completely used on all of their machines or a company gets one, so 150 copies is very wide usage. Okay, so then the DARPA funding really begins. There's the big debate about which one they're gonna run. Ultimately, they decide that it's gonna be UNIX and so serious development begins. So Bill gets the socket stuff organized and he wants to test it. And so he goes to Rob Gerowitz, who's a person at PBNN that's overseeing the development. And he says, well, can I get an early release of your code? And sure, of course. And so he gets the tape and he puts it on and puts it in and hack, hack, hack, hack, gets the interface to sockets going. And then we had actually a prototype of the thing called Ethernet, you may have heard of this, from the Xerox PARC folks. But it was the early Ethernet, so it only ran at three megabits, not 10. So we had the two machines in this three megabit Ethernet between them. And Bill fires it up and he needs to test copy a file across. Well, of course, you're supposed to have FTP, but FTP hadn't been written. So he did this little fast hack called RCP. And then in order to do remote login, you know, we were supposed to write Telnet, but well, we didn't really have time for that right away. So he did a little fast hack thing called R-Login. They never should have been let out. They just, you know, we knew at the time they were a disaster. But at any rate, so he fires up RCP and copies the file across. Well, BBNN had this great layering and there was a state machine and all these things in there that, you know, the way you're supposed to design code. But in Van Jacobson's words, layering is a great way to design protocols, but it's a crappy way to implement them. They're really inefficient. And so Bill fires this up and tries to copy a file across. Well, all that BBNN had been running on were the 56K backbones. We had a VAC 750, which was 0.7 MIPS. And there was so much computation that you completely saturated the CPU by the time you were getting 56K B throughput. Well, Bill was gonna have none of this. I mean, we have three megabits. Why, you know, we wanna get that bandwidth out of here. So, hack, hack, hack, hack, hack, hack. You know, we have this state machine. We'll just turn that into a big switch statement. What if you go tos between them for the state transitions, et cetera. Right, anyway, he had it so that you could copy a file from 1.752 another over three megabit and get the full bandwidth. Okay, so anyway, there's another sort of interesting story that I don't have time to tell, but it's how I got sucked into writing this little file system thing. Bill had done sort of an outline of what ought to be done and I needed a summer job for various bad reasons and he says, well here, just do a little prototype of this, you know, and so I did this sort of a summer project and of course got sucked in and spent 18 months getting it all working, because he didn't tell me that I had to do dump, restore, FSCK, et cetera. Anyhow, we finished this up and we actually released sort of an early release of this and what we wanted to call it was five BST. You know, one BST, two BST, three BST, four BST, what do you call next one, five BST. However, AT&T had just released something called system five and they were concerned that there would be marketing confusion if there was something called five BST and system five and so we could not call it five BST. So my attitude at the time was great, we'll call it six BST. But for various reasons that decided we would call it 4.1 and then 4.2, 4.3, 4.4, et cetera. So that's how that came about. Anyway, we released this thing which had the preliminary TCPIP code as hacked up by Bill and this was called 4.1A and this got fairly wide distribution because there were a lot of people that really wanted to use it. A lot of people really hammering on it. A lot of bug fixes and enhancements and other things. Another important thing is that Sam Luffler joined the project and Sam, unlike Bill, actually had some background in networking and made some very important changes to the API. Notably, it used to be that when you'd have a TCP socket and someone would connect to it, that port was tied up until you finished whatever you were doing. So if you had an SMTP server on port 25 and someone connected, no one else could connect to port 25 until that session was done. And Sam's like, no, no, no. Believe it or not, you might want to have more than one incoming mail connection at a time. Bill's like, oh, really? So anyway, the API got changed to add the accept system calls to essentially pop off connections as they come in, which was an important improvement. At any rate, I finished up the file system. That system was released along with these bug fixes as 4.1b. Then there was all the revision to signals. Again, it's an interesting story, but one I won't go into. That came out as 4.1c. And then 4.1d was supposed to have the new VM system in it. But Bill got kind of sidetracked by this company in the South Bay called Sun Microsystems. He, of course, went off to be one of the founders of it and then tried to convince me that I should go along. And I said, well, Bill, I'm only a year away from my PhD, and I know that you say I can finish my PhD if I'm there, but I know startups don't work that way. And besides which, this is the workstation market. Apollo's got a three-year jump on you. They've got all the applications locked in. How do you ever expect to succeed? And he's like, oh, they're open, blah, blah, blah. Yeah, right. OK, I'll talk to you when I'm done. Well, it took me 18 months to finish my PhD. And by that time, Sun was out there running. And the interesting stock options were gone. But I was a consultant to Sun and to port the Pascal compiler for them. So I ended up getting a few thousand shares of Sun stock, which ultimately turned to be quite valuable, which is why I can just wander around the world and give talks like this these days. At any rate, the VM system did not get done at that time. Instead, there was too much pressure to release 4.2, which we did. And that would have been in August of 1983. And about 1,000 copies of this got shipped out. So it was still, at that time, the predominant UNIX system that people were using. They would buy the AT&T license. They'd put the tapes on the side, and they would just immediately get the BSD and drop it on there. So it was sort of the heyday of the BSDs, certainly. The problem was that it wasn't open source, because there was always AT&T code. So you had to have an AT&T license. At the time, it was cheap to buy an AT&T license. And so that wasn't really much of an issue. However, the folks from BB&N had finished TCP at this point and had sent us the final thing. And were dismayed to discover that we hadn't put it in. Well, again, there's a very long and amusing story here. I don't really have time to tell all of. But what ultimately happened was that Berkeley and BB&N agreed to have a bake-off. And we had to find a neutral third party. And DARPA suggested this guy named Mike Moose at the Ballistic Research Lab in Aberdeen, Maryland. And he had been involved with various other DARPA things. So it was good with DARPA. And he was buddy-buddy with some folks at BB&N. So they thought they had an inside edge. On the other hand, he had done a whole lot of development of what we were shipping. And so we knew that he had a certain interest in that as well. So fine. It sounds like a good neutral party to us. Anyway, he does a bunch of tests. And one of the things that's really important to DARPA is when you have high packet loss. Because someone drops a nuclear bomb on Chicago and has to figure out that it has to route around through Texas or something. Anyway, so one of the tests, we were just maximal throughput basically on good connections, is what we really optimized for. Whereas BB&N had spent a lot of time worrying about lost packets and other things. And so one of the key tests that was to be run was one where they would lose about every fourth or fifth packet and see what the retransmissions and all that stuff was going to work. And so we, of course, don't find this out until we've already shipped it. And then we get back what the tests are going to be. It's like, ugh. So at any rate, Mike Moose's report comes. And of course, you immediately go to the last page and see what the conclusion is going to be. And he carefully doesn't really let you know. So you actually have to read the thing through. And it's a really amusing read. Because he talks about, first of all, when there's no packet loss, you know, BSD does this on BB&N is down here. But now we turn to the test where we're going to be losing a quarter of the packets or so. And so what we find is that BB&N gets off to an early start. They're getting much more data through than the BSD is. However, while BB&N is rebooting, BSD catches up. I guess you can figure out where it went from there. Because of course, our whole point was ours was better debugged. At any rate, that held up the release of 4.3 for a very long time, I mean, almost a year while all of this argument was going on back and forth. And finally, we got blessed to release that. And we did it. So that became the 4.3 release, which, where did I say? That came out finally in June of 1986. So we had been, we said in June of 85 that it was going to come out. And that was already two years. So it had been a long time. There was a lot of demand. Finally, we got that out. OK, so meanwhile, this guy named Keith Bostick. We have a little bit more money that's available to us now. So we decided to add a third programmer to the BSD team. This would be Keith Bostick. He came to Berkeley. One of his requirements in coming was that he would be allowed to finish 2.10, which was the PDP-11. He wanted to take the TCP-IP code and put it into the kernel that was released on the PDP-11. Well, TCP-IP code all by itself was the entire address space of the PDP-11. And so this was quite a challenging problem, because you had to do what's called overlays, where you essentially have two sets of things. And you flip the map registers as you cross from one segment back and forth, mind-boggling. I mean, I admire the problem, but it was mind-boggling. And neither Mike nor I could understand for the life of us why he wanted to do this. But sure, in your spare time, I mean, there's only three things you need to do here. One is you're going to have all technical support that comes in on the phone. Two is all technical support that comes in from email. And three is some of these other programming projects we have for you. But any spare time you have after that, feel free to do it. And somehow he did all of that. Anyway, he finally got 2.10 going. And we had a party to celebrate the fact that he'd finally gotten this done. And at the party, he opens the window to his office. We're on the fourth floor of Evans Hall. Looks down to make sure that there's nobody below and drops the PDP-11 out the window, smash onto the concrete four stories below. We're like, Keith, what did you just do? He said, I never want to see that PDP-11 again. OK, so after that, we had his full attention on what we were doing. So at this point now, AT&T, which used to sell their source licenses for about $20,000, had started raising the price. So by this time, it's about a quarter million dollars. And that's to run it on one CPU, one machine. And there were a bunch of people that wanted to build these products, which were sort of cards that you could plug into PCs. Because PCs were so feeble that they couldn't really run networking. So you'd have to build a separate card that had its own CPU on it that would do the protocol. And then it would just sort of stuff this thing back into the PC. And they needed a TCP IP stack. They wanted to get the one from Berkeley. We, of course, had completely written that ourselves. There was no AT&T code. The only networking that was in AT&T was your UCP. So they said, well, could you release just the networking stuff under a freely redistributable license? And Keith was really hot to do this. And so we went through and we took all of the TCP IP stack and sockets and all that out. And then we threw in Telmad and FTP and, regrettably, RCP and RLogin and put this out. And this was, we called this networking release one, which, again, we were ready to release it in about 1988. It took about a year to talk to the Berkeley lawyers to get them to sign off on doing this. They, of course, saw dollar signs. We're going to make all this money. But luckily, we'd been funded by DARPA. And one of the things we could show them in the DARPA contract was that this had to be made available freely because it had been paid for by the government. And so to the people, and this is Berkeley, so you can have some great arguments with the lawyers on this line. At any rate, so we get this license written and we tell them, well, it has to fit in every file. Because, of course, they wanted this thing that was 19 miles long. We said, no, no, we have to put that in every file. There wouldn't be enough room on the tape if we had to have this huge thing in every file. So we got it down to what's now referred to as the Berkeley license. In fact, it had four clauses and the newer ones today have only two. But at any rate, we put this out and this was a wild success. We figured we'd sell three copies. One would go to UUNet, who would put it up and everyone would just download it for free. But it turns out you could pay $1,000 to Berkeley to get it. And to our amazement, about 1,000 people sent in their money because they wanted that piece of paper from sign by the Berkeley lawyers saying, this is freely redistributable. It was great for us. It was like, you know, that was our budget for several years. OK, so we decided we continued doing our development of the main line system. The next system that should come out was 4.4. But Mike Carls, who was sort of organizing when the distributions ought to come out, had this thing in his mind of what 4.4 was supposed to have in it. And he wasn't going to call it 4.4 until all these things were done. And so we started coming out with 4.3 Tahoe and 4.3 Reno and all these sort of intermediate releases. And then finally, when Mike eventually left and I was totally in charge, 4.4 came out, even though it didn't have everything that Mike wanted to have in it. So we did the Tahoe release. And that was primarily to support a second architecture. And then the next intermarine release after that was 4.3 Reno. That had the new virtual memory system. Again, I don't really have time to tell that whole story. But we essentially started from mock. We didn't like the API. But the code was pretty solid. So we brought that in and then put the M-Map interface on it as opposed to the messaging stuff that they used. Also, NFS came in at that point in time. I'm sorry. But the sort of the real driving thing that was happening at this point was the release of Net1 had put pressure on us to do release more. There's lots more cold stuff in there. Can't you release it? And Keith Bostic in particular was really gung-ho. He was like, we should do this. And Mike and I are like, Keith, it's one thing to get the kernel. But there's all these utilities and all this. It's just too big of a project. If you can figure out something to do with the utilities and libraries, you let us know. Then we'll talk about the kernel. And then we figured that was the end of it. We weren't going to hear about it anymore. But we underestimated Keith. Keith, of course, couldn't do this himself. So we would go to USENIX conferences. And Keith would put up a list of all the utilities and libraries that were needed to be rewritten. And the thing was rewrite these utilities. And then you'll get your name in lights. You'll contribute it to Berkeley. And we'll say how wonderful you are. And that sort of works for a while. Someone will do L.S. and cat and stuff like that. But when he started getting things like T. Roth and some of the nastier bits of the C library, so he comes marching into our offices. He says, well, I've got two-thirds of the utilities and nearly the entire library. How's that kernel coming, guys? And I looked at Mike and Mike looked at me. And we're like, we can't really use the same technique you're using. So we said about trying to figure out, well, where is the AT&T code? Because the way you do C code is you don't rewrite everything. You grab a piece here and grab a piece there and put it together and glue it together. And so stuff that might have originated over in the terminal driver somehow ends up over here somehow. And so we have to identify all of the AT&T code. So we came up with this sort of amusing technique. We first ran the entire kernel through CB, the CButifier, which just puts it in a canonical form. And we took 32V and did the same thing with it. And then we built an inverted line-by-line database of 32V. And then we took every line of our code and compared it against the 32V. And any time you'd get a run of two or three lines in a row that matched two or three lines in a row out of 32V, you'd go, aha, something needs to be dealt with here. And mostly it was just stupid stuff, like a linear search through the process table. It's like, well, that's dumb. It's just hashed out. It improves the performance and gets rid of that bit of code. So anyway, when the dust all settled, we were down to about six files that were left that still had any significant amount of AT&T code. And my attitude was, well, let's just rewrite these six files. How hard can it be? And Mike's like, if we release a complete kernel, that's going to really get them going. But if we just release, this is a partial kernel and some utilities and stuff, like we did with net one, it'll be fine. Well, we went and talked to the lawyers. And we didn't want to get them to start up. So we said, this is just an expansion of the previous one. We want to call this networking release two, despite the fact that it contains 95% of the system. And most of the stuff that we threw out was like the console driver for the Vax. So anyway, the lawyers say, well, how close is this? And so we say, well, yeah, yeah, yeah, yeah. Anyway, they said, well, we're not going to approve this. That has to go to a higher level. So it worked up to the head of the department. He didn't want to sign off. It had the school of engineering. He didn't want to sign off. But I'm not allowed to say exactly how high it went. But that particular chancellor was very favorably disposed to us. And so he said, all right, I want you to get, or told the lawyers, bring in some outside experts, have them do an audit and see whether these people really know what they're talking about. We passed the audit. And so out it went. And in fact, the initial release didn't cause any trouble. The trouble occurred when a guy named Bill Joelitz wrote the six missing files and started having a system that would actually boot and run. And then the second problem was that Mike had left to start a company called Berkeley Software Design Incorporated. And being technical people rather than marketing people, they sort of did a few tweaks that wouldn't really be optimal. For example, they got the phone number to order. It was 1-800-ITS-UNIX. And they ran marketing campaign, UNIX at 1% the cost of what you have to pay AT&T. And anyway, this caught AT&T's attention. They didn't like it. So they sued BSDI. Well, BSDI, remember I told you you could pay $1,000 and get a thing signed by the university saying, this is freely redistributable? They said, hey, here's this letter from the University of California. It says it's freely redistributable. All we did was write these six files. Which of these six files do you want to discuss with us? Well, of course, they really had written those. And they were completely clean. And so the lawyer or the judge that was overseeing the case was about to throw it out as a pointless case. And so they were forced to sue the university in order to stop it. And so now you have, instead of huge company against little tiny thing that's going to get just obliterated, now you've got huge company against immovable force. And anyway, this is where I began my career learning about being an expert witness. One of the things that I'll remember to this day before I went into my first deposition was being prepped by the lawyer in which he said, now remember, a deposition is like getting a procted exam from Captain Hook. He wasn't kidding. Anyway, again, it's a huge fun story to go through the whole lawsuit, which I also don't have time for. But ultimately, in the end, what it turned out was that the people at AT&T had done some bad stuff. Like, they had taken the TCPIP code, which, of course, they were free to do. The one thing that they weren't allowed to do was remove the copyrights, which they hadn't done. So when they were comparing BSDI with their source code, they saw huge amounts of common code. Well, of course, it was common code because they'd taken it from BSD. But there was no copyright. And the people that had done that were gone. And so they didn't realize what they'd done. And when this came to light after two years, they realized that they really didn't have a case. And so it all settled. We agreed to make some minor changes so that we could release something new, which we called 4.4 BSD Light. And the agreement was that they would bless this. But we had to say that the net two could not be used because they figured that was going to set back BSDI because they were going to have to start all over again and that it was going to essentially put a damper on things. Turned out it didn't. But at any rate, the settlement came. And at the end of the day, we ended up having to add USL copyrights to 70 files, along with things saying that they were freely redistributed. All these were common header files, which had been discovered to be essentially in a public domain. And we had to delete three files. And there weren't really three files to delete in the kernel. And so I remember going out for a conference with our lawyers and they said, look, we don't care what you pick. Just pick something because they have to save face. So we came back in and said, OK, what we've decided that we're going to get rid of is the System 5 IPC emulation, the System 5 shared memory emulation, and the System 5 semaphores. Oh, please, don't make me take that stuff out of the kernel. OK, so the upshot of that was that 4.4 BSD light went out. That generated another 1,000 people paying $1,000. So we had another million dollars coming in. So we actually spent another two years just making little changes and bug fixes and a few other things. And we finally did one more release, 4.4 Light 2, which was the bug-fixed version of that. But at any rate, it was really the 4.4 BSD light, which was in the genesis of the various BSDs that are out there today. And again, I could go through all that. But I have more than used up my time. But you see, this is where I told you there's all these fascinating stories that I didn't get a chance to tell you, allows me to do my promotion of my DVD. So you can get all three, slightly over three hours of these stories for a mere $20 for the first 10 people that come down and ask for it. Also, you can get it off my website, www.macusick.com. All right, so I have zero time for questions, but I'll take a question anyway. Question time. Anyone first? Just one, was it? Come on, somebody should have at least one. Yep, I'm sure there are nervous people here in your prison. So when you read the classic email fight between Linus and the name was given to you, Tannenbaum, about maltyx and linux. What was the BSD creator take on? By this time, I was actually at the first public speech that Linus ever gave on linux, which at that time, it was really just, it was slightly past being a terminal emulator at that point. Yeah, it was 10,000 lines. Yeah. And so after that, I said, why did you start this thing? Because we've got BSD here. And he said, well, it was all tied up in litigation. Well, that litigation could have gone the other way. And then there would have been nothing. So we had to do something there. And he's never looked back. Any others? All done. All right. On that note, I would like to present you with a lovely macadamia husk bowl. But unfortunately, you would have heard about all the floods and what have you. We actually ran out, but we've still got the boxes. But what you wouldn't know, the floods, continuing on the flood theme, started all the way up north, went all the way south, right to Melbourne. Melbourne guys pretty much flooded out too. It did go further inland as well. So we tried to find something appropriate for you. No, that way up, that way up, that way up. Because that is all that's left of Uluru. Thank Marshall very much.