Live data from Hacker News

Linux Namespaces Are a Poor Man's Plan 9 Namespaces

yotam.net

41–50 of 311 posts

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#41
post #15
post #7

Earlier quoted context omitted.

The problem with find is that it tries to put an entire programing language into its arguments.

Hear hear. When I use find I only use it for the recursive dir listing with no arguments. I always pipe it into grep because I know grep better.

Hard to grep a list of path names for size or last modification date?

When I saw the start of this thread, I thought abusing "du" for "find" sounded insane - but after mulling it over - I guess du is just a recursive stat(1).

And I can see the logic; have a tool that builds a tree of metadata, filter with a tool that... filters.

However - as far as i can tell, du/grep on plan9 can't fill in for find(1) - but the idea (above) would probably fit with PowerShell or other "typed/rich streams" kind of shell...

https://man.cat-v.org/plan_9/1/grep

https://man.cat-v.org/plan_9/1/du

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#42
post #9
post #5

Earlier quoted context omitted.

Looking at the Unix to Plan 9 translation [1] gives me a different opinion. To name one egregious example, omitting find(1) in favor of piping du(1) (what is supposed to be a disk usage analyzer) to grep(1) is not an improvement; it's just user-unfriendliness in service of minimalist aesthetics. (Contrary to popular belief, find(1) is not a particularly "bloated" program; Rust's "fd" implementation is under 7,000 lin…

I got used to `du | grep` after using Plan 9 a lot and still do it on Linux, but yeah really I think Plan 9 fans have had a tendency to ossify the pragmatic minimalism of the Bell Labs guys into a sort of cultishness... there's no reason we couldn't have find on Plan 9, but now it's almost a religious point not to have it. On the other hand, the lack of find is not a particularly good rebuttal to the original point.…

The thing that I use find for most commonly is to perform a hierarchical grep, i.e

find . -exec grep -Hn regex \{\} \;

How would you do that with the du | grep combo?

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#43
post #2

As of someone who discovered Plan 9 far too late to do anything about it: everything is a poor man's Plan 9 something. Everything. All of it. Plan 9 lived in the goddamned future.

But what about security?

I haven't really used it but from what I understood at first most of it is very elegant because at the time it was developped all nodes in a network could still be trusted.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#44
post #16

Earlier quoted context omitted.

Just as its sucessor, Inferno. Which is what ChromeOS and Android are mostly today, leaving C to the kernel, or tiny special purpose libs, and everything else in a managed language, Limbo.

And how close is Go to Limbo?

Quite close, unsafe package and method declaration come from Oberon-2 (thanks Robert Griesemer), everything else is somehow inspired from Limbo.

https://www.vitanuova.com/inferno/limbo.html

https://www.vitanuova.com/inferno/docs.html

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#45
post #39
post #2

As of someone who discovered Plan 9 far too late to do anything about it: everything is a poor man's Plan 9 something. Everything. All of it. Plan 9 lived in the goddamned future.

Plan 9 had many improvements over Unix of its times. It opened up too late to conquer the world though. Some good things from it were imported into Solaris and Linux later. Technological progress likes to reinvent itself, looping back to the same idea that did not work last time, and maybe making it a hit finally. Two examples: - Apple Newton, 1992 (a flop) -> Palm Pilot, 1997 (niche success) -> Apple iPhone, 2007 (w…

I personally don't like WASM. I think the Native Client (which is more than a decade old today) was a much better technical solution. It used actual cpu native assembly bundled with a verifier, and had actual good integration into low-level platform APIs like graphics, threading, etc. instead of using this weird Javascript bridge approach. Due to it being native code from the start, it also had none of the startup performance issues, that plague WebAssembly.

WASI also seems like a wrong approach, considering it inherits the limitations of WASM, like problems with memory, allocation and multithreading and hacks needed to overcome them.

VM-s are also kind of a wash for me too, since nowadays the most popular way to run software in a portable/sandboxed manner is Docker, which is NOT cpu-agnostic, even if you ran a JVM app in it, the bundled JVM would be CPU arch dependent.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#46
post #25

Earlier quoted context omitted.

It is, but for what it's worth using the mouse is much more pleasant than what we're used to ime. It's weird at first, especially with the teleporting thing but it works really well. Also, if you're gonna try it do it either with a proper three-button mouse or with a large-ish and easy to press scroll wheel button. Otherwise it's really frustrating.

Just the idea of context switching from mouse to keyboard is so annoying to me outside of graphic editing. I installed vinium for firefox recently and it has been a game changer.

That's fair and I share the sentiment to some degree, especially in "regular" systems. In the time period I used plan 9 I quickly got used to it though, and the method of interaction made me a bit slower and much more considerate. I liked it a lot. I still miss it. I'll probably try it again some time.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#47
The simple, everything is a file, model of Plan9 is what makes the namespaces API as clear and as general as it is. All the objects export the same file API. Every interaction with the OS objects is done through file open, create, read, write, etc. But it has it's drawbacks.

First, it's not always easy to map every object operation into either an open read or write. With time, we should have seen a lot of ugly interfaces resulting from this limitation.

Second, hardware progress, the web, etc., introduced a lot of heterogeneity and complexity. People could no more keep up with simple general designs. And to squeeze every bit of performance, everyone was doing things different based on the hardware and the workloads. They use whatever makes their software, drivers, and OS objects work as fast as they could.

And this is how we ended with the extreme fragmentation and heterogeneity we have in Linux, which explains the complex and less general implementation of its namespaces and its other features.

Edit: fix typos

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#48
post #2

As of someone who discovered Plan 9 far too late to do anything about it: everything is a poor man's Plan 9 something. Everything. All of it. Plan 9 lived in the goddamned future.

The same person who is involved with Plan 9 also made Go. Taking one look at that programming language doesn't leave me very optimistic about Plan 9.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#49
post #23

Everything as a file was an interesting architecture in the 70s. The whole system was dependent on that model so it made total sense. In the 00s and beyond I thought everything as a service was a better model. Called through an API. Basically RPC. But even that has failed. It's very difficult to approach a new system from that perspective. I think you can design a protocol to say what the model of interaction should…

>Called through an API. Basically RPC

This doesn't map well to hardware

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#50
The three most used desktop operating systems look and feel archaic. They aren't very different from the oses of two decades ago.

BeOS still looks more advanced in some aspects than Windows, Linux and MacOS.

I expected lots of advancements to take place in the OS space in 20 years.

Post reply on HN