Hacker News Reader

> 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.

Also, they're working on CentOS based LTS versions of Bluefin: https://universal-blue.discourse.group/t/call-for-testing-bl...

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

> Long term support

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.

Yea the docs on the Fedora side are rough. I would help but I don’t know enough because the learning was so hard.

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?

Maybe it would help in a datacenter

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.

Immutable distros typically use a declarative configuration that is easier to manage with terraform

> the advantages of immutable distros

The high availability of ChromeOS is a good example of these advantages in a business of educational context.

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.

> But that basically doesn't happen between release upgrades

Nvidia would like a word

For pre-Turing closed drivers I'd count that as an unsupported third party, even if the distribution in questions tries to support it.

I have an Nvidia card and I've never had it cause problems.

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.

Well, that certainly counts as third party