9 ms·
Inferno-OS: distributed operating system where everything is a file
- foverzar 4y ago> where everything is a file. That didn't really age to well for Unix. I wonder if it is different for a distributed os.
- qznc 4y agoIt 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.
- jacquesm 4y agoI can't agree with you. I've done a lot of real time stuff and networking stuff as well as graphical user interfaces on a system that was based on the file metaphor and if anything it made things far easier. If only because you don't have to think about it, there is only the one way to do it. Similar to how HTTP is just a transport protocol, it's what you transport and how that is interpreted that matters. By restricting the number and kind of endpoints that you allow a driver or virtual device to have you ensure that all tooling is instantly composable, which is a much bigger advantage than the ones that you get from 'more effective APIs', which always turn into a giant salad of RPC. Think protocols, not functions and you're well under way to seeing why there is a lot of power to be found there that we've thrown out in the name of a couple of percent of efficiency.
- anthk 4y agoplan9/9front does that just fine.
- johndoe0815 4y agoSome additional recommended reading... Lynxline's Inferno Labs on porting Inferno to the Raspberry Pi: https://github.com/yshurik/inferno-rpi https://github.com/yshurik/inferno-rpi (the related web site http://lynxline.com/ 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/2022/2022-01-06.html https://www.boddie.org.uk/david/www-repo/Personal/Updates/20... https://en.wikipedia.org/wiki/Ben_NanoNote https://en.wikipedia.org/wiki/Ben_NanoNote
- michrassena 4y agoI'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 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.
- johndoe0815 4y agoThe zip file available in the github releases of the project contains the final binary release (0.6): https://github.com/yshurik/inferno-rpi/releases/tag/v0.6 https://github.com/yshurik/inferno-rpi/releases/tag/v0.6 Note that this Inferno port only works on the original Raspberry Pi 1 (probably also the 1B and the Pi Zero).
- 0xpgm 4y agoThe lab pages are archived from here: https://web.archive.org/web/20141216095808/http://lynxline.com/lab-1-compiler/ https://web.archive.org/web/20141216095808/http://lynxline.c...
- blacksoil 4y agoThe Readme says that things such as network interface is abstracted as files, but isn't Linux the same way?
- interroboink 4y agoLinux 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. [1] https://linux.die.net/man/2/sendmsg https://linux.die.net/man/2/sendmsg
- drpixie 4y agoIt 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.)
- MobiusHorizons 4y agoThe purpose of a good primitive is that it can be cleanly composed. Both files and streams of bytes have these properties, because the primitive allows code written by different people / teams / orgs to interact due to the common primitives. The higher level your primitives, the larger your api surface, and the less likely they are to be composable. Do you really want that? I certainly don’t.
- Technotroll 4y ago> An OS should be providing higher-level data management, and insisting that is what is used. This assertion seems normative. Could you please expand upon how higher-level data management improve the overall performance and efficiency of the system? Or could you point me in the direction of some good sources? Also what are the benefits of an OS providing higher-level data management instead of relying on lower-level data management solutions? Doesn't abstraction lead to less fine control? That is to say, how does insisting on using higher-level data management provided by an OS affect the development and maintenance of applications? I've seen some object-centric systems adopt this approach and find it very interesting.
- rubatuga 4y agoCan someone explain how this could benefit system design or from the viewpoint of a programmer?
- drpixie 4y agoIn general, simple interface is easy for the programmer to understand, and provides less opportunity for system bugs and strange interactions.
- KRAKRISMOTT 4y agoIt'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.
- emmelaich 4y agoYou can see echoes of Plan9/Inferno in e.g. the go-lang Dial() call. Plan9 / Inferno were also design descendants of System V Streams. https://en.wikipedia.org/wiki/STREAMS https://en.wikipedia.org/wiki/STREAMS
- uhura 4y agoCheck 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. [1] - http://doc.cat-v.org/plan_9/4th_edition/papers/9 http://doc.cat-v.org/plan_9/4th_edition/papers/9
- 437423744 4y agoIf you want to explore more OSes that look like this, [Fuschia](https://fuchsia.dev/ 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.
- haolez 4y agoWhat can you do with Fuschia today? I'd imagine that it's not usable as a mobile OS or a desktop OS.
- xyproto 4y agoYou can type a command and if the application is missing it will install it on the fly and the command will just work. I wish Linux distros had this feature as well.
- rwmj 4y agoThey do. I disable it always because it is annoying if you typo a command.
- bee_rider 4y agoI imagine sl would be even more annoying if you had to download it.
- xyproto 4y agoIf the download and installation is fast enough, it feels smooth, and not annoying. If a distro were to appear with this feature enabled by default, I hope they would have the foresight to not include "sl", or at least put it in the default blacklist.
- nvbkdw 4y agoI 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.
- numbsafari 4y ago… 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.
- anonymousDan 4y agoHard to say, here is an interesting take on it from a few years back: https://cs.brown.edu/people/malte/pub/papers/2013-apsys-dios.pdf https://cs.brown.edu/people/malte/pub/papers/2013-apsys-dios...
- 64operator 4y agoI 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.
- ericls 4y agoI was curious to see what the language used in this project, Limbo, looks like. And here it is: https://www.vitanuova.com/inferno/limbo.html https://www.vitanuova.com/inferno/limbo.html It's interesting to me how channels in Limbo look and work very similar to Go's channels.
- octotoad 4y agoMakes sense, given Rob Pike was one of Limbo's creators.
- luismedel 4y agoSome context from top of my head. 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/ https://www.vitanuova.com/inferno/ [1] http://doc.cat-v.org/inferno/java_on_dis/ http://doc.cat-v.org/inferno/java_on_dis/ [2] https://github.com/luismedel/sixthcircle https://github.com/luismedel/sixthcircle
- bheadmaster 4y agoNice piece of history. 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"?
- jimsimmons 4y agoWhy is stack more future proof
- rollcat 4y agoIt isn't, unless you consider SPARC the future. SPARC had an interesting register architecture, where making a function call would renumber registers 9-16 to 1-8, and give the function a fresh set of 9-16; IIRC most SPARC CPUs had 128 or so registers total, with this "sliding window" that went up and down as you called and returned, which essentially gave you something like a stack. The rest of the world's CPUs have normal registers, which is one aspect of what makes register-based VM bytecode easier to JIT to the target architecture, which was one of Dis' original design goals (with an interpreter being a fallback). It also happens that we know a lot more about actually optimising register-based instructions (rather than stack-based), so even if you had to fall back on an interpreter, the bytecode could've gone thru an actual proper optimisation pass.
- rnd0 4y agoWhat's the use case for this, exactly?
- jacquesm 4y agoSoft real time, clusters. A bit like the same space that you would aim Erlang/Elixir at.
- butterisgood 4y agoI 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.
- AnnaPali 4y agoThe 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.
- jacquesm 4y agoI 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.
- vrglvrglvrgl 4y ago[dead]
- Fnoord 4y agoIt wasn't fully FOSS till 2021: > 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) https://en.wikipedia.org/wiki/Inferno_(operating_system)
- ly3xqhl8g9 4y agoWas 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]: gscreendata.data = (ulong *)(va+0x800000); /* Framebuffer Magic */ [1] https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs [2] https://github.com/inferno-os/inferno-os/blob/48f27553574bf59de5f101ae072f82f5f1993d6f/os/js/screen.c#L226 https://github.com/inferno-os/inferno-os/blob/48f27553574bf5...
- kjellsbells 4y agoThe Dante references are all over this. Inferno. Dis. Vita Nuova. Is there a story here?
- tough 4y agoGood catch > “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-inferno-a-compact-system-for-building-cross-platform-distributed-systems/ https://dantetoday.krieger.jhu.edu/2009/03/08/vita-nuova-and...
- pedrow 4y agoAre there, or have there been, devices where one might have seen Inferno running 'in the wild' e.g. digital signs, PoS terminals etc.?
- floren 4y agoThere 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: https://web.archive.org/web/20070311234222/http://tuxscreen.net/ https://web.archive.org/web/20070311234222/http://tuxscreen....
- cryptonector 4y ago> 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.
- pjmlp 4y ago> I'd be very interested in an OS where all system calls that can block are async, 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.
- sillywalk 4y agoThe Vita Nuova website looks the same as it does 20 years ago. Does anybody know who is paying for them/using Inferno in production?