Inferno
see more templates or propose new |
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
Links
- Main Inferno Google Code Project
- Wikipedia Article
- Documentation
- Mailing List and other Resources
- Inferno Programming with Limbo by Phillip Stanley-Marbell (Book)
Development
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
Design
UI Ideas
- Plan 9 and Inferno user interface design was focused on 3-button mouse environments. The two button track pad presents a very different look and feel. How do we approach a new user interface based on the properties of the XO (trackpad, game-keys for tablet only operation, stylus?)
- Build menu system based out of hub design in such a way that it can be operated on purely with tablet-mode accessible keys (game pad)
- Keep task management and sharing as separate, omnipresent drop-down features
- Make SVG icons and TTF first-class citizens within Inferno via built-in modules
- Add transformation primatives to draw libraries (rotation, scaling, etc.)
Application Ideas
- Learn
- Read
- E-books
- Reading comprehension
- Vocabulary
- Write
- Typing
- Spelling
- Arithmetic
- Math Drills (Add, Subtract, Multiply, Divide, etc.)
- Calculator
- Unit Conversion
- Read
- Create
- Write
- Document
- Wiki
- Web
- Personal Journal
- Draw (Paint/SVG)
- Build (SDK)
- Demos
- Collide
- Coffee
- Bounce
- Polyyhedra
- Reference
- Man Pages
- Papers
- Tutorial
- Info
- Memory Manager
- Task Manager
- Module Manager
- File Tree
- SDK
- Code Editor
- Debugger
- Build Shell (MASH)
- Wish (Tk Shell)
- Demos
- Record
- Audio Recorder
- Video Recorder
- Camera
- MIDI Composer
- Write
- Play
- Tetris
- Minesweeper
- Soduku
- Snake
- Reversi
- Share
- Communicate
- Collaborate
- IM Chat
- Voice/Video Chat
- Whiteboard
- Poll
- Post
- Permanent Sharing (wiki?)
- Buddies (Community Management)
- Communicate
Don't know how to categorize yet:
- Multimedia Players/Viewers
- pictures
- movies
- songs
- midi
- encoded
- playlist sharing, etc.
Infrastructure Ideas
- Build an Inferno/Plan 9 approach (using synthetic file systems) to the sharing/presence technologies
- Build an Inferno/Plan 9 approach (using synthetic file systems) to DBUS interface objects
- Build an Inferno School Server implementation to handle registration/authentication, post style permanent sharing (perhaps based on wikifs), and long-term storage (via Venti)
- Create an external interface to GUI so that external programs can hook back into Inferno GUI via synthetic file system allow programs written in C, Python, Squeak, whatever to use the same widgets and what not
- Single laptop/multi-user model based on cryptographically secured file system images and inferno-internal id management in order to accommodate OLPC security model.
Implementation
Issues
- pragmatic issues
- fonts need to be bigger, so does toolbar icon
- need "better" basic apps set in launch menu
- would be nice to have "full screen" shortcut box on many apps (or default to full screen)
- fix font selection in apps to use fonts which have been included
- create olpc home directory and files
- "first day" script(?) for things like key generation and baseline configuration
- conformance issues
- rotate works, but not gracefully
- need full unicode font set to be fully internationalizable (talk to forsyth about licensing issues)
- emulation issues
- 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.