I’m currently delving deeper into Fedora Silverblue and Fedora CoreOS, both of which utilize rpm-ostree for atomic updates. As part of my learning journey, I’ve come across openSUSE’s transactional-update tool, which appears to serve a similar purpose, but for their MicroOS and Kubic distributions.
I understand that both rpm-ostree and transactional-update aim to provide atomic, reliable updates and utilize an approach where a new system snapshot/version is created for each update. However, I’m interested in understanding more about the specific differences between these two technologies from a Fedora perspective.
How does the implementation of atomic updates differ between the two?
Are there specific features or benefits of rpm-ostree that make it uniquely suited to Fedora’s approach, particularly in the context of Silverblue and CoreOS?
Are there lessons or inspirations that rpm-ostree could take from the approach used in transactional-update or vice versa?
I’d greatly appreciate any insights or resources that can help shed light on these questions. My aim is not to compare which one is better but to gain a deeper understanding of the unique design philosophies and implementation choices behind these technologies.
Conceptually transactional-update creates a new snapshot with btrfs before performing any update and uses that snapshot for modifications. Since btrfs snapshots contain only the difference between two versions and thus are usually very small, updates done with transactional-update are very space efficient. This also means several snapshots can be installed at the same time without a problem.
Hi Timothée, thanks for clarifying those key differences. However, I’m intrigued as to why Fedora decided on rpm-ostree’s approach over a btrfs’ snapshot-based system like openSUSE’s. Were there specific technical reasons or use cases behind this? Open to insights from the community on this.
rpm-ostree works with any filesystem. Btrfs snapshots obviously require you to use Btrfs.
The main difference in the approach is that with rpm-ostree you have a pre-built image and you can thus see the difference between it and the local changes on your system. It’s easier to make sure that all your systems are running the same bits and have the same config.
The disadvantage is that you have to build those images and decide which packages should be included in them, or pick the ones that are built in Fedora and accept the choice of packages, whereas with transactional updates you can use any combination of RPMs.
To be honest, I am ok with that, the concept of layered packages works for me, the only challenge I haven’t overcome is WiFi broadcom driver for my old MacBook Pro. But that wouldn’t be an issue if I managed to find a laptop with preinstalled Silverblue, or at least make it work on linux-friendly model such as Dell XPS 13. Thanks for your insights!
You can find a list of Linux/Fedora friendly hardware here:
Some of the vendors allow you to choose the OS, the laptop is delivered
with. I’m not sure Silverblue is an option. But the hardware should work
well with Silverblue.
Aye, this is basically correct about transactional-update.
We are based on openSUSE Tumbleweed, which is a rolling release, and we get a fresh “image” basically every 24 hours (in a perfect world, sometimes theres a lag if we have something fail in openQA or elsewhere).
So there is no “fixed” base image in openSUSE Aeon/Kalpa/MicroOS. As @siosm said, that does mean we don’t have an easy way to compare what the user may have installed, versus the “pre-built” image like Silverblue/CoreOS do. We also don’t have the concept of layering, like Fedora does.
If you decide to install rpm’s that aren’t included in the base install, you’re quite literally modifying the base system, which is fine 99.9% of the time if you’re just pulling packages from Tumbleweeds official repositories. But it can become a broken mess if you’re the sort of user that really leans heavily on third-party repositories like RPMFusion or Packman. We leverage flatpak/flathub and distrobox to a greater extent than Silverblue/MicroOS do.
If you’ve got any specific questions, I’d be glad to answer them.
The first two of those cases there are pretty easy on an rpm-ostree system. Just use sudo rpm-ostree override replace foo.rpm to replace any base layer package.
I’m not really sure what use case the third bullet point is describing so don’t know if I can speak to that one.
Aye, don’t have to get into building images, or any additional infrastructure or tooling, with the way we use btrfs snapshots and transactional-update with our stuff on openSUSE. Which can make it a bit more flexible than the image based setup of rpm-ostree I don’t honestly have any real opinion on whether either approach to the issue is “better” I just think they’re different.
I’ve not actually looked into VanillaOS, or the other offerings out there, but I believe they’re leveraging snapshots in a similar way that we do with the MicroOS based products.
@sfaulken yes, no rating here. The one has more freedom and flexibility (and thus maybe also more sustainability), the other is simply image-based, with the pros and cons of that
The rebasing and reset features of the Fedora Atomic spins are neat, I gotta admit. And not something that is achieved nearly as easily with other systems.
A/B root only has A and B so pinning wouldnt be possible, afaik. You just have 2 versions.
Rebase would be nice, and should be possible. The issue is mixing the mutable state of the current system (like /etc in OSTree, see this issue) with the upstream image.
That should not be that big of an issue though.
Rollback is no issue or course. You simply just have one rollback chance.