Back when I was in university we had a small course on Limbo/Inferno because of a connection my university (RIT) had to bell labs. I took the course in... 1998? and wrote a version of Tetris for limbo. The code was awful, but did find a bug in the Tk implementation. This lead me to my proudest/most embarrassing programming moment - apparently, my code ended up in front of Dennis Ritchie, who thought the code was terrible. Whatever, Dennis Ritchie looked at my code!
I went to RIT in 2003-2010 for CS and took Axel Schreiner's first Golang course (which AIUI was the second GoLang course offered anywhere, at a Uni level)
Among other classes I took with Axel, he definitely spent at least 20% of the time overall talking about Inferno. I never had my code in front of Dennis Ritchie, but I will throw in from my perspective, the most valuable part of a CS education from RIT was hearing that my code was terrible, just enough times to make me want to make it better later on, in my professional career when it has started to matter.
I'm a little weirded out cause I can't view any of the files or download, either it's a bug you found on GitHub (ha!) or it's a permissions thing? I came here for code, and got bugs... hah
In reality, this was an attempt to turn Plan 9 into a commercial product.
Plan 9 despite it's crazy UI (the shell and editor have been ported to Linux so some people must have liked it) brought a lot of new ideas which eventually found their way into other projects such as Linux containers and Go (for obvious reasons).
One really good idea that died with Plan 9 was transparent distribution of CPUs across the network. You could - the same way you mount a network drive today - mount a remote CPU and run your local software on it.
Transparently gluing boxes together over a low bandwidth fabric died as an active research area right around the time Plan9 was seeing its first development. By the late 80s shared bus SMP had demonstrated its practicality and quickly became the predominant architecture. Today we don't spawn processes on remote CPUs because the whole act of scheduling on multiple CPUs is entirely transparent to us, that's a competing architecture to the predecessor found in Plan 9
MOSIX is the only system from that era that I know is still around. It had a fork by the name of OpenMosix for some time, but according to Wikipedia ( https://en.wikipedia.org/wiki/MOSIX#openMosix ): "On July 15, 2007, Bar decided to end the openMosix project effective March 1, 2008, claiming that "the increasing power and availability of low cost multi-core processors is rapidly making single-system image (SSI) clustering less of a factor in computing"
(I admire the downvote, but please realize this is not a question of one's opinion!)
QNX can do that as well. You can, from the command line, run a program on computer A referencing a file from computer B and pipe the output to a program on computer C and send that output to a file on computer D.
Although I'm not sure how that "mounting" of cpus would avoid people hogging resources. I use a HPC system where users submit jobs and there's a whole complicated queuing system going on to make sure that greedy users don't monopolize the system.
"fully" distributed resources; memory, cpu, storage, what have you...
"LegoOS is a disseminated, distributed operating system designed for hardware resource disaggregation. It is an open-source project built by researchers from Purdue University. LegoOS splits traditional operating system functionalities into loosely-coupled monitors and run them directly on disggregated hardware devices."
There are times when I wish Plan9 and/or Inferno took off and won some respectable market share. Having a laptop, smartphone, tablet, Synology storage at home, servers on DO, and remnant external HDD from prior era becomes frustrating because my files end up being everywhere and nowhere. There were times when I want to be able to start working on some code on my laptop, pause, then continue work on my tablet later on. At those moments it would have been wonderful if I had Plan9's ability to mount remote filesystems, sync across the network, and have consistent view however I access the data. Yes, SSHFS is available, and the same protocol from Plan9 is available in Linux nowadays, but setting them up isn't as simple as it was in Plan9 and being native to the OS.
That, in addition to the fixes it had (truly everything is a file) and the innovative features delivered (e.g. namespaces).
Can we revive them? Inferno's development seems to have slowed down to a halt.
Plan 9 (and some of its distributions, namely 9front and 9pi, the latter being Plan 9 for the Raspberry Pi) are still developed. No revival needed. You'll just have to download, install and use them. And they come with VNC, if you absolutely need incompatible software like a sane web browser.
edit: That said, I happily use some of Plan9port every day. There never was a better Acme editor (or, rather, Acme2k) on any other operating system. Amazing concept!
> There were times when I want to be able to start working on some code on my laptop, pause, then continue work on my tablet later on
In order to do these things 'cleanly' (with a truly unified view of the entire "system"), you need some sort of process migration infrastructure that even Plan9 and Inferno don't really give you, AFAICT. Projects like OpenMosix and OpenSSI attempted to provide this, but I'm not sure to what extent they were successful, given that they've all been abandoned and bitrotted. Today, one might try to do the same sort of thing while also taking advantage of the new kernel-based namespacing that Linux provides, which might make some things somewhat easier.
I have some sort of love/hate relationship with this project, regarding the Dis VM.
IMHO, having read the spec, I think the VM had a great design for the nineties but was not future-proof enough. It's like it was designed with some specific CPUs of the time in mind, and that biased the design. Also, I find it too tied to the language used in the canonical implementation (obviously C).
In contrast, I find the JVM (contemporary to Dis) more generic and more easy to implement using other languajes than C.
BTW, a few years ago I wrote a (incomplete) Dis VM in C# [0] that I hope to finish^H^H^H^H^H^H rewrite some day...
Just a note for anyone who is looking to try this out: there are currently some fairly hard baked and thorny 32 bit dependencies in the Dis VM, so your system will need to be multilib to run it. There's currently a 64 bit porting effort going on in the form of Purgatorio, but that's still some time away from being complete (I recommend using it anyway because it's the most up to date version of the Inferno tree).
Namespaces: a program's view of the network is a single, coherent namespace that appears as a hierarchical file system but may represent physically separated (locally or remotely) resources
Standard communication protocol: a standard protocol, called Styx, is used to access all resources, both local and remote
The concept here is fairly profound and you could make the analogy of power to something like Lisp.
Lisp everything is a symbol, in Plan9 everything is a file and all namespaces are mutable. This concept is combined in the Interim OS experiment[1]. The idea of everything is a file is very literal and very serious compared to say, unix.
It's worth noting that 9p, while a filesystem protocol, is closer in concept to a REST api than something like say ext4.
In Plan9, the kernel could be thought of as a 9p connection router/multiplexer and all system resources and all servers must express themselves as 9p filesystems. The tooling 9p provides allows you to take trees of named objects (filesystems) and rearrange them however you please and place child processes under rules for modifying their own trees and how they can break scope, if at all.
Forking is more dynamic as provided by rfork[2] where you can give a child a specific subset of your process's namespace. So you could make a child who can only see specific files, executables, or resources and make it so that the child can't mount, unmount, etc.
This OS doesn't require an MMU or protected memory. I wonder if a processor architecture that lacks those features could yield much higher performance due to less complexity, reduced memory latency or less cache miss penalty. Will it be enough to mitigate the perormance penalty of runing code in the Dis VM?
You could do that (see Singularity OS [0] and Midori [1]), but recently it was discovered that it wouldn't work on modern out-of-order CPUs due to Spectre [2].
You'd have to compensate for the lack of memory protection by running all unprivileged code in a VM, which would very likely introduce its own class of complexities and performance penalties.
Would Plan9 fit in with applications like robotics? I feel like such an operating system would do well with the need to interoperate between a bunch of different types of sensors and hardware, and the need for sensor fusion. I’m not sure if Linux and device drivers are the right foundation for that kind of stuff.
The ev3dev project is partially inspired by everything is a file and I've used it in the past for educational purposes by making the business of controlling/using motors/sensors as trivial as read/write.
inferno is cool because it takes a lot of great ideas Ken and rob pike came up with for plan9 to address unfixable architectural flaws inherent to Unix's overall design, and basically makes an vm based portable OS/userland that is everybit what Java could have been.
And then of course Rob Pike, Russ Cox, Ken took what they learned from their background at Lucent and paired it with Robert Griesmers background in developing innovative VMs for Javascript and Java and they essentially put everything they learned to develop the Go programming language.
Which if you get into the architectural aspects of it. You know actually dig into how it's implemented deep down you will see a lot of code that is essentially derived from plan9 and inferno's code in many ways.
I remember reading about this in a Danish PC mag ‘PC Pro’ (or ‘Alt om Net’) in ca 1998. From memory there was also a framework called ‘Hades’ as per the mythological river. Or am I wrong here?
[+] [-] adam_gyroscope|6 years ago|reply
Anyways, here's the awful code: https://github.com/adamf/limbotris
[+] [-] yebyen|6 years ago|reply
Among other classes I took with Axel, he definitely spent at least 20% of the time overall talking about Inferno. I never had my code in front of Dennis Ritchie, but I will throw in from my perspective, the most valuable part of a CS education from RIT was hearing that my code was terrible, just enough times to make me want to make it better later on, in my professional career when it has started to matter.
[+] [-] riffraff|6 years ago|reply
[+] [-] jadbox|6 years ago|reply
[+] [-] fit2rule|6 years ago|reply
[+] [-] giancarlostoro|6 years ago|reply
[+] [-] panpanna|6 years ago|reply
Plan 9 despite it's crazy UI (the shell and editor have been ported to Linux so some people must have liked it) brought a lot of new ideas which eventually found their way into other projects such as Linux containers and Go (for obvious reasons).
One really good idea that died with Plan 9 was transparent distribution of CPUs across the network. You could - the same way you mount a network drive today - mount a remote CPU and run your local software on it.
[+] [-] _wmd|6 years ago|reply
MOSIX is the only system from that era that I know is still around. It had a fork by the name of OpenMosix for some time, but according to Wikipedia ( https://en.wikipedia.org/wiki/MOSIX#openMosix ): "On July 15, 2007, Bar decided to end the openMosix project effective March 1, 2008, claiming that "the increasing power and availability of low cost multi-core processors is rapidly making single-system image (SSI) clustering less of a factor in computing"
(I admire the downvote, but please realize this is not a question of one's opinion!)
[+] [-] spc476|6 years ago|reply
[+] [-] henesy|6 years ago|reply
Linux lacks a lot of core abstraction properties that would make containers elegant to implement under something like the Plan9 model, at least.
Cool project inspired partially by Linux containers: https://doc.9gridchan.org/guides/spawngrid
[+] [-] jhbadger|6 years ago|reply
[+] [-] lighthazard|6 years ago|reply
[+] [-] rhabarba|6 years ago|reply
[+] [-] darkpuma|6 years ago|reply
A manifestation of Cat-V.org Derangement Syndrome I wager.
[+] [-] soganess|6 years ago|reply
"fully" distributed resources; memory, cpu, storage, what have you...
"LegoOS is a disseminated, distributed operating system designed for hardware resource disaggregation. It is an open-source project built by researchers from Purdue University. LegoOS splits traditional operating system functionalities into loosely-coupled monitors and run them directly on disggregated hardware devices."
[+] [-] m_sahaf|6 years ago|reply
That, in addition to the fixes it had (truly everything is a file) and the innovative features delivered (e.g. namespaces).
Can we revive them? Inferno's development seems to have slowed down to a halt.
[+] [-] rhabarba|6 years ago|reply
edit: That said, I happily use some of Plan9port every day. There never was a better Acme editor (or, rather, Acme2k) on any other operating system. Amazing concept!
[+] [-] 0815test|6 years ago|reply
In order to do these things 'cleanly' (with a truly unified view of the entire "system"), you need some sort of process migration infrastructure that even Plan9 and Inferno don't really give you, AFAICT. Projects like OpenMosix and OpenSSI attempted to provide this, but I'm not sure to what extent they were successful, given that they've all been abandoned and bitrotted. Today, one might try to do the same sort of thing while also taking advantage of the new kernel-based namespacing that Linux provides, which might make some things somewhat easier.
[+] [-] nine_k|6 years ago|reply
You can have file sync with syncthing, or similar, again across platforms.
[+] [-] luismedel|6 years ago|reply
IMHO, having read the spec, I think the VM had a great design for the nineties but was not future-proof enough. It's like it was designed with some specific CPUs of the time in mind, and that biased the design. Also, I find it too tied to the language used in the canonical implementation (obviously C).
In contrast, I find the JVM (contemporary to Dis) more generic and more easy to implement using other languajes than C.
BTW, a few years ago I wrote a (incomplete) Dis VM in C# [0] that I hope to finish^H^H^H^H^H^H rewrite some day...
[0] https://bitbucket.org/luismedel/sixthcircle/src/default/
[+] [-] dang|6 years ago|reply
2014: https://news.ycombinator.com/item?id=8801372
2011: https://news.ycombinator.com/item?id=3007069
[+] [-] MisterTea|6 years ago|reply
[+] [-] ACE_Recliner|6 years ago|reply
[+] [-] henesy|6 years ago|reply
Purgatorio 64-bit is a ways away, but is a goal.
It'll happen eventually, but the more eyes the better.
[+] [-] fghtr|6 years ago|reply
Standard communication protocol: a standard protocol, called Styx, is used to access all resources, both local and remote
This looks similar to Qubes Air roadmap: https://www.qubes-os.org/news/2018/01/22/qubes-air/
[+] [-] henesy|6 years ago|reply
Lisp everything is a symbol, in Plan9 everything is a file and all namespaces are mutable. This concept is combined in the Interim OS experiment[1]. The idea of everything is a file is very literal and very serious compared to say, unix.
It's worth noting that 9p, while a filesystem protocol, is closer in concept to a REST api than something like say ext4.
In Plan9, the kernel could be thought of as a 9p connection router/multiplexer and all system resources and all servers must express themselves as 9p filesystems. The tooling 9p provides allows you to take trees of named objects (filesystems) and rearrange them however you please and place child processes under rules for modifying their own trees and how they can break scope, if at all.
Forking is more dynamic as provided by rfork[2] where you can give a child a specific subset of your process's namespace. So you could make a child who can only see specific files, executables, or resources and make it so that the child can't mount, unmount, etc.
[1] Interim OS: https://github.com/mntmn/interim
[2] http://man.cat-v.org/9front/2/fork
Some cool manuals:
- http://man.cat-v.org/9front/1/bind
- http://man.cat-v.org/9front/1/ns
- http://man.cat-v.org/9front/3/proc
- http://man.cat-v.org/9front/5/intro
[+] [-] rhabarba|6 years ago|reply
[+] [-] henesy|6 years ago|reply
Some Inferno related stuff:
- Limbo by Example: https://github.com/henesy/limbobyexample
- The Inferno Shell: http://debu.gs/entries/inferno-part-1-shell
- Try Inferno in the browser: http://tryinferno.rekka.io/
- Cat-v Inferno resources: http://doc.cat-v.org/inferno
- Experiments in Inferno/Limbo: https://github.com/caerwynj/inferno-lab/
- Inferno Programming with Limbo: https://web.archive.org/web/20160304092801/http://www.gemuse... (also on cat-v)
- Developing Limbo modules in C: https://powerman.name/doc/Inferno/c_module_en
- Simple FS example in Limbo: https://github.com/henesy/simplefs-limbo
- Inferno client for Redis: https://github.com/pete/iredis
- Inferno for Nintendo DS: https://bitbucket.org/mjl/inferno-ds/src/default/
- Inferno as an Android app: https://github.com/bhgv/Inferno-OS_Android
- Inferno replacing Android (hellaphone): https://bitbucket.org/floren/inferno/wiki/Home
- Porting Inferno to Raspberry Pi: https://github.com/yshurik/inferno-rpi
[+] [-] henesy|6 years ago|reply
[+] [-] sprash|6 years ago|reply
[+] [-] the_why_of_y|6 years ago|reply
[0] https://research.cs.wisc.edu/areas/os/Seminar/schedules/pape... [1] http://joeduffyblog.com/2015/11/03/blogging-about-midori/ [2] https://arxiv.org/abs/1902.05178
[+] [-] soraminazuki|6 years ago|reply
[+] [-] based2|6 years ago|reply
[+] [-] yingw787|6 years ago|reply
[+] [-] henesy|6 years ago|reply
http://doc.cat-v.org/inferno/4th_edition/styx-on-a-brick/
The ev3dev project is partially inspired by everything is a file and I've used it in the past for educational purposes by making the business of controlling/using motors/sensors as trivial as read/write.
https://www.ev3dev.org/
[+] [-] ori_b|6 years ago|reply
[+] [-] bangonkeyboard|6 years ago|reply
[+] [-] nurettin|6 years ago|reply
[+] [-] mortdeus|6 years ago|reply
And then of course Rob Pike, Russ Cox, Ken took what they learned from their background at Lucent and paired it with Robert Griesmers background in developing innovative VMs for Javascript and Java and they essentially put everything they learned to develop the Go programming language.
Which if you get into the architectural aspects of it. You know actually dig into how it's implemented deep down you will see a lot of code that is essentially derived from plan9 and inferno's code in many ways.
[+] [-] hestefisk|6 years ago|reply
[+] [-] rhabarba|6 years ago|reply