Inferno

Inferno This activity was Extra .xo Bundle – inferno-1.xo SVN sources in code.google.com GNU licensed under GPL2 Eric Van Hensbegren (Ericvh) see more templates or propose new

Inferno Applications Screenshot

Inferno Games Screenshot

Inferno® is a distributed operating system, originally developed at Bell Labs, but now developed and maintained by Vita Nuova® as Free Software. Applications written in Inferno's concurrent programming language, Limbo, are compiled to its portable virtual machine code (Dis), to run anywhere on a network in the portable environment that Inferno provides. Unusually, that environment looks and acts like a complete operating system.

The use of a high-level language and virtual machine is sensible but mundane. The interesting thing is the system's representation of services and resources. They are represented in a file-like name hiearchy. Programs access them using only the file operations open, read/write, and close. The 'files' may of course represent stored data, but may also be devices, network and protocol interfaces, dynamic data sources, and services. The approach unifies and provides basic naming, structuring, and access control mechanisms for all system resources. A single file-service protocol (called Styx or 9P2000) makes all those resources available for import or export throughout the network in a uniform way, independent of location. An application simply attaches the resources it needs to its own per-process name hierarchy ('name space').

The system can be used to build portable client and server applications. It makes it straightforward to build lean applications that share all manner of resources over a network, without the cruft of much of the 'Grid' software one sees.

Inferno can run 'native' on various ARM, PowerPC, SPARC and x86 platforms but also 'hosted', under an existing operating system (including FreeBSD, Irix, Linux, MacOS X, Plan 9, and Solaris), again on various processor types.

(description copied from google code project)

Besides being a new runtime environment, Inferno offers a number of applications which should run out of the box:

• multimedia (audio player, mpeg player, avi player)
• games (tetris, reversi, lego mindstorms interface, etc.)
• collaboration tools (email client, chat, shared whiteboard, etc.)
• servers (web server, content addressable storage system, etc.)
• tools (vt terminal, telnet, sgml editor, debuggers, etc.)

Releases

• inferno-1.xo - (~20MB) initial release, functional but not visually optimized for OLPC
• Documentation Bundle (~2MB) - installs papers and reference in browser library

Status

• first release available
• bundle installs correctly
• interacts properly with window manager
• functional, but UI is not optimized for OLPC environment (yet)
• JIT currently disabled, so it runs slower than optimal but faster than most other sugar apps

TODO

• olpc custom init script
  • bind activity writable data area over home directories
  • first run creates user home directory
• integrate libfreefont and use larger fonts for default environment

Issues

• pragmatic issues

1. fonts need to be bigger, so does toolbar icon
2. need "better" basic apps set in launch menu
3. would be nice to have "full screen" shortcut box on many apps (or default to full screen)
4. fix font selection in apps to use fonts which have been included
5. create olpc home directory and files
6. "first day" script(?) for things like key generation and baseline configuration

• conformance issues

1. rotate works, but not gracefully
2. need full unicode font set to be fully internationalizable (talk to forsyth about licensing issues)

• emulation issues

1. qemu doesn't seem to use the same screen size so menu bar is cut off under qemu

Notes on conforming to the Low-level_Activity_API

The big barriers seem to be:

a) dbus - ugh, necessary to interact with core services (resource (camera/audio) control, sharing (not sure how this will fit in with Inferno yet), and most likely job control/monitoring features. Either need to handle this via an external proxy (maybe some kind of dbusfs) or link emu against the necessary bits. Actually, maybe the right approach would be to use py9p to write a 9p gateway to the relevant dbus services. Not sure if there are restrictions against local socket connections, but if necessary I could always do it via stdin/stdout. On the other hand, that could turn out to be prohibative performance wise if I was using that path to do "tubes" or video. Perhaps the right thing is an olpc device driver which does the dbus stuff under the cover in a similar manner to GCompris.

b) Datastore - while unlocked currently, the eventual model for the OLPC is to be locked down in such a way that any state gets stored in their temporal journal. I believe it is a file system, but the apps aren't meant to use it that way. This probably means we'll need to have our own "image" for the user's home directory which we can then mount and bind into place. We'll also have to support consistent snapshots of this sucker. If you do the "full-implementation" of journal, session state (windows which are open, etc.) needs to be stored as well. But it seems to heavy weight to do with all of Inferno. This might be gotten around with the data directory, but right now it won't survive upgrades.

c) user/group - the user name the activity is run as depends on the instance that is run (groan), but the group should be the same for all instances of the activity. Might have to get creative with devfs here.

d) network access - you should be able to set bits to allow open network access, but it might also be nice to support their stream tubes so we link in with the sharing methodology.

So there is a bunch of things that have to be adapted. The only really onerous thing is Dbus interfacing. I've never dealt with DBUS, so I'm not sure how I'd want to interact with it from emu. I suppose we could link against dbus libraries, but maybe it would be better to use devcmd to start some sort of dbus proxy which we can then expose in the file system. Quickly looking at my options I'm leaning towards relying on an external proxy -- there doesn't seem to be a simple C library to link against to provide Dbus hooks.