▲ 184 points
back
131 comments
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.
As an aside, it's fun to see someone on the organizing committee affiliated with Cray, Inc.
> 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
Thanks for the improvements! Two small quality of life fixes over the original that I particularly appreciate:
- Window resize works as expected,
- Doesn't lose input focus on resize or move, and
- *Dyamic* scaling.
It had to happen. I was constantly annoyed at having to RDP over to a Linux box to try stuff. And I might end up doing a Plan9 RDP server as well.
Ooh la la
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.
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.
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.
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.
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.
> A printed version of the proceedings will be provided to the attendees
How adorable!
Modern Plan9 web version https://github.com/tractordev/apptron
That's cool, but what about it is plan9-like?
I was hoping it would explain "what is Plan 9", or rather, "why is it called plan 9, and what were the other 8 plans?"...
Its name ("Plan 9 from Bell Labs") is a reference to the movie "Plan 9 from Outer Space" :-)
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.
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.
I’m fairly sure that Rust compiler is bigger than the entire 9front (and 9front has Doom in it).
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.
Dozer might be the most likely path to that.
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
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?
That's why it's a research OS, a lot of people (or at least some) think that the current range of mainstream OS are not very well designed, and we can do better.
I'm not saying Plan 9 is the alternative, but it is kind of amazing how un-networked modern Operating Systems are, and we just rely on disparate apps and protocols to make it feel like the OS is integrated into networks, but they only semi-are.
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.
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.
The most "research" thing I'm aware of 9front (since you're speaking in present tense) doing is that GEFS needed to work out a lot of things for itself that weren't in the Bε-tree proof-of-concept FS that came before.
I dunno how "close to the metal" you'd consider that.
("GEFS" being a disk filesystem that's been discussed on HN.)
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!
Indeed, no, we shouldn't be sure everything-is-a-file makes sense to do OS research. I don't think this is particularly necessarily what need to considered close to the metal. But it is os research.
I think you're right about where computing is today. It's mostly at the app level.
I think you once again hit a super hard conventionality chord & speak to where we are by saying we don't have much evidence of "everything is a file* helping, anywhere. Broadly.
But analyzing where we are & assessing they everything-is-a-file isn't a sure thing doesn't dissuade me. Apps have wanted control, and there's beenfew drivers to try to unite & tie together computing. App makers would actively resist if not drag their feet against giving up total dominion of the user experience. OS makers don't have the capital to take over the power from apps. The strain of unweaving this corporate power interests is immense.
There have been some attempts. BeOS tried to do interesting things with enriching files, with making their more of a database. Microsoft's cancelled WinFS is rumored to have similarly made a sort of OS filesystem/database hybrid that would be useful to the users without the apps. But these are some of the few examples we have of trying anything.
We're in this era where agents are happening, and it's clear that there's very few clear good paths available to us now for agents to actuate & articulate the changes they could and should be doing. Which is just a reflection of app design where the system state is all bundled up deeply inside these bespoke awkward UIs. App design doesn't afford good access, and part of the proof is that other machines can't control apps short of enormous visual processing, which leaves much ambiguity. If agents can't it also strongly implies humans had little chance to master and advance their experience too.
I strongly think we should have some frontiers for active OS research that are user impactful. We ought be figuring out how to allow better for users, in ways that will work broadly & cross cuttingly. Everything is a file seems like one very strong candidate here, for liberating some of the power out of the narrow & super specific rigid & closed application layer.
I think Dan was also super on point writing A Social Filesystem. Which is that social networks & many online systems are everything-as-a-file under the hood. And that there is generic networked multi-party social networking platform available, that we have a super OS already here that does files super interestingly. And Dan points out how it unlocks things, how not having one specific app but having our online data allow multiple consumers, multiple tools, is super interesting an opening.
So, everything is a file is very webful. A URL logically ought be. A multi-media personal data server for every file you can imagine creates an interest powerful OS, and a networked OS.
And users have been warped into fitting the small box their apps demand of them so far. They've had no option about it. All incentive has been to trap users more and more to have no off roads to keep your tool being the one tool for the job.
Distribute the power. Decentralize off the app. Allow other tools. Empower broader OS or platform to let users work across media types and to combine multiple tools and views in their workflow. Allow them to script and control the world around them, to #m2m orchestrate & drive tool use.
I don't disagree with anything you said I just think it's a 30 year old basis you stand from, one that hasn't helped had gotten better and which has ongoingly shrunk what is possible & limited the ability to even start trying for more or better. I don't think we are served by what it feels like you are trying to highlight. And I think "everything is a file" could be an incredible way to start opening up better, possibly, maybe!! but I'm very down to hear other reasonable or out there ideas!! I'm just not interested in staying in the disgraceful anti-user app-controlled unyielding quagmire we have been trapped in for decades.
Is there Plan9 port for RISC-V (RV32I) ?
There's a 9legacy port, and an in-progress 9front port.
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.
>9front.org frequently questioned answers
Knowing that project am I going to be rickrolled?