Reddit Rants 1 : Plan 9

I'm going to start posting some of the rants I put on reddit that get some traction here as well, for posteritys sake. Because all the crap I've been saying is so important I should imortalize it in blag form forever!

This one was in a thread about plan9, got the most upvotes in the thread I think, and illustrates what it was and why it happened. Consider it a follow up to my attempts at running plan9 after all that research I did.

> I wiki'd Plan 9 but an someone give me a summary of why Plan 9 is important?

1. It was a solution to a late 80s problem that came up, that never was solved because technology outpaced it. Back then, there were 2 kinds of computers - giant room sized behemoth servers to do any real work on, and workstations for terminals. And they barely talked. Plan 9, because of how the kernel is modularized, allows one user session to have its processors hosted on one machine, the memory on another, the hard disks some place else, the display completely independent of all those machines, and they can input somewhere else, and the 9p protocol lets all those communications be done over a network line securely. So you could have dozens of terminals running off a server, or you could just (in a live session) load up the computation server to do something cpu intensive. The entire system, every part, was inherently distributed.
2. It treated every transaction as a single protocol, so that networked and local device access would be done under 9p, and the real goal was to make it so that any resource anywhere could be mounted as a filesystem and retrieved as a file. It had files for every device in the system well beyond what Linux /dev provides, and it had almost no system calls because most of that work was done writing or reading from system files. About the only major ones were read, write, open, and close, which were dynamic on the type of interaction taking place and could do radically different things (call functions in a device driver, mount and stream a file over a network, or read a normal file from a local volume).
3. File systems could be overlayed on one another and had namespaces, so that you could have two distinct device folders, merge them into one in the VFS, and treat /dev as one folder even if the actual contents are in multiple places. Likewise, each running program got its own view of the file system specific to its privileges and requirements, so access to devices like keyboards, mice, network devices, disks, etc could be restricted on a per application basis by specifying what it can or can not read or write to in the file system.
4. This might sound strage, but graphics are a more first class citizen in plan9 than they were in Unix. The display manager is a kernel driver itself, so unlike X it isn't userspace. The system wasn't designed to have a layer of teletypes under the graphics environment, they were discrete concepts.

Plan9 was full of great concepts and ideas in modern OS design. The problem became that it was always a research OS, so nobody tried using it in production. The same reason Minix is pretty low ball - it didn't have a major market driver for adoption. The problem it solved best, distributed systems using heterogeneous compoents spread across a network, became less of a problem as compute power improved, and the growth of the internet allowed similar behaviors to be overlayed on top of complete systems. The overhead of running entire operating systems to utilize network resources has never since been high enough to justify taking some of the radical departures (good ones, I think) plan9 made.
Today, it is kind of old (it doesn't fully support ANSI C, for example, and doesn't use the standard layout of libraries) and while it is realistically possible that if GCC and glibc were ported to plan9 fully, that you could build a pretty complete stack out of already available FOSS Linux programs, the target audience of plan9 is developers who really like dealing with files rather than arbitrary system calls, communication protocols, signal clones, etc.


I'll argue some flaws of plan9 (I also posted a lot of positives earlier up this thread...) on a lower level:

1.  It doesn't support ansi C, and uses its own standard library layout for its C compiler.  Because the OS threw out the sink, porting the GNU coreutils, glibc, and GCC would take a ton of effort.  So nobody takes the initiative.

2.  9p is another case of xkcd-esque standard protocols mess.  Especially today - I would make the argument IP as a filesystem protocol would probably make the most sense in a "new" OS, because you can change local crap much easier than you can change the world from using the internet.  *Especially* since ipv6 has the lower bytes as local addressing - you can easily partition that space into a nice collection of addressable PIDs, system services, and can still use loopback to access the file system (and if you take the plan9 approach with application level filesystem scopes, its easy to get to the top of your personal vfs).

3.  It is *too old*.  Linux of today is nothing like Linux of 1995 for the most part.  Almost every line since Linux 2.0 has been rewritten at least once.  plan9, due to not having as large a developer community, has a stale codebase that has aged a lot.  The consequence is that it is still built with coaxial ports, vga, svideo, IDE, etc in mind rather than modern interfaces and devices like PCIE, SATA, hdmi, usb, etc.  While they successfully added these on top, a lot of the behaviors of the OS were a product of its times when dealing with devices, and it shows.  This is the main reason I feel you have an issue with the GUI and text editor - they were written in the early 90s and have nary been updated that much since.  Compare rio to beOS, OS/2, Windows 95, or Mac OS 8.

A lot of the *ideas* (system resources provided as files, application VFS scopes, a unified protocol to access every resource) are *amazing* and I want them everywhere else.  The problem is that those don't show themselves off to the people who make decisions to back operating systems projects as much.

In closing (of the blog post, now) I still think I'd love to dedicate a few years to making a more modern computing platform that NT / Unix / whatever iOS is. I've illustrated my ideas elsewhere, and I will soon be posting a blog post linking to a more conceptualized language definition of that low-level language I was thinking of (I have a formal grammar for, I'm just speccing out a standard library.