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?
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.
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 filenserver". No different than FUSE, really.
Typically, if you were writing your hypothetical sql client in rc shell, you'd implement an interface that looks something like:
<>/mnt/sql/clone{
echo 'SELECT * from ...' >[1=0]
cat /mnt/sql/^`{read}^/data # or awk, or whatever
}
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.
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.
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.
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.
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.
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.
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 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
https://iwp9.org/
9front averages several commits a day:
https://git.9front.org/plan9front/9front/HEAD/log.html
Multiple experimental operating systems at multiple abstraction levels sounds like a good idea, though. What sort of system software would you like to build?
Well for one thing, such an abstraction enables you to avoid web apis and sql databases!
Which tends to be forgotten when praising Plan 9.
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 the influence is quite clear, plus the Oberon-2 style methods and SYSTEM package.
Knowing that project am I going to be rickrolled?
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.
https://m.youtube.com/watch?v=EOg6UzSss2A
Next question is how much RAM it needs to boot and can it be used without rio ?
[0] https://github.com/Barre/ZeroFS
[1] https://docs.kernel.org/filesystems/9p.html