Thank you for your reply!

I guess I’d define it as a distro where the base system is read-only and changes or updates to it are done by replacing it atomically.

Aight. I got no qualms with that definition for an immutable distro. However, small nitpick, the term “base system” can be very murky at times. And perhaps I would rephrase the part addressing changes/updates to “changes or updates to it are intended to be applied atomically”.

Btw, I think this conversation is primarily on semantics and some assumptions we’re making related to that. So, I agree with you that (strictly speaking) immutability is only part of the puzzle (perhaps I might even refer to it as an enabler) for acquiring a lot of the aforementioned benefits to the degree by which it’s attained. So, the precise implementation of immutability is at least as important.

For example, openSUSE Aeon/Kalpa, as much as I like them, have not been able to deliver most of these benefits beyond what traditional distros are capable of. Despite these distros being immutable*. However, they’ve recognized their faults and intend to move towards an image-based solution in order to improve. Similarly, Vanilla OS has recognized that their first vision of ABRoot wasn’t fit and thus overhauled it to be more in line with Fedora Atomic. We should continue to regard their initial visions as immutable distros despite ‘their failings’, but should also recognize that their failures aren’t representative of what immutable distros are or can be.

How exactly?

what can they do that you can’t on a normal distro?

Alright, let’s start:

(Note that the immutable distros will only be represented by Fedora Atomic, GuixSD and NixOS. The others are either too niche or immature)

• atomic updates; no need to explain as you’ve established this yourself.
• reproducibility; I’m not talking here simply about “reproducible builds”. Instead, I’m referring to how, on a daily basis, the system is actually built up from the ground (or at least capable of doing so without the hassle of actually committing to a complete reinstall). Some references in case you’re interested to know more about this. This is something I’ve simply never seen on a traditional distro. Though I hope you can correct me on this.
• declarative system configuration; atomicity is just a pre-cursor or enabler for this. Nonetheless, ultimately, it’s a feature found exclusively on immutable distros. In case you mention Ansible, you should be aware that Ansible (at best) offers convergent system management. The aforementioned immutables succeeds effortlessly in (the superior) congruent system management. Refer to this article in case you’re interested in the differences.
• increased security; Linux’ security standards leaves a lot to be desired. Unfortunately, whatever immutability offers in that regard, is far from enough to bridge the gap. By contrast, Qubes OS, while not being immutable (and technically not even a Linux distro), succeeds at setting an excellent security standard. But even they acknowledge the benefits that immutability provides for security (even on Qubes OS).
• built-in rollback functionality; I can’t remember how GuixSD and NixOS far surpass anything else out there in this regard. However, for Fedora Atomic’s OCI model, it’s required that some registry builds your images. Currently, these images are stored for 90 days by default. Which means that I can go back to any one of these without keeping the snapshots on my own device. While it’s technically possible to keep snapshots from the last 90 days with Snapper/Timeshift, most sane people would simply not do it as it’s overkill and/or wasteful of storage. However, Fedora Atomic allows such functionality without burdening your system. Hence, it’s superior. Though, once again, perhaps this functionality is somehow available on traditional distros. But I’m simply unaware of it*.

There’s no need to go over the “consequences” as they’re (as the name implies) consequences of what has mentioned earlier. Hence, as their causes are better than the one found on traditional distros, so are the consequences better than how they’re found on traditional distros.

Finally, minimizing bit rot, configuration drift and hidden/unknown states are direct consequences of atomicity and declarative system management. Hence, immutable distros perform better at this compared to traditional distros.

Thank you for the reply!

What do you mean by declarative system configuration? that thing that nixos does that you set it up thru its config file?

What you refer to in NixOS is indeed its solution to offer declarative system configuration. But the other two mature immutable distros, i.e. Fedora Atomic and Guix System, have their own solutions. Though, Guix System’s solution is a lot more reminiscent of NixOS’. While Fedora Atomic leans on ‘the ways’ established for OCI (and hence containerfile(s) etc). Even less mature immutable distros, i.e. blendOS and Vanilla OS, have put considerable effort into the works for managing their systems declaratively.

I’ve also kept several month old btrfs snapshots on my system and I don’t see a problem with it, they only add like 3 GIB of storage each when they are that old.

My argument here is mostly just “No occupied storage on device is better than some occupied storage on device.”. But yeah, its significance is definitely up-to-debate. Perhaps I should have relied more on the built-in aspect; from the mainstream independent and/or highly popular traditional distros only (Garuda,) Linux Mint(, Manjaro, Nobara) and openSUSE Tumbleweed come with built-in rollback/snapshot functionality. But, regardless, the rollback/snapshot part of the equation is definitely the least special (if at all).

Also I’m not sure what you meant by increased security? Is it more secure simply because you can’t edit the root filesystem?

It’s indeed related to how some parts of the system are read-only during runtime (under normal circumstances). Hence, some types of attacks are circumvented from the get-go. This, by itself, doesn’t warrant the use of an immutable distro over a traditional one; even if the user is security conscious. However, if said user already intends to use a distro that takes security seriously (i.e. Fedora or openSUSE) for the sake of security (or at least it plays some role in their decision-making), then they might as well prefer their atomic counterparts. But yeah, for actual security, one should probs rely on Qubes OS instead. Though, atomic distros have given us the likes of secureblue; which may be the most secure Linux system for general-use we got (besides Qubes OS, if we even count that as Linux). The only other contender is Kicksecure.