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

161–170 of 311 posts

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

#161

Post by lproven »

NL807 wrote: post #51
DeathArrow wrote: post #50

The three most used desktop operating systems look and feel archaic. They aren't very different from the oses of two decades ago. BeOS still looks more advanced in some aspects than Windows, Linux and MacOS. I expected lots of advancements to take place in the OS space in 20 years.

> BeOS still looks more advanced in some aspects than Windows, Linux and MacOS. In what ways?

* Incrementally improving on the WIMP model. (E.g. title bars as tabs.)

* Combining the simplicity of the classic MacOS Finder with the keyboard controls and hierarchical menus and customisable taskbars of the MS Win95 Explorer, without the horrid bloat of Win98 and all later versions, including copies such as KDE >=2.

* Removal and elimination of a huge amount of legacy bloat, making a tiny fast OS. (e.g. No text mode, no console, at all.)

* Removal of complexity of multiple languages and C as the lowest common denominator; everything is in C++ and nothing but.

* Richly multithreaded: ran extremely well on SMP machines in the 1990s, when this was strictly limited to huge workstations that cost as much as a house.

It was gorgeous. Haiku is lovely but IMHO a little bloated and sluggish by comparison.

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

#162

Post by SubjectToChange »

xxs wrote: post #147
SubjectToChange wrote: post #88

Earlier quoted context omitted.

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

/proc is for stuff like shell automation, not normal 'file' use. The idea is that files are just byte streams/arrays, and pretty good to be optimized. System calls will always be better than /proc, that's not the point at all.

/proc is for stuff like shell automation, not normal 'file' use.

Systems like /proc/ are cornerstones of the “Everything is a file” concept.

The idea is that files are just byte streams/arrays, and pretty good to be optimized.

If your point is simply that “files are efficient because they are just dumb bags of bytes”, then you are in a rude awakening.

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

#163

Post by Someone »

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…

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

That’s, basically, what COM/Corba/… are. There, UniversalInterface has an additional call “If you are a Foo, give me your Foo interface”, with Foo as an argument to that call.

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

#164

Post by arghwhat »

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.

We now have pidfd, because we actually need process handles and treating processes as files is the best way to do so.

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

#165

Post by doctor_eval »

vbernat wrote: post #34
doctor_eval wrote: post #31

Earlier quoted context omitted.

Perhaps depends on your definition of “user friendly” - Find is certainly not going to be at the top of my own list. Half the time I use ls -lR | grep because I can’t be bothered to rediscover the right find option - which won’t even do what I want the first time I try it.

Then you can use "find | grep".

Find works without parameters? I don’t think that’s always been the case, and it doesn’t work on MacOS.

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

#166

Post by arghwhat »

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…

In plan9 this is dealt with through a similar workaround as we use in Unix: ctl files with a per-file protocol. Linux uses a mix of this (sys and proc files) and ioctls (which are also per-file protocols) for many things.

There is no real practical difference in capability between this and dedicated syscalls. For Linux, the distinction is usually just whether the functionality is "global" or isolated to a certain area like devices or drivers.

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

#167

Post by Spivak »

Someone wrote: post #163
winter_blue wrote: post #153

Earlier quoted context omitted.

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…

> 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. That’s, basically, what COM/Corba/… are. There, UniversalInterface has an additional call “If…

And dbus as well on Linux. I think that that style is much better than everything is a file. Everything is a typed object.

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

#168

Post by butterisgood »

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.

Exactly? The alternative is ioctl whereas Plan 9 does everything over serialized streams to files.

The serialized streams make it easier to think of these ioctl-alikes as something you can easily access over a network (9p).

And that’s how resource sharing is done in plan 9.

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

#169

Post by thesuperbigfrog »

3cats-in-a-coat wrote: post #146
SubjectToChange wrote: post #132

Earlier quoted context omitted.

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.

I wouldn't sit here and claim Plan 9 was perfect, because if it was, we'd be using it. In particular, the issue is that you're reading raw stream of content on the way in and out of those file descriptors. This is akin to how shell piping in Unix is also just... text and bytes. This is limiting and produces many ad-hoc protocols. But take what Plan 9 was trying to do, and add to it what Microsoft's PowerShell tried t…

>> I wouldn't sit here and claim Plan 9 was perfect, because if it was, we'd be using it.

Many perfect and awesome systems have been built that never saw significant adoption.

I agree with ESR's observation: "Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough." Source: https://www.catb.org/~esr/writings/taoup/html/plan9.html

Another amazing OS that never caught on was BeOS: https://en.wikipedia.org/wiki/BeOS Neal Stephenson's description of BeOS as "fully operational Batmobiles" is accurate and it is sad that BeOS did not become more mainstream. See https://people.cs.georgetown.edu/~clay/classes/spring2010/os...

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

#170

Post by Spivak »

lproven wrote: post #156
TwentyPosts wrote: post #94

Earlier quoted context omitted.

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

Look into COM/dbus. There are generic language independent object models.
Post reply on HN