On Thu, Dec 3, 2020, 4:11 PM Colin Walters <walters@xxxxxxxxxx> wrote:
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).
Yes.
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.
Also yes!
> 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.
Right. It's not a property inherent to the tool you use to build though. "Could" means something else could do that as well.
> 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.
There are still interfaces between the container and the host. They can still break things. I do agree that ostree and the deployment model coreos is using as a host has really good mitigation for application stability though.
Outside of that, if one were to run applications directly on the host, there is a larger surface area that can break. I think it is interesting to see what enterprise distros accomplish around this problem and where they fall down. Fedora is even further away in this regard, but that's a conscious choice of the project.
josh
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
