Microsoft laat Ubuntu 18.04-gebruikers alsnog VS Code gebruiken voor een jaar

Microsoft gaat het voor besturingssystemen zonder glibc 2.28 toch mogelijk maken om VS Code te gebruiken. Daardoor kunnen gebruikers van Ubuntu 18.04 alsnog VS Code blijven gebruiken. Microsoft meldt wel dat de GNU C Library-versie vanaf volgend jaar wel nodig is.

Microsoft meldt dat VS Code een update krijgt waardoor de software te gebruiken is op besturingssystemen zonder glibc 2.28. Gebruikers krijgen dan wel een melding in beeld dat het besturingssysteem niet meer door Microsoft officieel wordt ondersteund. De update moet naar verwachting deze week beschikbaar komen.

De mogelijkheid om Ubuntu 18.04 te blijven gebruiken is niet permanent; over twaalf maanden zal VS Code niet langer werken op besturingssystemen zonder glibc 2.28 of lager. "We hopen dat dit jullie en jullie bedrijven de benodigde tijd zal geven om te migreren naar nieuwere Linux-distro's", schrijft een Microsoft-medewerker. De medewerker bedankt gebruikers voor het delen van 'jullie feedback en passie voor VS Code'.

De stap is een reactie op klachten van ontwikkelaars die Ubuntu 18.04 gebruiken, een longtermsupportrelease. Dit besturingssysteem bevat glibc 2.27 en dus niet glibc 2.28, een GNU C Library die in 2018 uitkwam. Deze gebruikers konden daardoor sinds de januariupdate geen gebruik meer maken van de recentste versie van VS Code. Overigens is Ubuntu 18.04 inmiddels een jaar end of life en krijgen alleen betalende gebruikers nog beveiligingsupdates.

Reacties (93)

[wildhagen]

Nette en coulant actie van Microsoft, door dit beschikbaar te stellen voor een OS versie die al een jaar end of life is.

Maar een wellicht domme vraag, ik weet te weinig van Linux: kun je die versie 2.27 van die library niet gewoon upgraden naar de vereiste versie 2.28? Of zit dit zo verweven in het OS dat Linux dit niet toestaat?

[rob12424]

Ja dat kan vaak wel maar is ingewikkeld vanwege beveiliging. In het uiterste geval kun je chroot of lxc container.

Maar de ingewikkelde manier is te re-linken.

Je zegt dan programma a moet gelinkt worden aan glibc versie 1.0 en mag niet upgraden.

En programma b moet gelinkt worden aan glibc versie 2.0

Zie hier de instructies:

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

Besef wel diehard Linux gebruikers doen dit lang niet altijd omdat het giga veel werk kan zijn en beveiligingsproblemen.

Dit zijn dingen die Windows volgens mij niet eens kan.

[TheVivaldi]

Het hangt ook van je distro af. openSUSE Tumbleweed hercompileert alle pakketen automatisch na een glibc-update, dus dan heb je zo een systeemupdate met een paar duizend pakketten.

[sfranken]

Tumbleweed en Ubuntu LTS hebben dan ook een compleet andere kijk op dingen en een compleet ander publiek. Een LTS (Ubuntu in dit geval) moet stabiel zijn en een ontwikkelaar moet erop aankunnen dat versie X en Y van alles over 5,6,7 jaar (EOL datum) hetzelfde is, aangezien daar vaak (maatwerk) software op draait waar een klant diep voor in de buidel tast.

Tumbleweed is, in mijn ogen, vergelijkbaarder met Fedora Rawhide. Meer een testbed voor RHEL/SLES/SLED

[TheVivaldi]

Wat heeft dat met mijn punt te maken? Lees even terug: de persoon waarop ik reageerde had het over

“Besef wel diehard Linux gebruikers doen dit lang niet altijd omdat het giga veel werk kan zijn en beveiligingsproblemen.”

Linux-gebruikers, dus niet specifiek Ubuntu. En diehard ook nog. De meeste diehard-gebruikers zitten niet eens op Ubuntu.

(En je vergelijking gaat ook mank, want Tumbleweed is niet hetzelfde als Rawhide. openSUSE Factory is de tegenhanger van Fedora Rawhide.)

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 19:03]

[Aldy]

Wat heeft dat met mijn punt te maken? Lees even terug: de persoon waarop ik reageerde had het over

Off topic: Soms is het beter om een quote te gebruiken, omdat alle commentaren volledig onoverzichtelijk worden als er veel van zijn. Je zoekt je een ongeluk om te zien waar iemand op reageerde en dan hoop je ook nog dat je het juiste commentaar hebt. Zeker als iemand veel gereageerd heeft.
Ik heb op het laatst jouw quote erboven gezet, want ik hou er ook niet altijd rekening mee dat mijn commentaar anders een losse flodder is.

[sfranken]

Ik weet dat Tumbleweed niet 1:1 te vergelijken is met Rawhide, daar ging het ook niet om. Het zit echter veel dichterbij Rawhide dan bij een LTS (ala RHEL), dát was het punt. Excuses dat dat niet duidelijk was.

[TheVivaldi]

Nogmaals: het zit niet dichtbij Rawhide, verre van zelfs. Factory zit dichtbij Rawhide. Sterker nog: dat zijn in wezen gewoon broertjes van elkaar.

Op Tumbleweed wordt veel meer getest voordat een en ander wordt uitgerold, daarom ook dat het vaak dagen of zelfs een paar weken duurt voordat zelfs zoiets als een (simpele) puntupdate van iets wordt uitgerold. Een LTS is het inderdaad niet, maar het is ook geen testbed. Er is gewoon geen vergelijking met Fedora/RHEL mogelijk.

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 19:03]

[Bathing Aap]

Je kan het kortweg op Windows zo moeilijk of makkelijk maken als je zelf wil, dus of compleet self-contained apps maken zonder enige afhankelijkheid van de host OS qua libraries, of een DLL hell creëren.

[.oisyn]

Dit zijn dingen die Windows volgens mij niet eens kan.

Wat kan Windows precies niet? Want wat Windows niet heeft is dat je vast zit aan een specifieke library voor een specifieke OS release. Glibc is de GNU implementatie van de C runtime. Blijkbaar heeft een specifieke distro zijn eigen vaste versie. Er is eigenlijk geen equivalent voor Windows. The C runtime wordt geleverd door door je dev-omgeving (typisch dus Visual Studio op Windows, maar elke VC++ heeft zijn eigen versie). Dan is er nog de platform SDK die toegang geeft tot de native win32 API, maar die is in principe backwards en forwards compatible (je kunt opgeven welke minimale Windows versie je wilt ondersteunen, en het werkt nog steeds op toekomstige versies). Verder kun je vrij gemakkelijk DLLs overriden zolang de interface compatible is.

[Power2All]

Kan wel, maar dan moet je de libraries die nodig zijn in het folder van de binary hebben.
De binary zoekt namelijk eerst lokaal naar het te gebruiken DLL bestand, om vervolgens op andere path locaties te kijken. Deze methode wordt ook vaak gebruikt met injecten van cheats, of de shader apps enzo. Maar we hebben het over libraries, niet over platforms. Werkt ook wel in Windows, maar kan lastiger worden iig.

[Reactie gewijzigd door Power2All op 23 juli 2024 19:03]

[bush]

dat is afhankelijk van welke libraries het zijn, als het dotnet libraries zijn kan het wel degelijk op windows zie
https://learn.microsoft.c...embly-binding-redirection

[Mushroomician]

Wie werkt op een OS dat al een jaar EOL is, is waarschijnlijk niet zo bezig met beveiliging. Mits die machine natuurlijk online is. Air gapped systemen hebben er natuurlijk geen last van, maar die upgraden ook VSC niet.

[bazzi]

CentOS 7.x en andere RHEL 7.x derivaten waren ook allemaal in ene buitengesloten. Terwijl CentOS7 nog een half jaar niet eol s en veel wordt gebruikt, ook als je de comments leest op de issues…

En dan is er nog extended support wat je voor veel RHEL 7.x kan krijgen, dat rekt het zo 5 jaar.

Daarom een half jaar voor eol date stoppen met ondersteunen van een distro dat veel gebruikt wordt is niet echt “slim”/net.

Waarom tweakers alleen over Ubuntu 18.x praat is mij een raadsel, zeker als je de comments leest op github…

[Reactie gewijzigd door bazzi op 23 juli 2024 19:03]

[graey]

Klopt, maar CentOS 7 zit ook wel in z'n laatste maanden en is al een tikje ouder dan Ubuntu 18.04.
Mooi dat de uitgever dat tien jaar ondersteunt, maar je kan niet van elke derde softwareboer verwachten dat die dat dan ook doet. Zeker niet als het om ontwikkelaarssoftware gaat, lijkt me.

[Robtimus]

Betalende gebruikers krijgen wel degelijk beveiligingsupdates, dat staat in het artikel:

Overigens is Ubuntu 18.04 inmiddels een jaar end of life en krijgen alleen betalende gebruikers nog beveiligingsupdates.

[MrFax]

Ook niet betalende gebruikers: Ubuntu Pro is voor persoonlijk gebruik gratis, waarmee je dus nog steeds updates krijgt voor Ubuntu 18.04

[Reactie gewijzigd door MrFax op 23 juli 2024 19:03]

[fifnih]

Ubuntu 18.04 LTS is niet EOL maar end of standard support. Een beetje bedrijf heeft Pro support afgesloten op Ubuntu. Er is dan nog 5 jaar security maintenance na het standard support. bij 18.04 LTS dus nog tot april 2028.

Als ik in onze organisatie kijk moet een oud operating system regelmatig zo blijven omdat applicatieteams niet tijdig zijn begonnen met migreren of aanpassen van de applicatie waarvoor die server was ingericht.

[bantoo]

Het laatste. Linux distributies worden nogal raar in elkaar geplakt en om de een of andere reden vonden ze het nodig om allerlei kernfunctionaliteit in een gigantische DLL te rammen. Dit probleem komt zeer vaak voor met Glibc.

[kdekker]

Het heet geen DLL, maar shared library. En volgens mij is glibc (eigenlijk dus de C-runtime) best redelijk beperkt qua omvang. Heeft jouw programma code meer functionaliteit nodig, dan heb je vaak veel meer afhankelijkheden dan alleen naar glibc. Alle GUI dingen, alles met database, veel met security, het zit allemaal niet in glibc.

Aan de andere kant: wat blokkeert Ununtu gebruikers om naar een hogere Ubuntu versie te stappen. Er zijn al 2 nieuwere LTS versies.

Ik heb jaren lang op Linux geprogrammeerd en de afhankelijkheid naar een specifieke glibc versie is 1x voorgekomen, a.g.v. een compiler breuk ik gcc. Ergens tussen 1.8x en 2.x als ik me goed herinner. Daarna nooit meer (al was het een uitdaging om 1 Linux build te maken die op en Suse SLES en RedHat ES draaide, omdat beide clubs hun eigen release schema hebben). Maar goed, ik ben ook al weer jaren weg uit Linux land (soms best wel jammer). Ik heb om Windows echt wel meer breuken meegemaakt, c.q. 10-tallen (of veel meer) varianten van de tegenhanger van (g)libc (MSVC runtime). Denk maar aan de WinSxS ellende. En (bijna) iedere Visual Studio versie (de Microsoft tegenhanger van gcc) had een eigen versie van de runtime. Al lijken de laatste jaren dat beperkt te zijn tot een stuk of 6 vanaf 2005 (https://learn.microsoft.c...d-vc-redist?view=msvc-170).

Kortom: hoewel er vele (g)libc versies zijn, zijn ze bijna altijd backward compatibel (= geen ABI breuk). Zie ook: https://stackoverflow.com...fferent-versions-of-glibc.

Wel zal een distro vaak alleen maar minor updates doen en geen major versie update van (g)libc. Kortom: upgraden van Ubuntu lijkt me de meest logische keuze. Zes jaar met 1 OS is best lang.

[Reactie gewijzigd door kdekker op 23 juli 2024 19:03]

[MrFax]

Qua omvang is de Glibc niet zo groot, maar het heeft wel de kernfunctionaliteit om C(++) te kunnen runnen, wat natuurlijk gigantisch veel gebruikt wordt.

[Reactie gewijzigd door MrFax op 23 juli 2024 19:03]

[kdekker]

Dat klopt. De Linux kernel zelf is ook (voor een deel) in C geschreven. En daarom is het zo ongebruikelijk dat er compatibiliteitsbreuken zijn. Ik denk eerder dat visual code iets wil gebruiken wat alleen in de nieuwere glibc zit. Dat zou ik geen compatibiliteitsbreuk noemen (een C programmeur kan vaak ook met oudere code ook wel bereiken wat die met nieuwere code wellicht eenvoudiger kan), maar meer een systeem vereiste voor een bepaald software pakket.

Ik houd het verder niet meer zo bij, maar mijn eerder genoemde URL van stackoverflow laat zien dat de ABI compatibiliteit dicht tegen de 100% aanzit (en de incompatibiliteiten die er zijn, zijn vaak edge cases c.q. weinig gebruikte constructies).

Zonder libc heb je idd geen Linux systeem. En het programmeren van buffer overflows horen nu eenmaal bij libc, omdat er in ISO/ANSI/POSIX genoeg functies zijn die geen buffer size meegeven. In die zin weet ik ook niet hoe vaak libc met security issues te maken heeft a.g.v. van fouten in libc zelf.

[BeosBeing]

Aan de andere kant: wat blokkeert Ununtu gebruikers om naar een hogere Ubuntu versie te stappen. Er zijn al 2 nieuwere LTS versies.

Voor de meeste thuisgebruikers niets. In principe kun je gewoon sudo apt update gevolgd door sudo apt upgrade doen (in Debian werkt dit behoorlijk betrouwbaar) of je gebruikt de grafische software updater. Normaal worden dan alle relevante pakketten bijgewerkt.

Bij Linux Mint kun je in principe ook zo updaten maar het wordt expliciet afgeraden (ze testen het waarschijnlijk zelf niet) en raden aan altijd een verse install te doen. Als je na het installeren van het basissysteem veel extra pakketten installeert (een andere browser, een paar spellen, wat andere dingen, iets dat niet in je packagemanager zit) dan kan het een uitdaging zijn om die na de distributie-upgrade ook weer terug te installeren. Weet je nog precies wat dat allemaal was?

Ik heb echter ook al meegemaakt dat je daarna een heel mooi boot-scherm kreeg met daarna een inlogprompt in zwart op een zwarte achtergrond, en op de systemen waar ik Linux op draaide kreeg ik dat zwart op zwart met alle Debian-afgeleiden, dus naast Ubuntu Studio en Xubuntu ook SolydX, SnowLinux e.a.

En als het linux-systeem zakelijk gebruikt wordt, zeker met custom made software, en er is een hele afdeling van afhankelijk dan wil je toch wel eerst goed testen, eerst met ieder softwarepakket apart en dan met verschillende combinaties. In het Windows-wereldje heb je bedrijven die pas over stapten van Windows XP op Windows 7 als windows 8 al uit was (Vista overgeslagen) en bedrijven die pas overstapten van Vista of 7 naar 8 als 10 al uit was, puur omdat het testen zoveel tijd vergt.

[Reactie gewijzigd door BeosBeing op 23 juli 2024 19:03]

[Goderic]

Is dat zo anders dan op andere platformen? Ook op andere Unixen heb je een libc en op Windows is er de Windows API.

[Sebazzz]

De reden dat userspace in Linux zo gemakkelijk breekt is één van de redenen van Docker. Iets als WinSxS bestaat niet echt op Linux.

[RiDo78]

Soms kun je dat wel, al loop je dan wel het risico dat je dat buiten je packagemanager (= soort windows installer) om moet doen. En dat an sich is al een bad practise.

Maar er zijn een aantal libraries die zijn zo fundamenteel en/of veelgebruikt dat je dat gewoon niet eens overweegt. De glibc library is daar het ultieme voorbeeld van. Net als dat he niet met je vingers aan bepaalde dll’s in Windows komt, kom je ook niet aan de glibc.

Wat je hier eigenlijk ziet gebeuren is dat Visual Studio er van uit gaat dat bepaalde functies op het OS beschikbaar zijn. En na de update van Visual Studio werken de gecompileerde programma’s ineens niet meer op -zeg- Windows X, die al een jaar niet meer standaard ondersteund wordt. Maar als blijkt dat veel bedrijven nog gebruik maken van een versie van Windows X en daarbij een contract hebben voor de verlengde ondersteuning, dan gaat er toch iets mis.

Nu heeft Microsoft natuurlijk op financieel vlak niets aan de gebruikers met een Ubuntu 18 LTS contract, maar het kan wel het vertrouwen van gebruikers en developers in VS beschadigen. En als het een kleine moeite is om dat terug te draaien… waarom dan niet?

[learn_more]

Zoiets is zeer zelden een kleine moeite.

[TheVivaldi]

Maar in dit geval wel, want in de nieuwste versie is het enige grote verschil dat er een controle plaatsvindt. Verder is er niks in de code gewijzigd dat afhankelijk is van een nieuwere glibc-versie (wel andere dingetjes). Wellicht dat ze dat wel van plan waren voor komende updates, maar nu is dat nog niet het geval. Dus in dit geval is het wel degelijk een kleine moeite om de controle er weer uit te halen: is een kwestie van de regels code met controle er weer uit halen, hercompileren en testen. Dat is niet gratis, maar niet dusdanig kostbaar dat het het niet waard is om terug te draaien. Daarom ook dat MS dat doet.

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 19:03]

[edeboeck]

Ik vind niet dat dat aan Microsoft zou moeten liggen. Als je beslist om een OS te gebruiken dat al een jaar EOL is, dan gebruik je toch gewoon de laatste versie van VS Code die wel werkt? Idem voor de OS'en die quasi EOL zijn.

[MrFax]

Je hebt best wel gelijk. Alles wat je handmatig moet installeren gaat later een keer een probleem geven. Daarom moet je bij linux servers ook altijd alles grondig testen nadat je iets handmatigs doet. Dit is wel het grootste nadeel van Linux, en waar Windows dan juist weer beter in is; compatibility. Bij Linux blijf je het beste bij de distro repo.

[Reactie gewijzigd door MrFax op 23 juli 2024 19:03]

[Jorick]

Alleen is het OS in kwestie niet end-of-life want het krijgt nog tot april 2028 beveiligingsupdate, zie https://ubuntu.com/about/release-cycle#ubuntu. Wel is het zo dat ik weinig redenen kan bedenken om niet te updaten naar een recentere LTS release.

[TheVivaldi]

En zoals al vaker gezegd en ook in het artikel staat: dat is alléén voor betalende klanten.

[Jorick]

Niet helemaal, hangt af van het aantal systemen dat je in gebruik hebt:

Ubuntu Pro is free for personal and small-scale commercial users on up to 5 machines and transparent, per-machine pricing for enterprises. It is available for desktops, servers, and IoT devices and on public clouds – AWS, Azure, Google, IBM and Oracle.

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

[latka]

Support tot 2028. Weinig end of life aan hoor.

[TheVivaldi]

Voor betalende klanten, ja. Dat is net alsof je zegt dat Windows 8.1 niet EOL is, terwijl Windows 8.1 alleen nog updates voor betalende klanten krijgt.

[_Thanatos_]

Ik weet ook weinig van Linux, maar ik weet dat het in Windows mogelijk is om een benodigde (andere versie van een) DLL gewoon naast de executable te gooien, en dan wordt die gepakt. Beetje kort door de bocht, maar dat is één van de manieren om een DLL als het ware te overrulen. Kort door de bocht dus heh, uitzonderingen daargelaten enzo.

Wellicht kan zoiets op Linux ook? Dus dat VScode voor oudere distro's wordt gebundeld met de library die nodig is. Weet iemand of zoiets kan?

[psychicist]

Dat doe ik vaak genoeg met applicaties die een bepaalde versie van een library nodig hebben. Het is niet zo eenvoudig als een shared library in een directory plaatsen, maar met een wrapper script kun je de variabel LD_LIBRARY_PATH zetten en dan de executable aanroepen. Dan werkt het prima.

Maar meestal heeft iemand wel een flatpak, snap of appimage aangemaakt, waardoor dit allemaal niet hoeft. Ik doe het eigenlijk alleen bij zelf gecompileerde software in mijn home directory (in $HOME/$APPLICATION/$VERSION).

Zoiets zou bij VScode ook gedaan kunnen worden, maar dat gaat nog steeds voorbij aan het feit dat de gebruikte versie van Electron glibc 2.28 vereist, zoals ik heb begrepen uit dit artikel.

[Borromini]

Zowat alles van je besturingssysteem en programma's dient met/tegen die GNU C library gecompileerd, dus nee, die vervang je niet effe als eindgebruiker. Die zit zodanig diep in het systeem verweven dat je ook niet effe een recente versie installeert voor één programma.

[Sayko]

Niet als de applicatie kijkt naar os versie dunkt mij.

[markg85]

I.t.t wat @rob12424 zegt en wat meer een antwoord op wat @wildhagen vraagt:
Nee, dat kan niet*.
glibc is zo'n library die op het diepste niveau van linux zit. Een update in die library zorgt er vaak voor dat heel veel andere pakketten ook moeten updaten. Soms zo simpel als een recompile maar dan nog is dat voor een distributie dus een nieuw pakket.

Roling releases (zoals Arch linux) doen deze updates wel, die zijn dan ook altijd up to date.
Fixed releases (niet rolling, zoals Ubuntu) doen doen deze diepgaande updates over het algemeen niet of alleen als er een hele goede reden is. Je ziet bij deze type distributies eerder dat een programma dan simpelweg de volgende versie van de release vereist.

* er zijn vele andere manieren om hier omheen te werken. De optie van @rob12424 kan, een andere is via een docker container (vscode draait dan in de container) en zo zijn er nog wel wat andere. Het maakt het allemaal niet makkelijker dus updaten is wel beter

[Mortov Molotov]

Net en coulant, maar verder begrijp ik de reactie van die gebruikers van Ubuntu 18.04 niet helemaal.

Ik bedoel: die versie is EOL? So what gives?

[Clemens123]

Kan...maar dat is niet hoe stable distributies vaak werken: de libs worden niet meer geupdate, tenzij met kritische security patches, geen functionele / api wijzigingen. Reden is dat alle paketten in de distro niet voor verassingen komen te staan, en je zeker kan zijn dat er zolang je geen versie verhoogt er iets breekt. Wat hier wel zou kunnen is met een docker image werken of met technologieen als appimage/snap/flatpack.

[rdk1980]

Je moet de hele stack hercompileren. En dan kun je ook te maken krijgen met ongewild bugs..kan je beter systeem uograden naar de jongere lts...

[Htbaa]

Zou het beschikbaar maken van VS Code als een snap package het gehele probleem niet oplossen? Dat was toch het idee van snaps dat je niet compleet gebonden bent aan de software libraries die bij het besturingssysteem komen?

[cricque]

Ja maar het merendeel wil geen snaps/flatpack whatever. Het zijn gewoon containers zodat je alles mogelijk 100x op je systeem hebt staan, weliswaar in zijn eigen container. Ok voor thuisgebruik is storage grootte misschien geen issue meer. Maar ik zou er niet moeten aan denken dat alles snaps of flatpack is. Er is niks mis mee met een .deb package. Alleen heeft elk systeem ook weer zijn eigen dingen ... aur, rpm, deb ... Of gewoon source. Maar als het echt niet anders kan wil ik het nog wel overwegen. Maar het hoeft al jaren niet, dus waarom dan overschakelen naar snaps of flatpack ofzo. Tevens moet dit dan ook weer nog werken op de oudere distributies. En sorry maar de 18.0 lts is al meer dan een jaar end of life. Dat wist je op voorhand. En als vscode echt een must is .... je kan toch altijd gewoon een oude versie blijven gebruiken ? Ja er zijn wel maandelijkse updates, maar van die vele updates die er geweest zijn, is er qua interface niet zoveel verschil. En als jij de laatste nieuwe functie nodig heb, dan heb je pech. Ik maak er trouwens al gebruik van toen vscode nog in beta was. Snap heel de heisa niet. Wel mooi van MS om alsnog een versie te maken.

[svenk91]

Het hoeft niet flatpack-only te worden. Maar als alternatief voor mensen die op een EoL versie van een Linux distro willen hangen is het wel een uitkomst. De meeste mensen kunnen idd beter een .deb of iets dergelijks gebruiken, maar die zullen ook op een recente (LTS) release zitten.

[TheVivaldi]

AUR is geen pakketsysteem, maar ik snap wat je bedoelt. Ik heb ook liever losse pakketten en als het écht moet een AppImage. Met AppImage heb je al die zooi die Snap en tot op zekere hoogte Flatpak leveren niet.

[sfranken]

Je weet dat flatpak (snap weet ik niet, blijf ik ver van weg) aan resource deduplicatie doet he? Als applicatie A en B beiden library C nodig hebben word die dus maar 1x geinstalleerd, en daarna gedeeld tussen applicatie A en B.

[brianbitchballs]

Zou het updaten van je OS die ondertussen 6 jaar oud is ook niet het gehele probleem oplossen?

[Terr-E]

Ubuntu 18.04 wordt nog ruim 4 jaar ondersteund door Canonical en RHEL 7 nog een aantal maanden door IBM, en sommige organisaties maken daar nou eenmaal gebruik van vanwege… redenen. Maar wat mij dan het meest verbaasd is waarom upgraden van het OS geen prio heeft maar het updaten van VS Code wel? In wat voor niche zit je als je nog gebonden bent aan Ubuntu 18.04/RHEL 7 maar niet meer VS Code van vorige maand mag gebruiken en ook geen Snap / Flatpak package kan installeren?

[Terr-E]

Er is een snap package van VS Code.
Geen idee of deze ook op 18.04 werkt (lijkt me wel, dat is het hele idee van snaps, toch?) en of het probleem zich daarin ook voordoet…

[Rarz]

Initieel dacht ik dat het wel weer zo'n situatie is van 'er is een nieuwe versie van een library dus moeten we door want beter'. glibc 2.28 is blijkbaar het minimum - maar als je vervolgens eens even kijkt naar de release history van glibc zie je dat die al op 2.40 zit en 2.28 al zes jaar oud is - tamelijk prehistorisch.

[Reactie gewijzigd door Rarz op 23 juli 2024 19:03]

[latka]

Prehistorisch maar gewoon ge-support tot 2028 voor security patches... altijd de laatste versie installeren is ook geen optie omdat dan alles hertest moet worden.

[TheVivaldi]

Prehistorisch maar gewoon ge-support tot 2028 voor security patches...

Wel alleen voor betalenden.

[GeroldM]

Denk dat @latka doelde op de support voor glibc v2.28.

Er zijn een heleboel andere software-pakketten waarvan meerdere versies soms heel lang ondersteund blijven. 1 van de bekendere software pakketten is de PostgreSQL database software. Daarvan heb je standaard zo'n 4 tot 5 verschillende versies van in omloop.

PostgreSQL is het eerste voorbeeld waar ik aan dacht, maar er zijn zoveel meer voorbeelden beschikbaar.

[graey]

'Altijd' de laatste versie installeren niet. Gelukkig komen LTS-versies al wat minder vaak uit dan normale releases: elke twee jaar. Dan kan je er ruim eentje overslaan en zelfs wachten tot die tweede release na je vorige install (dus bijv. 22.04 na 18.04) ook een beetje stabiel is. Je kon dus prima met ondersteuning t/m 2023 op 18.04 blijven, en dan in 2024 op een stabiele 22.04 overstappen.
Als je echt professioneel met Ubuntu werkt, en je zit op een LTS-release vanwege stabiliteit en/of veiligheid, dan moet je juist ook een migratieplan hebben om over te stappen op nieuwe LTS-versies. Of accepteren dat dan niet meer alles zal werken op een gegeven moment.

[Anoniem: 718943]

Security patches alleen zijn ook niet zaligmakend. Bugfixes krijg je bijvoorbeeld niet. (tenzij ze een security issue zijn).

Ik snap niet waarom er tot het laatste moment gewacht moet worden met upgraden. Waarom kan het op 2028 opeens wel?
Wat voor stroperig proces heb je dat je aan het standaard LTS window niet genoeg hebt?

[Riddle007]

Dat lijkt misschien prehistorisch, maar is dus wel uitgekomen na de release van Ubuntu 18.04 waardoor het vrij logisch is dat deze niet in die Ubuntu versie zit.

Eigenlijk heeft glibc 2.27 waarschijnlijk zelfs maar net de cut gehaald gezien deze pas in februari 2018 gereleased was en beta testing voor Ubuntu 18.04 begin maart reeds begonnen was (en dit een LTS versie was).

Ik herinner me dat ze in 2021 een oude gnome versie mee leverden omdat de nieuwe versie net te nieuw was (en dit was geen LTS)...

[graey]

Yep. Maar dan is 18.04 ook alsnog prehistorisch, waardoor het weer niet heel relevant is. 20.04 en 22.04 zijn ook LTS, 18.04 is EOL tenzij je betaalt voor extended support (en dan krijg je dus geen garanties op software van derden zoals VSCode).
Dit is erg netjes van Microsoft, maar wel echt een extra service waar geen enkele professional op zou moeten denken te kunnen rekenen.

[Riddle007]

Akkoord. Het is een absurd idee om qua OS zo lang mogelijk op een bepaalde versie te blijven zitten, maar wel te verwachten dat bepaalde software die je erop draait wel de meest recente versie is.

[w3news]

Ik weet niet de exacte reden dat mensen blijven hebben bij 18.04, maar zelf hou ik niet eens met de LTS versies aan, omdat ik geen problemen ervaar met de half jaar release.
Ik heb liever regelmatig vernieuwingen dan af en toe een grote upgrade.
Maar mogelijk dat het hele bewuste redenen zijn om bij 18.04 te blijven hangen, omdat daarna bepaalde wijzigingen doorgevoerd zijn die ze niet willen.

[MueR]

Ik heb anno 2022 nog een project moeten doen waar ik met een Java 1.2 SDK (J2SE) moest werken. Om je het Google werk te besparen, dat is een SDK die in November 2003 end of life was. De reden? Het hardware platform waar ik moest werken ondersteunde niet beter. Soms heb je te dealen met sectoren (looking at you machinebouwers) die al ruim 25 jaar met dezelfde oude meuk werken onder het motto "het werkt toch?. Ja tot ik zelf JSON parsers moet gaan bakken in een SDK die niet eens string splitting heeft. Bij software heb je genoeg leveranciers die geen brood zien in het upgraden van hun code.

[Cambionn]

En dat is juist waarom zulke verplichtingen goed zijn. Het forceerd soms updates die eigenlijk moeten maar altijd maar aan de kant geschoven worden. Zelfde met de inmiddels 10 jaar oude TPM2.0. TPM1.2 is niet veilig meer maar kijk wat een heisa omdat niemand reden zag tot upgraden. Tot het verplicht werd. Sindsdien wordt het wél uitgefaseerd (nieuwe hardware ondersteund het omdat het anders niet compatible is waardoor er steeds meer TPM2.0 machines en minder TPM1.2 machines in omloop zullen komen). En als je kijkt hoe veel mensen daar boos om zijn (en dus in de groep "niet upgraden zolang ze er om heen kunnen" vallen) is dat 10 jaar na data wel erg jammer maar nodig.

En wij hebben op werk helaas ook nog wat XP bakken met vergelijkbare redenen als jij noemt. Ik ken het probleem hoor. Maar die hoeven ook niet de nieuwste VS Code en kunnen op de oude dus nog verder draaien. Maar hoe minder support, hoe makkelijk management verteld wordt dat we echt over moeten. Als dat ombouwen om het te laten werken kost namelijk tijd en dus geld. En nog efficienter, alles wat kapot gaat kan enkel vervangen worden met nieuw up-to-date spul want het oude wordt niet geleverd.

[w3news]

Als developer heb je ook verantwoordelijkheid.
Zo kregen programmeurs bij VW de schuld voor emissie manipulatie.
Hebben ze het zelf bedacht? Denk dat dit ook vanuit hogere hand opgelegd is.
Voor mij zou het een harde nee zijn, met uitleg.
Oude software waar geen ondersteuning voor is is een no go.

[GeroldM]

In verie 18.04 LTS was het hele Snap gedoe nog niet al te prevalent aanwezig en werd het nog niet zo uitbundig gepushed door Ubuntu. Maar in 20.04 LTS was dat al behoorlijk veranderd en met versie 22.04 LTS moet je moeite doen om niet met Snap te worden opgezadeld.

Zelf zit ik al te denken om in 2025, als support voor 20.04 LTS is afgelopen, over te stappen op Debian, want geen Snap.

[Martinspire]

Wat is eigenlijk de reden dat MS over wil naar de nieuwe versie?

[Mike2k]

https://www.baeldung.com/linux/gnu-c-library

Daar kun je lezen want de library allemaal doet. Het is eige lijk de interface naar het OS. volgens mij een enigszins vergelijkbaar met wat .net doet voor Windows?

De reden dat de pakket versie eis verhoogd is, heeft waarschijnlijk te maken met nieuwe functies waar vs.code gebruik van wil maken die (pas) in versie 2.28 zitten.

ik zeg pas omdat de betreffende versie, zoals @Rarz al zegt, inmiddels 6 jaar oud is

[The Zep Man]

https://www.baeldung.com/linux/gnu-c-library

Daar kun je lezen want de library allemaal doet. Het is eige lijk de interface naar het OS. volgens mij een enigszins vergelijkbaar met wat .net doet voor Windows?

Win32 (geïmplementeerd in een paar kern-DLL's) is vergelijkbaar in Windows, samen met zaken als Visual C++ Redistributable om het werkbaarder te maken.

.NET kan je qua niveau vergelijken met iets als Java, en is wel meegeleverd maar eigenlijk optioneel in Windows.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 19:03]

[The Zep Man]

Bron:

As 18.04 reaches the End of Standard Support in May of 2023, companies that have deployed devices with this LTS need to take action. Staying on 18.04 EOL distribution is a security risk that companies can’t afford.

[CH4OS]

De vraag is waarom de glibc library requirement opgehoogd is naar versie 2.28. Dat heeft mag ik hopen niet te maken met het feit dat Ubuntu 18.04 LTS end of life is.

[Llopigat]

Dat komt doordat Electron die niet meer ondersteunt.

[CH4OS]

Dank, die was ik inderdaad vergeten toe te voegen aan mijn reactie.

CC: @Martinspire

[svenk91]

2.28 is ook alweer 5,5 jaar oud. Het zou best kunnen dat men juist nog op een oudere glibc bleef omdat Ubuntu 18.04 dat nog vereiste en het laatste OS was dat nog breed werd gebruikt en zo'n oude glibc versie gebruikte.

Zelf zie ik niet in dat als je op zo'n oude EoL distro zit dat je dan geen oude VS Code versie kan gebruiken. Je hangt er toch hopelijk niet mee aan het internet

[CH4OS]

Nee, door gebruik van een nieuwe versie van Electron werd versie 2.28 van glibc benodigd.

[Martinspire]

Daarmee is nog steeds niet duidelijk wat er nou zo belangrijk aan is. Sure, security issues en alles, maar dat is met zoveel tools het geval en zegt nog niet waarom deze versie verplicht wordt. Verder snap ik ook niet waarom ie niet met oudere versies kan blijven werken, het gebruiken van polyfills is voor dit soort tools vrij gebruikelijk.

[halfgaar]

Even speculeren:

De vereiste glibc versie is waarschijnlijk niet letterlijk gekozen, maar gewoon een keuze van 'op welke oudste distro bouwen we onze builds?'. Linken tegen glibc is forward compatible, niet backwards compatible. Dat betekent dat je met de oudste glibc die je wilt ondersteunen moet linken.

Als je linkt tegen libraries is het de verantwoordelijkheid van de librarymaker om die te voorzien van 'symbol versioning' als je wilt dat programma's die gelinkt zijn tegen een oude versie, met nieuwe versies van de lib kunnen draaien. De meeste libraries doen dat niet goed (in Linux wereld is het een hel). Glibc doet dat redelijk. Daarom is er iets als AppImage, wat de meeste libs inbouwt in een virtuel bestandssysteem. Maar, de AppImage wrapper zelf heeft nog wel de glibc van je systeem nodig.

Het is in de praktijk de gewoonte dat als je een binary maakt met iets als AppImage, dat je hem compileert op het oudste systeem dat je wilt ondersteunen. Als je namelijk een AppImage compileert op Ubuntu 20.04, dan draait hij niet meer op Ubuntu 18.04 omdat de 'version tags' die hij zoekt nog niet bestonden in die versie van glibc.

En bouwen op Ubuntu 18.04 geeft waarschijnlijk meer gedoe voor Microsoft, en dus hadden ze denk ik besloten te upgraden omdat 18.04 toch EOL is, en impliciet de glibc versie daarmee te verhogen.

[kdekker]

Klopt. Je bouwt meestal op het laagste nog gesupporte platform en daar bedien je de hogere versies mee, mits compatibel. Wat gelukkig bijna altijd het geval is.

[Loller1]

Mooi dat Microsoft dit doet, maar ook totaal onnodig. Het was al een half jaar geleden gecommuniceerd, en op een TLS versie van je OS zitten waar al 2 latere LTS's van zijn uitgekomen, die ook nog eens niet helemaal ondersteund meer wordt vanuit de fabrikant maar wel verwachten de laatste software te kunnen draaien is gewoon de gebruikers hun eigen schuld.

[vbmot]

Of gewoon overstappen op een andere text editor als je zo nodig een oude versie van Ubuntu wil draaien? Er zullen ongetwijfeld genoeg editors zijn die het nog doen.

[R4gnax]

Hoewel de scope ook VSCode desktop versie 1.86 betreft, ging het initieel niet eens daarom. Het stuk software dat voor iedereen stopte met werken en waartegen men ageerde was VSCode Server. Een spawn van VSCode op basis van prebuilt binaries, voor wanneer je remote development op een ander systeem wilt doen.

VSCode Server 1.86 heeft net als de desktop versie glibc 2.28 of hoger nodig.
https://code.visualstudio...older-linux-distributions

Hierdoor krijg je de situatie dat je naar 1.86 kunt updaten binnen je courante en up-to-date OS op je developer systeem, maar daarna niet naar je server kunt verbinden omdat de spawn voor 1.86 geen compatible pre-built binaries heeft.

Dat komt doordat servers vaak extended-support edities van diverse Linux distributies draaien. En in dit specifieke geval is het met name het support window voor de extended-support voor Red Hat Enterprise Linux dat roet in het eten blijkt te gooien en nog vasthangt aan een veel oudere glibc versie.
(Dat en de kleine kliek ontwikkelaars die het probleem initieel veel aandacht bezorgde, bleken uiteindelijk allemaal stuk voor stuk medewerkers van Amazon te zijn. Dus de vraag is ook nog eens hoe groot het probleem nou daadwerkelijk was. En in hoeverre het neerkomt op Amazon die hun troep niet update en/of direct op missie-kritieke productieomgevingen die niet down kunnen voor updates hun code zitten te hacken.)

Het feit dat Tweakers hier wederom (tweede keer) met een fikse clickbait titel aan komt zetten na hier met hun eerdere artikel in de reacties al op gewezen te zijn, is op z'n zachtst gezegd treurig te te noemen. En scherper gesteld: het is ronduit nalatig en onprofessioneel om VSCode op die manier eigenlijk te betuttelen alsof er iets fout gedaan zou zijn.

[Reactie gewijzigd door R4gnax op 23 juli 2024 19:03]

[IrBaboon79]

Vrij coulant - terwijl het hier feitelijk om developmentdoosjes gaat, dwz: desktops/workstations die je in een (paar) uur geupgrade hebt; vooral ubuntu is daar erg makkelijk mee immers.

Development tooling draai je uit principe niet op servers en servers zijn normaal dus ook de doelgroep waar je CentOS/Ubuntu Server LTS e.d. inzet;

Development desktops: niet zeuren maar gewoon upgraden naar iets recents - over 2-3 maanden Ubuntu Server LTS 24.04, kan je al mooi inplannen. shiny new scheduler en 6.8 kernel, etc...

[ultimasnake]

Kan iemand met deze versie van Ubuntu uitleggen waarom er zo wordt vastgehouden aan deze versie? Ik doe even een aanname maar het zal geen server betreffen waarop je een development environment draait, maar een desktop omgeving, en waarom dan dus niet updaten naar een recentere TLS?

(echt een vraag, ik heb te weinig verstand van Linux om te snappen waarom er wordt vastgehouden op een versie die al zo 'oud' is, of in ieder geval 'veel opvolgende versies kent')

[Delgul]

Ik verbaas me dat ik niemand hoor over VS Codium. Dat draai ik al geruime tijd en is VS Code maar dan een Open Source variant. Volgens mij aardig compatible, in ieder geval prima voor het werk dat ik doe. En ik gok zo maar eens dat dat wel beschikbaar blijft voor 18.04 vanwege het Open Source karakter, maar ik _kan_ me vergissen...

[kozue]

Ook open source projecten hebben minimale systeemeisen…

[TheVivaldi]

Precies. Ik kan zo al een aantal softwares opnoemen die niet meer te compileren is op zoiets als Ubuntu 18.04, vanwege bepaalde systeemeisen. En dat is allemaal opensourcesoftware.

[kozue]

Ik gebruik voornamelijk open source en ik kom het ook vaak genoeg andersom tegen: software die te oud is om makkelijk op nieuwe OS versies te installeren. Dan moet je eerst handmatig allemaal dependencies gaan compileren. Voor mij als developer wel te doen, maar voor een leek? Zoals software die nog gebruik maakt van python 2, terwijl moderne distro’s dat niet meer meeleveren. Probeer maar eens om python 2 van de grond te krijgen zonder voorgebakken distro pakketten.

Bij 1 tooltje was het dusdanig erg dat ik uiteindelijk maar de flatpak geïnstalleerd heb, waar de complete python 2 omgeving meegeleverd werd, en normaal gebruik ik nooit flatpaks en snaps want dat vind ik maar een bende. Dat ene tooltje van misschien hooguit 10MB heeft meer dan 1GB aan meuk geïnstalleerd. Python, gtk, X11 zut, de hele rataplan. Alleen maar omdat ze hun stack niet uptodate hebben gehouden.

Naar mijn ervaring maakt het dus niet veel uit of je open source of closed source pakt, voor wat betreft OS support. Het enige voordeel van open source is nog dat je de code zelf bij zou kunnen werken om het aan de praat te krijgen, maar leken gaan dat toch niet kunnen, en zelfs voor een developer kost het wellicht ook meer tijd dan dat het waard is.

[Loller1]

Eerst en vooral is het hele argument achter VS Codium natuurlijk gewoon onzin. Het enige verschil wat ze claimen is het verwijderen van de Microsoft branding en het uitschakelen van telemetry, iets wat gewoon een instelling is in VS Code, dus waarom zou je iemands binary gaan gebruiken waar je geen reden hebt om te vertrouwen dat het veilig is over die van Microsoft welke constant in de gaten wordt gehouden? Dat is pure, onnodige paranoia. En als je toch zelf compileert kan je net zo goed gewoon de normale VS Code repo gebruiken. En natuurlijk schiet je ondertussen jezelf in de voet met geen toegang te hebben tot de normale extensie winkel op de normale manier. Het is letterlijk moeilijk doen om moeilijk te doen.

Ten tweede, VS Codium is - zoals ik net al aanhaal - enkel en alleen VS Code zonder Microsoft branding. Ze gaan echt niet de moeite nemen om rond alle opeenstapelende wijzigingen te werken die latere versies van dependencies gaan vereisen. Deze gewijzigde systeemeisen gaan gewoon volgen.

[Delgul]

Wel, niets wat Microsoft voor Linux maakt heeft hij mij ooit lekker gedraaid. In ieder geval niet de hele O365 suite. Dus ik kies vrijwel altijd vrijwel automatisch voor een open variant als die er is. Extensies doen het prima. Weet niet of het handig is of niet, ik heb er in ieder geval nooit last van gehad…

[thegve]

Ik ben toevallig vandaag bezig geweest met het laten draaien van O365 onder Linux... Maar euh, dat is voor Windows he, en word in ieder geval niet door MS ondersteund.
Het grootste punt dat Loller1 maakt, is dat VS code letterlijk al open is ( https://github.com/microsoft/vscode ) en dat je extra risico neemt door een binary van een random guy op het internet te gebruiken, versus de originele open bron.

[Delgul]

Ze hebben ooit een O365 versie gehad volgens mij. Nooit lekker gedraaid... Niet voor mij. En voor MacOS is het ook kreupel...

[Anoniem: 454358]

2.28 is Net zon verplichting als tpm2 bij win 11? Maar zonder ook gewoon werkt?

[Cambionn]

Je bedoelt een dependencie upgraden van een oude onveilig (TPM1.2 is niet veilig bij moderne standaarden), bugvolle (niet specifiek dit voorbeeld maar vaak wel een side-effect van verouderde packages) danwel unsupported (de genoemde release is al EOL, zei het met optie tot koop van patches maar daarvoor kun je geen third party support verwachten) iets naar de nieuwere versie die ook al jaren bestaat (TPM2.0 is al bijna 10 jaar oud!, en ook 2.28 is niet bepaald net uit en ook voor dit OS zijn er al geruime tijd nieuwe LTS versies die het wel ondersteunen) maar waar men uit gemakzucht het nooit heeft implementeerd want dat kost moeite en "het oude werkt toch?" (Als in technisch gezien draait het, ongeacht beveiligingslekker, blokades voor modernisering en bugs).

Dan ja, net zo iets ja. Goed dat ze een push geven op zulke dingen. Ben geen Microsoft fan maar kan dit wel erg waarderen. Er is een aardig belang bij systemen up to date houden ipv verouderde dingen blijven draaien. En de paar systemen waarbij er echt baat is bij zo'n oud OS zullen ook niet de nieuwste VS Code nodig zijn.

Microsoft is lief dat ze toch nog een jaartje support leveren. Maar de push om updates van erg verouderde componenten (zei het hardware of software) te upgraden is vere van slecht. En het is niet alsof het om net nieuwe dingen gaat die ze opeens verplichten. Wat ze nu doordrukken bestaat al tijden en er was genoeg tijd om het te implementeren en dingen te upgraden.