Histoire des distributions Linux et de leurs origines

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 à une personne. Il démarre et détecte le matériel. Puis il s’arrête. Quelqu’un doit ajouter un userland, choisir comment les logiciels sont installés et mis à jour, et s’engager à continuer à les corriger pendant des années. Une distribution est l’ensemble de ces choix, ainsi que le groupe de personnes qui reste ensuite pour les maintenir.

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 publication : ce qui peut changer, la fréquence des changements et la durée pendant laquelle chaque version reçoit des correctifs.
• Des personnes : des responsables 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 cela à l’esprit lorsque vous comparez Linux et FreeBSD comme plates-formes serveur, où le noyau et le userland de base sont développés par un seul projet et publiés ensemble. Sous Linux, ces éléments proviennent de projets upstream distincts, et la distribution est ce qui les fait fonctionner ensemble.

Historique 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 un panneau de contrôle VPS appartiennent à l’une de ces familles ou en sont des dérivées. Une distribution dérivée conserve le format des paquets, l’organisation des fichiers et généralement les habitudes de publication. C’est pourquoi une dérivée de Debian reste reconnaissable après la disparition de sa marque.

Les distributions indépendantes méritent un paragraphe séparé, car elles ne sont issues d’aucun autre projet. 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 tout de même fini dans la liste d’images de votre fournisseur, pour des raisons qui n’avaient rien à voir avec le bureau.

1992 : les distributions avant les 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 disquette, avec un installateur piloté par menus. Elle existait parce qu’effectuer cette installation manuellement demandait une journée de travail.

SLS (Softlanding Linux System), publiée par Peter MacDonald en 1992, est allée plus loin en ajoutant X (the X Window System) et le réseau TCP/IP. SLS est à l’origine du sens actuel du mot distribution. Elle comportait aussi de nombreux bugs et sa maintenance était lente. En 1993, deux personnes ont décidé séparément de corriger 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 publiée

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 le nouveau paquet est déjà présente sur le disque. Cette décision unique a déterminé tout le reste. Si l’outil ne résout pas les dépendances, l’ensemble des paquets fournis 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 14.2.

La famille est restreinte. Les premières releases de SUSE, au milieu des années 1990, étaient basées sur Slackware, avant que le projet ne suive sa propre voie avec YaST puis, plus tard, le format de paquet 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 filiation, non.

Debian, 1993 : un contrat social et une chaîne de publication en 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 compagne, Debra, au sien. Le Debian Manifesto a suivi en janvier 1994 et en a fixé les principes : cette distribution serait maintenue ouvertement par des bénévoles, et non par une entreprise.

Debian a ensuite formalisé ces principes. 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éterminer ce qui pouvait appartenir à une distribution a finalement défini une catégorie de licences pour toute l’industrie. C’est aussi pourquoi votre sources.list comporte des composants : main contient les logiciels conformes aux guidelines, contrib et non-free contiennent ceux qui ne le sont pas, et Debian 12 a ajouté non-free-firmware afin qu’un ordinateur portable équipé d’une carte sans fil puisse être installé sans recherche fastidieuse.

Les outils constituent l’autre héritage. dpkg installe un paquet et échoue lorsqu’il manque une dépendance, 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 présente dans les distributions dérivées de Debian découle de ce travail.

Le processus de publication comporte trois suites et une règle. Un mainteneur téléverse un paquet dans unstable, dont le nom de code permanent est sid. Un script migre le paquet vers testing après environ 5 à 10 jours, s’il a été construit pour les architectures de la version et n’a introduit aucun nouveau bug critique pour la publication. Testing est ensuite gelée, l’équipe de publication règle les problèmes restants, 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 semble ancienne tout en restant fiable : les numéros de version s’arrêtent 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 fonctionnement 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. Debian n’a été ni la première distribution à effectuer ce changement, ni la dernière. Les raisons de ces changements successifs, ainsi que les objections qui se sont révélées fondées, sont retracées dans le récit du remplacement de SysV init par systemd. Les principaux descendants 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 les deux hommes 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 août 1999. IBM a finalisé le rachat de l’entreprise en juillet 2019 pour environ 34 milliards de dollars. La distribution certifiée par la plupart des logiciels d’entreprise appartient donc à IBM depuis cette date.

La contribution technique qui a le plus duré est RPM (Red Hat package manager), écrit par Erik Troan et Marc Ewing pour Red Hat Linux 2.0 en 1995. Un paquet RPM déclare ses dépendances et est produit à partir d’un fichier spec, qui contient une recette de build exécutable par n’importe qui. C’est cette seconde propriété qui a ensuite rendu possibles les reconstructions indépendantes 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 novembre 2003, comme version communautaire à évolution 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 raison est simple. Un même produit ne peut pas servir à la fois de terrain d’essai pour les nouvelles versions et de plate-forme qu’une banque exploite sans modification pendant dix ans. Les deux branches restent liées : une version majeure de RHEL est dérivée d’une version de Fedora, stabilisée, puis figée. L’outil de gestion des paquets a suivi le même calendrier, en passant 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 : reprendre les paquets sources publiés par Red Hat, supprimer les marques commerciales, les reconstruire, puis distribuer le résultat gratuitement. Il est devenu la distribution serveur gratuite par défaut pendant une décennie. Red Hat a intégré le projet en 2014.

Le 8 décembre 2020, Red Hat a annoncé que CentOS Linux 8 arriverait en fin de vie le 31 décembre 2021, soit huit ans plus tôt que la date annoncée, et que le nom continuerait d’exister sous la forme de 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, évoluer en amont est un mauvais choix : 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, cofondateur de 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 continué à viser des reconstructions identiques. AlmaLinux a modifié son objectif pour assurer la compatibilité ABI (application binary interface). Les logiciels créés pour RHEL peuvent ainsi s’exécuter, 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 afin de publier des sources communes. Toute cette évolution, de la séparation de 2003 au changement de publication des sources en 2023, ainsi que les garanties actuelles de chaque reconstruction, est décrite dans l’historique détaillé de Red Hat, CentOS, Rocky et AlmaLinux.

Si la liste d’images d’un fournisseur mentionne encore CentOS, vérifiez de quelle version il s’agit avant de l’utiliser comme base.

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 le suit, avec une période 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, pas sentimentale. Chaque cycle commence par l’importation de paquets depuis Debian unstable dans la nouvelle version d’Ubuntu. Ces importations se poursuivent jusqu’au Debian Import Freeze, au milieu du cycle. Ensuite, Ubuntu conserve ses propres modifications. De nombreux paquets Ubuntu correspondent au paquet Debian auquel s’ajoute un delta, et 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, et 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), ce que désigne généralement un fournisseur lorsqu’il propose Ubuntu sans autre précision. Le choix entre ces deux types de versions pour un serveur est le sujet de choisir entre Ubuntu LTS et les versions intermédiaires, et le passage d’une LTS à la suivante suit une procédure spécifique, présentée 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 le vérifier :

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 ce qui est exposé à Internet.

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

Judd Vinet a publié Arch 0.1 le 11 mars 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 publiée au sens classique. 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 exécute 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, et il est 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 comme ceci :

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 annonces indiquant qu’une intervention manuelle est nécessaire avant certaines mises à niveau. Exécuter la mise à niveau sans les lire peut laisser une machine qui ne démarre plus.

Arch est donc un mauvais choix pour 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 : la petite distribution rendue célèbre par les conteneurs

Alpine a été créée 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 GNU C, BusyBox à la place des utilitaires système GNU, OpenRC à la place de systemd et apk comme gestionnaire de paquets. Alpine 3.0, publiée en 2014, est la version qui a adopté musl.

Les conteneurs l’ont rendue populaire. Une couche de base Alpine occupe une fraction de l’espace 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 n’avaient jamais installé Alpine l’exécutaient chaque jour.

Le problème est que musl n’est pas glibc, et cette différence provoque des erreurs 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 chargeur 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, puis s’arrête lorsqu’aucun compilateur n’est installé. Le standard de wheel musllinux, introduit en 2021, a résolu ce problème pour les projets qui publient ces wheels, et pour aucun autre.

Comme système d’exploitation hôte sur un VPS, Alpine s’installe rapidement, occupe peu d’espace et reçoit vite ses mises à jour. En revanche, elle vous éloigne de l’environnement supposé 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 nouvelle arborescence complète du système de fichiers, téléchargée, préparée, puis activée au redémarrage suivant. L’arborescence précédente 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 apporté 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 fourni sous forme d’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 sur quoi se connecter. NixOS, dont la première version est sortie en 2007, suit une autre approche. Le système complet est construit à partir d’une seule configuration déclarative, et les générations précédentes restent amorçables.

Votre fournisseur ne propose probablement aucune de ces options sous forme d’image disponible en un clic, car elles sont conçues pour être configurées au premier démarrage par Ignition ou cloud-init, plutôt que par un administrateur qui modifierait des fichiers via SSH. Elles deviennent particulièrement utiles sur de nombreuses machines identiques. C’est votre cas dès lors que vous administrez plusieurs serveurs Linux à la fois et que chaque machine doit être vérifiable comme identique aux autres.

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

La politique de support est l’aspect d’une distribution avec lequel vous composez le plus longtemps. Elle est publiée sous la forme d’un nombre d’années. Voici les périodes de support pour les 5 releases 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 release 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 offre 5 ans de support pour les paquets de main. Un abonnement Ubuntu Pro porte cette durée à 10 ans. Il est gratuit pour un usage personnel sur un petit nombre de machines. RHEL 10 annonce 10 ans. L’option payante de support sur le cycle de vie étendu porte cette durée à 13 ans. AlmaLinux 10 reprend la période de support 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 release à prendre en charge. 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 la liste d’images de votre VPS ressemble à ceci

Un fournisseur propose les images que ses clients demandent par leur nom et qui s’installent sans intervention sur son hyperviseur. C’est pourquoi presque toutes les listes commencent par un Ubuntu LTS et un Debian stable, ajoutent AlmaLinux ou Rocky pour les personnes dont les logiciels sont certifiés avec RHEL, puis placent Alpine, Arch et Fedora plus loin. Une fois que vous savez ce qu’est un VPS et comment l’image arrive sur le disque, le schéma devient clair : le fournisseur choisit des systèmes d’exploitation qui supportent une installation sans intervention et restent pris en charge plus longtemps que la durée moyenne de conservation d’un serveur par un client.

Ce choix vous engage au-delà du gestionnaire de paquets. Il détermine la mise à niveau que vous effectuerez dans trois ans, et celle-ci diffère complètement selon la famille. Debian et Ubuntu prennent en charge les mises à niveau majeures sur 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. Ce 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 logiciel que vous exécutez, 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 propre à la famille Debian ou à la famille Red Hat. Choisir une autre famille signifie donc traduire les instructions pendant toute la durée de vie de la machine. Choisissez la famille dont la politique de versions 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 en dessous signifie 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, tandis qu’une machine AlmaLinux renvoie ID_LIKE="rhel centos fedora". Le gestionnaire de paquets constitue un autre indice. apt et dpkg indiquent la famille Debian, dnf et rpm la famille Red Hat, apk Alpine et pacman Arch.

CentOS est-il encore une version gratuite de RHEL ?

Non. CentOS Linux 8, la dernière reconstruction portant ce nom, a atteint sa fin de vie le 31 décembre 2021. CentOS Linux 7 a atteint la fin de sa 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. AlmaLinux et Rocky Linux ont repris le rôle des reconstructions gratuites historiques, avec toutes deux une durée 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é pendant 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 amont 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 amont correspond à la révision Debian, et apt changelog <package> répertorie les changements qu’elle contient. Évaluer la sécurité d’un serveur Debian à partir de ses numéros de version donne toujours une conclusion erronée.

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

Seulement si vous la mettrez à jour selon un calendrier régulier. Une distribution rolling suppose que toutes les machines convergent 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 restera stable. Si vous attendez un an, la première mise à niveau deviendra l’opération risquée.

Qu’est-ce qu’une distribution immutable ou atomic change réellement ?

Elle modifie 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 est conservée comme entrée de démarrage pour permettre un rollback. La machine est ainsi soit entièrement mise à jour, soit entièrement dans son état précédent, sans état partiellement appliqué. En contrepartie, vous ne pouvez plus installer des logiciels en modifiant directement des fichiers sur le système. Les applications sont donc placées dans des conteneurs ou dans des paquets en couches.