[emin_gun_sirer]

Plan 9 is "Unix done right." Think of everything everyone loves about Unix, especially its ability to connect components together via pipes and plain text files, and take it to the limit, and you'll get Plan 9.

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/

[rdtsc]

The problem with Plan 9 wasn't that it wasn't great. It was amazing, the problem was that Linux (and other *nix-es at the time) were also kind of good.

Maybe plan 9 was a bit before its time. Had it been developed today when distributed systems and big data is more talked about, it might have had a bigger impact.

[enneff]

I have heard Rob Pike describe Plan 9, or at least the kernel, as "The most object-oriented system ever built," (apologies if I paraphrased incorrectly). He was referring to the fact that everything satisfies one simple interface, and so everything can be plugged into almost anything else.

[emin_gun_sirer]

Right, everything is a filesystem in Plan 9. It's really elegant. Many people think Unix is elegant, which it is, but then they realize there is a higher plane of elegance in interface design when they encounter Plan 9.

In case anyone is wondering how the Plan 9 approach could accommodate special devices and so forth (i.e. objects that do not conform exactly to the same interface), there is an escape hatch called a control file, and you can do the equivalent of an ioctl by writing device-specific commands to the control file. But by and large, P9 represents everything as a filesystem and thus makes it really easy to reconnect the piping any which way the user likes.

Every hacker needs to see Plan 9 in action.

[Serow225]

How does it compare to the way BeOS was built?

[1337p337]

BeOS and Plan 9 have such different concepts of OO that they're hard to compare. In BeOS, there's a C++ interface your applications have to conform to, and it's somewhat machine-centric. Your objects are live processes in memory.

Plan 9 guys tend not to like the design of HTTP ( http://http02.cat-v.org/ ) so don't tell anyone I used this illustration, but Plan 9 is OO similar to the way REST is.

In Plan 9 (and Inferno) your objects can be files on disk, structs in memory, devices, etc. Anything that can conform to the interface. The interface in this case is files. Your objects expose a filesystem, and you interact with them by means of the usual tools for file manipulation. The Acme editor exposes a filesystem, the clipboard ("snarf buffer") is a file, and the network is, instead of a group of special syscalls, a filesystem. So you could write a shell script that reads a URL from the snarf buffer, downloads the page it points to, and puts the content into a new window in Acme, in three or four lines, without using anything more complex than cat and echo.

[zobzu]

I'm generally annoyed to see Linux go the "poettering" way instead of the Plan9 way. It feels like going backwards - and unfortunately - every few people are knowledgeable enough to understand this, or care

[1337p337]

It's certainly disappointing. There's been this furious obsession with "getting Linux onto the desktop", which lead to misguided attempts to dumb the OS down to the level that a Linux hacker thinks works for a "normal user". The efforts seem to have proven mainly that Linux hackers don't understand "normal users" and that, given enough determination, you can reimplement a broken version of Windows on top of any OS.

And then your config files get config files (GRUB2, Debian/Ubuntu network configuration, ...) as the horrifically bad design decisions made on behalf of the nonexistent "Linux desktop users" get pushed onto the server that you have to actually deploy working code onto. It's enough to drive a man to drink...or at least it's driven me to Inferno and Plan 9.

[zobzu]

Man, that rhum bottle is so tempting now

[pi18n]

One of the most interesting things to me is that Plan 9 did per-application sandboxing before and better than the broken implementation Apple is trying to do now. When every device driver is manipulated by writing to a file, one only needs to restrict access to the file to prevent net access. And Plan 9 has a filesystem that allows you to mount over specific files for a single process which is just so much more powerful than chroot.

[krakensden]

> Contrast this with the "Poettering-approach" to Pulse Audio: klunky, specialized, complex, and ultimately broken

I am skeptical. PA had teething problems, but on the other hand, they kept compatibility with ALSA, they kept compatibility with ESD. /dev/dsp had been known-to-be-broken for ten years or so when PA was released- and after the kernel added the necessary bits, osspd was released.

The PulseAudio rollout was a disaster, but it wasn't architecture that was the problem.