GNU Coreutils 9.12 accélère cut et uniq et corrige une course des options récursives
La version 9.12 de GNU Coreutils, publiée le 14 septembre 2026, livre des gains mesurés — cut jusqu’à 4× plus rapide, uniq jusqu’à 2,5× — et corrige une course qui faisait échouer les commandes -R face à des fichiers supprimés en parallèle. Une sortie de maintenance qui rappelle que la boîte à outils GNU reste, face à sa réécriture Rust, le socle par défaut des distributions.
14 septembre 2026. GNU Coreutils 9.12 est publié sur le site officiel de GNU. 4×. C’est le gain de débit revendiqué pour cut -w sur des entrées typiques. 2026. Une réécriture concurrente en Rust, uutils, poursuit dans le même temps sa montée en maturité. Pourquoi c’est important : ls, cp, cut, sort ou uniq sont dans chaque image de conteneur et chaque script shell du monde, et la façon dont cette fondation évolue concerne directement les administrateurs comme les mainteneurs de distributions.
Les gains de performance mesurés
Coreutils 9.12 n’est pas une sortie spectaculaire, mais elle chiffre ses progrès, ce qui est rare pour une maintenance. Trois optimisations ressortent :
cut -wgagne jusqu’à 4× de débit sur des entrées typiques. Pour quiconque découpe des colonnes délimitées par des espaces dans des logs volumineux, c’est directement du temps de pipeline récupéré.uniq -cest jusqu’à 2,5× plus rapide sur les systèmes où les fonctions stdio sont déverrouillées — le comptage d’occurrences, brique de base de l’analyse de logs, en profite.sortutilise mieux la mémoire disponible et le parallélisme quand il lit depuis une entrée de taille inconnue, comme un pipe. C’est le cas le plus courant en pratique, et c’est précisément celui où les heuristiques précédentes étaient conservatrices.
Ces chiffres ne sont pas anecdotiques. Sur un parc de serveurs qui traitent des téraoctets de logs par jour, un facteur deux sur uniq -c ou quatre sur cut -w se traduit en temps CPU et en latence d’observabilité, sans changer une seule ligne de script.
Le cas de --reflink=auto mérite une précision. Sur les systèmes de fichiers à copy-on-write comme Btrfs ou XFS avec reflink, cp --reflink=auto tente une copie quasi instantanée en partageant les blocs. Quand cette tentative échoue — par exemple parce que l’espace de métadonnées d’un groupe d’allocation XFS est épuisé — l’ancien comportement pouvait faire échouer la copie entière. La bascule automatique vers une copie standard rend le comportement plus prévisible : la copie aboutit, au prix de l’espace disque.
La course corrigée sur les options récursives
La correction la plus intéressante concerne un bogue de longue date : chcon, chgrp, chmod, chown, du et ls échouaient en traversant des hiérarchies avec l’option récursive -R lorsque des fichiers étaient supprimés en parallèle. Le symptôme — un code de retour d’erreur ou une interruption de parcours — apparaissait sur des arborescences vivantes, exactement celles que l’on rencontre dans des répertoires partagés ou des builds concurrents.
Ce type de course est le symptôme d’un logiciel qui a été écrit pour un monde où le système de fichiers est statique pendant qu’on le parcourt, alors qu’il ne l’est jamais. Sa correction rend les commandes récursives fiables dans les environnements où d’autres processus écrivent et suppriment pendant le parcours — un cas que les CI/CD et les clusters de build connaissent bien.
Cette correction concerne directement les outils de sauvegarde et de synchronisation qui s’appuient sur cp -R, chown -R ou du pour parcourir des arborescences actives. Un du qui échoue au milieu d’un décompte d’espace, ou un cp -R qui s’interrompt parce qu’un fichier a été supprimé en parallèle, fausse les résultats sans toujours être détecté. Les systèmes de sauvegarde concurrente — comme ceux qui capturent des volumes pendant que des écritures continuent — sont les premiers bénéficiaires.
Nouvelles options et nouveaux systèmes de fichiers
La version apporte aussi quelques ajouts fonctionnels :
uname -A(ou--all-labeled) : affiche toutes les informations avec un libellé par ligne, une sortie plus lisible pour les scripts qui parsentuname.statettailreconnaissent désormais les types de systèmes de fichiers FailFS et NULLFS, utiles dans les environnements de test et les mounts synthétiques.cp,installetmvbasculent sur une copie standard quand--reflink=autoéchoue pour des raisons diverses — par exemple sur XFS quand un clone épuise l’espace de métadonnées d’un groupe d’allocation.mvavertit désormais quand la copie d’un attribut étendu échoue, au lieu d’échouer silencieusement ou de masquer la perte.
S’y ajoutent des correctifs discrets : un possible dépassement de tampon en lecture dans factor, plusieurs bogues spécifiques à Solaris, et diverses retouches. Rien de spectaculaire, mais chaque élément renforce la fiabilité d’outils dont on attend qu’ils ne surprennent jamais.
La place de Coreutils dans l’écosystème
GNU Coreutils n’est pas la seule implémentation des commandes de base. BusyBox fournit une version compacte à destination des systèmes embarqués et des images minimales — c’est lui que l’on trouve dans Alpine Linux. Les BSD maintiennent leurs propres versions de ls, cp ou sort. Mais c’est la version GNU qui sert de référence de compatibilité : ses options, ses comportements et ses codes de retour sont ce que les scripts supposent par défaut.
Cette position explique pourquoi une sortie de maintenance intéresse autant de monde. Un changement de comportement dans cp ou sort se propage dans des chaînes entières d’outils, des Makefiles aux pipelines de données. C’est aussi pourquoi GNU Coreutils avance lentement : la stabilité est un produit en soi, et chaque option ajoutée — comme uname -A — doit cohabiter avec des décennies de scripts qui parsent la sortie existante.
GNU en C face à la réécriture Rust
Le contexte rend cette sortie plus intéressante qu’elle n’en a l’air. En parallèle de GNU Coreutils, le projet uutils coreutils réécrit la même boîte à outils en Rust, avec pour arguments la sécurité mémoire et une approche moderne. Le blog ETTAYEB a déjà documenté cette trajectoire : là où GNU capitalise sur des décennies de stabilité et de compatibilité, uutils gagne du terrain sur la robustesse face aux bugs mémoire.
Cette 9.12 illustre ce que la voie C produit encore : des optimisations ciblées (cut, uniq, sort) et des correctifs de course qui exigent une connaissance fine des appels système. Elle illustre aussi sa limite — une course restée ouverte des années avant d’être traitée. Pour les distributions et les mainteneurs d’images, la question n’est pas de choisir un camp, mais de savoir quand la version Rust aura atteint la couverture suffisante pour devenir l’alternative crédible par défaut. En attendant, Coreutils 9.12 reste ce que l’on déploie partout.
Cette tension, le blog ETTAYEB l’a déjà explorée dans son analyse de Rust Coreutils 0.10 : la réécriture uutils progresse sur la couverture des options et la sécurité mémoire, mais la version GNU garde l’avantage de la maturité et de la compatibilité absolue. Pour les images de conteneurs, l’enjeu est concret : Debian et Ubuntu embarquent GNU Coreutils, tandis qu’Alpine préfère BusyBox pour la taille. La version 9.12 ne change pas ce partage, mais elle renforce le cas de la version GNU pour les images où la conformité des options et la performance des pipelines comptent plus que quelques mégaoctets.
Verdict
GNU Coreutils 9.12 est une sortie de maintenance qui ne changera pas votre vie, mais qui améliore silencieusement la fondation sur laquelle tout le reste repose.
Si vous traitez de gros volumes de logs ou de données textuelles, testez cut -w et uniq -c en version 9.12 : les gains de débit sont mesurables sans migration de script. Si vous gérez des distributions ou des images de conteneurs, intégrez cette version dès qu’elle atteint vos dépôts, ne serait-ce que pour la correction de la course -R qui touche les parcours récursifs en environnement concurrent. Si vous suivez la montée de la réécriture Rust, gardez cette sortie en tête comme étalon de ce que la version C sait encore faire, pendant que uutils continue de combler son écart.