Hello Fedora Community,
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.
Thank you in advance for your time and knowledge!
rpm-ostree pulls down a pre-built ostree image and then optionally applies some changes to it locally:
It combines libostree as a base image format, and accepts RPM on both the client and server side
openSUSE transactional updates do not use pre-built images but operate with btrfs snapshots.
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.