Slashdot Mirror
Inferno Source Release
shawk writes "Vita Nuova today announced that it has obtained the exclusive,
worldwide rights to the Inferno Operating System from Lucent
Technologies' Bell Labs and that it is to publish the Inferno source
code under inexpensive, commercial licence terms. Vita Nuova has also
announced that Lucent Technologies and a UK investor have invested
equity capital into Vita Nuova to develop and market Inferno.
Personal Inferno Subscriptions cost $300 with a 50% discount for
academics and students. Corporate subscriptions cost from $1000 for
five developers. You can order your Inferno boxed set including CD,
programmer's manual and papers today. Full details can be found at the
Vita Nuova."
I was reading through the Inferno docs, and I must say, I'm quite impressed. It looks like a very clean and unified architecture. However, does the cleanliness of the design outweigh the performance disadvantages of this? Sure it may make it easier to port, and the whole "everything is a file!" think may make it a more unified design, but in the end is it worth it? Two things. /var/shm, and means that every access incurs a slight overhead by having to go through the file system.
A) Most operating systems only run one major architecture. Portability is good, but excessive portability at the expense of speed is bad. I think Linux strikes a nice balance in this regard, it uses ugly performance code when it has to, but keeps the whole thing pretty portable. Also, according to the Be developers, "there is no such thing as portable code, only code that has been ported."
B) Everything is not a file! To some extent, it makes sense, but I never understood the whole file concept. Isn't it much simpler to treat everything as a region of memory? So if you are writing a driver, you simply write to regions of memory starting from a base address rather than doing ioctls, which seem to abstract it to much. Also, when stuff like DNS lookups are done through files, isn't it getting a little silly? Isn't it simpler to map closer to the way the software is actually working? Especially in the cases of stuff like DNS lookups which don't totally make sense being treated as a file. Also, doesn't going through the FS create some overhead? In BeOS a region of shared memory (an "area") is simply a region of memory. You get a pointer to it through the create_area() function, and you tell the OS that you're done with it through delete_area(), kind of like malloc() and free(). In kernel 2.4, it is treated as a file mounted at
A deep unwavering belief is a sure sign you're missing something...
I looked at Inferno when it first came out, and it was very impressive in 1996, and it's still impressive today. Javasoft is attempting to target the same market with Jini, and meeting with equally glazed eyes, unfortunately.
But what sent me running away screaming was the programming language you were expected to use. Here was a language that looked like it was a solid step backward from C! And I'm sure everyone from procedural to functional programmers and everything in between can agree that this is an undesirable first impression to make upon someone.
-
Just because it works, doesn't mean it isn't broken.
many of the original developers from the Inferno project are now working for a comany called savaJe tech that is working on a product called jscream, a java kernel and os for information appliances.
Charging $300 a pop will certainly drive developer acceptance. I'm rushing right out to get my copy.
Wait. Linux is *free* you say?!?!? Never mind.
-Vercingetorix
"Necessitas non habet legem." -St. Augustine
Not that I'm complaining--they're entitled to go after any market they like. It's just plain from the price structure that they've no interest in the grassroots individual developer market at all.
It's probably not a bad choice, if they want to keep it for use only with "network devices" rather than PCs. But still, as PalmOS has shown, having grassroots developer support for non-PC computing devices is certainly an asset.
Steve
Inferno only runs directly on one architecture: the Dis virtual machine. This isolates in a very clean way the platform-specific parts that need to be changed to get Inferno to run on various architectures: just rewrite the Dis machine wherever you want Inferno to run.
Most of Inferno was written in a new language called Limbo. It's authors seem to like this language, although I've seen a good bit of criticism of it from others ("the infernal language"). I don't know much at all about Limbo first hand.
This concept is borrowed from Plan 9. The concept is that different processes have different views of the system called namespaces. Each namespace is essentially a hierarchical file system that presents available resources to the process. If a process does not have enough privilege to use something, it won't even see it. What are these resources? This gets into the next point...
This concept is borrowed from Unix but is taken to new extremes. All resources in the namespace are presented as files. The idea is to unify the interfaces to a variety of things by having an open/close/read/write way to use a variety of resources. Unix presented devices this way (/dev). Inferno goes a step further by presenting other machines, network cards, and a variety of other resources as files. For example, DNS lookups and socket programming can be done simply by reading and writing files. This is not so under Unix.
By using this hierarchical filesystem view of everything, Inferno can essentially hide that parts of this file system are remote (like NFS mounts). The hope is that programmers can write programs that read like simple shell scripts (open, read, etc.) to manipulate local and remote data and machines.
Styx is the protocol that is spoken over the network in order to present this filesystem abstraction remotely. Note that these 'files' are not traditional files: they can have arbitrary semantics (they can make things happen on the server when read/written; the possibilities are endless). A Styx server exports some filesystem to a Styx client. Note that the server decides what the semantics are for this filesystem (writing file A causes some configuration to be rewritten, reading file B reads off the current configuration, etc.) The client can mount this filesystem so that it appears in the namespaces of processes on the client machine.
I think Inferno has a lot of potential, even if only for simple management of networks. Today, management of heterogeneous network can be pretty complicated (managing routers with LDAP, SNMP, etc.). If routers implemented Styx servers to expose their configuration options as a filesystem, then some Inferno machine could mount all of the routers in a directory and run a simple script to configure them all. This would be much simpler than what goes on today.
as far as performance goes, there's also the fact that there hasn't yet been a great deal of work done optimizing the compiler output or the JIT (i.e. currently the JIT does little registerisation, where the design of the DIS VM means that registerisation should be relatively easy to do - see this). i have a feeling that it's quite a lot faster than most java versions.
what's it good for? all sorts of things. it's a really clean environment to write programs in. where plan 9 is really clean in the namespace and the system interface, but still uses C as the application programming language, Inferno has all that, but uses Limbo as the language with Dis underneath.
the main advantage it gives you when writing programs is that your programs are unconditionally portable - if i've written a Limbo program to run on a screen phone (bare hardware, ARM SA1100) then, assuming enough memory, i have no doubts about it running perfectly on any other platform on which Inferno is supported.
that, coupled with the fact that limbo is a really, really nice language means that i don't want to develop for anything else. i started off as a C developer about 10 years ago, managed to escape Ingres (eugh) after a couple of years, hacked some Occam (which is a nice language, but somewhat limited in its type system), ended up in Objective-C under NeXTstep/Openstep/(macosX?). so i've hacked in a number of languages, and Limbo wins hands down.
why? it's difficult to say. it's a combination of many factors that all go to make up for a thoroughly enjoyable programming experience. i love C (not C++ though!) and it keeps the "power at your fingertips" feel that you get with C, but without pointers, with garbage collection, with complete type safety... perhaps the main feature is that when you read a Limbo program, you can actually tell what it's doing! (shock horror). all the names that are accessible to a fragment of code are easily findable. there's no overloading. the OO paradigm works entirely around aggregation - no inheritance whatsoever. the inbuilt types work really nicely - value types mean that in a multi-threaded environment, which Inferno/Limbo is, you are utterly certain that a value can't be changed underneath you).
what programs are for it? well, there's a web browser, but if you're running it hosted, then you'll probably have one anyway (that doesn't have to conform to the restriction of needing to run in 4MB). i've written what i think is a fairly cool programmable shell for it which is pretty small as well (main binary for it is 36K). i also wrote a passable version of Tetris (which is great 'cos now i can play the same version against people in the office running windows, linux, plan 9 and screenphones!), and i'm finishing off a pretty nice FIBS client. most of that stuff i did in my spare time. there's a version of Acme that's been ported, so you can see how the original compares to Wily.
how easily can you port programs from *NIX? (shouldn't that be *N[UI]X ? :-]) depends on what sort of program you're talking about. what inferno does *not* have (and this is the reason it's so small) is all the legacy stuff that *NIX has picked up over the years. this it has in common with plan 9. it does not have cursor addressing programs (although i wouldn't mind porting a decent vt100 emulator). it does not have termcap/terminfo/curses/ioctl/fcntl or sockets. so porting anything that relies on that stuff (e.g. emacs, slrn) won't be at all easy. BUT, straight C usually goes very nicely into Limbo. most of the standard unix command line programs (i.e. the ones that just munge stdin to stdout) go fine. The Limbo arithmetic expression syntax uses the same precedence rules as C, so all those nightmare mathematical equations are little problem (unless they've got dodgy type promotion going on, which you want to know about anyway).
the best thing about inferno is that it's a truly component oriented architecture. OO systems with inheritance don't give you that as there's too much interdependence between objects at different levels. Limbo modules under the dis VM really do work as plug & play s/w...
hope this helps!
From this introduction at the web site:
Inferno is intended to be used in a variety of network environments, for example those supporting advanced telephones, hand-held devices, TV set-top boxes attached to cable or satellite systems, and inexpensive Internet computers, but also in conjunction with traditional computing systems.
Have we not seen this before? There certainly seems to be a proliferation of "network" operating systems for non-computer systems at the moment. Whilst I'm not knocking Inferno, I don't really know much about it, it has to be said that this are is fast becoming saturated, and the competition is likely to be fierce.
One thing I found interesting is that Inferno, as well as being a stand-alone OS, can also be run as an application under Windows NT, Windows 95, Unix (Irix, Solaris, FreeBSD, Linux, AIX, HP/UX) and Plan 9. This could give it an edge since it increases the number of places where its applications (written in Limbo?) can be run. So even if it doesn't become hugely popular, it might still survive on other platforms.
---
Jon E. Erikson
Jon Erikson, IT guru