Outrun: Execute local command using processing power of another Linux machine
github.com
github.com
I may or may not use this program but I did definitely learned another cool thing about Linux just now and that would most certainly be useful to me sometime in the future in an all together totally different context.
Thanks for the software and the explanation!
Kudos to the author, and I hope I'll see more of this everywhere.
I really think this is a clever hack, but I'm not sure how useful it is. Is it really good for the transcoding example? I could see that being good if the remote machine has a better GPU, but I'm struggling to see how this could work for other use-cases. Maybe compiling (which was one of the main use-cases behind Sun's SGE)?
I do most of my work on HPC clusters, so moving compute out to remote nodes is something I'm very interested in... and I'd love to learn more about what kinds of workflows the authors had in mind.
Another application I could see is putting a loud server into a closet somewhere and just running network cables to it. Make a 4 GPU render node, then just send jobs to it over your thin MacBook.
For the workflow you describe, why not just ssh or RDP into the beefy machine from the thin client? Wouldn't that make more sense?
If you were relying heavily on the remote machine, maybe using a pinebook pro or something, ssh or rdp might make more sense.
It's cool to have more options though, I have considered workflows like this before especially in the context of replacing my laptop with something like a pinebook.
Of course running it there will work too but will need more setup. So the occasional thing is what really makes this worthwhile.
It's a bit of a niche but I see the benefit.
I can totally see how I would use this to transcode videos from my NAS using my main workstation CPU since both are connected through a 10gbs switch though (need to figure out how to integrate this with Plex transcoding flow).
Then you only need to drive a 4k screen for displaying a desktop and maybe video playback, which can already be achieved with a passively cooled Raspberry Pi.
Checkout the official SSH/Docker/WSL Remote Development extensions to VSCode
Granted, this all falls flat when your network connection is garbage. :(
For now, I just habitually do M-x tramp-cleanup-all-connections whenever I stop actively working with remote files, and let Emacs reconnect automatically when I save a remote file or refresh a remote folder listing.
(Incidentally, half of my use of TRAMP went away once I managed to configure a 256-color terminal on my sidearm; with that, Emacs in terminal mode looks almost indistinguishable from a GUI session.)
Have you tried something like this? It does a common TCP/IP socket for each remote host and does application-level pings every 4 minutes to keep the socket active. Solved most of my "stay connected" issues.
Host *
ControlPath ~/.ssh/cm-%r@%h:%p
ControlMaster auto
ControlPersist 10s
ServerAliveInterval 240I still like running emacs locally.
It’s been done. Look at AWS Cloud 9, or Eclipse Che.
On the other hand, OP's project is exactly an linux/posix version of the same as what Plan 9 was designed to do and has been doing.
I couldn't remember setting up NFS or anything like that - apparently openMosix did some tricks too: http://www.firewall.cx/linux-knowledgebase-tutorials/openmos...
Which is why I'm curious about the applications they had in mind. I know that my workflow isn't typical for most people, so hopefully others have better uses in mind.
For me, I just submit adhoc jobs to SLURM and call it a day. Not everyone has access to an HPC cluster or is comfortable setting such a system up for a small, home cluster.
Anything (like this project) that makes HPC-like processing more accessible, I'm interested in.
Definitely, but, there are also many workloads (and situations) where it doesn't and this works great.
If I have to do those steps locally, I can't be gaming. That's not cool.
Still, kinda makes more sense to just fuse/smb the videos and have the remote processing node pull, processes, push.
Not if:
a) your network B/W is higher than your local disks (not as unusual as you might think, spinning medium is awful slow)
b) the app you're using chunks up data in a reasonably efficient manner so as to not get bitten by latency issues (ffmpeg encoding likely meets that bar).Yes, the README addresses this:
> File system performance remains a bottleneck, so the most suitable workloads are computationally constrained tasks like ray tracing and video encoding. Using outrun for something like git status works, but is not recommended.
The problem is that your task will still be limited by power of a single machine.
You need means to run a task across more than one server, and preferably great many.
It's possible, but completely impractical to run a shared memory system across network.
If somebody figures out how to do that usable in practice, and without complete rewrite of the program that will be really impressive, and an ACM medal material.
HPC programs which do use shared memory, were written with network latency in mind from the start.
Edit: yeah, I posted too fast. I am not their use-case.
A shell script that simply launches a new process on the most idle node of a network would be enough to get back some of that experience. Live migration would be even better, almost perfect for that. Hope some day I can easily build a bewolf cluster out of my ARM SBC's with an experience similar to the old days of Cluster-Knoppix.
I really wanted to set up a university computer lab such that when computers are idle, their CPU cycles are donated to some massively parallel simulations. Worked great on small scale, but I moved on before we implemented it on a larger scale.
https://github.com/nelhage/llama
> Llama is a tool for running UNIX commands inside of Amazon Lambda. Its goal is to make it easy to outsource compute-heavy tasks to Lambda, with its enormous available parallelism, from your shell.
But this could be very useful for ad hoc, or just spur of the moment things. Let's say I have a few servers that I have access to. Whenever I need to do something computation heavy and it could be something different everytime. Sometimes transcoding a video, sometimes compiling a library in rust. I just outsource them to the servers and keep using my laptop doing other stuff.
Yeah, once you get past ad hoc applications, one common way to set this up is to setup a cluster/batch scheduler. This lets your jobs be run on an available node. You don't get the same chroot/fuse filesystem voodoo, but once you have a cluster, then an NFS mount for applications is a common setup.
cpu/rcpu does the remote cpu session which can act like an ssh in a way. Plan 9 doesnt do "remote" control but instead imports/exports resources directly. Everything is done through 9p. Very zen OS.
Plan 9 was designed fro the get-go to easily build and run on different architectures. static linking helps and you do all your communication over 9p so you don't care if the machine is arm, power, x86, mips, etc. The protocol is platform independent and you just rpc everything. So instead of poorly bolting a security library to your program, you let someone experienced with security write a server and let it do the hard stuff. Then you statically lnk a little c lib into your code that just talks to the server.
And file servers are just little micro services running on your computer. plan 9 is more cloud ready and distributed than any poor excuse of an os nowadays.
The static library fetish was one of the things that helped keep Plan 9 marginal (along with the generalized NIH or "Invented Here But By Bjarne So Who Cares" attitude).
If you actually took the time to study plan 9 you would understand the architecture and why dynamic libs are not necessary. The idea is to move that logic into another program where it can run in its own namespace, in isolation. You then use pipes or 9p to communicate between them.
I've been frequently thinking over this past decade that an average consumer level distributed computing is the biggest causality of closed, proprietary software/hardware.
Consider compressing several terabytes of disjoint data to a zip file using compute resources of pc, smartphone, tablet etc. at the same time. I've seen some subtle attempts to make use of distributed computing in consumer space like Apple's Compressor for video encoding.
Of course distributed computing has been a staple in scientific research for a long time. I personally use dask, modin for some data exploration activities when I feel the urge for some distributed computing. Wanted to checkout Julia's distributed computing capabilities but it required similar setup for all nodes but I'm interested in cross-platform(architecture) only.
Common network storage access removed most of the headache with distributed computing in my explorations on that subject(OP is using common network share to execute programs as well).
Silicon valley season 2 last episode and season 3 first episode, should do, to get this.
And if any of this makes sense: https://fenollp.github.io/faster-rust-builds-docker_host
That way during the build process you're only transferring the cwd around your Dockerfile (the build state) to the daemon, and it takes it from there.
Versus this that would be doing a lot of file i/o during the build process all back across the wire.
Actually looking at the (very good!) readme, I'm thinking that the most interesting part is the custom file system.
I've been looking for the "perfect" networked filesystem, and this is the first new effort I've seen that seems to check most boxes (not disconnected operation though, but that is tall order..).
The only other contender I'm aware of is coda: https://github.com/cmusatyalab/coda
And maybe openAfs: https://www.openafs.org/
But I never did get around to play much with either.
Maybe it's time for someone to build another system on top of foundationdb?
A long time ago I contributed to HTCondor, which permits long-running processes to be automatically shuffled between N computers: https://research.cs.wisc.edu/htcondor/
> No need to first install the command on the other machine.
and
> It must be installed on your own machine and any machines that you'll be using to run commands. On those other machines you must make sure to install it globally, such that it can be started with a command like ssh user@host outrun.
Not sure if the readme is just out of date, or if I'm misunderstanding the initial statement about the _other machine_.
I would love to use this as a regular user without needing chroot.
For people who work mostly on a laptop but have access to various fast, stationary machines, Overrun lets them use their CPUs and GPUs without tirades of "scp -r" or "rsync".
(Of course you should still rsync to your backup machines, but that's not necessarily the same box as your compute server.)
It's interesting how stuff that is totally common and considered so normal it isn't even mentioned is special elsewhere and can be seen as a novelty. The future not being distributed equally also holds for the IT world.
At my last job simply watching the logs in TravisCI via Google Chrome would slow my MacBook to a crawl.
At my new job my MacBook is fine until I join a Zoom meeting, especially if I try and screen share.
Anything I actually call from the terminal is optimized enough to never be a bother. If I worked in a space where it wasn't (big data, video transcoding, etc), I'd probably just run a powerful cloud instance and sync my code there.