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

281–290 of 311 posts

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

#281

Post by lproven »

tytso wrote: post #224
lproven wrote: post #148

Earlier quoted context omitted.

It doesn't need cgroups or containers, because every process has its own namespace, its own view of the network-global filesystem, so everything is in a container by default. It doesn't need a microkernel, because the concept of microkernels is to split a big monolithic kernel into lots of small simple "servers" running in user space, and have them communicate by passing messages over a defined communications protoco…

Cgroups are a lot more than just "namespaces". It is also the mechanism by which you can constrain how much CPU, Memory, Network Bandwidth, Storage IOPS or Throughput, etc., processes in a particular cgroup or container can use.

That's fair.

But I think the core point here is that, as with much of the Plan 9 design, by including a more elegant and powerful abstraction in the core design, the need for a much more powerful and much more complicated abstraction layer on was obviated, if not eliminated.

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

#282

Post by lproven »

rhabarba wrote: post #226
lproven wrote: post #221

Earlier quoted context omitted.

I think that may be over-generalising a point into irrelevance. All editors have commands of some kind, yes. Otherwise, it's not an editor. But holding down a modifier key is not a mode in the software. You could sort of argue it's a mode of the keyboard,. or of the key, but I think it's over reaching. I've seen editors with no menus, no visible UI at all, just hotkeys that do stuff. It is still a UI even if it is no…

I’m not even sure if the point IS relevant at all. The software-side difference between “the user pressed I, am I in command mode?” and “the user pressed I, did he also press Ctrl?” is not that big. Granted, one is Shift and one is Caps Lock…

The point is hugely relevant.

It's like saying that cars, motorbikes and bicycles were irrelevant, because trains already existed.

A lot of terminal driven software design pivoted around lots of modes. Input mode, edit mode, command mode, extended command mode, etc etc etc. It's powerful but it's very hard to learn and everything becomes very context sensitive. What any key or instruction does depends heavily on what you did before.

That means you have to remember. That means you have to think much more.

The design of second generation GUIs (the Apple Lisa etc.) strove hard to eliminate this totally. The user can do anything at any point without modes of interaction.

The pivotal event that is often missed, and much of the Unix industry even today does not get, is that in the years after the Lisa and the Mac (and, don't forget, their affordable cousins such as the ST, Amiga etc.) appeared, that this stuff then filtered down to DOS and revolutionised DOS apps too.

And those (DOS and DOS apps) were the commercial mainstream, and that ecosystem is what evolved into Windows and all modern computers. Yes including the ones running Linux, and including Linux at the GUI level.

The Mac now is a descendant of NeXT, and is a Unix, remember. It's unrelated to Classic MacOS.

But the UI design of the GUI layer comes directly from Apple R&D. The UI at the shell layer comes from a decade or 2 earlier and is totally different.

Unless you know this, the differences between Unix' and Windows' GUIs and shells makes little sense.

Windows modernised its shell layer.

Unix didn't.

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

#283

Post by lproven »

Spivak wrote: post #218
lproven wrote: post #204

Earlier quoted context omitted.

I am aware of them! Do you really think that something like this is suitable to be embedded as the core internal communications mechanism of an entire operating system? 'Cause I don't. Do you remember, for example, that the original plan for the GNOME desktop environment was that components would communicate over CORBA? They abandoned that after version 1.

Oh I absolutely think so, in fact I really hope kdbus gets merged and eventually it gets used to expose kernel structures Processes being real objects /kernel/proc/1363 with interfaces like org.kernel.proc.Process1 that allow you to manipulate them with generic message passing/function calls would be amazing.

Huh.

Okay then.

Me, I'd prefer to throw the whole lot out and start over with something clean that incorporated this into its central design.

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

#284

Post by tsss »

mahogany wrote: post #159
tsss wrote: post #48

Earlier quoted context omitted.

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?").

It is almost our duty as citizens to throw shit back at the Google marketing machine.

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

#285

Post by bwanab »

jcrites wrote: post #243
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.

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…

Windows NT was designed by Dave Cutler who also designed VMS. And, I agree, for many things it is a very nicely designed system and doesn't deserve a lot of hate.

But, what I said about developing software stands: I'd much rather be using a unix .

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

#286

Post by mike_hock »

arghwhat wrote: post #266
mike_hock wrote: post #260

Earlier quoted context omitted.

This is an absurd interpretation of "everything is a file." The kind that makes you go "arghwhat?!" A file descriptor is exactly nothing like a file. You cannot write to a pidfd. You cannot waitid an eventfd. You cannot getsockopt on a regular file. The only operations that all file descriptors have in common is close, dup, poll and some other basic operations. So "file descriptor" basically just means "kernel interf…

A file descriptor is a handle to a file, and anything you have an fd to is a file. This file carries a vfs implementation, such as that of pidfd, a device driver, or disk storage. The kernel does not distinguish between these. If not being able to write makes it not a file, then files stop existing when a disk is full, and means that /dev/zero and /dev/null are not files - despite being at the heart of the whole "eve…

> A file descriptor is a handle to a file, and anything you have an fd to is a file. This file carries a vfs implementation, such as that of pidfd, a device driver, or disk storage. The kernel does not distinguish between these.

Which is what I said. It's a "file" in name only.

> If not being able to write makes it not a file, then files stop existing when a disk is full, and means that /dev/zero and /dev/null are not files - despite being at the heart of the whole "everything is a file" paradigm.

Great example that showcases the idiocy of Everything Is A File. /dev/null and /dev/zero are basic parts of the Unix API, so the basic OS API is broken-by-default at boot until one mounts a file system that had these dummy "device" nodes at a specific path that's hardcoded everywhere.

Instead of providing a sensible API like memfd_create or timerfd_create, for example.

> A streaming socket is exactly like a normal file. You read, write and poll.

That doesn't make it a file, that makes it an object that shares common traits with file objects. Datagram sockets do not read/write because they're not bound to a fixed remote address. And that's perfectly fine. They're not files.

> The only thing that is special is how to create it, but that is a design decision, not a technical limitation

And it's a good design decision. The socket API is pretty decent except for the dumb "file" nodes it creates when listening on standard unix sockets.

> see the plan9 file based API for making TCP sockets, which is trivially implementable in Linux.

But thank God it's not implemented in Linux.

> ioctls are not themselves bad design. In fact, scoping kernel functionality onto file handles is a great design

Agreed, the only bad part is that too much was shoehorned into the same syscall. It's certainly better than magic "files" that pretend to be "files" by having you read and write structs from, but you're only allowed to read and write whole structs per syscall, which has no resemblance whatsoever to how reading from and writing to a file work. (Maybe Plan9 doesn't have this limitation and tries harder to keep up the charade, I wouldn't know.)

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

#288

Post by winter_blue »

Spivak wrote: post #167
Someone wrote: post #163

Earlier quoted context omitted.

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

> Everything is a typed object.

That's really good. The fact that the file interface just gives you a string of bytes, with no concept of structure or type safety in the interface itself is a major flow of it. Type safety is immensely valuable.

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

#289

Post by torginus »

nine_k wrote: post #176
torginus wrote: post #45

Earlier quoted context omitted.

I personally don't like WASM. I think the Native Client (which is more than a decade old today) was a much better technical solution. It used actual cpu native assembly bundled with a verifier, and had actual good integration into low-level platform APIs like graphics, threading, etc. instead of using this weird Javascript bridge approach. Due to it being native code from the start, it also had none of the startup pe…

Actual CPU native assembly? It would need to support x86, x64, and aarch64 by now. (And likely RISC-5 in the near future.) The point of VMs like WASM is not (specifically) performance though, even if performance is desirable. It's the minimal, fixed standard, and the isolation. If you badly need native performance, develop a native application %)

Yeah, actual native assembly. I think doing a cross compilation for 2 architectures (x64 and aarch64) is more than doable, even 4, if you want to be thorough.

> The point of VMs like WASM is not (specifically) performance though

I feel like it is though. There was another thing, called asm.js back then, which was a subset of javascript that was easily translatable to machine code. It was a giant hack, and performed worse than NaCl.

I feel like WASM is more of a spiritual successor of that thing.

> If you badly need native performance, develop a native application

And pass up the ease of distribution/compatibility browsers offer?

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

#290

Post by codedokode »

marcosdumay wrote: post #203
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…

> write(SIGKILL, "/proc/12345/signals") Outside of lots of non-obvious problems with synchronization, this is your example that best fits the idea. This interface is probably a good one. > And of course you can get a peer address from /dev/tcp You will have lots and lots of problems with access controls if this is your only interface. > Shared memory can be a file Coercing random access memory into a serial file just…

> This interface is probably a good one.

This interface is a bad one because if you want to filter syscalls then it will be difficult to distinguish write to a file from sending a signal.

Post reply on HN