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!
Is there debian based immutable distro?
Yes, it’s called VanillaOS! https://vanillaos.org/
Isn’t it based on Ubuntu?
I think it was prior to version 2, but these days it’s based on Sid - https://vanillaos.org/nerd-info
Good. I just quickly glanced at the site and there were multiple mentions of Ubuntu… Glad they switched to Debian, this way I might try it on second PC.
Thank you)
Immutable, doesn’t mean extreme secure. It’s a false sense of security.
It could be more secure.
But during a runtime, it is possible to overwrite operational memory, mask some syscalls, etc.That’s my 3 cents.
Fully agreed. On almost any atomic distro, /home/user is writeable like usual, so any attacker is able to persist itself by editing
~/.bashrcand putting a binary somewhere.Secure can also mean more resilient. The infosec C-I-A triangle has three legs. Confidentiality, Integrity and Availability. Immutable distros are more resilient and thus offer better availability in the face of attacks or accidents.
it doesn’t allow changes to stuff that needs root access to change. If you have root access you can do anything, including switching images. It is not more secure. It’s not less either
I didn’t know that inflation can affect idiomatic expressions.
I love building my own uBlue image. Tinkering is done in toolbox containers, definite changes are baked into the image. Completely custom (to me) and when you get it right it will just work anywhere. If I would brick my PC/storage I can just boot up another and restore my (back-upped) home dir with very little effort.
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
patchelfon it somehow.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)
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.
I switched to silver blue after a bad update and my experience has been almost identical if not smoother than standard fedora
is nixos considered immutable or mutable? kind of has characteristics of both.
I’d argue it’s closer to a mutable distro than an immutable one.
Nixos tends to lean on the term reproducible instead of immutable, because you can have settings (e.g files in /etc & ~/.config) changed outside of nix’s purview, it just won’t be reproducible and may be overwritten by nix.
You can build an ‘immutable’ environment on nix, but rather than storing changes as transactions like rpm-ostree, it’ll modify path in /nix/store and symlink it. Sure, you can store the internal representation of those changes in a git repo, but that is not the same thing as the changes themselves; if the nixpkgs implementation of a config option changes, the translation on your machine does too.
Nixos tends to lean on the term reproducible instead of immutable, because you can have settings (e.g files in /etc & ~/.config) changed outside of nix’s purview, it just won’t be reproducible and may be overwritten by nix.
Interesting. If possible, could you more explicitly draw comparisons on how this isn’t quite the same over on say Fedora Atomic? Like, sure changes of
/etcare (at least by default) being kept track of. But you indeed can change it.libostreedoesn’t even care what you do in your home folder. Thus, changes to e.g.~/.config(and everything else in/var[1]) are kept nowhere else by default.
- Which happens to be more crowded than on other distros as folders like
/optare actually found here as well.
~/.config is probably a poor comparison on my part; it’s management is actually done by home-manager rather than Nixos proper, and I can’t think of another OS that fills this same role.
Nixos generates (for example) /etc/systemd/network to a path in /nix/store and symlinks it to it’s appropriate locations. After the files are generated the appropriate /nix/store paths are (re-mounted? Over-mounted? I’m not sure the implementation) made read-only (by default), but anything that isn’t generated is absolutely both mutable and untracked, and that “not tracking everything in /etc” is more what I’m going on about.
If you use Nixos as intended (when you find that a package is lacking a config option you want, create your own nix option internally) the distro is effectively immutable, but if you use Nixos for anything moderately complex that changes frequently e.g. a desktop os, you eventually run into the choice: become competent enough to basically be a nixpkgs contributor, or abandon absolute immutability.
I think the first option is worth it, and did go down that route, but it is unreasonable to expect the average Linux consumer to do so, and so something like fedora atomic is going to remain more “immutable” for them than nixos.
This need to git gud is thankfully lessening with every commit to nixpkgs, and most people can already get to most places without writing their own set of nix options or learning how to parse //random markup language// into nix, but you’ll eventually run into the barrier.
- Which happens to be more crowded than on other distros as folders like
nixos and guix are immutable and two of the only immutable distros I like
The store is immutable but the system itself definitely isn’t.
deleted by creator
Packages in nix are in the store directory, each package in a dir named after the package hash. So you can have 15 versions of firefox installed, for instance, and the different versions go in different folders with different hashnames.
When it’s time to set up a user env, their specific version of firefox is (conceptually) symlinked into the users profile. When that user executes firefox it gets one out of the 15 versions. Another user may get a different one.
Anyway, the package store is off limits to users, and a real bad idea to modify for root too.
deleted by creator
That’s not what sandboxed means and Nix isn’t sandboxed.
Sandboxed means it runs in a separate container, often with limited permissions; raising security at the cost of performance.
deleted by creator
I’m not really sure how the upsides of immutable distros work. I’ve been using linux for a long time and I’m not an expert but I’ve learned bits of things here and there.
I recently bought a steamdeck and it’s running an immutable distro. I don’t really know how to use software that’s installed via flatpak because it’s weird.
I have a game installed that runs badly (unplayable for me) through proton. I can launch it through q4wine if I switch the steamdeck into “desktop mode” and it runs much better.
If it wasn’t an immutable distro I could pretty easily make a shell script that launches the game through wine. Then I could add that shell script as a non steam game and it would (I think) run well, and I’d be able to launch it from the non desktop side of steam OS that is a lot more streamlined.
There is something comforting to me about immutable distros though.
I feel like I don’t remember half the shit I have installed on my computers. If I wanted to start cutting things out I don’t know where I’d start. But with flatpaks I get the sense I could probably just wipe anything I don’t use out of the flatpak directory and I probably wouldn’t break anything.
I’m fairly certain you could still run that shell script on steamOS? I don’t understand why an immutable distro would keep you from doing that. It’s essentially what Lutris and Heroic Games launcher do.
I have a really hard time getting Aurora working the way all my other Linux devices so that are running some form of Ubuntu (Mate or Bodhi). With that said, it’s been very stable and i like not being interrupted with packages to install while working on things…
Mixed bag review. I give it 3.5 out of 5 stars.
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.
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…
deleted by creator
Arch doesn’t break by itself tho, well… If you don’t update it for few months then yes, it breaks by itself
deleted by creator
TL;DR: My desktop PC uses EndeavourOS and the only immutable experience I have is SteamOS 3. I can’t say one approach is better than the other, but I like having the newest software and packages in my system. And that’s best provided with a rolling release. I also think that sandbox systems like Flatpak and the several alternative installation methods besides the system package manager is an added complexity for a new user in Linux.
I don’t mind using an immutable system (BTW another term that describes this kind of system is Atomic, which comes from Fedora), as long as it is designed around it and works well. The only immutable system I use is on my Steam Deck with the pre-installed SteamOS 3. My generic desktop personal computer is using an Archlinux derivative EndeavourOS with a rolling-release, where I have much greater control over the system.
Both systems have their strengths. I don’t think that my mutable and always up to date system is breaking more often than the other system. The best part of it is, its always up to date and I get the newest applications. I try to not use much Flatpaks or AppImages (but do for certain apps, where I have no other choice for ease of use). And an immutable system naturally basically asks me to use Flatpaks and other user space package formats that is not handled by the distribution itself.
Even though I have some thoughts on it, I am not excluding one approach. Many say that immutable distributions are good for new users to Linux. I think this adds some complexity and problems, because they need to use sandbox systems like Flatpak. And that’s if they know that they are using Flatpak, because sometimes the app distribution gives options like AppImage and custom installer scripts as well. This is all confusing for someone who just starts with Linux. On top of it, the sandbox of Flatpak requires some additional setup and configuration for some apps, to access certain hardware or filesystems in example.
All in all, I tend to like the traditional “mutable” distribution system as a rolling release model the most. But I’m an not excluding any other and would use a good “immutable” one; I just didn’t try any other than the one in my Steam Deck.
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.
That’s a very fair point. But it’s still annoying.
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
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”
Steam users are not the “average user”… they are the “average gamer”.
I need to run immutable distros more, and I need to figure out how to roll my own images.
Desktop side, I need certain things in the base image rather than adding more layers or using a container. Things like rsync, nvim, git, curl, lynx, etc.
Would immutable distros help reach more desktop audiences? Perhaps. It’s more about applications though. The biggest help has been electron apps and the migration to web apps. The Steam Deck is successful because it has applications people want.
Server side, they look really promising for bare metal servers. Provided, there is an easy way to compile custom images. Being able to easily rollback to a known good image is very enticing, as you point out.
I think they’re great. I’ve got two Linux newbies running some Ublue variant with no issues
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.
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.
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.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.
/etcis 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.
deleted by creator
Good point. I’ll have to stop using immutable and stay with atomic (and declarative).
Interestingly
/binand/usr/binare not in PATH by default, so/bin/chewycan only be executed by its path directly and won’t affect the systems reliability.
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.
