A split blue-and-orange tech scene contrasts successful device migration on the left with boxed transfers and storage on the right.
A September 22 column on How-To Geek argues that Linux newcomers should start with an immutable, or "atomic," distribution such as Fedora Silverblue or Bazzite instead of Ubuntu. The author spent a decade on Ubuntu. On an atomic system the core OS arrives as a complete, versioned image, and if an update goes wrong you boot the previous image. The documentation backs most of that case. Two parts need trimming: the idea that Ubuntu updates break often, and the idea that a read-only system core stops attackers from changing anything.

For a Windows user shopping for a second OS, or an admin looking after a few Linux desktops, the choice comes down to which kind of failure you'd rather deal with. Ubuntu's APT is fast and flexible, but it changes the running system in place. An atomic desktop protects its base and gives you a documented way back, and in return some tasks get slower and more awkward. That makes it a sensible default for many people, but it can't replace Ubuntu for everyone.

Fedora Atomic Desktops 44 treats the OS as one image​

The main example is Fedora's Atomic Desktops family. Fedora's project page lists release 44 as the latest. The Atomic Desktops special interest group describes the family as rpm-ostree-based versions of Fedora, one per desktop environment:

  • Silverblue ships GNOME.
  • Kinoite ships KDE Plasma.
  • Sway Atomic ships the Sway window manager and was formerly called Sericea.
  • Budgie Atomic ships Budgie and was formerly called Onyx.
  • COSMIC Atomic ships System76's COSMIC desktop.

The engine underneath is rpm-ostree. The project calls it a hybrid image/package system. It combines libostree as a base image format, and accepts RPM on both the client and server side, sharing code with the dnf project. Its features include transactional, background image-based (versioned/checksummed) upgrades. It also offers OS rollback that leaves user data alone. The project adds that today it is the underlying update mechanism of Fedora CoreOS as well as its derivative RHEL CoreOS. It is also used by Fedora IoT and Fedora Silverblue. Server and edge systems have run this design for years, so the desktop editions aren't an experiment.

Fedora's own description of Silverblue sets out the promise. The whole system updates at once, and Fedora says an update "will not apply if anything goes wrong." A previous version is always kept, and each update takes effect at the next reboot. You can keep working while the new image downloads and stages in the background. Graphical apps come as Flatpaks, which stay separate from the base system and have their own permission controls. Development tools go into Toolbx, a tool that creates OCI containers linked to your home directory and desktop. Fedora supports each Silverblue version for about 13 months.

"Immutable" describes how the base OS is managed. It doesn't mean every file on the disk is read-only. Your home directory, settings and app data stay writable, and exactly which areas are writable depends on the distribution.

Rollback in Silverblue is a documented procedure​

The strongest argument for atomic distros is recovery, and the tooling here is concrete. Fedora's Silverblue documentation explains that rpm-ostree keeps two deployments around, which both have an entry in the grub menu. When you boot, you can choose the other entry to boot into the previous deployment. A deployment is one bootable version of the system image. To permanently switch back to the previous deployment, use the rpm-ostree rollback command.

The basic commands are:

  1. rpm-ostree status lists your deployments and marks the one you booted.
  2. rpm-ostree upgrade --check looks for OS updates if you just want to check for available updates, without staging anything.
  3. rpm-ostree upgrade downloads and stages the new image. Due to the atomic nature of the OS, you will have to reboot into the new image to have the updates take effect.
  4. flatpak update updates your applications. They sit outside the OS image, so they're updated separately.
  5. If the new image misbehaves, pick the older entry in GRUB for a one-off boot, or run rpm-ostree rollback to make the previous deployment the default.

Major version upgrades use the same model under a different name. Fedora Magazine's April 2026 guide to moving to Fedora 44 shows the rebase command, rpm-ostree rebase fedora:fedora/44/x86_64/silverblue. First, though, it recommends pinning your current deployment with sudo ostree admin pin 0, so that this deployment will stay as an option in GRUB until you remove it. The old docs say just like system updates, rebases can be reversed: the previous deployment is still available, and you can boot back into it if there are any problems with the new OS.

On Ubuntu the nearest equivalent is holding packages back, booting an older kernel from GRUB, or restoring from backup. Those tools work, but none of them undoes everything a system upgrade changed in one step.

Where the rollback safety net has holes​

"Instant rollback" hides some limits. A rollback only works while an older deployment still exists. In a 2021 Fedora Discussion thread, a Silverblue user ran a cleanup command that removed the rollback deployment, then found out the newest build was broken. When he tried to go back, he got error: No rollback deployment found. The takeaway: pin a known-good deployment before any big change, and don't clean up old deployments until you've tested the new one.

Updates can also fail to finish. Comments on Fedora Magazine's Fedora 44 guide describe systems that keep rebooting into your previous Fedora Silverblue 43 deployment with a "failed to finalize previous deployment" error, caused by a conflict while merging configuration files in /etc. The fix posted there was to remove or rename a leftover /etc/ssl directory. In other words, the atomic model worked: the machine kept booting the old, working image instead of a half-upgraded one. The user still had to diagnose the fault, though. Fedora's claim that you "will always have a working computer" means you'll have something bootable. It doesn't promise that nothing will need fixing.

Bazzite's documentation adds a time limit. Rebasing to an older Bazzite build only works for builds from the last 90 days, and staying on an old build means going without security updates until you move back to a current branch. Rollback gets you out of a bad update. It isn't a way to stay on an old version.

Rolling back also restores the OS without touching your data. The rpm-ostree project describes OS rollback without affecting user data, which is what you want. It also means rollback won't recover a deleted document or a corrupted app profile, so you still need backups.

Ubuntu's APT is flexible, and the fair criticism is narrower​

The column says an interrupted upgrade, a broken PPA or a botched dependency chain can leave Ubuntu "genuinely inconsistent." That's possible, but the column makes it sound more common than it is.

Ubuntu's documentation calls APT ... the recommended way to install, remove and upgrade Debian packages. Its tools track the in-between states the column worries about. Aptitude's package list uses one status code for packages that are "half-configured" because configuration failed, and another for "half-installed" packages where removal failed. Both states exist because an interrupted package operation can leave the live system in need of repair.

Ubuntu's documentation also names the biggest real risk. It warns users to be careful with non-standard package sources, because some packages "could render your system unstable or non-functional in some respects." It also notes that Universe and Multiverse packages aren't officially supported and only get security patches through Ubuntu Pro's Expanded Security Maintenance. Pro is free for personal use on up to five machines. In practice, trouble on Ubuntu tends to come from third-party repositories and PPAs rather than from routine updates out of the main archive. The default for Ubuntu Server is to apply security updates automatically.

On the evidence, APT does change the running system in place, and atomic systems avoid that. Ubuntu has no built-in whole-system rollback like rpm-ostree's. Nothing here shows that normal Ubuntu updates are unreliable. You might switch because you want a recoverable base, not because Ubuntu is broken.

A read-only base narrows the attack surface without sealing it​

The column says the read-only root means "nothing — not a stray script, not a careless sudo command, not malware" can quietly rewrite core system files. That overstates it. A protected base does make it harder for a careless command or a misbehaving program to change system files while the machine runs. It does nothing for the things attackers usually want: your writable home directory, saved credentials, browser sessions, network services you've exposed, and whatever permissions you've granted to apps.

Flatpak sandboxing has the same limits. Flatpak's documentation says apps run in sandboxes with limited access by default. Access to files, the network, devices and system services depends on permissions and portals, which are system-provided dialogs such as file pickers. An app can be granted broad permissions, so "sandboxed" doesn't automatically mean isolated. Flatpak's documentation also says it isn't meant for some low-level software, including kernel modules and drivers.

The column says Ubuntu's Snap format "gestures at" similar sandboxing while the base OS stays mutable. The second half is accurate. No evidence reviewed here compares Snap and Flatpak isolation in detail, so treat them as two separate permission systems.

Bazzite and the cost of layered packages​

Atomic desktops ask for the most change when you need something in the base system: a kernel module, an unusual driver, a system service, or a low-level development tool. On Fedora Atomic you'd use package layering. rpm-ostree install adds an RPM on top of the image, and it only takes effect after a reboot.

Bazzite is a Fedora Atomic spin built for PC gaming, with desktop and handheld versions. Its documentation tells users to avoid layering when another option will do. Layered packages make updates slower, can clash with packages in the image, and can block upgrades until they're removed. Bazzite suggests a different place for each kind of software:

  • Most graphical applications should come from Flatpak.
  • Command-line tools can come from Homebrew.
  • Development environments and anything that needs a conventional package manager belong in containers.
  • Use rpm-ostree layering only when the software really has to be part of the host system.

If an upgrade gets stuck, rpm-ostree reset removes all layered packages and overrides. A community rpm-ostree cheat sheet calls this useful when an upgrade is wedged because of a layering conflict, and warns that layered drivers and kernel modules are particularly fragile across major version jumps. Anyone who depends on out-of-tree drivers should take that warning seriously. It's the clearest case where a traditional distro is still easier.

The column also names openSUSE Aeon and Kalpa, Universal Blue's Bluefin, NixOS, and Valve's SteamOS as examples of the same idea. openSUSE, Universal Blue and NixOS each have their own tools, and NixOS in particular uses a declarative model rather than rpm-ostree. The documentation reviewed here doesn't show SteamOS using Fedora's implementation, and SteamOS isn't Fedora-based. The practical advice above covers Fedora's Atomic Desktops and Bazzite. Check the others against their own project documentation.

What this means for you​

If you want a Linux desktop that recovers from bad updates and your software fits the Flatpak-and-containers model, an atomic desktop is a good place to start. If your work depends on custom kernel modules, drivers you compile yourself, or editing system files directly, stay on Ubuntu or another traditional distro for now. Before you install, make a list of your essential apps and drivers and check each one: is it on Flathub, will it run in a Toolbx container, or does it need to be layered? Anything that needs layering is where you'll feel the friction.

For admins with several machines, the base image is identical across installs, which removes much of the drift that builds up on long-lived APT systems. Machines can still differ in hardware, layered packages, image version and user configuration, so a reinstalled machine won't necessarily match the one it replaced.

  • Fedora Atomic Desktops 44 comes as Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic, and each version gets about 13 months of updates.
  • Run sudo ostree admin pin 0 before a major rebase so a known-good deployment can't be cleaned up.
  • If a new image misbehaves, choose the previous entry in GRUB for a one-off boot, or run rpm-ostree rollback to make it the default.
  • Keep layered packages to a minimum. They slow updates and can block upgrades, and rpm-ostree reset removes them if an upgrade gets stuck.
  • Keep backing up your data. Rollback restores the OS, not your files, and Bazzite limits rebasing to builds from the last 90 days.

The How-To Geek column gets the main point right. For the many people whose computing happens in a browser, desktop apps and games, a versioned, rollback-capable base is a better starting point than a system that's patched in place, and Fedora has spent years proving the tooling on CoreOS and IoT before bringing it to desktops. The guarantees are narrower than "nothing can break," though, and the exceptions (driver-dependent hardware, kernel-level work) are real. As more projects adopt this model, Ubuntu stops being the automatic answer to "which Linux should I install first?"

 

Click to expand...
You must log in or register to reply here.