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

241–250 of 311 posts

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

#241

Post by mananaysiempre »

EricE wrote: post #240
mananaysiempre wrote: post #219

Earlier quoted context omitted.

> Ultimately IO is [an] intrinsically complex topic, and trying to paper over that complexity with simple interfaces is disingenuous and falls flat on edge cases. I’m not against pointing out the edge cases in the Plan 9 file model[1,2], but the thing is, I haven’t seen complex I/O interfaces that aren’t a horror show, either. Granted, I haven’t seen that many of those at all, but I’ve had a thorough look at the ones…

BeOS was designed for multimedia and audio from the start - I had many friends excited about it's approaches to I/O.

I have never found the Be Book to be particularly engaging reading, but this might finally give me a reason to work through some parts. Thanks!

I’m not sure how much stock to put into the multimedia claims, however—a lot has changed since then, both in the state of human knowledge about low-latency multimedia, A/V sync, network streaming, etc., and in what we can and can’t afford on machines we perform multimedia processing on. How relevant and how commonly known are the insights that BeOS incorporated today?

(You can see that I expect the answers to be “not very” and “extremely”, but sometimes life surprises us. For example—did you know that Microsoft shipped a renderer for 2D animation based on FRP ideas, designed with the direct participation of Conal Elliott himself, in 1998? It was called DirectAnimation and released as part of DirectX 5.)

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

#242

Post by gnramires »

crabbone wrote: post #236
bwanab wrote: post #228

Earlier quoted context omitted.

What's an existing example of a non-'half-backed' OS? I personally liked VMS for concurrency, but for dealing with code and coding there was no contest that Unix was far better. I think the reality is they're all half-baked since none can satisfy every need.

I used "half-baked" in the context of UNIX history, where the legend goes that UNIX was the stop-gap solution for AT&T failing to come up with a better designed system on schedule. Unfortunately, today, UNIX is by and large all we have. Other things are either some kind of UNIX but with a twist, or very underdeveloped. Looking into the future, I'm very enthusiastic about OS-as-a-library approach, but I don't think we…

I think one approach in (re)designing an OS should be to go back to fundamentals: what makes an Operating System?

I think fundamentally, there are only a few things it has to do: Allow applications to run (on the CPU/other hardware), Allow applications to communicate between themselves (establish communication standards), Allow access to disk, Manage the time given to each application well/fairly, Define permissions around resources (who can talk to whom and who can access what). Depending on who you ask, shells/desktop environments should be part of the OS too.

When I think of the minimum that can accomplish that, I think something like a simple communication standard (with authentication mechanisms) would be interesting (with possibility to support more specialized standards). A standard for defining app. share of resources (CPU/disk). Maybe hardware resources like disks, devices like cameras, etc.. could be treated as applications via a driver (or application disk application disk driver). Then instead of 'opening' files, you're just communicating your intentions with a disk driver, and you can do essentially anything. Maybe then instead of a Filesystem Hierarchy standard, there could simply be "OS (standard) applications" that for example list what users are in the OS, what applications are available, and so on (without a filesystem hierarchy at all, if you wish!). An FHS could be provided for legacy reasons.

I also think permissions should take a more fine grained approach than Unix/Linux does (closer to Android permission systems), I think by default applications should have minimum permissions and should be whitelisted as needed.

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

#243

Post by jcrites »

bwanab wrote: post #228
crabbone wrote: post #223

Earlier quoted context omitted.

Wait until you realize you need asynchronous I/O operations, and then you also need to manage caching on I/O operations, and you also need to distinguish appends from over-writes, and that you also need to care about who allocates memory for the buffer being written to / read from... And then comes concurrency and exceptions... UNIX "design" anticipated none of the above. And it's not like these things were somehow u…

What's an existing example of a non-'half-backed' OS? I personally liked VMS for concurrency, but for dealing with code and coding there was no contest that Unix was far better. I think the reality is they're all half-baked since none can satisfy every need.

The Windows NT kernel is surprisingly well-designed. Everything is an 'object' to the kernel (or file descriptor). Concepts like ACLs apply to all kernel objects. I summarized about some of its capabilities previously: https://news.ycombinator.com/item?id=34914776

One concrete example of its design: exercising administrator (sudo) permissions causes a User Account Control (UAC) dialog to pop up, which takes over the screen from the current WindowStation -- making it impossible for any software to mess with approval or password entry [1].

IO Completion Ports (IOCP) also stand out as a powerful way to perform asynchronous IO that NT has had since ... I'm not sure how long, but I believe probably since the 90s. As one HN commenter wrote in 2016, "IOCP is the top item on my (short) list of things Windows simply does better. The performance boost you see from designing a server for IOCP from the ground up is jaw-dropping." [2] And it works for a variety of different IO tasks (including disk IO).

Windows gets a lot of hate, but most of the criticism you read about it online is not usually a well-considered critique of how its kernel APIs operate.

[1] https://learn.microsoft.com/en-us/windows/security/applicati...

[2] https://news.ycombinator.com/item?id=11867345

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

#244

Post by gpapilion »

miga wrote: post #99
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.

Article mentions that Plan9 missed `cgroups`, QoS. Linux moves towards massive process sharing, and thus various of sharing controls are key to the future that is missing from 90s operating systems. Just enable sound, run your browser and music app, and count number of processes living with `ps ef|wc -l`. I see 282 kernel threads, and 536 total processes. You will see that we live in the future, because of extensive…

It didn't have cgroups, because at the time it was thought of as a distributed system meaning it would run a single service, authentication for example, and there was no real ability to share resources in the way we do today.

Remember CPUs were largely single threaded, and you had expensive multi-cpu systems that ran 2, 4, and 8 CPUs. Compute heavy processes consumed entire systems, or CPU since SMT was also not common. You couldn't effectively microsegment CPU usage, because you were only really multiplexing idle time. Additionally, your OS had to consume more cycles to do that resource sharing.

Today, the story is pretty similar, but we have systems with multiple cores, and SMT. We can share resources more effectively, but its also that our systems have 16x more scheduling slots.

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

#245

Post by eschneider »

salawat wrote: post #195
mikepurvis wrote: post #125

Earlier quoted context omitted.

I always feel guilty that find . | grep is easier for me than remembering how find's flags work. But I think it's really a case of my brain rejecting exactly the redundant baggage you're speaking of here.

What's hard about "find . -regex -exec /;" Hardest thing that comes to mind is there's some slight portability differences to look out for between GNU find and BSD find that may require a quick man dive with relation to the max depth handling, but that's about it.

Ah...find's "swiss army chainsaw" mode. So, so useful. :)

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

#246

Post by ranger207 »

oskarw85 wrote: post #239

I often see those "Plan 9 did everything right" posts and can't help but add "... because it hardly did anything at all" Current complexities stem from years and years of development and edge cases of new, previously not known use cases. Therefore Plan 9 filesystem abstractions are either really simple and often not comparable to Linux equivalents, or complicated but hiding internals behind the quasi-elegant interfac…

Yeah, to paraphrase Stroustrup, there's two kinds of systems: ones people think are elegant, and ones people actually use

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

#247

Post by kramerger »

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…

Just a nitpick: "docker" is not a technology, its a product. What you (and the author) mean is "kernel containers".

Regarding the rest: I was an early Plan9 user and still use some of their tools. They had some good ideas and some bad ones. I don't want people to rewrite linux to make it a plan9 clone. The good parts have already been added to Linux anyway

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

#248

Post by markhahn »

c00lio wrote: post #202
adql wrote: post #194

Earlier quoted context omitted.

For one, encoding and decoding text is slower than binary calls to a function with solid parameters that don't need to be converted. It's far too easy to pretend reality is not complex and that "elegant" solution somehow will fit everything

Netlink sockets in Linux input and output packed C structures. Doesn't get more efficient than that. Such an interface definitely doesn't have to be strings-only. But of course, you cannot use it with just 'echo' in that case.

/proc pseudofiles could have a mode (perhaps on open) that determines whether the protocol is ascii or packed/binary. there could even be a side-band interface that provides the packed schema (assuming not everything is exploded to atomic type-evident items).

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

#250

Post by zilti »

jerf wrote: post #187
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 interf…

Well, Go is a descendant of Plan9's main programming language.
Post reply on HN