Home · Blog · RSS feed for this page
Updated 19 February 2026
I’m making a bit of an effort to read more articles and books – rather than social media – about computing this year. Below are some notes on what I’ve read.
February 2026 · plan9-rc.pdf
This article describes rc, the shell for Plan 9. The rc command language is based on the Bourne shell, which was previously the default on Unix.
Rc syntax is identical to Bourne shell for simple commands, including
redirecting stdin/out/err, pipes, and combining commands with
;, &&, and ||. Beyond
that, a lot of details are different: there’s a nicer syntax for if and
loops, a new switch statement, nicer syntax for functions, and some new
options for I/O redirection beyond the three standard streams.
The one fundamental change is that variables in rc are arrays of
strings, not just strings. The big advantage is that this means commands
don’t need to be re-scanned after variable substitution, which lets rc
avoid some of the most confusing aspects of the Bourne shell, including
its multiple types of quotes and the distinction between $*
and $@.
Overall, rc is not revolutionary, but it makes a lot of “quality of life” improvements over the older Bourne shell. I’m not sure why the Unix/Linux community didn’t end up adopting rc as a successor to the Bourne shell – probably due to inertia and the fact that the Bourne shell is mostly very good already.
February 2026 · plan9-names.pdf
This article describes two of the central ideas in Plan 9: per-process name spaces and the 9P protocol.
It briefly describes the different message types of 9P. There’s 17 message types, so it’s not complicated but also not simplistic. 9P is used to access files and services over the network, but not for local kernel-resident file systems. Those are accessed using a set of procedures that map one-to-one with 9P message types. The one-to-one matching means Plan 9 doesn’t need the clunky code generation that Protobuf and many other RPC frameworks use, which I think is rather elegant.
The bulk of the paper discusses examples of the flexibility and power that come from building a system on the principles of per-process name spaces and a common protocol. Two things stood out to me.
One is the use of plain-text messages, written to or read from files,
as APIs. For example, every process is represented by a directory under
/proc, for example /proc/123 for process 123.
This contains a ctrl file that’s used to control the
process. Something like
echo kill > /proc/123is used instead of
kill -9 123on Unix. A common namespace and a simple plain-text protocol means Plan 9 doesn’t need a special-purpose command for controlling processes.
Interestingly, one reason why they went with plain-text commands over a binary protocol was to avoid issues with endianness. One of the design goals for UTF-8 was byte-order independence. There’s an interesting contrast with Microsoft Windows, where the default is still, in 2026, to use BOMs (byte-order markers) with text files.
The other thing that stood out to me is how the uniform namespaces
can be used for debugging. The article describes a command called
iostats that implements a “statistics-gathering file
system”; basically a proxy for a process’s namespace that reports usage
and performance figures for accesses to file systems. The idea is a bit
like strace, but instead of a giant list of system calls,
you get statistics neatly organized in terms of the hierarchical file
system.
Another command is import, which connects part of the
name spaces on a remote machine to the local one. For example,
import helix /procmakes the /proc file system on machine helix available
locally, so you can see its processes with ps and other
standard tools. Contrast with Docker, which can make it difficult to
even see files and processes on your local machine!
February 2026 · plan9.pdf
The article is an overview of Plan 9, a distributed operating system developed at Bell Labs as a successor to Unix. It starts by explaining the motivation for building a new operating system:
Graphics and networking were added to UNIX well into its lifetime and remain poorly integrated and difficult to administer. More important, the early focus on having private machines made it difficult for networks of machines to serve as seamlessly as the old monolithic timesharing systems.
The article explains the three principles that Plan 9 is based on: a hierarchical file system that’s used not just for files but also other resources provided by various services; a standard protocol called 9P, used to access those resources; and a way to join the services together in a single private hierarchical namespace. After that, it presents how different parts of the system are designed, including the windowing system, the file server, networking, and user accounts.
There’s also a brief description of the concurrent programming language Alef.
One interesting detail is that Bell Labs’ Plan 9 system was heterogeneous, with MIPS, SPARC, and Intel machines. All software for Plan 9 was written in portable C or Alef, and the compilers were designed for cross-compilation, so programs could easily be built for all architectures.
From the perspective of 2026, Plan 9 seem impossibly ambitious. Its creators wanted a better way to do networking and to use graphical interfaces, so they came up with some new design principles for an operating system, built that operating system, started using it day-to-day and along the way created a new standard networking protocol, a new encoding for text, and a programming language for concurrent programming.
By contrast, everything we do today seems very incremental! It shows how much we’ve stagnated, especially in operating systems. We mostly seem to pile more layers on top of each other instead of designing better systems.
Another aspect I found interesting is how a small number of design principles can inform every aspect of a system. I should read some of the other Plan 9 papers to see more of how that plays out.