Plan 9 is still alive and kicking -- The next Plan 9 conference will be in Victoria, BC in Canada later this year.
9front averages several commits a day:
I’ve been on/off playing with 9front on an old laptop. I’ve been having a lot of fun with it, it’s fun to write code for, but i have had a hard time using it as anything but a toy.
I would love to use it as my main desktop, but ultimately (and kind of unsurprisingly), the blocker is the lack of a modern browser and a lack of video acceleration.
I’m sure I could hobble something together with virtualization for the former but I don’t see a fix for video acceleration coming.
Maybe I could install it on a server or something.
I did the same with an old Thinkpad but somehow found it relies too heavily on the mouse. I might still go back to it because I love how far they've taken the "everything is a file" idea and would like to experiment more with that.
> Theo is more specific than troll; it presents insults from OpenBSD founder Theo de Raadt.
check fortune(1) command.
People wanting a Retina-capable drawterm to access Plan9/9front from their Macs are welcome to have a look at https://github.com/rcarmo/drawterm
Ooh la la
> A printed version of the proceedings will be provided to the attendees
How adorable!
Why did BSD make Unix sockets something outside of the file system?
I can do this in bash but I always thought it would be more elegant to do a similar thing in C. I thought Plan 9 handled it more like this?
cat < /dev/tcp/localhost/22
SSH-2.0-OpenSSH_10.0
They did not have the original unix vision. and it is a lot easier to to design an interface as a programming interface than shoehorn it into a filesystem interface.
I think having a filesystem interface is pretty great, and plan9 showed it could be done. but having to describe all your io in the [database_key, open(), close(), read(), write(), seek()] interface. can be tricky and limiting for the developer. It is pretty great for the end user however. Having a single api for all io is a super power for adaptive access patterns.
I think the thing that bothers me the most about the bsd socket interface is how close it is to a fs interface. connect()/bind() instead of open(), recv()/send() instead ot read()/write() but it still uses file discripters so that stuff tends to work the same. We almost had it.
As much as I like BSD and as great an achievement that the socket interface was, I still think this was their big failure.
I just think this sounds very elegant
https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#/net
> Plan 9 does not have specialised system calls or ioctls for accessing the networking stack or networking hardware. Instead, the /net file system is used. Network connections are controlled by reading and writing control messages to control files. Sub-directories such as /net/tcp and /net/udp are used as an interface to their respective protocols.
> Combining the design concepts
> Though interesting on their own, the design concepts of Plan 9 were supposed to be most useful when combined. For example, to implement a network address translation (NAT) server, a union directory can be created, overlaying the router's /net directory tree with its own /net. Similarly, a virtual private network (VPN) can be implemented by overlaying in a union directory a /net hierarchy from a remote gateway, using secured 9P over the public Internet. A union directory with the /net hierarchy and filters can be used to sandbox an untrusted application or to implement a firewall.[43] In the same manner, a distributed computing network can be composed with a union directory of /proc hierarchies from remote hosts, which allows interacting with them as if they are local.
> When used together, these features allow for assembling a complex distributed computing environment by reusing the existing hierarchical name system
I remember first setting up NAT or IP masquerading around 1998. It seemed like an ugly hack and some custom protocols did not work.
I use a bunch of VPNs now and it still seems like a hack.
The Plan 9 way just seems very clean although you now have to secure the server more strongly because you are exporting filesystems from it and others are mounting it.
> can be tricky and limiting for the developer. It is pretty great for the end user however.
This seems to be a great general principle of api design! The best apis are those that are hated by the developer and loved by the end users.
> The best apis are those that are hated by the developer and loved by the end users.
No, just those loved by the API consumer. Negative emotions on one end doens't do anything positive.
In the case of plan9, not everything can be described elegantly in the filesystem paradigm and a lot of things end up having really awkward "ctl" files which you write command strings to that the fileserver needs to parse. It also handicaps performance due to the number of filesystem operation roundtrips you usually end up making.
Maybe if combined with something io_uring-esque, but the complexity of that wouldn't be very plan9-esque.
> a lot of things end up having really awkward "ctl" files which you write command strings to that the fileserver needs to parse.
These are no different in principle than ioctl calls in *ix systems. The `ctl` approach is at least a proper generalization. Being able to use simple read/write primitives for everything else is nonetheless a significant gain.
can you give a few examples of this "lot of things"? What operations do not map naturally to file access?
Modern Plan9 web version https://github.com/tractordev/apptron
The transition step between UNIX and Inferno, and between C and Limbo as main userspace language, by its authors.
Which tends to be forgotten when praising Plan 9.
Is it correct to say Golang is bringing Limbo to the masses?
Partially, Go still doesn't support a few Limbo features.
However the influence is quite clear, plus the Oberon-2 style methods and SYSTEM package.
No, it's bringing Aleph to the masses. Limbo is a cousin, and Dis was certainly very interesting and something I wish had caught on.
Aleph lacked GC, which Rob Pike considered the main reason for its implementation failure on Plan 9, and initially bounds checking was also missing.
Two key design difference from Go and its two predecessors.
Dis is an implementation detail, Go could offer the same dynamism with AOT toolchain, as proven by other languages with ahead of time toolchains available.
Dis is not an implementation detail for Inferno, though. And I wish it had gone much further.
I agree, but that is another matter.
However I will commit the sacrilege to suggest Android is the closest we got there on mainstream OSes.
That might be Rust, actually. They have more in common with thoughts about type systems, built-in constructs, deterministic memory usage, etc.
Limbo looks more like Go on the concurrency front, but that was inherited from Alef/Plan 9. That wasn't what Limbo brought to the table.
Limbo uses a garbage collector, though.
So does Rust. Rust is 'smarter' than Limbo, in that it can avoid using its GC in a lot of cases (but not all, hence why it still has GC to fall back on when necessary), but, I mean, that discovery was the reason for why Rust was created. Limbo was already there otherwise. Every new language needs to try to add something into the mix.
Still, the thoughts were in common, even though the final solution didn't end up being exactly the same.
Rust does not have a garbage collector in any way or form. It's just automatic memory like we're used to (e.g., stack in C++), with the compiler injecting free/drop when an object goes out of scope.
What Rust brings is ownership with very extensive lifecycle tracking, but that is a guard rail that gives compile-time failures, not something that powers memory management.
(If you consider the presence of Rc<T> to make Rust garbage collected, then so is C garbage collected as developers often add refcounting to their structs.)
Are you trying to say that Rc/Arc are GCs? I guess you're technically correct, but no one sees it that way.
I would say that RC is GC, yes, as it is most definitely technically true. But it was pjmlp who suggested it originally (Limbo also uses reference counting), so we have clear evidence that others also see reference counting as being GC. We wouldn't have a discussion here otherwise.
IMO, the biggest curse of the Internet age is how Distributed OS's did not become mainstream. Maybe we should repackage these as Unikernels and run our apps using their distribution services directly on a hypervisor.
k8s is really just a distributed OS implemented on top of Linux containers, only with extra facilities for automated tuning, scaling and overall management that are lacking on bare plan9.
9front it's far ahead of docker and crappy namespaces running on a libre reimplementation of a dead end Unix version. They did things right from the start. bind it's far superior to anything else.
But... muh scalability!
I would love to see more Rust on Plan9 implementations, IMHO, could be a good modern combination.
I don't know. I use a lot of Swift and C++ and while both are OK languages there is an absurd amount of complexity in these languages that doesn't seem to serve any real purpose. Just a lot of foot traps, really. Coming back to Plan9 from that world is a breeze, the simplicity is like a therapy for me. So enjoyable.
If "modern" means complex, I don't think it fits Plan9.
As a Swift noob, I would appreciate hearing what these foot traps are. This is in the context of Swift as a systems programming language?
I don't know about Swift, but in C++, the complexity serves at least three purposes:
1. Backwards compatibility, in particular syntax-wise. New language-level functionality is introduced without changing existing syntax, but by exploiting what had been mal-formed instructions.
2. Catering to the principle of "you don't pay for what you don't use" - and that means that the built-ins are rather spartan, and for convenience you have to build up complex structures of code yourself.
3. A multi-paradigmatic approach and multiple, sometimes conflicting, usage scenarios for features (which detractors might call "can't make up your mind" or "design by committee").
The crazy thing is that over the years, the added complexity makes the code for many tasks simpler than it used to be. It may involve a lot of complexity in libraries and under-the-hood, but paradoxically, and for the lay users, C++ can be said to have gotten simpler. Until you have to go down the rabbit hole of course.
AFAIK there is no Rust compiler for Plan 9 or 9front. The project is using a dialect of C and its own C compiler(s). I doubt adding Rust to the mix will help. For a research OS, C is a nice clean language and the Plan 9 dialect has a some niceties not found in standard C.
If you really want Rust, check this https://github.com/r9os/r9 it is Plan 9 reimplemented in Rust (no idea about the project quality):
R9 is a reimplementation of the plan9 kernel in Rust. It is not only inspired by but in many ways derived from the original Plan 9 source code.
There isn't, though you can run it over wasm on it. I tried it a while back with a port of the w2c2 transpiler (https://github.com/euclaise/w2c9/), but something like wazero is a more obvious choice
I’m fairly sure that Rust compiler is bigger than the entire 9front (and 9front has Doom in it).
Since Rust depends on LLVM, which is massive, that is almost certainly true. It seems likely even if you don't include LLVM though.
You would like Golang more than Rust. At leat the authors (and ex-authors) for sure they are aware of Go, they invented it too.
>9front.org frequently questioned answers
Knowing that project am I going to be rickrolled?
ZeroFS [0] is very thankful for what it brought to Linux with the v9fs [1] subsystem which is very nice to work with (network native) compared to fuse :)
I believe that the Windows Subsystem for Linux (WSL, really a Linux subsystem on Windows) uses the Plan 9 network protocol, 9p, to expose the host Windows filesystem to the Linux virtual environment.
Is there Plan9 port for RISC-V (RV32I) ?
There's a 9legacy port, and an in-progress 9front port.
That's interesting, thanks. I feel a need for simple multitasking/networking OS for synthesizable RV32I core (not RTOS like, but more like Unix or CP/M). Would be nice to try Plan9 on it once port is out.
Probably not. And there aren't many 32-bit RISC-V cores with an MMU. I guess you can use a simulator if you found one.
I use one written in SpinalHDL. :-)
Next question is how much RAM it needs to boot and can it be used without rio ?
I’m not sure it still makes sense to do OS research so close to the metal. Most computing is done up on the application level, and our abstractions there suck, and I haven’t seen any evidence that “everything is a file” helps much in a world of web APIs and SQL databases
Idk I still find low level OS stuff super interesting because it hasn't had a rework in so long. With everything we've learnt since the age of modern computing, drives larger than a few MBs, super fast memory and fast cryptography to name a few.
It's interesting to imagine a new OS that incorporates these changes from it's infancy.
I appreciate all of the effort put in by Linux, BSD, Android, QNX and closed source OSs' have put in to building upon existing ideas and innovating gradually on them. But man I really want to see something better than everything is a file. I really enjoyed the stuff BeOS was pitching.
Well, on the file system side BeOS was pitching "virtual folders" that are really no different than what plan9 provides.
Some of us are still interested in the world underneath all that web stuff!
Multiple experimental operating systems at multiple abstraction levels sounds like a good idea, though. What sort of system software would you like to build?
Operating systems are where device drivers live. It sounds awfully impractical to develop alternatives at this stage. I think OP is right.
I think OSes should just freeze all their features right now. Does anyone remember all the weird churn in the world of Linux, where (i) KDE changed from version 3 to 4, which broke everyone's KDE completely unnecessarily (ii) GNOME changed from version 2 to 3, which did the same (iii) Ubuntu Linux decided to change their desktop environment away from GNOME for no reason - but then unchanged it a few years later? When all was said and done, nothing substantive really got done.
So stop changing things at the OS level. Only make conservative changes which don't break the APIs and UIs. Time to feature-freeze, and work on the layers above. If the upper layers take over the work of the lower layers, then over time the lower layers can get silently replaced.
I didn’t really see the appeal until I learned how to use FUSE.
There’s something elegant about filesystems. Even more than pipes, filesystems can be used to glue programs together. Want to control your webcam with Vim? Expose a writable file. Want to share a device across the network? Expose it as a file system, mount that filesystem on your computer.
The "everything is a file" approach is nice in many cases, I'm worried though if it works everywhere. Maybe if done right. Subversion (SVN) shows branches as separate file trees.. and ClearCase too (though I'm on thin ice with ClearCase, having used it very little). And I just can't stand the file-oriented way SVN works, I could never get used to it. But there are a lot of other cases where "it's a file" does work, I've experimented with creating Fuse filesystem interfaces to some stuff now and then.
> I haven’t seen any evidence that “everything is a file” helps much in a world of web APIs and SQL databases
Well for one thing, such an abstraction enables you to avoid web apis and sql databases!
You're going to have to explain to me how a parametrized request/response system like calling a Web API or making a SQL query can be mapped to reading files. I've seen some stuff that people do with FUSE and it looks like ridiculous circus hoop jumping to making the Brainfuck-is-Turing-complete version of a query system. We have syntax for a reason.
Plan9 allows for implementing file servers in user space and exporting a whole file tree as a virtual "folder", so it's really more of "everything as a file server". No different than FUSE, really.
From what I've seen, Plan 9 fans turn their noses up at FUSE. They say FUSE is not "it", but don't really seem to explain what "it" is to differentiate it from FUSE.
And as Feynman said, you don't truly understand a thing until you can teach it. So that leaves us in a weird predicament where the biggest proponents of Plan 9 apparently don't understand Plan 9 well enough to teach it to the rest of us.
It depends what you mean by "it". FUSE clearly doesn't give you every feature in plan9, and in fact you can't have that without giving up the current Linux syscall API completely and replacing it with something vastly simpler that leaves a lot more to be done in user space. That's not something that Linux is going to do by default, seeing as they have a backward compatibility guarantee for existing software. Which is totally OK as far as it goes; the two systems just have different underlying goals.
You're frustrating me. You replied to me saying "it's basically FUSE" and then after I replied to you, you come back and say, "it's not really FUSE."
Plan 9 supports file server processes natively, and that's the part that's most FUSE-like. The full OS also has many other worthwhile features that are not really addressed by FUSE on its own, or even by Linux taken as a whole.
Typically, if you were writing your hypothetical sql client in rc shell, you'd implement an interface that looks something like:
This is also roughly how webfs works. Making network connections from the shell follows the same pattern. So, for that matter, does making network connections from C, just the file descriptor management is in C.<>/mnt/sql/clone{ echo 'SELECT * from ...' >[1=0] cat /mnt/sql/^`{read}^/data # or awk, or whatever }This is... I don't know. I don't get why I would care to sling SQL over a file system versus a network socket.
I mean, Postgres could offer an SSH interface as a dumb pipe to psql to just have you push text SQL queries in your application. But it doesn't, it offers a binary protocol over a network socket. All the database engines have had the same decision point and have basically gone down the same path of implementing a wire protocol over a persistent socket connection.
So yeah, I don't get what doing things this way would give me as either a service provider or a service consumer. It looks like video game achievements for OS development nerds, "unlocked 'everything is a file'." But it doesn't look like it actually enables anything meaningful.
How would you connect to Postgres in 4 lines of shell normally? How would you do it for a rest api? How about any other systems?
For Plan 9, it's all the same, all using the same interfaces, with little library glue.
Opening a window, and running a command in it? Similar interfaces. Adding LSP to your editor? Got it, you mount it and write to the files.
Universal shared conventions are powerful.
In addition to the sibling comment, you might also consider simply not using the APIs or SQL queries to begin with. Many people have entire careers without touching either.
Why would I ever consider doing that?
That's up to you. Why ask me?
I think you're failing to get that using a filesystem API to work with things that aren't naturally anything like filesystems might get perverse. And standard filesystems are a pretty unnatural way to lay out information anyway, given that they force everything into a tree structure.
This is what I was trying to get at. A lot of the data I deal with is directed, cyclic graphs. Actually, I personally think most data sets we care about are actually directed graphs of some kind, but we've gotten so used to thinking of them as trees that we force the metaphor too far. I mean, file systems are an excellent example of a thing we actually want to be a graph but we've forced into being a tree. Because otherwise why would we have ever invented symlinks?