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)

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.

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.

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.

I didn’t know that inflation can affect idiomatic expressions.

Fully agreed. On almost any atomic distro, /home/user is writeable like usual, so any attacker is able to persist itself by editing ~/.bashrc and putting a binary somewhere.

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

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

It would be a problem without distrobox. Since that gives you a normal, mutable OS on top, you don’t even notice the immutability.

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.

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)

And anybody who thinks that Linus doesn’t look for those ways to break Linux is deluding themselves. He’s a fucking asshole.

Honestly, I would say it isn’t great for anyone who has to do something low level even once. Now that there are open source nvidia kernel drivers that has solved a pretty big issue for most people who would be interested in immutable distros, but there are still many other drivers and issues that your regular user may face.

One example off the top of my head is that flatpaks specifically can’t ship systemd services if I recall correctly. A lot of wayland apps for thigns like input have to use daemons because of wayland’s security model. Lact for AMD and now Nvidia GPU control, ydotool, or even gui versions of such tools for remapping input.

Snaps require custom kernel modules that aren’t used outside of ubuntu, so I hesitate to trust them regardless of any of the other issues people have with them.

This basically leaves appimages which aren’t available for everything and don’t always seem to work at least not as reliably as flatpak. I even tried to package the rstudio forensic software as an appimage myself, so I could have an easy way to use that proprietary piece of software, but I just couldn’t get it to work. I couldn’t get it to work with distrobox either using the official methods they provide to install it on linux. I did get it working in a chroot for some reason, but it had graphical issues. In the end, I made a PKGBUILD for arch and got it working that way.

The point of all this is that a lot of times people say immutable is great for average, non tech savvy people, but I believe that literally everybody ends up needing to do low level stuff at least once or twice every so often. Which simply isn’t a great experience since you end up having to do layering which throws these theoretical average users right back into the normal complexity of a mutable system, but with even more uncertainty in my opinion.

Now then with all of these caveats. I do still agree that immutable distros are great for the aforementioned group of people and I know this statement contradicts a lot of what I have described above. The reason why I think they are great for the less tech savvy people however isn’t because of any actual technical merit of the systems design though. Immutable distros are great for people like Linus Sebastion because it limits what they can do. You simply have to accept what is there the same way that you have to on proprietary systems like Mac and Windows. Those systems force you to do things a certain way unlike Linux and that is what people like Linus need because they have no business mucking around with the system to begin with.

Lastly, all of this only works because devices like the Steam Deck are being run on specific hardware thus guaranteeing there compatibility. This is what we ultimately need. There would be much less need for low level operations to get drivers or change settings to make wifi or audio work right on a billion different devices if these people were buying linux compatible hardware in the first place.

Impermenance is not the same as immutability.

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.

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?

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.