Fedora 42 verscheen op 15 april 2025 en bracht een stilletjes ingrijpende verandering mee voor Silverblue: composefs is nu standaard ingeschakeld, GNOME 48 vervangt de vertrouwde 46, en de eerste concrete stappen richting Bootable Containers zijn gezet. Geen grote fanfares, geen rebrand — maar wie Silverblue de afgelopen twee jaar dagelijks gebruikt, voelt dat het systeem volwassener is geworden. Minder scherpe randjes, betere integratie, en een duidelijker pad naar de toekomst.

Die toekomst heet bootc. Dat klinkt abstract, maar het betekent concreet dat je Linux-systeem straks wordt beheerd als een gewone OCI-containerimage — dezelfde tooling die je kent van Docker en Podman. Voor nu is rpm-ostree nog de dagelijkse werkvloer. Maar het ecosysteem verschuift, en Silverblue staat midden in die verschuiving.

Wat Silverblue anders maakt

Als je gewend bent aan Ubuntu of Fedora Workstation, is het verstandig eerst het mentale model te begrijpen voordat je aan Silverblue begint. Het systeem werkt op basis van atomaire updates via OSTree: de volledige /usr-partitie is read-only, updates worden als een nieuwe snapshot naast de huidige deployment geplaatst, en pas na een reboot schakel je over. Gaat er iets mis, dan zit de vorige staat gewoon in GRUB — één keuze verderop.

In Fedora 42 is daar iets bovenop gekomen: composefs als standaard bestandssysteem voor de immutable rootpartitie. Composefs voegt integriteitsverificatie toe — elke file heeft een cryptografische hash. Dat is relevant voor systemen die op afstand worden beheerd of gevoelige workloads draaien, maar ook op een gewone desktop is het een extra laag zekerheid: een kwaadaardig pakket kan de base image niet stiekem aanpassen.

Wat blijft: je home-directory is volledig beschrijfbaar, Flatpak-apps installeer je zoals altijd, en voor uitzonderlijke gevallen met RPM's gebruik je package layering:

rpm-ostree install vim-enhanced

Die pakketten worden "ingelagen" bovenop de base image en zijn actief na de volgende reboot. Wil je zien wat je hebt ingeladen, dan geeft dit een overzicht:

rpm-ostree status

De output toont de actieve en de vorige deployment, inclusief welke extra pakketten aanwezig zijn, de commit-hash van de base image, en het tijdstip van de laatste update.

Dagelijks gebruik na twee jaar

De eerlijke beoordeling van Silverblue als dagelijks systeem is genuanceerder dan "gewoon Fedora maar immutable". In 2023 voelde het nog als een puzzel: welke app leende zich voor een Flatpak, welke moest echt als rpm-ostree layer, en wat moest je toch maar in een container stoppen? Twee jaar later is die puzzel grotendeels opgelost — niet door Silverblue dat soepeler is geworden, maar doordat het Flatpak-ecosysteem voldoende is uitgegroeid.

Op Flathub vind je Firefox, LibreOffice, GIMP, Inkscape, Obsidian, VS Code, Signal, Spotify en nog tientallen andere dagelijkse toepassingen. De meeste werken goed in de Flatpak-sandbox, al zijn er randgevallen: integratie met systeemthema's is soms slordiger dan bij native pakketten, en apps die toegang verwachten tot systeemdirectory's buiten je home-map hebben extra Flatpak-permissies nodig. Daarvoor is Flatseal je beste vriend — een Flatpak-app die toestemmingen grafisch beheert:

flatpak install flathub com.github.tchx84.Flatseal

Updates verlopen in Silverblue anders dan je gewend bent. Je draait rpm-ostree upgrade of laat GNOME Software het automatisch doen op de achtergrond — het nieuwe image wordt gedownload terwijl je werkt, en actief na de volgende reboot. Die reboot duurt bewust wat langer dan normaal de eerste keer, want de nieuwe deployment wordt op dat moment opgebouwd. Eenmaal actief: naadloos. Wil je een rollback?

rpm-ostree rollback

Dan ben je met één commando terug op de vorige staat. In twee jaar dagelijks gebruik heb ik dat drie keer nodig gehad — één keer voor een kernelregressie die mijn Wacom-tablet tijdelijk kapotmaakte, en twee keer na een GNOME-update die iets brak in mijn extensies. Telkens werkte de rollback in minder dan vijf minuten.

GNOME 48 in Fedora 42 brengt een bijgewerkte Wellbeing-functie met schermtijdbeheer, verbeterde notificatiegroepering en een verfijnde dynamische achtergronden-engine. Voor dagelijks gebruik is het een rustige release — de verbeteringen zitten in de details. De Wayland-integratie is opnieuw wat verder aangescherpt, wat merkbaar is in minder tearing bij snelle vensteroperaties.

Development in toolbox en distrobox

Voor developers is de grote vraag: hoe ga je om met een read-only systeem als je compilers, runtimes, taalversies en buildtools nodig hebt die constant wisselen per project? Het antwoord van Silverblue is Toolbox, en het alternatief dat veel developers verkiezen: Distrobox.

Toolbox is ingebakken in Silverblue en maakt rootless Podman-containers aan die je home-directory mounten en volledig integreren met de host — je shell, je SSH-keys, je Git-config zijn allemaal beschikbaar. Een standaard Fedora 42 toolbox maak je aan met:

toolbox create --image registry.fedoraproject.org/fedora-toolbox:42

En je stapt erin met:

toolbox enter

Binnenin kun je gewoon dnf install gcc python3-pip nodejs draaien alsof het een normale Fedora is. Je bestanden in ~ zijn direct beschikbaar. Sluit je de container, dan is de base image precies zoals je hem achterliet.

Distrobox gaat verder: het ondersteunt niet alleen Fedora-containers maar ook Ubuntu, Arch, openSUSE en meer — handig als je een specifieke .deb-dependency hebt die niet als Fedora RPM beschikbaar is. Installatie:

rpm-ostree install distrobox

Een Ubuntu 24.04-container aanmaken gaat zo:

distrobox create --name ubuntu-dev --image ubuntu:24.04

Met distrobox-export exporteer je applicaties of CLI-tools naar de host zodat ze beschikbaar zijn alsof ze native geïnstalleerd zijn. Een workflow die in de praktijk goed werkt: een projectgebonden container per client of taal, gekoppeld aan een alias in .bashrc. Je IDE — VS Code als Flatpak op de host — gebruikt via de Dev Containers-extensie diezelfde containers als buildomgeving.

Het vergt een initiële investering om te wennen aan dit model. Maar als het eenmaal zit, is het robuuster dan een traditionele workstation-setup: je host blijft schoon, iedere container is reproduceerbaar, en je kan een container met een defecte afhankelijkheid gewoon weggooien en opnieuw aanmaken zonder dat de rest van je systeem aangeraakt wordt.

Bootable Containers: de volgende stap

De langetermijnrichting van Silverblue — en van de hele Fedora Atomic-familie — is bootc: het beheren van je besturingssysteem als een OCI-containerimage. Dat klinkt als een krachtige abstractie, en dat is het ook.

In de praktijk betekent het dat een Silverblue-achtig systeem straks wordt gebouwd met een gewone Containerfile en gepusht naar een container registry. Een machine trekt die image binnen via bootc switch en reboots in de nieuwe staat. Rollback werkt identiek aan nu, maar de tooling is de vertrouwde container-tooling. Bazzite — de populaire gaming-variant gebouwd op Kinoite, de KDE-tegenhanger van Silverblue — werkt al op dit model: het is letterlijk een OCI-image, gebouwd via GitHub Actions, en te volgen als ghcr.io/ublue-os/bazzite:stable.

Voor Silverblue zelf is dit nog toekomstmuziek in Fedora 42. rpm-ostree blijft volledig ondersteund en gaat nog jaren mee. Maar de ontwikkelaarsfocus verschuift: nieuwe features landen in bootc en dnf, niet in rpm-ostree. Wie vandaag met Silverblue begint, bouwt al in de goede richting — het mentale model van atomaire images en containers is hetzelfde, alleen de toollaag verandert.

Een concrete test met bootc in Fedora 42:

rpm-ostree rebase ostree-image-signed:docker://quay.io/fedora/fedora-silverblue:42

Dat commando rebased je bestaande installatie naar de officiële containerimage-gebaseerde variant. Niet noodzakelijk voor dagelijks gebruik, maar illustratief voor waar het naartoe gaat.

Waar Silverblue zinloos is

Eerlijkheid over de beperkingen is minstens even belangrijk als enthousiasme over de sterke punten.

Snelle systeemtinkering. Als je iemand bent die dagelijks packages installeert en verwijdert om dingen uit te proberen, is Silverblue frustrerend traag. Elke rpm-ostree operatie vereist een reboot om actief te worden. Je kan dit deels omzeilen met toolbox of distrobox, maar de mentale overhead is reëel.

Oudere hardware met obscure driverbehoeften. Als je een network card hebt die een sterk aangepaste kernelmodule vereist, loop je snel vast. Out-of-tree kernel modules inladen op een immutable systeem kan — via rpm-ostree install kmod-<naam> — maar het is omslachtig en elke kernel update kan de module invalideren.

Enterprise-omgevingen met maatwerk RPM's. Als je organisatie intern gebouwde RPM-pakketten distribueert en verwacht dat medewerkers die direct installeren, past Silverblue slecht in die workflow. De package-layering werkt technisch, maar is niet ontworpen voor die use case.

Beginners zonder Linux-achtergrond. Silverblue is niet de distro voor iemand die net van Windows overstapt. De Flatpak-first filosofie is begrijpelijk als je het concept kent, maar totaal verwarrend als je gewend bent aan "gewoon iets downloaden en installeren". GNOME Software verbergt veel complexiteit, maar zodra je buiten die UI stapt, kom je al snel in CLI-territorium terecht dat uitleg behoeft.

Voor wie het wél werkt: developers die een schoon host-systeem willen combineren met gefragmenteerde toolchains in containers; sysadmins die een reproduceerbaar desktopimage willen beheren voor meerdere machines; of gewoon iemand die genoeg heeft van "mijn systeem werkt niet meer na de laatste update" en bereid is het model te leren.

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo