Il y a quelques jours – au moment où je rédige ce billet, le 23 septembre 2023 – une annonce a été faite : les nouveaux noyaux LTS seront désormais supportés 2 ans au lieu de 6. Il y a un excellent article sur zdnet concernant ce sujet.
Loin de moi l’idée de plagier l’article, mais je vais apporter mon point de vue, celui du linuxien lambda. Au moment où je rédige cet article, voici la liste des noyaux LTS supportés, dixit kernel.org.
- Linux 6.1.55. On le trouve dans Debian GNU/Linux 12, alias Bookworm
- Linux 5.15.133. On le trouve dans Ubuntu 22.04.x LTS
- Linux 5.10.197. On le trouve dans Debian GNU/Linux 11, alias Bullseye
- Linux 5.4.257. On le trouve dans Ubuntu 20.04.x LTS
- Linux 4.19.295. On le trouve dans Debian GNU/Linux 10, alias Buster
- Linux 4.14.326.
La preuve en image.
Vous noterez que je ne cite aucune version de la RedHat Enterprise Linux. Et pour cause. Aucune des versions supportées n’utilise de noyau linux LTS. Cf la page anglophone de wikipedia pour plus d’informations.
Nous avons donc 6 noyaux long terme supportés en parallèle. On peut dire 7 en comptant le dernier noyau disponible de l’année 2023 qui sera automatiquement le prochain LTS, donc sauf contre ordre, le noyau Linux 6.6.
Je ne connais aucune distribution qui supportent tous les LTS. Même Manjaro qui supporte une sacrée tripotée de noyaux – dont certains en temps réel – ne propose plus que les noyaux LTS à compter du 4.19. Source ? L’annonce du 18 septembre 2023 sur les mises à jour arrivées.
Je comprends parfaitement que ce doit être une charge énorme que de supporter autant de noyaux en simultané. Je dois dire que je m’attendais à une annonce de la réduction de la durée de vie des noyaux LTS bien avant que cela arrive.
Entre la quantité et la qualité, je préfère la deuxième. Mieux vaut avoir moins de noyaux mieux maintenus qu’une pléthore qui sera soutenu comme la corde soutient le pendu. Ce n’est bien entendu que l’avis d’un linuxien lambda qui a suffisamment roulé sa bosse dans le dou(céreu)x monde du libre pour oser l’ouvrir sans craindre de me prendre une injection familière de me taire.
Voila moi je suis sous Debian, la version est la « 6.4.0-4-amd64 » sans doute puisque je suis la version Sid, donc il y a de fortes chances que mon kernel soit jamais en LTS ?
Alors comme cela tu te fais des « injections familières de me taire », mais tu sais quand même que la drogue c’est de la merde 🙂
A pluche.
Tu auras le noyau LTS quand il arrivera en tant que tel sur Debian unstable. Ce sera un noyau temporaire, qui sera remplacé le court terme suivant quand il pointer le bout de ses octets.
Qui utilise un noyau en production en lts hors RHEL, Debian, ubuntu, Suse … personne 🙂
C’est tout a fait normal de réduire le temps de support.
Mis à part pour quelques cas particuliers qui ont besoin d’une stabilité absolue, j’ai toujours eu mal à comprendre pourquoi autant de noyaux pouvaient être entretenus aussi longtemps. En presque 18 ans de mono-boot Linux, aucune mise à jour de noyau, LTS ou pas, ne m’a jamais mis dans la mouise en termes de support matériel ou logiciel. Il était évident qu’une rationalisation arriverait un jour ou l’autre, et je préfère également la qualité à la quantité.
J’ai eu un peu moins de chance. À l’époque du noyau linux 4.9, j’ai eu une régression sur mon orfinateur portable. Et plus récemment, j’ai eu un problème avec les UUIDs de mes supports de stockage qui n’étaient plus reconnus.
En gros, deux emmerdes vraiment chiantes depuis 2006, je ne vais pas me plaindre 🙂
L’article de ZDnet explique bien que tout cela est une conséquence du manque de bras pour maintenir tout ce bazar. AMHA c’est le truc le plus important que devrait nous inquiéter tous. Car par le passé visiblement on y arrivait encore.
Salut,
Je comprend bien le pourquoi de cette annonce, car j imagine bien que trouver des mainteneurs est tres difficile car il faut des gars hyper competents qui acceptent de faire un boulot ingrat et en plus, comme dit lors de la conference, de maniere benevole car les entreprises ne jouent pas le jeux.
Cela ne changera rien pour des particuliers car en cas de soucis remonter quelques machines n’est pas un soucis.
En revanche pour les professionnels ca pourrait etre une autre paire de manches. Il doit y avoir pas mal mecs qui commencent à suer à grosse gouttes en ce demandant s ils arrivent bien à cerner ce que cela va impliquer reellement.
Pas vraiment.
Ça fait assez longtemps maintenant que les distros « pro » comme RHEL et SLE
entretiennent leur propre kernel en ne prenant pas pour base un kernel LTS
officiel de kernel.org
Actuellement, RHEL 9 et SLE 15.5 ont un 5.14 qu’ils gèrent eux-même. Et ils ne
font pas que du rétroportage pour failles de sécurité ou correction de bugs. Ils
en font également pour des nouvelles fonctionnalités ou support de nouveau matériel. Ce que ne fait pas kernel.org.
RHEL 8 c’est un 4.18 et c’est la même chose.
Ubuntu utilise des LTS officiels. Mais à l’époque de la sortie de Debian 8, il y avait eu un accord avec Debian pour « entretenir » le kernel 3.16 qui au début n’était pas un LTS officiel. Il ne l’est devenu qu’après. Donc s’ils le veulent …
Oui, je ne pense pas que pour des distrib comme REHL cela soit un soucis, par contre je ne sais pas pour debian ou pour les « successeurs » de centos car je ne suis plus les ativités de ces distribs.
Pour CentOS, c’est devenu une version de test Red Hat. Aucun soucis pour eux.
Pour Debian, oui, je pense que ça peut poser un soucis. Ils n’ont ni les moyens ni les mainteneurs qu’ils faut pour procéder comme Red Hat et SUSE.
Sauf, peut-être, à demander de l’aide chez Canonical qui est capable de le faire.
C’est une bonne chose.
Cela va-t-il libérer des ressource au profit de l’inovation?
Ce serait une chose encore meilleure….
Comme le dit l’article de ZdNet, c’est une histoire de main d’oeuvre disponible et par voie de conséquence à rémunérer vu le travail à accomplir en permanence, donc qu’une major de Linux maintienne son propre noyau aux frais de ses salariés c’est logique et c’est aussi rassurant même si on s’écarte de la logique communautaire.
Ensuite, passer de 5/6 ans à 2 ans pour du LTS c’est du foutage de gueule, il vaut mieux réduire les versions LTS officielles et les maintenir a minima 4 ou 5 ans pour ceux (professionnels et particuliers) qui préfèrent ou ont besoin de stabilité à moyen terme, on ne peut pas leur imposer un saut de l’ange tous les 2 ans, notamment pour ceux qui compilent un kernel personnalisé pour des raisons spécifiques.
« Passer de 5/6 ans à 2 ans pour du LTS c’est du foutage de gueule, il vaut mieux réduire les versions LTS officielles et les maintenir a minima 4 ou 5 ans pour ceux (professionnels et particuliers) qui préfèrent ou ont besoin de stabilité à moyen terme, on ne peut pas leur imposer un saut de l’ange tous les 2 ans »
→ L’ennui, c’est qu’il y a un nouveau noyau LTS tous les ans. Réduire la maintenance à deux ans permet de n’en garder que deux ou trois maximum. Les maintenir 5 ans, c’est justement la situation actuelle où ils se retrouvent avec 6 noyaux LTS à gérer simultanément, ce qui n’est plus gérable pour eux dans les conditions actuelles.
Début janvier 2024, ils seront encore à 6, mais ce sera plus maintenable, il ne restera qu’un noyau de la génération 4.xx qui sautera en décembre 2024.
Donc, pour voir un peu baisser le nombre de noyaux LTS, ce sera pas avant décembre 2026 avec les fins de vie des noyaux 5.4 puis 5.10.
Autant dire que ce sera encore bien chiant pour les mainteneurs durant près de 3 ans 🙁
cela a d’autre conséquences si les noyaux 6.x ont une durée de vie de 2 à 3 ans ,
dans le cas de mobile androidos , il faut aussi penser à montée de version ….
et dans cette situation , très peu de fabricants actuellement permettent de faire une montée de version SANS qu’il y ait de la casse ….
cela va donc s’appliquer a tout nouvelle architecture/plateforme/cpu requerant uniquement les versions 6.x