7 ms·

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 ra

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.

stefan_ 6y ago
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.
- deleted 6y ago
  [deleted]
- junipertea 6y ago
  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.
- alpaca128 6y ago
  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.
  - herbstein 6y ago
    > 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
    - taeric 6y ago
      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. :(
      - TeMPOraL 6y ago
        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.)
        taeric 6y ago
        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.
        martinflack 6y ago
        > 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
- mrmuagi 6y ago
  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?
- rwmj 6y ago
  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 https://www.spice-space.org/features.html)
jayd16 6y ago
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?
- zozbot234 6y ago
  ssh and RDP doesn't easily extend to live workload migration or other forms of location transparency.
- fuzzer37 6y ago
  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.
  - eightails 6y ago
    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.
    - fuzxi 6y ago
      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.
- GekkePrutser 6y ago
  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.
liuliu 6y ago
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).
- eightails 6y ago
  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 https://github.com/joshuaboniface/rffmpeg

stefan_ 6y ago

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.

deleted 6y ago
[deleted]
junipertea 6y ago
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.
alpaca128 6y ago
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.
- herbstein 6y ago
  > 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
  - taeric 6y ago
    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. :(
    - TeMPOraL 6y ago
      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.)
      - taeric 6y ago
        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.
      - martinflack 6y ago
        > 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
mrmuagi 6y ago
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?
rwmj 6y ago
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 https://www.spice-space.org/features.html)

jayd16 6y ago

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?

zozbot234 6y ago
ssh and RDP doesn't easily extend to live workload migration or other forms of location transparency.
fuzzer37 6y ago
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.
- eightails 6y ago
  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.
  - fuzxi 6y ago
    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.
GekkePrutser 6y ago
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.

liuliu 6y ago

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

eightails 6y ago
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 https://github.com/joshuaboniface/rffmpeg