Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Namespaces Are a Poor Man's Plan 9 Namespaces

yotam.net

Post reply on HN
Print view View original

191–200 of 311 posts

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

#191

Post by SkeuomorphicBee »

afr0ck wrote: post #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 interf…

> First, it's not always easy to map every object operation into either an open read or write.

Now a days people are mapping everything to JSON, and it works. The Plan9 directory structure was basically the JSON of the 80s, a hierarchical data structure were the hierarchy is easily navigable in a standard way, and the leafs can then hold any non-standard stuff you may need.

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

#192

Post by rakoo »

pcwalton wrote: post #5
DiabloD3 wrote: 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.

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…

Personal experience: find gets hard to use, and I always have to resort to piping into grep anyway. Maybe I should learn how find works; maybe I should just stick with standard tools. And if `du | grep` gets too long to type, especially with arguments, then that's where I write a script for my common use.

> Rust's "fd" implementation is under 7,000 lines of code

Not counting the 23.8k files, not even lines of code, of rust (https://github.com/search?q=repo%3Arust-lang%2Frust++languag...). Comparison should happen on a similar baseline

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

#193

Post by taeric »

SkeuomorphicBee wrote: post #191
afr0ck wrote: post #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 interf…

> First, it's not always easy to map every object operation into either an open read or write. Now a days people are mapping everything to JSON, and it works. The Plan9 directory structure was basically the JSON of the 80s, a hierarchical data structure were the hierarchy is easily navigable in a standard way, and the leafs can then hold any non-standard stuff you may need.

Mapping to JSON, "works." And usually not in an interop kind of way.

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

#194

Post by adql »

c00lio wrote: post #108
codedokode wrote: post #90

Earlier quoted context omitted.

> it would be great if everything was a file This is a bad design. Process is not a file because you cannot send signals to a file, or cannot debug a file. Network socket is not a file because you cannot get file's peer address. Shared memory is not a file. And so on.

Why would (pseudocode, nonexisting but possible example) write(SIGKILL, "/proc/12345/signals") not be possible? For the other direction, there is signalfd in Linux. And of course you can get a peer address from /dev/tcp ( https://andreafortuna.org/2021/03/06/some-useful-tips-about-... ). Yes, /dev/tcp is not an OS primitive but a bash builtin, but there isn't really a reason you cannot do this in the OS. Shared memor…

For one, encoding and decoding text is slower than binary calls to a function with solid parameters that don't need to be converted.

It's far too easy to pretend reality is not complex and that "elegant" solution somehow will fit everything

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

#195

Post by salawat »

mikepurvis wrote: post #125
randomdata wrote: post #26

Earlier quoted context omitted.

The big lesson Plan 9 seemed to have learned is that maintenance is a drag and a hinderance. find may be objectively better than du | grep for the user, but once introduced then the developers have to essentially maintain the same thing twice and carry that baggage forever into the future. In a parallel universe where Unix did not take on so much baggage, perhaps it could have even naturally evolved towards Plan 9 an…

I always feel guilty that find . | grep is easier for me than remembering how find's flags work. But I think it's really a case of my brain rejecting exactly the redundant baggage you're speaking of here.

What's hard about "find . -regex -exec /;"

Hardest thing that comes to mind is there's some slight portability differences to look out for between GNU find and BSD find that may require a quick man dive with relation to the max depth handling, but that's about it.

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

#196

Post by salawat »

wbl wrote: post #7
pcwalton wrote: 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…

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

I'd recommend you not look at awk/sed then.

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

#197

Post by kps »

rhabarba wrote: post #107
phrenicfraud wrote: post #97

Earlier quoted context omitted.

All these things you listed are objectively bad and a tumor and I'm glad that those that are gone, are gone for good, because the one that stayed is a menace to any programmer caring about his sanity.

What's wrong with Acme?

I only have two hands.

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

#199

Post by kps »

lproven wrote: post #150
phrenicfraud wrote: post #97

Earlier quoted context omitted.

All these things you listed are objectively bad and a tumor and I'm glad that those that are gone, are gone for good, because the one that stayed is a menace to any programmer caring about his sanity.

Bad how and why? I mean, as editors, for instance, Vi and Emacs are horrible ugly things that were rendered obsolete by the Apple Lisa in 1982, let alone by the mainstream success of the Mac a couple of years later. And yet, they persist. X11 is a horrid lashup for what most people actually use it for. And yet, it remains way more mainstream than Wayland, say.

> Vi and Emacs are horrible ugly things that were rendered obsolete by the Apple Lisa in 1982

Disagree. In the vi/TECO model and emacs to a slightly lesser extent, you operate on text, using text, with an input device that has a 1:1 mapping to units of text. In the Lisa model, you operate on pictures of text.

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

#200

Post by barrkel »

winter_blue wrote: post #153
3cats-in-a-coat wrote: post #110

Earlier quoted context omitted.

When everything is a file, what is a "file" becomes flexible. In Plan 9, you send signals and messages to a file by writing to it. And read messages by reading from it. It's in essence no different than OOP or actor model or what have you.

An attempt is being made to reduce everything to: interface UniversalInterface { fun open(…) fun read(…) fun write(…) fun close(…) } If you went to a software engineering design review meeting, proposing that several different kinds of objects representing everything from files, network sockets, to arbitrary devices should all use the interface above, you’d be laughed out of the room. Ultimately, when someone does en…

That's not far from the CRUD of a database, or POST/GET/PUT/DELETE of HTTP. It's also not far from what you'd expect at the transport layer of an RPC / IPC mechanism.

The metadata around files - ownership, permissions, creation time - apply to a lot more than files.

I don't really see it being laughed out of the room.

Post reply on HN