Hi Kevin, On Thu, Jan 15, 2015, at 05:20 PM, Kevin Kofler wrote: > > * customize your installation by adding/removing packages (and if it were > not prevented, the customizations would not persist across updates), First of course, while that's accurate for the rpm-ostree technology today, the Fedora Atomic Host pairs rpm-ostree with Docker, which allows fully dynamic application installation. It's also possible to use privileged containers to affect the host. For the rpm-ostree side itself, a prototype of layered packages has existed for some time in https://github.com/cgwalters/atomic-pkglayer and will be much easier when rpm-ostree's libhif port lands. > * update individual packages, > * get new updates (including security fixes) as soon as they hit the > mirrors, without waiting for a new OS tree compose (every extra step in > the process unavoidably introduces a delay), > * get individual packages from updates-testing or directly from Koji, > * use packages from third-party repositories, unless they respin the entire > OS tree for you, Note that an interesting aspect of rpm-ostree is it allows switching between branches. There is presently an updates-testing repository (same branch name) for Fedora Atomic 21. > * save bandwidth by downloading the packages that changed, or even only the > deltas of the actual change (delta RPMs), With OSTree's "archive-z2" mode, it's one HTTP request per file changed. In some cases, this is equally or more efficient than even delta RPMs (if you look at CPU and storage consumption). Say for a package update where just one translation file changed. In some cases it's just OK, and in some cases (e.g. boost-devel's over 9000 header files) it's catastrophically bad. We have "static deltas" in the works which will be a very significant improvement. > etc. > You gain… nothing! Upgrades are atomic (press control-C when you want) and you can always roll back to the previous tree. Bear in mind that a dynamic Workstation scenario as you appear to have primarily in mind is about the last targeted use case. Beyond the Atomic Host for Docker scenario, I am aiming for the tools to be used in scenarios where you want to replicate an absolutely identical software state across many nodes. In that model, it's not Fedora assembling the trees, it's the downstream user. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
