Program/process migration was a thing in the 1980s but was largely abandoned and ultimately replaced in the 2000s by VM migration, which solved the problem of migrating OS and network state by migrating the entire OS and network stack (though there is still some complexity regarding IP forwarding when a VM moves to a new physical network, as well as the annoying problem of data access potentially becoming non-local and therefore much slower.) But VM migration always struck me like hiring a truck to haul your entire house to the grocery store.

Now that containers are supplanting VMs, we've largely abandoned that migration capability. Instead the approach seems to be to make containers disposable, spinning up a new container and shutting down the old one. Migrating minimal, per-application VMs is still possible but not very popular.

Gate reduces OS state and cleverly moves across CPU architectures by leveraging webasm, but IP address forwarding is still a pain across networks.

It always occurred to me that something like this would be doable (even with older webasm-like systems like NaCl), but the network/IP forwarding bit and non-local storage problem still seemed like it might make it more trouble than it was worth.

Nonetheless, I would like to revive the approach of a distributed OS on a cluster of machines where you wouldn't really care which machine your code was actually running on, and could easily add more compute/memory/storage/interconnect in a modular manner. Live hardware and kernel upgrades seems like a nice feature as well.