Hello. I’ve recently been using various Fedora-based systems, including those from the Universal Blue project. I must say, I’m quite surprised. While the concept itself seemed intriguing, in practice, I can’t understand who these systems are for. What’s the difference, for example, compared to Fedora 42 with KDE and Flatpaks as the primary installation source?
Firstly, they run incredibly sluggishly. Every operation comes with a significant delay. Secondly, at least three installation methods—Flatpaks, Homebrew, and layering—complicate the workflow. This, combined with the inability to deeply edit the system due to its “atomic” nature, makes working with it uncomfortable.
Please explain what advantage such an architecture has over installing Fedora from a netinstall image, then adding minimal KDE and Flatpaks for everything needed, and taking Btrfs snapshots? Functionally, you get the same thing, but compared to, say, Aurora, it runs like a dream and is simpler to manage: flatpak update, dnf5 upgrade, and that’s it. Because the base is minimal and the rest is from Flatpaks, system control is extensive, performance is significantly better, and there’s no bloatware.
So, please explain, who is this solution for? Because it will be too difficult for beginners, and a power users can set up whatever they want within Fedora and just roll back to a snapshot if there are problems.
You can familirise with the docs for Aurora/Bluefin which cover most of the stuff
If you prefer your system to be “the old way”, use Fedora Workstation / KDE Plasma.
But Atomic systems don’t mean you cannot tweak your system. Applications are meant to be installed as flatpaks (GUI apps), for terminal/cli apps we recommend homebrew. You can also create a distroboxes for other “distros” if you need apps from those, these allow you to install apps with dnf/apt/pacman etc. Layering apps is not recommended, unless totally necessary (for example vpn apps).
Your goal is to work primarily within your home directory and avoid modifying the root system. You include the necessary drivers, your chosen Desktop Environment (DE), and desired applications in your base image, and you don’t modify it thereafter. If you want to change your DE, you can create another image (for example, using recipes in BlueBuild) and try it by simply changing the rpm-ostree base. This approach helps prevent the accumulation of unnecessary files or configurations in your system, thereby reducing the likelihood of unexpected system crashes. I exclusively use Flatpaks and Distrobox, which I find sufficient for my needs.
Dependency mess - I install programs with a package manager - it pulls 1000 other programs (dependencies) with it. That’s all good, but then I choose to uninstall something - Is everything that’s not needed also removed ? (My experience from like 6 years ago, I might be wrong here.)
Traditional - Not all the time, there might be mess left behind.
Atomic - Everything is tracked and no mess is left.
Configuration mess - I need to fix an issue, so I configure stuff at multiple locations I didn’t even knew existed, being a new user - fix didn’t work, how do I revert ?
Traditional - I don’t know, but everything works, let’s leave it… Until one day this mess left behind breaks something and reinstalling the system will be much quicker than trying to figure out what I changed.
Atomic
/etc - Tracked, can be reverted.
RO directories such as /usr - Should not really be touched IMO, but if needed, tracked through git commits of my custom image, revertable.
Updates - A new shiny update came out, lets install it.
Traditional - Potential dependency issues, potential breakage, the last time I used a traditional distro, an update broke it at the worst time possible when I needed a working device. (Yes I shouldn’t have updated it at the time.)
Atomic - Dependency issues unlikely, breakage very unlikely. Can have automatic updates set up without worrying if it boots the next day.
I strongly believe that whenever it seems uncomfortable, it’s because Atomic tries to do a new thing on a legacy base. If everyone moved to Atomic and all the tooling adapted to it, there would be close to 0 usage issues.
