Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The u-root CPU command

book.linuxboot.org

Post reply on HN
Print view View original

11–19 of 19 posts

Re: The u-root CPU command

#11

Post by amelius »

lmz wrote: post #4
dark-star wrote: post #3

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 y…

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

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

Re: The u-root CPU command

#12

Post by amelius »

LanternLight83 wrote: post #2

Awesome! This write up is satisfyingly detailed. Prior work in this space includes Plan9 of course, as well as the python project Outrun, which has it's own RPC-based FUSE FS: https://github.com/Overv/outrun Other approachs to deployment in particular include the functional package managers Nix and Guix, which can create lightweight application images, and could probably be cobbled together into some sort of remote e…

Are you saying that outrun's cache after one or more runs of e.g. ffmpeg could be zipped, and turned into a standalone package?

Re: The u-root CPU command

#13

Post by wrigby »

dark-star wrote: post #3

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 y…

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.

Re: The u-root CPU command

#14

Post by stragies »

So where does the 9P support in the remote linux machine running `cpud` coming from to mount `/tmp/cpu` ?

If kernelspace, would it not require the target machine to already have that module? If Userspace (= cpud contains an implementation of 9P client), won't that require at least the fuse kernel module present and loaded on the cpud remote machine?

Re: The u-root CPU command

#15

Post by stragies »

TazeTSchnitzel wrote: post #5

I found this a bit too much detail to understand the concept well. Is it basically SSH but with reverse file sharing: you connect to an SSH server and run commands there, but with the client's filesystem?

... but with a customizable/composed view of any combination of folders present on the client filesystem.

And other processes on the remote system can't look into your mounts.

Re: The u-root CPU command

#16

Post by amelius »

wrigby wrote: post #13
dark-star wrote: post #3

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 y…

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.

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.

Re: The u-root CPU command

#17

Post by LanternLight83 »

amelius wrote: post #12
LanternLight83 wrote: post #2

Awesome! This write up is satisfyingly detailed. Prior work in this space includes Plan9 of course, as well as the python project Outrun, which has it's own RPC-based FUSE FS: https://github.com/Overv/outrun Other approachs to deployment in particular include the functional package managers Nix and Guix, which can create lightweight application images, and could probably be cobbled together into some sort of remote e…

Are you saying that outrun's cache after one or more runs of e.g. ffmpeg could be zipped, and turned into a standalone package?

I suppose that's hypothetically possible, but no, it's not been implemented, and that's why I say that the intro seems to come at this from an odd angle-- I don't see u-root's CPU doing that either, despite the comparisons to static linking and other application packaging systems.

Re: The u-root CPU command

#18

Post by wrigby »

amelius wrote: post #16
wrigby wrote: post #13

Earlier quoted context omitted.

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.

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.

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.

Re: The u-root CPU command

#19

Post by lmz »

amelius wrote: post #11
lmz wrote: post #4

Earlier quoted context omitted.

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

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

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.
Post reply on HN