Upstream images vs bazzite: https://github.com/ublue-os/countme/blob/main/growth_upstream_with_bazzite.svg
My prediction: bazzite may have more installs than Fedora KDE by the end of the year.
Upstream images vs bazzite: https://github.com/ublue-os/countme/blob/main/growth_upstream_with_bazzite.svg
My prediction: bazzite may have more installs than Fedora KDE by the end of the year.
Run an update on a traditional system, and pull the power plug out when it’s half way through. If it recovers when you reboot it, you got pretty lucky.
Now do the same with an immutable system like Bazzite. It will be running the pre-update image when you reboot it. No harm done. It’s essentially impossible for an update (or even a failed update) to brick the system. You can always roll back to the last working image.
CachyOS does this just fine with bootable BTRFS snapshots before and after each update, without forcing me to use Flatpaks that don’t support all of the features of the normal apps or else break the immutability. For example, it’s not possible to get all Discord features working in Flatpak (even with tinkering) due to inherent limitations of Flatpak.
The real problem is config drift. You have to maintain a lot of little fixes over time as you operate vanilla Linux. I’ve run fedora atomic (and rebased to bazzite when it got fairly big) since it launched years ago with only one relatively minor hiccup that was resolved by a single line in terminal (rpm-ostree rebase). You can layer stuff over it to modify the base image and clear it if something breaks, whereas manually removing critical packages and being sure to clear every file would be a nightmare on any other distro. It’s an extremely hands off experience that works just like git does and is very bullet proof and reproducible.
I like putting it on old people’s computers. It’s perfect for a seamless experience.
Yeah, a file system snapshot is another way of achieving safe upgrades. There are upsides and downsides of all approaches though.
Rolling back to a btrfs snapshot might be harder than just picking the other ostree image in GRUB. And you still have the problem where old binaries might be running when only the new binaries/libraries exist on disk. But it also saves space on disk compared to an immutable distro, and it’s much easier to make changes to system files. Every approach is a compromise.
Yeah rolling back snapshots is way more annoying than ostree and is kinda a shotgun solution. Also ostree saves more disk space.
I see, that is a really nice feature! No idea why this is not something already safely handled my normal package managers.
It’s cause of the way an immutable system works. In an immutable system, the entire system is an image. Two are stored on disk. One is active, and the other is usually the previous image. When you update, it overwrites the old image. The current image stays untouched. It’s only once the new image is completely written to disk that it’s marked as the current image.
Package managers are working on the currently running system. They write over the only set of system files, and they can only do that one file at a time, so you can rely on the file system’s journal to make sure each file is correctly written, but there’s nothing preventing the system from being only half updated. If a package relies on a package that hasn’t been installed yet, and the update fails before it gets installed, that package is broken.
In a system like Ubuntu or Fedora, that’s mostly ok, because packages are always built for the kernel and library versions available throughout the lifecycle of the release. So a half updated system is probably fine and will continue the update when rebooted. But for rolling releases like Arch, or for a release upgrade like Ubuntu 25.10 to Ubuntu 26.04, a failed update might mean a broken system.
It’s the kind of thing they should have developed to release-ready state 20 years ago - when hard drives were already absurdly large vs needs of the OS and data.
That did happen btw! The project is called the android open source project