I recently took up Bazzite from mint and I love it! After using it for a few days I found out it was an immutable distro, after looking into what that is I thought it was a great idea. I love the idea of getting a fresh image for every update, I think for businesses/ less tech savvy people it adds another layer of protection from self harm because you can’t mess with the root without extra steps.
For anyone who isn’t familiar with immutable distros I attached a picture of mutable vs immutable, I don’t want to describe it because I am still learning.
My question is: what does the community think of it?
Do the downsides outweigh the benefits or vice versa?
Could this help Linux reach more mainstream audiences?
Any other input would be appreciated!
Immutable distros are great for applications where you want uniformity for users and protections against users who are a little too curious for their own good.
SteamOS is a perfect use case. You don’t want users easily running scripts on their Steam Decks to install god knows what and potentially wreck their systems, then come to Valve looking for a fix.
Immutable distros solve that issue. Patches and updates for the OS roll out onto effectively identical systems, and if something does break, the update will fail instead of the system. So users will still have a fully functional Steam Deck.
If you’re not very technical, or you aren’t a power user and packaged apps like Flatpaks are available for all your software, then go for it. I prefer to tinker under the hood with my computers, but I also understand and except the risk that creates.
Immutable distros are a valuable part of a larger, vibrant Linux ecosystem IMO.
Immutable are the ultimate tinkerer’s distros. It’s just a different way of tinkering. True tinkering in immutable means creating your own image from the base image and that allows you to add or remove packages, change configs, services, etc.
Example: you create your own image. You decide you want to try something, but you’re being cautious. So you create a new image based on your first with your changes. You try it out and you don’t like it or it doesn’t work for some reason, you can just revert back to you other image.
Another thing worth mentioning, with these distros, you can switch between images at will. I’m new to Linux as my daily driver desktop OS, and I’ve rebased three times. It’s really cool to be able to do that.
Don’t know why this would be downvoted. Atomic distro’s are a tinkerers paradise, as all of it can be done fearlessly. I can make stupid changes to configurations that I don’t understand on NixOS, then when things break, simply revert the git commit and rebuild. (Or reboot to the last build if I broke it bad enough).
Who knows. People are passionate about Linux. And downvoting takes no effort. And people downvote stuff randomly.
if something makes linux more secure, safer or easier to use then it’ll be hated because people in the linux community are allergic to all those things. Secure boot? they hate it, wayland? they hate it, immutability? they hate it, flatpaks/sandboxed app? they hate it, gnome? they hate it. Even rust is hated by many.
So Bazzite basically is an immutable 3rd-party SteamOS. It was originally designed for handhelds (though has desktop images now) and includes the Steam Deck’s
gamemode
package. That means it has the same interface, but working on a Legion Go or an Ally X. If anyone here has* any of those three you should seriously check it out!The other thing as well is that more often than not, the update will succeed and you won’t figure out until the next boot that something is wrong. However, Bazzite has a rollback tool so you can just change back to the previous image, reboot again and get to gaming.
That’s the best reason for immutable for gaming IMO. I don’t want to be fucking around with the OS when I’m in the mood to game. Being able to quickly rollback and jump into things in ~10 minutes or less is how it should be.
NixOS is kinda the best of both worlds, because it does everything in a way that is compatible with an immutable fs, but it doesn’t force you into abiding by immutability yourself.
You can always opt into immutability by using Impermanence, but I’ve never seen any reason to.
Edit: That said, the syntax has a steep learning curve and there are tons of annoying edge cases that spawn out of the measures it takes to properly isolate things. It can be a lot to micromanage, so if you’d rather just use your system more than tinker with it, it may not be a good fit.
Impermenance is not the same as immutability.
I suppose you’re right. It’s just another tool for helping you abide by immutable practices without forcing immutability as an unbreakable rule.
I heard both flatpak and immutability are obstacles to developers. How bad is it really?
I’ve had NixOS absolutely refuse to run some compiler toolchain I depended upon that should’ve been dead simple on other distros, I’m really hesitant to try anything that tries to be too different anymore.
It would be a problem without distrobox. Since that gives you a normal, mutable OS on top, you don’t even notice the immutability.
And Homebrew. I’m a developer and I’ve done all my work just with Homebrew.
if you program using vscodium, do you install a separate vscodium in every distrobox?
Yep, I do currently. I only have one main distrobox.
I had a lot of issues on silverblue using vscodium as a flatpak, I think I will try installing it in a distrobox instead.
It should behave pretty much the same as a normally installed version. Hope it works well for you!
I’ve had NixOS absolutely refuse to run some compiler toolchain I depended upon that should’ve been dead simple on other distros, I’m really hesitant to try anything that tries to be too different anymore.
Yes, some toolchain expect you to run pre-compiled dynamically linked binaries. These won’t work on NixOS, you need to either find a way to install the binary from nix and force the toolchain to use it or run
patchelf
on it somehow.Or enabling nix-ld can often get such binaries working.
NixOS likely only refused to run it because you weren’t running it in the Nix way. That’s not a jab or anything, Nix has a huge learning curve and requires doing a lot differently. You’re supposed to use devshells whenever doing development. If you want something to just work, you use a container.
Whatever issue you ran into most likely had nothing to do with NixOS being immutable, and was probably caused by the non standard filesystem hierarchy, which prevents random dynamically linked binaries from running.
I’ve never heard of flatpak and immutability being obstacles to developers, in fact I generally hear the opposite. Bluefin is primarily targeted at developers, and some apps, like Bottles, will only officially support the flatpak distribution because of the simplicity and benefits it brings over standard distro packaging.
Same issue, I still use nix on m’y laptop because it’s neat as can be, but I have to admit developing on nix can be quite a hassle if you don’t go it “the nix way”, moreover some packages don’t work as well because nix doesn’t link binaries the standard way (zed editor for example)
I don’t mind flatpaks in a pinch, but having to use them for literally every app on my computer is an unreasonable amount of bloat.
The barrier for me is that I use a lot of apps which require native messaging for inter-program communication (keepass browser, citation managers talking to Libreoffice, etc.), and the portal hasn’t been implemented yet. Its been stuck in PR comment hell for years. Looks like its getting close, but flatpak-only is a hard no go for me until then.
Even after that, I would worry about doing some Dev work on atomic distros, and I worry about running into other hard barriers in the future.
But the more apps the more the dedup is saving space
Not when every app decides to use a different point version of the same damn platform.
"Hello Mr. Application. I see you’d like to use the Freedesktop-SDK 23.08.27
“Oh…well hello other application. What’s this? You want to use Freedesktop-SDK 24.08.10? Well…I guess so…”
Edited to add: Yes, I know that flatpaks will upgrade to use updated platforms. But it doesn’t automatically remove the old one, forcing you to have to run flatpak remove --unused every week just to keep your drive clean. That’s hardly user friendly for the average person.
I had a systemd unit that ran it weekly after the update one ran. I feel like the default behavior though should be automatic purge old unused runtimes though too. I don’t see why that wouldn’t the case to me.
I’ve even gone so far as wanting to force run time changes underneath the packs because of Caves and such, but thats my niche and puts security over function.
Definitely not a free lunch sys admin wise, but it is still a marked improvement over native apps 98% of the time for me.
The average person has a 1tb+ drive and doesn’t care about a few hundred megabytes of bloat in a partition they will never look at. If someone is switching from Windows, every app having its dependencies self contained is mostly normal anyway (aside from the occasional system provided dll). The only people likely to care about removing old flatpak platforms are the kind of people who don’t mind running the command to remove them.
The average person has a phone, with 128gb of storage.
The typical laptop I deal with have 512gb ssd drives.
The typical desktop in a corporate environment is 256gb or 512gb.
1tb drives are very much not “average”.
The average person definitely doesn’t have a 1tb drive.
61% of steam users have 1tb or more total hard drive space.
https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam
Steam users are not the “average user”… they are the “average gamer”.
I don’t think Steam users really represent the average person…
The average person doesn’t own a computer anymore, but I think steam users are pretty representative of people who want to use the OS that markets itself as “The next generation of Linux gaming”
That’s a very fair point. But it’s still annoying.
Immutable ≠ atomic
Bazzite is atomic (not immutable), same with Silverblue and other Fedora variants (they’re all atomic, even on their main page it says atomic). It’s kinda misleading ngl
Fedora Atomic IS immutable. Rpm-ostree just layers (or hides) stuff on top of the already existing image. If you layer something, e.g. Nvidia drivers, you still download the same image everyone else uses, but basically compile the driver from fresh and put it on top. And that takes time. This is the reason using rpm-ostree to layer stuff is not recommended.
That’s why uBlue exists for example. It gives you a sane start setup, where all drivers are already built in into the image. And then you can either use the clean base and add your own stuff to create your own image, or use already great ones like Bluefin or Bazzite, where everything you want is already included.
Atomic just means that every process is either completed without errors, or not at all. This way, you don’t get an half updated and broken system for example in case you loose power. Happened to me quite a few times already, but never with Fedora Atomic.
Pretty much anything outside of
/var/
(even/home/
is placed inside/var/
) is read-only, and if you want to modify your install, you have to build your own image. Therefore, it is both immutable AND atomic.That’s why I prefer the term “image based”
Isn’t that just their nomenclature for immutable?
What’s the difference between an atomic distro and an immutable one?
A distro can be both atomic and immutable, and they often go hand in hand.
Immutable simply means the core of a distro is read-only, meaning it cannot be modified by usual means. There are still ways to modify these files, but it works differently than in other distros.
Atomic distros are ones that update atomically. Atomic is used to describe an operation that cannot be cancelled in the middle of it, they either complete, or nothing changes. This means you can’t break things by cancelling an update midway through. Atomic distros also often come with the ability to rollback to the previous build of the system.
Doesn’t all immutable distros have updates that can’t be cancelled and that will either complete or not change anything?
I only just started learning about immutable distros so I may be completely wrong but it’s how I understand them to work when reading about it.
Immutable ≠ atomic, but they generally come as a package deal. Bazzite, Silverblue, and all those other distro’s that call themselves atomic are also immutable. An atomic distro is just one with atomic updates, and an immutable distro is any distro with a read-only core.
These distro’s have started mainly calling themselves atomic because they agree that immutable is a poor description that generally confuses users.
I personally vastly prefer mutable distros for my own system, but I understand the appeal for those who like them. As long as mutable distros remain an option I don’t mind immutable distros.
As long as mutable distros remain an option
Precisely this, linux is about choice. It’s not like suddenly most distros would change init systems and make it near impossible to choose… oh, wait…
I prefer mutable and see immutable mostly as lazyness but if people wanna use’em go for it, i’m not pushing mutable down their throats.Linux isn’t about choice, it’s about freedom. Distro’s don’t owe you the choices you want, because the devs have the freedom to make what they want. You also have the freedom to modify them or make whatever distro you want.
Secure != stable Immutable distros aren’t always more secure but rather more stable and hard to break Also btw nixos can apply updates without rebooting
I wouldn’t call NixOS immutable.
NixOS is immutable and atomic, but it isn’t image-based.
Immutable simply refers to how the running system configuration can’t be changed by simply putting a file somewhere (e.g. copy a binary to
/bin
, which is a bad idea).For example, Fedora Atomic and derivatives are image based, although they are more flexible than the A/B types like SteamOS.
OpenSUSE MicroOS uses btrfs snapshots to apply updates atomically, and is more flexible than most image based immutable distros.
Edit: But I don’t think those terms have a single definition, so how would you differentiate these terms?
I’m on NixOS right now and just dropped a Chewy in my
/bin
, only had tosudo touch /bin/chewy
.deleted by creator
Good point. I’ll have to stop using immutable and stay with atomic (and declarative).
Interestingly
/bin
and/usr/bin
are not in PATH by default, so/bin/chewy
can only be executed by its path directly and won’t affect the systems reliability.That doesn’t make it not immutable. /bin is not a critical directory in NixOS, only the contents of /nix are, which are immutable. /bin isn’t even part of your path by default.
Well that was an approximation to keep it simple and disprove the given example. There are other directories in the root filesystem that are in the path by default, or used in some other critical way (like
/etc
). Even if they are links to directories in the nix store you can replace the link.I understand, but it didn’t really disprove anything. Immutable distro’s protect core components from being modified. /bin is hardly relevant on NixOS, so of course it wouldn’t be made immutable.
/etc
is also generally not considered a core component, and every immutable distro I’ve used left it writable. By default, every binary installed through NixOS is put in/run/current-system/sw/bin
, which is immutable. Many other important files are also linked to/run/current-system
, which is why the whole directory is immutable. It essentially takes the place of what the root directories would be on an FHS distro.I don’t know any other path used in critical ways that is not immutable. The primary paths that immutablility is relevant for in FHS distros are /usr, /lib, /lib64, and /bin. None of these paths are really used on NixOS, besides some files symlinked there for edge cases, like /bin/sh.
If you were to remove all the symlinks you are able to, the system would still work for the most part. You would lose custom configurations in /etc, but that is true for most immutable distros. Most apps have a default configuration to fallback to.
The misunderstanding comes from the fact that immutable is a poor description for any OS, which is why many now use atomic instead. Even in immutable distros, many files can still be modified, and things can still be broken if you try hard enough. Still, NixOS definitely falls under the general description of and immutable distro, as the core of the OS is immutable.
It can be made to be by pinning various things which are not by default.
What things?
At the surface, you can pin the commit you pull packages from, but if you want to go deeper, you can essentially define your own channel and dependent binaries, allowing you to store every aspect of how a generation is built.
Yes, or use flakes which gives you a lockfile pinning everything. But this is related to reproducibility, not immutability.
If you control everything in the build it is, and every generation is immutable.
Isn’t immutability related to the root filesystem being read-only? I can write on my root filesystem, even if it’s mostly links to the store I can replace those links.
In your opinion, when can we refer to a distro as being immutable? How do you regard the likes of Fedora Atomic, openSUSE Aeon or Vanilla OS? Are any of these immutable in your opinion?
To be honest I don’t know these very well. I only use NixOS. My understanding is that in an immutable distribution the root filesystem is read-only. Granted in NixOS the nix store is immutable and most things in the root filesystem are just links to the nix store, but the root filesystem itself is not read-only.
Then you have NixOS, which is declarative, and fairly immutable.
You don’t have to reboot to make changes, but you can’t just run unlinked binaries either.
You can’t do things like edit your hosts table or modify the FS for cron jobs. The application store is unwritable, but you can sync new apps into it .
You have to make changes to the config file and run a rebuild as root.
just for clarity: you can modify stuff like hosts or cron jobs but it’d get overwritten iirc? you can also make the change in the config and have it persist (reproducibility being the main point, not disallowing you to edit your files)
No, that file is located in the nix store and linked back, If you become root and try to edit /etc/hosts It will complain that you cannot edit the linked file.
If you go and try to edit the store directly you will meet the same kind of dead ends because /nix/store is a ro bind mount
With enough root access, time and persistence you could eventually unwrap its flavor of immutability which is why I said mostly immutable. Compared to most operating systems where you can just slip a quick edit into a cron job it’s leagues ahead.
TIL
guess i just never botheres to try cos config change & rebuild wasn’t much more of a hassle :shrugs:
Yep, it is ribbed for your protection. :)
I am a huge fan of immutable distributions, not for my personal daily driver but for secondary systems like my living room/home theater PC.
I am a big fan of breaking my system
Stock fedora is just for you my man, it breaks by itself
Manjaro enters the room…
arch >>>>
Arch doesn’t break by itself tho, well… If you don’t update it for few months then yes, it breaks by itself
Exactly. Arch is just better for the user to break. I like to break my system, not the system breaking by itself.
Since the idea is that the “root partition” is immutable, serious question:
How do you fix a hardware config issue or a distro packaging / provision issue in an immutable distro?
Several times in my Linux history I’ve found that, for example, I need to remove package-provided files from the ALSA files in
/usr/share/alsa
in order for the setup to work with my particular chipset (which has a hardware bug). Other times, I’ve found that even if I set up a custom.XCompose
file in my $HOME, some applications insist on reading the Compose files in/usr/share/X11/locale
instead, which means I need to be able to edit or remove those files. In order to add custom themes, I need to be able to add them to/usr/share/{icons,themes}
, since replicating those themes for each $HOME in the system is a notorious waste of space and not all applications seem to respect/usr/local/share
. Etc.Unless I’m mistaken on how immutable systems work, I’m not sure immutable systems are really useful to someone who actually wants to or needs to power user Linux, or customize past the “branding locking” that environments like Gnome have been aiming for for like a decade.
My guess would be: have an additional overlay filesystem on top of your immutable root and apply all your fixes to it.
On the one hand sounds sensible, on the other hand I wonder if that’s possible when wanting to apply things that need to take place as early in boot as possible (eg.: modprobe options for a module, apparmor profiles, …).
I have investigated the idea and came to the conclusion that immutable distros are essentially a research project. They attempt to advance the state-of-art a slight bit but the cost is currently too great.
Perhaps somebody will some day create something that’s worth switching to. But I don’t think that has happened yet, or is happening with any of the current distros. Silverblue might become that with enough polish, but I feel that to get that amount of polish, they would have to make Silverblue the 1st class citizen, i.e. the default install of Fedora.
I think they’re great. I’ve got two Linux newbies running some Ublue variant with no issues
what does the community think of it?
Everyone has their own opinion, personally I think they’re a great idea and have lots of great applications. But just like rolling vs non-rolling release it’s a personal and application dependant choice.
Do the downsides outweigh the benefits or vice versa?
Again, depends, for my personal computer I wouldn’t use it because I think it could get complicated to get specific things to work, but for closed hardware like the Deck or even a fairly stable desktop used as a gaming system it’s perfect.
Could this help Linux reach more mainstream audiences?
It could, it can also hamper it because people might start to try solutions that only work until next boot and not understanding why, or having problems getting some special hardware to work (more than it would be a mutable distro). But there is a great counter to this which is that once it’s running it will be very difficult to break by user error.
At the end of the day I think it’s a cool technology but that people should know what they’re getting into, just like when choosing rolling vs non-rolling distro, it’s not about what’s better, but what suits your needs best.
what does the community think of it?
It’s important to note how the Linux community interacts with change. In the past, whenever a change has been significant enough to influence individual workflows, it often provoked strong reactions. This was evident when systemd was introduced and adopted by distros like Arch and Debian. Even though systemd was arguably superior in essential aspects for most users, it failed to meet the needs of at least a vocal minority. Consequently, community endeavors were set up to enable the use of Debian or Arch without systemd.
Similarly, the introduction of immutable distributions seems to upset some people, though (at least to me) it’s unjustified. Immutable distributions don’t necessarily alter the traditional model. For instance, the existence of Fedora Silverblue doesn’t impose changes on traditional Fedora; let alone Arch or Debian.
But, overall, most Linux users aren’t bothered by it. Though, they often don’t see a use for themselves. Personally, I attribute this at least in part to existing misconceptions and misinformation on the subject matter. Though, still, a minority[1] (at best ~10%) actually prefers and uses ‘immutable’ distros.
Do the downsides outweigh the benefits or vice versa?
Depends entirely on what you want out of your system. For me, they absolutely do. But it’s important to note that the most important thing they impose on the user is the paradigm shift that comes with going ‘immutable’. And this is actually what traditional Linux users are most bothered by. But if you’re unfamiliar with Linux conventions, then you probably won’t even notice.
As a side note, it’s perhaps important to note that the similarities between traditional distros are greater than the similarities between immutable distros. Also, Fedora Atomic is much more like traditional Fedora than it is similar to, say, openSUSE Aeon or Vanilla OS. Grouping them together as if they are a cohesive group with very similar attributes is misleading. Of course, they share a few traits, but overall, the differences are far more pronounced.
Therefore, it is a false dichotomy to simply label them as traditional distros versus immutable distros. Beyond these names, which we have assigned to them, these labels don’t actually adequately explain how these systems work, how they interact, how their immutability is achieved (if at all), what underlying technologies they use, or how they manage user interactions. The implications of the above. Etc.
Could this help Linux reach more mainstream audiences?
The success of the Steam Deck and its SteamOS are the most striking and clear proof of this. So, yes. Absolutely.
- Not accounting SteamOS users.