@7c36db82 I think it IS more than a gimmick at the moment. It is more like a safety belt or airbag right now. I don't make *ANY* plans that involve deployment of either. Yet I regularly see those as the "defacto strategies" if "anything should go wrong". ;) 

 @7c36db82 Just to circle back to my very original statement: the amount of nuance we needed to get out of our systems here goes way beyond what I experience the majority (semi- or even non-technical) people understand and then extrapolate from about rollbacks ... ;) 

 @7c36db82 From my perspective the theoretical argument is not coherent with my experience. You might be overestimating what complexity you can deal with in an automated fashion. For example, one quickly ends up in merged sets of expressions that are contradictory - in essence a (very rough) Goedel statement where everything complex enough to be interesting will be breaking in interesting ways due to self-referential properties and people outsmarting your assumptions. 

 @7c36db82 That sounds too simplistic/hopeful. I don't think we have the necessary low level operations to create a *GENERIC* solution that allows atomic/synchronous snapshots at arbitrary scale. Also: rollbacks are intended for fast recovery. If I have to dive into analyzing NixOS expressions, the "fast" is out of the window. Roll forward may allow you to fix it quicker on an application level and pay attention to the outside world that your application already  communicated with. 

 @7c36db82 That's the point where you're basically at atomic snapshots which stuff like Ceph, LVM and other levels of abstraction can do. However, this gets even harder once you consider distributed data like OpenSearch and in addition: once your application modified state in the "outside universe" you can't roll that back without consequences :tm: