Canonical verlengt betaalde ondersteuning voor Ubuntu van 12 naar 15 jaar

Canonical gaat de betaalde ondersteuning voor lts‑releases van Ubuntu Pro verder verlengen. Die zijn nu maximaal twaalf jaar, maar Ubuntu maakt daar vijftien jaar van. Het gaat specifiek om de Legacy-add-on voor Ubuntu Pro. Dat geldt vanaf Ubuntu 14.04 LTS.

Ubuntu-moederbedrijf Canonical zegt dat het de ondersteuningsduur van de Legacy-add-on voor Ubuntu Pro met drie jaar verlengt. Daarmee wordt het mogelijk in totaal vijftien jaar ondersteuning te ontvangen voor long-term support releases (lts-releases) van Ubuntu.

Lts-releases van Ubuntu krijgen standaard vijf jaar beveiligingsondersteuning. Daarnaast is het mogelijk vijf jaar extra ondersteuning te krijgen in het Expanded Security Maintenance-programma, maar voor zakelijke gebruikers met Ubuntu Pro is het ook mogelijk nog eens de Legacy-add-on te gebruiken. Dat is mogelijk sinds vorig jaar, toen Canonical dat programma introduceerde. Legacy maakt het mogelijk om tegen betaling nog eens twee jaar extra ondersteuning te krijgen, waarmee de totale ondersteuning op twaalf jaar uitkwam.

Die laatste Legacy-ondersteuning geldt nu langer. Canonical verlengt die ondersteuning van twee naar vijf jaar. Daarmee is de totale ondersteuning maximaal vijftien jaar voor Ubuntu Pro. De ondersteuning geldt, net als toen Canonical Legacy introduceerde, met terugwerkende kracht vanaf Ubuntu 14.04 LTS.

Canonical verwijst naar 'de positieve ontvangst en groeiende interesse in langere levenscyclusondersteuning'. Het bedrijf zegt dat het steeds moeilijker wordt voor bedrijven om hun beveiliging op de lange termijn op orde te houden met upgrades en dat het vaak makkelijker is bestaande beveiligingsondersteuning simpelweg uit te breiden.

Reacties (16)

[Blokker_1999]

Er zijn dus enkele bedrijven die blijkbaar veel geld willen neertellen om een oude release in leven te houden in plaats van te investeren in upgrades. Maar het lijkt me dat je op een gegeven moment met zulks een oude codebase zit dat het steeds moeilijker wordt om na te gaan of bugs die we vandaag vinden in nieuwere versies van een pakket, of die ook van toepassing zijn op zulks een oude versies alsook de vraag hoe eenvoudig het dan is om een patch te backporten.

En wat met bugs die net in zo een oude versie zitten maar niet in nieuwere versies, die gaan niet veel aandacht krijgen en kunnen langer onder de radar blijven.

Ik begrijp Canonical volledig dat ze dit doen. Er is vraag naar en het zal winstgevend genoeg zijn voor hen, maar vind het vooral spijtig dat bedrijven hiermee weer maar eens niet leren van bij te blijven met software up to date te houden en een mooie cadans aan te houden van OS upgrades. Met een LTS release elke paar jaar moet je gewoon aanleren om een cadans van upgrades aan te houden. Dat betaald zichzelf op termijn ook terug in de meeste gevallen.

[lenwar]

in plaats van te investeren in upgrades

Dit heeft met heel veel factoren te maken. Ik zie dit soort discussies regelmatig voorbij komen, maar uiteindelijk zijn het kosten-baten redeneringen.

Stel je hebt een applicatie in een niche-markt. Er bestaat niet zo veel software die dit kan. Laten we zeggen voor een verzekeraar die bepaalde type verzekeringen/spaarconstructies aanbiedt. Die spaar-constructies hebben een levensduur van 80 jaar (ja ze bestaan) of langer. Belastingconstructies er omheen enzovoorts. Op een bepaald moment veranderd wetgeving, en kunnen die constructies niet langer worden afgesloten/verkocht, maar de bestaande verzekeringen moeten nog wel onderhouden worden.

De maker van die software heeft de software ontwikkeld voor besturingssysteem XYZ. Nu is het 8 jaar verder, en de software wordt niet meer doorontwikkeld (alleen bugfixes/securityfixes) door de leverancier. De verzekeraar wil eigenlijk van die oude software af, maar de functies die nodig zijn bestaan niet in modernere software (die voor andere zaken gebruikt wordt binnen het bedrijf). De verzekeraar zit dus vast aan de oude software en dus het oude besturingssysteem. Op een gegeven moment 'moet' het bedrijf wel over, want het oude besturingssysteem draait niet op modernere hardware (ook niet virtueel). Maar zover is het nog niet. En er zijn tenslotte ook bedrijven die 'oude componenten' kunnen aanbieden voor noodgevallen.

Nieuw aangekochte software ondersteund die oude functie niet (want het wordt niet meer verkocht), maar tegen betaling kan die softwaremaker het er wel in zetten. Het er in laten zetten kost 7.000.000 euro (inclusief onderhoud voor 6 jaar), plus de manuren binnen de verzekraar om het over te zetten binnen het bedrijf. Het onderhouden van het oude besturingssysteem kost 30.000 extra per jaar aan licenties, plus wat manuren manuren. Onderhoud aan het systeem is minimaal (na zoveel jaar draait het gewoon stabiel, en er komen toch geen nieuwe dingen in, want de diensten mogen niet verkocht worden.)

Het bedrijf moet nu een keuze maken. Financieel is de keuze makkelijk. Dat kunnen ze prima uitstellen. Want de manuren om de diensten over te zetten zijn ook niet gering, en de aandeelhouders kijken alleen maar naar kwartaalcijfers. Die 7 miljoen komt wel op een later moment.
Echter. Het oude besturingssysteem ondersteund niet meer de laatste cryptografische normen, enz, enz, enz. Maar de ondersteunde normen zijn nog wel 'acceptabel', en de ECB laat het nog wel toe. Ook staat het systeem volledig afgeschermd van de buitenwereld, dus het echte risico op beveiligingsproblemen is ook relatief klein. Er moet dus continu een middenweg gevonden worden.

Ook kan het laten inbouwen door de softwareleverancier langer duren dan verwacht, waardoor je ook weer langer die OS-ondersteuning nodig hebt.

Vanuit mijn systeembeheerdershart vind ik bovenstaande uiteraard gewoon ruk. Zorg ervoor dat je altijd redelijk meekomt met de laatste versies van zaken. Maar vanuit een zakelijk oogpunt, moeten er keuzes gemaakt worden.

Bovenstaande is één niche-voorbeeld, maar zo zijn er een heleboel. Het is niet altijd 'zomaar geregeld' om de boel te upgraden naar nieuwere versies van software en besturingssystemen. Zeker als (internationale) wetgeving ook nog is hele zware eisen stelt. Dat maakt het complex.

N.B. Ik heb zelf ook, net zoals jij al aangeeft, sterk twijfels bij de kwaliteit van de LTS-versies. Het vinden, en corrigeren van (beveiligings)fouten in hele oude software is heel ingewikkeld, en wordt hoe ouder het is, steeds moeilijker..

[HADES2001]

Toevallig ervaring met een bedrijf die onderzoek uitvoert, zei hebben machines gekocht door de decennia heen die per stuk miljoenen kosten (een aantal zelfs in de tientallen. Allemaal zijn ze uniek, custom hardware custom software. De makers van deze hardware geven geen support voor nieuwe OS versies omdat het teveel kost voor solo devices. Zei zijn dolblij met bedrijven als Ubuntu want zonder dit soort support constructies heb je een gigantisch probleem, ja het kost geld maar je wil ook niet je 5+ miljoen investering na een paar jaar bij het schroot zetten.

Soms heb je gewoon geen keuze, draai je nog steeds je DNS en DHCP server op ubuntu 14 ja dan ben je gewoon dom bezig maar ik snap in sommige situaties support contracten een gigantische uitkomst zijn

[Reactie gewijzigd door HADES2001 op 14 november 2025 11:02]

[CH4OS]

Als je een kritisch programma hebt, wat bovendien ook nog custom made is, maar waarvan de ontwikkelaar met de horizon vertrokken is (bedrijf bijvoorbeeld failliet), maar je als bedrijf wel dusdanig leunt op het programma en het niet werkt op een nieuwere versie van Ubuntu, kan ik mij voorstellen dat deze dienst interessant is.

Op deze manier en ik weet het, toch ook een beetje uitzonderingen zoeken, kan een dergelijke klant zijn oude programma in de lucht houden, omdat het OS tenminste nog wel ondersteund wordt. Dat kan dan goedkoper zijn dan een volledig nieuwe applicatie te (laten) ontwikkelen. Op die manier wordt een grote downtime (het stilvallen van het bedrijf) voorkomen.

[Reactie gewijzigd door CH4OS op 14 november 2025 09:42]

[xFeverr]

Het blijft wel steeds uitstel van executie dus er zou al een traject moeten lopen om het te kunnen vervangen. Dit zou een mooie oplossing zijn voor als dat nog niet helemaal klaar is, maar als je tegen die tijd nog geen beginnetje hebt gemaakt ga je toch echt een keer voor de bijl. Nu alleen 3 jaar later.

[CH4OS]

Dat is wellicht de ideale situatie, maar daar werken veel bedrijven niet op, die werken wellicht met die context in gedachten, maar bovenal met de nuance om geld te verdienen en winst te maken.

[xFeverr]

Bestaanszekerheid is toch ook belangrijk genoeg om op te sturen zou je zeggen. Anders stopt dat geld verdienen en winst maken op een dag. Er zijn weinig bedrijven beter geworden van niet meer investeren in zichzelf

[arnova]

Zo simpel is het gewoon niet. Weet je hoeveel werk het is om iets dergelijks voor bv. 1000 PC's elke keer te doen? En bovendien, doen we met Windows niet precies hetzelfde? Hoe oud is Windows 10 ook alweer? Juist!

[beerse]

Misschien moeten we ook zien wat ubuntu 14.4 lts zo bijzonder maakt. Wat houdt de gebruikers tegen om over te stappen.

• Is het de laatste lts ubuntu versie die nog met 32bits software en/of op 32 bits hardware werkt?
• Is het de laatste lts ubuntu versie met een bepaalde kernel versie?
• Zijn er libraries of andere omgevingen aangepast sinds ubuntu 14.4 lts?

Of is het gewoon en vooral omdat het kan, dat ubuntu haar routines voor elkaar heeft dat ze de patches betrekkelijk soepel kan backpoorten?

Mijn gedachten gaan ook uit naar alle distributies die zijn overgestapt naar roling-releases. Iets wat ubuntu tot op zekere hoogte ook doet met haar niet-lts distributie. Met zo'n roling-release voorkom je al direct dat gebruikers in een versie blijven hangen.

[[NUT]]

Soms word er sofware gebruikt die bedrijfskritish is, waarvan de ontwikkelaar nog wel bestaat maar simpel voet bij stuk houd over de ondersteuning. In het kader van "dit is wat we weten dat werkt en dit ondersteunen we tot het einde der tijden. Upgraden van het OS? Dat kan, maar dat word niet ondersteund en daarmee vervalt de levenslange ondersteuning."

Uiteraard word er een update aangeboden of een onderhoudscontract, voor grof geld. Soms gebeurt dat niet en dan heb je gewoon simpelweg geen keuze.

Het aantal AS400 systemen die nog in gebruik zijn bij verzekeraars en banken om alles maar te laten werken zoals het bedoeld is, is bedroevend hoog. Ik ken er al 4 en ik ben niet eens actief in die branche...

[tweaker29789]

Ik zie hier een aantal op Windows gebaseerde verhalen langskomen. Dit is niet vergelijkbaar als blijven hangen op bijv Windows XP zodat je je hardware of software kunt blijven gebruiken. Bijv. een HP printer die ineens niet meer werkt bij de volgende WIndows versie, is niet echt een ding in linux.

Bij een linux distro kun je alles vervangen in principe, ook de kernel die voor een groot deel je hardware ondersteuning bepaalt.

Dit klinkt als een kosten/baten plaatje. Linux is juist geschikt om bij te blijven terwijl je oude hardware/software blijft werken. Maar als de bedrijven in kwestie niet de kennis in huis hebben om dit zelf te doen voor hun specifieke situatie, zal die LTS ondersteuning wel goedkoper zijn.

[Reactie gewijzigd door tweaker29789 op 14 november 2025 12:04]

[ffha]

Ik denk dat je een beetje onderschat hoeveel libraries, usermode programmas etc. op Linux veranderen (/verdwijnen). Met een beetje pech, zit je ook vast aan eeuwenoude drivers die je niet zomaar overzet, en een moderne distro draait echt niet op kernel 2.6.39 of 3.19.

Betreft kennis; iets van dit kaliber vinden is moeilijk, en duur. Als je zulke mensen vindt, dan wil je die echt niet inzetten voor het onderhouden van een berg oude, dode meuk.

[tweaker29789]

Ik denk dat je een beetje onderschat hoeveel libraries, usermode programmas etc. op Linux veranderen (/verdwijnen). Met een beetje pech, zit je ook vast aan eeuwenoude drivers die je niet zomaar overzet, en een moderne distro draait echt niet op kernel 2.6.39 of 3.19.

Betreft kennis; iets van dit kaliber vinden is moeilijk, en duur. Als je zulke mensen vindt, dan wil je die echt niet inzetten voor het onderhouden van een berg oude, dode meuk.

Nee, dat onderschat ik niet. Het is gewoon niet zo dat al die library versies en hardware ondersteuning qua versie aan een distributie versie vastgenageld zitten zoals bij Windows. Je kunt in principe naar een nieuwe kernel versie gaan binnen je LTS versie. Of zelf compileren als je wilt.

Maar het kan ook gewoon zijn dat Canonical bepaalde voorwaarden heeft voor hun support. En dat bepaalde zaken zelf aanpassen in een LTS versie deze schendt. Vandaar mijn opmerking over kosten/baten.

Ik ben erg nieuwsgierig naar een praktisch voorbeeld mbt een Ubuntu LTS versie.

[Llopigat]

maar vind het vooral spijtig dat bedrijven hiermee weer maar eens niet leren van bij te blijven met software up to date te houden en een mooie cadans aan te houden van OS upgrades.

Je hebt niet altijd de keus. Soms zijn leveranciers niet in staat hun software bij te werken, of bestaat de leverancier gewoon niet meer. Of het kost miljoenen om een gemodificeerd pakket aan de nieuwe versie aan te passen.

Wij hebben ook hele oude systemen in het landschap maar je moet echt een verrekte goede reden hebben om dat te doen. Het gewoon niets geven om updates zie ik eigenlijk niet meer. Wannacry/NotPetya heeft de wereld wel wakker geschud wat dat betreft.

Edit: Oeps dit was een reactie op Blokker_1999 maar ik heb blijkbaar op de verkeerde reageer knop gedrukt.

[Reactie gewijzigd door Llopigat op 14 november 2025 09:24]

[Nozmordre]

Wat een vreselijk idee, ondersteuning zou juist sterk verkort moeten worden, dwing iedereen gewoon om te updaten.
LCM or die!

[groene henk]

Ubuntu is leuk voor op een oude desktop en dan is het mooi dat die versie nog langer support wordt. Echt wil je support voor specifieke software of hardware, dan kan het wel op hun universe lijst staan, maar dat wil niet zeggen dat ze er verstand van hebben.

Ze zorgen alleen maar voor een update van de source zonder je te kunnen helpen bij een echt probleem. Dus uitkijken met het gebruik van de universe libraries (niet de main). Het is dus een beetje schijn support. Maar ja, je betaalt er ook niet veel voor.