8 ms·

Imagine if everything they told you about Unix was true. Plan 9 is the operating system Bell Labs made after Unix, to fix many of the problems the designers saw

Imagine if everything they told you about Unix was true. Plan 9 is the operating system Bell Labs made after Unix, to fix many of the problems the designers saw. 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.

rakoo 6y ago
The interesting conclusion of all this is that if everything looks like a file, then it doesn't matter what OS it runs on. A /dev/screen can be on your local Plan 9, on a remote Windows or on your Linux VPS; as long as it respects the protocol it doesn't matter. Plan 9 is the host of all this experiment but its findings can be (and have been) imported in other places.
- dale_glass 6y ago
  Is that actually useful in practice? 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.
  - floren 6y ago
    In my work, there's not much which requires updating a full HD screen at 30 fps... video calls, I suppose. Everything else updates small portions of the screen at lower rates. 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.
    - cycloptic 6y ago
      I'm guessing these applications do not have any kind of animations or smooth scrolling? That would be a simple test, make your web browser or your image viewer fullscreen in 4K and see if there is lag in the scrolling/panning/zooming.
  - hnedeotes 6y ago
    There's been some post about upscaling algorithms here lately, perhaps they could be used for diminishing the required bandwidth?
  - effie 6y ago
    You are seriously overestimating the needed throughput in practice. 60fps 1080p can be streamed with good quality over 16Mbps channel (2MB/s). The real problem is lack of good open source software that will eliminate the annoying latency due to desktop protocols (Xorg...). There are things such as SPICE or X2GO or RDP which are "OK" but I suspect much better experience is possible. The computers are extremely fast already but our software is so bad we can't see it.
    - MrDOS 6y ago
      178 MB/s is a calculation, not an estimate: 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.
      - ori_b 6y ago
        Images can be compressed when using devdraw. The compression formats are relatively primitive, but they're good enough in practice. Slotting in better ones seems like it should be straightforward, though video codecs don't fit cleanly.
      - effie 6y ago
        So what is your estimation of simplicity of using video compression there? Is it possible?
    - dale_glass 6y ago
      But once you introduce a piece of software into the middle to make this usable, what's the actual difference between this and just using VNC? 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.
      - vidarh 6y ago
        You're right that it doesn't matter if it's a file or not per se. 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.
  - jdsully 6y ago
    178MB/s is under 1.5 gb/s. It’s only because we’ve been stuck with slow gigabit Ethernet for 20 years that we think this is a hard problem. 10G ethernet can do it no problem and fractional speed like the 2.5 and 5 gigabit standards should have little issue as well.
    - dale_glass 6y ago
      I concur that it sucks that Ethernet is in a rut for some reason. 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.
      - jdsully 6y ago
        10G switches are old hat and can do full x-bar switching at 10G, unless your using very old tech got off ebay you shouldn't have issues. 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.
    - mjevans 6y ago
      I've speculated it's the patents on 10G over copper holding us back. IIRC we're just about at the point where the early over fiber modes are off patent in the US. 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.
  - rakoo 6y ago
    /dev/screen was an example, in practice as said in the sibling comments you'd use drawterm which fulfills roughly the same usecase as what ssh or RDP do, so yes, the use is there. And you may not need a full HD screen at 30 fps to work 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.
  - deleted 6y ago
    [deleted]
  - mulmen 6y ago
    I think this looks at the benefit backwards. 9p allows resources to be where they make sense and abstract the location from the usage. Running a display over the network might not make sense but with 9p it also isn't necessary. 9p itself allows me to run my GUI locally while the data and processing live elsewhere.
  - chillfox 6y ago
    I can see it being very useful for events, call centers, or any kind of operations center where you want a lot of screens.
fnord123 6y ago
> and in many ways are still lightyears beyond what we have now. 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).
- ori_b 6y ago
  > I think this wildly overstates it. Much of the good innovations have been adopted in Linux. 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.
  - cycloptic 6y ago
    >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 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 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.
    - ori_b 6y ago
      > 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.
PeterWhittaker 6y ago
Many years ago (30?), the Plan 9 shell, rc, was made available for other platforms. I was working at the Big Nerd Ranch and ran it everywhere I could (I was doing 2nd/3rd level support work that gave me unfettered privileged access almost everywhere), until the nascent in-house software release process (SRP) caught up and sudo started becoming more widespread and privileged access started getting locked down. 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.
- LukeShu 6y ago
  I was going to say, 30 years ago, the 1st edition of the actual Plan 9 wasn't yet released (not until 1992), much less a clone/port of its shell. But it seems that Byron Rakitzis wrote his Unix clone of `rc` in 1991 before Plan 9 was even out! He based it on Tom Duff's paper which described Plan 9's shell. (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.)
  - byronr 6y ago
    Yes, I did! I used Duff's paper as a reference, and relied on the good taste of all my beta testers to guide me towards a working shell. Back when source code was distributed via shar files in an email.
    - PeterWhittaker 6y ago
      Thanks for writing rc! I’d forgotten about Duff’s paper and the exact circumstances of rc’s release until I read LukeShu’s and your replies. I had a lot of fun with rc....
      - byronr 6y ago
bitmapbrother 6y ago
>and in many ways are still lightyears beyond what we have now I'm struggling to find these ideas that are lightyears beyond what he have now.
outworlder 6y ago
> and in many ways are still lightyears beyond what we have now. How close were they to Lisp Machines? :)
- anthk 6y ago
  Just build tiny Scheme compiler for plan9, anything with r5rS support and call it a day.
williesleg 6y ago
No, it's not.

rakoo 6y ago

The interesting conclusion of all this is that if everything looks like a file, then it doesn't matter what OS it runs on. A /dev/screen can be on your local Plan 9, on a remote Windows or on your Linux VPS; as long as it respects the protocol it doesn't matter. Plan 9 is the host of all this experiment but its findings can be (and have been) imported in other places.

dale_glass 6y ago
Is that actually useful in practice? 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.
- floren 6y ago
  In my work, there's not much which requires updating a full HD screen at 30 fps... video calls, I suppose. Everything else updates small portions of the screen at lower rates. 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.
  - cycloptic 6y ago
    I'm guessing these applications do not have any kind of animations or smooth scrolling? That would be a simple test, make your web browser or your image viewer fullscreen in 4K and see if there is lag in the scrolling/panning/zooming.
- hnedeotes 6y ago
  There's been some post about upscaling algorithms here lately, perhaps they could be used for diminishing the required bandwidth?
- effie 6y ago
  You are seriously overestimating the needed throughput in practice. 60fps 1080p can be streamed with good quality over 16Mbps channel (2MB/s). The real problem is lack of good open source software that will eliminate the annoying latency due to desktop protocols (Xorg...). There are things such as SPICE or X2GO or RDP which are "OK" but I suspect much better experience is possible. The computers are extremely fast already but our software is so bad we can't see it.
  - MrDOS 6y ago
    178 MB/s is a calculation, not an estimate: 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.
    - ori_b 6y ago
      Images can be compressed when using devdraw. The compression formats are relatively primitive, but they're good enough in practice. Slotting in better ones seems like it should be straightforward, though video codecs don't fit cleanly.
    - effie 6y ago
      So what is your estimation of simplicity of using video compression there? Is it possible?
  - dale_glass 6y ago
    But once you introduce a piece of software into the middle to make this usable, what's the actual difference between this and just using VNC? 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.
    - vidarh 6y ago
      You're right that it doesn't matter if it's a file or not per se. 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.
- jdsully 6y ago
  178MB/s is under 1.5 gb/s. It’s only because we’ve been stuck with slow gigabit Ethernet for 20 years that we think this is a hard problem. 10G ethernet can do it no problem and fractional speed like the 2.5 and 5 gigabit standards should have little issue as well.
  - dale_glass 6y ago
    I concur that it sucks that Ethernet is in a rut for some reason. 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.
    - jdsully 6y ago
      10G switches are old hat and can do full x-bar switching at 10G, unless your using very old tech got off ebay you shouldn't have issues. 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.
  - mjevans 6y ago
    I've speculated it's the patents on 10G over copper holding us back. IIRC we're just about at the point where the early over fiber modes are off patent in the US. 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.
- rakoo 6y ago
  /dev/screen was an example, in practice as said in the sibling comments you'd use drawterm which fulfills roughly the same usecase as what ssh or RDP do, so yes, the use is there. And you may not need a full HD screen at 30 fps to work 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.
- deleted 6y ago
  [deleted]
- mulmen 6y ago
  I think this looks at the benefit backwards. 9p allows resources to be where they make sense and abstract the location from the usage. Running a display over the network might not make sense but with 9p it also isn't necessary. 9p itself allows me to run my GUI locally while the data and processing live elsewhere.
- chillfox 6y ago
  I can see it being very useful for events, call centers, or any kind of operations center where you want a lot of screens.

fnord123 6y ago

> and in many ways are still lightyears beyond what we have now. 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).

ori_b 6y ago
> I think this wildly overstates it. Much of the good innovations have been adopted in Linux. 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.
- cycloptic 6y ago
  >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 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 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.
  - ori_b 6y ago
    > 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.

PeterWhittaker 6y ago

Many years ago (30?), the Plan 9 shell, rc, was made available for other platforms. I was working at the Big Nerd Ranch and ran it everywhere I could (I was doing 2nd/3rd level support work that gave me unfettered privileged access almost everywhere), until the nascent in-house software release process (SRP) caught up and sudo started becoming more widespread and privileged access started getting locked down. 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.

LukeShu 6y ago
I was going to say, 30 years ago, the 1st edition of the actual Plan 9 wasn't yet released (not until 1992), much less a clone/port of its shell. But it seems that Byron Rakitzis wrote his Unix clone of `rc` in 1991 before Plan 9 was even out! He based it on Tom Duff's paper which described Plan 9's shell. (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.)
- byronr 6y ago
  Yes, I did! I used Duff's paper as a reference, and relied on the good taste of all my beta testers to guide me towards a working shell. Back when source code was distributed via shar files in an email.
  - PeterWhittaker 6y ago
    Thanks for writing rc! I’d forgotten about Duff’s paper and the exact circumstances of rc’s release until I read LukeShu’s and your replies. I had a lot of fun with rc....
    - byronr 6y ago

bitmapbrother 6y ago

>and in many ways are still lightyears beyond what we have now I'm struggling to find these ideas that are lightyears beyond what he have now.

outworlder 6y ago

> and in many ways are still lightyears beyond what we have now. How close were they to Lisp Machines? :)

anthk 6y ago
Just build tiny Scheme compiler for plan9, anything with r5rS support and call it a day.

williesleg 6y ago

No, it's not.