I've read a lot of places that say "Plan 9 is basically a better Unix", but I'm not entirely sure why. Can someone explain what made Plan-9 special? I'm not asking in a passive aggressive sense, I genuinely want to know.
Plan 9 shows that you can reduce the complexity of Unix by changing the idea behind mount slightly (mounts are inherited by processes rather than global) and creating a simple network filesystem protocol that applications can use to expose their state through.
In Unix you often get stuck having to create these walled-off systems. Your editor's inner state, for instance, is not visible to other applications, so you need to come up with your own whole programming scheme. Same with your window manager. And all your networking happens through a separate set of APIs that are similar to the file descriptor APIs but different enough that nothing works transparently.
Once you have per-process mounts and a simple network filesystem, all your applications and devices can start exposing their state over that protocol. All your software and hardware are automatically networkable if you follow the design. And you can use Unix utilities to do things that previously would require whole subsystems to be built. You don't need to build your own programming language for Acme, because Acme's state is visible as a filesystem. Same with the window manager. And you don't need to build a custom networking scheme for sharing Acme with your friend on another machine, because you can export Acme's filesystem to that machine (or have your friend export their keyboard onto your machine as a child of the Acme process).
"Everything really is a file" is a good way to sum it up. But that's only possible and relatively safe because of 9P and per-process namespaces.
> Your editor's inner state, for instance, is not visible to other applications, so you need to come up with your own whole programming scheme.
> Same with your window manager.
> You don't need to build your own programming language for Acme, because Acme's state is visible as a filesystem.
I don't see how it's good programming practice to expose your internal state to direct read/write access from other programs. It seems to violate basic encapsulation principles.
Your quotes are making me think of some really important takeaways from the Longhorn disaster with WinFS, detailed in a recent submission[1]:
> More profoundly, Bill’s vision of an ecosystem of applications that all store and share their data in this relational store is in direct conflict with how applications build their data models. While some desktop applications (and almost all internal IT-written ones) use relational stores for their internal data model, they do not want to expose those data models for unmonitored read and write by other applications. I detailed some of the fundamental reasons in the post referenced above, Leaky by Design.[2]
Solutions like this... "what if application state were like a relational data store, or hierarchical FS, that other programs can access", sounds great as a fun programming exercise, but it isn't often how people actually want to design applications.
By "inner state", the parent didn't mean literally the RAM or disk storage used internally by the application, just the logical state that belongs to it. A Plan 9 filesystem is just an interprocess communication API that happens to be structured in terms of virtual 'files' and file operations, kind of like what REST does with HTTP. The application handles all requests itself so it can always limit access or enforce invariants, which was absent in the Microsoft examples you linked.
This isn't really a ’project’ in the sense you seem to intend: it was a 1990s AT&T research project that was abandoned and released under an open source licence in the mid-2000s.
Congratulations, HarveyOS is really an intriguing project to support.
It would be nice, if they'd provide an ISO. The thing I noticed about Plan9 clones and Inferno is that, they almost always run entirely in the userland. I think that's the reason HarveyOS does not provide an iso. I am not sure they are building a standalone operating system.
If you're interested you could also try inferno, however getting it up and running is also a hassle.
Lastly, in the case you're not aware, Plan9 and inferno also have a very interesting history. Inferno and Java were once direct competitors. Limbo a programming languages invented for Plan9 is also mentioned in the Dan Brown's best seller Digital Fortress.
IMHO Plan9 spirit still lives in Golang, like the Lisp Machines' spirit lives in Emacs. Maybe with cloud based OS's we could see the ideas behind Plan9 in everyday world. But other than that Plan9 remains an OS for hobbyists and idealist computer folk :).
> It would be nice, if they'd provide an ISO. The thing I noticed about Plan9 clones and Inferno is that, they almost always run entirely in the userland. I think that's the reason HarveyOS does not provide an iso. I am not sure they are building a standalone operating system.
That's a really good way of putting it. I could see Plan9 being relevant today. A "unified system" is pretty much what all the cloud stuff is attempting to approximate (and more poorly, of course).
Everything is a file system. You can mount almost all things. All things have private namespaces by default.
Right down to the TCP/IP stack... you can run a program called "sshnet" and connect to a remote unix box, the /net in that process' namespace now has a tunnel to the remote box, and all children of that process that opt-in to share the namespace now have a VPN-like to the network you just ssh'd to.
Because the network stack is a file system you can do basic open, read, write, close stuff to dial up remote services and work with them. As such there's IRC clients written in the shell, without evil extensions like /dev/tcp in bash.
It's fun, but it doesn't outrun any other OS I've seen. Maybe that's changed.
Honest question: If we extend dbus to be similarly pervasive in Linux (via BUS1 or whatever ends up being merged), won't it have pretty much the same benefits? Once it's in-kernel I'm 100% sure we'll end up with a virtual file system for accessing it. It will definitely never be quite as elegant and integrated in the system as Plan9, but maybe we could reap similar benefits?
Well the nice thing, maybe, about Plan 9's virtualization of resources is that they all follow some 9P variant (simple protocol).
9p is v9fs in linux. There's FUSE 9p stuff for other platforms. There's a virtualized Erlang runtime that sits directly on Xen as the OS that uses 9p. 9p is part of QEMU's way of talking to the guest (or is it the host?) OS.
It's been on a lego mindstorm brick too.
To me, kernel dbus is a bit more like mach_ports. Those have their own advantages too. As did Solaris Doors.
> If we extend dbus to be similarly pervasive in Linux
That kind of pervasiveness involve replacing all i/o through the entire system with dbus. File systems, netlink, sun rpc, mmap, signals and kill, tcp, and so on.
And then making dbus sanely deal with networking and authentication.
9p isn't just pervasive: it's the only way to talk to the system, which means that if you want to mess with namespacing things, all you need to think about is 9p.
In Plan 9, everything literally is a file. Processes communicate using the 9p protocol which is also the basis of the file system; each process also has its own, local view of the file tree which children can inherit (or not). To do IPC with a server process, simply mount it and begin reading and writing to files in the mounted directory. Oh, and 9p is network-transparent, so you can see remote files and processes as if they were local.
It really is a neat idea, and shows what can be done when you take an idea to its logical extreme. But the interface is not human friendly. Real-world workloads are complicated and require kernels that handle the weird edge cases so you can't reduce a production kernel to a simple idea. And 9p performance lags behind other networked file systems. So it's really more of a prototype and a laboratory for generating ideas to be used in other systems, rather than a replacement for production Unix.
In a nutshell, and somewhat simplified: it cleans up the /dev/ interface and turns everything into streams of characters and mounts. So rather than a bunch of messy ioctls and other out-of-band mechanisms it just works with streams. This is nice because it allows you to use remote resources as if they're local.
Distributed name spaces, distributed computing, compute servers, distributed file servers and so on.
Remember the SUN slogan 'the network is the computer'? Plan 9 makes that a reality.
In Plan9 UNIX's ”everything is a file” philosophy is reaffirmed in a heightened and enhanced form, and all resources (CPUs, even) on a distributed network can be mounted with a simple protocol and accessed remotely. These namespaces make it possible to provide each and every program with its own namespace (to the point of being able to run a copy of the window manager within itself). For example you have /net directories with all the TCP ports in /net/tcp and those can be concatenated to forward ports or even create routers. It's amazing.
I've played with Pla9 a bit and I find it overall interesting. Here are the things from the top of my head that are improvements over Unix:
- Truly everything is a file. No exceptions; no special cases.
- Symlinks do not feel like a hack causing trouble. If you need a reference to a directory in another path, you mount it. If your software writes its binaries into its custom directory and you want the binaries within the $PATH, you mount that custom directory into /bin (or so, from what I remember).
This is seriously underappreciated IMO. You can entirely replace access control with private namespaces without any real loss in generality. In fact, they're more flexible and secure.
And actually that's exactly what the FreeBSD Jails paper says too. Their aim was to make uid 0 more granular by segmenting the system so that you have different access control in those jails.
You see some of these ideas in Linux, but as with all Linux kernel technologies they all feel like they've not been written with a design in mind from the start (just look at epoll, namespaces, /proc, and so on).
All UNIX flavours are pretty late to the party though, even plan 9. This sort of isolation was a feature of most capability operating systems since the 60s.
It's probably more accurate to say it was intended to be the successor of UNIX. Plan 9 was developed by the same group that developed UNIX (Bell Labs) with many of the same prominent people credited with C and UNIX; Rob Pike, Ken Thompson, Dennis Ritchie.
It's a truly distributed operating system and it's unix taken to it's logical conclusion. Everything is a file and everything is network transparent, thanks to 9P. The first wikipedia article is very worthwhile reading - this is a little except that gives you the idea:
> "Unix allows file systems to be built up from disparate resources using concepts such as links and file system mounts. These features masked the original directory; if one mounts a new filesystem on the directory named "net", one can no longer access its previous contents until the operation is reversed.
> Plan 9 introduced the idea of union directories, directories that combine resources across different media or across a network, binding transparently to other directories. For example, another computer's /bin (applications) directory can be bound to one's own, and then this directory will hold both local and remote applications and the user can access both transparently.
> Using the same system, under Plan 9 external devices and resources can be bound to /dev, allowing any device to be shared over the network without any additional code."
So, you can union mount other machines /dev/cpu/ folders into your machine's /dev/cpu folder and then have access to all the CPU's. Same for all other hardware, software and storage.
Just these two things - Union Mounts and 9P - when built into the whole system, create a very dynamic distributed computing environment. I really, really wish more of this would make it into Linux. We've kinda got some of it, but without joining up all the other bits, the real power isn't quite there.
"Just these two things - Union Mounts and 9P - when built into the whole system, create a very dynamic distributed computing environment. I really, really wish more of this would make it into Linux."
Union mounts and 9P are already available in Linux.[1][2] What other things would you like to see?
Union mounts only went into the linux kernel 3 years ago (2014) - and have lots of limitations.
It's also not really a central concept. plan9 doesn't have a $PATH env var, for example - you just union mount all your binaries into `/bin`.
Again, yes there's an implementation on 9p for linux - but it's not baked in and it's not used by the system as a unifying abstraction - this makes it fairly useless:
> Unlike most other operating systems, Plan 9 does not provide special application programming interfaces (such as Berkeley sockets, X resources or ioctl system calls) to access devices.
> Instead, Plan 9 device drivers implement their control interface as a file system, so that the hardware can be accessed by the ordinary file input/output operations read and write.
> Consequently, sharing the device across the network can be accomplished by mounting the corresponding directory tree to the target machine.
