Atomic Linux Distributions

Approaches to Immutability

Different distributions achieve "immutability" using distinct underlying architecture and tooling.

The "Git/Container" Model (OSTree / OCI)
- Examples: Fedora Atomic, Universal Blue.
- Tooling: rpm-ostree, bootc.
- Mechanism: Treats the OS as a versioned repository or container image. Updates are fetched as file deltas or image layers and deployed to a new "deployment" directory on the same partition using hardlinks.
- Key Trait: Centralized "DevOps" management; allows rebasing the entire OS to a different image/fork.
The "Snapshot" Model (Btrfs)
- Examples: openSUSE Aeon (MicroOS).
- Tooling: transactional-update.
- Mechanism: Wraps standard package management. It creates a new read-write Btrfs snapshot of the current root, installs packages into it via zypper, and sets it as the default boot target.
- Key Trait: Retains standard package management granularity but enforces a "reboot-to-apply" workflow.
The "A/B Partition" Model
- Examples: Vanilla OS, Android, ChromeOS.
- Tooling: ABRoot.
- Mechanism: Uses two completely separate physical root partitions (Slot A and Slot B). Updates are written to the inactive partition (via OCI sync or package manager) which is then toggled active for the next boot.
- Key Trait: Maximum isolation. A failed update or filesystem corruption on the inactive slot has physically zero impact on the running system, at the cost of higher storage usage.

Bootable Containers: The OS is delivered as a standard OCI container image.
Kernel Management: The kernel is a package inside the container image. It is version-locked to the userspace.
Storage Model: Uses a single physical partition with "Deployments" (snapshots) sharing space via hardlinks (OSTree). It does not use A/B physical partitions (unlike Android or VanillaOS).

Fedora Atomic (e.g. Silverblue):
- Uses Classic OSTree (Git-like file deltas) by default.
- Constraint: Cannot ship proprietary drivers (NVIDIA) or codecs due to Red Hat legal/philosophical policies.
Universal Blue:
- Builds on top of Fedora using GitHub Actions.
- Mechanism: Wraps Fedora content into OCI images.
- Bypass: Uses GitHub infrastructure to inject proprietary drivers/codecs that Fedora can't ship.

Tool	Role	Notes
`rpm-ostree`	Legacy Client + Build Tool	Uses `ostree-rs-ext` to translate OCI layers into OSTree commits on disk. Still used inside Containerfiles to install packages.
`bootc`	Modern Client	The future standard. Treats the container registry as the single source of truth.

Directory	State	Behavior on Update
`/usr`	Read-Only	Completely replaced by the new image content.
`/var`	Read-Write	Preserved (Logs, Docker images, libvirt).
`/home`	Read-Write	Preserved.
`/etc`	Read-Write	3-Way Merge: Compares (1) Old Default, (2) New Default, (3) User Edits. Tries to merge; user edits take precedence.

You can switch entire OS flavors (e.g., Desktop to Gaming) by changing the image source.

# Example: Switch to Bazzite (SteamOS clone)
bootc switch ghcr.io/ublue-os/bazzite:latest

Risk: /home config clutter. Switching Desktop Environments (e.g., GNOME to KDE) can cause theming/config conflicts in dotfiles.

Workflow: Define OS in recipe.yml (YAML) GitHub Actions builds image Device pulls updates from GHCR.
Benefit: Pre-install tools (Terraform, UV, Neovim) in the base image rather than layering them locally.

Rollback: The previous OS version is always available in the GRUB menu.
Pinning: ostree admin pin 0 ensures a specific working deployment is never garbage collected.
Critical Failure: Since deployments share a partition, filesystem corruption (superblock) kills all deployments. Requires Live USB recovery.