On Sat, Apr 5, 2014 at 12:28 PM, Les Mikesell <lesmikesell at gmail.com> wrote: > > If you need that, you are probably already block-replicating. Right; block replication has its advantages. There's a lot of projects out there for this. I know of a Fedora/Red Hat project around this a long time ago: https://fedoraproject.org/wiki/StatelessLinux The more modern version is the ChromiumOS updater, with its A/B partition scheme. It's widely deployed in Google Chromebooks. But OSTree is much more flexible than traditional block replication because: 1) It doesn't require doubling disk usage of the OS (the hardlinks deduplicate) 2) Even more crucially, it allows you the freedom to use whatever filesystem and block storage you want on each client. For example, you can install the "fedora-atomic/rawhide/x86_64/buildmaster/base/core" tree on one machine using plain ext4 with a single big /, and another on XFS-on-LVM, perhaps with thin provisioning if you like. You can be confident that any thinp snapshots or whatever that you make won't be interfered with by OSTree. > But how > do you deal with the necessary differences in that case? There is > always some ugly overlap in software/system/local configuration that > is hard to abstract away. This is another key point - in OSTree you have a writable /etc and /var. In particular the fact that a 3 way merge is applied to /etc helps make the system "feel like" Unix, in contrast to more basic block-level systems which are unaware of the semantics of /etc. > And yet none of them give you the ability to build/test one system, > then let someone else duplicate it easily and track its tested > updates. Which is what pretty much everyone needs to do if they have > multiple machines, and it would give people with no administration > experience the ability to have machines with software managed by > experts, almost for free. The more I think about your suggestion the more it feels like the "staging" model, which is clearly widely used inside individual organizations. Anyways, there's clearly a lot of ways to build, deploy, and manage systems =) I think the rpm-ostree model is a unique middle ground between traditional packages on the client and image-based updates - not for everyone, but some here might be interested, and I'm happy to hear any other feedback!