Actually, you probably could. If you write the hibernate image to a place using a machine-id of some sort. Imagine you have images like

    /hibernate/machine/5c76f5e0-9117-4e33-8093-9de2e2f1b6de
    /hibernate/machine/d755fe2c-2b13-4436-8a5b-ba3363b9c642

When your kernel boots up, it grabs its machine-id and looks for a hibernation image to map into its memory. If it finds one, great, you have an "instant wake". If it doesn't, you boot as normal. Now imagine that your kernel tries to mount a specific device to `/hibernate` prior to looking for hibernate images. Upon hibernating, it writes its image to its machine-id. You could easily share the disk between two machines (even of different architectures) and keep two separate hiberante images on disk. You wouldn't be sharing the processes, but you could share your data.

With a sophisticated enough setup, you could probably even dual-install binaries (although this would be much involved with ELF where you must have separate binaries compared to something like Mach-O) to something like /usr/bin_x86_64/ and /usr/bin_arm64/ and then use your shell to select your path. This might work on a system level, but would certainly work on a per-install basis manually.

Stick a hypervisor and (some sort of) NFS share in the mix to sidestep having to know about the layout of fs blocks on disk . Also, just extend the linux kernel ELF loader to know about fat-binaries to make the scheme work - there were proposed patches to accomplish this that were (unfairly) derided, but there's nothing fundamentally wrong with that proposal.

This seems like a very different end result than what was desired. All your in-flight app and system state is still unique to each machine you connect to.

Maintaining disk consistency would also be a nightmare as each machine is unaware that it’s sharing the physical disk with other machines and they’re all clobbering each other with conflicting writes. You “boot” on machine A and suddenly all the files it was reading/writing have changed unexpectedly.

That's true, but we're getting close: Linux ostensibly supports power-toggling and hot plugging CPUs, memory, and disks at this point. I think it's more focused on allowing VMs to be resized and replacing bad components in servers, but I know that some systems are already using some of this tech to improve power management and support better hibernation. I think there's still quite a ways to go to make graphical sessions robust enough to be suspended and then brought up on different hardware (I don't think things are presently set up to allow for changes to the pci controller and X sessions expect things to be pretty static, as evidenced by the hoops you need to jump through for switchable graphics), but we may get there if a major company ever decides to take an interest.

It’s probably solvable with enough resources. I don’t honestly know why anyone would fund this, though. The “let me plug my phone into random machines” crowd is pretty small. People who want roaming state are probably better served in general by cloud apps, which don’t require that the user carry a dedicated device to boot with.

> You can’t hibernate an OS and swap out all the hardware and expect it to actually wake back up. You’re going to have to do a full boot.

Have you actually tried? You sound like you're used to Windows where if you change a single piece of hardware the whole OS goes to pieces and needs to be re-installed or go through a painful process of driver searching. Considering I can (and have) literally moved hard drives between vastly different generation machines (granted, they were the same architecture), I don't think it's that far fetched to imagine Linux might actually resume from a hibernate with no issues on different machines. I've got some spare time this weekend, and I might just have to test this theory. Even if it doesn't work out, my experience with swapping hardware in Linux leads me to believe it wouldn't be that hard to add support for resuming from hibernate on different hardware. Sounds like a good college senior CS project to me.

> Have you actually tried? You sound like you're used to Windows where if you change a single piece of hardware the whole OS goes to pieces and needs to be re-installed or go through a painful process of driver searching.

Haha I didn't come here to be a win fanboy, but have you ever actually done this? I build all my own machines and I have removed a windows boot drive from a system, replaced the motherboard and all major components, put the drive back in and booted successfully without making any changes at all. I've done this on NT, XP and 7. Have not yet done it on 10. Some things will definitely not work right, and you will for sure have to update some drivers, but in all likelihood it will boot. It helps if you uninstall the board-specific drivers (chipset, etc) prior to the teardown, but I have done it both ways.

CRIU