Because everything was a file in Plan 9, tasks that were difficult for Unix were no brainers. Want to redirect your screen from one host to another? No problem, just mount a different framebuffer over the network. Compare that to the X11 monstrosity and its associated specific protocols for remote desktops and screen splitting/sharing and so forth -- in Plan 9, this was just done with mount.

Want to place a mixer on the audio path? No problem, the filter exports a filesystem interface, and you just mount it on top of the actual audio file. Different apps write to what they think is /dev/audio, which turns out to be a pipe to the mixer, which then mixes the signals from different apps and writes to the real /dev/audio. Contrast this with the "Poettering-approach" to Pulse Audio: klunky, specialized, complex, and ultimately broken.

Plan 9 was small, simple and incredibly powerful. Its /proc filesystem had impact on other OSes, notably Linux, but sadly no existing OS comes anywhere near its clean and elegant aesthetic.

There were so many other innovative aspects of Plan 9 (e.g. no superuser, utf-8 for everything, network protocols, the fileserver, the WORM filesystem that retained everything, the editor, the windowing systems, etc) that I cannot hope to be comprehensive, so I picked out its main feature. For the rest, I encourage everyone to read the papers: http://plan9.bell-labs.com/sys/doc/

It's been said already that on Plan 9 you've got the same interface to local and remote resources. That's cool and all, but how many computers have you got, really? And how many of them run Plan 9?

So here's a related example, a corollary almost, of local vs remote.

You see, it isn't just local vs remote, it's also in-kernel vs user-mode. On most systems, you make system calls to ask the kernel to do something for you, and you make library calls to access functionality that's been implemented in user-mode.

In Plan 9, you've got some system and library calls, but for most services you've got the same interface whether they're in the kernel or in user-mode. REgardless of what language they're implemented in, too.

In the 90's, Plan 9's networking interface was a user-mode filesystem written in Alef. The IP stack was, the hardware drivers were in the kernel though.

In 2000 or so it was all moved into the kernel (except the connection server). But it was still a filesystem. The same interface. A service was moved from userspace to the kernel, and the method of accessing it didn't change, so no programs had to be changed, or even relinked or recompiled.

I mentioned the connection server (cs). You wanna know about the cs? Basically, it's a program that understands network types FOR YOU, so you don't have to. You _could_ access the network without cs, but the feel would basically be the same as using sockets: you would have to know whether you're connecting to TCP, UDP, or other, and make different calls accordingly; you would have to know whether your user has passed you a DNS name or an IP address; etc. With cs, you ask cs to do it, and nicely receive a file descriptor to the correct type of network.

That IPv6 support was added without changing any programs is due to cs. This sounds similar to the other example, but it's different. In the first example, the implementation changed but the _types_ of networks supported remained constant. The Blue Gene has all sorts of esoteric networks not used anywhere else. Only thing that had to be done to Plan 9 was write the hardware drivers and teach cs the new networks.

If I could make this post shorter and still have all the same information, I would, honestly. But I could talk for hours about Plan 9.

Plan 9 is basically a redesign where your files and username/password are centralised like on a Unix network with dumb terminals (70s up to mid 80s Unix), but at the same time, you're able to make use of the local resources of your "terminal" like use the CD driver or a scanner or whatever. You have access to them as if you're root.

Plan 9 says: whoever turns the machine on is basically root. If you have physical access to the box, you could theoretically fuck it up any way you wanted, so we might as well just give you root - there's nothing valuable (security wise) on a terminal anyway. Enjoy your CD drive.

The paragraph before the last one is more important than you think. You see, all that other stuff I said about /net, that came afterwards. The original goal was just to have centralised auth and (disk) fs, and stateless terminals. But then, all that other stuff we have in Plan 9 (e.g. network transparency, no real superuser) sort of emerged as a corollary of that first goal.

Other things that Plan 9 users are obsessed with (e.g. mouse chording, output which is usable as input, etc) more fall under the category of things with would be equally easy or difficult to implement regardless of the underlying OS.

I'm really glad we've got all these nice things under one OS, because it's totally conceivable that someone could have designed an OS where (say) everything is a file, but doesn't have (say) clean readable code. We have both, but we also have relaxing colours, mouse chording, easy-to-use concurrency, and a cool mascot.

"To implement [NAT], a union directory can be created, overlaying the [gateway]'s /net directory tree with its own /net"

"Implement NAT"? Sorry, but exportfs doesn't contain any special-case code that says "oh, someone is accessing /net! Better switch on the NAT code!".

There's no actual translation of addresses, it isn't NAT. Plan 9 does have a NAT implementation but it's closed source.

And their example of a bind is horrible. They've got that LONG path into Inferno's "chroot". Inferno isn't part of standard Plan 9, and there aren't many paths in Plan 9 that are anywhere near as long as that. So it's misleading on two counts. If you must have a /bin example of a bind, a better one would be Acme binding its Acme-specific binaries and scripts onto /bin.

I'm really, really going to have clean that article up. It doesn't even have anything about how Plan 9 gets modularity without dynamic linking. Securely.

I like that they added an "Impact" section.