Enable VSCode/Remote on any supported remote regardless of OS, Kernel, GLIBC or other dependency

[the-moog]

The recent breaking update to VSCode, (that I only found out about through YT - The Linux Experiment where support for older GLIBC caused chaos globally. Note this was reported as support for Ubuntu 18.04, whereas it should be reported as older GLIBC as the former assumes the remote is Ubuntu. I am fairly sure most corporate systems are not Ubuntu, rather some sort of Fedora or Debian. In my (large global) organisation remotes are either RHEL or Windows Server.

Related issue: #9433. where I was 'asked for more information' at a time this issue must have been well known. Since then this issue has been discussed dozens of times..... BTW/SOT: I have often wondered about the safety and security of downloading and transmitting then executing arbitrary binaries on remote systems you have no admin rights on and no way to ensure are genuine...... Perhaps that needs a rethink?

I am sure MS have better metrics on this? I expect, like myself, many VSCode/Remote users have zero influence over the underlying remote infrastructure, which is often in place to support older services and tooling. Surely the Client IDE should not put requirements on the Corporate tools, services, systems and products that the user is being employed to maintain on any remote host?

Proposed Solution: VSCode/Remote should, as a convention or if necessary as a fallback, require minimal remote dependences, including but not limited to; OS Vendor, OS Release, session Kernel Version, CPU Architecture or GLIBC version. I know this is not possible in all cases (e.g. I am fairly sure VSCode remote will never work on a BBC Micro from the 80's) but I am fairly sure there is no practical reason why it should mandate an ABI.

After all, it's written in Javascript. If Node can be compiled for that platform, then it should work. Yes there are binaries (which IMO is not a great idea) but they should be cached optimisations not mandatory dependencies.

Detailed Implementation?

• Assume but don't rely on the fact there may be a compiler on the remote.
• Assume that compiler is a version of GCC.
• Assume but don't require static linkage is possible.
• During install, try compiling and running a 'probe' executable.
• Get metrics from that probe and then download the source for, and build the require missing components on the remote.
• Use those components to setup the TCP socket and present a minimal API to VSCode.
• 100% ensure that any dependency of any API function that can't get a speedup from running remotely can still work, all be it slower, with the code or a variant of that code, running on the client.

[xgdgsc]

If it' s only because a nodejs dependency issue. I remember something like https://stackoverflow.com/a/77752271/1136027 . I found in my anaconda installation at ~/miniconda3/x86_64-conda-linux-gnu/lib64/libstdc++.so which might be an environment where the server side can run without updating the system glibc or the system. Considering anaconda python might already have a large installation user base. Would adding a simple remote anaconda environment path as a config to workaround the issue the easiest solution for all? I also remember doing the source ~/miniconda/bin/activate or modifying LD_LIBRARY_PATH for using my own libs that are compiled for newer libstdc++ versions before. Also https://github.com/microsoft/vscode-remote-release/issues/103#issuecomment-913649289 did something similer.