On Thu, Dec 3, 2020, 4:11 PM Colin Walters <walt...@verbum.org> 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
