FYI VSCode's SSH Agent is a godsend for remote development - the "disadvantages" that Fly lists are part of its advantages. I've worked in several teams that have made extensive use of the extension, and it's never been an issue. You can restrict SSH access arbitrarily to ensure whatever security or access guardrails you need.
It turns out ssh is, well, a little awful. I use emacs as my primary dev tool, and I hardly ever tramp to a remote machine, preferring instead to ssh via terminal to the machine and run a local emacs instance on the target machine. Reason being that the ssh connection underlying Tramp can get downright creative in the ways it crashes or hangs emacs.
SSH, as a protocol, dates back to a time where you even though the network was built to be (ostensibly) robust against attack, there's a deeply-ingrained assumption that it's mostly up and persistent. That assumption doesn't work well in the era of laptops and wifi, as anyone who uses emacs regularly may be able to tell you. The defaults for SSH are wrong for the modern world, and once you tweak those the protocol reliability (against dropped or rerouted connection, not data corruption) is still rough.
Using SSH as a springboard to inject a better-designed protocol server is the right solution.
This is super good advice, thank you for sharing it.
It's good that the system can be tuned to work better, but the tricky bit is that the vscode solution just doesn't require that; for most people (it seems), It Just Works.
danielklnstein · · focus · HN ↗
FYI VSCode's SSH Agent is a godsend for remote development - the "disadvantages" that Fly lists are part of its advantages. I've worked in several teams that have made extensive use of the extension, and it's never been an issue. You can restrict SSH access arbitrarily to ensure whatever security or access guardrails you need.
shadowgovt · · focus · HN ↗
It turns out ssh is, well, a little awful. I use emacs as my primary dev tool, and I hardly ever tramp to a remote machine, preferring instead to ssh via terminal to the machine and run a local emacs instance on the target machine. Reason being that the ssh connection underlying Tramp can get downright creative in the ways it crashes or hangs emacs.
SSH, as a protocol, dates back to a time where you even though the network was built to be (ostensibly) robust against attack, there's a deeply-ingrained assumption that it's mostly up and persistent. That assumption doesn't work well in the era of laptops and wifi, as anyone who uses emacs regularly may be able to tell you. The defaults for SSH are wrong for the modern world, and once you tweak those the protocol reliability (against dropped or rerouted connection, not data corruption) is still rough.
Using SSH as a springboard to inject a better-designed protocol server is the right solution.
G3rn0ti · · focus · HN ↗
shadowgovt · · focus · HN ↗
It's good that the system can be tuned to work better, but the tricky bit is that the vscode solution just doesn't require that; for most people (it seems), It Just Works.