Histoire des distributions Linux et de leurs familles

Ce qu’est réellement une distribution Linux

L’histoire des distributions Linux commence par un manque : le noyau Linux seul ne permet rien d’utile à un utilisateur. Il démarre et détecte le matériel. Puis il s’arrête. Quelqu’un doit ajouter un userland, choisir comment installer et mettre à jour les logiciels, puis s’engager à les maintenir pendant des années. Une distribution est cet ensemble de choix, auquel s’ajoute le groupe de personnes qui continue à le faire vivre.

Elle comporte cinq éléments. Modifiez-en un seul et vous obtenez une distribution différente, même lorsque la plupart des binaires sont identiques :

• Un noyau, dans une version choisie par le projet, avec les correctifs et les pilotes qu’il a ajoutés.
• Un userland : la bibliothèque C, le shell, le système init et les commandes standard.
• Un format de paquet et l’outil qui l’installe.
• Une politique de versions : ce qui peut changer, la fréquence des changements et la durée pendant laquelle chaque version est maintenue.
• Des personnes : des mainteneurs de paquets, une équipe de sécurité et quelqu’un qui répond lorsqu’un paquet ne fonctionne plus.

Le noyau est la partie commune. Deux distributions Linux sont donc beaucoup plus proches l’une de l’autre que l’une ou l’autre ne l’est d’un autre Unix. Il faut garder ce point à l’esprit lorsque vous comparez Linux et FreeBSD comme plateformes serveur, où le noyau et le userland de base sont construits par un seul projet et publiés ensemble. Sous Linux, ces composants proviennent de projets upstream distincts, et c’est la distribution qui les fait fonctionner ensemble.

Une histoire des distributions Linux en trois familles

Trois projets lancés en 1993 et 1994 sont devenus des familles : Slackware, Debian et Red Hat. Presque toutes les images proposées aujourd’hui dans le panneau de contrôle d’un VPS sont l’une d’elles ou un de ses descendants. Un descendant conserve le format des paquets, l’organisation des fichiers et généralement les habitudes de publication des versions. C’est pourquoi un dérivé de Debian reste familier après la disparition de sa marque.

Les distributions indépendantes méritent une ligne à part, car elles ne sont issues d’aucune autre. Arch, Gentoo, Alpine, NixOS et Void ont chacun développé leur propre gestionnaire de paquets et leurs propres règles. Deux d’entre elles, Arch et Alpine, ont malgré tout fini dans la liste des images de votre fournisseur, pour des raisons qui n’avaient rien à voir avec le bureau.

1992 : les distributions avant les grandes familles

MCC Interim Linux est apparue en février 1992. Owen Le Blanc l’a assemblée au Manchester Computing Centre. Elle regroupait le kernel et les outils GNU (GNU's not Unix) dans deux images de disquettes, avec un installateur piloté par menus. Elle existait parce qu’une installation manuelle demandait une journée de travail.

SLS (Softlanding Linux System), publiée par Peter MacDonald en 1992, allait plus loin et ajoutait X (the X Window System) ainsi que le réseau TCP/IP. SLS a donné au mot distribution son sens actuel. Elle comportait aussi de nombreux bugs et sa maintenance progressait lentement. En 1993, deux personnes ont décidé séparément de résoudre ces problèmes. L’une l’a reconstruite. L’autre est repartie de zéro avec des règles écrites.

Slackware, 1993 : la plus ancienne famille encore maintenue

Patrick Volkerding a publié Slackware 1.00 le 16 juillet 1993, à partir de SLS après en avoir corrigé les bugs. La distribution est toujours maintenue, ce qui en fait la plus ancienne distribution Linux encore existante.

Un paquet Slackware est une archive tar compressée qui contient un script d’installation. Il n’y a pas de résolution des dépendances : rien ne vérifie que la bibliothèque requise par votre nouveau paquet est déjà présente sur le disque. Cette seule décision a déterminé tout le reste. Si l’outil ne résout pas les dépendances, l’ensemble distribué doit être cohérent par construction. Les releases restent donc rares et conservatrices. Slackware 15.0 est sortie en février 2022, six ans après la version 14.2.

La famille est restreinte. Les premières releases de SUSE, au milieu des années 1990, étaient basées sur Slackware. Le projet a ensuite suivi sa propre voie avec YaST, puis avec le format de paquets RPM. Ce dernier point prête à confusion. SUSE et openSUSE utilisent des paquets RPM, mais ce ne sont pas des dérivées de Red Hat. Le format a circulé. La lignée, elle, n’a pas suivi.

Debian, 1993 : un contrat social et une chaîne à trois suites

Ian Murdock a annoncé Debian le 16 août 1993, trois semaines après Slackware et pour la même raison. Le nom associe celui de sa partenaire, Debra, au sien. Le Debian Manifesto a suivi en janvier 1994 et a fixé les règles : cette distribution serait maintenue ouvertement par des bénévoles, et non par une entreprise.

Debian a ensuite formalisé ces règles. Le Debian Social Contract et les DFSG (Debian free software guidelines) ont été adoptés en juillet 1997, et les DFSG sont devenues la base de l’Open Source Definition en 1998. Un document rédigé pour définir ce qui peut appartenir à une distribution a finalement défini une catégorie de licences pour toute l’industrie. C’est aussi la raison pour laquelle votre sources.list comporte des composants : main contient les logiciels conformes aux guidelines, tandis que contrib et non-free contiennent ceux qui ne le sont pas. Debian 12 a ajouté non-free-firmware pour qu’un ordinateur portable équipé d’une carte réseau sans fil puisse installer le système sans recherche interminable.

Les outils constituent l’autre héritage. dpkg installe un paquet et s’arrête lorsqu’une dépendance manque, en affichant dpkg: dependency problems prevent configuration of. APT (advanced package tool), devenu l’outil par défaut avec Debian 2.1 en 1999, détermine quels autres paquets récupérer et dans quel ordre. Chaque commande apt de chaque dérivé de Debian découle de ce travail.

Le processus de publication comporte trois suites et une règle. Un mainteneur envoie un paquet vers unstable, dont le nom de code permanent est sid. Un script fait migrer le paquet vers testing après environ 5 à 10 jours, s’il a été compilé pour les architectures de la version et n’a introduit aucun nouveau bug bloquant la publication. Testing est ensuite gelée, l’équipe de publication corrige les derniers problèmes, puis stable est publiée lorsque la liste des bugs est suffisamment courte. Il n’y a pas de date fixe. C’est pourquoi Debian stable paraît ancienne et reste fiable : les numéros de version cessent d’évoluer au moment du gel, tandis que les correctifs de sécurité continuent d’y être rétroportés.

La gouvernance est également formalisée, avec un chef de projet élu et des résolutions générales contraignantes. En 2014, ce mécanisme a choisi systemd comme système init par défaut. Les personnes qui n’étaient pas d’accord ont créé Devuan, dont la première version est sortie en 2017. Les principaux dérivés sont Ubuntu, Raspberry Pi OS, Proxmox VE, Kali et Linux Mint.

Red Hat, 1994 : RPM, puis la séparation entre Fedora et RHEL

Marc Ewing a publié le premier Red Hat Linux vers Halloween 1994. L’entreprise de Bob Young l’a racheté en 1995, puis ils ont créé la première entreprise Linux qui vendait du support plutôt que des logiciels. Red Hat est entrée en bourse le 11 August 1999. IBM a finalisé l’acquisition de l’entreprise en July 2019 pour environ 34 milliards de dollars. La distribution certifiée par la plupart des logiciels d’entreprise est donc la propriété d’IBM depuis cette date.

La contribution technique durable est RPM (Red Hat package manager), écrit par Erik Troan et Marc Ewing pour Red Hat Linux 2.0 en 1995. Un RPM déclare ses dépendances et est produit à partir d’un fichier spec, c’est-à-dire une recette de build que n’importe qui peut exécuter. C’est cette deuxième propriété qui a ensuite rendu possibles les rebuilds indépendants du produit d’entreprise de Red Hat.

Red Hat Linux 9, publié en 2003, a été la dernière version de la branche d’origine. L’entreprise l’a séparée en deux : Fedora Core 1 en November 2003, comme release communautaire rapide, et RHEL (Red Hat Enterprise Linux), qui avait commencé sous le nom Advanced Server 2.1 en 2002, comme version payante à évolution lente. La cause est simple. Un même produit ne peut pas être à la fois l’environnement où l’on teste les nouvelles versions et la plateforme qu’une banque exploite sans modification pendant dix ans. Les deux branches restent liées : une version majeure de RHEL dérive d’une release Fedora, est stabilisée, puis gelée. L’outil de gestion des paquets a suivi le même calendrier, de yum dans les années 2000 à dnf comme valeur par défaut de Fedora en 2015, avec rpm sous les deux.

Pourquoi CentOS a cessé d’être une reconstruction gratuite de RHEL

CentOS a été créé en 2004 avec un objectif simple : récupérer les paquets sources publiés par Red Hat, supprimer les marques déposées, les reconstruire, puis distribuer gratuitement le résultat. Il est devenu la distribution serveur gratuite par défaut pendant une dizaine d’années. Red Hat a intégré le projet en 2014.

Le 8 décembre 2020, Red Hat a annoncé que CentOS Linux 8 prendrait fin le 31 décembre 2021, soit huit ans plus tôt que la date publiée, et que le nom continuerait avec CentOS Stream. Stream n’est pas une reconstruction. Il s’agit de la branche à partir de laquelle les versions mineures de RHEL sont créées. Elle évolue donc avant RHEL, et non après. Pour une machine que vous prévoyez de conserver pendant plusieurs années, cette évolution en amont pose problème, car vous recevez les changements avant les clients payants de Red Hat.

Deux reconstructions sont apparues en 2021. Rocky Linux a été lancé par Gregory Kurtzer, qui a cofondé CentOS. AlmaLinux a été financé par CloudLinux. En juin 2023, Red Hat a cessé de publier les sources de RHEL ailleurs que dans CentOS Stream et sur son portail client. Rocky a conservé l’objectif de produire des reconstructions identiques. AlmaLinux a changé d’objectif pour viser la compatibilité ABI (application binary interface). Cela signifie que les logiciels conçus pour RHEL s’exécutent sur AlmaLinux, sans garantie que la liste des bugs corresponde ligne par ligne. Oracle, SUSE et CIQ ont créé OpenELA plus tard la même année pour publier des sources communes.

Si la liste d’images d’un fournisseur mentionne encore CentOS, vérifiez de quelle version il s’agit avant de vous appuyer dessus.

cat /etc/os-release

NAME="CentOS Stream" est une branche de développement rolling qui précède RHEL. NAME="AlmaLinux" ou NAME="Rocky Linux" est une reconstruction qui suit RHEL, avec une durée de support de dix ans.

Ubuntu, 2004 : un instantané de Debian unstable, selon un calendrier

Ubuntu 4.10 est sorti le 20 octobre 2004, avec le financement de Mark Shuttleworth. Sa relation avec Debian est mécanique plutôt que sentimentale. Chaque cycle commence par l’importation de paquets depuis Debian unstable dans la nouvelle version d’Ubuntu. Ces importations continuent jusqu’au Debian Import Freeze, au milieu du cycle. Ensuite, Ubuntu conserve ses propres modifications. De nombreux paquets Ubuntu sont le paquet Debian auquel s’ajoute un delta. Le changelog indique lequel.

L’autre moitié concerne le calendrier. Debian sort ses versions lorsqu’elles sont prêtes. Ubuntu sort ses versions en avril et en octobre. Le numéro de version correspond à la date : 24.04 est sorti en avril 2024. Une version d’avril sur deux est une LTS (long term support). C’est cette version qu’un fournisseur désigne lorsqu’il propose Ubuntu sans autre précision. Le choix entre les deux types de versions pour un serveur est traité dans le choix entre Ubuntu LTS et les versions intermédiaires. Le passage d’une LTS à la suivante suit une procédure spécifique, décrite dans la mise à niveau de 24.04 vers 26.04.

Un détail revient chaque année dans l’administration des serveurs. L’archive Ubuntu est divisée en composants. main est maintenu par Canonical pendant toute la période de support. universe est maintenu par la communauté, avec une couverture de sécurité différente. apt install n’affiche aucune information sur cette différence. Une commande permet de la voir :

apt-cache policy nginx

Une ligne de dépôt qui se termine par /main signifie que l’équipe de sécurité de Canonical est responsable de ce paquet. Une ligne qui se termine par /universe signifie que la communauté l’est. Vérifiez ce point pour tout paquet exposé à Internet.

Arch, 2002 : rolling releases et coût d’une mise à niveau partielle

Judd Vinet a publié Arch 0.1 le 11 March 2002, avec un gestionnaire de paquets qu’il avait écrit lui-même, pacman, et des recettes de compilation qui sont de simples scripts shell. Arch n’a aucune version stable publiée. Les supports d’installation sont des instantanés datés des mêmes dépôts rolling. Une machine installée en 2019 et mise à jour chaque semaine utilise donc le même Arch qu’une machine installée aujourd’hui. L’AUR (Arch user repository) contient des recettes de compilation fournies par les utilisateurs. Ce ne sont pas des paquets vérifiés. Lire un PKGBUILD avant de l’exécuter fait donc partie du travail.

Le rolling release a un mode de défaillance, toujours provoqué par l’administrateur. L’installation d’un seul paquet avec pacman -Sy foo actualise la base de données des paquets, puis installe un nouveau binaire lié à des bibliothèques plus récentes que celles présentes sur le disque. Les programmes échouent alors de la manière suivante :

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

L’opération prise en charge est pacman -Syu, qui met tout à jour en une seule fois. Le projet publie également des entrées d’actualité indiquant quand une intervention manuelle est nécessaire avant certaines mises à niveau. Effectuer la mise à niveau sans les lire peut laisser une machine qui ne démarre plus.

Arch convient donc mal à un serveur que vous prévoyez de laisser sans surveillance. Une machine mise à jour chaque semaine ne pose pas de problème. Une machine mise à jour une seule fois, un an plus tard, vous impose toutes les interventions ignorées en une seule exécution.

Alpine : une petite distribution rendue célèbre par les conteneurs

Alpine a commencé vers 2005 comme un fork de LEAF (Linux embedded appliance framework), lui-même issu du Linux Router Project. Natanael Copa l’a conçue pour les appliances, pas pour les postes de travail. Elle remplace la plupart des composants habituels de l’espace utilisateur : musl à la place de la bibliothèque C GNU, BusyBox à la place des utilitaires système GNU, OpenRC à la place de systemd et apk comme gestionnaire de paquets. Alpine 3.0, en 2014, est la version qui est passée à musl.

Les conteneurs l’ont rendue populaire. Une couche de base Alpine occupe une fraction de la taille d’une image de base Debian ou Ubuntu. À partir de 2016, Alpine est donc devenue une image de base courante, et beaucoup de personnes qui ne l’avaient jamais installée l’ont utilisée tous les jours.

Le problème est que musl n’est pas glibc, et cette différence se manifeste par des bugs qui semblent sans rapport. Un binaire lié à glibc échoue sur Alpine avec un message qui pousse à rechercher un fichier pourtant déjà présent :

sh: ./myapp: not found

Le programme existe. Son interpréteur ELF n’existe pas, car le loader de glibc est absent. Python réserve une autre surprise fréquente : les wheels précompilées pour manylinux ne s’installent pas avec musl. pip revient donc à compiler depuis les sources et s’arrête lorsqu’aucun compilateur n’est installé. Le standard de wheels musllinux, créé en 2021, a résolu le problème pour les projets qui publient ces wheels, et pour personne d’autre.

Comme système d’exploitation hôte sur un VPS, Alpine s’installe rapidement, se met à jour rapidement et vous éloigne du chemin suivi par la plupart des documentations. Chaque guide qui vous demande d’exécuter systemctl enable doit être adapté en rc-update add.

La génération immuable : mises à jour atomiques et serveurs basés sur des images

La branche la plus récente modifie le modèle de mise à jour, plutôt que la liste des paquets. Un système basé sur ostree conserve /usr en lecture seule. Une mise à jour correspond à une arborescence complète du système de fichiers, téléchargée, préparée, puis activée au redémarrage suivant. L’ancienne arborescence reste disponible comme entrée de démarrage. Une mise à jour défectueuse peut donc être annulée en redémarrant sur l’ancienne.

Fedora Silverblue a apporté ce modèle aux postes de travail en 2018, puis Fedora CoreOS l’a étendu aux serveurs en 2019, après le rachat de CoreOS par Red Hat en 2018. Flatcar Container Linux a poursuivi le projet Container Linux d’origine après son retrait en 2020. openSUSE MicroOS obtient un résultat similaire grâce aux snapshots btrfs et à transactional-update. En 2024, Red Hat a ajouté un mode basé sur une image à RHEL, construit sur bootc. Le système d’exploitation est alors fourni sous la forme d’une image de conteneur, et une machine est mise à jour en la faisant pointer vers un nouveau tag. Talos Linux va plus loin et supprime entièrement le shell et SSH : la machine se configure via une API, et il n’y a donc rien auquel se connecter. NixOS, publié pour la première fois en 2007, suit une autre approche. L’ensemble du système est construit à partir d’une configuration déclarative unique, et les générations précédentes restent amorçables.

Votre fournisseur ne propose probablement aucun de ces systèmes sous la forme d’une image installable en un clic. Ils sont conçus pour être configurés au premier démarrage par Ignition ou cloud-init, plutôt que par un administrateur qui modifie des fichiers via SSH. Ils sont particulièrement utiles sur un grand nombre de machines identiques. C’est la situation dans laquelle vous vous trouvez lorsque vous administrez plusieurs serveurs Linux à la fois et que chaque machine doit être démontrablement identique aux autres.

Combien de temps une version est-elle prise en charge ?

La politique de prise en charge est l’aspect d’une distribution avec lequel vous composez le plus longtemps. Elle est exprimée en nombre d’années. Voici les périodes de prise en charge des 5 versions serveur actuelles.

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Alpine prend en charge chaque branche 3.x pendant 2 ans. Elle convient donc mieux à une image de conteneur que vous reconstruisez souvent qu’à un hôte que vous laissez fonctionner sans intervention. L’équipe de sécurité Debian prend en charge une version stable pendant environ 3 ans. L’équipe LTS prend ensuite en charge les architectures courantes jusqu’à environ 5 ans au total. Une Ubuntu LTS vous donne 5 ans de prise en charge des paquets dans main. Un abonnement Ubuntu Pro prolonge cette période jusqu’à 10 ans. Il est gratuit pour un usage personnel sur un petit nombre de machines. RHEL 10 annonce 10 ans. L’option payante Extended Life Cycle Support prolonge cette période jusqu’à 13 ans. AlmaLinux 10 reprend la période de prise en charge de RHEL, soit 10 ans, sans aucun abonnement. C’est précisément la raison d’être de ces reconstructions.

Arch n’apparaît pas ici, car une distribution rolling n’a pas de version à maintenir. Pour Arch, le nombre important est la durée pendant laquelle vous pouvez laisser une machine sans intervention. Cette durée se mesure en semaines.

Pourquoi votre liste d’images VPS ressemble à cela

Un fournisseur propose les images que ses clients demandent explicitement et qui s’installent sans intervention sur son hyperviseur. C’est pourquoi presque toutes les listes commencent par une Ubuntu LTS et une Debian stable, ajoutent AlmaLinux ou Rocky pour les utilisateurs dont les logiciels sont certifiés pour RHEL, puis placent Alpine, Arch et Fedora plus bas dans la page. Une fois que vous savez ce qu’est un VPS et comment l’image est écrite sur le disque, le schéma devient clair : le fournisseur choisit des systèmes d’exploitation capables de terminer une installation unattended et de rester supportés plus longtemps que la durée moyenne d’utilisation d’un serveur par un client.

Ce choix vous engage au-delà du gestionnaire de paquets. Il détermine la mise à niveau que vous exécuterez dans trois ans, et celle-ci varie complètement selon la famille. Debian et Ubuntu prennent en charge les mises à niveau majeures in place. La famille Red Hat les effectue avec leapp. Arch n’a pas de mise à niveau, car elle n’a pas de version. Celle d’Alpine consiste à modifier /etc/apk/repositories et à exécuter apk upgrade --available. Le choix détermine également les logiciels que vous pouvez installer sans ajouter de dépôt tiers, le fournisseur qui publie le correctif lorsqu’une entrée CVE (common vulnerabilities and exposures) concerne un composant que vous utilisez, ainsi que le système init et la bibliothèque C que vos futurs logiciels supposeront présents.

Un autre effet est souvent sous-estimé. La plupart des réponses publiées sur Internet supposent une procédure adaptée à la famille Debian ou à la famille Red Hat. Choisir une autre famille vous oblige donc à traduire les instructions pendant toute la durée de vie de la machine. Choisissez la famille dont la politique de release correspond à la fréquence à laquelle vous acceptez d’intervenir sur le serveur, puis conservez-la. Modifier les paquets installés au-dessus est simple. Modifier la distribution sous-jacente implique de reconstruire la machine.

FAQ

Dans quelle famille de distributions Linux se trouve mon serveur ?

Exécutez cat /etc/os-release. Le champ ID indique la distribution et ID_LIKE sa famille. Une machine Ubuntu renvoie donc ID_LIKE=debian et une machine AlmaLinux renvoie ID_LIKE="rhel centos fedora". Le gestionnaire de paquets fournit une autre indication. apt et dpkg désignent la famille Debian, dnf et rpm la famille Red Hat, apk Alpine et pacman Arch.

CentOS est-elle encore une version gratuite de RHEL ?

Non. CentOS Linux 8, le dernier rebuild portant ce nom, a atteint sa fin de vie le 31 décembre 2021. CentOS Linux 7 a atteint sa fin de vie le 30 juin 2024. Le projet qui subsiste, CentOS Stream, est la branche à partir de laquelle sont générées les versions mineures de RHEL. Il reçoit donc les changements avant RHEL, et non après. Les rebuilds gratuits qui ont repris l’ancien rôle sont AlmaLinux et Rocky Linux, tous deux avec une période de support de dix ans.

Pourquoi Debian stable fournit-elle des numéros de version aussi anciens ?

Parce que le numéro de version reste inchangé alors que les correctifs continuent d’être publiés. Debian rétroporte les correctifs de sécurité dans la version publiée au lieu d’importer une version upstream plus récente. Un paquet affichant 2.4.57-2+deb13u1 peut donc contenir un correctif publié la semaine dernière. Le suffixe qui suit la version upstream est la révision Debian, et apt changelog <package> indique ce qu’elle contient. Évaluer la sécurité d’un serveur Debian à partir de ses numéros de version conduit systématiquement à une conclusion erronée.

Dois-je utiliser une distribution rolling release comme Arch sur un VPS ?

Seulement si vous la mettrez à jour selon un calendrier régulier. Une distribution rolling suppose que chaque machine converge vers l’ensemble actuel des paquets. La mise à jour d’un seul paquet avec pacman -Sy foo peut donc laisser des bibliothèques incompatibles et provoquer des erreurs comme cannot open shared object file. Exécutez régulièrement pacman -Syu, consultez la page d’actualités du projet avant chaque exécution, et le système reste stable. Si vous laissez passer un an, la première mise à niveau devient risquée.

Que change concrètement une distribution immutable ou atomic ?

Elle change le moment où les mises à jour sont appliquées et la manière de les annuler. /usr est monté en lecture seule. Une mise à jour est préparée sous la forme d’une arborescence complète, puis activée au redémarrage. L’arborescence précédente reste disponible comme entrée de démarrage pour permettre un rollback. La machine est ainsi soit entièrement mise à jour, soit entièrement dans l’état précédent, sans état partiellement appliqué. En contrepartie, vous ne pouvez plus installer des logiciels en modifiant des fichiers sur place. Les applications sont donc placées dans des conteneurs ou dans des paquets superposés.