I’ve been running Tumbleweed for a few years now. It’s great, but it’s not 100% autopilot, updates often require manual intervention (resolving small problems) or updates try to add 50 packages I don’t need (recommends) all the time despite them not being in a pattern. I’ve been looking for a distro on which I could set up automatic updates and forget mostly about it, while still having recent packages; reliability and peace of mind while being on the bleeding edge. Due to having an NVIDIA GPU, LTS distros are a no-go. I’ve debated on the following
- Debian: packages too old, ideal for my server though.
- Ubuntu 24.04: Plasma 6 not available until next release. Snap is still a problem.
- Fedora/Ublue: DNF is painfully slow. Immutable variants are interesting but download full GBs worth of images
- Arch: insanely fast package manager, but can require manual intervention. Automatic updates aren’t recommended for arch. It also lacks my printer driver on the repos (only available on the AUR). One of the only distros that can truly satisfy my minimalist itch.
- KDE Neon: Snaps, no nvidia graphics
- NixOS: Never tried it but apparently the unusual file structure causes many problems
So I ended up trying again OpenSUSE Kalpa. I had completely forgotten about it, and I really like the concept. It’s like the Fedora immutable variants, but instead of downloading whole GBs of images, it creates BTRFS snapshots between normal zypper updates. So you can have the benefits of offline updates without having to wait at boot or at shutdown. Just like silverblue, the concept is to try to install everything through flatpak/distrobox and avoid adding anything unnecessary to the base, so that system updates can be snappy and unproblematic.
I was really tired of opening my laptop, updating everything and then rebooting. I just want to open my pc, have all updates automatically applied in the background through systemd units so that the next time I boot, I have an updated system. No “updating” during next boot. I finally found a distro perfect for me in that regard, and for everyone else who’s tired of babysitting their linux desktops, you should give a shot to Kalpa/Aeon.
Apart from the other comnent explaining the many benefits of rpm-ostree to transactional-update (apart from the horrendous name)
it creates BTRFS snapshots between normal zypper updates. So you can have the benefits of offline updates without having to wait at boot or at shutdown.
You are referring to standard Fedora here. Atomic variants have no offline update screen.
Also just having snapshots between updates means you cannot rebase to the updated AND vanilla variant.
You could make a BTRFS snapshot right after install and keep that from disappearing. But this means when you need to reset, you downgrade tons of packages wich always causes problems with config files etc.
Just like silverblue, the concept is to try to install everything through flatpak/distrobox and avoid adding anything unnecessary to the base, so that system updates can be snappy and unproblematic.
As said in the other comment, I dont think this is specific to Atomic Fedora. For sure the long rpm-ostree updates kinda enforce that (they get way longer when layering packages) but rpm-ostree is way more stable than for example Ubuntu APT or Fedora DNF. So I think you should use Flatpak and Distrobox on the traditional distros, while Atomic Fedora is actually less critical.
“Immutable” OpenSUSE is not any better than mutable OpenSUSE though, their package manager doesnt solve many problems with installing random RPMs to the base. So it needs Flatpaks etc more.
I was really tired of opening my laptop, updating everything and then rebooting. I just want to open my pc, have all updates automatically applied in the background through systemd units so that the next time I boot, I have an updated system. No “updating” during next boot.
This is all standard Fedora. Atomic Fedora updates in the background and reboots are as fast as normal ones.
But there are some issues with just updating automatically:
- using tons of data when connected to a phone hotspot
- updating on high system load, causing freezes
- updating on low battery
I wrote about this here and uBlue addresses these issues in their ublue-update
OpenSUSE doesnt mitigate this.
This is pretty complex and I wanted to write a post about it, will follow. In short:
Fedora Atomic uses
rpm-ostreefor managing all installed RPM packages. This is basically git for binaries, meaning your system is 100% the system that Fedora tests and pushes to their servers.Then you have the ability to add and remove RPM packages, which will be transparent (
rpm-ostree status) and reversible (rpm-ostree reset).This means
- you can modify the system and install or uninstall any RPM you want
- these changes will always be applied fresh to your system, meaning you will always start fresh and apply exactly them.
- this means the entropy (amount of randomness, how much your system diverges from their system) is very little and transparent. “I cant reproduce on my system” is gone
- you can switch (
rebase) ostree remotes, also with support for container images like uBlue uses. This means you can have various upstream configurations with different goals, like Aurora/Bluefin, Bazzite etc - you can still reset your system to 100% upstream, to make sure you have reproducible bugs, or to find a broken package
Most of these things are not possible on OpenSUSEs model. To my understanding they basically just use zypper but with BTRFS snapshots. So you normally update the system, but into a new snapshot to the updates dont affect the current one.
But there is no way to reset or rebase, this means from day 1 there is a chance that your system is not the same as upstream.
They try to tackle that by advising to not install any RPMs which is pretty hillarious. If you use a good RPM distribution model like rpm-ostree, installing or even removing packages is no problem because A: you see the changes transparently and B: you can always reset.
As good as their efforts may be, their reproducible builds, their services, their YaST etc. Their “immutable variants” are not the same and way worse.
You can also see that by the adoption of rpm-ostree I would say. OpenSUSE has microOS and Aeon, which dont share a common name and are separate projects. Kalpa, the KDE Plasma variant, is officially unmaintained.
Fedora has
- Atomic Desktops: GNOME, KDE, Sway, Budgy
- uBlue: Bluefin, Aurora, Bluefin-DX, Aurora-DX, Bazzite (and all its variants), dozens of base images for various hardware and desktops
- all the uBlue community images including secureblue
- coreOS and IOT, which are a bit different
- possibly future CentOS and RHEL adaption of the model
I wasnt aware of how bad this situation was actually.
It started by me asking in their forum “where do I need to place a repo to add external RPMs”?
Because on Atomic Fedora the
dnfrepo add command doesnt work, but the repos can be placed in the same dir and work the same. So I assumed this worked on “the OpenSUSE equivalent” the same.Instead of getting the needed answer (assuming that their model worked just as well as Fedoras) they told me
- installing RPMs causes random changes to the system that are not reversible (yes they are, on Fedora)
- installing RPMs is not supported, only Flatpaks (which dont support user namespace creation for process isolation in browsers, so not an option here)
- the only RPMs that should be installed are drivers etc. So they advise something they dont support, lol
- they supposedly hate Fedora?
I still dont know where such a repo would be placed, and why they would support installing RPMs on the “chaotic” traditional variants, while they dont on their “more stable” “immutable” variants.
Well yes I know. Because their model is not any better in solving the mentioned problems.
I mean, by logic, a better package manager should improve stability when installing system packages. You shouldnt need to install Flatpaks or Distrobox containers only on “immutable” distros, but especially on traditional, messy ones.
Because these traditional distros dont have measurements to revert the permanent changes that sometimes occur when installing, changing or upgrading packages.
If your OS is so unreliable that you only support installing Flatpak, then the package management is crap.
Speed of a package manager should never be a major concern nowadays. It’s not like you have to build packages from source slow. You install packages once, even if it takes minutes, just do something else. Updates happen in the background.
Same for huge updates. For one, are you sure it downloads the whole image? Downloading an update of fedora atomic is very fast on my device. Even then, games are huge, 4k movies are huge. An OS updates is small. I don’t care about that size. That is nothing of importance.
The real question is: image vs snapshot. What do you think about that question?
Snapshots are a lot more flexible. You can make any modifications to your system without issue. Layering packages on image based distros is slow and annoying, to the point UBlue OS was born out of that annoyance.
Speed of package managers did matter in my original search, because my workflow was to open my pc, update everything, reboot, start working. But with Kalpa snapshots, my updates are started in the background then silently and promptly applied on next reboot, I don’t even have to think about it. It’s like offline updates but without the wait.
Ublue does more
- hardware enablement with nonfree packages Fedora cannot ship
- experimental images
- opinionated configurations
I’m not that knowlegable why ublue was created in the first place but ublue has incredible advantages besides not having to layer packages. You can create your own custom distro and ship it to many comouters without major knowledge, time or effort. Can you do the same with opensuse’s?
Layering packages shall be annoying. As with other installs, you do it once. Because it’s annoying you do it only if it is important. You do not layer random malware downloaded from the internet. You shall not tinker with the system, that’s why it is immutable. If you want to tinker, use a traditional installation method, or simply use distrobox
Ublue is indeed fantastic tech, I don’t deny that. For my own purposes, I would have to spend too much time curating my own custom OS if I used it, so I prefer Kalpa.
This is due to the fact that Kalpa is a traditionally package-managed OS. On image based Atomic Fedora there is a base image, and the overlays are always added on top.
If these overlays are always the same, like ublues “hardware enablement” then it makes way more sense to use the base image and apply these changes once. Doing that workload once, minimizing randomness between users and doing unstable stuff like proprietary NVIDIA drivers, rpmfusion, custom kernels etc. on a single repo. The issues will occur there and can be fixed centrally.
The slow process it not ostree, but doing the changes on every update. But tbh when updates are automatic it doesnt matter than much anymore.
That sounds like a painful workflow.
Updating and rebooting before using is basically just paranoia. And Atomic Fedora now has automatic updates (by default, was just a settings switch before).
Note that automatic updates have many issues which ublue fixed in their ublue-update
@boredsquirrel @swooosh not having to reboot would make this finally useable to me!
Snapshots are a lot more flexible. You can make any modifications to your system without issue.
The issue is the lack of any versioning and control. It works “without issue” just as it works on traditional distros, it works until suddenly you have strange errors, devs tell you “I cant reproduce this here and btw modifying the base OS is not a supported use case” (it actually isnt) and as there is no way to revert the “issueless changes” you need to fix them manually or reinstall the OS.
Speed of a package manager should never be a major concern nowadays.
I would like to disagree with this. It’s not just updates. Sometimes I add and remove a bunch of packages back to back to test stuff out or check soft dependencies or pull/remove dependencies for projects I am checking out and compiling or switch between prepackaged/compiled versions. For example I was once testing the difference between wine and wine-stable-ubuntu in combination with winetricks installed/uninstalled. That is four configurations and you might visit each one more than once. I once saw a classmate use the fedora package manager in real life and I thought it was quite slow. I am happy with pacman, it really rips through packages which is convenient.
I am speaking of day to day use of a computer.
In your case it matters. it always matters if it’s the main task. even in your case you do the comparison once. And a task that is performed once, shouldn’t be the main focus. I wouldn’t use atomic for tinkering with the system.
That sounds like a usecase for distrobox or toolbx, and not something an average user would need to consider for choosing a distro
deleted by creator
Please tell me more about OpenSuse Kalpa/ Aeon/ MicroOS.
I’m a huge fan of Fedora Atomic, but find Suse interesting as well.
What are the differences between the two?
- Layering packages (rpm-ostree alternative?)
- Are updates still reproducible and atomic?
- What is the difference between Tumbleweed and Kalpa? You named snapshots. Are they different from Snapper?
- Can you rebase between Aeon and Kalpa?
- Why Suse and not Fedora?
As far as I understood their package manager is just zypper with enforced snapshots.
- It is not layering, it is just installing like regular. There is no base, no image, just the base packages that are managed traditionally. This will just add another package and there is no way to revert it
- Updates are atomic, but they are not reproducible, as there is no real base. You cant just use
rpm-ostree status, reset and install the layered packages, as there is no reset. There is no way to revert back to the currently shipped base OS. You can only revert back the snapshots that were created every update, so you could keep a snapshot of the fresh install, and that would be somewhat a reset, but reset to completely outdated packages, causing likely dotfile conflicts etc. - The OS is always atomic and snapshots are enforced, changes have to be made to the next deployment / BTRFS snapshot and the live base system is read only afaik.
- There is no rebase. And Kalpa is officially unmaintained. And there are no other variants than the 2 :/
- No idea
Thanks for your answer.
This may sound harsh, but I’m glad I’m on Fedora Atomic. Suse sounds a bit shitty/ not much better than the regular edition.
As
distrodesktop hopper, the ability to rebase to other spins is one major aspect of using Atomic, and I use it all the time.
Unfortunately I only have the last one: Because of the recent actions RedHat has been taking against OpenSource
I wish the technical aspects were better though
I agree with you, that the future of Desktop Linux are the atomic Distros. They are more stable and require less intervention, so they can be used more easily by less knowledgeable users and users who prefer a stable (in the non-breaking way, not no updates). Making Linux more accessible for new users, is exactly what Linux needs.
I disagree on your view about the Fedora atomic spins, especially universal blue. Who cares if the underlying OS downloads as one big image. It all happens in the background, you don’t notice that. Everytime you reboot, you are on an updated system.
Inefficient data usage is a problem. Network connections arent free, there are people using metered networks, or with really bad bandwidth.
I am really interested in improving this.
I dont agree with “atomic distros are the future” as in my eyes Fedoras approach is the only good one really (and even that has tons of issues, see here).
Some things need to be improved:
- flatpak runtimes share tons of packages but each gets downloaded individually, even though they may be deduplicated locally
- podman containers just for installing packages dont need a separate system, it would be perfectly fine if they would just use a symlinked or otherwise deduplicated base system.
- rpm-ostree has no delta update support, but afaik Fedora neither
So it may be worth the tradeoff for us both, but I definetly see a problem and I am also kinda tired of using podman containers for something they are not supposed to (system upgrades are impossible for example).
I want to experiment with the “linking all the system binaries to a podman container”, the flatpak stuff needs to be solved by them.
Out of interest, hsve you heard/read much about VanillaOS and their AB partition system, and if so what do you make of that compared to Fedora Atomic?
Yes I have. I think they do the same as OpenSUSE microOS basically.
The live system is immutable, when updating they clone it to the other partition and run regular apt in there. (Not sure about that but I think). Same issue as on OpenSUSE [whatever they want to call these variants].
It sounds like the thing Android is doing, but in detail it is way less secure. I only know of rollback prevention and signing, so an update needs to be an update and cannot downgrade components. This may not be available there but idk.
And the entire boot process on any Linux distro is extremely insecure compared to Android/GrapheneOS on a Pixel.
Their “apk package manager” is just a wrapper for Distrobox, not solving any fundamental problem. But Distrobox for sure is awesome for closing the gaps.
I think uBlue with homebrew is doing something more sustainable here though, as homebrew is independent, well maintained (cross OS!) and does not rely on having a separate OS run in parallel. So if you imagine Fedora would only supply base packages in some future, a project like homebrew could take care of the rest.
Also I couldnt even get the Debian version installed in a Qemu VM, same as with EndlessOS, so yeah so much about “alternative immutable distros”.
I disagree on your view about the Fedora atomic spins, especially universal blue. Who cares if the underlying OS downloads as one big image. It all happens in the background, you don’t notice that. Everytime you reboot, you are on an updated system.
Universal Blue co-maintainer here, this is a temporary situation, efficient downloads are coming, I’m actually at the Red Hat Summit and have been discussing things with the right engineering teams. This involves an intersection of podman, ostree maintainers etc. all aligning on it. It’s definitely a priority for them to fix this.
We’ve pushed pretty hard and pretty fast on the cloud native model, part of it was convincing people that this was a thing that users want, they hear us loud and clear now, it’s going to be an awesome year.
Thats great to hear! Boredsquirrel is right, the download size might not matter to me, but it’s important to improve for a lot of reasons, i can see that.
Edit: For other people reading this, this is a nice read related to the download sizes and what can be done.
On a side note: keep doing what you are doing. Your blog posts and the enthusiasm you displayed in your YouTube videos are what got me interested in universal blue in the first place.
