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 would 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.
Commercial version of Unix developed by IBM (IBM AIX 4) ↪
Files
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 files.
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 filesystems.
On the other hand, Fuchsia software delivery stack is opinionated about filesystems, in the sense that it only allows loading files as executables if they’re stored in the specific filesystem called BlobFS .
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 more difficult.
Hierarchical structure
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: Fuchsia does not explicitly manage file system hierarchies. But the operating system does reason 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:
$ ls
bin
blob
boot
config
data
dev
hub
hub-v2
mnt
(..)
(output of ls on a Fuchsia workstation
build)
There are two interesting things to note:
- what we see is a Fuchsia namespace . The entries are not filesystem directories and files. Instead, these are Fuchsia capabilities (services), organized in directories
- every software component has its own namespace
, ie. its own view of the capability universe, containing only the services it can access. The output of
lsis what the operating system (specifically Component manager ) configured for the ssh tool to see, based on the its component manifest . There is no global view of the capability tree.
Connecting programs
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 uses dash , a Unix-style shell that supports pipes. These pipes work on Fuchsia the same way they work on Unix-like systems.
Perhaps more interestingly, Fuchsia provides a more general mechanism to build arbitrary connections between programs. FIDL is a 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 pipes.
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:
Portability
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: 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 written in various languages 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 cohesive experience.
Fuchsia runs on multiple hardware platforms, see Supported system configurations .
Conclusion
One overarching difference between Fuchsia and Unix that emerges from this, is that Fuchsia is capability oriented. In Fuchsia, everything is a capability, and the operating system facilitates connecting and using capabilities between various software components.
PS This is probably a great moment to recommend the Strange Loop 2022 talk on FIDL by Ian Mckellar.