that... is a really fucking cool idea. i mean, it's of limited utility in the sense that builds really should generally work most of the time & be reproducible,

that... is a really fucking cool idea. i mean, it's of limited utility in the sense that builds really should generally work most of the time & be reproducible, so even though there is a bit of wasted effort, bandwidth, etc. in running the same build in multiple places at once, it's not like the worst thing in the world... but it just feels like there have to be cool / "useful" scenarios where you want to distribute a thing, but not the environment, etc. required to build the thing. oh wait, that already exists: it's called "a binary"... lol. iono. i mean i guess if you have a process byte-for-byte frozen in time, you're a bit more certain (provably so? maybe?) maybe that when it is resurrected on some remote host that remote process and local process (as of t_freeze) are in ~"exactly" the same state? or if you continuously snapshotted a process while it was running, and then when it crashes you (hopefully) have a snapshot from right before when it crashed that can be replayed, modified, etc. at will? but that's a bit of a stretch, and there are simpler ways of accomplishing that for the most part... the only other thing i could think of is that this could allow you to run completely diskless servers, because you can just beam all the processes in, without ever having to "install" anything, beyond copying all the shared libs, etc. which i guess could get the "1 have one of these and i want 100 of them, in the cloud" latency down by an order of magnitude or two maybe.