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.
Bazzite is awesome. Not surprised it’s so successful. Congrats to the team. :)
While I see value in something as NixOs for the reproducibility. I do not understand what is the value in having an immutable system. I’m not saying there’s no value, I just can not imagine a use case in which it is better than a normal system.
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.
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.
I like Bazzite because it has a bunch of optimisations for getting games runnin well, and because it disallows applications screwing with the system. If I really need an application that demands it’s files be put in a bunch of places I can’t audit easily, it can go in a toolbox and not impact the system, or I can audit exactly what it does and layer it into the system.
For a Linux newbie, I really appreciate a system that stays what it is, and doesn’t let anything change that without my explicit approval.
It protects against system breakage and malware because the core of the OS is sealed and updates can only fully complete or fully fail, you can’t have a half-uodated system like Ubuntu would be if you unplugged the PC half way through.
And because your apps and commandline tools are sandboxed with Flatpak and toolbox/distrobox so malware getting in through one doesn’t compromise the whole system.
So does iOS, but it’s ‘bad’ to be walled garden there, but ‘good’ to be walled garden here.
iOS is a walled garden because they do everything they can to block third party app stores, and the “activation” process allows Apple to remotely brick your phone at any time. Immutable Linux distros don’t have these issues.
I tried bazzite and kinoite and they are great. Unfortunately I don’t have a souped up gaming pc and I found them a little on the slow side compared to other distros… I’ve been using NixOS for a couple of months and I am loving it. The system is responsive, the boot time is half that of bazzite and while perhaps it isn’t ideal for someone’s very first distro it also isn’t that complicated, if I can figure it out 90% of other users could. I have all my old windows games working and my old hybrid Nvidia card chugging along nicely.
I can’t tell you how many times I’ve had an update on a mutable system fuck my shit up to a point I just reinstalled the distro. Not having to worry about that is my primary reason for moving to immutable system. While malware and viruses are still mostly prevalent in the windows world, Linux isn’t immune to it. That is, unless it’s an immutable distro.
I had that happen many times, but that was on arch. On other distributions getting updates which break the system is quite rare in my experience.
How does an immutable distribution make the system immune to virus? I’d imagine flatpak can have upstream attacks as well as opening stuff in vulnerable software. You still have access to all your personal files, which is likely what the malware will go after.
its a container image with a kernel. the whole idea is reproducibility.
“immutability” doesnt really make sense it the context of the container. like, if you want to change the image, just make a new one with whatever changes you want and boot that.
in my opinion, it doesn’t make sense to change the whole base OS image just to install some random package or program. keep that in the user writable domain, or userspace. not in the base OS image.
It’s better to think about it as though you are making a queue of changes that need approval to be permanent. Rather than just accepting that you just installed a ton of dependencies for no reason because you didn’t really want the software, you can cleanly reverse any of the changes.
In a sense, it accomplishes a similar thing as nix in a different way.
its even better to just think of it as a container image.
I swapped to it in May from Endeavour OS as I happened to be doing a clean install, and 90% of my PC usage nowadays is gaming, and I have never looked back, even though I thought Endeavour OS would have been the end of my Distro hopping.