Histoire du noyau Linux : les choix qui ont duré

Bref historique du noyau Linux

L’histoire du noyau Linux s’étend de la version 0.01, publiée en septembre 1991, à la série 7.x qui démarre aujourd’hui sur les serveurs. La liste des versions est la partie la moins intéressante. Quelques décisions ont défini son architecture, et chacune a encore des conséquences sur une machine que vous louez cet après-midi.

Les dates et les numéros de version indiqués ici proviennent de kernel.org et de l’historique des versions qu’il publie. État actuel, en août 2026 : la version 7.0 est sortie le 12 avril 2026, la version 7.1 le 14 juin 2026, et la version 7.2 est au stade des release candidates.

Pourquoi le choix de la GPL en 1992 reste important

La version 0.01 a été publiée le 17 septembre 1991 sous une licence que Torvalds avait écrite lui-même. Elle exigeait la distribution du code source et ajoutait une clause plus importante : « Vous ne pouvez pas distribuer ce logiciel contre rémunération, pas même pour couvrir les coûts de “manutention”. » En 1991, les logiciels étaient distribués sur des disquettes, et la copie ainsi que l’envoi de disquettes coûtaient de l’argent. Cette clause rendait impossible une distribution Linux commerciale.

Il a changé cette licence. Le passage à la GNU General Public License (GPL) a été annoncé dans les notes de version de la version 0.12 en janvier 1992 et a pris effet le 1 février 1992. La version 0.95, publiée en mars 1992, a été la première version distribuée sous cette licence. Toutes les entreprises qui se sont ensuite construites sur Linux reposent sur ce changement.

Le kernel est uniquement sous GPL version 2 et n’est jamais passé à la version 3. Torvalds l’a refusé en 2007, principalement à cause de la règle anti-tivoisation de la GPLv3, qui exige qu’un appareil distribuant du code GPL accepte également une version modifiée de ce code. Il considérait le matériel verrouillé comme une décision commerciale propre au fabricant. En 2017, les développeurs du kernel ont publié le Kernel Enforcement Statement, qui reprend malgré tout un élément de la GPLv3 : une personne qui corrige une violation après en avoir été informée conserve sa licence, au lieu de la perdre définitivement dès la première violation.

Deux conséquences s’appliquent à un serveur. Le binaire du kernel que vous démarrez vous donne le droit d’obtenir le code source correspondant. Personne ne peut donc vous fournir un kernel Linux que vous ne pourriez ni inspecter ni reconstruire. L’avis de copyright du kernel précise également que la licence ne couvre pas les programmes utilisateur qui utilisent les services du kernel au moyen d’appels système normaux. C’est pourquoi des bases de données propriétaires et des agents de monitoring sont distribués pour Linux sans enfreindre la licence. Une licence permissive crée la pression inverse, et cette différence mérite d’être comprise avant de choisir une plateforme : voir Linux et FreeBSD comme plateformes serveur.

Pourquoi le noyau monolithique s’est imposé en pratique

Le 29 janvier 1992, Andrew Tanenbaum a publié un message intitulé « LINUX is obsolete » dans le newsgroup comp.os.minix. Il avançait deux arguments. Les noyaux monolithiques, dans lesquels les pilotes et les systèmes de fichiers s’exécutent dans un même espace d’adressage privilégié, étaient une conception des années 1970. Les microkernels, dans lesquels ces composants s’exécutent comme des processus ordinaires, représentaient l’avenir. En outre, Linux était étroitement lié à l’Intel 386 et ne pourrait donc jamais être porté sur d’autres architectures.

L’argument de la portabilité a été réfuté par les portages. La version 1.2, publiée en mars 1995, a ajouté Alpha, SPARC et MIPS. La version 2.0, publiée en juin 1996, a ajouté un portage 64 bits pour Alpha.

L’argument lié à la conception a reçu une réponse pragmatique. Linux n’est jamais devenu un microkernel. Il a adopté les loadable kernel modules : des fichiers objets que vous pouvez insérer dans un noyau en fonctionnement, puis retirer, afin qu’un pilote soit fourni séparément du binaire du noyau.

lsmod | head
modinfo virtio_net | head -5

lsmod liste les modules actuellement chargés. modinfo affiche le fichier d’origine du module et les paramètres qu’il accepte. Sur un serveur virtuel, une grande partie de la pile de stockage et du réseau repose sur des modules. C’est pourquoi une même image de noyau peut démarrer sur du matériel qu’elle n’a jamais rencontré.

Les modules ont apporté cette flexibilité sans le coût du modèle microkernel. Isoler un pilote dans son propre processus impose un context switch et l’envoi d’un message à chaque appel. En 1992, ce coût était important.

Le coût conservé par Linux est celui dont il faut tenir compte : un module s’exécute avec tous les privilèges du noyau. Un module défectueux peut donc arrêter toute la machine, au lieu de ne faire tomber qu’un seul processus. Les out-of-tree modules posent particulièrement problème. Un pilote fourni par un éditeur qui ne fait pas partie du mainline doit être recompilé pour chaque nouveau noyau. C’est ce que fait DKMS lors d’une mise à niveau. Si cette compilation échoue, le périphérique est simplement absent après le redémarrage.

Pourquoi SMP a mis quinze ans à aboutir

Linux 2.0, en juin 1996, a été le premier kernel à prendre en charge le multiprocessing symétrique (SMP), c’est-à-dire l’exécution d’un même kernel sur plusieurs CPU. La première implémentation utilisait un verrou unique, le big kernel lock (BKL). Un seul processeur pouvait donc exécuter du code du kernel à la fois. Un deuxième CPU aidait ainsi une charge qui effectue ses calculs dans l’espace utilisateur, mais très peu une charge composée d’appels système, car ceux-ci étaient mis en attente derrière le même verrou.

La suppression de ce verrou a pris quinze ans. Les derniers utilisateurs ont été convertis au fine-grained locking, en grande partie par Arnd Bergmann, puis le BKL a été supprimé dans la version 2.6.39, publiée le 18 mai 2011. Le scheduler a évolué selon le même calendrier lent : le scheduler O(1) dans la version 2.6.0, le Completely Fair Scheduler (CFS) à partir de la version 2.6.23 en 2007, puis EEVDF, qui a remplacé CFS dans la version 6.6 en octobre 2023.

C’est grâce à ce travail qu’un plan avec 4 vCPU est devenu banal. Il montre aussi une limite qu’il faut connaître. Sur un serveur virtuel partagé, votre kernel planifie vos threads, tandis que l’hyperviseur planifie votre kernel. Exécutez top et lisez le champ %st. Le steal time correspond au temps CPU que votre kernel était prêt à utiliser, mais que l’hôte a attribué à un autre guest. Aucun réglage dans votre kernel ne permet donc de le récupérer.

Pourquoi la série 2.6 a changé la manière de construire le kernel

Avant 2.6, les numéros de version fonctionnaient par paires. Un deuxième numéro pair indiquait une série stable (2.4) ; un numéro impair indiquait une série de développement (2.5). 2.4 est sorti le 4 janvier 2001 et 2.6 le 17 décembre 2003. Les utilisateurs ont donc attendu près de trois ans pour la série stable suivante. Les distributions ne pouvaient pas attendre et ont donc effectué des backports. Deux fournisseurs distribuant tous deux « 2.4 » pouvaient fournir des kernels séparés par des milliers de patches.

La séparation a été abandonnée après 2.6. Le mainline ouvre maintenant une merge window d’environ deux semaines, accepte les nouveaux développements, puis publie des release candidates jusqu’à ce que le rythme se stabilise. Une nouvelle version sort ensuite toutes les 9 à 10 semaines, selon la cadence toujours documentée sur kernel.org. L’autre moitié du modèle est apparue le 4 mars 2005 avec la première version de la stable tree : une mise à jour limitée aux correctifs de 2.6.11, maintenue par Greg Kroah-Hartman et Chris Wright. La stable tree accepte les correctifs et refuse les fonctionnalités.

Un effet secondaire est que le numéro de version a cessé d’être une garantie. 3.0, 4.0, 5.0 et 7.0 ne sont pas des réécritures. Torvalds augmente le premier numéro lorsque le deuxième devient suffisamment élevé pour le gêner. C’est pourquoi 7.0 a suivi 6.19 en avril 2026. Pour un serveur, l’important est de savoir quelle branche votre distribution suit et si cette branche reçoit encore des correctifs.

Comment la rupture avec BitKeeper a donné naissance à git en avril 2005

À partir de février 2002, le noyau a été développé avec BitKeeper, un système de contrôle de version distribué propriétaire de l’entreprise BitMover, fondée par Larry McVoy, en commençant par la série 2.5. BitMover accordait une licence gratuite aux développeurs du noyau, avec certaines conditions : ils ne pouvaient pas travailler sur un outil de contrôle de version concurrent et ne pouvaient pas effectuer de rétro-ingénierie de BitKeeper. De nombreux développeurs n’appréciaient pas de développer un noyau libre avec un outil dont ils n’avaient pas le droit d’examiner le code.

La situation a éclaté en avril 2005, après qu’Andrew Tridgell a présenté un programme qui communiquait avec les dépôts BitKeeper. BitMover a considéré cela comme de la rétro-ingénierie et a retiré la licence gratuite. Le noyau a perdu son système de contrôle de version au milieu d’un cycle de développement.

Le développement de git a commencé le 3 avril 2005. Torvalds l’a annoncé le 6 avril. Le 7 avril, git était auto-hébergé : son propre historique était déjà conservé dans git. La première fusion de plusieurs branches a été effectuée le 18 avril. En juin 2005, git a géré la release de 2.6.12. Torvalds a rapidement confié la maintenance à Junio Hamano, puis est retourné au noyau.

La conception découle directement du problème : des milliers de contributeurs et des mainteneurs qui récupèrent les modifications les uns des autres sur un réseau auquel personne ne fait confiance. Chaque objet est nommé par le hash de son contenu. Modifier un seul octet de l’ancien historique modifie donc le nom de chaque commit qui le suit. C’est pourquoi un clone constitue une preuve et non une simple déclaration. Chaque pipeline de déploiement, chaque dépôt de configuration, l’hébergeur de code vers lequel la plupart des équipes poussent et le serveur git que vous pouvez exécuter vous-même sont issus d’un conflit de licence concernant un noyau.

Ce que garantit le modèle LTS, et ce qu’il ne garantit pas

La branche mainline n’est pas celle que vous utilisez en production. Une version mainline est remplacée 9 à 10 semaines plus tard. L’arbre stable reçoit des correctifs pendant quelques semaines après chaque version. Les branches longterm, généralement appelées LTS, en reçoivent pendant des années. Ce sont celles sur lesquelles les distributions basent leurs versions.

La version 2.6.32, publiée en décembre 2009, a confirmé la validité de ce modèle. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 et Ubuntu 10.04 LTS l’ont intégrée, et la branche a été maintenue jusqu’en février 2016, soit plus de six ans après sa publication.

La durée de maintenance a changé plusieurs fois. Elle était de deux ans, puis de six ans pour certaines branches. En 2023, les mainteneurs de stable ont ramené la durée par défaut à deux ans, car le backporting vers d’anciens arbres demande du temps aux mainteneurs et que les anciennes branches sont peu testées en conditions réelles. Le 25 février 2026, Greg Kroah-Hartman a de nouveau publié des projections plus longues, après des échanges avec les entreprises qui dépendent de ces branches. Le cadre actuel couvre une durée de trois à six ans.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

kernel.org répertorie 6 branches longterm en août 2026. La plus ancienne, 5.10, aura reçu des correctifs pendant 6.0 ans à sa fin, prévue en Dec 2026. La plus récente, 6.18, devrait être maintenue jusqu’en Dec 2028, soit 3.1 ans de correctifs.

Considérez ces dates comme une durée minimale, pas comme un engagement contractuel. Les projections des branches 6.6 et 6.12 ont toutes deux été prolongées en février 2026. À l’inverse, une branche que personne n’utilise peut être abandonnée plus tôt. Votre distribution fait généralement ce choix à votre place : Debian 13 fournit la version 6.12, tandis qu’Ubuntu 26.04 LTS fournit la version 7.0. Cet écart correspond concrètement à la question du choix entre LTS et version intermédiaire sur un serveur. C’est aussi ce qui change réellement sous-jacent lorsque vous mettez Ubuntu 24.04 à niveau vers 26.04.

Cela entraîne un piège. uname -r sur Ubuntu 24.04 affiche quelque chose comme 6.8.0-51-generic. Il s’agit d’une base upstream à laquelle la distribution ajoute ses propres backports. Le numéro indique donc l’origine de la branche, pas les correctifs qu’elle contient. Pour cette raison, les scanners qui évaluent un kernel à partir de sa chaîne de version signalent à tort des vulnérabilités sur les kernels des distributions.

Ce sur quoi le noyau débat actuellement

Deux débats sont en cours, et tous deux portent sur la personne ou le composant chargé du travail.

Rust a été intégré à l’infrastructure du noyau en 6.1, en décembre 2022. Dans 7.0, la mention expérimentale a été retirée. Les langages principaux du noyau sont donc C, l’assembleur et Rust, et la compilation ne nécessite plus de compilateur nightly. Le désaccord porte sur la maintenance. Un mainteneur C qui modifie une interface peut casser des bindings Rust qu’il ne lit pas. Le débat porte alors sur la responsabilité de les corriger.

Le second débat concerne les contributions produites avec l’aide de l’IA. Sasha Levin a proposé une politique en juillet 2025, après l’augmentation du nombre de patchs assistés par des machines envoyés sur les listes. Le document a été intégré le 23 décembre 2025 à la documentation des processus du noyau, à l’adresse docs.kernel.org/process/coding-assistants.html. Un agent d’IA ne doit pas ajouter de tag Signed-off-by, car cette ligne certifie le Developer Certificate of Origin (DCO), et seule une personne peut l’attester. L’assistance est déclarée avec un tag Assisted-by:, qui a remplacé Co-developed-by: pendant la revue, car un outil n’est pas un auteur. Le code généré doit être compatible avec GPL-2.0-only. La personne qui envoie le patch le relit et en assume la responsabilité.

La pression à l’origine de cette politique vient du temps nécessaire à la revue. Générer un patch prend quelques secondes, tandis que sa revue peut occuper l’après-midi d’un mainteneur. Un tag ne corrige pas ce déséquilibre. En revanche, il préserve la provenance : l’historique continue d’indiquer qui a signé chaque modification. C’est précisément cette propriété que le DCO a été créé pour protéger en 2004.

Ce que cet historique implique pour le serveur que vous louez

• La licence explique pourquoi vous pouvez consulter et reconstruire le kernel démarré par votre fournisseur, et pourquoi les logiciels propriétaires continuent de fonctionner dessus.
• La conception monolithique explique pourquoi un bug de driver redémarre toute la machine, et pourquoi un module out-of-tree doit être reconstruit à chaque mise à niveau du kernel.
• Le modèle de release explique pourquoi le numéro de version vous apprend peu de choses, tandis que la branche et sa date d’end-of-life vous renseignent presque entièrement.
• Le type de virtualisation détermine ce que vous pouvez faire : avec KVM, vous démarrez votre propre kernel et chargez des modules ; avec une virtualisation par conteneurs qui partage le kernel de l’hôte, uname -r affiche la version de l’hôte, modprobe échoue et plusieurs sysctl sont en lecture seule.

FAQ

Pourquoi le noyau Linux est-il toujours sous GPLv2 et non sous GPLv3 ?

Torvalds a refusé GPLv3 en 2007, principalement en raison de son exigence contre la tivoïsation, qui impose à un appareil distribuant du code GPL d’accepter également une version modifiée de ce code. Il considère que le verrouillage du matériel relève des choix commerciaux du fabricant. Un changement de licence est également presque impossible en pratique, car les droits d’auteur du noyau appartiennent à des milliers de contributeurs et aucun accord de cession ne permet de contourner ce problème. Le noyau est sous GPL-2.0-only : du code proposé uniquement sous GPLv3 ne peut donc pas être intégré.

Le noyau Linux est-il monolithique ou de type microkernel ?

Il est monolithique, avec des modules chargeables. Les pilotes et les systèmes de fichiers s’exécutent dans l’espace d’adressage du noyau, et lsmod affiche ceux qui sont actuellement chargés. Cela offre de meilleures performances, mais augmente aussi le rayon d’impact : un module défectueux peut provoquer un panic sur toute la machine, alors qu’un microkernel perdrait un seul processus. Cette distinction s’est toutefois atténuée depuis 1992 grâce aux systèmes de fichiers FUSE exécutés dans l’espace utilisateur et aux programmes eBPF que le noyau vérifie avant de les exécuter.

Quelle est la différence entre les noyaux mainline, stable et longterm ?

Mainline désigne l’arbre de Torvalds. Une version en sort toutes les 9 à 10 semaines et les nouvelles fonctionnalités y sont intégrées en premier. La branche stable part de la version mainline la plus récente et reçoit des corrections de bugs pendant quelques semaines. Les branches longterm continuent de recevoir des corrections pendant plusieurs années. C’est sur elles que les distributions basent leurs noyaux. kernel.org répertorie les branches longterm actuelles avec une date de fin de vie prévue pour chacune.

Le noyau Linux accepte-t-il du code écrit par une IA ?

Oui, conformément à une politique adoptée en décembre 2025. L’outil doit être indiqué dans une balise Assisted-by:, un agent IA ne doit pas ajouter de ligne Signed-off-by, et le code généré doit être compatible avec GPL-2.0-only. Le contributeur humain signe la soumission. Cela signifie qu’il a relu le patch et qu’il en assume la responsabilité au titre du Developer Certificate of Origin.

Quelle version du noyau dois-je utiliser sur un serveur ?

Dans presque tous les cas, celle maintenue par votre distribution. Le noyau fourni par une distribution combine une branche longterm, des corrections rétroportées et les tests du fournisseur. C’est également ce que supposent les images de votre hébergeur et vos conditions de support. Compilez un noyau mainline plus récent si vous avez besoin d’un pilote ou d’une fonctionnalité spécifique. Vérifiez la date de fin de vie de la branche vers laquelle vous migrez avant de vous engager.