9 ms·

Bell Labs' Plan 9 research project looks to tomorrow (1990)

100 points by rmbryan 5y ago

stormbrew 5y ago
The most frustrating thing to ever happen to the concepts in plan9 is the funhouse mirror distortions of them that have landed in the linux world. They look just enough like plan9 that people think they represent those ideas, and so they have no idea how powerful those ideas can actually be and don't even know that they don't know it. We'll never have any of the things it really promised until we give up on POSIX, tbh.
- yjftsjthsd-h 5y ago
  > We'll never have any of the things it really promised until we give up on POSIX, tbh. What about POSIX is in conflict with Plan 9? I would have called Plan 9 a subset of POSIX
  - jacquesm 5y ago
    A good starting point: http://9p.io/sys/doc/ape.html http://9p.io/sys/doc/ape.html Note that this - as almost everything else that is plan 9 related - is dated.
  - stormbrew 5y ago
    I would call it maybe vageuly similar, but it is by no means a subset. It has some features in common and many that are completely nonsense in a posix context. The most pressing problem for implementing plan9-like semantics in a POSIX system is the permission system. In particular, setuid as a mechanism for privilege escalation. This is a big part of why users can't make their own namespaces on linux without help/intervention from root-owned processes (like dockerd or systemd). Think about it: if you can make the file namespace any shape you want, and then run `sudo`, which is a setuid process that looks at /etc/sudo.conf to decide whether your escalation is allowed, how do you secure it? How do you even begin to do distributed permissions if everything's looking at /etc/passwd and /etc/group in the current process' namespace to decide who you are? POSIX is very much built on the idea of a canonical view of the filesystem, and plan9 is built on a vfs that may as well be sand.
    - lizknope 5y ago
      Capabilities were supposed to split up the need to having a single root account that could do everything. I'm not sure how far it has gone. https://tbhaxor.com/understanding-linux-capabilities/ https://tbhaxor.com/understanding-linux-capabilities/ https://blog.container-solutions.com/linux-capabilities-in-practice https://blog.container-solutions.com/linux-capabilities-in-p...
      - stormbrew 5y ago
        They're a good step but they're really a step in a different direction, even though capabilities are at the heart of how plan9 does permissions as well. Plan9 capabilities are more like kerberos tokens, so you get them from privileged services and then can use them to perform privileged actions. Linux capabilities don't really change any of the issues around namespace security because they don't inherently provide a way to elevate privileges without setuid.
    - DarylZero 5y ago
      In modern Linux this is no problem. You can now give a process its own UID namespace. In the calling namespace its UID is non-zero, but in its own namespace it's root.
      - ori_b 5y ago
        You understood the problem backwards. How do you give out actual, real, global root, without taking away the ability to do arbitrary namespaces?
        DarylZero 5y ago
        I think you're right that I don't understand the problem. If you want to give actual real global root, I think you can do it by having a gifting process put the real global root process into the same process namespace as the giftee process.
        5y ago
  - turminal 5y ago
    Pretty much everything is in conflict. POSIX standarized and attempted to unify a dozen different incompatible systems that developed independently on top of the original unix from bell labs. Those systems were developed by building new functionality on top of what unix provided. In order to keep at least some sort of compatibility the old and at times obsolete functionality was kept in the system. Plan 9 on the other hand intentionally broke compatibility with its predecessors and had those same features that were glued recklessly on top of each other in various unices thoughtfully redesigned from scratch, often omitting stuff that didn't seem relevant enough to its authors.
    - pjmlp 5y ago
      Additionally it also took the role of being C's standard library that ISO C did not want to take upon themselves.
  - ori_b 5y ago
    The number of special cases. For example: consider how you'd write some generic code to forward all ioctls transparently across the network. Keep in mind that the data attached to the ioctls is machine dependent, driver dependent, and has no information about how it's formatted. Every ioctl for every driver is its own special case. Meanwhile, faithfully forwarding all devices in a plan 9 system is trivial. Control messages aren't strictly formatted -- but they're done via reads and writes on file descriptors, so sending them to the devices that understand them, and relaying back the result, is trivial. It's just 9p: https://man.9front.org/5/0intro https://man.9front.org/5/0intro Doing this fully, for all devices (except /srv, which is a bit magical) is implemented here, in a short shell script. This is the remote login program used by 9front, which gives you something resembling ssh or vnc, but with full access to the data and devices on your local machine, graphics, audio, mouse, keyboard, USB, network, and anything else, even if it hasn't been implemented yet. It does both client and server side: https://git.9front.org/plan9front/plan9front/HEAD/rc/bin/rcpu/f.html https://git.9front.org/plan9front/plan9front/HEAD/rc/bin/rcp... The client side sets itself as a file server, using exportfs. It exports everything in its namespace, including /dev, over to the server. The server takes the client's namespace, and mounts it over /mnt/term. Then, it takes /mnt/term/dev/cons and binds that over /dev/cons and starts a shell. That means that every time a program is run, it opens /dev/cons to interact with the user, using the client's mouse, keyboard, and so on, forwarding all the operations transparently over the network. The idea can go further; Instead of using network translation layers, for example, a plan 9 machine would import a different machine's network stack and mount it over itself: # whats my ip? % cat /net/ipselftab 192.168.1.11 01 4u % hget https://api.ipify.org 74.{home.address} # ok, let's import another machine's network stack and use it. % rimport orib.dev /net/ /net # what's my ip now? look ma, I'm proxying! % cat /net/ipselftab 144.202.1.203 01 4u % hget https://api.ipify.org 144.202.1.203 There are no special hooks in the network stack for this. It doesn't know. This happens for free because the network stack being accessible through the filesystem API. This kind of thing happens everywhere, because everything goes through 9p, and everything can be namespaced. There isn't any other special case to consider: If you forward 9p, you forward all operations you can do with a device. Or any other file server. If everything is in a namespace, you don't pull the devices other programs are using out from under them, so you can put one login in one sandbox with a remote mouse and keyboard, and a different one in a different sandbox with a different network stack. This falls apart when you have the 53,719 special cases bundled with posix. If you need a special case for each operation you through the network, or interpose in userspace, you're in for a rough time. Plan 9 works because it's relatively simple and uniform.
- deleted 5y ago
  [deleted]
- tyingq 5y ago
  WSL in Windows uses the 9p filesystem protocol :)
  - yjftsjthsd-h 5y ago
    As does the ChromeOS Linux VM system.
- throwawaylinux 5y ago
  Plan 9 fell to second system syndrome. This will hurt Plan 9 enthusiasts and probably get me flamed but it's my opinion. Not necessarily bloated or inelegant, but over engineered and over confident and missing reasons the first system was successful. Purifying and perfecting some of the concepts from unix is nice, but someone running a file server or CAD program or editing source code or compiling code or running shell scripts and piping a lot of commands together to do cool things with data just does not see a whole lot of incremental benefit beyond what unix gave them. Unix was successful because it was there and accessible and pretty easy and pretty good and evolved quickly (if not always elegantly) to new meet new requirements. For example: purists talk about sockets as some kind of catastrophe. But in all honesty they're not that bad and once you have a few networking tools you can use in shell pipelines you really don't have to have absolute everything as a file. Simple standard composable tools is more important for practical use than everything is a file.
  - stormbrew 5y ago
    Oh I don't disagree with this at all. The main reason I wouldn't ever actually use plan9 day to day on a desktop, which is to some extent the primary use it was designed for (well, thin clients workstations really), is that the whole windowing system is just too alien. I think most of the missteps in plan9 are above the "everything is a file" layer though. And while sockets aren't that bad, I do think I would still rather interact with them in the plan9 way than the unix way if I could.
MarkusWandel 5y ago
Unix with its "worse is better" simplicity steamrollered vastly more complex operating systems (Multics above all). It even steamrollered its own successor. Plan 9 is brilliant, but Unix already served most people's needs so why change. Mental game: If they had managed to quickly push the whole thing out as what is now called open source, while Unix was still proprietary, how would the world look now?
- generalizations 5y ago
  > how would the world look now Computer system security would be vastly superior, I imagine. Webpages would be mounted file systems with restricted permissions systems, and browser apps would be command line utilities. Both would have benefited from the same security that UNIX systems use these days.
  - yjftsjthsd-h 5y ago
    Given that webpages aren't static today, it seems just as likely that in that universe sites would expect you to execute them natively, mounted over 9P. This actually could still work out since Plan 9 did could easily sandbox things, though the security angle would still make me nervous.
  - pcwalton 5y ago
    We've had sandboxing for a decade on mainstream operating systems with mainstream browsers. I doubt that just adopting Plan 9 would offer any meaningful security improvements over the status quo. It would just be switching a big pile of non-memory-safe C++ for a big pile of non-memory-safe C.
    - pjmlp 5y ago
      Well, at least we will be using C Machines in a decade, if the trend for hardware memory tagging keeps going on.
- justin66 5y ago
  > Mental game: If they had managed to quickly push the whole thing out as what is now called open source, while Unix was still proprietary, how would the world look now? An AT&T that was willing to do that would have been willing to let BSDI slide. Linux would have died in the crib and we'd all be using BSD right now.
twblalock 5y ago
One of the best gifts of Plan 9 was static linking: https://9p.io/wiki/plan9/why_static/index.html https://9p.io/wiki/plan9/why_static/index.html Hard drives are cheap, so space is not an argument anymore, for reasonable uses of disk space. And most uses are reasonable! Ah, but you might say, if a shared library is compromised, it's easy to push a fix! But how to you think it got so widely compromised in the first place? Perhaps because it was a widely shared library? Sharing is a double-edged sword. The impetus behind the virtual environments for scripting languages, like Python's venv and Ruby's RVM, is isolation from the base system. Untold developer hours have been lost in attempts to run software with different dependencies than the base system. It's a total mess. We shouldn't expect an operating system to be a monolith that dictates the dependency versions for all the code that runs on it. Code should be deployed in sandboxes and it should be independent of the base system. When the code is removed, it should be like it was never there.
- anyfoo 5y ago
  > Ah, but you might say, if a shared library is compromised, it's easy to push a fix! But how to you think it got so widely compromised in the first place? Perhaps because it was a widely shared library? Sharing is a double-edged sword. Not sure I understand. I imagine without dynamic linking/shared libraries, most widely used shared libraries would be widely used statically linked libraries, and so a vulnerability in them would indeed be harder to fix, as you'd need to relink all the binaries using them instead of just the dynamically linked library? (Also, memory usage seems more concerning to me than disk space. Shared libraries are called "shared" because all their non-mutable pages in memory are shared across processes. To even approximate the same with static libraries, you'd pretty much have to have deduplication of pages in memory. Link-time optimization might then spoil even that plan entirely. Of course on the other hand, dynamic linking precludes LTO for that.)
  - twblalock 5y ago
    You don't re-link binaries. The vendors ship you a new build. Your OS should not have any libraries other than the ones it needs to function by itself.
jiriro 5y ago
Is there a showcase of Plan9’s killer features? For example there is this mandatory covid testing. So each department is handed an excel file and they log the tests. And there is another excel which summarizes those dept’s ones. Can Plan9 be useful in such a situation?
MomoXenosaga 5y ago
And then 1995 happened. https://youtu.be/lAkuJXGldrM https://youtu.be/lAkuJXGldrM
xvilka 5y ago
Rio is unusable in modern world though. They need to adapt or create something new for the touchpad and touchscreen, or keyboard-driven.
- rcarmo 5y ago
  This. So much this. I've used Plan9 on a Raspberry Pi with a mouse, but have never been really able to use it on any kind of modern hardware simply because of the mouse chording anachronisms (which the community is steadfast in considering "perfectly normal")
jakuboboza 5y ago
It looks like they were forward thinking and had a solid idea what will happen / be important in future.

100 points by rmbryan 5y ago

The most frustrating thing to ever happen to the concepts in plan9 is the funhouse mirror distortions of them that have landed in the linux world. They look just enough like plan9 that people think they represent those ideas, and so they have no idea how powerful those ideas can actually be and don't even know that they don't know it. We'll never have any of the things it really promised until we give up on POSIX, tbh.

yjftsjthsd-h 5y ago
> We'll never have any of the things it really promised until we give up on POSIX, tbh. What about POSIX is in conflict with Plan 9? I would have called Plan 9 a subset of POSIX
- jacquesm 5y ago
  A good starting point: http://9p.io/sys/doc/ape.html http://9p.io/sys/doc/ape.html Note that this - as almost everything else that is plan 9 related - is dated.
- stormbrew 5y ago
  I would call it maybe vageuly similar, but it is by no means a subset. It has some features in common and many that are completely nonsense in a posix context. The most pressing problem for implementing plan9-like semantics in a POSIX system is the permission system. In particular, setuid as a mechanism for privilege escalation. This is a big part of why users can't make their own namespaces on linux without help/intervention from root-owned processes (like dockerd or systemd). Think about it: if you can make the file namespace any shape you want, and then run `sudo`, which is a setuid process that looks at /etc/sudo.conf to decide whether your escalation is allowed, how do you secure it? How do you even begin to do distributed permissions if everything's looking at /etc/passwd and /etc/group in the current process' namespace to decide who you are? POSIX is very much built on the idea of a canonical view of the filesystem, and plan9 is built on a vfs that may as well be sand.
  - lizknope 5y ago
    Capabilities were supposed to split up the need to having a single root account that could do everything. I'm not sure how far it has gone. https://tbhaxor.com/understanding-linux-capabilities/ https://tbhaxor.com/understanding-linux-capabilities/ https://blog.container-solutions.com/linux-capabilities-in-practice https://blog.container-solutions.com/linux-capabilities-in-p...
    - stormbrew 5y ago
      They're a good step but they're really a step in a different direction, even though capabilities are at the heart of how plan9 does permissions as well. Plan9 capabilities are more like kerberos tokens, so you get them from privileged services and then can use them to perform privileged actions. Linux capabilities don't really change any of the issues around namespace security because they don't inherently provide a way to elevate privileges without setuid.
  - DarylZero 5y ago
    In modern Linux this is no problem. You can now give a process its own UID namespace. In the calling namespace its UID is non-zero, but in its own namespace it's root.
    - ori_b 5y ago
      You understood the problem backwards. How do you give out actual, real, global root, without taking away the ability to do arbitrary namespaces?
      - DarylZero 5y ago
        I think you're right that I don't understand the problem. If you want to give actual real global root, I think you can do it by having a gifting process put the real global root process into the same process namespace as the giftee process.
        5y ago
- turminal 5y ago
  Pretty much everything is in conflict. POSIX standarized and attempted to unify a dozen different incompatible systems that developed independently on top of the original unix from bell labs. Those systems were developed by building new functionality on top of what unix provided. In order to keep at least some sort of compatibility the old and at times obsolete functionality was kept in the system. Plan 9 on the other hand intentionally broke compatibility with its predecessors and had those same features that were glued recklessly on top of each other in various unices thoughtfully redesigned from scratch, often omitting stuff that didn't seem relevant enough to its authors.
  - pjmlp 5y ago
    Additionally it also took the role of being C's standard library that ISO C did not want to take upon themselves.
- ori_b 5y ago
  The number of special cases. For example: consider how you'd write some generic code to forward all ioctls transparently across the network. Keep in mind that the data attached to the ioctls is machine dependent, driver dependent, and has no information about how it's formatted. Every ioctl for every driver is its own special case. Meanwhile, faithfully forwarding all devices in a plan 9 system is trivial. Control messages aren't strictly formatted -- but they're done via reads and writes on file descriptors, so sending them to the devices that understand them, and relaying back the result, is trivial. It's just 9p: https://man.9front.org/5/0intro https://man.9front.org/5/0intro Doing this fully, for all devices (except /srv, which is a bit magical) is implemented here, in a short shell script. This is the remote login program used by 9front, which gives you something resembling ssh or vnc, but with full access to the data and devices on your local machine, graphics, audio, mouse, keyboard, USB, network, and anything else, even if it hasn't been implemented yet. It does both client and server side: https://git.9front.org/plan9front/plan9front/HEAD/rc/bin/rcpu/f.html https://git.9front.org/plan9front/plan9front/HEAD/rc/bin/rcp... The client side sets itself as a file server, using exportfs. It exports everything in its namespace, including /dev, over to the server. The server takes the client's namespace, and mounts it over /mnt/term. Then, it takes /mnt/term/dev/cons and binds that over /dev/cons and starts a shell. That means that every time a program is run, it opens /dev/cons to interact with the user, using the client's mouse, keyboard, and so on, forwarding all the operations transparently over the network. The idea can go further; Instead of using network translation layers, for example, a plan 9 machine would import a different machine's network stack and mount it over itself: # whats my ip? % cat /net/ipselftab 192.168.1.11 01 4u % hget https://api.ipify.org 74.{home.address} # ok, let's import another machine's network stack and use it. % rimport orib.dev /net/ /net # what's my ip now? look ma, I'm proxying! % cat /net/ipselftab 144.202.1.203 01 4u % hget https://api.ipify.org 144.202.1.203 There are no special hooks in the network stack for this. It doesn't know. This happens for free because the network stack being accessible through the filesystem API. This kind of thing happens everywhere, because everything goes through 9p, and everything can be namespaced. There isn't any other special case to consider: If you forward 9p, you forward all operations you can do with a device. Or any other file server. If everything is in a namespace, you don't pull the devices other programs are using out from under them, so you can put one login in one sandbox with a remote mouse and keyboard, and a different one in a different sandbox with a different network stack. This falls apart when you have the 53,719 special cases bundled with posix. If you need a special case for each operation you through the network, or interpose in userspace, you're in for a rough time. Plan 9 works because it's relatively simple and uniform.
deleted 5y ago
[deleted]
tyingq 5y ago
WSL in Windows uses the 9p filesystem protocol :)
- yjftsjthsd-h 5y ago
  As does the ChromeOS Linux VM system.
throwawaylinux 5y ago
Plan 9 fell to second system syndrome. This will hurt Plan 9 enthusiasts and probably get me flamed but it's my opinion. Not necessarily bloated or inelegant, but over engineered and over confident and missing reasons the first system was successful. Purifying and perfecting some of the concepts from unix is nice, but someone running a file server or CAD program or editing source code or compiling code or running shell scripts and piping a lot of commands together to do cool things with data just does not see a whole lot of incremental benefit beyond what unix gave them. Unix was successful because it was there and accessible and pretty easy and pretty good and evolved quickly (if not always elegantly) to new meet new requirements. For example: purists talk about sockets as some kind of catastrophe. But in all honesty they're not that bad and once you have a few networking tools you can use in shell pipelines you really don't have to have absolute everything as a file. Simple standard composable tools is more important for practical use than everything is a file.
- stormbrew 5y ago
  Oh I don't disagree with this at all. The main reason I wouldn't ever actually use plan9 day to day on a desktop, which is to some extent the primary use it was designed for (well, thin clients workstations really), is that the whole windowing system is just too alien. I think most of the missteps in plan9 are above the "everything is a file" layer though. And while sockets aren't that bad, I do think I would still rather interact with them in the plan9 way than the unix way if I could.

MarkusWandel 5y ago

Unix with its "worse is better" simplicity steamrollered vastly more complex operating systems (Multics above all). It even steamrollered its own successor. Plan 9 is brilliant, but Unix already served most people's needs so why change. Mental game: If they had managed to quickly push the whole thing out as what is now called open source, while Unix was still proprietary, how would the world look now?

generalizations 5y ago
> how would the world look now Computer system security would be vastly superior, I imagine. Webpages would be mounted file systems with restricted permissions systems, and browser apps would be command line utilities. Both would have benefited from the same security that UNIX systems use these days.
- yjftsjthsd-h 5y ago
  Given that webpages aren't static today, it seems just as likely that in that universe sites would expect you to execute them natively, mounted over 9P. This actually could still work out since Plan 9 did could easily sandbox things, though the security angle would still make me nervous.
- pcwalton 5y ago
  We've had sandboxing for a decade on mainstream operating systems with mainstream browsers. I doubt that just adopting Plan 9 would offer any meaningful security improvements over the status quo. It would just be switching a big pile of non-memory-safe C++ for a big pile of non-memory-safe C.
  - pjmlp 5y ago
    Well, at least we will be using C Machines in a decade, if the trend for hardware memory tagging keeps going on.
justin66 5y ago
> Mental game: If they had managed to quickly push the whole thing out as what is now called open source, while Unix was still proprietary, how would the world look now? An AT&T that was willing to do that would have been willing to let BSDI slide. Linux would have died in the crib and we'd all be using BSD right now.

twblalock 5y ago

One of the best gifts of Plan 9 was static linking: https://9p.io/wiki/plan9/why_static/index.html https://9p.io/wiki/plan9/why_static/index.html Hard drives are cheap, so space is not an argument anymore, for reasonable uses of disk space. And most uses are reasonable! Ah, but you might say, if a shared library is compromised, it's easy to push a fix! But how to you think it got so widely compromised in the first place? Perhaps because it was a widely shared library? Sharing is a double-edged sword. The impetus behind the virtual environments for scripting languages, like Python's venv and Ruby's RVM, is isolation from the base system. Untold developer hours have been lost in attempts to run software with different dependencies than the base system. It's a total mess. We shouldn't expect an operating system to be a monolith that dictates the dependency versions for all the code that runs on it. Code should be deployed in sandboxes and it should be independent of the base system. When the code is removed, it should be like it was never there.

anyfoo 5y ago
> Ah, but you might say, if a shared library is compromised, it's easy to push a fix! But how to you think it got so widely compromised in the first place? Perhaps because it was a widely shared library? Sharing is a double-edged sword. Not sure I understand. I imagine without dynamic linking/shared libraries, most widely used shared libraries would be widely used statically linked libraries, and so a vulnerability in them would indeed be harder to fix, as you'd need to relink all the binaries using them instead of just the dynamically linked library? (Also, memory usage seems more concerning to me than disk space. Shared libraries are called "shared" because all their non-mutable pages in memory are shared across processes. To even approximate the same with static libraries, you'd pretty much have to have deduplication of pages in memory. Link-time optimization might then spoil even that plan entirely. Of course on the other hand, dynamic linking precludes LTO for that.)
- twblalock 5y ago
  You don't re-link binaries. The vendors ship you a new build. Your OS should not have any libraries other than the ones it needs to function by itself.

jiriro 5y ago

Is there a showcase of Plan9’s killer features? For example there is this mandatory covid testing. So each department is handed an excel file and they log the tests. And there is another excel which summarizes those dept’s ones. Can Plan9 be useful in such a situation?

MomoXenosaga 5y ago

And then 1995 happened. https://youtu.be/lAkuJXGldrM https://youtu.be/lAkuJXGldrM

xvilka 5y ago

Rio is unusable in modern world though. They need to adapt or create something new for the touchpad and touchscreen, or keyboard-driven.

rcarmo 5y ago
This. So much this. I've used Plan9 on a Raspberry Pi with a mouse, but have never been really able to use it on any kind of modern hardware simply because of the mouse chording anachronisms (which the community is steadfast in considering "perfectly normal")

jakuboboza 5y ago

It looks like they were forward thinking and had a solid idea what will happen / be important in future.