In the 90s our sector started to look (again) at VMs as viable alternatives for software platforms. The most prominent example of that is Java. But Inferno was born at the same time at the other side of the Atlantic Ocean[0], sharing the same goals: an universal platform intended for set-top boxes, appliances and the like, with the same write once, run everywhere philosophy.
Inferno programs ran on top of a VM called Dis and programs were written in Limbo (designed by Rob Pike). If you use Go nowadays, you're using a descendant of Limbo, as both share a lot of syntax and concepts (and Limbo descended from Aleph, by Rob Pike too, but that's another story)
Going back to 90s. This space was in a very "exploratory" state then, and any technology had to probe it's superiority to gain adoption. For example, Inferno creators implemented Java on Dis[1] simply to demonstrate how fast was Dis vs the JVM.
I don't know exactly why things were the way the went, but I suppose Sun had more deep pockets to push it's technology and Inferno ended as a the rarity we have today.
From a pure tech standpoint, I've studied the Dis VM to write my own (incomplete) interpreter[1] and, IMHO, it's design is far less abstract than the JVM. It seems to be too low level and tied to that era processor design. That make it less future proof (but that's only my own point of view, of course)
God damn it I missed the holy grail era of the computing industry. It’s all so drab compared to the 90s to the early 00s. So much more experimental and willingness to try very new things
From what I remember reading, JVM is a stack machine, while Dis is a register machine, right? Is there any other significant difference that would make Dis less "future proof"?
If you want to explore more OSes that look like this, [Fuschia](https://fuchsia.dev/) is a good one to look at. Rather than having a file be the core primitive, it has an "actor" as the core primitive. And processes send messages to these actors to do anything.
Interestingly, Plan9 started moving in this direction in their later papers. They'd walk through all the many different file operations you'd need to get something accomplished, and then say "but we made a library which does all these things, so you don't need to do it yourself," which kinda defeats the purpose of having everything be a file--and brings you toward the Fuchsia approach.
I'm disappointed to see that the binaries for the Raspberry Pi aren't available anymore at the bitbucket linked on https://github.com/yshurik/inferno-rpi.
I've run Plan9 in the paste on Raspberry Pi and found it to be a neat experience. Inferno I've only run under Windows, and which seemed kind of pointless.
> The Inferno Business Unit closed after three years, and was sold to Vita Nuova Holdings. Vita Nuova continued development and offered commercial licenses to the complete system, and free downloads and licenses (not GPL compatible) for all of the system except the kernel and VM. They ported the software to new hardware and focused on distributed applications. Eventually, Vita Nuova released the 4th edition under more common free software licenses, and in 2021 they relicensed all editions under mainly the MIT License. [1]
Was looking for the framebuffer file: if everything is a file then the framebuffer must be a file (as Plan 9 [1] intended), changing the pixel (123, 324) to some color should be a simple file update, found this funny line [2]:
I wonder why this pattern of managing distributed system at OS level is not widely adopted? and we end up with various customized systems handling distributed system issues at application level.
… legacy applications and dominance of the win32 and posix APIs.
It’s proven easier to implement many of the features of Plan9 lineage and Erlang via containers and orchestrators, rather than porting software and reteaching developers.
The plan9 ecosystem is amazing. It's a pity we work with much older abstractions - although they still didn't consider security to be an issue and I can't comprehend how we'd jerry rig it to work without trusting anything.
I helped build a large message switch using something called QnX, which supported some very basic security mechanisms but it definitely wasn't bullet proof by any definition. The way we dealt with that was by treating the whole cluster much the same way that you would treat a single instance. If you had user access to any node it was assumed you had super user access to the whole cluster and all other security was handled at the physical and the application layers. Given that all of this was written in classic 'C' I don't doubt that there were many ways to exploit that system. But the niche application and the very limited way in which it was connected to the internet (it was mostly a replacement for a very large number of telexes) helped us to get away with it.
> Inferno represents services and resources in a file-like name hierarchy. Programs access them using only the file operations open, read/write, and close. `Files' are not just stored data, but represent devices, network and protocol interfaces, dynamic data sources, and services.
Great. But `open()` needs to be hyper-extensible. Think of URI q-params and HTTP request headers as `open()` options. Think of all the `ioctl()` APIs that have arisen because "files" are a relatively poor way to represent devices. But most importantly `open()` needs to be async.
I'd be very interested in an OS where all system calls that can block are async, and where something like io_uring is the only way to make system calls.
The "everything is a file" thing is fine, but we need more innovation around that if that metaphor is going to stick.
It is - until you want to do something interesting, then it's all ioctl(), recv(), and the various gather calls!
I'd like to see an OS that drops the concept of files. Files are very low level (generally a stream of bytes) - the app has to interpret it as config, or data, etc "manually". An OS should be providing higher-level data management, and insisting that is what is used.
(And please not SQL. It's only a little higher level that raw data, and has serious interface problems that permit prompt injection ... the db equivalent of buffer overflows.)
no, in inferno or plan9, if a fileserver exports the part of its filesystem that contains its network interface, you can mount that on your filesystem and use its network interface. instant vpn! (except 9p isn't encrypted, oops)
the plan9 window system also worked this way, so you could access a window on someone else's display if you mounted it locally; this was how you would run a graphical program on a remote server, by mounting your desktop display in its container on the remote server
linux is not like this at all; you have to use separate protocols for graphics, vpning, and filesharing
Linux isn't quite the same way, no. Though over the years, it is true that Linux has incorporated various Plan9 concepts (Plan9 is the progenitor of Inferno, roughly).
In Linux, you often use sockets to communicate over the network, perhaps with sendmsg[1] to send data.
On Inferno (as I understand it), everything is done via the standard filesystem operations of open/read/write/close. And that includes everything on the system - printers, mouse+keyboard, even the entire windowing system.
It isn't. A network interface on linux is a special creature, traditionally named something like eth0, and it doesn't appear in a filesystem. You have to use tools like ip to interact with it.
There was a land-line telephone with a built-in screen that ran Inferno. Unfortunately it's very difficult to find any screenshots of the phone running Inferno; I'm not even sure they really sold them to the public, but a guy got a couple thousand for cheap and resold them as Linux devices:
It feels simple and elegant at first. It is too simple though. GPUs, real time audio, Networking protocols, etc. It requires more than a simple file system API to handle those effectively.
It's interesting as a historical study. Plan 9's a direct successor to Unix, and made by same people
who would invent the Go programming language. The same philosophy behind Go and Unix is woven into Inferno/Plan 9.
Check the “introduction” paper about the family of OS [1], it provides a good introduction to get the how and why.
My two cents is that composing applications at the FS level is more expressive than Files/Sockets/HTTP requests.
Gluing up different of pieces of software becomes easier as most of the time it becomes just a matter of mounting a filesystem and you don’t need to worry about it being provided by a local or remote process.
> “People often ask where the names Plan 9, Inferno, and Vita Nuova originated.
Allegedly, Rob Pike was reading Dante’s Divine Comedy when the Computing Science Research Group at Bell Labs was working on Inferno. Inferno is named after the first book of the Divine Comedy, as are many of its components, including Dis, Styx and Limbo.
The company name Vita Nuova continues the association with Dante: his first work, a book of poetry about his childhood sweetheart Beatrice, was called La Vita Nuova. The literal translation of Vita Nuova is ‘New Life,’ which in the circumstances is surprisingly prophetic.
Plan 9 is named after the famous Ed Wood movie Plan 9 from Outer Space. There are no other connections except that the striking artwork for the products is a retro, 60s SciFi image modeled on the Plan 9 movie poster.’
I used to have Inferno running on a workstation at work, and another one at home. Each was hosted on Linux (though Inferno can run natively on hardware as well).
One can build a tiny grid with encrypted communications to share resources using Inferno operations to glue it all together.
Nowadays 9p, (known as Styx on Inferno), is used in the Linux kernel, as part of WSL, QEMU, and various other places to share resources and files on a network.
It's a really simple protocol. I started working on an implementation in Swift, and should probably finish it someday.
I had a project with this back in the 2001-2003 era or so and at that time the browser could still do the "modern web" such as it was. It should never have failed like Lisp Machines, Smalltalk, Forth environments, Pascal, and the rest. The nice thing is the web is so borked that you could easily replace it and some entity will. My guess is China.
[+] [-] luismedel|2 years ago|reply
In the 90s our sector started to look (again) at VMs as viable alternatives for software platforms. The most prominent example of that is Java. But Inferno was born at the same time at the other side of the Atlantic Ocean[0], sharing the same goals: an universal platform intended for set-top boxes, appliances and the like, with the same write once, run everywhere philosophy.
Inferno programs ran on top of a VM called Dis and programs were written in Limbo (designed by Rob Pike). If you use Go nowadays, you're using a descendant of Limbo, as both share a lot of syntax and concepts (and Limbo descended from Aleph, by Rob Pike too, but that's another story)
Going back to 90s. This space was in a very "exploratory" state then, and any technology had to probe it's superiority to gain adoption. For example, Inferno creators implemented Java on Dis[1] simply to demonstrate how fast was Dis vs the JVM.
I don't know exactly why things were the way the went, but I suppose Sun had more deep pockets to push it's technology and Inferno ended as a the rarity we have today.
From a pure tech standpoint, I've studied the Dis VM to write my own (incomplete) interpreter[1] and, IMHO, it's design is far less abstract than the JVM. It seems to be too low level and tied to that era processor design. That make it less future proof (but that's only my own point of view, of course)
[0] https://www.vitanuova.com/inferno/ [1] http://doc.cat-v.org/inferno/java_on_dis/ [2] https://github.com/luismedel/sixthcircle
[+] [-] Nokinside|2 years ago|reply
1. Java,
2. Inferno,
3. Oberon System (Niklaus Wirth, ETH Zurich),
4. Squeak (Apple, Walt Disney Imagineering)
5. Erlang (Ericsson, Joe Armstrong) still going strong.
IMHO, Technologically Java was the worst and least innovative. Platform adaption is "Worse is Better" so Java won.
Oberon, Erlang and Squeak were are all amazing in their own way.
[+] [-] pjmlp|2 years ago|reply
Now we are back at it with WebAssembly, as if it was something new.
[+] [-] no_wizard|2 years ago|reply
[+] [-] bheadmaster|2 years ago|reply
From what I remember reading, JVM is a stack machine, while Dis is a register machine, right? Is there any other significant difference that would make Dis less "future proof"?
[+] [-] 437423744|2 years ago|reply
Interestingly, Plan9 started moving in this direction in their later papers. They'd walk through all the many different file operations you'd need to get something accomplished, and then say "but we made a library which does all these things, so you don't need to do it yourself," which kinda defeats the purpose of having everything be a file--and brings you toward the Fuchsia approach.
[+] [-] haolez|2 years ago|reply
[+] [-] hulitu|2 years ago|reply
[+] [-] mpweiher|2 years ago|reply
Can you point out which ones? I thought I was pretty familiar with the Plan 9 papers but don't remember that part. Or maybe I just missed it?
[+] [-] 7373737373|2 years ago|reply
[+] [-] johndoe0815|2 years ago|reply
Lynxline's Inferno Labs on porting Inferno to the Raspberry Pi:
https://github.com/yshurik/inferno-rpi (the related web site http://lynxline.com/ is currently not reachable)
David Boddie's port of Inferno to the Ben NanoNote, a tiny MIPS-based handheld from 2010:
https://www.boddie.org.uk/david/www-repo/Personal/Updates/20...
https://en.wikipedia.org/wiki/Ben_NanoNote
[+] [-] michrassena|2 years ago|reply
I've run Plan9 in the paste on Raspberry Pi and found it to be a neat experience. Inferno I've only run under Windows, and which seemed kind of pointless.
[+] [-] 0xpgm|2 years ago|reply
https://web.archive.org/web/20141216095808/http://lynxline.c...
[+] [-] Fnoord|2 years ago|reply
> The Inferno Business Unit closed after three years, and was sold to Vita Nuova Holdings. Vita Nuova continued development and offered commercial licenses to the complete system, and free downloads and licenses (not GPL compatible) for all of the system except the kernel and VM. They ported the software to new hardware and focused on distributed applications. Eventually, Vita Nuova released the 4th edition under more common free software licenses, and in 2021 they relicensed all editions under mainly the MIT License. [1]
[1] https://en.wikipedia.org/wiki/Inferno_(operating_system)
[+] [-] ly3xqhl8g9|2 years ago|reply
[2] https://github.com/inferno-os/inferno-os/blob/48f27553574bf5...
[+] [-] nvbkdw|2 years ago|reply
[+] [-] anonymousDan|2 years ago|reply
[+] [-] numbsafari|2 years ago|reply
It’s proven easier to implement many of the features of Plan9 lineage and Erlang via containers and orchestrators, rather than porting software and reteaching developers.
[+] [-] ericls|2 years ago|reply
It's interesting to me how channels in Limbo look and work very similar to Go's channels.
[+] [-] octotoad|2 years ago|reply
[+] [-] AnnaPali|2 years ago|reply
[+] [-] jacquesm|2 years ago|reply
[+] [-] cryptonector|2 years ago|reply
Great. But `open()` needs to be hyper-extensible. Think of URI q-params and HTTP request headers as `open()` options. Think of all the `ioctl()` APIs that have arisen because "files" are a relatively poor way to represent devices. But most importantly `open()` needs to be async.
I'd be very interested in an OS where all system calls that can block are async, and where something like io_uring is the only way to make system calls.
The "everything is a file" thing is fine, but we need more innovation around that if that metaphor is going to stick.
[+] [-] pjmlp|2 years ago|reply
Welcome to WinRT application model as it was introduced in Windows 8.
Sadly it was yet another reason why the Windows development community rebelled against it.
[+] [-] blacksoil|2 years ago|reply
[+] [-] drpixie|2 years ago|reply
I'd like to see an OS that drops the concept of files. Files are very low level (generally a stream of bytes) - the app has to interpret it as config, or data, etc "manually". An OS should be providing higher-level data management, and insisting that is what is used.
(And please not SQL. It's only a little higher level that raw data, and has serious interface problems that permit prompt injection ... the db equivalent of buffer overflows.)
[+] [-] kragen|2 years ago|reply
the plan9 window system also worked this way, so you could access a window on someone else's display if you mounted it locally; this was how you would run a graphical program on a remote server, by mounting your desktop display in its container on the remote server
linux is not like this at all; you have to use separate protocols for graphics, vpning, and filesharing
[+] [-] interroboink|2 years ago|reply
In Linux, you often use sockets to communicate over the network, perhaps with sendmsg[1] to send data.
On Inferno (as I understand it), everything is done via the standard filesystem operations of open/read/write/close. And that includes everything on the system - printers, mouse+keyboard, even the entire windowing system.
[1] https://linux.die.net/man/2/sendmsg
[+] [-] unixhero|2 years ago|reply
[+] [-] stonogo|2 years ago|reply
[+] [-] pedrow|2 years ago|reply
[+] [-] floren|2 years ago|reply
https://web.archive.org/web/20070311234222/http://tuxscreen....
[+] [-] foverzar|2 years ago|reply
That didn't really age to well for Unix. I wonder if it is different for a distributed os.
[+] [-] qznc|2 years ago|reply
[+] [-] rubatuga|2 years ago|reply
[+] [-] KRAKRISMOTT|2 years ago|reply
[+] [-] uhura|2 years ago|reply
My two cents is that composing applications at the FS level is more expressive than Files/Sockets/HTTP requests.
Gluing up different of pieces of software becomes easier as most of the time it becomes just a matter of mounting a filesystem and you don’t need to worry about it being provided by a local or remote process.
[1] - http://doc.cat-v.org/plan_9/4th_edition/papers/9
[+] [-] drpixie|2 years ago|reply
[+] [-] kjellsbells|2 years ago|reply
[+] [-] tough|2 years ago|reply
> “People often ask where the names Plan 9, Inferno, and Vita Nuova originated. Allegedly, Rob Pike was reading Dante’s Divine Comedy when the Computing Science Research Group at Bell Labs was working on Inferno. Inferno is named after the first book of the Divine Comedy, as are many of its components, including Dis, Styx and Limbo. The company name Vita Nuova continues the association with Dante: his first work, a book of poetry about his childhood sweetheart Beatrice, was called La Vita Nuova. The literal translation of Vita Nuova is ‘New Life,’ which in the circumstances is surprisingly prophetic. Plan 9 is named after the famous Ed Wood movie Plan 9 from Outer Space. There are no other connections except that the striking artwork for the products is a retro, 60s SciFi image modeled on the Plan 9 movie poster.’
https://dantetoday.krieger.jhu.edu/2009/03/08/vita-nuova-and...
[+] [-] sillywalk|2 years ago|reply
[+] [-] rnd0|2 years ago|reply
[+] [-] butterisgood|2 years ago|reply
One can build a tiny grid with encrypted communications to share resources using Inferno operations to glue it all together.
Nowadays 9p, (known as Styx on Inferno), is used in the Linux kernel, as part of WSL, QEMU, and various other places to share resources and files on a network.
It's a really simple protocol. I started working on an implementation in Swift, and should probably finish it someday.
[+] [-] jacquesm|2 years ago|reply
[+] [-] 64operator|2 years ago|reply
[+] [-] vrglvrglvrgl|2 years ago|reply
[deleted]