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

131–140 of 311 posts

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

#131

Post by samus »

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…

This means layering additional protocols on top of the file APIs. Of course you can do that, but eventually there will be a similar explosion such as on top of `ioctl`, and it's doubtful whether the resulting interfaces will be any easier to use than the existing ones.

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

#132

Post by SubjectToChange »

3cats-in-a-coat wrote: post #110
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.

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.

When everything is a file, what is a "file" becomes flexible.

It’s really “Everything has a File Descriptor”, nothing about the concept of a file has changed.

It's in essence no different than OOP or actor model or what have you.

I’m sure there’s an isomorphism that could be drawn but it does nothing to show that it’s an equally good paradigm to write software in. IMO, it’s a tortured abstraction.

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

#133

Post by josefx »

akira2501 wrote: post #60
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. It doesn't seem like it. Linux has a habit of multiplexing alternate functions through a single handle with additional and somewhat scary methods like ioctl. Plan9 manages this with servers, directories, and more than one path available for a single resource depending on what you're trying to access. This is far more sane.…

> alternate functions through a single handle with additional and somewhat scary methods like ioctl. Plan9 manages this with servers, directories, and more than one path available for a single resource depending on what you're trying to access. This is far more sane.

Given how horribly asynchronous filesystems are I take one handle owned by the current process over a dozen free hanging files that might be reused for different resources at any time. Hell I am quite sure Linux had to kill suid on scripts because the kernel could not guarantee that the script file wasn't swapped out before the interpreter would load the path.

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

#134

Post by mike_hearn »

masfuerte wrote: post #111
mike_hearn wrote: post #59

The Plan 9 design wasn't as great as people like to think and it wouldn't have survived in the advertised form if Plan 9 actually had taken off. Actually it was already losing that aesthetic coherence quite early on in its lifetime. Hierarchical nouns, a fixed collection of verbs and a stream of bytes is aesthetically pleasing and can be helpful for developers hacking around, but is too limited and low level a vocabu…

Minor nitpick. Much of the RPC in Windows predates (D)COM. I think it's closer to vanilla DCE RPC.

DCOM is built on top of MS-RPC which is originally a DCE-RPC variant yes, but DCE-RPC isn't object oriented and all the interfaces inside Windows are. You can't just open a local socket and speak DCE-RPC to Windows services, you have to use COM.

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

#135

Post by stefncb »

arp242 wrote: post #130
stefncb wrote: post #116

Earlier quoted context omitted.

I learned the chords very quickly, but everyone works differently. What kind of feedback exactly would you expect from it? I can't immediately think of anything that would make it much better. I guess animations could help, but then they might just be distracting. I think the main thing people get confused by besides the chording is the teleporting of the cursor, but then you realize it's actually really useful once…

> What kind of feedback exactly would you expect from it? I don't know exactly; this is one of those things where I'd have to implement some things and play around to see what works. Something like some text popping up maybe? I don't know. More advanced users can always just disable these sort of things (I also set up my Vim to not show "-- INSERT --" because at this point it's never helpful for me and it looks a bit…

Fair enough.

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

#136

Post by c00lio »

samus wrote: post #131
c00lio wrote: post #108

Earlier quoted context omitted.

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…

This means layering additional protocols on top of the file APIs. Of course you can do that, but eventually there will be a similar explosion such as on top of `ioctl`, and it's doubtful whether the resulting interfaces will be any easier to use than the existing ones.

On the other hand, layering tons of stuff on unsuitable interfaces has been all the rage in the last 25 years. Just think of everything-over-http, stuff-it-in-xml/json, program-it-in-yaml and similar industry trends. ;)

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

#137

Post by Hendrikto »

randomdata wrote: post #26
pcwalton wrote: post #13

Earlier quoted context omitted.

> If I rolled up in a prototype personal transport which could go 1000 miles on a single AA battery, would you complain that the seats were poorly stitched? If the poor stitching were taken as a point of pride and the community refused to fix it, then yeah, I'd assume that that community values purity over practicality. Which is exactly how I feel about Plan 9: it had good ideas and was an improvement over Unix in ma…

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…

> The big lesson Plan 9 seemed to have learned is that maintenance is a drag and a hinderance.

So they chose to just never finish the OS instead.

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

#138

Post by maleldil »

comex wrote: post #32
pcwalton wrote: post #8

Earlier quoted context omitted.

I agree with you to some extent, but the solution is fd: change the tool's interface to make simple things easy. Deleting the tool entirely does nobody any favors. As bad as find(1) is for simple stuff, piping du(1) to grep(1) is worse.

That's half of the solution. The other half, I'm convinced, will be a tool that makes complex things possible. After all, if I really need some complex filtering, find's primitive logical operators probably wouldn't even be sufficient. To that end, I love how Nushell's leading example on their home page is ls | where size > 10mb | sort-by modified It seems so elegant! Down with strings! …But it's not my life yet, sin…

> Nushell they didn't have scripting yet

If you mean you couldn't run batch scripts from a file, they can do that now. There's an example repo with some community scripts. My favourite is how they handle CLI parsing: https://github.com/nushell/nu_scripts/blob/main/sourced/nu_1...

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

#139

Post by civilitty »

c00lio wrote: post #136
samus wrote: post #131

Earlier quoted context omitted.

This means layering additional protocols on top of the file APIs. Of course you can do that, but eventually there will be a similar explosion such as on top of `ioctl`, and it's doubtful whether the resulting interfaces will be any easier to use than the existing ones.

On the other hand, layering tons of stuff on unsuitable interfaces has been all the rage in the last 25 years. Just think of everything-over-http, stuff-it-in-xml/json, program-it-in-yaml and similar industry trends. ;)

I can’t wait till we’re configuring our OS using CSS-in-JS and booting using webpack.

npm install -g styled-linux

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

#140

Post by dale_glass »

exitb wrote: post #122
SubjectToChange wrote: post #74

Earlier quoted context omitted.

…we're using insane amount of code and cpu load to solve really simple problems on daily basis. Piping programs together is almost always going to use significantly more resources than one program doing it all. More code doesn’t necessarily imply more resource usage. Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code. I don’t want to be all around negative about…

> More code doesn’t necessarily imply more resource usage. That's true! Yet, somehow we found ourselves in a situation where most people use computers, to chat, read news etc, all of which would be possible with much less resources. All done with the use of platforms that we literally can't rewrite, as they're too complex. It's certainly not find's fault, but the complexity creep starts somewhere. Plan 9, as a resear…

Little conveniences cost a lot.

Just having a framebuffer with page flipping for seamlessly redrawing the screen costs 64MB of memory at 4K resolution. People did real work and gaming on computers with a small fraction of that.

Early on in the history of computing the framebuffer was discussed as a theoretical construct, like "what could we do with this concept if we had the memory to implement it".

Post reply on HN