Ah I see. I totally missed that.

So that's quite interesting. Because on the host I generally run Ubuntu 18.04. Because I know how it works and can ensure it's secured and up to date.

Same with someone with familiarity with Redhat/Centos etc.

But installing a whole different OS?

Like I get it on niche Linux distros where people like packaging their desktop environments whilst pulling in Debian packages for everything else, for example.

But what's the advantage here?

There are a few advantages.

First is minimalism - it's designed to run containers.

Next is automatic, atomic updates - layers that comprise the entire OS are "pulled" and updated when the host boots, similar to how updates work with containers. Because updates are atomic, they can also be rolled back.

I think there is also built-in support for rolling updates across a fleet of host machines.

I find CoreOS a very interesting proposition, but because it's so different from other distros, there is going to be a learning curve.

Oh, I forgot one! The OS is read-only while the host is up, which is a big security and stability benefit.

Fedora CoreOS is read-only?

CoreOS Container Linux is not. But changes are not persistent over redeployment. That's nice for quick testing and development, but of course fatal should you do it in a production system. And of course not ideal for security.

Disclaimer: Edited for false claims. Hope, it's correct now...

Go look at /usr on Container Linux, where the actual OS lives. It’s literally mounted R/O. Binaries are symlinked from there, so it’s impossible to modify OpenSSL, etc.

How is root prevented from modifying it? (Readonly mount alone is trivial to bypass)

dm-verity mainly

https://coreos.com/blog/verifying-os-at-runtime.html

Bit more on dm-verity as it relates to appliance and non-appliance systems. https://blog.verbum.org/2017/06/12/on-dm-verity-and-operatin...

Btrfs will support cryptographically secure hash algorithms (sha256 and blake2) starting with kernel 5.5. I wonder if this is a suitable compromise over dm-verity, which can't be updated, and more conventional file system options? When I consider various use cases, Btrfs always results in EIO rather than propagating bad data to user space; compress=zstd:1 reduces writes, saves storage space, and can improve performance of slower storage.

There's also two interesting read-only options: read-only snapshots and read-only volume (via the seed flag), root can't write to either. Root would need to unset the flag first. A read-only seed can support writes via a volatile 2nd device, e.g. /dev/zram device, reboot and you get a reset. Or persistence via a partition. Either way a reset also resets filesystem state.

The entire partition is signed so the machine will detect it

I'm shipping a test appliance out this week but we haven't completely locked on a production OS. This feels like an interesting path. Host level data persistence isn't something I need or desire, so a RO filesystem is perfect. For $reasons I've been on an Ubuntu track (changed from Debian because of an official upstream LTS). My hesitation about Fedora is the fact that it's bleeding edge (ish) and doesn't have an LTS path (reasonably, bases in the design goal). The evidence is in they fact that the upgrade path is not expected to be smooth here.

I can eat a lot of shakeup in my own data center or cloud but a shipped box makes that a lot more problematic.

> I find CoreOS a very interesting proposition

I personally find CoreOS very confusing. None of the advantages you mentioned are a problem nowadays, for personal computing. I haven't heard of Debian, Ubuntu, or RHEL update that would bork the system in a long while. All of these distros are more than capable of running containers...

And, for corporate use? You'd use Debian + Kubernetes to take care of your needs, wouldn't you?

As I said, I'm left here scratching my head, thinking up usecases for this system.

> I haven't heard of Debian, Ubuntu, or RHEL update that would bork the system in a long while. All of these distros are more than capable of running containers.

Fedora CoreOS is designed to have the smallest possible attack surface out of all operating systems currently capable of hosting containers.

Unlike Ubuntu, Debian, and CentOS, Fedora CoreOS doesn't contain packages that aren't required for hosting containers, and is automatically kept up-do-date without any manual interventions.

Just like Chromium OS on PCs, Fedora CoreOS on servers eliminates the need for "dist-upgrade", and thus reduces risks and increases reliability.

> And, for corporate use? You'd use Debian + Kubernetes to take care of your needs, wouldn't you?

CoreOS is designed for these workloads. For example, with OpenShift 4 (Red Hat enterprise Kubernetes) the masters run on RHCoreOS and the worker nodes have the option of running on RHEL or RHCOS. You can end up having your entire Kube platform running entirely on CoreOS, either bare-metal or virtualized.

Fedora CoreOS is big as OCP uses RHCOS. OKD (the community version) needed its own platform and FCOS is that platform.

CoreOS is designed to remove everything you don't strictly need to run containers and to allow for automatic-upgrades across multiple machines (ie: don't reboot everything at once). That means you have a minimal amount of things that can be hacked and easy automatic updates for the rest.

In the OpenStack world you can use the old Fedora atomic and container Linux to automatically spin up k8s clusters using OpenStack heat and OpenStack magnum.