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

181–190 of 311 posts

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

#181

Post by nine_k »

anthk wrote: post #81
nine_k wrote: post #39

Earlier quoted context omitted.

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.

Yes, I mean the concept, the approach.

Unix as a concept (a set of ideas and interfaces) achieved world domination, but it's not the original AT&T kernel, and not the original AT&T userland.

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

#182

Post by nine_k »

regentbowerbird wrote: post #114
nine_k wrote: post #39

Earlier quoted context omitted.

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…

When you say Inferno led to WASM, is it just conceptual or is there a concrete link?

Inferno did not "lead" to WASM. Palm Pilot did not "lead" to iPhone.

Instead I'm trying to show the same general idea tried over and over, at different times and from different angles. The arrows just show the sequence in time.

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

#183

Post by dadie »

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…

It might not be the best example but in my experience Microsoft seemingly tries with Windows the approach of (almost) everything being an API. It might be the Windows API specifically or that I'm mainly driving Linux outside of work, but I often found the approach of (almost) everything being an API annoying.

The presence of PowerShell softened my annoyance somewhat, but it never the less often feels unnecessary over-complex and overtly limiting. Tasks I can do in a few seconds on Linux often require reading long convoluted documentations and writing quite long PowerShell scripts or even full blown programs on Windows.

My experience is that the more basic and simple the task at hand the more annoying having to search thru pages upon pages of documentation and writing scripts became. But the more complex a task became the more I was happy not having to always deal with (and error handle) parsing an integer out of a string or splitting a string by a certain character.

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

#184

Post by masfuerte »

mike_hearn wrote: post #134
masfuerte wrote: post #111

Earlier quoted context omitted.

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.

The RPC protocol used by Windows between machines (e.g. for registry access, file sharing, setting permissions, etc.) isn't COM-based. Similarly, the RPC used internally (e.g. to talk to win32k) isn't COM-based. My Windows knowledge is quite stale but when I was developing for it COM was used for APIs but it wasn't much used for RPC.

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

#185

Post by osigurdson »

codedokode wrote: post #90
xiphias2 wrote: post #66

Earlier quoted context omitted.

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.

Maybe instead of saying everything is a file, perhaps it should be "all resources are organized in a tree structure". The nodes of the tree can be different things where different operations apply.

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

#186

Post by garaetjjte »

lproven wrote: post #144
regentbowerbird wrote: post #114

Earlier quoted context omitted.

When you say Inferno led to WASM, is it just conceptual or is there a concrete link?

It's not even conceptual. It's an entirely separate, kludgy and vastly inelegant, reinvention of a concept that had already been done much better. First in Tao Group's Taos, later much refined and improved in Elate and Intent. Then done in a more Unixy way in Inferno. Inferno embeds the cross-platform runtime VM right into the kernel and makes it the default. WASM bodges a cross-platform runtime VM together out of ch…

There is basically none Javascript tech in WASM.

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

#187

Post by jerf »

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…

I wrote a while ago about how Go is more UNIX than UNIX, which in context really meant is more Plan 9 than Plan 9:

https://www.jerf.org/iri/post/2931/

The idea there is that the particular way interfaces work in Go is possibly the way that Plan 9 should have worked. In reality, trying to fit everything into a file is still non-functional, because not everything is a file. But if you instead have a hierarchy of interfaces, starting at the very bottom with "this is a stream", working up to "this is a stream you can close", and so on and so forth up through "this is a seekable, sparse, appendable chunk of bytes that can have ACLs set and has the following ioctls", you can get what you're looking for out of common interfaces, while at the same time not having to run all around the system putting "do nothing" methods on things just to conform to interfaces. ("Do nothing" methods are a valid tool for a bit of fitting into an interface, and actually quite important, but only when the methods are themselves something that can be fulfilled by a do-nothing implementation. "Set this ACL" shouldn't be satisfied by a do-nothing method.)

For many things even a file is overkill; what you care about is that you can stream bytes in or out once you have it, not whether you can change the ownership of the thing you are working with. And with ioctls you see cases where files aren't anywhere near good enough.

(Note this is not advocacy for Go as a language you might want to program in; it's more a suggestion for a Plan 10 by drawing on Go as a particular combination of features. It would take non-trivial work to figure out how to turn this into an OS feature, but it's not inconceivable amounts of work IMHO.)

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

#188

Post by anthk »

lproven wrote: post #158
anthk wrote: post #82

Earlier quoted context omitted.

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.

https://pspodcasting.net/dan/blog/2019/plan9_desktop.html

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

#189

Post by kps »

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.

> io_uring is a more modern API to file access.

With a remarkable similarity to certain mainframe systems from half a century ago.

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

#190

Post by riddley »

iopq wrote: post #70
didntcheck wrote: post #52

Earlier quoted context omitted.

Sure, which lends weight to the idea that the shell should be a more extensive programming language. Then you can pass an arbitrary Predicate to the finder (which would likely just be a convenience function of about 5-20 lines), and receive a list of file objects for you to do what you want with That's the direction Powershell took, and to some extent was what other OSes were doing at the time of Unix. But Unix has b…

Unix being stringly-typed is a huge problem. For example, I found a flatpak of a system monitor and thought it was portable. Turns out, it parses `ps` output directly, but it's not compatible with BusyBox `ps` output https://github.com/hakandundar34coding/system-monitoring-cen... the author literally doesn't care since it works with coreutils `ps` it's a culture problem

Doesn't ps just parse /proc entries these days? Seems like an odd hill for that dev to die on.
Post reply on HN