On Sun, Apr 6, 2014 at 12:40 PM, Colin Walters <walters at verbum.org> wrote: > > But OSTree is much more flexible than traditional block replication > because: Is if flexible enough to scale 'down'? That is, is it something you would likely use to install your 2nd system if you only had 2 and had never used it before? Or your first system as a copy of something someone else already has running? > > 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. Does something mange the necessary differences during an install? And can it tell a hardware or local difference that doesn't change in an update from a software configuration item that would be software-version specific? Or do these still leave lots of odd special cases, especially if you aren't using VMs? >> 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. Yes, everyone with more than a few machines needs that - and large organizations need it so badly they build their own in spite of the cost and difficulty. Which is why I think it is so odd that the stock tools aren't designed to do repeatable updates in the first place. Why is it so difficult to tell yum to just ignore anything added to the repositories after the staging system update was done and reproduce that same update to a production system after your tests are complete? > 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! It is very unlike the unix philosophy to need a lot of ways to do something. Why isn't there one tool that does it right in the first place - and can work appropriately for 2 systems the same as 2,000? And more annoyingly, why does every variation of the simple idea of installing and tracking versioned updates need different and complex infrastructure for the package repository and invent a new configuration and command language that is incompatible with anything used before or the source management systems that do essentially the same things? -- Les Mikesell lesmikesell at gmail.com