Inferno OS(c2.com)
c2.com
Inferno OS
http://c2.com/cgi/wiki?InfernoOs
48 comments
I use this a lot. My text editor (octopus) runs in it. Inferno is pretty interesting and very easy to code on, however the programming model takes getting used to.
I never did get the chance to use Octopus for any length of time, it always looked a bit over complicated. I guess it didn't help that the talks I saw on it were Spanish people taking in English. Not all of the subtlety came across.
But I think it was Francisco that came up with "It's not Universal, it's not Serial and it's not a Bus", I always liked that one.
But I think it was Francisco that came up with "It's not Universal, it's not Serial and it's not a Bus", I always liked that one.
Which editor do you use?
Octopus. It's an lsub research thing.
There is, at some level, a Java VM that is functional with Inferno OS. No idea at what capacity it can be made to function, but I've been meaning to mess with it for awhile now. https://code.google.com/p/inferno-j2d/
This was revived for a GSOC project a few years ago but the google link here doesn't seem to have the resulting work. Anyone have more up to date details?
I believe that this is the up to date repository...it was GSOC for '13 and the last commit time seems to match. The repo states that the repository was cleaned and files removed to comply with Oracle/Sun, but there is an index that lists all required files from JDK7.
This was the operating system used in my intro to operating systems course in undergrad.. My professor was an expert, it was very interesting.
Is the the book you used?http://www.amazon.com/Principles-Operating-Systems-Applicati...
Did your professor write the book used in the class? If so, we may have had class together.
Does it have a public webpage ?
If history had gone differently, we could have had this instead of Java. Inferno was a futuristic jet to Java's stone-age wheel, but it was not to be.
A perfect example that superior design and implementation doesn't win out. Other factors are more significant.
A perfect example that superior design and implementation doesn't win out. Other factors are more significant.
You're comparing an operating system to a language specification. Not sure I see what you're getting at here.
The beauty of Inferno is that one of the incarnations happens to be an operating system that runs on bare metal. But the very same code can be run as a command line program in Windows / OpenBSD / OSX / Linux. Or as a multi-windowed program like an MDI or a single window, or a full screen window in kiosk mode, or as a network service on IBM's Blue Gene.
Inferno is used by IBM, NASA, Alcatel-Lucent, the US DoD.
Inferno is used by IBM, NASA, Alcatel-Lucent, the US DoD.
Wasn't there a JavaOS as well at some stage? Or at least planned?
Sun even made Java cpu's / appliances
These days there's http://www.azulsystems.com/products/vega/overview
Bruce Ellis (one of the people who created Mark V Shaney) and one of the original Inferno developers until it was sold, has been working on a Verilog cpu to execute DIS natively but still no prototype.
One of the beauties of Inferno is it will run on a platform with no hardware MMU.
And the Styx protocol means it can do great things easily. It has even had servers running on Logo Mindstorm.
These days there's http://www.azulsystems.com/products/vega/overview
Bruce Ellis (one of the people who created Mark V Shaney) and one of the original Inferno developers until it was sold, has been working on a Verilog cpu to execute DIS natively but still no prototype.
One of the beauties of Inferno is it will run on a platform with no hardware MMU.
And the Styx protocol means it can do great things easily. It has even had servers running on Logo Mindstorm.
> Inferno is used by IBM, NASA, Alcatel-Lucent, the US DoD.
Where?
Where?
From the site:
"There's a good comparison to be made with java, as they had similar design goals:
"There's a good comparison to be made with java, as they had similar design goals:
good performance (within an order of magnitude of C)
cross platform / virtual machine based (WriteOnceRunAnywhere, except actually delivered this time)
safe execution of untrusted code
powerful network / browser focus
register based byte-code (as opposed to stack based), maps well to existing processors, JIT compilation works much better
supported as a native operating system (i.e., it'll easily run on bare hardware, for many values of hardware)"The choice of register vs stack for bytecode doesn't make any difference for a modern JIT like HotSpot. The bytecode gets transformed into an intermediate representation (IR) and optimized before being translated to machine code. A register based bytecode like Dalvik that has 65,535 registers certainly does not map directly to hardware.
Edit: Michael Franz's research would seem to disagree, and I believe Mike Pall (of LuaJIT) would also disagree.
As I remember, the Dis bytecode used 64-bit instructions, with a 16 bit opcode, a 16-bit address and a 32-bit address. I've heard it described as a memory machine, and also as a machine with 65,536 registers.
In any case, it's easier and more efficient to perform register allocation from an intermediate language with a huge number of registers down to a small number of physical registers than it is to assign slot locations to registers. See Michael Franz's SafeTSA [1] project for an example of modifying a JVM to be able to mix and match both Java bytecode and an SSA-based bytecode in the same process. Granted SSA has some additional properties besides an infinite register set that make code generation nice. However, they found that it took less time to generate native code from SafeTSA and that the generated native code ran faster, even though the JIT backend was identical for the two bytecode formats. The disadvantage of SSA and memory machine bytecodes is they are more complicated to efficiently interpret if you're not generating native code from them.
[1] http://en.wikipedia.org/wiki/SafeTSA
As I remember, the Dis bytecode used 64-bit instructions, with a 16 bit opcode, a 16-bit address and a 32-bit address. I've heard it described as a memory machine, and also as a machine with 65,536 registers.
In any case, it's easier and more efficient to perform register allocation from an intermediate language with a huge number of registers down to a small number of physical registers than it is to assign slot locations to registers. See Michael Franz's SafeTSA [1] project for an example of modifying a JVM to be able to mix and match both Java bytecode and an SSA-based bytecode in the same process. Granted SSA has some additional properties besides an infinite register set that make code generation nice. However, they found that it took less time to generate native code from SafeTSA and that the generated native code ran faster, even though the JIT backend was identical for the two bytecode formats. The disadvantage of SSA and memory machine bytecodes is they are more complicated to efficiently interpret if you're not generating native code from them.
[1] http://en.wikipedia.org/wiki/SafeTSA
In any case, Java's stack-based bytecode is really a register machine in disguise. It isn't a general stack machine -- for instance, at a given "PC" the shape of the expression stack (i.e. the number and "basic" types of elements in it) needs to be constant.
The right way to look at Java's bytecode stream is opcodes for a register machine with _implicit_ input and output registers. Mapping it to a compiler IR would not be easy in the general case if that weren't true.
The right way to look at Java's bytecode stream is opcodes for a register machine with _implicit_ input and output registers. Mapping it to a compiler IR would not be easy in the general case if that weren't true.
That's a disingenuous - of course it makes a difference. Trying to infer an efficient allocation of registers from a chain of stack instructions involves a ton of tricks that bloat the compiler and make loading the bytecode slow and processor intensive. That's the problem Dalvik was designed to solve, and why Dalvik's successor ART is a regular compiler and not a JIT.
By mentioning "Java," the poster probably was referring to the JVM. As jwz says, "Java" refers to numerous things:
there are four completely different things that go by the name ``Java'':
A language;
An enormous class library;
A virtual machine;
A security model.
http://www.jwz.org/doc/java.html
there are four completely different things that go by the name ``Java'':
A language;
An enormous class library;
A virtual machine;
A security model.
http://www.jwz.org/doc/java.html
I think names are important, but I don't tend to comment on them. It's more like something good you can add if you find a good one.
But Inferno literally means Hell. (or "a large fire that is dangerously out of control.")
I think it's a bit off-putting, like "OS from Hell."
But Inferno literally means Hell. (or "a large fire that is dangerously out of control.")
I think it's a bit off-putting, like "OS from Hell."
The name is in accord with the "Bell Labs tradition of selecting names that make marketeers wince." [1]
[1] http://www.plan9.bell-labs.com/wiki/plan9/lfaq/#GENERAL_INFO...
[1] http://www.plan9.bell-labs.com/wiki/plan9/lfaq/#GENERAL_INFO...
The entire concept was based off of Dante's Divine Comedy. Limbo (programming language), Styx (communications protocol), Dis (the virtual machine).. I'm pretty sure there were more.
Is Limbo the only language you can use to create programs for Inferno, or are there any others?
If by that you mean "languages that target the dis VM", yes. There was a Scheme interpreter written in Limbo, but that's about it.
I think that's the biggest hurdle regarding Inferno - I'd like to see other languages running atop dis.
I think that's the biggest hurdle regarding Inferno - I'd like to see other languages running atop dis.
A Scheme interpreter! Wonderful. That counts. More than that, Scheme is the langage I prefer to program in, so it's perfect.
Looks like this[1] is probably the one you mean.
Awesome.
[1] - https://code.google.com/p/inferno-scheme/
Looks like this[1] is probably the one you mean.
Awesome.
[1] - https://code.google.com/p/inferno-scheme/
Beware, it is quite slow and limited.
You can create plan9 C programs outside of Inferno to run inside it.
Any pointers on how this works SixSimga?
There is always the source code
https://code.google.com/p/inferno-os/
But like most Unix like programs, stdin / stdout.
Better still, provide a Styx service (p9 by another name) and then mount your service as a file system. If you do this then one can also mount it in plan9 or Linux
https://code.google.com/p/inferno-os/
But like most Unix like programs, stdin / stdout.
Better still, provide a Styx service (p9 by another name) and then mount your service as a file system. If you do this then one can also mount it in plan9 or Linux
what could be the use case now for learning Limbo/Inferno?
it says "distributed" but i couldnt see what it offers for distributed as in multi rack or even multi dc distributed. distributed as in distributed automatically to threads?
Distributed as in network-transparent. Inferno inherited Plan9's ability to deal with resources independently of location.
Here's an example of distributing machine resources across different networks and devices [1] using inferno. An example of distributing computation is at [2].
[1] http://bluishcoder.co.nz/2012/11/07/sharing-computer-and-pho... [2] http://debu.gs/entries/inferno-part-2-let-s-make-a-cluster
[1] http://bluishcoder.co.nz/2012/11/07/sharing-computer-and-pho... [2] http://debu.gs/entries/inferno-part-2-let-s-make-a-cluster
Incidentally, that first link has a nice set of instructions on how to get, compile, and use Inferno. Thanks!
Mechiel Lukkien has a bunch of interesting Limbo programs and libraries that work on Inferno [1]. Also of interest might be running Inferno on Android phones [2].
[1] https://bitbucket.org/mjl [2] http://bluishcoder.co.nz/2012/06/11/building-inferno-os-for-...
[1] https://bitbucket.org/mjl [2] http://bluishcoder.co.nz/2012/06/11/building-inferno-os-for-...
ah, nice to see that code linked! quite a few of those repo's aren't very interesting, some are:
- httpd (have been using it as my webserver for many years) - qwm (window manager, inspired by acme and a bit of dwm, but a bit buggy) - vixen (vi clone in limbo (i can't use acme for days on end)) - wmrun, together with qwm and vixen was an attempt at get more of an acme-like workflow - ssh & novt, ssh client and terminal
i attempted to write enough software for me to use it daily. sadly i ran out of time & energy.
inferno is such an amazing system. very clean code. limbo is a joy to program in. it deserves more attention than it gets...
- httpd (have been using it as my webserver for many years) - qwm (window manager, inspired by acme and a bit of dwm, but a bit buggy) - vixen (vi clone in limbo (i can't use acme for days on end)) - wmrun, together with qwm and vixen was an attempt at get more of an acme-like workflow - ssh & novt, ssh client and terminal
i attempted to write enough software for me to use it daily. sadly i ran out of time & energy.
inferno is such an amazing system. very clean code. limbo is a joy to program in. it deserves more attention than it gets...
Thanks for making all your code available! I've used ircfs and httpd amongst others and it's also been a great reference of Limbo to look at.
I go through phases of doing as much as possible inside Inferno and it would be much more difficult without your contributions.
I go through phases of doing as much as possible inside Inferno and it would be much more difficult without your contributions.
Thanks for all the cool stuff mjl! You've given us some really nice code on top of a really nice system.
Hey mjl, maht here. It's plan9 time again on HN.
I'm wondering if (Inferno OS) and (TempleOS) would do a dual boot together on a PC? :)