I've been using a Linux as my primary OS for about 20 years. Over that time I've used dozens of different distros, different desktop environments, different display servers, and compiled countless custom kernels, and even built a few toy kernels of my own.
And over that time I've developed plenty of strong opinions regarding how I want my operating system to be.
(And I think it important to draw attention to the my operating system, because I seriously expect only a small number of people to really share these views)
Yesterday, I published a poll on mastodon in which I outlined two possible futures.
In the first future, I ignore these opinions and simply accept the new Linux status quo. I pick a mainline distro that fully takes advantage of tight systemd integration, adopts wayland as the display protocol, probably run one of those nice and shiny rust based compositors, and move on to more important things.
In the second future, I fully embrace the instinct deep inside of me that says that is deeply dissatisfied with modern operating systems, and direct some of my energy towards that dissatisfaction.
At time of writing the votes are still coming in, but the distribution is undeniable. The result, perhaps obvious in hindsight.
Down the rabbit hole we go..
What is an OS anyway?
The OS as a Package Manager
There is a long standing philosophy in a few circles that the core of any operating system (or rather the most important aspect of the operating system itself) is the package manager. This philosophy can be seen in Linux distros like Gentoo and NixOS in addition to being a fairly prominent part of the BSDs.
In these operating systems the primary mode of modification is through the package manager which takes responsibility for building, optimizing, installing, and uninstalling capabilities - as well as avoiding dependency conflicts.
This is a view of Operating Systems I quite like, it's a practical view, one rooted in the necessity of managing software distributions. There is a deep academic well that has greatly improved the state of the art over recent decades - and I think there are still exciting avenues to explore.
The OS as a Programming Language
Another long standing philosophy is one that positions the operating system as a programming language. With the operator taking on the role of programmer, combining the various atoms to produce larger and more complex behaviour. This is the heart of the UNIX philosophy and the core driver behind standards like POSIX,
I love the idealism of this view, the elegance of combining small parts to form a whole, the rejection of monoliths. There is something in this philosophy that appeals strongly to my sensibilities that is deeply tied to when and how I was first introduced to this world.
Programming Languages as Operating Systems
A quick aside to remark that most programming languages, are themselves Operating Systems - with their own concepts of managing dependencies, their own higher level interfaces, and security models - abstracting away the details of the underlying system calls and other OS-internals.
It is very easy to spend a lot of time here attempting to define an exact line where a programming language ends and the operating system begins, but for now let us remark that the choice of programming language is not a trivial one and is tightly coupled to how the rest of the operating system is structured (something that we will definitely revisit in later notes).
The OS as a Manager
A aspect we must consider is that the OS as defined by its ability to manage access to resources. Diverse devices require a growing set of drivers to manage, in addition to the infinite configurations that allow them to be useful. On top of that, a growing userspace requires managing what programs get access to what devices and to help manage this complexity many mainstream services have been developed - all of which need to be configured and managed by the operating system.
Under this model, there is little benefit to atomic programs as many must have a shared understanding of the services on the system in order to get anything done, resulting in a large repository of shared code and build-time inter-dependencies.
Systemd has a lot of supporters and is now a core dependency in most of more mainstream Linux distros, desktop environments, and various core software. This centralization and standardization of various interfaces and expectations is popular and benefits from a large chunk of FOSS dev-hours.
The OS as Security Enforcer
One last aspect I want to visit is the idea that the OS is defined by security boundaries - userspace and kernel space, users and groups, file permissions etc. How far an OS should go to enforce boundaries is still a fairly open topic. Android went to great lengths to isolate processes (both by uid and through IPC). Linux's ability to setup sandboxes has greatly improved in recent years thanks to Landlock (shoutout to BSDs pledge who got there much earlier).
Security extends further, into how executables are run, how they are linked, how they are built, and into how dependencies are managed. Operating systems that focus on security (like Qubes or Whonix) have focused on isolation, containerization, and sandboxing - a non-trivial feat especially in a world where most applications are web browsers in disguise.
The OS as OS
Of course an OS is all of these things, the mixture and prominence of any particular aspect is what defines the OS.
So what kind of mix do I want?
I am a big fan of tools that do one thing well, and libraries with few (if any dependencies). Both from a practical perspective and from a security perspective. The sheer complexity of many modern Linux distributions doesn't sit well with me.
I like systems I can grasp, and turn around in my head. This gravitate towards smaller systems, because these days my head can only hold so much. I would much rather many small programs, than a few larger ones.
I like the idea of one well defined IPC mechanism e.g. a message bus like bus1. As useful as I find directly connecting programs via pipes, it is clear that a more robust mechanism is needed for certain usecases.
I'm OK with having to rewrite or port significant software into the system - especially if it avoids greater intrinsic complexity in the system itself. In practice this means that I am considering writing my own desktop environment and accepting that anything with a user interface will need to be ported. This is a direction I've experimented with in the past, and one I am keen to explore further.
I am free to ignore compatibility and in doing so really consider new security and interaction models. I expect to make heavy use of modern sandboxing and likely some virtualisation. i
I want to bring in some of the lessons from modern package and build managers while maintaining strong isolation and independence across packages.
Starting
I have been hacking away on a few pre-prototypes for a little while, and it is clearly time to start bringing them together. I have a barebones kernel and initramfs that gets me a shell, some base utils (for now, sbase and ubase), a compiler (tcc) and a libc (musl). This in practice is enough to get a lot of software up and running and from this base I've explored in a few different directions (including using Nix packages and an initial custom desktop prototype).
I think the most natural place to head next is introducing a build/dependency manager. I have experimented with quite a few over recent months, and nothing really felt right. So my plan for this coming weekend, and perhaps many weekends to come, is to design and play around with an approach that feels right to me - perhaps I will end up reimplementing 20% of Nix and justifying adopting the rest to myself, or maybe some inspiration will pull me in a slightly different direction. Ideally I want something that feels like a natural combination of smaller atoms making full use of the interfaces offered by the kernel - I have some ideas here, but this note has already run on too long, and I think it best to leave it for another time.
The rabbit hole is deep with plenty of side tunnels. Watch this space.