I think that installation was originally 18.04 and I installed it when it was released. A while ago anyways and I’ve been upgrading it as new versions roll out and with the latest upgrade and snapd software it has become more and more annoying to keep the operating system happy and out of my way so I can do whatever I need to do on the computer.
Snap updates have been annoying and they randomly (and temporarily) broke stuff while some update process was running on background, but as whole reinstallation is a pain in the rear I have just swallowed the annoyance and kept the thing running.
But now today, when I planned that I’d spend the day with paperwork and other “administrative” things I’ve been pushing off due to life being busy, I booted the computer and primary monitor was dead, secondary has resolution of something like 1024x768, nvidia drivers are absent and usability in general just isn’t there.
After couple of swear words I thought that ok, I’ll fix this, I’ll install all the updates and make the system happy again. But no. That’s not going to happen, at least not very easily.
I’m running LUKS encryption and thus I have a separate boot -partition. 700MB of it. I don’t remember if installer recommended that or if I just threw some reasonable sounding amount on the installer. No matter where that originally came from, it should be enough (this other ubuntu I’m writing this with has 157MB stored on /boot). I removed older kernels, but still the installer claims that I need at least 480MB (or something like that) free space on /boot, but the single kernel image, initrd and whatever crap it includes consumes 280MB (or so). So apt just fails on upgrade as it can’t generate new initrd or whatever it tries to do.
So I grabbed my ventoy-drive, downloaded latest mint ISO on it and instead of doing something productive I planned to do I’ll spend couple of hours at reinstalling the whole system. It’ll be quite a while before I install ubuntu on anything.
And it’s not just this one broken update, like I mentioned I’ve had a lot of issues with the setup and at least majority of them is caused by ubuntu and it’s package management. This was just a tipping point to finally leave that abusive relationship with my tool and set it up so that I can actually use it instead of figuring out what’s broken now and next.
It’s often used to describe a distro in which (at least some) parts of the system are read-only on runtime. Furthermore, features like atomicity (i.e. an upgrade either happens or doesn’t; no in-between state), reproducibility[1] and improved security against certain types of attacks are its associated benefits that can (mostly) only exist due to said ‘immutability’. This allows higher degree of stability and (finally) rollback-functionality, which are functionalities that are often associated with ‘immutability’ but aren’t inherently/necessarily tied to it; as other means to gain these do exist.
The reason why I’ve been careful with the term “immutable” (which literally is a fancy word for “unchanging”), is because the term doesn’t quite apply to what the distros offer (most of these aren’t actually unchanging in absolute sense) and because people tend to import associations that come from other ecosystems that have their own rules regarding immutability (like Android, SteamOS etc). A more fitting term would be atomic (which has been used to some degree by distros in the past). The name actually applies to all distros that are currently referred to as ‘immutable’, it’s descriptive and is the actual differentiator between these and the so-called ‘mutable’ distros. Further differentiation can be had with descriptions like declarative, image-based, reproducible etc.
I really appreciate this thorough response. Are there arguments against immutability? Besides that it’s probably a challenge to maintain…
Initially I was typing out a very long answer, but it quickly got unwieldy 😅. So instead, this one will be oversimplified 😜.
Currently:
One might (perhaps correctly) point out that most of these are actually more related to the technology lacking maturity. And that atomic distros would actually (already) net positively otherwise. Therefore, I’d argue, the transition to atomic distros is perhaps more akin to a natural evolution. I believe (at least) Fedora has already mentioned the possibility to sunset the non-atomic variant in favor of the atomic one when the time is there (or at least switch focus). Which is why I believe that atomicity will probably leave a lasting impact to the Linux landscape, similarly to what systemd has done in years prior.
If your use-case is supported and you’ve acquired the associated knowledge for setup/configuration and maintenance, then I’d argue it’s probably even easier than a non-atomic distro; simply by virtue of atomicity, increased stability and rollback-functionality. But, as has already been established previously, the learning curve is steeper in general, so getting there is probably harder. With the exception being those whose needs are satisfied easily by the accessible software found in the main package-‘storefront’. Which makes distros like Endless OS very suitable for people whose primary interaction with ‘computers’ has been mobile phones and tablets, as the transition is -perhaps surprising to some- near flawless.