# Inferno OS treats every resource as a file in a per-process namespace

> Inferno is a distributed operating system from Bell Labs, now maintained by Vita Nuova as free software, where applications written in Limbo talk to devices, network interfaces and services through a single file protocol. It runs natively on several architectures and hosted under ordinary Unix systems, which makes it a study in a file-like universe rather than a modern general purpose OS.

**inferno-os/inferno-os** — Inferno® is a distributed operating system.  Inferno represents services and resources in a file-like name hierarchy, including devices, network and protocol interfaces, dynamic data sources, and services.Applications are written in a concurrent programming language, Limbo.

- Repository: https://github.com/inferno-os/inferno-os
- Stars: 831 · Forks: 115
- Language: C
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/inferno-os-inferno-os

## One namespace, one protocol, every system resource

Inferno represents services and resources in a file-like name hierarchy. The README is precise about what that means: programs access them using only the file operations open, read/write and close. A file in Inferno is not just stored data, it can be a device, a network or protocol interface, a dynamic data source, or a service.

That single decision is the architecture. Rather than giving devices a driver API, network sockets a socket API and services their own RPC, everything becomes a name you can open. The result is that naming, structuring and access control work the same way for all system resources, and the mechanism by which those resources are shared is one protocol rather than many.

The protocol is 9P, the same file-service protocol used in Plan 9. Because it is the same protocol, resources can be imported or exported across the network in a uniform way regardless of where they physically live. An application attaches the resources it needs to its own per-process name space, and from the application's point of view that namespace is the universe it can see.

This is the design that makes Inferno distributed in a literal sense rather than as a marketing adjective. A service running on one machine and a file on another are reached the same way a local file is, and the location of a resource is not part of how you refer to it.

The system originated at Bell Labs and is now developed and maintained by Vita Nuova as free software, according to the README. Applications are written in Limbo, Inferno's concurrent programming language, and compiled to Dis, its portable virtual machine code, so a Limbo program runs unchanged on any machine that has the Inferno environment.

## Native or hosted, and the difference is where you look

Inferno can run natively on ARM, PowerPC, SPARC and x86 platforms, and it can also run hosted under an existing operating system, including AIX, FreeBSD, IRIX, Linux, MacOS X, Plan 9 and Solaris, again across processor types.

The hosted mode is the one that matters for evaluation, because it lets you run the whole environment without dedicating a machine to it. The README describes that environment as portable and unusual in that it looks and acts like a complete operating system, rather than a library bolted onto the host. The host provides the process and the display, and inside the emulated environment you have a file system, a window system, a shell and an application environment that behaves like an OS because it is one.

The repository layout shows how much of the work is per platform. There are separate directories for AIX, DragonFly, FreeBSD, Irix, Linux, MacOSX, NetBSD, Nt, OpenBSD, Plan9 and Solaris, alongside the shared core: acme for the command editor, appl for applications, dis for the virtual machine, emu for the emulator, lib for the system libraries, limbo for the compiler and virtual machine sources, and services for the network services. There are also mkconfig and mkfile at the top level, plus makemk.sh, which is the bootstrap script.

So the porting boundary is visible in the tree. The shared library and application sources are common, and each port directory carries the machine specific glue. Reading Linux next to Solaris shows what has to change for a new target, which is more informative than any amount of prose about portability.

## Building it under Docker on an i386 image

The repository ships a Dockerfile that gives you a hosted Linux build without installing anything on your machine. It starts from the i386 Ubuntu devel image, installs the X11 and C development headers and gcc, and then constructs a custom mkconfig that points the build at the source tree.

The mkconfig lines are the interesting part, because they are the whole configuration surface for the build.

```bash
ENV INFERNO=/usr/inferno
COPY . $INFERNO
WORKDIR $INFERNO
RUN echo > mkconfig ROOT=$INFERNO
RUN echo >>mkconfig TKSTYLE=std
RUN echo >>mkconfig SYSHOST=Linux
RUN echo >>mkconfig SYSTARG=Linux
RUN echo >>mkconfig OBJTYPE=386
```

SYSHOST names the host system, SYSTARG the target system, and OBJTYPE the architecture. The two include lines pull in the host makefile and the target makefile from the mkfiles directory.

```bash
RUN echo >>mkconfig 'OBJDIR=$SYSTARG/$OBJTYPE'
RUN echo >>mkconfig '<$ROOT/mkfiles/mkhost-$SYSHOST'
RUN echo >>mkconfig '<$ROOT/mkfiles/mkfile-$SYSTARG-$OBJTYPE'
```

The build then runs the bootstrap and the standard make steps, and the resulting binaries are put on the PATH.

```bash
RUN ./makemk.sh
ENV PATH="$INFERNO/Linux/386/bin:${PATH}"
RUN mk nuke
RUN mk install
```

Finally the container command launches the emulator with the window system, which is the first thing you see.

```bash
CMD ["emu", "-c1",  "wm/wm"]
```

Note that the Dockerfile targets 386 and comments that on i386 there is no need for multilib, with the multilib lines left commented out. The image is therefore a 32 bit x86 build of the hosted Linux port.

## Limbo, Dis, and the compiler suite in the tree

The application model is worth separating from the operating system model, because they are separate languages and separate layers.

Limbo is Inferno's concurrent programming language, and it is the level at which applications are written. Limbo source is compiled to Dis, the portable virtual machine code, and that is what executes inside the Inferno environment. The result is that an application built once runs on any Inferno machine, native or hosted, on any of the listed processor types, because the virtual machine absorbs the platform differences.

The repository includes the native compiler suite for that pipeline. The dis directory holds the virtual machine, and the limbo directory holds the language implementation. There are also doc and man directories for the language, system and manual page documentation.

Limbo's concurrency is the feature that makes it more than a scripting language. Because the system model is built around file-like namespaces and services, and because Limbo is designed for concurrent programming, an application can treat a service as a name and talk to it over the network without changing its code. That combination of a uniform name space with a concurrent language is the reason the README calls the environment portable and complete.

For a developer coming from a modern stack, the mental shift is the point. There is no separate network API, no file API variant for sockets, and no device model to learn. There is open, read, write and close, plus a namespace you assemble for yourself.

## Where Inferno stops being practical

Three limits are visible from the repository itself rather than from a stated policy.

The first is the absence of releases. The project has no GitHub releases at all, and the version information lives in a CHANGES file and a NOTICE file at the root rather than in tagged artifacts. The last push to the repository was on 2026-06-21. That is recent enough that the tree is not frozen, but the project is not publishing versioned artifacts, so pinning a specific known good state means pinning a commit rather than a release, and the licence for the repository is not stated either.

The second is the hardware and platform range. Native support covers ARM, PowerPC, SPARC and x86, and the hosted targets include some systems that are historical even now, such as IRIX and Solaris. This is a faithful research and teaching system from a specific era of systems design, not a system that has been reworked for contemporary hardware or for a contemporary security posture. Nothing in the README claims otherwise, and the absence of a threat model or an update policy is itself informative for anyone planning to deploy it.

The third is that the hosted mode is a simulation of an operating system, not an operating system. Running Inferno under Linux gives you a complete environment to explore, with its own file system, its own window system and its own network services, and it is a genuinely instructive way to see the design. But it is running inside the host's process model and the host's security model, and it is not a way to run modern workloads.

And for a purely practical purpose, if you only want to hash a file or serve a directory, this is obviously the wrong tool. The value of Inferno is the design itself.

## How it differs from Plan 9 and from Unix

Inferno grew out of Plan 9 from Bell Labs, and the relationship is explicit: the file-service protocol is the same 9P used in Plan 9, and Plan 9 is listed among the hosted operating systems Inferno runs under. The two systems share the file-as-everything idea and the namespace model.

The difference is the distribution story. Plan 9 is a research operating system that also became a distributed system with its own network services, and it is famous for the way it treats every service as a file served over 9P. Inferno takes that idea and makes the language, the virtual machine and the portable environment the primary deliverable, so that the same Limbo program runs identically on a native ARM machine, a SPARC workstation, or a hosted Linux box. Plan 9 asks you to boot Plan 9. Inferno lets you run inside what you already have.

Against Unix, the difference is that Unix gives each subsystem its own interface. A file, a socket, a device and a pipe are four different things with four different system call families, and the shell papers over it with a dozen special files. Inferno collapses that to one interface. The cost of that collapse is equally clear: everything is a name in a tree, and the tree is assembled per process, so the mental model is different enough that Unix habits will mislead you at first.

Against the modern container and microservice world, the difference is that Inferno's distribution is native to the system rather than bolted on. There is no separate service mesh or RPC library, because a remote service is attached to a namespace the same way a local file is.

## Conclusion

Inferno fits researchers, teachers and systems programmers who want to study or extend a complete operating system that unifies every resource behind one file protocol, and it fits anyone who wants a portable Limbo toolchain on an existing machine without replacing the host OS. It does not fit everyday workstation use, since the hosted environment is not a modern desktop, and it does not fit a team that needs a current vendor-supported toolchain, given that the last push to the repository was on 2026-06-21 and the project publishes no GitHub releases at all. Before evaluating it, read the INSTALL file and the doc directory, try the Dockerfile path on an i386 image if you want a hosted build without touching your host, and check the port directories in the repository, since the per-port source trees are where the platform differences actually live.

## FAQ

### What is Inferno OS and what language are its applications written in?

Inferno is a distributed operating system originally developed at Bell Labs and now maintained by Vita Nuova as free software. Applications are written in Limbo, its concurrent programming language, and compiled to Dis, the portable virtual machine code.

### How does Inferno access devices and services?

Programs access every resource using only open, read/write and close. Files are not just stored data but represent devices, network and protocol interfaces, dynamic data sources and services, and each application attaches the resources it needs to its own per-process name space.

### Which operating systems can Inferno run hosted on?

The README lists AIX, FreeBSD, IRIX, Linux, MacOS X, Plan 9 and Solaris, and it can also run natively on ARM, PowerPC, SPARC and x86 platforms. The repository carries separate port directories for AIX, DragonFly, FreeBSD, Irix, Linux, MacOSX, NetBSD, Nt, OpenBSD, Plan9 and Solaris.

### How do I build Inferno?

The repository ships a Dockerfile that builds a hosted Linux target on an i386 Ubuntu image. It writes a custom mkconfig with ROOT, TKSTYLE, SYSHOST, SYSTARG and OBJTYPE, includes the host and target makefiles from mkfiles, runs ./makemk.sh, then mk nuke and mk install, and finally starts emu -c1 wm/wm.

### How does Inferno relate to Plan 9?

Inferno uses the same file-service protocol as Plan 9, namely 9P, so resources can be imported or exported across the network in a uniform way, and Plan 9 is one of the systems Inferno can run hosted under. The difference is that Inferno centres on a portable virtual machine environment so the same Limbo program runs natively or hosted, while Plan 9 asks you to run Plan 9.

## Sources

- [inferno-os/inferno-os on GitHub](https://github.com/inferno-os/inferno-os)
- [Issues](https://github.com/inferno-os/inferno-os/issues)
- [README](https://github.com/inferno-os/inferno-os/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/inferno-os-inferno-os