Context
This section covers contextual elements regarding this Linux distribution project. Some information has already been provided in the introduction, but this page covers it all using a more formal method I like a lot: QQOQCP.
What am I building?
A custom Linux distribution
I am creating my own Linux distribution with the following features:
- Binary package downloads available – I do not want to build an entire OS locally on my laptop with every update.
- Quick first-time installation using a guided installer – Installing Linux by hand is a lot of fun, but it can get redundant over time.
- Plug-and-play “distribution” kernel – I love manual configuration, golfing, and compilation, but having a kernel that does not require tweaks for every new device is relaxing.
- Simple security – Full-disk encryption is a must, a small firewall is easy to add.
For now, the result must mirror my daily use case and security requirements. Further desirable additions include:
- An update mechanism with rollbacks, at least for major upgrades like kernel major version jumps (e.g. LTS 6.6 to 6.12). However, I will have to choose how to allow installing packages without breaking them on updates.
- Improved security (SELinux, proper sandboxing).
A factory in my homelab
Although this sounds like a lot of trouble for very little return, I want to build an ISO ahead of time using my own “factory” and “package assembly line” automatically. It is the idea that made me start working on this project in the first place, as an “excuse” to start a homelab experiment. Below is a brief functional description of what I intend to implement.
Package “assembly line”:
- Portage mirror for ebuilds (this counts as a solution, not a requirement)
- Homemade compilation pipeline
- Publicly available repositories for binaries and ISOs
ISO generation:
- Versioned as-code operating system description in a self-hosted forge
- Automated installation media creation with CI/CD pipelines
- Testing mechanisms to ensure everything went right before uploading the ISO
Update mechanism (secundary):
- Filesystem archive (or ISO) download and verification
- Local and modern update system using systemd-sysupdate or a similar solution
- A backup mechanism to recover in case of failed updates, whithout overwriting manually installed packages and configurations
A Linux lab platform
The very first implementation of my distribution will actually serve as a base for later experiments. This consideration will allow me to create several spins of the distro, e.g. a hardened version, one for servers, one for VMs, etc.
A comprehensive documentation
Last, but not least, I plan to document my choices and the lessons this endeavour teaches me. All content will be published as wiki pages, project management documents, Codeberg issues, and blog post available from this very website.
Who are the targeted users?
Me, myself and I (for now). The distro is actually an excuse to learn network infrastructure, CI/CD, Linux hardening, etc. Ideally, I wish to run the end result as a daily driver on my laptop and other machines.
Although my use case is straightforward and mundane, I still need a little extra in terms of ergonomics
Where, when and how is the product used?
Use cases
RadishOS is meant for my laptop and desktop computers. It should cover my daily use cases, such as web browsing, document editing, gaming, development, messing around with configs and packages, etc. I plan to use it like any regular OS and install it from an ISO image on a bootable thumb drive.
Administration
The OS itself should allow for weekly package updates, which means that the binary package host should follow this pace. In case a bigger update would be needed, I would like to perform it every month, implying that the factory would not need to run frequently.
Ergonomics
One important thing to mention is my need for additional keyboard layouts, as I use Colemak-DH almost all the time; with custom additions at that (see my dotfiles).
Hardening
Lastly, I have never hardened my desktop Linux beyong encrypting the disk and using a firewall (UFW), and my current use case does not compell me to harden it more. Therefore, only full disk encryption and firewall protection are considered necessary.
Why am I building this?
Finally, here is a list of reasons why I am undertaking this project:
- for fun;
- to get a good grasp of topics related to Linux, hardening, network infrastructure, and more;
- to start a homelab