5 distributions Linux dont vous n'avez peut-être jamais entendu parler

La meilleure distribution Linux pour les développeurs est celle qui fait fonctionner les chaînes de compilation, les conteneurs et les pilotes GPU avec le moins de friction possible. CachyOS, Bazzite, Nobara, Vanilla OS et Chimera Linux font chacune un compromis différent sur ces trois points.

La plupart des classements des « meilleures distros » sont en réalité des benchmarks de jeu. Ils vous donnent des fréquences d’images, mais ne vous disent pas si npm install, Docker ou votre IDE se comporteront correctement un mardi matin.

Votre machine n’a plus besoin de reproduire l’environnement de production, car les conteneurs s’en chargent désormais. Le choix du système hôte se résume donc à trois critères : les pilotes, le comportement des mises à jour et la façon dont vous installez vos outils. Cet article passe en revue cinq distributions moins connues à travers ces trois critères. Omarchy et Garuda Linux font l’objet d’articles dédiés et ne sont donc pas abordées ici.

CachyOS : une Arch optimisée pour les performances

CachyOS est une distribution en rolling release basée sur Arch. Elle se distingue d’une Arch standard sur deux points : un noyau optimisé par CachyOS qui utilise par défaut un ordonnanceur EEVDF ajusté (BORE et d’autres ordonnanceurs sont disponibles en option), et des dépôts de paquets compilés pour x86-64-v3, x86-64-v4 et AMD Zen 4/5. Elle convient aux développeurs qui apprécient déjà Arch et veulent que l’optimisation soit faite pour eux.

• Paquets : les dépôts Arch plus l’AUR. Les CLI atypiques, les serveurs de langage et les SDK de niche ne sont généralement qu’à un paquet de distance.
• Avant de pouvoir travailler : installez vos environnements d’exécution et Docker ou Podman depuis les dépôts. Rien ne vous en empêche.
• NVIDIA : le packaging NVIDIA d’Arch et la page NVIDIA de l’Arch Wiki s’appliquent directement.
• Au quotidien : les mises à jour du noyau, de Mesa et de la chaîne de compilation arrivent en continu, et vous êtes censé lire les actualités avant les mises à niveau importantes.

Le prix à payer : la maintenance propre au rolling release. Si une mise à jour tourne mal un jour de livraison, c’est à vous de la réparer.

Bazzite : Fedora Atomic avec des images NVIDIA dédiées

Bazzite est une distribution immuable dont le système de base est une image Fedora Atomic en lecture seule. Elle se met à jour d’un seul bloc, et il suffit de démarrer sur l’image précédente pour revenir en arrière. Vous n’installez donc pas vos outils de développement globalement comme vous le feriez avec dnf. Elle convient aux développeurs qui veulent une machine qui reste cohérente et qui acceptent de travailler dans des conteneurs.

• Paquets : Flatpak pour les applications graphiques, la superposition (layering) rpm-ostree pour les logiciels de l’hôte, et des conteneurs pour les chaînes de compilation. Bazzite intègre Distrobox. Si vous voulez Docker prêt à l’emploi, il est fourni avec la variante Bazzite DX, et non avec l’image standard.
• Avant de pouvoir travailler : créez un conteneur de développement.
• NVIDIA : Bazzite propose des images spécifiques pour NVIDIA. Choisissez la vôtre sur la page de téléchargement.
• Au quotidien : les mises à jour sont atomiques et réversibles, mais votre répertoire personnel, vos conteneurs et vos paquets superposés restent sous votre responsabilité.

Sur un système Fedora immuable, vous superposez les paquets au niveau de l’hôte sur l’image avec rpm-ostree, et ils prennent effet après un redémarrage. Les chaînes de compilation des langages vont dans un conteneur Distrobox ou Toolbx qui partage votre répertoire personnel :

rpm-ostree install zsh          # host layer, applied on next boot
systemctl reboot

distrobox create --name dev --image registry.fedoraproject.org/fedora:latest
distrobox enter dev
sudo dnf install nodejs gcc make   # inside the container only

rpm-ostree rollback             # revert to the previous deployment

Tout ce que vous installez dans dev reste en dehors de l’image de l’hôte, et supprimer le conteneur le fait disparaître.

La base en lecture seule de Bazzite bouscule les habitudes. Peut-être avez-vous l’habitude de régler les problèmes avec sudo et un éditeur de texte, et maîtrisez-vous parfaitement les permissions et la propriété des fichiers. Sur Fedora Atomic, /usr est en lecture seule. /etc reste accessible en écriture, mais OSTree fusionne vos modifications à chaque nouvelle image. Un autre piège vous attend : un IDE empaqueté en Flatpak s’exécute dans un bac à sable (sandbox) et peut donc ne pas voir les compilateurs présents dans votre conteneur ou sur l’hôte, à moins de le configurer en conséquence.

Le prix à payer : chaque installation d’outil impose de décider d’abord s’il a sa place sur l’hôte, dans un conteneur ou dans un Flatpak.

Nobara : Fedora, sans les aspérités

Nobara est une Fedora classique et modifiable, à laquelle s’ajoutent des codecs multimédias, les pilotes NVIDIA et des correctifs du noyau orientés jeu. La majeure partie de la documentation Fedora et vos habitudes avec dnf restent valables telles quelles. Maintenue par GloriousEggroll, elle convient aux utilisateurs de Fedora lassés de configurer codecs et pilotes après chaque installation.

• Paquets : dnf, Flatpak et l’écosystème Fedora, plus les dépôts propres à Nobara.
• Avant de pouvoir travailler : presque rien. Installez vos environnements d’exécution et votre moteur de conteneurs comme vous le feriez sous Fedora.
• NVIDIA : préinstallés, ce qui élimine la source de friction la plus fréquente au premier démarrage sous Fedora.
• Au quotidien : un système modifiable. Vous pouvez tout modifier, et donc tout casser.

Le prix à payer : un projet plus modeste que Fedora. En cas de panne, vous devez diagnostiquer les correctifs de Nobara en plus du code upstream.

Vanilla OS : immuable et centrée sur les conteneurs

Vanilla OS conserve un système de base immuable et déplace l’installation des logiciels dans des conteneurs. Installer un compilateur commence par choisir le conteneur dans lequel il sera installé, et non le dépôt dont il provient. Elle convient aux développeurs qui ont régulièrement besoin de paquets issus de plusieurs distributions sur une même machine.

• Paquets : l’hôte est géré par ABRoot, qui applique chaque mise à jour sur une seconde partition racine et bascule dessus au redémarrage suivant. Apx gère des conteneurs basés sur d’autres distributions et rend leurs gestionnaires de paquets accessibles depuis l’hôte. Flatpak couvre les applications graphiques.
• Avant de pouvoir travailler : créez un conteneur Apx pour chaque famille de chaînes de compilation.
• NVIDIA : consultez la documentation du projet pour votre matériel.
• Au quotidien : les mêmes compromis liés à l’immuabilité que sur Bazzite s’appliquent, mais via les outils propres à Vanilla plutôt que rpm-ostree.

Le prix à payer : des outils spécifiques à Vanilla. La documentation de Fedora Atomic et d’Arch ne s’y transpose pas directement.

Chimera Linux : la véritable originale

Chimera Linux est une distribution indépendante en rolling release qui évite GNU autant que possible. Elle utilise musl au lieu de glibc, les outils de base de FreeBSD au lieu des GNU coreutils, LLVM/Clang comme chaîne de compilation système et dinit comme système d’init. Les paquets sont gérés par apk-tools. Elle convient aux développeurs système et à tous ceux qui veulent tester la portabilité de leur code.

• Paquets : les dépôts apk. Tout ce qui repose sur le packaging d’Arch ou de Fedora nécessite un conteneur.
• Avant de pouvoir travailler : vérifiez que vos environnements d’exécution fonctionnent avec musl.
• NVIDIA : consultez la documentation du projet concernant la prise en charge de NVIDIA.
• Au quotidien : les scripts shell écrits pour les GNU coreutils peuvent mal se comporter, car les outils BSD utilisent des options différentes.

Une distribution basée sur musl comme Chimera Linux compile et exécute votre propre code sans difficulté. Les binaires précompilés liés à glibc sont une autre affaire : les CLI de fournisseurs et les paquets qui ne publient que des builds glibc risquent de ne pas fonctionner sans couche de compatibilité ou conteneur glibc.

Le prix à payer : les présupposés de l’écosystème. La plupart des binaires distribués sont compilés pour glibc.

Quelle distribution Linux choisir pour développer ?

• Si vous vivez dans l’AUR et que les mises à jour en continu ne vous dérangent pas, CachyOS vous offre une Arch déjà optimisée.
• Si vous voulez un système stable et que développer dans des conteneurs vous convient, le modèle d’images de Bazzite et Distrobox répondent à ce besoin.
• Si vous connaissez déjà Fedora et voulez simplement que NVIDIA et les codecs soient réglés, Nobara préserve vos habitudes.
• Si vous avez régulièrement besoin de paquets issus de plusieurs distributions sur une même machine, Vanilla OS place chaque chaîne de compilation dans son propre conteneur Apx.
• Si vous voulez un système atypique pour tester la portabilité de votre code, Chimera fera ressortir chaque présupposé lié à glibc ou à GNU.

Aucune de ces distributions ne change l’environnement d’exécution de votre code en production. Le choix détermine la manière dont les chaînes de compilation arrivent sur la machine, dont les mises à jour sont appliquées, et la quantité de travail sur les pilotes nécessaire avant d’ouvrir votre éditeur. Identifiez la situation qui correspond à la vôtre, installez la distribution adaptée sur une partition libre et reconstruisez-y l’environnement de votre projet actuel avant de vous engager.

FAQ

Faut-il redémarrer à chaque exécution de rpm-ostree install sur Bazzite ou Fedora Atomic ?

Non, pas si vous ne faites qu'ajouter des paquets. Par défaut, chaque opération rpm-ostree est hors ligne et prend effet au démarrage suivant, mais rpm-ostree install --apply-live (forme courte -A) applique immédiatement les paquets nouvellement superposés au système en cours d'exécution. L'application à chaud ne fonctionne que pour les ajouts de paquets, sans autre modification en attente. Les suppressions nécessitent toujours un redémarrage, et rpm-ostree apply-live --reset revient à l'arborescence démarrée.

CachyOS fonctionne-t-elle sur les anciens processeurs qui ne prennent pas en charge x86-64-v3 ?

Oui. CachyOS conserve un dépôt x86-64 générique en plus de ses builds x86-64-v3, x86-64-v4 et Zen 4/5. Lors de l'installation, l'installateur et le script de configuration des dépôts détectent les capacités du processeur et sélectionnent le niveau de dépôt le plus adapté. Les processeurs sans AVX2 reçoivent les paquets génériques : la base Arch en rolling release et les outils CachyOS restent donc disponibles. La commande /lib/ld-linux-x86-64.so.2 --help indique les niveaux pris en charge par votre processeur.

Quelle est la différence entre Distrobox et Toolbx pour les conteneurs de développement ?

Les deux créent des conteneurs persistants qui partagent votre répertoire personnel avec l'hôte. Toolbx fonctionne uniquement avec Podman et donne les meilleurs résultats avec des images de type Fedora. Distrobox s'appuie sur Podman ou Docker, se rabat sur son propre gestionnaire Lilipod et exécute des images de presque n'importe quelle distribution. Toolbx suffit pour des conteneurs Fedora sur Fedora Atomic. Distrobox est préférable lorsque vous avez besoin d'un espace utilisateur Arch, Ubuntu ou Alpine, par exemple pour un outil fournisseur distribué uniquement au format .deb.

La version Flatpak de VS Code peut-elle utiliser les compilateurs installés dans Distrobox ou sur l'hôte ?

Pas par défaut. Le paquet VS Code de Flathub s'exécute dans un bac à sable qui n'a pas accès aux SDK installés sur l'hôte : les chaînes de compilation présentes dans un conteneur Distrobox ou superposées avec rpm-ostree restent donc invisibles. Les notes du paquet proposent trois solutions de contournement : exécuter les commandes de l'hôte via flatpak-spawn --host ou host-spawn, configurer le terminal intégré pour qu'il utilise un shell de l'hôte, ou installer dans le bac à sable des extensions du SDK Freedesktop, comme le SDK Go ou .NET.