341
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.
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 19 Jul 2026
341 points (99.1% liked)
Linux
66512 readers
525 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 7 years ago
MODERATORS
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.
Because the image never gets built if there's a packaging error, so the user never ends up on a broken image. A broken package never makes it to the end. If it's broken the user just doesn't get an image until the package is fixed and then they get a new image.
I had broken packages getting installed before. They would compile correctly but certain functionality would not work due to how it was packaged. This is not something which can be prevented, I do not believe it is possible.
It is 100% possible and people have been doing it for years. If the package is broken the final product is never built, it's impossible to ship it to the end user since it's one whole complete image.
I am afraid we are talking about different things. Recently I had to report a broken package to a repository. The problem was that they mapped a path to the incorrect directory.
The software compiled and worked correctly, but some specific functionality which needed to read data from that directory was broken.
I do not think there is a way to prevent this kind of errors.
I am thinking that they wouldn't define that as a broken package, since I would consider that a bug that would need to be addressed in the next release. I would expect a broken package not to be able to run rather than simply to have a broken function.
In normal repos they also test their packages. I do not think it is possible in any distribution repo to ship a binary which did not compile. Dynamic library linking may have some problems I guess, but unless you're using arch that is generally never a real problem with package manager installations. I have never got a package which plain does not run.
I have had a couple of instances where I updated a package through apt and those updates resulted in a binary which crashed on launch or a configuration/database error that prevented the binary from being launched, so it does happen.
The fix was relatively simple and I had it working again in minutes, but I think it's still worth consideration as a potential point of friction, especially for users who don't have the ability or desire to fix their own systems.
As an aside, I think you should want to know how to fix your system, but I don't think it's unreasonable for non-tech people to be able to install an OS they don't have to periodically tinker with to get installed programs to launch correctly every time with no fuss.
For so many people, tinkering is like washing the dishes and they simply don't want to do it; an immutable system is like the dishwasher of tech purely in the sense that using it means that less effort is required from the user. I wouldn't expect my non-tech wife to think Linux From Scratch would be a fun learning project (like I do), we are all different.
Hope this comment isn't too tangential, I'm trying as a person to be less rigid in my thinking about how people do things because I think it holds us back and, really, it's a testament to the value of open source software that we have all of these options available. I wouldn't want there only to be one way to run Linux.