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

3 of 98 comments (clear)

  1. "New Ideas" in Inferno by nestler · · Score: 5
    Just to inform people that may not know too much about Inferno, I thought I'd post a few unique things about it (and some ideas that the developers wanted to focus on). I've done work for Lucent related to it, so I know a few useful things about it.
    1. Runs on a Virtual Machine

    2. 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.
    3. Written in Limbo

    4. 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.
    5. Namespaces

    6. 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...
    7. Files, Files, Files

    8. 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.
    9. Transparency of Networked Machines (or toasters)

    10. 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.
    11. Styx Protocol

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

  2. Re:New OS's from this company... by rpeppe · · Score: 5
    well i don't think it's still "horridly slow"; i use it a lot of the time and it is slower than C, but not bad at all.

    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!

  3. How useful is this? by Jon+Erikson · · Score: 5

    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