19 ms·

Linux Namespaces Are a Poor Man's Plan 9 Namespaces

304 points by jandeboevrie 3y ago

miga 3y ago
Try to implement Docker in Plan9 using this tutorial: https://akashrajpurohit.com/blog/build-your-own-docker-with-linux-namespaces-cgroups-and-chroot-handson-guide/ https://akashrajpurohit.com/blog/build-your-own-docker-with-... Wonder how far will you fare, and how long will it take. Or try PlanD: https://github.com/rvs/planD https://github.com/rvs/planD
DiabloD3 3y ago
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.
- klysm 3y ago
  Did it live too far in the future for the time?
  - pjmlp 3y ago
    Just as its sucessor, Inferno. Which is what ChromeOS and Android are mostly today, leaving C to the kernel, or tiny special purpose libs, and everything else in a managed language, Limbo.
    - jjtheblunt 3y ago
      And how close is Go to Limbo?
      - afr0ck 3y ago
        If I remember correctly, they have similar concurrency models. They were both written the same author as well, Rob Pike. Edit: fixed a typo
      - pjmlp 3y ago
        Quite close, unsafe package and method declaration come from Oberon-2 (thanks Robert Griesemer), everything else is somehow inspired from Limbo. https://www.vitanuova.com/inferno/limbo.html https://www.vitanuova.com/inferno/limbo.html https://www.vitanuova.com/inferno/docs.html https://www.vitanuova.com/inferno/docs.html
- pcwalton 3y ago
  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 lines of code [2], about a third of the size of Lua.) [1]: https://9p.io/wiki/plan9/Unix_to_Plan_9_command_translation/index.html https://9p.io/wiki/plan9/Unix_to_Plan_9_command_translation/... [2]: https://github.com/sharkdp/fd https://github.com/sharkdp/fd
  - wbl 3y ago
    The problem with find is that it tries to put an entire programing language into its arguments.
    - pcwalton 3y ago
      I agree with you to some extent, but the solution is fd: change the tool's interface to make simple things easy. Deleting the tool entirely does nobody any favors. As bad as find(1) is for simple stuff, piping du(1) to grep(1) is worse.
      - comex 3y ago
        That's half of the solution. The other half, I'm convinced, will be a tool that makes complex things possible. After all, if I really need some complex filtering, find's primitive logical operators probably wouldn't even be sufficient. To that end, I love how Nushell's leading example on their home page is ls | where size > 10mb | sort-by modified It seems so elegant! Down with strings! …But it's not my life yet, since last time I wanted to try Nushell they didn't have scripting yet, and I have yet to circle back around to it. There's also Elvish and PowerShell and Oil Shell but they all have their own issues.
        arp242 3y ago
        zsh solves this with globbing qualifiers: ls -t *(Lm+10) "L" for the "file size" qualifier (why "L"? For "less than size", I think – probably because "s" is already used for setuid), "m" for megabytes, "+" for "larger than". You can also add "om" or "Om" to sort by mtime, but ls will reorder it so you need the -t flag (or the -U flag to not sort things). The syntax is not easy, even byzantine, but it's a lot less to type and pretty convenient in interactive shells.
- totallywrong 3y ago
  Never tried but I remember reading it was very dependent on the mouse. I probably wouldn't like it.
  - stefncb 3y ago
    It is, but for what it's worth using the mouse is much more pleasant than what we're used to ime. It's weird at first, especially with the teleporting thing but it works really well. Also, if you're gonna try it do it either with a proper three-button mouse or with a large-ish and easy to press scroll wheel button. Otherwise it's really frustrating.
    - prmoustache 3y ago
      Just the idea of context switching from mouse to keyboard is so annoying to me outside of graphic editing. I installed vinium for firefox recently and it has been a game changer.
      - stefncb 3y ago
        That's fair and I share the sentiment to some degree, especially in "regular" systems. In the time period I used plan 9 I quickly got used to it though, and the method of interaction made me a bit slower and much more considerate. I liked it a lot. I still miss it. I'll probably try it again some time.
      - hardware2win 3y ago
        Context switch?? After longer usage you do that without any thinking
        taeric 3y ago
        Ish. Just changing where you are oriented can impact how some people are thinking. By nature of their orientation. Moving to a mouse primes my brain to start thinking spatially about things. Which is not something I'm typically doing when looking at textual/symbolic things. I can see some value in doing it, of course.
- thesuitonym 3y ago
  I once saw Plan 9 described as "Imagine if all the stuff they told you about Unix was true." Edit to add: I don't know that this actually makes Plan 9 better, but I'm pretty sure it doesn't make it worse (Although from our perspective in 2023, it's definitely alien and difficult)
- nine_k 3y ago
  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 (world domination). - Java Virtual Machine, 1994 (server-side world domination, a flop in the browser) -> Inferno OS, from the makers of Unix and Plan9, 1996 (a flop) -> WASM (prospects of world domination in the browser).
  - torginus 3y ago
    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 performance issues, that plague WebAssembly. WASI also seems like a wrong approach, considering it inherits the limitations of WASM, like problems with memory, allocation and multithreading and hacks needed to overcome them. VM-s are also kind of a wash for me too, since nowadays the most popular way to run software in a portable/sandboxed manner is Docker, which is NOT cpu-agnostic, even if you ran a JVM app in it, the bundled JVM would be CPU arch dependent.
    - nine_k 3y ago
      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 %)
      - vilunov 3y ago
        Or it could get translated to the target ISA by the user-agent Rosetta-style, suffering the same warmup issues, but only on some architectures.
- prmoustache 3y ago
  But what about security? I haven't really used it but from what I understood at first most of it is very elegant because at the time it was developped all nodes in a network could still be trusted.
- tsss 3y ago
  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.
  - didntcheck 3y ago
    Agreed. Go is a shining example of Unix philosophy - but I don't mean that as a compliment. I mean it prioritizes ease of implementation over any other concerns and hence forces the user to reinvent many wheels. Forces round things into square holes, regardless of if that interface actually makes sense. And either completely ignores good ideas from other camps or goes sour grapes and claims they're overcomplicated and bad (then quietly tries to hack them on later) Worse is better than nothing, but when better has been demonstrated to exist, worse is just worse
    - phrenicfraud 3y ago
      I remember trying to figure out what's up with Go and left in complete disbelief when I was told that I need to install nginx on my local machine and fake a DNS entry just for go's package manager to "fetch" my local package from my local machine just so I could mess around with it how that works. All because I couldn't care less about 3rd party services like github.
      - bufio 3y ago
        User error.
      - lagniappe 3y ago
        you're holding it wrong
      - rakoo 3y ago
        That's never been and still isn't mandatory
  - rhabarba 3y ago
    > 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.
- bmacho 3y ago
  Can't everyone design a better OS than the current operating systems? More features, easier to use as a user, safer, easier to write programs for it, less bugs, more compatibility, etc. I am using operating systems for years, and I have ideas how they should work on the surface. But it will be slower, and won't have any useful software written for it, also you won't be able to use internet or your GPU. (To be fair several years ago I tried the HURD distribution ArchHurd. I just installed on it on my laptop, and by luck internet just worked, and had a firefox running so it was good.)
  - bmacho 3y ago
    edit: probably I did not even install it, but it was a live system.
- phrenicfraud 3y ago
  And then replies slowly devolve into arguing about irrelevant things that were solved with the existence of Linux because plan9 sucks and Linux is just a kernel which is actually used by people and therefore they actually found ways to solve problems they were most annoyed by. All these "X is poor man's Y" are a cope. Plan9 is poor man's <insert any operating system that is supposedly inferior to Plan9> because noone uses it. I'm sure on most people the irony of this statement will be lost, so I'm gonna explain: yeah, plan9 is better on paper, too bad we live in glass world.
  - SubjectToChange 3y ago
    Plan9 is the perfection of a dead end.
- miga 3y ago
  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 modularization of system services, and cannot get back without sacrificing reliability and comfort.
  - lproven 3y ago
    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.
    - tytso 3y ago
      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.
      - lproven 3y ago
        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.
- butterisgood 3y ago
  Yeah when you look at REST vs GraphQL and realize it’s all just streams and namespaces plus some conventions - you get the generality of Plan 9 again.
InTheArena 3y ago
The pros argument seems a little disingenuous/backwards - plan 9 brought the future including things like /proc - which was implemented in UNIX. I loved a lot of the ideas on plan 9, but it really was unusable as a day to day environment.
- anthk 3y ago
  Today with 9front you can accomplish lots of things.
  - lproven 3y ago
    I managed to install a recent version in a VM and get it doing things, which I never managed with traditional Plan 9, despite several attempts. That impressed me.
    - anthk 3y ago
      https://pspodcasting.net/dan/blog/2019/plan9_desktop.html https://pspodcasting.net/dan/blog/2019/plan9_desktop.html
pizza 3y ago
Could you do this with some kind of eBPF approach?
- DaiPlusPlus 3y ago
  eBPF works because it only runs programs that pass its own static-analyzer - which basically means programs have to be specifically written for eBPF - you can't just take an arbitrary C program and have it run as an eBPF program. The restrictions on eBPF programs are... legion, just count all the "No, you can't" answers in the FAQ: https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.htm...
asim 3y ago
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 be for a resource but essentially demonstrate that with a single application rather than the whole operating system. Hard to convince an engineer otherwise but the pursuit of technical perfection is often what stops something from achieving it.
- xxs 3y ago
  >Called through an API. Basically RPC This doesn't map well to hardware
  - asim 3y ago
    Realistically neither do files. I think it really comes down to our common abstractions. Everything is IO. For the most part shared memory maps are what drives the most performance and ease of use.
    - xxs 3y ago
      According Linus (and everything is a file) "File" actually mean byte array/"stream of bytes"[0]. The latter maps proper well to all cache hierarchy. [0]: https://yarchive.net/comp/linux/everything_is_file.html https://yarchive.net/comp/linux/everything_is_file.html
  - SubjectToChange 3y ago
    Care to explain? How does something like procfs map better to hardware than an explicit API?
    - xxs 3y ago
      /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.
skissane 3y ago
> Plan 9 had two major ideas, that everything else was built on. The first was the idea that everything is a file. You might think that in Unix everything was already a file, but it was only partially true. In Plan 9 they took this idea to the extreme. Everything including the input and output of the system, process management and network connections were all accessed through the file system instead of the usual syscalls. Historically, Unix has had two main APIs for establishing TCP/IP connections - Berkeley sockets, and the AT&T Streams-based TLI (which later evolved into XTI). In Berkeley sockets, although a socket is a file descriptor, you can't create one just using `open()`, you have to use the `socket()` system call instead. Whereas in TLI, a network protocol such as TCP is actually a device file (e.g. `/dev/tcp`), and you create a socket by opening it – although instead of `open()` you have to use `t_open()`. Arguably, TLI is closer to "everything is a file" in this regard than Berkeley Sockets is. Alas, Berkeley Sockets won and TLI lost. TLI was more Unix-like because it was invented on Unix; Berkeley Sockets was copied from TOPS-20. Originally with TLI, `/dev/tcp` was an actual device file on disk. In principle, you could have an alternative TCP stack using some other name, e.g. `/dev/tcp2`, although I'm not sure if any systems ever did that. The later XTI standard moved away from "everything is a file" by stating that `/dev/tcp` didn't actually have to exist in the filesystem, instead the kernel could just interpret `/dev/tcp` as an opaque string requesting the TCP protocol. `/dev/tcp` in bash is possibly inspired by TLI but uses Berkeley sockets, and I don't think TLI ever let you do `/dev/tcp/HOST/PORT`, instead you had to use `t_bind()` to bind and `t_connect()` to connect. I wonder why Linux/etc never added support for bash-style `/dev/tcp` (and `/dev/udp`) in the kernel so other programs could use it. Nowadays, I suspect many would object to that on the grounds that it could potentially be abused into a security vulnerability. z/OS is unusual in supporting multiple concurrent TCP/IP stacks, and technically being a Unix (it is certified as one). If you have more than one TCP/IP stack, you can control which one your application uses by setting the `_BPXK_SETIBMOPT_TRANSPORT` environment variable, or by calling the `setibmopt()` API on the socket. If you don't do either, z/OS extracts the routing table from each stack and uses that to forward requests to the appropriate stack by matching the IP address against those routing tables.
afr0ck 3y ago
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 interfaces resulting from this limitation. Second, hardware progress, the web, etc., introduced a lot of heterogeneity and complexity. People could no more keep up with simple general designs. And to squeeze every bit of performance, everyone was doing things different based on the hardware and the workloads. They use whatever makes their software, drivers, and OS objects work as fast as they could. And this is how we ended with the extreme fragmentation and heterogeneity we have in Linux, which explains the complex and less general implementation of its namespaces and its other features. Edit: fix typos
- zokier 3y ago
  > First, it's not always easy to map every object operation into either an open read or write. Heck, even for basic files on disk, and even more so for sockets, the traditional open/read/write/close is starting to feel not so great. There is reason why iouring is hailed as the second coming, and it solves just part of the problems; stuff like fsync apocalypse comes to mind. And ioctls are imho completely disgusting hack. Ultimately IO is intrinsically complex topic, and trying to paper over that complexity with simple interfaces is disingenuous and falls flat on edge cases.
  - xiphias2 3y ago
    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.
    - rcxdude 3y ago
      it's a more modern API to system calls in general, though most of the focus is on IO.
    - 3y ago
ceving 3y ago
Your post looks like an abstract. Where is the article?
DeathArrow 3y ago
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.
- NL807 3y ago
  > BeOS still looks more advanced in some aspects than Windows, Linux and MacOS. In what ways?
  - lproven 3y ago
    * 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.
    - miga 3y ago
      No text mode, and no console is a step back. Note that most terminal applications still use virtual terminals (`/dev/pty*`), and it is important to provide standard interface here. Also, terminal makes it easier to debug failing UI, and host headless OS. You forget that _all_ modern OS transcend the desktop: they support phones, tablets, and headless devices.
      - lproven 3y ago
        I see about 6 main points here and I disgree with all of them. Despite what Haiku's sole full time developer says, Haiku is a FOSS recreation of BeOS, and BeOS was clearly and explicitly designed not to be another flavour of Unix. If you feel that the OS world begins and ends with Unix, then we have nothing more to talk about. It's one data point on a vast and branching tree, and while it's shifted a lot of units, that doesn't make it especially significant or interesting. In the wider space of graphical desktops, Unix is a poor, third-rate entrant. Anyone half serious about talking about OS development and implementation in general should be able to name half a dozen non-Unix OSes that do at least some things better in various ways. Your points all assume that BeOS is trying to be a better Unix than Unix. It was not. It was not trying to be a Unix at all.
throwawaylinux 3y ago
I have used Plan 9, and found it is a poor man's Linux.
- anthk 3y ago
  More like the reverse. Coding in 9front's C from the book from Francisco J. Ballestero's felt and still feels like the future today. Golang for example borrows lots of stuff from 1-9c compilers from plan9/9front, Limbo and Plan9 design such as static binaries and cross compiling from anywhere to everywhere.
  - phrenicfraud 3y ago
    [flagged]
    - anthk 3y ago
      I use GNU Hyperbola as my main OS. Is not that I am a GNU/Linux hater. But 9front has good points to borrow from. Cross GCC (or clang) sucks a lot compared to [1-9]c compilers by a huge margin. Current compilation suites are brain damaged. Don't get me started on cross compiling packages for foreign archs and hunting bugs. Or the compat32 disaster on Debian and derivatives like Trisquel/Ubuntu. Slackware does it fine, tho. Also, I hope that FS from ori_b gets ported into the future Hyperbola BSD.
mike_hearn 3y ago
The Plan 9 design wasn't as great as people like to think and it wouldn't have survived in the advertised form if Plan 9 actually had taken off. Actually it was already losing that aesthetic coherence quite early on in its lifetime. Hierarchical nouns, a fixed collection of verbs and a stream of bytes is aesthetically pleasing and can be helpful for developers hacking around, but is too limited and low level a vocabulary to express many important APIs. An obvious example is the Plan 9 windowing/graphics server, which in theory is just files but because that's way too low level is actually accessed via a client library written in C. That's how it would have always gone in the end: in theory it'd be files, in practice it'd be RPCs squashed and squeezed to look a bit like files as long as you don't think too hard, with a C API wrapping it for convenience. APIs and files are very different things. Every modern platform has a fairly sophisticated inter-process RPC system at its core for that reason. Windows has (D)COM, Apple has XPC, Linux has DBUS (but doesn't use it as much), Android has the Binder, Chrome(OS) has Mojo. The designers of these platforms were all quite familiar with Plan 9 and yet none chose to implement the everything-is-a-file model, which I think is good evidence that this is a dead-end design wise. Fundamentally you don't write complex programs in shell scripts but the Plan 9 design assumes you do. One place this model does live on is HTTP, but HTTP isn't enough and is thus always used with extensions, at minimum JSON or XML but also things like multipart, websockets, headers, CORS, maybe Swagger etc. And of course HTTP servers only look like a file system on the surface, in reality you can't actually browse them or do most of the things you'd expect of a filing system, and you don't use the filing system APIs to access them. Networking and filesystems are an especially difficult combination because the UNIX APIs for file access (which Plan 9 largely also uses) are too impoverished to provide necessary functionality. They all assume relatively reliable and low latency access, so even quite basic things like being able to get progress information from operations isn't easy. Still, the underlying ideas in Plan 9 are worth iterating on. My company has an internal Kotlin based scripting tool designed to bridge the world of shell scripting and 'real' programming languages. It exposes a shell-like API with functions like mv, cp, wget, and so on which are all implemented internally. One of the things it does is expose progress events via a unified progress reporting API. You can assign a progress event handler and then do things like file copies or archival operations, and get information on what's going on. By default it renders a nice animated progress bar on the terminal but you can also do things like serialize these events across network boundaries. The filesystem API is pluggable so you can do things like browse into zips, and there's also an ssh function that lets you connect to the file system of a remote server: strings can be turned into path objects that remember their home filesystem and those can then be used to do things like copy/browse/execute things on remote systems: val local = dir / "local-archive.tar.gz" ssh("//foo.com/home/bar") { cp("remote-archive.tar.gz", local) } extract(local) ... etc ... It also acts as a sort of testbed for vaguely Plan9-ish ideas. For instance I want to experiment with how to adapt a regular POSIX-ish file API to allow nodes to be both files and directories simultaneously. But you don't need an OS for this. It can all be done in userspace.
rhabarba 3y ago
Longhorn is poor man's 9P2000. ed is poor man's sam. (Can be continued.)
fulafel 3y ago
Did Plan 9 offer unprivileged networking virtualization the same way netns can in Linux, or userid namespaces?
- hdidhdish 3y ago
  yes, by filesystem isolation you get most of the rest "for free"
esjeon 3y ago
To be fair, even the namespace design of Plan 9 isn't very elegant, because file-base API hits its own limit pretty quickly. Linux had to abuse `ioctl` to avoid that. The best namespace design should come from the microkernel world, where isolation can be achieved by simply rerouting outgoing API calls to alternate servers. This will also allow injecting all kinds of crazy/complicated policies in the middle.
- ori_b 3y ago
  That's... More or less how it works in plan 9? http://man.9front.org/3/mnt http://man.9front.org/3/mnt
  - esjeon 3y ago
    Yes, but the simplicity is in a different level. Especially in nameserver-based designs, which is quite major, namespacing is a matter of using a different nameserver. The implementation boils down to one syscall that writes to a single uint value in the process struct (which would take, idk, 10 lines in total?).
somnium_sn 3y ago
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.
- depr 3y ago
  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 a particular process. This mapping is at the heart of the implementation."
  - appleflaxen 3y ago
    That's such a meaningful blurb. Thanks for putting it here!
intsunny 3y ago
"A used poor man's anything is better than an unused rich man's anything" -- Someome, somewhere, sometime.
codedokode 3y ago
"Everything is a file" is not a good idea, because different objects have different interfaces. For example, a network socket is not a file because you cannot seek it. A process is not a file because you cannot send signals to a file. This also caused appearance of syscalls like ioctl - very ugly solution. Ioctl is a large and undocumented API. Pseudo-filesystems like /proc or /sys are also examples of undocumented APIs. Instead of "everything is a file", "everything implements well-documented object-oriented interfaces" would be much better idea.
- what_the_h321 3y ago
  In Plan9 they implemented signals using the filesystem https://news.ycombinator.com/item?id=3077504 https://news.ycombinator.com/item?id=3077504
- TwentyPosts 3y ago
  >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?
  - samus 3y ago
    The operation system already very much behaves like an object-oriented system, even in a languages without language support for this: you ask the OS for a handle, which has to be passed as the first argument to any system call. The kernel has figure out what object the handle refers to and redirect the call to the appropriate subsystem. This is abstraction and polymorphism. And of course, the kernel won't give you any access to internals by default, which gives you encapsulation. The argument of GP is that file-oriented interfaces like `rewind` or `seek` are ill-suited for anything that doesn't behave like a seekable file. `read` and `write` work well for anything with a streaming interface, but are utterly unsuitable for things like processes. You'd have to layer protocols on top of it.
  - 3y ago
miga 3y ago
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 of system that underwent radical redesigns of several subsystems. 4. All features of Plan9 could be brought to Linux by adding modules for alternative system interfaces, and deprecating old ones or blocking them with security capabilities.
- pomalat 3y ago
  wrt #4: No, the big thing about Plan 9 is that each process has its own view of the filesystem, and can modify it without any privileges. This would break the unix security model because unix has setuid. Quote from https://utcc.utoronto.ca/~cks/space/blog/unix/WhyNoUserNamespaces https://utcc.utoronto.ca/~cks/space/blog/unix/WhyNoUserNames...: > Imagine that Unix had this feature and still had setuid, and you would like root privileges. No problem; make a custom namespace for /etc that has a version of /etc/shadow, /etc/group, and /etc/sudoers that have known passwords and list you as authorized. Now run sudo. Done.
- ori_b 3y ago
  The feature of plan 9 that makes it all hang together is that all features interact through a single, network transparent, universal layer. Fixing this in Linux means removing everything that doesn't fit in this interposable, redirectable, nameable world with a uniform way to interact with all resources. That's most of Linux. Ioctl is a particularly egregious violation of the model.
- hdidhdish 3y ago
  on plan9 you can theoretically tarball a running process file, move it over the network, ubtar it and have it continue to run as it was before. that a little above your docker usecase already...
- kramerger 3y ago
  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
pabs3 3y ago
I think Hurd also has the per-process namespace thing, I wonder if it got that from Plan 9?
stuaxo 3y ago
I wonder if it would be easier to back-fit to an OS like Serenity where the whole code is in a mono-repo, from kernel up to web browser?
- samus 3y ago
  This is the biggest advantage of single-vendor ecosystems like Apple's. The governance aspect is very simplified in this situation, and it becomes possible to ram through such extensive changes. It has to be balanced with backwards compatibility of course.
azlev 3y ago
I think the simple / complex design discussion is the classic tradeoff discussion without a right answer.
Technotroll 3y ago
Plan 9? Is this a reference to the cult movie Plan 9 From Outer Space? Edit: Oh, it looks like it is indeed!^[1] [1] https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
_trapexit 3y ago
For all the comments about ioctl and APIs... There isn't a lot of options when it comes to the basic interface to an API. You have functions and their arguments. They can be strongly typed like most random syscalls or generic like ioctl or some microkernels. io_uring's API is not so nice in the sense it is very generic on the surface and typing is handled in the data structure rather than signature so it needs wrapping for any language level typing support. And that that point, besides some internal details, what separates ioctl from io_uring? Could I not send similar data to ioctl and have it act similarly? At the end of the day it is just a way to shuffle data to and from the kernel. How the kernel acts on that is what matters.
osigurdson 3y ago
>> You don’t care if each resource is local or not, you access it the same way through the filesystem Abstractions with 3 orders of magnitude difference in latency / bandwidth are not abstractions.
oskarw85 3y ago
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 interface. The latter being prone to fail on various edge cases. What strikes me as unnecessarily convoluted is "mounting remote server /net directory to create proxy". Imagine what obscene things must be going behind the scenes.
- ranger207 3y ago
  Yeah, to paraphrase Stroustrup, there's two kinds of systems: ones people think are elegant, and ones people actually use
packetlost 3y ago
ITT: people who do not know that files do not have to be stored on a disk.

304 points by jandeboevrie 3y ago

miga 3y ago

Try to implement Docker in Plan9 using this tutorial: https://akashrajpurohit.com/blog/build-your-own-docker-with-linux-namespaces-cgroups-and-chroot-handson-guide/ https://akashrajpurohit.com/blog/build-your-own-docker-with-... Wonder how far will you fare, and how long will it take. Or try PlanD: https://github.com/rvs/planD https://github.com/rvs/planD

DiabloD3 3y ago

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.

klysm 3y ago
Did it live too far in the future for the time?
- pjmlp 3y ago
  Just as its sucessor, Inferno. Which is what ChromeOS and Android are mostly today, leaving C to the kernel, or tiny special purpose libs, and everything else in a managed language, Limbo.
  - jjtheblunt 3y ago
    And how close is Go to Limbo?
    - afr0ck 3y ago
      If I remember correctly, they have similar concurrency models. They were both written the same author as well, Rob Pike. Edit: fixed a typo
    - pjmlp 3y ago
      Quite close, unsafe package and method declaration come from Oberon-2 (thanks Robert Griesemer), everything else is somehow inspired from Limbo. https://www.vitanuova.com/inferno/limbo.html https://www.vitanuova.com/inferno/limbo.html https://www.vitanuova.com/inferno/docs.html https://www.vitanuova.com/inferno/docs.html
pcwalton 3y ago
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 lines of code [2], about a third of the size of Lua.) [1]: https://9p.io/wiki/plan9/Unix_to_Plan_9_command_translation/index.html https://9p.io/wiki/plan9/Unix_to_Plan_9_command_translation/... [2]: https://github.com/sharkdp/fd https://github.com/sharkdp/fd
- wbl 3y ago
  The problem with find is that it tries to put an entire programing language into its arguments.
  - pcwalton 3y ago
    I agree with you to some extent, but the solution is fd: change the tool's interface to make simple things easy. Deleting the tool entirely does nobody any favors. As bad as find(1) is for simple stuff, piping du(1) to grep(1) is worse.
    - comex 3y ago
      That's half of the solution. The other half, I'm convinced, will be a tool that makes complex things possible. After all, if I really need some complex filtering, find's primitive logical operators probably wouldn't even be sufficient. To that end, I love how Nushell's leading example on their home page is ls | where size > 10mb | sort-by modified It seems so elegant! Down with strings! …But it's not my life yet, since last time I wanted to try Nushell they didn't have scripting yet, and I have yet to circle back around to it. There's also Elvish and PowerShell and Oil Shell but they all have their own issues.
      - arp242 3y ago
        zsh solves this with globbing qualifiers: ls -t *(Lm+10) "L" for the "file size" qualifier (why "L"? For "less than size", I think – probably because "s" is already used for setuid), "m" for megabytes, "+" for "larger than". You can also add "om" or "Om" to sort by mtime, but ls will reorder it so you need the -t flag (or the -U flag to not sort things). The syntax is not easy, even byzantine, but it's a lot less to type and pretty convenient in interactive shells.
totallywrong 3y ago
Never tried but I remember reading it was very dependent on the mouse. I probably wouldn't like it.
- stefncb 3y ago
  It is, but for what it's worth using the mouse is much more pleasant than what we're used to ime. It's weird at first, especially with the teleporting thing but it works really well. Also, if you're gonna try it do it either with a proper three-button mouse or with a large-ish and easy to press scroll wheel button. Otherwise it's really frustrating.
  - prmoustache 3y ago
    Just the idea of context switching from mouse to keyboard is so annoying to me outside of graphic editing. I installed vinium for firefox recently and it has been a game changer.
    - stefncb 3y ago
      That's fair and I share the sentiment to some degree, especially in "regular" systems. In the time period I used plan 9 I quickly got used to it though, and the method of interaction made me a bit slower and much more considerate. I liked it a lot. I still miss it. I'll probably try it again some time.
    - hardware2win 3y ago
      Context switch?? After longer usage you do that without any thinking
      - taeric 3y ago
        Ish. Just changing where you are oriented can impact how some people are thinking. By nature of their orientation. Moving to a mouse primes my brain to start thinking spatially about things. Which is not something I'm typically doing when looking at textual/symbolic things. I can see some value in doing it, of course.
thesuitonym 3y ago
I once saw Plan 9 described as "Imagine if all the stuff they told you about Unix was true." Edit to add: I don't know that this actually makes Plan 9 better, but I'm pretty sure it doesn't make it worse (Although from our perspective in 2023, it's definitely alien and difficult)
nine_k 3y ago
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 (world domination). - Java Virtual Machine, 1994 (server-side world domination, a flop in the browser) -> Inferno OS, from the makers of Unix and Plan9, 1996 (a flop) -> WASM (prospects of world domination in the browser).
- torginus 3y ago
  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 performance issues, that plague WebAssembly. WASI also seems like a wrong approach, considering it inherits the limitations of WASM, like problems with memory, allocation and multithreading and hacks needed to overcome them. VM-s are also kind of a wash for me too, since nowadays the most popular way to run software in a portable/sandboxed manner is Docker, which is NOT cpu-agnostic, even if you ran a JVM app in it, the bundled JVM would be CPU arch dependent.
  - nine_k 3y ago
    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 %)
    - vilunov 3y ago
      Or it could get translated to the target ISA by the user-agent Rosetta-style, suffering the same warmup issues, but only on some architectures.
prmoustache 3y ago
But what about security? I haven't really used it but from what I understood at first most of it is very elegant because at the time it was developped all nodes in a network could still be trusted.
tsss 3y ago
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.
- didntcheck 3y ago
  Agreed. Go is a shining example of Unix philosophy - but I don't mean that as a compliment. I mean it prioritizes ease of implementation over any other concerns and hence forces the user to reinvent many wheels. Forces round things into square holes, regardless of if that interface actually makes sense. And either completely ignores good ideas from other camps or goes sour grapes and claims they're overcomplicated and bad (then quietly tries to hack them on later) Worse is better than nothing, but when better has been demonstrated to exist, worse is just worse
  - phrenicfraud 3y ago
    I remember trying to figure out what's up with Go and left in complete disbelief when I was told that I need to install nginx on my local machine and fake a DNS entry just for go's package manager to "fetch" my local package from my local machine just so I could mess around with it how that works. All because I couldn't care less about 3rd party services like github.
    - bufio 3y ago
      User error.
    - lagniappe 3y ago
      you're holding it wrong
    - rakoo 3y ago
      That's never been and still isn't mandatory
- rhabarba 3y ago
  > 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.
bmacho 3y ago
Can't everyone design a better OS than the current operating systems? More features, easier to use as a user, safer, easier to write programs for it, less bugs, more compatibility, etc. I am using operating systems for years, and I have ideas how they should work on the surface. But it will be slower, and won't have any useful software written for it, also you won't be able to use internet or your GPU. (To be fair several years ago I tried the HURD distribution ArchHurd. I just installed on it on my laptop, and by luck internet just worked, and had a firefox running so it was good.)
- bmacho 3y ago
  edit: probably I did not even install it, but it was a live system.
phrenicfraud 3y ago
And then replies slowly devolve into arguing about irrelevant things that were solved with the existence of Linux because plan9 sucks and Linux is just a kernel which is actually used by people and therefore they actually found ways to solve problems they were most annoyed by. All these "X is poor man's Y" are a cope. Plan9 is poor man's <insert any operating system that is supposedly inferior to Plan9> because noone uses it. I'm sure on most people the irony of this statement will be lost, so I'm gonna explain: yeah, plan9 is better on paper, too bad we live in glass world.
- SubjectToChange 3y ago
  Plan9 is the perfection of a dead end.
miga 3y ago
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 modularization of system services, and cannot get back without sacrificing reliability and comfort.
- lproven 3y ago
  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.
  - tytso 3y ago
    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.
    - lproven 3y ago
      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.
butterisgood 3y ago
Yeah when you look at REST vs GraphQL and realize it’s all just streams and namespaces plus some conventions - you get the generality of Plan 9 again.

InTheArena 3y ago

The pros argument seems a little disingenuous/backwards - plan 9 brought the future including things like /proc - which was implemented in UNIX. I loved a lot of the ideas on plan 9, but it really was unusable as a day to day environment.

anthk 3y ago
Today with 9front you can accomplish lots of things.
- lproven 3y ago
  I managed to install a recent version in a VM and get it doing things, which I never managed with traditional Plan 9, despite several attempts. That impressed me.
  - anthk 3y ago
    https://pspodcasting.net/dan/blog/2019/plan9_desktop.html https://pspodcasting.net/dan/blog/2019/plan9_desktop.html

pizza 3y ago

Could you do this with some kind of eBPF approach?

DaiPlusPlus 3y ago
eBPF works because it only runs programs that pass its own static-analyzer - which basically means programs have to be specifically written for eBPF - you can't just take an arbitrary C program and have it run as an eBPF program. The restrictions on eBPF programs are... legion, just count all the "No, you can't" answers in the FAQ: https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.htm...

asim 3y ago

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 be for a resource but essentially demonstrate that with a single application rather than the whole operating system. Hard to convince an engineer otherwise but the pursuit of technical perfection is often what stops something from achieving it.

xxs 3y ago
>Called through an API. Basically RPC This doesn't map well to hardware
- asim 3y ago
  Realistically neither do files. I think it really comes down to our common abstractions. Everything is IO. For the most part shared memory maps are what drives the most performance and ease of use.
  - xxs 3y ago
    According Linus (and everything is a file) "File" actually mean byte array/"stream of bytes"[0]. The latter maps proper well to all cache hierarchy. [0]: https://yarchive.net/comp/linux/everything_is_file.html https://yarchive.net/comp/linux/everything_is_file.html
- SubjectToChange 3y ago
  Care to explain? How does something like procfs map better to hardware than an explicit API?
  - xxs 3y ago
    /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.

skissane 3y ago

> Plan 9 had two major ideas, that everything else was built on. The first was the idea that everything is a file. You might think that in Unix everything was already a file, but it was only partially true. In Plan 9 they took this idea to the extreme. Everything including the input and output of the system, process management and network connections were all accessed through the file system instead of the usual syscalls. Historically, Unix has had two main APIs for establishing TCP/IP connections - Berkeley sockets, and the AT&T Streams-based TLI (which later evolved into XTI). In Berkeley sockets, although a socket is a file descriptor, you can't create one just using `open()`, you have to use the `socket()` system call instead. Whereas in TLI, a network protocol such as TCP is actually a device file (e.g. `/dev/tcp`), and you create a socket by opening it – although instead of `open()` you have to use `t_open()`. Arguably, TLI is closer to "everything is a file" in this regard than Berkeley Sockets is. Alas, Berkeley Sockets won and TLI lost. TLI was more Unix-like because it was invented on Unix; Berkeley Sockets was copied from TOPS-20. Originally with TLI, `/dev/tcp` was an actual device file on disk. In principle, you could have an alternative TCP stack using some other name, e.g. `/dev/tcp2`, although I'm not sure if any systems ever did that. The later XTI standard moved away from "everything is a file" by stating that `/dev/tcp` didn't actually have to exist in the filesystem, instead the kernel could just interpret `/dev/tcp` as an opaque string requesting the TCP protocol. `/dev/tcp` in bash is possibly inspired by TLI but uses Berkeley sockets, and I don't think TLI ever let you do `/dev/tcp/HOST/PORT`, instead you had to use `t_bind()` to bind and `t_connect()` to connect. I wonder why Linux/etc never added support for bash-style `/dev/tcp` (and `/dev/udp`) in the kernel so other programs could use it. Nowadays, I suspect many would object to that on the grounds that it could potentially be abused into a security vulnerability. z/OS is unusual in supporting multiple concurrent TCP/IP stacks, and technically being a Unix (it is certified as one). If you have more than one TCP/IP stack, you can control which one your application uses by setting the `_BPXK_SETIBMOPT_TRANSPORT` environment variable, or by calling the `setibmopt()` API on the socket. If you don't do either, z/OS extracts the routing table from each stack and uses that to forward requests to the appropriate stack by matching the IP address against those routing tables.

afr0ck 3y ago

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 interfaces resulting from this limitation. Second, hardware progress, the web, etc., introduced a lot of heterogeneity and complexity. People could no more keep up with simple general designs. And to squeeze every bit of performance, everyone was doing things different based on the hardware and the workloads. They use whatever makes their software, drivers, and OS objects work as fast as they could. And this is how we ended with the extreme fragmentation and heterogeneity we have in Linux, which explains the complex and less general implementation of its namespaces and its other features. Edit: fix typos

zokier 3y ago
> First, it's not always easy to map every object operation into either an open read or write. Heck, even for basic files on disk, and even more so for sockets, the traditional open/read/write/close is starting to feel not so great. There is reason why iouring is hailed as the second coming, and it solves just part of the problems; stuff like fsync apocalypse comes to mind. And ioctls are imho completely disgusting hack. Ultimately IO is intrinsically complex topic, and trying to paper over that complexity with simple interfaces is disingenuous and falls flat on edge cases.
- xiphias2 3y ago
  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.
  - rcxdude 3y ago
    it's a more modern API to system calls in general, though most of the focus is on IO.
  - 3y ago

ceving 3y ago

Your post looks like an abstract. Where is the article?

DeathArrow 3y ago

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.

NL807 3y ago
> BeOS still looks more advanced in some aspects than Windows, Linux and MacOS. In what ways?
- lproven 3y ago
  * 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.
  - miga 3y ago
    No text mode, and no console is a step back. Note that most terminal applications still use virtual terminals (`/dev/pty*`), and it is important to provide standard interface here. Also, terminal makes it easier to debug failing UI, and host headless OS. You forget that _all_ modern OS transcend the desktop: they support phones, tablets, and headless devices.
    - lproven 3y ago
      I see about 6 main points here and I disgree with all of them. Despite what Haiku's sole full time developer says, Haiku is a FOSS recreation of BeOS, and BeOS was clearly and explicitly designed not to be another flavour of Unix. If you feel that the OS world begins and ends with Unix, then we have nothing more to talk about. It's one data point on a vast and branching tree, and while it's shifted a lot of units, that doesn't make it especially significant or interesting. In the wider space of graphical desktops, Unix is a poor, third-rate entrant. Anyone half serious about talking about OS development and implementation in general should be able to name half a dozen non-Unix OSes that do at least some things better in various ways. Your points all assume that BeOS is trying to be a better Unix than Unix. It was not. It was not trying to be a Unix at all.

throwawaylinux 3y ago

I have used Plan 9, and found it is a poor man's Linux.

anthk 3y ago
More like the reverse. Coding in 9front's C from the book from Francisco J. Ballestero's felt and still feels like the future today. Golang for example borrows lots of stuff from 1-9c compilers from plan9/9front, Limbo and Plan9 design such as static binaries and cross compiling from anywhere to everywhere.
- phrenicfraud 3y ago
  [flagged]
  - anthk 3y ago
    I use GNU Hyperbola as my main OS. Is not that I am a GNU/Linux hater. But 9front has good points to borrow from. Cross GCC (or clang) sucks a lot compared to [1-9]c compilers by a huge margin. Current compilation suites are brain damaged. Don't get me started on cross compiling packages for foreign archs and hunting bugs. Or the compat32 disaster on Debian and derivatives like Trisquel/Ubuntu. Slackware does it fine, tho. Also, I hope that FS from ori_b gets ported into the future Hyperbola BSD.

mike_hearn 3y ago

The Plan 9 design wasn't as great as people like to think and it wouldn't have survived in the advertised form if Plan 9 actually had taken off. Actually it was already losing that aesthetic coherence quite early on in its lifetime. Hierarchical nouns, a fixed collection of verbs and a stream of bytes is aesthetically pleasing and can be helpful for developers hacking around, but is too limited and low level a vocabulary to express many important APIs. An obvious example is the Plan 9 windowing/graphics server, which in theory is just files but because that's way too low level is actually accessed via a client library written in C. That's how it would have always gone in the end: in theory it'd be files, in practice it'd be RPCs squashed and squeezed to look a bit like files as long as you don't think too hard, with a C API wrapping it for convenience. APIs and files are very different things. Every modern platform has a fairly sophisticated inter-process RPC system at its core for that reason. Windows has (D)COM, Apple has XPC, Linux has DBUS (but doesn't use it as much), Android has the Binder, Chrome(OS) has Mojo. The designers of these platforms were all quite familiar with Plan 9 and yet none chose to implement the everything-is-a-file model, which I think is good evidence that this is a dead-end design wise. Fundamentally you don't write complex programs in shell scripts but the Plan 9 design assumes you do. One place this model does live on is HTTP, but HTTP isn't enough and is thus always used with extensions, at minimum JSON or XML but also things like multipart, websockets, headers, CORS, maybe Swagger etc. And of course HTTP servers only look like a file system on the surface, in reality you can't actually browse them or do most of the things you'd expect of a filing system, and you don't use the filing system APIs to access them. Networking and filesystems are an especially difficult combination because the UNIX APIs for file access (which Plan 9 largely also uses) are too impoverished to provide necessary functionality. They all assume relatively reliable and low latency access, so even quite basic things like being able to get progress information from operations isn't easy. Still, the underlying ideas in Plan 9 are worth iterating on. My company has an internal Kotlin based scripting tool designed to bridge the world of shell scripting and 'real' programming languages. It exposes a shell-like API with functions like mv, cp, wget, and so on which are all implemented internally. One of the things it does is expose progress events via a unified progress reporting API. You can assign a progress event handler and then do things like file copies or archival operations, and get information on what's going on. By default it renders a nice animated progress bar on the terminal but you can also do things like serialize these events across network boundaries. The filesystem API is pluggable so you can do things like browse into zips, and there's also an ssh function that lets you connect to the file system of a remote server: strings can be turned into path objects that remember their home filesystem and those can then be used to do things like copy/browse/execute things on remote systems: val local = dir / "local-archive.tar.gz" ssh("//foo.com/home/bar") { cp("remote-archive.tar.gz", local) } extract(local) ... etc ... It also acts as a sort of testbed for vaguely Plan9-ish ideas. For instance I want to experiment with how to adapt a regular POSIX-ish file API to allow nodes to be both files and directories simultaneously. But you don't need an OS for this. It can all be done in userspace.

rhabarba 3y ago

Longhorn is poor man's 9P2000. ed is poor man's sam. (Can be continued.)

fulafel 3y ago

Did Plan 9 offer unprivileged networking virtualization the same way netns can in Linux, or userid namespaces?

hdidhdish 3y ago
yes, by filesystem isolation you get most of the rest "for free"

esjeon 3y ago

To be fair, even the namespace design of Plan 9 isn't very elegant, because file-base API hits its own limit pretty quickly. Linux had to abuse `ioctl` to avoid that. The best namespace design should come from the microkernel world, where isolation can be achieved by simply rerouting outgoing API calls to alternate servers. This will also allow injecting all kinds of crazy/complicated policies in the middle.

ori_b 3y ago
That's... More or less how it works in plan 9? http://man.9front.org/3/mnt http://man.9front.org/3/mnt
- esjeon 3y ago
  Yes, but the simplicity is in a different level. Especially in nameserver-based designs, which is quite major, namespacing is a matter of using a different nameserver. The implementation boils down to one syscall that writes to a single uint value in the process struct (which would take, idk, 10 lines in total?).

somnium_sn 3y ago

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.

depr 3y ago
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 a particular process. This mapping is at the heart of the implementation."
- appleflaxen 3y ago
  That's such a meaningful blurb. Thanks for putting it here!

intsunny 3y ago

"A used poor man's anything is better than an unused rich man's anything" -- Someome, somewhere, sometime.

codedokode 3y ago

"Everything is a file" is not a good idea, because different objects have different interfaces. For example, a network socket is not a file because you cannot seek it. A process is not a file because you cannot send signals to a file. This also caused appearance of syscalls like ioctl - very ugly solution. Ioctl is a large and undocumented API. Pseudo-filesystems like /proc or /sys are also examples of undocumented APIs. Instead of "everything is a file", "everything implements well-documented object-oriented interfaces" would be much better idea.

what_the_h321 3y ago
In Plan9 they implemented signals using the filesystem https://news.ycombinator.com/item?id=3077504 https://news.ycombinator.com/item?id=3077504
TwentyPosts 3y ago
>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?
- samus 3y ago
  The operation system already very much behaves like an object-oriented system, even in a languages without language support for this: you ask the OS for a handle, which has to be passed as the first argument to any system call. The kernel has figure out what object the handle refers to and redirect the call to the appropriate subsystem. This is abstraction and polymorphism. And of course, the kernel won't give you any access to internals by default, which gives you encapsulation. The argument of GP is that file-oriented interfaces like `rewind` or `seek` are ill-suited for anything that doesn't behave like a seekable file. `read` and `write` work well for anything with a streaming interface, but are utterly unsuitable for things like processes. You'd have to layer protocols on top of it.
- 3y ago

miga 3y ago

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 of system that underwent radical redesigns of several subsystems. 4. All features of Plan9 could be brought to Linux by adding modules for alternative system interfaces, and deprecating old ones or blocking them with security capabilities.

pomalat 3y ago
wrt #4: No, the big thing about Plan 9 is that each process has its own view of the filesystem, and can modify it without any privileges. This would break the unix security model because unix has setuid. Quote from https://utcc.utoronto.ca/~cks/space/blog/unix/WhyNoUserNamespaces https://utcc.utoronto.ca/~cks/space/blog/unix/WhyNoUserNames...: > Imagine that Unix had this feature and still had setuid, and you would like root privileges. No problem; make a custom namespace for /etc that has a version of /etc/shadow, /etc/group, and /etc/sudoers that have known passwords and list you as authorized. Now run sudo. Done.
ori_b 3y ago
The feature of plan 9 that makes it all hang together is that all features interact through a single, network transparent, universal layer. Fixing this in Linux means removing everything that doesn't fit in this interposable, redirectable, nameable world with a uniform way to interact with all resources. That's most of Linux. Ioctl is a particularly egregious violation of the model.
hdidhdish 3y ago
on plan9 you can theoretically tarball a running process file, move it over the network, ubtar it and have it continue to run as it was before. that a little above your docker usecase already...
kramerger 3y ago
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

pabs3 3y ago

I think Hurd also has the per-process namespace thing, I wonder if it got that from Plan 9?

stuaxo 3y ago

I wonder if it would be easier to back-fit to an OS like Serenity where the whole code is in a mono-repo, from kernel up to web browser?

samus 3y ago
This is the biggest advantage of single-vendor ecosystems like Apple's. The governance aspect is very simplified in this situation, and it becomes possible to ram through such extensive changes. It has to be balanced with backwards compatibility of course.

azlev 3y ago

I think the simple / complex design discussion is the classic tradeoff discussion without a right answer.

Technotroll 3y ago

Plan 9? Is this a reference to the cult movie Plan 9 From Outer Space? Edit: Oh, it looks like it is indeed!^[1] [1] https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs

_trapexit 3y ago

For all the comments about ioctl and APIs... There isn't a lot of options when it comes to the basic interface to an API. You have functions and their arguments. They can be strongly typed like most random syscalls or generic like ioctl or some microkernels. io_uring's API is not so nice in the sense it is very generic on the surface and typing is handled in the data structure rather than signature so it needs wrapping for any language level typing support. And that that point, besides some internal details, what separates ioctl from io_uring? Could I not send similar data to ioctl and have it act similarly? At the end of the day it is just a way to shuffle data to and from the kernel. How the kernel acts on that is what matters.

osigurdson 3y ago

>> You don’t care if each resource is local or not, you access it the same way through the filesystem Abstractions with 3 orders of magnitude difference in latency / bandwidth are not abstractions.

oskarw85 3y ago

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 interface. The latter being prone to fail on various edge cases. What strikes me as unnecessarily convoluted is "mounting remote server /net directory to create proxy". Imagine what obscene things must be going behind the scenes.

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

packetlost 3y ago

ITT: people who do not know that files do not have to be stored on a disk.