[HN Gopher] Bell Labs' Plan 9 research project looks to tomorrow...
___________________________________________________________________
Bell Labs' Plan 9 research project looks to tomorrow (1990)
Author : rmbryan
Score : 59 points
Date : 2022-01-18 18:09 UTC (4 hours ago)
(HTM) web link (doc.cat-v.org)
(TXT) w3m dump (doc.cat-v.org)
| MarkusWandel wrote:
| 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?
| IshKebab wrote:
| Fewer bugs I imagine. I was reading up on symlinks (trying to
| find a good reference for how much of a bad idea they are) and
| found this: https://9p.io/sys/doc/lexnames.html
|
| Kind of sad that Plan 9 got rid of them literally decades ago
| and we're still stuck dealing with their mess.
| generalizations wrote:
| > 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.
| justin66 wrote:
| > 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.
| stormbrew wrote:
| 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 wrote:
| > 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
| stormbrew wrote:
| 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 wrote:
| 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://blog.container-solutions.com/linux-capabilities-
| in-p...
| jacquesm wrote:
| A good starting point:
|
| http://9p.io/sys/doc/ape.html
|
| Note that this - as almost everything else that is plan 9
| related - is dated.
| ori_b wrote:
| 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
|
| Doing this fully, for all devices (except /srv, which is a
| bit magical) is implemented here, in a short shell script --
| both client and server side:
|
| 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.
| turminal wrote:
| 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.
| [deleted]
| jiriro wrote:
| 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?
| twblalock wrote:
| One of the best gifts of Plan 9 was static linking:
| 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 wrote:
| > 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.)
___________________________________________________________________
(page generated 2022-01-18 23:01 UTC)