Building a free and minimal Unix system (Part 1) - Foundations

In my previous post, I wrote about technological minimalism as a matter of responsibility rather than convenience. This series is a practical extension of that idea.

When people talk about “secure” or “free” systems, the discussion often begins at the level of applications or operating systems. In my experience, this is already too late. If you do not control the firmware that starts your machine, or the storage that holds your data, then the freedom offered by the layers above it is largely illusory.

For that reason, this series begins at the bottom: firmware, boot, and disk encryption. These are not optional hardening steps added later; they are the foundation upon which everything else rests.

This is not a beginner’s guide, nor a set of commands to be followed blindly. It assumes a willingness to understand the system being built, and to accept responsibility for its behaviour.

What “free” means here

When I describe a computer as free, I am not referring to cost, convenience, or aesthetics. I mean freedom in the sense of agency: the ability to understand, modify, and take responsibility for the system as a whole.

A system that depends on opaque firmware, locked boot paths, or vendor-controlled updates is not fully owned by the person using it. Even if the operating system itself is free software, control has already been ceded at a more fundamental level.

Freedom, in this context, is architectural. It begins before the kernel is loaded.

Firmware as the root of trust

The firmware is the first code that runs when a machine powers on. It defines what can be executed, in what order, and under whose authority. If this layer is proprietary, undocumented, or hostile to modification, then every layer above it inherits those constraints.

Modern computing often treats firmware as an implementation detail, something to be ignored or updated automatically. I believe this is a mistake. Firmware is not peripheral — it is the root of trust for the entire system.

For anyone serious about owning their machine, firmware cannot be an afterthought.

Libreboot and firmware freedom

Libreboot replaces proprietary firmware with a fully free boot firmware, removing large portions of vendor-controlled code from the boot process. This does not make a system magically secure, but it does restore a critical property: the ability to understand and control what happens when the machine starts.

I do not recommend Libreboot casually. Flashing firmware carries risk, and not all hardware is supported. For those unwilling or unable to perform the process themselves, I strongly recommend purchasing a pre-flashed machine from a trusted vendor.

My own Librebooted ThinkPad was obtained from Leah at Minifree. Minifree provides refurbished laptops with Libreboot preinstalled, using hardware known to be compatible with free firmware. The service is careful, principled, and transparent, and I believe it is worth supporting for anyone serious about owning a genuinely free computer.

Starting from a Librebooted machine simplifies everything that follows. It removes an entire class of uncertainty from the system and establishes a clear boundary of responsibility: what happens on the machine happens because you configured it to do so.

A note on UEFI and modern boot processes

Most modern computers ship with UEFI firmware and a tightly controlled boot process. In theory, UEFI provides flexibility and security features. In practice, it often does the opposite for users who wish to run free operating systems.

Secure Boot implementations, vendor keys, and opaque firmware updates can make it difficult — and in some cases impossible — to install or maintain a fully free system without accepting proprietary components. The complexity of the modern boot stack also increases the distance between the user and the machine’s initial state, making it harder to reason about what code is executed and when.

Boot managers layered on top of UEFI often inherit these problems. They add abstraction without restoring agency, and encourage a mindset in which the boot process is something to be worked around rather than understood.

This does not mean that UEFI systems cannot be used securely, nor that all users must abandon them. It does mean that they come with structural trade-offs that should be acknowledged honestly. For those who care about control, auditability, and long-term ownership, older hardware with free firmware support often provides a simpler and more comprehensible foundation.

Disk encryption as a default

A free system must also protect the data it contains. Disk encryption should not be treated as an optional feature or a convenience toggle, but as a default property of the system.

Encryption determines who can access your data when the machine is lost, stolen, or inspected. It also shapes how the system is booted, recovered, and maintained. These decisions cannot be cleanly separated from firmware and boot design; they are part of the same chain of responsibility.

For this reason, disk encryption must be considered early, not bolted on later.

Separating boot from data

One of the simplest ways to reduce complexity and increase clarity is to separate the boot medium from the encrypted system disk. Doing so limits what is present on the machine when it is powered off, reduces the attack surface, and forces explicit interaction at boot.

This approach also reinforces an important principle: the system does nothing unless you deliberately allow it to do so.

Most people will not have the threat model or necessity of having the boot medium removable. In most cases having the boot medium on the internal drive is fine; but you should lock the boot loader with a password either way.

I personally do not have the my boot medium on removable storage. I did when I was on a deep dive into OPSEC and system security.

What comes next

The next part of this series will move from foundations to implementation. I will describe how I install a minimal Artix Linux system with runit, encrypted using plain dm-crypt, and the reasoning behind those choices.

Later posts will cover the tooling I use, the tools I avoid, and how I maintain the system over time without drifting back toward unnecessary complexity.

Everything in this series builds on the foundations laid here. Without control over firmware, boot, and storage, the rest is largely cosmetic.