On Thu, Dec 3, 2020, at 2:14 PM, Josh Boyer wrote:
This seems more split on the OS consumption model to me, rather than
the tools to make it. The end user shouldn't care at all about what
tools make it.
I've been meaning to write a longer blog post on this but briefly:
How you build software gets very entangled with how you ship it, and how you ship it gets
entangled with how users consume and manage it. It's really this dynamic that has
created so much inertia around traditional dpkg/rpm/etc., and also is already happening in
the container ecosystem too around Kubernetes (the fact you don't do in-place updates
there but schedule a new pod deeply impacts configuration/management).
The fact that FCOS releases are uniform and constant and biweekly feeds into a whole lot
of things across that stack. The concept of a "stream" was brought up and
that's quite central too, along with the Cincinnati staged rollout system.
They just want to install their OS and keep it updated
and have those updates NOT BREAK their systems or apps. ostree based
OS updates have some inherent benefits that a per-package update model
lacks and I find it intriguing because you could test a whole OS
update stack to at least ensure it's consistent within itself.
Not "could" - that's the basis of our technology stack and how we think and
operate.
Whether that happens or not is up to the creators of the OS. You
can
do the same with bodhi but we... don't. Neither set of tools can
really claim to validate the updates won't break third party apps
though.
We expect applications run as containers.