Je travaille depuis plus de vingt ans sur site central (mainframe), et ça fait quasiment autant de temps que ma marotte, c'est me faciliter la vie au travail en automatisant le plus possible les actions répétitives.

Vous me direz rien de bien nouveau, c'est l'essence même de l'informatique…

Certes, mais je me rends compte qu'il existe tout un univers plutôt confidentiel à mon sens qui gravite autour l'aménagement de ses propres raccourcis clavier.

Sommaire

• Un peu d'historique
  • Problème de place
  • Le pad
  • Le cas Pacbase
  • L'invite de commande « universelle »
• Les logiciels de raccourcis sous Windows
  • Clavier+
  • AutoHotKey
  • Fonctionnalités communes
  • Ce qu'apporte AHK
• En résumé
• PS
  • Quelque raccourcis que j'utilise tout le temps
  • Tip

Un peu d'historique

Comme déjà écrit, je travaille sur site central, et pendant longtemps, ça voulait dire utiliser un émulateur 3270 (même si ça sert encore beaucoup pour les tâches d'administration, Eclipse et VSCode sont de plus en plus présents, notamment pour développer). C'est un logiciel qui simule un terminal passif (qui se contente d'afficher un écran, et de réagir au clavier, point barre - mais qui dispose du 24 touches fonction physiques), et qui dispose de fonctionnalités « modernes », tel le copier-coller (oui, oui, point de copier-coller sur terminal passif).
Ce qu'il y a de chouette avec un émulateur, et ça rejoint (enfin) le sujet de cette dépêche, c'est que ça permet de lancer des séquences de frappes de touche.

Prenons comme exemple l'affichage d'une table de paramétrage, pour afficher le contenu d'une table il faut :

• Appuyer sur la touche ECHAP (qui efface l'écran)
• Taper X RCD071
• Valider avec Enter
• Saisir le nom de la table de paramétrage
• Interroger son contenu avec PF3

L'émulateur permet de lancer des séquence de touches de plusieurs manières :

• à l'aide d'un raccourci clavier ;
• à l'aide d'un pad, ensemble paramétrables de boutons auxquels on peut associer des actions, dont une séquence de frappes de touche. C'est là que ça commence à devenir intéressant, je vais y revenir.

En reprenant l'exemple du listage d'une table de paramétrage, je peux facilement associer le listage de la table1 à un raccourci, et celui de la table2 à un autre.

Problème de place

Et c'est là qu'on s'aperçoit vite des limites des raccourcis claviers : leur nombre est forcément limité, d'autant plus que bon nombre de combinaisons sont déjà prises : il est illusoire de vouloir se passer de CTRl+C et de CTRL+V par exemple.
L'autre problème est celui de la mémoire, pas celle du PC, mais celle de celui ou celle qui est derrière le clavier : pas facile de mémoriser toutes ces combinaisons.

Le pad

J'ai gardé pour maintenant cette histoire de pad : mais qu'est-ce que ça apporte ? Et bien ça « libère » de la mémoire : la vocation du raccourci est disponible sous les yeux, et ça, j'achète !

Moyennant un petit travail de classification en sous-groupes, je retrouve facilement tous mes raccourcis en un clin d'œil.
Mais n'avoir à disposition que des boutons, est-ce suffisant ?
Pas vraiment, parce que libellé d'un bouton, c'est statique.

Le cas Pacbase

PACbase est un AGL (NdM: propriétaire) générant du COBOL, intégrant un dictionnaire de données. On y stocke :

• des données ;
• des structures de données ;
• des programmes ;
• des textes pour la documentation ;
• etc.

Ce qui est important pour le sujet que j'évoque que la navigation dans ce référentiel est entièrement textuelle, on accède aux entités au travers d'une ligne de commande :

• j'affiche la donnée toto en tapant E toto ;
• j'affiche la documentation de donnée toto en tapant e toto gc (ou si je suis déjà en train de consulter la donnée toto en tapant -gc) ;
• j'affiche un programme titi en tapant p titi, sa documentation en tapant p titi gc
• etc.

C'est là qu'on s'aperçoit de limite des boutons (même si c'est mieux que les raccourcis) : pas question de créer autant de boutons que d'entités à accéder.

L'invite de commande « universelle »

Il se trouve que l'interface principale du site central (hors applications métiers) qui s'appelle ISPF (NdM: propriétaire) est également textuelle est qu'elle possède également une ligne de commande.

J'ai donc cherché à mettre au point une interface dans laquelle je taperai mes commandes, qui seraient mémorisées et qui, à l'instar du comportement d'un terminal, faciliterait le rappel de commandes.

Au passage, j'ai écrit une macro « universelle » qui permet d'interagir de manière scriptée avec l'émulateur, en utilisant un pseudo langage très basique, mais permettant des actions reproductibles : saisie de paramétrage (permettant une « saisie » d'environnement en environnement), réinitialisation de mot de passe avec envoi de courriel avec les mots de passe provisoire, etc.

Je me suis appuyé sur différents modules proposés par l'émulateur 3270, avec comme limites l'univers site central. Or il se trouve que j'avais envie d'automatiser plein d'autres actions sur d'autres logiciels (comme lancer les règles dans Outlook par exemple).

Les logiciels de raccourcis sous Windows

Clavier+

C'est alors que j'ai découvert :

• Clavier+ (GPLv3), un logiciel libre qui a la bonne idée de pouvoir être lancé en ligne commande avec une documentation tout en français ;
• les pages HTA, qui sont des fenêtres écrites en HTML / Javascript / CSS.

J'écris mes pads en HTA, avec des liens qui lancent des actions via Clavier+. Et là, c'est quasi parfait : je paramètre Clavier+ pour lancer une fenêtre HTA quand je tape sur la touche PAUSE (facile d'accès et peu utilisée en standard) qui m'affiche des boutons d'actions et des invites de commandes, fenêtre qui se masque une fois l'action lancée et que je rappelle en rappuyant sur PAUSE. J'ai donc Clavier+ qui lance une fenêtre qui permet de lancer plein d'actions via Clavier+. Pas toujours facile de s'en sortir avec du Javascript pas toujours reconnu dans ses dernières fonctions pourtant bien pratique, et surtout, pas simple de gérer la persistance des données, même si je m'en suis sorti à l'aide de cookies.

AutoHotKey

Je change d'entité dans le groupe qui m'emploie, et patatras, pas de Clavier+ dans le centre logiciel ! Je me lance dans une demande d'intégration de Clavier+, demande qui traîne, et voilà que je découvre que si Clavier+ n'est pas proposé, c'est qu'à sa place figure AutoHotKey (GPLv2)

\o/ : apothéose : Autohotkey (AHK), c'est clavier+ puissance 1 000 ! Ça gère les raccourcis — heureusement —, mais aussi et surtout les interfaces graphiques, les fichiers, etc. C'est très puissant, mais la documentation — tout en anglais — est parfois un peu absconse (Clavier+ c'est juste génial à ce niveau).

Fonctionnalités communes

• Activation d'une fenêtre par son titre
• Restriction de l'usage d'un raccourci à une fenêtre donnée (via son titre)
• des configurations séparables par fichiers

Ce qu'apporte AHK

• les interfaces graphiques
• interaction avec le système de fichiers
• la superposition des configurations
• et beaucoup plus encore

En résumé

Pour celles et ceux qui souhaitent découvrir comment facilement paramétrer des raccourcis claviers, Clavier+ et fait pour vous. Pour aller (beaucoup beaucoup) plus loin AutoHotKey ouvre tout un univers de possibilités.

PS

Quelque raccourcis que j'utilise tout le temps

• rappel des commandes passées (PACbase et ISPF)
• lancement des règles sous Outlook
• recherche des erreurs de compilation COBOL sous VScode
• configuration et tri des SYSOUT sous SDSF

Tip

Ne pas rager pas si votre tout dernier raccourci ne fonctionne pas avec Clavier+ : vous avez certainement laissé la fenêtre de configuration ouverte…

Nous sommes fiers de vous annoncer la 13ᵉ édition de Kernel Recipes. Elle aura lieu du 21 au 23 septembre 2026 à Paris, à la Fondation Biermans-Lapôtre, 9A boulevard Jourdan dans le 14ᵉ, RER Cité universitaire. Comme les années précédentes, une vingtaine d’interventions autour du fonctionnement de la communauté, des outils, de Rust, de la sécurité… et, pour la première fois (mais de façon raisonnée), de l’IA appliquée au développement noyau.

Le parrain de cette édition : Jonathan Corbet

Cette année, nous avons l’immense honneur d’accueillir Jonathan Corbet en tant que parrain de l’édition. Rédacteur en chef de LWN.net et observateur privilégié du développement du noyau depuis des décennies, il a participé grandement à la construction du programme – autant dire que l’édition s’annonce très bien !

Les conférences : variées, avec un peu d’IA, du Rust, de la sécurité, des outils…

Le programme mêle, comme d’habitude, mainteneurs historiques et nouvelles têtes :

• Steven Rostedt revient sur les coulisses peu glorieuses des futex (Futex: The good, the bad and the ugly! (mostly ugly)) ;
• côté Rust, Miguel Ojeda fait le point sur Rust for Linux et Danilo Krummrich (Red Hat, fondateur du driver Nova pour GPU NVIDIA) détaille comment imposer à la compilation les règles de cycle de vie des drivers ;
• côté sécurité, Marta Rybczynska se demande si Linux est enfin secure by default, et Greg Kroah-Hartman abordera la sécurité à l’ère des LLM ;
• côté outils, on retrouve Patrick Steinhardt (GitLab) sur l’actualité de Git, Konstantin Ryabitsev sur l’infrastructure kernel.org, et Matthieu Baerts sur MPTCP ;
• côté ordonnancement et mémoire, SeongJae Park présente DAMOS, Changwoo Min et Gavin Guo (Igalia) parlent de leur ordonnanceur BPF LAVD, Victor Laforet (Inria) de verrouillage et ordonnancement, et Roman Guschchin de la gestion mémoire des cgroups ;
• et bien sûr, Martin Uecker, Arnd Bergmann, Detlev Casanova (Collabora) et d’autres viendront compléter ce menu copieux.

Et la fameuse touche IA, justement : oui, le sujet est au programme cette année, mais on est resté raisonnable :

• Greg Kroah-Hartman, « You are holding it wrong! » : comment obtenir d’un LLM un correctif de bug réellement valide, ce qui marche, ce qui ne marche pas, et pourquoi la plupart des gens s’y prennent mal ;
• Roman Guschchin, The Sashiko review system : un système de revue de patchs assisté par IA, conçu spécifiquement pour le noyau, qui aurait détecté plus de la moitié des bugs dans un corpus de 1000 correctifs historiques ayant pourtant passé la revue humaine.

Deux conférences, une seule vraie question : à quoi ressemble l’outillage assisté par IA quand il se confronte à la rigueur du développement noyau ?

Comme chaque année, Kernel Recipes organise ses enchères caritatives ! Cette année, nous avons souhaité mettre à nouveau en lumière le travail de la Software Freedom Conservancy. Bradley Kühn interviendra sur ce sujet le 22 septembre, juste avant le lancement des enchères.

Dans la salle

Frank sera bien sûr de la partie pour croquer sur le fait les orateurs et oratrices, mais aussi participants, perpétuant une tradition désormais incontournable de la conférence.

Notre mascotte est en train de se faire une beauté et devrait apparaître prochainement dans de nouveaux habits.

Sponsors

La conférence ne pourrait pas avoir lieu sans nos sponsors. Ils nous supportent en 2026 : Meta, ARM, PremDay, Jump Trading, HaProxy, Igalia, Collabora et d’autres à venir très bientôt.

Passer du système de gestion de contenu WordPress au générateur de sites statiques Hugo c’est changer de paradigme, il faut savoir ce que l’on va gagner et ce que l’on va perdre et il faut retrousser ses manches, un jour viendra où cela se fera en un clic, mais ce n’est pas aujourd’hui !

Sommaire

• Avant même de se poser la question comment, on peut se poser la question : pourquoi ?
  • Mais pourquoi Hugo et pas une autre solution, par exemple Jekyll ?
• Ma vie, mon œuvre
• WordPress via le navigateur, Hugo via le terminal
• On installe le plugin, clic ! On importe le résultat et c’est fini !
• Exportez votre site WordPress et appliquez un outil magique !
• La vérité est ailleurs ?
• On installe Hugo
• C’est pas beau hein ?
  • Les blocs réutilisables de WordPress
  • Les <figure>
  • URL permanentes
  • URL relatives
  • Le menu
• Un site WordPress c’est un site web comme un autre
• On repart de zéro et on mélange tout
  • Variations mais pas sur le même thème

Avant même de se poser la question comment, on peut se poser la question : pourquoi ?

Avec WordPress chaque page repose sur du PHP, un programme est exécuté qui peut faire de nombreuses actions, il y a une base de données. WordPress est un des classiques LAMP (Linux, Apache, MySql, PHP) et consorts, il nécessite l’installation de multiples composants. Quand le contenu à délivrer doit s’adapter au contexte utilisateur et à d’autres facteurs, c’est approprié, pour un site de commerce ça l’est, s’il s’agit d’une vitrine statique, ça ne l’est pas. Entre les deux on trouve le blog, qui peut se balancer d’un côté ou de l’autre si l’on souhaite gérer des accès utilisateurs, suivre les pages ou ajouter des interactions.

Avec Hugo, le site est généré une seule fois puis les pages sont délivrées, à l’ancienne dirait-on. À la grande époque où l’on éditait le HTML à la main et on publiait son site via FTP. Sauf qu’avec Hugo on manipule du Markdown plutôt que du HTML. Le Markdown est pratique, c’est l’héritage pragmatique d’Aaron Schwartz dont on peut encore trouver la trace dans le code PHP de génération. Le Markdown lui-même porte une étincelle de liberté, il est désormais normalisé dans la RFC 7763. Et on utilise le programme Hugo qui est un binaire fourni, ou bien compilé depuis du code Go, pour générer des pages HTML. Le site généré peut être délivré en http par Hugo ou bien par n’importe quel serveur web. Hugo repose aussi sur des en-têtes front-matter dans les fichiers Markdown qui est une extension plus récente.

Sortir de WordPress c’est sortir d’une zone de confort et ce sera nécessairement perdre des fonctionnalités, comme l’édition en ligne directe intégrée par exemple, le suivi de vues et les formulaires.

C’est aussi faire un choix simplificateur, économe et efficace. Beaucoup moins énergivore il est aussi beaucoup plus efficace et rapide. Il est aussi beaucoup plus facile à déployer qu’un WordPress puisqu’en définitive ce n’est qu’un binaire et un thème.
Une autre bonne raison de migrer est la sécurité, comme a pu le faire le projet Xubuntu à la fin de l’année dernière suite à la compromission de leur site de téléchargement sous WordPress

Mais pourquoi Hugo et pas une autre solution, par exemple Jekyll ?

Hugo est la version la plus efficace, écrit en Go et compilé, les performances se rapprochent sans les égaler de celles de Rust ou de C. Et il est maintenu, dispose d’une communauté qui maintient des thèmes permettant de facilement avoir un rendu à la mode. Jekyll est en Ruby qui n’est pas le plus performant des langages mais est très versatile. Jekyll est apparu avant Hugo ce qui explique sa notoriété.

Ces deux logiciels ont popularisé la génération de sites statiques, mais ce ne sont pas les seuls, eleventry par exemple a déjà été couvert par un journal sur LinuxFr.org.

Ma vie, mon œuvre

Dans mon cas je ne me suis pas posé la question puisque je réponds à une demande d’une personne qui a déjà fait son choix, il faut migrer !

Avant de me lancer dans l’aventure j’ai dû me renseigner, parce que j’opère bien un site statique qui me sert de vitrine et celui-ci est en Markdown sous Git, mais tout est fait à la main et je ne connais pas Hugo. Je ne suis pas non plus un grand utilisateur de WordPress, que j’ai toujours trouvé lourd, et d’ailleurs j’ai toujours eu un faible pour les challengers, et je m’étais penché sur Joomla qui a les mêmes défauts. Utiliser ces CMS c’est déjà avoir appris une façon de penser, avec les pages et les posts, cela ne m’a jamais paru intuitif.

Donc j’étais absolument et résolument prêt pour cette migration !

Vous pouvez à ce moment me demander pourquoi donc l’ai-je fait ?

Parce qu’un ami me l’a demandé, parce qu’il rémunère pour cela et parce que je trouve que cela va dans le bon sens. Celui de l’éco-responsabilité, une sobriété qui ne transige pas avec la qualité et un mouvement vers plus d’indépendance.

Donc je me renseigne.

WordPress via le navigateur, Hugo via le terminal

Si vous ne souhaitez pas utiliser de terminal et des scripts shells, alors je serais d’avis de vous déconseiller fortement de vous lancer dans l’aventure Hugo.
Parce qu’Hugo c’est du Web as code, très exactement l’inverse du WYSIWYG le PETALE Pris à l’écrit tel à l’écran. Tout se fait en Markdown dans votre éditeur favori.
Cela s’opère souvent via Git et le fait de pousser le commit git vers le serveur régénère le contenu du site.
S’il est possible de le faire via un VSCodium, je reste sur mon Emacs favori, mais évidemment ceci un choix très personnel.
Un bon éditeur de texte capable de te laisser saisir des codes Markdown est absolument nécessaire, un éditeur de texte dans ce cas ce n’est pas un traitement de texte, Libreoffice par exemple ne m’apparait pas comme l’outil adapté, mais je vous laisse juge.

On installe le plugin, clic ! On importe le résultat et c’est fini !

C’est assez évident en fait il suffit de suivre ce que propose le projet Hugo en matière de migration vers Hugo.

Ça c’est ce que l’on souhaite et j’y ai presque cru.

Il n’y a pas de plugin WordPress officiel pour exporter vers Hugo, mais il y en a pour exporter en Jekyll. Sachant que Hugo sait importer du Jekyll, cela semble évident.

Tout d’abord il faut importer le plugin sous WordPress.
Si cela semble évident quand le plugin est disponible dans le magasin des plugins WordPress, cela ne l’est plus quand il faut l’installer à la main.

Dans mon cas, et peut être dans le vôtre aussi vous n’avez pas installé le WordPress, il vous a été fourni en tant que service hébergé, et c’est pourquoi vous êtes limités aux plugins officiels, quand encore, on vous y autorise.

Donc en suivant le lien de migration depuis WordPress je lis (en anglais, mais je vous offre gratuitement la traduction) :

wordpress-to-hugo-exporter

Un plugin en un clic qui convertit tous les posts, pages, taxonomies, metadata, et settings en Markdown et YAML et déposable dans Hugo. (Note: Si vous avez des difficultés avec ce plugin, vous pouvez exporter le site pour Jekyll et utiliser le convertisseur intégré à Hugo listé ci-dessus)

Oui mais non, je n’ai pas accès au backend.

Et pourquoi ne pas juste installer un plugin officiel comme celui dont wordpress-to-hugo-exporter dérive ? Le jekyll-exporter

Ce n’est pas un échec, mais ça n’a pas marché.

Après l’installation du plugin et l’utilisation de l’export le site me réponds avec aplomb : 500 Internal ERROR.

Plutôt que d’abandonner, je cherche sur le projet source s’il y a un bug en cours et effectivement : Issue #400 sur wordpress-static-site-exporter. Sur ce, je rajoute mes informations sur le bug et j’attends une réponse.

Donc le ça fonctionne en un clic n’aura pas tenu bien longtemps, en attendant un correctif je me penche sur une alternative. Mais ne vous inquiétez pas, nous y reviendrons, si vous avez suivi le lien de l’issue vous le savez déjà !

Exportez votre site WordPress et appliquez un outil magique !

Ce n’est pas bien grave, il y a d’autres outils…

blog2md
Fonctionne sur l’XML exporté depuis le site gratuit votre VOTRE-DOMAIN.wordpress.com. Cela sauve aussi les commentaires approuvés sous forme YOUR-POST-NAME-comments.md à côté des posts.

Ce projet n’a pas évolué depuis quatre ans, je ne vais pas choisir cette option.

wordhugopress
Un petit utilitaire écrit en Java qui exporte le site WordPress depuis la base de donnée et les resources (c’est-à-dire par exemple les images) stockées localement ou à distance. Ainsi la migration depuis des backups est possible. Support de multiples sites vers un seul site Hugo.

Je n’ai pas accès à la base de données où à l’export des backups, je ne vais pas choisir cette option non plus.

wp2hugo

Celui-ci est un très bon candidat, sauf que je vends mon travail et la licence de cet outil est Attribution-NonCommercial-ShareAlike 4.0 International, donc je ne vais pas choisir cette option. Si mon budget avait été très important j’aurais envisagé de contacter l’auteur pour négocier, mais ce n’est pas le cas.

Donc aucun de ces autres outils ne répond à mes besoins.

La vérité est ailleurs ?

Oui, mais il n’y a pas que site Hugo de référence non plus.

Les forums et en particulier https://discourse.gohugo.io/t/wordpress-migration-url-rewriting/3827, mais il a été écrit il y a presque dix ans…
Et dans mes pérégrinations hors des sentiers battus des scripts Python émergent https://www.infinitescript.com/2024/01/migrate-from-wordpress-to-hugo/.
Ce guide aussi m’a inspiré https://fr.benchwiseunderflow.in/blog/guide-complet-migration-wordpress-hugo/ ceci dit fournir les scripts Python dans son blog sans l’indentation, ce n’est pas ce qui se fait de mieux.

Voici la liste des projets que j’ai regardés, je n’en ai testé qu’une sous partie entre ceux utilisant de l’IA ou pour lesquelles mon utilisation ne respecterait pas la licence et celles dont le contenu semble trop vieux…

Site	Commentaire	langage	html -> markdown	license	testé
https://github.com/benbalter/wordpress-to-jekyll-exporter	plugin officiel nécessite une migration supplémentaire jekyll -> hugo	php wordpress plugin	Markdownify	GPL-3.0	✅
https://github.com/SchumacherFM/wordpress-to-hugo-exporter	basée sur une version du projet ci-dessus mais datant de 2014, a dérivé depuis. Ce n’est hélas pas un plugin officiel	php wordpress plugin	Markdownify	GPL-3.0-or-later	✅
https://github.com/lonekorean/wordpress-export-to-markdown	travailler sur l’export en XML it won’t migrate GUID correctly	nodeJs javascript	turndown	-	✅
https://github.com/bradfeld/wp-to-hugo	plus complet mais : IA generated Claude / typescript via API strip WordPress block comments	nodeJs typescript	turndown	MIT License (& IA ?)	Non : IA
https://github.com/ashishb/wp2hugo	attachment page post wp_navigation wp comments footnote	go	[[site_scrapping_vers_Hugo#johanneskaufmann_html_to_markdown]]	Attribution-NonCommercial-ShareAlike 4.0	Non, licence non commerciale et c’est un travail commercialisé
https://github.com/helgeklein/WordPress-Hugo-Migration-Scripts-HTML-Markdown/	https://helgeklein.com/blog/scripted-wordpress-html-to-hugo-markdown-migration/ post_type in (“post”, “page”)… donc pas de gestion des blocks	python	BeautifulSoup	MIT
https://github.com/some-programs/exitwp	https://web.archive.org/web/20221120194327/https://www.justindunham.net/migrating-from-wordpress-to-hugo/ 2019 ? page et post + item_type_filter	python	beautifulsoup html2text	~ GNU GPL 3
https://github.com/dreikanter/wp2md	issues https://github.com/dreikanter/wp2md/issues	python	html2text
https://fr.benchwiseunderflow.in/blog/guide-complet-migration-wordpress-hugo/	status “publish” post_type “post”, “page” le code fourni est à copier coller et non fonctionnel	python	pandoc
https://www.infinitescript.com/2024/01/migrate-from-wordpress-to-hugo/	post de blog contenant le code python utilisé	python	re (regular expression python)
https://github.com/palaniraja/blog2md	Le projet a 4 ans et part de blogger et non de WordPress	javascript	?	absence de licence	non testé

C’est wordpress-export-to-markdown qui a remporté une partie du travail. Cela a nécessité l’installation de node puisque le code est en javascript.

J’exporte donc le site via la fonction standard d’export de site WordPpress qui fourni un fichier XML.

Cet export contient tout sauf les images et les autres ressources, donc il faudra que l’outil puisse les rechercher, et donc que le site WordPress soit toujours activé. Ceci ne peut donc pas se faire sur un site indisponible ou bien même déjà arrêté.

On installe Hugo

Et il faut un serveur, une vraie machine avec une adresse IP publique, un serveur web.
Là où pour du WordPress un hébergeur fournit la solution, en Hugo le plus classique est tout de même de mettre en place son propre serveur. Avec tout ce qui va bien, et le certificat pour HTTPS.

Mais avant de faire le pas, cela s'installe en local sur une machine de développement avec docker, podman, inclus ou bien même directement puisque ce n’est qu’un exécutable.

sur une machine Linux :

sudo apt install hugo

ou

snap install hugo

Il suffit de lancer hugo server dans le répertoire du projet hugo et se connecter sur localhost avec l’URL qui a été fournie dans le terminal.

Dans le cas d’une migration vous aurez forcément à modifier de nombreuses pages de votre site qui comportent des problèmes de code markdown mal converti depuis le HTML.

Et il vous faudra utiliser des scripts, dans votre langage préféré, mais dans tous les cas l’utilisation d’expressions régulières sera nécessaire. C’est-à-dire : il faut connaître un minimum de programmation.

Voici le genre de commande qui recherche tous les fichiers avec l’extension.md et supprime le 'Proudly powered by WordPress' dedans :

text='Proudly powered by <a href="https://wordpress.org" rel="nofollow">WordPress</a>'
find content -name '*.md' -print0 | xargs -0 sed -i 's|'"$text"'||g'

Attention cette commande fonctionne, car le texte $text est compatible avec la syntaxe de commande sed en particulier utiliser un '|' dans la variable text serait problématique.

En suivant la procédure d’installation rapide https://gohugo.io/getting-started/quick-start/ on va créer un dépôt git. Si par la suite on souhaite le répliquer pour le tester ailleurs alors il ne faudra pas oublier les submodules pour le thème, sinon la génération du site rendra un site vide.

git clone user@server:quickstart --recurse-submodules mon_site
cd mon_site
hugo server

On termine avec un firefox http://localhost:1313 par exemple pour voir en local.

on pourra alors éditer le contenu sous content avec notre éditeur préféré et créer un commit git quand nous sommes contents de notre résultat local.

git add content
git commit -m 'édition numero xx du site'
git push

Cela doit pousser sur le git parent le contenu. Si le git parent est attaché à la production alors la production est mise à jour ainsi.

C’est pas beau hein ?

Le contenu généré par l’outil de migration ayant été copié dans le répertoire content du projet Hugo, il suffit de lancer le serveur Hugo pour qu’il soit délivré sur le port indiqué en console. En se connectant avec un navigateur firefox https://localhost:1313, le contenu apparait…

Ah j’oubliais, en Hugo toute la présentation est contrôlée par le thème, ici le thème choisi est ananke, c’est celui proposé dans la documentation de démarrage rapide de Hugo

Il y a du contenu, certes mais quand même il y a eu des dégâts collatéraux.

Cliquez sur l’image pour voir la vidéo.

Les blocs réutilisables de WordPress

Il s’agit d’une fonctionnalité ajoutée dans l’éditeur de WordPress Gutemberg, la possibilité de créer des blocs réutilisables qui seront référencés dans d’autres pages ou bien même dans d’autres blocs

Pratiquement tous les outils d’export ne conservent pas les items qui ne sont ni de type page ni de type post et quand ils conservent les autres type, ils ne gèrent pas les blocs réutilisables.

Dans le fichier d’export.xml de WordPress on les retrouve ainsi :

<item>
…
<wp:post_id>610</wp:post_id>
…
</item>

et sont utilisés par référence :

<!-- wp:block {"ref":610} /-->

Dans mon cas pour l’outil wordpress-export-to-markdown, j’ai créé une demande de fonctionnalité pour le support des blocs réutilisables.

En pratique les outils perdent complètement le contenu de ces blocs.

Une façon de résoudre le problème est d’utiliser la source HTML générée par WordPress directement et de la convertir en Markdown.

Les <figure>

Hugo ne gère pas le tag <figure>, il faut supprimer ces tags, sinon les images qu’ils contiennent n’apparaissent juste pas. Or WordPress génère souvent des blocks HTML avec des tags figure.

Voici un script bash qui supprime le tag figure partout dans tous les fichiers.md de content.

find_files=(find content -name '*.md' -print0)
command2=(xargs -0 sed -i 's|</\?figure[^>]*[>]||g;')
"${find_files[@]}" | "${command2[@]}"

URL permanentes

Il est crucial que les pages migrées se retrouvent au même endroit après migration. C’est crucial car cela fait partie du SEO, votre référencement, si vos pages changent de place, les moteurs de recherche vont vous perdre, tout comme les références depuis tout autre site.

En Hugo c’est le champ urldans l’entête front-matter du fichier markdown qui sert à indiquer où la page destinée à être délivrée.
Cette URL peut être totalement différente du répertoire dans lequel le fichier se trouve, même s’il est conseillé de conserver la mẽme hiérarchie, c’est une solution pratique.

URL relatives

WordPress délivre toutes ses pages avec des URL absolues dans le corps c’est-à-dire avec le nom du site intégré dans l’URL, ceci est un souci quand on souhaite déplacer le site, ou bien avec un site réplica lui aussi accessible en ligne mais sous une autre URL.

Les expressions régulières sont là pour ça, il faut supprimer http://monsite du début des toutes les URL. Pour rappel, à l’intérieur d’une page HTML un lien href='/article/linuxfr.html' est une référence relative dans le site courant, si l’URL du site est https://example.com alors le lien avec l’URL absolue est au lien `href='https://example.com/article/linuxfr.html'.

Si vous ne faites pas vous pourriez avoir la surprise lors de l’arrêt du site WordPress de ne plus avoir les images et autres ressources, car elles étaient sur le site original et non sur le nouveau site migré !

voici un exemple en bash

find_files=(find content -name '*.md' -print0)
command2=(xargs -0 sed -i "s|https://${site_domain}||g")
"${find_files[@]}" | "${command2[@]}"

Le menu

Le menu a été perdu, c’est ballot !
Via l’export Hugo il n’y a pas de menu du tout, il est perdu.
Dans WordPress le menu est supporté par du CSS les classes wp-block-navigation…
En Hugo c’est le thème qui le gère, ici avec ananke il faut rajouter des entrées de menu avec menu.main, dans mon cas j’ai rajouté le menu globalement dans le fichier de configuration Hugo, mais il y a plusieurs façons de définir les menus en Hugo.

Un site WordPress c’est un site web comme un autre

Une autre approche est de considérer qu’un site WordPress c’est un site web comme un autre.
Un navigateur n’a pas de code particulier pour visualiser un site WordPress, donc un site WordPress est juste un site web, certes avec beaucoup de JavaScript et CSS, mais un site web.
Et un site web, ça se siphonne, et c’est facile, il suffit de regarder le projet internet archive, par exemple le site de LinuxFr.org le 2 avril 2018 pour s’en convaincre, il est très facile de récupérer le contenu visible d’un site web, à condition de connaître tous les points d’entrée et en pratique il suffit de partir de la page principale.
Puisque vous migrez un site que vous possédez, il n’y a pas de souci à utiliser un aspirateur de site.

Une fois le site récupéré, il y a des convertisseurs Markdown.

En particulier j’ai employé le convertisseur de HTML vers Markdown de Johannes Kaufmann, qui est aussi une base pour d’autres projets de conversion pour des applications particulières dont WordPress.

Et le tour est joué ! Ou presque…

On repart de zéro et on mélange tout

Si aucune des solutions ne fonctionne, chacune permet de créer une partie du site. En utilisant toutes les générations on peut récupérer les meilleurs pages.

Dans mon cas le plugin officiel de migration de jekyll vers hugo a été corrigé et j’ai donc pu l’utiliser.

En utilisant aussi des parties générées depuis le site statique, j’ai obtenu un résultat acceptable, mais cela ne s’est pas fait sans une série de petits scripts en bash à base de find et de sed et donc d’expression régulières, les fameuses regex.

Variations mais pas sur le même thème

Une fois le contenu cohérent, il est temps de tester d’autres thèmes Hugo pour donner au site une apparence différente.
Ces thèmes aussi peuvent être personnalisés. La notion de thème existe déjà dans WordPress, donc vous ne devez pas être surpris, mais les thèmes de WordPress ne peuvent pas être transposés tels quels dans Hugo, par exemple le thème twentytwo désormais classique ne se résout pas en la copie de son continu sur Hugo.
Mais passer à Hugo c’est aussi l’opportunité de se démarquer.

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.

Ce compte-rendu liste les principales modifications survenues en février, mars et avril. Ces changements sont numérotés de hrev59356 jusqu’à hrev59671 dans le code source de Haiku, soit environ 320 changements ce trimestre.

Les grosses nouveautés sont la disponibilité d’une version ARM64, l’accueil de 3 participants au Google Summer of Code et l’approche de la version beta 6, très attendue puisque la dernière version publiée, la beta 5, date de septembre 2024.

Sommaire

• Portage de Haiku pour les architectures ARM64 et RISC-V
• Applications
  • TextSearch
  • HaikuDepot
  • Software Updater
  • DeskCalc
  • Mail
  • Tracker
  • StyledEdit
  • CharacterMap
  • DeskBar
  • Terminal
  • LaunchBox
  • MediaPlayer
  • ActivityMonitor
  • WebPositive
  • Devices
  • Préférences de localisation
  • Préférences d’apparence
• Outils en ligne de commande
• Kits
  • Application Kit
  • Support Kit
  • Interface Kit
  • Storage Kit
  • Network Kit
  • Media Kit
• Serveurs
  • app_server
  • launch_daemon
  • Bluetooth
  • Mail
  • Media
• Pilotes matériels
  • Stockage
  • Réseau
  • Affichage
  • USB
  • Virtualisation
  • Gestion d’énergie
• Systèmes de fichiers
  • Packagefs
  • NTFS
  • BTRFS
  • XFS
  • NFS v2
  • FAT
  • BFS
  • RAMFS
  • RAM disque
• Réseau
• libroot
• Noyau
  • Gestion des ASIDs dans les TLB
• Chargeur de démarrage
• Système de build
• Documentation
  • Haiku Book
  • Documentation pour les développeurs
• C’est pour quand la bêta 6 ?
  • Février
  • Mars
  • Avril
• Google Summer of Code

Portage de Haiku pour les architectures ARM64 et RISC-V

C’est la grosse nouvelle de ce trimestre : la version ARM64 de Haiku parvient enfin à lancer le Tracker et permet donc d’avoir un environnement fonctionnel !

Ce travail repose bien entendu sur les efforts de nombreux contributeurs par le passé pour mettre en place cette nouvelle architecture. Ces derniers mois, le travail a été complété par smrobtzz avec des corrections pour pouvoir compiler Haiku depuis macOS, des pilotes pour le port série S5L utilisé par Apple, une correction de l’adresse de base du noyau, la remise à 0 du frame pointer lors du début d’exécution du noyau, des corrections dans la gestion de la mémoire physique, ainsi que quelques correctifs dans l’espace utilisateur. SED4906 a également participé avec des corrections dans la gestion des pages mémoire du bootloader, ainsi que dans les vérifications de taille de pages du runtime_loader.

smrobtzz ne s’est pas arrêté là, il a ensuite ajouté la possibilité d’utiliser plusieurs cœurs et threads de processeur (SMP) et corrigé des problèmes de compatibilité avec la version du firmware EFI EDK2 fournie par défaut avec QEMU, ainsi que, entre autres, des problèmes avec la fonction system_time.

Une fois le système de base stabilisé, le travail s’est poursuivi du côté de Haikuports où smrobtzz et waddlesplah ont travaillé ensemble pour corriger de nombreux problèmes, en particulier sur les recettes de compilation croisée et le processus de “bootstrapping” qui permet de générer le jeu de paquets initiaux permettant d’exécuter Haiku. Les téléchargements de “nightly builds” pour ARM64 fournissent donc maintenant un système utilisable sur les machines ARM64 au moins dans QEMU.

Un fil de discussion sur le forum de Haiku permet de suivre l’évolution de ces développements. La prochaine étape est la compilation de toutes les applications disponibles dans Haikuports, la correction des problèmes que cela va immanquablement dénicher, et la stabilisation du système. Ensuite, le travail pourra se poursuivre pour rendre cette version de Haiku utilisable hors de QEMU sur du matériel réel.

Du côté de RISC-V, le portage de Haiku est un peu plus avancé depuis quelques mois déjà, et fonctionne sur certaines machines sans virtualisation dans QEMU. Ce trimestre, on voit donc seulement une correction de TODO dans le code pour le thread-local storage concernant l’utilisation de variables atomiques (waddlesplash).

Applications

TextSearch

TextSearch est une application de recherche de texte dans le contenu de fichiers. C’est l’équivalent graphique de la commande grep.

Désactivation de vérifications de types de fichiers redondantes pour accélérer l’application (Philippe Houdoin).

HaikuDepot

HaikuDepot est à la fois un gestionnaire de paquets et un magasin d’applications.

apl continue d’améliorer l’application HaikuDepot.

• Modification du code de vérification des schémas JSON, en particulier pour préparer son intégration avec le code traitant les requêtes REST et pouvoir ainsi valider les requêtes et les réponses.
• Correction d’un problème d’affichage de l’onglet “Featured packages” (avec une correction dans BTabView).
• Refonte du code d’affichage des données dans la liste des paquets.

Software Updater

Software Updater est l’application permettant de télécharger et d’installer des mises à jour de paquets logiciels.

Correction d’un crash lorsque l’on quitte l’application pendant une mise à jour (Nathan242).

Ajout d’une option (activée par défaut) de nettoyage automatique des points de restauration anciens pour éviter de remplir le disque système avec des paquets obsolètes. La règle retenue est de conserver toujours au moins 10 points de restauration, et tous ceux qui sont plus récents que 30 jours (waddlesplash).

DeskCalc

DeskCalc est une calculatrice.

Nettoyage et améliorations du code de calcul en précision arbitraire (John Scipione).

Mail

Mail est le client email de Haiku. Il propose seulement l’affichage et la rédaction de mails : l’envoi et la réception sont traités par un service indépendant (mail_daemon), tandis que l’affichage de la boîte de réception est réalisé par des requêtes directement dans Tracker.

Humdinger s’est penché sur la gestion des mails avec plusieurs corrections et améliorations :

• L’attribut thread est correctement enregistré sur les messages envoyés, ce qui permet de facilement les regrouper avec les messages reçus dans la conversation correspondante.
• Quelques fichiers du code source n’étaient pas scannés par les outils de localisation, donc certains termes restaient invariablement en anglais.
• Implémentation de labels, permettant d’étiqueter les messages avec des chaînes de caractères arbitraires. Auparavant, l’attribut statut était détourné pour ça, mais cela pose des problèmes lors de la synchronisation avec les serveurs IMAP, pour lesquels le statut du message a une signification bien spécifique. Les labels sont pour l’instant entièrement locaux et ne sont pas synchronisés avec le serveur de messagerie. Cette fonctionnalité comprend également un nouvel add-on pour le Tracker, permettant de facilement étiqueter un fichier.

La couleur du texte pour le corps des messages se met à jour immédiatement lors d’un changement des préférences de couleur du système (John Scipione).

Tracker

Tracker est le gestionnaire de fichiers de Haiku.

John Scipione continue son travail sur le Tracker :

• L’aperçu des fichiers en cours de glissé-déplacé affiche maintenant les fichiers avec leur apparence « sélectionnée » (texte blanc sur fond noir), ce qui permet de garder le texte plus facilement lisible (bien que ce soit peut-être moins joli).
• L’icône de la corbeille s’affichait parfois pleine alors qu’elle est vide ou inversement, suite à des problèmes de synchronisation de cache et de collecte des informations de l’état de la corbeille de chaque disque monté.

John a également supprimé du code obsolète et corrigé de très nombreux problèmes, par exemple avec le tri des fichiers, la gestion des images de fond dans les fenêtres, le copier coller…

Nathan242 a quant à lui corrigé un plantage lorsqu’on annule le vidage de la corbeille ainsi que des problèmes de formatage de l’indicateur du nombre de fichiers sélectionnés.

Madmax a fait en sorte que les raccourcis claviers pour les add-ons se mettent à jour immédiatement (et pas lors de l’ouverture d’un menu pop-up) lorsque les add-ons sont modifiés.

Waddlesplash a également fait quelques corrections mineures, dont une mérite une mention : une optimisation pour réduire le nombre d’appels système pour le node monitring (réception de notifications lorsque des fichiers sont modifiés).

StyledEdit

StyledEdit est un éditeur de texte de type « bloc notes ». Il permet d’utiliser du texte formaté (polices, couleurs…)

Lors de la création d’un nouveau document texte, le nom « Sans titre 1 », « Sans titre 2 », etc. est généré avec le plus petit nombre non utilisé. Auparavant, les numéros s’incrémentaient même si certains fichiers avaient entretemps été renommés ou fermés (x512).

CharacterMap

CharacterMap permet d’explorer le jeu de caractères unicode et d’y piocher des caractères intéressants.

Correction d’un bug dans la recherche par nom de bloc unicode, amélioration de la disposition des caractères, et diverses autres petites améliorations (madmax).

DeskBar

DeskBar est la barre des tâches de Haiku, permettant de naviguer entre différentes fenêtres et applications.

Ajout dans la fenêtre des préférences d’un sélecteur de coin (similaire à celui déjà utilisé pour les coins actifs dans les préférences des écrans de veille). Ceci permet d’améliorer la découvrabilité de la possibilité de déplacer la DeskBar à différents endroits sur l’écran, et est plus facile à utiliser que le “grip” de déplacement de la DeskBar elle-même, qui est tout petit (PulkoMandy, basé sur un ancien patch de mmu_man).

Terminal

Ajout d’une initialisation manquante pour la couleur du curseur, en particulier lorsque le Terminal est utilisé comme réplicant dans une autre application (JackBurton79, suite à l’utilisation du Terminal dans l’IDE Genio).

Utilisation de _exit au lieu de exit dans les processus fils lancés par fork() sans exec(). L’utilisation de exit appelle les destructeurs globaux dont la destruction de certaines ressources partagées avec le processus parent. C’est une difficulté du mélange des API graphiques de BeOS avec un modèle POSIX complet (waddlesplash). Le même problème a été également corrigé dans l’application Expander.

LaunchBox

LaunchBox est un « dock » permettant de stocker des raccourcis vers des applications fréquemment utilisées.

Simplification du mécanisme d’enregistrement des paramètres. Auparavant, l’enregistrement était fait après un délai d’inactivité, pour éviter d’enchaîner plusieurs écritures sur disque à chaque modification de réglages. Il semble plus simple d’enregistrer les modifications tout de suite, et de laisser le cache disque faire son travail pour décider d’écrire ces changements sur disque tout de suite ou un peu plus tard (nephele).

MediaPlayer

Optimisation du code de lecture des fichiers de playlist pour lire le contenu des fichiers ligne par ligne, et pas caractère par caractère (mohammedrattia, dans le cadre de sa candidature au Google Summer of Code).

ActivityMonitor

ActivityMonitor affiche des graphes avec différentes statistiques d’utilisation de la machine.

Correction d’un bug lors de l’affichage des températures du système dans les cas où le pilote ne fournit pas de nom pour la température mesurée (OscarL).

WebPositive

WebPositive est le navigateur web de Haiku. Il utilise le moteur WebKit qui est un projet libre co-développé principalement par Apple (Safari), Sony (PlayStation), et Igalia (versions GTK et WPE).

Pour les téléchargements dont la taille est inconnue, affichage d’un « barber pole » au lieu d’une barre de progression bloquée à 100 % (YashSuthar983 dans le cadre d’une candidature au Google Summer of Code).

Lorsque WebPositive est quitté en fermant le dernier onglet ouvert, il ne restaure pas ce même onglet lors du prochain démarrage (nipos).

Suppression de code obsolète dans la barre d’onglets (nipos).

Devices

Devices affiche une liste du matériel présent sur la machine.

Les premiers patchs développés par Aquamatic dans le cadre de sa candidature au Google Summer of Code ont été intégrés ce trimestre :

• Les périphériques peuvent être triés par bus (PCI, USB…) en complément des autres options déjà disponibles.
• Nettoyage du code pour prendre en compte certains « TODO » listés dans le code de l’application.
• Investigation et correction d’une fuite de mémoire.

Préférences de localisation

Modification de la localisation dans plusieurs applications pour s’assurer que le comportement de l’option « traduire les noms des applications » est respecté partout lorsque le nom de l’application est mentionné dans un autre texte (humdinger).

Préférences d’apparence

Retrait d’espacements inutiles et disgracieux dans la fenêtre (humdinger).

Outils en ligne de commande

Remplacement des fonctions fork et exec dans time_stats pour utiliser posix_spawn (waddlesplash). L’utilisation de fork et exec pour lancer des processus enfants est la méthode traditionnelle, la première mise en place dans UNIX. Elle pose des soucis de performance et cause des comportements problématiques. En particulier, de nombreuses ressources du processus parent sont conservées (descripteurs de fichiers ouverts, sémaphores…) alors qu’ils ne sont pas toujours nécessaires. La fonction posix_spawn permet un meilleur contrôle de ces comportements, tout en étant beaucoup plus rapide et plus simple à implémenter. Le sujet a conduit à plusieurs modifications dans d’autres parties du code, dont on reparle plus loin dans la dépêche.

pkgman propose maintenant une sous-commande cleanup pour le nettoyage des points de restauration. Contrairement à SoftwareUpdater, ce nettoyage n’est pas automatique, car cela rendrait l’utilisation de pkgman potentiellement trop destructrice. Cependant, un message s’affiche après l’installation de mises à jour indiquant le nombre de points de restauration qui peuvent être nettoyés (waddlesplash).

Amélioration de la commande ltrace, mais celle-ci est toujours un travail en cours et pas encore utilisable (waddlesplash).

Kits

Les APIs de programmation de BeOS et de Haiku sont implémentées en C++. Elles sont organisées en “kits” regroupant des fonctionnalités liées.

Application Kit

L'application kit comporte toutes les fonctions d’échange de messages entre applications et au sein d’une application.

Meilleure gestion d’un cas d’erreur dans BInvoker pour remonter l’erreur à la fonction appelante (korli).

Support Kit

Le support kit contient toutes sortes de fonctions utilitaires basiques : gestion des chaînes de caractères, parser JSON…

Ajout de tests unitaires pour la classe BStopWatch (priyanshu-gupta07).

La famille de fonctions string_for_size change d’unité lorsque la valeur atteint 1000 et pas 1024. Par exemple on affichera “0.9 Gio” plutôt que “1,000 Mio” (korli). Elles pré-initialisent certaines données au démarrage de l’application plutôt que de les recalculer à chaque appel, ce qui rend l’utilisation de ces fonctions beaucoup plus rapide (waddlesplash).

Les fonctions de géolocatisation BGeolocation utilisent maintenant les services de Beacon DB, suite à la fermeture de Mozilla Location Services (PulkoMandy).

Suppression des objets BLocker alloués statiquement à plusieurs endroits. Ils sont problématiques lors d’un fork : par défaut, les objets BLocker dans les deux processus résultants pointent vers le même verrou système, mais si l’un des deux processus s’arrête, il détruit le verrou et laisse l’autre dans un état incohérent. Dans ce cadre, ajout également de vérifications pour empêcher le processus fils de continuer à utiliser l’interface utilisateur ou même d’appeler la fonction exit() (waddlesplash).

Refonte des classes BBlockCache, BTokenSpace et BLooperList utilisées pour gérer des ressources diverses, en particulier dans BMessage : utilisation de locks moins lourds, suppression de sémaphores qui n’était pas nécessaires, optimisation des performances (waddlesplash).

Modernisation des tests unitaires du support kit, pour rendre plus facile l’ajout de tests supplémentaires (KapiX).

Optimisation des méthodes de recherches de BString (pour trouver un caractère, une sous-chaîne…) en utilisant les fonctions C prévues à cet effet dans la libc plutôt que des boucles écrites à la main (waddlesplash, avec des corrections de madmax).

Interface Kit

L'interface kit contient toutes les classes nécessaires à la réalisation d’interfaces graphiques.

Correction de l’utilisation de la touche “Suppr” dans une zone d’édition de texte lorsqu’il y a également un raccourci clavier de menu (même désactivé) associé à cette même touche (nathan242).

Optimisation des méthodes BView::FillStroke et FillPolygon dans leur variante recevant directement un tableau de points pour éviter de recopier ce tableau dans un objet temporaire (x512).

Correction d’incompatibilités avec BeOS dans le format d’enregistrement de BPicture (x512) :

• pour l’enregistrement d’images bitmap,
• le “cisaillement” (shear) des polices de caractères,
• les sous-pictures,
• les transformations affines,
• les “échappements” (espacement des caractères) de texte,
• et d’autres petits problèmes.

Ce format permet de stocker une suite d’instructions de dessin pour afficher quelque chose à l’écran. Il est parfois utilisé par certaines applications pour stocker des ressources dans un format vectoriel compact, c’est pourquoi le respect du format défini par BeOS est important.

Ajout d’une taille minimale pour les barres de défilement, pour qu’elles gardent une taille raisonable même si l’utilisateur choisit une taille de police de texte en dessous de 12pt. La taille de toute l’interface s’adapte automatiquement à ce choix, mais pas de façon linéaire (nipos).

Suppression d’une valeur présente en double dans le message « mouse idle » envoyé aux applications lorque la souris cesse de se déplacer (x512).

Correction du code de dessin des cases à cocher pour restaurer l’état initial de la vue dans laquelle le dessin est fait. Ce problème était visible en particulier dans WebPositive lors de l’affichage de cases au sein d’une page web (nephele).

Correction de la façon dont BButton initialise ses couleurs, pour correspondre au comportement de BeOS et corriger des problèmes avec les applications utilisant liblayout, en particulier Wonderbrush (PulkoMandy).

Deux modifications sur la gestion des raccourcis clavier :

• Vérification des changements de raccourcis seulement lorsque c’est vraiment nécessaire. Cela est particulièrement visible dans Tracker où la plupart des raccourcis sont dynamiques (par exemple, actifs seulement si un fichier est sélectionné) (jscipione)
• Remplacement du tableau simple utilisé pour stocker les raccourcis par un arbre binaire de recherche, permettant de trouver rapidement si une combinaison de touches est associée à un raccourci clavier (waddlesplash).

Storage Kit

Le storage kit permet l’accès aux systèmes de fichiers.

Ajout de la nouvelle macro _DEPRECATED pour signaler au compilateur de déclencher un avertissement si certaines fonctions sont utilisées (via l’option -Wdeprecated). Les premières méthodes à recevoir ce traitement sont dans BMimeType et BResources (waddlesplash).

Grosse optimisation du « renifleur MIME » qui analyse le contenu des fichiers pour déterminer leur type MIME. L’utilisation de fonctions POSIX optimisées (memmem entre autres) et d’autres améliorations rendent l’étape « mimeset'ing package contents » de la compilation de Haiku ou de paquets HaikuPorts au moins 10 fois plus rapide (waddlesplash).

Network Kit

Le network kit permet la programmation d’application communiquant en réseau.

Correction d’un bug dans BSecureSocket qui ne validait plus les certificats SSL suite à une erreur lors d’une modification précédente (Horizons).

Media Kit

Le media kit se charge des médias audio et vidéo.

Réparation de l’add-on média « mixeur vidéo » qui est maintenant disponible dans l’image de base. Il est surtout utile comme démonstration des possibilités du media kit (x512).

Serveurs

Les serveurs sont des applications lancées en tâche de fond et qui rendent différents services. Ils sont similaires aux “daemons” de UNIX.

app_server

app_server est le serveur graphique de Haiku.

Correction d’un crash lors de l’utilisation d’un dégradé de couleurs ne comportant aucune couleur (KapiX).

La taille indiquée aux accelerants pour les curseurs matériels n’était pas la bonne (Goldfish64).

Intégration de commits de versions plus récentes de AGG pour corriger des typos dans quelques fonctions (Coldfirex).

Correction de fautes de frappe détectées par codespell, un outil de vérification orthographique pour le code (korli). Ces modifications font suite à une mise à jour des règles de codage de Haiku pour spéficier que c’est l’orthographe américaine qui est préférée lorsqu’il y a des divergences avec l’anglais européen.

Ajout d’un nouveau mode de fonctionnement pour les accélerants où le framebuffer n’est accessible que par l’espace utilisateur. Pour l’instant, seuls les pilotes VESA et framebuffer sont concernés, mais les autres pilotes devraient être modifiés de la même façon, car il n’y a pas de raison pour le noyau d’accéder directement au framebuffer à part dans le cas d’un kernel panic, ce qui se fait de toutes façons par une autre méthode (waddlesplash).

launch_daemon

launch_daemon est l’application “init” qui se charge du démarrage des autres services et des sessions utilisateurs. Il joue un rôle proche de celui de systemd pour Linux ou de launchd pour Mac OS.

Retrait des utilisations de fork+exec dans net_server et launch_daemon au profit de posix_spawn. Amélioration du code qui interprète les variables d’environnement (waddlesplash).

Bluetooth

Le serveur bluetooth centralise toutes les opérations concernant les périphériques Bluetooth.

Les premiers patchs des candidats au Google Summer of Code font que les choses bougent à nouveau du côté du serveur Bluetooth !

Vighnesh Sawant a corrigé le traitement du message “inquiry result” lorsqu’un appareil fournit plusieurs réponses d’un coup (ce qui est possible d’après la spécification du Bluetooth). Il a également implémenté le traitement de nouveaux types de réponses contenues dans ce message, terminé le code nécessaire pour la procédure d’appairage basique, corrigé l’apparition de périphériques bluetooth en double, et encore d’autres problèmes. Il a aussi déplacé tout le code concernant l’appairage basique dans un fichier source séparé.

Mohammed Rattia a quant à lui nettoyé les fonctions de recherche du périphérique Bluetooth local, et réparé la compilation des tests unitaires liés au Bluetooth.

Enfin, shivamsinghydv a ajouté une validation de l’adresse MAC des périphériques lors de leur activation par le serveur Bluetooth et corrigé un crash.

Mail

Le serveur de mail se charge de l’envoi et de la réception de courrier électronique (POP, IMAP et SMTP). Les messages sont mis à disposition du reste du système sous forme de fichiers avec des attributs étendus.

Philippe Houdoin a fait quelques changements sur le client IMAP :

Vérification des informations CAPABILITY retournées directement en réponse à une commande IMAP LOGIN. Les capacités étaient récupérées séparément, mais dans certains cas le serveur envoie cette liste dès le début de la connection, afin de pouvoir informer de capacités qui influent le processus de login, par exemple.

Modifications de la réponse à la commande ID pour identifier clairement le client mail de Haiku lorsque le serveur demande qui on est.

Media

Le serveur média permet l’interfaçage avec la carte son, et les entrées et sorties vidéo s’il y en a.

Le mélangeur de sons n’est démarré que lorsqu’une application a besoin de jouer du son pour la première fois. Cela économise du CPU et de la batterie (puisque la sortie de la carte son peut être laissée en veille jusqu’à ce moment. Pour l’instant il n’y a pas encore d’arrêt du mixeur et de mise en veille de la carte son lorsque la lecture de son est finie, cela pourra être ajouté plus tard. Cela corrige également certains problèmes conduisant à l’erreur « performance time too large ! » suite à une vérification ajoutée il y a environ deux ans pour détecter des utilisations incorrectes du media kit (waddlesplash).

Pilotes matériels

Stockage

Le pilote virtio_block a été temporairement désactivé en préparation de la publication de la version beta 6 de Haiku. En effet, il semble causer des problèmes de corruption disque dans certains cas, sans que les développeurs de Haiku aient pu identifier pour l’instant la source du problème. Si vous utilisiez virtio_block, vous pouvez le remplacer par virtio_scsi qui fournit des fonctionnalités équivalentes mais avec un protocole de communication avec la machine hôte différent. Il faut donc par exemple modifier la ligne de commande de démarrage de QEMU (waddlesplash).

Ajout de paramètres manquants dans les APIs permettant de détecter les fonctionnalités disponibles pour les disques NVMe (feature management) (korli).

Amélioration de l’initialisation des périphériques connectés à un contrôleur SDHCI : désactivation des cartes dont la tension d’alimentation n’est pas compatible, et mise en place des premières étapes pour la communication avec les périphériques eMMC (Mahmoussam, dans le cadre d’une candidature au GSoC qui n’a pas pu être acceptée).

Réseau

Synchronisation des pilotes réseau avec la dernière version d’OpenBSD (waddlesplash).

Correction d’un bug dans le pilote USB ethernet qui causait un plantage de certains adaptateurs USB lors de la lecture de l’adresse MAC (smrobtzz).

Ajout de l’USB dans la couche de compatibilité avec FreeBSD, ce qui a permis de remplacer le pilote ASIX-USB développé spécifiquement pour Haiku par celui de FreeBSD, qui permet d’utiliser une plus large gamme d’adaptateurs utilisant un chipset ASIX (waddlesplash et smrobtzz).

Import du pilote zyd de FreeBSD sous le nom zydzifi1211 avec l’ajout des fonctions nécessaires dans la couche de compatibilité. Ce pilote est à la recherche de testeurs pour confirmer son bon fonctionnement (waddlesplash).

Affichage

Ajout des identifiants PCI pour une nouvelle génération de contrôleurs GART Intel, permettant de gérer le partage de la mémoire entre le CPU et le GPU (OscarL).

USB

Désactivation d’une optimisation « zéro copie » dans le pilote EHCI (USB 2). Cette optimisation semble déclencher des plantages ou des corruptions sur certaines machines (waddlesplash).

Virtualisation

Intégration d’une série de pilotes pour le virtualiseur Hyper-V : souris, heartbeat pour confirmer que le système virtualisé est toujours vivant, synchronisation de l’heure, pilote SCSI, et diverses couches basses nécessaires à tous ces pilotes (Goldfish64).

Gestion d’énergie

Correction de messages de debug dans le pilote AMD P-States. Correction de la compilation du pilote audio HDA lorsqu’il est compilé sans les logs de debug. Ce pilote émet de très nombreux logs au démarrage pour identifier la carte son et toutes ses capacités, il est donc parfois utile de désactiver ces logs pour travailler sur autre chose (OscarL).

Systèmes de fichiers

Les systèmes de fichiers semblent être une cible appréciée des contributeurs au Google Summer of Code : le périmètre est bien maîtrisé, et le gros du travail se situe au niveau des structures de données, qui sont enseignées dans la plupart des cursus scolaires en informatique.

Ceci explique une activité inhabituellement élevée dans ce domaine lors de la période de candidature. Cependant, les tâches les plus abordables ont déjà toutes été traitées, et aucun des dossiers de candidature reçus cette année dans ce domaine n’a été jugé de qualité suffisante pour embaucher un nouveau contributeur.

Packagefs

Packagefs est un système de fichier virtuel permettant d’accéder aux contenus des paquets installés sur le système. Cette approche permet d’utiliser les paquets logiciels sans avoir besoin de les extraire, et accélère considérablement l’installation et la désinstallation de logiciels.

Amélioration de la gestion du manque de mémoire RAM, pour favoriser un ralentissement du système plutôt que de déclencher des erreurs de lecture (waddlesplash).

NTFS

NTFS est le système de fichier utilisé par Windows.

Correction d’un crash lors de certaines erreurs de montage de partitions (waddlesplash).

BTRFS

BTRFS est un des systèmes de fichiers utilisés par Linux. Il offre de nombreuses fonctionnalités avancées dont le pilote pour Haiku ne sait que faire. Seule la lecture de fichiers classiques est possible.

Lecture des fichiers compressés avec ZSTD (Abdullah Zulfiqar).

Corrections de warnings du compilateur et de bugs potentiels (grep-name).

Ajout de vérification de validité et traitement des collisions de hash dans les recherches de fichiers dans des dossiers ; vérification que la taille des partitions est suffisante avant de formatter un disque en btrfs ; amélioration de certains cas de gestion d’erreur ; nettoyage et amélioration de commentaires (Anuj Billore).

XFS

XFS est un système de fichiers initialement développé pour IRIX mais dont le développement continue dans Linux. Il est une alternative populaire à ext4 pour ce dernier.

Plusieurs corrections par sleipbyte :

• Correction d’une erreur de compilation
• Implémentation de rewind_dir, qui permet au Tracker d’afficher le contenu des dossiers,
• Correction d’erreurs SMAP (accès à la mémoire utilisateur par le noyau sans validation de pointeurs)
• Amélioration de la détection des partitions
• Reconnaissance de nouveaux drapeaux indiquant des fonctionnalités additionnelles dans XFS (le système de fichier continue d’évoluer dans son implémentation pour Linux)
• Traitement d’un cas particulier pour la gestion des attributs étendus : leur absence peut être indiquée par un pointeur NULL ou une taille à 0.

NFS v2

NFS est un système de fichiers permettant d’accéder à des fichiers stockés sur un autre ordinateur.

Amélioration des logs d’erreur lorsqu’un volume NFS ne peut pas être monté (kallisti5).

Il existe un deuxième pilote plus récent mais qui reconnaît uniquement NFS version 4, malheureusement, certains NAS n’implémentent que la version 3…

FAT

FAT est un ancien système de fichiers utilisé par Microsoft, pour DOS et les premières versions de Windows. Il reste populaire sur certains périphériques de stockage amovible et comme dénominateur commun entre beaucoup de systèmes.

Correction d’un plantage qui pouvait survenir lors du formatage d’une image disque au format FAT (nathan242).

BFS

BFS est le système de fichiers de BeOS et de Haiku. Il a la particularité d’avoir une gestion poussée des attributs étendus, et la possibilité d’effectuer des requêtes sur ces derniers à la manière d’une base de données.

Corrections et améliorations par Waddlesplash :

• Un plantage pouvait survenir lors de la vérification d’un système de fichiers corrompu,
• Une division par zéro dans le parseur de requêtes (utilisé aussi par packagefs et ramfs),
• Un break manquant qui pouvait déclencher un plantage du noyau (assertion ou même utilisation de mémoire libérée) lors de la suppression de plusieurs fichiers en parallèle,
• Ajout de notifications de renommage et déplacement pour les requêtes “live” en même temps que celles envoyées pour le « node monitoring », afin que les résultats de requêtes restent bien synchronisés avec l’état du disque.

RAMFS

RAMFS est un système de fichiers stockant les données directement en RAM. Il permet un accès très rapide aux fichiers, mais il est non persistant, les données sont perdues en cas de coupure ou de redémarrage du système.

Réorganisation du code par waddlesplash :

• Nettoyage du code pour tracer la taille des allocations,
• Consolidation de la logique do « node monitoring »,
• Correction des évènements « node monitor » sur les fichiers simples.

RAM disque

Le ramdisk n’est pas un système de fichiers, mais un périphérique de stockage de masse. Il peut être formaté avec n’importe quel système de fichiers.

Retrait de l’utilisation de l’ordonnanceur I/O et traitement direct des requêtes à la place. Cela contourne un bug de l’ordonnanceur dans le cas où la taille des secteurs du disque est plus large que les blocs du système de fichiers, ce qui force à écrire plusieurs blocs sur un secteur d’un seul coup. Ce problème ne se produit habituellement pas sur d’autres supports de stockage (la taille des secteurs étant habituellement de 512 octets dans les autres cas). L’ordonnanceur sera tout de même corrigé plus tard, pour permettre son utilisation dans d’autres cas où il est pertinent et dans ce cas de figure, comme les flash NAND accessibles sans contrôleur de haut niveau (nathan242).

Réseau

Correction d’une fuite de sockets dans la pile Bluetooth (Vighnesh Sawant).

Activation du code permettant de charger des modules pour le résolveur DNS nsswitch dans libnetwork. Cela permettra par exemple de charger le module mDNS (aussi connu sous le nom de Avahi pour Linux ou Bonjour pour Mac OS) pour la résolution des noms de machines sur le réseau local (Philippe Houdoin).

Vighnesh Sawant a également ajouté la possibilité d’utiliser l’option AI_V4MAPPED au résolveur DNS.

Ajout de la notification de l’erreur B_SELECT_DISCONNECTED (correspondant à l’erreur POSIX POLLHUP) dans les notifications sur les sockets, corrigeant ainsi un cas de test de compatibilité BSD (waddlesplash).

libroot

libroot est l’implémentation de la librairie C standard de POSIX. Elle regroupe les fonctions habituellement réparties entre les libc, libm et libpthread sur les systèmes UNIX classiques.

Remise en place de code spécifique par architecture dans printf qui avait été incorrectement enlevé. Cela corrige des plantages dans certains cas spécifiques (waddlesplash).

Ajout de la définition de GETENTROPY_MAX qui était manquante dans limits.h (korli).

Implémentation de la réservation d’espace d’adresse pour le tas du runtime_loader. Ceci évite la fragmentation de l’espace mémoire et améliore les performances, en particulier lorsque l'ASLR est désactivé (Amir Ramez, dont c’est la première contribution).

Réécriture de l’implémentation de pthread_barrier pour utiliser moins d’appels systèmes, corriger des problèmes de synchronisation, et au final éliminer un blocage qui survenait dans des applications utilisant OpenGL (waddlesplash).

Remplacement de l’implémentation de strchr et de strcpy par des versions plus optimisées venant de la bibliothèque musl (waddlesplash).

Correction d’un plantage lors de l’utilisation des allocateurs mémoire “debug” ou “guarded” dans libroot, qui était causé par des changements sur l’ordre d’initialisation des données de localisation (waddlesplash).

Correction d’incompatibilités dans l’implémentation de kqueue, en particulier, la fermeture d’un descripteur de fichier surveillé déclenchait une notification alors que ce n’est pas le cas dans les implémentations BSD (waddlesplash).

Renommage de PTHREAD_RECURSIVE_MUTEX_INITIALIZER pour ajouter le suffixe _NP. La constante porte ainsi le même nom que dans glibc par exemple, indiquant clairement qu’il s’agit d’une extension non-POSIX (waddlesplash).

Remise en place d’une prise en charge multi-plateforme pour le type long double de 128 bits. Le code de glibc pour cela avait été supprimé lors d’un précédent nettoyage car les plateformes x86 utilisent un format à 80 bits. Cela devrait corriger des plantages sur ARM64 et RISC-V lors de l’utilisation de ce type de valeurs (waddlesplash suite à l’investigation de smrobtzz). Bien que le problème eût déjà été signalé lors de la suppression du code concerné, à l’époque il n’y avait pas d’architecture fonctionnelle permettant de prouver la présence du problème.

Ajout d’un wrapper pour la fonction sigaction dans le « POSIX error mapper », qui permet de faire fonctionner des applications dépendant du fait que les valeurs de errno sont positives (contrainte apparue dans les versions récentes de POSIX, mais impossible à satisfaire tout en conservant la compatibilité avec BeOS) (korli).

Réparation de POSIX_SPAWN_SETSID, qui ne fonctionnait pas (waddlesplash).

Noyau

Le noyau de Haiku est un noyau monolithique assez classique. Il offre la possibilité de charger des modules, et une attention particulière est apportée à conserver le mieux possible l’API définie entre le noyau et les modules, rendant assez facile le développement de modules (tels que des pilotes de périphériques) indépendamment du noyau.

Gestion des hôtes Hyper-V : calibration TSC spécifique et pilote VMbus (Goldfish64 dont c’est la première contribution).

Amélioration du suivi des mutex de l’espace utilisateur dans le noyau, pour rendre les problèmes moins faciles à déclencher et plus faciles à rattraper (waddlesplash).

Korli a corrigé des problèmes détectés par les tests du langage Go :

• Lors de la création d’un fichier qui impose de traverser un lien symbolique vers un dossier qui n’existe pas encore,
• Dans la gestion des paquets réseaux, où une gestion de taille de tampon mémoire utilisait des valeurs incohérentes.

Retravail en profondeur des messages SMP (à la base de toute la mécanique de synchronisation de l’exécution du code entre différents threads et cœurs de CPU) : réduction des attentes actives en utilisant rw_spinlock au lieu de spinlock simples, envoi de messages à seulement certains cœurs plutôt qu’en broadcast, traitement des messages reçus par un cœur avant d’attendre la réception des messages envoyés aux autres, suppression d’opérations atomiques inutiles, etc. (waddlesplash). Ces changements ne semblent pas régler les gros problèmes de performance observés avec ce code lors de l’utilisation de Haiku dans VirtualBox, qui reste donc non recommandé pour utiliser Haiku.

Activation de l’utilisation de certaines fonctions “builtins” du compilateur dans le noyau. Le noyau est compilé avec l’option -freestanding pour indiquer au compilateur qu’il ne s’agit pas d’un environnement d’exécution standard, en espace utilisateur et avec une bibliothèque C. Cette option empêche le compilateur de supposer qu’une fonction nommée memcpy (par exemple) a un comportement spécifique et peut être remplacée par une implémentation accélérée. Cela limite les possibilités d’optimisation. Pour éviter ce problème, il faut appeler explicitement les fonctions built-in du compilateur qui implémentent ces opérations, ce qui se fait via des manipulations du préprocesseur C. Les noyaux Linux et FreeBSD ont déjà mis en place cette solution, et maintenant Haiku applique la même solution (waddlesplash).

Correction d’un problème d’initialisation de IO-APIC sur certains systèmes avec un bus PCIe (Goldfish64).

Optimisation de fonctions liées à la gestion de la swap (waddlesplash). Retravail de la gestion des allocations pour améliorer la stabilité et les performances lorsque la mémoire swap est utilisée (ce patch était en test depuis plusieurs mois afin de trouver un maximum de bugs avant de le fusionner, et de ne pas trop déstabiliser les nightly builds). Nettoyage du code vérifiant les permissions d’accès à la mémoire et la protection (en lecture ou en écriture).

Modification de l’initialisation des tas d’allocation mémoire du noyau pour permettre d’activer les modes “debug” ou “guarded” avec une option du menu de démarrage (sans devoir recompiler le noyau). Ainsi les utilisateurs peuvent facilement activer ces options pour aider à l’investigation de problèmes de corruption de mémoire qui ne se reproduisent que sur leur machine (waddlesplash).

Correction de problèmes de synchronization entre le cache de mémoire virtuelle et les opérations sur le système de fichiers, qui pouvait aboutir à un blocage complet du système. Ajout d’un test unitaire pour ce cas particulier (waddlesplash).

Réorganisation de la mémoire allouée pour le SMP (multiprocesseurs), pour éviter d’allouer un grand nombre de variables atomiques dans la même ligne de cache CPU (problème de "false sharing »). (waddlesplash)

Découpage des fichiers de code “VM” (gestion de la mémoire virtuelle) dans des fichiers de taille raisonable, par exemple pour le code d’initialisation et le « page writer ». Déplacement du code de notification de page occupée, suppression d’un champ inutile dans les page queues. Waddlesplash poursuit ce travail avec une refonte du page writer, qui n’est pas encore mergée pour l’instant.

Gestion des ASIDs dans les TLB

Ce sujet avait été discuté il y a quelques années dans le cadre d’un début de participation au Google Summer of Code qui n’avat pas abouti. Il est revenu à la surface suite à une série d’article « The Gerrit Code Review Iceberg », qui explore les patchs et changements abandonnés par leurs auteurs respectifs sur la plateforme de revue de code Gerrit (plus de 300 changements en attente). L’un des changements listés a attiré l’intérêt de SED4906 qui s’est penché sur les ASIDs. Le sujet est un peu technique et mérite quelques explications.

Pour gérer la mémoire virtuelle, on utilise une structure appelée TLB. C’est cette structure qui permet de faire correspondre une adresse en mémoire physique à une adresse en mémoire virtuelle, et également de gérer les permissions d’accès (lecture, écriture ou exécution) sur cette mémoire. Ces informations sont stockées en RAM et, pour gérer les vastes quantités de mémoire sur les machines modernes, peut comporter jusqu’à 5 niveaux d’indirection.

Si chaque accès mémoire devait traverser ces 5 niveaux pour trouver l’adresse physique à accéder, le système serait extrêmement ralenti. Le processeur inclut donc un cache spécifique dans lequel sont stockées les entrées TLB les plus récemment utilisées. Ainsi, la plupart des accès sont résolus très rapidement à l’aide de ce cache et l’impact de la mémoire virtuelle sur les performances est faible.

Cependant, ce cache crée un autre problème : lors d’un changement de contexte (exécution d’un autre processus par le processeur par exemple), il faut prendre garde à vider ce cache. Sans quoi, le nouveau processus pourrait accidentellement accéder aux données de l’ancien, suite à la mise en cache des mauvaises données. La solution traditionnelle à ce problème est de vider ce cache à chaque changement de contexte, c’est-à-dire plusieurs centaines de fois par seconde. Un processus interrompu, même brièvement, va donc se retrouver lorsqu’il reprend son exécution avec un cache vide, et les premiers accès à la mémoire seront donc fortement ralentis.

Une solution plus récente est l’utilisation d'ASIDs dans la table des pages. Cela signifie que, dans le cache TLB, chaque entrée va stocker non seulement l’adresse physique et les permissions, mais aussi un identifiant du processus auquel ces informations sont associées. Ainsi, lors d’un changement de contexte, il n’est plus nécessaire de vider le cache. Le nouveau processus disposant d’un ID différent, il ne va pas utiliser les entrées présentes pour un autre processus. Et si le processus initial reprend son exécution, il trouvera une partie du cache déjà préchargée avec ses informations.

Des identifiants spéciaux peuvent également être utilisés, par exemple pour l’espace mémoire du noyau. Cela permet de conserver dans le cache TLB toutes les entrées correspondant au noyau, qui sont utilisées lors des appels système peu importe le processus en cours d’exécution.

Le patch implémentant les ASIDs pour les processeurs x86 est encore en cours de développement. Mais la discussion autour de ces changements a déjà conduit à l’intégration de deux modifications plus simples:

• Lors de la synchronisation entre CPU : par exemple si plusieurs threads (partageant le même espace mémoire) s’exécutent sur des cœurs de processeur différents, il est nécessaire de synchroniser les caches TLB des cœurs de processeur correspondants. Pour ce faire, les processeurs s’envoient des messages s’informant mutuellement de la nécessité de vider le cache TLB. Ce message peut être reçu alors que le processus en cours d’exécution a déjà changé, et dans ce cas, il déclenchait inutilement une vidange du cache supplémentaire (waddlesplash).
• Il y avait d’autres problèmes dans l’implémentation spécifique aux processeurs x86. Les mesures de performances sur le patch avec activation des ASIDs (dans plusieurs versions) ont conduit à récupérer certains correctifs améliorant les performances sans nécessiter l’activation des ASIDs (SED4906 et waddlesplash).

Sur les processeurs x86, l’utilisation d’ASIDs est entièrement optionnelle. Ce n’est pas le cas sur d’autres architectures comme SPARC, où leur intégration dans le processeur est beaucoup plus profonde, avec par exemple des instructions permettant de travailler avec plusieurs espaces d’adressage simultanément.

Chargeur de démarrage

Correction d’un problème avec la fonction pour “bloquer” des fichiers (par exemple désactiver des pilotes de périphériques empêchant le démarrage) pour traiter correctement les noms de fichiers contenant des espaces (madmax).

Correction d’une fuite de mémoire dans le code affichant l’écran de démarrage. La mémoire était bien libérée lors du démarrage du noyau, mais seulement après avoir été tranférée du bootloader vers le noyau ce qui complique et rallonge inutilement la procédure de démarrage (waddlesplash). Augmentation de la taille de la zone de mémoire contenant les arguments du noyau, qui pouvait se remplir dans certains cas particuliers comme les images “bootstrap”.

Système de build

Forçage de la compatibilité C89 lorsqu’on compile GCC 2 avec les versions récentes de GCC. GCC 2 est toujours utilisé dans Haiku pour assurer la compatibilité avec BeOS. Il n’est pas possible de le compiler avec un compilateur s’attendant à trouver du code compatible avec les versions actuelles du langage C (korli, waddlesplash, kallisti5). La plateforme d’intégration continue a ensuite pu être mise à jour vers une version de Linux qui fournit GCC 14.

Activation de l’option de compilation -Werror pour un plus grand nombre de dossiers, en particulier netfs, et les pilotes graphiques radeon et s3 (fruitdelapassion). Cette option demande au compilateur de déclencher une erreur de compilation, plutôt qu’un simple avertissement, pour un certain nombre de problèmes. Ainsi, on s’assure que les développeurs ne passent pas à côté d’un problème qui aurait pu être détecté tout de suite. La prochaine étape sera d’inverser la logique pour cette option : l’activer par défaut pour tous les dossiers, et la désactiver explicitement lorsque c’est absolument nécessaire, par exemple pour du code importé d’autres projets pour lequel il est préférable de limiter les modifications.

KapiX a démarré un chantier d’amélioration du système de tests unitaires afin de rendre plus facile l’ajout de nouveaux tests, réduire la quantité de code à écrire pour faire fonctionner un test, et encourager les autres développeurs à écrire des tests :

• Correction de la compilation des tests existants (kernel, app_server, libroot…)
• Définition d’un nouveau type d’image “test” contenant les tests unitaires et un serveur SSH. Cette image peut être générée par la CI, puis démarrée dans une machine virtuelle pour lancer les tests
• Désactivation des tests qui ne fonctionnent pas au point de provoquer un plantage irrécupérable.

Ajout d’un fichier de prédéfinition des paramètres POP/IMAP pour l’hébergeur disroot.org (humdinger).

Correction de la compilation de libroot avec le compilateur clang (nephele).

Nettoyage des Jamfiles, où du code exécuté en espace utilisateur employait les en-têtes normalement réservés au noyau. Les fichiers qui étaient souvent utilisés dans les deux espaces ont été déplacés dans un dossier commun (waddlesplash).

Modification de la gestion de errno dans libroot_build (la couche de compatibilité qui implémente des fonctions spécifiques à Haiku sur un système hôte utilisé pour la compilation croisée). Dans certains cas, la valeur de errno n’était pas bonne, ce qui créait des problèmes de comportement dans mimeset et dans d’autres outils utilisés lors de la compilation (waddlesplash).

Ajout d’un harnais fs_shell pour le système de fichiers ExFAT. Cela permet de tester le code du système de fichiers hors de Haiku, dans une interface en ligne de commande permettant de réaliser des opérations simples (Halonix).

Ajout d’un message d’avertissement dans la sortie de ./configure si certaines bibliothèques nécessaires à la compilation de Haiku ne sont pas disponibles (nephele).

Correction de diverses mauvaises orthographes pour le mot “unknown” un peu partout dans le code (SED4906).

Suppression d’un fichier temporaire qui était accidentellement laissé en place lors de la génération d’une image “MMC” (contenant un chargeur de démarrage pour une platforme ARM). Certains utilisateurs ont confondu ce fichier avec l’image finale et ont eu du mal à démarrer Haiku à cause de ce problème (waddlesplash).

Documentation

La documentation de Haiku est séparée en 3 parties:

• Un guide de l’utilisateur, présentant les différentes applications, raccourcis clavier…
• Le « Haiku Book », une référence des API pour les développeurs d’applications,
• Une documentation “interne”, pour les développeurs qui travaillent sur le système d’exploitation lui-même.

La première est traduite dans plusieurs langues, tandis que les deux autres sont actuellement disponibles uniquement en anglais.

Haiku Book

Le Haiku Book est actuellement à utiliser en complément du Be Book, son équivalent rédigé pour BeOS. Haiku a obtenu l’autorisation de distribuer des copies du Be Book, mais avec une license n’autorisant pas les modifications. Cela veut dire que le Haiku Book doit être réécrit de zéro. Les efforts ont donc été mis en priorité sur les nouveautés de Haiku, et la documentation des parties reprises de BeOS arrive petit à petit.

Ajout de documentation pour B_QUERY_WATCH_ALL qui devient une API publique. Ce flag permet de générer une requête sur le système de fichier et de recevoir des notifications du node monitor lorsque les fichiers trouvés par la requête sont modifiés, même si la modification n’entraîne pas un ajout ou une suppression du fichier des résultats de la requête. C’est l’équivalent de B_WATCH_ALL qui existait déjà pour le node monitoring sur un dossier classique (waddlesplash).

Ajout de documentation pour des classes liées à l’utilisation du réseau : BCertificate, BProxySecureSocket, BSecureSocket et BSocket (cafeina).

Gros nettoyage et amélioration de la documentation de BEntry et BStatable. Ajout d’une remarque sur MenusBeginning dans la documentation de BWindow (John Scipione).

Documentation pour les développeurs

La documentation interne est un projet plus récent. Elle est construite à partir de documents, d’articles et de messages de mailing list écrits au cours du temps par les développeurs de Haiku, dans le but de mieux structurer ces connaissances et de décharger le site web principal du projet, qui avait initialement accueilli ce type de documents au début du projet. Aujourd’hui, il serait plus intéressant d’avoir un site web plus centré sur l’utilisation de Haiku que sur son développement, mais il ne faudrait cependant pas perdre ces informations, soit pour leur intérêt technique, soit pour leur intérêt historique et la vision qu’elles donnent sur les débuts du projet.

Clarification d’un paragraphe incompréhensible dans la documentation du device manager (OscarL).

Mise à jour de la documentation sur l’implémentation de la mémoire swap et suppression de vieux documents sur la VM (gestion de la mémoire virtuelle) qui ne correspondait plus du tout à l’implémentation actuelle (waddlesplash).

C’est pour quand la bêta 6 ?

Waddlesplash inclut ce paragraphe dans les rapports d’activités mensuels. Le mieux pour se rendre compte des avancées est de reprendre tel quel les commentaires des 3 derniers mois :

Février

On s’approche !

Un gros changement sur la gestion de la mémoire qui corrige une méchante régression est en attente de revue depuis plus d’un mois mais aucun développeur ne semble disponible pour le relire.

Du côté du Tracker, la plupart des régressions sont corrigées, mais il en reste encore quelques-unes.

En dehors de ces deux gros sujets, il n’y a plus que 5 ou 6 bugs et régressions qui doivent absolument être corrigées, mais certaines d’entre elles promettent d’être des sujets compliqués qui vont demander un peu de temps.

Mars

C’est pas pour tout de suite !

Il y a un problème de rafraîchissement de l’affichage dans WebPositive qui bloque le processus de release. Une bonne partie des autres problèmes sont corrigés.

Avril

Pas encore !

Le problème dans WebPositive (dans HaikuWebKit, en fait) a été corrigé, mais il y a maintenant un problème pour télécharger les sources de HaikuWebKit depuis son nouvel hébergement sur Codeberg depuis les machines de build de Haikuports (le fichier est assez gros et déclenche un timeout du côté de Codeberg).

Et de toutes façons, il reste encore quelques bugs du côté de Haiku lui-même à traiter aussi.

On peut également jeter un oeil sur l'outil de suivi des bugs pour voir où on en est. Au moment de la rédaction de ce rapport, il reste 25 tickets ouverts dans le jalon beta 6, dont 3 de priorité critique :

• Un problème de texte illisible lorsqu’on fait un glisser-déplacer d’un grand nombre de fichiers dans le Tracker,
• Le mode « économie d’énergie » du scheduler empêche le fonctionnement de certains claviers et trackpads,
• La fenêtre de sauvegarde de fichiers a des problèmes de mise en page, parfois les contrôles de la fenêtre sont superposés

Google Summer of Code

Haiku fait de nouveau partie des organisations sélectionnées cette année pour encadrer quelques participants au Google Summer of Code.

Une quarantaine de candidatures ont été reçues, dont une grande partie ont été assez rapidement éliminées : hors sujet, ne respectant pas le format demandé ou ne comprenant pas une contribution au code par exemple. Le projet Haiku s’en sort plutôt bien, là ou d’autres organisations plus reconnues ont reçues plusieurs centaines de propositions.

Finalement, étant donné le petit nombre de “mentors” disponibles pour encadrer les participants, seulement 3 participants ont été retenus cette année grâce à leur travail de très bonne qualité avec plusieurs patchs déjà intégrés avant même la fin de la période de candidature.

Aquamatic sera encadré par KapiX et Korli, et va améliorer l’application “Devices” (gestionnaire de périphériques), en particulier pour indiquer clairement les périphériques pour lesquels un pilote est disponible ou non.

Mohammed R. Attia et Vighnesh Sawant seront encadrés par Waddlesplash, Scottmc et PulkoMandy. Ils vont poursuivre l’implémentation du Bluetooth dans Haiku. Mohammed se concentre sur les périphériques HID (claviers et souris sans fil) tandis que Vighnesh se chargera du profil audio HFP et, si le projet avance bien, des autres profils audio de meilleure qualité.