Linux 7.3-rc1 clôt la fenêtre de fusion le 30 août. Linus Torvalds souligne sa taille, dont une grosse contribution graphique AMD. Le nombre de lignes ou de commits ne dit pas combien de vitesse votre machine va gagner.
Ce que mesure réellement l’annonce
Dans son message de publication, Torvalds décrit une grosse première candidate sans affirmer un classement exact à la deuxième place. Il attribue environ un tiers du patch au code graphique AMD et aux en-têtes de registres DCN6. L’illustration traduit cette proportion approximative en surfaces ; ce n’est pas notre propre comptage des lignes modifiées.
Une définition de registres peut ajouter beaucoup de lignes sans créer un chemin utilisé sur votre ordinateur. Inversement, quelques lignes dans l’ordonnanceur peuvent modifier le comportement de votre matériel. Taille du patch, prise en charge matérielle et performances répondent à des questions différentes.
Construire une comparaison exploitable
Choisissez un symptôme ou une charge avant le test. Pour une sortie de veille, relevez réveil, retour de l’affichage et reconnexion réseau. Pour du stockage, gardez jeu de données, système de fichiers, options de montage et état du cache identiques. Pour un jeu, fixez résolution, réglages et pilotes en espace utilisateur. Mélanger des pourcentages de benchmarks sans rapport ne prédit pas le résultat.
Utilisez une machine de test ou une installation récupérable avec une entrée de démarrage connue comme fiable. Gardez une copie des données importantes ailleurs. Notez les noyaux effectivement démarrés, le firmware et les modules tiers. Ces commandes inspectent le système sans modifier sa configuration :
uname -a
cat /proc/sys/kernel/taintedLa première identifie le noyau actif. Une valeur tainted non nulle est un masque de bits décrivant des conditions utiles au diagnostic ; elle ne prouve pas automatiquement une panne matérielle et n’explique pas seule une régression.
Transformer l’échec en signalement
Le guide de signalement du noyau explique comment vérifier une version amont récente, documenter la reproduction et identifier la dernière version fonctionnelle. Suivez ses indications pour trouver le bon sous-système, plutôt que d’envoyer un journal complet sans explication à un mainteneur choisi au hasard.
Un rapport utile commence par quatre éléments concrets : action, résultat attendu, résultat obtenu et version où le comportement change. Joignez les journaux pertinents après avoir vérifié les données privées qu’ils contiennent. Si le défaut apparaît après dix veilles, précisez-le ; un réveil réussi ne le réfute pas. Répéter la même séquence sur les deux versions apporte davantage que changer plusieurs pilotes à la fois.
Cet article reste consacré à rc1 : il n’annonce pas une version stable de Linux 7.3. La date historique est conservée tandis que l’explication est corrigée.
Sources
Vérification du message de Torvalds ; retrait du classement exact non établi et des performances de sous-systèmes amalgamées, ajout d’une méthode de signalement des régressions.