3 ms·

Remote desktops can work great if you constrain and structure what you do in them. For me, this means not using traditional desktop environments like gnome/kde

by danans 4y ago

Remote desktops can work great if you constrain and structure what you do in them. For me, this means not using traditional desktop environments like gnome/kde/windows/macos, but instead a full screen tiled window manager (i3 in my case) with different virtual desktops assigned to different work items. Each virtual desktop is split in half between the IDE (vim in my case) and a terminal session for the code under development in that IDE. That's it. No silly weather or chat widgets (all that lives in my local laptop's traditional desktop). The result is I never have to search for a dev task related tab or be unsure if the code I'm running is the code I'm editing (which can happen if you are working on many concurrent changes). I liken the setup to the keyboard-driven text terminals you still see in some shops, hotels, and airport check-in desks. In general, I think smartly crafting your workflow matters a great deal more than the particular tool you might use.

yjftsjthsd-h 4y ago
> Each virtual desktop is split in half between the IDE (vim in my case) and a terminal session for the code under development in that IDE. That's it. No silly weather or chat widgets (all that lives in my local laptop's traditional desktop). I don't disagree, but if your editor is vim and you run/test in a terminal, why not do the whole thing in tmux in SSH?
- danans 4y ago
  > you run/test in a terminal Some of the software has a GUI, and some of the tools (i.e. unit test runners) display their output in a locally (to the remote desktop) running web app viewed via a browser. If I were doing strictly text-based work, I might use tmux, but to be honest i3 scales down so well to the text-only use case that I probably wouldn't bother, since there is no upside to doing so.
  - aleksiy123 4y ago
    For tools with webapp output. You can use a proxy to access it in your local browser. Something like ngrok would work well. The advantage of having tools with APIs
    - danans 4y ago
      Sure, but it's a lot easier just to open a browser in the remote desktop session. It's not like the FPS of the browser matters much when looking at unit test results.

by danans 4y ago

yjftsjthsd-h 4y ago

> Each virtual desktop is split in half between the IDE (vim in my case) and a terminal session for the code under development in that IDE. That's it. No silly weather or chat widgets (all that lives in my local laptop's traditional desktop). I don't disagree, but if your editor is vim and you run/test in a terminal, why not do the whole thing in tmux in SSH?

danans 4y ago
> you run/test in a terminal Some of the software has a GUI, and some of the tools (i.e. unit test runners) display their output in a locally (to the remote desktop) running web app viewed via a browser. If I were doing strictly text-based work, I might use tmux, but to be honest i3 scales down so well to the text-only use case that I probably wouldn't bother, since there is no upside to doing so.
- aleksiy123 4y ago
  For tools with webapp output. You can use a proxy to access it in your local browser. Something like ngrok would work well. The advantage of having tools with APIs
  - danans 4y ago
    Sure, but it's a lot easier just to open a browser in the remote desktop session. It's not like the FPS of the browser matters much when looking at unit test results.