[jpalomaki]

What I would like to do is use my phone as portable storage device and then plug it in to external processing unit and boot from my phone. The external processing unit could be desktop computer, laptop or tablet.

The reason? When sitting behind my desk at home or office I don't like to be limited with the mobile CPU. I have the required kWhs to power a proper CPU, GPU and run 64GB of memory. I also don't want to run separate computers on each location, because keeping these in sync (OS settings, applications, databases etc) is painful.

Technically we are almost there. We can put reasonably fast flash storage to the phone. USB-C should provide enough bandwidth. On OS software side we would need some work to make plugging in/out convenient. I don't want to do a full reboot every time I "unplug" the phone from desktop processing unit and move it somewhere else. As I move between processing units I would like to keep my apps open, maybe just doing a hibernate/sleep and then waking the system up connected to a different processing unit.

This solution means double spending on CPUs and memory, but desktop hardware is relatively cheap.

[srcmap]

One solution is use rdnis over usb.

It allows ethernet connection over USB.

Once ip network is setup, you can easily run nfs, samba, vnc over that network interface.

A few years back when I worked on AOSP project, I dislike the tools from Android. I put a "ubuntu for arm" rootfs in a subdirectory inside a cell phone platform, chroot to that subdir. I have full ubuntu environment inside a cell phone. xfce4-terminal, ddd, nfs, samba - ~40k ubuntu packages all available with a simple apt-get install command.

As long as you have enough RAM, CPU cores, storage space inside a cell phone, it is very easily to setup.

If you keep the vnc server running, you can plug and unplug that cell phone to any desktops, thin client and your can instantly log back into the same GUI environment.

[theposey]

I think you mean RNDIS?

[jordache]

We really need robust USBC drivers.

Even Apple, being in the forefront of USB C connectivity, is vastly lacking in robust USB C operations. Plug in/out of usbc cables causes dramatically high crash rate on the new MBPs

[jonaswi]

Ah so I am not the only one! My MacBook Pro was regularly crashing completely when I unplugged my dock while it was closed. I now always have to wake up my MacBook before I unplug the dock.

[fragmede]

By "forefront of USB-C connectivity", you mean the new iPhones still use the proprietary lightning connector, to the detriment of progress.

[jordache]

first mass market laptop to be exclusively on USBC? Yeah if anyone, you'd get expect them to get the USB C stuff right...

But it wasn't the case. It's downright infuriating to use.

[mahrain]

Google could easily enable this on their Chromebooks, that run Android apps. Especially the ARM versions should be able to run the same code and use the same apps.

[dpark]

> I don't want to do a full reboot every time I "unplug" the phone from desktop processing unit and move it somewhere else.

How do you expect this to work? 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.

[emidln]

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.

[fragmede]

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.

[dpark]

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.

[clhodapp]

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.

[dpark]

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.

[npsimons]

> 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.

[markbnj]

> 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.

[Hello71]

CRIU

[digi_owl]

I seem to recall there is an app like that for Android, but it requires a rooted device.

Basically it presents ISOs over the USB connection as if they were storage devices, allowing them to act as boot media for a connected PC.

[d_k_f]

I just googled this, do you mean https://softwarebakery.com/projects/drivedroid?

Sounds rather nice, especially considering I've been installing various systems over the last few days and flashing images to a thumb drive gets old really fast.

Thanks for mentioning this, it'll probably save me a few hours in the future!

[digi_owl]

Yep, i think thats the one.

[nialv7]

This is a brilliant product glitch that will make developers cringe...