Linux Namespaces Are a Poor Man's Plan 9 Namespaces

Plan 9 is the failed¹ 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, the /proc file system was first implemented in UNIX 8th Edition, which was the predecessor to Plan 9². 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 process namespace.

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 protocol³.

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.