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

81–90 of 311 posts

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

#81

Post by anthk »

nine_k wrote: post #39
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.

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…

> world domination

No. Android won. The concept from iPhone won, but Android it's the world leader.

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

#82

Post by anthk »

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.

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

#83

Post by creshal »

jabl wrote: post #69
akira2501 wrote: post #60

Earlier quoted context omitted.

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

For an example, most high performance devices expose functionality as memory locations mapped into the CPU address space. In many cases it's necessary to allow userspace direct access to (part of) the memory the device exposes, such as with GPU's, RDMA NIC's and so forth. Not sure you could get high performance with a read/write stream based interface, as conceptually elegant such an interface is.

Devices have been doing that since forever, so Plan9 has an mmap equivalent with segment/segattach, where you use file I/O (only) to define a memory mapping and attach it to the current process. Everything from that point on is regular memory I/O.

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

#84

Post by anthk »

throwawaylinux wrote: post #54

I have used Plan 9, and found it is a poor man's Linux.

More like the reverse. Coding in 9front's C from the book from Francisco J. Ballestero's felt and still feels like the future today.

Golang for example borrows lots of stuff from 1-9c compilers from plan9/9front, Limbo and Plan9 design such as static binaries and cross compiling from anywhere to everywhere.

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

#86

Post by somnium_sn »

I don't know how zones were implemented in Solaris, but since the article brings up docker, I feel the original zones implementation in Solaris is a still significnatly better user experience than docker or anything similar on Linux. The combined stack of zones + crossbow and zfs was just a pleasure to work with.

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

#88

Post by SubjectToChange »

xxs wrote: post #49
asim wrote: 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

Care to explain? How does something like procfs map better to hardware than an explicit API?

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

#89

Post by codedokode »

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

Instead of "everything is a file", "everything implements well-documented object-oriented interfaces" would be much better idea.

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

#90

Post by codedokode »

xiphias2 wrote: post #66
zokier wrote: post #58

Earlier quoted context omitted.

> First, it's not always easy to map every object operation into either an open read or write. Heck, even for basic files on disk, and even more so for sockets, the traditional open/read/write/close is starting to feel not so great. There is reason why iouring is hailed as the second coming, and it solves just part of the problems; stuff like fsync apocalypse comes to mind. And ioctls are imho completely disgusting h…

io_uring is a more modern API to file access. Actually I think it would be great if everything was a file and the communication with the kernel was only with io_uring.

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

Post reply on HN