Plan 9 represents the ultimate triumph of architectural purity over market pragmatism, proving that a "failed" operating system can still define the DNA of modern computing. It remains a poignant reminder that the most profound innovations often arrive as quiet revolutions rather than commercial blockbusters.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
Plan9: The squeal to UnixAdded:
We've probably all heard of Unix. And if we've not heard of it, we've definitely used it. We may not have realized that we've used it or a Unix like operating system. Heck, if you're watching this video, you're definitely using it as that's how it's serving the content out to you. Now, what you may not know is the creator of Unix, Bell Labs, created a follow-on operating system intended to replace Unix called Plan 9. And you're thinking, hey, wasn't there an awful be movie called Plan 9 from outer space?
Yes, there was. And that's what the name's inspired from. Welcome to the video about plan 9 from Bell Labs. In order to understand why Bell decided to create Plan 9, we have to go back in time a bit before Plan 9 was created. In the first era of commercial computing, we had what was known as batch systems.
Essentially, a very large mainframe that would run a job one after the other.
Developers didn't get anywhere near the main frame. The closest they got was the pigeon hole in which they popped their punch cards with their program on and usually with a note saying what tapes they needed mounting onto the system when the job was run. Their output from this would be either a mixture of printouts and yet more punch cards and possibly some updates to a tape. The machines were run by the machine operators. So there was no interaction between the users of the computer and the computer itself. As we get into the 60s, we start to come up with the idea of time sharing. Multiple users can use the computer at once. It doesn't just do one job at once anymore. Time on the machine is shared between a number of terminals, typically teletype machines, hence initially being referred to as time sharing. And it's into this world that we see units getting created. A number of people at Bell Labs have been involved in the creation of an early time sharing operating system called Multix. That apparently did not go well.
And while that would eventually get cancelled, those involved were not willing to give up on the idea just yet.
Armed with a leftover PDP7, Ken Thompson with the help of Dennis Reaching and Rug Canaden started implementing a hierarchical file system that Thompson had written as part of a experiment of ideas he had related to the Multix project. This project would then grow out to form Unix. Initially spelled U N I CS, no X, which is intended as a pun on Multix. At some point later on, the CS would just become an X and we'd have Unix as it's spelled now. No one seems to remember when that happened or exactly why. But the reason for stepping far this back in history is to get across the core concept of Unix. It was a big machine being shared by multiple people on different terminals. The mini computer had only just been invented and most computers were still basically mainframes. We were still a while away from getting a usable micro computer.
But by the mid to late 80s, the world had changed quite a bit. We now had some fairly powerful micro computers. And even in the Unix workstation world, we weren't having one computer used by multiple people. People were starting to get a Unix workstation on their desk. So really, it was one computer being used by one person the majority of the time.
And we'd also invented this thing called the GUI, the graphical user interface.
So the world of computing had changed quite a lot from the late '60s, early '7s when Unix was being created. And the team at Bell thought, well, what we need is an operating system that reflects how things are now in terms of hardware.
Now, this team would consist of Rob Pike, who you might know as the person behind language go, Ken Thompson, one of the creators of Unix and the language scene, along with Dennis Richie, also from CF, and include contributions from Brian Kahan, Tom Duff, Doug Moy again, and Beyond Strauss, the guy behind C++, and finally Bruce Ellis. So, a whole bunch of heavy hitters in terms of who's contributed what to the world of computing into all the nerdy details about Plan 9. However, we should probably have a word from this channel sponsor PCB way. Fine. Purveyor printed circuit boards. Yes, you design things.
You upload a design. In exchange for money, they will send you PCBs back in the post. But that's not the only thing they will make for you. No, they'll also do 3D printing. Apparently, now including metal 3D printing. By which I mean 3D printing things out of metal.
not say for example printing out mega dash logo. Although maybe you could get them to print that out of metal. They also do CNCing where they use drill bits to take things off a big lump of metal or maybe even plastic or wood to get the shape that you designed in your 3D CAD system. But no matter what it is you've got them doing, you upload design, you give them money, things come back in post. Let's keep the world's postman happy. Now, one of the first things you probably know about plan 9 is the intention was not to run it on a single computer like you would with Unix. In fact, it would run across multiple computers all having slightly different roles in what they referred to as a grid. These days, we would probably refer to it as nodes in a cluster. Also, unlike Unix, it wasn't going to be based on text mode input and output devices like a TTY or a, you know, a dumb terminal, but would in fact be a graphical operating system from the outset with the initial idea being a user would sit at a graphical terminal.
Now there are a couple of things driving this grid concept because they'd looked at how institutions ran their micro computers i.e. everyone sits at their own one. They work almost in isolation to each other. But still some poor administrators then got to admin a whole bunch of computers. With plan N administrator would be able to administer the grid and would not have to think about what each individual computer is going. Just manage resources in and out of the grid and uses access to those resources. They felt like this would make a much better system for running an environment maintained essentially by some central body but with users able to access it. The other factor behind this was relatively inexpensive high bandwidth networking technologies now existed and one bell lamp center the RAM was Ethernet well 10meg Ethernet. Now I know you might be thinking that doesn't sound very quick given that we now have gig Ethernet but in the mid 1980s 10 megabits was a lot of bandwidth. Prior to that, a couple of hundred kilobits was considered a lot of bandwidth, and it was certainly enough bandwidth to make the ideas they had practicable. Now, the reason I'm getting into this before getting into all the nitty-gritty is that if you think of plan 9 is designed to run on a grid of computers rather than just one computer, its whole design makes a lot more sense.
Another factor around the grid idea was that you could infer the make more efficient use of the compute resource that you purchased. Because one of the issues with the existing microcomput model is with one machine per person, if the person sat at the machine isn't particularly taxing the machine, well, there's a lot of resource in that machine that isn't getting utilized.
Whereas at the same time, you might have another user who needs to use vastly more resource than their one computer can provide for them. So in theory with a grid, the user needing the resource can get connected to that resource. Now obviously how effectively that works does depend on the design of the application itself. After all, everything can't necessarily run in parallel across multiple machines, right? Let's get into the nitty-gritty of how the operating system works and its features. One of the first things we need to get into is the whole model of everything is a file. No, really, everything. Now, Unix already had a pretty much everything's a file model.
So, when the people were creating plan 9, they already quite liked this idea.
And with plan 9, they really took it even further. Now, some of their extensions to this everything's a file concept you may already be familiar with, especially if you're a Linux user and you've seen the proc filing system.
For those of you who are not a Linux user, I will explain it to set a whole bunch of kernel and networking parameters and basically a lot of things to do with your operating system. There is a file that represents that concept in the proc filing system. And by writing value to it, well, that's how you control that stuff. So if for example I wanted to turn my Linux box into a router, I would stick the value in of one into /rock/sis/net /ipv4/ip_ward and that would turn on IP forwarding for the whole machine. Now the proc filing system concept was basically borrowed from plan 9 as Linus could just decide to do that cuz he was writing his own implementation of a Unix like operating system. So you could take really good ideas from multiple Unix like places.
The other departure from the way Unix had done stuff is 9 does not provide any special APIs for doing stuff like say the sockets library. A device driver would provide a file for every aspect of the hardware that needs controlling. So you can just read and write data to and from those files. So unlike Linux, there's no IOCTRL interfaces on device files. So if we take a serial port for example in Linux, there would be a device that represents that serial port. But if you wanted to do things like change the serial port speed, well, you'd use an IOCTRL call.
In plan 9, while there's a file for reading data in and out of the serial port, there is also a file to do things like control the speed of the serial port and stop bits and parity and that sort of jazz. Now, this did mean that you had to have a lot more files to represent things, but we also were no longer limited to a 1970s PDP7, so did not particularly have to worry about the extra resource that those extra files would take up. One of the advantages of things having moved on a little bit, this also significantly simplifies the interface for developers because we now have an operating system where the only SIS calls we need to make to control the OS is open, read, write, and close as everything is done by just reading and writing to a file. This everything is a file concept even expands to cover all the operating system services that make up plan 9. As you can think of plan 9 as doing the whole micro service thing before we started calling them microervices in that for each aspect of the operating system there is a little service that does that job even ironically when it comes to files. Now you might remember earlier that I mentioned that plan 9 is intended to run in a grid of computers. So when you the user accesses the things you regularly think of as files your documents etc. Well, typically you're not directly going at files on a hard drive. No, you're talking to a file service. And you guessed it, yes. In order for your application to be able to chat to that file service, it has to open a file with the file server. So, even access to other files is done via a file. It's files all the way down, people. In fact, logging into this file server is how you log into the machine typically as it's the file server service that holds all the account records for the users. Now, in order for all these services to be able to communicate across the network, plan 9 has a protocol called 9P, also referred to as the plan 9 file system protocol. You can think of this as sitting in the same sort of layer of the protocol stack as HTTP in that it does rely on a transport protocol underneath it to get it from machine to machine.
The original one is one they use called IL or internet link. Now, that would sit directly on top of the IP stack and you can think of it as an alternative for TCP. Later on in the fourth edition of plan 9, they would actually replace IIL with actual just regular TCP as YIL worked pretty well for local area networks over longer distances. Yeah, it wasn't particularly reliable. So every service in plan 9 uses this 9P protocol.
And again with every service using exactly the same protocol, this simplifies everything massively for the developers once again. As if you're writing code to do something, you just need to learn the 9P protocol. That's it. But the 9P protocol would also be used to handle your connections to the internet as well. Now, typically on Unix and most other operating systems that have implemented TCP IP, you have something called the sockets interface, which is an API applications use in order to get an IP connection across to another machine. So, let's say you want to open a socket to, I know, a web server somewhere in the world of plan 9.
Well, you'd open the file /net/TCP/clone and the value you'd read from that would be your file descriptor number. You would then go open /net/TCP/ the file descriptor number and then ctl.
And into that file, you would write connect space the IP address exclamation mark the port number followed by a new line that tells the IP service to go open up a connection to that port on that IP address. So if we then wanted to write some values to that web server, we would then write into the file /net /tcp/file descriptor number slash data. And if we're having a HTTP conversation, we'd shove our get string in there. We could then read back anything that comes from the web server by just reading back that same file. And when we're done with that connection, well, we then just close that file. And if we wanted to support other network protocols, well, we could.
It's just the initial file that we open in order to listen to that protocol or make a connection via it would just be a different file name. Now, in order to help port programs from Unix and other operating systems that already had TCP IP, there was a C wrapper library that provided the regular sockets interface that those applications targeted. So, you could compile that and then compile your code against it and link a lot together. And in the background, yes, it's doing its file opening business, but the application gets to see what looks like a socket interface to it, at least at compile time. Plan 9 did also provide a little C library that meant wrapping this up a little bit easier rather than going at file names. You had the instruction dial that would let you open a connection to something, hang up, obviously that would hang it up. You had listen if you wanted to listen on a TCP port for something and accept and reject that let you either accept connections not or reject them on that port. But again in the background it's still just hitting those files. See everything really is just a file. Now the next major concept in plan 9 is name spaces.
With an OS built more or less entirely out of files things should get a little bit crowded. You also need some way to control what applications have access to which files and also limit which files can be seen by different applications.
Now namespaces gives us a pretty good way to manage this. Now you may already be familiar with the idea of namespaces even if not by that name as if you've used either Docker or Kubernetes you'll have used namespaces without entirely realizing that you're using namespaces potentially. In the world of Docker, when you start a process up, that process gets to see a limited subset of your operating system. It only gets to see the other processes that are running inside the container, only bits of filing system that you've linked up to that container. And that's because in the background, the kernel is using what's known as a namespace. Each container gets its own unique namespace, which is how come when you do something like a process list, you only see the processes that are in the same namespace that you're in. Well, plan 9 has the same idea. Every process or little group of processes runs inside a namespace.
The only files that are visible in that namespace are the ones that have been put into that namespace from the global namespace. The global namespace being all the file names that are known to the entire operating system. Now this intrinsically stops the process from opening any files that are not in the same nameace as it immediately providing a degree of security. But it also allows you to manage and organize things a little bit better. For example, a process can be designed to access the same file name whenever it runs.
However, for one user, it wants to access a different file than it might for another user. Well, when you create the namespace and spin up the process, you map one user's version of that file into a predictable name inside the namespace. So, for example, the program might always just open the file image.jpeg. Being a single image viewer, you don't need it to do anything else.
So when you start that process in its namespace, you map whatever image you want to be displayed to image.jpeg inside the namespace. You then don't need code in that application to do file choosers and other dialogue options like that. That's all done by whatever it is that launches that process. It also means you only need to give it access to one whole file in the entire global filing system. Well, then whatever files it needs to be able to access in order to draw on the screen. Yes, even the GUI is file-based. And this helped solve some of the bigger problems we talked about at the beginning when they wanted multiple systems all operating on the grid where it was centrally managed. Yet users had the freedom to use all the resource in the grid. An administrator can use namespaces to make sure that the right groups of files are presented to the right users on the system. So for example, you've got a printer and you only want one group to be able to access that printer. Well, you namespace it into their processes. Therefore, they can print through that one printer.
don't map in the other files representing the other printers. Through controlling access to files and what's in what name spaces, that allows you to police who has access to what resources in the system. So now we know some of the goals of Plan 9 and some of the techniques they use to implement that.
So you might be wondering how did this operating system fare? Well, the initial answer is pretty well. Plan 9 soon took over as the standard operating system for people operating inside Bell Labs.
Now this is no small deal. Remember this is how Unix got its start too. It went from someone's curious side project to the thing that the patents department started using to text format all their documents to slowly becoming the primary operating system for people using computers inside Bell Labs. So in order for that to be displaced by another operating system, they had to be getting a lot of utility out of it. And while plan 9 was quite Unixy, it's not exactly source code compatible either. So you really needed something quite decent to persuade people to port all their stuff across to it. But it seems like internally it was quite a big hit. And remember initially the Plan N people are seeing this as the target market for what they're doing. Research groups like this, university groups, anything where you had a large group of people who needed compute resource that they could all access and yet it'd be operated in a centrally managed way without getting in everyone's way. And the Bell Labs people are not the easiest audience to make happy. While there's a ton of really cool things happening in Bell Labs and an awful lot of very gifted individuals working on those things, there is also, how should we put it? A a couple of people with quite spiky personalities.
It's not like you're just preaching to the choir here. Unless your choir is in some way chocked full of people who have their own independent musical ideas, most of whom think that their musical ideas are better than the musical ideas of the people in charge of the choir.
And they're certainly not going to listen to you quietly deliver a sermon.
So, Plan 9 really did have to be quite good in order to sell itself to this crowd. And it really did seem to well sell itself to this crowd. So, having got itself over hurdle one and made itself quite popular with a fairly difficult audience. You might be wondering, well, how come we haven't heard of this thing like running on everything? Why is the whole world not running plan 9? Because Unix and Unix like operating system sure of heck have been quite popular over the years. Well, in order to look at the commercial success of Plan 9, well, I kind of have to how much things had changed in the world of computing even since Unix had come along. Now, Unix was originally developed again by the Bell Lamps team.
But Bell Lamps was not a business like any other business. Bell was the monopolistic supplier of telephone services in the United States. And at one point, the US government had realized that monopolies weren't always good for consumers and decided to, you know, do something about it. Imagine that being something that happens in the world. So, Bell had had to reach a settlement with the US government that saw it being partially split up, but also put restrictions on what businesses Bell could get into and couldn't. And one of those restrictions was that Bell couldn't get into the computer business.
It could still research things with Bell Labs. It could still patent things and it could license those patents to other businesses as well as copyrighted code.
So this is why Bell themselves had not tried to commercialize Unix. It had however let universities have licenses which had given rise to the Berkeley system distribution BSD that had given rise to other versions of Unix and various workstation companies starting to sell Unix based systems around BSD.
Bell or AT&T as it had become then started improving on their Unix software and licensing it out to Unix workstation vendors all of whom could create their own operating system based around it. So for example we see Sun from running Sonos going to Solaris which is them shifting from BSD to a system 5based distribution from AT&T. Each vendor was allowed to license and then modify their version of Unix to suit their hardware and often introduced their own standards on top of Unix that they could use as a unique selling point for their particular flavor of it. Although suddenly when there's about 20 different ways of doing something all from different companies, they were forced to all come together to unify their standards a bit somewhat rather than just fragment their market into oblivion. Also, when AT&T first starts letting these licenses out the door to the likes of Berkeley, operating system-wise, there's not a lot of competition. Computing is largely massive mainframe systems that come with their own operating system or mini computers that are available with a range of operating systems, but none of them quite what Unix could be. We were starting to see micro computers, but the ones we first saw were not capable of running anything as sophisticated as Unix. And initially, most of them didn't even have an operating system. You might get a basic interpreter, but as CPM had started to become the standard operating system for microcomputers, followed by MS DOS, by the time Unix workstations have risen, Belle find that the operating system market is way more crowded these days. Their own original operating system, Unix, is on practically every workstation known to man in one form or another. Microsoft are dominating a certain desktop market with Windows. Apple is still clinging in there. Although by the time Bell's coming to release plan 9, Apple's barely just clinging in there. Honestly, we all thought that thing would just go bust.
So, it's an extremely crowded marketplace. We also have other upandcomers starting to appear like Linux, various FreeBSDs available for x86, and stuff like BIOS. So, by the time Bell's ready to let us have this in the early to mid 1990s, the marketplace is indeed very crowded. And Bell are not planning on making any hardware for this. They're hoping you're going to use generic PC type stuff, which already typically tends to come with an operating system that you'd be forced to wipe, or higherend machines, which again you purchase with an operating system that you're going to have to wipe. So, this was always going to be an uphill struggle for any new operating system.
Now, one of the big things Ken Thompson points towards as a reason that Plan 9 didn't quite take off in the way that they had hoped is they launched it with the public around about the same time that the worldwide web was becoming popular. And Plan 9 was missing a web browser at that point. Really, the big web browsers were only available for Unix, Windows, and Mac. Plan 9 had relatively little to offer in that space at that particular point in time, which is a really bad point in time not to have anything to offer in that space.
Just as the whole world's becoming obsessed with the web, plan 9 is launching without the ability to do the web. If it had been made generally available a couple of years before that, nobody would have cared cuz there was no web to care about. However, if you want to be the latest cool shiny thing in tech, not being able to do the thing that is the latest new shiny thing in tech It's not great from a marketing point of view, and obviously Thompson is right about that. However, I do personally have my own opinion as to why Plan 9 didn't quite take off in the way that the creators of Plan 9 hoped and how much we think it might have done given how decent an operating system it actually was. Plan 9 is a pretty complicated operating system, and it does a pretty good job of solving a number of complex problems. However, most organizations are unaware that they have those complicated problems or are going to have them in the future. In the early to mid90s, a whole bunch of businesses were just getting computers in for the first time as something they'd used generally across their whole business. While they might have had specialized IT systems for their accounts, for example, or other business functions, large parts of their organization would have operated completely without computers until this sort of point in time. And people would use phrases like, "Ooh, the paperless office." So, the complexity of plan 9 did not make it easy to sell. You needed to already know quite a lot to know you'd have the sort of problems that plan 9 is going to solve. This is like trying to sell many sophisticated products. There are not a lot of users that realize they need that sophistication until they come to the point, well, when they need that sophistication after they've made the purchasing decision. Windows was out there. It was massive. It was huge.
Everybody knew about it. Everyone understood it. And there were quite a few people that thought even Windows was quite complex. So an operating system you distribute across multiple machines or using microervices and their own network protocol is not so much complicated at this point as actual rocket science. But also plan 9's geared around this idea as some form of central administration taking care of this thing for you. A lot of organizations didn't have that decision-m around what they were doing with computing was more distributed around the business. For example, the finance system would typically be decided upon by your finance and accounts department.
Engineering teams already had a solution they particularly wanted in place, usually involving a Unix workstation.
Individual bits of business function were typically deciding what their own IT needs were. In older, larger businesses, while they would have a centralized IT team, they were typically looking after the mainframe and the companywide business applications. They were letting individual departments have a much more free hand over what they did in terms of microcomputers on the desktop. All of these make selling plan 9 quite difficult when you also have the steaming great big juggernaut that is Windows taking up the entire bottom end and workstation end of computing with Unix and NT being at the upper end along with microvax. It was difficult for plan 9 to find a space in this market.
However, with all that said, there was a certain buzz and excitement in certain circles around plan 9. Unix had been very popular. So a successor/SQL operating system. However, after an initial shipping to universities in 1992, and the fact it took a free further years for it to be made more generally available via a book publisher really didn't help matters. You see, they tried to license this as just a source thing, hoping to work in the same way that Unix did. However, the various Unix licences that were out there were already out there using Unix and making workstations based around it and didn't have any particular risk to change what they were doing. The dotcom boom was getting into full swing and they were making money handover fist. They did not need a new operating system to help with that. And with such a crowded market, the customer base wasn't exactly screaming give us plan 9 now. So, commercially speaking, it kind of appeared whimpered and died. Now, by the year 2000, Bell Labs had been sold to Lucent Technologies and was now Lucent Labs. And Lucent released a third edition of Plan 9, this time with an open- source license. And then in 2002, the fourth edition to muddy the waters somewhat as well. There was a spin-off operating system from plan 9 called Inferno, which yeah, this sort of took the idea of plan 9 and also bolted in a virtual machine kind of like the Java virtual machine. So you could have application code that was independent of whatever processor the operating system was running on top of. And this is happening about the same time project oak is running in Sun that does become Java. So it's not like they were jumping on a Java bandwagon here except whereas the virtual machine in Java is a stackbased virtual machine. This is a registerbased virtual machine. So it's much closer to how the hardware actually does stuff. But if you think trying to sell plan 9 as a distributed grid operating system was complex, imagine doing that and then throwing in the whole virtual machine thing on top of that too. Yeah, it all becomes complexity on top of even more complexity. So at this point you're probably wondering what is it like to use plan 9. Well, I can show you because we can run a distribution of plan 9 on a Raspberry Pi. So here we have Ninefront, a plan N distribution largely targeting the Raspberry Pi where we can run all our services on one machine or we could in theory distribute them across a grid of machines as well. But I'm just going to run everything on one machine. Just keep in mind that all the things I'm doing on this could be done across multiple systems. Now I probably will add one virtual machine running on my cluster to this at some point. not in this video, but just so I have filebased stuff, not on the Raspberry Pi. Right.
So, I've downloaded the image of Thorfront and I've put the SD card in this little Raspberry Pi 500, sorry, 400, which is a Raspberry Pi 4, but just a keyboard kind of a case. I bought it for just moments like this sort of thing when I've got an operating system I want to run. Right, let's power this thing up.
See what we get.
and just wait for this thing to boot.
And there we go. We're straight into the plan 9 graphical console as the thing boots up.
Now, although you can see it's text based, hopefully you can make out the little mouse cursor in the top left there. I need to go grab myself a USB mouse in a second.
But this is the device booting up for the first time. And as you can see, it brings up this graphical console first.
Admittedly, it's rendering text into it, but it's rendering text in a graphics mode. As plan N, as we mentioned earlier, is entirely graphics based, right, we shall just wait for this to do its thing.
As you can see, you've got Unix like devices there for the storage devices.
Fan 9 again takes Unix's everything's a file thing, including the hard drives, and well, kind of runs with it. Right. Right.
Rebooting this thing with a mouse plugged in. Hopefully, that will work. Well, not yet. Have this ludicrously over the top gaming mouse.
Um, it's absolutely not functioning.
Huh. Well, that's not ideal. H. Okay.
Going to have to figure out what we need to do about mouse support. Right. Again, apologies for the audio quality difference between this and the voice over bit as I'm using the built-in mic to the camera. Now, you may have noticed I have got a completely different computer hooked up rather than the Pi 400. Um, that's not a continuity error.
Yeah. So, it turns out there is a bit of a problem with the Pi 400.
and 9. I'm just going to power this thing up.
Yeah, this is just a P4, by the way, in a fancy case that's got a built-in battery. Um, so at one point someone was selling cheap on eBay, and I I picked a bunch of them up, right, hopefully, we'll see some video output in a second on the screen, editing me here. So, I sat there for quite a while waiting for this thing to produce an output. And it turns out it was never going to because the HDMI adapter that was in there was actually damaged. Okay, we are back with a non-mangled HDMI adapter. Let's hopefully just boot this thing up and get this working. Oh, there we go. That's a promising sign.
So, here we go. This is a fresh install of plan 9. Now, the reason I've swapped to this Raspberry Pi 4 is the Raspberry Pi 400. Yeah, not as supported as you might think. Um, it turns out that that thing, while mostly compatible with Pi 4, is not entirely compatible with Pi 4 as the USB keyboard's wired a bit differently inside. So, what happens is it boots the operating system, but it then can't detect the keyboard and do anything with it. So, hence swapping over to the Pi 4.
Apparently, you can get it working with much messing around. I decided not to because I was only using that to make it easy for the video. So yes, I just changed the SD card in this Pi 4 I was using for something else. Right. So we dropped to its graphical environment there system RIO. I'm just going to move just trying to remember the there right mouse button for moving stuff. This is Rio the graphical environment.
As you can see, it brings up a bunch of terminals to start with. And yeah, it uses a bunch of whole style Unix commands to that cuz while this is not a version of Unix, they did get a lot of the same commands. And you can see the original difference between ls, which lists them literally as a list, and LC to listing columns.
Yeah, it's a bit old school even for a Unix environment. Do we have find? No, that's a shame. Right. If I load up ACME, which is the standard text editor/file editor, is that actually load that? As you can see, when you actually load a thing, it kind of replaces the shell window. It's not hidden underneath it. It's become window that we had before. And we can resize this. Hang on.
This is our text editor, but it's also our file environment as well.
Middle mouse actually selects the menu item. When you quit, you can see it drops back down to the terminal window that launched it. That means that terminal window becomes that right. Can we now different mouse button combinations to say right mouse button move button selects the menu out text edit mode. So, we can start typing in some text. Again, future editing me here. So, when I recorded this, I thought the screen was coming out much better on the camera than it turns out it has done in edit. So, for those of you watching this on a small screen, the left hand side of Acme is the text editor and the right hand side of it is essentially the file manager.
So, that's a bit of a look of plan 9 running on a Raspberry Pi. Now, as you can tell, the base install of this is pretty bare bones. It's Rio, Acme, and that monitor program that you saw in the top left corner of the screen. There are a whole bunch of command line tools that are installed by default and the compiler as well. But of course, none of that looks particularly impressive on camera. And that kind of summarizes one of the issues with plan 9 in that it didn't get a lot of applications developed for it. And a lot of the ones that did get developed for it, well, they were fairly niche. They addressed the problem really, really well, but you never really got those generic desktop applications. Now, subsequently, a number have been ported to it from Linux that you've all seen a million times before, but none of them are particularly worth showing off on camera. Now, while we've talked about the idea of everything being a file in Plan 9 and the idea of name spaces and mounting files into different namespaces, we've not actually talked about the filing system itself. Now, things in plan 9 work a bit differently to most other operating systems you've probably used in that to access the file system, the kernel itself doesn't have a driver for the filing system that then everything uses like you might on Linux or Windows or Mac. No, the filing system is a a service just like anything else in plan 9 that you access via a file.
So, on one of the computers in your plan 9 grid, you run the file server. You can actually run it on multiple machines and it might be in the machine that you're physically sat at, but really it doesn't matter where in the grid you run the file server. The file server opens a number of files that other hard disk devices on that machine and that server then exposes a filing system to anyone that wants to connect to it. So, as you can see, how the filing system plums into the operating system is different to most other operating systems. But the file server had some pretty interesting properties that at the time almost no other operating system could offer in that we had snapshots or at least that's what we'd call them now. Now there might be many of you who are not familiar with the idea of snapshots cuz a lot of desktop operating systems either don't offer that as a feature or the setup to them is rather complicated. So most people don't know that it's there or simply just don't use it. Now the idea of a snapshot is that any point in time you can freeze the filing system taking what we call a snapshot. Any further modifications to the filing system don't touch the blocks belonging to the snapshot. So it's not the same as copying a whole filing system. You only copy the bits as you modify them as they would get overwritten. Then that ends up on a new block on the disc leaving the blocks belonging to the snapshot alone.
This means at any point in time you can reverse the filing system back to the point it was in the past or you can mount an older version of the filing system anywhere within the current filing system. So you can access older versions of files. You can of course then remove a snapshot at which point no you can't rewind at that point but it does free the disk blocks related to the changes between the snapshotted version of your filing system and its current state. But because this is all very disefficient, you can have a lot of snapshots of your filing system stored in not much more hard drive space than your whole filing system would take without snapshots. Now, plan 9 would let the administrator schedule up regular disk snapshots, but would also allow individual users to snapshot their own files at any point in time. So, say as a user you had a bunch of files you were going to edit, well, you can quickly take a snapshot, then do your edits. If you don't like your edit, well, you can revert those changes out. and it would be possible to access both the old versions and the new versions at the same time. So you could do things like a diff. Now that filing system part was known as Fossil. But we then got an add-on system called Venti which allows you to make these snapshots permanent.
Now the way Venti worked is it was not a regular filing system. It would create 160bit SHA1 hash of the data it was storing and that hash would be used as the address for that data and these blocks of data were stored as read only after it was first written. You could never append to that data or amend it or overwrite it. You could only ever write it once, but you could read it as many times as you want. A system known as Worm. Write once, read many. Now, while Venty would store the index of hashes on a hard drive, typically, the data blobs could be written to slower medium, like worm discs, for example, which were fairly common around the time that this came out. And you might have had access to some of them yourselves cuz a lot of CD burners, well, they're worm discs essentially. You can write to them once, but you can read the data back multiple times. And why we did get CDRWs where you could wipe and then rewrite once again. CDRs were far more common. But there were other formats of worm disc as well, largely sold to organizations that wanted to archive large amounts of data.
And typically those were an optomagnetic kind of a disc. Venty would also support using archival tapes. And you would link this to Fossil and Fossil would go store the snapshot unique blocks via Venty. If you then needed to bring back a snapshot from a long time ago, some operator would have to mount a tape or put a worm disc in a drive, but Fossil making use of Venty could then bring that snapshot back that you could just mount in another directory or potentially revert a filing system back. And this made the operation of a plan N grid impressively robust in terms of being able to access files when you've had a fat fingered oopsy and erase some data out of a database you didn't mean to or you know trash or corrupt a file. You could also rewind or examine changes to essentially have an audit process of what has happened to particular files in their lifetime. And all of this was at the user's fingertips with assistance from an operator who's occasionally putting media in and out of the machine with the venty stuff on it. It is however not perfect. One of the issues is around that SHA1 hash that I mentioned, the 160- bit hash. While a collision, i.e. two different bits of data making the same hash is incredibly rare, SHA1 is a bit vulnerable to people being able to artificially make that collision happen.
So, this could generate some real problems for venting. Now, in 2017, Google demonstrated this attack with a tool that they called Shattered, which could produce two different PDFs in terms of their content, but both would have the same SHA1 hash being a collision with the first. As you can imagine, that would be an issue for a system that stores files based on their SHA1 hash as the unique identifier. Only one version of that data could ever be snapshotted. The other version could not. Now admittedly over time they could have changed the hashing algorithm of use to one that isn't so prone to having collisions artificially generated but by the time this discovery was made there wasn't really anyone who saw any major commercial advantage in distributing plan 9 anymore. Now, while we're on the topic, there is more than one way to dump or back up a plan 9 systems filing system. And I'm going to introduce what was my favorite utility in Plan 9. And and more importantly, from my point of view, a version of it that was ported to Linux that became my main backup utility for well years. And that's dump FS or its Linux version pdump FS. Now, this is a utility that allows you to dump an entire filing system or a subsection of a filing system to another disc. Now, in my case, when I was using it on my Linux boxes, that was a removable USB hard drive. Now, I'll talk mostly about P Dumper Fest because you can still use that today on your modern Linux machines. Now, what this utility does is each time you run it, it dumps the filing system in its current state, but it looks at the previous backups or dumps you've got in the target device you're backing up to, in my case, that removable USB hard drive, and it creates a new directory with the current date as the title of the directory. and any files that have changed since the last backup get written into that directory.
It then puts something called a hard link to all the files from the previous backup that have not been modified. That way, each time you back up in the directory with a title that matches the date of the backup, you will find a full copy of what you've told it to back up.
However, all the files that were the same as the previous backup, while still appearing in that directory, they don't take up any more disk blocks than they were already taking cuz the hard link just points to the disk blocks belonging to that file. The same file essentially exists in multiple places in the same filing system. If you want to erase older backups, well, you can do you delete the directory that has the name that matches the date of that backup. If any of the data blocks on the disk are no longer referenced by a file in any of the backup directories, well, those data blocks become marked as free, so they can be reused again. If some of the files are still referenced in an older backup or a newer backup, the blocks will be left on the disc still. This way, I could have versions of the filing system of the box I was backing up going back years, all fitting on the same hard drive, but I would not have 40 copies of my filing system. I would have 40 directories, the contents of which basically all linked to the same disc blocks. So my restore process is to just go into the dated directory, go find the file I want, and copy it into my regular filing system. It very neatly combined for me the idea of backup and archival all on the same storage device using the same tool. Now admittedly, these days I've moved to a more network ccentric tool cuz I don't want to be plugging USB hard drives in and out on a regular basis. I happen to use restic if anyone's particularly interested but when network bandwidth was relatively low then this gave a very cheap very reliable backup mechanism that included archiving and I very soon after the invention of USB hard drives came to massively prefer using this over magnetic tape as once you got a few USB hard drives in rotation this was a lot more reliable than tape it was somewhat more cost effective and also backed up and restored at a speed that massively outpaced that of tape. It was also substantially easier to manage than tape libraries as well, and you did not have to run the risk of leaving tapes in the tape library for an extended period of time for the backup to complete, leaving you potential loss of data issues when a fire broke out in the same building as your server and your tape library. as a lot of organizations had those two things in the same place with P Dumper Fest copying a relatively small amount of data each time because it doesn't have to clone the entire filing system every single backup. You could pretty much guarantee that the backup would have completed by morning and you can just swap the hard drives over. One goes back home with a member of staff and the new hard drive gets plugged in. That way you never have last night's data in the same place as your server and thus don't have the same kind of potential fire data loss that you might have using a tape library where you're cycling through tapes into the next day. The reduced time frame, especially when combined with snapshots, meant this whole system was a lot more reliable and gave you a much more consistent backup.
And frankly, I have Plan 9 in its dump FS tool to thank because that's what inspired the creation of Pumpump FS. So yes, my favorite backup tool for years was a plan 9 backup tool. It was just being run on Linux instead. So hopefully you've seen from all that plan 9 is actually pretty cool to use. So what happened with plan 9? Now as you can see from this being open source, it didn't just instantly die out, even though it never commercially took off in the way that its creators might have hoped. Now, still today, there's a number of people running it cuz obviously distributions like this exist. And it's fair to say that those who got into Plan 9 still really love Plan 9. Although quite a few people run a Linux desktop locally and then run the plan 9 client so they can talk to their plan 9 grid and then do an amount of their day-to-day stuff on their Linux desktop like browsing the web for example. But a lot of plan 9 has ended up in a lot of places you wouldn't expect it. For example, the 9P protocol that's a core part of plan 9 that is available for pretty much everything Linux, Mac, even Windows. It's had a pretty hefty influence on a number of operating systems. For example, the proc filing system in Linux. One of the big things that got created alongside plan 9, which is now absolutely everywhere, is uniode or UTF8. This has basically become the standard way to encode text.
Prior to this, ASI was the predominant way to represent text, which used 8 bits to represent text characters, or at least all the ones we use in English.
And in fact, UTF8 is in fact compatible with ASI, as in UTF8 can have single bite characters, and those first eight bit pretty much line up with the ASI character set. However, 8 bits is not enough bits to represent all the characters, they're used by humans in written languages. Uni-ode lets us encompass all the characters that don't regularly fit into ASKI. Even though you could get ASKI to represent more characters by knowing which code page the ASKI text was in, i.e. which numbers link to which set of symbols. UTF8 massively improves on even that because we don't need to know externally what code page the asky text is in. As uni-ode can use two bytes for a character. You don't need any data outside of the text to display it correctly. Uni-ode is also what gave us emojis. Yes, without uniode we wouldn't have emojis and then what would we have all typed into our phones in the late 2000s? So, next time you send someone a smiley emoji or any of the other emojis that are available, you have plan 9 to thank for that. Plan 9 has also been ported to run on top of other operating systems. For example, we have plan 9 for user space. The terrible puns just keep coming, which is a system that allows you to run plan 9 on top of Linux, only you're not using the plan 9 operating system kernel. It all runs in user space on the Linux machine, hence plan 9 for user space. but it lets you run a distributed system on top of Linux. So, as you can tell, there is a huge legacy for Plan 9. Even if you didn't know it, it impacts your life in a lot of ways on a daily basis, even if it is just sending someone an emoji.
Well, if you got all the way to the end, I'd like to say thank you very much for watching. Hopefully, you've enjoyed this one down what turned out to be a surprisingly interesting and influential yet ultimately culde-sac operating system, at least commercially speaking.
If you enjoyed the video, YouTube has provided a little button you can press to indicate that fact. There is also another button of which we shall not speak. If you're feeling inclined to press that button, well, I guess thanks for the engagement. If you would really like to help the channel out, why not hit the subscribe button? Cuz we're in danger of getting to a really large round decimal number at some point. And hitting that number would really remind YouTube that we exist.
Related Videos
Agentforce NOW AMA: Build with React and Salesforce Multi-Framework
SalesforceDevs
490 views•2026-05-28
How agent o11y differs from traditional o11y — Phil Hetzel, Braintrust
aiDotEngineer
450 views•2026-05-28
WEB TECHNOLOGIES UNIT-2 | Degree 4th sem BCOM Computers web technologies unit-2 full explanation💯✅
LearnwithSahera
1K views•2026-05-29
More tests are always better? How to use AI to identify tests that bring little value
Alliance4Qualification
335 views•2026-05-29
Search Algorithms Explained in 60 Seconds! 🤖💨
samarthtuliofficial
218 views•2026-06-01
People of Game of Thrones using JavaScript DOM
AltCampus
296 views•2026-05-30
Introduction to Problem Solving Part - 1 | Lecture 1 | Intermediate DSA
ascensionix
107 views•2026-05-29
So What's Odin Lang Even Good For
TechOverTea
131 views•2026-06-01











