Linus Torvalds geeft Linux 6.0-kernel met nieuwe AMD- en Intel-drivers vrij

Linus Torvalds heeft versie 6.0 van de Linux-kernel gepubliceerd. Deze update voegt onder meer ondersteuning voor nieuwe hardware toe, naast prestatieverbeteringen en bugfixes. De nieuwe kernelversie brengt geen grote veranderingen met zich mee.

Linus Torvalds schrijft in de Linux-mailinglijst dat Linux-kernel 6.0 vanaf nu beschikbaar is. Het is voor het eerst in jaren dat er een nieuwe grote 'nummerrelease' van de Linux-kernel verschijnt; Linux 5.0 verscheen in maart 2019. Tegelijkertijd schrijft Torvalds dat Linux 6.0 geen grote release is; er zitten weinig grote veranderingen in de kernelversie.

"Zoals hopelijk voor iedereen duidelijk is, is de grote versienummerwijziging meer een gevolg van het feit dat ik geen vingers en tenen meer heb dan van grote, fundamentele veranderingen." Torvalds benadrukt wel dat er ruim 15.000 non-merge commits in Linux 6.0 zitten. Daarmee is het volgens de Linux-maker een van de grotere releases op het gebied van commits.

In Linux 6.0 zitten, naast verschillende bugfixes, nieuwe drivers van hardwarefabrikanten. Zo voegt Intel ondersteuning voor zijn komende Sapphire Rapids-serverchips en Raptor Lake-processors toe. AMD levert bepaalde fixes voor zijn komende RDNA 3-gpu's. Een workaround voor oude AMD-chipsets, die de prestaties van moderne AMD-systemen kon schaden, is verwijderd. Daarnaast is de H.265-api naar de stable branch geplaatst.

Met de release van Linux 6.0 wordt de merge window van Linux-versie 6.1 binnenkort geopend. Naar verwachting krijgt die release grote veranderingen, waaronder officiële ondersteuning voor de Rust-programmeertaal, schrijft ook Phoronix.

Reacties (55)

[PerAspera]

Wil jij ook aan versienummers doen? Maar wil je het niet baseren op aantal vingers en tenen?
Neem dan nu een kijkje op https://semver.org/ voor een zinnig startpunt!

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backwards compatible manner
PATCH version when you make backwards compatible bug fixes
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

[uiltje]

Waarmee impliciet wordt aangegeven wordt dat Linux dus niet op semver is gebaseerd, want dan had de major versie niet moeten worden opgehoogd. Nou is het de taak van een OS om zo lang mogelijk backwards compatible te zijn, dus waarschijnlijk ben je beter af als je er een major versie van 1 voor fantaseert.

Zelfs dan geeft dit aan dat er weinig verschil zou zijn tussen MINOR & PATCH; ik denk ook niet dat semver erg goed werkt voor zulke grote verzamelingen. Als de software groot genoeg is is er altijd wel ergens een breaking change (die verder niet van belang hoeft te zijn voor het gros van de applicaties).

[ACM]

Semver's major-nummering is inderdaad vooral relevant wanneer het concept van 'BC breakage' bestaat en men dat serieus neemt en praktisch kan toepassen.

In mijn ervaring zijn er projecten die daar heel netjes mee omgaan en projecten die ook af en toe in minor updates toch een BC-breakage doen omdat het maar een kleintje is (zoals Symfony dat met versie 6.1 een nieuwe PHP-versie afdwong, ipv daarvoor een 7.0-versie te introduceren).

Als de Linux-kernel in een "minor" versie ineens een bepaald apparaat niet meer ondersteund, is dat wel verwarrend voor gebruikers die het concept van semver verwachten. Anderzijds, worden er tegenwoordig zoveel apparaten ondersteund, dat ze dan bijna alleen maar major's zouden uitbrengen omdat er bijna iedere keer wel weer e.o.a. obscuur apparaat niet meer wordt ondersteund...

[Reactie gewijzigd door ACM op 29 juli 2024 08:36]

[air2]

Op zich zou iedere keer een nieuwe major vesie natuurlijk ook geen ruk uitmaken. Of het nu 5.4.2 is of 543.0.0 het blijft een nummer. Nu zegt het nummer niks. Met semver zou het praktisch gezien ook weinig zeggen. Aangezien bij de kernel release bijna alles wel ergens breaking is. Maar aan de andere kant ze zouden makkelijk fixes voor oudere kernels kunnen uitgeven. Er valt voor beide wat te zeggen.

[bazzi]

Ja die symfony was echt wen topper op gebied van semver

[Rafe]

zoals Symfony dat met versie 6.1 een nieuwe PHP-versie afdwong, ipv daarvoor een 7.0-versie te introduceren

Punt 1 van SemVer is dat "software [..] MUST declare a public API" en het is aan de software om precies te specificeren wat onder de publieke API valt. Ben niet bekend met Symfony maar zolang de method signatures exact hetzelfde zijn zou ik het ophogen van vereiste versie van de runtime niet zien als een breaking change, net zoals SemVer dat voor dependencies niet ziet als een breaking change?

[Reactie gewijzigd door Rafe op 29 juli 2024 08:36]

[JBVisual]

De release van Ubuntu is ook logisch om te volgen met een jaartal + maand en een versienummer voor de patch versie.
Zie https://wiki.ubuntu.com/Releases

[TheVivaldi]

Niet echt, want in 3022 hebben ze dan een probleem met 22.04 en 22.10...

Precies wat je nu ook al ziet met bijvoorbeeld oude prentbriefkaarten: er staat een poststempel uit '10 op, maar dat verwijst naar 1910 en niet naar 2010.

[GertMenkel]

Je kunt uit de context wel opmaken of er 2010 of 1910 bedoeld wordt. Rond Y2K was dit een probleem maar ik denk niet dat Ubuntu 3022.04 een probleem zal vormen omdat alle apparaten die 22.04 draaien dan al lang weggeroest zijn.

[TheVivaldi]

Uit de context wel, maar als er alleen een linkje naar 22.04 staat, dan is dat verschil niet te bemerken. Dan moet je dus al gaan zoeken naar een datum of zo. Het gaat er niet om of apparaten die 22.04 nog werken of niet, het gaat er om dat je duidelijk wilt weten welk jaartal de versie van is. En dan is 2022.04 duidelijk dan 22.04.

[GertMenkel]

Dat het geen datum is, blijkt uit context omdat voor "22.04" altijd "Ubuntu" of "versie" staat. Het scheelt ook helemaal niemand wat welk nummertje er precies staat, aangezien 18.04 nog steeds wordt bijgewerkt en 21.10 al niet meer, dus het is niet alsof "recenter dus beter" opgaat ofzo.

Ik acht de kans dat Ubuntu over honderd jaar nog bestaat gigantisch klein, nog kleiner dan dat er ooit verwarring over de titel ontstaat. Dit is gewoon geen probleem in de echte wereld.

[TheVivaldi]

Tja, MAN dacht vast ook dat ze niet eeuwig zouden bestaan, gezien de oprichters van de bedrijven vóór de fusie geen grootheidswaanzin hadden, maar ze bestaan nog steeds. En voor AmigaOS leek het doek ook lang geleden gevallen, maar het bestaat nog steeds en krijgt nog steeds updates en upgrades. Ik acht de kans dat Ubuntu over 100 jaar nog bestaat dus best groot.

[Reactie gewijzigd door TheVivaldi op 29 juli 2024 08:36]

[GertMenkel]

AmigaOS is nog geeneens een halve eeuw oud, laat staan een eeuw. Ubuntu is nog niet eens twintig jaar oud.

Het zou leuk zijn als Ubuntu over tachtig jaar nog bestaat, maar ik denk dat ze net als Red Hat dan al lang door een techreus zijn overgenomen en ze niet eens besturingssystemen maken. Ze lijken zich nu al te focussen op vage serversystemen en een of ander snap-gebaseerd businessmodel, ik denk dat ze over tien jaar al alleen nog maar een merknaam zullen zijn als ze zich zo blijven gedrsgen.

[TheVivaldi]

AmigaOS is nog geeneens een halve eeuw oud, laat staan een eeuw.

Dat was mijn punt ook niet. Ik had het over de levensvatbaarheid.

Daarbij noemde ik ook MAN en die bestaan echt wel meer dan een eeuw, te weten sinds 1898 (sinds 1908 onder de huidige naam). En als je de pre-fusies ook meetelt, dan gaat het bedrijf zelfs terug tot 1758.

[nout77]

Ubuntu 18.04 is een LTS versie, (Long Time Support), net als 22.04. Staat ook netjes toegelicht o.a. op hun website dat LTS versies elke 4 jaar worden uitgebracht. En deze worden dan ook vele jaren ondersteund. De tussenliggende niet LTS versies worden 9 maanden ondersteund.

[StGermain]

Dan doen ze toch 122.04 en 122.10?

[Hobbit13]

Vaak wil marketing ook wat over de versienummers zeggen, aangezien ze ook zichtbaar zijn voor de klant. Dan is "coole nieuwe feature die backwards compatible is" toch echt wel een MAJOR.

[pimlie]

MAJOR version when you make incompatible API changes

En daarom volgt Linus geen semver: We do not break userspace!

[GertMenkel]

En vergeet niet: als de versie met 0. begint, mag alles van minor versies tot patchversies breaking changes bevatten!

Leuk idee, maar hier houdt echt helemaal niemand zich aan. Minor versies krijgen in de praktijk breaking changes omdat mensen van het buggedrag uitgingen, major versies worden vrijgegeven met alleen maar nieuwe features en geen tot weinig breaking changes, ga zo maar door.

Een besturingssysteem heeft sowieso niks aan semver, daar is het veel te complex voor. Iedere release wordt dan een major versie en voor je het weet zit je op Linux 100.1.23, dat zegt net zoveel als Linux 6.3.36. Helemaal omdat de Linux-kernel maar beperkte LTS-versies heeft die je voor meer dan een paar maanden kunt gebruiken, heb je helemaal niks aan dit schema.

[thunderbird2k]

Voorheen gebruikte Linux dit ook, maar sinds 2.6 zijn ze er vanafgestapt aangezien er geen gigantische fundamentele veranderingen meer waren. Voorheen waren er grote veranderingen zoals het geheugenmodel. Sinds einde van de 2.6x cyclus is Linus begonnen met 3.0 en met 5-6 releases per jaar, zorgt dit voor een major bump ruwweg elke 3-4 jaar.

[blahenazo]

LOL,
vroegah hadden we letterlijk dit zoals hierboven.

Dan kwam er een nieuwe release mgt tool die maar 2 digits supportte , dus XX.YY (allicht gekozen door een of andere expert ) => policy => alles moet naar 2 nummers. Jamaar wij gebruiken deze methode , reply : zwijgen en aanpassen,....

Ok dan => major.minor+1 , en bij 99 doen we een carry bit naar de major


Op een gegeven moment maakt het niet meer uit en is het een nummer......

[MIB75]

"Zoals hopelijk voor iedereen duidelijk is, is de grote versienummerwijziging meer een gevolg van het feit dat ik geen vingers en tenen meer heb dan van grote, fundamentele veranderingen."

Beetje aparte zin...

[T-men]

Vrij vertaald: er zijn zoveel kleine versies geweest dat we ze eens een keer moeten samenvatten onder een grote versienummerwijziging.

[MIB75]

Ja, zoiets dacht ik ook. Maar het blijft een vreemde zin.

[Ohmarinus]

Ik ben het daarmee eens, en die verwarring ligt in de foute vertaling in het Nederlandstalige artikel van Tweakers.

'Ik hou geen vingers en tenen meer over' of iets in die trant.

Als je de link bekijkt, dan zie je dat de Engelstalige uitleg duidelijker is:

the major version number
change is more about me running out of fingers and toes than it is
about any big fundamental changes.

[ACM]

Is de vertaling echt zoveel anders? Ook even op losse regels gezet:

Zoals hopelijk voor iedereen duidelijk is, is
de grote versienummerwijziging
meer een gevolg van het feit dat ik geen vingers en tenen meer heb dan van
grote, fundamentele veranderingen.

[gday]

Ik kon ook helemaal niks met de Nederlandse 'vertaling', tot ik de originele Engelse zin las.

Als je zo dicht mogelijk bij de oorspronkelijke uitspraak zou willen blijven, zou ik eerder zeggen: "Zoals hopelijk voor iedereen duidelijk is, is de grote versienummerwijziging
meer een gevolg van het feit dat ik niet genoeg vingers en tenen heb dan een gevolg van grote, fundamentele veranderingen."

(Ja, offtopic. I know. )

[Reactie gewijzigd door gday op 29 juli 2024 08:36]

[LA-384]

You've heard the bell ring but you don't know where the clapper hangs.

Er is natuurlijk vertalen en vertalen. Vertaal je de letterlijke tekst, of de betekenis? Dat van die vingers en tenen is volgens mij geen Nederlandse uitdrukking.

Bij nader inzien is het ook niet eens een echt gezegde/uitdrukking. Het ging er dus om dat het nummer achter de punt te groot werd om nog op vingers en tenen te kunnen tellen.

[Reactie gewijzigd door LA-384 op 29 juli 2024 08:36]

[ACM]

Wellicht zouden we eerder iets van "op handen en voeten kan tellen" gebruiken. Maar een heel andere uitdrukking neerzetten dan een vrij letterlijke vertaling maakt het niet altijd duidelijker of beter, al is het maar omdat zo'n alternatieve uitdrukking mogelijk net wat anders betekent.

Misschien had gewoon de Engelse tekst maar moeten worden overgenomen (maar dan krijgen we vast daar weer klachten over )

[LA-384]

"Zoals hopelijk voor iedereen duidelijk is, heeft de grote versienummerwijziging meer te maken met het feit dat ik niet genoeg vingers en tenen heb om het nog mee te kunnen tellen, dan met grote, fundamentele veranderingen."

Zoiets? Dat loopt in mijn ogen iig beter.

Of

"Zoals hopelijk voor iedereen duidelijk is, is de grote versienummerwijziging meer een gevolg van het feit dat ik inmiddels vingers en tenen tekort kwam om het nog op te kunnen tellen, dan van grote, fundamentele veranderingen."

Het origeel is gewoon een kromme zin. Dat is ook een feit

[Ryceck]

Vertaalde versie: hij wil niet hoger met de versie nummers dan 20 want dat is zo moeilijk tellen op vingers en tenen. Andere versie met dezelfde strekking is zoals hij in augustus zelf al aangaf:
"Torvalds remarked, "I'll likely call it 6.0 since I'm starting to worry about getting confused by big numbers again.""

En hij geeft hiermee tegelijk ook aan (zoals Linus al jaren doet) dat het hem zal rotten welk nummertje het ding heeft; 6.0 is niet heel veel spannender dan 5.19 wat de vorige versie was :-)

[Verwijderd]

Hij heeft ergens wel een punt ook. Bijna alle professionals weten ongeveer waar we momenteel zitten met de versie van de Linux kernel. Dat is vooral door niet te grote nummers links van de en rechts van de punt te hebben. Bijvoorbeeld Qt lijkt een gelijkaardig model te volgen.

Heel wat andere software titels hebben of gigantische nummers rechts en blijven dan 25 jaar in versie 1. of 2. hangen (ik denk dan bv. aan GLib, Gtk, GNOME, etc); of gigantische nummers zowel rechts als links waarbij niemand weet wat het wil zeggen. Vaak hebben die nummers ook een marketing-kantje. Daardoor worden ze helemaal onbruikbaar in de technische context (bv, het updaten en bijhorende package management). Want ga er maar van uit dat marketing mensen geen kaas hebben gegeten van dat wat er toe doet: package management; dat ze denken dat mensen meer centjes zullen geven voor het nummertje waar zij deze week mee op de proppen zijn gekomen in de meeting met de baas, ongeacht of het waar is (we moeten dus ook iets hebben voor de marketing jongens. Laten we dat de 'release naam' noemen, ipv het nummer? - misschien met mogelijkheid voor plaatjes, emoticons, banners, neon-lampen en muziek?).

Ik ben zelf voorstander van x.y.z i.p.v. enkel x en y omdat je dan je grotere nummers (m.a.w. je bugfix releases) in z kan onderbrengen. Je feature releases in y. En de grote wijzigingen in x (m.a.w. semantic versioning). Maarja. Dan zou voor de Linux kernel je dus gigantische nummers voor x krijgen. Want er komen continue grote wijzigingen toe. En de y is nu al ongeveer op die manier gebruikt voor de Linux kernel. Vroeger had je oneven y nummers voor onstabiel en even y nummers voor stabiele Linux kernel releases. Maar dat kon denk ik niet blijven duren. Alle Linux releases horen trouwens stable te zijn.

ps. Eigenlijk wil je in fatsoenlijk software ontwikkeling tegenwoordig twee keer semantic versioning gecombineerd, want je hebt de upstream versie en je eigen downstream versie met je eigen wijzigingen (die net zo goed met semantic versioning geversioneerd horen te worden) die nog niet geaccepteerd zijn in een upstream versie. M.a.w. x.y.z~tag-x.y.z dan. Ben je zelf upstream en/of de enige ontwikkelaar, dan is enkel x.y.z wel voldoende. M.a.w. heeft RedHat wijzigingen voor de Linux kernel 6.0.10 (wat bugfix release 10 is voor feature release 6.0) dan hebben zij dus versie 6.0.10~redhat-0.1.1 wat dus hun eerste bugfix release voor hun eerste feature release van hun wijzigingen boven op upstream 6.0.10 is. Ben je downstream van een andere downstream van een upstream dan is het tildes al the way down).

[Reactie gewijzigd door Verwijderd op 29 juli 2024 08:36]

[qbig1970]

ik heb ook inderdaad geleerd Major-Minor-Maintenance
beste en eenvoudigste manier begreep ik.

[Juice2000]

"Een workaround voor oude AMD-chipsets, die de prestaties van moderne AMD-systemen kon schaden, is verwijderd"

Dat was een leuke vondst inderdaad. Een stuk oude code wat extra delay's uitvoerde die nodig waren bij sommige Via chipsets van oude AMD systemen. Jammer dat het twintig jaar geduurd heeft, en dus iedereen met een AMD cpu al die tijd niet alle performance er uit kon halen. Zie ook: https://www.theregister.c...27/obsolete_amd_acpi_fix/

[MrMarcie]

Geldt dat ook voor mijn 3700X? Nog maar paar jaar oud.

[Juice2000]

Volgens mij ging het om alle AMD processors. Maar het is nu gefixt, dus updaten en je bent geholpen.

[MrMarcie]

Werk met Fedora dus hopelijk komt dat snel. Ga het niet zelf doen.

[Cageman1984]

Welke distro's gebruiken de laatste versie eigenlijk? Dat ga ik eens googlen.

...nieuwe AMD- en Intel-drivers vrij...

Wanneer zou Nvidia nou eens in dit rijtje komen?

Off topic: steamos 3 / holoiso heeft nog steeds geen goede Nvidia support .

Trouwens, kan iemand me uitleggen waarom de note bij versie 6 "Named "Hurr durr I'ma ninja sloth" is??? Geen grapje, zie regel 6 in deze link

[Reactie gewijzigd door Cageman1984 op 29 juli 2024 08:36]

[latka]

Om mensen te entertainen. Zie https://handwiki.org/wiki/List_of_Linux_kernel_names voor een complete lijst van namen. Ik vond linux 3.11 "Linux for work groups" erg grappig bijv.

[jerisson]

En mogelijk een referentie naar Linux 4.0, genaamd "Hurr durr, I'm a sheep!", hetgeen de uitkomst was van een poll die Linus hield op Google+. (Nuja, de andere optie was toen "I like online polls")
https://git.kernel.org/pu...be9507871fab3931deccff539

De 3.11 was wel nice inderdaad

[Jogai]

Prima dat je met je kernel geen SemVer volgt, maar om het helemaal arbitrair te maken is imo wel een beetje jammer. De volgende release heeft ondersteuning voor Rust modules, dat had een hele mooie feature geweest om met een nieuw Major nummer (dus 6) te vieren. Ach, Linus doet Linus dingen...

[Verwijderd]

Dat is in semver hooguit een feature increment, geen major increment. Want je breekt er niets mee (mag ik hopen).

De "API" van Linux is haar userspace POSIX ondersteuning. Dat is nog nooit gebroken. M.a.w. zou Linux dan nog steeds op 0.y.z zitten. Misschien 1.y.z want er zal vast wel eens ooit iets wat betreft userspace gebroken geweest zijn. Maar zelfs nieuwe dingen ondersteunen zou dan enkel een ophoging van y zijn. Bijvoorbeeld een nieuwe file monitoring API zou dan 0.1.z veroorzaakt hebben.

[Jogai]

Daarom zeg ik ook, prima zonder semver, maar maak het nog wel logisch, dus een major versie voor major features, of om speciale toevoegingen te 'vieren'. Bovendien kan je nog steeds doortellen in y.z.

[aikebah]

1.y.z, want in SemVer is je eerste stabiele release 1.0.0

[latka]

Vanuit de gebruiker gezien verandert er geen bips met de komst van rust: de api en calling convention blijven gewoon die van linux en rust is gewoon een van de tig features die ze hebben. Ik het logischer vinden als ze ophogen als er een nieuw hardware platform ondersteunt wordt, maar dan zouden ze ook al in versie 312.x zitten

[Jogai]

Op zich heb ik niet tegen versie 384.x

Maar ik vind versie nummers vooral iets voor developers. Die krijgen straks meer mogelijkheden met Rust en dan zou ik het vreemd vinden als dat wel werkt op 6.1 en niet op 6.0. Als dev verwacht je toch een beetje dat je binnen 1 major versie ongeveer hetzelfde kan.

Nu is het niet meer dan een grap, en daarvoor vind ik het versienummer niet de juiste plaats. Je zult bij iedere keuze wel mensen hebben die het niet in hun straatje vinden passen, maar zou er tenminste nog 1 groep zijn die er wat aan had. Nu heeft niemand er wat aan.

[latka]

Het probleem is dat er 2 versie zijn: user facing en die is eigenlijk niet wezenlijk verandert sinds versie 2.6 oid en de interne api, want zo redeneert Linus: als je in de kernel wil is het jouw verantwoordelijkheid om te zorgen dat het werkt. De interne kernel api is instabiel en dat is by-design. Dus een versie nummer is niet zo zinnig. Je kunt beter een git hash check doen om te zien of iets mogelijk werkt, of beter nog: zorg dat je code gemerged wordt in de kernel en regressies worden ook door anderen gesignaleerd. Het idee om een stabiele kernel api te hebben hindert vooruitgang (zie windows) dus dat doet'ie gewoon niet.

[Jogai]

Het idee om een stabiele kernel api te hebben hindert vooruitgang (zie windows) dus dat doet'ie gewoon niet.

Dat is ook niet wat ik probeerde te zeggen.

[latka]

Ik miste een stukje wellicht, want ik denk dat ik snap wat je probeerde te zeggen:
Versie nummers binnen de kernel beteken niets: een feature kan er bij versie 3.1 ingekomen zijn, bij 3.2 verwijderd zijn en dan vervolgens een jaar later bij 3.8 weer teruggekomen, maar dan beter/anders. Aftesten op een versie (versie > 3.1) is dus nooit een goed plan in dat geval. Vandaar mijn opmerking dat je beter de git-hash kan checken: die stijgt ook niet monotoon, maar geeft wel precies aan wat er in de kernel zit. Kernel extensies in Linux worden vrijwel nooit (met uitzondering zoals Broadcom en Nvidia) buiten de kernel om ontwikkelt. Dus is de relevantie van een intern versie nummer zeer laag.

[latka]

-verkeerde parent-

[Reactie gewijzigd door latka op 29 juli 2024 08:36]

[Katsunami]

Mooi; gaat dit ook een LTS-kernel worden, of wordt dat 6.1? Ik vraag me af welke kernel Debian 12 gaat krijgen. Zover ik heb kunnen zien komt er ergens in oktober een LTS-kernel uit, die dan in januari in Debian terecht komt.

[gekkie]

Op zich zou 6.1 misschien wel aardig zijn, MGLRU, Rust basics. Maar goed zo is er altijd wel iets om nog 1 versie te wachten

[Katsunami]

Als de kernel die LTS wordt goed werkt met de nieuwe 7950x en de nVidia 4000 en whatever-de-recente-AMD-kaarten zijn, dan vind ik het prima. Ik ga na de release van Debian 12 voor een 7950x kijken (die dan waarschijnlijk in ECO-mode gaat draaien....)

[N8w8]

Vroeg ik me ook af; hier wordt uitgelegd waarom waarschijnlijk 6.1 LTS wordt.

[Katsunami]

Het zou heel mooi zijn als KDE zijn huidige 5.26 cycle afgewerkt krijgt tot 5.26.5, en kernel 6.1 LTS wordt.

Nu draai ik Debian 11 (kernel 5.10 en KDE 5.20.5) op een i7-6700K.
Als ik kan upgraden naar een 7950X (in ECO mode) met Debian 12 op kernel 6.1 en KDE 5.26.5, dan zou dat zowel qua hardware als software een flinke sprong zijn. Dat systeem zou dan makkelijk mee moeten gaan tot en vanaf Debian 12 t/m 16 (8 jaar).