Allow connecting to unsupported Linux remotes, by use of custom glibc and stdc++ libraries

[murkvin]

Context

I'm following up on a change from earlier this year that caused the "Remote - SSH" VS Code extension to become incompatible with Amazon Linux 2 (among others) by enforcing a version requirement on glibc >= 2.28 and libstdc++ >= 3.4.25. As a temporary workaround, Microsoft made a change to allow VSCode to connect to incompatible OS versions until February of 2025.

Related links:

• Clarify platform requirements for 1.86 release #201129
• Workaround for machines that do not have glibc >= 2.28 #203375

Request

With February 2025 fast approaching, it would be helpful to clarify what your action plan is for February. A concrete plan will help those of us who rely on VSCode (and the Remote - SSH extension) for our development workflows to understand what our options are. To kick off this line of communication, I have a few questions:

1. Is there any plan to extend the February 2025 timeframe?
   1a. If not, will support be going away at the beginning or the end of February?
2. Will you be making an explicit change to disable legacy compatibility?
   2a. What change (or changes) might that be?
   2b. Will elements like /tmp/vscode-skip-server-requirements-check still exist?
3. Would you be willing to provide a draft release with your planned changes so that we can be proactive in evaluating workarounds?

Closely related to my request for opening up a line of proactive communication, I'd also like to request that the legacy compatibility stay in place to whatever extent it is possible and practical to maintain. For users in many environments, pinning versions and missing out on security patches is a complete non-starter. We'd be forced to move to different tooling at least until we move to new, compatible systems.

As a user, I worry that I'll be "left behind" by VSCode despite being on a mainstream distribution's active LTS release.

[isidorn]

Thanks for reaching out. Let me try to answer your questions.

There are no plans to extend the February 2025 deadline. Compiler requirements for newer Node.js versions and the security push inside Microsoft will make it harder to support across all three architectures of the legacy server with the current sysroots.

Will support be going away at the beginning or the end of February?

Support will be removed in beginning of March 2025. February release of VS Code will be the last version to support legacy server

Will you be making an explicit change to disable legacy compatibility? Currently, there are a number of elements in play--the legacy server, a special /tmp/vscode-skip-server-requirements-check check, shell script checks, checks written in Rust, etc.

Yes, the following changes will be made:
a) Removal of the pipeline that builds the legacy server https://github.com/microsoft/vscode/blob/main/build/azure-pipelines/linux/product-build-linux-legacy-server.yml
b) Update the checks in cli https://github.com/microsoft/vscode/blob/main/cli/src/util/prereqs.rs to exit with an error on platforms that used legacy server
c) Drop the support for legacy server use in the version check script

vscode/resources/server/bin/helpers/check-requirements-linux.sh

Line 14 in a77885d

# 100: Use legacy server.

Would you be willing to provide a draft release with your planned changes so that we can be proactive in evaluating workarounds?

Yes, this is a reasonable ask, we can provide a custom insiders build to test by December.

[reukiodo]

Will there be an announcement prior to the release in order to disable automatic updates? Or even better some method to automatically STOP automatic updates prior to this breaking change?

[simozacca]

Our research groups at London universities, along with many hundreds of other colleagues in similar academic environments worldwide, have been unable to upgrade our servers due to factors beyond our control. We hope you understand that, in certain contexts, especially in academia, financial constraints and administrative processes make such changes less feasible and significantly slower.

We would greatly appreciate it if a solution could be provided that allows us to continue using VSCode remotely on our outdated servers. A possible approach could be pinning a stable reference version that, while no longer maintained, could still be used by those in similar circumstances (which we believe is a considerable number of users).

We appreciate your understanding, as VSCode remains an essential resource for our publicly funded research.

[reukiodo]

Also, users of VSCode are not necessarily admins of the systems they utilize. Breaking VSCode users is just penalizing your users, especially when they are not in the ability to upgrade equipment they are required to use.

[isidorn]

Thanks for your feedback.

Yes there will be announcement.
You may disable automatic updates of VS Code via the setting "update.mode": "none".

We will consider making the last version of VS Code that connect to an unsupported OS accessible from our docs.

[adamcolon]

I can assure you, many of us cannot have legacy systems upgraded. Many of us are clients and we have no control over the hardware, but we must manage and update code on them.

As long as you provide a path to ignore the check and keep using the software bypassing the lockout, we're fine.

tldr; there's no way for some of us to upgrade legacy hardware but we still need to do work on them