11 ms·
In Praise of Plan 9
- anderspitman 4y agoOther than being different from what you might be used to, and not having a lot of software available, what other tradeoffs would you be making if you wanted to try and use Plan 9 in production? How's the performance?
- AceJohnny2 4y agoA great way to get a feel for Plan9's concepts and their power is Russ Cox's (of now Go fame) Tour of the Acme Editor: https://youtu.be/dP1xVpMPn8M https://youtu.be/dP1xVpMPn8M
- jzellis 4y agoI'm sure Plan 9 is cool and all but y'all Plan 9 nerds are like dudes who keep pushing network TV for a Barney Miller revival even though like the entire cast has been dead for years :-D <3
- dogmatism 4y agoMan, that Barney Miller comment was too close to the bone!
- ainar-g 4y agoGood ideas are worth preserving. And preserving these ideas means keeping the discussion alive. Drew mentions in the article that quite a lot of ideas have since ported in one way or another to other unices, but Plan 9 was more than just the sum of its parts. More of a product of its parts, if you will, heh.
- deleted 4y ago[deleted]
- 0x445442 4y agoLast I checked the Fish shell had many users and an active community.
- pjmlp 4y agoWhile Plan 9 is cool and such, I prefer what they built afterwards with the lessons of Plan 9, while trying to compete against Java and Sun. Inferno and Limbo, which tend to be ignored with too much focus on Plan 9, a middle stop in their whole experience designing OSes and programming languages after being done with UNIX and C.
- ainar-g 4y agoI've always wondered. Bell Labs' Inferno, Sun's JavaOS, and Microsoft's Singularity were built on the same principles of OS being almost entirely built on top of a virtual machine, and it's a very interesting idea from many points of view. But all of them seem to have failed to gain enough traction to enter the mainstream. Was there any reason for that? Were the CPUs not powerful enough, or were the compilers not quite there yet? Or did it have more to do with the business side of things?
- e3bc54b2 4y ago> Was there any reason for that? Perfect is the enemy of good, and good enough is the perfect enemy of better. Unix/Linux were/are good enough for vast majority of world's needs. So anything better is not worth the hassle.
- Turing_Machine 4y agoYep. *n*x is a victim of its own success. Thompson, Ritchie, Kernighan, et al built something so much better than most of the competition that it ate the world. There have been better ideas since then (including Plan 9) but nothing able to knock *n*x off its perch. IMO, LMI and Symbolics might have done it, if their offering hadn't required enormously expensive machines (by the standards of the time), while *n*x would run on cheap hardware (again, by the standards of the time). Perhaps we'll eventually see an innovative OS written in WASM. That's about the only way I see to get around the vendor lock-in (I mean, even Microsoft appears to be converging on a "Windows UI wrapped around a *n*x kernel" model... Apple, of course, has been using a "Mac UI wrapped around a *n*x kernel" for a couple of decades now). For anyone who hasn't read it, I recommend Richard Gabriel's "Worse is Better" essay: https://dreamsongs.com/WorseIsBetter.html https://dreamsongs.com/WorseIsBetter.html (original essay and several followups at this link)
- boris 4y ago> you open /net/tcp/clone to reserve a connection, and read the connection ID from it. Then you open /net/tcp/n/ctl and write "connect 127.0.0.1!80" This feels so ham fisted to me. Why not just open /net/tcp/127.0.0.1/80? I am sure there are reasons, but if the goal is to make everything a file, this feels like a more natural representation.
- ddevault 4y agoThe ctl file also lets you control other connection settings, such as keep alive. It would also be unfortunate to run ls in /net/tcp and dump the entire IPv4/6 space into your terminal.
- jagged-chisel 4y agoNot sure I buy that last sentence. Why would the system populate these directories with anything other than a) what’s configured to be assigned to the system, and b) what the caller requests to be created by simply opening a specific path? Sure, you could script opening each address of the entire address space and have an unfortunate situation, but you don’t get that by default when you simply query what exists. That said, it’s been a veeeery long time since I tried out Plan9 and Inferno.
- ddevault 4y agoYeah, you could do that, but it's a bit magic innit?
- jagged-chisel 4y agoEverything is a file. Dumping magic strings in these “files” causes stuff to happen … Magic indeed.
- boris 4y ago> The ctl file also lets you control other connection settings, such as keep alive. Yes, though this could have been achieved with a bunch of sysfs-like entries under /net/tcp/127.0.0.1/80/<port>/ with the added benefit of being easily discoverable. > It would also be unfortunate to run ls in /net/tcp and dump the entire IPv4/6 space into your terminal. A reasonable semantics here would be to only list hosts to which there are active connections.
- IshKebab 4y agoIt definitely has lots of interesting ideas. Especially the filesystem mounting stuff (and the shunning of symlinks). I'm still unconvinced by "everything is a file". Writing `connect 1.1.1.1!80` to a file is a particularly shitty completely untyped, unchecked, fragile and slow alternative to an actual ABI. It's obviously easier to use from shell scripts but I don't think that's what you should optimise for. IMO there should be a proper API with a typed IDL and then you can automatically make it easy to access from a shell without compromising other languages. I think maybe Fuchsia works like this.
- zozbot234 4y agoByte streams are "untyped and unchecked" too, but that's because typing and checking can be deferred to a higher layer in the stack. I.e. one could easily define a typed IDL to provide a semantics over these bare text streams. No different from how most languages provide type checking over, e.g. ABI-standard subroutine calls.
- qubex 4y agoOr how types in typed languages are expressed by in-stream sequences in the source-code made implemented in untyped text files.
- IshKebab 4y agoRight, but if you're going to have a higher layer that presents a nicely typed interface why use a text-based interface in the first place? It's just an opportunity for inefficiency and bugs. The fact that you can paper over a bad interface doesn't mean it isn't a bad interface.
- cropcirclbureau 4y agoUnless your OS is virtual machine that checks the structure of the user program, at some point, your typed data will have to be a set of numbers and/or a byte stream. Granted, the set of numbers required for utf-8 `connect` is a little less efficient than your system call no. but that's hardly a highly typed API. Anything with less mechanical sympathy that's designed for _any_ user program to access it will have to pay similar costs.
- enqk 4y agoThe thing that I find hard to defend is that plan9 turns all internal service / api calls into text based / filed based protocols, with parsing involved. This feels so inefficient and adhoc, and requires more documentation
- zozbot234 4y agoWhat's the alternative? Binary protocols tend to be dependent on machine specifics such as endianness and alignment requirements, which would be a non-starter on a network-focused OS like Plan9 - as well as poorly extensible and not always properly documented. There are some well-known pitfalls wrt. text formats, such as parsing and emitting floating point numbers (which is why hexfloats are a thing) but for mostly everything else they're good enough.
- AnIdiotOnTheNet 4y agoThere is no reason that binary protocols have to rely on endianess or alignment. Reversing or realigning a field is orders of magnitude faster than parsing text, so just pick one and stick with it.
- sanxiyn 4y agoNote that 9P is in fact a binary protocol.
- torginus 4y agoI'm not sure - first of all, turning everything to a text-based protocol might be something can be fixed - it's not impossible to amend the specification to allow for binary protocols, or - if the caller and callee are on the same machine - literal system calls. But the important thing to not is this fixes the biggest issue of modern Linux - the lack of stable API/ABI - that requires everything to be compiled for every distro. It also naturally documents each program's interface allowing them to be easily rewritten/mocked/logged/debugged etc.
- origin_path 4y ago
- mananaysiempre 4y ago> everything really is just a file in Plan 9 That’s... true, but what “file” means in that sentence is a bit tricky. The graphics protocol (or at least I think it was the graphics protocol) requires each command to be written in a single write() call, so a Plan 9 file is neither an array nor a stream of bytes, it includes those implicit boundaries as well. The interface used for impersonating users, IIRC, looks like a kernel-implemented file server but that file server essentially uses its kernel nature by referencing the process that opened the file, so this interface only deserves being called a file if /dev/stdin and /proc/self in classic Unix do as well. I like Plan 9, mind you, but I also think we ought to be careful in treating it as an existence proof for what the pure everything-as-a-file model can do. Even outside of things Plan 9 doesn’t and can’t implement (e.g. modern bandwidth-limited 3D graphics), it also has some hacks in parts it does.
- torginus 4y agoThat sounds strange - mind you I'm not familiar with Plan 9, but was the graphics wire protocol text-based? If yes, why wasn't the separation handled by newlines? I'm sure you can encode command separators in binary without the need to rely on write flushes.
- pjmlp 4y agoHave some fun reading about Carmack's point of view on Plan 9 graphics. https://marc.info/?a=111558719100068&r=1&w=4 https://marc.info/?a=111558719100068&r=1&w=4
- hulitu 4y ago> Have some fun reading about Carmack's point of view on Plan 9 graphics. > https://marc.info/?a=111558719100068&r=1&w=4 https://marc.info/?a=111558719100068&r=1&w=4 > "Computers should feel instant whenever possible. This involves the event path, whatever processing is done, the speed of drawing, and the way the drawing is displayed." This was 27 years ago and still no progress on this field.
- MarkusWandel 4y agoPlan 9 is a fascinating time capsule of a period where text terminals were just being replaced with graphics ones. Which of course Plan 9 had a cleverly designed one for. However if it had become mainstream, it would be just as cluttered up with inelegant stuff as Linux is now, in the endless pursuit of, say, graphics bandwidth performance, first for videos, then for 3D immersive games and now to merely draw your desktop. Mount an audio device remotely. Lovely. But try to get that working with Bluetooth, something mainstream desktop Linux has only just recently managed (i.e. use bluetooth headsets reliably and without fuss). Ditto for 10GB ethernet or what have you. Elegance is quickly sacrificed at the altar of efficiency and expediency. At the risk of inciting disagreement, look at what happened to the originally relatively elegant and simple X protocol.
- torginus 4y agoI don't necessarily think so for 2 reasons: The fact that the lowest level of interaction you can have with a computer is writing memory. When writing device drivers, or interfacing with microcontroller hardware, the way you give commands and transfer data is by writing your command to a memory-mapped device register, or an area of memory that will be copied to the target device. This, coupled with the ability to map a file to memory, allows this paradigm to compete with the most efficient bare-metal implementations. One particular example is the /dev/draw interface mentioned in the article, where anyone could literally write graphics program just by fiddling with bits in memory, just like in DOS or the C64. The other thing is, modern computers are networks in a box. For example, what if your GPU is a separate computer networked over a high-speed link. What if I could upload a texture just by opening a 'file' on the GPU, mmaping -it and memcpy-ing the data into it? I don't see anything particularly inefficient here, particularly if the data transfer can be handle by a special network protocol that takes advantage of PCIExpress.
- zozbot234 4y ago> For example, what if your GPU is a separate computer networked over a high-speed link. What if I could upload a texture just by opening a 'file' on the GPU, mmaping -it and memcpy-ing the data into it? AIUI, you need something like CXL to implement a proper concurrency model that works seamlessly for both local and remote memory. So we're kinda close to what you're describing but not quite there yet.
- slmjkdbtl 4y ago> Plan 9 failed, in a sense, because Unix was simply too big and too entrenched by the time Plan 9 came around. So many good ideas in so many areas didn't go off for this reason (some previous design is already too widely adopted)..
- hulitu 4y agoAnother reason was that the GUI would not run on most systems.
- DC-3 4y ago> [Plan 9] is the most interesting operating system that you’ve never heard of Drew, who do you think is reading your blog if not the sort of people who know what Plan 9 is :p
- nhanb 4y agoGo's io/fs[0] design is one of the more successful ideas inspired by Plan 9 imho. If we can't have a 9p-centric OS, the next best thing is a 9p-like interface in a language's standard library. For example, I have been developing a static site generator where I implement the output folder as an fs.FS[1]. The output generating code is now a simple function that copies from folder A to folder B, without even knowing that A is a virtual filesystem. Now how do I implement a preview server? Simply pass said filesystem to the standard library's http.FileServer. Done. (okay you actually have to pass it through the http.FS() adapter, but that's only because http.FileServer predates io/fs) Of course this kind of abstraction can be done in any language, but Go explicitly specifies this interface, which can already be used by multiple utilities in the standard library (e.g. http.FileServer, go:embed). This nudges people to the same interoperable interface, and I'm all for it. [0]: https://www.youtube.com/watch?v=yx7lmuwUNv8 https://www.youtube.com/watch?v=yx7lmuwUNv8 [1]: https://pkg.go.dev/io/fs#FS https://pkg.go.dev/io/fs#FS
- pjmlp 4y agoWhile a great idea, Java and .NET did it first, on their standard libraries.
- lambertsimnel 4y agoHow interoperable with each other are the various Plan9 variants (including plan9port and hosted Inferno)? If all of the Plan9-like servers on a network have the exact same OS, does that enable possibilities that wouldn't otherwise be available, like migrating running processes between them?
- pjmlp 4y agoThey aren't. Inferno requires userspace code to be written in Limbo.
- qubex 4y agoI have fond memories of setting up a Plan9 installation in 2000-2003 and throughly messing around with it. Really opened my eyes on what “distributed computing” could mean at the architectural level. Their backup soliton (name escapes me) was also very interesting — too many things to mention in a single article. If I’m not mistaken when I ran it they had an older GUI called 9½.
- sanxiyn 4y agoPlan 9's file system was called Fossil, and it had snapshot feature. Fossil was backed by Venti, a content-addressable storage.
- deleted 4y ago[deleted]
- bigbillheck 4y ago> When everything is supposed to be a file on Unix, why is it that the networking API is entirely implemented with special-purpose syscalls and ioctls? The internet existed for most of a decade before Berkeley Sockets. Surely there were other APIs out there. If none of them forced everything to go through a filesystem, maybe that means it's just a bad fit?
- bakul 4y ago> Plan 9 failed, in a sense, because Unix was simply too big and too entrenched by the time Plan 9 came around. The Unix renaissance in the ‘90s had a lot to do with open source source OSes such as (primarily) Linux and the BSDs. Until then we had a bunch of corporate unixes, no two alike but expensive and kernel hacking was basically off limits. With the advent of i386 we had affordable & powerful computers that could run “real” OSes and us hackers were hungry for an open source OS. Computing history might’ve been different if plan9 was made open source before Linux became available. But that was not to be.
- zozbot234 4y agoNote that Linux is basically getting the whole Plan9 feature set added to it, if in incremental and unplanned ways. AIUI, a kernel feature for implementing block devices in user space was added quite recently.
- bakul 4y agoIMHO the kitchensink like approach of adding more features to Linux misses the point of the simplicity of plan9. Representing & accessing resources as file systems was the real insight. If the OS provides N different ways of doing something, it has to continue supporting that which has a real cost. I once compared compiling plan9 & Linux from scratch on the original RaspberryPi. 1 minute versus many hours. Granted that the Linux kernel does a lot more and supported a few more devices on 'pi and plan9 pushes more drivers in the user space but even compiling everything on it took about 4 minutes. That included Ghostscript and two editors and the windowing system and more.
- zozbot234 4y agoLinux has to support its kernel syscall interface, so that Linux-native programs continue to run. Pretty much everything else is up for grabs - but if you want native Linux software to interoperate within a more Plan9-like system, adding features that allow for implementing/managing these kernel-provided interfaces in userspace is helpful.
- PuercoPop 4y ago> The plumber is cool, it’s like “what if xdg-open was good actually” Yeah, plumber is way better than xdg-open in that it is extensible and it can be invoked from a script more easily via 9P. Given how hard it to customize xdg-open, I use a xdg-open wrapper that gets the caller's name using procfs and sends it to the plumber service. That way I can open links on a different browser depending from where the link was clicked/opened from . #!/usr/bin/env bash # this is named xdg-open and placed in a directory that is # before /usr/bin in the $PATH PARENT_COMMAND=$(cat "/proc/$PPID/comm") case "$PARENT_COMMAND" in slack) /home/puercopop/src/plan9/bin/9 plumb -s slack "$@" ;; zoom) /home/puercopop/src/plan9/bin/9 plumb -s zoom "$@" ;; *) /usr/bin/xdg-open "$@" ;; esac And then on my plumbling file I have type is text src is zoom data matches 'https?://.*' plumb to firefox-trunk $data type is text plumb to xdg-open $data
- captainmuon 4y agoI admire Drew Devault's work, but I personally have very different sensibilities on what I consider good software. So this seems to be a case of "Tell me who praises you, and I'll tell you what your mistake is" ;-) "Everything is a file" is a nice idea, but we almost have that in Unix, and it is something that can be emulated perfectly in a programming language or a library. There is no need for the low level stuff to be neat. It has to be performant, secure, and support my hardware. Everything else can - and I think should - be built as abstractions on top. That I can basically run the same applications on macOS, Linux, and Windows shows that it is possible and works well. One thing where Plan 9 is lacking IMHO is in the GUI department. ACME is novel but where are the really new radical (G)UI concepts? I wonder what we would have got if BeOS or Longhorn would have been successful. Both played with the idea that the filesystem is a database. Your file system browser morphs into a mail client, a MP3 player, a photo browser depending on the circumstances. You don't deal with "video files" anymore but "episodes", for example. And I think it is not really a technical but a UX challenge to make something like that work well. I hope that people start experimenting with that stuff again!
- hedora 4y agoThe article touches on how to implement the filesystem half of those ideas in plan 9 when it talks about implementing virtual hardware devices with shell scripts.
- zozbot234 4y ago> Everything else can - and I think should - be built as abstractions on top. The problem is that those abstractions cannot implement the interfaces that, e.g. native Linux programs will expect to use. Features like FUSE (filesystems implemented in userspace) are useful precisely as means of increasing the level of abstraction.
- natas 4y agoSo essentially, based on the above, the security of Plan 9 depends on the identification of a host? Meaning that if one trusted host is compromised in the network, then you can just mount anyone's devices or filesystems?
- ddevault 4y agoNo, there are authentication pieces in place that I did not go into in this article.
- natas 4y agoCompared to Linux or OpenBSD, is Plan9 as "secure", i.e. randomization of tcp seq numbers, cryptography, authentication, mitigation of spectre and hardware vulnerabilities etc. Or it needs some improvements? Meaning, if I had a simple C application that could easily be ported to plan9 but it has to be super secure, would 9front be advisable, or it's better to stick with Linux or OpenBSD for the time being?
- AceJohnny2 4y agoWhenever I read a praise for the conceptual cleanliness and power of niche operating systems, I remind myself: The current mainstream platforms are as complicated as they are because of performance. Abstractions are fine until you realize you're doing thousands of network round-trips to draw a window, so what if you short-circuited that? Yes the 9P protocol sounds great and cleaner than FUSE but what's the IOPS? The reason only some of Plan 9s concepts made it elsewhere was because those were the ones that could be implemented without too steep a performance penalty (or where performance didn't matter). (No excuses for sockets though :p)
- origin_path 4y agoI think a bigger problem is that a pseudo-file is not actually an especially good API for any use case. It's a sort of compromise solution that makes nobody happy. The sockets example is a good example. What programmers want is a function or OOP style API where they can pass strings, type safe structures and so on, but a file is just a stream of bytes so they invented some ad-hoc socket-opening-protocol thing, presumably so you can shell script it. But then shell scripts want to use higher level protocols so it's not useful for them, and programs would wrap that pseudo-file with a library API anyway, so it's just an implementation detail and not so great for that job either. Like, it can introduce a world of parsing/escaping/versioning bugs, race conditions and overheads. In contrast a custom syscall that takes a structure is a more direct interface, more suited for writing actual programs. It also means the API is much more tightly defined. Everything-is-a-file can create a lot of edge cases just like how HTTP creates a lot of edge cases in web programming by pretending everything is a document. What happens if you delete /dev/draw, what does that mean? You need to define the semantics of that. Does it mean closing the window? What about trying to move or copy it - does that make sense? Do you have time to think about all these operations and give them meaningful results? Once you go down the road of saying that there should be a consistent set of operations you can perform on conceptual 'objects' using a generic set of tools and commands, you may start to wonder why you'd pick a file API for that. Why not just invest in objects as a core tech - why not allow binding directly to an object in a remote process or over the network and then have methods and functions actually work? Why pretend it's a file and force everyone to constantly invent mini-protocols and formats, when types and functions are what you need 90% of the time anyway? That's why Microsoft ended up going down the DCOM path, why Apple ended up with XPC/Mach, why Android/BeOS ended up with the Binder and so on. The Plan9 approach wasn't taken up in any big way because if you're going to make a big effort to unify everything it might as well be around objects, not files.
- gnufx 4y agoIn contrast to what Drew says, Plan 9 probably failed because it was proprietary, not because of the Unix predecessor. If it had a free licence at the time, I doubt RMS would have felt the need for GNU, though I don't know what he'd make of some of the design.
- gnufx 4y agoSomething not mentioned is Plan 9 security. Specifically Unix file handles are often quoted as like capabilities, but you do need namespaces to make that useful for isolation. I don't remember exactly what the paper on security in Plan 9 says, but it does talk about capabilities.