[dark-star]

This sounds interesting, but I think I don't fully understand the use-case here. I mean I get it, you "cpu in" to another system, and the session you have there will transparently mount all your /home, /etc, /usr, /bin and so on from your system to the remote host.

What are some actually useful commands to use with that? I mean if all you're doing is remote-execution of bash, you could just start bash locally since your filesystem looks the same anyway? If you run vi through that tool, it can edit the files that you have on your host (because all directories are "passed through"), so why not just run vi on your host?

Edit: two usecases that I could think of where this is useful, but both don't really work I guess: - If you have a very small flash-constrained system (think router, embedded, IoT) ... but these are usually different architectures (i.e. not x86_64) so this wouldn't work - The example from the article, if you have a different Ubuntu version running in a container than on your host. But this would create a "hybrid" Ubuntu after CPU'ing in, since many directories simply come from your host, and only some stuff is from your container. I don't think this would be very useful?

[lmz]

Maybe the "cpu host" is faster and you run a computationally heavy command there, or it's closer to some resource (e.g. you wrote a script to search for some data inside S3 and want to run it on an EC2 instance). Maybe it's something with specialized hardware that you'd like to control (I see /dev is not forwarded).

[amelius]

Isn't it dangerous to use a /dev and /etc from two different systems at the same time?

[lmz]

Yes, if you plan to run disk management commands. Otherwise I don't see what commands would access machine specific device files on a regular basis anyway.

[wrigby]

One of the use cases I can think of is "I have a set of scripts (shell, GDB, etc.) that are useful when troubleshooting servers, and I want to be able to use any of them at will once I've connected to a machine that's broken."

Even just having my own dotfiles (.vimrc especially) present on a machine that I'm troubleshooting is huge.

[amelius]

But how can you troubleshoot the remote machine if you're seeing your local filesystem?

Everything you run to test whether the remote is working uses only the CPU of the remote machine, not its files, which is where the problem usually is.

[wrigby]

Hah, that's what I get for skimming the article and assuming I knew what was going on here.

With that said, I guess the quickest thing that comes to mind is wanting to run my Jupyter notebooks on a machine with much beefier CPU and memory than my laptop. I was recently working on some lightweight ML stuff, which required training 3 SVR models. Each model really only took 30 seconds to train on my laptop (with a small, synthetic training set), but if cpu was in my workflow, I would have just done it on a beefier machine and saved a minute or two of time every time I wanted to test a new iteration.