Fedora 45 gardera exactement la même base x86-64 que les versions précédentes. Le comité d'ingénierie et de pilotage de Fedora, le FESCo, a rejeté la proposition de construire un jeu de paquets parallèle en x86-64-v3, celui qui pourrait supposer AVX et AVX2, FMA et BMI2, et réclame davantage de mesures de performance ainsi qu'un plan pour les supports d'installation avant de réexaminer le sujet, Fedora 46 étant la cible réaliste la plus proche. Cela fait un an de retard pour un changement que RHEL 10 a déjà tranché, et que Microsoft souhaite pour Azure Linux, bâti sur Fedora.
The short answer
Le comité d'ingénierie et de pilotage de Fedora a rejeté le changement qui aurait construit un second jeu de paquets au niveau x86-64-v3 pour Fedora 45, à côté de la base existante. Le FESCo veut davantage de mesures de performance et une réponse aboutie sur les supports d'installation avant de reconsidérer la question, et invite à resoumettre pour Fedora 46. RHEL 10 exige déjà x86-64-v3, et Microsoft a un intérêt dans l'affaire via Azure Linux, bâti sur Fedora.
Fedora a passé des mois à débattre de la compilation de ses paquets pour du matériel de la dernière décennie plutôt que pour du matériel de 2003. Mardi, la réponse est tombée : pas cette année.
Ce qui était sur la table
La proposition était plus prudente que le titre ne le laisse croire. Elle ne demandait pas à Fedora d'abandonner les processeurs anciens. Elle demandait un jeu de paquets supplémentaire et parallèle, construit au niveau x86-64-v3, la base x86-64 actuelle restant en place pour qui possède une machine datée.
x86-64-v3 est le troisième des quatre niveaux de micro-architecture que l'industrie a définis pour cesser d'énumérer des modèles de processeurs. Il suppose AVX et AVX2, FMA, BMI et BMI2, MOVBE et XSAVE, ce qui recouvre Intel Haswell et plus récent, ou AMD Excavator et plus récent. En gros, une machine x86 de la dernière décennie remplit la condition.
Le modèle de livraison était conçu pour être invisible. Selon la page de changement, l'ingénierie de version publierait des dépôts et des images v3, et DNF5 sélectionnerait de façon transparente la construction v3 sur un système compatible. Le travail derrière cette invisibilité n'était pas mince : étendre Koji pour les constructions supplémentaires, ajouter les options de compilation dans redhat-rpm-config, apprendre la logique de sélection à DNF5, et faire évoluer Pungi pour générer les composes. Le tout porté par Lleyton Gray, Kyle Gospodnetich et Owen Zimmerman, visant Fedora Linux 45, et suivi dans le ticket 13310 de l'ingénierie de version.
Pourquoi le comité a refusé
Le FESCo n'a pas soutenu que les paquets v3 étaient une mauvaise idée. Il a soutenu que la démonstration n'était pas faite, sur deux points précis.
Le premier, les données. Le comité attendait des mesures de performance assez solides pour justifier de quasiment doubler une partie de la chaîne de construction et de compose, et ce qui est arrivé ne permettait pas de trancher. Le second, les supports d'installation. Dès lors que deux jeux de paquets existent, une image d'installation doit toujours démarrer sur l'ancienne base, puis déterminer lequel poser, et la matrice d'images et de composes à construire, tester et diffuser grossit d'autant. Le FESCo a demandé une réponse aboutie sur ce point avant d'avancer.
Ces deux objections se lisent facilement comme de la bureaucratie, et n'en sont généralement pas. Un changement de base à l'échelle d'une distribution est une porte à sens unique pour la version qui l'accueille, et le coût est payé par l'ingénierie de version et par chaque exploitant de miroir, à perpétuité.
La partie que personne n'a bien mesurée
La réponse honnête sur les gains est qu'ils varient énormément, et c'est exactement ce qui rend la demande de données raisonnable.
Le code qui se vectorise proprement peut tirer un bénéfice net d'une cible v3, et la manipulation de bits BMI2 apparaît dans la compression, l'analyse syntaxique et le hachage. Mais une grande partie de ce que livre une distribution est de la colle : gestion de configuration, traitement de chaînes, outillage limité par les entrées et sorties. Rien de tout cela ne bouge parce que vous avez parlé d'AVX2 au compilateur.
Un second effet réduit encore le gain attendu, et il est sous-estimé dans ces débats. Les bibliothèques où le SIMD compte le plus, et les chemins chauds de choses comme OpenSSL, les routines de chaînes de la glibc ou les codecs vidéo, pratiquent déjà la répartition à l'exécution : elles testent les capacités du processeur au chargement et sautent vers l'implémentation optimisée. Sur ces chemins, votre machine exécute du code v3 ou mieux depuis des années, quelle qu'ait été la cible de compilation du paquet. Ce qu'une base v3 apporte, c'est la longue traîne, tout ce que personne n'a optimisé à la main. Cette traîne vaut quelque chose à l'échelle d'un système entier, mais c'est précisément le type d'amélioration diffuse qui exige une mesure soignée plutôt qu'un test sur le seul cas qui la met en valeur.
Qui le voulait, et qui l'a déjà
La pression ne vient pas seulement des passionnés. RHEL 10 exige déjà x86-64-v3 comme plancher, ce que Red Hat a justifié sur le même terrain : presque tout système Intel ou AMD déployé ces dix dernières années franchit la barre. Microsoft a également un intérêt, puisque la nouvelle base Azure Linux est bâtie sur Fedora et qu'une base x86-64-v3 lui convient. Des distributions orientées performance comme CachyOS livrent des constructions optimisées depuis un moment, ce qui constitue une donnée de terrain, même non contrôlée.
Le sens de l'histoire n'est donc pas en cause. Le rejet du changement pour Fedora 45 dit quelque chose sur l'état de préparation, pas sur la destination, exactement comme le travail sur les profils d'alimentation de Fedora 44 parlait de valeurs par défaut plutôt que de capacité.
Quoi en faire
Rien d'urgent, et c'est l'enseignement pratique. Fedora 45 se comportera comme les versions de Fedora qui la précèdent du point de vue de votre processeur, rien de ce que vous exécutez ne cesse d'être supporté, et aucun parc n'a besoin d'être réinstallé.
Deux points méritent d'être notés pour la planification. Si vous exploitez encore en production du matériel x86 antérieur à Haswell ou Excavator, l'écosystème vous dépasse depuis un moment et RHEL 10 est déjà parti : intégrez-le à votre prochain renouvellement plutôt qu'à votre prochaine mise à jour. Et si vous construisez vos propres paquets pour un parc dont vous maîtrisez le matériel, la cible v3 vous est ouverte depuis toujours. La difficulté à laquelle Fedora se confronte n'est pas l'option de compilation, c'est de livrer deux jeux de paquets à des millions de machines sans que personne ne s'en aperçoive.
Sources et pour aller plus loin
- Fedora x86-64-v3 Optimized Packages Pushed Back To At Least Fedora 46, Phoronix, 18 août 2026
- Changes/Build x86-64-v3 Packages, wiki du projet Fedora
- F45 Change Proposal: Build x86-64-v3 Packages, Fedora Discussion
- Fedora Yet To Decide On x86_64-v3 Packages For Fedora Linux 45, via LXer
Questions fréquentes
Qu'est-ce que x86-64-v3, exactement ?
C'est l'un des quatre niveaux de micro-architecture qu'AMD, Intel, Red Hat et SUSE se sont accordés à définir pour que les distributions puissent parler de capacités processeur sans énumérer des modèles. Le niveau v1 correspond au x86-64 d'origine, de 2003. Le niveau v3 suppose AVX et AVX2, FMA, BMI et BMI2, MOVBE, XSAVE et une poignée d'instructions associées, ce qui correspond en pratique à Intel Haswell et plus récent, ou AMD Excavator et plus récent. Le niveau v4 ajoute AVX-512, et c'est là que le paysage matériel redevient compliqué. L'intérêt de ces niveaux est qu'un paquet peut être construit pour un ensemble de capacités plutôt que pour une liste de modèles.
Que demandait précisément la proposition Fedora ?
Pas une coupure nette. Le changement, porté par Lleyton Gray, Kyle Gospodnetich et Owen Zimmerman et visant Fedora Linux 45, proposait de construire un jeu de paquets supplémentaire au niveau x86-64-v3 tout en conservant intacts les paquets de la base x86-64 actuelle, afin que les machines antérieures à Haswell continuent de fonctionner. La livraison devait rester transparente : l'ingénierie de version publierait des dépôts et des images v3, et DNF5 choisirait automatiquement les paquets v3 sur les systèmes compatibles. Le travail listé n'était pas mince : étendre Koji, ajouter les options de compilation dans redhat-rpm-config, la logique de sélection dans DNF5 et les évolutions de Pungi pour la génération des composes, suivies dans le ticket 13310 de l'ingénierie de version.
Pourquoi le FESCo a-t-il refusé ?
Pour deux raisons, procédurales plutôt que philosophiques. Le comité attendait depuis des mois des mesures de performance assez solides pour justifier le coût, et il n'a pas jugé suffisant ce qu'il a reçu. Il voulait aussi une réponse concrète sur le fonctionnement des supports d'installation dans un monde à deux jeux de paquets, question légitime : une image d'installation doit démarrer sur l'ancienne base, puis décider quoi installer, et la matrice des images et des composes grossit d'autant. Le FESCo a rejeté le changement pour Fedora 45 mais a explicitement laissé la porte ouverte à une nouvelle soumission pour Fedora 46 une fois ces manques comblés.
Combien de performance est réellement en jeu ?
C'est précisément la question que le comité a jugée sans réponse, et il vaut mieux l'assumer que répéter un chiffre que personne n'a publié. Les gains d'une base v3 sont réels mais très inégaux : le code qui se vectorise bien, ou qui s'appuie sur la manipulation de bits BMI2, peut bouger sensiblement, tandis qu'une grande part d'une distribution est faite de colle, d'analyseurs et de travail limité par les entrées et sorties, qui ne bougera pas du tout. Beaucoup de bibliothèques sensibles à la performance pratiquent déjà la répartition à l'exécution : elles testent les capacités du processeur au chargement et choisissent un chemin optimisé. Le code le plus chaud tourne donc souvent déjà en version rapide, quelle que soit la base de compilation. C'est exactement pourquoi des mesures crédibles à l'échelle d'une distribution sont difficiles, et pourquoi le FESCo les réclame.
Est-ce que cela me concerne aujourd'hui ?
Seulement si vous prépariez de la capacité ou des images autour de ce changement. Fedora 45 se comportera comme Fedora 44 sur ce point, rien ne change dans votre déploiement existant et aucun matériel ne devient non supporté. Si vous utilisez RHEL 10 ou une reconstruction, vous êtes déjà sur une base v3, ce qui rappelle utilement que tout ce qui est antérieur à Haswell ou Excavator quitte discrètement les matrices de support depuis un moment. Et si vous construisez vos propres paquets pour un parc dont vous maîtrisez le matériel, rien ne vous empêche de compiler dès aujourd'hui avec la cible v3, chemin qu'ont pris CachyOS et d'autres distributions orientées performance.