Actuellement, il existe six versions LTS, de la 4.14 à la 6.1 mises en ligne entre fin 2017 et 2022. La fin de vie de la 4.14 est programmée pour janvier 2024, tandis que la 6.1 devrait être maintenue jusqu’en décembre 2026.
La question du pourquoi limiter à deux ans trouve une réponse auprès de Jonathan Corbet, comme le rapporte ZDNet.com : « Il n'y a vraiment aucun intérêt à les maintenir aussi longtemps parce que les gens ne les utilisent pas ». Une annonce faite durant l’Open Source Summit Europe.
Autre point important : « les mainteneurs de code Linux sont en train de s'épuiser », précisent nos confrères. « Cela ne peut pas durer, nous avons besoin d'aide », explique Darrick Wong.
Commentaires (35)
#1
Du coup, est-ce que synology va revoir sa politique de gestion de mise à jour du noyau au sein de ses NAS ?
J’avoue que je ne serais pas contre. J’envisage d’utiliser Wireguard sur mon NAS, mais pour l’instant, je ne peux pas sans grosse bidouille à cause de ça
#1.1
J’attends la même chose
une MAJ des kernel dans les Synology pour wireguard ;)
#2
Le soucis de départ c’est pourquoi autant de LTS en parallèle ?
Qu’il y ai un nouveau LTS en cas de grosse évolution technique ou de support matériel ok mais là j’ai l’impression qu’on fait du LTS pour faire du LTS et ça disperse pour pas grand chose les forces des mainteneurs (effectivement qui utilise encore aujourd’hui un noyau V4 ? Peut être quelques vieux serveurs opérés par des gens qui ne veulent pas / ne savent pas faire l’entretient mais ça doit pas faire lourd en nombre)
#3
Deux ans c’est pas énorme, il ferait mieux de réduire le nombre LTS, une tout les deux ans par ex.
#4
Le vrai problème est pour android. Pour répéter ce que j’ai appris via Ars Technica, il faut à peu près deux ans entre le moment ou une version du noyau est figée pour le développement d’un nouveau smartphone et sa sortie sur le marché. Figée parce que cette version est forkée et adaptée plusieurs fois dans le processus de développement.
Donc, ça va nous faire des téléphone qui arrivent sur le marché avec des noyaux qui ne seront déjà plus officiellement supportés. Histoire d’en rajouter au bordel sécuritaire provoqué par les modèles de développement et de commercialisation d’Android.
#4.1
C’est pas très grave en soi puique les grosses boites type google, RH ou Canonical ont largement les reins pour maintenir leur propre sous-version de noyau, c’est d’ailleurs ce qu’ils font déjà en backportant nombre de commits en tout genre et c’est aussi pour ça que les clients paient.
Un noyau Rhel 7 3.10.0-XXX actuellement toujours supporté par RH est déjà bien différent de ce qu’est 3.10.0 dans sa dernière version upstream.
#5
Une question que je me pose : est-ce que Google va enfin se décider à utiliser autre chose qu’un noyau 4.19 sur Android (même version 13+) ?
#5.1
J’imagine que le kernel, même si basé sur une version 4.19, a beaucoup divergé avec le temps et que passer sur une version plus récente demande des efforts conséquents, voire une réécriture complète (pour y intégrer les besoin spécifiques) ?
#6
Si c’est vraiment un problème, une boite comme gogole doit bien pouvoir allouer quelques ressources aux noyaux LTS, non?
Sinon, il est tout à fait possible de la jouer à la Red-Hat qui non seulement maintiens des noyaux bien plus longtemps que les LTS et l’a fait bien avant qu’ils n’existent, mais en prime porte le support des nouveaux matos introduits dans les noyaux récents vers les anciens qu’ils maintiennent: Comme les driver-model changent quand cela devient nécessaire, là c’est vraiment un gros boulot qu’ils font afin de pouvoir coller une distribution homogène sur des matériels passés et à venir.
Si RH y arrive, gogole devrait le pouvoir.
#7
…. Et que les constructeurs s’abstiennent bien de jouer le jeu de l’upstreaming de tous leurs drivers proprio.
Si ils le faisaient, alors ce serait aux mainteneurs qui introduisent des changements d’API incompatibles de patcher tous les drivers concernés…
Du coup tous les téléphones pourraient sans souci passer de version en version.
Au lieu de quoi, là on a une partition vendor avec non seulement des firmwares (ça, encore), mais surtout des drivers kernel , donc potentiellement incompatible ad vitam eternam vu que ces drivers proprio ne sont ensuite jamais maintenus …
(D’ou le verouillage sur 4.19, et j’ai vu du 5 plus récemment mais jamais de 6 encore)
#8
On t’a répondu pour Android, j’y ajoute ceci : demande-toi sur quelles versions de Linux tournent les plus anciennes versions des distributions fixed release encore maintenues par leurs éditeurs respectifs à ce jour.
RHEL, avec son cycle de prise en charge de 10, voire 13 ans, doit facilement détenir le record. Sous quel Linux tourne RHEL 7, sortie en 2014 ? Linux 3.10, lui-même sorti fin juin 2013. Mais IBM-Red Hat fait sa propre maintenance en rétroportant les correctifs, même si ça fait longtemps que la branche 3.10 est abandonnée en amont. J’imagine que ça ne va donc pas affecter grand-monde, si les éditeurs assument et assurent la maintenance de leur côté, si ça ne les pousse pas à revoir eux aussi leurs politiques de prise en charge.
#9
Des serveur encore en RHEL 8, j’en connais un paquet.
#10
Des SAN, des serveurs BDD, … D’un autre côté s’il ne fallait pas réécrire à chaque fois les pilotes sous Linux, ça serait plus simple.
Mine de rien, sous Windows les pilotes ne sont pas un gros soucis: Windows 11 peut installer des pilotes de Vista. Et en a d’ailleurs toute une partie.
#10.1
Heu ouais faut le dire vite, les constructeurs souvent ne garantissent les pilotes que pour un OS donné et j’ai vu récemment des gens tenter d’utiliser un driver prévu pour W10 sur du 11 et il y a eu des bugs en tout genre.
Un pilote qui marche à travers la version de windows ça peut arriver mais c’est plus de l’ordre de l’exception que de la normale en plus d’être rarement supporté.
#11
D’accord avec la première partie.
Mais pour Windows, il y a quand eu quelques grosses ruptures dans le temps.
Témoin l’imprimante en parfait état qui reste dans un tiroir parce qu’inutilisable,
souvenir du passage à Vista.
Mais je reconnais que ça fait un bail.
#12
Punaise, c’est surtout le monde de l’embarqué qui va morfler.
Quand le portage d’un kernel pour un SoC est entamé, il peut bien se passer du temps avant que le SoC ne soit dispo sur le marché. Ce qui fait que le moindre système embarqué commence d’office avec un vieux noyaux. Et à peine le développement du système est terminé qu’il faut tout mettre à jour ? Super.
C’est aussi pour ça qu’android tourne souvent avec des kernel des temps anciens. Sans oublié la multitude de routeur/appareil connecté.
Rien qu’openwrt a eu du mal à passer au kernel 5.15 parce qu’il y avait vraiment du matériel ou tout était à refaire… J’image mal les voir passer d’un coup au 6.2
Bref, c’est peut être une bonne chose pour les développeur kernel sur PC, mais pour les systèmes embarqués cela veut dire plus de monde pour faire des backports, et moins de monde pour le développement des fonctionnalités ou des optimisations…
J’ai tellement hâte d’avoir un android qui rame avec 64GB de RAM tout ça parce que les développeurs n’ont pas eu le temps d’optimiser leur code pour pouvoir supporter le kernel 6.14…
#13
Le rythme c’est de dédier une version en mode LTS par an. Le plus souvent fin d’année/début d’année suivante. C’est pour ça que les EOL sont aussi calibré sur les fin/début d’année. Ce n’est pas la première fois qu’ils tentent le coup de limiter une LTS sur 2 ans. (la version 5.15 je crois était annoncé sur cette limite avant d’être étendue).
Le problème posé de façon récurrente dans le développement du noyau c’est le manque de mainteneur. Ils ont du monde pour implémenter des nouveaux trucs, mais bien moins de personne pour ces tâches de fond qui semblent manquer d’attractivité.
#14
C’est vrai que 6 versions LTS ça commence à faire, peut être que de conserver une ligne d’un seul LTS, et de 2-3 STS ça permettrait de mieux équilibrer la balance autour de l’implémentation - maintenabilité ? À voir… Ça en parle ici aussi…
#15
Les grands utilisateurs de LTS, ce sont Redhat, Ubuntu, Google. Il suffirait qu’ils mettent la main au portefeuille, et ce serait réglé.
#16
Vista était la rupture. Windows 10 en a fait une deuxième dans les pilotes graphiques (un monde particulier: sous Linux la moitié du pilote est dans le kernel)
C’est vrai que ce serait plus logique. Une grosse version tous les 6 ans, utilisable par l’embarqué et les systèmes fermés, ça ne paraît pas le bout du monde.
Par contre, une longévité de 6 ans, c’est limite nécessaire, sinon tout ce qui est basé sur linux deviendra en obsolescence sécurité programmée :)
#17
Je ne sais pas quelle est la solution mais c’est vrai que 6 noyaux LTS en même temps qu’il faut maintenir, je trouve que c’est énorme.
Cependant, je m’interroge sur ce qu’il va en être des serveurs avec des LTS de 2 ans.
Je pense qu’une LTS tous les 24 mois serait sûrement un bon rythme. Et peut être qu’une version plus long terme (10 ans) toutes les 3 versions LTS donc tous les 6 ans et maintenue conjointement par les grosses entreprises qui patchent déjà les noyaux pour ces durées serait peut être une solution. Les entreprises dont je parle sont Cannonical, RedHat, Oracle, Google, etc. En gros, toutes les entreprises qui patchent déjà les noyaux de leur coté, autant réunir les forces de travail pour faire des patchs en commun même si ensuite, chacun y va de son petit ajout perso.
#18
Il sort une nouvelle version majeure du noyau Linux tous les deux mois (6.4 en juin, 6.5 en août, 6.6 probablement en octobre ou novembre), et ce rythme s’est accéléré depuis août 2018. Clairement, même pour la branche LTS, rester sur des noyaux vieux de plusieurs années devient de moins en moins viable. Tant pis pour les distributions qui croient encore qu’elles peuvent rester 10 ans (ou même simplement 6 mois) sur les mêmes versions de paquets, et de noyau, qu’à leur sortie (sachant que souvent, ces paquets sont déjà obsolètes en amont quand la distro sort) ; même si elles essaient de compenser en rétroportant les correctifs de sécurité : elles vont devoir s’adapter, et au minimum changer leur manière d’être.
#19
A quoi correspond ce type de fonctionnement si ce n’est une rolling release ? 6 mois… c’est le temps que j’ai passé sous Arch Linux, parce qu’en lançant une mise à jour par semaine j’avais la quasi-totalité des paquets du système qui étaient concernés ; notamment l’ensemble Qt/Plasma/KDE. C’était lourd. Et il fallait régulièrement corriger manuellement des trucs qui passaient pas à cause des incompatibilités introduites par les nouvelles versions. Ca m’a lassé et j’ai quitté.
J’aime bien cette idée d’avoir un environnement qui n’est pas bousculé tous les 4 matins. Je ne pense pas être le seul. J’ai beaucoup utilisé Debian parce que ça correspondait à cette idée. Le seul défaut, c’est qu’à la fin… oui… on a hâte de la nouvelle majeur.
#20
C’est plutôt le contraire. C’est souvent supporté. Ce n’est pas pour rien qu’on pouvait encore utiliser des drivers pour XP sous Seven par exemple.
Maintenant, cela n’empêche pas Microsoft de mettre à jour les caractéristiques pour certains types de pilote. Si la portabilité se retrouvait assez aisément avec des pilotes de périphériques plug&play (souris, clavier, imprimante, etc.), des cartes d’acquisitions, etc… pour d’autre comme des cartes graphiques qui sont très liées au système, c’était très différent.
Les vieux drivers ne sont plus utilisables aujourd’hui car
#21
Comprend pas trop les débats dans les commentaires sur Android et les embarqués.
Le constructeurs qui vous sortent un device avec un noyau qui a déjà 2 ans, vous pouvez vous rincer pour qu’il fasse des mises à jour noyau derrière. Et quand il est en capacité de le faire il l’a modifié.
LTS ou pas ça n’a aucune importance, le device a 2 ans de retard de mise à jour notamment sécurité, c’est un fait qui existe avec ou sans support. Rien n’empêche le constructeur de mettre le noyau à jour avec sa compatibilité matérielle, mis à part le fait qu’il va sûrement pas mettre le budget pour des ingés pour des devices qu’il considère déjà être des déchets, ce qui est l’essence du problème.
#22
Pour les RH et cie ils prennent sur eux de maintenir les noyaux qu’ils utilisent sur le long terme et le faisaient d’ailleurs déjà avant l’apparition des LTS du coup ils n’ont pas vraiment besoin
Et ça n’enlève pas que maintenir 6 noyaux LTS en parallèle ça n’a pas beaucoup de sens (et comme dit dans l’article personne ou presque ne les utilise)
Pour Androïd pour moi c’est un des gros défaut structurel du truc : permettre à chacun de “propriétariser” le noyau Linux et la distrib qui l’accompagne est une énorme connerie.
Il faudrait au contraire standardiser au maximum le bouzin de façon à pouvoir mettre à jour avec une “distrib” centralisée et standardisée (ça règlerait de fait le problème des failles de sécurité non patchées par les constructeurs sur les modèles trop anciens à leur goût) quitte à ce qu’après chaque constructeur viennent rajouter ses softs et sa surcouche mais toujours en restant compatible avec l’OS de base.
Au lieu de ça on est parti sur un système merdique ou chaque chip/périphérique fonctionne grâce à un pilote proprio qui n’aura de support que pour une ou deux versions de l’OS obligeant à changer la machine complète si on veux rester à jour.
En plus bonjour le gaspillage de ressources à obliger les devs de chaque constructeurs à bosser chacun de leur coté pour développer exactement la même chose au lieu de bosser sur un tronc commun qu’il faudrait juste légèrement adapter.
#23
Si tu as apprécié la philosophie Arch mais que les mises à jour constantes et qui potentiellement cassent tout si tu ne les fait pas suffisamment régulièrement te saoule Manjaro est faite pour toi.
Les OS à bidouiller tous les jours pour espérer que ça marche j’ai donné avec Gentoo, aujourd’hui je veux une machine qui tourne sans soucis et si possible le plus à jour possible niveau versions de softs (donc exit les Debian, Mint, etc …) et pour l’instant je n’ai pas trouvé mieux que Manjaro pour avoir tout ça
#24
Juste pour clarifier: le noyau linux, c’est bien?
Ce qui est gênant dans Linux, c’est le lien fort kernel - pilotes, non? Quand on dit qu’un nouveau Linux sort, c’est bien tout le package qu’il faut back-porter, pilotes inclus?
Si on backporte uniquement les changements kernel/couches c’est moins compliqué?
Et d’un autre côté, quel est le problème de mette à jour le noyau? On peut jongler avec les noyaux au démarrage (5.10, 6.1 dans mon cas) sans avoir à réinstaller les softs autour, ça marche pareil.
Mon plus gros problème de mise à jour sous Linux, ça a commencé par le noyau (les nouveaux ayant droppé un des pilotes FC - pas possible de mettre à jour la distro), mais le plus gros écueil, c’était de recompiler tout le côté user (problème de compatibilité PHP + nouvelle libc pas compilable avec le gcc qu’on avait + chasse aux dernières version compilables - pas de chemin d’upgrade clair et sécurisé + compiler le nouveau gcc avec l’ancien gcc nécessitait de compiler une autre lib qu’on ne pouvait pas compiler avec notre gcc…)
On aurait pu garder le noyau et reconstruire tout au-dessus en partant de zéro, je pense que ça aurait marché (si on avait trouvé toutes les sources et eu un temps infini…).
Dans Android, le problème est différent car Android s’appuie sur des fonctionnalités du kernel. Sinon on compilerait Zygote sous Windows et on démarrerait le user space Android comme n’importe quelle appli Windows (en forçant le trait)
D’ailleurs, la couche de compatibilité Linux dans FreeBSD fonctionne toujours bien, ce qui montre que le noyau Linux n’est pas un élément incontournable?
#25
Je suis sur Arch depuis que j’ai renoué avec Linux en août 2014. Je fais les MAJ tous les matins, et je n’ai pas dû avoir à corriger manuellement plus de 10 fois après coup (sachant que si des opérations manuelles sont requises, celles-ci sont signalées soit par un message après l’installation de la MAJ, soit sur le site d’Arch).
Après, j’utilise XFCE, qui doit être moins pénible que Plasma.
Tout ce que je peux dire, c’est que sur Arch, tu peux avoir seulement le paquet du noyau à mettre à jour, le reste se fait tout seul. Et s’il y a des paquets supplémentaires à mettre à jour avec, ils sont proposés en même temps (comprendre : la MAJ du noyau n’est pas proposée tant que les autres paquets ne sont pas prêts aussi). Comme ça, tout est fait.
#26
C’est la raison qui m’a fait venir à debian pour mon ordi fixe : la stabilité dans le temps. Et c’est pour le défaut que je suis passé sous arch depuis 1 an et demi.
Par contre, je n’ai pas eu de soucis majeur sous arch, pas beaucoup plus que sous debian mais il est vrai aussi que je ‘ai pas envie de bidouiller ma machine, pour cela, j’ai les VM. A deux trois reprises, j’ai eu des manipulations à faire suite à des mises à jours mais le site d’arch est assez bien fait là dessus, même si perso, je préfèrerai n’avoir rien à faire
#27
Les mises à jour majeure de noyaux embarquent par exemple des améliorations au niveau des protocoles de base : couches 3, 4 ou 5.
Ou des correctifs compensant des défaut matériel (les récents trouvés chez Intel et Zenbleed pour AMD par exemples).
Si la première brique tarde à être mise à jour, ce qui se trame au-dessus ne peut pas l’être.
La logique “on ne touche pas tant que cela fonctionne” a aussi ses effets pervers qu’il faut comprendre & limiter.
Même si cela est toujours aussi inquiétant, rions un peu : https://xkcd.com/2347/
#28
Je n’ai jamais essayé Arch mais avec Gentoo si tu fais les mises à jour tous les jours effectivement t’as globalement pas trop de problème (à part bloquer la machine 3 plombes pour compiler les paquets mis à jour mais ça c’est le concept du truc).
Par contre si tu laisses passer plus d’une semaine entre 2 mises à jour là les problèmes commencent : tu as potentiellement sauté une version d’un paquet, du coup la compatibilité avec le reste peut devenir un problème parceque les contournements mis en place pour la version que tu as raté ne marchent pas forcément pareil pour la suivante et tu te retrouves à passer 3 pombes à éplucher les journaux et forums pour trouver des solutions, à masquer temporisement des paquets pour passer outre des dépendances circulaires, etc … bref tu passes plus de temps à bidouiller la machine qu’à utiliser.
C’est ce qui m’avait fait lâcher cette distrib et passer à Mint à l’époque : je voulais impérativement un système fiable sans prise de tête, et ce qui m’a fait ensuite lâcher Mnt pour Manjaro c’est que je voulais quand même des versions de logiciels un peu moins obsolètes (sur Mint beaucoup de paquets datent d’1 an ou plus, j’imagine faute de mainteneurs pour tout tenir à jour)
#29
Pour le coup même si Manjaro est une rolling release, je n’ai, à ce jour et après une paire d’années à utiliser la distrib, jamais eu de soucis quand une mise à jour n’a pas été faite depuis une certaine durée (genre un mois voire plus, typiquement je ne joue pas avec mon Pinephone tous les jours) par rapport au souci que tu évoques avec Gentoo.
Le principal souci que je rencontrais à un moment était le keyring des clés GPG qui faisait planter la validation des paquets et nécessitait une reconstruction de ce dernier car il se mettait pas à jour. Mais je n’ai pas observé ce comportement depuis longtemps, donc je pense qu’il a dû être réglé.
Bon, par contre une mise à jour à 900 paquets ça fait toujours son petit effet lors du prompt [y/n]
#30
En juillet et août, quand je passe la semaine dans mes quartiers d’été, le PC fixe de chez moi attend du lundi matin au vendredi soir que je les fasse, les MAJ. Et jusque-là, quand bien même il y a eu des grosses MAJ comme celles du noyau entretemps, ça n’a jamais posé de problème et les besoins d’intervenir manuellement pour bien faire passer une MAJ n’arrivent en vrai que deux fois par an maxi (et ça dépend aussi de quels paquets tu as installés). D’accord, mon expérience n’est rien de plus, mais pour utiliser Arch quotidiennement depuis maintenant 9 ans (et en OS principal depuis septembre 2015), je trouve pas que ce soit aussi fragile que tu le décris.
Après, je reste sur le canal Stable, je vais pas aller jouer à passer en Testing… Enfin, tu parles de « contournements », mais les paquets d’Arch sont aussi vanilla que possible. Donc, et à part ce qui est indiqué dans les news du site de la distro, c’est rare de devoir toucher à la config après une MAJ de paquet (encore que je le fais pour quelques-uns, comme Vivaldi, car chaque MAJ écrase mon choix de police d’UI par défaut depuis la sortie de l’actuelle version 6.2). Je dirais que c’est du cas par cas et faut voir de quels paquets tu parles.
#31
Je n’ai pas dit qu’il n’y avait pas de solution. C’est très loin d’être aussi simple que de dire “l’argent de Google règle tous les problèmes”, par contre.