Nouvelle mouture importante pour le noyau Linux. Même si la nomenclature ne donne plus la même importance aux « comptes ronds » et a été surtout introduite pour simplifier la numérotation, cette version 6.0 reste significative.
Les améliorations y sont très nombreuses, ne serait-ce que sur le support matériel. On y trouve notamment la prise en charge des processeurs Alder Lake et GPU Arc d’Intel (expérimentale celle-ci), du Soc Snapdragon 8cx Gen 3 de Qualcomm ou encore un meilleur support des bibliothèques 3D du Raspberry 4.
On trouve également plusieurs améliorations pour l’architecture RDNA3 d’AMD ainsi qu’une meilleure prise en charge pour les Ryzen 7000 (plateforme Raphael).
Le noyau Linux 6.0 introduit en outre un important mécanisme de vérification à l’exécution pour la sécurité des systèmes critiques. Autre apport significatif, l’API H.265/HEVC est maintenant considérée comme stable.
Comme toujours, les nouveaux noyaux ne sont pas forcément disponibles tout de suite. Tout dépend de la distribution utilisée. Si vous êtes sur une rolling release de type Manjaro, la mise à jour est peut-être déjà là. Pour les autres, comme Ubuntu, il faudra attendre la version suivante du système.
Maintenant que la version 6.0 est sortie, la 6.1 est en préparation et pourrait être encore plus importante. Elle introduira un support initial pour l’infrastructure Rust, le langage initialement créé par Mozilla et depuis géré par une fondation dédiée. Si vous voulez en savoir davantage, le site Phoronix (en anglais) propose déjà une liste des améliorations connues.
Commentaires (28)
#1
Je ne comprends pas ce qu’une API de codec vidéo vient faire dans le noyau. C’est du code qui normalement est dans une “lib”, soit en logiciel pur, soit en mixte avec interface avec le matériel (QuickSync chez Intel par ex).
#1.1
C’est la prise en charge de l’accélération matérielle. Il faut donc que ce soit dans le noyau.
#1.2
Il n’y avait pas un flou juridique au niveau des brevets pour l’accélération matérielle? Ce flou aurait incité Fedora à désactiver l’accélération matérielle dans sa dernière version.
Je trouve alors étrange que cela arrive dans le noyau malgré ce flou juridique.
#1.3
Si pour bénéficier de l’accélération matérielle, il faut payer une licence, il faut bien que le code soit implémenté pour que ce soit fonctionnel.
Du coup je trouve pas ça déconnant que le code soit présent, mais pas forcément disponible.
#1.5
c’était pas lié seulement à certains codecs à licence comme h264 ou mpeg?
#1.4
Contrairement à son nom, le kernel Linux n’est pas qu’un noyau. C’est aussi tous les drivers qui lui sont intégré.
De plus, les drivers sont dans l’espace kernel et/ou l’user space.
On parle ici d’une “user space API”, on n’est donc pas loin de ce que tu dis.
Comme il a été dit plus haut, cette API finit par piloter du matériel pour l’accélération. C’est donc bien un driver qui a toute sa place dans le noyau Linux qui inclut les drivers.
#1.6
Ouais… et j’imagine qu’on aura pas un noyau spécifique serveur pour éviter tout ce code inutile mais agrandissant la surface d’attaque…
#1.7
Le noyau n’est pas un seul exécutable mais il est modulaire. C’est l’administrateur de la machine qui choisit au final si un driver est utilisé ou nom.
#2
Non : Arch reste sur la 5.19.12 pour le moment (et je doute que Manjaro prenne de l’avance sur Arch avec ses propres paquets), et proposera sûrement une 5.19.13 avant de passer à la branche 6.0.x sur le canal stable (ce qui ne devrait pas arriver avant au moins la version 6.0.1, voire 6.0.2).
Certains ont noté une réactivité accrue avec ce noyau (qu’ils ont compilé eux-mêmes, donc ; vu qu’aucune distribution ne le propose à ce jour). Vous confirmez, celles et ceux qui ont pu le tester ?
#3
un rapport avec ceci ?
#3.1
Ce truc qui ne sert que pour certains processeurs/chipsets d’il y a 20 ans est quand même imposé à tous les processeurs et cela réduit à la fois leurs perfs et leur efficacité énergétique ?
Ils ont réussi à open-sourcer même les mauvaises pratiques de certains spécialistes du closed-source
#3.2
Manifestement si on lit le diff, le noyau utilise déjà un moyen plus efficace pour les Intel “récents” (ie moins de 15 ans… Ne restent impactés que les AMD dans certains cas de figure (bursts cycliques d’activité)
Par ailleurs, il est difficile par définition d’établir si le logiciel closed-source dont tu parles a le même problème ou si cela y est résolu depuis 10 ans
#4
Manjaro propose 6.0 en Experimental (6.0rc4)
Les dernières versions stables à ce jour sont la 5.19.7 ou la 5.19.0_rt
Perso je reste en 5.15.65 LTS pour le moment.
#5
On parle d’API au départ ; effectivement pour utiliser l’accélération matérielle à un moment il faut être en mode noyau, mais c’est une autre partie du code éventuellement (la partie “driver” plus bas niveau).
Ah ?
Si l’API est “user space”, elle n’est pas dans le noyau donc (tu sembles être d’accord dans ta première phrase). Le driver lui est dans le noyau mais s’attaque à plus bas niveau (des bouts de données à coder ou décoder par ex).
PS : il est question ici surtout des SoC côté matériel, on dirait (le lien Phoronix).
J’aurais pensé que l’API H265 était stable depuis longtemps vu que le format n’est pas tout récent (et les principes proches du H264).
#5.1
Je ne fais que reprendre la terminologie des développeurs de Linux qui parlent aussi de driver pour le userspace.
Quand un driver est écrit (essentiellement) en userspace, ils parlent de “kernel module” pour la partie la plus basse.
La plupart des nouveaux drivers sont écrit ainsi afin de minimiser les risques de plantage du noyau à cause d’un bug driver.
Tu ne vas pas m’apprendre ce qu’est un driver, tu étais encore au collège que j’en avait déjà écrit en école d’ingénieur et j’ai fait l’essentiel de mon parcours professionnel dans le domaine de l’embarqué et le logiciel temps réel.
J’ai même écrit un patch pour le driver USB de Linux qui ne respectait pas la norme USB dans un cas particulier ce qui plantait notre produit.
Par contre, dans le contexte de Linux, désolé, j’adopte leur terminologie, sinon, on ne comprendrait pas de quoi je parle.
#6
Pas spécialement : c’est juste qu’ils prennent le temps de vérifier que, pour le noyau, il n’y aura pas de problème avant de proposer une nouvelle version majeure aux utilisateurs. C’était la même chose au moment du passage de la branche 5.18 à 5.19, et les autres avant elles.
D’ailleurs, sur Arch, le noyau LTS ne passe à la branche suivante que lorsque le noyau « normal » quitte la branche appelée à devenir la nouvelle LTS (autrement dit : le paquet
linux-ltsn’est passé en 5.15 que lorsque le paquetlinuxtout court est passé en 5.16¹).¹ Encore qu’en vrai, ça s’est pas tout à fait passé comme ça, car les mainteneurs de ces deux paquets sont deux personnes différentes et elles ne se coordonnent pas, même quand elles prennent des vacances et ne s’occupent donc plus de les mettre à jour pendant ce temps. On a ainsi eu pendant quelques jours un paquet
linux-ltsde même version, voire avec une version plus avancée que celle du paquetlinuxtout court (ce qui ne doit normalement jamais arriver). Un comble !C’est vrai que Manjaro préfère les noyaux LTS, de toute façon. Mais rester en 5.19.7, qui date déjà d’il y a un moment…
#7
Vi vi. Je sais tout ça :-) (et la suite, on met plus de trucs en espace utilisateur, comme FUSE).
Pas sûr que tu sois plus âgé que moi. Et pour info j’ai vu mon premier Linux en 1995, déjà avec X11. J’ai également tâché de modifier un peu un driver SCSI vers 1998, sinon j’ai fait de l’assembleur 6502 sur C64, jeunot toi-même :-P .
#7.1
Si, j’ai à peu près 10 ans de plus que toi, on a déjà abordé le sujet.
J’ai fait de l’assembleur 6502 en 1981 sur mon Atom Acorn puis en 1982 en école d’ingé avec assemblage à la main en entrant le code avec un clavier hexadécimal, puis j’ai géré toute une famille de produits au niveau logiciel en assembleur 6502 (un petit peu modifié en fait, il y avait quelques instructions en plus). Donc, le 6502, j’ai pratiqué.
Il n’ y a que pour Linux que tu y as touché avant moi. J’ai attendu 1998.
#7.2
Je ne sais pas si ça te fait ça, mais la plupart des lecteurs ont un âge intemporel pour moi, sauf ceux qui, selon ce que m’évoque leur attitude et discours, semblent plutôt jeunes (25-30 ans ou moins). Bon, après, l’ignorance de certaines choses basiques n’est pas l’apanage de la jeunesse, j’ai au moins un camarade de lycée comme ça.
#7.3
#8
Bof, si t’as pas de soucis avec l’existant et que tu n’a pas besoin des nouveautés du dernier noyau en date ni de ses ajouts de nouveau supports matériel je ne vois pas vraiment d’urgence à upgrader son noyau, hors découverte de bug critique bien entendu.
#9
Tu oublies les correctifs de sécurité (on trouve des dizaines de failles tous les jours). D’ailleurs, même les noyaux LTS continuent d’être mis à jour en fonction de ça.
Bien sûr, que sur mes PC de 2009, j’ai pas besoin des nouvelles fonctions (ils ont même pas d’USB 3.0 !). Mais les correctifs (et les améliorations sur les fonctions déjà existantes, tant qu’à faire), c’est malheureusement pas négociable.
Et accessoirement, j’avais vu juste : ce matin, j’ai eu le 5.19.13 à installer sur mon ordi (la 6.0.0 est dans le canal Testing, mais je ne suis pas dessus).
#10
Perso je classe les failles de sécu comme bugs critique, pour ça que j’avais précisé ce cas de figure ;-)
Après ça n’implique généralement pas un saut de version majeure, la plupart du temps on reste dans la même branche/sous branche ce que je ne considère pas comme un upgrade à proprement parler, j’aurais dû le préciser.
D’ailleurs à ce propos je me suis remis à Linux il y a une petite année après l’avoir perdu de vue pendant pas mal de temps et dans mes souvenirs les versions impaires étaient les versions “testing” et les versions paires les “stables”, aujourd’hui ça semble ne plus avoir la moindre importance (par exemple il y a un paquet d’années il aurait été impensable de voir une 5.15 qualifiée de LTS, ça aurait été la 5.14 ou la 5.16 mais jamais la 5.15)
#11
Oui, un paquet d’années, ça a changé avec la version 2.6 fin 2003.
#11.1
Putain le coup de vieux là …
Tu pourrais prévenir avant de cogner aussi fort
#12
J’ajoute qu’en plus de limiter désormais la numérotation au nombre de doigts (mains et pieds) qu’il a, Linus a décidé que les versions LTS seraient annuelles, et que ce serait la branche stable en cours au 1er janvier qui serait choisie pour devenir la LTS suivante. Fin décembre 2020, on était à la version 5.15.x. Pendant longtemps, ça tournait de 5 en 5 : 4.4, 4.9, 4.14, 4.19, 5.4, mais c’est passé ensuite à 5.10, puis 5.15, et il y a des chances que ce soit l’actuelle branche 6.0 qui sera la prochaine branche LTS.
C’est pour ça que dans le schéma de numérotation x.y.z, y et z ne vont jamais dépasser 20 (quand ils l’atteignent… Il y a eu une 4.20, mais pas de 3.20 ni de 5.20 ; et z va lui-même rarement au-delà de 12 ou 13 avant qu’y ne soit incrémenté).
#13