
Inferno Operating System - giancarlostoro
https://en.wikipedia.org/wiki/Inferno_(operating_system)
======
adam_gyroscope
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!

Anyways, here's the awful code:
[https://github.com/adamf/limbotris](https://github.com/adamf/limbotris)

~~~
riffraff
I find it impressive you still have code you wrote for a university class in
'98!

~~~
AJ007
My dad has a box of punchcards for code he wrote in his university class, well
before ‘98. I think all of my own 90s era code was on floppy disks that may or
may not still be readable.

------
panpanna
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.

~~~
_wmd
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](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!)

~~~
nickpsecurity
Although no downvote, there continued to be plenty of research and dollars in
grid computing that did stuff like that on top of "distributed, shared memory"
that did stuff like that. Then, all the research in HPC clusters that tried to
create a "Single, System Image" running stuff across machines like it was one
machine. The MOSIX quote doesn't change the fact that various researchers kept
attempting this and making prototypes.

~~~
_wmd
I think the keyword here is transparency -- later designs (even stuff like
MPI) explicitly expose the topology of the available hardware. SMP is the
closest thing we've ever got to true transparency, and then only for 80% of
cases, and for those only because the compute nodes have very similar locality
and e.g. memory bandwidth

Even SMP requires careful control if you want to get anything close to the
actual performance of the underlying hardware, and the topology is once again
very explicit

~~~
gnufx
You better specify what "SMP" means. By definition, Symmetric Multi-Processing
doesn't have locality concerns, but that's basically dead, and Shared Memory
Programming does, indeed, typically require attention to topology and thread
binding -- frequently ignored, of course. I don't know the MPI standard well,
but I didn't think there was anything requiring topology to be exposed, and it
won't be in the absence of something like netloc, which is still experimental.

------
m_sahaf
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.

~~~
0815test
> 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.

~~~
yjftsjthsd-h
CRIU should allow you to migrate a running process from one system to another,
particularly in combination with a container (Docker or LXC/D).

~~~
michaelmrose
Doesn't this work on about nothing in practice? Like nothing that has an open
file, no gui apps etc.

~~~
yjftsjthsd-h
Here is a writeup of using CRIU on openvpn:
[https://www.redhat.com/en/blog/using-criu-upgrade-vpn-
server...](https://www.redhat.com/en/blog/using-criu-upgrade-vpn-servers-
kernel-without-dropping-connections)

So it seems to work. But I'm no expert and I've never done it, so I might well
be missing something.

------
luismedel
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...

[0]
[https://bitbucket.org/luismedel/sixthcircle/src/default/](https://bitbucket.org/luismedel/sixthcircle/src/default/)

------
dang
2015:
[https://news.ycombinator.com/item?id=9876217](https://news.ycombinator.com/item?id=9876217)

2014:
[https://news.ycombinator.com/item?id=8801372](https://news.ycombinator.com/item?id=8801372)

2011:
[https://news.ycombinator.com/item?id=3007069](https://news.ycombinator.com/item?id=3007069)

~~~
MisterTea
And we won't stop posting until Glenda and her labs bread hoard have crushed
all others!

~~~
dang
There's nothing wrong with posting an interesting story after a year or two.
Especially when the topic is as interesting as this one! The current thread is
the best so far.

------
ACE_Recliner
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).

~~~
henesy
Source:
[http://code.9front.org/hg/purgatorio/](http://code.9front.org/hg/purgatorio/)

Purgatorio 64-bit is a ways away, but is a goal.

It'll happen eventually, but the more eyes the better.

------
fghtr
_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_

This looks similar to Qubes Air roadmap: [https://www.qubes-
os.org/news/2018/01/22/qubes-air/](https://www.qubes-
os.org/news/2018/01/22/qubes-air/)

~~~
rhabarba
Except that you cannot run a Qubes CPU server without a giant overhead.

~~~
fghtr
As a happy Qubes user, the overhead in CPU is barely noticeable for Xen
virtualization. One needs a lot of RAM though.

------
henesy
Nice to see Inferno posted!

Some Inferno related stuff:

\- Limbo by Example:
[https://github.com/henesy/limbobyexample](https://github.com/henesy/limbobyexample)

\- The Inferno Shell: [http://debu.gs/entries/inferno-
part-1-shell](http://debu.gs/entries/inferno-part-1-shell)

\- Try Inferno in the browser:
[http://tryinferno.rekka.io/](http://tryinferno.rekka.io/)

\- Cat-v Inferno resources:
[http://doc.cat-v.org/inferno](http://doc.cat-v.org/inferno)

\- Experiments in Inferno/Limbo: [https://github.com/caerwynj/inferno-
lab/](https://github.com/caerwynj/inferno-lab/)

\- Inferno Programming with Limbo:
[https://web.archive.org/web/20160304092801/http://www.gemuse...](https://web.archive.org/web/20160304092801/http://www.gemusehaken.org/ipwl/)
(also on cat-v)

\- Developing Limbo modules in C:
[https://powerman.name/doc/Inferno/c_module_en](https://powerman.name/doc/Inferno/c_module_en)

\- Simple FS example in Limbo: [https://github.com/henesy/simplefs-
limbo](https://github.com/henesy/simplefs-limbo)

\- Inferno client for Redis:
[https://github.com/pete/iredis](https://github.com/pete/iredis)

\- Inferno for Nintendo DS: [https://bitbucket.org/mjl/inferno-
ds/src/default/](https://bitbucket.org/mjl/inferno-ds/src/default/)

\- Inferno as an Android app: [https://github.com/bhgv/Inferno-
OS_Android](https://github.com/bhgv/Inferno-OS_Android)

\- Inferno replacing Android (hellaphone):
[https://bitbucket.org/floren/inferno/wiki/Home](https://bitbucket.org/floren/inferno/wiki/Home)

\- Porting Inferno to Raspberry Pi: [https://github.com/yshurik/inferno-
rpi](https://github.com/yshurik/inferno-rpi)

~~~
henesy
It's a really early draft, but here's the base for an awesome-inferno
repository: [https://github.com/henesy/awesome-
inferno](https://github.com/henesy/awesome-inferno)

------
sprash
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?

~~~
soraminazuki
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.

~~~
tinus_hn
People always defend Java as if these penalties don’t exist somehow.

~~~
sprash
The question was more about how the big the penalty is compared to running a
MMU.

Also according to my (admittedly rather basic) tests the DIS VM performs far
better than JVM.

------
based2
[http://doc.cat-v.org/inferno/historical_documents/website/in...](http://doc.cat-v.org/inferno/historical_documents/website/infernojava)

------
yingw787
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.

~~~
henesy
This exists and to a pleasant effect!

[http://doc.cat-v.org/inferno/4th_edition/styx-on-a-
brick/](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/](https://www.ev3dev.org/)

------
bangonkeyboard
This project had my favorite naming theme in all of computing.

~~~
nurettin
Does it have the seven shells and a lake of boiling blood instead of the
kernel?

~~~
0_gravitas
With full compatibility with the latest version of your Seas of Ire

------
mortdeus
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.

------
hestefisk
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?

------
rhabarba
I actually tried the Android port once. It was... interesting.

