Histoire du noyau Linux : les choix qui durent

Bref historique du noyau Linux

L’histoire du noyau Linux va de la version 0.01, publiée en septembre 1991, aux versions 7.x qui démarrent aujourd’hui sur des serveurs. La liste des versions est la partie la moins intéressante. Quelques décisions ont défini sa structure, et chacune a encore des conséquences sur une machine que vous louez cet après-midi. La raison pour laquelle un nouveau noyau était nécessaire en 1991 s’inscrit dans l’histoire plus longue d’Unix, des licences AT&T et du procès qui a freiné BSD.

Les dates et les numéros de version indiqués ici proviennent de kernel.org et de l’historique des releases 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 lui-même rédigée. Elle exigeait que le code source soit distribué et ajoutait une phrase plus importante encore : « 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 toute distribution commerciale de Linux.

Il a changé cette disposition. Le passage à la GNU General Public License (GPL) a été annoncé dans les notes de version de la 0.12 en janvier 1992 et a pris effet le 1er 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 développées autour de Linux reposent sur ce changement.

Le kernel est sous GPL version 2 uniquement 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. Celle-ci exige qu’un appareil qui distribue du code sous GPL accepte également une version modifiée de ce code. Il considérait le matériel verrouillé comme une décision commerciale relevant du fabricant. En 2017, les développeurs du kernel ont publié le Kernel Enforcement Statement. Ce document 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 infraction.

Deux conséquences concernent les serveurs. Le binaire du kernel que vous démarrez vous donne droit au code source correspondant. Personne ne peut donc vous fournir un kernel Linux que vous n’auriez pas le droit d’inspecter ou de reconstruire. Par ailleurs, la mention de copyright du kernel précise que la licence ne couvre pas les programmes utilisateur qui utilisent les services du kernel via les appels système habituels. 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. 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 drivers et les systèmes de fichiers s’exécutent dans un même espace d’adressage privilégié, relevaient de la conception des années 1970. Les microkernels, dans lesquels ces composants s’exécutent comme des processus ordinaires, représentaient l’avenir. Il affirmait aussi que Linux était étroitement lié à l’Intel 386 et ne pourrait donc jamais être porté sur d’autres architectures.

La portabilité a été démontrée 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.

La question de la conception a été résolue par un compromis. Linux n’est jamais devenu un microkernel. Il a adopté les loadable kernel modules : des fichiers objet que l’on insère dans un noyau en fonctionnement et que l’on peut ensuite retirer, ce qui permet de distribuer un driver séparément du binaire du noyau.

lsmod | head
modinfo virtio_net | head -5

lsmod affiche la liste des modules actuellement chargés. modinfo affiche le fichier dont provient le module et les paramètres qu’il accepte. Sur un serveur virtuel, la plupart des composants de la gestion du stockage et du réseau sont des modules. C’est pourquoi une même image de noyau peut démarrer sur du matériel qu’elle n’a jamais rencontré. Le noyau signale uniquement la présence du nouveau matériel. Un daemon de l’espace utilisateur décide ensuite quel module charger et quel nom attribuer au device. C’est ainsi que la gestion des devices a fini par être intégrée au système d’init, ce qui explique notamment pourquoi systemd est devenu difficile à éviter.

Les modules ont apporté cette flexibilité sans le coût du modèle microkernel. Isoler un driver 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 qu’il faut anticiper : un module s’exécute avec tous les privilèges du noyau. Un module défectueux peut donc faire tomber toute la machine, et pas seulement un processus. Le problème est particulièrement visible avec les out-of-tree modules. Un driver fourni par un éditeur qui n’est pas intégré au mainline doit être recompilé pour chaque nouveau noyau. C’est ce que fait DKMS pendant une mise à niveau. Si cette compilation échoue, le device est tout simplement absent après le redémarrage.

Pourquoi SMP a pris quinze ans à être finalisé

Linux 2.0, sorti en juin 1996, est le premier kernel à prendre en charge le multiprocesseur 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 améliorait ainsi les workloads qui effectuent leurs calculs en espace utilisateur, mais très peu ceux qui exécutent des appels système, car ces derniers attendaient 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, principalement 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 ce travail qui explique qu’un plan avec 4 vCPU n’a plus rien d’exceptionnel aujourd’hui. Il indique aussi une limite qu’il faut connaître. Sur un serveur virtuel partagé, votre kernel ordonnance vos threads, puis l’hyperviseur ordonnance 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 modifié la manière de construire le noyau

Avant 2.6, les numéros de version fonctionnaient par paires. Un deuxième numéro pair indiquait une série stable (2.4), tandis qu’un numéro impair indiquait une série de développement (2.5). La version 2.4 est sortie le 4 janvier 2001 et la version 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 un noyau « 2.4 » pouvaient livrer des noyaux séparés par des milliers de patches.

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

Un effet secondaire est que le numéro de version a cessé d’être une garantie. Les versions 3.0, 4.0, 5.0 et 7.0 ne sont pas des réécritures. Torvalds augmente le premier numéro lorsque le second devient suffisamment élevé pour le déranger. 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 corrections.

Comment la rupture avec BitKeeper a produit git en avril 2005

À partir de février 2002, le noyau a été développé avec BitKeeper, un système de gestion de versions distribué propriétaire de l’entreprise BitMover, fondée par Larry McVoy. Cela a commencé avec la série 2.5. BitMover accordait gratuitement une licence aux développeurs du noyau, sous certaines conditions : il était interdit de travailler sur un outil de gestion de versions concurrent, et il était interdit de procéder à la rétro-ingénierie de BitKeeper. De nombreux développeurs n’appréciaient pas de construire un noyau libre avec un outil dont ils n’avaient pas le droit d’examiner le fonctionnement.

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 s’est retrouvé sans système de gestion de versions au milieu d’un cycle de développement.

Le travail sur 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 en 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é à partir du hash de son contenu. Modifier un seul octet dans un 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, la forge de code sur laquelle la plupart des équipes poussent leur code et le serveur git que vous pouvez exécuter vous-même sont issus d’un conflit de licences autour d’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. 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, les reçoivent pendant des années. Ce sont elles qui servent de base aux distributions.

La version 2.6.32, publiée en décembre 2009, a démontré la viabilité du 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. Red Hat est allé plus loin et a conservé son kernel basé sur 2.6.32 avec ses propres backports jusqu’à la fin de RHEL 6 en 2020. Reproduire gratuitement cette décennie de support est précisément la raison pour laquelle CentOS a existé, puis Rocky Linux et AlmaLinux l’ont remplacé.

La durée de support 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 mobilise du temps de maintenance et que les anciennes branches sont peu testées en pratique. Le 25 février 2026, Greg Kroah-Hartman a de nouveau publié des projections plus longues, après avoir échangé avec les entreprises qui dépendent de ces branches. Le cadre actuel couvre une période 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 recense 6 branches longterm en août 2026. La plus ancienne, 5.10, aura reçu des correctifs pendant 6.0 ans lorsqu’elle arrivera en fin de vie en Dec 2026. La plus récente, 6.18, devrait être maintenue jusqu’à Dec 2028, soit 3.1 ans de correctifs.

Considérez ces dates comme une limite minimale, pas comme un engagement contractuel. Les projections pour 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. Votre distribution fait généralement ce choix pour vous : Debian 13 utilise 6.12 et Ubuntu 26.04 LTS utilise 7.0. C’est le contenu pratique de la question du choix entre LTS et version intermédiaire sur un serveur. C’est aussi ce qui change réellement sous le capot lorsque vous mettez Ubuntu 24.04 à niveau vers 26.04.

Un piège découle de cette situation. uname -r sur Ubuntu 24.04 affiche quelque chose comme 6.8.0-51-generic. Il s’agit d’une base upstream à laquelle s’ajoutent les propres backports de la distribution. Le numéro indique donc l’origine de la branche, pas les correctifs qu’elle contient. Les scanners qui évaluent un kernel d’après sa chaîne de version génèrent exactement pour cette raison de fausses alertes avec les kernels des distributions.

Ce que le noyau est en train de débattre

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

Rust a été intégré à l’infrastructure du noyau en 6.1, en décembre 2022. Dans la version 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 consulte pas, et le débat porte sur la responsabilité de les corriger.

Le second débat concerne les contributions générées avec l’IA. Sasha Levin a proposé une politique en juillet 2025, après l’arrivée d’un volume croissant de patches assistés par des outils dans les listes de diffusion. Le document a été intégré le 23 décembre 2025 et figure désormais dans la documentation des processus du noyau, à l’adresse docs.kernel.org/process/coding-assistants.html. Un agent 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. Il préserve toutefois la provenance : l’historique continue d’indiquer qui a signé chaque modification. C’est précisément la 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 lire et reconstruire le kernel démarré par votre fournisseur, et pourquoi les logiciels propriétaires peuvent malgré tout 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 recompilé à chaque mise à niveau du kernel.
• Le modèle de publication explique pourquoi le numéro de version vous apprend peu de choses, tandis que la branche et sa date de fin de vie 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 sysctls sont en lecture seule.

FAQ

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

Torvalds s’est opposé à GPLv3 en 2007, principalement en raison de son exigence contre la tivoïsation, qui impose qu’un appareil distribuant du code GPL accepte également une version modifiée de ce code. Pour lui, le matériel verrouillé relève du modèle économique du fabricant. Le changement de licence est également presque impossible en pratique, car les droits d’auteur sur le 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 microkernel ?

Il est monolithique, avec des modules chargeables. Les drivers 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 apporte de la vitesse, 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 est moins nette depuis 1992 grâce aux systèmes de fichiers FUSE en 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, publié toutes les 9 à 10 semaines. C’est là que les nouvelles fonctionnalités 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. Ce sont elles que les distributions utilisent pour construire 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, selon 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. 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 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, utilisez celle maintenue par votre distribution. Le noyau d’une distribution est une branche longterm à laquelle s’ajoutent des corrections rétroportées et les tests du fournisseur. C’est aussi ce que supposent les images de votre provider et vos conditions de support. Compilez un noyau mainline plus récent si vous avez besoin d’un driver ou d’une fonctionnalité précise. Vérifiez la date de fin de vie de la branche vers laquelle vous migrez avant de vous engager.