The u-root CPU command(book.linuxboot.org) |
The u-root CPU command(book.linuxboot.org) |
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 environment replication even across architectures. As I read on, I thought less about how this compares with Guix in regards to application/environment packaging and more about how these things could be glued together in interesting ways, because I think the intro leads in through slightly off-label examples, if that makes sense. Application packaging isn't what this addresses at the end of the day, but it's no less fascinating for it.
And other processes on the remote system can't look into your mounts.
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?
Even just having my own dotfiles (.vimrc especially) present on a machine that I'm troubleshooting is huge.
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.
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?
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.