Unix is arguably one of the most influential projects in the history of
computing. It pioneered and popularized a number of innovations in operating
system design and spawned an entire family of systems that can be described as
“Unix-like” or “Unix-derived”. Notable examples of modern-day Unix-related
systems include Linux, iOS and Android, powering much of the cloud computing and
smartphone technologies we use every day.
In his book about Unix
Brian Kernighan (one of the early developers of Unix at Bell Labs) includes an
elegant summary of what he sees as the lasting technical legacy of Unix. I
thought it could be interesting to look at some of these lasting innovations and
see how they’re reflected in Fuchsia, a new open-source operating system
that is not based on Unix.
In the following sections we go over key technical features of Unix mentioned by
Brian Kernighan in Unix: A History and a Memoir (chapter 9) and compare the Unix
approach with Fuchsia.
Unix approach: Files contain arbitrary bytes. The operating system does not
reason about the data format of the file. To interoperate on the same files,
programs need to agree on the formats, but the operating system does not
control what formats are allowed.
Why it mattered: Some of the operating systems before Unix managed
separately different types of files. For example, differentiating source code
files, compilers, executable program files and data files. This limits
flexibility: for example, if “executable program files” can only read “data
files”, it’s harder to make an executable file that itself processes executable
Fuchsia approach: Fuchsia indeed does not care about file formats. Actually,
Fuchsia takes this to a next level: the operating system kernel does
not reason about filesystems altogether
Fuchsia’s filesystems (..) are not linked nor loaded with the kernel; they are
simply userspace processes that implement servers that can appear as
The reason for this restriction is that the capability to use a piece of stored data as
executable code (instructing the processor to start executing the instructions
contained in a file) is sensitive. Software attacks are often based on
the attacker planting a piece of executable code on the victim’s computer and
tricking the machine into executing it. Enforcing that all executable files are
stored in a read-only, cryptographically verified file system makes such attacks
Unix approach: Unix filesystem has a root directory containing files and directories. Directories can contain further files and directories and can be nested.
Why it mattered: Before Unix (and Multics, an earlier OS that inspired Unix), most OSes had arbitrary limitations on filesystem structure. For example, MIT’s Compatible Time-Sharing System released in 1961 supported nesting but only up to two levels.
Fuchsia approach: as stated before, Fuchsia does not reason about file system hierarchies. But the operating system reasons about capabilities
, which are a more general concept. Fuchsia capabilities represent any piece of functionality exposed by a piece of software to other software components (e.g. a file that can be read, or a speaker driver that can be used to play sound). In organizing the capabilities of the system into namespaces
visible to software components, Fuchsia does follow the hierarchical approach of a Unix-like filesystem.
For example, if we were to ssh into a Fuchsia workstation build
and type ls (command to list the “file system” content), we are going to see what looks like a Unix-style list of directory content:
what we see is a Fuchsia
The entries are not filesystem directories and files. Instead, these are
(services), organized in directories
every software component has its own
ie. its own view of the capability universe, containing only the services it
can access. The output of ls is what the operating system (specifically
configured for the ssh tool to see, based on the
its component manifest
There is no global view of the capability tree.
Unix approach: Pipes are a Unix mechanism that can take the output of one
program and feed it as input to another program.
Why it mattered: Pipes are a useful mechanism of composition, allowing
construction of powerful data processing pipelines from simpler programs. The
system command line interface (shell) made it easy to chain programs this way,
so that one could type:
who | wc -l
to build a command that counts the number of users currently signed in. who prints the users currently signed in, one per line. wc -l counts the number of lines of its input.
Fuchsia approach: Fuchsia
, a Unix-style shell that
supports pipes. These pipes work on Fuchsia the same way they work on Unix-like
Perhaps more interestingly, Fuchsia provides a more general mechanism to build
arbitrary connections between programs.
Fuchsia system for defining interfaces between software components (potentially
written by different parties in different programming languages) and exchanging
data over those interfaces. In a way, it can be seen as a generalization of
Unix authors were clearly thinking about the tradeoff between the expressive
power of arbitrary connections and the elegant simplicity of 1-1 connections
offered by pipes:
Unix approach: Starting from 1973, the majority of Unix was implemented in
C. It’s a “high-level” language in the sense that, as opposed to system
assembly, C instructions (after an intermediate compilation step) can work on
different hardware architectures.
Why it mattered: While before Unix different types of computers typically
ran different proprietary operating system delivered by the hardware
manufacturer, Unix (thanks to the portability of C) made it easy for
contributors to make it run on whatever hardware they already had. This enabled
the Unix community (mostly composed of university/research institutions) to
align on one compatible operating system, and therefore better share tools,
learnings and best practices.
Fuchsia approach: Similarly to Unix, Fuchsia is written in high-level
languages (meaning not in system assembly language), wherever it’s possible to
avoid assembly. Most of the kernel is written in C and C++, core system components are
including Rust and C++.
Fuchsia explicitly aims to be inclusive of different programming languages and
environments. This is stated as the
“Bring your own runtime” principle
developers are free to use their application runtime and programming language
of choice. Software from different runtimes can integrate together to form a
In these notes we reviewed high level differences between various technical
approaches taken by Unix, and the equivalent mechanisms in Fuchsia. The
overarching difference that emerges is that Fuchsia is capability oriented –
everything is a capability, and the operating system facilitates connecting and
using capabilities between various software components over a facility called