Hacker News Reader

Comment by fuzzer37 | Hacker News Reader

I can totally imagine wanting to work on a thin client on your home network over a 1gbps network connection. Hell, if you optimized specifically for this and ran a 10gbps line right from your thin client to the server, it would be blazing fast.

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.

View on HN

The thing is you need a client fat enough for normal use but too thin to run the command in question.

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?

ssh and RDP doesn't easily extend to live workload migration or other forms of location transparency.

Well for starters, no scp command at the beginning and end of each job. I'm sure you could work out an alternative solution, this is just one such solution.

Yeah, this feels like a good solution for when you only occasionally need to get the remote machine to do the work, e.g. the macbook example for simple dev work. In that case it probably is more convenient.

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.

Per the readme, architectures aren't cross-compatible, so you can't run commands from an x86 box on an ARM box (and presumably vice-versa). That would rule out the pinebook and most SBCs as potential use-cases.

The thin machine could be your laptop where you'd occasionally want to do a heavy operation on a workstation or server on the data you happen to work on on your laptop. Sounds like a decent usecase.

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.

The said method doesn't support cross-platform executions (at least not without some qemu hackery).

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

I believe you could get a similar result using Jellyfin and rffmpeg [0]. From a quick glance it seems like it should work from ARM->x86

https://github.com/joshuaboniface/rffmpeg

A 4k 60hz 30bpc display requires 14Gbps to feed. The thin client thing is such a meme, all the computing requirements continuously scale - there is nothing "seamless" about them.

I agree that computing requirements scale as we go, but surely you don't need 4k at 60Hz to browse the web now? I regularly play games using steam link now and while it's not the full quality and framerate, it's just convenient (and cheaper than having a full desktop pc in every room). Thin computing seems much more seamless and workable now than it did in my college years with Sun thin clients.

A ton of tasks don't require any graphical data streaming, in fact aside from gaming most resource intensive applications can be run in the terminal and thus easily offloaded to another machine. Text editors are already getting distributed code checkers via LSP, it wouldn't surprise me if in a couple years we could run the whole backend of IDEs on another computer and the local part can be more lightweight than most websites.

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.

> it wouldn't surprise me if in a couple years we could run the whole backend of IDEs on another computer and the local part can be more lightweight than most websites.

Checkout the official SSH/Docker/WSL Remote Development extensions to VSCode

Not surprisingly, emacs has been able to transparently do this for a long time, now.

Granted, this all falls flat when your network connection is garbage. :(

Also could use some more polish around handling SSH connections; I often manage to lock up TRAMP when I step away from the computer for 5 minutes. It's something that can probably be fixed with the right ssh_config/sshd_config, but I can't for the life of me figure out the right incantations.

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

For me, I'm just fighting rural networking. Ever since I setup control master for my ssh, I have not had too much issue with the ssh.

I still like running emacs locally.

> It's something that can probably be fixed with the right ssh_config/sshd_config, but I can't for the life of me figure out the right incantations.

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've finally got my emacs setup just how I like it. But my gigabit internet connection isn't fast enough for a text editor these days..."

If only I had gigabit... 4g lte that constantly drops is not fun.

Meanwhile I have a 4G modem at home because it came with higher stability and more than double the bandwidth compared to a similarly priced cable connection. Sometimes the more traditional telecoms are working really hard at pulling an Intel.

To be sure, this is my best option at the moment. Can't get any cable connection.

I wrote the "more lightweight than most websites" part for a reason. VS Code is already horribly sluggish on my Thinkpad with i7 CPU, I would go totally insane trying to run it on anything referred to as thin client. Might as well go for a full-blown IDE at that point, some of them are actually trying to optimise for low-latency text input.

> if in a couple years we could run the whole backend of IDEs on another computer

It’s been done. Look at AWS Cloud 9, or Eclipse Che.

I think if you were to send the raw frames sure, but wouldn't they just send the delta of the frames (only areas which changed) -- with some sort of compression algorithm and parameters like VNC does?

SPICE solved this (years ago in fact) by doing various sorts of compression, including detection of video, and streaming that over the network. (https://www.spice-space.org/features.html)

Reply on news.ycombinator.com