The purpose of C/R isn't sandboxing, it has nothing to do with it. It's about managing internal state and data structures from an external agent. C/R enables c

The purpose of C/R isn't sandboxing, it has nothing to do with it. It's about managing internal state and data structures from an external agent. C/R enables complete persistence by duplicating a process from its image, which can cut initialization and startup times by orders of magnitude, and resume service from an exact position with zero downtime, and not just basic mechanisms like socket superservers. It lets you back up process state at any arbitrary moment, send it over the network, recalculate and reexec immediately and then thaw again for debugging it from that particular point. It just helps enable live migrations and zero downtime recoordinations with far less complicated redundancy schemes. This includes containers. On top of it being a universal save/pause button. Depending on the robustness of the image format, it can be made space efficient through deduplication. C/R is quite invaluable for any scenario that involves fault tolerance, high response times, tracking down difficult bugs, low startup overhead and so on. I'm surprised why it's still such an obscure technique. Besides, I don't think the primary use case here is even graphical apps (not that they don't work just fine). What you really want is a local indexed copy of all the execution environment details, like pipes, sockets, timers, ttys, timers, sigmasks, *fds, etc. for infrastructure.