Just a FYI, this feature will install a binary on the remote host and run it.
> Your local machine will attempt to connect to the remote server using the ssh binary on your path. Assuming the connection is successful, Zed will download the server on the remote host and start it.
As long as that is notified and correctly authenticated, it is a reasonable approach because the remote process can progress without having to send the whole workspace through SSH. I also expect most language servers would have to be on remote for the same reason.
It's not a reasonable approach because these binary blobs they're installing are guaranteed to be non-functional unless the target OS somehow happens to be the exact distribution and version the binary blob developers are testing for.
(You could theoretically make a truly portable and hermetic binary blob with something like WASM, but I guarantee you this black magic is not accessible to IDE developers.)
They address this in the article - they're statically linking with musl, which should address most distros, and their phrasing indicates that they're testing multiple distros too.
> Unlike our normal Linux builds, the remote server can be compiled with musl, which requires no dynamic linking. This lets it work on older distros (where before we ran into compatibility problems with glibc) and on modern share-nothing distros like Nix that don't have a global set of libraries to dynamically link.
> these binary blobs they're installing are guaranteed to be non-functional unless the target OS somehow happens to be the exact distribution and version the binary blob developers are testing for.
Whoever makes publicly available binary blobs are necessarily aware of all those issues and try to engineer them to be resilient enough for most environments. That's why they typically work well even though they generally have little information about the system besides from most basic ones (ISA, OS/kernel and ABI to be precise). This is significantly more difficult in Linux due to its higher variability, but not even close to impossible.
Presumably the attack vector is that someone malicious at Zed or VSCode could change the code in the server components to introduce a backdoor that could be used later.
..and is not even open source (EDIT: I'm wrong, see below). Zed's remote server on the other hand seems to be OSS. One could probably install it themselves without relying on the automatic download.
The extension that invokes it isn’t, but there are a few implementations of it that are, and I think vscodium bundles one with their build. It’s just some shell scripts that download the reh build and run it with the correct args.
Hmm, are the docs outdated then or are they talking about something else?
> The Visual Studio Code Remote Development extensions and their related components use an open planning, issue, and feature request process, but are not currently open source.
That’s the extension which launches the server. The server itself, which is what runs on the remote machine, is part of the vscode repo itself. You can see this open source extension for an example of what the extension does as well as an explanation of what it does https://github.com/xaberus/vscode-remote-oss
Mainly just sets up the UI/connect commands in vscode UI and launched REH (the vscode server) on the remote machine. The actual server is just a different binary you build from the same repo. Non-Microsoft OSS builds of vscode work with SSH fine.
That's how most of these remoting features work, by running the IDE backend on the remote host.
I'm not sure if IntelliJ IDEA has an equivalent, but CLion has an option to just do the build and run/debug on the remote host without running the whole IDE on it.
> Your local machine will attempt to connect to the remote server using the ssh binary on your path. Assuming the connection is successful, Zed will download the server on the remote host and start it.
https://zed.dev/docs/remote-development