[brancz]

Yes this is a direct fork. I happened to have been a CoreOS Berlin employee and know the kinfolk folks (now acquired by Microsoft) that did this fork after the Red Hat acquisition very well. I’m very glad they did, a lot of things I liked a lot about CoreOS container Linux unfortunately didn’t make it into Fedora CoreOS.

The kinfolk folks also run the update server to perform auto updates.

//edit

Continuation wouldn’t be a wrong word either as it all coincided with the Red Hat acquisition. But I guess “fork” is correct since it’s under a different name.

[avtar]

> a lot of things I liked a lot about CoreOS container Linux unfortunately didn’t make it into Fedora CoreOS.

Like what?

[brancz]

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

[dilyevsky]

It uses ostree but it’s read-only root partition and changes only take place on reboot unless you pass a special flag

[avtar]

Gotcha. Thanks for clarifying.

[jzb]

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.

[yencabulator]

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

[brancz]

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.