Quel que soit le domaine, hormis pour l’instant les PC traditionnels, Linux est en train de gagner des parts de marché. Sur les très grands systèmes HPC, c’est un véritable monopole, mais sur les serveurs c’est la même chose, si ce n’est curieusement sur les serveurs de grande puissance où Unix joue encore un rôle important. Quant aux mobiles, 90 % des machines sont motorisées avec Linux, essentiellement via Android.

La position de Linux est incontestable et le moment est sans doute venu en 2018, de nous intéresser aux internes de ce système, de comprendre comment il est mis à jour et « essayer » de s’y retrouver dans sa numérotation. Avec la distinction qu’il faut faire entre les distributions et le noyau.

Le rôle de Linus Torvalds

Linux est sans doute le seul système d’exploitation au monde, hormis les OS confidentiels qui ne dépassent pas les limites du garage de leur concepteur, qui soit non pas géré, mais « dominé » par un seul homme et non pas une communauté, en l’occurrence le finlandais d’origine, Linus Torvalds, qui en 2018, continue de faire la pluie et le beau temps et décide de ce qui est bon et mauvais pour son cher Linux. Une situation très étonnante, en totale rupture avec les systèmes propriétaires, mais aussi avec les communautés Open Source, qui se fondent sur le dialogue pour faire avancer leurs idées. Les membres de l’équipe chargée du noyau Linux, vous diront évidemment le contraire, mais il suffit d’écouter Linus Torvalds et les commentaires des très bons développeurs qui travaillent avec lui, pour en déduire que l’on n’est pas ici dans un modèle de démocratie.

Distributions et noyau Linux

La multitude de distributions Linux s’explique par l’architecture même du système, conçue dès le départ par Linus Torvalds de manière modulaire, pour ne pas tomber dans le piège des gros blocs monolithiques, tels que Windows.

En gros, il y a trois grands composants : le noyau (kernel), la distribution, qui comporte des éléments système qui ne sont pas pris en charge par le noyau et qui le personnalisent, par exemple, pour un usage donné, mobiles, HPC, etc et au-dessus de ces deux briques de base, les applications clientes.

Ce qui nous intéresse ici c’est de bien faire la distinction entre le noyau et les distributions.

Par principe, le noyau est la couche fondamentale et partagée de toutes les distributions, chargée de l’ordonnancement des tâches à exécuter (scheduling), de l’allocation mémoire, des drivers pour fonctionner sur diverses architectures x86 32 bits, x86 64 bits, ARM, RISC, etc. On le pilote par une interface clavier CLI (Command Line Interface), bien que les distributions proposent souvent une interface graphique, qu’aucun « linuxien » digne de ce nom, ne voudra utiliser…

A noter que le kernel s’exécute dans un espace mémoire protégé, de manière à éviter les interventions inadéquates des applications.

Quant aux distributions, il faut les considérer comme des OS complets, qui ajoutent au noyau, des modules supplémentaires, tels que des drivers, des librairies partagées, des démons système (des process qui s’exécutent en arrière-plan, sans contrôle du noyau), des modules spécifiques réseaux, etc. La distribution est le produit final, celui que l’on trouve dans nos machines. Et c’est à elle que les utilisateurs ont affaire, pas au noyau.

Il y a là deux possibilités. Si le noyau convient aux développeurs d’une distribution, ils le prennent tel quel. Si ce n’est pas le cas, ils peuvent le personnaliser et le recompiler. On voit bien que l’on n’est pas chez Microsoft. Cela dit, cette modularité du noyau ne s’est pas faite en un jour et Linus Torvalds s’y est longtemps opposé, arguant qu’elle nuisait aux performances du système.  

Il y aura ensuite de très nombreuses possibilités. Une distribution pourra par exemple se caler sur une version du noyau et ne pas la changer pendant des années ou au contraire suivre un rythme de mise à jour proche de celui du noyau, pour bénéficier des correctifs que les mainteneurs lui apportent. Là est toute la question, qui nous amène à regarder de près comment les mises à jour kernel sont effectuées et comment elles sont numérotées. Sachant que l’écosystème « noyau », c’est 4 300 développeurs qui participent dans le monde, issus de plus de 500 entreprises (parfois concurrentes) et qu’en 2017, il y a eu 5 releases du noyau comportant chacune entre 12 000 et 14 500 modifications, l’équipe centrale validant en moyenne 8,5 changements par heure…

Imaginez maintenant que vous ayez développé une distribution Linux (c’est peut-être le cas), vous devez donc adopter votre politique vis-à-vis de ce noyau, car vous n’allez pas pouvoir suivre le rythme.

La numérotation des versions noyau

Dans son excellent blog, Greg Kroah-Hartman, l’un des principaux mainteneurs du noyau, rappelle l’historique de cette numérotation. Et décrit celle qui a cours aujourd’hui, à laquelle, à vrai dire, personne ne comprend plus rien…

Sans remonter aux années 2003 où ce système trouve ses origines, avec la version 2.6.x du noyau, depuis 2005, l’équipe des mainteneurs applique une méthode différente.

En gros, il va y avoir ce que l’on peut appeler des générations, c’est-à-dire des versions très importantes du noyau, celles qui lui font franchir un cap important. Et c’est Linus qui décide…

En 2011, on est passé à 3.x (qui a succédé à la 2.6.39), puis en avril 2015 à la 4.x et on attend la 5.x en 2018. Ce sont des changements de releases majeures.

Le « x » correspond à une release stable du noyau : 4.9, par exemple, qui jalonne la vie des releases majeures précédentes. Avec une nouvelle release tous les 2 ou 3 mois, décidée encore par Linus Torvalds. Vous nous suivez toujours ?

Chacune de ces releases appartenant à la même release majeure, vont donner lieu à des mises à jour, qui seront étiquetées « stables » : 4.9.1, 4.9.2, 4.9.2, etc, chacune d’elles étant confiée à un développeur unique, dont la tâche sera d’intégrer les patchs disponibles. Ces releases stables perdureront jusqu’à ce que Linus décide de passer à une autre release. De 4.x à 4.y, par exemple, les mainteneurs sur 4.x devant obligatoirement passer à la nouvelle version 4.y.

Depuis 2005, cette pratique a posé des problèmes, car certaines distributions ont fait valoir qu’elles avaient besoin de s’appuyer sur une même release pendant plus de 2 à 3 mois, une durée jugée insuffisante.

C’est comme cela qu’est né le concept de release LTS (Long-Term Stable) kernel, la première d’entre elles ayant été la 2.6.16 en 2006, une version du noyau proposée à un rythme annuel, l’équipe Torvalds, assurant cependant la maintenance pendant 2 ans.

Les versions courantes LTS du noyau sont aujourd’hui les 4.4, 4.9 et 4.14.

En fait, une LTS est une version dont les fonctionnalités sont gelées et qui n’acceptent que des correctifs de sécurité ou des corrections de bugs. L’avantage d’une telle version est évidemment qu’elle stabilise les distributions, mais elle a aussi l’inconvénient de les bloquer fonctionnellement pendant de longs mois, autrement que pour corriger les anomalies. Paradoxalement on est exactement dans le mode tant décrié de Windows et des logiciels propriétaires.

Si on se résume, après avoir pris quelques cachets d’aspirine, on a donc deux modèles.

Un modèle avec des releases stables tous les 2 à 3 mois et des releases complémentaires « mineures » pour chacune d’elles et un modèle LTS avec une nouvelle release tous les ans et une maintenance sur 2 ans et là encore avec des releases qui vont venir se greffer, pour prendre en compte les évènements courants.

Dans la pratique, Greg Kroah-Hartman indique que 9 ou 10 patchs sont acceptés chaque jour pour les LTS et 10 à 15 pour les autres.

Quant aux choix des LTS, après avoir été quelque peu aléatoire au début, qui a surtout donné trop de versions LTS dans une même année, le processus est devenu plus rigoureux, tout en restant quelque peu opaque pour les non-initiés.

On est donc bien sur deux cycles de fonctionnement différents, mais qu’il est essentiel d’avoir bien assimilé pour comprendre la stratégie des éditeurs de distributions. D’un côté un cycle très court et dynamique et de l’autre un cycle plus long et plus rassurant.

Très récemment, Greg Kroah-Hartman a indiqué que les versions LTS bénéficieraient désormais d’un support étendu à 6 ans. Il répondait en cela aux demandes exprimées (entre autres) par les éditeurs de distributions Linux du monde mobile, qui avaient besoin de plus de visibilité, compte tenu des parcs d’utilisateurs qu’ils pratiquent et des opérations très complexes et risquées de mises à jour.

C’est ainsi que le kernel LTS 4.9 de Greg Kroah-Hartman sera maintenu jusqu’en janvier 2019 et que la toute dernière version du même Greg, la 4.14, sera maintenue jusqu’en janvier 2020.

La situation en 2018

Une nouvelle release majeure est prévue pour l’été 2018, la 5.x. Linus a déjà prévenu que ce ne serait pas une release révolutionnaire, ce qui semble en contradiction avec le principe même d’une release majeure. Mais il ne faut plus s’étonner de rien…Linus Torvalds rappelant à ce sujet que le « 5 » n’est qu’un chiffre et qu’il ne témoigne pas nécessairement d’un changement de millénaire…

On aimerait bien savoir, alors, sur quels critères il se fonde pour abandonner la filière 4.X.Y et passer à la 5.X.

Il fonde par ailleurs son point de vue, sur un constat évident et que nous partageons. Quand vous arrivez à des numéros de release élevés, cela n’a plus beaucoup de sens, car les grands nombres ne vous évoquent plus rien. Alors que l’on est plus à l’aise avec des chiffres plus petits, jusqu’à 13 ou 14. C’est la raison pour laquelle il n’y aura pas de 4.20, mais bien une 5.0.

Les adeptes de la gestion de projet Scrum ne seront pas étonnés, qui pratiquent la même idée quand ils trafiquent la suite de Fibonacci pour les grandes valeurs du « poker gaming », qu’ils réduisent à 3 ou 4 niveaux d’évaluation. C’est exactement la même chose.