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

151–160 of 311 posts

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

#151

Post by [deleted] »

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…

[deleted]

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

#153

Post by winter_blue »

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.

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 end up implementing something like the above as the sole interface for some major component, it’ll result in libraries that return a wrapping object with a more useable and pleasing interface that abstracts away the ugliness of using UniversalInterface to interact with said component.

I see two ways forward with this. Either: (a) present the option of using UniversalInterface to interact with X object, in addition to interface that’s much more idiomatic and closer to how X object actually behaves.

Or, (b) come up with an alternative universal (or flexible) object interaction interface that’s much more flexible than UniversalInterface.

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

#154

Post by lagniappe »

phrenicfraud wrote: post #95
didntcheck wrote: post #55

Earlier quoted context omitted.

Agreed. Go is a shining example of Unix philosophy - but I don't mean that as a compliment. I mean it prioritizes ease of implementation over any other concerns and hence forces the user to reinvent many wheels. Forces round things into square holes, regardless of if that interface actually makes sense. And either completely ignores good ideas from other camps or goes sour grapes and claims they're overcomplicated an…

I remember trying to figure out what's up with Go and left in complete disbelief when I was told that I need to install nginx on my local machine and fake a DNS entry just for go's package manager to "fetch" my local package from my local machine just so I could mess around with it how that works. All because I couldn't care less about 3rd party services like github.

you're holding it wrong

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

#155

Post by _trapexit »

For all the comments about ioctl and APIs...

There isn't a lot of options when it comes to the basic interface to an API. You have functions and their arguments. They can be strongly typed like most random syscalls or generic like ioctl or some microkernels. io_uring's API is not so nice in the sense it is very generic on the surface and typing is handled in the data structure rather than signature so it needs wrapping for any language level typing support. And that that point, besides some internal details, what separates ioctl from io_uring? Could I not send similar data to ioctl and have it act similarly? At the end of the day it is just a way to shuffle data to and from the kernel. How the kernel acts on that is what matters.

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

#156

Post by lproven »

TwentyPosts wrote: post #94
codedokode wrote: post #89

"Everything is a file" is not a good idea, because different objects have different interfaces. For example, a network socket is not a file because you cannot seek it. A process is not a file because you cannot send signals to a file. This also caused appearance of syscalls like ioctl - very ugly solution. Ioctl is a large and undocumented API. Pseudo-filesystems like /proc or /sys are also examples of undocumented A…

>Instead of "everything is a file", "everything implements well-documented object-oriented interfaces" would be much better idea. Why "object-oriented" specifically? Is this in any sense different from non object-oriented interfaces, eg. Rust's traits or Go's interfaces, or just to make it more clear that you're talking about interfaces in the programming languange sense?

Not really, because then, the influence reaches deep into the programming language, and that means you get one of the many single-language type OSes, like Smalltalk, or Oberon, or Lisp Machines.

They do have many advantages, but lots of people don't like being compelled to use just one thing, and I think that's a huge factor in how the Unix/WinNT model did so well.

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

#157

Post by ori_b »

esjeon wrote: post #67

To be fair, even the namespace design of Plan 9 isn't very elegant, because file-base API hits its own limit pretty quickly. Linux had to abuse `ioctl` to avoid that. The best namespace design should come from the microkernel world, where isolation can be achieved by simply rerouting outgoing API calls to alternate servers. This will also allow injecting all kinds of crazy/complicated policies in the middle.

That's... More or less how it works in plan 9?

http://man.9front.org/3/mnt

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

#158

Post by lproven »

anthk wrote: post #82
InTheArena wrote: post #4

The pros argument seems a little disingenuous/backwards - plan 9 brought the future including things like /proc - which was implemented in UNIX. I loved a lot of the ideas on plan 9, but it really was unusable as a day to day environment.

Today with 9front you can accomplish lots of things.

I managed to install a recent version in a VM and get it doing things, which I never managed with traditional Plan 9, despite several attempts. That impressed me.

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

#159

Post by mahogany »

tsss wrote: post #48
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.

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.

> 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.

Hilarious how in any thread on HN tangentially related to Go, somebody will inevitably find a way to construct that bridge to Go purely to shit on it (and it's rarely anything more interesting than "Go sucks, right?").

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

#160

Post by ori_b »

miga wrote: post #96

I disagree with the author: 1. We could gradually port Linux `ioctl` to Plan9 namespaces, if there was understanding they greatly simplify Docker. 2. Docker and virtualization are one of most important applications of Linux, but there is still not even a proof-of-concept implementation of such on Plan9. 3. We don't need a complete rebuilding of Linux to make it more like Plan9. Both Windows and Mac OS X is an example…

The feature of plan 9 that makes it all hang together is that all features interact through a single, network transparent, universal layer.

Fixing this in Linux means removing everything that doesn't fit in this interposable, redirectable, nameable world with a uniform way to interact with all resources.

That's most of Linux.

Ioctl is a particularly egregious violation of the model.

Post reply on HN