It looks like they were forward thinking and had a solid idea what will happen / be important in future.
Bell Labs' Plan 9 research project looks to tomorrow (1990)
41–50 of 75 posts
Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)
#42Earlier quoted context omitted.
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.
What mess?
Read the page, but essentially `/foo/bar/..` is not the same as `/foo`. It makes loads of things way more complicated than you'd expect, e.g. normalising paths now requires filesystem access, and normalising paths that only partially exist is really complicated.
Another annoying issue is symlink loops, but I'm not sure if Plan 9's solution solves that.
Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)
#43Earlier quoted context omitted.
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.
I dunno about the sibling comment's "backwards" comment but the thing here is that the goal isn't to prevent a user process from obtaining privileges, which is what uid namespaces are for. This is the kind of thing I mean about "not knowing what you don't know," because you're looking at namespaces through the lens linux does, which is that they exist to limit capabilities. Plan 9 uses namespaces to allow users to co…
[deleted]
Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)
#44Earlier quoted context omitted.
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.
Well, that's the point. The vendor needs to relink, and now you need to wait for an update from the vendor of each individual client of a library. With shared libraries, replacing the shared library is enough. What I did not understand is how static linking would have precluded the problem in the first place. I don't think that would have made those libraries less widely used.
> With shared libraries, replacing the shared library is enough.
Yes, but if a shared library update includes a bug, it affects all your programs! That's why it is a double-edged sword: The same mechanism that solves the bugs can also deliver bugs.
Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)
#45Unix 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?
Plan 9 would have to contend with a huge install base issue. Remember academics had been using Unix freely since the 1960's and had a massive pile of code plus every machine worth mentioning. Plan 9 would be trying to catch up from a very delayed position.
Woah there, UNIX only reached academic world after UNIX V6, released in 1975 and its first Assembly version was born in 1969, only being released to the world in 1973.
Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)
#46One 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 lib…
This comes up constantly and is pretty easily refuted by opening pretty much any app on an Android or iOS phone and observing just how many pages of the system shared libraries are touched by even the most trivial apps. You can do this by e.g. purging the FS cache, disabling readahead, launching an app, and then observing how many code pages are resident. All of that code would have to be brought into app binary itse…
Including XPC, D-BUS and COM into the picture, which allow for dynamic linking, or if one wants static linking like experience with out-of-process servers, and still there are some issues with it.
Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)
#47The 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, tb…
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.
Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)
#48One 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 lib…
Plan 9 replaces dynamic linking and direct C calls with the opening and interaction with server processess via file streams.
I see two unfortunate issues with that:
1. you lose the ability to use manifest and static types for your interfaces (everything's a text or binary protocol, dynamically typed)
2. you lose performance due to (de)serialization at any interface
Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)
#49One 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 lib…
I don't much care for static linking. I do care about it being too difficult to have multiple versions of the same shared library, and no easy distribution mechanism when I just want to shoot a binary over to some system and run it.
In an ideal world, archives would be well structured executables and my system would automatically deduplicate libraries out of them when they landed on the local filesystem. The linker would automatically pull a whitelist of "known bad" and do overrides for me from my package manager/security source automatically.
Re: Bell Labs' Plan 9 research project looks to tomorrow (1990)
#50Rio is unusable in modern world though. They need to adapt or create something new for the touchpad and touchscreen, or keyboard-driven.
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")