On Tue, Sep 8, 2015 at 10:00 AM, Owen Taylor <otaylor@xxxxxxxxxx> wrote: > *However* - I think it's important to realize that the interesting and > hard part of the project here is *not* using rpm-ostree for the base > operating system. Putting Fedora Workstation images into an ostree > could be done today; getting installation and updates to work is a few > weeks to a few months of work but something we could very plausibly > have done for Fedora 24. But what would we have then? Something that > almost nobody would want to use ... certainly not developers. We'd have > taken away the ability to freely mutate the operating system, and > provided any sort of replacement. I have thought abstractly about and interim approach by leveraging the part of ostree that understands the "trees" state of an OS, and therefore manage the bootloader configuration, without the rigid immutability aspect you refer to. That's a derivative of ostree + lvmthinp and/or Btrfs snapshots. That gets us rollback with conventional mutability but can also help limit slew. That might be too much work for its implied limited lifespan until the app dev and deploy angle for Atomic Host is sorted out and matured. It also might overstate the importance of rollbacks. Afterall, we've never had that and the world hasn't ended. -- Chris Murphy -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
