9front averages several commits a day:
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 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
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.
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.
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.
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.
Which tends to be forgotten when praising Plan 9.
However the influence is quite clear, plus the Oberon-2 style methods and SYSTEM package.
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.
However I will commit the sacrilege to suggest Android is the closest we got there on mainstream OSes.
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.
Still, the thoughts were in common, even though the final solution didn't end up being exactly the same.
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.)
If "modern" means complex, I don't think it fits Plan9.
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.
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.
Knowing that project am I going to be rickrolled?
Next question is how much RAM it needs to boot and can it be used without rio ?
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.
Multiple experimental operating systems at multiple abstraction levels sounds like a good idea, though. What sort of system software would you like to build?
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.
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.
Well for one thing, such an abstraction enables you to avoid web apis and sql databases!
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.
<>/mnt/sql/clone{
echo 'SELECT * from ...' >[1=0]
cat /mnt/sql/^`{read}^/data # or awk, or whatever
}
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.
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.