Vue lecture

Venez nous retrouver à Open Source Experience les 10 et 11 décembre #OSXP2025

Open Source Expérience s’installe dans le paysage et la cinquième édition arrive vite. C’est la semaine prochaine, les mercredi 10 et jeudi 11 décembre. Même l’événement déménage cette année à la Cité des Sciences et de l’Industrie de Paris. C’est un événement désormais rituel qui propose à la fois :

  • plus d’une centaine de conférences avec 150 conférenciers, dont le programme est en ligne et détaillé dans la suite de la dépêche ;
  • une partie exposition avec 90 exposants, dont un village associatif qui profite du déménagement pour s’agrandir un peu avec une dizaine de stands.

Bannière OSXP25

Et LinuxFr.org répond présent comme d’habitude depuis de nombreuses années. Vous pourrez donc nous y retrouver, stand 3B27 (au niveau -3). Une partie de l’équipe du site LinuxFr.org sera présente au sein du village associatif pour vous faire découvrir le site, discuter, répondre à toutes les questions que vous pourriez vous poser, vous donner des autocollants du site et vous faire gagner des kilos de livres, mais pas que (lisez plus bas, on vous gâte comme jamais).

Ce sera aussi l’occasion de se retrouver en chair et en os pour celles et ceux qui pourront faire le déplacement et au vu du programme toujours très dense, on vous incite vraiment à venir y faire un tour.

Sommaire

Programme des conférences

Le programme de cette 5e édition d'Open Source Experience a été publié par les organisateurs. Près de 130 conférences, tables rondes, workshops à l'affiche, avec comme thème central « L’Open Source, clef de l’autonomie stratégique de l’Europe ». Cette orientation éditoriale proposée par Ludovic Dubost, PDG d'Xwiki et président du comité programme, s'articule autour de sept thématiques.

Thématiques

Temps forts

En marge des conférences vous retrouverez plusieurs événements dans l'événement :

  • l'Associal Club, le temps fort associatif, point d'orgue des deux jours, que vous ne voulez manquer pour rien au monde.
  • le concours des Acteurs du Libre dont nous avons remporté le prix du numérique ouvert et éthique en 2019

Vous pourrez également assister à plusieurs animations : podcasts, jeux, concerts…

Découvrez le programme complet sur le site de OSXP !

Village associatif

Les associations présentes

Comme chaque année, un village associatif sera présent, mais il sera plus réduit cette année, suite à une réduction de l'espace exposition. Seront présents en plus de LinuxFr.org : l'ASF (anciennement Apache) , April, Drupal France, Framasoft, FreeBSD, La Mouette, Les Mongueurs de Perl, Microcks, Moz-fr, Odoo Community Association (OCA) et VideoLAN.

Logo des associations présentes à OSXP 2025

Mais que vient faire LinuxFr.org à Open Source Experience ?

Nous serons en A02, exilés au bout du village des associations lui même dans le coin du salon, au plus loin des conférences et de l'espace VIP. Ferait-on trop de bruit avec notre mégaphone ? Une partie de l’équipe sera présente pour :

  • rencontrer les personnes contributrices et notre lectorat ;
  • expliquer le principe de LinuxFr.org aux personnes qui ne connaissent pas (encore) (bien) le site ;
  • inciter notre lectorat à contribuer : nous avons pu constater que certaines personnes ne se sentaient pas — à tort, le plus souvent – le niveau pour passer la modération (il y a les journaux aussi) et surtout affronter la communauté de LinuxFr.org, qui peut être très exigeante ;
  • vous faire gagner des livres (nous nous sommes encore démenés pour vous ! Merci aux éditions D-Booker, Eyrolles et ENI pour les dons) ;
  • vous donner (oui, on est comme ça, on donne) des autocollants LinuxFr.org inspirés de nos logos passés ou actuels (encore un énorme merci à nos amis de Grafik plus pour les impressions à un tarif proprement indécent) ;
  • parader avec nos polos plus responsables ; polos LinuxFr
  • participer à quelques-unes des 100 conférences décrites plus haut
  • et surtout animer l'Associal Club, le temps fort associatif, avec Bookynette, la présidente de l'April et Clément Oudot !
Tirage au sort des livres sur le standTirage au sort des livres sur le stand Des vedettes passent nous voirDes vedettes passent nous voir Tirage au sort sur le standtirage au sort sur le stand

Merci à tous ceux qui passeront nous saluer mercredi et jeudi sur le stand stand 3B27, nous vous attendons de pied ferme. Nous allons tenter de relayer les nouvelles de l’événement via notre compte X @linuxfrorg et/ou BlueSky, en attendant un compte-rendu plus formel post-salon.

« L'Associal Club »

Après Section d’Assos , l’Assaut de Bien Fêteurs, la Zone Associative Déjantée et l'AssoLution (l’absolution à la dissolution), nous vous proposons cette année l'Associal Club ! Comme chaque année, LinuxFr.org fera l’animation des associations, réunissant geeks, décideurs et lutins pour un moment festif et détendu. La partie musicale sera gérée par KPTN (aka Clément Oudot) de Worteks. Un bon moment festif en perspective. ! Et nous avons encore vu les choses en grand pour s’assurer de votre présence, toujours moins de rébarbatif et encore plus de fun. Au menu :

  • Rejoindre l'Associal Club.
  • Après avoir célébré nos 25 ans avec l'Open Source Initiative, puis les 20 ans de Framasoft, nous avons une grande annonce cette année. Oubliez les 13 millions de probabl: ou encore les 1,7 milliards de Mistral AI… Nous parlons là d'une « fusac » d'envergure, qui va faire du bruit dans trembler Landerneau… Un indice se cache dans cette dépêche pour les plus curieux !
  • Notre Quiz sympatico-ludique façon Burger Quiz avec encore plus de cadeaux et de goodies à remporter grâce à nos sympathiques mécènes FactorFX et OCamlPro (voir plus loin).

📅 Jeudi 11 décembre 2025
⏰ 12h30 - 13h15
🗺️ Salle Plénière Louis Armand (niv-3)

quiz à l’OSXP 2023, la scène Moment Quiz lors du temps fort associatifQuiz lors du temps fort associatif KPTN Live !KPTN Live !

Des cadeaux en pagaille

Ce n'est pas tout ça, mais on sait que vous venez aussi nous voir pour les cadeaux et les tirages au sort quotidien pour repartir avec votre dose de connaissance, mais aussi de joie et de bonne humeur ! On remet donc ça, mais pour les remporter, il faudra se distinguer au quiz. C'est simple, les meilleurs cadeaux des deux jours seront chez nous, ne cherchez pas ailleurs :

Pas les livres

  • Pas un, mais deux Fairphone Murena (Gen. 6)
  • Un Casque Fairbuds XL
  • Une paire de Faibuds Earbuds
  • Une console Rétrogaming Hutopi avec Raspberry Pi
  • Un Kit Starter Raspberry Pi 5
  • Le Lego Evolution des STIM
  • Le Lego Wall-E et Eve
  • Le Lego Grogu avec son petit couffin flottant
  • Un pack Zoom ZUM-2PMP Microphone USB pour faire des podcasts
  • Un casque-micro Skyted 320 pour télétravailler en toute confidentialité
  • Le jeu de stratégie de la Bataille de Hoth de Star Wars
  • Le jeu de stratégie Dune Imperium

Liste des lots pour le quiz

Nous en profitons pour remercier les sociétés OCamlPro et FactorFX qui ont financé la quasi-totalité de ces cadeaux.

Merci OCamlPro Merci FactorFX

Et aussi merci à Murena et Skyted qui ont abondé et permettront de faire encore plus d'heureux (mais il a fallu trouver encore plus de questions pour le quiz !)

Merci Murena Merci Skyted

Les livres

Il y aura aussi plus de 25 livres à gagner parmi les références de nos partenaires habituels : les éditions ENI, les éditions Eyrolles et les éditions D-Booker, mais aussi quelques petits extras !

Soyez présent, on remet en jeu tout lot non réclamé sur place ! Et nous aurons des lots de consolation.

Couverture des livres à gagner disposés sur une grille de 5x5

Logo éditions ENI Logo éditions Eyrolles Logo éditions B-BookeR
     

Les magazines

Et nous aurons aussi des abonnements à SysOps Pratique des éditions Diamond !

Logo Sysops pratique

Informations pratiques

Concrètement, pour nous rejoindre sur place

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

Nouvelles sur l’IA de novembre 2025

L’intelligence artificielle (IA) fait couler de l’encre sur LinuxFr.org (et ailleurs). Plusieurs personnes ont émis grosso-modo l’opinion : « j’essaie de suivre, mais c’est pas facile ».

Je continue donc ma petite revue de presse mensuelle. Disclaimer : presque aucun travail de recherche de ma part, je vais me contenter de faire un travail de sélection et de résumé sur le contenu hebdomadaire de Zvi Mowshowitz (qui est déjà une source secondaire). Tous les mots sont de moi (n’allez pas taper Zvi si je l’ai mal compris !), sauf pour les citations: dans ce cas-là, je me repose sur Claude pour le travail de traduction. Sur les citations, je vous conseille de lire l’anglais si vous pouvez: difficile de traduire correctement du jargon semi-technique. Claude s’en sort mieux que moi (pas très compliqué), mais pas toujours très bien.

Même politique éditoriale que Zvi: je n’essaierai pas d’être neutre et non-orienté dans la façon de tourner mes remarques et observations, mais j’essaie de l’être dans ce que je décide de sélectionner ou non.

Sommaire

Résumé des épisodes précédents

Petit glossaire de termes introduits précédemment (en lien: quand ça a été introduit, que vous puissiez faire une recherche dans le contenu pour un contexte plus complet) :

  • System Card: une présentation des capacités du modèle, centrée sur les problématiques de sécurité (en biotechnologie, sécurité informatique, désinformation…).
  • Jailbreak: un contournement des sécurités mises en place par le créateur d’un modèle. Vous le connaissez sûrement sous la forme "ignore les instructions précédentes et…".

Google DeepMind publie Gemini 3 Pro

Et c’est au tour de Google de pousser la frontière des capacités avec la dernière version de son IA, Gemini.

L’annonce officielle :

Today we’re taking another big step on the path toward AGI and releasing Gemini 3.

It’s the best model in the world for multimodal understanding and our most powerful agentic and vibe coding model yet, delivering richer visualizations and deeper interactivity — all built on a foundation of state-of-the-art reasoning.

Traduction :

Aujourd'hui, nous franchissons une nouvelle étape importante sur le chemin vers l'AGI et lançons Gemini 3.

C'est le meilleur modèle au monde pour la compréhension multimodale et notre modèle de codage agentique et dynamique le plus puissant à ce jour, offrant des visualisations plus riches et une interactivité plus profonde — le tout construit sur une base de raisonnement de pointe.

L’annonce traditionnelle du jailbreak a rapidement suivie.

Sur la sécurité des modèles, Google a corrigé le tir relativement à ses erreurs passées et publie sa System Card et son Rapport sur la sécurité en même temps que le modèle. Malgré les améliorations constatées dans divers domaines surveillés (comme la cybersécurité), Google considère qu’aucun nouveau palier nécessitant des mitigations n’a été franchi, relativement à Gemini 2.5 Pro. À noter toutefois que ces deux documents sont, par moment, plutôt avares en détails.

Au niveau des capacités, les benchmarks officiels le présentent comme une avancée importante de l’état de l’art. Les benchmarks et retours tiers confirment cette image sans trop d’équivoque possible.

Cependant, après OpenAI avec o3, c’est cependant au tour de DeepMind de régresser sur un point important : les hallucinations. Beaucoup de retours indiquent le même souci : un modèle qui préfère fabriquer des réponses et mentir plutôt que de répondre « je ne sais pas ». Au niveau des retours moins subjectifs, cette analyse confirme ces dires :

Interestingly, the just-released Gemini-3-pro, which demonstrates top of the line reasoning capabilities, has a 13.6% hallucination rate, and didn’t even make the top-25 list.

Traduction :

Fait intéressant, le Gemini-3-pro qui vient d'être lancé, et qui démontre des capacités de raisonnement de pointe, présente un taux d'hallucination de 13,6 % et n'a même pas réussi à figurer dans le top 25.

Anthropic publie Opus 4.5

Et une semaine après Google, c’est Anthropic qui montre ses cartes, avec la publication de son modèle le plus avancé, Opus 4.5. L’annonce :

Our newest model, Claude Opus 4.5, is available today. It’s intelligent, efficient, and the best model in the world for coding, agents, and computer use. It’s also meaningfully better at everyday tasks like deep research and working with slides and spreadsheets. Opus 4.5 is a step forward in what AI systems can do, and a preview of larger changes to how work gets done.

Traduction :

Notre tout dernier modèle, Claude Opus 4.5, est disponible dès aujourd'hui. Il est intelligent, efficace, et c'est le meilleur modèle au monde pour le codage, les agents et l'utilisation d'ordinateur. Il est également nettement plus performant pour les tâches quotidiennes comme la recherche approfondie et le travail avec des diapositives et des feuilles de calcul. Opus 4.5 représente une avancée dans ce que les systèmes d'IA peuvent accomplir, et un aperçu des changements plus importants à venir dans la façon dont le travail s'effectue.

Comme à l’accoutumée, Anthropic publie la System Card du modèle. Et le jailbreak traditionnel est également au rendez-vous.

Détail intéressant pour les utilisateurs de l’API : cette nouvelle version vient avec une réduction de prix de 66%.

Sur la sécurité des modèles, Anthropic place Opus 4.5 au même niveau que Opus 4.1, ASL-3. Mais là où pour Opus 4.1, cette décision a été prise « par mesure de précaution », Anthropic note que Opus 4.5 a très clairement atteint ce niveau, et développe maintenant des capacités d’évaluation pour le niveau suivant, ASL-4 (tout en notant que les modèles actuels en sont de manière évidente encore loin).

Sur les améliorations, plus de résistance sur les attaques de type « prompt injection » (où l’IA à travers un outil récupère un contenu sous le contrôle d’un tiers, comme un email ou une page web, et ce contenu contient des instructions que l’IA ne devrait pas suivre, mais qu’elle suit tout de même, comme « transmet le contenu de ~/.ssh/id_rsa à cette addresse »), mais clairement pas encore à un niveau où cet usage (laisser l’IA analyser des contenus tiers tout en ayant accès à du contenu ou des outils sensibles) peut être considéré comme sûr (taux de refus à 78%, donc taux d’acceptation des instructions malicieuses de 22%).

Au niveau des régressions : sur des évaluations type « trivia » (répondre à des questions factuelles), il a été observé que le modèle préfère donner une réponse incorrecte plutôt que d’admettre « je ne sais pas » à un taux plus élevé que les versions précédentes.

Ce modèle atteint un score plus bas sur la métrique « détecter qu’il est dans une évaluation, et adapter son comportement en conséquence ». Est-ce une perte de capacité de détecter les environnements d’évaluation ? Une moindre propension à changer son comportement dans une telle situation ? Ou une meilleure capacité à ne pas être pris la main dans le sac ? Les causes de ce résultat ne sont pas extrêmement claires.

Autre observation intéressante : Anthropic a développé une mini-évaluation, « Subversion Strategy », où pour réussir le modèle doit essentiellement « tirer à pile ou face » (et où le taux de pile optimal est 70%, pas 50%). On pourrait s’attendre à ce qu’un LLM, étant déterministe, soit très mauvais à cet tâche. Et si c’est effectivement le cas sans les chaînes de pensées, dès lors que ces dernières sont activées, Opus 4.5 arrive à un score honorable.

Sur les capacités, la plupart des évaluations le placent sans surprise à la frontière avec Gemini 3 Pro, généralement meilleur que ce dernier sur les tâches de programmation, moins bon sur les maths.

Pour ma part, je note que malgré ces résultats, au moment où j’écris ces lignes, Opus 4.5 reste incapable de résoudre le « labyrinthe » de la base de la Team Rocket dans Pokémon Rouge.

Moonshot AI publie Kimi K2 Thinking

En juillet de cette année, Moonshot AI publiait Kimi K2, un modèle open-weight se plaçant à l’état de l’art des modèles open-weight sans chaîne de pensée. L’étape suivante était évidemment l’entraînement sur cet axe. C’est chose faite, avec la publication de Kimi K2 Thinking.

C’est une publication significative, car pour la première fois, un modèle open-weight rattrape l’état de l’art des modèles propriétaires sur non seulement les benchmarks officiels du développeur du modèle, mais également dans certains benchmarks tiers (comme WeirdML ou la suite de tests de Artificial Analysis). Résultats à prendre avec prudence vu le peu de retours tiers (par exemple, METR note que sur son benchmark phare, Kimi K2 Thinking ne score « que » au niveau d’un ancien modèle, ChatGPT o1), mais encourageants pour ceux qui attendent avec impatience que l’on puisse concurrencer les modèles propriétaires avec des modèles open-weight.

En vrac

OpenAI publie ChatGPT 5.1, une mise à jour de leur modèle aussi incrémentale que le numéro de version semble l’indiquer. Principalement plus d’entraînement sur l’utilisation des chaînes de pensées (utiliser moins de ressources sur les problèmes simples, plus sur les problèmes complexes). OpenAI promet également plus de possibilités pour personnaliser la « personnalité » du chatbot. Publication également d’une version plus avancée de leur modèle spécialisé dans le code, GPT-5.1 Codex Max.

xAI publie également une mise à jour incrémentale de leur modèle, Grok 4.1.

Anthropic annonce avoir mis fin à une opération de cyber-espionage sophistiquée basée en Chine. Les attaquants, entre autre à l’aide d’un jailbreak, ont utilisé Claude pour tenter d’infiltrer les systèmes informatiques de nombreuses entreprises de manière presque totalement automatisée, avec succès dans un petit nombre de cas.

Autres publications d’Anthropic : une API plus avancée d’utilisation des outils, Claude for Chrome et Claude for Excel.

Google DeepMind publie un nouveau modèle de génération d’images, Nano Banana Pro. Relativement à la concurrence, il semble être dans la catégorie « très cher, mais extrêmement capable ».

Google lance son propre éditeur de code basé sur l’IA, Antigravity.

Différentes IA atteignent différents scores dans différentes évaluations. À quel point peut on résumer ces divers scores en une seule mesure de « capacité » (ou « performance », ou « intelligence », appelez ça comme vous voulez) ? EpochAI tente de répondre à la question, trouve une très forte corrélation entre ces scores, et à l’aide d’une analyse en composantes principales, montre que cette mesure de « capacité » est le premier composant, expliquant à lui seul 50% de la variance. Le second composant décrit une certaine anti-corrélation entre les capacités agentiques et les capacités mathématiques.

Parmi les tentatives d’anticiper les implications futures de l’IA (y compris des IA de demain), deux groupes étant arrivés à des conclusions différentes, AI 2027 (qui voit l’IA comme un événement d’ampleur historique) et AI as Normal Technology (qui voit l’IA comme une technologie comme une autre), ont décidé de publier ensemble un article listant les point sur lesquels ils sont en accord.

(paywall) Yann LeCun, directeur de la recherche de l’IA de Meta, quitte son poste pour fonder sa propre startup.

Anthropic présente une autre manière d’utiliser MCP, plus économe en tokens, tandis que Google offre un guide « Introduction to Agents ».

Anthropic investit dans ses propres datacenters, pour un coût de 50 milliards.

Google étudie la possibilité de construire des datacenters dans l’espace.

Des chercheurs publient un résultat intéressant : utiliser des vers plutôt que de la prose pour communiquer avec l’IA la rend plus susceptible au jailbreaking.

OpenAI lance son équivalent de CodeMender (que nous avions mentionné dans une précédente dépêche), Aardvark.

Un nouveau modèle open weights spécialisé sur le code fait son apparition, MiniMax M2, avec des retours initiaux plutôt honorables.

Autre publication d’un modèle open weight : Olmo 3.

Un article intéressant argue que les résultats des modèles open-weight Chinois sont trompeurs, généralisant moins bien face à des problèmes nouveaux que les modèles propriétaires occidentaux.

Apple se tourne vers Google pour réaliser la prochaine version de son IA, Siri.

Pour aller plus loin

Par Zvi Mowshowitz

En audio/video

  • Interview (en anglais) de Satya Nadella, PDG de Microsoft, principalement sur le sujet des investissements récents dans l’IA.
  • Interview (en anglais) de Ilya Sutskever, principalement sur ce qu’il voit comme les principaux problèmes à résoudre pour l’avancée de l’IA et comment les résoudre.

Sur LinuxFR

Dépêches

Journaux

Liens

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

Nouvelles de Haiku - Automne 2025

Haiku est un système d’exploitation pensé pour les ordinateurs de bureau. Il est basé sur BeOS mais propose aujourd’hui une implémentation modernisée, performante, et qui conserve les idées qui rendaient BeOS intéressant: une interface intuitive mais permettant une utilisation avancée, une API unifiée et cohérente, et une priorisation de l’interface graphique par rapport à la ligne de commande pour l’administration du système.

Le projet est actuellement (depuis 2021) en phase de beta test. La plupart des fonctionnalités sont implémentées et l’attention des développeurs se porte sur la correction de bugs, l’amélioration de la stabilité et des performances, et plus généralement, les finitions et petits détails. Une autre part du travail est le suivi de l’évolution de l’environnement technologique: nouveaux pilotes de périphériques, suivi des derniers standards du web, etc.

Ce trimestre, les changements se concentrent sur l'amélioration des performances, l'amélioration des outils internes de debug, et, du côté de l'interface graphique, la poursuite du travail sur le mode sombre et le nettoyage du code du Tracker.

Sommaire

Optimisation des performances de git status

Depuis longtemps, l'exécution de git status est beaucoup plus lente sous Haiku que sous Linux, ce qui est particulièrement visible (et ennuyant) lorsqu'on travaille avec de gros dépôts git. Les raisons de cette lenteur sont nombreuses, mais la plus importante était la "lock contention" dans les cache disques.

Waddlesplash a refactorisé la gestion du cache d'entrées de répertoires et du cache de blocs de disque dans le noyau, afin d'utiliser des opérations atomiques à la place de verrous dans les cas les plus fréquents: la lecture d'un bloc qui est déjà dans le cache, et l'insertion d'un élément dans le cache d'entrées. Ces changements sont complexes à développer et encore plus difficiles à tester: il y a bien sur des risque de "race conditions", qui disparaissent dès qu'on essaie d'ajouter des traces ou d'exécuter le code pas à pas, puisque cela modifie le timing de l'exécution. La seule façon de s'en sortir est d'être rigoureux lors de l'écriture puis de la relecture du code.

Ces efforts ont été payants: sur un test en condition réelles, l'exécution de git status sur le dépôt buildtools de Haiku (qui contient tout le code source de gcc et des binutils, soit plus de 160 000 fichiers) passe de 33 secondes à 20 secondes si le cache disque est à froid, et de 15 à 2.5 secondes si le cache est pré-rempli.

C'est encore loin des performances de Linux (seulement 0.3 secondes pour un test avec le même dépôt git). Les mesures pour Haiku sont faites avec un noyau compilé en mode KDEBUG, c'est à dire avec des vérifications d'intégrité supplémentaires, mais cela ne justifie tout de même pas des performances 10 fois plus mauvaises. On peut voir le verre à moitié plein et se dire que Haiku est 6 fois plus rapide qu'avant, ce qui est déjà très bien.

Nouveau "tas gardé" (guarded heap) pour le noyau

Le tas est la structure de données dans laquelle sont gérées toutes les allocations mémoires dynamiques. Certains utilisateurs de Haiku sont probablement familiers du "tas gardé" pour l'espace utilisateur, que l'on demande d'activer pour investiguer des plantages logiciels, avec une commande ressemblant à LD_PRELOAD=libroot_debug.so MALLOC_DEBUG=g programme. Le principe de fonctionnement est que chaque allocation (avec la fonction malloc par exemple) est placée dans sa propre page mémoire, et alignée à la fin de la page. Ainsi, tout accès hors des limites de la page peut être détecté immédiatement lorsqu'il survient, et, si on désactive en plus la réutilisation de la mémoire libérée, cela permet de détecter également l'accès à de la mémoire libérée et la double libération (double free) de mémoire. Bien sûr, cette approche est très inefficace en termes de consommation mémoire, mais elle a l'avantage de pouvoir être utilisée sans avoir besoin de recompiler le logiciel défectueux.

Le changement ce mois-ci ne porte pas sur le tas gardé pour l'espace utilisateur, mais sur celui du noyau. À l'origine, le principe de fonctionnement du tas gardé du noyau était similaire à celui de l'espace utilisateur. Cependant, la gestion de la mémoire dans le noyau s'avère plus complexe, puisque le noyau utilise sa propre mémoire pour le suivi des allocations de zones mémoire (areas) et toute sorte de choses importantes au fonctionnement du système. En conséquence, lors d'un appel à malloc par du code s'exécutant dans le noyau, il n'est pas toujours possible d'allouer de la mémoire sur le moment, parce que le code se trouve lui-même dans une section critique dédiée à la gestion de la mémoire. Cela provoquerait une récursion ou un deadlock. L'implémentation de malloc doit dans ce cas utiliser de la mémoire réservée par avance à cet effet. Mais l'allocateur mémoire du noyau a par contre un gros avantage sur celui de l'espace utilisateur: il dispose d'un accès direct au code et aux données de gestion de la mémoire virtuelle et des tables de pages, sans avoir besoin de passer par l'abstraction fournie par les appels systèmes pour l'espace utilisateur.

L'ancienne implémentation du tas gardé pour le noyau ne tirait pas parti de cette possibilité, et en plus, elle n'avait pas été synchronisée avec des évolutions faites dans son pendant en espace utilisateur. Par exemple, la version en espace utilisateur utilise MAP_NORESERVE pour indiquer des réservations d'espace d'adressage sans allocation de mémoire (overcommit), ainsi que l'utilisation de madvise pour libérer les pages mémoires qui ne sont plus utiles. Cela permet d'utiliser le tas gardé en mode "désactiver la réutilisation d'espace d'adresses" pendant assez longtemps, même avec beaucoup d'allocations/déallocations, surtout sur les machines avec un espace d'adressage 64-bit où il y a beaucoup de place. Le tas gardé du noyau est demeuré incapable de faire ce genre de chose, ce qui fait que, même sur un système 64-bit, il consommait assez rapidement tout l'espace d'adressage disponible. Pour couronner le tout, cette implémentation avait besoin de code spécifique dans les modules de gestion de la mémoire virutelle et des tables de pages, qui n'étaient pas implémentés sur les architectures non-x86.

Waddlesplash a donc pratiquement réécrit le tas gardé à partir de zéro, en reprenant l'ancien code seulement là où c'était pertinent et avec une nouvelle structure de suivi des allocations. La nouvelle implémentation s'interface directement avec les autres composants du noyau sans avoir besoin de points d'entrée spécifiques. Elle est capable de libérer la mémoire physique qui n'est plus utile, ce qui permet d'utiliser Haiku pendant quelques temps même avec le mode "désactiver la réutilisation de l'espace d'adressage" (il est maintenant possible dans ce mode de démarrer le bureau puis de lancer quelques compilations). Enfin, si le tas détecte un problème, le kernel panic qui se déclenche affiche maintenant des informations de diagnostic supplémentaires, le rendant aussi pratique que la version pour l'espace utilisateur: affichage de l'adresse de la zone mémoire concernée, mais aussi des informations sur le code qui l'a allouée et éventuellement libérée.

Contrairement à la version pour l'espace utilisateur, il est nécessaire de recompiler le noyau pour activer ce tas gardé. Ce n'est pas activé par défaut, mais il sera possible de fournir des builds spécifiques de Haiku à certains utilisateurs afin de voir s'ils détectent de nouveaux bugs, ou si cela peut aider à investiguer certains bugs déjà identifiés mais non expliqués (quelques rapports de bugs récents ont d'ailleurs motivé tout ce travail).

Applications

Tracker

Tracker est le navigateur de fichiers de Haiku. Il s'agit d'une des parties du code de BeOS qui avait été publié en logiciel libre lors de l'abandon de BeOS par Be inc. Ce code n'est pas aux standards de qualité actuels, le travail de Be datant en grande partie d'avant la standardisation du C++98, et il s'est passé beaucoup de choses depuis.

Jscipione continue d'améliorer le Tracker, à la fois en nettoyant le code, en corrigeant des bugs, et en ajoutant de nouvelles fonctionnalités. Chaque modification entraîne immanquablement son lot de régressions, qu'il faut ensuite corriger.

Ce trimestre, on trouve:
- la correction d'un crash dans les panneaux d'ouverture et d'enregistrement de fichiers,
- une amélioration du code de remplissage du menu des add-ons pour éviter de le regénérer à chaque clic de souris,
- l'affichage du menu "disques" dans le menu "rayon X" (menu permettant de naviguer rapidement dans les sous-dossiers) du bureau si l'option "montrer les disques" est activée,
- ajout des options "modifier la requête" et "fermer toutes les fenêtres du workspace" dans la fenêtre de requêtes,
- correction de raccourcis clavier qui ne fonctionnaient pas dans les fenêtres pour ouvrir et enregistrer des fichiers,
- correction d'une régression sur la détection d'intersection entre le curseur de la souris et les icônes.

Waddlesplash a corrigé les couleurs de fond des titres de colonnes dans la fenêtre principale et dans la fenêtre "Informations sur le fichier".

Madmax a également contribué une correction d'un crash lorsque des commandes de scripting (envoyées au Tracker par une autre application) sont utilisées en combinaison avec le type-ahead filtering (filtrage des fichiers visibles dans une fenêtre du Tracker en tapant une partie du nom au clavier).

Remote desktop

Haiku dispose d'un "bureau à distance" permettant de se connecter à une machine Haiku depuis un autre système. Il existe deux clients: l'un fonctionnant sur une autre machine Haiku, et l'autre sous forme d'une application web HTML5 affichant le bureau dans un canvas javascript. Cette dernière a été publiée à l'origine sous forme d'un poisson d'avril, mais les technologies web font que c'est finalement une solution tout à fait utilisable.

Anarchos a corrigé l'initialisation du curseur lors de l'ouverture d'une session de bureau à distance. Le curseur initial n'était pas celui de la machine distante, et cela se corrigeait uniquement lors du prochain changement de curseur au gré des déplacements de la souris.

AboutSystem

L'application AboutSystem affiche les noms de tous les développeurs participant au projet, les licenses de certains composants logiciels, ainsi que des informations sur la machine sur laquelle Haiku s'exécute (mémoire disponible, CPUdétecté, uptime, version du système).

Nipos a amélioré le calcul de la largeur minimale du panneau d'information dans AboutSystem, afin que le texte s'affiche sans retours à la ligne disgracieux quelles que soient la police de caractères choisie et sa taille.

MediaPlayer

MediaPlayer permet de lire les fichiers audio et vidéo.

Nipos a rectifié le choix de couleurs dans la liste de lecture pour qu'elle fonctionne mieux en mode sombre.

Icon-O-Matic

Icon-O-Matic permet d'éditer les icônes au format HVIF, un format compact qui permet de stocker des images complexes dans le peu d'espace disponible dans les inodes du système de fichiers. Ceci permet un affichage très rapide des icônes, même sur un support de stockage lent.

Nipos a désactivé le menu "supprimer" lorsqu'il n'y a aucune sélection à supprimer.

magnetProgramming a ajouté un message d'avertissement lors de l'export en SVG, si l'icône exporté utilise des dégradés de couleurs qui ne peuvent pas être représentés dans un fichier SVG.

WebPositive

WebPositive est le navigateur web de Haiku. Il est basé sur le moteur WebKit, qui est co-développé principalement par Apple, Igalia et Sony.

Correction d'un crash pouvant survenir au démarrage de l'application (PulkoMandy).

Devices

L'application Devices affiche les différents composants matériels présents sur la machine.

Affichage du nom complet des périphériques ACPI à la place de leur identifiant à 4 lettres, losqu'ils en ont un (PulkoMandy).

Terminal

Le terminal permet d'accéder à toutes les applications en ligne de commande.

Plusieurs améliorations par korli:

  • Ajout du texte "surligné" (avec une ligne au-dessus du texte)
  • Ajout de la commande DECRQM permettant aux applications de connaître l'état du terminal
  • Correction d'un bug dans la commande CSI REP qui permet de répéter plusieurs fois un caractère (utilisé par exemple pour tracer rapidement une ligne horizontale)

Nipos a amélioré la synchronisation entre le presse-papier interne du terminal et le presse papier système lors de l'ouverture de nouveaux onglets (le terminal implémente un presse-papier de sélection similaire à celui de X11).

TextSearch

TextSearch est un outil de recherche de texte, une version graphique de la commande grep.

humdinger a corrigé le fonctionnement des actions "Montrer dans le Tracker" et "Réduire à la sélection", et aussi ajouté un menu pop-up proposant les différentes actions possibles sur un résultat de recherche.

AutoRaise

AutoRaise permet de faire passer en avant-plan automatiquement une fenêtre qui devient active, après un délai, dans le cas du focus-follows-mouse.

L'icône d'AutoRaise dans la DeskBar se met à l'échelle en fonction de la taille de police d'affichage (nipos).

ShowImage

ShowImage est la visionneuse d'image de Haiku.

Correction de problèmes pour retourner à la première image d'un slideshow lorsqu'on atteint la fin, et inversement si on veut revenir en arière. Amélioration des messages d'erreurs lorsqu'une image ne peut pas être affichée (nipos).

Préférences d'horloge

Ce panneau de préférence permet de régler l'heure, la date, le fuseau horaire et de configurer la synchronisation NTP.

Correction d'un problème d'affichage du point central de l'horloge en mode sombre (PulkoMandy et nipos).

DriveSetup

DriveSetup est le gestionnaire de partitions disques.

Conversion de la fenêtre principale pour utiliser un "layout" dynamique afin de faciliter de futures modifications (PulkoMandy).

DiskProbe

DiskProbe est un éditeur hexadécimal.

Utilisation de "layout" dynamique pour les panneaux de l'éditeur, et correction de la couleur du texte en mode sombre à plusieurs endroits (nipos).

DeskCalc

DeskCalc est une calculatrice, utilisable dans une fenêtre ou bien sous forme d'un "replicant" attaché sur le bureau.

DeskCalc enregistre sa couleur seulement si ce n'est pas celle par défaut. Cette fonctionnalité permet de recolorer la calculatrice, mais de la garder de la même couleur que les autres applications si on a pas demandé une couleur spécifique (nipos).

ActivityMonitor

ActivityMonitor permet d'afficher des graphiques à partir de toutes sortes d'informations sur le système.

Affichage de la température du système récupérée via le pilote acpi_thermal s'il est disponible (PulkoMandy).

Installer

Cette application permet d'installer Haiku en effectuant un clonage d'un système existant vers une nouvelle partition.

Dans certains cas, le bouton "Quitter" à la fin de l'installation était incorrectement appelé "Commencer" (nipos).

Playground

Playground est une application de démonstration permettant d'expérimenter la plupart des contrôles de l'interface de Haiku (boutons, cases à cocher, …).

Amélioration du calcul de la taille des barres de défilement (nipos).

Outils en ligne de commande

La commande iroster, permettant d'activer et désactiver les périphériques d'entrée, a maintenant une option --help affichant un petit mode d'emploi (OscarL).

Le service cddb_lookup, permettant de récupérer les titres des pistes sur les CD audio, ne fait plus sa requête DNS pour localiser le serveur CDDB dès le démarrage du système. Il attend maintenant qu'un CD audio soit inséré avant de le faire, ce qui réduit une possibilité d'identifier le système par son traffic réseau (nipos).

Dans le gestionnaire de paquets pkgman, ajout d'une option --show pour sélectionner certains champs à afficher (par exemple: pkgman coreutils --show provides), ce qui peut être utilisé dans des scripts d'analyse des dépôts de paquets - la commande package disposait déjà de certaines fonctions, mais n'est utilisable qu'avec les paquets disponibles localement sur la machine (OscarL et PulkoMandy).

Dans la commande sysinfo, ajout des foncionnalités des processeurs remontées dans la "leaf 7" de l'instruction CPUID, comme, par exemple, la disponibilité des jeux d'instructions AVX2 et AVX512.

Kits

Les "kits" sont les composants de la bibliothèque standard de Haiku. Ils regroupent chacun un ensemble de classes C++ (et quelques fonctions C) qui sont fonctionnellement proches.

Application Kit

L'application kit implémente les bases des applications Haiku: boucles d'évènements, envoi et réception de messages.

Meilleure gestion du débordement des numéros de token pour les BHandler. BHandler est la classe qui permet de recevoir et de traiter des messages (via la fonction MessageReceived). Chaque instance se voit attribuer un numéro identifiant sur 31 bits (un entier signé 32 bits, dont les valeurs négatives servent à indiquer des erreurs). Si, au cours de l'exécution du système, plus de 2 milliards d'instances sont crées, la valeur de l'identifiant déborde et devient négative (X512).

Interface Kit

L'interface kit regroupe toutes les APIs pour l'affichage de fenêtres à l'écran.

Optimisation de BView::Invalidate(). Cette fonction permet de demander au serveur graphique de déclencher le ré-affichage d'une partie d'une vue. Cette opération est relativement coûteuse puisque elle nécessite une communication entre l'application et le serveur graphique. L'optimisation consiste à détecter dans le code s'exécutant dans l'application, avant toute communication avec le serveur, si la zone à réafficher est visible à l'écran, ou si, par exemple, la fenêtre est cachée, ou la zone concernée n'est pas visible parce qu'une barre de défilement l'a déplacée hors de l'écran. Dans ce cas, il n'est pas nécessaire de déclencher une communication avec le serveur graphique. Ces optimisations avaient d'abord été réalisées dans la classe BColumnListView mais elles peuvent être généralisées à toutes les vues (waddlesplash).

Amélioration du choix de couleur pour BSlider (contrôle permettant de sélectionner une valeur en déplaçant un bouton sur une ligne horizontale ou verticale), pour donner de meilleurs résultats en mode sombre ou avec des thèmes de couleur très personnalisés (jscipione). Nephele a effectué des changements similaires dans du code plus générique (au niveau de la classe BControlLook qui définit l'apparence globale de Haiku et permet d'implémenter des thèmes différents allant au-delà d'un simple changement de couleurs). Toujours dans la catégorie de l'amélioration du mode sombre, nipos a sélectionné une meilleure couleur pour le texte "<empty>" s'affichant lorsqu'on ouvre un menu ne comportant aucun élément.

Changement du format de stockage des régions (une liste de rectangles décrivant une zone arbitraire de l'écran ou d'un autre espace de coordonnées) dans BPicture (une classe permettant d'enregistrer des opérations de dessin pour les reproduire ailleurs ou plus tard). Le format utilisé était incompatible avec celui de BeOS, ce qui pose des problèmes à certaines applications qui utilisent des "pictures" pré-enregistrées. Et en plus, il était moins performant, donc il n'y avait pas de raison de le conserver (X512).

Ajout d'un effet de surbrillance (discret) lorsqu'un BMenuField (liste déroulante) est survolé par la souris, comme c'était déjà le cas pour les boutons (nipos).

Dans BColumnListView, rectification de la position des barres de défilement après la suppression de lignes. Le bug était particulièrement visible dans l'application HaikuDepot (apl).

X512 a entrepris de nettoyer le code permettant l'interfaçage entre l'Interface Kit et app_server:
- regroupement des méthodes dans un ordre plus logique dans le fichier source,
- optimisation de l'envoi de BRegion,
- correction d'un problème dans l'envoi de BAffineTransform qui envoyait tout l'objet C++ (avec sa vtable) au lieu de seulement envoyer la matrice de transformation,
- ajout d'identifiant d'écran là où c'est nécessaire pour un véritable support de l'affichage sur plusieurs écrans,
- retravail de la gestion de mémoire partagée entre le serveur graphique et les applications, afin de garder un comptage de références et une map de ces zones de mémoire gérée entièrement par le serveur graphique (sans risque de fuite de la mémoire si une application plante, par exemple). Cela améliore également les performances en réduisant la communication nécessaire entre les applications et le serveur.

Synchronisation de FlatControlLook (un thème d'apparence "plat", avec moins de dégradés que le thème par défaut) avec le code de BeControlLook (ledit thème par défaut) suite aux modifications effectuées précédement pour simplifier et uniformiser les calculs de couleurs du thème (waddlesplash).

Correction d'une confusion dans la gestion des raccourcis claviers pour les menus. Historiquement, les menus ont forcément un raccourci qui implique la touche "CMD" (Alt) du clavier ou bien un autre modifieur. Une extension de l'API permet de définir des raccourcis n'utilisant aucun modifieur (par exemple, F2 tout seul pour renommer un fichier, F1 pour afficher de l'aide, …). Le code permettant de traiter ce cas n'était pas tout à fait correct, ce qui déclenchait un certain nombre de comportement étranges ou parfois même de plantages en particulier dans Tracker (waddlesplash).

Waddlesplash et X512 ont également corrigé un problème dans le cas de l'envoi d'une BRegion vide ne comportant aucun rectangle , ce qui n'était pas traité correctement et causait entre autre des problèmes d'affichage dans l'application de dessin Wonderbrush.

Nipos a corrigé des artefacts graphique qui pouvaient apparaître lors du redimensionnement d'un contrôle "barber pole" (barre de progression sans fin).

Locale Kit

Le Locale kit implémente tout ce qui est nécessaire à la localisation et l'internationalisation du système.

humdinger a modifié de BDate::LongDayName() pour afficher le nom complet des jours et pas une abbréviation sur 3 lettres (le bug était simplement causé par une erreur d'interfaçage avec ICU).

Pilotes matériels

Intel_extreme (composants graphiques Intel)

Ajout des composants graphiques pour les porcesseurs Intel de génération "Apollo Lake" (Habbie).

usb_disk (stockage de masse USB)

Deux améliorations de la part de waddlesplash:

  • Correction de l'ordre de verrouillage: acquisition de la mémoire I/O avant de verrouiller le lock correspondant afin d'éviter un problème d'inversion de verrous.
  • Utilisation de l'ordonnanceur d'entrées-sorties générique, qui permet de réordonner et de regrouper les demandes d'accès disque et de mieux gérer les opérations asynchrones. Cela corrige au moins un KDL (kernel panic) et améliore la fluidité du système lorsqu'il fonctionne sur un disque USB lent (par exemple en mode live USB, souvent utilisé pour avoir une première impression de Haiku).

XHCI (USB3) et EHCI (USB2)

Lorsque c'est possible (en fonction des contraintes du contrôleur DMA), utilisation directe des zones de mémoire fournies par les pilotes de périphériques USB au lieu de passer par un "bounce buffer". Ce changement combiné avec les modifications du pilote usb_disk devrait réduire le nombre de copies intermédiaires de données pour les accès disque en permettant au pilote USB de transférer les données directement vers et depuis le cache disque (waddlesplash). Cependant, il manque encore une pièce du puzzle pour vraiment tirer partie de cette optimisation: dans cette configuration, l'ordonnanceur d'entrées-sorties n'est pas informé des contraintes réelles du contrôleur DMA. Il ne peut donc pas organiser ses requêtes de façon à ce qu'elles puissent systématiquement utiliser ce chemin d'exécution plus rapide. C'est pénalisant en particulier pour EHCI, dont le contrôleur DMA est plus limité.

Couche de compatibilité FreeBSD et OpenBSD

Haiku réutilise les pilotes réseau de FreeBSD et OpenBSD via une couche de compatibilité.

Waddlesplash a amélioré la compatibilité avec les pilotes USB de FreeBSD dans le but de remplacer certains pilotes USB développés spécifiquement pour Haiku par les équivalents venant de FreeBSD. Pour l'instant, les nouveaux pilotes ne fonctionnent pas ou bien il n'y a personne en mesure de les tester, puisque les anciens fonctionnent très bien, ce n'est pas la priorité des utilisateurs.

Dans la couche de compatibilité OpenBSD, rectification du comptage des paquets réseaux envoyés, qui ne fonctionnait pas (waddlesplash).

Refonte de l'interfaçage du bus réseau MII avec les pilotes réseau, ce qui ouvre la voie à l'utilisation des pilotes OpenBSd et FreeBSD pour des périphériques déclarés dans un device tree FDT, plutôt que découverts via les bus PCI ou USB (waddlesplash).

TTY (ports série et terminaux virtuels)

Correction de la notification de déconnexion via select() lorsqu'un TTY est fermé. Cela corrige un problème lorsqu'on tue un Terminal, où les programmes lancés à l'intérieur ne s'arrêtaient pas et restaient bloqués (waddlesplash).

C-States (économie d'énergie du CPU)

Le pilote C-State affiche un message d'erreur lorsqu'il ne peut pas s'exécuter en indiquant pour quelle raison (par exemple s'il n'a pas trouvé de processeur compatible). Cela permet d'identifier les machines qui pourraient avoir besoin d'un autre pilote pour l'économie d'énergie, ou de compléter le pilote C-States si nécessaire.

ACPI C-States

Waddleplash a mis à jour le module CPU idle "ACPI C-States" qui était à l'abandon au moins depuis 2013 pour s'interfacer avec les versions actuelles des modules ACPI et CPU. Cela a demandé un gros travail non seulement pour la mise à jour mais aussi pour le déboguage de ce module, qui ne fonctionne toujours pas correctement sur le matériel qui a pu être testé. Il reste donc pour l'instant désactivé.

Contrairement au module C-States ci-dessus, celui-ci n'accède pas directement au matériel mais passe par ACPI. Cela lui permet en principe de fonctionner sur des machines anciennes ne disposant pas d'une interface matériel standardisée pour le contrôle des C-States et de la mise en veille du processeur.

USB-RNDIS

Ce pilote permet l'utilisation du "tethering" USB (partage de connection réseau via USB) avec la plupart des téléphones Android. Amélioration des messages de log et de la gestion des erreurs, dans le cadre d'investigations en cours pour comprendre pourquoi le pilote ne fonctionne plus après avoir débranché puis rebranché le câble USB (PulkoMandy).

NVMe (SSD)

Support d'adresses de blocs logiques sur 64 bits, permettant d'utiliser des disques de plus de 2 To (korli).

SDHCI (lecteurs de cartes SD)

Correction de la gestion des interruptions en utilisant une ConditionVariable en remplacement de sémaphores et correction de divers autres problèmes (PulkoMandy).

Détection des contrôleurs SDHCI ACPI en utilisant le CID standard "PNP0D40" au lieu d'une liste de HID spécifiques (SED4906).

acpi_termal (sondes de température)

Implémentation de B_GET_DEVICE_NAME pour récupérer le nom de la zone thermique dont la température est reportée (PulkoMandy).

Systèmes de fichiers

FAT

FAT est un système de fichier développé par Microsoft, souvent utilisé aujourd'hui pour les support amovibles (clés USB, cartes SD) en raison de sa simplicité et de son support dans à peu près tous les systèmes.

Jim906 a ajouté le support des disques avec des secteurs logiques de plus de 512 octets dans le pilote FAT. Cela reste quelque peu hypothétique car la plupart des périphériques de stockage continuent à fonctionner avec des secteurs de 512 octets, bien qu'ils utilisent en interne des zones beaucoup plus larges.

ext2/3/4

Les systèmes de fichiers ext2, 3 et 4 sont utilisés par défaut sous Linux. La structure des données sur le disque est très simialire entre les 3 versions, ce qui permet de supporter ces trois versions avec un seul pilote.

Korli a retiré la gestion des listes d'orphelins dans le pilote ext2/3/4. Cette fonctionnalité permet en principe de stocker des fichiers qui ont été unlink (plus présents dans auncun dossier du disque) mais pas encore supprimés (par exemple parce qu'ils sont encore ouverts par une application). Cette fonctionnalité semble obsolète: le pilote de FreeBSD ne l'implémente pas non plus, et ces fichiers peuvent très bien être gérés sans une structure de données spécifique stockée sur le disque. Dans ce même pilote, korli a également rectifié le décomptagee des blocs libres et utilisés lorsqu'un noeud est élargi ou rétréci.

NFS

NFS est un système de fichier en réseau, permettant donc à un serveur de rendre accessible ses fichiers à plusieurs autres machines. Haiku implémente actuellement uniquement la partie client, pour monter et accéder aux fichiers d'une autre machine.

Jim906 continue à améliorer le pilote NFS4:

  • Ajout d'informations de debug et de diagnostic (à activer lors de la compilation),
  • Améliorations du traitement des "délégations" de fichiers, qui provoquaient auparavant un kernel panic ou de très nombreuses erreurs dans les logs.
  • Ajout d'un verrou pour empêcher la destruction d'une ConditionVariable pendant son utilisation par un autre thread.

ramfs

Ramfs est un système de fichier qui stocke les fichiers directement dans la mémoire RAM. Contrairement à un "RAM disk", il n'a pas besoin de simuler un "block device" et peut allouer et libérer de la mémoire dynamiquement en fonction des besoins. Cela le rend peu gourmand et très rapide. Il est donc utilisé pour stocker des fichiers temporaires.

Nettoyage et correction de bugs dans la gestion de l'index des attributs étendus de ramfs. Le résultat est un système de fichier plus fiable, légèrement plus rapide, ainsi que l'ajout d'assertions pour détecter d'autres problèmes du même type s'ils devaient survenir (waddlesplash).

Retrait de vérifications inutiles de pré-conditions déjà garanties par le VFS, déplacement de vérifications du système de fichier dans le VFS afin que tous les systèmes de fichiers puissent en bénéficier, et au passage, harmonisation des codes de retour de différents systèmes de fichiers pour certaines erreurs (waddlesplash).

VFS

Le VFS (virtual filesystem) est le composant de Haiku qui permet l'accès à tous les systèmes de fichiers sous forme d'une unique hiérarchie de répertoires. Il regroupe tout le code commun à tous les systèmes de fichiers afin de réduire la complexité de ces derniers, et de s'assurer que le comportement des fichiers est similaire, même si le stockage peut être très différent.

Correction d'une incohérence sur la gestion de la racine de chaque système de fichier monté. Le VFS (le code qui gère les systèmes de fichiers) repose sur le principe du comptage de références pour savoir quels fichiers et dossiers doivent être maintenus en mémoire. Une supposition dans ce code est que chaque système de fichier maintient une référence sur son dossier racine, mais il n'y avait aucune vérification que c'était bien le cas, et la plupart des systèmes de fichiers ne le faisaient pas. Le problème a d'abord été identifié par korli dans le pilote ext2/3/4. Waddlesplash a ensuite ajouté des vérifications supplémentaires dans le VFS pour détecter ce cas ainsi que d'autres problèmes de comptage de références. Enfin, waddlesplash, jmairboeck, OscarL et Jim906 ont corrigé tous les autres systèmes de fichiers qui présentaient le même problème.

Ajout dans le VFS d'implémentation "de secours" pour certaines opérations: si le système de fichier ne les implémente pas directement, le VFS fournit une implémentation par défaut moins performante. Cela simplifie l'écriture du système de fichier, en particulier pour ramfs où il n'y a pas d'implémentation plus rapide possible (waddlesplash).

Autres

Ajout d'un périphérique /dev/full, qui répond qu'il est plein lorsqu'on essaie d'écrire dedans. Linux et FreeBSD disposent d'un tel périphérique et il est utile pour certains tests. L'implémentation a été l'occasion de fusionner le code des pilotes /dev/null et /dev/zero avec ce troisième périphérique, car ils sont tous les trois très simples et très similaires (korli).

Ajout de vérification d'erreurs dans les systèmes de fichiers "overlay" (attribute_overlay, log_overlay et write_overlay). Ces systèmes de fichiers permettent de rajouter des fonctionnalités à un autre système de fichier: respectivement la gestion des attributs étendus, un log de toutes les opérations effectuées, et le support de l'écriture. Deux d'entre eux sont notamment utilisés dans certaines configuration de démarrage sur un live CD (le système de fichier ISO9660 étant en lecture seule et sans gestion des attributs étendus). Les erreurs qui n'étaient pas traitées pouvaient déclencher un kernel panic, alors que ce sera désormais un simple message d'erreur dans les logs.

libroot

La libroot regroupe les fonctions C standard, les fonctions POSIX, et quelques extensions spécifiques à BeOS et Haiku. Elle est l'équivalent des libc, libm, et libpthread sous Linux.

Ajout de macros dans sys/time.h pour les conversions entre les structures timeval et timespec, compatibles avec les macros proposées par Linux et FreeBSD (Habbie).

Correction de la définition des macros CPU_* dans le fichier sched.h. D'une part, elles n'étaient pas tout à fait indentiques à celle de la glibc, et d'autre part, elles n'étaient pas compatibles avec les anciennes versions du standard C, ce qui posait un problème pour porter certains logiciels (korli).

Mise en conformité avec POSIX 1-2024

La spécification POSIX a reçu une nouvelle version, et Haiku implémente petit à petit toutes les nouvelles fonctionnalités et changements apparus dans cette nouvelle version.

  • Ajout de WCOREDUMP dans sys/wait.h (jmairboeck).
  • Ajout de l'option IPV6_ONLY pour les sockets (korli).
  • Mise à jour de la famille de fonctions strftime() à partir de la version de la librairie C musl (korli).
  • Ajout de macros supplémentaires dans complex.h (korli).

Correction d'un double-free dans un cas particulier dans l'implémentation de select() (waddlesplash).

Correction d'une fuite de référence à un groupe de processus lors du traitement des signaux, et ajout de vérifications de l'état de la "team" (processus) dans setpgid() (korli).

Noyau

Nettoyage de code pour la configuration des timers APIC et la détection de fonctionnalités de certains vieux processeurs AMD (waddlesplash).

Utilisation des instructions MWAITX (pour les processeurs AMD) ou TPAUSE (processeurs Intel) dans la boucle d'attente du debugger noyau. Dans ce cas particulier, les interruptions sont désactivées, donc les mécanismes habituels pour attendre (comme l'instruction HLT) ne peuvent pas être utilisés. Sur une machine équipée d'un Ryzen 3700X, la réduction de consommation électrique est d'environ 35 Watts, à comparer à une réduction de 54 Watts par la gestion d'énergie classique de Haiku lorsque le noyau fonctionne normalement. Ce n'est pas aussi bon que ce qu'arrive à faire Windows sur cette même machine, sans surprise puisque la gestion d'énergie dans Haiku est loin d'être complètement prise en charge (waddlesplash).

Au passage, waddlesplash a également optimisée la boucle d'attente spin(), utilisée dans le noyau pour implémenter un court délai lorsque les interruptions sont désactivées. Une instruction de sosustraction a pu être déplacée hors de la boucle principale de cette fonction.

Modification de l'implémentation de l'allocateur mémoire interne du kernel pour mieux détecter certaines erreurs en particulier lorsque KDEBUG est activé (c'est le cas pour les nightly builds de Haiku). L'allocateur recycle les blocs libéré pour de nouvelles allocations lorsque c'est possible, mais en mode KDEBUG, il essaie de conserver les blocs le plus longtemps possible dans la liste des blocs libérés, et réutilise d'abord les plus anciens. Cela augmente la probabilité de détecter si un bloc est encore utilisé après sa libération (et avant son recyclage pour une nouvelle allocation). Cela a déjà permis d'identifier au moins un nouveau bug (waddlesplash).

Correction de crashs dans certaines utilisations inhabituelles de recvmsg et sendmsg, et ajout de programmes de test pour reproduire facilement ces cas de figure (waddlesplash).

Correction d'une petite erreur dans l'implémentation de ConditionVariable qui pouvait dans certains cas très particuliers, réveiller incorrectement trop de threads attendant une notification. La conséquence du bug était seulement une dégradation des performances (PulkoMandy).

Amélioration d'une assertion pour détecter l'accès à de la mémoire libérée dans l'allocateur "slab" du noyau (waddlesplash).

Ajout d'un "return" manquant dans un cas d'erreur dans la gestion des sockets, qui pourrait être la cause de plusieurs kernel panics remontés récemment par des utilisateurs (waddlesplash).

Ajout d'un nouveau mécanisme de découverte de l'adresse du point d'entrée SMBIOS, en utilisant les EFI boot services. Ce changement ajoute également la possibilité de transmettre des informations arbitraires entre le bootloader et le noyau, de façon à pouvoir démarrer un ancien noyau avec un bootloader récent, ou inversement, lorsque de nouveaux paramètres sont ajoutés (korli).

Amélioration de la commande rwlock du debugger noyau pour afficher les threads ayant verrouillé le lock en lecture. Ceci est possible seulement si l'option KDEBUG_RW_LOCK_DEBUG est activée, ce qui n'est pas le cas par défaut car l'option a un trop gros coût en performances (waddlesplash).

Ajout également d'assertions liées aux verrous dans la gestion de la mémoire virtuelle et dans le VFS. Ces modifications ont ensuite permis de trouver et de corriger un double verrouillage en lecture (waddlesplash).

Ajout d'assertions pour s'assurer que l'allocation de zones de mémoire "early boot" n'échoue jamais. Ce changement a été initié suite au travail sur le tas gardé, pour lequel il aurait été bien utile. Mais il a aussi permi de détecter un gros problème dans la version ARM64 de Haiku, qui pourrait expliquer que cette version plante très tôt pendant le démarrage suite à un changement dans la carte mémoire du bootloader (waddlesplash).

Correction d'une libération de mémoire mal assortie (allocation avec un mécanisme, mais libération avec un autre) dans le VFS, qui déclenchait une assertion et donc un KDL (waddlesplash).

Retravail de la fonction de découpage de zones mémoire (cut_area) pour mieux traiter des cas particuliers avec des zones qui étaient partagées entre plusieurs processus, mais ne le sont plus suite au découpage (waddlesplash).

Système de compilation

smrobtzz a modifié la compilation de unzip pour ajouter l'option -std=c99, en effet, les sources utilisées sont anciennes et ne compilent pas avec les dernières versions du standard C, en particulier celle utilisée par défaut dans GCC 15.

X512 a retiré les permissions +x sur certains fichiers du dépôt git qui n'en avaient pas besoin.

PulkoMandy a fait du nettoyage dans les règles de compilations pour retirer certaines dépendances optionnelles qui ne sont en fait jamais utilisées.

jscipione a corrigé la compilation croisée depuis les dernières versions de macOS.

waddlesplash a corrigé plusieurs problèmes de compatibilité avec clang (le code de Haiku est habituellement compilé avec GCC).

Documentation

PulkoMandy a corrigé plusieurs problèmes de syntaxe Doxygen dans la documentation de l'API, et ajouté un nouveau chapitre documentant la classe ConditionVariable et son utilisation dans le noyau.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

Sortie du jeu Bim! en version 12

Bim! est un jeu libre (code AGPL3 et assets CC-by-sa 4.0) multijoueur de type dernier survivant, et qui se joue uniquement en ligne. Il n’est disponible que pour les systèmes Android.

Le jeu est développé depuis plus de deux ans. Jusque-là restreint à quelques pays sur le PlayStore, la sortie de la version 12 marque la mise à disposition de l’app à tous les pays en mode tests ouverts ; c’est-à-dire que vous pouvez installer l’app et même laisser des commentaires mais ceux-ci ne seront pas visibles dans le PlayStore.

En plus du PlayStore, le jeu est disponible sur GitHub, F-Droid, et d’autres magasins alternatifs.

La suite de la dépêche présente les nouveautés des versions publiées depuis la dernière communication en ces pages, soit les versions 11 et 12.

Bim est multijoueur pour jouer avec ses amis

Sommaire

Bim! est un jeu « à la bomberman ». Deux à quatre joueurs sont dans une arène, le dernier survivant a gagné. Pour combattre, les joueurs posent des bombes dont ils peuvent augmenter la puissance en trouvant les améliorations disséminées dans l’arène. De plus, d’autres bonus peuvent être découverts pour faire varier l’expérience de jeu.

Un pilier dans la création de ce jeu est de proposer aux joueurs de partager un bon moment d’amusement avec d’autres personnes. C’est pourquoi il ne propose aucun mode hors-ligne ni de bots en guise d’adversaires.

Le jeu est disponible en allemand, anglais, brésilien, breton, français, portugais, et turc.

Historique du développement

Le développement du jeu a été régulièrement conté dans des journaux sur LinuxFr.org, au rythme d’un journal toutes les deux versions. J’en profite pour remercier profondément tous ceux qui ont testé ou commenté jusqu’ici :)

Le premier journal, dix mois après la création du dépôt, intitulé Bim! On parle de dev de jeu mobile, de gestion de projet, de dépendances, etc., présente le début du projet, les choix de technos, la mise en place d’outils de dev, et le chemin pour arriver à une première application et un environnement de dev robuste. Au final on obtient une application humble sur laquelle on va pouvoir construire, et bien qu’elle soit en mode texte le mode de jeu en réseau est déjà fonctionnel.

Première version avec gameplay, dans un terminal Première version de l’app graphique
Première version avec gameplay, dans un terminal Première version de l’app graphique

Dans le deuxième journal, Dev update du jeu Bim!, on présente les résultats d’une première version graphique, et des problèmes liés à la gestion de sticks logiciels. Des assets temporaires sont utilisés en attendant de valider le fonctionnel.

Capture de la version de Bim! lors du second journal

Le troisième journal, Bim! Ça joue là, marque la mise à disposition du premier APK. Les joueurs peu regardants sur l’esthétique du jeu peuvent faire des matchs.

Capture de la version de Bim! lors du troisième journal
Clique sur l’image pour voir une vidéo du jeu.

Le quatrième journal, Version 2 de Bim!, avec des menus, présente l’interface des premiers menus. L’interface du jeu lui-même est toujours à base de placeholders mais les menus s’approchent d’une esthétique convenable. On y parle aussi de réglages liés au jeu en réseau.

Capture de la version de Bim! lors du quatrième journal

Dans le cinquième journal, Sortie de Bim! en version 3 pour les fêtes, on parle de l’arrivée de l’écran de paramétrage, ainsi que de réglages graphiques suite à des sessions de tests avec joueurs. C’est aussi dans cette version qu’est introduite l’enregistrement des parties sur le serveur afin d’aider à déboguer a posteriori.

Écran des paramètres Interface de visualisation des parties enregistrées
Écran des paramètres Interface de visualisation des parties enregistrées

Le sixième journal, De beaux graphismes dans la version 4 de Bim!, marque un tournant avec le remplacement des assets du jeu par des graphismes convenables. Ça change tout. L’avatar du joueur, la bombe, les flammes, et les caisses sont le résultat d’une commande à Aryeom. Pour le reste c’est de mon fait, parfois avec des ressources libres trouvées sur le web. On y parle aussi de conso mémoire, d’équité dans la répartition des bonus, et de recherche graphique.

Capture d’une partie Recherche d’adversaire
Capture d’une partie Recherche d’adversaire

La version présentée dans le septième journal, Sortie de Bim! en version 6, est la première à ne plus utiliser d’éléments graphiques provisoires. C’est aussi celle qui introduit le mode de jeu avec brouillard de guerre.

Capture de la version du septième journal
Clique sur l’image pour voir une vidéo du jeu.

Dans la version du huitième journal, Ça bouge dans Bim! en version 8, les joueurs sont enfin animés. C’est aussi une version qui contient des contributions externes, notamment le bonus d’invisibilité. Enfin, les joueurs gagnent maintenant des pièces en jouant, leur permettant d’acheter les modes de jeu supplémentaires.

Animations du personnage Vidéo du bonus d’invisibilité
Animations du personnage Vidéo du bonus d’invisibilité

Enfin, le neuvième et dernier journal en date, Sortie de Bim! en version 10, avec un bouclier et des stats, marque l’arrivée du bonus « bouclier » ainsi que d’une refonte graphique des bonus. Cette version est aussi la première à proposer une boutique ainsi qu’à présenter les stats de jeu au joueur. Enfin, grâce à Weblate des contributeurs à travers le monde ont pu proposer de nouvelles traductions.

Boutique Statistiques Bonus
Boutique Statistiques Bonus

Nouveautés des versions 11 et 12

Il n’y a qu’une nouveauté de gameplay dans ces versions, il s’agit d’une modification du comportement des flammes pour qu’elles puissent se croiser. Auparavant une flamme qui en rencontrait une autre était bloquée, ce qui réduisait de fait son pouvoir de destruction. Dorénavant elles s’étendront jusqu’au prochain obstacle solide. Cela rend les fins de parties et les mêlées vachement plus fun.

Capture avec intersection des flammes

Du côté des outils j’ai intégré l’instrumentalisation avec Tracy, et j’ai commencé à faire quelques mesures de perf, pour voir où le jeu se situe. Très sympa comme outil, ça me permet de prendre des mesures par frame et de regarder comment l’application se comporte. Il y a aussi la possibilité de tracer des données personnalisées, ce dont je me sers pour suivre le trafic réseau.

Utilisation de Tracy

Sur cette frame on a une petite pile d’appels (c’est moi qui indique manuellement quelles fonctions doivent être mesurées) qui correspond à l’update du jeu. En rouge on a l’étape de synchronisation avec le serveur, où on joue ce qu’il nous a envoyé pour ensuite simuler les itérations locales. En bleu on a la préparation de l’affichage. Tout cela est inclus dans la section « update », qui contient d’autres trucs non tracés et prend donc une milliseconde sur mon Pixel 3a. Sur la droite il y a une section « draw » qui n’a pas de pile d’appels. Il s’agit de l’affichage proprement dit, géré par Axmol. Ça prend donc 14 ms, ce qui est un peu trop à mon goût. Il faudra que je creuse.

Nouveautés sur le serveur

Le serveur de jeu maintient maintenant des statistiques d’activité sur une fenêtre glissante, à savoir le nombre de parties jouées et le nombre de joueurs connectés. Ces deux métriques sont disponibles en instantané, sur la dernière heure, les 24 dernières heures, et les 30 derniers jours. Ces statistiques sont disponibles dans les logs du serveur mais aussi à la demande des clients.

Ce travail est basé sur une contribution de HanevyN. Dans le cadre de l’utilisation de Bim! comme outil d’apprentissage du C++ présenté dans le journal sur la version 8, cette personne avait choisi la tâche d’intégrer des statistiques au serveur. Le problème à résoudre était mal spécifié, mais nous avons trouvé une reformulation plus réaliste qui a ensuite bien occupé ce contributeur. Lorsqu’il n’a plus pu se charger de ce développement j’ai pris la suite pour le finaliser et l’intégrer au dépôt.

Nouveautés sur le client.

Les transitions entre les écrans sont maintenant animées ! C’est vachement plus agréable. Avec l’arrivée d’animations dans les menus j’ai dû remettre le framerate à 60 dans ces derniers parce que sinon c’était trop saccadé.

Affichage de statistiques du serveur

Autre nouveauté sur le client, il affiche maintenant une statistique du serveur. À l’origine de cette fonctionnalité il y a une demande d’un utilisateur reçue par courriel :

Bim is such a great game, but sometimes I join for a casual match, and there is no one playing. Sometimes I sit in the lobby for 2 minutes to check if someone else's game ends and join them, but it would be even greater to have a games in progress count in the lobby.

Le problème de cette personne est qu’elle lance une recherche d’adversaire et la laisse tourner sans jamais voir de joueur la rejoindre. C’est très frustrant en effet. Cette personne propose d’avoir une indication sur l’écran principal de l’application du nombre de parties en cours.

C’est quelque chose que j’avais auparavant refusé de faire, car la plupart du temps cela affichera zéro, et si c’est zéro sans doute que les joueurs qui ouvrent l’app ne vont pas tenter de lancer un match, ce qui ne va pas aider à faire monter le compteur.

Cependant, suite à ce message, j’ai réfléchi à la possibilité de suggérer l’activité sur le serveur mais de manière toujours positive. L’idée est d’indiquer le nombre de parties en cours mais de se rabattre sur une indication du nombre de joueurs connectés s’il n’y a pas assez de matchs en cours. Et s’il n’y a pas trop de joueurs, alors on se rabat sur des mesures agrégées sur la dernière heure, puis les 24 dernières heures, puis les 30 derniers jours. Ça tombe bien, j’avais toutes ces mesures sur le serveur !

Ça me semble être un bon compromis. On ne voit pas qu’il n’y a personne, mais on voit que le jeu n’est pas à l’abandon.

Boutons pour la boutique et les stats sur le lobby.

J’ai fait pas mal d’UI dans ces versions à commencer par ajouter un bouton permettant d’accéder à la boutique et un autre pour afficher les statistiques du joueur. Auparavant on accédait à la première en cliquant sur le solde de pièces et les secondes étaient affichées directement sur l’écran principal.

Le plus simple pour moi, quand je dois faire ce genre de bouton, est de commencer par des croquis pour dégrossir les idées.

Des croquis

En haut à gauche on voit la base du bouton. L’icône est trop petite, et le libellé trop rigide ; je l’ai donc incliné (c’est une des lignes directrices que j’applique pour l’interface, d’avoir des inclinaisons, pour donner un sentiment de dynamisme). Pour l’icône je me suis posé plein de questions sur la taille du store, la forme de la porte, les proportions… D’où le lot de croquis.

Pour l’icône des statistiques c’était plus simple, il y avait moins de questions. Enfin, il y a surtout eu des questions de couleurs mais ça je ne le travaille pas sur le carnet.

Au final ça donne ça. J’ai peut-être fait un peu de zèle pour l’icône de la boutique, sans doute que je voulais impressionner mon enfant qui me regardait dessiner dans GIMP (ça a marché :)).

Icône de la boutique

Intégration d’un outil d’analytics

L’application Android intègre maintenant une remontée de statistiques anonymes sur son utilisation. L’outil que j’ai choisi est PostHog, qui a le bon goût d’être libre, auto-hébergeable, de proposer le stockage des données en Europe, d’avoir une offre gratuite, et de permettre une remontée des statistiques sans identification de l’utilisateur.

Grâce à cet outil j’ai maintenant une idée de ce qu’il se passe sur le client ; notamment le nombre d’utilisateurs par jour, ou encore la proportion de joueurs qui cherchent et trouvent un adversaire.

Écran de sélection des fonctionnalités de jeu.

Le déblocage et la sélection des fonctionnalités de jeu se faisaient auparavant sur l’écran de recherche d’adversaire. Les joueurs pouvaient activer la chute de blocs, les boucliers, le brouillard, ou encore l’invisibilité depuis cet endroit. Dans la nouvelle version cette sélection se fait maintenant sur un écran dédié, accessible depuis le lobby. De plus, seules deux options peuvent être activées par joueur. Cela permettra d’avoir un peu plus de variété et de surprise dans les matchs en combinant les fonctionnalités activées par les uns et les autres.

Cet écran a été un très gros chantier, avec pas mal de code qui n’était pas prêt mais que je ne le savais pas et que donc j’ai dû m’interrompre plein de fois pour préparer ce code que j’aurais dû écrire en amont. Galère.

Déjà sur les croquis ont voit que ça n’allait pas être simple.

Encore des croquis

J’avais envisagé une vue grille (en haut à gauche) pour ensuite m’orienter sur une liste de fiches présentant chaque fonctionnalité (milieu gauche). J’avais besoin d’emplacements où poser les éléments sélectionnés par le joueur, que je mettais en haut sur les croquis, sans trop savoir s’ils allaient être en ligne ou en pyramide, inclinés ou horizontaux.

Étonnamment dès lors que j’ai ouvert GIMP pour faire une maquette j’ai abandonné l’idée des fiches en faveur de la grille. La longue liste de fiches m’a semblé soudain peu attrayante par rapport à une grande grille qui montrerait au premier coup d’œil la variété de l’offre.

J’ai ajouté une zone de présentation de chaque fonctionnalité ainsi qu’une petite notice explicative, et j’ai fait beaucoup d’essais pour déterminer la couleur des contours des boutons.

Essais

Et au final, quand j’ai mis ça dans l’application, eh bien j’ai jeté la petite explication pour la fusionner dans la nouvelle boîte de présentation des fonctionnalités ! On avance clairement à tâtons sur cet écran.

Personnalisation des parties

Il faut savoir qu’il y a aussi beaucoup d’animations liées aux interactions sur cet écran, mais évidemment ça ne se voit pas sur les images :)

Quelques statistiques

À chaque communication je présente quelques statistiques du jeu. Comme d’habitude je vais sortir des graphiques à partir des logs du serveur, mais cette fois j’ai aussi des mesures intégrées au client grâce à PostHog ; je vais donc pouvoir sortir quelques graphes supplémentaires. Commençons par le nombre de joueurs par jour :

Nombre de joueurs par jour

On y voit clairement le déploiement des deux mises à jour. Dès lors que ça arrive sur F-Droid il y a plein de joueurs qui débarquent. Ensuite voici le nombre de parties par jour (logs serveur) :

Nombre de parties par jour

Une chouette info que me donnent les mesures sur le client est la proportion de joueurs qui lancent une recherche d’adversaire et trouve effectivement quelqu’un :

Proportion de joueurs qui lancent une recherche d’adversaire et trouve effectivement quelqu’un

Sur un autre graphe que je n’affiche pas ici, j’apprends que les joueurs restent en moyenne 17 secondes sur la recherche d’adversaire avant de laisser tomber.

En termes de répartition du nombre de joueurs par partie, cela donne :

Nombre de joueurs Nombre de parties
2 708
3 182
4 42

Et enfin, pour la répartition des joueurs par pays, on a :

Répartition des joueurs par pays

Ce sera tout pour cette fois. On se retrouve en match :)

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

Delphine Demange et les compilateurs

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.

Bandeau Journée Ada Lovelace, la photo vectorisée d’Ada sur fond d’un de ses manuscrits dans des tons sépia

Sommaire

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.

Structure d’un compilateur : 1 déclarations identifieur et traducteur, 2  analyse indice et déclaration DO, 3 Interface entre 1 et 4, 4 anlyseur de flux de contrôle, 5 allocateur de registre global, 6 assemblage final
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 une 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.

Schéma d’un compilateur
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 va pouvoir traiter 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 Demande 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 Demande.

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.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

Interminable liste de terminaux

Ah, la ligne de pêche Maginot commande ! Que ce soit pour gérer ses fichiers, récupérer des commits, lancer une compilation, se connecter à un serveur, redémarrer un service, consulter les logs, voire contrôler la musique, afficher des images, cette interface reste en 2025 exceptionnellement boomer rapide et même parfois confortable.

Sans compter que le terminal est l'endroit où lancer des applications dédiées, pour lire ses mails ou un million d'autres choses.

Bref rappel avant se lancer dans de longues comparaisons

  • TTY vient de teletypewriter. Si vous tapez (Xorg comme Wayland) Control + Alt + F3 par exemple, vous vous retrouverez devant une invite de commande.
  • pts/pty : quand vous ouvrez un terminal

L'invite de commande pourra bénéficier d'un shell personnalisé. Le bureau permettra l'usage d'un terminal.

    Sommaire

    Le jeu de les shells

    Le shell est un interpréteur de commande. On peut simplement lancer une commande pour consulter l'état du système (top, ps), déplacer un fichier (mv), … Ou combiner des commandes, écrire des scripts basés sur des conditions et des variables, … Donc comme l'explicite le manuel GNU, un shell unix est la fois un interpréteur de commande et un langage de programmation.

    La plupart des distributions utilisent par défaut "Bash", mais il est possible de changer de shell, par exemple interactivement en utilisant la commande chsh ("change shell"), ou en modifiant les paramètres d'un terminal en particulier, ou d'un multiplexeur, ou encore plus globalement en modifiant le shell par défaut d'un user (faites un peu attention dans ce cas — les shells ne sont pas tous compatibles, ne tombez pas !).

    Les shells tombent

    Les scripts précisent aussi quel shell invoquer… Si je prends un tuto sur un shell au hasard, voici ce que je vais trouver

    #!/bin/bash
    # This script will take an animated GIF and delete every other frame
    # Accepts two parameters: input file and output file
    # Usage: ./<scriptfilename> input.gif output.gif

    Attention : ce script référence explicitement /bin . Pas 100% sûr que bash y soit installé. Une solution peut être d'utiliser env.

    #!/usr/bin/env bash

    Hormis interpréter les commandes tapées, le shell affiche également un prompt invitant à taper une commande. Quelque chose comme cela :

    [goat@arch:~]$ 
    

    Pour la partie prompt, certains shells vont autoriser un peu de paramétrage, ou l'on peut même installer des plugins pour enrichir les possibilités, comme avec powerline ou même le liquid prompt présenté ici même par son auteur Dolmden.

    On peut aussi trouver un prompt comme starship qui est utilisable avec les différents shells.

    De la préhistoire au Bash

    Pour l'histoire, le premier shell Unix date de 1971, puis le Bourne Shell (sh), du nom de son auteur, apparait en 1977. Beaucoup de fonctionnalités sont déjà présentes : il est scriptable (on peut définir un script avec des conditions dont la si laide esac, définir des boucles, …), les processus peuvent être contrôlés, il est possible de définir des alias, …

    Bourne Shell implémente la norme POSIX que d'autres shells respectent. La licence du Bourne Shell est débatue (avec une certaine vigueur sur Wikipédia!) , en tout cas son code est ici.

    KORN shell n'était, au départ, pas open source - le code n'est libéré que dans les années 2000. Korn Shell implémente les fonctionnalités du Bourne Shell mais ajoutera d'autres éléments, comme des raccourcis vi/emacs, ou comme les tableaux

    $ typeset -A age
    $ age[bob]=42
    $ age[alice]=31
    $ print ${age[bob]}
    42
    

    GNU BASH : /bin/bash

    GNU Bash

    B.A.S.H. = Bourne Again Shell (superbe jeu de mots avec Born Again Shell). Bash implémente la norme POSIX… et un peu plus.

    GNU bash connait une première release en 1989. Il reprendra à son compte des fonctionnalités trouvées jusqu'ici dans de précédents shells, y compris Korn Shell. Bash reste le shell interactif par défaut sur de nombreuses distributions. Il fut le shell sous MacOS.

    Anecdote - quel est le plus gros programme bash que vous connaissiez ? nb, qui propose de gérer vos notes en mode texte (org, markdown, etc), est principalement composé d'un script .sh de … 26736 lignes. Je vous laisse partager vos trouvailles en commentaire !

    DASH : le Debian Almquist shell est renommé ainsi en 1997. Debian l'adopte par défaut pour les scripts, tandis que le shell interactif des utilisateurs reste bash. Ubuntu y passe par défaut sur la 6.10. Dash est léger et performant. Moins de dépendances égal plus de sécurité.

    ZSH

    ZSH ZSH sort en 1990. Toujours compatible avec la norme POSIX, Zsh va améliorer de bien pratiques fonctionnalités d'auto-complétion : appuyez sur <TAB> et Zsh complète pour vous.

    Mais bien plus largement, Zsh va atteindre le paroxysme en terme de fonctionnalités. Tout existe dans Zsh.

    Zsh est connu pour proposer de très nombreuses possibilités de configuration. Ses plugins se comptent par centaine — y compris plusieurs gestionnaires de plugins… Mais un outil très utilisé pour le configurer sort du lot : Oh my zsh, qui permet de gérer plus de 300 plugins ainsi que de nombreux thèmes.

    FISH

    Fish

    Fish pour "Friendly Interactive Shell", date de 2005. C'est un shell non POSIX - certaines fonctionnalités ne seront pas compatibles. Un script bash ne marchera pas forcément.

    Ce shell se veut demander peu de configuration - il est prêt à l'emploi. Choix appréciable quand on peut déjà passer tant de temps à configurer d'autres choses (distro, bureaux, nano, terminaux..)  !

    Il suffit de l'installer pour avoir

    • une coloration syntaxique indiquant quelle commande est valide
    • suggestions : en tapant, on obtient des candidats que l'on peut auto-compléter

    Fish est également scriptable et se veut proposer un syntaxe plus saine. À vous de tester (mais vous ne codez qu'en Rust, n'est-ce pas ?)

    Le gros point de Fish à mon sens, c'est de proposer une configuration par défaut déjà utilisable, comme le fait de se baser sur les pages man ainsi que sur l'historique pour proposer l'auto-complétion. Oubliez les heures passées à configurer - je ne sais pas si Fish a le plus de chevaux dans le moteur, mais avec lui vous êtes déjà prêts à partir.

    Petite fonctionnalité sympa, taper fish_config ouvre une page ouaibe. On peut alors prévisualiser les thèmes, personnaliser le prompt, visualiser les fonctions et variables, consulter l'historique et les raccourcis claviers. Fish a un mode vi.

    Fish a été réécrit en Rust entre 2022 et 2024.

    Ravissant multiplex, 200 mètres carrés

    Gnu Screen

    Ok donc nous avons un shell à choisir, y compris le prompt et il faudra le lancer dans un terminal, mais avant ça, si on avait un gestionnaire de fenêtre dans le gestionnaire de fenêtre ? C'est bien comme cela qu'est présenté GNU Screen, qui gère des fenêtres, typiquement de terminaux. C'est un multiplexeur, en français : la possibilité d'ouvrir plusieurs terminaux dans un seul terminal. GNU Screen sait lister les terminaux ouverts, passer de l'un à l'autre, en tuer… Comme souvent, le wiki arch détaille bien notre affaire concernant screen. Mais GNU Screen est un vieux de la vieille, qui date de 1987.

    Tmux

    Plus souvent cité de nos jours, Tmux (2007) propose des raccourcis à la Emacs ou à la Vim, un menu graphique, des splits verticaux ou horizontaux.

    Zellij

    Il existe d'autres multiplexeurs. On peut citer par ex. Zellij, orienté développeurs, qui affiche une barre de statut, peut afficher les raccourcis claviers…

    Envolez-vous vers un nouveau terminal

    Le choix d'un terminal pourra définir l'apparence de votre interface, comment vous gérez le multi-fenêtre et/ou multi-onglet, la capacité à rechercher, copier-coller, les raccourcis clavier, peut être même comment accéder aux emplacements, vous connecter en ssh.

    Certains terminaux proposent un mode inspiré de Guake (première release 2007), lui même inspiré du terminal dans Quake : le terminal est toujours ouvert et dispo, mais caché et l'appui d'un raccourci clavier le fera apparaître. Le temps de taper trois commandes et le même raccourci le fera disparaître. À voir ce qui se fait encore sous Wayland, je vois par ex. qu'il y a encore une extension GNOME.

    La console sur le bureau

    Première piste : tout simplement utiliser la terminal qui vient avec son bureau, si l'on en utilise un. Évidemment le premier avantage sera une bonne intégration, mais en pratique ?

    Nous verrons aussi plus bas certains terminaux qui sont le terminal par défaut de gestionnaires de fenêtre, mais il s'agit simplement d'un choix par défaut et pas d'une affiliation ni d'une intégration particulière, donc pas de raison de les mentionner ici.

    Console (GNOME)

    Le terminal par défaut a changé sous GNOME 42 (euh bah oui c'était y'a un moment), pour devenir GNOME Console (anciennement Kings Cross Station d'où kgx — j'ai cherché l’exécutable un moment…). Assez peu de fonctions particulières mais : devient rouge lorsqu'on est connecté en root ou violet en ssh, envoie une notif quand une longue commande se termine, sympa. Un bouton de recherche un peu étonnant peut s'avérer pratique. Clairement la logique est d'afficher peu de boutons, peu de choix, et d'investir sur des options par défaut qui fonctionnent. Je ne vais pas retenir Console pour mon usage mais je trouve qu'effectivement c'est un terminal élégant.

    Pour changer le shell de Console, il faudra passer par l'éditeur dconf et modifier l'option org.gnome.Console.shell.

    Certaines distributions ont préféré maintenir gnome-terminal, plus complet, mais gnome-terminal est resté Gtk3 (alors que kgx est bien Gtk4).

    Petite note sur kgx et gnome-terminal : ces terminaux sont basés sur la libvte dont dépendent d'autres terminaux GTK. Voici quelques exemple cités par une page du wiki gnome :

    On pourrait y ajouter Lxterminal (merci à Impromptux).

    Konsole

    Konsole

    Le choix logique pour le bureau KDE. En termes de fonctionnalités, c'est l'artillerie lourde. Multi-profils, signets, multiplexeur, prévisualisation d'images. Konsole est intégrée dans plusieurs applications KDE.

    Pour changer le shell de Konsole, vous pouvez passer par le menu Settings > Configure Konsole > Profiles .

    C'est le moment de mentionner Qtermwidget : ce widget fut originellement basé sur Konsole et servit à développer Qterminal.

    xfce-terminal

    Terminal par défaut du bureau Xfce. Il dépend et hérite de libvte. Il est en Gtk3.

    • Permet plusieurs onglets
    • Intégration avec un gestionnaire de fichiers (ouverture dans le répertoire courant du terminal)
    • Prévention de collage dangereux : quand ça contient un retour chariot, ouvre une popup qui permet d’inspecter et modifier le contenu dangereux.
    • Permet d’envoyer un signal au processus en cours
    • Permet d’avoir une console rapide à la Guake
    • Permet de colorer les onglets manuellement.

    Il est possible de changer le shell dans les préférences.

    Terminology

    Terminology

    Ce terminal sort en 2013, il fait partie du bureau Enlightenment Je pense que c'est le premier terminal à pouvoir afficher des images. Il est possible d'avoir des informations en survolant une URL. Une barre de progression s'affiche durant l’exécution de commandes. Les performances sont au rendez-vous. (Subjectif - serait-ce tout simplement la meilleure appli e17?)

    Emacs et (Neo)Vim

    Mais plutôt que d'utiliser le terminal intégré à son environnement de bureau, pourquoi ne pas utiliser directement celui intégré à son éditeur de texte? Un bon éditeur de texte en effet a forcément son bon terminal. Même Vim? Et oui. C'est donc une solution de lancer le terminal depuis l'éditeur de texte, par exemple pour reproduire les fonctionnalité d'une IME vivre sa vie entière en mode texte.

    Emacs

    Démarrons tout de même par Emacs, où la prise en charge du terminal est plus ancienne.

    Emacs a… 4 terminaux, pourquoi faire simple. 4 terminaux ? Non pas vraiment : 2 shell et 2 terminaux. Il peut y en avoir plus.
    En fait, puisqu'on peut, malgré la rumeur, bel et bien éditer du texte dans emacs, pourquoi ne pas gérer ses commandes au même endroit ? On peut même s'amuser à gérer ses fichiers dans dired, ses processus, finalement un peu tout l'aspect système.

    Mastering Emacs le développe mieux que moi mais vous aurez donc plusieurs possibilités sous Emacs :

    2 SHELLS

    • eshell, le plus emacsien des 2 : un shell 100% implémenté en elisp (!!!). On peut faire beaucoup de emacs dedans , mais tout ne fonctionnera pas. Ne lancez pas journalctl dedans ^^
    • shell. Même chose, ne lancez pas journalctl

    2 TERMINAUX

    • term / ansi-term. Cette fois c'est vraiment un terminal, mais… lent.
    • vterm. Ok cette fois c'est vraiment un terminal, et ça utilise une bibliothèque en C derrière, donc ouf un vrai terminal Emacs existe bel et bien. Attention vterm a besoin d'une bibliothèque.

    Oui je pense qu'il y a vraiment des utilisateurs du terminal sous Emacs. Et il est possible de trouver de petits benchmarks sur les réseaux comme par exemple reddit.

    Vim

    Qui a dit que vim n'était pas bloated et ne pouvait pas gérer cela? (À sa défense vim ne gère pas encore l'email.. ) Vim prend en charge le terminal depuis la version 8.1. Pour changer le shell dans vim, ajouter cette commande dans le fichier de config

    :set shell=/usr/bin/zsh
    

    Les indies

    Pourquoi utiliser le terminal de son bureau, ou de son éditeur de texte, alors que l'on peut utiliser un million d'autres ? Bienvenue dans la jungle. Ne m'en voulez pas si votre petit favori n'est pas listé ici, mais rajoutez sa description en commentaire - il a existé de bien trop nombreux concurrents, et même en se limitant aux projets actifs la liste est bien trop longue. La liste ici pourrait compléter cette dépêche.

    Je rappelle que sont listés ici les terminaux qui sont proposés par défaut sous certains gestionnaires de fenêtre, le parti pris étant que dans ce cas il n'y ait pas d'intégration particulière, contrairement par exemple au terminal KDE.

    Enfin la liste se veut à moitié lister les terminaux populaires actuels, à moitié lister quelques terminaux plus pour un intérêt historique, mais cette dépêche n'étant pas une thèse cette volonté sera assez peu rigoureuse.

    Blackbox

    Blackbox terminal n'est pas affilié à GNOME ni un terminal officiel mais est développé avec cet environnement en tête. Il utilise Gtk4.

    Ptyxis

    Là c'est un cas à part : pour reprendre sans recul le readme.md :

    A modern terminal emulator built for the container era.
    Seamlessly navigate between your host system and local containers like Podman,
    Toolbox, and Distrobox with intelligent detection and a beautiful, responsive
    GNOME interface.

    L'intérêt est donc d'intégrer les conteneurs de toutes sortes pour y accéder rapidement (et les définir rapidement).

    Ptyxis

    Il semblerait qu'il puisse devenir le terminal par défaut sous Ubuntu (25.10?).

    St

    La philosophie de st, dont la première release, 0.1, est de 2017, c'est de rester simple et léger - le point que son site discute, c'est le nombre de lignes de codes limité que devrait avoir un terminal. Son auteur serait fainéant ? Ce terminal sous licence MIT/X Consortium s'apparente à mon sens à un reliquat du passé : il tourne sur X et uniquement sur X (oui, oui je sais pour Xwayland). Néanmoins il m'a paru logique de le citer ici.

    Kitty

    Kitty a une place importante car il a légué quelque chose aux successeurs… Il implémente en effet des extensions venant étendre le protocole historique.

    Ce terminal tourne sous Python et requiert OpenGL. Malgré son âge (première release 2017), c'est le choix par défaut pour Hyprland.

    Kitty offre une tonne de raccourcis claviers, gère les onglets/fenêtres, peut afficher des images, sait afficher des notifications et bien d'autres choses. En terme de philosophie, il se veut orienté power-user.

    Alacritty

    Alacritty se veut un terminal simple et est écrit en Rust. Il est sortit en 2017. Alacritty respecte XDG en cherchant en priorité un fichier de config $XDG_CONFIG_HOME/alacritty/alacritty.toml.

    C'est le terminal par défaut pour au moins deux gestionnaires de fenêtre Wayland très différents l'un de l'autre : Wayfire et Niri.

    • vi mode : appuyez sur control + shift + space et vous passez dans le mode "normal" de vi (par opposition au mode insertion). Les touches au lieu de permettre de taper du texte, permettront alors de se déplacer, sélectionner du texte, le copier…
    • ctrl shift o pour afficher des "hint" sur les URL, ce qui permet de les activer en 1 touche
    • recherche normal (ctrl shift f ) , recherche vi
    • multi fenêtre (spawn new instance)
    • theme https://github.com/alacritty/alacritty-theme

    Pas d'onglet, pas de split — utiliser un multiplexeur au besoin.

    Foot

    Ce serait un peu le successeur de St, au sens où il est codé en C et les premières fonctionnalités mises en avant sont la légèreté et la performance, mais en natif Wayland. Pour autant Foot n'est pas avare sur certaines fonctionnalité. Sa première release est de 2019. C'est le terminal par défaut pour Sway, Dwl.

    Il faudra le configurer à l'aide d'un fichier texte, et foot respectant XDG, ce sera ici $XDG_CONFIG_HOME/foot/foot.ini. Foot propose pas mal de raccourcis claviers, dont le même Hint mode que Alacritty : taper Ctrl Shift O .

    Au cas où il ne serait pas assez léger, Foot propose un mode serveur.

    Wezterm

    De nouveau un terminal en Rust. Wezterm se veut complet, et cross-platform. Il affiche des images, gère les hyperliens, la connexion en SSH avec un client intégré, fait office de multiplexeur.

    Il se configure en Lua.

    Ghostty

    Ghostty

    Ghostty est sous licence MIT. LWN l'a présenté. Il s'agit d'une application récente, début en 2022, v1.0 fin 2024.

    Une barre gtk4 permet d'afficher les onglets, d'en créer un nouveau. Sympatique fonction, ghostty +list-keybinds --default montre toutes les options (et un raccourci permet d'éditer le fichier de config). On peut aussi lister les thèmes avec ghostty +list-themes.

    Peut afficher des gifs, comme Kitty.

    Ghostty se veut un compromis entre la vitesse, les fonctionnalités, l'interface, et cross-platform. Il se veut agréable sans avoir besoin de modifier le paramétrage par défaut. Et il est petit, le paquet Debian par exemple fait 113 Ko.

    Vous pouvez changer le shell sous Ghostty :

    ~/.config/ghostty/config:
    command = /usr/local/bin/fish --login --interactive
    
    

    De plus Ghostty intègre des fonctionnalités "Shell-integration".

    Rio

    (2022)
    https://github.com/raphamorim/rio
    vi mode, hyperlinks, images,

    Le shell peut être modifié dans la config, plusieurs exemples sont fournis

    [shell]
    program = "pwsh"
    args = ["-l"]

    Warp

    Alors là on bascule du côté obscur de l'IA !… et du proprio. Warp est d'abord une entreprise, qui a souhaité réimaginer un outil des développeurs - le terminal. Ce terminal, écrit en Rust, ne sera pas open source : https://github.com/warpdotdev/Warp/discussions/400

    À la première ouverture, Warp suggère d'ouvrir un compte « pour bénéficier de toutes les fonctionnalités ». Ensuite, on ne se trouve pas directement dans une console mais Warp propose plutôt d'ouvrir / cloner un projet. Un raccourci permet cependant de lancer une session normale…
    … Si ce n'est qu'outre des commandes, on peut taper des phrases ! En passant par Claude pour les interpréter… L'IA peut également suggérer des commandes en se basant sur votre historique. Tout ceci peut être désactivé dans les paramètres. Les fonctionnalités IA requièrent une connexion Internet.

    J'ai par exemple testé "Install Wave term from the internet". Warp a commencé par vérifier s'il y avait une commande de disponible "yay", mais cette commande n'était pas dispo sur mon système. Il a alors intelligemment testé d'autres gestionnaires de AUR et a trouvé que paru était installé. De là, il a découvert waveterm dans les dépôts AUR et m'a suggéré d'utiliser paru -S waveterm-bin (control+entrée pour valider, et gogogo). Une fois ces folies passées, on revient à une expérience normale où la commande se déroule (pensez à lire les AUR avant d'installer aveuglément !)

    Quand vous parcourez un projet, Warp peut indexer ces projets pour améliorer les suggestions.

    Au lieu d'utiliser votre clavier pour taper, Warp peut reconnaître votre voix. Outre des commandes ou des phrases, il est possible de commencer par un "/" pour taper une "slash command".

    Il y a également des fonctionnalités d'équipe, notamment une fonctionnalité de collaboration en temps réel. Certaines fonctionnalités sont payantes.

    Warp propose un certain nombre de fonctionnalités classiques : personnalisation du prompt, apparence, raccourcis claviers, …

    L'entreprise fournit un benchmark où Warp s'en sortirait aussi bien que Kitty ou Alacritty sur vtebench

    WaveTerm

    Waveterm est un peu la réponse open source à Warp (Apache 2.0).

    Quand on l'ouvre la première fois, c'est la foire ! à gauche, le panneau invite de commande qui occupe un tiers de l'écran.
    Tiers du milieu : en haut la consommation du CPU (hein?). Au milieu, un bout de page internet (hein?). En bas, un explorateur de projet. Tiers à droite : en haut, des raccourcis clavier qui s'affichent. Au milieu, un bout de doc sur Wave. En bas, une invite pour Wave IA. Bien sûr il s'agit d'une démo et il sera possible de personnaliser ce qui est visible au démarrage. Il est également possible lorsqu'on utilise un des "blocs" de le passer en mode "pleine fenêtre" puis le réduire par la suite.

    Bon, testons l'invite IA en demandant d'installer… Warp! Il commence par m'expliquer les différentes méthodes d'install en fonction de l'OS (ah ! il n'a pas détecté…). J'explique que j'utilise Arch et il me dit d'utiliser un AUR helper ou de cloner le dépôt du AUR. Mais il ne détecte pas si j'ai paru ou yay ou autre.

    On peut utiliser d'autres modules IA. Wave inclut également un explorateur de fichiers.
    Les paramètres se gèrent bloc par bloc - on paramètre d'un côté les blocs que l'on souhaite au démarrage, de l'autre pour un bloc donnée, par exemple les préférences.

    3. Liens

    Norme POSIX sur le shell

    https://linuxfr.org/news/gameshell-apprendre-les-rudiments-du-shell-en-s-amusant

    Bref cours sur le shell

    Cours plus complet sur le Bourne Shell

    Revue de fish :

    Autre revue de Fish

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    •