Inferno is Lucent Technologies' (``Bell Labs'') successor to Plan 9. The Inferno network operating system was designed to be compact while fully functional, and fit in a small amount of memory. It is designed to run on devices such as set-top boxes, PDAs, and other embedded systems [Lucent97].
In Inferno, everything is represented by files. Therefore, file systems are indistinguishable from other services; they are all part of the Inferno name space. Even devices appear as small directories with a few files named ``data,'' ``ctl,'' ``status,'' etc. To control an entity represented by such a directory, you write strings into the ``ctl'' file; to get status, read the ``status'' file; and to write data, open the ``data'' file and write to it. This model is simple and powerful: operations can be done using simple open, read/write, and close sequences -- all without the need for different APIs for networking, file systems, or other daemons [Breitstein97].
Inferno allows name spaces to be customized by a client, server, or any application. The mount operation imports a remote name space onto a local point, much like Unix file system mounts work. The bind operation is used to make a name space in one directory appear in another. This is similar to creating symbolic links and hard links in traditional Unix file systems, with the exception that Inferno can also unify the contents of two directories.
For Inferno to offer a new file system functionality that might otherwise be achieved via vnode stacking, an application has to mount and bind the right name spaces, add its own as required (implemented via the Limbo programming language [Kernighan96]), and then offer them for importation (which can be done securely).
Inferno's main disadvantage is a familiar one. It is a brand new operating system, and employs a new programming language and model. Inferno is not likely to be as portable and in wide use for years to come. My impression of Inferno is that if successful, it will become popular in the field of embedded systems.