Have you seen the tutorials at the ANTS farm subsite? They show a series of things you can do to explore the 9worker and 9queen in combination with live CDs, which show what I believe are new exciting features for Plan 9 that I have tried to add. There is also a full length paper explaining how I have tried to improve the design of Plan 9 and how I use ANTS on my systems.
Ah, okay. Clicking on the tutorial link and then clicking on the "Overview" link on the site for the tutorial yielded "Creates a new service namespace beneath normal userspace for administration" and "Move between namespaces on demand with rerootwin and other scripts", both of which seem pretty useful. You might want to make a semi-prominent link to the overview.
"Plan 9 is a grid computing platform. It is an effort to provide a computing environment for geographically distributed clusters running on heterogeneous hardware, engineered for modern distributed environments and designed from the start to be a networked operating system.[12] It can be installed as a self-contained system and used on a single computer, but also has the capability to separate its components between separate computers. In a typical Plan 9 installation, users work at terminals running rio, and they access CPU servers which handle computation-intensive processes. Permanent data storage is provided by additional network hosts acting as file servers and archival storage.[13] Currently available desktop computers can emulate this architecture internally using multiple virtual machines."
Anyone else care to explain the elements which make Plan 9 stuff awesome (in noob terms)?
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/
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.
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.
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.
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.
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
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.
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.
> 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.
That Wikipedia article is wrong in all sorts of ways. It was pretty good the last time I seen it, but clearly someone has been editing it who doesn't actually USE Plan 9.
"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.
OK, my other post didn't really "explain the elements which make Plan 9 stuff awesome (in noob terms)". Here is one that attempts to, while not duplicating what's already been said.
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.
