Inferno 4 Available for Download
Tarantolato writes "A new preliminary public release of the Inferno distributed operating system is now available for downloading from Vita Nuova's website. Inferno is meant to be a better Plan 9, which was meant to be a better Unix. It can run as a standalone OS, as an application on top of an existing one, or even as a browser plugin. Also, all of its major components are named after things related to hell."
I've briefly looked into trying out Inferno, but bear in mind it's not designed as a desktop system. Instead, the market it seems to be used in is the embedded market - so it'd be interesting to see how easy you can write server apps for application boxes with it.
However, it initially appears that Limbo is the only way to program for Inferno (prove me wrong please), which would be an obvious impediment to developer take-up.
Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
Plan 9 had a license where you couldn't sue Lucent on an unrelated matter if you used it. They've now changed that (as of June 2003), and Stallman now considers it a "free software license incompatible with the GPL". From the GNU site:
Inferno's license seems to be the same as the new plan 9 one. (But I haven't looked in depth).
Google confirms: Ruby is the world's most beloved programm
If you look at some of the docs, there seem to be a bunch of Bell Labs folks contributing (perhaps even principal developers)... including a doc by Brian Kernighan and lo and behold, Dennis Ritchie, the authors of one of the canonical C books ("The C Programming Language" -- more affectionately known as "K&R".)
Could be interesting stuff, especially the Limbo "C-like, concurrent" programming language (though the syntax seems like an ugly version of Python with some bizarre odds and ends tacked on like a <- operator for "channels").
-fren
"Where are we going, and why am I in this handbasket?"
Oh no, it's slashdotted. Check this out -- a google cached version.
[--- PGP key and more on http://www.root42.de ---]
I thought a better unix was linux!
/gui/window/...etc. Also, the network protocol is entirely file-based. Your desktop system (or smartphone, or brower plugin) sees the server or another client as part of the same filesystem that its own resources sit in.
Linux is better mostly because it's free. It does not fix some of the imperfections in the core design (for good reasons; that would break Posix compatibility). According the Inferno Design Principles, Inferno takes Unix ideas and applies them more consistently. For instance: everything is a file. In Inferno, what you're typing in a text editor window can be queried in something like
Google confirms: Ruby is the world's most beloved programm
Friend told me that Lucent is using Inferno (version 3) on Lucent BRICK firewall (model 20, model 80 ... model 1000). It is stateful firewall and works well! he says
Just wondering -- has anyone else tried this, successfully? I downloaded the demo disk and ran the OS X install script, and when the script got to the part where it started running the "emu" binary, all sorts of fascinating and wonderful errors began, starting with malloc messages. I finally ended up having to kill the process.
this being developed by Lucent several years ago, around the time that they just switched names from Bell Labs. I'd read about it somewhere on their website and never heard anything about it until now. It sure seems to have taken on a completely different form.
You're not too far off the track. It is a network
operating system that lends itself to clustering
applications, and Vita Nuova has a few big clients
looking at exactly this.
Plus the Vita Nuova people are very approachable.
(Their office is virtually within sight of mine).
One of the great advantages is that just about
everything looks like a file so it is very easy
to create namespaced collections of device-type
files that might be resident on your machine, or
just as easily resident on a collection of
disparate machines. It makes prototyping GRID
applications very much easier.
Personally I am very keen on looking more at
Inferno for GRID computing just as soon as I have
more time to spend on it. It's not a solution to
all ills, but it has definite advantages, and
seems to be very robust and has a small footprint.
I've seen it running happily on a fairly old
PDA being used to seamlessly integrate a whole
series of remote devices.
Aaron Turner, University of York
Way back in 97 as part of MS directed research stuff @ USC. Came to a screeching halt when Lucents marketing weenies decided that a source license would cost in excess of $1M. Funny bit after that was the marketing person called one of the guys on our project team and was complaining that she got chewed out by D Ritchie. He'd posted the details of the licensing deal to comp.os.inferno .
K&R, also the authers of the C language, but I suppose the book was more of an achievement?
I don't see the resemblance to Python. Limbo has:
I don't see any redeeming qualities.
This naming scheme, or at least something very similar, is used by Discreet
for their effects, editing & compositing software.
Products include Inferno, Fire, Smoke, Flame, Combustion, etc.
Inferno was developed by the same lab - and many of the same individuals - who developed Plan 9 and, earlier, Unix. that lab did all the early development, and while the primary development is now done by Vita Nuova, there remains collaboration between them (and it helps that Plan 9 and Inferno are very similar under the hood).
Of particular note is that Dennis Ritchie has written exactly two language reference manuals in his life: C and Limbo. that says a lot to me, anyway.
name dropping aside, Limbo really is a huge win for user-mode programming. the channel stuff isn't bizarre at all - it's a very elegant way to handle inter-process communication. Python's got nothing on Limbo for this.
i speak for myself and those who like what i say.
The following link might also be of interest:
http://www.wrgrid.org.uk/conference2004_slides.htm l
(Link to Vita Nuova talk about 2/3 of the way down the page).
Aaron Turner
Well, look here and here.
Indeed. In case folks don't get Radja's point, Dis, Styx, and Charon are all from Greek myth (e.g, Styx goes back at least as far as Hesiod).
Everything those gentlemen have produced thus far has been too good to be true. C, Unix, etc. Why should this be any different?
*IX is pretty good. There aren't a whole lot of obvious changes I'd like to see.
:-)
/str[^n].*/.)
/net/tcp/clone (Keep the file handle, call it f_ctl) You'll end up with /net/n/ctl when you open it.
Spelling creat with a "e"
And umount with an n... (Plan 9 has unmount. Don't know about create though. It also lacks the root of string overflows,
* I've always wondered why network interfaces (at least under Linux, not sure if this is the same under other OSes) are not files like almost everything else in the UNIX world.
In Plan 9... the whole network interface and system is done as files, not merely the channel. (For at least the TCP part)
1. Open
2. Write 'connect 192.168.1.1 23' into f_ctl.
3. If there is no error from the write, then read from f_ctl a number. Call it tcp_n.
4. Open "/net/" + tcp_n + "/data". (Call the file handle f_data)
5. Use f_data like a socket/pipe.
Lo and behold, you have a telnet connection to 192.168.1.1:23. You can write a whole server in a shell script without needing a wrapper.
Relevant man pages:
ether (3)
ip (3)
Anyway, when I have some free time, I will implement this. It should be quite easy to override the system calls using LD_PRELOAD.
Statically compiled binaries may not respect LD_PRELOAD and ignore your overrides, calling their static copy of libc directly.
By using a single, simple metaphor to represent external resources (a hierarchical filesystem with streamlined semantics), it's possible to write general purpose components that are not conceivable in other systems, because their resources are not available in such a uniform way.
For instance:
- Distributed resources:
A simple, but deeply-thought-out protocol allows access to a resource hierarchy to be made available, transport independently, through a channel. Thus, any resource in the filesystem can trivially be made available over the network. This includes graphics, network interfaces, serial devices, raw disks, user-level filesystems, user-level program interfaces, etc, etc.
- Authentication: Inferno can use a single well-defined authentication protocol to secure access to all external resources in a transparent, end-to-end fashion. Applications need not have any knowledge of this, but nonetheless gain all the benefits. If you're using this stuff, you couldn't care less about 802.11 security (or lack of it) - it's irrelevant.
- Transformation: it's easy to "layer" resources; for instance I could export a read-only version of a particular resource just by forbidding all Styx Twrite, Tremove, Twstat, etc operations.
- Application transparency: because everything looks like a file, and all the traditional unix tools just work on files (or byte-streams - same difference), it's possible to use all of Inferno's unix-like tools directly on devices, or aspects of a program's external interface without any extra "glue" code at all. This vastly decreases the dev-time, as you can just write independent components, test them individually, and just stick 'em together to make the final application.
Basically it's all about isolating complexity, network and everything else, into independently verifiable bits; the system lets you plug it all together.Almost all of the complexity in most conventional systems today comes from backward compatibility requirements. Inferno can do what it does by discarding that backward compatibility - the obvious cost is that it's quite an effort to get your old programs to run underneath it. However, for many applications, that's not an issue, whereas the unreasonable complexity of other "modern" systems is.
The cURL license seems okay now: cURL license. I suppose it wouldn't be on Sourceforge if it weren't okay.
Don't confuse cURL with Curl, from the Curl Corporation.