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.
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.
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.
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.
Immutable means: every time you power it on, it’s the same.
So, if you get infected by a virus, power cycle and it’s like it never happened.
That, like everything you read on the internet, is a gross oversimplification, caveats apply, etc. etc. but for the most part, that’s what immutable means: the running system has no ability to persist changes (except in very specific, controlled, secure, easier to protect circumstances…)
I guess a virus can, and often does, live in plain data. Moreover, can you not have scripts and executables in your personal directory? Can you not schedule a cronjob or a systemd service?
Everything is possible. The point of immutability is the ability to restore to “factory fresh” state with a power cycle.
In theory, the data section is treated as data only, not executable. Software (games) can, and will, improperly store and execute code there, but at least they can be identified when they do and disabled/removed without breaking the underlying system.
A htpc in which you just need to launch media
A steam Deck like handheld in which you just want your game launcher
A PC for a kid whom you don’t want messing around with system files
A PC for your technologically inept family members to just use as an email/browser/word processor
I still miss the advantages for these cases.
I can understand the kid example, but I feel that’s easily solved by not giving them root access.
Setup the system and install whatever media software. Update it every once in a while or setup auto updates. I do not see any difference between traditional os and immutable. You’re likely not modifying any system files anyway.
The producing company controls software and updates, it should be immutable anyway as users likely do not have root access. Were users to have root access this may make sense. I’m not sure, maybe the immutability would make updates easier for the company?
Are they really going to brick their system? That would require opening the terminal. But I mean, fair.
What I do not understand is why there are users swearing by bazzite and other immutable distributions. These examples you make is basically for users who just do the most basic operations with their systems. Fair, if this makes it easier for non technical people to use Linux I’m all for it. What I do not understand is why technically adept people are so excited for these kinds of distributions?
Root vs non-root is, in a nutshell, a tangled mess with millions of opportunities for “oops, didn’t think of that” situations: https://www.cve.org/downloads
Immutable keeps the legacy system confituration basically unchanged, but also restores it “from ROM” every time you power on. (not real ROM, but effectively.) In an immutable system, the attack surface is dramatically reduced, and much more diverse among systems than with a mutable OS.
I reckon this must be true. However I do not see this as a reason for wide adoption of immutable systems. I guess that is a fairly valid use case.
I’d like to understand why some users are enthusiastic about bazzite. As of now I understood two of the reasons:
However I do not understand why these two things make their users so enthusiastic. It’s two things you rarely worry about when using a computer. They are indeed important, but in my opinion not much of a problem in modern distributions.
In the other hand you have to install everything through flatpak, which is something which would really get to my nerves.
I understand there are some good advantages, I just fail to understand which ones those are.
It requires literally zero work from me to maintain, that’s why I’m enthusiastic. Saying mutable Linux is zero work is dead wrong.
It’s actually quite a lot more than a bit more secure. Think of it as the difference between traversing no-mans land on a bicycle (current systems) vs in an armored personnel carrier with armor thick enough to stop EVERYTHING that the other side can throw at it. Sure, you could just open the door of the APC and take a hit, but if you don’t do that, you’re pretty safe.
Are you trying to think logically about that question? Because that would be a huge mistake.
Yeah, not my favorite either. A BIG part of why I’m not loving the majority of the immutable systems I have investigated is because they all seem to heavily lean on tech like flatpak, snaps, etc. and there are valid logical reasons for that, but I’d really rather not go there…
Zero-maintenance and upgrades.
You’re overthinking it, there’s no reason to care if the root disk is readable or not. If it updates reliably out of the box there’s no reason to touch it.
You don’t need to open a terminal to brick a traditional linux system they tend to do that on their own.
I can’t speak for “immutable distributions” but for bazzite it’s to ensure working upgrades.
I’m technically adept at Linux I expect software to work. (system upgrades should work, app installation shouldn’t break the PC, etc.)
So, the main advantage is that it is ensured that an update will not brick the system?
That is pretty neat, but it’s been quite a while since the last update which broke something for me. And that was either on arch of switching Debian version.
I reckon it is nice that you ensure updates won’t break anything, even though I’m not sure that can be ensured, in most cases I had it was the repo itself which made mistakes in packaging the software who broke it and I don’t think there’s solution for that. Either way, I myself do not see this such an advantage as to displace the pain of having everything run in flatpak.
Updates can be ensured and broken repositories go away entirely that’s the entire point. I don’t think it’s “nice” I would consider that a basic feature in Linux. If you like Linux your way then that doesn’t go away.
What do you mean? How can it be possible to eliminate a packaging error? If the packaging team makes a mistake you get a broken software, regardless whether you download a binary through a repository or through flatpak.
Yes exactly, my potentially hot take is that twenty years from now we’ll look at immutability as the tipping point that sent Linux mainstream on desktop.
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.