Ubuntu 18.04 is EOL, unless you pay for extended support. How many people are paying for that support?
I hope the people complaining about the VSCode incompatibility aren't people running EOL software and complaining that other people aren't keeping their software compatible with it.
I upgraded a number of servers to Ubuntu 20.04 because Ubuntu 18.04 was EOL. I also upgraded my desktop to Debian 12. ;-)
Yeah I'm a big fan of aggressively dropping support for obsolete platforms unless someone is paying you a lot of money to do otherwise. Don't run software that isn't getting security patches.
Can't you just keep using the old version? It's pretty much feature complete after all
Edit: yes the article mentions it so it's not nearly as bad as suggested IMO. If you're on an os from 2018 you're clearly not really dependent on the latest versions of everything.
In the mean time you could start working on the OS upgrade.
I don't really understand the wish for old versions in the Linux world. I use BSD myself which doesn't have this coupling.. You can be on a stable OS but have rolling cutting-edge packages. Pretty ideal for me.
This messed with me too. At work our primary development environment is a farm of older CentOS machines. They all lost support with this vscode upgrade. It probably impacts hundreds of people. I had to send out instructions to downgrade and pin your vscode version while we look for a workaround.
I get that it isn't entirely within the vscode team's control (Electron chose to make the switch), but even then, it really interferes with a lot of people's daily development needs. These systems aren't particularly old or out of support.
I just helped a coworker get his remote vscode working on RHEL7. If you compile glibc from source and install it in some local directory, you can run patchelf —set-interpreter —set-path on ~/.vscode-server/bin/*/node and write to a special “skip requirements file”
touch /tmp/vscode-skip-server-requirements-check
patchelf --set-interpreter /opt/glibc/lib/ld-linux-x86-64.so.2 --set-rpath /opt/glibc/lib:/opt/glibc/lib64 ~/.vscode-server/bin/*/node
Warning: you’ll need gmake and all the gnu tools for building, make sure to ../configure with —disable-werror
> These systems aren't particularly old or out of support.
CentOS 7 goes EOL June 30th, so you're pretty close to their end of life (CentOS 8 stream has 2.28, so should still work with the new vscode version, which is why I'm guessing you're talking about 7.)
If you don't already have plans for replacement/upgrading, you really need to have plans.
Ubuntu 18 went EOL on May 31, 2023 so about 8 months ago. What CentOS are you running that's still in support and was affected by this change? I had to upgrade all my systems last year after the EOL as most python packages dropped 3.8 support.
Just to double-check - does this mean Ubuntu 18.04 cannot be a VSCode remote target anymore?
> VS Code 1.86 (aka the ‘January 2024’ update) saw Microsoft bump the minimum build requirements for the text editor’s popular remote dev tools to ≥glibc 2.28 — but Ubuntu 18.04 LTS uses glibc 2.27, ergo they no longer work.
Wouldn't this just mean if you're on Ubuntu 18.04 you'd need to manually update glibc to >= 2.28?
18.04 is an LTS release which according to Ubuntu's website ended standard support in April 2023 and still has "Expanded Security Maintenance" until April 2028.
From the article it seems like the real problem is Microsoft didn't adequately communicate the change in advance or provide safety checks when upgrading. It seems like an easy oversight to make though.
Also I'm sympathetic to the numerous situations in which developers have no ability to upgrade old Linux boxes but it seems like Microsoft's not entirely to blame for not supporting a 6 year old Ubuntu release a year after its standard support timeframe.
TL;DR: Situation sucks, seems like a typical Linux dependency issue, hopefully they consider and communicate better in the future.
Not on the system as you'll likely break ABI compatibility and need to recompile everything that uses glibc (basically everything), and LTS distros (e.g. CentOS, RHEL, Ubuntu LTS) guarantee binary compatibility during the release so this isn't feasible.
justin_oaks|2 years ago
I hope the people complaining about the VSCode incompatibility aren't people running EOL software and complaining that other people aren't keeping their software compatible with it.
I upgraded a number of servers to Ubuntu 20.04 because Ubuntu 18.04 was EOL. I also upgraded my desktop to Debian 12. ;-)
TillE|2 years ago
daveoc64|2 years ago
The extended support is free for consumers.
wkat4242|2 years ago
Edit: yes the article mentions it so it's not nearly as bad as suggested IMO. If you're on an os from 2018 you're clearly not really dependent on the latest versions of everything.
In the mean time you could start working on the OS upgrade.
I don't really understand the wish for old versions in the Linux world. I use BSD myself which doesn't have this coupling.. You can be on a stable OS but have rolling cutting-edge packages. Pretty ideal for me.
cypress66|2 years ago
I'm on Windows 10 which is from 2015. I want the latest software, but an older more stable OS (not Windows 11 yet).
It's true that Windows 10 has had big updates (builds). But maybe that's the right approach?
inferiorhuman|2 years ago
kaelinl|2 years ago
I get that it isn't entirely within the vscode team's control (Electron chose to make the switch), but even then, it really interferes with a lot of people's daily development needs. These systems aren't particularly old or out of support.
funkychicken|2 years ago
touch /tmp/vscode-skip-server-requirements-check
patchelf --set-interpreter /opt/glibc/lib/ld-linux-x86-64.so.2 --set-rpath /opt/glibc/lib:/opt/glibc/lib64 ~/.vscode-server/bin/*/node Warning: you’ll need gmake and all the gnu tools for building, make sure to ../configure with —disable-werror
dmm|2 years ago
emacs will always be there for you, when you're ready.
Twirrim|2 years ago
CentOS 7 goes EOL June 30th, so you're pretty close to their end of life (CentOS 8 stream has 2.28, so should still work with the new vscode version, which is why I'm guessing you're talking about 7.)
If you don't already have plans for replacement/upgrading, you really need to have plans.
mikeravkine|2 years ago
asdaq1312512|2 years ago
> VS Code 1.86 (aka the ‘January 2024’ update) saw Microsoft bump the minimum build requirements for the text editor’s popular remote dev tools to ≥glibc 2.28 — but Ubuntu 18.04 LTS uses glibc 2.27, ergo they no longer work.
pythonaut_16|2 years ago
18.04 is an LTS release which according to Ubuntu's website ended standard support in April 2023 and still has "Expanded Security Maintenance" until April 2028.
From the article it seems like the real problem is Microsoft didn't adequately communicate the change in advance or provide safety checks when upgrading. It seems like an easy oversight to make though.
Also I'm sympathetic to the numerous situations in which developers have no ability to upgrade old Linux boxes but it seems like Microsoft's not entirely to blame for not supporting a 6 year old Ubuntu release a year after its standard support timeframe.
TL;DR: Situation sucks, seems like a typical Linux dependency issue, hopefully they consider and communicate better in the future.
ekimehtor|2 years ago
https://sourceware.org/glibc/sources.html
PlutoIsAPlanet|2 years ago
orf|2 years ago
1. https://github.com/microsoft/vscode-linux-build-agent/issues...