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

Comments

No.

[gnarphlager]

Because the inchfan is so L337 that we have to screen candidates. It's a long and grueling application process, and I'm not quite sure that you could hack it. We're talking a half dozen phone interviews, of about 45 minutes each, 4 days personal interview (though we do put you up in a local hourly motel when we're through with you), complete reference check going back to third grade, require a sizeable tithe bi-monthly. IF you pass the first round, then there are further trials you must pass, but I can't let you know what they are until you past the first day.

Rule one: No one talks about the Inchfan.

Rule two: Don't listen to a word I say ;-)

Re:Too little for too much $$$

[rpeppe]

well, it's only the core OS that's being charged for - most of the development environment is free (as in beer & liberty), unencumbered, open source, whatever you want to call it. that includes (at the last count) 225460 lines of Limbo source code doing all sorts of cool things outside the kernel.

you can do with that what you want. if you want to hack the kernel, port it to a new platform, whatever, then, yes you have to pay your $300 and become a subscriber. but once one person has done that, they can distribute the kernel binaries with no hinderance, and due to the portable nature of inferno, all worked under it will still work under the new version.

if i wasn't involved in inferno development and was stuck under Windows of some description, then i'd get a copy, just for the environment. unix-like shells under NT are ok, but they don't give you that "my whole environment is pliable under my fingers" feel that having a complete environment does.

the beauty of inferno includes the fact that once you've got something in your namespace (and everything, including network connections, is accessed through the namespace) you can transparently export it through any type of datalink, with whatever sort of encryption/authentication you want, and use it as if it was local. i don't know any other system that provides that much flexibility for so little protocol overhead.

Cleanliness vs. Performance.

[be-fan]

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.
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 /var/shm, and means that every access incurs a slight overhead by having to go through the file system.

Re:Cleanliness vs. Performance.

[hey!]

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.

Well, you could treat your disk as a linear array of blocks, but for all the different things you use it for its convenient to have a hierarchical organization. Trees are very nice because they allow you to handle a large quantity of heterogenous data to potentially organize huge volumes of information in an fractal manner.

Maybe it would be more correct to ask whether you would prefer to organize everything you deal with in a flat address space like a hash table or in a directed, possibly cyclic graph. Maybe there are better abstractions, but if you have to live with one, DCGs are probably a good choice.

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?

No, I think its easier to read the contents of the virtual file "/network/IP/dns/www.slashdot.org" than to learn a custom set of function calls just for DNS. DNS is a critical, but very small part of many programs. It is bad to have a large number of small, critical parts to a program, each with its own idiosyncratic abstraction and needing its own set of mental and software tools. The fact that a mechanism may closely tracks the underlying implementation has no particular virtue -- why provide abstractions at all unless they transform the underlying problem in a significant way? The application programmer typically has no more interest in the underlying design of something like TCP/IP sockets than he does in the physical geometry of his hard disk. It's a necessary evil.

Re:Cleanliness vs. Performance.

[be-fan]

True, in the case of DNS it is definitely network traffic. But what about more important syscalls and calls to stuff like graphics or sound libraries? These functions are called many times repeatedly, and often (as in the case of some graphics calls like putpixel) the function call actually takes less time to exectute than the actual function.

Re:Cleanliness vs. Performance.

[be-fan]

I think treating a device as anything other than a region of memory is pretty silly, because that's exactly what it is. Maybe its just from doing so much DirectX work, but I find stuff that maps to the hardware (like Direct3D) much easier to program for than stuff that gives me abstractions that the author thought was appropriate (OpenGL). Say you're writing a graphics driver. You know that you have to write certain values to certain locations from a certain offset. Say writing 5 to BASE+0x5 results in a video mode change. Under the whole file paradigm, you have to convert this to the ioctl format or a stream based thing, wheras in the memory region way, you could just set 0x5 above the pointer to 5. Also, devices don't exactly have depth. Probaly the deepest tree you'll have in the case of an Inferno device would be that of something like a Voodoo2, where you'd have a root dir, and two files representing texture memory and frame buffer. Lastly, having this overhead doesn't sit well with me. Not only does inferno run everything in a VM (kinda like a Java OS? Last time I checked, Java was barely fast enough for those porn feeds, much less and OS!) but it makes these abstractions that result in a further performance hit. Performance penalties should be optional. Why not have a base API designed for performance, and then wrap these abstractions around that?

Re:Cleanliness vs. Performance.

[be-fan]

No, actually I was not thinking hard disk files. I assumed that they'd be virtual in-memory files, kind of like shared memory is under Linux. In Linux, when you call gethostbyname(), it directly maps to how the software is designed. In Inferno, the call has to be relayed through the file system (context switch to kernel) which has to relay it to the appropriate code. Even if the file never hits the harddisk (now that would be silly!) it still incurs the overhead of having to have the filesystem code deal with the write and call the appropriate code.

Re:Cleanliness vs. Performance.

[be-fan]

Okay, I'm thinking of it as code associated with a name space. However, when you have a function, you actually have a pointer to the memory where that code is, and a function call is simply a jump to those instructions. Under this method, however, the filesystem part of the OS has to step in to decode the reads and writes to that virtual file and turn them into requests for the DNS address. For example,
In Linux: You call gethostbyname(). It calls a system trap which jumps to that code inside the kernel (or netoworking library or whatever.) That function then procedes to get the host name and return it.
In Inferno: You write something to a virtual file. The Inferno filesystem intercepts the write. It takes a look at what command you are trying to do, takes a look at the stuff you feed it (parameters) and then passes that info onto the networking code in the kernel via a function call. This step of having the kernel intercept the call and decode it is what introduces the overhead. Also, since it is a virtual file, memory writes and reads have to be done than during a funciton call. All this is what introduces the overhead.

Re:Embedded OSes.

[be-fan]

Small nitpick. QNX is also a(n) UNIX.

Inferno? Plan9?

[1010011010]

Is there any relationship between Inferno and Plan9?

Re:Inferno? Plan9?

[johnbates]

Yes. They were developed by more or less the same set of developers at Bell Labs. Inferno came along after Plan 9 and includes the virtual machine and Limbo programming language which are not present in Plan 9. There is a lot of similarity at the source code level in the kernel and anyone familiar with the Plan 9 kernel would quickly get to grips with Inferno kernel development. They share the same C cross-compiler suite for a variety of machine architectures. One big difference, though, is that Inferno can run as a hosted operating system on Plan 9, Linux, Free/BSD, Windows, Solaris, and others as well as running natively in its own right.

Products that currently use Inferno

[nexus9k]

What all products are currently using the Inferno OS?

I know that the Lucent Managed Firewall / VPN Gateway does, and I have to say, even though it has quite a price tag (>$10k), it's still a very nice device. They integrate a full feature ICSA and NSA-certified hybrid firewall including anitivirus control and URL blocking. I believe the throughput is in the 75 Mbps range for 3DES (with a few thousand VPN tunnels). Real nice box, but yeah, you pay for it.

Re:OS runs as an application

[jdike]

How hard would it be to make Linux do that? I'd think that User Mode Linux would be a very good start.

Shouldn't be too hard. The host OS needs the ability to intercept and annull system calls. There are some other things which would be nice to have, but probably can be worked around if they're not there.

NT allegedly has the capabilities, 98 is iffy, and 95 is out. I've looked at FreeBSD (and one other, I think NetBSD) and they don't seem to have system call interception. I don't know about the other Unices.

Jeff

Re:"New Ideas" in Inferno

[rpeppe]

Besides, you can do incredible things with mere sh scripts in inferno, since everything is a file.

had to respond to this, as i've recently finished writing the inferno shell. (unless that's anonymous coward chris, ya bugger, in which case i've just been trolled, sorry folks)

where else can you make a distributed app in one line of shell script?
file2chan /dev/shellctl {} {somecommand ${unquote ${rget data}}}
that one line makes a file in the namespace - any write to that file runs somecommand with the arguments that have been written to the file. i.e. i can do:
echo ${quote arg1 'arg 2'} > /dev/shellctl
or even better:
fn somecommand {
echo ${quote $*} > /dev/shellctl
}
somecommand arg1 'arg 2'
and it'll run
somecommand arg1 'arg 2'
in the original process. the properties of the inferno namespace mean that i can then export that across the network transparently, encrypted, etc. corba eat your heart out. :-)

Re:Embedded OSes.

[Junks Jerzey]

I for one would rather be involved in the embedded Linux effort.

If you knew anything about embedded programming, you wouldn't want Linux to be an embedded OS. You don't really want an embedded system with the "unlimited resources" attitude of UNIX. That's not to say Linux is bad, just that it is out of place for embedded systems work.

Re:Why is it called inferno?

[/]

Judging from the prominent (aka "big-ass") quote on their website, it was inspired by Dante's opus of the same name. It also fits in nicely with the name of the related programming language: Limbo.

Re:OS runs as an application

[jdike]

FreeBSD/NetBSD have system call interception. That's how their Linux/BSDi/etc "emulation" works.

Could you point me at the code in the kernel that implements it? Or anything on a FreeBSD system that uses it?

I looked at the FreeBSD system call path and saw no sign of any kind of tracing or interception. Also, the ptrace headers contain nothing resembling PTRACE_SYSCALL, and strace doesn't exist on the system I looked at.

Jeff

It's too bad Limbo is such a horrid language

[Doubting Thomas]

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.

-

other related info...

[kootch]

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.

Re:other related info...

[kootch]

sorry, forgot to turn on html... savaJe

Infernal OS?

[Denor]

I believe Microsoft holds the trademark for their own Infernal OS. This company's just looking to get themselves sued!

Wait, Inferno?

New OS's from this company...

[gavinhall]

Posted by 11223:

It seems that this company is publishing two OS's from Bell Labs - and is trying to enter the alternative OS market. I've played with the inferno emulation environment under Linux, and it was interesting but horridly slow. I hope the standalone version corrects that. However, I do have a few questions: What is it good for? What programs are for it? How easily can I port programs from *NIX?

Re:New OS's from this company...

[rpeppe]

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!

Too little for too much $$$

[jheinen]

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.

OS runs as an application

[SurfsUp]

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.

How hard would it be to make Linux do that? I'd think that User Mode Linux would be a very good start.
--

Notice who pays the full price

[stevens]

This is something that I never really noticed until now. Note how the price structure works:

• Students -- big discount
• Academics -- big discount
• Commercial, volume purchases -- discount
• Single Hobbyist/Developer -- full price

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

"New Ideas" in Inferno

[nestler]

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.

Re:Saw it coming

[johnbates]

It has been very popular with some Far Eastern companies as the native operating system for their webphones. Probably partly due to the slick way that Limbo and Tk work together to provide the graphics in a very small footprint. I think too that the fact that you can run native inferno in a device like a phone and run Inferno emulated on, say Windows, and then mount the namespace from the phone into your Windows Inferno make application development and debugging much easier. Your phone applications can also run in an identical environment under Windows, Linux, Plan 9 for testing.

I use the Acme development environment (which both Inferno and Plan 9 have) as my editor of choice on Linux, Windows and Plan 9.

Oh, that I had a moderation point to spend on this

[weston]

subject says it all

Impostor

[Bruce Perens]

The above post is an impostor.

How useful is this?

[Jon Erikson]

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

Um.

[Bruce Perens]

No problem with your posting more than I do, but it's time you took personal responsibility for what you write. Right now, you're putting on a mask of my face and then giving the thin self-justification that it's not perfect and occassionally you admit the deception. From here, it seems far more cowardly than honestly labeling yourself as an AC.

The things you write generally seem rational but they aren't what I would write. Your posting on the Academy tonight was especially far off.

Get your own name, already, cowboy.

Bruce

Embedded OSes.

[len(*jameson);]

How many other OS choices do we need?! Didn't QNX just attempt a similar sort of pricing structure change in order to attract new developers?

It's true, choice is a Good Thing(tm) when it comes to OSes, but I think that these companies are really starting to get jealous of the developer interest and support that the *Nixes enjoy and want a piece of the action.

I for one would rather be involved in the embedded Linux effort.