I totally see the advantages of immutable distros, particularly in a professional or cloud environment. Even as a hobbist, I feel tempted to use immutable distros if it were not because of:
- Learning. Figuring out how to migrate a setup even to the most mainstream-like immutable distro (fedora silverblue) can take a while, and to niche distros like talos even longer. However, a k8s-friendly setup with low customization requirements would help to speed up the migration (but it requires more powerful machines).
- Long term support. Regular distros like Debian and AlmaLinux offer free 5 and 10 year support cycles which means maintenance can be done every 1 or 2 years. On the other hand, immutable distros would require much more frequent maintenance, once every 6 months. A weekend every 6 months is a sizeable part of my time budget for hobbies.
One aspect in which immutables distros have improved a lot is in resource usage. They used to require significantly more disk space and have slightly higher minimum requirements than regular distros, but that doesn't seem to be the case anymore.
> Long term support. Regular distros like Debian and AlmaLinux offer free 5 and 10 year support cycles which means maintenance can be done every 1 or 2 years.
What's maintenance in the context if immutable distros? Running "ujust upgrade"? That's done automatically in the background for my Aurora installation.
Yes, system upgrade is the main maintenance task. With some monitoring, security updates can be automated but after system upgrades I must check manually that everything is working. E.g. incompatible configuration files, changes in 3rd party repos, errors that surface one week after the upgrade, ...
There are also smaller maintenance tasks that are tipically ad-hoc solutions to unsolved problems or responses to monitoring alerts. One of this ad-hoc routines was checking that logs do not grow too large, which used to be a problem in my first systemd centos, although not anymore.
PD: thanks for the bluefin read, it made me discover devpod/devcontainer as an interesting alternative to compose files
Intuitively, this seems opposite, because you could obviously 'mutate' (or mutilate) your Debian system until the updates break. Isolating user changes should make updates easier, not harder. Also MacOS uses a 'sealed' system volume and updates are like butter there.
> Also MacOS uses a 'sealed' system volume and updates are like butter there.
Smooth as in "no data loss", sure. Smooth as in "supports the software I buy and use for long periods of time" is most certainly not true, even despite half the software for Mac being statically linked. Windows and Linux arguably do better at keeping system functionality across updates even with their fundamental disadvantages.
While true, this isn't even slightly related to the os being "immutable" or not. Immutable-OS upgrades can and do break things - that's the reason it's even a thing. They just give you a reliable rollback.
I found Fedora is terrible at documentation, or at least around rpm-ostree they are. It has made learning more of a struggle than necessary. I think the basics are that there is some sort of container image builder that can work from a manifest, then some way to create a distro out of a container image. All of the content I can find is fragmented across many sites and not complete enough to actually use. Extremely frustrating.
Fair call. In any case I think you'll find things moving towards bootc and away from having to know rpm-ostree at all. The bootc documentation for fedora is pretty good and the Universal Blue project has built some awesome distros that use bootc.
I dont see how it helps in a cloud environment? With correct permissions users aren't making changes to live servers or even logging in and if you want to roll out upgrades you can do it with OS images already?
Exactly, and if it's immutable, you know they aren't. Not through SSH, and not through a vulnerability either. I assume there's something you can hash to determine prove that you haven't been hacked, as well.
In some aspects, I'd hope that there are potential benefits on the security side of things as well. Since the host FS is generally read only in these type of distros, there is the potential to make some security teams happy.
You’re missing the whole point of an immutable distro. If you have a hobby project on a regular distro, you run apt-get update or whatever, it installs 200 packages and half of them run scripts that do some script specific thing to your machine. If something goes wrong you just bought yourself a week’s worth of debugging to figure out how to roll back the state.
If you update using an immutable distro, you rebase back on to your previous deployment or adjust a pin and you’re done. Immutable distros save you tons of time handling system upgrades, and the best part is you can experimentally change to a beta or even alpha version of your distro without any fear at all.
> If something goes wrong you just bought yourself a week’s worth of debugging to figure out how to roll back the state.
But that basically doesn't happen between release upgrades, not unless you're doing something with third party repos at least.
> If you update using an immutable distro, you rebase back on to your previous deployment or adjust a pin and you’re done
I genuinely don't know, but can you do security updates without rebasing? Just keeping some working version pinned sounds like bad idea to me, and doesn't even save you time because you'll need it resolve that problem eventually anyways.
Many people install Nvidia drivers by using their shipped .run binary (which is a bad idea) and thus breaks when the kernel is updated to something higher than the DKMS module supports.
- Learning. Figuring out how to migrate a setup even to the most mainstream-like immutable distro (fedora silverblue) can take a while, and to niche distros like talos even longer. However, a k8s-friendly setup with low customization requirements would help to speed up the migration (but it requires more powerful machines).
- Long term support. Regular distros like Debian and AlmaLinux offer free 5 and 10 year support cycles which means maintenance can be done every 1 or 2 years. On the other hand, immutable distros would require much more frequent maintenance, once every 6 months. A weekend every 6 months is a sizeable part of my time budget for hobbies.
One aspect in which immutables distros have improved a lot is in resource usage. They used to require significantly more disk space and have slightly higher minimum requirements than regular distros, but that doesn't seem to be the case anymore.