VSCode Drops Ubuntu 18.04 Support
omgubuntu.co.ukUbuntu 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.
> Ubuntu 18.04 is EOL, unless you pay for extended support. How many people are paying for that support?
The extended support is free for consumers.
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.
> If you're on an os from 2018 you're clearly not really dependent on the latest versions of everything.
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?
Saying “Windows 10 is from 2015” is like saying “Ubuntu is from 2004”.
Those “big updates” in Win 10 that you mention even use more or less the same versioning scheme as Ubuntu using the year and part of the year to identify the release. Windows 10 “22H2” is essentially the same name scheme as Ubuntu “22.10” don’t you think.
Ubuntu 18.04 is contemporary with Windows 10 version 1803. Hmm, I wonder if that came out in March 2018. Oh, it was April 2018 actually? Coincidence? If so, I guess it is also a coincidence that the next version came out in October 2018 ( version 1809 ). What was the next “Windows 10”? Oh look, it was 1903. It did not come out until May. I guess MS has a harder time keeping a schedule than Canonical does.
The real lesson here though is that you should not ship new software as native packages for older distros. If the distro is not updating it, you should not either.
If you want to ship VS Code for older distributions, do it as a Flatpak. If you do not think that is fair, I am sure you must be enjoying the version of VS Code that ships specifically for Windows 10 1803. Or are you using a VS Code installer that ships independently of the OS which targets multiple releases of the OS?
It's not the same as Ubuntu Linux from 2018.
On Ubuntu both the OS and software packages are frozen in time and fixes are backported from newer versions.
It's not the same at all as what Microsoft does. In fact Windows is de facto a rolling OS, a phenomenon which also exists in the Linux world but is much less popular there. A rolling OS user would not have the problem in the article.
Windows 10 22H2?
To be fair, Microsoft doesn't support VSCode on BSD anything (and likely never will).
It works just fine for me though. It's in the standard FreeBSD package collection.
'Support' is a hollow term when it comes to Microsoft anyway. I deal with their paid 'premium support' regularly at work. It's double outsourced, first to Accenture and then to a ton of tiny companies that know nothing.
I get so much better support from the FreeBSD package maintainers than I've ever had from Microsoft :)
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
> while we look for a workaround.
emacs will always be there for you, when you're ready.
> 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.
CentOS 7 with the EOL of June 30, 2024 was affected.
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.
Is it not possible to just update glibc ?
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.
Would it actually break though? It's my understanding that glibc attempts to preserve backwards compatibility, such that binaries built under older versions will work under newer versions. As far as I know it's not a hard commitment the way it is for the kernel, but breakages are infrequent.
This is the PR that bumps it[1]. The issue appears to be NodeJS 16 reaching EOL.
1. https://github.com/microsoft/vscode-linux-build-agent/issues...