What's Plan9?
That said, it's based around what the designers of Plan 9 thought were problems with Unix. It's a very opinionated operating system. But it has so many ideas that were ahead of their time, and in many ways are still lightyears beyond what we have now.
It's a really cool piece of computing history, and if you haven't tried it, I suggest you look into it, but keep in mind that even though it looks and sometimes feels like Unix, it very much is not. It's not terribly useful as a daily driver OS due to a lack of software, but it's very, very cool.
When you're talking about things like displays, performance is extremely important. We're talking about 178MB/s to update a full HD screen at 30 fps, which requires networking pretty much no normal user has.
There's a program called drawterm which implements Plan 9 graphics devices on Linux. You run drawterm locally, connecting to a Plan 9 system, and your applications on the Plan 9 system draw to your drawterm window over the network. I regularly run it at 4k and it performs quite well.
1,920 x 1,080 pixels @ 24 bits/pixel = 6,220,800 bytes/frame
30 frames/s = 186,624,000 bytes/s = 177.98 MiB/s
You are seriously underestimating the simplicity of plugging in a video encoder.
At that point it doesn't really matter if the screen is a file or not -- you need a compressor that can easily provide the output on a network socket, and a client that can perform the decoding.
What matters - and what the file interface gets you, but you can do the same thing in many other ways - is introducing the concept of a generic pluggable, chainable API.
10G ethernet can do it no problem and fractional speed like the 2.5 and 5 gigabit standards should have little issue as well.
But even on 10G that's no picnic. Sure, that works for a single user, but add a few more people and it's not hard to run into trouble. Such a system can't for instance just drop frames when the network is overloaded which to me makes this more of a curiosity than something anybody would actually want to use in practice.
Trunk lines of 100G and higher are pretty common in core networks now, if your big enough to span a single switch. The main limit was we had trouble doing 10G over cat-5e copper with long distances. 2.5/5 solve that problem and 10g is possible with cat-6. Fibre has no issue with super high rates for network backhauls to aggregate all that traffic.
With the exception of the copper standards all of this has been roled out in the datacenter for years and is pretty mature.
However the 10G (over copper) encoding format uses a complex forward error correction encoding that is a bit energy intensive, it also adds some latency. A smaller silicon production node and this being used outside of SERIOUSLY EXPENSIVE for pro-sumers / medium businesses would instigate a drop via commodity.
But it doesn't stop there. Wanna play local music remotely ? /dev/audio is there for that. Want to use a machine as a jump server ? Just mount their /net folder into yours and any network operation will go through them.
The ideas can be used today. I have a folder of Music with only lossless songs for personal reasons, but it's obviously not perfect for playing from my phone because of how large they are. So I had a server that transcoded them to Vorbis on-the-fly and served them with FUSE, and a sshfs on top of that to serve the transcoded fly to my phone. This composition of a common interface might use no line of code from Plan 9 but it definitely reuses its philosophy.
I think this wildly overstates it. Much of the good innovations have been adopted in Linux. 9p exists. /proc was adopted (though that was in UNIX first).
One unifying principle of plan9 is that everything is a file. But the (POSIX) file api has a lot of limitations. Fuschia, in contrast had some nice ideas about different types of file (blob/object, log, etc).
The main innovation can't be done by addition. With plan 9, many special cases are removed. You no longer have to wonder what happens if you try to create a Unix socket on an NFS file system, and then mmap it: There's just 9p. Everywhere.
9p is nice, but it isn't special. Making the whole universe 9p is where the improvement lies.
How does that work? I don't know the details of any implementation, but 9p the protocol appears not to have any concept of mmap: https://9fans.github.io/plan9port/man/man9/intro.html
I think I see what you mean about 9p not being that special, it doesn't seem much different than if Windows decided to export every system-level API as a DCOM object, that would also get you the same kind of "the whole universe is networked" kind of deal.
The difference is that in Plan 9, there is no 'if', and there's no other option for accessing resources. All programs interface with the OS and other programs via 9p, more or less: Notable exceptions are process creation calls like rfork() and exec().
> but 9p the protocol appears not to have any concept of mmap:
Correct. Mmap is a kernel feature -- and mmap style stuff is only really done for demand paging of binaries at the moment. You get a cache miss and a page fault? Backfill with a read. Backfilling IO on page fault is really all mmap does, conceptually.
That seems like it would create difficulties in porting software there. Please correct me if I'm wrong but the original plan9 appears to also have no support for shared memory or for poll/select.
>Backfilling IO on page fault is really all mmap does, conceptually.
For read-only resources yes, for handling writes to the mmapped region, that seems quite broken.
> For read-only resources yes, for handling writes to the mmapped region, that seems quite broken.
No more broken than mmap of nfs. Consistency is hard.
Right, I get that's what you meant, it doesn't seem to really change much versus NFS, or DCOM, or whatever. So it's unclear what benefit is being provided by 9p here.
Also upon further research I am not sure what you mean by this is the only option, plan9 seems to suggest use of channels for other types of IPC interfaces, which seem to not be the same as 9p and are not necessarily network serializable. (Or are they?)
There are few magic kernel devices that don't act like 9p, like '#s' which implements fd passing on a single node. And the VGA drivers expose a special memory segment on PCs to enable configuring VGA devices.
But the exceptions are very few and far in between, and affect very few programs.
> So it's unclear what benefit is being provided by 9p here.
A uniform and simple API for interacting with out-of-process resources that can be implemented in a few hundred lines of code.
I guess I just don't see what is conceptually the difference here versus something like doing basic HTTP over a TCP socket, it seems like the same kind of multiplexing. Either way, you still have to deal with the same issues: can't pass pointers directly, need to implement byte swapping, need another serialization library if you want the format to be JSON/XML or if you want a schema, etc... So in cases where that stuff isn't important, channels would come in handy, but of course that is now getting closer to a local Unix IPC. Am I getting this right?
A thread reads them from a file descriptor and writes them to a channel. You can look at the code which gets linked into the binary:
/sys/src/libdraw/mouse.c:61
while(read(fd, event)){
parse(event);
send(mousechan, event);
}
And getting the FD is also done via 9p, which means that it naturally respects namespaces and can be interposed. For example, sshnet just mounts itself over /net, and replaces all network calls transparently for all programs in its namespace. Because there's no special case API for opening sockets: it's all 9p.
To me the problem with saying "no special cases" seems to make it quite limited on the kernel side and prevent optimization opportunities. For example if you look at the file node vtables on Linux [0] and FreeBSD [1] there are quite a lot of other functions there that don't fit in 9p. So you lose out on all that stuff if you try to fit everything into a 9p server or a FUSE filesystem or something else of that nature.
[0]: https://elixir.bootlin.com/linux/v5.11.8/source/include/linu...
[1]: https://github.com/freebsd/freebsd-src/blob/master/sys/kern/...
I don't have to use the network stack from my machine, I can grab it from the network gateway. NAT gets replaced with mount.
I don't have to use the debug APIs from my machine, I can grab them from the machine where the process is crashing. GDB remote stubs get replaced with mount.
You see the theme here. Resources don't have to be in front of you, and special case protocols get replaced with mount; 9p lets you interpose and redirect. Without needing your programs to know about the replacement, because there's a uniform interface.
You could theoretically do syscall forwarding for many parts of unix, but the interface is so fat that it's actually simpler to do it on a case by case basis. This sucks.
* In kernel devices can add some hacks and special magic, so long as they still mostly look as if they're speaking 9p. This is frowned upon, since it makes the system more complex -- but it's useful in some cases, like the '#s' device for fd passing. This is one of the abstraction breaks that I mentioned earlier.
> The debug APIs can still only return a direct memory mapped pointer to the process memory as a special case
Can you point to the special case here?
http://man.cat-v.org/plan_9/3/proc
Because it replaces ptrace, and seems to work perfectly fine when I mount it over 9p. It's used by acid, which needs no additional utilities: http://man.cat-v.org/plan_9/1/acid
> If you want to add compression to your VNC thing
Images may be sent compressed. More -- or at least better -- formats would be good, but this is done.
http://man.cat-v.org/plan_9/3/draw
For a full implementation of remote login using these interfaces, here's the code:
http://shithub.us/ori/plan9front/fd1db35c4d429096b9aff1763f2...
It's a bit complex because it needs to do more than just forward mouse, keyboard and drawing -- signals need to be interposed and forwarded, and there are a few other subtle things that need to happen in the namespace. And because it contains both the client and server code. Even so, it's still small compared to VNC.
And yes, shithub is hosted on plan 9.
> or add some more complex routing to your network setup, you have to start adding special daemons and proxies and translation layers into another socket
Here are the network APIs.
http://man.cat-v.org/plan_9/3/ip
What kind of complex routing are you talking about, and why would it be impossible to implement using those interfaces?
https://devblogs.microsoft.com/commandline/a-deep-dive-into-...
stream-of-bytes was the right idea then. It doesn't mean it is still right.
It failed.
FTFY.
> 9p exists.
A hacked up version called 9p200.u and later on, 9p2000.l which comes laden with posix and unix baggage and of course linux baggage in the lase of .l. This is to handle things like symlinks and special device file hacks inherited from Unix.
> /proc was adopted (though that was in UNIX first).
Linux proc is a mess. Plan 9 proc is just that, the interface to running processes. There's no stupid stuff like /proc/cpuinfo. wtf is that doing in there? http://man.postnix.pw/plan_9/3/proc
> One unifying principle of plan9 is that everything is a file. But the (POSIX) file api has a lot of limitations.
Plan 9 is not posix.
> Fuschia, in contrast had some nice ideas about different types of file (blob/object, log, etc).
A file is an array of bytes. Why complicate that simple approach?
Do you think Plan 9 /proc would have remained as "clean" over time if it were as popular as Linux?
One thing that seems to be something of an axiom is that popular interfaces become messy over time. The location of /proc/cpuinfo seems to be an individual act of vandalism rather than being due to fundamental differences in underlying philosophy/approach.
If people are allowed to submit "functionality" patches ad-hoc with little to no scrutiny or thought, then yes, any project will become a mess.
The general approach taken by plan 9 maintainers is to question functionality/feature patches and ask "Who does this benefit?" If the answer is only the submitter or rare edge cases then the patch is rejected. If the patch benefits a large audience, then it is accepted.
But to be fair, Linux is hammered on by large corps who's only goal is to make money by vomiting webshit from Linux servers. They don't care about simplicity, technical details, correctness, or anything like that, so long as it increases their bottom line. From my point of view the Linux I came to love is long dead.
A lot of the appeal of Plan 9 is that it's not widely used, and so has remained opinionated. It's not a general use operating system. It's a research operating system.
At that point, I needed muscle memory across all machines more than anything else, and switched back to sh (bash was still very new and not widely available, csh was born borked, and ksh was only available under certain OSes). That was sad.
rc had a beautiful, clean C-like syntax without any csh weirdness and was much more powerful than sh. Scripts were a joy to write and maintain.
(Plan 9's `rc` was originally written for 10th edition Unix, and would later get ported back to Unix as part of Russ Cox's plan9port in 2003.)
I had a lot of fun with rc....
PS1="$(hostname)=; "
How close were they to Lisp Machines? :)
Plan 9 from Bell Labs is a distributed operating system, originating in the Computing Science Research Center (CSRC) at Bell Labs in the mid-1980s, and building on UNIX concepts first developed there in the late 1960s. The final official release was in early 2015.
Under Plan 9, UNIX's everything is a file metaphor is extended via a pervasive network-centric filesystem, and the cursor-addressed, terminal-based I/O at the heart of UNIX-like operating systems is replaced by a windowing system and graphical user interface without cursor addressing, although rc, the Plan 9 shell, is text-based.
“Starting in the late 1980s, a group led by Rob Pike and UNIX co-creators Ken Thompson and Dennis Ritchie developed Plan 9. Their motivation was two-fold: to build an operating system that would fit an increasingly distributed world, and to do so in a clean and elegant manner. The plan was not to build directly on the Unix foundation but to implement a new design from scratch. The result was named Plan 9 from Bell Labs – the name an inside joke inspired by the cult B-movie "Plan 9 from Outer Space."
Plan 9 is built around a radically different model from that of conventional operating systems. The OS is structured as a collection of loosely coupled services, which may be hosted on different machines. Another key concept in its design is that of a per-process name space: services can be mapped on to local names fixed by convention, so that programs using those services need not change if the current services are replaced by others providing the same functionality.“
It's of course not relevant in the current context but still fun so I dare add that it is famous because it's so bad. It's known as "worst movie ever". It is worth watching the start and a few scenes - even if one does not have the patience for the whole thing - just for some laughs. It already starts (4 minutes in) with a scene in a hilarious airplane cockpit, which does not look like one at all (those controls..!). The zombies are really funny too.
Full movie: https://youtu.be/Ln7WF78PolA
One of the reviewers of ‘Manos’ says: “What can I say about a movie so bad that it makes Plan 9 From Outer Space look like Casablanca?”, another “I have endured a thing or two in my life: Plan 9 from outer space. Hercules against the moon men. Godzilla versus Megalon. German musical comedies from the early sixties. However, THIS was too much for me. About one hour or so into the movie, I quit.”
I am very glad I had alcohol to go with it.
"Manos" is worse to the extent slogging through it is a chore, at least without commentary to add some entertainment value.
Well explained in this PDF.