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

https://github.com/joshuaboniface/rffmpeg

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 240

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

[1] https://en.m.wikipedia.org/wiki/OpenMosix

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.

[0] - https://www.gnu.org/software/parallel/

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.