4 ms·
The proper name for this functionality is Visual Studio Code Remote - SSH (https://code.visualstudio.com/docs/remote/ssh https://code.visualstudio.com/docs/remo
by ak217 2y ago
The proper name for this functionality is Visual Studio Code Remote - SSH (https://code.visualstudio.com/docs/remote/ssh https://code.visualstudio.com/docs/remote/ssh), and it's VSCode's killer feature. With this plugin, VSCode is the first IDE to properly implement the remote IDE paradigm.
When VSCode connects to the remote using the plugin, it installs an entire VSCode server - seamlessly to the user every time they connect to a remote - that keeps track of all project facilities, shells, extension accessory runtimes, takes care of embedded or computationally heavy tasks like compiling, building, running project-wide code analysis tools, etc. while keeping all settings, editor windows, and accessory panes local (which is critical for UX and latency). VSCode appropriately partitions responsibilities between the local and the remote, automatically restores IDE infrastructure on the remote as needed, and enforces the partitioning architecturally for all extensions.
This architecture is not an accident - it's rooted in VSCode's origin as a browser-based IDE, and makes use of the LSP and other features that don't exist in Emacs/TRAMP because nobody really thought deliberately about running the extensions at an arm's length from the editor UI in Emacs, using an async protocol that doesn't allow extensions to impact core UI latency. But the flipside is that the "client" part I described above does place a lot of trust in the "server" part, just as you might expect a browser-based application to do.
Whether you consider this architecture bananas or not depends on your security model. It's probably not the best idea to let people SSH to production using this plugin. If you are trying to rely on it to partition a novel AI tool away from part of your infrastructure, yeah, it wasn't really meant for that. The plugin predates agentic AIs by 5+ years. But it's an incredibly powerful and useful feature. I don't think taking cheap shots against it is helpful when the actual bananas thing is trying to use it in a way it was not intended for.
- nomendos 2y agoWhen is the Risc-V support coming?
- Aurornis 2y ago> Whether you consider this architecture bananas or not depends on your security model. Knowing about the security risks is good. In all of my use cases I control both client and server machine. The remote SSH capability just lets me use the UI comfortably on my laptop.
- amluto 2y ago> VSCode appropriately partitions responsibilities between the local and the remote, automatically restores IDE infrastructure on the remote as needed, and enforces the partitioning architecturally for all extensions. Excuse me? This: https://github.com/microsoft/vscode-remote-release/issues/6608#issuecomment-1112960548 https://github.com/microsoft/vscode-remote-release/issues/66... Is the opposite of architecturally enforced appropriate partitioning. This is “we want to make it convenient to use, and we do not care about security or enforcement of the local vs remote split at all.”
- laserlight 2y agoWow. Only a genius could come up with the idea of compromising the localhost security when connecting to a remote host --- and still call the thing SSH.
- moondev 2y agoCoda by panic had integrated ssh support for remote editing + terminal. Predates vscode by 7ish years. https://en.m.wikipedia.org/wiki/Coda_(web_development_software) https://en.m.wikipedia.org/wiki/Coda_(web_development_softwa...
- dangus 2y agoI think that the author of this blog post doesn't understand what a development environment is! Which isn't a surprise to me considering that fly.io is such a crap service, I'm not shocked they have employees that don't understand development practices. Remote development environments with this sort of setup are sometimes needed for applications that can't effectively run on your local workstation, or where the server environment is very different than the workstation, or where you want to ensure better consistency than a local workstation can offer. The operating system controls the security boundaries fully. Your ops team or person who built the remote OS can limit the permissions of your remote connection's user however they'd like. It's like the author of this article forgot how Linux works: you can restrict users from running certain commands or accessing unauthorized directories with trivial ease. And when it comes to security risks, this is supposed to be a development environment. It's not meant to be used in a produciton system accessed outside the boundaries of your organization.