Plan 9 is the failed1 successor to Unix. It was developed by the same group,
Bell Labs, with all of the experience they had gather in the twenty years since
Unix was first written. Many features that are common today in many Unix
systems, and some non Unix systems, came originally from Plan 9. For example,
/proc file system was first implemented in UNIX 8th Edition, which was the
predecessor to Plan 92. Another example, which I will talk about in this
post, is the use of process namespaces.
Plan 9 had two major ideas, that everything else was built on. The first was the
idea that everything is a file. You might think that in Unix everything was
already a file, but it was only partially true. In Plan 9 they took this idea to
the extreme. Everything including the input and output of the system, process
management and network connections were all accessed through the file system
instead of the usual syscalls. The second major idea is, you guessed it, per
These two major ideas are the key to what makes Plan 9 namespaces so great.
Instead of having a different namespace API for each resource, like we have in
Linux, we had a unified concept of filesystem namespaces. It already means that
the namespace API is a lot simpler than its Linux counterpart, but it also means
that we have a namespace for almost anything. A popular example is the
drawterm terminal, which connects to a remote machine, and binds the client
display and input devices into the process namespace. That makes for an elegant
remote desktop solution that doesn’t require a custom protocol3.
The drawterm program also shows another awesome property of Plan 9, which is a
side effect of the two major ideas. Plan 9 was made after the concept of
computer networks was more common, and so it supports networking natively. Plan
9 has its own network filesystem protocol called 9p, which is used to create the
filesystem view of the process. You don’t care if each resource is local or not,
you access it the same way through the filesystem. A nice example of it, is that
if you want to create a proxy in Plan 9, you just need to mount the remote /net
directory of the proxy server into the local /net for the desired process.
I’m not aware of a Docker counterpart in Plan 9 but I think it’s obvious how one
would implement such a thing easily. Some APIs are missing, like cgroups, and
the operating system is sadly stuck in the 90s, but I think Plan 9 can be a
great inspiration in simplification. Sadly, we can’t just bring Plan 9
namespaces into Linux or any other Unix-like os. Only a system designed from the
start properly, with such coherence, can achieve something so simple yet so
powerful and intergate with the whole system.