Context
This section covers de details of this project’s context. Some information have already provided in the introduction, but this page covers it all using a more formal method I like a lot: QQOQCP.
What am I building?
Linux distribution
My dream Linux distribution has the following features:
- Binary package downloads available – I do not have time to build an entire OS locally 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.
- Decent security – RootFS encryption is a bare minimum, but features such as sysctl, SELinux, sandboxing, and Secure Boot could be interesting to try out. For now, the result must mirror my daily use cases and security requirements; I plan to handle hardening as a separate, later project.
- 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 (Portage package sets?).
OS Factory
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. Below is a brief functional description of what I consider implementing.
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
Package “assembly line”:
- Portage mirror for ebuilds
- Homemade compilation pipeline
- Publicly available, binary repository
Update mechanism:
- Filesystem archive (or ISO) download and verification
- Local and modern update system using systemd-sysupdate or a similar solution
- A rollback mechanism to recover in case of failed updates, whithout overwriting manually installed packages and configurations
Who are the targeted users?
Me, myself and I. Nobody else is supposed to need my distro. The only part of this project I deem worthy of sharing is the source code and documentation, so that people can understand it, and try the product for themselves.
Where, when and how is the product used?
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. 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. This means that the factory would not need to be running often. Naturally, I want to have a way of managing the factory as a whole, so I must add a user management solution.
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 solve the few issues I mentioned in the introduction regarding my current distro installations.