Hacker News new | ask | show | jobs
by brancz 1165 days ago
A couple of small things, but primarily I don’t think it actually embraced immutability in the same way. CoreOS container Linux used A/B partitions for updating truly immutably. Partition B didn’t boot? Just boot A again.

Fedora CoreOS and RHEL CoreOS use OSTree [1], no shade on OSTree, it works well, but I slept better with A/B partitions, I just find them easier to reason about.

[1] https://github.com/ostreedev/ostree

3 comments

It uses ostree but it’s read-only root partition and changes only take place on reboot unless you pass a special flag
Gotcha. Thanks for clarifying.
From Fedora CoreOS docs: “ When an update is complete, the previous OS deployment remains on disk. If an update causes issues, you can use it as a fallback.”

IIRC RHEL now has tooling for automatic rebooting into the old version when checks are failed. Not sure how hard that is to do with Fedora CoreOS.

Guess I’m not sure what functions are missing in these implementations that would cause you to lose sleep.

With A/B-partitions, you can't really end up with a corrupt root filesystem. With OSTree, you can.

(Of course, you can lose the data partition.)

It’s the same in spirit, but I just find the A/B partitions easier to reason about. To me it’s about minimizing factors.