Day: GNOME OS

As far as I can see, the 'stupid merge' strategy -- or a smarter one with custom merge drivers -- is the only sane approach. What's the alternative? As far as I can see, there is none other than some bizarre intent to avoid all systemwide configuration forever, which, as I said, is just not going to fly with virtually any upstream you don't already control.

Any system that retains configuration state in any way will retain the problem of merging it -- and systemwide state isn't the largest problem in any case, it's per-user state, which is far more mutable and often contains references to data that must not be lost (be that emails or financial info). What are you going to do, wipe everyone's dotfiles whenever a downgrade takes place? Keep the config with the earlier trees, so if you make a change after upgrading it's *lost* on downgrade? Neither seems even slightly sane to me.

What OSTree is proposing is somewhat unclear, but appears to require rebooting on *every single package upgrade* so as to switch into a new chroot containing that package. That means several times a day for me. Not a bloody chance am I letting something like *that* near any of my systems outside a VM: it is transparently ridiculous and optimizing for a very few programs that might need to take extra measures to avoid being broken by updates happening underneath them, like Chromium, yeah, already *did*, so it is clearly not impossible: the zygote is also not exactly rocket science, weighing in at well under a thousand lines of code).

Now maybe laptops don't mind being rebooted this often, but a server with NFS-mounted home and scads of daemons and remote users relying on it, no way. (And that's where I do most of my work, upgrading and downgrading everything but the kernel when necessary with nary a hiccup, and no reboot-associated state loss. Yes, I know this setup is 'obsolete' now in the brave new Web 3.0 world where everyone uses horrible proprietary web services rather than anything like shared filesystems, but it meant I and some friends could band together and buy one big RAIDed box with ECCRAM that none of us could otherwise afford, and it means lower power costs than each of us owning a medium-big box.)

What's bizarre is that you reference nixos, which does most of this right (and which I am not associated with in any way, despite the coincidence of names: nixos *does* do some things wrong, including, last time I looked, paying no attention to the fact that most shared library upgrades do not break compatibility) -- and then you go on to propose a system which is as far as I can tell worse in every way in which it differs from nixos. Why?!