Live data from Hacker News

Linux Namespaces Are a Poor Man's Plan 9 Namespaces

yotam.net

141–150 of 311 posts

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

#141
post #5
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.

Looking at the Unix to Plan 9 translation [1] gives me a different opinion. To name one egregious example, omitting find(1) in favor of piping du(1) (what is supposed to be a disk usage analyzer) to grep(1) is not an improvement; it's just user-unfriendliness in service of minimalist aesthetics. (Contrary to popular belief, find(1) is not a particularly "bloated" program; Rust's "fd" implementation is under 7,000 lin…

« To name one egregious example, omitting find(1) in favor of piping du(1) [...] to grep(1) is not an improvement »

I agree, but it seems to me that this is partly because it's stuck in its tiny little niche and never got the rough edges worn down by exposure to millions.

I was a support guy, not a programmer. I started Unixing on SCO Xenix and later dabbled in AIX and Solaris, and they were all painful experiences with so many rough edges that I found them really unpleasant to use.

Linux in the 1990s was, too. Frankly WinNT was a much more pleasant experience.

But while Win2K was pleasant, XP was a bloated mess of themes and mandatory uninstallable junk like Movie Maker. So I switched to Linux and found that, 5-6 years after I first tried Slackware and RHL and other early distros with 0.x or 1.0 kernels, it was much more polished now.

By a few years later, the experience for non-programmers was pretty good. It uses bold and underline and italics and colour and ANSI block characters, right in the terminal, because it assumes you're using a PC, while the BSDs still don't because you might be on a dumb terminal or a VAX or a SPARCstation or something. (!)

Linux just natively supports the cursor keys. It supports up and down and command-line editing, the way Windows does, the way PC folk expect. BSD doesn't do this, or very poorly.

Linux just natively supports plain old DOS/Windows style partitions, whereas BSD did arcane stuff involving "slices" inside its own special primary partitions. (GPT finally banishes this.)

I've taken this up with the FreeBSD and OpenBSD devs, and they just plain do not understand what my problem is.

But this process of going mainstream on mainstream hardware polished the raw Unix experience -- and it was very raw in the 1990s. Linux from the 2nd decade of the 21st century onwards got refined into something much less painful to use on

Plan 9 never got that. It still revels in its 1990s-Unix weirdness.

If Plan 9 went mainstream somehow, as a lightweight Kubernetes replacement say, it would soon get a lot of that weirdness eroded off. The purists would hate it, of course, just as BSD purists still don't much like Linux today.

Secondly, Plan 9 did a tonne of cleaning up the C language, especially (AFAICT) after it dropped Alef. No includes that contain other includes is obvious and sensible and takes orders of magnitude off compilation times. That rarely gets mentioned.

The other vital thing to remember is that despite 9front (and HarveyOS and Jeanne and so on), Plan 9 was not the end of its line.

After Plan 9 came Inferno.

I have played around with both and just by incorporating late-1990s GUI standardisation into its UI, Inferno is much more usable than Plan 9 is.

Plan 9 made microkernels and loosely-couple clustering systems obsolete >25y ago.

A decade or so later, Inferno made native code compilation and runtime VMs and bytecode and all that horrible inefficient 1980s junk obsolete. It obsoleted WASM, 2 decades before WASM was invented.

With Plan 9, all the machines on your network with the same CPU archuitecture were parts of your machine if you wanted.

(A modernised one should embed a VM and a dramatically cut-down Linux kernel so it can run text-only Linux binaries in system containers, and spawn them on other nodes around the network. Inelegant as all get-out, but would make it 100x more useful.)

But with Inferno, the restrictions of CPU architecture went away too. The dream of Tao Group's Taos/Intent/Elate, and AmigaDE, delivered, real, and FOSS.

When considering Plan 9, also consider Inferno. It fixed some of the issues. It smoothed off some of the rough edges.

I feel, maybe wrongly, that there could be some mileage in somehow merging the two of them together into one. Keep Plan 9 C and native code as an option for all-X86-64 or all-Arm64 clusters. Otherwise, by default, compile to Dis. Maybe replace Limbo with Go.

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

#143
post #136

Earlier quoted context omitted.

On the other hand, layering tons of stuff on unsuitable interfaces has been all the rage in the last 25 years. Just think of everything-over-http, stuff-it-in-xml/json, program-it-in-yaml and similar industry trends. ;)

I can’t wait till we’re configuring our OS using CSS-in-JS and booting using webpack. npm install -g styled-linux

As always, Fabrice Bellard is ahead of his time: https://bellard.org/jslinux/ :)

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

#144
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?

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 chunks of web browser and Javascript tech, and then others rip it out of the browser and make it run standalone.

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

#145
post #92

I don't know how zones were implemented in Solaris, but since the article brings up docker, I feel the original zones implementation in Solaris is a still significnatly better user experience than docker or anything similar on Linux. The combined stack of zones + crossbow and zfs was just a pleasure to work with.

There is a paper called "Solaris Zones: Operating System Support for Consolidating Commercial Workload". It mentions aspects such as: "At the most basic level, the kernel identifies specific zones in the same fashion as it does processes, by using a numeric ID. The zone ID is reflected in the cred and proc structures associated with each process. The kernel can thus easily and cheaply determine the zone membership of…

That's such a meaningful blurb. Thanks for putting it here!

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

#146

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.

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 to do, where you stream objects, structured information, instead of just bytes, on the way in and out of commands and files...

And suddenly... we got ourselves an Erlang.

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

#147
post #49

Earlier quoted context omitted.

>Called through an API. Basically RPC This doesn't map well to hardware

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.

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

#148
post #99
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 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 protocol, some kind of RPC type thing. It works, and QNX is the existence proof. But it's really hard and it's really inefficient -- of which, the HURD and Minix 3 are the existence proofs.

So most of the actual working "microkernel" OSes kludge it by embedding a huge in-kernel "Unix server" that negates the entire microkernel concept but delivers compatibility and performance. Apple macOS and iOS are the existence proof here. (It could be argued that Windows NT 4 and later are also examples.)

Plan 9 achieves the same result, without the difficulties, by default by having most things user space processes and communicating via the filesystem.

Disclaimer: this is my very rudimentary understanding. I am not an expert on Plan 9 by any means.

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

#149
post #131
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.

Plan 9 does this. The resulting interfaces are indeed easier to use, forward over the network, and redirect or emulate for testing.

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

#150

Earlier quoted context omitted.

> The same person Go was designed by: - Robert Griesemer, known for nothing else, - Rob Pike, primarily known for sam(1), acme(1) and several other Plan 9 tools, the Blit (Unix's own graphical terminal), UTF-8 (with Ken Thompson), Inferno and Limbo, - and Ken Thompson, ancient god.

All these things you listed are objectively bad and a tumor and I'm glad that those that are gone, are gone for good, because the one that stayed is a menace to any programmer caring about his sanity.

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.

Post reply on HN