La décision Fedora porte sur un jeu supplémentaire de paquets optimisés. Elle ne retire pas le support des anciens processeurs x86-64 et ne garantit pas l’arrivée du projet dans Fedora 46.
La décision figure dans le ticket
Le ticket FESCo 3599 enregistre le refus pour Fedora 45 le 17 août, avec cinq votes favorables au refus, sans opposition ni abstention. Les auteurs sont invités à resoumettre pour Fedora 46 avec comparaisons de performances, analyse d’impact sur l’infrastructure et détails sur les supports d’installation.
La proposition de changement contient encore des notes de version provisoires décrivant la sélection automatique des paquets v3. Elles décrivent le résultat envisagé, pas une fonction approuvée et livrée. L’ancien article situait incorrectement la décision au mardi et présentait la direction future comme acquise.
Une variante supplémentaire, pas un minimum universel
Le projet conserverait les compilations x86-64 existantes en ajoutant des variantes v3, sélectionnées selon les capacités du processeur. Outils de compilation, dépôts et composition des images doivent tous gérer ce choix.
L’année d’achat du matériel constitue un mauvais test de compatibilité. L’ensemble des fonctions exposées au système compte réellement. Une machine virtuelle peut voir un modèle de CPU restreint malgré un hôte compatible avec des instructions récentes. Une image choisie sur un hôte peut ensuite démarrer ailleurs : cibles de migration et de récupération entrent aussi dans l’évaluation.
Mesurer ce qui change réellement
Certaines bibliothèques critiques sélectionnent déjà une implémentation optimisée à l’exécution. Recompiler les paquets environnants pour v3 ne prouve pas qu’un chemin déjà optimisé accélère encore. À l’inverse, le compilateur peut améliorer du code qui ne disposait pas d’implémentation spécialisée sélectionnée à l’exécution.
Prenons un exemple original : une tâche dure 100 secondes, dont 30 dans le calcul concerné et 70 dans du travail inchangé. Diviser la première partie par deux donne 15 + 70 = 85 secondes, soit 15 % de temps total en moins. L’application ne devient pas deux fois plus rapide. Ce sont des valeurs hypothétiques, pas des benchmarks Fedora.
Comparez source, compilateur, options et charge identiques en faisant varier le niveau cible. Relevez correction, durée et variabilité, puis examinez coût de compilation, stockage et vérification du jeu supplémentaire. Tant qu’un projet révisé n’est pas approuvé et livré, les exigences de la version réelle priment sur les notes provisoires pour administrer un parc.
Revue du 8 septembre : annonce vérifiée, affirmations corrigées et illustration explicative originale ajoutée.