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 also fills up the hard drives on shared server, where each user up to 5 GB of vscode nonsense.
Also, I realized that students are likely to use vscode to connect to embedded Linux machines and fill up their emmcs (and RAM), so I came up with a partial solution for our experiment's yocto image (<a href="https://github.com/RNO-G/meta-rno-g/blob/main/recipes-support/fuck-vscode/files/home-rno%5Cx2dg-.vscode%5Cx2dserver.mount" rel="nofollow">https://github.com/RNO-G/meta-rno-g/blob/main/recipes-suppor...) , but a more general solution would be nice. Probably better to just not allow any node process to run via LSM.
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.
neuroticnews25 · · focus · HN ↗
cozzyd · · focus · HN ↗
Also, I realized that students are likely to use vscode to connect to embedded Linux machines and fill up their emmcs (and RAM), so I came up with a partial solution for our experiment's yocto image (<a href="https://github.com/RNO-G/meta-rno-g/blob/main/recipes-support/fuck-vscode/files/home-rno%5Cx2dg-.vscode%5Cx2dserver.mount" rel="nofollow">https://github.com/RNO-G/meta-rno-g/blob/main/recipes-suppor...) , but a more general solution would be nice. Probably better to just not allow any node process to run via LSM.