CachyOS Is Not The Problem
Cette vidéo analyse le succès de CachyOS non pas comme une preuve de supériorité technique, mais comme le révélateur d’une maladie culturelle dans l’écosystème Linux : la confusion entre hype, benchmarks et véritable valeur infrastructurelle.
SYNTHÈSE STRUCTURÉE
Le paradoxe CachyOS : six fois plus de trafic qu’Arch Linux
L’intervenant ouvre avec des chiffres précis issus de DistroWatch : CachyOS reçoit environ 3 800 hits par jour contre 640 pour Arch Linux, soit un rapport de six pour un. Il souligne que CachyOS est une dérivée d’Arch, pas un système écrit de zéro. « Cashios did not come from nowhere. It’s not an operating system written from scratch. It is Arch Linux with an installer », rappelle-t-il. Ce paradoxe pose une question fondamentale : comment une dérivée peut-elle éclipser son projet parent à ce point ? La réponse n’est pas « CachyOS est meilleur », mais plutôt « des milliers de personnes veulent Arch sans pouvoir y accéder ».
La vraie mesure : curiosité contre usage réel
L’intervenant anticipe l’objection que DistroWatch mesure la curiosité, pas l’utilisation. Il concède que d’autres métriques confirment un usage réel : environ 14 % des systèmes Linux sur le Steam Hardware Survey, et une première place sur ProtonDB pour les rapports de compatibilité en mars 2026. Mais il note l’absence de CachyOS dans les classements W3Techs des OS serveurs web et dans les enquêtes Stack Overflow sur les OS de développement. « It’s dominant where people play. It’s invisible where people work and deploy and build things that have to keep running. » Cette distinction entre usage ludique et usage professionnel est cruciale pour comprendre la portée réelle du projet.
La distribution comme infrastructure, pas comme produit
L’intervenant développe une métaphore filée : une distribution Linux est un pont, pas un benchmark. « A distribution is not a set of packages. A distribution is infrastructure. It’s organization. It’s governance. It’s a build chain. » Il énumère ce qui fait réellement une distribution : l’équipe qui répond aux vulnérabilités, l’archive historique, la politique de sécurité, la capacité à garantir la continuité quand les fondateurs disparaissent. Cette vision s’oppose frontalement à l’évaluation par les performances pures, qui changerait la « meilleure distribution » tous les six mois à chaque nouvelle version de compilateur.
Les limites réelles des optimisations CachyOS
L’intervenant cite les tests de Michael Larabel sur Phoronix (février 2024) sur une workstation Threadripper, un environnement idéal pour ces optimisations. Résultats : « In Blender. No meaningful difference. In Python. Essentially nothing. In Firefox. Again, no real perceptible difference. » Le gain le plus net apparaît en PHP, un workload très spécifique. Il souligne aussi un point technique souvent ignoré : les paquets précompilés comme Discord, Steam ou les applications Electron ne sont pas reconstruits avec les optimisations de CachyOS. « An enormous slice of the modern desktop simply does not benefit from those optimizations at all. » C’est une conséquence technique, pas une critique, mais elle mérite d’être dite.
Le vrai chef-d’œuvre : l’outil cachyos-hardware-detection
L’intervenant identifie un programme méconnu comme la véritable innovation du projet : cachyos-hardware-detection (ou chwd). C’est un système de détection matérielle écrit en Rust, fonctionnant à partir de profils matériels vérifiés, configurant automatiquement les bons drivers et vérifiant la présence réelle du matériel avant toute modification. « It’s released under the GPL and it can be installed on plain Arch Linux, not just on CachyOS. » Ce point est essentiel : c’est une contribution à l’écosystème entier, pas un avantage exclusif. « That is the moment a derivative stops being merely a derivative and becomes innovation. »
La sécurité comme processus, pas comme fonctionnalité
L’intervenant introduit le concept de supply chain security avec une métaphore architecturale : avoir les plans d’une maison ne garantit pas que la maison construite correspond aux plans. « We can read the source of OpenSSL. We can read the source of the kernel. We can read the source of systemd. But who guarantees that the binary downloaded from the mirror was actually compiled from that source? » Il distingue clairement reproductibilité et sécurité : un binaire reproductible peut contenir un bug ou un backdoor, mais au moins il est vérifiable. « Trust becomes verifiable. »
Le conflit fondamental : optimisation contre reproductibilité
CachyOS utilise des techniques comme le Profile-Guided Optimization (PGO) et l’optimisation post-link, qui dépendent de données collectées pendant l’exécution. L’intervenant explique que ces méthodes réorganisent le binaire en fonction du comportement observé, ce qui rend deux compilations du même source potentiellement différentes. « On one side, we want to squeeze out every clock cycle. On the other, we want to verify every single bit. Those two things do not always get along. » Ce n’est pas une négligence, c’est un choix assumé : « Every engineering decision carries a renunciation. »
La crise de l’AUR en 2026 et ses implications pour CachyOS
L’intervenant rappelle les incidents de sécurité sur l’Arch User Repository : environ 1 500 paquets compromis en juin 2026 via un mécanisme d’adoption de paquets abandonnés, avec un payload combinant credential stealer et rootkit ciblant tokens d’accès et clés SSH. Une deuxième vague avec code obfusqué est apparue, et l’équipe DevOps d’Arch a temporairement désactivé l’adoption de paquets en août. L’intervenant pose alors une question cruciale : CachyOS propose des paquets pré-construits depuis l’AUR, signés avec sa propre clé et distribués via le canal de mise à jour standard. « The user is no longer trusting an AUR maintainer. The user is trusting the distribution. » Et il conclut : « I am not saying anything happened. I am saying that if it did, the mechanism that would make it visible does not exist. »
Les sept piliers d’évaluation d’une distribution
L’intervenant propose une méthode alternative aux benchmarks, basée sur sept critères :
- Sécurité : existence d’une équipe dédiée, advisories publics, suivi des vulnérabilités
- Chaîne de build : reproductibilité, transparence, vérifications indépendantes
- Mémoire : archives historiques, snapshots, capacité à reconstruire le passé
- Gouvernance : fondation, charte, procédures, indépendance vis-à-vis du fondateur
- Continuité : le « bus factor » — combien de personnes doivent disparaître pour que le projet soit en crise
- Contribution externe : patches upstream, documentation, outils partagés
- Temps : la capacité à durer, car « it’s easy to maintain a distribution for 6 months, much less easy for 6 years, almost impossible for 30 »
La conclusion paradoxale : CachyOS n’est pas le problème
L’intervenant refuse la conclusion attendue que CachyOS serait surévalué. « I believe CachyOS is one of the best projects to come out of the Arch ecosystem in years. » Le problème est ailleurs : « We are the ones who turned DistroWatch into a world ranking. We are the ones who reduced 25 years of engineering to a neofetch screenshot. » Le succès de CachyOS mesure un besoin réel d’accessibilité, pas une supériorité technique. « CachyOS does not prove that Arch has been surpassed. It proves how hard Arch is to reach. »
CONCEPTS CLÉS
- Reproducible builds : méthode permettant de compiler le même code source sur différentes machines et d’obtenir un résultat bit-à-bit identique, rendant la confiance vérifiable
- Supply chain security : sécurité de la chaîne d’approvisionnement logicielle, couvrant tout ce qui se passe avant que le logiciel n’atteigne l’ordinateur de l’utilisateur
- Profile-Guided Optimization (PGO) : technique d’optimisation qui collecte des données d’exécution pour réorganiser le binaire