jpnt website

UNIX, Plan9 and Linux Containers

Posted on Apr 4, 2025

Introduction

The history of operating systems is a story of solving isolation – of processes, resources, and users.

From UNIX’s monolithic simplicity to Plan 9’s radical reimagining of distributed computing, each step laid groundwork for today’s modern Operating Systems infrastructure and in my opinion by learning these concept we can get a broader understanding of Linux containers.

UNIX: The Birth of Modular Design

Born at Bell Labs in 1969, UNIX introduced a philosophy: everything is a file. Devices, pipes, and even network sockets were files in a single global namespace. Users interacted via “dumb terminals” while computation happened on centralized mainframes.

Limitations:

  • No isolation: Processes shared PIDs, filesystems, and devices.
  • Network opacity: Remote resources required clunky protocols (NFS).
  • Monolithic: Tight coupling made scaling complex.

UNIX was revolutionary, but its flaws demanded rethinking.

Plan 9: What UNIX Could Have Been

By the 1980s, Bell Labs saw UNIX’s limits. Plan 9 emerged as a distributed OS where every component was a service.

Key Innovations:

  1. Per-Process Namespaces Each process had a private view of the system. /bin could be local or a remote server, /dev dynamically mounted.

  2. 9p Protocol Resources (even hardware) were files accessible over a lightweight network protocol.

  3. Microservices Before Their Time Authentication, storage, and UIs were decoupled services. A window manager was just a filesystem mount.

Why It Failed:

  • Required specialized hardware.
  • Arrived too early – networks were slow, ecosystems fragmented.

Yet Plan 9’s ideas such as namespaces and network transparency lived on.

Linux: From Hobby Project to Container Host

Linux began in 1991 as a UNIX clone but evolved into something more. Its monolithic kernel prioritized performance, while adopting Plan 9’s /proc and namespaces.

The Internet Era: Apache on Linux powered the web, but scaling demanded better isolation. Virtual machines were heavy; developers craved lightweight solutions.

Linux Containers: Plan 9’s Legacy Realized

Containers solved two problems: isolation (preventing processes from colliding) and resource control (limiting CPU/memory).

Kernel Tools:

  • Namespaces (PID, network, mount): Isolate a process’s view of the system. Example: A container thinks it’s alone because its PID namespace hides host processes.
  • cgroups: Allocate CPU/memory per process group.
  • seccomp: Restrict syscalls (e.g., block mount() in a container).

From chroot to Docker:

  • chroot (1979) jailed filesystems but lacked resource controls.
  • LXC (2008) combined namespaces and cgroups for full OS containers.
  • Docker (2013) popularized portable images and microservices.

And Docker will not be the last, I believe better solutions like Podman exist and many more will come as this technology improves and new security and performance requirements surge.

Old Lessons, New Tools

Plan 9’s vision – of namespaces, modular services, and network transparency – found belated success in Linux containers. What once required a niche OS now underpins cloud-native ecosystems. Containers are Plan 9’s quiet victory, proving that good ideas resurface when the world catches up.

As Plan 9’s creators noted: “Old tools are used for new purposes.” Containers are those tools, reimagined.

Resources