En cette traditionnelle période de vœux lors du changement d’année, voyons ce qui devrait… changera… pourrait éventuellement changer ou non. Donc une nouvelle fois encore retour sur nos accomplissements passés et projection dans le futur, vers ce que nous aimerions voir plus sur notre site préféré et écouter plus dans notre podcast préféré.

Quatre personnes se sont prêtées au jeu de cette dépêche, pas vraiment de vœux, mais un peu quand même. En vrac dans les accomplissements : retours d’expérience, accessibilité, rencontres, arkéologie, transmission, fiabilité, migration, vote électronique, technocritique, documentation et programmation. L’année qui vient, sur LinuxFr.org et Projets Libres, promet d’être fédérée, pérenne, humaine, sobre, excitante, écrite et écoutée, réutilisable, réparable et résiliente.

Sommaire

• Benoît (Oumph) Sibaud
  • Accomplissements, réalisations, progrès de l’année 2025
  • Ce que je voudrais faire, apprendre ou approfondir en 2026
  • Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)
• Walid (Wawa) Nouh
  • Accomplissements, réalisations, progrès de l’année 2025
  • Ce que je voudrais faire, apprendre ou approfondir en 2026
  • Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)
• vmagnin (Vincent)
  • Accomplissements, réalisations, progrès de l’année 2025
  • Ce que je voudrais faire, apprendre ou approfondir en 2026
  • Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)
• Ysabeau
  • Accomplissements, réalisations, progrès de l’année 2025
  • Ce que je voudrais faire, apprendre ou approfondir en 2026
  • Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)
• Pour finir

Benoît (Oumph) Sibaud

Accomplissements, réalisations, progrès de l’année 2025

Commençons par le serpent de mer de la réduction du retard côté adminsys pour LinuxFr.org : une plus grande partie des services est maintenant portée par une distribution récente (Debian Trixie), avec un mélange de conteneurs lxc et docker. Évidemment on passe toujours trop de temps à gérer du spam et des pénibles. J’ai eu l’occasion de rejouer avec des cartes DRAC pendant les incidents, d’écrire des comptes-rendus d’incident (ne jamais négliger leur importance) et de faire un peu plus de systemd.
J’ai participé au stand et aux animations sur place lors de la conférence Open Source eXPerience Paris et c’était toujours agréable et remotivant de voir d’autres personnes de l’équipe, de notre lectorat, des libristes connus de longue date et des nouvelles personnes. Le 28 juin 2025, on fêtait les deux ans de la politique de minimisation des données et il ne s’est rien passé car la prochaine étape est en juin 2026 (les premiers comptes avec trois ans d’inactivité).

Je suis satisfait d’une certaine fiabilité en termes de contenus publiés : les rétrospectives toutes les quinzaines, la traditionnelle dépêche d’appel aux dons, les non moins régulières assemblée générale et publication de bilan et célébration d’anniversaire ou un poisson d’avril.

En dehors de contenus attendus, j’ai écrit sur les sujets liés à LinuxFr.org (OSI rejointe, incidents du 26 juin et du 26 août), sur des sujets qui m’intéressent (la maintenance, le vote électronique ou le jeu d’apprentissage SQLNoir), des sujets plus tristes (un décès parmi d’autres ou une fin de vie pour un projet), et publié quelques liens sur les licences, la sécurité, le vote électronique, l’Union européenne, les dons, la technocritique et le spam.

Ce que je voudrais faire, apprendre ou approfondir en 2026

Déjà dans les reports de 2024, je voudrais m’intéresser au Fediverse et à ActivityPub peut-être, et peut-être à Gemini (le protocole) ? Il y a des travaux en cours sur le service de partage sur les réseaux sociaux share. Par contre j’ai donné moins de conférences en 2024 pour LinuxFr.org et globalement assisté à moins d’événements : donc je réitère l’ambition 2025 de rencontrer plus régulièrement le lectorat ou les personnes contribuant au site ou des publics nouveaux, car c’est appréciable pour le moral et la motivation.

Hum c’est malheureusement bon on peut garder tel que.

Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)

De manière générale, je suis toujours intéressé par plus de contenus sur LinuxFr.org (idéalement des dépêches). Mais plus précisément, en termes de sujet, j’aimerai encore et toujours plus d’articles la réparation, la maintenance et la réutilisation, sur la sobriété en informatique, sur la lutte contre la corruption, sur les sujets politiques autour du numérique et des données. Et bien sûr toujours plus de retours d’expérience, de sujets qui ne me viendraient pas à l’idée (sérendipité) et de sujets qui vous passionnent vous (partagez !). Pour Projets Libres, c’est un peu de la triche, j’ai accès à la préparation et j’ai déjà un premier aperçu de la richesse des sujets qui seront traités, mais je sais aussi qu’on compte sur vous pour aider à enrichir les émissions avec vos suggestions diverses et variées.

Walid (Wawa) Nouh

Accomplissements, réalisations, progrès de l’année 2025

L’année 2025 a été chargée puisque 19 émissions ont été diffusées. Nous avons eu aussi l’occasion de parler dans des conférences et des meetups.
Le podcast continue à gagner en visibilité et d’après nos statistiques OP3 (qui ne sont pas parfaites), pour la première fois deux épisodes ont dépassé les 2000 téléchargements dans le premier mois (Dégooglisons l’évaluation avec Framasoft, et le futur sera fédéré et auto-hébergé avec Elena Rossini).
J’ai finalement trouvé le temps de poser des mots pour expliquer mon travail sur le podcast, résumé comme ceci : documenter, transmettre, apprendre.
Bien entendu la grosse actualité de la fin d’année est le rapprochement avec LinuxFr, qui est une suite logique et aussi une reconnaissance de notre travail depuis 2023.
Pour finir, nous avons eu l’occasion, à travers l’association LinuxFr, de donner des cours d’introduction au logiciel libre dans une école d’ingénieur (Florent Zara, Raphaël Semeteys, Jérôme Herledan et moi-même). Cela confirme mon idée que des prestations annexes sont un moyen intéressant de financer l’édition du podcast et de faire en sorte de ne pas avoir de publicité.

Ce que je voudrais faire, apprendre ou approfondir en 2026

Pour cette nouvelle année, Raphaël et moi avons fixé un thème, qui sera la ligne directrice de notre travail sur 2026 : pérennité et résilience.

– Pérennité, car c’est un sujet qui nous tient à cœur, à travers les épisodes sur les fondations, ou sur les projets qui existent depuis un grand nombre d’années.
– Résilience : c’est la suite logique de tous les épisodes qui traitent, entre autres du Fediverse, de l’auto-hébergement et de l’informatique responsable et c’est plus que jamais important vu l’actualité géopolitique actuelle.

Mes souhaits vont sûrement évoluer courant de l’année, mais j’aimerais dans les semaines à venir commencer à tester des OS mobiles basés sur Linux (Ubuntu Touch et PostmarketOS pour commencer), afin de préparer de potentiels épisodes sur le sujet.
J’aimerais aussi donner plus la parole à des personnes qui utilisent le libre (dans la lignée de l’épisode avec Elena Rossini).
Bref, beaucoup d’idées, le backlog est d’actuellement une cinquantaine d’épisodes…

Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)

Je vais surtout passer plus de temps à relire du contenu déjà présent sur LinuxFr :)
Comme annoncé lors de l’évènement AssocialClub au salon Open Source Experience, il y a toute une intégration du podcast dans et avec LinuxFr à imaginer, cela va être passionnant !

vmagnin (Vincent)

Accomplissements, réalisations, progrès de l’année 2025

Côté accomplissements sur LinuxFr, je suis surtout content d’avoir fait œuvre arkéologique avec ma série automnale de cinq journaux consacrés aux Fiches Libres, au site antique GNULinews et aux Tuxeries (1, 2, 3). Cela a abouti à la modernisation des fiches par Ysabeau et de mon côté à la restauration des Tuxeries, plus de deux cents images et animations du dessinateur JC.

Toujours à cheval entre passé et futur (donc dans le présent ?), j’ai publié ma dépêche n°7 sur le Fortran. La disparition du service non-libre Netvibes m’a forcé à migrer vers une Pétrolette libre. Et parmi les dépêches auxquelles j’ai contribué sensiblement, je me souviens surtout de Rendez-nous nos boutons !, un questionnement humoristique sur certaines évolutions techniques imposées parfois sans discernement.

À part ça, en 2025 j’ai migré mes machines de travail d’Ubuntu vers Fedora. Probablement en partie pour retrouver un peu le piment qu’on ressentait à chaque version d’Ubuntu il y a 20 ans. Dans toute vraie passion, il y a apparemment une quête de l’excitation originelle que l’on essaie de retrouver décennie après décennie. Oui, j’essaie aussi de rejouer encore une fois l’excitation pré-adolescente de l’apprentissage de la programmation grâce à Rust. J’ai terminé de lire le livre Développez avec Rust (Dunod).

Ce que je voudrais faire, apprendre ou approfondir en 2026

Je suis loin de maîtriser les nouveaux concepts présentés dans ce très bon livre, mais j’ai au moins balayé l’essentiel et j’ai tout 2026, enfin j’espère, pour progresser en Rust. Et aussi avancer un peu dans quelques projets Fortran pro ou perso.

Continuer à réfléchir sur l’IA et sur la poursuite de l’informatisation du monde. Avec en ce moment comme toile de fond la lecture de La Technique ou l’enjeu du siècle de Jacques Ellul (2ᵉ édition de 1960), qui se termine par : « […] nos plus intimes passions sont connues, publiées, analysées, utilisées. L’on y répond, l’on met à ma disposition exactement ce que j’attendais, et le suprême luxe de cette civilisation de la nécessité est de m’accorder le superflu d’une révolte stérile et d’un sourire consentant. » Après autant de lucidité, on verra si j’ai le courage de lire Le Système technicien (1977) qui se termine par : « L’homme qui aujourd’hui se sert de la technique est de ce fait même celui qui la sert. Et réciproquement seul l’homme qui sert la technique est vraiment apte à se servir d’elle. » Pas glop !

Bon, ça ne m’empêchera pas d’écouter des podcasts Projets Libres / LinuxFr.org. Et ne soyons pas sombre puisque 2026 est un nombre heureux (voir le site OEIS pour plus de propriétés de 2026).

Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)

Monomanie technicienne : des trucs sur Rust :-)

Ysabeau

Accomplissements, réalisations, progrès de l’année 2025

Une année moins productive que les précédentes sur le plan informatique, quoique ! En avril un tutoriel sur Mastodon, les balises Alt et deux ou trois autres trucs qui fait partie de ce que je voulais approfondir : l’accessibilité des textes. Par contrecoup, pour mes sites j’essaie d’avoir aussi des images et documents mieux présentés.

Sinon pour LinuxFr : la dépêche sur Delphine Demange et les compilateurs m’a donné, enfin, l’occasion d’en savoir plus (de découvrir en fait) sur les compilateurs et les commentaires, dont j’ai vraiment apprécié la qualité, de résoudre un mystère vieux de 2020. Avec celle sur la sortie d’Unicode 17 j’ai approfondi ma connaissance des systèmes d’écriture et de ce qui est nécessaire pour qu’il puisse figurer dans le registre Unicode. L’histoire de la convention du mètre et de l’ODF a été aussi un genre d’épopée en ce qui me concerne puisque j’ai profité de l’occasion pour « epubifier » un document complexe avec formules de mathématiques et autres joyeusetés, Le Système métrique décimal. Sa création en France. Son évolution. Ses progrès. Et, évidemment, les fiches libres, que je dois continuer à revoir, ont été sources d’enseignements, j’aime bien l’idée du travail arkéologique. Par contre, j’ai laissé le Transimpressux en jachères.

Si j’ai relativement peu écrit, j’ai beaucoup tricoté, des bérets, notamment, sur la base d’une méthode que j’ai mise en ligne et qui a réclamé quasiment l’entièreté de mes capacités mathématiques (pas grand-chose). Et en fait, j’aurais pu faire plus simple… Et puis j’ai fait du Banksy.

Marque-pages la petite fille au ballon inspirés de celle de Banksy même si, au final, le résultat est très différent.

Ce que je voudrais faire, apprendre ou approfondir en 2026

L’accessibilité, encore et toujours, écrire un ou des tutoriels sur le sujet. Utiliser plus ou mieux Draw pour faire des modèles de jouets de papier. Et, oui, j’ai encore à apprendre sur l’EPUB, et Inkscape. Oh, et continuer des dépêches de la série Transimpressux, il faut vraiment que j’écrive sur l’Unicode dans ce cadre.

Des contenus que je voudrais voir plus sur LinuxFr.org ou écouter plus dans le podcast Projets Libres (type de contenu, sujet, etc.)

Des contenus sur l’accessibilité, la réparabilité, le bricolage informatique comme celles du dernier journal de Sébastien Rohaut ou celui d’Ecran Plat sur les clés USB-C lentes. Et aussi plus de contenus sur l’histoire de l’informatique et des logiciels et de l’arkéologique.

Pour finir

Nous vous souhaitons tout de même la meilleure année possible (on oscille entre excellence optimisée et résilience robuste ainsi que pérennité soutenable et humour drolatique). Et, bien évidemment, n’hésitez pas à « continuer » cette dépêche dans les commentaires.

Et un merci à toutes celles et ceux qui font de LinuxFr.org un site enrichi en sérendipité et surprises et de Projets Libres un podcast nimbé de découvertes et bienveillance.

Cette année, la date de la journée Ada Lovelace, une journée dont l’objectif est d’accroître la visibilité des contributions des femmes dans les domaines scientifiques, technologiques, mathématiques et ingénierie (STEM), est le 15 octobre 2025.

Pour l’occasion, en 2023, LinuxFr avait consacré une dépêche à Lorinda Cherry, Evi Nemeth et Jude Milhon. En 2024, cela avait donné lieu à une mini-série sur la participation des femmes à la conquête de l’espace. Cette année, on se penchera sur les compilateurs, créés par Grace Hopper, et qui ont valu à Frances Allen un prix Turing en 2006 et on dressera le portrait de Delphine Demange, lauréate du prix Gilles Kahn 2013.

Sommaire

• Qu’est-ce qu’un compilateur ?
  • La naissance des compilateurs
  • À quoi ça sert ?
  • Comment ça marche ?
• Delphine Demange : comment vérifier que les compilateurs font leur travail correctement
  • Parcours
  • La vérification des logiciels
• Quelques autres sources d’information
• Questions et remerciements

Qu’est-ce qu’un compilateur ?

La naissance des compilateurs

Le premier compilateur, il s’appelait « translator » (traducteur) à l’époque, a été inventé par Grace Murray Hopper pour l’UNIVAC 1 en 1951, l’A-O System. Soit après la sortie de l’IBM 604 (1948), avant celle de l’IBM 650 (1954) et un peu avant le FORTRAN, langage compilé, créé vers 1953 par John Backus pour l’IBM 701 et lancé en 1957. La même année où IBM embauche Frances Allen pour former des scientifiques et des ingénieurs réticents à l’utilisation du langage. Elle sera, en 2006, la première femme à obtenir un prix Turing. Elle raconte, dans les Annals of History of Computing (Volume 6, N°1, janvier 1984) que :

L’une des façons dont le laboratoire de recherche a convaincu les gens à utiliser ce langage a été d’imposer son utilisation via un règlement.

Elle ajoutera :

le compilateur FORTRAN a établi la norme en matière d’efficacité du code objet. Mais surtout, il a démontré la faisabilité de l’utilisation des langages de haut niveau. Lorsque j’ai enseigné le FORTRAN en 1957, l’utilisation de ce langage a rencontré une forte résistance. Cette résistance a rapidement été érodée par le type de code produit par le compilateur.

John Backus, qui trouvait par ailleurs que Grace Murray Hopper était difficile à égaler, détaillait dans ces mêmes annales les auteurs et l’autrice du compilateur. Peter Sheridan avait écrit la section 1 qui analysait les expressions algébriques, les traduisait en code et optimisait ce code. Pour la section 2, Harlan Herrick avait inventé l’instruction DO, rédigé : « la partie de la section 1 qui regroupe toutes les informations sources non utilisées dans les expressions algébriques dans des tableaux nécessaires aux sections suivantes. ».

C’est également à Herrick que l’on doit l’introduction des mots clés GO TO ! Roy Nutt a conçu la majeure partie du langage d’entrée/sortie et rédigé la partie de la section 1 qui traduisait les instructions d’E/S en boucles DO. Il a également rédigé la section 6, qui assemblait le programme symbolique final et complétait le traitement des instructions d’E/S. C’est également à Nutt que l’on doit l’introduction de l’instruction FORMAT. Bob Nelson et Irv Ziller ont rédigé la section 2, qui s’est avérée être la plus grande section du compilateur. Elle analysait les références aux tableaux dans les boucles DO et produisait un code hautement optimisé pour le reste du programme source. Leur travail a eu un impact important sur le niveau global d’optimisation que j’ai mentionné précédemment. Dick Goldberg a rédigé la section 3, qui rassemblait le code compilé par les sections 1 et 2 et produisait d'autres informations nécessaires aux sections suivantes. Les gens continuaient à se concerter et à demander aux auteurs des sections précédentes de produire un peu plus, quelques tableaux supplémentaires dont ils avaient finalement besoin. Dick a également joué un rôle important dans le débogage de la section 5. Lois Haibt (en) a rédigé la section 4, qui effectuait une analyse statistique de la fréquence d'exécution […] Ici, la section 4 a également préparé de nombreux tableaux pour la section 5, si je comprends bien. Sheldon Best a écrit la section 5, qui a converti le programme utilisant de nombreux registres d'index en un programme en utilisant trois. Ses méthodes ont eu un impact considérable sur les travaux ultérieurs dans ce domaine et ont eu un effet majeur sur le niveau d'optimisation du compilateur. Enfin, David Sayre a rédigé un manuel du programmeur exceptionnellement clair et concis et a aidé Dick Goldberg à déboguer la section 5.

Schéma de la structure du compilateur de l’ordinateur IBM 704 adapté de celui fait par Frances Allen dans les « Annals of History of Computing », Volume 6, N°1, janvier 1984 (page 24).

De leur côté, les Soviétiques, qui fabriquaient aussi des ordinateurs, utilisaient également des compilateurs. Dans son article sur les ordinateurs soviétiques, Yves Logé rapporte qu’ils utilisaient, en 1955, les langages de compilation : PP2 – PP et BESM. Le BESM étant un ordinateur sorti en 1953. La fondatrice de la programmation théorique en Ukraine, Katerina Yushchenko (en), y a fort probablement contribué.

À quoi ça sert ?

En août 2001, dans un entretien (en) avec Janet Abbate qui lui demandait comment elle définirait un compilateur, Frances Allen répondait :

Je pense qu’un compilateur sert à traduire ce que l’utilisateur de l’application […] demande […] à la machine de manière à obtenir la bonne réponse, mais aussi à utiliser au mieux les ressources de la machine. C’est ça, l’optimisation. On peut se contenter de transposer les choses sans tirer parti des registres et de nombreuses autres unités de calcul, mais cela ne serait pas aussi efficace. L’optimisation consiste donc à tirer parti des ressources de la machine et à très bien connaître cette dernière. C’est en quelque sorte combler un fossé, afin que l’utilisateur n’ait pas besoin de tout savoir !

Plus généralement, un compilateur est décrit comme un programme dans un langage de haut niveau qui traduit le code-source en code objet pour le rendre exécutable en détectant les erreurs et en l’optimisant par la même occasion.

Le code source est envoyé au compilateur qui le traduit en langage machine.

Les compilateurs sont des outils essentiels et très complexes qui interviennent dans tous les programmes, notamment des logiciels très critiques :

Par exemple, les programmes embarqués dans les systèmes bancaires, dans les systèmes de contrôle de vol des avions, ou même dans la chirurgie assistée par ordinateur ou les centrales nucléaires […] : la présence d’erreur durant leur exécution pourrait avoir des conséquences désastreuses, que ce soit en termes de vies humaines, de dégâts écologiques, ou de coût financier. (Delphine Demange, Semantic foundations of intermediate program representations, Thèse soutenue le 19 octobre 2012.)

Comment ça marche ?

Réponse rapide : avec beaucoup de mathématiques. Réponse un peu plus détaillée : à partir de différents types d’analyses après une phase de pré-traitement qui permet de déterminer comment traiter les informations.

1. L’analyse lexicale : découpe le code en unités lexicales ou « tokens » qui vont permettre au compilateur de traiter les données par la suite. Ce faisant le compilateur sépare les différents types d’éléments : variables, opérateurs, séparateurs, mots-clés, etc.
2. L’analyse syntaxique : vérifie que le programme source ne contient pas d’erreur de syntaxe et que le code source est correct et, évidemment le compilateur signale les erreurs qu’il a pu trouver à ce stade.
3. L’analyse sémantique : après la syntaxe, c’est le sens du code qui est examiné. Le compilateur va ainsi vérifier s’il y a des erreurs de logique, passant, que le code fait bien ce qu’il est censé faire. À ce stade, le compilateur va aussi signaler les erreurs, voire, rejeter un code incorrect.
4. L’optimisation : permet de nettoyer le code pour le rendre plus rapide à exécuter. À l’heure actuelle avec des processus très gourmands en ressources, c’est une étape-clé, ça n’a pas toujours été forcément le cas.
5. La génération du code final : c’est la dernière phase dont le résultat est le code exécutable.

Delphine Demange : comment vérifier que les compilateurs font leur travail correctement

Parcours

Delphine Demange entre en licence d’informatique à l’université de Rennes 1 en 2004. Elle y obtiendra un magistère Informatique et télécommunications en 2006 puis fera le mastère de recherche en informatique de la même université en 2008. Elle achèvera cette partie de ses études par un stage de master à l’IRISA (équipe Celtique), en vérification de programme. Au bout des cinq mois de stage, en 2009, elle s’inscrira en thèse. Une thèse, Fondements sémantiques des représentations intermédiaires de programmes (en), soutenue en 2012 et qui lui vaudra le prix de thèse Gilles Kahn 2013 de la SIF, et qui porte sur :

la vérification formelle de logiciel, c’est-à-dire à l’ensemble des techniques et d’outils scientifiques qui permettent d’assurer qu’un logiciel remplit ces exigences [de qualité des systèmes critiques]. (Résumé étendu de sa thèse).

Elle part ensuite pour les USA, à l’Université de Pennsylvanie pour une année de post-doctorat. Là, elle travaillera sur un projet alliant vérification et sécurité. De retour en France, elle passe des concours. Elle est, depuis 2013, maîtresse de conférence à l’université Rennes 1.

En février 2024, elle donnait un cours au Collège de France : Représentations intermédiaires pour la compilation : s’affranchir du graphe de flot de contrôle.

On peut retrouver ses communications et articles ainsi que sa thèse, toutes en anglais, sur HAL science ouverte.

La vérification des logiciels

Comme elle le dit en résumé de sa thèse :

Nos vies quotidiennes dépendent de plus en plus, sans même parfois que nous nous en rendions compte, de l’utilisation de programmes informatiques. Ces programmes n’ont toutefois pas tous le même niveau de criticité. Par exemple, les programmes embarqués dans les systèmes bancaires, dans les systèmes de contrôle de vol des avions, ou même dans la chirurgie assistée par ordinateur ou les centrales nucléaires sont appelés systèmes critiques : la présence d’erreur durant leur exécution pourrait avoir des conséquences désastreuses, que ce soit en termes de vies humaines, de dégâts écologiques, ou de coût financier. Ce type de programme requiert donc de fortes garanties : leur exécution ne devrait pas échouer, et leur correction fonctionnelle devrait être garantie.

Elle ajoute plus loin que les compilateurs étant des logiciels, ils sont à leur tour susceptibles d’avoir des bugs comme n’importe quel autre programme. Il est donc nécessaire qu’ils répondent aux mêmes exigences infaillibilité que les systèmes critiques sur lesquels ils travaillent.

Dans un entretien accordé au site de l’université de Rennes en 2014, elle précise que son travail a pour but final :

d’assurer, par une preuve mathématique et assistée par ordinateur, que les compilateurs compilent correctement les programmes (i.e. ils n’ajoutent pas de nouveaux comportements aux programmes), et que les vérifieurs calculent des propriétés sur des modèles corrects des programmes (si le modèle du programme ne comporte pas d’erreur, alors le programme d’origine n’en comporte pas non plus).

Ses travaux de thèse portant les représentations intermédiaires (IR) des programmes sur lesquels travaillent les compilateurs et vérificateurs. Ces IR simplifient les analyses de ces outils qui peuvent analyser des programmes très complexes. Elle continue, depuis, ses recherches dans le même domaine avec :

la vérification des techniques de compilation optimisantes pour les langages de haut-niveau, en y incluant les aspects les plus difficiles des langages modernes, comme la gestion de la mémoire, la concurrence et les modèles de mémoire faibles. (entretien, Université de Rennes).

Tout cela demande beaucoup de mathématique, parfait pour quelqu’un qui a hésité entre les maths et l’informatique.

Quelques autres sources d’information

Sur les compilateurs, internet est bien pourvu en ressources en français sur le sujet, par exemple :

— Compilation informatique : définition concrète et rôle, Journal du net, 2016,
— Comment fonctionnent les compilateurs, IBM, [sd],
— Qu’est-ce qu’une conception de compilateur ? Types, outils de construction, exemple, Kaia Céruléen, GURU99, [septembre 2025 ?],
— Cours de compilation, [sd],
— Compilation, pdf à télécharger,
— Langages de programmation et compilation, Jean-Christophe Filliâtre, septembre 2016,
— Représentations intermédiaires pour la compilation : s’affranchir du graphe de flot de contrôle, cours au Collège de France, 15 février 2024
— Fondements sémantiques des représentations intermédiaires de programmes, thèse, en anglais, de Delphine Demange.

Sinon on peut aussi lire ou relire l’hommage à France Allen sur LinuxFr. Il y a aussi, en anglais, cet article Early Computers and Computing Institutions (en) qui raconte les débuts de FORTRAN. C’est très intéressant. Mais il faut soit l’acheter (15,50 dollars pour les membres ou 30 dollars pour les non-membres) ou faire partie d’une structure adhérente.

Questions et remerciements

Compte de tenu de l’importance des compilateurs, la question se pose de la raison pour laquelle la personne qui a été à l’origine du premier compilateur et du COBOL, Grace Murray Hopper (1906-1992) n’a pas reçu le prix Turing pourtant créé de son vivant, en 1966, et à une époque où elle était encore active. Le récipiendaire du prix Turing 1966 ayant d’ailleurs été Alan J. Perlis pour la construction de compilateurs.

Question complémentaire, pourquoi France Allen n’a reçu son prix Turing qu’en 2006 « pour ses contributions pionnières à la théorie et à la pratique des techniques utilisés par les compilateurs optimiseurs qui ont jeté les bases des compilateurs optimiseurs modernes et de l’exécution parallèle automatique. » Frances (“Fran“) Elizabeth Allen. A.M. Turing Award 2006 (en), alors qu’elle avait pris sa retraite depuis 2002. Elle reste toujours aussi importante : un de ses textes de 1970 fait partie de la bibliographie de la thèse de Delphine Demange.

Dernière question, dans son discours de remise du prix Turing en 2007, Frances Allen disait qu’après une phase de stagnation des compilateurs, on devrait avoir une phase de progrès significatifs dans le domaine. Est-ce que vous avez une idée de ce à quoi elle aurait pu penser ?

Un très grand merci à vmagnin pour son aide et les documents qu’il m’a envoyés pour m’aider à rédiger cette dépêche.

Nous vous avons entendu. Les dépêches noyaux me manquent aussi. Et entre Google qui veut les attraper tous, sudo qui n’est plus sudo sûr que ça, des pays qui sortent d’Internet, les chats qu’on veut surveiller parce qu’ils ne miaulent pas droit et le rythme de travail pour bien vivre, il est temps de revenir aux fondamentaux.

Alors sans plus attendre, quoi de neuf dans la 6.17 ? D’après Linus Torvalds lui-même, It's not exciting — ce n’est pas intéressant. Ce qui, pour lui, est un gage de qualité. Le noyau Linux 6.17 a été officiellement publié le 28 septembre, après la RC7.

Points marquants de la version

• Des corrections de sécurité et de stabilité dans la pile Bluetooth (beaucoup de bugs de type use-after-free).
• Des corrections pour les pilotes GPU et réseau (beaucoup de petites corrections).
• Prise en charge de patch à la volée (live patching) sur ARM 64 bits.
• Meilleur contrôle sur les atténuations de Spectre/x86.
• Suppression officielle de la gestion des architectures monoprocesseur, (nous y reviendrons).
• Introduction de nouveaux syscalls file_getattr() et file_setattr(), permettant la manipulation directe des attributs d’inodes via l’espace utilisateur.
• Gestion du protocole DualPI2 pour la gestion de congestion TCP.

Sommaire

• Architecture
  • Résumé
  • En détails
• Systèmes de fichiers et stockage
  • Résumé
  • En détails
• Réseau et connectivité
  • Résumé
  • En détails
• Virtualisation
  • Résumé
  • En détails
• Sécurité et cryptographie
  • Résumé
  • En détails
• Changements internes et outils
  • Résumé
  • En détails
• Le bilan en chiffres
• Appel à volontaires

Architecture

Résumé

• Intégration et mise à jour de la prise en charge de nombreux SoC ARM, Intel, AMD et RISC-V, dont :
  • Mediatek MT6572 (Disponible sur l'Orange Pi IoT3G), Exynos2200, NVIDIA Tegra264, BeagleBone Green Eco et OrangePi 4A sur ARM.
  • Nouvelles cartes STM32, Imx6, Radxa Rock 5T, FriendlyElec NanoPi M5, et Raspberry Pi RP1 PCI device.
• Ajout de nouveaux contrôleurs mémoire, avec prise en charge étendue de divers matériels industriels.
• Pilotes GPU : beaucoup de patchs pour amdgpu, i915/xe (options de debug et prise en charge de nouveaux formats colorimétrique).
• Les cartes Realtek 8851BU/8852BU sont désormais prises en compte sur le bus USB.
• Suppression officielle de la gestion des architectures monoprocesseur.

En détails

La suppression de la gestion spécifique des architectures monoprocesseur dans Linux 6.17 concerne toutes les architectures (x86, ARM, RISC-V, MIPS, etc.) où le noyau pouvait jusqu’ici être compilé et exécuté en mode UP (pour Uni Processor), opposé au mode SMP (Symmetric MultiProcessing).

Désormais, même les machines avec un seul cœur ou un seul processeur utiliseront des noyaux compilés avec gestion SMP activée. Cette modernisation simplifie le code de l’ordonnanceur (scheduler) et d’autres sous-systèmes internes du noyau, qui peuvent désormais partir du postulat que le système est au moins SMP, même si physiquement un seul cœur est présent. Cela permet un énorme nettoyage du code spécifique à cette fonctionnalité, et donc, à terme, une meilleure maintenance et une plus grande cohérence.

Néanmoins, l’impact, même très léger et invisible sur beaucoup de systèmes modernes, est réel. Le coût mémoire et processeur (dû à la gestion des locks) va augmenter légèrement, et impactera plus fortement les systèmes embarqués très contraints.

Pour les chiffres (et des explications), les tests effectués sur des systèmes monoprocesseurs avec un noyau SMP ont montré une baisse de performance de 5 %, et une augmentation de 0,3 % de la taille. Ingo Molnar, à l’initiative de ce changement, avait pointé le fait qu’il y avait, dans l’ordonnanceur actuel, 175 #ifdef dépendant de #CONFIG_SMP qui ont pu être nettoyés, et avec, plus de 1000 lignes de code supprimées.

Systèmes de fichiers et stockage

Résumé

• Btrfs : la gestion de large folios est ajoutée (expérimental), tout comme des options étendues pour la défragmentation et la compression intelligente des extents. Les premiers tests de performance montrent un gain de 20 % pour la création de fichiers et diverses améliorations…
• Ext4 : introduction du flag RWF_DONTCACHE permettant la purge automatique des données du cache après écriture, ce qui améliore certains workloads orientés I/O.
• NFS : prise en charge des délégations d’écriture même en mode write-only, accélérant des cas d’usage précis.
• Introduction de nouveaux syscalls file_getattr() et file_setattr(), permettant la manipulation directe des attributs d’inodes via l’espace utilisateur.
• Bcachefs : Les relations entre le développeur de ce système de fichiers (Kent Overstreet) et les autres mainteneurs du noyau se sont largement dégradées. Plusieurs mainteneurs ont fait part de leur refus de travailler à l’avenir avec Kent ce qui a conduit Linus a ne plus accepter les demandes de mises à jour (pull requests). Bcachefs est donc figé dans cette version 6.17 du noyau (et il a été complètement retiré de la future version 6.18). Un module DKMS externe est maintenant disponible pour les utilisateurs voulant continuer à utiliser ce système de fichiers.

En détails

Pour ceux qui s’intéressent aux performances et comparatifs des différents systèmes de fichiers avec le kernel, Phoronix a testé ces FS sur ce noyau 6.17. Pas de comparatif avec les précédents noyaux, mais un comparatif entre les FS.

Le flag RWF_DONTCACHE permet des opérations de lecture ou d’écriture passant par le cache mais où les données lues ou écrites ne sont pas conservées dans ce cache une fois l’opération terminée. Autrement dit, les données ne « polluent » pas le cache mémoire, ce qui est utile pour certains types d’I/O où l’on ne veut pas fatiguer le cache avec des données temporaires ou volumineuses qui ne seront pas réutilisées rapidement. Ce flag est une option pour les appels systèmes preadv2() et pwritev2()

    ret = pwritev2(fd, &iov, 1, 0, RWF_DONTCACHE);

En ce qui concerne les délégations d’écriture, cela permet de réduire les appels réseaux (jusqu’à 90 % dans certains cas d’usages — rapport)

Les syscalls file_getattr() et file_setattr() introduits dans Linux 6.16/6.17 permettent la manipulation directe des attributs d’inode depuis l’espace utilisateur, avec une interface plus simple et plus complète que les méthodes existantes.

Réseau et connectivité

Résumé

• Plusieurs nouveaux flags et options : SO_INQ pour AF_UNIX, extension de la gestion de MSG_MORE pour les paquets TCP volumineux et application plus stricte de la fenêtre TCP.
• Introduction de la prise en charge du protocole de congestion DualPI2 (RFC 9332) pour TCP/IP, notamment sur IPv6.
• Nouveau sysctl force_forwarding sur IPv6 permettant l’activation du mode forwarding.
• Remplacement progressif de la gestion des pages réseau par des descripteurs spécialisés (struct netmem_desc), préparant l’évolution vers les folios.

En détails

Le nouveau sysctl force_forwarding permet de forcer l’activation du forwarding indépendamment d’autres configurations potentiellement conflictuelles. (En particulier sur des profils limitatifs ou locaux)

    sudo sysctl -w net.ipv6.conf.all.force_forwarding=1

Petits rappels sur les folios (aussi utilisés dans ce noyau pour Btrfs). Historiquement, le noyau Linux gère la mémoire en unités appelées « pages » (généralement 4K octets). Un folio est un regroupement logique de pages (souvent pages, comme 16 pages de 4K pour former un folio de 64K). Les folios permettent une gestion mémoire plus efficace, évitent les appels redondants liés aux pages individuelles et optimisent les copies. netmem_desc sert d’abstraction générique pour la mémoire réseau, et utilisant les folios, remplace progressivement le struct page d’origine.

L’algorithme DualPI2 est un exemple d’algorithme de gestion active de file d’attente à double file couplée (AQM) spécifié dans la RFC 9332. Il sert de composant de base AQM au sein du cadre DualQ Coupled AQM conçu pour gérer deux files d’attente : une file « Classique » pour les contrôles de congestion compatibles Reno et une file « L4S » pour les contrôles de congestion Scalables. Vous trouverez plus de détails dans l'article en lien, avec, page 6 un ensemble de tests de performance en ce qui concerne DualPI2.

Virtualisation

Résumé

• Gestion de GSO (Generic Segmentation Offload) sur tunnel UDP dans virtio
• KVM : Unicité des enregistrements irqfd
• vhost-net : Prise en charge de VIRTIO_F_IN_ORDER
• vsock : Introduction de la prise en charge ioctl SIOCINQ
• iommu : Révision complète de la prise en charge des IRQs postées
• vfio/qat : Prise en charge des function virutelle Intel QAT 6xxx

En détails

La prise en charge des GSO permet d’améliorer les performances des machines virtuelles en réduisant la charge CPU liée au traitement des paquets UDP.

L’irqfd (interrupt request fd) a été modifié pour être globalement unique, ce qui améliore la gestion des interruptions virtuelles et évite des collisions ou conflits dans la gestion des événements d’interruption, renforçant la stabilité et sécurité des VM.

VIRTIO_F_IN_ORDER permet de gérer un ordre strict pour les paquets pour les cartes réseaux virtuelles.

vfio, qui expose des périphériques aux machines virtuelles, ajoute la prise en charge des fonctions virtuelles des accélérateurs Intel QAT 6xxx (QuickAssist Technology), améliorant ainsi les capacités de calcul cryptographique et compression dans les environnements virtualisés.

Sécurité et cryptographie

Résumé

• AppArmor peut désormais contrôler l’accès aux sockets AF_UNIX.
• Ajout de nouvelles fonctions pour SHA-1, SHA-256 et SHA-512 dans la bibliothèque crypto.
• Optimisation de CRC32c sur les CPU récents (AVX-512).
• La gestion de la profondeur de pile via GCC/Clang permet désormais l’effacement automatisé de la stack (voir SafeStack pour plus de détails).
• Meilleur contrôle sur les atténuations (mitigations) de Spectre/x86.
• Ajout d’un délai de 5 secondes sur /sys/fs/selinux/user.
• Introduction des types neversaudit dans le contexte SELinux.

En détails

Pour rappel, AF_UNIX est une classe de socket Unix permettant la communication interprocessus. Avant cet ajout, AppArmor ne gérait pas la sécurité avec ce niveau de finesse pour ces sockets. Désormais, il est possible de restreindre dans les profils AppArmor, la communication via ces sockets, entre deux applications.

Phoronix a testé les améliorations sur CRC32C sur différentes architectures récentes, qui sont résumées dans le graphique ci-dessous.

Le noyau 6.17 introduit un meilleur contrôle sur les atténuations Spectre, grâce à un mécanisme appelé Attack Vector Controls (AVC). Le principe est simple, plutôt que d’activer ou désactiver des dizaines de protections individuelles contre les bugs d’exécution spéculative (Spectre, variantes de Meltdown, etc.), il est désormais possible de les piloter par groupes, selon la portée des attaques. Le noyau classe les atténuations en cinq catégories :

• attaques utilisateur-vers-noyau (user-to-kernel)
• attaques utilisateur-vers-utilisateur (user-to-user)
• attaques invité-vers-hôte (guest-to-host)
• attaques invité-vers-invité (guest-to-guest)
• attaques inter-threads (cross-thread)

Avec un seul paramètre de démarrage mitigations=, il devient possible d’exclure une catégorie entière d’attaques (par exemple, désactiver toutes les protections invité-vers-invité si aucune VM non fiable n’est utilisée) et ainsi récupérer des performances.

Example: disable user-to-kernel attack mitigations, keep others at auto defaults
GRUB_CMDLINE_LINUX="... mitigations=auto,no_user_kernel ..."

Cette page liste l’ensemble des vulnérabilités CPU, et est une bonne source d’informations à ce propos.

Changements internes et outils

Résumé

• L'ordonnanceur ajoute le cgroup v2 cpu.max pour gérer de manière plus fine l’utilisation du CPU.
• Ajout de DAMON_STAT pour le monitoring.
• Le montage automatique de tracefs sur /sys/kernel/debug/tracing est devenu obsolète au profit de /sys/kernel/tracing.
• La migration vers des outils plus modernes : l’outil gconfig bascule sur GTK3.
• Toujours plus de Rust avec de nouvelles abstractions pour la gestion du matériel et des propriétés firmware.

En détails

cpu.max est plus précis et global que les précédentes méthodes (utilisant cpu.cfs_quota_us et cpu.cfs_period_us ou cpu.shares), en s’appuyant sur l’extension CFS Bandwidth Control de CFS (Completely Fair Scheduler)

# Limite de 50ms d’utilisation CPU toutes les 100ms (50%)
echo "50000 100000" > /sys/fs/cgroup/cpu.max

DAMON_STAT est un module noyau statique de surveillance de l’espace d’adressage mémoire beaucoup plus léger que les précédentes méthodes

    # Si DAMON_STAT est compilé en module
    $ sudo modprobe damon_stat

    # Activation du monitoring 
    $ echo 1 | sudo tee /sys/kernel/mm/damon/stat/enable

    # lecture des informations
    $ cat /sys/kernel/mm/damon/stat/statistics
    damon_latency_avg: 23 ms
    damon_bandwidth_bytes_per_sec: 5242880
    damon_coldness_percentile_75: 40%

    # Désactivation
    echo 0 | sudo tee /sys/kernel/mm/damon/stat/enable

Le bilan en chiffres

Statistiquement, ce n’est certes pas le noyau le plus calme de la série 6.x, comme nous pouvons le voir sur les graphiques ci-dessous, néanmoins, il reste plutôt tranquille, avec du nettoyage et peu d’ajouts.

Appel à volontaires

Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :

	Mainteneur	Contributeur(s)
Architecture	Aucun
Développeurs	Aucun
Systèmes de fichiers	Aucun	patrick_g
Réseau	Aucun
Virtualisation	Aucun
Sécurité	Aucun
Changements internes	Aucun
Édition générale	Aucun	BAud - vmagnin - orfenor

Un peu de vocabulaire :

• le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
• un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.

Nous sommes particulièrement à la recherche de mainteneurs pour toutes les parties.

Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, vous pouvez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !