Ontwikkelaars klagen dat VS Code op Ubuntu 18.04-lts plotseling niet meer werkt

Ontwikkelaars zijn niet blij met een recente update van Visual Studio Code. Dat werkt niet meer op Ubuntu 18.04, een lts-release. Onder andere op GitHub komen veel klachten binnen over de gestopte ondersteuning.

Ontwikkelaars klagen op GitHub over de recente januariupdate voor VS Code, versie 1.86. Maker Microsoft heeft de eisen voor die tool verhoogd, waardoor minimaal glibc 2.28 nodig is, de GNU C Library die in 2018 uitkwam. Ubuntu 18.04 is een longtermsupportrelease, die nog glibc 2.27 bevat. Dat betekent dat veel gebruikers van de lts-release van de populaire distro VS Code niet meer goed kunnen gebruiken.

De ontwikkelaars klagen onder andere dat ze de verandering niet aan zagen komen en zich er daarom niet op konden voorbereiden. Microsoft schrijft in de releasenotes dat ontwikkelaars als alternatief de webversie van de tool kunnen gebruiken. Ook zouden gebruikers ervoor kunnen kiezen een oude versie van VS Code te gebruiken.

Reacties (137)

[GertMenkel]

Dat dit zou gebeuren is aangekondigd in de release notes van augustus vorig jaar:

Prebuilt binaries from the official Node.js repo for Linux are now compatible with Linux distributions based on glibc 2.28 or later. This would mean dropping support from our servers for Ubuntu 18, CentOS 7, RHEL 7, etc. We are now shipping a custom build of Node.js for our Linux servers to maintain glibc 2.17 or later compatibility. This support will change in future updates when we are no longer capable of building newer Node.js versions on CentOS 7 images, so we advice our server users to update their OS versions if they are affected by this change.

Een les voor Microsoft: niemand leest de release notes

De officiële workaround is om VS Code te downgraden naar de laatste versie die nog wel de oude binary had.

[NMe]

De goede oplossing is om niet vast te houden aan een LTS-release uit 2018 die vorig jaar EOL is gegaan... Er zijn sindsdien twee andere LTS-versies uitgekomen en over twee maanden komt een derde LTS-versie uit.

Sorry, maar als je nota bene als developer zo lang achterloopt dan vraag je er toch echt zelf om. Ik vind dit echt non-nieuws. Een beetje developer zou beter moeten weten dat ouwe meuk gebruiken en verwachten dat het ad infinitum blijft werken.

Bijzonder overigens dat de auteur van het artikel wel ingaat op het feit dat het een LTS-release is, maar niet op het feit dat die release EOL is..

[Creesch]

Je hebt in princiepe wel gelijk, maar EOL hier is niet zo EOL als het lijkt. Er is namelijk ook nog ESM en Ubuntu PRO wat in hetzelfde artikel waar je naar linkt wordt besproken

Sometimes migration is not straightforward. Dealing with dependency changes or simply recalling devices from the field can be troublesome. While the aim will be to migrate, you might need some time. So if you need more time and want to keep devices compliant, ESM gives you 5 extra years before 18.04 EOL.

ESM is part of the Ubuntu Pro subscription. ESM provides continuous vulnerability management and patching for critical, high and medium Common Vulnerabilities and Exposures (CVEs). This means that you will keep receiving security updates for more than 2,300 packages in Ubuntu Main. Here you find packages such as Python, OpenSSL, OpenVPN, network-manager, sed, curl, systemd, udev, bash, OpenSSH, login, libc… For the whole list of what’s included in Main, you can visit the Ubuntu Packages Search tool.


But there is more. With the release of Ubuntu Pro, you can also get security coverage to an additional 23,000 packages beyond the main operating system. These are packages in Ubuntu Universe. For example, Boost, Qt, OpenCV, PCL, python-(argcomplete, opencv, pybind11, png…), cython, eigen, GTK, FFMPEG… are some of the many packages covered in Universe that are now getting security maintenance from Canonical.

[RoyTrenneman]

Security updates dus, geen applicatie-updates.

Zeker bij Ubuntu ben je wel een enorme pannekoek als je niet standaard update naar een supported LTS-versie. Kost je 'niks' en had je acht niet meteen in april 2020 hoeven doen, maar toch wel ruim voor april 2023 als 18.04 LTS eol werd.

Ik kom het ook nog frequent tegen dat klanten, oude eol versies willen blijven gebruiken en bijna eisen dat we bugs oplossen die gerelateerd zijn aan eol besturingsystemen.

Denk dan aan bijv. Windows 7, Windows 8, etc. Of Windows server 2012. Gelukkig komen we het bij Ubuntu niet zoveel tegen. Daar lopen we meer tegen Ubuntu derivaten aan (die ook gewoon moeten werken, want het is bijna hetzelfde als Ubuntu).

Mense begrijpen niet dat we een QA proces hebben voor elke OS versie (32 stuks momenteel) die we ondersteunen en we niet zitten te wachten op een QA proces voor bijv ElementaryOS die mensen gebruiken omdat de interface 'mooier' is dan die van Ubuntu, of DietPi, omdat dit een kleiner pakketje is dan RPI OS.

Vaak zijn de probleempjes relatief klein bier en een kwestie van dependancies updaten, maar gewoon niet schaalbaar om te ondersteunen.

[BeosBeing]

Daar lopen we meer tegen Ubuntu derivaten aan (die ook gewoon moeten werken, want het is bijna hetzelfde als Ubuntu).

Die zouden dan ook gewoon moeten werken. Is het issue aanwezig in de wel ondersteunde versie van Ubuntu dan kun je het oppakken, zoniet dan ligt verwijzing naar de derivaatmaker (bv ElementaryOS) voor de hand.
Daarbij kun je gelukkig in dit soort OS-sen zelf makkelijk een VM maken met daarin een standaard Ubuntu (of ander wel ondersteund OS mits geen MacOS of Windows) of je kunt het systeem multiboot maken om een ondersteund OS te gebruiken voor dergelijke zaken. Degenen die zelf een derivaat installeren zullen dat zelf ook kunnen.

Alleen als het gewenste OS een Linux variant is die vrij is van systemd-rommel kan het een probleem zijn als alle ondersteunde Linux-versies wel systemd draaien. Dan zal ook de derivaat-maker niet kunnen helpen.

Mense begrijpen niet dat we een QA proces hebben voor elke OS versie (32 stuks momenteel) die we ondersteunen

Interessant, welke OS-versies dat zijn. (Met Linux kan het hard gaan) *

en we niet zitten te wachten op een QA proces voor bijv ElementaryOS die mensen gebruiken omdat de interface 'mooier' is dan die van Ubuntu, of DietPi, omdat dit een kleiner pakketje is dan RPI OS.

een kwestie van dependancies updaten, maar gewoon niet schaalbaar om te ondersteunen.

Tja dat is in iedere distro anders.

* ik hoop ReactOS, Haiku, FreeBSD, TrueOS, Midnight BSD, Calculate Linux, AntiX, Manjaro en verwacht Gentoo, Arch, Debian, Suse, Slackware, SteamOS, Fedora, en wat Ubuntu varianten naast MacOS en enkele varianten van Windows 11, Windows 10 en Windows Server.

[RoyTrenneman]

De besturingssystemen zijn:

Windows, macOS, Ubuntu Linux, Raspberry PI OS, Android, iOS en daar verschillende versies van die momenteel ook nog door de Microsoft, Apple, Canonical, RPI foundation, en Google ondersteund worden.

Sorry, niet meer distros. Maar onze doelgroep kiest vooral naar de GUI en de prijs.

Overigens hebben wel mogelijkheden om andere distros te gebruiken, maar met beperkte support and onze (OEM) partner dient een eigen test en support proces te hebben.

[BeosBeing]

De besturingssystemen zijn:
Windows, macOS, Ubuntu Linux, Raspberry PI OS, Android, iOS en daar verschillende versies van ...

Slechts 6 besturingssystemen en dan toch 32 verschillende versies. Dat zijn best veel versies per OS.
Van macOS en iOS worden toch niet zoveel varianten ondersteund? Ook bij Linux gaan de ontwikkelingen snel dus ook daar had ik er niet zoveel verwacht. Ubuntu waarschijnlijk 23.10, 23.04, 22.10, 22.04 LTS, en 20.04 LTS in desktop en server, dat tikt dan wel aan.

[RoyTrenneman]

Ik ga niet alle versies delen, omdat ik graag mijn werkgever erbuiten laat hier, maar het zijn inderdaad best wat versies per OS, maar die allen nog ondersteund worden door de ontwikkelaars van de OS.

Vwb Ubuntu, momenteel ondersteunen we alleen 18.04 LTS, 20.04 LTS en 22.04 LTS. We ondersteunen geen non-LTS versies.

[BeosBeing]

Ik ga niet alle versies delen, omdat ik graag mijn werkgever erbuiten laat hier, ...

Snap ik

maar het zijn inderdaad best wat versies per OS, maar die allen nog ondersteund worden door de ontwikkelaars van de OS.

Ik heb geen idee hoeveel versies* van W10 en W11 er nog door MS ondersteund worden, maar daar verkijk je je heel snel op. MacOS en iOS zal denk ik iets minder zijn, Wikipedia zegt alleen 12, 13, 14 respectievelijk 15, 16, 17, maar geeft geen minor version numbers. Verder is er niets over te vinden.

* Wikipedia schrijft :
W11 home, pro, SE, workst : 23H2, 22H2
W11 edu, enterprice, IOT: 23H2, 22H2, 21H2
W10 home, pro, edu, workst. : 22H2,
W10 edu, enterprice, IOT: 22H2, 21H2
W10 LTSC 1507, 1607, 1809,
(Totaal 30 varianten)
Qua servers zegt Wiki niets maar heeft Ms zelf een uitgebreide lijst en die zegt
Windows 2016 Extended support
Windows 2019 Extended support
Windows 2022 Supported

Vwb Ubuntu, momenteel ondersteunen we alleen 18.04 LTS, 20.04 LTS en 22.04 LTS. We ondersteunen geen non-LTS versies.

Geen non-LTS-versies is logisch, maar 18.04 lijkt me al uit support. Bij het lijstje dat ik noemde zijn:
1) Calculate Linux, AntiX, Manjaro, Gentoo en Arch van het soort dat Rolling Release genoemd wordt.
Dat lijkt me voor ondersteuning een behoorlijke uitdaging maar ik hoop dat alle distro's hier naartoe gaan. De eerste twee zijn daarnaast ook nog eens vrij van systemd.

2) FreeBSD, TrueOS, Midnight BSD geen linux-versies maar (Free)BSD-varianten (en dan heb ik OpenBSD, NetBSD en DragonflyBSD er nog buitengelaten)

3) ReactOS en Haiku geen Linux-versies en ook nog in alpha.

[Tjolk]

Hoewel je gelijk hebt, heeft dat een hele andere doelgroep dan Ubuntu voor ontwikkelaars. Dat gaat over het lange tijd stabiel en veilig draaien van bijvoorbeeld terminals. Heb ik ooit in een ver verleden ook gedaan bij ons in de logistiek, dat werkte prima en het belangrijkste doel was zorgen dat alles zoveel mogelijk bij hetzelfde bleef zodat ik er geen omkijken naar had en de werknemers die erop moesten werken voldoende hadden aan een monkey brain (niet vervelend bedoeld, dat hadden ze namelijk niet maar wel veel ad hoc inhuur).

VS code is bij uitstek bedoeld voor developers. Daarvan mag je verwachten dat ze hun systemen enigszins up to date houden. Ja, waarschijnlijk pakken ze een lts release en misschien doen ze maar eens in de 4 jaar en major upgrade. Dat is allemaal prima. Maar een developer tool hoeft niet te werken op terminals, simple as that.

[JackBol]

Je kan extended ondersteuning op het OS krijgen, maar daarmee niet impliciet aannemen dat alle software erop blijft draaien. Vooral in deze extreme situaties ben je als beheerder (of gebruiker) verantwoordelijk voor de compatibiliteit checks.

[rob12424]

Of gewoon dingen goed doen en bijvoorbeeld patchelf gebruiken.

https://www.baeldung.com/linux/multiple-glibc

Wel zorgen dat je de boel vastlegt en weet wat je doet (depencyhells zijn niet leuk)

Probleem hierin is wel VS code is closed source. Anders kom je VS code re-linken en met dynamic links aan de gang.

Nu moet je alles behalve VS code re-linken en vastleggen en hopen op geen depencyhell. (Of je gooit de nieuwe versie in een LXC?)

[anvil]

VS Code is niet closed source , zie https://github.com/microsoft/vscode
Maar anders neem je Codium , https://vscodium.com/ , daar is bovendien alle tracking en telemetry uit gesloopt.

[embeddaan]

Deels met je eens, echter, er zijn ook ontwikkelaars (zoals ik) die containers draaien (voor vscode met de plug-in devcontainer, jetbrains standaard in gebakken) . Ik heb niet veel met het operating system wat mijn pc draait, en laat dat ook het liefst langs mij gaan.

[GeroldM]

Hou je Microsoft producten tegen dezelfde standaard?

Bij Linux geeft men duidelijk aan dat er 5 jaar support kan worden verwacht, maar dat er nog eens 5 jaar support kan worden aangeschaft. Windows krijgt de 1e 5 jaar hetzelfde nivo aan support als Linux. Na die periode daalt het nivo van support ook bij Windows flink. Die eerste 5 jaar betekent dus niet dat de server EOL is. Bijna niemand neemt die extra 5 jaar support met Linux. Dus beschouwt men een 5 jaar oude versie als EOL. Maar dat is het in feite niet.

Nu ben ik zelf van mening dat 5 jaar zowiezo de uiterste limiet is dat een server in zijn huidige vorm mag bestaan. Daarna is het verstandiger om de hele server opnieuw op te zetten met vernieuwde (en hopelijk verbeterde) inzichten. Maakt niet uit of het Windows of Linux server is.

[_Pussycat_]

Bij Linux geeft men duidelijk aan dat er 5 jaar support kan worden verwacht, maar dat er nog eens 5 jaar support kan worden aangeschaft.

"Bij Linux" zit helemaal geen support. Bedoel je Ubuntu LTS?

[rko4u]

Maar dan nog, dan wil je een OS van meer dan 5 jaar oud gebruiken om te ontwikkelen? Het OS gelijk houden, maar wel de software die er op draait updaten.
Die extra support is mijns inziens bedoeld voor productie machines waar men niets aan de software wil veranderen. Dit artikel gaat echter over ontwikkelmachines, waar dagelijks mensen op ontwikkelen. Die ontwikkel machines moet je dus WEL up-to-date houden.

[Svrooij86]

Hier sluit ik mij graag bij aan… Elke keer als je op die server hebt ingelogd in de laatste 3 jaar heb je een melding gekregen “hey er is een nieuwe LTS versie, type ….. om te upgraden”.

Waarvoor gebruik je überhaupt visual studio code op de server zelf, mag ik constateren dat het dan een verijdelde tekst editor is omdat ze niet met vi of nano om kunnen gaan?
Of als het echt om software gaat, dat ze hun release proces niet op orde hebben? Denk aan git & continuous deployment.

Ik geef toe ik heb ook wel eens visual studio code gebruikt om via ssh met een server te verbinden, maar dat had nooit met “productie” applicaties te maken. Al met al de nieuwswaarde van dit bericht is echt nihil. Neigt zelfs naar sensatiezoekerij.

- update beschikbaar
- heeft weinig met VS code te maken (er is ook geen bericht geweest “NodeJS dropt support voor 5 jaar oud besturingssysteem”)

[djwice]

De goede oplossing is om niet vast te houden aan een LTS-release uit 2018 die vorig jaar EOL is gegaan... Er zijn sindsdien twee andere LTS-versies uitgekomen en over twee maanden komt een derde LTS-versie uit.
...
Bijzonder overigens dat de auteur van het artikel wel ingaat op het feit dat het een LTS-release is, maar niet op het feit dat die release EOL is..

@TijsZonderH Het End of Life (EOL) zijn van Ubuntu 18.0.4 is hier wel relevant.

Ook zoals @GertMenkel aangeeft dat NodeJS (waar VS Code op draait) het simpelweg niet meer ondersteund én dat het 6 maanden geleden al werd aangekondigd.

Lijkt me ook relevant.

[Olaf van der Spek]

Een les voor Microsoft: niemand leest de release notes

Windows 10 waarschuwt mij keurig dat Windows 11 niet compatible is met mijn computer.
Zou handig geweest zijn als VS Code dat ook gedaan had, en niet automatisch zou upgrade in dat geval..

[Yoshi]

OS <-> software applicatie en softwaredetectie <-> hardwaredetectie.
Ik zou denken dat net de meeste gebruikers van VS code dat heel goed snappen. Dat geldt voor een pak libraries die onderliggend gebruikt worden. Ik zie ook niet meteen het probleem om te downgraden. En dat geldt zeker voor de gebruikers van die specifieke LTS (en andere LTS'en trouwens)

[Reactie gewijzigd door Yoshi op 24 juli 2024 22:01]

[djwice]

Je kunt toch ook gewoon zelf glibc 2.28 of nieuwer installeren?

Wat is de reden dan je nog een EOL versie van Ubuntu draait? Dat lijkt me zakelijk en prive niet heel wenselijk.

[_JGC_]

Als er een reden is om zo'n oude Ubuntu versie te draaien ga je niet "gewoon" glibc upgraden. Glibc is onderdeel van het basissysteem waar alle software tegen linkt. Die upgraden kan allerlei bugs introduceren. Dan kan je beter upgraden naar 20.04 of 22.04.

[rko4u]

Klopt, maar op zo‘n machine ga je dus ook geen software op ontwikkelen met VS Code. Die gebruik je dan voor test en productie werkzaamheden.

[Morkatog]

Nee, geen les voor MS maar voor de gebruiker; upgrade je EoL OS (dat al 6 jaar oud is dit jaar), zekers wanneer dat OS een in place upgrade ondersteund.

[Reactie gewijzigd door Morkatog op 24 juli 2024 22:01]

[laurxp]

Betere les voor de gebruiker:

Gebruik in plaats van VS Code een editor die écht open source is, en die niet al zijn plugins verliest als je het zelf compileert / door je distro maintainer laat compileren in plaats van de officiële binary gebruikt.

[elmuerte]

Een les voor Microsoft: niemand leest de release notes

Welke release notes? VS Code upgrade zichzelf automatisch. Na de update krijg je de releases notes wel te zien in VS Code, als die kan starten.

[swhnld]

[...]

Welke release notes? VS Code upgrade zichzelf automatisch. Na de update krijg je de releases notes wel te zien in VS Code, als die kan starten.

De reactie waar jij op reageert begint met " de release notes van vorig jaar Augustus '

[SuperDre]

Ho hu halt, jij kiest bij VS Code zelf voor of je automatische updates krijgt, dus niet met onzin komen dat het door je strot wordt geduwd. Dat jij automatische updates aan laat staan en niet release notes leest is aan jou toe te wijzen, niet aan MS.

[Sando]

Ho hu halt, jij kiest bij VS Code zelf voor of je automatische updates krijgt

Ik snap dat je je ergert aan het woordgebruik waar je op reageert, maar wat je zegt is feitelijk onjuist. Bij veel Linux distro's staan automatische updates na de installatie van Linux aan, of wordt je bij het eerste gebruik op het hart gedrukt om deze aan te zetten vanwege de veiligheid.

Als een VS Code zich dan stilzwijgend aan je systeemupdates toevoegt, dan heb je daar helemaal niet voor gekozen, maar heeft VS Code de verantwoordelijkheid om niet exclusief voor jouw distro een update te plaatsen die kapot is. Dan moet VS Code gewoon de update voor alle compatibele distros plaatsen en die voor 18.04 op de oude versie laten staan. Zo werken apt repositories en VS Code wijkt daarvan af.

Installing the .deb package will automatically install the apt repository and signing key to enable auto-updating using the system's package manager.

[Proliges]

Maar de release notes bestaan dus al sinds augustus. Als je nu de update krijgt heb je 5 maanden de tijd gehad om deze te bekijken.

[GertMenkel]

De release notes verschijnen na elke update tenzij je ze zelf uitschakelt. Als je daar geen interesse in hebt snap ik dat, maar de release notes worden in de standaardconfiguratie getoond bij elke update.

[Loller1]

De gebruiker krijgt de kans niet de release notes te lezen? Als VS Code update krijgt - zoals die comment zelf ook al toegeeft - de gebruiker gewoon te zien dat VS Code bijgewerkt is geweest en wat er nieuw is en eventueel aankomende deprecaties, zoals ook deze. Ze hebben een half jaar de tijd gehad.

[GertMenkel]

De release notes die elke keer verschijnen als VS Code besluit zich te updaten. Mocht je ze in het verleden uit hebben gezet en wil je in de toekomst van dit soort dingen op de hoogte worden gebracht: Settings > Application > Update > Show Release Notes.

Standaard staat die instelling aan, in elk geval hier op de officiële release voor Linux.

[beerse]

Misschien is het wel een les in updaten: Als je wel de software bijwerkt maar het operatingsysteem niet dan moet je daar wel een heel goede reden voor hebben.

Toegegeven, ubuntu lts 18.04 wordt nog ondersteund door de leverancier. Maar er zijn ondertussen al een paar andere ubuntu lts versies uitgekomen. Heb je een goede reden om bij de oude versie te blijven, hou dan ook de software op de bijpassende versies.

Als je om wat voor reden dan ook zo af en toe je tools bijwerkt, doe dat dan met alle tools en dus het hele operatingsysteem. Met de meeste linux distributies kan die upgrade in-place gebeuren.

[R4gnax]

Ontwikkelaars klagen dat VS Code op Ubuntu 18.04-lts plotseling niet meer werkt

Lekkere clickbait titel. Is het weer komkommertijd?

Het probleem is niet met VS Code zelf, maar met VS Code Server.

VS Code Server is het stuk software wat je kunt draaien om de remote development features van VS Code te gebruiken, waarmee je via een VSCode client op een ander systeem of via de web-based VSCode remote op het doelsysteem in kwestie in VSCode kunt werken.

Het is een niche scenario en heeft in de praktijk weinig tot niets te maken met je eigen ontwikkelsysteem.
VS Code Server komt in de meeste gevallen pas in het spel wanneer je met een thin-client opzet te maken hebt; of met een collaborative development opzet. (Of wanneer je met idioterie te maken hebt zoals direct in productie debuggen en editen.)

In die gevallen zit je in de praktijk - tenminste: als je met een goede opzet te maken hebt - niet direct op de host te werken, maar binnen een Docker container. En dan zijn library versies op de host totaal irrelevant.

[Reactie gewijzigd door R4gnax op 24 juli 2024 22:01]

[Morkatog]

Dit soort fouten worden helaas vaker gemaakt en zelden gecorrigeerd. Ik heb ook wel eens feedback gegeven op inhoud maar men doet er helaas weinig mee. Gelukkig kunnen we je een +2 geven om dit soort info toch zichtbaar te krijgen.

[Mitsuko]

Als je werkt met de Remote SSH extensie van VSCode Remote Development dan probeert die automatisch dezelfde versie te installeren op de server als de versie van de client. Dat werkt in dit geval niet waardoor je een foutmelding krijgt.

Je moet dus op de client automatische updates uitzetten, terug gaan naar versie 1.85.2 en dan ook nog een oudere versie van de Remote SSH extensie installeren. Dat is dus best irritant!

[R4gnax]

En dat moet je, alsnog, alleen wanneer je van remote development gebruik wilt maken. Het is dus niet, zoals het artikel sensationeel doet suggereren, dat VS Code ineens niet meer werkt voor iedereen die achtergebleven is op Ubuntu 18. Wat ook nog eens de vorige LTS versie van Ubuntu is en niet de huidige, zoals het artikel ook doet suggereren.

En daarnaast is de oplossing voor dit hele probleem om de omgeving waarop je remote development wilt doen, in een docker container te draaien zodat de libraries van het host OS niet langer relevant zijn.

Hiervoor zijn als ik me niet vergis zelfs standaard docker images beschikbaar gesteld door Microsoft, op basis van Alpine.

[Reactie gewijzigd door R4gnax op 24 juli 2024 22:01]

[Mitsuko]

Makkelijker gezegd dan gedaan. In ons geval ging het om CentOS 7, en de servers zijn niet in eigen beheer waardoor het lang wachten is. Of het voor ons mogelijk is om volledig in Docker images te gaan werken is maar helemaal de vraag, door omstandigheden waar ik verder niet op in zal gaan.

Ik zat dus vrijdag met de situatie dat het hele team ineens niet meer op de server kon komen via VSCode zonder eerst de clientversie terug te rollen. Het artikel had wat preciezer mogen zijn maar zo obscuur is onze situatie nou ook weer niet.

[karelvandongen]

centos 7 hebben wij gelukkig achter ons gelaten. sinds een maand, want dit soort problemen komt wel vaker voor aan het einde van ondersteuning. Daarom is tijdig upgrade, of overstappen op een fatsoenlijke hoster zo belangrijk.

[anvil]

Nu nog iets kritieks op CentOS 7 draaien is niet best... over 5 maand is het over en uit.
Ik zou maar heel snel een migratie strategie gaan plannen en meteen een andere hoster zoeken, want een hoster die zijn klanten nu nog niet actief aan het migreren is neemt zijn taak niet serieus.

[Antiloop]

Ubuntu 18 is niet de vorige LTS versie, de huidige is 22 en de vorige is dus 20 en daarna komt 18 pas

Over 4 maanden is Ubuntu 24 LTS er ook alweer

[HollowGamer]

Ik gok eerder een gebrek aan kennis.

Weet niet welk onderdeel het precies is, maar dit is een oude Ubuntu LTS versie. Misschien dat je een extra update plan van Ubuntu/Canonical kan kopen, maar dan nog is het niet een probleem van de developer.

Vraag mij af of een Flatpak of Snap het wel werkt, maar het interesseert mij vrij weinig. Je wordt gek van die mensen die vasthouden aan super oude versies, want het is stable ofzoiets.

[david-v]

Ik snap het even niet. 18.04 is een lts maar die is vorig jaar toch EOL verklaard? Als je deze versie niet wil upgraden, waarom wil je dan wel een nieuwere versie van VS code die deze EOL versie niet meer ondersteunt?

Zie ik hier iets over het hoofd?

[mischy]

Dit dus, precies. Je oude OS niet bijwerken maar wel bepaalde software die je er op draait naar de nieuwste versie updaten, dat vind ik kolder.

Kan best dat je om een of andere reden per sé op die versie Ubuntu wilt (moet vind ik te ver gaan) blijven, maar wees dan ook terughoudend met updaten van de software die je er op draait. Als je die nieuwste versie echt nodig hebt zijn er mogelijkheden om dat te draaien op andere manieren.

Nogal een non-argument artikel in mijn optiek.

[Mitsuko]

VSCode installeert standaard automatisch updates. Tot nu toe zonder problemen, dus er is nooit een reden geweest om dat uit te zetten.

Nou moet er wel een kanttekening bij: De automatische updates worden geïnstalleerd op de client, dus op een andere versie van Linux of zelfs Windows, en dan gaat het mis als je met VSCode remote development een verbinding probeert te maken naar een server waarop een verouderd besturingssysteem draait. Die probeert dan dezelfde versie te installeren en dat werkt niet.

[Svrooij86]

Ik denk dat men inderdaad doelt op de VS Code remote integratie doelt, waarbij je vanuit een lokale VS code via bijvoorbeeld ssh verbind met een server (waar dan automatisch het server gedeelte op wordt geïnstalleerd). Je kan dan remote debugger enzo.

Deze functionaliteit vereist dat beide kanten dezelfde versie hebben. Dit was tot deze update gewoon mogelijk, maar nu wil de server kant niet meer installeren en dan zegt de cliënt kant ik kan de server niet bijwerken.

De use-case voor deze functionaliteit is wat mij betreft sowieso heel beperkt en als dit dan het probleem is het je ook nog wel andere problemen, zoals waarschijnlijk versiebeheer en direct op productie dingen kunnen wijzigen.

[Blorgg]

Downgraden dus. De LTS versie houd oudere versies aan van alle software paketten. En dat is prima als je dat nodig hebt. Maar dan moet je ook niet vreemd opkijken als nieuwe software er niet meer op werkt. Jammer alleen inderdaad dat Microsoft hier niet even eerder een waarschuwing voor heeft gegeven. Dan hadden mensen de update kunnen overslaan en dat had hen weer wat gedoe gescheeld.

[graey]

Dit. En daarnaast: 18.04 is LTS, maar er zijn 2 nieuwere LTS-versies. LTS kiezen is één ding, maar als je nu nog bewust op 18.04 zit, doe je dat waarschijnlijk juist omdát je specifiek oudere software nodig hebt, daar hoort VSCode nu ook bij.
Ook voor support/stabiliteit had je al overgekund naar 20.04 of 22.04.

[Eärendil]

De standard support voor 18.04 LTS is juni 2023 al geëindigd. Het zit nu in de Expanded Security Maintenance (ESM) fase (ESM provides security updates on Ubuntu LTS releases for additional 5 years)

In die fase is dit te verwachten voor externe software.

[asing]

Dit dus. "Niet zien aankomen" is een beetje jammeren om het jammeren want 18.04 is EOL en ze hadden al over gekund naar 20.04 of 22.04.

Verder is het van de LTS versies bekend dat onderdelen ervan alleen security en bugfixes krijgen. Je krijgt niet ineens nieuwe versies van paketten. Dat is allemaal helemaal prima zolang je maar binnen de repo van Ubuntu blijft. Zodra je externe repo's (zoals Microsoft in dit geval) gaat toevoegen aan je LTS versie dan weet je dat je in de problemen kan komen als die paketten wel updates krijgen.

[GertMenkel]

Ik zie ook een hele hoop klachten van mensen die aangeven dat ze dit nodig hebben voor development op CentOS 7. Mensen die op oude software vastzitten voor wat voor reden dan ook (en dat kunnen hele geldige redenen zijn), zijn niet blij dat ze ook op hun desktop met oude tools moeten gaan werken om hun oude servers bij te kunnen houden.

Microsoft had wel duidelijker mogen zijn, vind ik. Een popupje van "hee, over drie maanden werkt remote development op deze server niet meer, tijd om te upgraden" was beter geweest dan een melding diep in de release notes en het programma na een update spontaan niet meer laten werken. Natuurlijk blijft het gratis software, en iets met een gegeven paard en zijn bek, maar het zou wel netjes zijn geweest als meer mensen dit doorhadden voordat hun workflows kapot gingen.

[rbr320]

zijn niet blij dat ze ook op hun desktop met oude tools moeten gaan werken om hun oude servers bij te kunnen houden.

Maar dat hoeft helemaal niet, je kunt prima CentOS/RHEL 7 machines beheren vanaf een nieuwe versie van CentOS/RHEL/Rocky/Alma of zelfs Debian/Ubuntu zodat je gebruik kunt maken van nieuwere tools.

[Reactie gewijzigd door rbr320 op 24 juli 2024 22:01]

[Htbaa]

Maar 18.04 is niet EOL als je ESM/Ubuntu Pro hebt. Dan heb je nog tot en met 2028 :-). Maar verder eens hoor wat betreft externe repositories.

Poosje geleden bij een inmiddels uitgefaseerde Ubuntu server ook gedoe gehad met Docker via externe repo. Die ondersteunde een bepaalde filesystem driver niet meer. Het was downgraden of alle images opnieuw builden en de containers opnieuw deployen.

Het is fijn dat met ESM/Pro nog updates komen, maar dat is echt alleen in de vorm van security.

[yade]

Dat is prima, maar dat verplicht de ontwikkelaars van software zoals VS Code helemaal tot niets. Je draait dan dat, met oude ontwikkelomgevingen. Dat is dan dan wat het is.

[Cergorach]

18.04 LTS komt uit april 2018, 'End of Standard Support' was voor deze versie in juni 2023 en EOL in 2028.
20.04 LTS april 2020
22.04 LTS april 2022
En ik verwacht in april 2024 (~2.5 maanden) een 24.04 LTS.

Het is natuurlijk puur dat de OS maker dit zo ondersteund, de software makers zelf kunnen hun eigen eisen stellen.

[BlueArchon]

Inderdaad, 18.04 is zelfs officieel EOL sinds mei vorig jaar (al kan je wel nog extended support aankopen).

[divvid]

Sterker nog, ik heb software draaien die alleen onder 16.04 werkt. Dat is dus in een docker image gezet. De rest draait op 22.04

[Edsger]

Ik snap niet echt wat men had verwacht. De glibc vereiste staat in de release notes. Het specifiek bijhouden van de libraries van alle LTS en stabiele Linux versies en ze los verwittigen lijkt me ondoenlijk.
Als het nu een recente glibc zou zijn die nog heel breed gebruikt wordt zou je nog een ruime aankondiging kunnen doen, maar als je dit ook doet bij alle minor upgrades dan verval je in een wirwar van aankondigingen omdat er zo vaak wel een lib aanpassing is.

[latka]

Aan de andere kant mis ik ook de reden dat ms de dependency qua versie verhoogt heeft. Op basis van de release notes van glibc 2.2.8 zie ik er niet iets in wat visual code echt nodig heeft, dus is het eerder luiheid van ms om de versie te verhogen. Security kan het niet zijn want Ubuntu doet backports en updates op de glibc versie in 18.04. Dus ockhams razor: dit is een kwestie van luie developers bij ms.

[NMe]

Security kan het niet zijn want Ubuntu doet backports en updates op de glibc versie in 18.04.

18.04 is uit het standaard LTS-traject en alleen het pro-traject wordt nog gepatcht.

Dus ockhams razor: dit is een kwestie van luie developers bij ms.

Lui inderdaad, software die meer dan zes jaar oud is niet meer supporten ten behoeve van het up to date houden van hun developmentsoftware...

Aan de andere kant mis ik ook de reden dat ms de dependency qua versie verhoogt heeft.

Ik mis de reden waarom iemand, nota bene een developer, bejaarde software zou willen blijven gebruiken op zijn of haar ontwikkelsysteem terwijl er twee LTS-versies tussendoor zijn uitgekomen en er in april een derde uitkomt.

[SuperDre]

Noodzaak? Maar dan blijf je dus ook een oudere IDE gebruiken om je oudere software bij te houden. Ik gebruik bv nog steeds de VB6 IDE voor de oudere software, maar heb nog geluk dat deze nog steeds zelfs perfect werkt in Windows 11, al dan niet dat je bij installatie iets extra's moet doen.

[Loller1]

Luiheid? Als het luiheid was dan hadden ze geen werk gestoken in het verhogen van de vereiste. Wat een onzin. Ubuntu 18.04 is gewoon een oude LTS versie, en het is een beetje absurd van gebruikers om te verwachten dat ze de nieuwste software kunnen draaien terwijl ze er ook voor kiezen om zo oud mogelijke software te draaien...

[Jackkeayn]

Alleen is Ubuntu 18.04 sinds Mei 2023 end-of-life, dus nee die versie wordt niet meer gebackport door Ubuntu. Als je als developer nog op 18.04 hoef je voor mij geen software te schijven. Maar de kans is groot dat er een grote organisatie achter zit die lui is om te migreren naar 20.04 of 22.04.

[Verwijderd]

Wellicht API support. Een nieuwere glibc heeft wellicht nieuwere calls erin zitten waardoor bijv. Vscode beter performt of bepaalde bugs gefixed heeft of wellicht beter integratie met cgroups en docker.
Of wellicht is het impliciet vanwege dependencies voor vscode die een hogere versie vereisen.

Geen idee wat de daadwerkelijke reden is maar er zal vast wel een gegronde reden zijn.

Volgens diezelfde logica kun je je afvragen waarom game devs niet lekker bij directx 5 zijn gebleven.

[Olaf van der Spek]

Aan de andere kant mis ik ook de reden dat ms de dependency qua versie verhoogt heeft.

Volgens mij hebben ze de build servers geupdate en daardoor kun je niet meer deployen naar systemen die oudere packages hebben.

[SuperDre]

Wel reden, upgrade omdat het OS EOL is en alleen nog in extended (betaalde?) support zit, inmiddels zijn er al weer 2 nieuwere LTS versies met over niet al te lange tijd weer 1.

[Edsger]

... Op basis van de release notes van glibc 2.2.8 zie ik er niet iets in wat visual code echt nodig heeft, dus is het eerder luiheid van ms om de versie te verhogen....

Het gaat om versie 2.28. Dat zijn vrij grote release notes. Los daarvan kan het ook nog een indirecte dependency zijn.
Het lijkt mij zeer sterk dat het luiheid is. Libs updaten (met alles eromheen, testen, doc, etc) is juist een van de dingen die in de praktijk uit luiheid juist blijven liggen.

[Edsger]

Dat is wel nagelopen want het staat in de release notes.

[SuperDre]

En dat is hun goed recht. Ik ga bv ook niet meer testen of mijn applicatie nog op windows 7 of 8 werkt, werkt het nog, mooi, werkt het niet? Pech gehad. Het zijn OSsen die EOL zijn, op eventuele sporadische securitypatches na. Voor business zijn die systemen al jaren geleden afgeschreven,vdus hadden al rustig geupdate kunnen worden.

[Verwijderd]

Niet? Nou, misschien bij bepaalde hobbyprojecten niet. Ligt ook een beetje aan de support die je richting je klanten levert qua compatibiliteit, en hoe ver je je backwards compatibiliteit wilt laten gaan.

Ik ben er zelf ook wel een voorstander van om het op een gegeven moment niet te gemakkelijk te maken voor je klanten om oude meuk te gebruiken. Beetje opvoeden.
(Vooral als je met oa. financiele software werkt is het wel lekker als je vanuit security oogpunt een beetje afdwingt dat omgevingen redelijk recent zijn).

[Olaf van der Spek]

Het specifiek bijhouden van de libraries van alle LTS en stabiele Linux versies en ze los verwittigen lijkt me ondoenlijk.

Zo lastig is dat toch niet? Zeker voor de wat grotere libraries en apps.

[laurxp]

De glibc vereiste was geen enkel probleem geweest als Microsoft niet zo krampachtig vast hield aan het zelf distribueren van binariers, en het niet expliciet verbood om praktisch alle plugins te draaien op een zelfgecompileerde versie.

[Umbrah]

LTS betekent niet LUS. Ja, er zit een lange ondersteuning op het OS, maar dat het er is betekent het niet dat je het lang moet gebruiken. LTS OS-en, zeker in een land waar een tool als VScode nodig is (het is primair een dev tool, het kan meer, maar primair: een dev tool) geld doorgaans het beleid: "update regelmatig". Niemand zegt dat je daily/canary moet draaien, maar zeker drie LTS-versies achter lopen is wel heel erg ver.

Bij LTS OS-en die wél in hun langere fases (dus niet de volgende versie) of zelfs extended support fase komen, denk ik aan industriële automatisering, geisoleerde systemen, en super gespecialiseerde omgevingen. Die doorgaans verder in de 4-support-tiers gaan (general, extended, mature, retired). Een offshore edge compute systeem, een embedded industriele automatiserings appliance, of zelfs POS omgevingen: daar verwacht ik extreem LTS OS-en. Maar daar verwacht ik ook géén VSCode doorgaans, en als dat al wel zo was, dan zeker niet een rolling release VSCode, heck, in de 'grote broer die niet echt een broer is', Visual Studio, is een LTSC channel beschikbaar. Zelfde geld voor python/jupyter achtige omgevingen. Maar ergens in de software "tiering" hierarchie moet je niet release-vormen en support vormen gaan mixen. Dan krijg je namelijk dit soort ongein.

Dat gezegd hebbende, niet helemaal weten hoe packaging in dit scenario precies werkt (zelfs volgens Linus Torvalds is dat hét probleem van desktop linux wat veel devs weerhoud er voor te releasen: packagen en updaten is inconsistent door het ecosysteem heen -- is 18.06 al flatpack?), je zou er iets voor kunnen zeggen dat de package/installer/self-updater misschien een korte dependency check had moeten doen, en dan eigenlijk had moeten zeggen: "nope, not today tenzij je zelf even deze lib update".

Want let op: als je updates lang genoeg uitstelt, dan ben je snel genoeg bezig met projecten ipv beheer.

[Reactie gewijzigd door Umbrah op 24 juli 2024 22:01]

[NMe]

Jammer alleen inderdaad dat Microsoft hier niet even eerder een waarschuwing voor heeft gegeven.

Dat hebben ze dus wel gedaan, ruim op tijd zelfs...

Dit is echt nieuws van "old man yells at cloud"-niveau. Developers zijn boos dat nieuwe software, na een aankondiging zes maanden daarvoor, niet meer werkt op een LTS-versie van een OS die meer dan een half jaar geleden EOL is gegaan, terwijl er twee andere LTS-versies tussendoor zijn gereleased én er over twee maanden een derde uitkomt. Sorry, maar als je zo achterloopt dan faal je toch echt als developer als je de maker van software aankijkt voor het up to date houden van hun die software.

[Reactie gewijzigd door NMe op 24 juli 2024 22:01]

[Waswat]

Een waarschuwing was gegeven in Augustus vorig jaar zoals @GertMenkel
zegt maar blijkbaar leest niemand de release notes.

[Reactie gewijzigd door Waswat op 24 juli 2024 22:01]

[IrBaboon79]

Ik zie even niet in waarom een LTS belofte van een OS afdwingt dat je losse 3rd party tool dat ook tot in den treure moet volgen… je zou je LTS ook eens naar een 22.4 kunnen upgraden natuurlijk (we zijn al bijna bij 24.4 immers) want vscode is niet iets dat je op kritieke servers draait dus we hebben het hier over development desktops…

[ultimasnake]

Dat dacht ik ook, het is een desktop/development environment geen server…

Lts 18.04 krijgt ook al sinds maart 2023 geen security updates meer, dus helemaal een reden om die versie echt niet meer te gebruiken zou je zeggen (tenzij je een pro subscription hebt?)

[Olaf van der Spek]

Waar heb je maart 2023 vandaan?
Volgens https://wiki.ubuntu.com/Releases was juni 2023 "End of Standard Support".
End of Life is april 2028.

[ultimasnake]

Letterlijk de link die achter jouw lijst staat

https://ubuntu.com//blog/18-04-end-of-standard-support

‘ It is important to take action – either by migrating to the next LTS or upgrading to Ubuntu Pro. Unless you take action, your 18.04 LTS machines will not receive any security updates after 31 May 2023.’

(Al leer ik nu dat pro gratis is voor prive gebruik, effectief kan iedere end user tot 2028 door, maar waarom niet naar de volgen tls? Ik heb te weinig idee waarom je dat zou willen)

[Reactie gewijzigd door ultimasnake op 24 juli 2024 22:01]

[Olaf van der Spek]

after 31 May 2023

"May" is dus niet "maart"...

Ik heb te weinig idee waarom je dat zou willen)

Blijkbaar grote deployments / clusters, met custom software die mogelijk niet goed draait op een nieuwer OS.

[Reactie gewijzigd door Olaf van der Spek op 24 juli 2024 22:01]

[biteMark]

"May" is dus niet "maart"...

Maakt dat wat uit? We hebben het nog steeds over 2023.

[Olaf van der Spek]

Het maakt niet veel uit, ik begreep alleen niet waar die datum vandaan kwam.

[ultimasnake]

Inderdaad foutje van mij, maar visual studio gebruik je niet op clusters

[Olaf van der Spek]

Inderdaad foutje van mij, maar visual studio gebruik je niet op clusters

Als ik https://github.com/microsoft/vscode/issues/203967 een beetje lees is niet iedereen het daar mee eens.

[CAPSLOCK2000]

Blijkbaar grote deployments / clusters, met custom software die mogelijk niet goed draait op een nieuwer OS.

Ik snap hoe het in praktijk werkt maar wil even duidelijk stellen dat het echt probleem hier zit bij die "custom" software die blijkbaar niet goed wordt onderhouden, of zo moeilijk in het beheer is dat die effectief niet onderhoudbaar is.

Momenteel klopt het "hart" van de software-industrie op ongeveer 1 major release per 2 jaar voor besturingssytemen en dergelijke grote pakketten. Dat beketent dat je iedere 2 jaar een grote upgrade hoort te doen.

Omdat dingen nu eenmaal tijd kosten en soms fout gaan geven de grote fabrikanten ongeveer 5 jaar ondersteuning op hun software. Dan kun heb je een heel cyclus de tijd om je upgrades te regelen met wat extra voor het geval er iets mis gaat. Helaas wordt dat nogal eens uitgelegd als dat je een release kan overslaan en maar eens in de 4 jaar een upgrade hoeft te doen. Daarbij vergeten mensen dat upgrades moeilijker worden naarmate de software ouder is en dat ze dan nog maar 1 jaar hebben om alle upgrades te regelen. Mensen denken dat ze tijd besparen door releases over te slaan maar in mijn ervaring werkt het precies omgekeerd. Na 4 jaar heb je veel meer werk aan een upgrade dan na 2 jaar. Hoe langer je wacht en hoe meer afhankelijkheden er ontstaan van specifieke versies / features / bugs / vergeten gaatjes in de firewall / verkeerde rechten / etc... Dit soort dingen sluipen er altijd in en pas bij de volgende grote verandering merk je dat er zaken zijn die niet werken zoals het hoort. Daarnaast zakt kennis en ervaring weg en krijgen mensen andere functies. Hoe langer je wacht hoe groter de kans dat belangrijke informatie verloren gaat waardoor toekomstig onderhoud moeilijker wordt.

De werelds is niet perfect en soms blijf je helaas zitten met systemen die echt niet meer te moderniseren zijn. Voor dat soort systemen zijn er "extended support"-achtige constructies die tot wel 10 jaar ondersteuning geven, maar dat is als een patient die in het ziekenhuis in leven wordt gehouden met kunstmatige beademing en sondevoeding. Helaas zijn er nogal wat mensen die alleen maar zien "10 jaar support" en denken dat ze dus 9 jaar niks hoeven te doen en dan nog een jaar hebben om hun systeem te upgraden en even 5 major releases in te halen. Dat mislukt steevast.

Je moet dus iedere 2 jaar een major upgrade doen. Niet alle software brengt iedere twee jaar een nieuwe major versie uit maar genoeg software doet dat wel en in ieder geval het OS. Dat alleen zou voldoende reden moeten zijn om te upgraden.

[Christoxz]

Volgens mij dwingt niemand het af maar kwam het onverwachts, waardoor ze er niet blij mee zijn.

Verder kan het logisch zijn om ook development te doen op een oudere LTS, als de productie daar ook op draait. Dat maakt testen wel zo makkelijk.

Neemt verder niet af dat je dan ook gewoon soms oudere software moet accepteren, zoals VSCode

[Reactie gewijzigd door Christoxz op 24 juli 2024 22:01]

[CH4OS]

Volgens mij dwingt niemand het af maar kwam het onverwachts, waardoor ze er niet blij mee zijn.

Zoals in de eerste post van deze thread te lezen valt; het was al aangekondigd in Augustus 2023. Als je het dan niet hebt zien aankomen, dik een half jaar geleden dus al had kunnen lezen, nadat zelfs de support op Ubuntu 18.04 gestopt was en het de extended support in ging. Maar vervolgens klagen developers bij Microsoft omdat ze niet lezen en zichzelf voorbereiden? Sowieso vreemd om als developer op een oude versie van Ubuntu te zitten die al zes jaar oud is en er zelfs twee nieuwere LTS-versies gereleased zijn.

[Reactie gewijzigd door CH4OS op 24 juli 2024 22:01]

[SirBlade]

Er is anders een vocale minderheid van tweakers die op de desktop ook de oudst mogelijke Windows LTSC blijven hangen voor hun daily driver. Dat soort figuren zullen er ook vast aan de linux kant zijn.

[biteMark]

Tsja dan moet je ook de consequenties accepteren, 3rd-party software kan moeilijk rekening houden met LTS OS’s.

[TunefulDJ_Mike]

18.04 LTS is al bijna een jaar niet meer supported, alleen via Ubuntu Pro kan je nog Extended Security Maintenance krijgen

[Hydranet]

Ik neem aan dat ze het over de deb package versie hebben, dan lijkt mij dat de Snap of Flatpak wel moet werken, maar ik kan het niet testen.
https://snapcraft.io/code
https://flathub.org/apps/com.visualstudio.code

[Reactie gewijzigd door Hydranet op 24 juli 2024 22:01]

[vrilly]

Ik snap niet dat de nieuwe deb geïnstalleerd kan worden? Normaal zou de package manager direct nee zeggen als er niet aan de glibc wordt voldaan, en een beetje maintainer zorgt dan voor een oplossing of stopt de support en pinned de package op een bepaalde versie.

[Hydranet]

Dat lijkt mij af te hangen hoe het package gemaakt is, want ik heb wel is mee gemaakt dat een nieuwe versie van atom nog wel wou installeren op een RHEL7 systeem maar weigerde op te starten.

[hackerhater]

Als de deb aan geeft dat ie minimaal glibc 2.2.8 nodig heeft ja.
Als........

[rneeft]

Ik ben maar een simpele Windows gebruiker dus ik ben wel even nieuwsgierig waarom dit een issue is? Microsoft stelt een nieuwe versie van een library verplicht (minor +1) dat al sinds 2018 beschikbaar. Klinkt mij in de oren als, upgrade dat even en klaar, of eigenlijk waarom staat een nieuwere versie niet überhaupt al geïnstalleerd.

[windwarrior]

glibc is een fundamentele library op een Linux systeem en daar link je dynamisch mee. Als je een LTS hebt kan het maar zo zijn dat je een oude glibc hebt, updaten niet kan, of dus overal tegelijk glibc voor update.

[Daco]

zie men comment naar @raro007 : Daco in 'Ontwikkelaars klagen dat VS Code op Ubuntu 18.04-lts plotseling niet meer werkt'

glibc is de core c/c++ library die , o.a. , bepaalde functies omzet naar kernel syscalls

[Reactie gewijzigd door Daco op 24 juli 2024 22:01]

[berchtold]

Alhoewel ik het eens ben met de meesten die zeggen dat ubuntu 18 niet meer supported is. Vind ik het wel slechte zaak van microsoft dat ze een update lanceren die lukraak geïnstalleerd wordt zonder dat die update zelf een check doet of een systeem compatible is met die update

[qlum]

Eens, voor native apps zou de app zichzelf normaal niet moeten updaten, dit is aan de distro om te doen. Werkt dat niet dan zijn er flatpaks, appimages en helaas ook nog snaps.

[Vicky Ronnen]

Vergelijk software ontwikkeling met een drie sterren restaurant.
Jij bent als senior developer, de chef der chefs.
Wanneer een driesterren chef gaat koken met ingrediënten die over de THT/TGT datum zijn, zal het restaurant terecht door de NVWA gesloten worden.
In software land zou dit niet anders moeten zijn. Hopelijk maakt NIS2 een einde gebruik van bedorven software.
Wat gaat er mis in je lifecycle management wanneer je een EOS LTS gebruikt?
Er is geen lifecycle management is waarschijnlijk het eerlijkste antwoord.
Agile zijn betekent ook nieuwe versies van OS, database etc. kunnen absorberen in je project.
Fabrikanten die failliet gaan of stoppen met een product?
Reden om direct naar een vervanging te kijken en die met spoed in te voeren.
De klant heeft de impliciete verwachting dat er state of the art geleverd wordt, geen antieke zooi.
In contracten is nooit opgenomen dat de klant akkoord gaat met antieke zooi.
Het updaten van dependencies naar de laatste versie kan geautomatiseerd worden in de CI/CD.
Immer professionele software heeft een testsuite met minimaal 80% dekking.
Wanneer alle tests groen blijven na update, hoeveel discussie is dan nog nodig om de laatste versies door te zetten naar productie.
Ja maar we hebben geen testsuite… Dan schrijf je dus legacy software, geen professionele software.

Bijblijven betekent bijdragen aan de kenniseconomie,
Blijven stilstaan betekent bijdragen aan een achterhaalde kenniseconomie.

[Blokker_1999]

Hoewel dit artikel nu de focus legt op Ubuntu 18.04 zijn er andere situaties te lezen in de bugtracker waarbij je al sneller kunt zeggen dat er wel degelijk situaties zijn waarin dit voorkomt. Wanneer je zelf volop met oude code bases moet werken die gebruik maken van oude libraries is het ineens een heel stuk minder eenvoudig om je editor wel in een moderne omgeving te draaien.

En als je klanten honderdduizenden euro per jaar geven om die oude versie van je software te blijven ondersteunen maar geen miljoenen wensen te investeren om te upgraden naar je meest recente release. Wat ga jij als software ontwikkelend bedrijf dan doen?

De klant heeft vooral de verwachting dat je product goed blijft werken, performant blijft werken tegen bodemprijzen. Die hebben geen zin een grote upgradetrajecten met, in het ergste geval, grote downtime en een resem storingen tot gevolg. Die klant geeft er niet om dat het state of the art is of dat je nog hoogbejaarde mensen in dienst moet houden om het draaiende te houden.

[R4gnax]

En als je klanten honderdduizenden euro per jaar geven om die oude versie van je software te blijven ondersteunen maar geen miljoenen wensen te investeren om te upgraden naar je meest recente release. Wat ga jij als software ontwikkelend bedrijf dan doen?

Nou- als je enige morele verantwoordelijkheid hebt voor de situatie alsmede de beveiligingsproblematiek met oude software-pakketten die allang tot vergane glorie behoren, dan vertel je zulke klanten: "betalen, of oprotten."

En als iedereen dat consquent zou doen, dan zou er geen keus meer zijn en zouden ze moeten betalen.
Waarna uiteraard de dienstverlening weer duurder zal worden, want die kosten moeten verrekend worden.
En dat zal bij de concurrenten niet anders zijn.

En voor je het weet ben je dan weer terug bij de situatie voor de vergaande digitalisering die zogenaamd alles sneller, beter, en vooral goedkoper zou maken. Dat laatste valt dan dus gewoon weg.

[Microwilly]

Als je oude software ontwikkeld. Dan kan je toch prima de 'oude' Vscode blijven draaien.

[DaSt1986]

Dit betekend overigens ook dat de `remote-ssh` extensie niet meer werkt als je connect naar een server met een oude `libc` (Ubuntu 18.04 en CentOS 7)