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

201–210 of 311 posts

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

#201

Post by rektide »

foul wrote: post #30
jrockway wrote: post #10

Earlier quoted context omitted.

Is that a problem? A simple tool is good if it can solve complex problems, but a simple tool that can't is just an underdeveloped tool. Sometimes you need a complex tool to solve a complex problem. I think a good mini language bridges the gap between interactive commands and programming. Sometimes you need to spend an hour writing a program to do something complicated. But because of various "extraneous features" bui…

>I think a good mini language bridges the gap between interactive commands and programming. find(1) is a bad mini language. Its arguments are in a legacy format and its solution for composability is a hack, and an unstable one.

And shell users already have a language they know & should be able to use to compose computing: the shell.

Different programs introducing their own specific programmatic layers defeats the holistic small pieces, loosely coupled premise.

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

#202

Post by c00lio »

adql wrote: post #194
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…

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.

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

#203

Post by marcosdumay »

c00lio wrote: post #108
codedokode wrote: post #90

Earlier quoted context omitted.

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

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 to go and emulate a random access over that file is... not a great way to deal with a high-performance primitive.

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

#204

Post by lproven »

Spivak wrote: post #170
lproven wrote: post #156

Earlier quoted context omitted.

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.

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.

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

#205

Post by lproven »

rhabarba wrote: post #174
lproven wrote: post #150

Earlier quoted context omitted.

Bad how and why? I mean, as editors, for instance, Vi and Emacs are horrible ugly things that were rendered obsolete by the Apple Lisa in 1982, let alone by the mainstream success of the Mac a couple of years later. And yet, they persist. X11 is a horrid lashup for what most people actually use it for. And yet, it remains way more mainstream than Wayland, say.

Well... https://dreamsongs.com/WorseIsBetter.html

100% this, yes.

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

#206

Post by c00lio »

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…

> Coercing random access memory into a serial file just to go and emulate a random access over that file is... not a great way to deal with a high-performance primitive.

The file doesn't need to have an on-disk representation. I don't see why an mmap-ed file should behave any different from a SHM segment. They are basically the same thing, the SHM segment even has a file descriptor. It just doesn't have a name somewhere in the filesystem hierarchy. https://man7.org/linux/man-pages/man7/shm_overview.7.html

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

#207

Post by lproven »

garaetjjte wrote: post #186
lproven wrote: post #144

Earlier quoted context omitted.

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.

As I understand it, and I could be wrong, the origins of the project lay in trying to target the output from a compiler to a bytecode like intermediate language that the JavaScript runtime could execute. I am more than happy to believe that no trace of that is left now, but I think that is more or less how it got started.

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

#208

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.

To elaborate on those points a bit further, past what I already said about pidfd being introduced exactly to treat processes as files:

1. ioctls can make any "syscall" on a file.

2. a process does not have to be a singular file. All processes have most if not all their attributes exposed as files /proc/$PID/ as files, and can have this arbitrarily extended. In plan9, passing a signal (technically a note) is done by writing to /proc/$PID/note, and there is no technical reason for not allowing the same on Linux.

3. the entire concept of memory mapping is based around files, with anonymous memory - i.e., non-disk-backed memory - just being a subset of this. POSIX shared memory (shm_open) is provided through /dev/shm, which is a tmpfs folder and is indeed just files.

4. sockets are file descriptors, and file descriptors is what makes a file, and as such you can get a peers address of a file descriptor when such is present. Ways to expose creating sockets in the filesystem also exist, and not just for plan. The special socket-bits could easily be made less special, with the only justification for the current BSD socket API being that it became dominant and so everyone copied it.

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

#209

Post by lproven »

kps wrote: post #199
lproven wrote: post #150

Earlier quoted context omitted.

Bad how and why? I mean, as editors, for instance, Vi and Emacs are horrible ugly things that were rendered obsolete by the Apple Lisa in 1982, let alone by the mainstream success of the Mac a couple of years later. And yet, they persist. X11 is a horrid lashup for what most people actually use it for. And yet, it remains way more mainstream than Wayland, say.

> Vi and Emacs are horrible ugly things that were rendered obsolete by the Apple Lisa in 1982 Disagree. In the vi/TECO model and emacs to a slightly lesser extent, you operate on text, using text, with an input device that has a 1:1 mapping to units of text. In the Lisa model, you operate on pictures of text.

I think that you misunderstand my point here.

As far as the UI goes, the critical distinction is not about how it looks on screen or how it is rendered, it's about modal versus nonmodal user interfaces. I happened to side with Larry Tesler on this: "don't mode me in!"

As far as Emacs goes, I was more thinking about its strange set of user interface conventions and terminology, which pre-date (and conflict with) industry standards such as the IBM CUA set of standards which came to almost completely dominate DOS, Windows, and Linux.

How the appearance of the thing is rendered on the screen is completely irrelevant to this.

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

#210

Post by marcosdumay »

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.

Another L4 fan?

Post reply on HN