Ubuntu 22.04.4 LTS

Ubuntu logo (75 pix) Versie 22.04.4 van Linux-distributie Ubuntu is uitgekomen. Tweemaal per jaar verschijnt er een nieuwe versie en vormen het jaar en de maand van uitgave het versienummer. Deze versies worden negen maanden ondersteund. Eens in de twee jaar komt er een versie uit die niet negen maanden maar vijf jaar voorzien zal worden van updates. Versie 22.04, een versie die vijf jaar ondersteuning krijgt, heeft codenaam Jammy Jellyfish meegekregen, draait op Linux Kernel 5.17 en gebruikt standaard Gnome 42 als de desktopomgeving. Meer informatie over deze release is bij Omg! Ubuntu te vinden en op onze eigen voorpagina. Versie 22.04.4 is de vierde update met een verzameling bugfixes en verbeteringen.

Ubuntu 22.04.4 LTS is now available
These release notes for Ubuntu 22.04 LTS (Jammy Jellyfish) provide an overview of the release and document the known issues with Ubuntu and its flavours. For details of the changes applied since 20.04, please see the 22.04.4 change summary. The change summary for 22.04.1, 22.04.2 and 22.04.3 are available as well.
Support lifespan
Maintenance updates will be provided for 5 years until April 2027 for Ubuntu Desktop, Ubuntu Server, Ubuntu Cloud, and Ubuntu Core. All the remaining flavours will be supported for 3 years. Additional security support is available with ESM (Extended Security Maintenance).

Lees meer

Reacties (76)

Timsie 24 februari 2024 22:54

Ik zit al uit te kijken naar versie 24.04, draai nu 23.10, heb ook 22.04 gehad, maar na een crash bij het updaten heb ik daarna meteen maar de nieuwste geinstalleerd.

kozue @Timsie • 25 februari 2024 08:44

Ik kijk er ondertussen helemaal niet meer naar uit. Ik ben een beetje klaar met Ubuntu. Dat geduw met die snaps komt me m’n keel uit. Het wordt iedere release erger.

Ik vond het al ronduit schandalig dat ze Firefox naar snap hadden verhuisd, en dat ik allemaal moeite moest doen om m terug te krijgen naar deb, maar in 24.04 hebben ze hetzelfde met Thunderbird gedaan, en kan ik weer hetzelfde riedeltje langs. Waar houdt het op?

En die full disk encryptie vond ik ook maar niks. Ik had rond 22.04 een nieuwe werklaptop gekregen en had die dus vers geïnstalleerd, met de standaard instellingen. Toen heeft ie er een bende van gemaakt. Met een /boot van 500Mb, die met slechts een paar kernels al vrijwel vol zit. En omdat ze er zfs op zetten en automatisch snapshots maken kreeg ik een paar maande geleden ineens problemen met updates installeren omdat die snapshots niet meer wilden lukken (minder dan 20% vrij).

Hun zfs setup is sowieso een bende. Vanwege die snapshots hebben ze allemaal losse mounts gemaakt en raak je compleet het overzicht kwijt over hoeveel diskruimte je nou eigenlijk hebt. En het geheugen lijkt altijd vol te zitten vanwege de userspace disk cache die als programmageheugen telt, dus je weet ook nooit hoe vol je geheugen eigenlijk zit. Ben ik nog veel mee aan het klooien geweest om dat binnen de perken te houden.

In 24.04 hebben ze een nieuwe optie voor TPM gebaseerde disk encryptie. Maar dat is weer allemaal snap gebaseerd. Kom ik weer terug op het punt aan het begin van m’n post, het geduw met snaps. Dus daar ga ik ook niet aan beginnen.

En nou moest ik vorige week m’n laptop opnieuw installeren, en stond ik voor de keuze: weer Ubuntu met z’n groeiend aantal onhebbelijke eigenschappen, of eens iets anders proberen. Dus ik heb er dit keer maar Pop!_OS opgezet. Ik kan er na die paar dagen nog weinig over zeggen, want je weet nooit waar je nog allemaal tegenaan gaat lopen, maar tot nu toe bevalt het prima. Geen gezeur met snaps (Firefox gewoon uit deb), disk encryptie ziet er normaal uit (ext4 in luks container), en vertrouwd Gnome gebaseerd (ipv een Windows-achtige desktop zoals op Mint).

Miki @kozue • 25 februari 2024 11:09

Het zal voor de doorgewinterde individuele Linux gebruiker een gruwel zijn maar de richting die Canonical opgaat is duidelijk. Dat is de zakelijk kant, dit zie je ook terug in de nieuwe installer die af-fabrieks installaties mogelijk maakt. Snap icm TPM is de end-game.

De keuze om snap te pushen vanuit perspectief van Canonical is dus verre van vreemd.

Grimm @Miki • 25 februari 2024 15:26

De keuze om snap te pushen vanuit perspectief van Canonical is dus verre van vreemd.

Vreemd is het niet nee. Maar voor veel individuele gebruikers is het ongewenst dus die gaan b.v. naar Linux Mint. Dan heb je de voordelen van Ubuntu maar zonder de nadelen.

kozue @Miki • 25 februari 2024 22:44

Dat is wel een vreemde keuze. Hoeveel bedrijven zouden nog voor Ubuntu kiezen als ze hun gebruikers weg jagen? Het zijn volgens mij juist vaak de techs die zelf een voorkeur hebben voor een bepaalde distro die dat soort keuzes maken. Management weet niks van distro’s. Ik ga in ieder geval geen Ubuntu meer gebruiken, met hun geduw naar snaps. Die snap dingen wil ik op m’n servers ook niet hebben. Zal wel Debian worden volgende keer als er weer een server bij moet.

moredruid @Miki • 26 februari 2024 17:02

De zakelijke kant, misschien. Enterprise daarentegen... Hun (onnodige) vervanging van de preseed voor geautomatiseerde installaties in een gemengde Linux OS omgeving is een drama. PXE-boot is helemaal omgebouwd, ipv een 40M kerneltje via PXE moet je nu een 1.7GB ISO downloaden. Om nog maar te zwijgen over snap en alles wat daarbij hoort, ufw een drama omdat alles van iptables nog gewoon werkt maar toch ook weer net niet, en netplan met een hoop extra complexiteit t.o.v. resolv.conf.

Het is dat Ubuntu op universiteiten zoveel gebruikt wordt waardoor het in het bedrijfsleven ook gevraagd wordt (een beetje zoals je vroeger Windows + Office op school kreeg dus je wist niet beter tenzij je er naar op zoek ging). En als je tegenwoordig naar een how-to of tutorial zoekt krijg je in 95% van de gevallen een Ubuntu gericht resultaat. Dat werkte voorheen nog wel redelijk, maar ze hebben nu zoveel gewijzigd dat al de oude informatie meer stuk maakt dan dat het je verder helpt als linux niet je dagelijkse pakkie-an is zodat je dat soort valkuilen kunt omzeilen.

Nee, ik ben echt geen fan van Ubuntu meer, ik ben sinds versie 12 afgehaakt voor mijn werkdesktop (debian mocht niet, we hadden keus uit rhel, suse of ubuntu).

ArmEagle

@kozue • 25 februari 2024 21:38

Die snaps kunnen mij ook gestolen worden. Faalt Snap vervolgens zelf te updaten.

Firefox download ik gewoon naar mijn user omgeving en draai vanaf daar. Dan laat ik het updaten mooi aan Firefox zelf over.

kozue @ArmEagle • 25 februari 2024 22:46

Mja maar daar hadden we dus een package manager voor he, om je software bij te houden. Niet iedere software heeft een eigen update mechanisme (de meeste niet), en persoonlijk vind ik al die software in m’n homedir ook onwenselijk.

ArmEagle

@kozue • 26 februari 2024 07:38

Snap ik.
Maar ik heb geen behoefte aan een update melding voor Chromium twee dagen achtereen. Dat doorbreekt mijn flow. Waar de app zichzelf ook zou kunnen updaten.

Browsers zijn tegenwoordig te belangrijk en krijgen regelmatig updates. Die heb ik ook het liefst zo snel mogelijk.

whiner @kozue • 25 februari 2024 21:56

Dit kan je tijdens de installatie van Ubuntu toch ook gewoon selecteren, ext4 inlaats van zfs ?

kozue @whiner • 25 februari 2024 22:41

Nee, de full disk encryptie is een vinkje die je aan kunt zetten, zonder verdere configuratie. Er was me bij de installatie niks gezegd over zfs. En dat soort zaken zijn wel belangrijk om te weten, zodat je een betere keuze kunt maken. Achteraf toevoegen gaat wat lastig

beerse @kozue • 26 februari 2024 09:13

Zo ver als dit verhaal ben ik met ubuntu nooit gekomen. Zelf ben ik met het begin van dat snappak en flatpak circus overgestapt op kali linux met de roling release. Voor de kali-beginner: het is niet alleen maar hakken en zagen met kali. Standaard komt ze al met de gebruikelijke desktop tools en alles werkt gewoon.

Natuurlijk kan je ook meteen debian gebruiken, zeker nu ze tegenwoordig iets relaxter zijn met de firmware en zo. Maar de techneuten en tweakers die zich met kali bezig houden maken het net iets werkbaarder.

Archcry @Timsie • 25 februari 2024 08:37

Ik draai liever gewoon een Linux distributie die hun LTS releases niet uitbrengt met EOL kernels. Kijk bijvoorbeeld naar de 22.04 LTS release in dit specifieke artikel. Afgelopen januari is de kernel geüpdatet van 6.2 (end of life) naar 6.5 (end of life). Dat terwijl 6.1 longterm is en 6.6 ook longterm is. Waardeloos als je het mij vraagt.

Het zou me overigens ook niet verbazen dat de kernel voor de 24.04 release ook op of snel na de datum van release al EOL is. Een project wat hun LTS releases uitbrengt met EOL kernels kan ik niet serieus nemen laat staan gebruiken als server distributie voor systemen die klantdata verwerken.

[Reactie gewijzigd door Archcry op 23 juli 2024 02:14]

YoMarK @Archcry • 25 februari 2024 09:54

En waarom precies zou je je daar druk over maken?
Canonical support het hele OS incl de kernel. Security/patches voor het hele systeem wordt door hen voorzien.
Oude LTS edities draaien vaak ook 'unsupported' versies van b.v. Apache of php, maar security issues worden dus opgelost door fixes te maken/backporten.

Archcry @YoMarK • 25 februari 2024 10:39

Omdat Ubuntu al meer dan eens aangetoond heeft dat ze niet zo goed zijn in het ondersteunen van hun eigen kernel. Als voorbeeld dit artikel uit 2022. Systemen die docker gebruiken kapot omdat Canonical een kernel patch verkeerd implementeert.

En ik weet dat waar gewerkt wordt fouten gemaakt worden. Maar deze fout had gewoon voorkomen kunnen worden als ze een LTS kernel gebruikten die door de Linux communitie gemaakt, getest en ondersteund wordt. Waarom zou je met een relatief klein groepje developers een kernel willen ondersteunen als de Linux developers dit voor je doen.

En laten we eerlijk zijn, het is toch ook niet bepaald handig om steeds een EOL kernel te kiezen wanneer er één versienummertje hoger of lager een LTS kernel beschikbaar is? Mijns inziens is het gewoon logisch om dan in notabene en LTS OS ook een LTS kernel van upstream te kiezen.

Als afsluiter wil ik wel nog even aangeven dat je vergelijking met Apache of PHP niet opgaat. Je zegt zelf dat het unsupported versies zijn die ze alleen voorzien van security patches. Dat is dus anders dan een kernel die ze wel actief updaten naar een nieuwe versie. Als je de kernel update zorg er dan in ieder geval voor dat je naar een longterm versie update. Daarnaast waren PHP en Apache nog wel supported toen de LTS uitkwam. Voor de kernel is zelfs dat niet vanzelfsprekend bij een Ubuntu LTS release.

[Reactie gewijzigd door Archcry op 23 juli 2024 02:14]

YoMarK @Archcry • 25 februari 2024 11:38

Ik draai en beheer al 10 jaar+ Ubuntu LTS op servers, die automatisch updaten(unattended) en heb nog nooit echt rare dingen meegemaakt(behalve dan dat bepaalde default zaken zoals te kleine /boot partities die na wat release updates echt te klein waren). Ik draaide ook CentOS, en ook daar weinig rare dingen.

[Reactie gewijzigd door YoMarK op 23 juli 2024 02:14]

Archcry @YoMarK • 25 februari 2024 11:52

Tja, er zal altijd wel een "works on my machine" argument te maken zijn voor een Linux distributie. Dat is ook waarom ik in mijn reactie beargumenteer waarom het een slecht idee is om een EOL kernel te kiezen. Zou je daar eens op in kunnen gaan in jouw reactie?

YoMarK @Archcry • 25 februari 2024 12:52

Mijn argument is dus dat de gemiddelde(daar val je niet onder) eindgebruiker daar helemaal geen last van heeft, zoals ik hierboven ook al heb beschreven. Ik gebruik gewoon de default repository's en alle packages die daarin vertoeven zijn gecompileerd door Canonical en zijn op details aangepast en die packages worden per definitie niet ondersteund door de originele bouwers maar door canonical. Of het nu een php, apache, mariadb of een kernel .deb is die apt installeert, het boeit me niet welke versie zolang het maar securitytechnisch en functioneel in orde is. Als jij graag een andere kernel van source wil compileren, of een je een andere distributie wil gebruiken dan kan dat, keuze genoeg.
Edit: 'it works on my computer' argument is trouwens nogal flauw, het is een van de meest gebruikte 'gratis' LTS server edities, en dat komt ook doordat het gewoon(relatief probleemloos) werkt op een shitload aan computers want anders zouden ze een alternatief zoeken.

[Reactie gewijzigd door YoMarK op 23 juli 2024 02:14]

Archcry @YoMarK • 25 februari 2024 13:48

Het "works on my machine" argument was niet zozeer flauw bedoeld. Dat jij in die 10 jaar geen last van problemen gehad hebt betekent niet dat dit een goed argument is om te verantwoorden dat het okay is om EOL of unsupported software te shippen.

Ik snap ook wel dat software een keer EOL wordt en dat developers van software hun software niet tot in de oneindigheid kunnen blijven ondersteunen. Als Canonical voor hun eindgebruikers moeite doet die software te blijven ondersteunen dan kan ik ze daar alleen maar in aanmoedigen.

Het wordt een ander verhaal als je willens en wetens end of life software releast bij introductie van je LTS en/of tijdens een grote update van je OS. Wat dus met de kernel vaak gebeurt bij Ubuntu en wat dus blijkbaar voor dermate veel problemen zorgt dat er nieuwsartikelen over geschreven worden.

Ik kan me ook herinneren dat Ik Ubuntu 17.10 op sommige laptops de UEFI bricktte. Ze hebben toen zelfs de release offline gehaald. Reden hier was dat Canonical had besloten UEFI tools die "experimental" waren te shippen. Is misschien ook niet op jouw systemen gebeurd maar de mensen die er wel last van hadden zaten wel met de gebakken peren door een "foutje, moet kunnen" van Canonical die mijns inziens ook gewoon voorkomen had kunnen worden.

Het gaat mij er ook niet om dat ik zelf een kernel wil compileren en dat ik niet gelukkig zou zijn met de software die voor mij samengesteld wordt door Canonical. Het gaat mij om het rare keuzeproces bij het samenstellen van deze software wanneer er duidelijk betere alternatieven zijn.

In eerste instantie was je vraag waarom ik mij er druk om zou maken dat Ubuntu met EOL kernels shipped. Als ik er niet op kan vertrouwen dat een partij als Canonical een goed pakket software kan samenstellen dan gebruik ik het liever niet. Dat is waarom ik mij er druk om maak en persoonlijk ben ik van mening dat anderen dit ook zouden moeten doen in plaats van het goedpraten van dit gedrag met argumenten als "Ja, maar ik heb er nooit problemen mee gehad".

[Reactie gewijzigd door Archcry op 23 juli 2024 02:14]

joker1977 @Archcry • 26 februari 2024 13:22

Je gaat er a priori vanuit dat jouw redenering de correcte is en een (succesvol) miljoenen-bedrijf wat al sinds jaar en dag de meest succesvolle Linux-distro maakt het bij het foute eind heeft ?

Misschien, heel misschien heb jij niet alle informatie voorhanden op welke basis zij tot hun besluiten komen ?

Als ze zelf over de kennis beschikken om de gekozen kernel zelf te supporten dan is dat toch geen probleem ? Sterker nog, werd niet het overgrote deel van maintenance op de LTS-kernels uitgevoerd door personeel van Ubuntu/Canonical ?

En tuurlijk, er gaat weleens wat fout, zoals de voorbeelden die je geeft, maar gemiddeld genomen heeft Ubuntu een verdomd goed track-record, vandaar ook dat ze al sinds jaar en dag by-far het grootste markt-aandeel hebben van Linux-distro's.

Dat het niet voor jou geweldig is kan, maar je argumentatie lijkt vooral te rusten op eigen voorkeur en niet op grove fouten van Ubuntu-zijde.

moredruid @joker1977 • 26 februari 2024 17:10

Zolang je niets bijzonders wil met Ubuntu kun je er prima mee vooruit (lees: LAMP stack of developerwerk). Hier een paar honderd systemen in beheer, een 65 - 35% mix van RHEL/Centos - Ubuntu. Het merendeel van de fouten in onze onderhoudsweekenden zijn van Ubuntu. Updates die soms stikken om onverklaarbare redenen, 100% geautomatiseerd werkt niet altijd (soms moet je whiptail killen omdat een unattended upgrade toch gewoon om bevestiging van een of ander ding vraagt). Updates die ofwel zelf half geinstalleerd worden ofwel Jenkins breken. Een hoop dingen ga je in een kleine omgeving niet merken of tegenaanlopen, zodra je het gaat inzetten in een enterpriseomgeving wordt het heel anders.

raxon @Archcry • 25 februari 2024 11:05

Is het veel werk dan, als je je daar aan hebt gecommit ? Kan ook wel gemiddeld half uur per week kosten...

rbr320 @YoMarK • 25 februari 2024 10:47

Hou op schei uit. Ik heb deze discussie met zo'n beetje elke CISO en andere "beveiligingsexpert" moeten voeren op elke klus waar ik de afgelopen 5 jaar geweest ben. Steeds maar klagen dat de software geupdate moest worden omdat dit achter zou lopen, terwijl we gewoon de laatste patches van Red Hat hadden geïnstalleerd. Als je meer recente softwareversies wilt zal je een nieuwere versie van Red Hat (of welke distro je dan ook gebruikt) moeten draaien en niet blijven hangen op een (LTS) versie die je jaren geleden hebt gekozen. Maar dat durfden ze dan weer niet omdat ze bang waren dat andere software van derden partijen zou omvallen.

"Vertel me dat je niet weet hoe een Linux distributie werkt zonder me te vertellen dat je niet weet hoe een Linux distributie werkt."

Korvaag

@rbr320 • 25 februari 2024 14:09

Same here: je moet dat package updaten want het is versie x van drie jaar oud en er is inmiddels versie x+4. Als je dan gaat uitleggen dat al die vier releases geen dingen bevatten die relevant zijn voor de betreffende implementatie en ook geen security fixes dan slaat men op tilt. Ja maar je moet de laatste versie -1 draaien! Dat staat in het beleid.

Prima, ik ga wel weer een heel traject in om iets bij te werken wat nergens voor nodig is.

rbr320 @Korvaag • 25 februari 2024 15:31

Het stomme is dat ik het best eens ben met het (x of x-1) beleid maar dat moet je dan wel bekijken vanuit de (enterprise) distro die je gebruikt en niet gaan inzoomen op de individuele packages. Ik leg dan altijd even duidelijk uit dat het bijwerken van software buiten de package manager om een complexe klus is en niet beheer(s)baar, waardoor het meer potentiële beveiligingsproblemen creëert dan dat het oplost.

Vervolgens kunnen ze van mij dan ook nog een flinke lading kritiek verwachten over dat ze véél te laat zijn met het nadenken over een update naar de volgende major release van de gekozen distro. Als je recent pas begonnen bent met nadenken over updaten naar RHEL 8 of Ubuntu 22.04 dan loop je gewoon achter de feiten aan.

Korvaag

@rbr320 • 25 februari 2024 16:21

Het beleid heb ik ook weinig op tegen an sich, maar het zou beleid 'tenzij' moeten zijn. Zaken up to date houden is in dusverre handig dat het meestal ook zo is dat hoe verder je achterloopt, hoe meer issues je kan verwachten bij een upgrade van (ik noem maar wat) een versie 8.1 direct naar 8.24). Echter: als er in de tussenliggende versies aantoonbaar niets relevants is bijgewerkt dan valt dat bij mij onder de 'tenzij'. Je kan dan prima overwegen 2 of 3 versies achter te lopen, maar wel beargumenteerd.

Helaas wordt het vaak heel zwart-wit gebracht en kost het meer energie om er tegenin te gaan dan dat het kost om het stukje software bij te werken. Dat doe je dan dus maar met wat gemor en gebrom.

Kleine edit
Met problemen met te ver achterlopen heb ik momenteel een voorbeeld bij een klant. Een oud OS met een oud stuk enterprise software. OS moet nu bijgewerkt worden, maar het oude stuk software is niet supported op het nieuwe OS. We moeten daar dus in een stuk of vier stappen upgraden (afwisselend OS naar een tussenliggende versie en enterprise sofware naar een tussenliggende versie) om alles weer netjes up to date te krijgen op een manier waarbij je in support blijft. Dan heb je het dus te lang laten liggen.

[Reactie gewijzigd door Korvaag op 23 juli 2024 02:14]

YoMarK @rbr320 • 25 februari 2024 13:00

Dat heb ik inderdaad ook al diverse keren meegemaakt.

moredruid @rbr320 • 28 februari 2024 14:53

Men begrijpt kennelijk niet dat RedHat security fixes back-port voor de packages die ze leveren. Je kunt degene die de security rapportage maakt wel laten zien dat CVE's gefixt zijn (rpm -q --changelog {package-name} | grep CVE-NUMBER)

beerse @YoMarK • 26 februari 2024 09:16

Over de lts of eol van de kernel versie die in de distributie zit is wel degelijk belangrijk. Natuurlijk: Canonical zorgt er wel voor dat de belangrijkste patches en dergelijke er wel in komen en ook dat het onderhoud wel goed zit.

Maar de tools die niet door canonical worden onderhouden gaan uit van de lts of eol waarde van de kernel die er in zit. En als je dan dus dergelijke tools wilt gebruiken dan moet je wel een goede aansluiting hebben. Juist de reden waarom canonical bij haar kernel-versie blijft is precies de reden om juist de lts versie van de linux kernel te willen gebruiken: het nummer staat er op en de interface is daar.

YoMarK @beerse • 27 februari 2024 12:29

Het zit dus anders, zie ook mijn andere post hier vlak onder. 5.15 is en was gewoon default kernel in Ubuntu 22.04 LTS, en die is nog steeds supported(tot in 2026).
Als je 6.5 draait op je systeem, dan heb je die handmatig geïnstalleerd. Is wel beschikbaar in de default repositories voor de liefhebbers die iets nodig hebben wat 6.5 wel biedt maar 5.15 niet.

Eärendil @Archcry • 25 februari 2024 16:45

Ubuntu 22.04 LTS is uitgebracht met Linux 5.15 LTS, en die kan je gewoon nog gebruiken.
Later zijn daar ook 5.19, 6.2 en 6.5 bijgekomen uit als Hardware Enablement (HWE) kernel. Dit zijn de kernels van resp. 22.10, 23.04 en 23.10. Die worden ook niet de hele lifetime van 22.04 ondersteund.

YoMarK @Archcry • 27 februari 2024 12:19

Ik heb dit nog even nagekeken(ook aan de hand van de comment van Eärendil hieronder), en al mijn Ubunty 22.04 LTS systemen draaien "5.15.0-97-generic #107-Ubuntu SMP Wed Feb 7 13:26:48 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux" .

By default is dit dus nooit 6.1 of 6.5. Je hele verhaal klopt dus niet.

Dat artikel van tuxcare waarnaartoe je linkt is ook onvolledig, want je moet handmatig een package installeren voor kernel 6.5:
https://ubuntuhandbook.or...tall-in-ubuntu-22-04-lts/

Ubuntu 22.04 is dus 5.15 en blijft 5.15. En 5.15 is een LTS release, supported t/m Oktober 2026.
https://en.wikipedia.org/wiki/Linux_kernel_version_history

Wat betreft de andere link, die gaat over de vorige LTS versie 20.04, standaard geleverd met kernel 5.4. Nog steeds gesupport, zie link hierboven. Wat betreft de laatste pointrelease van 20.04, zie hier:
https://www.omgubuntu.co....ed-with-linux-kernel-5-15
Nee, by default geen 5.15 of andere kernel dan 5.4, want:

Ubuntu 20.04.5 LTS will stay on kernel 5.4.0.x unless you install the HWE (hardware enablement stack) manually

Zelfde verhaal dus. Je kán "upgraden" naar een nieuwe kernel branch, b.v. omdat je niet anders kan b.v. omdat je hardware niet supported wordt en tóch 20.04 LTS wil draaien. Maar imho...het gaat een beetje tegen het hele "LTS" concept in.

[Reactie gewijzigd door YoMarK op 23 juli 2024 02:14]

Archcry @YoMarK • 27 februari 2024 12:37

Ik snap dat je mijn comment op deze manier interpreteert. Misschien had ik even moeten verduidelijken dat dit niet voor alle versies van Ubuntu het geval was. 20.04 en 22.04 zijn naar mijn weten inderdaad initieel met een LTS kernel geshipped. Dit was echter niet het geval voor 18.04 LTS die werd geshipped met een (toen al) EOL kernel. Daarnaast worden de HWE kernels dus vaak op basis van een EOL kernel gemaakt. Ook zal 24.04 LTS uitkomen met Linux 6.8. Aangezien 6.6 al longterm is betwijfel ik dat 6.8 ook een longterm Linux release wordt. M.a.w. tegen te tijd dat 24.04 uitkomt in april zou het goed kunnen dat Linux 6.8 inmiddels alsweer EOL is.

Daarnaast blijft het mijns inziens niet zo netjes dat Canonical gebruikers middels HWE aanmoedigt om te "upgraden" naar een EOL kernel in een LTS distributie.

[Reactie gewijzigd door Archcry op 23 juli 2024 02:14]

YoMarK @Archcry • 27 februari 2024 15:11

Als het klopt, dan is dat is dat iets wat bijna 6 jaar geleden speelde.Heb er nooit last van gehad, veel Ubuntu machines die ik draai heb ik al van releases van vér voor 18.04, en heb dus altijd supported kernels gedraaid(door Canonical).
Verder moedig niemand je aan om HWE kernels te installeren. Als je er niet naar gaat zoeken, dan kom je er niet eens achter dat ze bestaan.

Archcry @YoMarK • 27 februari 2024 17:49

Iets wat 6 jaar geleden en hoogst waarschijnlijk komende april speelt bedoel je. Daarnaast staan HWE kernels gewoon gedocumenteerd op de Ubuntu website. Ook worden er nieuws artikelen over geschreven. Het argument "als je er niet naar zoekt weet je het bestaan er niet van" is niet heel sterk.

Heb er nooit last van gehad, veel Ubuntu machines die ik draai heb ik al van releases van vér voor 18.04, en heb dus altijd supported kernels gedraaid(door Canonical).

Zoals ik ergens anders ook al schreef, dat jij er geen last van hebt betekent niet dat het geen probleem is. Ik heb ook geen last van files op de A1 want ik rij daar nooit. Betekent niet dat de files geen probleem zijn.

Verder kan je als je dit lijstje goed bekijkt en de kernel versies erbij opzoekt zien dat het Canonical nooit veel uitgemaakt heeft of een kernel nu wel of niet LTS was. Dat ze in sommige gevallen een LTS kernel kiezen voor een LTS release lijkt meer toeval dan intentie.

[Reactie gewijzigd door Archcry op 23 juli 2024 02:14]

HollowGamer 24 februari 2024 22:46

https://ubuntu.com/about/release-cycle

Deze krijgt dus tot 2027 updates.. als software ontwikkelaar lijkt mijn het verschrikkelijk. Waarom moet je rekening houden met een OS zo lang te ondersteunen? Dan tel ik Pro nog niet eens mee.

Uiteindelijk zal Ubuntu/Canonical het zelf doen, dat hebben ze vaker gedaan, maar wellicht is beter dan iedereen overstapt naar Flatpaks/Appimage, zodat ontwikkelaars niet oude tech/libs hoeven te ondersteunen.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 02:14]

RobertMe @HollowGamer • 24 februari 2024 23:38

Als software developer hoef je hier helemaal niks voor te doen. Canonical verzorgt de updates en dat is dus ook hun probleem. Waarbij ze ook nog maar eens alleen zelf patches toepassen die zij nodog vinden.

Juist als software developer is deze hele opzet rete irritant als je semi verplicht met ("outdated") Ubuntu LTS moet werken. Zelf PHP programmeur en onze hosting provider (/managed VPS provider) wil alleen Ubuntu LTS leveren en geeft geen support op packages die niet in Ubuntu zitten. Gevolg: de server draaide tot voor kort op PHP 8.1.2, op Ubuntu 22.04, terwijl vanuit PHP zelf er zelfs een 8.1.27 is. En zelfs ten tijde dat Ubuntu 22.04 uit kwam was er al een hogere patch versie (lijkt op een update elke maand. PHP released in novemver, dus .1 in december, .2 van Ubuntu 22.04 uit januari, .3 in februari, .4 in maart). Waarbij we recentelijk ook tegen een PHP bug aan liepen die ik meen al in 8.1.8 of iets dergelijks was opgelost. Maar dus ook nooit gebackport is door Ubuntu. Zij blijven gewoon doodleuk op de versie zitten van de feature freeze en backporten alleen security fixes en mogelijk kritische bugfixes (als ze echt niet anders kunnen).

Crim @RobertMe • 25 februari 2024 01:47

Als software ontwikkelaar is het juist rete irritant als je steeds je code moet aanpassen vanwege veranderingen in bijvoorbeeld PHP en MariaDB. Met een LTS versie weet je redelijk zeker dat je een paar jaar niet voor verrassingen komt te staan.

Voor andere / nieuwere versies kan je altijd nog Docker gebruiken.

xFeverr @Crim • 25 februari 2024 09:41

En dan moet je een keer upgraden en mag je alle afhankelijkheden die veranderingen hebben gehad de afgelopen x jaar in één keer fixen, in plaats van stapje voor stapje. Kies ik als ontwikkelaar toch liever voor het laatste. Bij blijven zorgt er voor dat je ook vooruit kan.

HollowGamer @xFeverr • 25 februari 2024 09:54

Je zult verbaasd zijn hoeveel programmeurs zelfs dan nog blijven hangen met deprecated code, zeker in webdevelopment.

xzaz @HollowGamer • 25 februari 2024 11:58

Dat komt omdat het reden vaak is 'wat ziet de klant ervan? Niks? Prio naar beneden'. Je kan het wel op veiligheid gaan gooien maar daar is de noodzaak pas terug te vinden als het mis is gegaan.

raxon @xFeverr • 25 februari 2024 11:15

Ik zit op debian met php, ik merk bij mij met bijblijven dat ik toch nog dingen moet skippen bij update / upgrade. Ook mede door mijn eigen code. En whop ben je er dan bijna weer, is er weer een nieuwe versie. Ik doe het dan in mijn eentje, maar doctrine heeft daar ook een handje van, steeds weer deprecrated stuff verwijderen door weer net iets andere schrijfwijze. Gaat mij allemaal net iets te snel momenteel...

HollowGamer @raxon • 25 februari 2024 12:01

Je hebt daar tools voor, deze kunnen je helpen, ook bij best practices.

Guru Evi @RobertMe • 25 februari 2024 02:38

Daarmee dat je op die versies blijft, ze backporten alles dat je nodig hebt. Als de versie waar je aan vast zit een echte bug heeft die je niet kan rondwerken dan neemt je hosting provider gewoon contact op met Canonical en krijg je een patch.

RobertMe @Guru Evi • 25 februari 2024 08:04

Die procedure was mij onbekend. Maar had dan wel verwacht dat de provider dat zou weten. Dat is namelijk geen kleintje, en staat zelfs op deze website op elke pagina vermeld * kuch *.

HollowGamer @RobertMe • 25 februari 2024 09:51

Beste is hierbij overstappen op containers.

Wij hebben helaas ook nog VPS'en met een losse PHP versie, al hebben ze daar wel een GUI/managed oplossing voor geschreven.

Guru Evi @RobertMe • 26 februari 2024 13:21

Als je een degelijke hosting provider hebt met een klantendienst. Let wel op dat je dezelfde versie krijgt (dus van 8.1.12 blijft 8.1.12) maar ze voegen een staartje aan het versie zoals -5 voor de 5de iteratie aan backports.

Red Hat doet dit ook, ik erger mij meer aan security scanners die het verschil niet weten en enkel op versie afgaan. Dat zijn de diensten waar je uiteindelijk 5 of 10 jaar ondersteuning betaalt.

jb044 @RobertMe • 25 februari 2024 07:12

Het is en blijft een keuze. Zelf niet zo van de Ubuntu zeker niet voor server toepassingen, pak dan Debian

Maar dat terzijde .... Laat ik het bij mezelf houden: als je perse support wilt, hetzij vanuit de vendor hetzij vanuit je service provider dan is dat gewoon een keuze. Op RedHat achtigen, ook de gratis varianten is het niet zo spannend om meerdere php versies naast elkaar te draaien er zijn gewoon simpele oplossingen voor, oplossingen die niet op een grove manier het hele systeem vernagelen. En zeker sinds php iets is dat je als daemon wilt draaien is dat ook geen hogere wiskunde, maar dan nog: het is er gewoon en in het geval van RedHat van dezelfde maintainer als de reguliere pakketten. Goed, Ubuntu zal ongetwijfeld ook zoiets bieden . Maar als je perse de support wilt van deze of gene en deze of gene jou restricties oplegt dan is dat jouw keuze en zijn er ook consequenties. Wat anderen al zeggen is het alternatief containers, en daar heb ik juist meer moeite mee: als je echt heel groot bent dan draai je een beperkt aantal containers en weet je heel goed wat daar de eventuele problemen mee zijn. Voor de meesten van ons is een echte server of zelfs een stevige VPS een duur ding, dus daar zal dan van alles op draaien. Containers geven je dan flexibiliteit maar de support daarop is vele malen slechter dan van een Ubuntu LTS, Debian Stable of RHEL. Het is een beetje 'doe het maar lekker zelf allemaal'. Ook dat is allemaal geen hogere wiskunde en wederom een keuze.

Ik vind het altijd wel grappig dat het nooit goed is, terwijl het gewoon om keuzes gaat en keuzes hebben nou eenmaal consequenties

mopringles @jb044 • 25 februari 2024 22:14

Ik vind het altijd wel grappig dat het nooit goed is, terwijl het gewoon om keuzes gaat en keuzes hebben nou eenmaal consequenties

Goed gezegd en dan nog een kleine aanvulling: ook zo grappig hoe iedereen zijn/haar eigen keuze probeert te rechtvaardigen, zonder dat daarom gevraagd is.

Navi @RobertMe • 24 februari 2024 23:51

Das wel gek, in principe zouden ze op 8.1 moet blijven hangen maar de minors 8.1.x wel meenemen.

Olaf van der Spek @RobertMe • 25 februari 2024 03:39

en onze hosting provider (/managed VPS provider) wil alleen Ubuntu LTS leveren

Kun je niet gewoon een self-managed VPS nemen dan?

ArmEagle

@RobertMe • 25 februari 2024 21:39

Hmm. Dat zijn bekende PHP versie nummers...

Ben jij toevallig verantwoordelijk voor BitLocker LockBit?

[Reactie gewijzigd door ArmEagle op 23 juli 2024 02:14]

GeroldM @HollowGamer • 25 februari 2024 03:23

...wellicht is beter dan iedereen overstapt naar Flatpaks/Appimage, zodat ontwikkelaars niet oude tech/libs hoeven te ondersteunen.

Je snapt hopelijk wel dat deze container-vormen alle benodigde libraries en andere afhankelijkheden hebben ingebakken, zodat de maker van de software zeker weet dat zijn/haar software werkt. Met elke Flatpak/Snap/AppImage die je op je systeem kwakt, vergroot je juist de nood om oude software te moeten ondersteunen. Jij als gebruiker hebt er (misschien) minder last van, maar de ontwikkelaar niet echt.

Containers zoals deze vergen echter behoorlijk wat administratie van de gebruiker, want hoe zeker kun je zijn of de maker/maakster van software zijn/haar software goed updated? En hoe snel deze personen kunnen reageren of eventuele problemen in hun software container? Want als dat niet niet tijdig gebeurt, dan draaien de meeste Flatpaks/Snaps/AppImages wel de nieuwste gepatchte software maar word je systeem alsnog onderuit gehaald door die ene container die niet tijdig updated.

Dat laatste heb je zelf niet onder controle. Je kan dan alleen Snaps/Flatpaks/AppImages van de meest bekende software gebruiken, maar die zitten vaak ook al de software repository van de Linux distributie. Deze zijn getest en verknallen je systeem niet. Dus welk probleem los je dan op met Snaps/Flatpaks/AppImages?

AppImages hebben het hoogste bestaansrecht als het gat om dit type van software container. Waarom? Omdat de software maker 1 keer een AppImage hoeft te maken en dat deze werkt op Debian/Ubuntu/RedHat/Fedora/Gentoo/Arch-gebaseerde distributies. Snaps werken alleen met Ubuntu. Flatpaks zijn niet uitwisselbaar tussen de verschillende Linux distributies voor zover ik had begrepen.

hsb85 @GeroldM • 25 februari 2024 07:09

Flatpaks werken juist bijna overal, app images niet. Die gaan er meestal van uit dat je Ubuntu draait en dus sommige packages net niet meenemen en dus niet meer werken in andere distro..

Hydranet @hsb85 • 25 februari 2024 09:44

Ik heb zelfs mensen Snaps op Arch zien draaien, dus die lijken overal wel te werken. Maar ik heb ze nog nooit zelf gebruikt dus kan het niet met zekerheid zeggen.

Hydranet @GeroldM • 25 februari 2024 09:50

Ik kwam van het weekend nog een usecase tegen voor Flatpaks. Ik gebruik beiden Xorg en Wayland omdat er nog wel is iets stuk kan gaan op Wayland. Nu ben ik voor Steam van de Native Steam package naar de Flatpak gegaan omdat ik wel is heb gelezen dat het veiliger is om games onder Xorg in een sandbox te draaien(Ja de sandbox van Flatpaks zijn niet perfect), geen idee in hoeverre dat werkelijk ook is maar daar gaat het niet om. Nu had ik een spel die onder Wayland niet wou opstarten met de Native Steam package, diezelfde game wou wel opstarten onder Xorg maar met de Steam Flatpak lukt het dus we om dat spel ook onder Wayland op te starten.

HollowGamer @GeroldM • 25 februari 2024 09:59

Ik weet het alleen bij Flatpaks, maar daar draait een bot die je depends checkt en ook test of het nog werkt. Daarmee bedoel ik installeert, want testen kun je ook semi-automatisch doen op je eigen branch.

Het probleem is juist dat distros software om zeep helpen door backports of andere patches die ze aan je pakket toevoegen. Het is vaak verre van vanilla, en jij als developer hebt dat niet altijd door dat Canonical jouw software heeft gepatched. Daar kunnen ook bedrijven als Mozilla over meepraten.

Het idee van al die je noemt, is juist dat het inwisselbaar is. Je kunt prima een Snap op Arch draaien, als je maar de service er voor installeert. Zelfde met al die andere formaten, dat is juist de opzet van het systeem, ze moeten inwisselbaar zijn.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 02:14]

jesse! @HollowGamer • 24 februari 2024 22:54

Als bedrijven software / OS maar een paar jaar ondersteunen klagen er ook mensen. Is ook nooit goed natuurlijk.

En als ontwikkelaar heb je nog altijd de keuze om het te ondersteunen of niet.

TheVivaldi

Ubuntu

@jesse! • 24 februari 2024 23:17

Dat ook, en het is ook niet alsof Canonical de enige is. Hoelang werden oudere Windows-versies ondersteund? En macOS? En AmigaOS 3.x en 4.x? En Red Hat? Om maar even enkele voorbeelden te noemen.

HollowGamer @jesse! • 25 februari 2024 09:49

Die keuze kreeg Microsoft niet echt bij VSCode bijvoorbeeld.

Ik vind dat bedrijven ook vaker mogen updaten. Als je zo lang blijft hangen op een LTS, dan heb je uiteindelijk ook een probleem, omdat je niet mee groeit en/of test of het werkt op nieuwere versies.

Het is alsof deze nog zitten op Windows 7/8, en dat kan voor een developer (zelfs MS) nog altijd een probleem zijn.

Jeroen hofman 25 februari 2024 13:41

Ik volg het zover wat betreft snap, ik liep hier ook tegenaan
Wat is dan een alternatief voor UBUNTU. Linux mint ?
Ubuntu 22.04 was mijn favor... OS Jammy Jellyfish

VincentvdBergh @Jeroen hofman • 25 februari 2024 16:34

Ik ben zelf naar openSUSE LEAP gegaan.

Miki @Jeroen hofman • 25 februari 2024 21:16

Ik zou zeker kijken naar Debian, want dat is tenslotte de distro waarvan Ubuntu haar pakketten afleid. Daarnaast zijn voor mij Fedora en OpenSuse interessante alternatieven.

Linux Mint is op zichzelf ook een prima alternatief maar ik ben zelf geen fan van alle wijzigingen die zij doorvoeren maar dat is mijn persoonlijke voorkeur.

synoniem @Jeroen hofman • 25 februari 2024 23:36

Mijn hoofdsysteem draait nog op 20.04 maar ik ga zeker niet 24.04. Denk dat het Debian wordt, die hebben tegenwoordig een heel behoorlijke updatecyclus en geen Snaps.

beerse @Jeroen hofman • 26 februari 2024 09:18

Zelf ben ik uit nieuwsgierigheid overgestapt op kali linux. Net zo debian als ubuntu en mint en zo. Maar dan roling release en onderhouden door techneuten.

Vaevictis_ 25 februari 2024 12:04

Ubuntu was ooit het meest gebruikersvriendelijkste Linux distro, maar afgelopen jaren gebruikers weggejaagd. Snap is echt een drama. Ben blij dat er voldoende alternatieven zijn zoals Linux Mint. Ieder zijn ding.

VincentvdBergh @Vaevictis_ • 25 februari 2024 16:39

Klopt helemaal.

Ik ben begonnen met versie 6.06, en ben bij 16.04 afgehaakt en deels naar openSUSE gegaan. Toen 18.04 uitkwam alles van *Buntu van mijn computer afgesmeten en nog geen spijt van gehad.

Ik werk heerlijk op openSUSE LEAP KDE die ik zo heb gemodificeerd dat het een perfecte imitatie van de Unity desktop is.

Want de Unity desktop vond ik subliem. Het past perfect bij mijn workflow en modus operandi.

[Reactie gewijzigd door VincentvdBergh op 23 juli 2024 02:14]

beerse @Vaevictis_ • 26 februari 2024 09:23

De geschiedenis van diverse linux distrubuties heeft mij geleerd dat er verschillende definities van gebruikersvriendelijk zijn. Het is maar net op welke gebruikers gericht wordt.
Met iedere nieuwe versie van msWindows is er weer een nieuwe groep van ex-msWindows gebruikers waar op gericht kan worden. Daarnaast krijgen de linux gebruikers vanzelf ervaring genoeg om zelf verder te kijken naar andere distributies die meer passen op hun ervaringen.

Het mooiste van linux is dat het gewoon allemaal kan. Tegenwoordig zie ik best veel 'appliances' langs komen: Kant en klare linux-met-een-applicatie die zo kan worden uitgepakt en gebruikt. Dat is ook gebruikersvriendelijk.

elteck 25 februari 2024 06:34

Deze update is fijn! Had wat probleempjes met m’n bluetooth toetsenbord (koppelde niet automatisch bij opstarten), is nu opgelost. Ook zie ik geen hardware foutmeldingen meer bij het opstarten.

yor111 24 februari 2024 20:48

De officiële release komt pas 25 april toch? Dit een test release voor systeem beheerders en developers

magnifor @yor111 • 24 februari 2024 20:51

Nee dan komt versie 24 uit, die van vandaag is nog de 22 reeks die tot 2027 wordt ondersteund.

Master FX

@yor111 • 24 februari 2024 21:30

Het is gewoon een update van de 22.04 release. (de vierde: 22.04.4)

VincentvdBergh @yor111 • 24 februari 2024 22:21

Dit is gewoon het 4e servicepakket voor de 22.04 uitgave.

De standaard download is nu 22.04.4, waardoor er onder andere een nieuwere kernel versie meegegeven wordt.

24.04 komt pas eind april uit.

Jeroen hofman 27 februari 2024 11:12

@VincentvdBergh
zijn er verschillende distro van openSUSE LEA ben hier niet zo bekend mee

VincentvdBergh @Jeroen hofman • 27 februari 2024 18:26

LEAP is de stabiele uitgave van openSUSE. Vergelijk het met een LTS uitgave van Ubuntu.

OpenSUSE heeft ook een rolling release met de nieuwste pakketjes en software: Tumbleweed.

Daarnaast is er een slow rolling release.

Jeroen hofman 28 februari 2024 09:40

Mooi dan ga is OpenSUSE proberen, is voor mij onbekend

Op dit item kan niet meer gereageerd worden.

Versienummer	22.04.4 LTS
Releasestatus	Final
Besturingssystemen	Linux
Website	Canonical Ltd.
Download	https://ubuntu.com/download/desktop
Licentietype	Voorwaarden (GNU/BSD/etc.)

31-08	Ubuntu 24.04.1 LTS	47
26-04	Ubuntu 24.04 LTS	11
24-02	Ubuntu 22.04.4 LTS	76
10-'23	Ubuntu 23.10	20
08-'23	Ubuntu 22.04.3 LTS	46
04-'23	Ubuntu 23.04	51
02-'23	Ubuntu 22.04.2 LTS	39
10-'22	Ubuntu 22.10	14
08-'22	Ubuntu 22.04.1 LTS	5
04-'22	Ubuntu 22.04 LTS	30

Software-update: Ubuntu 22.04.4 LTS

Update-historie

Lees meer

Reacties (76)

Sorteer op:

Weergave: