 Does it sound all right? Yeah, OK. I guess so. OK, lots of people. I guess RMS didn't sing the Free Software song. I was a bit afraid that everybody would run away. But sorry about that. There were some problems with this. I don't have network yet. They have gone through for a network cable. So I can demo some of the distributed stuff. Let me start the presentation. Can you bring me the other mouse? This one doesn't work. Well, anyway. I can use the built-in one, but it just sucks. Sorry, I'm a bit nervous. OK, it works. Well, I'm going to talk about plan 9. I guess most of you already know what plan 9 is. But I'm going to give a short introduction first. And well, first of all, talk about what most people ask about plan 9, which is, well, it's plan 9 open source. Because for many years, it was not open source. And it was not free software, whatever your political tendency is. Well, yes, plan 9 and Inferno, which I will not speak about today. But it's also closely related to plan 9, are open source. And they are free software. A few years ago, the license was changed. RMS, which I think is not around anymore, said that then it was all right. The open source initiative said that it was all right. And the Debian project actually packages some of the Debian source code. So it's also free, according to the Debian free software guidelines. We in plan 9 don't like to talk about licenses. Well, we only prefer to talk about code and about technical stuff. So after so many years, people is a bit sensible. But, well, I hope everybody should be happy to know that it's under a free software license. OK, this, I guess, is the most important of the whole presentation. Jim Thuinsky asked once, what's the most important thing about a project? So I think we have a pretty good answer for plan 9. Well, I guess I think it's a very cute basket. I don't know what other people agree. But I think it's much better than a fat penguin or some sort of demon or something. I hope people find it useful. OK, some history. Plan 9 was started in the mid-80s by the same people that did UNIX in the 70s and 60s. Well, late 60s. And that's another common question people say. So it's plan 9 finished. Can people use it? Well, in Bell Labs, it has been used since 1980. And since 1989, in a production environment by quite a few hundreds of people, the problem is that they are pretty quiet about it. They use it. And, yeah, well, it has been used since then. And today, it's also used. Other organizations use it, too. It's used at Los Alamos National Laboratory. They use it for clustering and so on. It's used at various universities. And, well, some small companies use it, too. Plan 9 has had four public releases, major releases. They are not very common. But, well, the first one was in 93, but only to universities. Then the second edition was still preparatory in 95. And you had to pay for it. And then in 2000 was the first source code release. And then it was, in 2002, was under this new open source license, which was accepted for everybody. There is also Inferno, which is sort of the system from Plan 9. Inferno is quite different. But it uses some of the same ideas. And they have many things in common. And they use the same technologies. I will not speak very much of Inferno, but I think people should also look into it. It's also open source. It's under a GPL and MIT license. And it's very interesting. It also uses a different language. It's not in C. Well, parts of it is quite in C, but it uses the limbo programming language, which is rather interesting. OK, what about Plan 9 today? Well, most people think it's dead. I have heard many people say it. But it's not really. I mean, every day there is changes to the source tree. And the ISO that you can install and boot from, it's not only an installer. You can also boot it without installing it in your hard disk directly. It's rebuilt every day from the latest sources. So you can go to nyanfans.net. And there you can download it. It's 80 megabytes compressed. Well, I think if you compare with some recent Linux distributions that are like a few DVDs or something, I think there's a small size difference. And then there is a system to retrieve updates to your running system to update your source code directly from what it's called sources. Sources is the main repository of the source code at Bell Labs. And any user can send patches using a patch management system called patch, slightly confusing with the Unix patch. There's many things in Plan 9 that are somewhat confusing because they have nothing to do. So you can create patches and you can send them into the queue and somebody will look at them and say, oh, this is all right, and put it into the main system or not. And then there is N-Sources Country, which is if you write something for Plan 9 but doesn't fit into the main distribution or you port some software or whatever, anybody can get a directory there and put any random code that you can come up with. And you can find also lots of contributed documentation and contributed programs and so on. So that's also interesting. OK, some more older background. I guess everybody knows about Multics, but I wonder, I guess nobody has ever used it here. Not me either. Well, because it was a great system, but it was a bit too complicated. So in the late 60s, Multics was started and was going to be the next big operating system that was going to be useful for everything and it was going to be able to do everything and so on. But, well, it became too big, too complex, and in the end just failed completely. Ken Thompson and Dennis Ritchie, which were at Bell Labs at the time, were part of the project and, well, when they failed, they had nothing to do. So they went to play with a PDP7 and, well, we everybody knows what happened next. Unix was born. But what was different from Unix to Multics? They all had lots of things in common. But they had a big difference that Unix was much, much simpler than Multics. Unix took some of the ideas of Multics. Almost all the concepts that you can find in Unix, you could find them in Multics, like a hierarchical file system, like even pipes existed. If I remember correctly, in some form of fail, but I think it was called data channels, they existed in Multics. But the problem is that to do what you do in a single line, like a cat full, piping to grep, piping to sort, you had to write like 10 lines of code that set up the channel and then used it. And the programs had to be especially designed to talk to each other and so on. So Unix came up with a much simpler and cleaner way to do it. And, well, and then there is the idea of one program to do one thing well, which actually that was pretty new in Unix. And text as a universal language. Text everywhere. All applications speak text. They print text, and they understand input as text. And that way, all programs can talk together. And if they sign to originally to work together, that there's lots of ways you could build powerful combinations. And, well, that was pretty new at the time, writing in a high level language. All these Unix had in 1970s. But today, Unix has some of these things, but others are a bit lost. It's too old to do one thing well. I mean, it's like you have networking into Bash and that kind of really useful features. And then you have networking built into Alk and networking built into Cat. Oh, no, I think GNU or Cat doesn't have that yet. Maybe. I don't keep track of all the dash, dash, blah, blah, blah options. Maybe in the main page. Oh, no, in the info page, sorry. So what are the problems? I mean, many of these things are still true, but it has not changed very much. So why was Plan 9 started? By the same people that created Unix. Well, during the 80s, well, Unix started to grow and grow and get more complex. So it was not simple anymore. And also it started to like the people in California doing LSD, they started to add like sockets and a bunch of other stuff like that. So that started to make problems. And the thing is that Unix was not designed to work in a network time environment. Unix was designed as a time sharing system where all the users were in a single system and where all the resources were in a single place. And you access them more or less in the same way, but in a centralized place. And it was not designed for graphics either, and it was not designed for lots of things that have happened in the last 30 years. But lots of people just went and attached them on the side of Unix. Well, maybe with quite a bit of thought, but without following the Unix principles. So, and still, well, in Unix, things don't work as well as they could. And there is lots of accumulated stuff. I will talk a bit about what the stuff has accumulated in Unix, which the people that developed Unix thought it was time to get rid of. And the most important with all these people adding a stuff is that it was a loss of conceptual integrity. This is something that Fred Brooks wrote about in a mythical man month, which I hope everybody has read. It's one of the most important computer science books. And conceptual integrity of a system is very important because it's what it makes it consistent and what makes all the parts of the system possible to understand and what you know with one part of the system be possible to apply to another part of the system. And in Unix, that has been lost by adding all these things from other systems and all these hacks to adapt it to the network and to other new things. So Unix is not very simple anymore. And well, if you just look at the GCC man page or something like that, you will notice that it has got a bit complicated. So here's a list of things that Plan 9 does not have. This is very important because, well, it's important, I think, that people don't get wrong expectations. Plan 9 is similar to Unix in many ways. It was developed by the same people at the same place. But it's not the same as people expect today of Unix. All these things, we don't have them. And we don't have them because, in our opinion, we don't need them. I will explain later. Well, there is things like RootWitch and SUED, which, well, maybe at the time seemed like a really great idea, but today is a security nightmare. TTI courses, things designed for an era of hard copy terminals and things like that. IOCTL, a horrible hack to be able to fit all kinds of stuff through a single device file. Sockets, well, sockets, well, they work, but they don't fit into the Unix model of files and so on. They have a pretty weird interface, compared with the kind of interfaces in other previous Unix systems. Select and pull anybody that knows a bit about their implementation in the kernel. They are pretty messed up. And SimLinks and other, they destroy the semantics. The simple, the originally really simple file system semantics with SimLinks sort of go to hell and solve problems. Well, anyway, I could go on talking about lots of them for quite a while. Well, C++, if you like C++, fine. Maybe you have an IQ of 10 hundred or something, but I don't think I know anybody that understands C++. So it doesn't follow very much the Unix philosophy of simplicity and so on. Actually, some of these things, there are. You can have them in Plan 9, but don't expect them, because, well, maybe somebody poured the GCC because they really needed somebody at Bell Labs some years ago, poured the GCC, because they needed a C++ application to run for some scientific project or whatever. And they poured it, but, well, I have never heard of anybody else using it. And this guy that did the poured died. So, well, I don't know if there is a connection between people in Plan 9 not liking C++, but well. I never heard of anybody else using it. So, that will give you an idea. MX and VI, well, we have other kinds of text editors. They have never been very popular. X11, XML, well, I think these days Unix people likes very much MacaSex. I really cannot believe it. I mean, it's like they're in the script, start writing an XML, what were they thinking? And, well, I had put originally Boost Word, Complan, but, well, web 2.0 seems to be the fashion word this week. So, no, we don't have web 2.0 or anything like that, and we will never have, so don't worry about that. Well, if you like it, I'm sorry. So, Plan 9 is a completely new system. That's something that it's very uncommon. There are very few systems in the last 30 years that are completely new. Everything, the kernel, the compilers, the libraries, the user interface. I mean, you see people working in whatever project and they use like, oh, well, we use GCC because, well, writing an new compiler is lots of work. Yeah, but GCC is not that great either, especially if you ask some of the BSD people, they are not all that happy and, well, it's really fun when it produces broken code and then you have to figure out if it's a bug in your program or it's just that you hit the wrong optimization flags. There is a, I think there's a sport based on this, it's called GEN2 or something. Well, we really rather spend the time doing all the things. So, GEN2, the Plan 9 compilers and they are, well, we like them, they are nice. New user interface, also designed to fit together with the new technologies and new input devices and new display devices and back to have some consistency in the system, some way to all the pieces, all these different pieces to be thought to work together rather than just be smashed together and taken from there or whatever. So, it's back to, in a way, it's back to the Unix routes and many things that are in Plan 9, they are almost the same as in the original Unix and they are different with current Unixes and it's because, well, many people thought that, well, the way they are done today is not that great or it's maybe too complex. So, when you look at Plan 9, don't think of it as another Unix because then you will get disappointed. You will expect things to work in a way and you will not find that. You will not find BI, you will not find all the GCC options and you will not find a million of things that are not there but it's because they are not supposed to be there because, well, it was designed to work in a different way. It's not that, well, if other people like them, fine but Plan 9 is about solving these problems in a different way. So, what are Plan 9? Take three ideas and build a whole system on top of them. They are slightly based on the ideas of Unix. The idea of everything is a file. In Unix everything was a file except, well, some files were slightly different to special like device files or SIM links or and so on. So, now in Plan 9, all the files are exactly the same and all the files, you can make the same operations of them. No IOCTL, no backdoors into the brain of the kernel used through a file or whatever. No, it has to explicitly read, cry, open, remove, that's it. So, and actually many things are thought more as a file tree than as a single file because it makes it quite hard if you have to fit a whole device through a single file that's why you have IOCTL because just reading right in a single file doesn't give you the range of operations that you want to make in a complex device like a screen or like almost anything actually. So, that's the idea that things are a file tree and you can have different files that give you a total interface to all the workings of the interface you want to export but all the components are files and all the components work as files and all the files work the same and have the same operations. Then, we take these files and we have a file system protocol that works transparently over the network and very simple protocol to do these kinds of operations that we have defined for files and that works both locally, remotely and for all these files. This is the NNP protocol and that's what gives you the network transparency to all resources, not used to the ones that are designed to have a specific protocol and locally you access the resources over NNP, remotely you access the resources over NNP, everywhere you use NNP to access the different resources. And once you have these two things, you have a third thing that puts the whole idea together which is the privet name spaces. This is something that some people has had a bit of a problem getting their mind around which is a bit, because it works pretty different from all our systems. Priced name spaces, every process can, not necessarily they can share a name space but every process has its own view of all these resources because if you have a huge network or a set of networks, you cannot impose the same view on every user because they are not interested in seeing everything, maybe they're interested in mounting the API stack from the firewall but they are not interested on mounting the graphics from the firewall which is not a very powerful machine or something. So the privet name space not only gives it at the machine level but also at the process level. That gives you security and that gives you, it has lots of advantages. We will see it later, but it lets you work. You can have a window with a view of network and you can have another window with another view and it's used everywhere by providing these different name spaces to different applications. Another of the main reasons is that there is lots of conventions. Applications expect to find the keyboard in its last day of cons but that can come from one place or another and sometimes you want it to come from one place, sometimes you want it to come to another but you don't want all the applications to see the same keyboard. You want it to be able to be different. It's okay, connecting with that. What resources are file systems? Well, almost everything except fork and memory allocation, everything else basically probably means something but anyway, networking, authentication, encryption, graphics, Windows system, process control, it's also done through the file system. There is a proc file system in many unixes but in plan nine is the only way to do process control. If you want to kill a process, you have to write keel into the control file for that process. That would use a lot of the complexity and the number of syscalls that you have to have. Ember environment is also a file system, a mail file system which passes a mailbox and gives you a hierarchical view. That simplifies very much the writing of, for example, mail clients because it handles all the mime crap and so on. So mail client gets very simplified. Then boring stuff that you can see in some other systems like a CD file system, web file system, tower file system, FTP file system. Well, CD file system is somewhat interesting because if you want to burn a CD, you just copy the file into the right directory and they get burned there. So that's somewhat different. And it's like this horrible drag and drop, whatever, but you can do it in the unix way, use CP instead of having a huge interface on top of it to do it. Okay, the nine P protocol. This is the protocol that links everything together. It's a very lightweight compared with other network protocols like NFS. Oh, I forgot to AFS, under FS, but well, I think it's pretty complicated having in mind that use for authentication includes like care bearers just into the implementation or something like that. I don't know. Anyway, it's much, much simpler than all these other file systems, network file systems. Only 13 messages, byte oriented, can run over any transport. It has been implemented over all these and a few more. TCP IL is a transport on top of IP that was developed especially for plan nine. At Bell Labs, it's used only in local networks because to reduce even lower overhead than TCP for new connections and so on. But it doesn't do the fancy stuff that TCP do. So it works great for local networks, not for over the net, but you can, that's another thing which I will show later. It doesn't really matter which of these transports you use because it's going to work the same. All the applications are not going to notice anything. So it's good to have different options. And that is used for local remote synthetic and physical files, all files. You don't need, it's like anybody that has tried to do a net boot setup in Unix. Well, it can be made to work, but it's a bit of a pain in plan nine because all these are the same local and remote. It just works. Authentication and encryption. Also, not built into the protocol, but the protocol design to handle any form of authentication. So you can use any authentication system. I will talk a little bit about that later and encryption. Also, the applications don't have to care how you are encrypting and how you are authenticating the connection. And the sign for caching and stacking. So you can stack different file system on top of another and so you can have cache of the file system. Okay, let's see what. I'm sorry, maybe I'm talking a bit too fast. Okay, dynamic spaces. There is three operations to handle dynamic spaces. Yeah, well, once you get used to proving dynamic spaces, it really feels really natural and it feels very awkward to have to, when you do a mount and you ever write something else where that everybody gets to see it and well, that's sometimes not a problem, but sometimes it is. But it's more annoying that you cannot customize your view of the system to whatever you find convenient right now and then in any way you would like. I think actually in Linux, they have implemented a form of prepaid dynamic spaces but they have a problem that if they let users change and mount the stuff, well, all these two idea stuff breaks because you could mount something in a slash ATC and then put on a different password file and then run su and it will be really happy. That's a big problem, but well, because we don't have root and su ID, we don't care. In plan nine is everything designed to be able to customize your dynamic space and actually makes things much more secure because if you cannot see it, you cannot touch it. So, and because all resources are files, if you have a prepaid dynamic space and you mount your passwords there, nobody's going to be able to see it in any way whatsoever, no matter what they do. So there is three main file system, NAMM space operations, bind. Bind takes one path and throws it in another. It's used mostly for union file systems but also it's used for a lot, but it lets you, that's mostly for customizing because it doesn't add anything to your existing NAMM space but makes visible a file in a different point from where it was before. You couldn't think of it as a sim link but it's not in the file system. The file system doesn't know anything at all about bind and it's also not permanent. It's only associated with the NAMM space. That has a set of advantages but I will not get to it now. Mount is what lets you add stuff into your NAMM space. You take a file descriptor, a file descriptor over which you talk NAMP and say where you want that file descriptor. The NAMP connection is going to open into a whole file tree, right? So you mount it somewhere and in that place in your NAMM space, all these tree will show up. Okay, then there is a feed and a name which is what it's used for authentication. That I will explain a little bit later but it's a bit more complicated but the thing is that mount, if you don't want authentication, you just pass minus one as the authentication file descriptor and you're all right but usually the application doesn't care. I will explain a bit later. And then un-mount. Here there's a big difference. They added an N so you always should remember it's not un-mount, it's un-mount. And well, that just removes something from your NAMM space that you changed before. Okay, let's see if I can demo something. If somebody can bring me a mouse that works, it will be really nice. USB mouse? Oh, I left mine up there and the planning people, they are not very friendly. So just if you get into the planning community, you have to be aware of this. We are a bit nasty. So well, you see, thank you very much. Let's see. Oh, well, thank you. Okay. Okay, thank you. By the way, I don't know how much time I have. Let's see. 20 minutes, okay, thank you. Let's see. What's wrong with this mouse? Sorry. Okay. Okay, well, the USB doesn't want to, the USB mouse doesn't want to work. I don't know why. Anyway, I can use this stupid built-in one. That's a problem with Plan 9 also. It's designed to use a mouse. That's a very big difference from Unix and many old Unix people because, yeah, you have to use a mouse. I will try to show it with the built-in mouse. It's still quite useful. Okay, this is the source code for my slides, of course, in Truff. And what was, what I was going to show? Okay. Well, here you are also seeing the blooming system, which is not a string anywhere. You can bloom it by right-clicking it in Acme. Acme is this text editor in development environment and it will do something supposedly smart with it and in which case this is a source file. It will just open it in the text editor. Here's an example of using mount. This is how you open a new window in the window system. What you do is you have an Ember Ryan variable which defines where you can find the window system running and you mount the file descriptor. Well, here it just checks for it, otherwise it does the default and so on. But, well, this is the line that matters. It mounts into a slash deb, a new instance, a new attach. Same file system is exported over 9p, can be attached many times. In the case of the window system, for example, it exports a new window. Every time you attach, it creates a new window and you can play around with it. Let me see if I can see this. Yeah, for example, if we, if I open a new terminal here and mount the slash n will automatically create end points dynamically and new, okay? It creates a new window, but it's an empty window because no process is running in it, okay? But instead of the default to create a new window, as you saw before, which is to mount it in this last deb, this time I mounted it into end foo. So here you can see the file system exported by this window here or the file system that controls this window here. So if I write into cons, it will show up there. I can also do, erst is the shell and like this and I do ls, it will display in the other place because now the input of this is connected to the shell here. Okay, you can do a bunch of cool stuff like that. But what this shows you is that when you attach, it creates a new file tree and you can put it anywhere you like and that's how you talk and manipulate this file. And I think, okay, I'll know we can delete them and we can go back here. Okay, well, sorry if this was not a very good demo, but anyway. When you mount, you have three options, which is you can mount overriding the previous mount point so what was there just goes away and disappears or you can mount before or after what it's already there. That creates union mount points which are slightly or considerably different from BSD mount points, union mounts, aside from everybody can do them. And the first, if you mount it before, then the files will show up first so if you try to open a file, it will go through the stack of mounted file system and set that mount point and pick up the first one with that name. Then there's an extra flag, which if you set in the first file system mounted there, which has this M28 mount flag, new files will get created there. That's pretty useful, for example, if you want to compile something in a directory where you don't have permissions for, you bind your slash TMP into that directory and give it a create flag and then you do MK and use builds. Oh, okay, another. To see another thing that it's used for is if I do NS, this plays my current name space in this window. And if I do NS, grab bin, you will see here that I have a bunch of stuff of different stuff bind under a slash bin. In plan nine, there is no path. Well, there is, but it's not used really. Everything, all the executables are bound into a slash bin so you can always find them there. The only thing is that they are mounted there dynamically into a union mount. The advantage, why do you do this? Because if you connect to a different server, it will change dynamic space by, instead of here it says 386, here this is the 386 binner binaries, else is the shell, this is the shell scripts, they're always there. But the 386 stuff will be replaced by whatever other architecture. So you can execute commands remotely, even if they are, even if you are connecting to a different architecture computer, because it will pick up the right binaries for that architecture. Okay, the kernel. Well, I was trying to check yesterday how many IOCTLs the Linux kernel has. I could not figure out, I don't think anybody knows. But the last number I found, which was from one dot something, was over 400. I guess there are quite a few more now. Well, it has over 300 syscalls and well, a few lines of code. And other Unix systems like Solaris or maybe I think the Detroit, Detroit's guy is coming after me, has a few more. In plan nine, we only have 37 syscalls. And for example, there is nothing related to networking, which is rather peculiar. If you have in mind it's a distributed system and that everything can work over the network. But precisely because there are no syscalls related to it, it means that everything can go over the network. And no IOCTL. And well, a little less code. Of course, the compression is not fair because drivers and so on. But we got quite a few drivers and a number of architectures is a few less, but we support quite a few architectures too. And the portion also between drivers and generic code is more or less similar. So I think it's a good compression. There has an optional real-time scheduler, microkernel or monolithic kernel. Everybody ask, oh, is plan nine a monolithic kernel? Microkernel, well, I thought the fashion for microkernels finished in the early 90s. But no, these people never dies. They never go away. They always wonder microkernels. I think they knew hard people. How long have been edited? They never give up. Well, okay, fine. They have fun. Good. Well, it's planning a microkernel. Well, I know a microkernel sellout which thinks it's a microkernel. Well, I don't know and I don't care. In plan nine, everything are file systems and file systems can be in user space. So you can have money drivers in user space, but not all because in some cases it just makes more sense to put it in the kernel because it makes things so much easier. The IPS tag, for example, has been both inside and outside the kernel and has moved as people has found it convenient. The applications don't care because it's just a file system and they are going to talk to it in the same way, no matter if it's in the kernel, outside the kernel, in the other side of the world, it's always going to talk to it through 9P. So the concept of microkernel in plan nine doesn't make that much sense. I mean, in my opinion, it's a monolithic kernel because most of the drivers are in the kernel, but well, it's because they are much easier to write in the kernel. So I don't know why people worry so much about that, but well, and so I was saying, well, you can change it later anyway if you really wanted to put it in user space. The applications don't care if it's user space. So the idea is to be pragmatic. Not, oh, everything should be outside the kernel and then we have mach, which is pretty bigger than our kernel. And I don't see the point. Okay, well, now this is the user interface. I don't know if anybody here has seen an ASR33. I haven't. Well, I think I saw one in a museum or in an exhibition, but if you look at your X term, there is still the sign to mostly work like this. Otherwise, use through an STDI, STDI and tell me why your X term has a bowed rate and how it defines the bowed rate of your X term. I'm not sure, but well, maybe somebody can explain to me later. Well, by the way, the real Windows system, it's used throws away all that, used to start from scratch with a much simpler model. And it's designed to use mouse, which I don't have, and well, you see it has some disadvantages. Well, actually, there is also input device with pen and so on because it's ported to the E-Pack and then they wrote some pointing device input and so on and a bunch of other stuff. But anyway, but you really want to use a three button mouse because it's really designed to take advantage of it. All text everywhere is editable. It's a graphical interface, but it's textual interface because it takes this idea of Unix that everything should be text and that you should be able to manipulate it easily. That has another advantage because everything is text and everything is UTF-8. It can work over the network. You don't have to worry about byte, endian and that kind of stuff because well, it's going to be text and UTF-8 doesn't care about byte, endianess. By the way, UTF-8 was invented by Ken Thompson for plan nine in 1992. And well, plan nine, the whole system was ported to UTF-8 everywhere in, if I remember correctly, three days by Rob Pike and Ken Thompson. And well, last time tried in Unix, it doesn't seem to work very well. I don't understand why. It's only taking them like 15 years. So the Windows system multiplexes the interface that it gets from the kernel itself. Maybe I have time to demo. I have to go a bit faster. Acme is the user interface, what Rob Pike called user interface for programmers that manage lots of Windows, do all kinds of weird stuff. If I have time, I will. You can write all kinds of applications. You interact with it through a file system interface too. There's a wiki browser with it. There's an email client and a bunch of other things. Plumbing is what I was showing before. You can plumb anything and it will, it's a set of rules which based on regular expressions and if you send it a string it will, it has a set of ports which are also files and applications that can handle that file will listen to the right port. So for example, there is a, let's say URL port and then the web browser will attach there and anything you plumb it will say, oh, this looks like a URL. I send it this way and that kind of stuff. Okay, the compilers. They are curse compilers compilers. All compiling and curse compilers is the same in plan name. You have a different binary compiler binary for each architecture. There are a few there. I think there is a few more but I cannot remember them from memory. Very few lines of code. It compiles really fast. It's quite reliable, especially compared with other compilers. And well, it's pretty small. It has a very simplified preprocessor because well, I think most people will agree that the preprocessor was one of the biggest mistakes in C which lets people do some pretty above-enabled stuff. No inline assembler, of course. The assembler, there is very little assembler in plan name, mostly for portability. We try to keep the amount of assembler as low as possible just in a few localized files because otherwise people just think, oh, well, this matter, I add a bit here, a bit there, a bit everywhere and then you try to port it and it's total hell. Or debug it or whatever. And it has some of the small extensions which I think I don't have time to explain here. As it is, the debugger is actually a programming language, an interpreted programming language. That helps with portability because the debugger, only a small part of the debugger has to be ported and it interacts over its last proc with the kernel. So you can debug remotely exactly the same as you debug locally. If somebody has a bug, they can just export the directory for the process that crashed or that has a problem and you can attach it remotely exactly the same as you will attach it locally. That helps a lot for embedded systems and so on. You can also take a snap. There's no core dumps. What you do is you make sort of a tar ball of the proc directory and then you can just re-instantiate it later. So that's quite handy for debugging. Okay, networking. I guess that many of you here has writing all these before. This is how you open a network connection with sockets. Pretty fun and you have to try like three different things just in case the user puts IP or a name or whatever. And of course it only works for a certain kind of addresses. So if you go to IPv6, this will not work. And well, some more used in case. Yeah, used in case the, what was the, yeah, if the name resolution doesn't work then you have to do it, but wow, it's tedious. It's clunky and it's used too many things specific to the protocol are stacked there. And well, if you want to do it, you have to prep it or you need bindings for another language and so on. Well in plan nine, we have a single library call of course, no Cisco because all networking is done over the file system. And it just takes a string which it's converted in, well the thing is that this takes a bit more to explain but it's actually very simple. And all applications do this. So when the system was ported to IPv6, no applications had to be changed at all. In Unix, every application had to be changed to be able to handle IPv6 and it's just a total pain in the ass. Here everything, all the details about the protocol is abstracted. You get a connection and you can read and write from it. That's all you care anyway. How is this done? You have a SlashNet file system. SlashNet has, it's a union amount of various file system. The TCP-AP file system which provides TCP, UDP, the Ethernet device which provides the Slash Ether device number, the DNS solver and the CS is called the connection server. What you do is you write to a SlashNet CS, the connection string. The connection string is just an address of what machine you want to connect to. And the connection server will say, well there is a network database which replaces DNS in planning environments. But you can ignore that because if you don't use that it's not a problem. It will then try to resolve it via DNS. But it will figure out what kind of connection it is. If it's an IPv6 address it will know oh this is an IPv6 address. And then it will do all the work that needs to be done to open a connection. And it will give you a string. That string is a string you have to open. And when you open that file, you will get a file to a directory where you have a data file and you can read and write. All that is encapsulated in this dial syscall. Well it's not a syscall of course, it's just a library call. Okay what advantages does this have? Because as SlashNet it's a file system. You can just import it from your gateway and you don't need NAT. There is no other translation involved. You just are using directly the IPS stack of the gateway from your local machine. That also can be used to access the sort of BPM. I could go on with that. Okay, first of all in Bentay. This is the file storage, more traditional file storage. And this gives you automatically daily snapshots of the whole system. If you want to see how was the state of a file yesterday you use history. That we'll check in Slash and SlashDump how the file system looked like. Well the storage file system of course. Yesterday all the storage is done in a venti server. Venti server is a hash address block storage. And on top of that there is the fossil file system which uses that to build daily snapshots of the whole system. But because all the complicated data is address by the same hash it just goes away. So you can take daily snapshots with very little storage cost. And here there are two small examples of history dash D will make a diff, an interactive diff of all the versions, all the existing versions of admin users. And you can see all the changes to the user database that have been done in that system over time. Okay, security. There is no root, there is no SUID. Well you can escalate privileges if there are no main privileges. NAMI space is also provide very good isolation. I have seen lots of people that thinks true root is really safe. Well it's not. Anybody that knows a bit of security it's pretty easy to get out of true root. And in plan nine no because once you are in set a NAMI space if you don't provide and file the script or to mount other NAMI space or you can even disable the mount syscall when you call fork. And well then you will not be able to mount anything else. If you run your web server like that there will be no way they can get out of that. And then authentication and encryption. It's all handled in a file server which provides this authentication file descriptor which I mentioned before in the mount syscall. You get it from the factatum which centralized authentication and keeps track of your keys without the application being able to see it. So if it's public key authentication even if the application is compromised your keys don't get compromised. This also will make a whole presentation of its own. Concurrency. There is no pthreads. Yeah okay I have to finish. There is no pthreads. Concurrency is handling with communication sequential processes. This is all very interesting but you will have to go to usynccsp.com. There is the free online PDF book there. It's very very nice way to handle concurrency much better than pthreads and so on. Inferno it's a whole other system. You can. Okay the planning community. Well the planning community is that it's not very friendly but I think well it's not matter of being friendly. It's matter of well if you're interested I think there's a lot you will learn and if you ask intelligent questions you will get intelligent answers most of the time. Maybe you have to try again or maybe you have to look at the source code. But well the source code is pretty simple and easy to read so I think it's worth it. And well I took this I guess many of you have seen it. I used to say Unix and then it used to say computer but the guy looks a bit like Ken Thompson anyway so it applies to planning too. Conclusions. Plan nine shares some things some ideas and some philosophy with Unix but it's very very different and everything works in very different ways. So don't go to plan nine expecting to see the same as you have seen in Unix. But still I think I mean if you are never going to use plan nine because it's so different and because well maybe you really have to use same acts. I really will try ACME. Many people that like same acts have tried ACME. I used to use VI and now I love ACME. Use the mouse all the time and it works great. Just get it takes a little while to get used to it but give it a chance. And still if you just go and read the papers lots of the problems that Unix systems have tried to solve over the last 30 years planning people has looked into them. They created Unix. They have thought of what's the simplest and most clear way to solve these problems. Look at the papers. Most of the papers have a section near the end. How can these ideas be applied to Unix? Check it out. Maybe there is something that you can learn about it and that you can apply to your day to day work. And well here there are some resources that you can check out for extreme formation and so on. That's everything. Is there time for questions? I'm not sure. Let's see if it works. Well questions? There are no questions? Or I don't have time for questions? Just while the next speaker is setting up. Because you started late so you... Yeah, yeah, I'm sorry. Okay, well this and that, this and that. Did you want to get a spark with it? No, I don't. No, maybe I...