A report from the 2022 Image-Based Linux Summit

(Yes, I know this - and I'm pretty sure you know I know too ;) But, I know we're also conversing with an audience so some repetition is needed unfortunately)

> it simply means that they sit in a different place on the wide spectrum of image-based Linux, with significant enough differences to be meaningfully distinguishable.

Yes! We're in agreement. There's lots of nuances between different points on that spectrum. And a lot of space to share knowledge and approaches across them.

Security is also (as you know) not a binary thing. Personally, I think one of the biggest problems in our industry in general is people *not updating the operating system at all*. Switching to "the operating system auto-updates by default" was one of the big changes from the original Container Linux - and we've carried that forward in both Flatcar and Fedora CoreOS. It's actually a pretty profound difference in practice - I blogged about this but basically I think there's a strong sense of "responsibility" for updates that shifts from "I typed apt|dnf|whatever update and it broke, so it's my fault" to "the system just fell over, it's $OS's fault".

On this topic, I think "unlocked" image based systems (like pulling btrfs snapshots, snap and ostree, etc.) having the properties of e.g. transactionality and offline updates (not disrupting the running system) provide a very meaningful improvement to security from *this* aspect. Not to mention the "we tested the update image server side and you are bit for bit reproducing it".

Another way to say it is, these properties are also very meaningfully distinguishable from traditional package based systems.

What I'm arguing at the core is: s/image based/dm-verity based/ in the original sentence. I also would tend to use the term "locked" or "sealed" when talking about this because honestly "image" means too many things already.