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.
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.
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.
Appears to be a continuation of that project under a different name. Someone else pointed out that this one was acquired my Microsoft in 2021, but does appear to be receiving regular updates so it’s not sunsetted yet.
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.