 Okay, so I called my talk Plan 9, The Better Unix, and I actually jumped in to give this talk now because somebody got sick, and it's a talk I had given before somewhere else, so it's recycled in a way, and I didn't have much time to prepare it, but I think it'll be fine. So I'm going to start with some slides, and then we later see the system in action. So Plan 9 was meant to be the successor to Unix, and it was developed at Bell Labs by mostly the same people who also did Unix. And you can think of it as pretty much Unix plus graphics and network and some improvements like the lessons learned. It was written by mostly Rob Pike and Ken Thompson, who like they did the initial basic system and concepts, and then other people like Dave Prasato, how tricky, Full Winter Bottom and others fleshed out the system and implemented various aspects of it. It started in the 1980s, and by 1992 the first edition was released to universities. Then three years later the second edition was released to more, like to a wider public, but you couldn't use it commercially. Then in 2000 the third edition was released under some open source license, which was not quite what people were happy with, and then 2002 the fourth edition was released under the loose and public license, which was a free license but still incompatible with GPL, and people were still not quite happy with it either. And that was the last release from Bell Labs, and people started because it was not really developed further after that point, at least not so much. So people started forking it or putting in their own improvements, and there were some projects, Nine Atom is no longer, doesn't exist anymore I think, Nine Front is still going and this is like the main place where Plan 9 development still happens I think, and Nine Legacy is like a set of patches on top of the original Bell Labs, Plan 9, to sort of keep the original system running. And then only 2021 the Plan 9 Foundation was founded and the whole code was re-licensed under MIT license. So we start with Unix. The user interface on a Unix system was originally a teletype like you can see here. And there was a very neat hack in the kernel because Unix had this concept of everything as a file and particular devices are represented as files. So there was a file DevTTY, which always refers to the current teletype that one is working on. And this was a hack in the kernel. The kernel knows which TTY a process runs on, like which one it's attached to, and it gives this file, DevTTY, a different meaning depending on which process is opening the file or reading the file or whatever. So you can see there is DevTTY 0 and 1, and these are absolute names, so to speak. They refer to one concrete teletype, but DevTTY always refers to the current one. So if like Dennis here sits down next to Ken, then he will also have a DevTTY, but it's a different one. But that was pretty much a hack in the kernel, yeah. And it was a nice idea, though. In the late, well, maybe in the early 80s, graphics started to happen, and Rob Pike and Bartlo Canty built this Blit terminal, which you can see a photo of here. And it was, well, like a teletype, but graphical, of course, with the keyboard and mouse in the screen. But it was still a terminal, which connected to a Unix machine. The user interface was inspired by Smalltalk and the Perk computer, but the Perk was a workstation. And they took this name Perk, and because they were not very happy with it, they called their version the jerk, but that was not commercially viable, so when AT&T decided to make a product out of it, they called it the Blit. After the BitBlit operation to put pixels on the screen. So this was a terminal, not a workstation. It had to connect to Unix system to do anything useful. But still it needed like a small, tiny operating system on that Blit to do like the windows and the terminal emulation, so to speak. It's not a terminal emulator like we use now, which are essentially like VT100s. These are just windows with text, pretty much, not proper terminals. And it was connected to Unix machine, and this Unix then needed some kind of pseudo TTY files, like we also have with SSH now or something. But previously that didn't exist because you just had the hard copy terminal or video terminal. And the essential idea of this system was that every window, like you have one screen and one mouse and one keyboard, but if you have windows on that screen, it's like you're multiplexing these things and every window just gets its own view of the mouse and its own view of the keyboard. Like when I'm in a different window and I type something, the other windows don't see that. And pretty much everything has the same view of the system. They all have a screen, which is their own window, and a keyboard, which is the keys that they get when the window is active and similar with the mouse. And I could show a demo of this, but I don't know, maybe later, depends on the time. So that was like a very basic operating system. And you still have this distinction between Unix and the terminal. So Rob Pike started writing, well, first of all, they built a second machine, the knot. And it's like an iteration on the Blit design. It's a bit more powerful and so on. And Rob Pike experimented with an operating system for that machine. And there were two main ideas. The one, the first one is that in Unix you have this file tree which looks the same for everyone. Like you go from the root directory and then directory slash directory and so on. And the new idea was that every process could have its own view of the file system. So for instance, the reason that the mount system call in Unix needs root permissions is because it changes the global state of things for everyone. And plan 9 mount is not a privileged thing. Everyone can do it because they only change their own view of the system. And also the file system is not made up of like these persistent files on disk or device files, but anything that looks like a file pretty much. And the kernel can mount different file servers to different parts in the file tree and build up their view, their namespace, like that. And the kernel needs some file servers built in, like for the hardware, for a mouse, for a screen, for maybe a serial or a network connection. And that's it. And that's enough to talk to Unix system, for instance, in this early time it was a Unix system, to mount files on disk, like a Unix file server, like source code, binaries and so on. But at this point, it was still two different systems again. And some of the, like this DevTTY hack was kind of, like the idea was nice, but it was changed, first of all, it's split up now because we have graphics, so DevCons is pretty much the keyboard, DevMouse is the mouse, and BitBlit is, BitBlit and Windows for the graphics. But now the important difference is that previously we had DevTTY, which was a single file which looked differently depending on the process, but DevCons is always a different file, but it always has the same name. So a program just opens DevCons and reads from the keyboard, but it could be the real keyboard, like the hardware keyboard, or it could be the multiplexed keyboard that's connected to a single window only. And the power of the namespace allows for different files to have the same name. And that system evolved and became Plan 9. And by 1990, they were able to use it for productive use. They had the node terminals built from 68K CPUs, CPU servers which ran proper programs like compilers and everything. And that was SGI MIPS based at the time. And the file server was originally on a different machine, on a Unix machine, still running on a Vax. And they had the window system, 8.5, named after the movie. The SAM text editor, which was also graphical, still is. The new shell, the RSC shell, which is also still the shell in Plan 9 today. And a new C compiler and C library. And some kind of POSIX compatibility layer, APE. Yeah, later it was part of two more hardware like Intel, Spark, PowerPC, Alpha, and so on. And the file server still remained a separate thing early on, like a separate kernel, but it became a user space program later. So now let's take a look at the system calls. These are around 40 system calls compared to Linux with 450, and Windows NT4 with around 200, and then 500 more photographic stuff that went into the kernel at some point. This is pretty minimal. And we have pretty much standard system calls to deal with processes, with memory, with a file system, files, nodes, which is the Plan 9 equivalent to signals, and some of ours, which were actually later, if I'm not mistaken, for synchronization. Rend, rendezvous is the preferred way, I think, to do synchronization stuff. And notice there are pretty much two. Do I have a slide for this? Yeah, notice there is no iOctols, and also no sockets, or network, no graphics. This is all done through the file system. Yeah, the main differences to Unix, like these are almost what you would expect from a standard Unix system, but there are a few differences. Our fork is the first one, Unix has fork, and our fork is more powerful, as we will see. And there is bind, which is new, and yeah, mount has some changed semantics, but it's pretty much these three that are the difference. So bind takes one file, or one name. Well, as I explained, I don't know why it's called old, but you take a name that exists already on the system, and you give it a new name, and then it's also available under that name. And with a flag, you can, there's like, you have an order, like you can bind before, or you can bind after, because you can mount multiple things to the same name. And this is useful, for instance, for having binaries in different directories, and Unix has this path variable in the shell for this, and it will look up every directory until it finds the binary. And on plan nine, you can just use the file system for it. You just bind all the locations that you have your binaries in, you bind them under a slash bin, and then everything is visible under a slash bin, and you don't need any path variable anymore. And this is called a union bind, because you see everything that you bound to this location. That's what bind does. Something fun you can do is if you have a different system mounted over the network, or, well, you have access to the file system of a different machine, you can use that slash net directory of the other machine and bind it over your own slash net, and then you're using the network of that other machine. And this is sort of like a VPN. And it's just one line in plan nine, well, like a shell command, and you get some really fancy stuff. Do you have a question? Yeah, if that's like an empty file or something, then you can hide it, yes. And mount, it sort of works like Unix mount, where you give a device file to it, and then you mount it into some directory, but in this case it's not a device file, but it's a file descriptor that speaks the 9p protocol, which is the file protocol that's spread all over plan nine. And you can do authentication as well over the A file descriptor, but that's not so interesting for us right now, I think. So one example is you mount a Rio, which is the window system. There is a file that it serves, which speaks 9p, and you can mount that server under, for instance, mount foo, and you give it an argument, that's the A name in the call, and if that's new, it will create a new window, and you will have it available under mount foo, so a window has multiple files, we'll see that later. Actually, I think we can just try it out now. This is just the normal way to make a window, and we can go to here, and let's say mount serve mount foo new, and here I have my window, and now if I go to mount foo, I see all the files that are associated with that window, and now I can say something like, hello VCFB, and it will display in the window, and if I mount this con, well, I'm not going to experiment now, but I could take over the window, I just start a shell, which connects its standard input and output to this con's file of that new window, and it will run in that window. Okay, so the idea is bind copy something to another place, something that already exists, mount add something new to the namespace, and unmount removes that, and I can check all the, I can check how my namespace was constructed with the NS command, which is like LSPS, and this is NS, so you can see the, where is it? So these hash thingies are kernel devices, so the kernel knows about those directly, so hash C is the device directory, and hash D is for file descriptors and so on, and these have pretty fancy characters in some cases. No, C is not the, C is the, sorry, C is the con's device, so this is like the keyboard, and we can actually just take a look at what hash C is. So this is what hash C gives us, and if I check out the whole, I get more, and also notice that because it's a union mount, the same name appears multiple times, but you only get the last one, the latest one, you can't access the previous ones, and that's why there are these before and after arguments, so you can control in which order your namespace is constructed. Okay, now let's check out our fork. So Unix fork just copies the process completely with all resources like file descriptors, and it just creates a new process, and our fork allows for more granularity, so you can give it flags, what to fork, so you can fork a process, and this is what would normally be called a thread, so it's a different thread of execution, you can also fork memory, this would turn a thread in the same program and give it a different memory map, so this would split the process, split the threads into what would be called processes in normal, using normal usual terms. You can fork the namespace, so processes can share namespaces or they can be in separate namespaces, environment for environment variables, nodes, as I said, like signals and Unix, they will be in different signal groups and so on, file descriptors and rendezvous groups as well, so these are more plan 9 specific, but this process and memory thing is more general than what you have in Mac or NTE, where you have just this distinction between threads and processes, in plan 9 this is all kind of the same thing, you just give fork different flags what to fork. So this is pretty powerful. I'm not sure, I don't think it's about resource usage. I wouldn't say that. Yeah, I think it's just, it's like reflecting on fork. Okay, what does fork do? It forks the process and I get two processes, but I have more stuff that maybe I want to keep some part of it and maybe I want to split fork another part and this is just an implementation of that. I don't think it's necessarily about resource usage or anything like that. So the way that 9p works is we have these pretty much equivalents to the standard Unix system calls for files, like walk for instance, walks down a file tree and opens a file, creates a file and so on. And these are just, these are functions that every device in the kernel has to implement to work as a file server. And there is one device called dev mount and this device translates these function calls in the kernel to RPCs, so to the 9p protocol, so you can speak it over files, over a network and so on. And this is what allows the kernel to mount any program that speaks that 9p protocol into a namespace. Like you can mount it from the kernel, the kernel is the client of that 9p server. Yeah, and 9p just has an equivalent for pretty much each of these. It's not an exact match, I think, but it's pretty close. And there is a T and R version of everything, so you have a request and then a reply to everything, except for error, there's only, you can't request an error, just reply with an error. And there's a library written in C, Lib 9p, where you take these messages, like the encoded version of the RPC, and it turns it back into functions, so you have a nice interface you can use with it. These are some of the file servers that the kernel provides, and I picked a really bad font because L, pipe and I look almost identical. But yeah, so you have the IP, for instance, you can see that. Here all the network stuff is here, so you have Ethernet, that was the hash L thing, L stands for LANs, by the way. And you have TCP, and to open a network connection, you would just open this clone file, and then you get one of these, so every one of these directories here with the numbers, represents one TCP connection. So you open the clone file, and it will create a new directory, like not literally create a directory on disk, but it's visible in the file tree as a directory, and then you write some connection message to the file that you get, or you listen or whatever, like TCP connection stuff. And then you get a file, and you can read and write it, and it just looks like a file, but it's a network connection. Yeah, the slash proc file system, for instance, is also one. Plan 9 wasn't the first, some version of Unix at Bell Labs also had it, and Linux actually, I don't know, Linux took it from Unix or from Plan 9, I suspect from Plan 9, but I can go to some process, and I will have all sorts of files to deal with it. Yeah, but this should be mostly familiar from Linux actually, because that part of Linux was inspired by Plan 9. Okay, so I already gave a quick overview of the versions, but also like a little changelog maybe. So the second edition introduced a new text editor that is actually kind of popular now, not super popular, but Acme, and it's inspired by Oberon, actually. So first of all, the user interface is very mouse driven on Plan 9. This was because it's inspired by Smalltalk and the Blit, and it hasn't really changed much since the Blit days in the 80s, it still behaves quite similar. But I have a file listing here, and if I do a right click on this directory, it will just open this directory and give me the... There's some beeping noise here, it's really irritating. It will open the directory and show me the files, so I don't know, I have some PDP11 emulator here, and then I can open some file, I don't know, and with the middle mouse button I can drag panes around and I can scroll, and the text you see up here is to control the window, so by middle click on Dell, for instance, it will delete, but the text is not some hard coded button, but if I can write Dell anywhere, and I can write my own Dell and then click that, and it works too, and I can write, I don't know, I can write new here, and I get a new window, so that's kind of neat, and it has a lot of funny features, and it's definitely worth checking that out. It's quite interesting as an editor, so that was new in the second edition. Asset is the debugger. The third edition redid the whole graphics part, actually. The original one was still inspired by the Blit, and it was only bitmap graphics, black and white, and for the third edition they redid the whole thing, first of all in color, and the semantics changed quite a bit as well. I don't know if I can get into that, but I don't think I have anything about that. But the old Windows system essentially re-implemented this drawing file completely. How do you explain that? It's quite hard. So the BitBlit protocol was used to draw on the screen, and the Windows system implemented that whole BitBlit protocol just for a single window. So the program running in the window has absolutely no idea that it's not running full screen. It just sees Dev BitBlit and uses that to draw pixels, but the Windows system had to re-implement that whole protocol for every window. And because you can do things recursively, like I can run Rio in this window and I get a new Windows system, and I can hide this and so on, because that was kind of inefficient, DevDraw actually handles the window multiplexing, and the Windows system kind of manages these. The neat transparent way the Windows system worked was, well, given up to some degree for efficiency, but it's still nice enough. The plumber is very interesting as well. So let's see. Actually, let's kill that. Oops, that was the big Windows system. I'm going to re-log in again. The exit button didn't used to be there, it's new. It takes a while because over the network it binds my own local directory. Actually, that's something I can show. So Draw Term is a program that's quite interesting because it provides these kernel files. It's kind of a little Player 9 kernel that has these device files, and it logs into my machine at home, exports its own file system to that machine, and there it runs the Windows system, and it just opens DevCon, DevDraw, whatever, like it usually does, but it really files on my laptop that it's opening, and it doesn't know, and in SlashMound term I have my local laptop. So I can deal with all my files that I have on my laptop from the machine at home running Player 9 because it just exports the file system back home. And running Rio just opens the files and starts things. And the plumber, I wanted to get to the plumber really, so actually let's go to maybe the kernel. So I don't know, some interesting file. Maybe this one, I can click on this, like put my cursor on this file and say Plum, and it will know what to do. It will open a text editor. There's not Acme, there's a Sam, but it will open the file in a new text editor, and I can do the same thing here, and it will reuse the text editor that already exists. So that's quite neat, and you can also do, I don't know, if we grab for something, I don't know, I just see Lock here on the screen. That's enough. I can do something like this, Plum, and it will actually go to the file number that I... You can give patterns to this plumber and it understands what to do with those patterns and kind of does the right thing. You can also use it to open PDF files or whatever. You just click on the thing and say Plum, and it will just send it somewhere that knows how to handle it, and that's pretty neat. So the fourth edition had Factotum, which is like the... It's all about authentication and cryptography and so on. It handles all these protocols, and programs don't really have to implement anything of that themselves. They just talk to Factotum and they forward all the messages, and Factotum will do it. Fossil and Venti was a... Or is a file system. Fossil is for... It's kind of like a cache for Venti. Venti is for archiving. It's a append-only thing. But in Ninfront, those were removed because they were quite buggy at the time, and the old file server was kind of resurrected, so that is CWFS, HJFS. Ninfront got a new USB stack, a new security like keeks change protocol, because the other one was insecure, a new CPU. So CPU is like a remote login, a new CPU thing. VMX is for virtualization, so you can actually run like OpenBSD and Plan9 as well. Lots of device drivers and many smaller fixes and improvements and so on. And as I said, Nine Legacy is like a patch set for the fourth edition. A lot of it came from Ninfront. Okay, so why didn't Plan9... Why didn't it really succeed? So compared to other operating systems, Windows had a lot of weight, like Windows NT had a lot of weight, because Windows 3.1 was very popular and people spread very quickly and it was just a very big operating system. Unix had been around for a very long time and people had gotten used to it and depended on the exact semantics of the operating system and so on. Linux was probably successful because of the way that the development process worked, the free software style, and it also succeeded due to Unix being a re-implementation of Unix. But what had Plan9 going for it? Good question. I mean, it's really nice, but maybe that just wasn't enough. And it was a research system, not a product, and the license situation was not really great until maybe 2000 or something, which was really late. So it didn't have a lot of early adoption and not too many people contributing to it. And as a result of that, many things that we consider that we just expect to be there just aren't there, like C++ or a modern web browser, so that might be a problem. But on the other side, the system is relatively pure and small and easy to grasp. But the other problem is that Plan9 was meant to... You have the whole... You have the network as the system. You don't have these monolithic Unix machines where you log in with terminals, but you build your whole system out of CPU servers, file servers, terminal machines, and so on. And that kind of didn't... Like, it doesn't really fit with how we work with computers today, I guess. But the good things... It's like a... Yeah, it's a nice iteration on Unix. Many thoughts that went into Unix were really kind of polished in Plan9, like thought through to the end. Private namespaces are nice for various purposes. 9p is a very nice, easy protocol to talk over files, and it's also used elsewhere, not only in Plan9. I think QMU uses it. It has very nice abstractions compared to other operating systems, I think. Again, everything is a file, but this time a bit more than in Unix. Programs can really work together well on Plan9. There's a pipe idea where you pipe the output of one program to the input of the next. And in Plan9, this character even has a stronger character like this. The code is pretty simple compared to, I don't know, Linux is huge, Plan9 is pretty small. You can compile the whole system in, like, five minutes on a reasonably fast machine, like kernel, user space, everything takes maybe five or ten minutes. You can pretty much understand the whole system from, like, the boot process to, I don't know, whatever. And you can learn a lot from it. And there's still quite a lot of low-hanging fruit, I think, to things to improve, things to add to it. And of course it's fun. There's some legacy. UTF-8 was originally invented for Plan9. I think Ken Thompson converted the whole system to Plan9 and the whole Plan9 system to UTF-8 in, like, a night or something after inventing UTF-8. The slash proc file system, you know it from Linux. It came from Plan9, or earlier Unix, actually. You have something like, you have user space file systems on Linux as well. It's called Fuse there. Maybe inspired by 9P, I don't know. Private namespaces in Linux do exist, but they're not really the same. They're meant to be, like, they're meant to cage you in to have, like, separation of processes. And in Plan9 you have, like, it's a different idea. The reason for them being in the system is different. The Go programming language was done by pretty much the same people. Rob Pike and Thompson, Roscox originally did Plan9 and then used the Plan9 C compiler to bootstrap Go. And there is a user space port of a lot of the Plan9 stuff to Unix, and it was done by Roscox. And here are some links. There's a demo of the Blit, which is quite famous. Maybe you've seen it. Plan9 validation, old Bell Labs website. 9front9 legacy, and there's a lot of Unix on Plan9 related stuff on catv.org. I only have five more minutes, I think. But I already showed some demos, so I don't know if you want to see anything else, or if you have questions. Maybe that's the time for it now, yes. If I read from a file, it's just like on a normal Unix systems, or does the user space process have to speak 9p as a client? No, no, 9p is handled, like the client part of 9p is handled in the kernel. And if you have an open, like open and read system calls, this will go to the mount device in the kernel, and the mount device will generate the 9p messages and write them to the file or read them from the file. And the file server runs in user space. So there you actually have to implement a protocol yourself. But there's a library which facilitates it. There's still some work to do, but it's not so hard. You can write a simple demo file server, like some simple functionality in, I don't know, maybe 100 or 200 lines of code. How many lines of code does the system have? Oh, let's see. You mean everything or just the kernel? Well, everything would be more interesting. I don't know if I can easily do that. No. I don't know, but I think I can probably, oops, I can tell you the kernel. So the portable part of the kernel is 70,000 lines. And the device drivers for, like, standard PC stuff is a bit more, but still under 200,000 lines total for the whole kernel. And then the user space, yeah, it depends. I mean, we have ghost script for PDFs and post script, and that's, like, the main bulk of the system. Like, I don't know, 50% of the system is just ghost script. You said at some point that the licensing situation was a bit complicated, and I would like to know what the intention was, what Bell Labs thought they would be producing. I think Bell Labs did not have any experience with open source or free software. I mean, the licensing situation with Unix was also complicated already, and they were just very cautious and didn't want people to use their stuff too much, I guess. They wanted to kind of make a profit or, I don't know, I can't say, but I think the way that the Unix situation played out was kind of similar, and they were just very restrictive at that time. Oh, there is a fun story. Ken actually wanted to include a lot of his music collection on the Plan 9 CDs in a new file format that they developed at Bell Labs, but the Law Department at Bell Labs said nope. So we didn't get the music. Okay, that seems to be all. Okay, thank you.