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é.

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.

Il ne s’agit pas d’une distribution Linux, mais d’un système complet avec son propre noyau, sa propre pile graphique, etc. L’idée de cette approche est d’avoir une seule équipe travaillant sur toute la pile logicielle, pour éviter les soucis de coordination entre projets indépendant et d’excès de modularité, qui peuvent aboutir à une architecture logicielle inefficace. En revanche, cela demande un gros travail pour une équipe relativement réduite, et le système est donc en développement depuis bientôt un quart de siècle sans avoir encore publié une version majeure complète.

La cinquième version beta a été publiée en 2024. Les développements continuent pour stabiliser, optimiser et peaufiner le système, avec une version beta 6 prévue en début de cette année, qui sera probablement suivie par une beta 7 quelque temps plus tard.

Cette série de dépêches est basée sur les rapports d’activité publiés mensuellement par le projet Haiku. Cette édition couvre les modifications de Haiku numérotées entre hrev59111 et hrev59355 (soit 244 changements individuels), en plus d’activités se déroulant hors du dépôt Git principal.

Entre parenthèses est indiqué le pseudonyme de l’auteur ou autrice principal·e du changement. Des pseudonymes sont utilisés par habitude (venant des canaux IRC et/ou de la culture de la demoscene) et aussi pour préserver l’identité des personnes qui le souhaitent (certains participants utilisent également leur nom légal, d’autres pas).

Sommaire

• Mise à jour de Go en version 1.18
• Redémarrage automatique de app_server
• Applications
  • ActivityMonitor
  • Terminal
  • HaikuDepot
  • WebPositive
  • Expander
  • AboutSystem
  • LaunchBox
  • Tracker
  • MediaPlayer
  • Sudoku
  • DeskBar
  • People
  • Lecteur MIDI
  • MidiPlayer
  • ProcessController
  • Installer
  • Mail
  • DriveSetup
  • Debugger
  • Changements transverses
• Fenêtres de préférences
  • Réseau
  • Périphériques d’entrée
  • Apparence
• Outils en ligne de commande
• Kits
  • Interface
  • Storage
  • Device
  • Package
• Serveurs
  • Notifications
  • Network
  • app_server
• Pilotes de périphériques
• Systèmes de fichiers
• libroot & noyau
  • Réseau
  • Gestion des processus
  • Bibliothèque C standard
  • Gestion de la mémoire
  • Entrées-sorties
  • Chargeur de démarrage
  • Systèmes de fichiers
  • Outils de debug
• Build system
• Documentation
  • Haiku book
  • Documentation interne
• Autres nouvelles
  • Changement de tarification de Netlify
  • Remise sur les rails de HSA (Haiku Support Association)
  • Série d’articles « Gerrit code review iceberg »
  • Statistiques de contribution pour 2025
  • Mise à jour de haiku-format
  • À quand la beta 6?

Mise à jour de Go en version 1.18

Le mois de novembre a vu l’arrivée d’une grosse mise à jour de la chaîne d’outils pour le langage Go en version 1.18. Il s’agit d’une version de 2022, mais c’est un gros progrès puisque la version précédente disponible pour Haiku était la version 1.4 datant de 2014. De plus, cette version 1.18 est disponible dans le dépôt de paquets et peut être installée normalement avec pkgman (au moins pour les architectures x86 et x86_64).

La plus grande partie du travail a été réalisée par Korli, depuis plusieurs années, pour mettre en place l’environnement de compilation nécessaire, et aussi corriger de nombreux problèmes de compatibilité POSIX dans Haiku qui ont été mis en évidence par les tests de Go.

Cela permet par exemple d’utiliser Hugo, le générateur de site statique utilisé pour le site principal de Haiku. Waddlesplash a donc pu rédiger et vérifier le rapport d’activité de novembre en utilisant uniquement Haiku : avec Hugo, WebPositive (le navigateur natif de Haiku, basé sur WebKit), l’éditeur de texte Koder, ainsi que Iceweasel (un portage de Firefox) pour la correction d’orthographe.

Redémarrage automatique de app_server

app_server est le serveur graphique de Haiku. Il s’agit d’un composant critique, pour lequel un crash rend le système à peu près inutilisable. Waddlesplash a corrigé plusieurs problèmes dans le code pour permettre de redémarrer le serveur après un crash, et de le reconnecter avec les applications en cours d’exécution. Ce redémarrage nécessite encore quelques étapes manuelles car les crash démarrent actuellement le debugger automatiquement, mais cela peut être changé par une simple configuration.

Applications

ActivityMonitor

ActivityMonitor affiche sous forme graphique divers paramètres du système: charge CPU, consommation mémoire… Il peut s’exécuter dans une fenêtre ou bien être intégré au bureau sous forme d’un « réplicant ».

Affichage d’un message « pas de capteurs de température » à la place du graphe de température du système si l’information n’est pas disponible (OscarL).

Correction d’un problème de localisation, certains fichiers sources n’étaient pas pris en compte et les chaînes contenues dedans ne pouvaient pas être traduites (humdinger).

Terminal

Le Terminal permet d’exécuter des applications en ligne de commande.

Synchronisation du presse-papier interne du Terminal avec celui du système seulement une fois au démarrage de l’application, et pas lors du changement d’onglet comme cela avait été implémenté au trimestre précédent (OscarL).

Correction d’un problème qui masquait le signal SIGUSR1 pour les shells et autres processus lancés dans le terminal (korli).

Implémentation des séquences d’échappement permettant aux applications CLI de définir des liens hypertextes (en complément des liens qui étaient déjà détectés automatiquement par le terminal en fonction du contenu du texte) (korli).

HaikuDepot

HaikuDepot est l’interface graphique du gestionnaire de paquets. Il utilise un backend en ligne en Java pour stocker et récupérer les captures d’écrans, commentaires et notes d’utilisateurs, icônes des paquets, liste de paquets mis en avant, et d’autres informations.

L’application est plus robuste en cas de problème de réseau : gestion des erreurs et affichage de messages clairs pour l’utilisateur. Gestion en particulier des erreurs 503 remontées par l’API web utilisée par HaikuDepot (apl).

Ajout de filtres pour trouver facilement les applications « natives » (n’utilisant pas Qt ou GTK) et d’un filtre « desktop » pour trouver les applications graphiques (et filtrer un très grand nombre de paquets de bibliothèques, applications en ligne de commande…) (apl, avec des améliorations par humdinger pour clarifier la terminologie).

Amélioration de la taille de la fenêtre des conditions d’utilisation sur les écrans haute densité (nipos).

Refonte de la gestion des identifiants de messages internes à l’application HaikuDepot pour en simplifier la maintenance (apl).

Interdiction de la sélection multiple dans la liste des paquets (apl).

WebPositive

WebPositive est le navigateur web fourni avec Haiku. Il est basé sur le moteur WebKit, co-développé avec Apple, Sony, Igalia et d’autres participants.

Modification du message envoyé au Tracker pour ouvrir le dossier contenant un fichier (par exemple un téléchargement), pour utiliser le message officiellement prévu à cet effet plutôt qu’un moyen détourné (humdinger).

Meilleure gestion des noms de fichiers longs dans la fenêtre de téléchargements avec l’ajout d’une barre de défilement horizontal (mull, avec un petit correctif par humdinger pour corriger un décalage d’un pixel du positionnement de la barre de défilement).

Un chantier est en cours pour réintégrer à nouveau le portage de WebKit pour Haiku dans les sources upstream. Cela avait déjà été fait en 2010, mais n’avait pas été maintenu par la suite, ce qui a conduit à retirer ce code. Depuis, Haiku utilise un fork resynchronisé régulièrement, mais cela génère du travail en plus. L’envoi du code est aussi l’occasion de faire relire toutes les modifications par les autres développeurs de WebKit, avec des conseils pour améliorer et simplifier l’architecture.

Expander

Expander est une application permettant de décompresser des archives.

Correction d’un décalage d’un pixel de la barre de défilement (humdinger).

AboutSystem

AboutSystem affiche quelques informations sur le système et surtout la liste des auteurs de Haiku.

Simplification du code pour la mise à jour automatique des couleurs, mise en place de la mise à jour automatique des couleurs pour la liste des crédits (si on passe en mode sombre par exemple) (jscipione).

Ouverture de la fenêtre avec une taille respectant les proportions du nombre d’or, esthétiquement plus plaisant (axeld).

LaunchBox

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

Correction de la couleur du panneau de LaunchBox, et d’autres couleurs dans le sélectionneur de couleurs standard (nephele).

Tracker

Tracker est l’explorateur de fichiers. Le code du Tracker contient également les fenêtres « ouvrir » et « enregistrer sous », mises à disposition des autres applications sous forme de la bibliothèque libtracker.so.

Envoi de la notification d’activation de l’espace de travail à tous les réplicants, afin que ces derniers puissent ajuster leur couleur (par exemple) en fonction de l’espace de travail actif (jscipione).

Correction du positionnement du champ de texte lors du renommage de fichiers dans la vue par icônes, résolution de problèmes de gestion de l’état des fenêtres après un glisser-déposer avorté, affichage des volumes disque en premier (avant les dossiers) si l’option « trier les dossiers en premier » est active, synchronisation en direct des fenêtres de sélection de fichiers lors du changement d’options, et divers nettoyages de code (jscipione).

Ajout d’une bordure manquante dans les fenêtres de sélection de fichiers (nipos).

Ajout du nombre d’élément sélectionnés (en plus du nombre d’éléments total du dossier) dans les fenêtres du Tracker (nathan242).

Correction d’un problème de concurrence dans le constructeur des fenêtres de sélection de fichiers, dont la conséquence était une mauvaise disposition des contrôles dans la fenêtre (certains boutons apparaissant superposés par exemple (PulkoMandy).

Amélioration de l’image d’aperçu qui suit la souris lors d’un glisser-déplacer lorsqu’on déplace beaucoup de fichiers: l’image est tronquée pour ne pas être trop grande mais le dégradé de transparence sur les bords n’était pas bien calculé (PulkoMandy).

Déclenchement automatique du « renifleur » de type MIME, qui identifie automatiquement les fichiers pour les afficher avec la bonne icône par exemple. En particulier cela rend l’utilisation du Tracker plus confortable sur les systèmes de fichiers ne permettant pas de stocker le type MIME dans un attribut étendu (Jim906).

Correction d’une régression sur la mise à jour en direct des tailles et dates de modification de fichiers dans les résultats de requêtes (waddlesplash).

MediaPlayer

MediaPlayer est une application pour lire des fichiers média (son et vidéo).

Correction de la couleur du texte dans la fenêtre d’informations (nephele).

Dans cette même fenêtre, le champ indiquant le chemin du fichier en cours de lecture est maintenant cliquable (nathan242, dont c’est la première contribution).

Ajout d’une détection automatique du type MIME des fichiers, s’il n’est pas renseigné (par exemple s’il est stocké sur un système de fichiers où il n’y a pas d’attributs étendus) (DigitalBox98).

Sudoku

Sudoku est un jeu de Sudoku, très utile pour patienter pendant une compilation un peu longue.

Amélioration de la palette de couleurs en mode clair (le mode sombre nécessite encore du travail) (axeld).

DeskBar

DeskBar est la barre des tâches de BeOS et de Haiku. La même application contient également le code pour la fenêtre de changement de tâches « Twitcher ».

Correction d’un bug qui faisait apparaître des applications en double dans le « Twitcher » (la fenêtre de changement rapide d’application qui apparaît avec le raccourci Alt+Tab) (madmax).

People

People est un gestionnaire de contacts. Il stocke les contacts dans des fichiers « person » avec les informations sous forme d’attributs étendus.

Correction du défilement avec la molette de la souris ou au touchpad (nipos).

Lecteur MIDI

Le lecteur MIDI permet d’écouter des fichiers au format MIDI.

MidiPlayer

Le lecteur MIDI permet d’écouter des fichiers au format MIDI.

Changement de la couleur du contrôle de volume qui était codée en dur, non configurable et pas harmonisée avec le reste du système (nipos).

ProcessController

ProcessController affiche la charge CPU et l’occupation mémoire dans la DeskBar. Il permet également d’afficher des statistiques par application, et de débugger et stopper des applications via un menu popup.

Ajustements pour les écrans haute densité : taille des menus, largeur par défaut de l’icône réplicant, autorisation du redimensionnement de la fenêtre principale (la taille est conservée si on installe ensuite un réplicant sur le bureau, et divers autres changements (waddlesplash).

Installer

Installer permet de cloner l’installation de Haiku actuelle vers un autre disque.

Ajout d’un outil pour copier automatiquement le chargeur de démarrage sur la partition EFI du système, pour réduire le nombre d’étapes manuelles pour installer Haiku correctement sur un système EFI (PawanYr, avec des améliorations de kallisti5 pour nommer le fichier installé correctement en fonction de l’architecture CPU du système).

Amélioration du calcul de la taille de la fenêtre « EULA » de l’installeur (qui affiche non pas un contrat de license, mais un message de bienvenue et quelques instructions pour l’installation), en fonction de la taille de texte sélectionnée dans les préférences (nipos).

Mail

L'application Mail permet de lire et de rédiger des e-mail. Elle fonctionne en collaboration avec le mail_server qui s’occupe de l’envoi et de la réception des messages.

Correction d’une régression sur la couleur de fond des champs d’adresse. Mise en place des mises à jour de couleurs automatiques. Les champs désactivés ou en lecture seule sont maintenant « navigables » (avec la touche tab) et le texte peut être sélectionné et copié (jscipione).

Les boutons « suivant » et « précédent » peuvent être accompagnés de la touche Maj. (Shift), pour changer de message sans modifier le statut « lu » des messages (humdinger).

DriveSetup

DriveSetup permet de configurer les supports de stockage: formatage, partitionnement.

L’application s’affiche sur tous les espaces de travail si la DeskBar n’est pas lancée. Ce cas particulier est utile lors du lancement de l’installation de Haiku, dans ce cas, le bureau n’est pas lancé, mais il est tout de même possible d’utiliser plusieurs espaces de travail, ce qui peut donner l’impression que les fenêtres ont disparu si on se retrouve sur un espace vide (PulkoMandy).

Finalisation d’un patch datant d’il y a plusieurs années pour ajouter un menu permettant d’écrire ou de lire des images disques depuis ou vers des partitions (plus besoin d’utiliser dd en ligne de commande) (sed4096, avec l’aide d’humdinger pour des améliorations de localisation et de choix de vocabulaire).

Debugger

Debugger permet de débugger les logiciels fonctionnant dans Haiku.

Correction d’un crash lorsqu’on essaie de débugger des applications trop grosses, par exemples celle utilisant Mesa et llvmpipe pour faire du rendu 3D (waddlesplash).

Changements transverses

Modification de toutes les chaînes de caractères où le nom d’une application est présent (par exemple : « Deskbar preferences »). En effet, le nom des applications peut optionnellement être traduit, et toutes ces chaînes doivent donc s’adapter dans les deux cas (nom d’application traduit ou conservé en anglais selon les préférences de l’utilisateur). Auparavant ce réglage ne pouvait pas être appliqué de façon systématique (humdinger).

Fenêtres de préférences

Réseau

Affichage de l’état précis des interfaces réseau (en cours de configuration DHCP, par exemple) et pas seulement « hors ligne » ou « en ligne » (nipos).

Périphériques d’entrée

Ajout et amélioration de plusieurs options pour la gestion des touchpad (samuelrp84). Voir plus bas les informations sur la réécriture du pilote Elantech qui donne plus de détails.

Apparence

Envoi d’un seul message de mise à jour aux applications lorsque plusieurs couleurs changent simultanément, ce qui est plus efficace et réduit les « clignotements » d’applications dans certains cas (nephele).

Correction de la hauteur des fausses barres de défilement visibles dans la fenêtre d’apparence pour configurer les barres de défilement (jscipione).

Outils en ligne de commande

Le réplicant NetworkStatus peut être installé dans la DeskBar via la ligne de commande même lorsque une fenêtre de NetworkStatus est déjà ouverte (nipos).

Ajout dans strace de l’affichage des structures stat, sockopt, sigset_t, sigprocmask et des noms de signaux (korli avec un correctif par nathan242).

Correction de plusieurs problèmes dans l’interface en ligne de commande du Debugger, qui conduisaient entre autres à un gel de l’application. Cette interface est surtout utilisée en cas de crash d’un service critique (app_server, registrar, input_server) qui empêcherait l’utilisation de l’interface graphique. Les investigations sur ces services en cas de crash sont donc facilitées.

Modification de bfs_tools pour rendre ces outils compilables sur le système hôte utilisé pour compiler Haiku (axeld). Ces outils permettent de manipuler à la main un système de fichiers bfs, de récupérer certaines données sur un disque corrompu, et diverses manipulations de bas niveau.

Modification de l’outil makebootable pour vérifier que la partition à rendre bootable est bien une partition BFS. Utiliser l’outil sur une partition d’un autre format ou sur un disque complet pourrait corrompre le système de fichier et rendre les données inaccessibles. Ajout d’un message indiquant lorsque le lancement de makebootable n’est pas nécessaire, car les utilisateurs continuent de recommander de lancer cet outil sans aucune raison pour corriger des problèmes de démarrage (encourageant ainsi les nouveaux utilisateurs à faire dea mauvaises manipulations et à corrompre leur système de fichiers) (PulkoMandy).

Suppression d’une verrue dans checkfs qui n’est plus nécessaire suite à des améliorations du Storage Kit. Cela permet de lancer checkfs pour vérifier une partition en donnant le chemin de n’importe quel fichier contenu dans la partition (waddlesplash).

Activation du support de l’IPv6 dans telnet, implémentation dans netstat (avec des corrections sur les opérateurs de filtrage), et ajout de traceroute6 compilé à partir des sources fournies par NetBSD (cmeerw).

Amélioration de l’affichage de df avec plus d’informations, un listage sur deux lignes, et l’ajout d’une option pour afficher les informations standardisées dans le format imposé par POSIX (nipos et PulkoMandy).

Kits

Interface

L'interface kit se charge de tout l’affichage de fenêtres à l’écran et des contrôles de base (boutons, cases à cocher…)

Correction d’un bug dans le contrôle calendrier lors du déplacement vers les mois suivant ou précédent (nipos).

Correction d’un problème de navigation au clavier dans une ListView après l’insertion de nouveaux objets (nipos).

BControl (la classe parente de tous les contrôles d’interface graphique) ne change plus ses couleurs dans la fonction AttachedToWindow(). Ce n’est plus nécessaire après d’autres changements dans BButton, et cela simplifie le code nécessaire pour personnaliser la couleur d’un contrôle spécifique (pour avoir, par exemple, un bouton rouge) (jscipione).

Améliorations sur BSlider: correction de la couleur du texte, nettoyage du code de dessin des sliders dans les implémentations de ControlLook (jscipione).

Augmentation de la taille des marques sur les boutons des barres de défilement (marques qui ne sont pas activées à moins de modifier manuellement un fichier de configuration) pour les rendre plus visibles sur les hautes résolutions (jscipione).

Les infobulles utilisent un espacement calculé en fonction de la taille du texte, pour une apparence plus jolie sur les écrans à haute densité (waddlesplash).

Séparation du titre des onglets et du nom des vues qui leurs sont attachées. Le comportement original est hérité de BeOS, il est donc préservé pour les anciennes applications. Mais pour les nouvelles applications, le nom interne des vues ne doit pas être traduit (il peut être utilisé par des scripts ou par le code de l’application), tandis que le titre affiché à l’utilisateur doit l’être. C’était le seul endroit où ce principe de séparation du nom et du texte affiché n’était pas respecté (KapiX et PulkoMandy).

Dans BTextView, la fonction « tout sélectionner » déplace le curseur à la fin de la sélection (et à la fin du texte). C’est le comportement de la plupart des autres systèmes, et préserver la position du curseur dans ce cas ne semble pas particulièrement utile (OscarL).

Correction de problèmes de choix de couleurs dans le code qui dessine des sliders avec un curseur triangulaire (nipos). Cette correction a permis d’utiliser ce type de slider dans les fenêtres de réglages de différents traducteurs d’images.

Amélioration de l’apparence des cases à cocher partiellement cochées. Elles s’affichent avec un signe "-" au lieu d’une croix. Auparavant, la couleur était subtilement modifiée mais ce n’était pas très visible (PulkoMandy).

Implémentation de la lecture d’un son dans BAlert, qui peut être activé dans les préférences de son (sed4096).

Storage

Le storage kit permet de contrôler les disques et supports de stockage (liste des partitions, montage et démontage, accès aux fichiers, chemins d’accès, requêtes…)

BPartition retourne une erreur B_BUSY si on essaie de monter une partition qui est déjà montée à un autre endroit, au lieu de la monter une deuxième fois (jscipione).

Device

Le device kit permet l’interaction directe avec certains périphériques (USB, série, joysticks…) directement depuis l’espace utilisateur.

Correction de problèmes de gestion de la mémoire dans BUSBInterface mis en évidence par AtomoZero lors d’expérimentations pour corriger le pilote de webcam à l’aide d’un LLM (waddlesplash).

Package

Le package kit se charge de la résolution des dépendances entre paquets et du téléchargement des paquets à installer. Il fonctionne en collaboration avec le système de fichier packagefs qui permet d’accéder au contenu des paquets une fois installés.

Retravail de BRepositoryCache pour remonter les informations sur les paquets via un callback plutôt que de remplir une structure BPackageInfoSet. Cela économise beaucoup de mémoire et d’allocations mémoire, et rend donc la lecture des dépôts de paquets plus rapide (waddlesplash).

Serveurs

Notifications

Le serveur de notifications permet d’afficher des notifications pour les évènements importants.

Les notifications déjà affichées changent de position immédiatement lorsque la configuration est modifiée pour les déplacer (nipos).

Ajout de la lecture de l’effet sonore choisi dans les préférences de son lors de l’apparition des différents types de notification, et à chaque pourcent de progression pour les notifications contenant une barre de progression (sed4096).

Choix de couleurs plus visibles en mode sombre pour les icônes de fermeture et de repli des notifications en mode sombre (nipos).

Network

Le serveur de réseau se charge de la configuration des interfaces réseau, de la configuration des routes et d’autres aspects liés à la communication en réseau.

Refonte du client DHCP dans net_server pour l’exécuter dans un thread séparé et ne pas bloquer la boucle de messages principale. Cela corrige plusieurs cas de gel du serveur lui-même et d’application qui communiquent avec de façon synchrone, par exemple les préférences de réseau. Cela permet également de plus facilement arrêter les requêtes DHCP lorsqu’une interface est reconfigurée avec une adresse statique (waddlesplash).

app_server

app_server est le serveur graphique gérant l’affichage à l’écran.

Correction de crashs causés par des verrous de concurrence manquants et des opérations effectuées dans le mauvais ordre (waddlesplash).

Retrait d’identifiants de messages qui n’étaient plus utilisés dans le protocole de communication entre les applications et le serveur graphique (X512).

Ajout du code nécessaire pour le tracé de lignes avec un dégradé de couleur (dans app_server et dans BView). Auparavant, les dégradés étaient utilisables uniquement pour le remplissage des formes et pas pour les contours (x512).

Modifications de BPicturePlayer pour utiliser une classe C++ avec de l’héritage plutôt qu’une structure C contenant des pointeurs de fonctions. Cela permet de vérifier que l’interface est implémentée correctement par les différents utilisateurs de cette classe dès la compilation (X512).

Implémentation de méthodes manquantes dans BoundingBox player, une implémentation de BPicturePlayer qui calcule un rectangle assez grand pour contenir tout le dessin réalisé par un objet BPicture rejoué via BPicturePlayer (KapiX).

Retrait d’une optimisation incorrecte dans le traitement des calques avec une opacité globale de 100% dans app_server. Ces calques peuvent tout de même contenir des pixels avec de la transparence, et doivent donc être applatis en tenant compte du canal alpha comme tous les autres calques (KapiX).

Modification du protocole app_server pour l’opération permettant de récupérer les « bounding boxes » pour chaque caractère d’une chaîne. L’interface précédente utilisait un tableau de structures, la nouvelle API est inversée ce qui permet d’envoyer plus efficacement 2 tableaux de types primitifs (X512).

Pilotes de périphériques

Implémentation correcte des timeouts sur les commandes dans le pilote SDHCI, ce qui corrige la compatibilité avec plusieurs lecteurs de cartes SD (PulkoMandy).

Réécriture complète du pilote pour les touchpads Elantech. Cette série de changements retouche tout d’abord la gestion des touchpads en général, avec des améliorations sur la documentation, sur le traitement des données invalides, la configuration par défaut, et un nettoyage du code.

Ensuite, le code pour la reconnaissance de « gestures » a été amélioré pour mieux reconnaître plusieurs mouvements tels que le « tap » pour cliquer, le défilement en faisant glsser 2 doigts sur le touchpad, etc. Les préférences du touchpad ont reçu plusieurs nouvelles cases à cocher pour configurer ces différentes options.

Enfin, la dernière partie du patch met à jour le pilote Elantech pour reconnaître les 4 versions du protocole, dont la dernière est entièrement testée. La version 2 ne fonctionne pas correctement pour l’instant (elle a été désactivée pour l’instant) et les versions 1 et 3 sont activées de façon expérimentale dans les nightly builds en attendant les retours d’utilisateurs (samuelrp84).

Normalisation des noms de volumes générés par le pilote usb_disk pour s’assurer qu’ils ne commencent pas par des espaces (madmax).

Mise à jour de la couche de compatibilité FreeBSD avec FreeBSD 15 et synchronisation de tous les pilotes réseau (ethernet et wifi) concernés avec ceux de FreeBSD 15. Synchronisation du pilote rtl8125 avec OpenBSD (waddlesplash).

Ajout de « quirks » et de code supplémentaire dans le pilote I2C-HID pour essayer de se rapprocher du comportement implémenté dans Linux. Ce pilote ne fonctionne pas correctement pour l’instant et il est désactivé par défaut (Lt-Henry).

Systèmes de fichiers

Ajout d’un bouchon supplémentaire pour une API qui n’a pas besoin d’être implémentée dans userlandfs-FUSE (qui permet l’utilisation de systèmes de fichiers FUSE sous Haiku). Cette modification permet d’utiliser en particulier le système de fichier squashfs-fuse pour accéder à des volumes squashfs (OscarL).

Toujours dans userlandfs-fuse, propagation de l’état « lecture seule » du système de fichier, ce qui permet au Tracker de clairement afficher ces systèmes de fichiers comme étant en lecture seule (fond de fenêtre grisé, désactivation des opérations modifiant les fichiers) (OscarL).

Dans le système de fichiers UDF, amélioration des messages de logs, et correction d’un kernel panic déclenché par une assertion suite à des modifications précédentes dans le VFS (waddlesplash).

Correction d’un double lock dans le pilote FAT qui pouvait déclencher un kernel panic dans de rare cas (Jim906).

Intégration d’une partie des patchs permettant de redimensionner une partition BFS. Ce travail avait été commencé en 2014 dans le cadre du Google Summer of Code mais n’avait pas pu être terminé dans les temps. La série de patch est restée à l’abandon pendant de longues années, mais elle est en train d’être finalisée pour pouvoir en intégrer au moins une première partie (axeld).

Correction d’un bug sur la gestion des timestamps avec un nombre de secondes entier pour BFS. Historiquement dans BeOS, il n’existait pas d’API POSIX pour stocker une date de modification avec une résolution plus fine qu’une seconde. Cela conduisait de très nombreux fichiers à avoir le poids faible de leur date de modification à 0, avec pour conséquence une dégradation de la répartition dans les tables de hachage pour l’exécution de requêtes. Dans ce cas, BFS stocke une valeur aléatoire générée en interne par le système de fichier dans les bits de poids faible. Le bug était que cette valeur pouvait être exposée à l’espace utilisateur, entraînant de mauvais résultats sur la gestion des comparaisons de dates (par exemple pour déterminer les règles à lancer dans un makefile). La représentation interne a été légèrement modifiée pour bien distinguer les fichiers pour lesquels une date précise a été enregistrée, de ceux pour lesquels il s’agit de bits aléatoires. Ces derniers peuvent ainsi être filtrés et masqués pour l’espace utilisateur (PulkoMandy).

Correction de la gestion des dossiers déjà existants dans write_overlay. Ils'agit d’un système de fichier qui permet de stocker en RAM des écritures temporaires sur un système de fichier monté en lecture seule, utilisé en particulier pour l’exécution en mode live CD (nathan242).

Le pilote BTRFS ne déclenche plus un kernel panic lorsqu’il rencontre un type de compression inconnu, à la place, il retourne simplement une erreur et considère que le fichier ou dossier concerné ne peut pas être lu (AbdullahZulfiqar2005).

Des changements sur les requêtes (pour BFS et les autres systèmes de fichiers capables d’exécuter des requêtes): une petite optimisation du code, une modification pour ne pas notifier les suppressions de nœuds via B_QUERY_WATCH_ALL car elles sont déjà notifiées par d’autres moyens. L’API B_QUERY_WATCH_ALL est maintenant considérée comme stable, et a donc été ajoutée dans la documentation officielle (waddlesplash).

libroot & noyau

Réseau

Implémentation des sockets du domaine UNIX de type SOCK_SEQPACKET. Pour ce faire, modifications de recv et send pour accepter des buffers de taille 0 (pour les socket de type datagramme, pas les streams). Implémentation de MSG_TRUNC et MSG_PEEK pour les sockets du domaine UNIX, et amélioration de la gestion des adresses invalides dans accept et recv pour se rapprocher du comportement de Linux et des BSD (korli).

Implémentation de la découverte de MTU de chemin complet pour TCP et IPv4 (waddlesplash) et IPv6 (cmeerw). L’algorithme mis en place est simpliste, mais permet d’établir des communications dans des cas où le MTU est limité et la fragmentation de paquets n’est pas mise en place.

Nettoyage des buffers mémoire utilisés pour stocker des adresses dans le code de gestion du réseau. Cela corrige un comportement incorrect dans le cas où une adresse de socket UNIX n’est pas terminée par un caractère NUL (cas qui est explicitement autorisé sous Linux car l’information de longueur de l’adresse est disponible par ailleurs) (Anarchos pour la correction du cas où la vérification était oubliée, suivi d’un nettoyage par waddlesplash pour avoir une solution plus systématique à tous les endroits où ce cas particulier doit être pris en compte).

Un socket TCP qui est fermé alors que des données sont reçues par le noyau mais pas encore lues par l’application associée renvoie un paquet RST plutôt qu’un FIN. Ceci corrige un problème détecté dans les tests du langage Go. Modification du comportement lors de la réception d’un reset pendant la fermeture d’un socket TCP pour se comporter comme les autres systèmes (korli).

Déplacement du fichier networks utiliser par getnetent dans le dossier data, avec les autres fichiers de configuration du réseau. Il était placé par erreur dans /etc, qui est son chemin habituel pour d’autres systèmes UNIX (PulkoMandy).

Report d’une correction faite par NetBSD dans le résolveur DNS, il manquait une partie de l’initialisation de certains objets dans l’état du résolveur (cmeerw).

Gestion de l’IPv6: correction d’un problème dans la mise à jour du cache pour le protocole NDP (neighbor discovery), implémentation du multicast (cmeerw).

Remplacement des fonctions inet_net_ntop et inet_net_pton par l’implémentation d’OpenBSD, qui est plus respectueuse du standard que celle de NetBSD utilisée auparavant (korli).

Gestion des processus

Autorisation de l’appel de exec() depuis un autre thread que le thread principal du processus, pour se mettre en conformité avec POSIX et corriger un problème avec les outils de compilation d’OCaml (korli).

Préservation des signaux masqués lors de l’appel à fork (korli).

Mise en conformité POSIX des codes d’erreurs retournés dans certains cas dans la gestion des groupes de processus (waddlesplash).

Bibliothèque C standard

Mise en conformité POSIX-2024:

• Ajout des fonctions ffsl et ffsll dans strings.h (korli)
• Ajout de getresuid(), setresuid(), getresgid(), setresgid() (korli)
• Ajout de la déclaration de posix_spawn_file_actions_add[f]chdir dans les en-têtes publics (la fonction était déjà implémentée mais pas déclarée) (waddlesplash)

Synchronisation de l’implémentation de arc4random avec la dernière version d’OpenBSD (korli).

Correction d’un bug dans la gestion des locales, il n’était pas possible de changer seulement certaines catégories (date, format monétaire, messages), tout était forcément dans la même langue (waddlesplash).

Correction de plusieurs problèmes dans la famille de fonctions strftime (waddlesplash):

• ajout des formats %k et %l,
• correction sur la gestion des caractères d'espacement Unicode,
• correction de problèmes sur la gestion des fuseaux horaires.

Correction de problèmes mineur de compatibilité POSIX: ajout de déclarations de fonctions et de constantes dans search.h, unistd.h, semaphore.h, nettoyage dans limits.h, définition de getlocalename_l… (waddlesplash).

Remplacement de strtok_r par l’implémentation de musl (waddlesplash).

Refonte du stockage et de la gestion des données ctype pour rendre le code plus facile à maintenir, supprimer des indirections inutiles et corriger un problème de thread safety (waddlesplash).

Nettoyage des fonctions de conversions d’encodage de caractères, et correction de la valeur de MB_CUR_MAX pour l’encodage UTF-8 (waddlesplash).

Définition de la constante DEV_BSIZE (mentionnée dans POSIX mais pas obligatoire) dans sys/param.h, modification de tous le code utilisant stat.st_blocks pour utiliser cette constante, y compris des problèmes dans certains systèmes de fichiers qui utilisaient st_blksize à la place. En effet, il n’y a aucun rapport entre la taille de bloc de st_blksize et le nombre de blocs de st_blocks défini juste à côté (waddlesplash).

Gestion de la mémoire

Correction d’une régression du mois précédent sur la gestion des réservations de mémoire lors du découpage d’areas`. Ajout de la possibilité de transférer des réservations de pages pour les caches et areas réservés, pour éviter de réduire les réservations de façon incorrecte. Cela pouvait causer des assertions et des plantages du noyau en particulier lors de l’exécution d’applications utilisant AddressSanitizer (waddlesplash).

Correction d’une fuite de mémoire dans… la gestion de la mémoire, mis en évidence entre autres par l’exécution du compilateur Rust qui consomme beaucoup de mémoire. Au passage, nettoyage du code et des messages de logs dans cette partie du code (waddlesplash).

Entrées-sorties

Modification de la gestion des requêtes d’entrées-sortie pour autoriser les pilotes de périphériques à sous-classer IORequestOwner. En particulier, cela permet au pilote NVMe d’utiliser ces fonctionnalités sans passer par l’ordonnanceur d’I/O générique qui ne se prête pas bien à l’interfaçage de matériel pouvant traiter plusieurs requêtes en parallèle. Cela permet de simplifier du code, supprimer une fonction récursive devenue inutile et finalement corriger un débordement de pile (waddlesplash).

La taille des partitions indiquée dans le bootloader n’était pas correcte : c’était la taille du disque entier qui était affichée à la place (waddlesplash).

Chargeur de démarrage

Correction de l’affichage de caractères unicode dans le menu de démarrage. En particulier cela évite de corrompre l’affichage lors de la navigation dans le système de fichiers pour désactiver certains pilotes de périphériques. Le firmware UEFI utilise de l’UTF16, tandis que le BIOS utilise une page de code IBM non standardisée. Le bootloader utilise en interne de l’UTF-8 et doit donc convertir les caractères dans le bon format dans chaque cas (madmax).

Implémentation du démarrage via le réseau sur les plateformes EFI (avec un peu de nettoyage sur le support réseau dans OpenFirmware et PXE). Cela fonctionne au moins sur l’architecture ARM 32-bit et facilite le développement sur cible réelle: compilation sur une machine, et exécution sur une autre sans devoir entretemps copier le système de fichiers et le bootloader sur une clé USB ou une carte SD (kallisti5 et PulkoMandy).

Un des en-têtes du bootloader utilisait une syntaxe C++, il a été corrigé pour pouvoir être importé depuis du code C si nécessaire (beaglejoe).

Le chargeur EFI ignore les disques qui ont une taille de bloc de 0 octet, ce qui évite une division par zéro lors de tentatives de lire des données (archeYR).

Systèmes de fichiers

Le noyau interdit maintenant de monter plusieurs fois la même partition. Cette vérification avait d’abord été implémentée dans le pilote FAT, puis via une vérification en espace utilisateur, mais ces deux protections étaient insuffisantes et causaient d’autres problèmes (waddlesplash).

Centralisation de plusieurs vérifications au niveau du VFS, par exemple les vérifications de type fichier ou dossier, les modes d’ouverture des fichiers, des codes d’erreurs retournés pour certaines erreurs spécifiques. Ces changements évitent d’avoir des différences de comportement entre différents systèmes de fichiers et s’assurent que le comportement implémenté est bien celui spécifié par POSIX (waddlesplash).

Implémentation de « fallbacks » pour les systèmes de fichiers qui ne savent pas traiter eux-mêmes les opérations SEEK_DATA,  SEEK_HOLE et select(), dont en particulier le write_overlay. Cela permet à la commande cp de fonctionner correctement dans ce cas (nathan242).

Outils de debug

Remise en commun de code pour la gestion du MMU dans le chargeur de démarrage EFI. Le code avait été dupliqué pour chaque architecture de CPU supportés, mais il est en fait en très grande partie identique. Regrouper ce code permet de s’assurer que les évolutions sont bien faites de façon synchronisée pour toutes les architectures (PulkoMandy).

Affichage dans le message de kernel panic de la version de Haiku (numéro hrev). Ceci évite de devoir demander ce numéro aux utilisateurs remontant un bug, il est directement inclus dans la capture d’écran de l’erreur (nathan242).

Modification de la valeur retournée par kernel_version dans les informations système. La valeur retournée par Haiku était la version majeure, qui est 1 depuis le début du projet Haiku en 2001. Elle retourne maintenant une version plus complète qui peut être utilisée dans la commande uname pour indiquer la version de Haiku plus précisément (waddlesplash).

Désactivation de la fonction spécifique à BeOS exect sur les architectures qui n’implémentent pas de compatibilité binaire avec BeOS.

Build system

Ajout d’une macro _DEPRECATED dans les en-têtes de base du système, permettant d’indiquer les classes, méthodes et fonctions qui sont obsolètes et à ne plus utiliser. Cela permet d’avoir un avertissement du compilateur lors de leur utilisation dans le code existant, et de commencer à mettre à jour le code, mais sans casser le code déjà écrit pour l’instant. Actuellement, cette macro n’est pas utilisée, des discussions sont encore en cours sur l’opportunité de retirer certaines APIs.

Remise en état des tests pour le bootloader. Ces tests permettent de lancer une partie du bootloader (dont le menu de configuration) sous forme d’un programme s’exécutant sous Haiku. Cela permet de tester une grande partie du code du bootloader sans avoir besoin de redémarrer le système (waddlesplash).

Ajout d’un script pour convertir une disposition de clavier de la console Linux dans le format reconnu par Haiku (mmu_man).

Mise à jour de paquets pour réparer la compilation en mode « bootstrap » (sans dépendances précompilées) pour ARM et ARM64 (PulkoMandy).

Nettoyage et amélioration de la classe utilitaire FunctionTracer qui permet d’afficher facilement une trace de l’exécution de fonctions, avec une indentation indiquant les appels imbriqués. Il existait plusieurs versions de cette classe utilisées à différents endroits dans le code, chacune avec de légères variations. Renommage de fonctions qui pouvaient entrer en conflit avec l’utilisation de debug_printf et modification de cette dernière pour retourner le nombre de caractères imprimés afin de pouvoir l’utiliser de façon interchangeable avec les autres fonctions de la famille printf (PulkoMandy).

Déplacement de plusieurs en-têtes initialement développés pour une utilisation dans le noyau, de headers/private/kernel/util vers headers/private/util, en effet ils implémentent des fonctionnalités assez génériques (listes chaînées, hash tables, opérations sur les bits…) et sont tout à fait utilisables en dehors du noyau (c’est d’ailleurs déjà le cas à plusieurs endroits dans le code de Haiku) (PulkoMandy et waddlesplash).

Retrait de cas ou l’activation de DEBUG=1 (compilation en mode debug avec des assertions supplémentaires) était empêchée pour certains composants du code (waddlesplash).

Modification du code pour inclure les catalogues de traductions automatiquement dans le paquet contenant l’exécutable correspondant. Ce code incluait également les catalogues de toutes les dépendances, ce qui conduisait les catalogues système de libbe.so à être présents plusieurs fois dans plusieurs paquets, occupant inutilement de la place). Ce changement n’est pas tout à fait terminé puisque maintenant certains catalogues ne sont plus inclus du tout (PulkoMandy).

Modernisation de la page d’accueil de WebPositive pour en permettre l’utilisation avec d’autres navigateurs: définition du bon type MIME, utilisation de HTTPS pour télécharger des ressources externes, déclaration de l’encodage du fichier (humbinger).

Modification du « Makefile Engine » pour autoriser des flags de compilation différents entre les fichiers sources C et C++, ce qui permet d’éviter des warnings de compilation dans certains projets compilant des sources C (OscarL).

Il est maintenant possible de compiler Haiku depuis NetBSD (cmeerw).

Réparation de la compilation de test_app_server (KapiX).

Utilisation de la constante B_DEV_NAME_LENGTH plutôt que de la valeur numérique 128 à plusieurs endroits dans le code (jscipione et OscarL).

Suppression de la dépendance du build à la commande bc, en utilisant à la place des expressions arithmétiques du shell POSIX (PulkoMandy).

Réparation de la compilation des tests unitaires, modification des tests utilisant l’interface graphique pour les exécuter avec test_app_server, ajout d’un package haiku_unittests et d’un profil de build qui inclut ce package dans le système de fichier compilé. L’objectif est de pouvoir lancer ces tests automatiquement dans le cadre de l’intégration continue de Haiku (KapiX, à partir d’un travail plus ancien démarré par kallisti5).

Mise à jour de l’année de copyright à 2026 dans le menu de démarrage et dans les métadonnées des paquets générés par Haiku (PulkoMandy).

Mise à jour des paquets précompilés utilisés pour compiler Haiku avec les dernières versions fournies par HaikuPorts pour les architectures x86 et x86_64. L’outil utilisé pour faire cette synchronisation a reçu lui-même quelques évolutions. Le code de Haiku a été légèrement ajusté pour corriger les problèmes de compilation avec ces nouvelles versions des dépendances (waddlesplash, avec l’aide de madmax pour corriger des problèmes de compilation sur RISC-V qui utilise pour l’instant une version plus ancienne de certains paquets).

Documentation

Haiku book

Le « Haiku book » documente les API publiques et s’adresse aux développeurs d’applications pour Haiku. Il complète et remplace petit à petit le Be Book de BeOS, qui est distribué sous une licence CC-BY-ND ne permettant pas de le mettre à jour et de le corriger.

• Ajout du chapitre sur le Device Kit (DigitalBox98)
• Correction d’une documentation inversée pour un paramètre de BKeyStore (PulkoMandy)
• Ajout de documentation pour BSimpleGameSound, BSerialPort, MailAttachment, MailDaemon, mail_encoding (cafeina)
• Documentation des déviations connues de Haiku par rapport à la spécification POSIX (PulkoMandy).

Documentation interne

La documentation interne s’adresse aux développeurs et développeuses du système Haiku lui-même.

Correction de fautes de frappe dans le chapitre sur les systèmes de fichiers (OscarL).

Autres nouvelles

Changement de tarification de Netlify

Netlify héberge le site www.haiku-os.org. Ils ont récemment modifié leur tarification pour ajouter un système de crédit en fonction de la bande passante consommée. Haiku bénéficie de l’offre « Open Source », avec une certaine quantité de trafic offerte (en échange de l’affichage d’un logo de Netlify en base de page du site). Cette offre s’est révélée insuffisante dans la nouvelle tarification, surtout suite à une attaque de robots (probablement pour l’entraînement de LLM de mauvaise qualité, puisque ils requêtaient des pages n’existant pas et n’obtenaient que des erreurs 404). Du côté de Haiku, des protections ont été mises en place pour éviter ce genre de problème, mais entretemps, Netlify a facturé le dépassement de bande passante autorisée pour le mois de décembre.

Finalement, après une discussion avec l’équipe de support de Netlify et une vérification de ce qu’il s’était passé, la facture a été annulée, et la consommation de bande passante pour Haiku a été augmentée pour mieux convenir à l’utilisation habituelle générée par Haiku.

Remise sur les rails de HSA (Haiku Support Association)

Actuellement, l’association Haiku inc est la principale organisation recevant des dons et finançant les activités de Haiku (développeur employé, coût d’hébergement de l’infrastructure…).

Cette association est basée aux USA, ce qui est récemment devenu une source d’inquiétude pour certains contributeurs et donateurs de Haiku.

Suite à une discussion sur les forums, il y a donc un regain d’intérêt pour la Haiku Support Association, une autre organisation basée en Allemagne et qui était dormante depuis plusieurs années. Plusieurs personnes ont donc adhéré à cette association et cela va peut-être permettre d’en relancer l’activité et d’assurer une présence en Europe.

En particulier, c’est cette association qui organisait la conférence BeGeistert et le traditionnel « coding sprint » associé, permettant aux développeurs et aux utilisateurs de Haiku de se rencontrer régulièrement. Cette activité avait cessé suite au manque de public pour ces évènements, à une perte d’intérêt des membres de l’association, et une absence de nouveaux adhérents pour relancer les choses. Espérons que cette période d’inactivité soit maintenant terminée et que l’organisation de conférences plus régulières puisse reprendre.

Série d’articles « Gerrit code review iceberg »

Haiku utilise l’outil Gerrit pour la revue de code.

Il y a actuellement plus de 300 « change requests » qui sont ouvertes. Cela a suscité quelques interrogations sur le forum. Le projet est-il submergé de contributions? Les développeurs font-il un bon travail de revue? Quelles futures fonctionnalités de Haiku se cachent dans ces changements en attente?

Une série d’articles est en cours de publication pour examiner ces propositions abandonnées, en cours de travail ou partant dans une direction qui n’est pas acceptable pour les mainteneurs du projet. Chaque article examine 5 de ces change requests et explique les changements proposés, et pourquoi le travail n’a pas abouti.

Cette démarche a déjà permis à certains de ces changements de trouver un repreneur, plusieurs développeurs (anciens ou nouveaux contributeurs) se prenant au jeu de finaliser l’un d’entre eux. Cela devrait permettre de réduire un peu la liste, et d’encourager ensuite les nouvelles contributions en voyant que finalement, peu de choses sont vraiment abandonnées.

Statistiques de contribution pour 2025

Haiku a reçu 1068 commits en 2025. C’est la deuxième année la plus calme après 2023 et très loin du record de 2009 où il y avait eu 5555 commits. Cependant la comparaison n’est pas directe: en 2009, la revue de code était faite après l’envoi d’un commit sur la branche principale, avec des corrections effectuées par des commits supplémentaires si nécessaire. Aujourd’hui, chaque commit peut recevoir plusieurs modifications dans Gerrit avant d’être finalement intégré.

49 personnes ont écrit du code pour Haiku en 2025, entre 9 (en septembre) et 22 (en janvier) par mois. C’est là aussi plutôt dans le bas du tableau, et loin du record de 2012 (72 personnes). Waddlesplash se hisse à la troisième place du classement des personnes ayant le plus contribué (en nombre de commits) et va peut-être dépasser korli dès l’an prochain, malgré l’activité ininterrompue de ce dernier depuis 2003, presque au tout début du projet. Pas de changement du top 10, on attendait l’arrivée de kallisti5, mais il lui manque encore 70 commits pour dépasser Stefano Ceccherini. axeld conserve sa première place avec une avance confortable, malgré une activité plus réduite depuis quelques années.

Haiku compte environ 5 millions de lignes de code source, tout type de fichiers compris (ce nombre est stable voire en légère baisse depuis 2015) et 25 000 fichiers.

La situation est assez différente pour Haikuports : avec 2653 commits, 2025 est la deuxième année la plus active, derrière 2018 ou le projet avait atteint 2908 commits.

Le contributeur ayant le plus de commits est toujours korli, bien que Begasus semble en passe de le rattraper avec un rythme de contribution très soutenu.

Le projet a reçu en 2025 des contributions de 75 personnes différentes, ce qui est un peu en dessous du record établi l’année précédente avec 82 contributeurs mais reste un très bon score.

Le dépôt de Haikuports comporte 7000 fichiers et a dépassé 1 million de lignes de code, avec une progression approximativement linéaire depuis la création du dépôt en 2008.

La très grande majorité des commits de Haikuports sont réalisés sur des machines configurées avec les fuseaux horaires UTC, UTC+1 ou UTC+2, suivis par le fuseau UTC+10 (pour Haiku, ces statistiques de fuseaux horaire ne sont pas exploitables, la plus grande partie des commits ayant été importé depuis SVN qui ne préserve pas cette information).

Pour les deux projets, le pic d’activité semble être le mardi soir et on peut observer les heures creuses entre 2 h et 5 h du matin. Il n’y a pas de grosse différence entre les jours de semaine et les week-ends. On peut observer par contre que les mois d’hivers sont beaucoup peu plus actifs que ceux d’été et d’automne.

• Statistiques détaillées pour Haiku: https://pulkomandy.tk/stats/
• Statistiques détaillées pour Haikuports: https://pulkomandy.tk/stats_hp/

Mise à jour de haiku-format

Haiku-format est un ensemble de patchs pour clang-format pour tenter d’implémenter les règles de formatage de code choisies par le projet Haiku. Ces dernières ont été décidées avant la disponibilité d’un tel outil, et sont difficiles à automatiser correctement.

Les patchs ont été reportés sur une version plus récente de clang-format par owenca, et le robot de revue de code connecté à Gerrit mis à jour avec cette nouvelle version et remis en service par nielx. Les suggestions comportent encore des propositions de formatage incorrectes, c’est pourquoi cet outil est déployé uniquement sous forme d’un robot de revue et pas comme un outil de reformatage automatique.

Les développeurs qui connaissent bien les règles de formatage peuvent ensuite vérifier si ces commentaires sont pertinents. Cette solution est imparfaite, mais une discussion pour rendre les règles plus simples à automatiser n’a pas abouti à un consensus suffisant pour faire des modifications pour l’instant.

À quand la beta 6?

La version beta 5 de Haiku commence à être assez ancienne. Toute l’année 2025 est passée sans nouvelle publication de version.

La liste des choses à traiter pour cette nouvelle version s’est beaucoup réduite, cependant il reste encore quelques régressions assez gênantes. Certaines des corrections sont déjà en cours de relecture (en particulier pour améliorer la gestion de la mémoire swap). Il faudra probablement encore quelques mois pour venir à bout de toute la liste. On en reparle au prochain trimestre !

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
• Nouveau "tas gardé" (guarded heap) pour le noyau
• Applications
  • Tracker
  • Remote desktop
  • AboutSystem
  • MediaPlayer
  • Icon-O-Matic
  • WebPositive
  • Devices
  • Terminal
  • TextSearch
  • AutoRaise
  • ShowImage
  • Préférences d'horloge
  • DriveSetup
  • DiskProbe
  • DeskCalc
  • ActivityMonitor
  • Installer
  • Playground
• Outils en ligne de commande
• Kits
  • Application Kit
  • Interface Kit
  • Locale Kit
• Pilotes matériels
  • Intel_extreme (composants graphiques Intel)
  • usb_disk (stockage de masse USB)
  • XHCI (USB3) et EHCI (USB2)
  • Couche de compatibilité FreeBSD et OpenBSD
  • TTY (ports série et terminaux virtuels)
  • C-States (économie d'énergie du CPU)
  • ACPI C-States
  • USB-RNDIS
  • NVMe (SSD)
  • SDHCI (lecteurs de cartes SD)
  • acpi_termal (sondes de température)
• Systèmes de fichiers
  • FAT
  • ext2/3/4
  • NFS
  • ramfs
  • VFS
  • Autres
• libroot
  • • Mise en conformité avec POSIX 1-2024
• Noyau
• Système de compilation
• Documentation

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.

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.

Les trois derniers mois ont été un peu plus calmes que d’habitude pour Haiku, mais cela est largement compensé par une très forte activité du côté de Haikuports. Cela révèle que le système lui-même devient plus mature et qu’il devient de plus en plus facile de développer ou de porter une application sans tomber sur des problèmes du système qui doivent être corrigés au préalable.

Sommaire

• Applications
  • Tracker
  • Terminal
  • Mail
  • HaikuDepot
  • TextSearch
  • Debug Analyzer
  • Préférences d’apparence
  • Utilisation de IconMenuItem
  • Adaptation aux écrans à très haute réolution
• Outils en ligne de commande
  • Remote Desktop
  • Time
  • pkgman
  • su
  • listarea
  • fdinfo
  • install-wifi-firmwares
• Kits
  • Support kit
  • Interface kit
  • Storage kit
  • Shared kit
• Serveurs
  • app_server
  • input_server
• Pilotes
  • ACPI, gestion d’énergie, système
  • Réseau
  • Interface homme-machine
• Systèmes de fichiers
  • NFS4
  • EXT4
  • RAMFS
  • FAT
• libroot
  • Mise à jour de la libio
  • Correction de multiples problèmes dans les fonctions standard C et les extensions BSD:
  • Intégration des changements de POSIX-2024
  • Améliorations sur la gestion de la mémoire
• Noyau
• Bootloader
• Documentation
  • API (Haiku book)
• Environnement de compilation
• Portage de Haiku sur d’autres CPUs
  • RISC-V

Applications

Tracker

Tracker est le navigateur de fichiers de Haiku. Le code est hérité directement de BeOS (cette partie avait été publiée sous licence libre lors de l’abandon de BeOS par Be) et fait l’objet depuis de nombreuses années d’un gros travail de nettoyage et de modernisation.

Pas de grosses nouveautés ces derniers mois, mais des corrections pour plusieurs régressions suites à du nettoyage effectué précédemment. Par exemple, les icônes des disques montés sont à nouveaux affichés sur le bureau dans les dialogues d’ouverture et d’enregistrement de fichiers. L’annulation du filtrage du contenu d’un dossier en tapant un nom de fichier partiel est correctement annulé si on appuie sur échap.

Enfin, des problèmes de synchronisation de l’icône de la poubelle, qui apparaissait pleine alors qu’elle était vide, ont été corrigés. Ces problèmes étaient déjà présents dans BeOS.

Terminal

Le terminal permet de lancer des applications en ligne de commande.

Un chantier en cours consiste à rendre le terminal utilisable comme un “replicant”, c’est-à-dire de pouvoir l’intégrer dans d’autres applications telles que l’IDE Genio. Cette approche demande de restructurer beaucoup de choses, et pour l’instant, il est plus simple pour les développeurs de Genio de recopier une partie des sources du Terminal dans leur projet et de les intégrer de façon plus statique. Les problèmes sont corrigés petit à petit.

Une autre correction mérite d’être mentionnée: le terminal se plaçait lui-même dans le dossier de travail du shell lancé lors de l’ouverture d’un nouvel onglet. Si ce dossier se trouve dans un disque qu’on essaie par la suite de démonter, le démontage échoue (même si l’application lancée dans le terminal a elle-même changé de dossier entretemps). Désormais le terminal ne modifie pas son dossier actif et ne bloque plus le démontage des disques.

Mail

L’application Mail permet de lire et d’envoyer du courrier électronique. Elle est composée d’un serveur de synchronisation et d’une interface graphique indépendante. Entre les deux, les mails sont stockés sous forme de fichiers augmentés d’attributs étendus, ce qui permet d’utiliser Tracker et les requêtes BFS comme outil principal pour traiter les messages.

Les changements listés ici concernent l’application de lecture et rédaction de messages:

• Correction du comportement du menu « Fermer et marquer comme… » lorsqu’il est appliqué à plusieurs messages.

  • Modifications pour éviter de montrer des informations vides, en double, ou absentes dans les détails des adresses mail (nom d’expéditeur, de destinataire, etc).

HaikuDepot

HaikuDepot est à la fois le gestionnaire de paquets et le magasin d’applications de Haiku. Ce double rôle conduit pour l’instant à une interface qui prête un peu à confusion, et l’interface devrait être repensée pour un fonctionnement plus intuitif. En attendant, quelques petites améliorations ont tout de même été faites pour rendre les problèmes moins gênants.

Lorsqu’une recherche dans la vue « paquets mis en avant » ne donne aucun résultat, il y a affichage d’un lien permettant de poursuivre la recherche dans la liste complète des paquets. En effet, de nombreux utilisateurs se sont plaints de ne pas trouver certains logiciels en effectuant une recherche, sans se rendre compte qu’ils faisaient une recherche dans une liste de quelques dizaines de paquets et pas dans tout ce qui est disponible.

TextSearch

TextSearch est un outil de recherche dans le contenu des fichiers par expressions régulières (une version graphique de grep).

Il reçoit ce trimestre une fonction pour filtrer les fichiers à rechercher, équivalent à l’option grep --include.

Debug Analyzer

Debug Analyzer est un outil de profiling et d’analyse de traces d’exécution.

Correction d’un problème de compilation suite à des changements dans l’API de BObjectList (cet outil n’est pas compilé par défaut, il avait donc été oublié lors du changement d’API au trimestre précédent).

Préférences d’apparence

Dans la configuration des couleurs du système, renommage de la couleur « barre d’état » en « barre de progression ». Le nom « barre d’état » (status bar en anglais) correspond à la classe BStatusBar utilisée par BeOS et Haiku, mais tout le monde appelle ça une barre de progression. On peut au moins éviter la confusion pour les utilisateurs, à défaut de pouvoir le faire pour les développeurs d’applications en renommant la classe elle-même (ce qui causerait des problèmes de compatibilité d’API et d’ABI).

Utilisation de IconMenuItem

Ce changement concerne l’application ShowImage (visualiseur d’images) ainsi que FileTypes (les préférences d’association de types fichiers avec des applications). Ces deux applications utilisent un menu pour sélectionner une application (pour ouvrir une image dans un éditeur, ou pour associer un type de fichier à une application, respectivement).

Les applications pour Haiku utilisant des icônes colorées et facilement identifiables, c’est beaucoup mieux qu’une liste de noms pour s’y retrouver rapidement. Ces deux applications utilisent donc maintenant des IconMenuItem dans ces menus, pour afficher les applications avec leur icône respective.

Adaptation aux écrans à très haute réolution

Un travail en cours sur les applications concerne l’adaptation aux écrans à très haute résolution.

Presque toutes les applications pour Haiku utilisent un système de mise en page dynamique, et toutes les ressources (police de caractères, icônes…) sont vectorielles. Cela permet en théorie d’afficher l’interface avec un niveau de zoom arbitraire. Cependant, une partie du code a été écrit avec des tailles en pixels « en dur » et ne s’adapte pas comme il faudrait (la bonne façon de faire est de se baser par exemple sur la taille de la police de caractères sélectionnée par l’utilisateur).

Ce trimestre, on trouve des évolutions à ce sujet dans plusieurs applications:

• Expander (décompression d’archives)
• SerialConnect (communication par port série)
• Mise à l’échelle de la barre de défilement
• Préférences d’imprimantes
• Mise à l’échelle des icônes

Outils en ligne de commande

Remote Desktop

L’outil de connexion au bureau à distance n’est pas vraiment une application en ligne de commande. Cependant, il nécessite pour l’instant un lancement depuis un terminal avec les bonnes options, et selon les cas, la mise en place d’un tunnel SSH. Une interface grapique plus simple d’uitlisation sera probablement ajoutée plus tard.

• Amélioration du parsing de la ligne de commande et en particulier de l’option pour choisir un port SSH
• Activation de l’option SO_REUSEADDR permettant de plus facilement relancer l’outil s’il plante, sans attendre un timeout de la connexion précédente qui n’a pas été fermée proprement

Time

Le panneau de préférences de date et heure peut être lancé en ligne de commande avec une option spécifique pour forcer une synchronisation NTP. Cette fonctionnalité n’est pas vraiment documentée, à l’origine il s’agit plutôt d’une astuce interne au système. L’application reconnaît maintenant l’option --help standardisée et affiche un message d’aide qui documente cette fonctionnalité.

Il peut être utile de relancer cette commande manuellement si jamais la synchronisation au démarrage n’a pas fonctionné (par exemple si le réseau n’était pas disponible à ce moment-là). En particulier, cela peut être utilisé dans des scripts d’automatisation et pour des machines où l’interface graphique n’est pas facilement accessible (serveurs de build par exemple).

pkgman

pkgman est une commande permettant d’installer, mettre à jour et rechercher des paquets logiciels.

Ajout d’une option --no-refresh pour ne pas retélécharger la base de données des paquets.

Cette base de données contient non seulement les noms des paquets, mais aussi leur description courte et la liste des “provides” (par exemple: commandes et bibliothèques fournies par chaque paquet). pkgman vérifié déjà si une nouvelle version de la base de données est disponible, mais cette dernière peut être mise à jour plusieurs fois par jour par l’intégration continue.

Le nombre de paquets augmentant, la taille de la base de données devient non négligeable (plusieurs méga-octets), ce qui pose problème en particulier pour les utilisateurs et développeurs ne disposant pas d’un accès internet illimité.

su

La commande su est peu utilisée puisque l’utilisateur par défaut a déjà tous les droits. Son implémentation était donc un peu incomplète. Elle peut toutefois être utile pour avoir des utilisateurs supplémentaires restraints, par exemple pour un accès à distance par ssh.

• La commande su ne demande pas de mot de passe si l’utilisateur dispose déjà de l’accès root
• Toutes les commandes liées à la gestion des utilisateurs (su, login…) configurent les groupes actifs lors du changement d’utilisateur

listarea

listarea est une commande de debug permettant de lister les zones mémoire allouées à différentes applications. Elle affiche maintenant le verrouillage et les protections de ces zones (swappable ou non, exécutabele ou non, accessible en écriture ou non).

fdinfo

fdinfo permet d’examiner les descripteurs de fichiers ouverts (un peu comme lsof). Cette commande peut maintenant afficher en plus le dossier courant de chaque application (ce qui aurait été bien utile pour identifier le problème avec le dossier courant du Terminal ci-dessus).

install-wifi-firmwares

Ce script permet d’installer les firmwares pour certaines très anciennes cartes Wifi. Les firmwares publiés à l’époque sont disponibles avec des licenses n’autorisant pas la redistribution ou les modifications de packaging, ce qui empêche l’intégration dans le système de paquets habituel. Le problème a été corrigé depuis longtemps par les fabricants de cartes Wifi, mais les anciens firmwares n’ont jamais été republiés avec des licenses mises à jour.

Le script a été mis à jour pour récupérer certains firmwares depuis un nouveau serveur, l’ancien emplacement utilisé n’étant plus disponible.

Kits

La bibliothèque de fonctions de Haiku est découpée en kits qui regroupent des ensembles de fonctions et de classes par thématique (stockage sur disque, interface graphique…). Dans certains cas il s’agit principalement d’une méthode d’organisation du code source et de la documentation (les kits pouvent être très interdépendants). Certains kits sont toutefois fournis sous forme de bibliothèques séparées.

Support kit

Ce kit contient diverses fonctions utilitaires et basiques du système.

Changement d’API pour la classe BUrl. Dans l’ancienne version de cette classe, il était possible de construire un objet BUrl représentant une URL encodée ou non-encodée (échappement des caractères réservés). Cela rendait trop facile d’oublier d’encoder une URL avant de l’utiliser, ou bien d’encoder plusieurs fois une URL et de se retrouver avec un lien invalide.

La nouvelle API impose d’indiquer dès la création d’un objet BUrl si la chaîne de caractères servant de base est déjà encodée ou non. L’objet BUrl construit représentera toujours une URL déjà encodée, qui peut éventuellement être décodée pour affichage si nécessaire.

Interface kit

Ce kit contient tout ce qui se rapporte à l’interface graphique: fenêtres, vues, contrôles, mise en page…

Retour en arrière sur une modification des raccourcis claviers de BTextView pour naviguer vers les mots suivant et précédent. Les nouveaux raccourcis entrent en conflit avec des raccourcis déjà utilisés par plusieurs applications, et n’apportaient pas grand-chose.

Correction de problèmes de compatibilité dans le format des données stockées par la classe BPicture (il s’agit d’un enregistrement de commandes envoyées au serveur graphique, qui peuvent être rejouées plus tard). Le format des données stockées était différent de celui de BeOS. Certaines applications utilisant un objet BPicture enregistré dans une ressource de l’application, ne s’affichaient pas correctement.

Amélioration de la gestion des sous-menus, en particulier cela corrige un crash si un sous-menu est fermé en utilisant la touche échap.

Remise à plat de tous les calculs accumulés au cours des années pour générer les couleurs de l’interface graphique en fonction des couleurs choisies par l’utilisateur. Chaque morceau de code concernait faisait ses propres calculs pour générer de jolis dégradés, des variantes plus sombres et plus claires, etc. Cela fonctionnait bien avec le thème par défaut, mais pas forcément avec des choix de couleurs qui en sont très éloignés. Le nouveau code est plus simple, plus prédictible, et permet de rassembler ces calculs dans la classe « control look », qui peut être remplacée par un add-on pour fournir une apparence complètement différente.

Cela peut nécessiter d’ajuster un peu les couleurs dans les préférences d’apparence si vous les avez personnalisées.

Storage kit

Ce kit regroupe tout ce qui concerne le stockage de masse et la gestion des fichiers.

Harmonisation de la nouvelle fonction BQuery::SetFlags avec d’autres fonctions similaires, et ajout d’une page de documentation pour cette fonction.

Correction d’un crash lorsqu’on enregistre un type MIME alors que le type parent n’existe pas (par exemple si on enregistre image/gif alors que le type image n’existe pas).

Ajout d’une constante pour identifier les systèmes de fichiers FAT16 parmi la liste des systèmes de fichiers connus.

Shared kit

Le shared kit contient des fonctions expérimentales en cours de développement mais déjà utilisées par plusieurs applications.

Contrairement aux autres kits, il est fourni sous forme d’une bibliothèque statique, ainsi chaque application peut en utiliser une version différente (choisie au moment de la compilation) et il n’y a pas de contraintes pour conserver une stabilité d’API ou d’ABI. Les fonctions développées dans le shared kit peuvent ensuite être migrées vers les autres kits une fois qu’elles sont finalisées.

La classe « color list » (utilisée par exemple dans les préférences d’apparence) accepte maintenant le glisser-déposer de couleurs.

Serveurs

Les serveurs sont des applications lancées au démarrage du système. Ils sont similaires aux services systemd. Ils fournissent des services utiles à l’implémentation de la bibliothèque standard, car tout ne peut pas être fait dans une bibliothèque partagée.

app_server

app_server regroupe le serveur graphique de Haiku (utilisé au travers de l’interface kit) ainsi que la gestion des applications en lien avec l’application kit.

Correction d’un problème d’initialisation de variables indiquant dans quels workspaces (bureaux virtuels) une fenêtre doit être présente. Cela se manifestait par l’apparition de morceaux incomplets de la fenêtre si on change de bureau virtuel pendant son apparition. Le bug existait depuis 15 ans mais n’avait jusque-là pas pu être identifié.

Les curseurs de souris ne sont plus générés en bitmap à la compilation à partir des sources vectorielles. C’est maintenant fait lors de l’initialisation du serveur graphique, ce qui permet d’avoir un plus gros curseur sur les écrans à très haute résolution.

input_server

input_server se charge des périphériques d’entrée utilisateurs (claviers, souris et autres périphériques de saisie et de pointage).

Correction de la keymap espagnole latino-américaine dans laquelle plusieurs combinaisons de touches ne fonctionnaient pas comme sur les autres systèmes.

Pilotes

ACPI, gestion d’énergie, système

Mise à jour de ACPICA pour la prise en charge de ACPI avec la dernière version disponible.

Correction de problèmes dans le pilote poke (permettant l’accès direct à la mémoire pour écrire certains pilotes en espace utilisateur) pour mieux valider les paramètres des ioctl et éviter de pouvoir facilement déclencher un kernel panic suite à une mauvaise utilisation du pilote.

Réseau

Correction d’un problème dans la pile TCP ou les retransmissions de paquets lors de l’établissement de la connexion n’étaient pas faits, si le premier paquet était perdu, la connexion ne s’établissait jamais.

Lorsque IP_HDRINCL est activé (une application demande à envoyer et recevoir elle-même les en-têtes IP des paquets reçus), la pile réseau s’assure tout de même que les en-têtes générés ont bien un checksum valide. Cela permet à traceroute de fonctionner correctement par exemple.

Mise en place de l’infrastructure pour la découverte de MTU deu chemin. Cela permet de déterminer la taille maximale des paquets qu’on peut envoyer vers un serveur, sans que de la fragmentation IP soit mise en jeu en cours de route (ce qui, au mieux dégraderait les performances, au pire empêcherait la connexion de fonctionner correctement):

• Ajout de l’option IP_DONTFRAG pour demander aux routeurs de ne pas redécouper certains paquets,
• Remontée de l’information ICMP FRAGMENTATION_NEEDED pour détecter qu’on a essayé d’envoyer un paquet trop gros.

Cela permet déjà de détecter les problèmes de MTU, mais pas encore de les corriger automatiquement. La suite du code est encore en cours de test.

Remplacement du pilote iprowifi3945 par la version mise à jour disponible dans OpenBSD (pilote “wpi”) à la place de celle de FreeBSD qui est actuellement moins bien maintenue.

Interface homme-machine

Ajout de la tablette Intuos 4 dans le pilote pour les tablettes Wacom, ainsi que du support de la molette présente sur certaines tablettes.

Systèmes de fichiers

NFS4

NFS est un système de fichier en réseau. Une machine serveur se charge réellement du stockage des fichiers, et d’autres machines peuvent monter ce disque et accéder aux fichiers partagés. Plusieurs machines peuvent accéder au même serveur en même temps et modifier les fichiers, ce qui nécessite une attention particulière lors de l’implémentation d’un système de fichier client.

Le travail sur le pilote NFSv4 se poursuit pour le stabiliser et améliorer sa compatibilité avec les serveurs NFS existants.

Correction de problèmes de gestion du cache et de libération anticipée d’inodes`, points sur lesquels NFS est un peu inhabituel par rapport à d’autres systèmes de fichiers puisque des évènements peuvent arriver du serveur NFS concernant un fichier qui a été supprimé localement, par exemple.

Correction d’un problème qui pouvait conduire un fichier nouvellement redimensionné à contenir des données non initialisées au lieu d’octets à 0.

Cela permet de corriger des problèmes détectés par des tests NFSv4 existants pour d’autres systèmes.

EXT4

Le pilote ext4 permet de monter, en lecture et en écriture, les systèmes de fichiers ext2, ext3 et ext4 développés pour Linux.

Implémentation et activation de la fonctionnalité « metadata_csum_seed » qui est activée par défaut pour les systèmes de fichiers nouvellement créés sous Linux.

Corrections dans le « tree splitting » qui n’était pas implémenté correctement, empêchant d’accéder à des dossiers contenant un trop grand nombre de fichiers.

RAMFS

RAMFS est un système de fichiers non persistant, stockant les fichiers uniquement dans la RAM. Il est plus rapide qu’un système de fichier traditionnel.

Correction de crashs lors de la création de gros fichiers et lors du remplacement d’un hardlink par un autre fichier.

FAT

FAT est un système de fichiers développé par Microsoft pour DOS et les anciennes versions de Windows. Il est assez répandu et sert un peu de format d’échange standard en particulier pour les supports de stockage externes (clés USB, cartes SD, disquettes…).

Ajout d’assertions et de vérifications d’intégrité supplémentaires. Le pilote FAT utilisé actuellement provient de FreeBSD, dont les développeurs nous ont assuré qu’il était bien testé et maintenu. Mais, de façon similaire aux pilotes Wifi, on se rend compte que les bases d’utilisateurs de Haiku et de BSD ne sont pas du tout les mêmes, et nous sommes face à beaucoup de systèmes de fichiers FAT corrompus ou inhabituels, ce qui se produit peut-être moins souvent dans les utilisations de FreeBSD sur un serveur par exemple.

libroot

La libroot contient l’équivalent de la libc, libdl, libpthread et libm d’un système UNIX standard, ainsi que des fonctions bas niveau spécifiques à BeOS.

Les extensions GNU et BSD sont déportées dans des bibliothèques séparées (libgnu et libbsd), ce qui permet de respecter au mieux la spécification POSIX sans avoir à utiliser des astuces telles que des « weak symbols ».

Mise à jour de la libio

La bibliothèque standard de Haiku est à l’origine un fork de la glibc, utilisant exactement la même version que BeOS afin de garantir une compatibilité d’ABI optimale avec ce dernier. Cependant, cette version ancienne et obsolète ne répond pas aux besoins des applications modernes.

Petit à petit, des parties de la bibliothèque C sont donc remplacées par des composants venant de FreeBSD, NetBSD, OpenBSD ou plus récemment de musl. Certaines choses sont très bien standardisées et ne posent pas de problèmes, pour d’autres parties, des symboles internes de la bibliothèque sont exposés et parfois exploités par des applications (directement par des développeurs applicatifs pour contourner un bug, ou alors parce que les développeurs de la glibc ont mal isolé les choses et ont exposé des détails internes).

Ce trimestre, la partie libio (gestion des flux d’entrée-sortie) a été mise à jour avec la dernière version de la glibc. Il n’est pas possible d’utiliser une autre bibliothèque C pour cette partie sans casser l’ABI, mais la mise à jour est possible.

Correction de multiples problèmes dans les fonctions standard C et les extensions BSD:

• Ajout d’une vérification de la locale passée à setlocale pour retourner une erreur si la locale demandée est invalide.

• L’ouverture d’un chemin se finissant par un / avec open() échoue si le fichier n’est pas un dossier (par exemple open("/home/user/foo.txt/")).

• Validation du paramètre “how” de la fonction shutdown() et retour d’une erreur si le paramètre n’est pas une valeur connue.

• Les queues d’évènement créées par kqueue ne sont pas conservées lors d’un fork (même comportement que les BSD).

• Un socket sur lequel il n’y a jamais eu d’appel à listen() ou connect() ne doit pas déclencher les erreurs EPIPE ni ENOTCONN.

• La fonction socket() retourne maintenant les bons codes d’erreurs détaillés si elle ne peut pas créer le socket: EPROTOTYPE si le type de protocole est inconnu, EPROTONOSUPPORT s’il est connu mais pas disponible, EAFNOSUPPORT si la famille d’adresse n’est pas disponible. Auparavant, tous ces cas renvoyaient EAFNOSUPPORT.

• Amélioration de la gestion des erreurs dans accept()

• Gestion de cas particuliers pour bind() en UDP

• Ajout de l’option RTLD_GROUP pour dlopen(). Il s’agit d’une extension développée par Solaris qui permet d’avoir plusieurs espaces de noms pour la résolution de symboles lors du chargement de bibliothèques partagées. En particulier, dosemu l’utilise pour fournir aux programmes DOS une bibliothèque C indépendante de celle de l’hôte (fournissant donc des fonctions memcpy, memset… qui entreraient en conflit avec celles de l’hôte). L’implémentation est triviale, car le même comportement était déjà en place pour la gestion des add-ons de BeOS; il n’était simplement pas accessible au travers de l’API POSIX dlopen(). Linux implémente ce flag sous un autre nom, cependant, la documentation de la glibc n’est pas correcte, et FreeBSD a implémenté ce qui est documenté pour la glibc avec le même nom. C’est pourquoi le nom utilisé par Solaris, qui n’est pas ambigu, est utilisé pour l’instant, en espérant que la méprise entre Linux et FreeBSD pourra être corrigée.

• sethostname() retourne une erreur si le hostname proposé est trop long (auparavant il était simplement tronqué).

Intégration des changements de POSIX-2024

La spécification POSIX a été mise à jour en 2024. Cette mise à jour est assez importante grâce à un changement de la méthode de travail de l’Austin Group qui maintient la spéficication. Le groupe de travail a ouvert un bug tracker sur lequel il est possible de remonter des problèmes et de proposer des améliorations (à conditions que ces dernières soient déjà implémentées sous forme d’extensions sur un assez grand nombre de systèmes).

Cela a permis à plus de monde de prendre part à la spécification et de standardiser beaucoup de nouvelles choses. Haiku intègre ces changements petits à petits, parfois par anticipation, parfois parce que l’extension correspondante était déjà disponible, et parfois parce que le portage d’un logiciel le nécessite.

• Ajout de O_CLOFORK, MSG_CMSG_CLOEXEC, et MSG_CMSG_CLOFORK pour fermer des descripteurs de fichiers lors d’un fork (équivalent de O_CLOEXEC qui ferme lors d’un exec, typiquement après un fork). Au passage, ajout dans la libbsd de closefrom() et closerange(), ces deux fonctions permettant de lancer des tests développés pour BSD pour ces nouveaux drapeaux.
• Ajout de fdatasync(), une fonction qui s’assure que le contenu d’un fichier est bien enregistré sur disque et pas seulement dans le cache.

Améliorations sur la gestion de la mémoire

La gestion de la mémoire est un sujet central pour un système POSIX. L’API proposée (malloc, realloc, calloc et free) est à la fois très simple d’utilisation et très générique. Elle a donc tendance à être très sollicitée par les applications, ce qui en fait un composant critique de l’optilisation des performances du système. De plus, les applications sont de plus en plus consommatrices de mémoire et le matériel a tendance à en contenir de plus en plus.

L’allocateur mémoire a été remplacé il y a quelques mois, l’ancien allocateur hoard2 ne permettant pas d’agrandir dynamiquement l’espace alloué à une application. Après plusieurs essais, c’est pour l’instant l’allocateur d’OpenBSD qui a été retenu. En effet, beaucoup d’allocateurs plus modernes supposent un espace d’adressage 64 bit et sont peu économes en termes de réservation d’espace mémoire.

Cependant, même l’allocateur d’OpenBSD montrait ses limites sur les systèmes 32 bit. Son paramétrage a été amélioré, et d’autres modifications ont également été faites pour réduire la fragmentation de l’espace mémoire. Cela corrige des problèmes ou GCC ne parvient pas à allouer assez de mémoire lors de la compilation de très gros fichiers (par exemple lors de la compilation de clang ou de webkit). Il reste recommandé de désactiver l’ASLR (randomization de l’espace d’adressage) dans les cas où on a besoin de beaucoup de mémoire pour une application 32 bits.

Noyau

Le noyau de Haiku est un noyau monolithique tout à fait classique pour un système UNIX. Il permet le chargement dynamique de modules, et fournit une API relativement stable pour ces derniers, ce qui permet de maintenir des pilotes facilement en dehors du dépôt de sources de Haiku.

Correction de problèmes causant le kernel panic « failed to acquire spinlock for a long time » lorsque l’affichage à l’écran des logs du noyau est activé.

Ajout d’assertions supplémentaires dans le code de gestion de la mémoire virtuelle pour essayer de détecter des problèmes au plus tôt et avant de risquer de corrompre des données importantes.

Correction de l’affichage des paramètres des appels systèmes dans strace sur x86.

Correction de problèmes dans la gestion des permissions pour write_stat (modification des informations sur un fichier comme la date de modification) dans le noyau ainsi que dans les systèmes de fichiers RAMFS, BFS et EXT4. Cela corrige des comportements étranges observés lors de l’utilisation de rsync.

Ajout d’un test vérifiant le bon fonctionnement des exceptions remontées par le FPU lors de calculs en virgule flottante (ces exceptions sont un peu difficiles à traiter dans un système multitâche, et en particulier dans Haiku où le code du noyau peut lui-même utiliser le FPU alors que ce n’est pas le cas pour d’autres systèmes).

Correction de problèmes liés au découpage et au redimensionnement des areas (zones de mémoires allouées par les APIs prévues à cet effet de BeOS, ou indirectement par mmap et d’autres fonctions permettant de manipuler l’espace mémoire). Cela corrige des problèmes pour RAMFS ainsi qu’un kernel panic observé lors du lancement de dosemu.

Correction de problèmes avec les areas en lecture seule, qui pouvaient aboutir dans certains cas à une sous-évaluation de la mémoire utilisée, aboutissant à un kernel panic, car il n’y a plus de mémoire disponible à un moment où le noyau ne s’y attend pas. Cela a été mis en évidence en particulier avec l’utilisation mémoire de certains navigateurs web, qui ont tendance à gérer la mémoire directement sans passer par l’allocateur standard du système, pour des raisons de performance.

Remise en route de guarded_heap (un allocateur mémoire qui détecte les dépassements de buffers, au prix d’une consommation mémoire fortement augmentée). Correction de problèmes mis en évidence par cet allocateur dans quelques pilotes.

Dans la structure mcontext/ucontext passée aux fonctions de traitement de signaux, ajout de plusieurs registres manquants (registres de segments, addresse de faute…). Cela est utilisé par le JIT de dosemu et va probablement permettre d’utiliser le JIT dans d’autres applications également. En effet, une approche possible pour le JIT est de déclencher volontairement un signal, afin d’intercepter l’état des registres, éventuellement de le manipuler, puis de reprendre l’exécution là où elle s’était arrêtée.

Ajout de vérification de permissions manquantes dans l’appel système get_extended_team_info.

Correction d’une possible fuite d’un descripteur de fichier dans le VFS.

Bootloader

Mise à 0 de tous les registres non utilisés lors de l’appel de fonctions du BIOS, afin d’aider à investiguer des problèmes avec certains BIOS capricieux.

Amélioration des messages d’erreurs lorsque le bootloader ne parvient pas à charger le fichier ELF du noyau. Le chargeur de fichiers ELF du noyau est volontairement incomplet pour simplifier les choses (après tout, il a besoin seulement de charger le noyau), mais cela pose problème lors de mises à jour de GCC ou lors du portage sur de nouvelles architectures, si l’organisation du fichier ELF du noyau se trouve modifiée.

Correction de problèmes de compilation lorsque des logs de debug optionels sont activés.

Documentation

La documentation de Haiku se découpe principalement en trois parties:

• Un guide de l’utilisateur,
• Une documentation d’API pour les développeurs d’applications,
• Une documentation d’implémentation pour les développeurs du système lui-même.

API (Haiku book)

Documentation de la classe BControl (classe abstraite qui fournit l’API standard de la plupart des contrôles utilisables dans l’interface graphique, les rendant interchangeables dans une certaine mesure).

Documentation de AdoptSystemColors et HasSystemColors pour la classe BButton.

Ajout de documentation pour les extensions à dlfcn.h par rapport à ce qui est déjà spécifié par POSIX.

Environnement de compilation

Haiku est écrit en C++ et utilise jam (un concurrent de make) comme outil principal de compilation. Cet outil a été retenu, car il permet de définir des règles de compilation génériques et réutilisables pour faire toutes sortes de choses. La compilation de Haiku pouvant mettre en jeu trois compilateurs différents (un pour le système hôte, un pour le système Haiku cible, et un troisième pour la couche de compatibilité avec BeOS), la plupart des autres outils ne répondent pas bien aux besoins.

Suppression de règles Jam redondantes. Jam repose sur des règles nommées pour savoir quelles actions sont nécessaires pour générer une cible à partir de sources. Les règles “Application”, “Server”, “Preferences” et “Executable” étaient toutes identiques, elles ont donc toutes été remplacées par “Application” pour simplifier le système de build.

Correction de “warnings” du compilateur pour des variables inutilisées et suppression de code mort (dans le cadre du maintien d’un code propre et lisible, une tâche plus ou moins continue pour suivre l’évolution des bonnes pratiques, la disponibilité de nouveaux outils d’analyse, et absorber la dette technique qui peut s’accumuler au cours d’un projet aussi ancien).

Début de support pour GCC 15: il est ajouté dans la liste des versions du compilateur reconnues pour le système hôte, ce qui permet de compiler Haiku depuis un système Linux très récent. L’intégration en tant que compilateur cible viendra plus tard.

Remplacement de la commande which utilisée dans certains scripts de build par l’équivalent command -v, ce qui évite une dépendance à une commande non standard qui n’est pas forcément installée par défaut partout.

Dans le makefile engine (un template de makefile proposé pour développer facilement des applications pour Haiku), ajout de documentation et d’exemples pour les variables INSTALL_DIR et TARGET_DIR.

Portage de Haiku sur d’autres CPUs

RISC-V

Correction d’un problème dans un script de link qui empêchait le démarrage du noyau.

Mise à jour de paquets utilisés pour compiler le système de base.

Mise en place d’un serveur de compilation de paquets pour RISC-V, ce qui permet de remplir le dépôt de paquets pour cette architecture et d’envisager une version officielle de Haiku pour RISC-V lors de la prochaine version bêta. L’architecture RISC-V s’ajoutera ainsi au x86 (32 et 64 bit) déjà supporté.

Suite à une question posée en 2023, cette dépêche propose un état des lieux des sources librement accessibles (sans imposer un jeton pour accéder aux API pour obtenir de manière structurée l’information) permettant de suivre les jours en tensions pris en compte dans l’option tarifaire TEMPO chez EDF. Cette option tarifaire consiste à payer moins cher l’électricité à condition de la payer 3 fois plus cher 22 jours dans l’année : les jours en tensions, généralement durant l’hiver.

Cette option permet de lisser la charge sur le réseau de transport de l’électricité. Pour faire bon usage de cette option, il faut surveiller la couleur du jour pour déterminer s’il vaut mieux réduire le chauffage électrique et les autres sources de consommations électriques. L’information est affichée le jour même sur le compteur électrique, mais il peut être utile d’être prévenu. On peut consulter le site de EDF, mais il peut être plus intéressant de disposer d’une API pour récupérer cette information, et ainsi pouvoir l’intégrer dans un système domotique, par exemple.

Sommaire

• Les anciennes APIs ne fonctionnent plus
• À la recherche d’une solution de remplacement
• Conclusion

Les anciennes APIs ne fonctionnent plus

En effet, les forums domotiques attestent que c’était pourtant très utilisé, depuis le 29/08/2024 (avant-veille du changement de saison Tempo) les URL concernées (resp. couleur du jour+lendemain et compteurs saison en cours) répondent en erreur:

Couleurs jour/lendemain
Totaux en cours

À la recherche d’une solution de remplacement

On voit une autre URL apparaître ces derniers jours sur les forums, mais elle ne donne pas spécifiquement les couleurs jour/lendemain mais des compteurs: nombre de jours bleus, rouges et blancs depuis le début de l’année. Il faudrait donc déduire la couleur du jour en fonction de ce qui change d’un jour à l’autre! On a vu plus simple, mais comme ça marche pas on ne risque pas de l’utiliser:
URL nouvelle

{
    “errors”: [],
    “content”: [
        {
            “typeJourEff”: « TEMPO_BLANC »,
            “libelle”: « TEMPO BLANC 2024 2025 »,
            “nombreJours”: 43,
            “premierJour”: « 2024-09-01 »,
            “dernierJour”: « 2025-08-31 »,
            “premierJourExclu”: null,
            “dernierJourExclu”: null,
            “nombreJoursTires”: 0,
            “etat”: “OUVERTE”
        },
        {
            “typeJourEff”: « TEMPO_BLEU »,
            “libelle”: « TEMPO BLEU 2024 2025 »,
            “nombreJours”: 300,
            “premierJour”: « 2024-09-01 »,
            “dernierJour”: « 2025-08-31 »,
            “premierJourExclu”: null,
            “dernierJourExclu”: null,
            “nombreJoursTires”: 12,
            “etat”: “OUVERTE”
        },
        {
            “typeJourEff”: « TEMPO_ROUGE »,
            “libelle”: « TEMPO ROUGE 2024 2025 »,
            “nombreJours”: 22,
            “premierJour”: « 2024-11-01 »,
            “dernierJour”: « 2025-03-31 »,
            “premierJourExclu”: null,
            “dernierJourExclu”: null,
            “nombreJoursTires”: 0,
            “etat”: « NON_COMMENCEE »
        }
    ]
}

Le site d’EDF utilise une API interne indiquant la couleur, jour par jour, pour une plage de dates donnée. Il faut remplir quelques en-têtes HTTP pour que la requête soit acceptée :

curl \
    'https://api-commerce.edf.fr/commerce/activet/v1/calendrier-jours-effacement?option=TEMPO&dateApplicationBorneInf=2023-9-12&dateApplicationBorneSup=2023-9-15&identifiantConsommateur=src' \
    -H 'accept: application/json, text/plain, */*' \
    -H 'cache-control: no-cache' \
    -H 'content-type: application/json'

Exemple de réponse:

{
    “errors”: [],
    “content”: {
        “dateApplicationBorneInf”: « 2023-09-12 »,
        “dateApplicationBorneSup”: « 2023-09-16 »,
        “dateHeureTraitementActivET”: « 2024-09-11T11:19:26Z »,
        “options”: [
            {
                “option”: “TEMPO”,
                “calendrier”: [
                    {
                        “dateApplication”: « 2023-09-12 »,
                        “statut”: « TEMPO_BLEU »
                    },
                    {
                        “dateApplication”: « 2023-09-13 »,
                        “statut”: « TEMPO_BLEU »
                    },
                    {
                        “dateApplication”: « 2023-09-14 »,
                        “statut”: « TEMPO_BLEU »
                    },
                    {
                        “dateApplication”: « 2023-09-15 »,
                        “statut”: « TEMPO_BLEU »
                    }
                ]
            }
        ]
    }
}

Ces APIs semblent répondre en erreur « La syntaxe de la requête est erronée » aléatoirement lorsqu’on y accède avec curl. Une requête peut fonctionner une fois puis subitement cesser de répondre. S’agit-il d’une limitation du nombre de requêtes venant de la même IP? D’une authentification à effectuer pour avoir le droit de faire des requêtes? Ou juste d’un système complètement buggé qui plante une fois sur 10?

Pour ceux, que j’imagine nombreux, a qui cela va poser problème et qui ne veulent (ou peuvent) obtenir l’info via un module téléinfo à monter sur son compteur, il y a une URL dont je n’ai pas trouvé référence sur le site de RTE (qui ne propose que des API à jetons) qui se trouve en regardant le github source d’un site tiers donnant également l’info:
Source tierce

L’info délivrée par le compteur arrive en prime bien plus tardivement: En début de soirée au lieu de fin de matinée. C’est parce qu’elle transite par Enedis, une autre entreprise qui se charge de la distribution de l’électricité (les lignes à basse tension et les compteurs électriques).

On peut donc utiliser cette indirection ou regarder les sources afin de trouver l’URL en question, pour laquelle on a une info hélas bien plus verbeuse où il faut faire son marché : on récupère un JSON de tous les jours écoulés depuis le début de la saison en cours, et il faut :

— extraire l’info aux bonnes dates,
— refaire ses compteurs de jours bleu/blanc/rouge pour savoir s’il reste des jours rouges ou blancs prévus avant la fin de l’hiver,
— traiter le flag “fallback” qui, selon la documentation, indique un mode dégradé, mais ce flag ne semble jamais être mis à “true” dans l’historique des données disponibles, et son rôle exact n’est pas clair.

Conclusion

Il est au final navrant qu’EDF remplace un truc simple qui marchait très bien par un machin alambiqué qui tombe en marche une fois sur 10…

Je ne donne pas l’URL librement accessible, mais non documentée, de RTE car je n’aimerais pas qu’elle croule sous les demandes: Ceux qui sont capables de l’utiliser de manière raisonnée sans exploser des quotas sauront bien la trouver avec les infos données!

(RTE, Réseau de Transport de l’Électricité est l’entreprise qui s’occupe du réseau électrique à haute tension en France. Ce sont eux qui déterminent les jours où le réseau va être très chargé, et c’est ça qui détermine le prix de l’électricité).

Un avantage à l’utiliser, c’est que l’info est disponible encore plus tôt qu’elle ne l’était chez EDF (c’était généralement MAJ peu après 11h00), permettant d’anticiper encore un peu plus un jour rouge, sachant qu’ils sont souvent en série, si on a quelques lessives à lancer…

S’il y a des suggestions d’alternatives (sans jetons d’API) non citées, merci de les indiquer en commentaires.

Haiku est un système d’exploitation pour les ordinateurs personnels. Il s’agit à l’origine d’une réécriture de BeOS. Le projet a démarré en 2001 et est actuellement en phase de beta-test pour une première version stable avec support à long terme. Depuis 2024, l’activité du projet Haiku s’accélère grâce entre autres à l’embauche d’un développeur à plein temps. Les dépêches sur Haiku sont donc désormais publiées tous les 3 mois au lieu de tous les ans pour leur conserver une longueur digeste.

La complète liste des changements survenus pendant ces 3 mois comporte près de 300 commits. La dépêche ne rentre pas dans les détails de chaque changement et met en valeur les plus importants.

Les grosses évolutions sont un nouveau port de Iceweasel (Firefox), et des grosses améliorations sur la gestion de la mémoire.

Comme on est en début d’année, c’est aussi le moment du bilan financier.

Sommaire

• Rapport financier 2024
  • Recettes
  • Dépenses
  • Réserves
• Applications
  • Iceweasel
  • Tracker
  • TeamMonitor
  • HaikuDepot
  • Préférences
  • Expander
  • Cortex
  • Icon-O-Matic
  • PowerStatus
  • StyledEdit
  • WebPositive
  • Mode sombre et configuration des couleurs
  • Outils en ligne de commande
• Kits
  • Application kit
  • Debug kit
  • Device Kit
  • Interface kit
  • Media Kit
  • libshared
• Servers
  • app_server
  • input_server
  • net_server
  • notification_server
  • mail_daemon
  • runtime_loader
• Drivers
  • Périphériques de stockage
  • Cartes son
  • Réseau
  • Pilotes FreeBSD
  • Pilotes spécifiques à Haiku
  • USB
  • PS/2
  • virtio_pci
  • ACPI
  • Sondes de température
  • Pilotes graphiques
• Systèmes de fichiers
  • FAT
  • BFS
  • packagefs
  • NFS4
  • ramfs et ram_disk
  • Autres
• libroot
  • Compatibilité POSIX-2024
    • ioctl et posix_devctl
• Kernel
  • VFS
  • Console et affichage
  • Réseau
  • Gestion de la mémoire
  • Autres
• Chargeur de démarrage
• Outils de compilation
• Documentation
  • Documentation interne
  • Documentation d’API
• Traductions de Haiku

Rapport financier 2024

Recettes

L’association Haiku inc (association de type 501(c)3 aux USA) publie chaque année un rapport financier. Le rôle de l’association est de récolter les dons et de les redistribuer pour aider au développement de Haiku. Elle ne prend pas part aux décisions techniques sur l’orientation du projet, et habituellement les dépenses sont faites en réponse aux demandes des développeurs du projet.

L’objectif en début d’année 2024 était de récolter 20 000$ de dons. Cet objectif a été largement atteint, il a dû être mis à jour 2 fois en cours d’année et finalement ce sont plus de 31 000$ qui ont été reçus ! Cela en particulier grace à un assez gros don de 7 500$.

Les dons sont récoltés via différentes plateformes: Github Sponsors (intéressant, car il n’y a aucun frais de traitement), PayPal, Liberapay, Benevity (une plateforme de « corporate matching »), ainsi que des paiements par chèque, virements bancaires, et en espèce lors de la tenue de stands dans des conférences de logiciels libres. La vente de T-Shirts et autre merchandising via la boutique Freewear reste anecdotique (une centaine de dollars cette année).

Il faut ajouter à ces dons une contribution de 4 400$ de la part de Google en compensation du temps passé à l’encadrement des participants au Google Summer of Code.

Il faut également ajouter des dons en crypto-monnaies, principalement en bitcoins. Le rapport financier présente les chiffres en détail en tenant une compatibilité séparée en dollars, en euros, et en crypto-monnaies, avant de convertir le total en dollars pour dresser un bilan complet.

Une mauvaise nouvelle tout de même: le service de microdons Flattr a fermé ses portes. L’entreprise propose maintenant un service de bloqueur de publicités payant, qui reverse de l’argent aux sites dont les publicités sont bloquées.

Le compte Flattr de Haiku avait été créé pour recevoir des dons sur la plateforme, mais n’avait jamais été configuré pour transférer ces dons vers le compte en banque de l’association. Malgré un certain temps passé à discuter avec le service client de Flattr et à leur fournir tous les documents demandés, il n’a pas été possible de trouver une solution pour récupérer cet argent. Ce sont donc 800$ qui ne reviendront finalement pas au projet Haiku.

Au final, les recettes sont de 36 479 dollars, de loin la plus grosse somme reçue par le projet en un an.

Dépenses

La dépense principale est le paiement de Waddlesplash, le développeur actuellement employé par Haiku inc pour accélérer le développement du système (les autres développeurs participent uniquement sur leur temps libre, en fonction de leurs autres activités). Cela représente 25 500$, un coût assez faible par rapport au travail réalisé.

Le deuxième poste de dépenses est l’infrastructure, c’est-à dire le paiement pour l’hébergement de serveurs, les noms de domaines, et quelques services « cloud » en particulier pour le stockage des dépôts de paquets.

Le reste des dépenses consiste en frais divers (commission PayPal par exemple), remboursement de déplacements pour la participation à des conférences, ainsi que le renouvellement de la marque déposée sur le logo Haiku.

Le total des dépenses s’élève à 31 467$. C’est moins que les recettes, et l’association continue donc de mettre de l’argent de côté. L’année 2022 a été la seule à être déficitaire, suite au démarrage du contrat de Waddlesplash. Ce contrat est à présent couvert par les donations reçues.

Réserves

L’association dispose de plus de 100 000$ répartis sur son compte en banque, un compte PayPal (qui permet de conserver des fonds en euros pour les paiements en euros et ainsi d’éviter des frais de change), et un compte Payoneer (utilisé pour recevoir les paiements de Google).

Elle dispose également de près de 350 000$ en crypto-monnaies dont la valeur continue d’augmenter. Cependant, actuellement ces fonds ne sont pas accessibles directement, en raison de problèmes administratifs avec Coinbase, l’entreprise qui gère ce portefeuille de crypto-monnaies. Le compte n’est pas configuré correctement comme appartenant à une association à but non lucratif et cela pose des problèmes de déclaration de taxes lorsque on souhaite vendre des crypto-monnaies contre du vrai argent. Cette situation persiste depuis plusieurs années, mais l’association n’a pour l’instant pas besoin de récupérer cet argent, les réserves dans le compte en banque principal étant suffisantes.

Applications

Iceweasel

Le navigateur web Iceweasel est disponible dans les dépôts de paquets (seulement pour la version 64 bits pour l’instant). Il s’agit d’un portage de Firefox utilisant la couche de compatibilité Wayland. Le nom Firefox ne peut pas être utilisé puisqu’il ne s’agit pas d’un produit officiel de Mozilla.

En plus du travail de portage pour réussir à faire fonctionner le navigateur, cela a nécessité un gros travail d’amélioration au niveau de la gestion de la mémoire, une partie du système qui est fortement mise à contribution par ce navigateur. On en reparle plus loin dans la dépêche.

Le navigateur est encore considéré comme expérimental: plusieurs fonctions sont manquantes et il peut y avoir des plantages. WebPositive (le navigateur natif basé sur WebKit) reste donc le navigateur installé par défaut avec Haiku, mais les deux sont complémentaires. Par exemple, Iceweasel permet d’afficher les vidéos Youtube avec des performances acceptables.

Tracker

Tracker est le gestionnaire de fichiers de Haiku. Il implémente une interface « spatiale », c’est-à-dire que chaque dossier s’ouvre dans une fenêtre séparée et enregistre sa position à l’écran.

Le code du Tracker fait partie des composants qui ont pu être récupérés de BeOS. Cela signifie que certaines parties du code ont été développées il y a près de 30 ans, dans un contexte où l’élégance du code n’était pas la priorité (il fallait pour les développeurs de BeOS, d’une part livrer un système fonctionnel dans un temps raisonable, et d’autre part, fonctionner sur les machines relativement peu performantes de l’époque).

Les évolutions sur le Tracker nécessitent donc souvent du nettoyage dans de nombreuses parties du code, et provoquent souvent des régressions sur d’autres fonctionnalités. Toutefois, les choses s’améliorent petit à petit.

Ce trimestre, on a vu par exemple arriver la correction d’un problème avec l’utilisation de la touche « echap ». Cette touche peut servir à plusieurs choses:

• Fermer une fenêtre de chargement ou d’enregistrement de fichier,
• Annuler le renommage d’un fichier,
• Annuler une recherche rapide « type ahead » qui consiste à taper quelques lettres et voir immédiatement la liste de fichiers du dossier courant se réduire à ceux qui contiennent cette chaîne de caractères.

Ces différentes utilisations peuvent entrer en conflit. Plus précisément, lorsqu’on utilise le filtrage « type ahead », puis qu’on change d’avis et qu’on appuie sur la touche « echap », il ne faut pas que cela ferme la fenêtre en même temps.

Un autre changement concerne plutôt la validation des données: Tracker interdit l’insertion de caractères de contrôle ASCII dans le nom de fichiers. Ce n’est pas strictement interdit (ni par Haiku, ni par ses systèmes de fichiers, ni par POSIX) en dehors de deux caractères spéciaux: le '/' et le 0 qui termine une chaîne de caractères. Mais, c’est très probablement une mauvaise idée d’avoir un retour à la ligne ou un autre caractère de contrôle enregistré dans un nom de fichier. Le Tracker interdit donc désormais de le faire et si vous êtes vraiment résolu à y parvenir, il faudra passer par le terminal.

Enfin, une nouvelle fonctionnalité dans le Tracker est la mise à jour en temps réel des menus pop-up. Cela peut se produire pour plusieurs raisons, par exemple, l’appui sur la touche « command » modifie le comportement de certains menus. Avant ce changement, il fallait ré-ouvrir le menu (command + clic droit) pour voir ces options modifiées. Maintenant, on peut d’abord ouvrir le menu, puis maintenir la touche command enfoncée pour voir les options modifiées.

Cela a nécessité une refonte complète de la gestion de ces menus (qui proposent de nombreuses autres choses comme la navigation « rayons X »). Au passage, certaines options qui étaient uniquement disponibles au travers de raccourcis claviers ou de la barre de menu des fenêtres du Tracker sont maintenant aussi affichées dans le menu pop-up.

TeamMonitor

TeamMonitor est le gestionnaire d’applications affiché quand on utilise la combinaison de touches Ctrl+Alt+Suppr. Il permet de stopper des programmes, de redémarrer la machine, et autres manipulations d’urgence si le système ne fonctionne pas comme il faut.

Les processus lancés par une même application sont maintenant regroupés et peuvent être tous arrêtés d’un seul coup. Ce changement est nécessaire suite à l’apparition de IceWeasel, qui crée beaucoup de processus en tâche de fond pour une seule instance du navigateur web.

HaikuDepot

HaikuDepot est l’interface graphique pour le système de paquets de Haiku. Il se présente comme un magasin d’applications, permettant non seulement d’installer et de désinstaller des logiciels, mais aussi de les évaluer avec une note et un commentaire.

• Ajout d’un marqueur sur les icônes des paquets qui sont déjà installés, et remplacement du marqueur utilisé pour indiquer les applications « natives » (utilisant le toolkit graphique de Haiku, par opposition à Qt et GTK par exemple).
• Affichage plus rapide de l’état « en attente d’installation » lorsqu’on demande l’installation d’un paquet.
• L’interface pour noter un paquet est masquée si l’attribution de notes n’est pas possible.

Préférences

Diverses améliorations dans les fenêtres de préférences:

• Correction d’un crash dans les préférences d’affichage (korli).
• Les préférences de fond d’écran n’acceptent plus le glisser-déposer d’une couleur sur un contrôle de choix de couleur désactivé. La modification de la position X et Y de l’image de fond se met à jour en temps réel quand on édite la valeur des contrôles correspondants.
• Ajout de réglages supplémentaires (vitesse, accélération, défilement) dans les préférences des pavés tactiles. Ces options étaient déjà implémentées dans l’input_server, mais configurable uniquement pour les souris.
• Suppression de code mort et amélioration de la gestion des polices de caractères dans les préférences d’apparence.

Plusieurs améliorations sur les préférences de sons de notifications:

• La fenêtre de sélection de fichiers retient le dernier dossier utilisé,
• Elle permet également d’écouter un son avant de le sélectionner,
• Les menus de sélection rapide de sons affichent uniquement les fichiers et pas les dossiers,
• Certains sons ont été renommés.

La plupart des sons ne sont cependant toujours pas utilisés par le système.

Expander

Expander est un outil permettant d’extraire plusieurs types de fichiers archivés.

Peu de changement sur cet outil qui est assez simple et fonctionnel. La seule amélioration ce mois-ci concerne un changement des proportions de la fenêtre pour éviter un espace vide disgracieux.

Cortex

Cortex est une application permettant de visualiser et de manipuler les nœuds de traitement de données du Media Kit.

Le composant « logging consumer » qui reçoit des données d’un autre noeud et les enregistre dans un fichier de log pour analyse a été amélioré pour enregistrer un peu plus d’informations.

Icon-O-Matic

L’éditeur d’icônes vectoriels Icon-O-Matic évolue peu, après un projet Google Summer of Code qui a ajouté la plupart des fonctionnalités manquantes. Ce trimestre, un seul changement: l’ajout d’une entrée menu pour supprimer un « transformeur ».

PowerStatus

L’application PowerStatus affiche l’état de la batterie. Cela peut se présenter comme une icône dans la barre des tâches. L’icône est de taille réduite, et les différents états n’étaient pas forcément bien visibles. Ce problème a été corrigé avec des nouveaux marqueurs pour l’état de la batterie (en charge ou inactive).

StyledEdit

StyledEdit est un éditeur de texte simple, permettant tout de même de formater le texte (un peu comme WordPad pour Windows).

L’application reçoit une nouvelle option pour écrire du texte barré. Le code nécessaire a également été ajouté dans app_server, puisque cette possibilité était prévue, mais non implémentée.

WebPositive

Le navigateur WebPositive reçoit peu d’évolutions en ce moment, en dehors de la maintenance du moteur WebKit. On peut tout de même mentionner l’ajout d’un menu contextuel sur les marque-pages, permettant de les renommer et de les supprimer. Ce développement est issu d’un vieux patch réalisé par un candidat au Google Summer of Code, qui ne fonctionnait pas et n’avait jamais été finalisé.

Mode sombre et configuration des couleurs

Depuis la version Beta 5, Haiku dispose d’un nouveau système de configuration des couleurs, permettant d’obtenir facilement un affichage en « mode sombre ». Cependant, cet affichage est loin d’être parfait, et de petits ajustements sont à faire petit à petit dans toutes les applications qui n’avaient pas été pensées pour cela. En particulier, le changement de couleurs se fait en direct lorsqu’on change les réglages. On trouve ces trois derniers mois des changements dans DeskBar, Tracker, HaikuDepot, l’horloge, ainsi que la classe BTextView.

Outils en ligne de commande

pkgman peut rechercher les paquets installés et qui n’ont aucun autre paquet dépendant d’eux. Cela permet de trouver des paquets inutiles qui peuvent être désinstallés (il manque encore la possibilité de marquer un paquet comme étant « installé manuellement » avant de pouvoir automatiser le nettoyage).

La commande route accepte la syntaxe utilisée par openvpn pour la configuration d’une route par défaut, ce qui facilite l’utilisation de VPN avec Haiku.

Correction d’un problème dans le compilateur de ressources: la commande rc -d ne savait pas décompiler la structure app_version des applications Haiku, uniquement le format plus ancien utilisé par BeOS.

La commande screenmode permet maintenant de récupérer la valeur actuelle du réglage du rétro-éclairage (en plus de permettre de changer cette valeur).

Kits

La bibliothèque de fonctions de Haiku est découpée en « kits » qui regroupent un ensemble de classes et de fonctionnalités liées.

Application kit

L’Application Kit permet, comme son nom l’indique, de lancer des applications. Il offre également toutes les fonctionnalités de boucles d’évènements, et d’envoi de messages entre applications et entre composants d’une application.

Correction d’un problème de suppression d’un port dans la classe BApplication.

Debug kit

Le Debug Kit fournit les services nécessaires au Debugger pour débugger une application. Cela consiste d’une part en un accès privilégie à l’espace mémoire d’une application, et d’autre part en outils pour analyser les fichiers ELF des exécutables et bibliothèques.

Le Debug Kit reçoit ce trimestre plusieurs évolutions et corrections permettant le décodage des stack traces dans les programmes compilés avec clang et lld. Par exemple, les fichiers ELF générés par ces outils sont découpés en plusieurs segments, alors que ce n’est pas le cas pour gcc.

Device Kit

Le Device Kit regroupe tout ce qui concerne l’accès direct au matériel et aux entrées-sorties depuis l’espace utilisateur: ports série, accès direct aux périphériques USB, accès aux joysticks et manettes de jeu.

Les ports série RS232 peuvent être configurés avec des valeurs en baud personnalisées (pour l’instant uniquement pour les adaptateurs série USB).

Interface kit

L’Interface Kit regroupe tout ce qui concerne l’affichage de fenêtres et de vues à l’écran et les interactions avec ces fenêtres.

• Ajout de constructeur « move » et d’opérateur d’assignation pour BRegion et BShape pour améliorer les performances en évitant les copie d’objet immédiatement suivies de suppression.
• Ajout d’un constructeur pour BRect avec deux arguments (largeur et hauteur) pour les rectangles alignés en haut à gauche ou dont la position n’a pas d’importance.
• Remise en place d’un cas particulier dans BBitmap::SetBits pour la gestion du canal alpha afin d’avoir un comportement plus proche de celui de BeOS.
• BColorControl réagit correctement et déclenche les évènements nécessaires lorsqu’on modifie sa couleur par glisser-déposer.

Media Kit

Correction d’une assertion vérifiant la mauvaise condition dans BTimeSource.

Réécriture de la classe BTimedEventQueue pour améliorer ses performances en évitant d’allouer de la mémoire dynamique.

Amélioration de l’affichage des « media controls » (sliders de contrôle de volume par exemple) en mode sombre.

libshared

La « libshared » contient plusieurs classes expérimentales, en cours de développement, mais déjà utilisées par plusieurs applications. Il s’agit d’une bibliothèque statique, ce qui permet de changer facilement son contenu sans casser l’ABI des applications existantes.

Ajout de la classe ColorPreview qui existait en plusieurs exemplaires dans le code de Haiku (préférences d’apparence et Terminal). Cette classe permet d’afficher une couleur dans un petit rectangle. Elle est utilisée à plusieurs endroits dans des contrôles de choix de couleur plus complexes, tels que des listes ou des menus.

Servers

Les servers sont des processus systèmes implémentant différentes fonctionnalités de Haiku. Le concept est similaire à celui des daemons dans UNIX, ou des services dans Windows NT et systemd.

app_server

L’app_server s’occupe de l’affichage des applications à l’écran.

Suppression de code inutilisé depuis longtemps permettant l’accélération matérielle d’opérations de dessin en 2D (blit, tracé de lignes, remplissage de rectangles…).

Sur les cartes graphiques PCI, ces opérations étaient souvent réalisées plus rapidement par le CPU qui tourne à une fréquence bien plus rapide que la carte. Sur les cartes AGP, l’accès en lecture à la mémoire vidéo par le CPU est très lent, et il était donc plus intéressant de faire ces opérations en RAM centrale avant d’envoyer un buffer prêt à afficher à la carte graphique. Enfin sur les cartes PCI express modernes, ces fonctions d’accélération ont disparu ou en tout cas n’ont pas du tout une interface compatible avec les besoins de Haiku. Il est donc temps de jeter ce code.

Modification de la façon dont les applications récupèrent la palette de couleurs en mode graphique 256 couleurs: elle utilise maintenant une mémoire partagée, et il n’est plus nécessaire que chaque application demandent au serveur graphique d’en obtenir une copie.

input_server

L’input_server se charge des entrées souris et clavier. Cela comprend les méthodes d’entrée de texte (par exemple pour le Japonais) ainsi que des filtres permettant de manipuler et d’intercepter ces évènements d’entrée avant leur distribution dans les applications.

Améliorations du filtre PadBlocker pour bloquer le touchpad quand le clavier est en cours d’utilisation sur les PC portables: gestion des répétitions de touches, blocage uniquement du touchpad et pas des autres périphériques de pointage.

net_server

Le net_server se charge de la configuration des interfaces réseau.

Arrêt du client d’autoconfiguration (DHCP par exemple) lors de la perte du lien sur un port Ethernet, pour ne pas essayer d’envoyer des paquets alors que le câble est débranché.

notification_server

notification_server se charge de l’affichage de panneaux de notification pour divers évènements tels que la connexion et déconnexion d’interfaces réseau, un niveau dangereusement bas de la batterie, la fin d’un téléchargement…

La fenêtre de notification a été retravaillée pour mieux s’adapter à la taille de police d’affichage choisie par l’utilisateur.

mail_daemon

mail_daemon permet d’envoyer et de recevoir des e-mails. Les messages sont stockés sous forme de fichiers avec des attributs étendus pour les métadonnées (sujet, expéditeur…). Plusieurs applications clientes permettent de rédiger ou de lire ces fichiers. Ainsi chaque application n’a pas besoin de réimplémenter les protocoles IMAP ou SMTP.

Amélioration de la fenêtre de logs pour la compatibilité avec le mode sombre.

runtime_loader

Le runtime_loader est l’outil qui permet de démarrer un exécutable. Il se charge de trouver toutes les bibliothèques partagées nécessaires et de les placer dans la mémoire.

Ajout du flag PF_EXECUTE qui rend exécutable uniquement les sections ELF qui le nécessitent (auparavant, toutes les sections qui n’étaient pas accessibles en écriture étaient exécutables). Cela est utilisé en particulier par clang, qui sépare une zone en lecture seule (pour les constantes) et une autre en lecture et exécution (pour le code). Avec gcc, les deux sont habituellement regroupées dans la même section.

Drivers

Périphériques de stockage

Correction de bugs dans la couche SCSI (utilisée également pour d’autres périphériques de stockage qui encapsulent des commandes SCSI). Des drapeaux d’état n’étaient pas remis à 0 au bon moment, ce qui causait des kernel panic avec le message « no such range! ».

Cela a été l’occasion de faire du ménage : suppression de champs inutilisés dans des structures de données, et suppression du module d’allocation mémoire locked_pool qui n’était utilisé que par la pile SCSI. À la place, utilisation des fonctions d’allocation mémoire standard du noyau, qui sont amplement suffisantes pour répondre aux besoins de ce module (waddlesplash).

Cartes son

Correction d’erreurs dans le code de gestion mémoire des pilotes es1370 et auvia. Ces drivers utilisaient deux copies d’un code d’allocation identique, mais avaient divergé l’un de l’autre. Ils ont été réunifiés mais cela a provoqué quelques régressions, avec des difficultés pour trouver des machines permettant de tester chacune des cartes son concernées. Haiku peut heureusement compter sur des utilisateurs « avancés » qui testent régulièrement les nightly builds pour détecter ce type de régression (korli).

Réseau

Correction d’une fuite mémoire lors de l’utilisation de sockets « raw » permettant d’envoyer et de recevoir directement des paquets ethernet (en contournant la couche IP).

Pilotes FreeBSD

Une grande partie des pilotes de carte réseau de Haiku sont en fait ceux de FreeBSD ou d’OpenBSD. Une couche de compatibilité permet de réutiliser ces pilotes avec très peu de changement dans leur code source. Ainsi, les évolutions et corrections peuvent être partagées avec l’un ou l’autre de ces systèmes. La collaboration avec les *BSD pour les pilotes réseau se passe de mieux en mieux : suite au développement d’une couche de compatibilité permettant d’utiliser les pilotes OpenBSD dans Haiku, les développeurs de FreeBSD étudient la possibilité de réutiliser également ces pilotes. De plus, les développeurs de Haiku et d’OpenBSD sont en contact pour coordonner les mises à jour et les tests.

Génération de statistiques plus fiables sur les paquets réseaux dans la couche de compatibilité FreeBSD et remontée des statistiques générées par les pilotes associés.

Synchronisation du pilote realtekwifi avec la version de FreeBSD et reconnaissance d’un identifiant de périphérique USB supplémentaire dans ce pilote.

Amélioration de la couche de compatibilité pour se comporter plus précisément comme FreeBSD, et suppression de patchs correspondants dans les pilotes qui sont devenus superflus.

Amélioration des performances de la couche de compatibilité: retrait de comparaisons de chaînes de caractères et d’allocations inutiles.

Pilotes spécifiques à Haiku

Amélioration du comportement du pilote USB RNDIS (partage de connexion sur USB de certains téléphones Android) lorsque le câble USB est déconnecté. Le pilote incluait du code pour tenter de restaurer la connexion existante si le même appareil est reconnecté, mais les périphériques RNDIS utilisent des adresses MAC aléatoires qui changent à chaque connexion, donc cela ne pouvait pas fonctionner. De plus, certains transferts USB n’étaient pas correctement annulés pour laisser la pile USB dans un état propre après la déconnexion du périphérique.

USB

Ajout d’une annulation de transferts de données en attente dans le pilote pour les périphériques de stockage USB, ce qui corrige un kernel panic lors de l’utilisation de lecteurs de disquettes USB. Arrêt immédiat des opérations (au lieu de ré-essayer pendant quelques secondes) si le périphérique indique « no media present » (CD ou disquette éjectée de son lecteur par exemple).

Ajout d’une vérification de pointeur NULL et de libération de mémoire manquantes dans la pile USB, ce qui corrige des fuites de mémoires (qui étaient là depuis longtemps) et une assertion qui se déclenchait (introduite plus récemment).

Le pilote de webcam UVC est mis à jour pour utiliser des constantes (identifiants de types de descripteurs…) partagées avec le reste du système au lieu de toutes les redéfinir une deuxième fois. L’affichage des descripteurs dans listusb est également complété pour décoder toutes les informations disponibles. Le pilote n’est toujours pas complètement fonctionnel: l’établissement des transferts au niveau USB fonctionne, mais pour l’instant le pilote ne parvient pas à décoder les données vidéo reçues correctement.

Le pilote HID sait reconnaître les « feature reports », qui permettent de configurer un périphérique. Par exemple, cela peut permettre de configurer un touchpad en mode multi-point (dans lequel le système doit effectuer lui-même le suivi de chaque doigt sur la surface tactile pour convertir cela en mouvements de pointeur de souris) ou en mode émulation de souris (où on ne peut utiliser qu’un doigt à la fois, mais avec un pilote beaucoup plus simple).

Le pilote pour les tablettes Wacom reconnaît la tablette CTH-470.

PS/2

Les ports PS/2 ont disparu de la plupart des machines ces dernières années, mais le protocole reste utilisé pour le clavier des ordinateurs portables, ainsi que pour certains touchpads. Malheureusement, le protocole est seulement émulé au niveau de l’« embedded controller » (le microprocesseur qui se charge de l’interfaçage de divers composants annexes). Le résultat est que l’implémentation du protocole et des registres d’interface peut s’éloigner considérablement des documents officiels.

Amélioration de la détection des contrôleurs PS/2 supportant le protocole « active multiplexing » permettant de connecter à la fois une souris et un touchpad. La procédure de détection officielle peut générer des faux positifs: certains contrôleurs répondent bien à cette commande, mais n’implémentent en fait pas du tout le protocole. Cela provoquait un long délai au démarrage alors que le pilote tente d’énumérer des périphériques de pointage qui n’existent pas. Une vérification supplémentaire après l’activation du mode multiplexé permet de détecter ce cas.

virtio_pci

virtio est un standard matériel pour les machines virtuelles. Plutôt que d’émuler un vrai matériel (carte réseau, carte graphique…), une machine virtuelle peut émuler un matériel qui n’a jamais été fabriqué, mais dont la programmation est beaucoup plus simple. Cela permet également des opérations inimaginables sur du matériel réel, comme la possibilité de changer la taille de la RAM en cours d’exécution pour mieux partager la mémoire de l’hôte entre différentes machines virtuelles.

Le pilote virtio_pci est à la racine du système virtio. Il détecte la « carte PCI » virtio et implémente les primitives de base d’envoi et de réception de messages entre l’hôte et la machine virtualisée (du côté virtualisé, pour le côté hôte, c’est le virtualisateur, par exemple QEMU, qui s’en charge).

Correction de plusieurs problèmes avec les numéros de files virtio qui rendaient les pilotes instables.

ACPI

ACPI est un cadriciel pour la gestion de l’énergie et l’accès au matériel. Le fabricant du matériel fournit (dans la ROM du BIOS) un ensemble de « tables » contenant une description du matériel disponible, ainsi que des méthodes compilées en bytecode pour piloter ce matériel. Le système d’exploitation doit fournir un interpréteur pour ce bytecode, puis réaliser les entrées-sorties vers le matériel demandé lors de l’exécution.

Haiku utilise actuellement ACPICA, une bibliothèque ACPI développée principalement par Intel.

Correction d’un problème d’accès à de la mémoire non cachée. Une modification faite pour les machines ARM a déclenché un problème sur les machines x86.

Sondes de température

Ajout d’un nouveau pilote amd_thermal, ajout de ce dernier ainsi que des pilotes pch_thermal et acpi_thermal dans l’image disque par défaut. Ces pilotes devraient permettre de récupérer la température du processeur sur la plupart des machines. Il reste maintenant à intégrer cela dans les outils en espace utilisateur pour faire un bon usage de ces informations.

Pilotes graphiques

Ajout de deux nouvelles générations de cartes graphiques dans le pilote intel_extreme.

Le pilote VESA est capable de patcher le BIOS de certaines cartes graphiques à la volée pour y injecter des modes graphiques supplémentaires (la spécification VESA permettant à l’OS uniquement de choisir un mode parmi une liste fournie par la carte graphique, liste souvent assez peu fournie). Ce mode est désormais activé par défaut sur les cartes graphiques où il a pu être testé avec succès.

Systèmes de fichiers

FAT

FAT est un système de fichier développé par Microsoft et qui remonte aux premiers jours de MS-DOS. Il est encore utilisé sur certaines clés USB et cartes SD, bien que exFAT tend à le remplacer petit à petit. Il est également utilisé pour les partitions systèmes EFI.

Le pilote de Haiku a été récemment réécrit à partir de celui de FreeBSD. L’amélioration de ce nouveau pilote se poursuit, avec ce mois-ci :

• Les noms de volumes FAT sont convertis en minuscules comme le faisait l’ancien pilote FAT,
• Le cache de blocs implémente maintenant un mécanisme de prefetch pour récupérer plusieurs blocs disque d’un coup, et le pilote FAT utilise cette nouvelle possibilité pour améliorer en particulier le temps de montage,
• Correction de problèmes dans le cache de fichiers si deux applications accèdent au même fichier mais avec des noms différents par la casse (le système de fichier ignorant ces différences).

BFS

BFS est le système de fichier principal de BeOS et de Haiku. Il se distingue des autres systèmes de fichiers par une gestion poussée des attributs étendus, avec en particulier la possibilité de les indexer et d’effectuer des requêtes pour trouver les fichiers correspondants à certains critères.

Clarification de la description des options disponibles lors de l’initialisation d’un volume BFS.

Correction des fonctions d’entrées/sorties asynchrones pour référencer correctement les inodes, ce qui corrige un très ancien rapport de bug. Des corrections similaires ont été faites également dans les pilotes FAT et EXFAT.

Correction des requêtes sur l’attribut « dernière modification », et amélioration de la gestion du type « time » pour éviter les conversions inutiles (ce type d’attribut est historiquement stocké en 32 bits mais migré en 64 bits lorsque c’est possible pour éviter le bug de l’an 2038, aussi le code doit être capable de traiter ces 2 formats de stockage).

packagefs

Le système de fichier packagefs est au centre de la gestion des paquets logiciels dans Haiku. Les paquets ne sont pas extraits sur le disque, mais montés dans un système de fichier spécifique (qui implémente une version tout-en-un de ce qui pourrait être réalisé sous Linux avec squashfs et overlayfs).

Ce système de fichier se trouve donc sur le chemin critique en termes de performances, ce qui fait que même de petites optimisations peuvent déboucher sur de gros gains de performance.

Optimisation de la gestion de la mémoire: utilisation d’un allocateur dédié pour allouer et désallouer très rapidement de la mémoire de travail avec une durée de vie courte.

Ajout d’une vérification manquante sur la présence du dossier parent, qui pouvait déclencher un kernel panic.

NFS4

Le pilote NFS4 permet de monter des partages réseau NFS. Cependant, le pilote ne fonctionne pas toujours, et certains utilisateurs doivent se rabattre sur le pilote NFS v2 (ancienne version du protocole de moins en moins utilisée), ou encore sur des systèmes de fichiers FUSE comme SMB ou sshfs.

Le pilote NFS4 peut maintenant être compilé avec userlandfs (équivalent de FUSE pour Haiku) pour s’exécuter en espace utilisateur. Cela facilitera le déboguage.

ramfs et ram_disk

ram_disk est un périphérique de stockage qui stocke les données en RAM, il a une taille fixe et doit être formaté avec un système de fichiers avant de pouvoir être utilisé.
ramfs est un système de fichier stockant les données directement en RAM sans passer par un périphérique de stockage de type bloc. Sa taille est dynamique en fonction des fichiers qui sont stockés dedans.

Ces deux pilotes ont reçu divers nettoyages et corrections, suite à des problèmes mis en évidence par des assertions ajoutées précédemment dans le code.

Dans le ramfs, nettoyage de code dupliqué, réduction de la contention sur les verrous, amélioration de la fonction readdir pour retourner plusieurs entrées d’un coup au lieu de les égréner une par une.

Ajout de la gestion des fichiers « spéciaux » (FIFOs nommés, sockets UNIX) dans ramfs.

Autres

Refonte de l’algorithme de « scoring » des requêtes sur les systèmes de fichiers. Cet algorithme permet d’estimer quels sont les termes de la requête les moins coûteux à évaluer, afin de réduire rapidement le nombre de fichiers répondant aux critères, et d’effectuer les opérations complexes seulement sur un petit nombre de fichiers restants. Les requêtes s’exécutent ainsi encore plus rapidement (waddlesplash).

Réécriture du code pour identifier les partitions dans mount_server. Ce code permet de re-monter les mêmes partitions après un redémarrage de la machine, mais l’ancien algorithme pouvait trouver de faux positifs et monter des partitions supplémentaires (OscarL et waddlesplash).

Correction d’une option de debug pour intercepter les accès aux adresses non initialisées (0xcccccccc) ou déjà libérées (0xdeadbeef). Cela permet de détecter certains accès à des pointeurs invalides. Cette option ne fonctionnait correctement que sur les systèmes 32 bit, maintenant, l’adresse correspondante pour les machines 64 bit est également protégée.

libroot

La libroot est la librairie C de base de Haiku. Elle regroupe les fonctions parfois implémentées dans les libc, libm, libpthread, librt et libdl pour d’autres systèmes. Haiku choisit une approche tout-en-un, car il est excessivement rare qu’une application n’ait pas besoin de toutes ces bibliothèques.

Du fait de la grande diversité des services rendus par cette bibliothèque, il est difficile de présenter les changements de façon cohérente et organisée.

Correction de quelques cas particuliers dans le traitement des tableaux de descripteurs de fichiers pour select() et déplacement d’une partie des définitions de sys/select.h vers des en-têtes privés non exposés aux applications (waddlesplash).

Ajout d’une fonction manquante dans les « stubs » de la libroot, qui sont utilisés lors de la compilation de Haiku en mode « bootstrap » (sans aucune dépendance précompilée externe). Les stubs sont normalement générés à l’aide d’un script, mais celui-ci n’avait pas pris en compte une fonction nécessaire seulement sur les architectures x86.

Poursuite du travail d’unification des fonctions de manipulation des temps d’attentes pour toutes les fonctions de la libroot qui peuvent déclencher un timeout. Correction d’un cas où la fonction pthread_testcancel retournait NULL au lieu de la valeur attendue PTHREAD_CANCELED.

Optimisation de la fonction strcmp, remplacement d’autres fonctions avec de meilleures implémentations provenant de la bibliothèque C musl.

Compatibilité POSIX-2024

La spécification POSIX Issue 8 a été publiée et comporte de nombreux changements. Après la version 7, la façon de travailler est devenue plus ouverte, avec un outil de suivi de bugs permettant de proposer des améliorations. Cela conduit à la standardisation de nombreuses extensions qui sont communes entre les systèmes GNU et BSD, rendant plus facile d’écrire du code portable entre tous les systèmes compatibles POSIX.

• Ajout de fonctions qui ouvrent des descripteurs de fichiers avec le drapeau O_CLOEXEC activé par défaut (dup2, pipe3)
• Ajout de reallocarray (un mélange de calloc et realloc)
• Ajout de memmem (recherche d’une suite d’octets dans une zone de mémoire)
• Ajout de mkostemp
• Ajout de posix_devctl et modifications de l’implémentation de ioctl
• Ajout de pthread_getcpuclockid pour mesurer le temps CPU consommé par un thread
• Ajout de la constante d’erreur ESOCKTNOSUPPORT bien qu’elle ne soit jamais utilisée (cela facilite le portage d’applications qui attendent l’existence de ce code d’erreur)
• Correction d’une boucle infinie dans pipe2
• Suppression des fonctions *randr48_r des en-têtes publics. Il s’agit d’une extension disponible uniquement dans la glibc, et qui ne devrait donc pas être disponible dans la libroot. Cependant, l’implémentation est conservée pour assurer la compatibilité d’ABI avec les applications existantes.

ioctl et posix_devctl

La fonction ioctl existe depuis le début de UNIX et permet de réaliser des opérations spéciales sur les descripteurs de fichiers (tout ce qui n’est pas une simple lecture ou écriture). En particulier, elle est beaucoup utilisée pour les pilotes de périphériques qui exposent une interface sous forme de fichiers dans /dev.

L’existence de cette fonction était demandée dans la spécification POSIX, mais son fonctionnement n’était pas documenté à l’exception de quelques cas particuliers. La documentation spécifie une fonction avec un nombre d’arguments variable : un numéro de descripteur de fichier, un identifiant de l’opération à effectuer, puis des paramètres qui dépendent de l’opération. On trouve des opérations avec aucun, un, ou deux paramètres.

Dans UNIX et la plupart de ses dérivés, la liste des opérations possibles est définie à l’avance, et le format des numéros identifiants permet de déterminer de façon prédictible quel est le nombre de paramètres attendus. Ce n’est pas le cas dans Haiku : les pilotes de périphériques ont le choix d’assigner n’importe quelle valeur à n’importe quelle opération, et la même valeur numérique peut donc avoir une signification différente selon le type de fichier.

L’opération ioctl est donc en réalité implémentée avec toujours 4 arguments pour Haiku : en plus des deux déjà mentionnés, il faut ajouter un pointeur vers une zone de mémoire, et un entier indiquant la taille de cette zone. Des acrobaties à base de macros permettent de remplir ces deux paramètres avec des valeurs par défaut lorsqu’ils ne sont pas nécessaires (au moins pour les programmes écrits en C ; en C++, ces deux paramètres sont simplement déclarés avec une valeur par défaut).

Heureusement, ces problèmes avec ioctl vont être résolus, puisque POSIX a introduit une nouvelle fonction en remplacement : posix_devctl. Celle-ci fonctionne comme l’implémentation de ioctl dans Haiku, mais les arguments doivent toujours être spécifiés explicitement. Cela va donc permettre de disposer d’une interface réellement portable pour ces opérations.

Kernel

Correction de la taille du tampon mémoire par défaut de la classe KPath qui permet au noyau de manipuler des chemins dans le système de fichiers (waddlesplash).

VFS

Le VFS (virtual filesystem) est l’interface entre les appels systèmes d’accès aux fichiers (open, read, write…) et les systèmes de fichiers proprement dit. En plus de ce travail d’interfaçage (par exemple : convertir un chemin de fichier absolu en chemin relatif à un point de montage), cette couche regroupe un ensemble de fonctionnalités qui n’ont pas besoin d’être réimplémentées par chaque système de fichier: vérification des permissions, mémoire cache pour limiter les accès au disque.

Si les systèmes de fichiers identifient chaque objet par un inode (en général lié à la position de l’objet sur le disque ou dans la partition de stockage), le VFS travaille lui avec des vnode qui existent uniquement en RAM et sont alloués dynamiquement pour les fichiers en cours d’utilisation.

D’autre part, les systèmes de fichiers peuvent se reposer sur un cache de blocs. Ce dernier se trouve plutôt à l’interface entre un système de fichier et le support de stockage correspondant, puisqu’il fonctionne au niveau des blocs de données stockées sur disque. Mais son intégration avec le VFS est nécessaire pour savoir quels sont les fichiers en cours d’utilisation et les opérations prévisibles sur chacun (par exemple, il est utile de pré-charger la suite d’un fichier lorsque un programme demande à en lire le début, car il est probable que ces informations vont bientôt être nécessaires).

Le VFS est donc un élément central en particulier pour obtenir de bonnes performances sur les accès aux fichiers, en minimisant les accès aux vrais systèmes de fichiers qui doivent maintenir beaucoup d’informations à jour sur les disques. Tout ce qui peut être traité en utilisant uniquement la RAM grâce à la mise en cache est beaucoup plus rapide.

Investigation et amélioration des performances de la commande git status qui prenait beaucoup plus de temps à s’exécuter que sur d’autres systèmes (waddlesplash):

• Meilleure gestion des vnodes inutilisés à l’aide d’une liste chaînée 'inline' protégée par un spinlock, à la place d’un mutex peu performant dans ce code très fréquemment appelé.
• Modification de la structure io_context pour utiliser un verrou en lecture-écriture (permettant plusieurs accès concurrents en lecture, mais un seul en modification).
• Ajout d’un chemin rapide dans le cas le plus simple de la recherche de vnode.

Avec ces changements, les performances sont améliorées au moins lorsque les données nécessaires sont déjà disponibles dans le cache disque.

Nettoyage et corrections dans les fonctions d’entrées-sorties vectorisées et asynchrones do_iterative_fd_io et do_fd_io utilisées par les systèmes de fichiers: meilleure gestion des références et prise en compte de certains cas particuliers. Cela permet de simplifier un peu le code de pré-remplissage du cache de blocs (waddlesplash).

La prise en compte des drapeaux O_RDONLY|O_TRUNC lors de l’ouverture d’un fichier est maintenant faite directement dans le VFS, il n’est plus nécessaire de transmettre la requête au système de fichier. Cette combinaison de drapeaux est un comportement indéfini dans POSIX, et supprime le contenu du fichier dans Linux. Dans Haiku, elle remonte une erreur.

Correction du comportement de l’ouverture d’un symlink invalide (ne pointant pas sur un fichier) avec le flag O_CREAT.

Le parser de requêtes pouvait essayer de lire des données invalides (la taille de clé d’un index inexistant) dans certains cas particuliers.

Nettoyage de logs dans tous les systèmes de fichiers qui affichaient un message lors de chaque tentative d’identification. On avait donc un message de chaque système de fichier pour chaque partition. Maintenant, le cas le plus courant (le système de fichier ne reconnaît pas du tout la partition) ne déclenche plus de logs.

Correction d’une erreur dans userlandfs sur la fonction file_cache_read pour les tentatives d’accès après la fin d’un fichier (cas particulier nécessaire pour implémenter correctement mmap).

Correction d’une mauvaise gestion du errno dans le cache de blocs, qui pouvait aboutir à un kernel panic.

Diverses améliorations, nettoyages et corrections de fuites mémoire: dans la gestion des fichiers montés comme image disques, dans les entrées-sorties asynchrones, dans l’enregistreur d’évènements scheduling recorder.

Console et affichage

Unification du code d’affichage du splash screen (par le bootloader) et des icônes de la séquence de démarrage (par le kernel) pour éviter qu’ils prennent des décisions différentes sur le positionnement (par exemple si l’un est compilé pour afficher le logo de Haiku, et l’autre en version « dégriffée » sans ce logo qui est une marque déposée) (waddlesplash).

Initialisation de la console framebuffer beaucoup plus tôt dans le démarrage du noyau, ce qui permet d’afficher un message à l’écran en cas de kernel panic y compris dans les premières étapes du démarrage (par exemple, l’initialisation de la mémoire virtuelle). Auparavant, ces informations étaient disponibles uniquement dans le syslog (inaccessible si le système ne démarre pas) ou via un port série (en voie de disparition sur les machines modernes) (waddlesplash).

Réseau

Remontée des données annexes (ancillary data) en une seule fois lorsque c’est possible. Ces données sont utilisées en particulier dans les sockets de domaine AF_UNIX pour permettre d’échanger des descripteurs de fichiers entre processus. Ce regroupement de données n’est pas exigé par la spécification POSIX, mais c’est le comportement attendu par le code de communication interprocessus de Firefox et de Chromium (ils utilisent tous les deux le même code) (waddlesplash).

Gestion de la mémoire

Comme indiqué plus haut dans la dépêche, l’apparition du navigateur Iceweasel a mis en évidence de nombreux problèmes autour de la gestion de la mémoire. Cela a donc été l’objet d’un gros travail de stabilisation et d’amélioration.

• Le cache d’objets du noyau pouvait parfois ignorer le paramètre indiquant la réserve minimum d’objets devant toujours être disponibles (waddlesplash)
• Amélioration de l’implémentation de la famille de fonctions autour de mprotect, qui permettent une gestion fine et bas niveau de la mémoire. En particulier, plusieurs problèmes se posaient lors de l’utilisation de ces fonctions lors d’un appel à fork, les deux processus se retrouvant dans un état incohérent,
• Suppression de logs présents dans les méthodes de défaut de page, qui sont peu appelées pour les applications classiques, mais exploitées volontairement par d’autres applications (machines virtuelles Java ou Javascript par exemple). Les logs étaient donc superflus dans ce cas (waddlesplash),
• Optimisation de l’écriture par lot de plusieurs pages de mémoire vers le swap,
• Meilleure gestion des permissions d’accès page par page,
• Correction de plusieurs problèmes conduisant à un blocage ou fort ralentissement du système quand il n’y a plus assez de mémoire libre,
• Amélioration de la stratégie d’allocation de la table des descripteurs de fichiers,
• Regroupement de code dupliqué pour chaque plateforme qui était en fait générique.

Ce travail se poursuit avec un remplacement de l’allocateur mémoire actuel, qui est basé sur hoard2. Cette implémentation est assez ancienne et montre aujourd’hui ses limites. Des essais sont en cours avec l’implémentation de malloc d’OpenBSD, ainsi qu’avec mimalloc de Microsoft, pour déterminer lequel des deux sera utilisé. D’autres allocateurs ont été rejetés, car ils ne répondent pas au besoin de Haiku, en particulier la possibilité de fonctionner efficacement sur un système 32 bits ou l’espace d’adressage est une ressource limitée.

Autres

Sécurisation des permissions sur les zones mémoire partagées: une application ne peut pas ajouter des permissions en écriture aux zones mémoire d’une autre application. Une application qui n’est pas lancée par l’utilisateur root ne peut pas inspecter la mémoire d’une application lancée par l’utilisateur root. Ajout toutefois de cas particuliers pour permettre au Debugger de faire son travail (il a besoin d’accéder à la mémoire d’autres applications).

Ajout et amélioration de commandes dans le debugger noyau pour investiguer l’état de l’ordonnanceur d’entrées-sorties, qui se charge de programmer les accès disque dans un ordre le plus efficace possible (waddlesplash).

La fonction vfork n’appelle plus les fonctions pre-fork. Haiku n’implémente pas complètement vfork, mais peut se permettre des optimisations sur le travail qu’un duo fork + exec classique demanderait normalement.

La configuration de la randomization de l’espace mémoire (ASLR) est maintenant faite par la libroot et pas par le noyau. Ainsi une application peut utiliser une version différente de la libroot pour avoir une politique de randomization différente.

Optimisation de l’accès par un thread à sa propre structure Thread

Chargeur de démarrage

L’écran de démarrage s’affiche correctement sur les systèmes EFI utilisant un mode écran avec une profondeur de couleur 16 bits (korli).

Affichage de la taille des partitions démarrables dans le menu de démarrage, pour faciliter leur identification (waddlesplash).

Activation des warnings du compilateur sur les chaînes printf invalides.

Augmentation de la zone de mémoire utilisée pour la décompression de l’archive de démarrage lors du boot sur le réseau, l’archive était devenue trop grosse suite à l’ajout de nouveaux pilotes.

Refactorisation du code de gestion de la mémoire entre le bootloader et le runtime_loader, ajout de tests pour cette implémentation, et optimisation de l’utilisation mémoire du bootloader.

Amélioration du comportement si le device tree définit un port série sans spécifier de baudrate: le bootloader suppose que le baudrate est déjà configuré, et utilise le port sans essayer de le réinitialiser.

Outils de compilation

La compilation de Haiku est un processus relativement complexe: il faut utiliser deux compilateurs pour Haiku lui-même (un gcc récent plus une version plus ancienne pour assurer la compatibilité avec BeOS) ainsi que un compilateur pour le systême hôte de la compilation (qui peut être Linux, BSD, Mac OS ou Windows) pour générer des outils nécessaires à la compilation elle-même. L’outil retenu est Jam, une alternative à Make avec une meilleure gestion des règles génériques réutilisables.

• Ajout de vérification pour éviter d’avoir un build partiellement configuré, avec des ConfigVars définies mais vides.
• Retrait d’un warning incorrect dans l’outil de build jam si on spécifie à la fois un profil et une cible de compilation sur la ligne de commande.
• Reconnaissance des processeurs hôtes ARM et RISC-V pour la compilation croisée, correction d’autres problèmes avec les architectures non-x86.
• Ajout de dépendances manquantes dans les règles de compilation de packagefs.
• Suppression de fichiers de licence fournis avec Haiku mais concernant du code qui avait été supprimé de Haiku auparavant.
• Amélioration de la remontée d’erreur du script configure si un interpréteur Python n’a pas été trouvé.
• Correction de messages d’avertissement de awk pour l’utilisation de fonctions qui n’existent plus dans le traitement des fichiers d’identifiants matériels USB et PCI.

Documentation

Documentation interne

Ajout de documentation sur les détails d’implémentation de ioctl et posix_devctl et les spécificités de Haiku pour la première (PulkoMandy).

Correction de fautes de frappe dans l’introduction au launch_daemon.

Remplacement de toutes les références à "OpenBeOS" par "Haiku".

Documentation d’API

Ajout de documentation pour les méthodes GetFontAndColor et SetFontAndColor de BTextView.

Ajout de documentation pour les classes BShelf et BGameSound.

Réorganisation de la liste des caractères de contrôles dans la documentation du clavier, ajout d’entrées manquantes dans cette liste et ajoute de commentaires indiquant à quelles combinaisons de touches ces caractères sont normalement associés.

Traductions de Haiku

La traduction du système dans différentes langues est un facteur important d’inclusivité et d’accessibilité (même si la communication avec l’équipe de développeurs pour le support n’est pas toujours simple).

Haiku est disponible dans 30 langues, la trentième étant le coréen, pour lequel il y a un nouveau responsable des traductions (le précédent avait cessé toute activité et laissé la traduction inachevée).

Haiku recherche des volontaires pour s’occuper des traductions en biélorusse, croate, bulgare, hindi, punjabi et slovène, pour lesquelles les précédents responsables de relectures n’ont plus le temps d’assurer le rôle. Ainsi bien sûr que de l’aide pour la traduction du système, du manuel d’utilisation, et des applications tierces, que ce soit pour ajouter de nouvelles langues ou pour renforcer les équipes s’occupant de langues existantes. Le point d’entrée est le portail d’internationalisation de Haiku.

La traduction du système Haiku s’effectue avec Pootle. L’outil n’est plus développé et des investigations sont en cours pour le remplacer par Weblate. La traduction du manuel d’utilisation s’effectue avec [un outil spécifiquement développé pour cela](https://github.com/haiku/userguide-translator. La traduction des applications s’effectue également avec un outil personnalisé nommé Polyglot.

Traditionnelle période de vœux lors du changement d’année. Voyons ce qui devrait… changera… pourrait éventuellement changer ou non. Donc revenons cette année encore sur nos accomplissements passés et futurs et de ce que nous aimerions voir plus sur notre site préféré.

Cinq personnes se sont prêtées au jeu de cette dépêche pas vraiment de vœux, mais un peu quand même. En vrac dans les accomplissements : hurl, cadran solaire, programmes électoraux, Amstrad CPC, financement européen, Haiku, CV, Transimpressux, visualisation scientifique, XMPP, commentaires de code, docker, menstruation, vélo, documentation, éditeur pixel art, assembleur, OSXP, Smalltalk. L’année qui vient, sur LinuxFr.org, promet d’être (fe)diverse, événementielle, ferroviaire, bureautique, réparable, un peu rouillée, résolue et motivée.

Sommaire

• Benoît Oumph Sibaud
  • Accomplissements, réalisations, progrès de l’année 2024
  • Ce que je voudrais faire, apprendre ou approfondir en 2025
  • Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)
• Ysabeau
  • Accomplissements, réalisations, progrès de l’année 2024
  • Ce que je voudrais faire, apprendre ou approfondir en 2025
  • Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)
• vmagnin
  • Accomplissements, réalisations, progrès de l’année 2024
  • Ce que je voudrais faire, apprendre ou approfondir en 2025
  • Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)
• gUI
  • Ce que je voudrais faire, apprendre ou approfondir en 2025
• PulkoMandy
  • Accomplissements, réalisations, progrès de l’année 2024
  • Ce que je voudrais faire, apprendre ou approfondir en 2025
  • Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)
• Pour finir

Benoît Oumph Sibaud

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

Le retard côté adminsys pour LinuxFr.org se réduit, de même pour celui sur le code (évidemment ça ne va jamais assez vite, c’est le principe) (voir les dépêches sur nos services img et epub). J’ai eu l’occasion de jouer un peu avec Hurl pour des tests HTTP (voir les dépêches précédemment mentionnées et celle sur Hurl 6.0.0) et docker et docker compose, en plus de faire un peu de Go. J’ai pu de nouveau être présent pour le stand et les animations sur place lors de la conférence Open Source eXPerience Paris et c’était bien de revoir d’autres personnes de l’équipe, de notre lectorat, des libristes connus de longue date et des nouvelles personnes (et de goûter la bière de nos 25 ans aussi). Le 28 juin 2024, la politique de minimisation des données mise en place un an plus tôt (pour les 25 ans du site) s’est appliquée pour les comptes déjà fermés préalablement (prochaine étape en juin 2026).

Je suis aussi content de ma dépêche sur le contenu programmatique lors des élections européennes de juin. Je mentionnerais aussi dans les sujets importants la question du programme de financement européen Next Generation Internet (NGI) et la dépêche sur le décès de lunar, un hacktiviste pédagogue.

Ce que je voudrais faire, apprendre ou approfondir en 2025

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

Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)

Je peux reprendre in extenso mon propos de l’année dernière : je serais intéressé d’avoir plus de contenus (idéalement des dépêches) sur la réparation et la réutilisation, sur de l’informatique sobre, sur des sujets qui ne me viendraient pas à l’idée (sérendipité), sur les politiques autour du numérique et des données, sur des retours d’expérience et sur les sujets qui vous passionnent vous.

Ysabeau

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

Quelque chose dont je suis plutôt franchement fière c’est d’avoir parlé d’un sujet typiquement féminin sur LinuxFr.org tout en restant parfaitement dans le thème du site et celui de la Journée internationale des droits des femmes. Le dessin de l’illustration, qui met les points sur les « i » m’a beaucoup amusé. La qualité de l’accueil de la dépêche sur LinuxFr.org et ailleurs m’a ravie. Dans la série réalisations : les portraits que j’ai faits, quelque chose que j’entends continuer, ont été une grande source de connaissances en ce qui me concerne. Pour finir le modèle-tutoriel de CV – Fiche de candidature qui me trottait dans la tête depuis un certain temps.

Concernant les progrès : je pense avoir atteint, en matière d’EPUB, le niveau pour mes besoins. Un jour il faudra que je fasse une dépêche sur ce sujet et sur Sigil. Et j’ai bien progressé avec Inkscape, et même en XML hourra !

Ce que je voudrais faire, apprendre ou approfondir en 2025

Je n’ai pas fini la série Transimpressux, je vais continuer à travailler dessus. En 2024, j’avais aussi pour objectif, désir, de me pencher sur l’informatique et le handicap, l’exploration de l’espace, entre autres sujet, m’en a éloignée. À voir si j’arrive cette année à mieux explorer le terrain. J’ai aussi dans l’idée de rédiger quelque chose sur l’art la manière de faire des modèles pour LibreOffice et le site des extensions de LibreOffice. Parce que ce n’est pas si évident. Peut-être même, si je trouve comment faire, transformer en extension certaines de mes séries de modèles.

Quoi d’autre ? Ah oui et faire des modèles de jouets et miniatures (pour maisons de poupée par exemple) pour Draw et Inkscape qui pourraient être faits soit en imprimant le modèle sur papier et en utilisant des matériaux de récupération (cartons divers) pour la réalisation, soit en utilisant un graveur (découpeur ?) laser. Améliorer peut-être ma connaissance du XML et finir de lire les spécifications de l’ODF peut-être.

Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)

Comme pour l’année dernière, j’aimerais qu’on explore plus les questions de réparabilité très concrètement et sur les plans techniques et juridiques. Il y a aussi la question du handicap et de l’informatique qui mérite d’être plus mise en avant. Et plus de tutoriels.

vmagnin

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

J’ai publié en mars 2024, avec mon coauteur Ali, une bibliothèque en Fortran orienté objet nommée ForColormap qui propose des palettes de couleurs pour la visualisation scientifique. Côté hobbys, j’ai bien progressé dans mes projets musicaux ForMIDI et ForSynth (qui génère des WAV), avec à nouveau l’introduction de l’orienté objet. C’est une façon d’étudier la musique : programmer c’est comprendre. J’ai aussi avancé sur mon projet de cadran solaire ForSundial, le seul que j’ai hébergé pour l’instant sur Codeberg. J’espère avoir le temps un jour d’aller au-delà du prototype en peuplier (il paraît que la découpe laser peut graver du marbre). Ah oui, je me suis aussi acheté une carte Greaseweazle 4.1 pour récupérer le contenu de disquettes des années 80 (en particulier au format Atari ST, non lisible sur PC), mais je n’ai toujours pas eu le temps de faire ce que je voulais. Chacun de ces points pourrait faire l’objet d’un journal, mais le temps, c’est ça le problème…

Sur LinuxFr.org, je n’ai publié que ma dépêche pseudo-périodique « Des nouvelles de Fortran n°6 » pour Noël, ainsi que deux journaux, dont un long qui est la suite de celui de novembre 2021 sur le pulsar iconique CP 1919 et qui parle de beaucoup de choses : histoire de l’informatique, musique électronique, plongée dans les décennies 70 et 80 et ce qu’elles ont à nous dire sur le monde d’aujourd’hui (similarités et différences), etc.

Mais j’ai en fait aussi participé plus ou moins à d’autres dépêches qui m’intéressaient : relecture, discussion ou rédaction. C’est sympa à faire et c’est un peu comme y avoir accès en avant-première. N’hésitez pas à franchir le pas (onglet Rédaction) si ce n’est déjà fait.

Ce que je voudrais faire, apprendre ou approfondir en 2025

Je commence à apprendre le Rust, non pas tellement parce que j’en aurais un quelconque besoin côté professionnel ou côté hobby, mais avant tout pour étudier de nouveaux (pour moi) concepts comme les génériques, les traits, les motifs, la possession et la durée de vie, les fermetures, etc. J’ai emprunté un bon livre : Développez avec Rust traduit récemment chez Dunod. La dernière fois que j’avais vraiment été excité d’apprendre un nouveau langage, c’était avec Python il y a quinze ans (et les expressions régulières en même temps). Après le serpent, je prendrais bien un peu de crabe…

Sinon, j’aimerais bien avoir le temps de faire en 2025 ce que je n’ai pas eu le temps de faire en 2024 :-) Mais j’ai peut-être tort, je devrais peut-être vouloir faire moins de choses pour avoir plus de temps… à ne rien faire (en plus c’est écologique). Être idle.

Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)

Donc des journaux ou dépêches sur Rust :-) J’aime bien aussi ce qui concerne l’histoire de l’informatique, et ce qui sort des clous comme l’histoire des sciences, les arts, en particulier la musique, etc. L’informatique étant quasiment partout, on trouve facilement un prétexte pour parler de n’importe quoi… On pourrait publier des critiques de livres autour de l’informatique ou de la science et la technologie, et pourquoi pas de films ou autres œuvres. Enfin, des bricolages en FabLab peuvent être intéressants.

gUI

Une version très raccourcie pour moi, je voudrais me concentrer particulièrement sur une chose cette année :

Ce que je voudrais faire, apprendre ou approfondir en 2025

De la documentation !

Plusieurs points dans ce sens :

• Améliorer mes commentaires (j’y documente déjà tous les pièges à cons, mais je continue d’avoir du mal à me comprendre quand je déterre des vieux bouts de code)
• Améliorer mes notes perso : aujourd’hui j’utilise nb pour ça. C’est pas mal, mais c’est un peu le foutoir, c’est pas centralisé, bref… peut mieux faire
• Améliorer la doc de mon infra domestique : oui en bon vieux gros Geek c’est pas simple chez moi. Alors déjà quand je dois remettre les mains sur un truc qui tourne sans soucis depuis des années j’ai des gouttes de sueurs, je n’ose imaginer s’il m’arrive quelque chose (eh oui, soyons prévoyants) comment ma famille (pourtant pas des manches) va s’en sortir.
• Quelques autres projets de doc un poil hors-sujet ici (livret d’accueil dans mon association sportive par exemple)

PulkoMandy

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

J’ai continué à travailler sur l’adaptation de vbcc et vasm pour la console de jeux VTech V. Smile. L’assembleur et le compilateur C sont fonctionnels et on peut compiler le système d’exploitation Contiki avec. Le code généré n’est pas du tout optimisé pour l’instant.

J’ai un peu avancé sur mon interpréteur pour les fictions interactives du jeu Lectures Enjeu mais il y a des fonctionnements que je n’arrive pas à comprendre: si je fais fonctionner un jeu, j’en casse un autre :(

J’ai publié une nouvelle version de l’éditeur pixel art GrafX2, il n’y en avait pas eu depuis 2021. Je ne fais plus grand-chose pour ce projet, je pense que le logiciel est assez complet.

Je continue bien sûr à travailler pour Haiku: entre autres sur les dépêches Linuxfr, le navigateur web WebPositive, et le client XMPP Renga. Je n’ai jamais le temps et la motivation de participer autant que je le voudrais.

Enfin, j’ai entrepris la réalisation d'un interpréteur Smalltalk pour Amstrad CPC. Il fonctionne, mais il est beaucoup trop lent.

Et comme il n’y a pas que l’informatique dans la vie, j’ai traversé la France en vélo pour me rendre de Toulouse à Avranches, soit environ 900km en une douzaine de jours. J’ai eu plus de problèmes au retour en train qu’à l’aller en vélo.

Ce que je voudrais faire, apprendre ou approfondir en 2025

Du côté des problèmes techniques: le système de sauvegarde externe de mon serveur auto hébergé est cassé. Il faut que j’investigue les scripts perl fournis par le service de sauvegarde que j’ai choisi (qui a l’avantage d’être vraiment pas cher, et les inconvénients qui vont avec).

Je vais sûrement continuer à travailler sur les projets mentionnés ci-dessus (et quelques autres) et essayer de ne pas en commencer de nouveaux avant d’avoir fini quelque chose. J’ai beaucoup d’idées mais pas le temps pour tout faire.

Je vais essayer de lire les livres que j’ai gagnés grâce à mes contributions à LinuxFr.org et que je n’ai pas tous eu le temps d’ouvrir :(

Je vais également essayer de faire du vélo plus régulièrement, ces derniers temps la motivation m’a beaucoup manqué pour ça.

Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)

J’aimerais lire des choses sur d’autres systèmes d’exploitation: Linux, BSD, mais aussi Serenity, ReactOS ou Redox OS et sûrement plein d’autres dont je n’ai pas entendu parler.

(mais ce serait en plus des contenus existants sur plein de sujets, et des débats dans les commentaires, qui sont passionnants).

Pour finir

Nous vous souhaitons tout de même la meilleure année possible (on oscille entre être rebelles et conformistes). Et, bien évidemment, n’hésitez pas à « continuer » cette dépêche dans les commentaires.

Et un merci à toutes celles et ceux qui font de LinuxFr.org un site enrichi en sérendipité et surprises.

La dernière dépêche annuelle sur les nouveautés dans Haiku a dépassé la longueur maximale tolérée par Linuxfr (et été finalement découpée en plusieurs parties publiées séparément). Aussi, les nouveautés sur Haiku seront désormais publiées trimestriellement, pour faire face à l’augmentation d’activité dans le projet.

Sommaire

• Applications
  • Améliorations du mode sombre
  • AboutSystem
  • Débogueur
  • DriveSetup
  • HaikuDepot
  • Horloge
  • Tracker
  • Terminal
  • PowerStatus
• Outils en ligne de commande
• Serveurs
  • app_server
  • media_server
  • registrar
  • input_server
  • net_server
  • package_daemon
• Kits
  • Interface
  • Media
  • Locale
  • Support
• Pilotes de périphériques
  • Processeurs et économie d’énergie
  • Réseau
    • virtio_net
    • broadcom750x
    •  vmxnet
    •  Couches de compatibilité BSD
    •  TCP
    •  Ethernet
    •  UNIX domain sockets
  • USB
  • PCI
  • Périphériques de stockage
  • ACPI
  • Graphiques
  • virtio
  • PS/2
• Systèmes de fichiers
  • ram_disk et ramfs
  • packagefs
  • FAT
  • BFS
  • Query parser
  • block_cache
• kernel
  • VFS
  • Gestion de la mémoire
• libroot
  • libnetwork
  • Compatibilité POSIX
• runtime_loader
• Outils de debug
• Bootloader
• Documentation
  • Haiku Book
  • Haiku Interface Guidelines
  • Wiki et documentation interne
• Système de build, environnement de compilation
• ARM & PowerPC

Ce rapport est basé sur les rapports mensuels d’activité d’août, septembre et octobre publiés sur le site de Haiku. Il couvre les changements de code survenus entre hrev57901 et hrev58291 de Haiku.

Certains des changements mentionnés dans ce rapport font partie des derniers développements du mois d'août, et étaient déjà présents dans la version R1 bêta 5 qui a été publiée début septembre 2024.

Les corrections de bugs sont appliquées sur la branche bêta 5 si elle est concernée, mais les nouveaux développements sont mis dans la branche principale et seront disponibles uniquement dans les « nighlty builds » (constructions journalières) puis dans la prochaine version, qui sera probablement étiquetée R1 bêta 6.

La version R1 est très attendue, mais la feuille de route comporte toujours environ 600 bugs et demandes d’amélioration. Jusqu’à ce qu’ils soient tous traités (corrigés, devenus obsolètes ou déplacés vers une version plus tardive), Haiku continue de publier des versions bêta.

Applications

Amélioration et corrections de textes de messages dans diverses applications (humdinger).

L’application Switcher — permettant de naviguer rapidement entre les différentes fenêtres et applications à l’aide d’un menu qui apparaît lorsque la souris se trouve sur les bords de l’écran — peut à nouveau être compilée. Cette application n’est pas terminée et non intégrée dans Haiku par défaut pour l’instant (nephele).

Dans les préférences de disposition clavier, des icônes avaient disparu de certains menus suite à un problème dans une modification précédente. Ces icônes sont maintenant de retour (jscipione).

Les réglages de polices de caractères de WebPositive peuvent faire des retours à la ligne dans le texte d’exemple utilisé pour visualiser la police choisie (correction récupérée depuis la fenêtre de réglage des polices du système, qui utilise une variante du même code). (nipos).

Le raccourci clavier « muet » permet d’alterner entre l’activation et la désactivation du son, au lieu de toujours passer en mode muet (korli).

Plusieurs applications pouvaient ouvrir leurs fenêtres en dehors de l’écran si leur dernière position enregistrée n’était pas bonne (après un changement de résolution d’écran par exemple). L’appel de la fonction MoveOnScreen() après la création d’une fenêtre permet de régler ce problème (korli, pinaraf, waddlesplash).

Icon-O-Matic ouvre ses dialogues de sélection de fichiers dans le dossier où se trouve l’icône en cours d’édition (nipos).

Il est possible de sélectionner une famille de polices directement dans FontDemo (nipos).

Améliorations du mode sombre

Modifications faites par nipos et nephele.

Depuis la version bêta 5 de Haiku, il est beaucoup plus simple de configurer un thème de couleurs dans Haiku (avec seulement 3 couleurs à sélectionner, les autres étant calculées automatiquement).

Cependant, toutes les applications et contrôles graphiques ne se comportent pas forcément très bien, en particulier si on choisit une couleur de fond de fenêtres sombre. Ce trimestre, on trouve donc des améliorations sur ColumnListView (contrôle permettant l’affichage de données en listes, en arbre et en colonnes), et dans les applications Debugger, Mail (en particulier les marqueurs de portions de message citées), WebPositive, ResEdit, FontDemo, Cortex, Sudoku et Tracker (les fenêtres de configuration des permissions de fichiers et de statut de copie de fichiers), ainsi que dans les préférences de disposition clavier (couleur des touches de clavier affichées), et de configuration des écrans et des écrans de veille. Ces applications utilisaient encore quelques couleurs codées « en dur » qui ne s’adaptaient pas automatiquement au thème choisi.

En outre, les formules de calcul utilisées pour générer le thème de couleurs ont été améliorées pour donner de meilleurs résultats dans le cas de couleurs sombres, assurant de conserver un bon contraste entre tous les éléments graphiques et une meilleure cohérence des couleurs.

AboutSystem

L’application AboutSystem donne quelques informations sur la machine (RAM, CPU), et surtout affiche les noms des développeurs et les messages de copyright et clauses de licences obligatoires de logiciels libres qui sont embarqués dans Haiku.

Correction d’un crash à cause d’une information de copyright mal enregistrée (madmax).

Mise à jour des crédits à l’occasion de la version Beta 5 : ajout des nouveaux membres de l’équipe, et passage dans la catégorie « anciens développeurs » de certaines personnes qui ne participent plus pour l’instant. (waddlesplash).

Débogueur

Haiku est fourni avec un débogueur graphique permettant d’investiguer facilement les problèmes dans les applications.

Waddlesplash a amélioré le désassembleur pour mieux décoder les adresses mémoire calculées à partir de la valeur d’un registre CPU. La correction a été remontée dans la bibliothèque tierce Zydis, utilisée pour le désassemblage.

Il a également modifié le code du Debugger pour ne pas essayer de télécharger des informations de debug lorsque l’outil est lancé en mode non-interactif (dans le cas d’une test suite automatisée par exemple). Plusieurs autres problèmes qui pouvaient causer un plantage du debugger ou un blocage dans un état invalide (avec l’application qui ne s’arrête jamais) ont été également traités.

DriveSetup

L’outil DriveSetup permet de modifier la table de partitions et de formater les partitions avec différents systèmes de fichiers.

Pour les partitions de type « Intel » (MBR), lorsqu’on crée une première partition, par défaut elle est marquée automatiquement comme partition active. Auparavant il fallait cocher une case pour cela, et de nombreux utilisateurs oubliaient de le faire, ce qui pouvait rendre le système impossible à démarrer (korli).

Dans certains messages, le nom des partitions n’était pas mis entre guillemets, ce qui pouvait prêter à confusion avec des noms de partitions choisis maladroitement (ou judicieusement, selon de quel point de vue on se place). Maintenant le nom de la partition est clairement identifiable dans le message (humdinger).

HaikuDepot

HaikuDepot est le frontal graphique du gestionnaire de paquets de Haiku. L’application est maintenue par apl et se compose d’une interface graphique native développée en C++ et d’un webservice développé en Java qui permet de stocker des métadonnées supplémentaires sur les paquets : captures d’écrans, notes et revues des utilisateurs, liste des paquets à mettre en avant.

• Refactoring du « language model », de la gestion des chemins, de la récupération des données des paquets, de l’affichage des auteurs de paquets, de la gestion des notes données par les utilisateurs. (apl)
• Fenêtre des conditions d’utilisation: correction de la couleur du texte, correction d’un crash si on clique dans la fenêtre avant que le texte soit chargé. (apl et jscipione)
• Le bouton « Ouvrir » permettant de lancer une application installée ne fonctionnait pas toujours (apl).
• Amélioration de la sélection d’un icône par défaut pour les paquets qui n’ont pas d’icône inclus (apl).

La liste de paquets mis en avant a été revue, un nouveau mainteneur (Michel) se charge de la tenir à jour avec des règles mieux définies : une sélection d’applications populaires (sur suggestion de participants aux forums de discussion) ainsi que des applications mises à jour récemment. Si vous utilisez Haiku, n’hésitez pas à passer un peu de temps à évaluer et noter les applications, peu de personnes le font et il est difficile d’exploiter les données de façon pertinente si beaucoup d’applications n’ont reçu qu’un seul vote.

Horloge

L’application horloge permet d’afficher l’heure (sans surprise). Elle propose diverses apparences de cadrans, peut être redimensionnée, et incrustée dans le bureau sous forme d’un replicant.

Un bug dans l’application conduisait à afficher une heure aléatoire (non initialisée) pendant quelques centièmes de secondes au démarrage avant de commencer à afficher l’heure courante (OscarL)

Les aiguilles de l’horloge étaient décalées de quelques pixels et ne pointaient pas précisément là ou elles devraient (dovsienko).

Tracker

Tracker est le gestionnaire de fichiers de Haiku. Il affiche le bureau et toutes les fenêtres de navigation et de recherche de fichiers. Il se distingue par son utilisation de la navigation dite « spatiale », où chaque dossier s’ouvre dans une fenêtre séparée dont la taille et la position à l’écran sont mémorisées.

jscipione continue son travail d’amélioration du Tracker (cela comporte de nombreux changements qui sont encore en gestation). Ce trimestre, les changements intégrés permettent :

• la désactivation d’entrées du menu « Nouveau » lorsque les opérations ne sont pas disponibles,
• la mise à jour dynamique de certains menus en fonction des opérations disponibles,
• la préservation de la sélection après une opération de copie où de déplacement (avec quelques problèmes d’affichage corrigés au passage),
• des corrections de bug sur le choix de couleurs utilisées dans la fenêtre « Ouvrir avec »,
• la possibilité de créer un lien symbolique lorsqu’on fait un drag and drop depuis un dossier virtuel,
• utilisation de la police de caractères « menu » de façon cohérente dans tous les menus.

Il a également travaillé sur des tâches de fond, sans changements visibles pour l’instant. Le code du Tracker provient de BeOS et est un peu vieillissant. Il est souvent nécessaire de faire beaucoup de nettoyage avant de pouvoir développer de nouvelles fonctionnalités sans casser autre chose. Cette fois-ci, on trouve entre autres une refonte de la gestion des raccourcis claviers, la fermeture automatique des fenêtres en double lors du passage en mode « navigation spatiale », et divers crashs liés à la gestion des menus popup.

humdinger a également travaillé sur le Tracker pour améliorer certains messages concernant la copie et la création de fichiers, pour les rendre plus faciles à traduire.

humdinger a également travaillé sur l’organisation du menu « templates » (affiché quand on fait un clic droit -> nouveau… et permettant de créer différents types de fichiers à partir de fichiers de référence). Ce menu peut maintenant être organisé en plusieurs sous-menus à l’aide d’une nouvelle option « New template folder », pour les personnes qui utilisent cette fonctionnalité avec de nombreux fichiers de référence au point d’avoir besoin de les organiser.

La fenêtre de requêtes (recherche de fichiers en fonction de leurs attributs étendus indexés dans le système de fichiers) permet maintenant d’afficher en temps réel les résultats lorsqu’on édite une requête. En outre, il est possible de filtrer les résultats pour afficher uniquement les fichiers contenus dans un répertoire donné (auparavant, on pouvait au mieux restreindre par volume disque). Ces changements ont été réalisés dans le cadre du Google Summer of Code par CalistoMathias, avec également une participation de jscipione, humdinger et waddleplash pour finaliser le travail.

Correction d’un crash du Tracker lors de changements de résolution d’écran (OscarL).

Terminal

Le Terminal permet d’exécuter des applications en ligne de commande.

Lors du changement de la taille de texte du Terminal, ce dernier ajuste le nombre de lignes et colonnes de texte visibles, au lieu de redimensionner sa fenêtre (nipos).

Prise en compte de la séquence d’échappement ANSI pour effacer l’historique de défilement (CodeForEvolution).

PowerStatus

L’application PowerStatus affiche des informations sur les batteries pour les ordinateurs portables.
sen a effectué plusieurs améliorations pour les systèmes avec plusieurs batteries:

• Gestion de plusieurs emplacements pour batteries qui ne sont pas forcément tous utilisés,
• Meilleur calcul des alertes de batterie faible,
• Prise en compte de la déconnexion de batteries pendant le fonctionnement du système.

Outils en ligne de commande

La commande profile (qui permet d’analyser les performances d’autres applications et du système) peut maintenant afficher le nombre d’évènements qui n’ont pas pu être enregistrés par l’analyseur système (waddlesplash).

La commande package_repo update (utilisée pour mettre à jour un dépôt de paquets avec de nouveaux logiciels) peut maintenant fonctionner sans avoir accès au contenu complet des fichiers packages à inclure dans le dépôt (seuls les noms des paquets et quelques autres métadonnées sont réellement nécessaires).

La commande package_repo list dispose d’une option -f pour afficher le nom de fichiers correspondant aux paquets contenus dans un dépôt de paquets. Les fichiers peuvent ainsi être téléchargés facilement par un outil tiers. (waddlesplash)

Ces deux modifications sont utiles en particulier pour la ferme de build de HaikuPorts, qui souhaite héberger les fichiers dans des buckets S3 afin de simplifier l’infrastructure et de réduire les coûts de fonctionnement.

Amélioration du format de sortie de la commande launch_roster pour indiquer le statut des services et pas simplement leur nom (kallisti5 + waddlesplash).

Ajout dans strace du décodage des drapeaux de configurations de mutex (par exemple MUTEX_SHARED) (waddlesplash).

Serveurs

Les serveurs sont des applications fonctionnant en tâche de fond et qui implémentent une grande partie des fonctionnalités du système.

app_server

app_server est le serveur graphique qui se charge de l’affichage du bureau et des fenêtres.

madmax a travaillé sur la gestion des polices de caractères: correction de problèmes de verrouillage pour éviter des accès concurrents au gestionnaire de polices par plusieurs fils d’exécution, amélioration du traitement de l’ajout et du retrait de polices, et une optimisation pour éviter de scanner deux fois de suite les dossiers de polices au démarrage.

waddlesplash a complété ce changement en déplaçant une partie du code de gestion des polices pour éviter que d’autres parties de l’exécution soient bloquées par l’initialisation des polices, qui peut prendre beaucoup de temps (quelques secondes) au démarrage du système.

waddlesplash a corrigé un problème de calcul de délai d’expiration (probablement sans conséquence, découvert par hasard en investiguant un autre problème).

jscipione a corrigé un problème de rafraîchissement de l’affichage lorsque des fenêtres sont empilées, qui pouvait conduire à ne pas bien effacer la barre de titre dans certains cas.

Un clic simple sur le coin bas-droite de la fenêtre (coin de redimensionnement) déclenchait par erreur une minimisation de la fenêtre concernée (madmax).

media_server

Le media_server prend en charge les flux audio et vidéo et permet de router ces flux entre différentes applications ainsi que depuis et vers le matériel (cartes son, cartes d’acquisition vidéo, webcams…).

Travaux effectués par waddlesplash:

Correction de problèmes de calculs de temps dans le mixeur audio (problèmes découverts suite à l’amélioration de la détection d’erreurs dans BTimeSource, mentionné plus haut), et ajout de contrôles d’intégrité supplémentaires lors du démarrage du mixeur.

Cela corrige plusieurs bugs qui faisaient que le système n’avait pas de son au démarrage pendant un certain temps, avant que soudainement ça se mette à fonctionner.

D’autre part, des améliorations de performance sur la programmation des évènements, et des corrections de crash sur la connexion et déconnexion des nœuds média vers la sortie audio, et sur le nœud multi-audio avec certaines cartes sons qui exposent des types de contrôles invalides.

D’autres changements sont en cours pour pouvoir changer la sortie audio sans avoir besoin de redémarrer le serveur média, mais ça ne fonctionne pas encore.

registrar

Le registrar surveille quelles sont les applications déjà lancées et fournit divers services de communication entre applications, en particulier pour le presse-papier.

Ajout de vérification d’erreurs si un message de récupération du contenu du presse-papier échoue. Cela peut arriver si on a mis beaucoup de données dans le presse-papier et qu’il n’y a plus assez de mémoire disponible.

Des corrections du côté de la libbe permettent maintenant de gérer ces erreurs et de ne pas faire planter l’application concernée.

input_server

L’input_server` se charge des périphériques d’entrée (clavier, souris…)

Améliorations la validation des données des fichiers de configuration de souris, qui dans certains cas pouvaient empêcher la souris de fonctionner. Refonte de la gestion des accès concurrents à la liste des périphériques, pour supprimer des verrous inutiles et permettre les accès à la liste même si un thread de gestion d’un périphérique est bloqué. (madmax)

Les codes de touches pour la touche power et la touche \_ des claviers japonais s’étaient retrouvés assignées à des valeurs identiques (cela semble provenir tout droit de changements datant de BeOS, car ces touches non présentes sur un clavier de PC américain classiques sont assez mal documentées). La documentation a été mise à jour pour mieux expliquer quels sont les codes utilisés, et les différents pilotes (PS2, USB) ont été harmonisés pour utiliser les mêmes codes (x512 et PulkoMandy).

Le code power pourra également être utilisé par un pilote GPIO sur les machines où c’est nécessaire (souvent non compatibles PC).

net_server

Le net_server se charge de toutes les opérations liées au réseau.

mmlr a corrigé un problème dans le client DHCP, qui utilisait certaines variables sans les initialiser.

package_daemon

Le package_daemon vérifie la cohérence des paquets installés avec leurs dépendances, crée les dossiers de transactions et de sauvegarde de l’état passé du système, et se charge de lancer les scripts d’activation et de désactivation de paquets. L’accès au contenu des paquets est en revanche traité dans le noyau par le système de fichier packagefs.

Changement des couleurs des fenêtres « problèmes » et « résultats » qui apparaissent quand il y a des conflits ou d’autres problèmes de résolution de dépendances lors de l’activation des paquets (jscipione).

Kits

Les « kits » sont les composants de la bibliothèque standard de Haiku. Il s’agit principalement d’une convention de documentation et d’organisation de code source pour regrouper des fonctionnalités liées entre elles.

Interface

L’interface kit` permet l’ouverture de fenêtre et l’ajout de contrôles d’interface graphiques à l’intérieur de ces dernières.

Les objets BBitmap (permettant de stocker une image « raster ») avec le flag ACCEPT_VIEWS (permettant d’attacher une « vue" pour dessiner dans le bitmap ne sont plus automatiquement effacés. Cela permet de créer un bitmap à partir de données existantes, puis de dessiner autre chose par-dessus. Ce changement corrige un problème de compatibilité avec BeOS, et permet aussi d’utiliser cette méthode dans l’implémentation de WebKit pour Haiku (ZardShard).

Un changement précédent avait causé un problème de compatibilité d’API avec BeOS, qui déclenchait dans certains cas une récursion infinie et un crash lorsqu’on essayait de faire défiler une BListView par glisser-déplacer (par exemple dans l’application Wonderbrush). Waddlesplash a corrigé ce problème, et jscipione a également ajouté quelques améliorations sur la mise à jour des items sélectionnés lorsqu’on effectue cette opération.

Il est maintenant possible d’afficher des « checkmarks » (coche indiquant une option activée) sur les items de menus disposés en « matrice ». Habituellement les menus sont soit disposés sur une ligne, soit sur une colonne avec les items les un au-dessous des autres. Le mode « matrice » permet de s’affranchir de ces restrictions pour disposer les items librement avec du code applicatif.

Mise à jour en direct des couleurs dans les contrôles BSpinner, refonte de l’héritage des couleurs de la vue parente, et changement de la couleur de fond des boutons en mode sombre (jscipione).

Centrage vertical des dates dans BCalendarView (permettant d’afficher un calendrier) (nipos).

Factorisation de code dans BView pour l’envoi des données BShape vers app_server (x512).

La méthode de debug BPoint::PrintToStream affiche maintenant les coordonnées avec des décimales, permettant de détecter les points qui ne sont pas alignés avec la grille de pixels (ayu-ch).

Les boîtes de texte marquées comme « invalides » ont maintenant un fond rouge. La bordure rouge utilisée précédemment n’était pas assez visible (nephele).

Media

Le media kit permet aux applications de s’interfacer avec le media server, et fournit en plus une interface standardisée pour les codecs audio et vidéo.

Ajout d’assertions dans la classe BTimeSource pour empêcher les applications d’envoyer des temps avec un « drift » inférieur ou égal à 0. Le « drift" est utilisé comme multiplicateur et diviseur dans les calculs d’horloge, donc les valeurs inférieures ou égales à 0 causent des problèmes. Ceci a été mis en évidence par des corrections au niveau du noyau (voir plus loin dans la dépêche) et a ensuite permis de trouver encore d’autres problèmes en particulier dans les add-ons media (waddlesplash).

Locale

Le « locale » kit permet la traduction des applications, le formatage des nombres en fonction des préférences de chaque pays, la gestion des fuseaux horaires, et toutes les autres problématiques liées à l’internationalisation. Il s’agit principalement d’un enrobage de la bibliothèque ICU pour faciliter son utilisation avec les types natifs de Haiku.

Meilleure gestion des erreurs si la bibliothèque ICU ne peut pas être initialisée (waddlesplash).

Support

Le support kit contient diverses méthodes et classes utilitaires et génériques.

Contrôle d’intégrité des données lors de la déserialisation de BMessage (waddlesplash).

Correction d’incohérence de nommage de paramètres de fonction entre les fichiers .cpp et .h détectés par cppcheck (mt).

Pilotes de périphériques

Les pilotes sont indispensables pour assurer le fonctionnement de Haiku sur une grande variété de matériel. Certains sont développés à partir des spécifications du matériel spécifiquement pour Haiku, et d’autres ont été adaptés de travaux réalisés pour d’autres systèmes d’exploitation.

Le niveau de logging par défaut a été abaissé dans certains pilotes afin de ne pas trop polluer le journal système, en particulier:

• Suppression de messages indiquant qu’aucun matériel compatible avec le pilote n’a été détecté,
• Suppression de certains logs de debug dans les pilotes audio HDA et usb_audio.

Processeurs et économie d’énergie

Renommage du pilote intel_cstates en x86_cstates puisque les processeurs récents de chez AMD sont également pris en charge par ce pilote.

Appel à ce pilote à plus d’endroits dans le noyau pour mettre les processeurs en veille ou au ralenti quand ils ne sont pas utilisés.

Réseau

virtio_net

Le pilote virtio_net (carte réseau utilisée dans les machines virtuelles) implémente maintenant le « checksum offloading » pour les protocoles IP, TCP et UDP. En effet, dans le cas de ce pilote, les vérifications et calculs de sommes d’intégrité doivent être faits de toutes façons du côté de la machine hôte, il est donc inutile de les refaire dans la machine virtuelle.

Au passage, correction de quelques erreurs dans ce driver, et en particulier de problèmes de calcul de taille de buffers en mémoire.

broadcom750x

Utilisation des interruptions par messages (MSI) lorsque c’est nécessaire pour certaines versions du matériel (waddlesplash).

 vmxnet

Nouveau pilote porté depuis FreeBSD qui permet d’utiliser l’interface réseau paravirtualisée de VMWare (CodeForEvolution).

 Couches de compatibilité BSD

Haiku utilise des pilotes réseau venus de FreeBSD et OpenBSD, cela permet de mutualiser les ressources et de ne pas perdre du temps à réinventer la roue. Une couche de compatibilité permet de réutiliser les pilotes avec très peu de modification dans leur code et une simple recompilation.

Cette approche est également utilisée par d’autres systèmes d’exploitation comme RTEMS.

La couche de compatibilité a reçu des corrections de problèmes sur l’allocation de mémoire dédiée aux transferts DMA, ainsi qu’un problème sur le calcul de la taille d’un buffer de réception, qui empêchait les pilotes de fonctionner sur certains matériels.

 TCP

Waddlesplash a travaillé sur l’amélioration de l’implémentation de TCP :

• Refonte de la gestion des ACK reçus dans le désordre,
• Amélioration du code de débogage pour investiguer des crashs du noyau remontés par quelques utilisateurs,
• Modification du code de mise à jour de la taille de fenêtre TCP pour éviter d’envoyer inutilement des changements de taille,
• Correction de calcul du temps d’aller-retour,
• Implémentation du redimensionnement dynamique de la fenêtre de réception (auparavant, elle était de taille fixe),
• Ajout d’assertions à divers endroits dans la pile réseau pour détecter les problèmes à la source.

Ces améliorations permettent au trafic TCP d’être au moins 10 fois plus rapide, selon le type de connexion utilisé, et règle un problème de lenteur des téléchargements depuis Haiku qui était présent depuis assez longtemps.

 Ethernet

Du côté d’Ethernet, quelques améliorations et nettoyages sur le calcul de la MTU (taille maximale d’un paquet qui peut être envoyé). Pour l’instant, la découverte du « path MTU », la MTU du chemin complet entre deux machines, n’est pas encore disponible. Haiku ne s’autorise donc pas à envoyer du trafic plus large qu’une trame Ethernet standard, même si cela pourrait être possible pour le réseau local. Il reste donc une amélioration potentielle des performances réseau dans certains cas.

 UNIX domain sockets

Les sockets UNIX sont une méthode de communication entre processus standardisée par POSIX, utilisée surtout par des logiciels portés depuis d’autres systèmes (les applications natives pour Haiku utiliseront plus volontiers des BMessages ou des ports).

Amélioration et nettoyage du code autour de la gestion des données annexes dans les sockets UNIX. Correction de petites fuites de mémoire et d’un kernel panic qui pouvait se produire lors de la fermeture d’un socket (waddlesplash).

USB

Implémentation de l’USB « Super Speed Plus », qui permet des connexions USB avec un débit pouvant atteindre 10 gigabits par seconde (korli).

Refonte et consolidation du comptage de références dans la pile USB, ce qui met en évidence sous forme de kernel panic des cas où les choses ne sont pas bien faites. Ce n’est pas agréable, mais c’est tout de même mieux qu’une corruption mémoire difficile à investiguer (waddleplash).

Décodage des descripteurs USB Audio v2 dans la commande listusb, mais pas encore dans le pilote usb_audio qui implémente pour l’instant seulement la version 1 (gscrain).

PCI

Correction de problèmes d’accès au bus PCI sur les machines équipées de ACPI. Suite à une modification précédente, les accès sur 8 ou 16 bits étaient convertis en accès sur 32 bits, mais ce n’est pas le comportement attendu. En particulier, certains registres effacent automatiquement leur contenu lorsqu’ils sont lus, ou bien les données accessibles en lecture et en écriture ne sont pas les mêmes. (PulkoMandy)

Il n’est donc pas possible de lire une valeur sur 32 bits, remplacer 8 bits, et réécrire 32 bits pour simuler une écriture sur 8 bits dans un registre.

Les accès sont à nouveau traités correctement, ce qui permet à Haiku de fonctionner à nouveau normalement sur les machines concernées par ce type d’accès au bus PCI (cela dépend du matériel et des pilotes).

Périphériques de stockage

Petites améliorations de performances dans le pilote NVMe (waddlesplash).

Modification du pilote AHCI/SATA (waddlesplash) :
- Suppression de code dupliqué pour utiliser à la place des fonctions communes partagées avec d’autres pilotes,
- Correction d’une confusion entre adresses 32 et 64 bits qui empêchait de démarrer la version 32
bits de Haiku sur certains systèmes avec plus de 4Gio de RAM.

La pile SCSI prend mieux en compte les restrictions sur les adresses DMA. Chaque pilote de périphérique qui implémente SCSI peut indiquer ce qu’il est capable de faire, et la pile SCSI fait en sorte que les demandes de transferts DMA respectent ces contraintes, ce qui évite aux pilotes de devoir découper par eux-mêmes les transferts en unités qu’ils sont capables de traiter (waddlesplash).

ACPI

ACPI est une interface standardisée avec le matériel. Elle permet la gestion d’énergie (extinction de la machine par exemple), ainsi que l’accès à du matériel annexe tels que les boutons on/off, la détection de rabat de l’écran sur un PC portable, le contrôle des LEDs indicatrices ; ainsi que la découverte de matériel non connecté sur le bus PCI (comme certains modules eMMC dans des tablettes et ordinateurs à bas coût).

La spécification étant assez complexe, la bibliothèque ACPICA est utilisée pour implémenter les bases de ACPI. Ensuite, des pilotes dédiés permettent d’exposer chaque périphérique ACPI.

Mise à jour de ACPICA avec la dernière version publiée par Intel (publiée en mars), et un peu de nettoyage afin de pouvoir intégrer quelques patchs dans la version upstream de ACPICA (PulkoMandy).

Ajustement du pilote ACPI pour mapper sa mémoire physique en « write back » au lieu de désactiver complètement le cache. C’est nécessaire sur ARM64, car le cache permet d’intercepter les accès mémoire non alignés. Correction de problèmes liés au fait que la même zone de mémoire physique pouvait être mappée plusieurs fois avec des configurations différentes, ce qui est impossible (déclenche une « machine check exception ») (oanderso).

Graphiques

Avancées sur la prise en charge des cartes graphiques Intel de générations Tiger Lake, Ice Lake et Gemini Lake (ttmfx, ilzu, PulkoMandy). L’utilisation de ces cartes graphiques reste assez limité, sans accélération matérielle et sans possibilité d’utiliser plusieurs écrans pour l’instant.

virtio

Les pilotes virtio permettent l’utilisation de matériel virtuel défini pour tirer le meilleur parti des machines virtuelles. Plutôt que de copier le fonctionnement d’un matériel existant, l’interface peut être conçue pour rendre le travail plus simple aussi bien pour l’hôte que pour le système virtualisé.

Correction de problèmes dans l’allocation des files de messages virtio et amélioration de la gestion des erreurs (mmlr).

Vérification de l’état du périphérique après une réinitialisation, et correction d’un accès mémoire hors limite dans le pilote virtio_pci (korli).

PS/2

Les ports PS/2 ont disparu de la plupart des machines depuis de nombreuses années, mais le protocole est encore utilisé pour les claviers des ordinateurs portables ainsi que pour certains touchpads. Ces derniers utilisent de nombreuses extensions peu standardisées et mal documentées pour offrir des fonctions avancées qui n’existaient pas à l’époque des souris à deux boutons.

Le driver reçoit ce trimestre une refonte de la gestion des verrous entre ses différents composants, pour essayer de régler quelques problèmes de synchronisation (waddlesplash).

Systèmes de fichiers

ram_disk et ramfs

ram_disk est un périphérique bloc (block device) qui stocke ses données en RAM (non persistante au redémarrage). Il peut être formaté avec n’importe quel système de fichier.

ramfs est un système de fichiers qui stocke ses données en RAM, sans passer par un block device. Cela permet de meilleures performances (pas besoin de journalisation par exemple), une meilleure intégration avec le cache de fichiers (la mémoire peut être partagée directement entre ramfs et le cache), et de s’affranchir des limites habituelles des périphériques de bloc (par exemple: une taille fixe connue lors de la création du système de fichiers).

Un utilisateur a remonté un problème de compatibilité avec POSIX. Si on utilise mmap() sur un fichier stocké dans un ramfs, et que la taille du fichier n’est pas un multiple de la taille des pages de mémoire, la fin de la dernière page pouvait contenir des données aléatoires. Selon la spécification POSIX, il faut que cette zone soit remplie avec des 0, et le compilateur clang dépend de ce comportement pour implémenter une lecture rapide des fichiers sources compilés.

Le problème a été corrigé, avec au passage une commonalisation de code entre ramfs et ram_disk, de petits ajustements de performances, et un peu de nettoyage.

Enfin, la priorité des allocations mémoires de ces deux pilotes a été abaissée, ce qui permet d’éviter un gel du système s’il n’y a plus de mémoire disponible.

Le pilote ramfs continue d’être stabilisé, quelques problèmes qui pouvaient encore causer des kernel panic ont été corrigés.

packagefs

packagefs est un système de fichier virtuel qui expose le contenu de fichiers de packages au format hpkg. Des paquets peuvent être ajoutés et supprimés pendant le fonctionnement du système, et il n’est pas nécessaire d’extraire leurs données sur disque.

Plusieurs améliorations faites par waddlesplash :

• Ajout de vérifications de la bonne utilisation de verrous entre différents threads et corrections de problèmes mineurs qu’elles ont mis en évidence,
• Amélioration du message d’erreur si on essaie d’activer deux paquets qui entrent en conflit.

Un reproche qui est souvent fait au packagefs est d’avoir augmenté les besoins en RAM de Haiku, en effet, depuis la version Beta 1 de Haiku, la configuration mémoire minimum recommandée est de 384Mio de RAM, alors que les versions précédentes se contentaient de 128Mio.

• Utilisation d’object_cache` (un allocateur mémoire pour des objets qui font tous la même taille) dans différents endroits de packagefs pour réduire sa consommation de mémoire,
• Utilisation de listes chaînées simples au lieu de listes chaînées doubles là où ça ne pose pas de problème de performances,
• Suppression de champs constants dans certaines classes,
• « inlining » des compteurs de références pour rendre les structures de données plus compactes,
• Réorganisation des structures pour réduire le padding,
• Retrait des « dépôts d’objets » dans les arènes d'allocation,
• Découpage des allocations en plusieurs zones distinctes,
• Utilisation de verrous moins fins (par exemple, avoir un seul verrou pour tout un dossier au lieu de un par fichier),
• Utilisation d’un « bump allocator » pour les objets à courte durée de vie.

La réduction de consommation mémoire avec ces changements est de près de 20%, soit environ 15Mio sur une installation de référence. En effet, un gain de quelques octets sur le stockage d’informations sur un fichier est multiplié par plusieurs milliers de fichiers présents sur le disque, ce qui fait que chaque petite optimisation est intéressante. Cependant, les investigations ont aussi permis de découvrir d’autres problèmes encore plus importants qui n’étaient pas directement liés au packagefs, on en reparle un peu plus loin.

Un autre changement a été fait par waddlesplash, non seulement pour packagefs mais aussi pour d’autres endroits où le même code était utilisé : La fonction pour calculer un hash de chaîne de caractères utilisait un algorithme obsolète. Elle a été remplacée par hashdjb2 qui génère moins de collisions.

FAT

FAT est un système de fichier développé par Microsoft. Il est utilisé en particulier sur les cartes SD et les clés USB, ainsi que pour les partitions systèmes EFI. Bien que sa conception soit quelque peu obsolète, il reste donc indispensable.

Le pilote FAT de Haiku, qui provenait tout droit d’un code source publié par Be, a été remplacé dans la version beta 5 par une nouvelle version basée sur le code de FreeBSD. Ce nouveau pilote reçoit depuis des améliorations régulières par Jim906, le développeur qui s’est chargé du portage du code de FreeBSD.

Ce trimestre, le pilote reçoit des corrections sur l’initialisation des « media bytes » dans l’en-tête des partitions, des améliorations de performances pour réduire le temps nécessaire au montage d’une partition FAT, ainsi qu’une meilleure gestion des erreurs dans le traitement des noms de volumes. Il est également possible de monter les volumes FAT de taille supérieure à 2TiO.

BFS

BFS est le système de fichier hérité de BeOS et utilisé pour les partitions natives de Haiku. Il propose une très bonne implémentation des attributs étendus (sans limite de taille, et typés) et permet en plus d’exécuter des requêtes sur ces attributs pour localiser très rapidement les fichiers répondant à certains critères.

L’implémentation du système de fichier BFS est assez mûre et reçoit habituellement peu d’évolutions. Cependant, il reste toujours des possibilités d’améliorer les performances.

C’est le cas de la fonction de recherche de blocs libres. Les blocs sont chacun représentés par un bit dans une structure indiquant s’ils sont disponibles ou pas. La recherche de blocs libres se faisait bit à bit, mais il est possible de gagner beaucoup de temps en testant 64 bits d’un coup pour savoir tout de suite qu’ils représentent tous des blocs occupés, et passer directement aux 64 bits suivants. Cela améliore les performances de la création et du redimensionnement de fichier, en particulier sur les architectures RISC-V (waddlesplash).

Query parser

Plusieurs systèmes de fichiers conçus pour BeOS ou Haiku (bfs, ramfs, et packagefs) permettent l’utilisation d’attributs indexés par le système de fichiers qui permettent d’effectuer des requêtes pour localiser des fichiers comme dans une base de données.

Depuis la version beta 5 de Haiku, ces 3 systèmes de fichiers partagent le code utilisé pour parser une requête (envoyée sous forme de texte) et la convertir en une opération de recherche exécutable.

Ce parser pouvait dans certains cas (requêtes trop complexes) déclencher volontairement un kernel panic. Celui-ci a été remplacé par une « simple » erreur, remontée à l’application qui a déclenché la requête. L’application aura la charge de remonter cette erreur à l’utilisateur, et de l’inviter à simplifier sa demande.

block_cache

Le cache de blocs, comme son nom l’indique, stocke en mémoire RAM une copie de certains blocs des systèmes de fichiers. Cela permet d’accélérer les opérations bas niveau sur le système de fichier, en particulier pour mettre en cache des structures internes du disque. Il complète le file_cache, qui lui se trouve à un niveau plus haut, et met en cache uniquement le contenu des fichiers lus et écrits par les applications.

Le seul changement notable sur le block_cache est le retrait de paramètres inutilisés dans certaines fonctions, afin de simplifier le code (waddlesplash).

kernel

Une correction de bug sur le blocage des threads avec timeout (par exemple, l’attente d’un mutex ou d’un sémaphore avec un délai maximum): dans certains cas, une fonction pouvait retourner B_TIMED_OUT pour d’autres raisons que l’expiration du timer. Ce n’était pas traité correctement, et le noyau supposait que le timeout avait expiré, alors qu’il s’agissait d’autre chose. Des vérifications supplémentaires permettent de traiter ce cas correctement.

Correction de problème sur la programmation des timeouts « absolus temps-réel ». Comme leur nom l’indique, ils référencent l’horloge « real time » (qui essaie de suivre l’heure et la date « réelle », par opposition à l’horloge système qui est basée sur l’uptime de la machine, mais garantit de ne jamais faire de saut ou revenir en arrière). Ces timers ne fonctionnaient pas du tout (ou alors, seulement sur un coup de chance), et restaient probablement bloqués pendant une durée beaucoup plus longue que demandé. Au passage, nettoyage du code de gestion des timers.

Dans le code de gestion des interruptions: ajout d’assertions pour investiguer un bug dans les addons vmware ou virtualbox.

Correction d’un bug dans l’implémentation de kqueue qui produisait un blocage au démarrage de la libevent (qui utilise maintenant kqueue pour Haiku).

Des petites améliorations de performances: sur l’allocateur mémoire du noyau, sur l’utilisation de verrous dans la gestion de la mémoire virtuelle, des fuites de mémoire dans l’allocation de page, des améliorations sur la détection de références devenues invalides (jpelczar + waddlesplash).

Le script de link du noyau refuse maintenant les sections inconnues avec un message d’erreur, au lieu de simplement les ignorer (korli).

Correction du décompte du temps CPU utilisé par le thread en cours d’exécution, pour donner des résultats plus fiables dans les applications qui affichent l’utilisation CPU (waddlesplash).

Refactorisation du décompte du temps d’exécution des appels systèmes. Seul le temps passé dans l’exécution du syscall est prise en compte, sans mesurer la mise en place d’un appel système et du retour vers l’espace utilisateur (qui ne peuvent de toutes façons pas être mesurées de façon fiable depuis le noyau). Cela rend l’affichage des durées d’exécution dans strace plus facile à interpréter (waddlesplash).

Réduction de la taille maximale des tampons mémoire pour stocker des dirent à 8Kio. La plupart des applications n’utilisent pas un tampon aussi large, et les quelques-unes qui le faisaient ont été modifiées pour réduire la taille. Cette réduction permet d’utiliser un allocateur spécialisé beaucoup plus rapide, ce qui devrait compenser les rares cas où le tampon est trop petit pour récupérer tout le contenu d’un dossier en une seule fois (waddlesplash).

Correction de plusieurs problèmes dans le système de gestion des ressources faibles (qui essaie de libérer de la mémoire quand il n’y en a plus assez de disponible). Dans certains cas, le système finit par geler ou déclencher un kernel panic, alors qu’il devrait toujours être possible de refuser des demandes d’allocation mémoire venant de l’espace utilisateur, et de conserver suffisamment de mémoire libre pour au moins afficher proprement une erreur.

Amélioration de la gestion des mutex (exclusions mutuelles entre threads):

• Ajout d’assertions pour détecter des cas de réveil d’un thread qui ne devrait pas l’être.
• Correction d’un problème introduit récemment et investigué à l’aide de ces nouvelles assertions.
• L’ABI des locks est identiques entre les builds du kernel en version debug ou release, ce qui permet de ne pas avoir besoin de recompiler tous les pilotes dans le même mode que le kernel. Les pilotes compilés en mode release vont déclencher une erreur de symbole manquant si on essaie de les utiliser avec un noyau en mode debug, dans l’autre sens, il n’y a pas de problème. Auparavant, dans les deux cas on obtenait des crashes ou un gel complet du système, difficile à investiguer et faisant perdre du temps.
• Ajout d’assertions dans plusieurs cas pour détecter les utilisations incorrectes des rw-locks. Certaines activées par défaut, et d’autres uniquement sur demande à la compilation du noyau en raison de coût de vérification trop importants.
• Correction de mauvaises utilisations des rwlocks ainsi détectées.

Généralisation de l’utilisation de fonctions utilitaires partagées pour la conversion des timespec en durées en microsecondes. Cela permet aux fonctions concernées (entre autres kqueue) de bénéficier de contrôles de validité supplémentaires (waddlesplash).

Ajout d’informations de debug supplémentaires dans la sortie de la commande slab_object du debugger du noyau.

Réactivation de la calibration du TSC à partir d’informations du CPUID lorsque Haiku s’exécute dans un hyperviseur, comme c’était déjà le cas lorsqu’il s’exécute directement sur une machine physique. Le TSC est un timer interne du CPU qui permet des mesures de temps très rapides (une seule instruction CPU) mais dans une échelle de temps arbitraire qu’il faut corréler avec le « vrai » temps. Cela peut être fait soit à l’aide d’une mesure empirique (méthode historique), soit à l’aide d’informations sur cette horloge disponibles dans les informations retournées par l’instruction CPUID.

Affichage de plus de fonctionnalités du CPU reconnues dans les logs de debug pour les processeurs x86 (korli).

Ajout d’un raccourci clavier (Control+D) pour quitter le debugger noyau et reprendre l’exécution normale si possible (équivalent à la commande continue ou co) (mmlr).

Le chargement des pilotes de périphériques se fait en priorité depuis les dossiers non-packaged avant de rechercher les fichiers dans les paquets logiciels, ce qui permet de tester facilement une version modifiée d’un pilote - sauf si les dossiers non-packaged sont désactivés dans la configuration du noyau (korli).

VFS

Le VFS (virtual file system) est le composant de Haiku qui gère l’accès aux fichiers. Il fait l’intermédiaire entre les appels systèmes liés aux fichiers (open, read, write…) et les systèmes de fichiers eux-mêmes. Il implémente autant que possible ce qui peut être mis en commun entre tous les systèmes de fichiers: résolution de chemins relatifs, vérification de permissions…

Cela rend plus facile l’écriture d’un nouveau système de fichiers, qui peut alors se concentrer sur les aspects bas niveau et la gestion de ses structures de données.

Ajout de vérifications d’intégrités supplémentaires dans le VFS pour détecter des bugs dans les systèmes de fichiers le plus rapidement possible, au lieu d’obtenir un crash du noyau difficile à investiguer un peu plus tard.

Retrait d’un scan du bus SCSI et des pilotes associés par le device manager pour réduire un peu le temps de démarrage.

Correction d’un gros problème dans l’API du noyau IORequest qui aboutissait à une confusion entre la taille totale d’une requête et l’offset de la dernière donnée transférée (les transferts ne commençant pas forcément à l’offset 0). La conséquence était l’écrasement de données dans le cache de fichiers, déclenchant des crashes du noyau avec des messages d’erreur incompréhensibles à propos des structures de pages. Correction d’un problème de calcul d’offset qui faisait que certaines opérations étaient considérées comme réussies, alors qu’il y avait en fait une erreur.

Correction de problèmes de décomptage de références et de gestion du cache à l’interface entre ramfs et VFS, mis en évidence lors du travail de portage de Firefox.

Ajout d’une acquisition de référence sur un vnode qui manquait dans le cache de fichiers (waddlesplash).

Améliorations du cache d'entrées, dont en particulier la mise en cache du hash des noms de fichiers, pour éviter des comparaisons de chaînes de caractères inutiles.

Gestion de la mémoire

La gestion de la mémoire virtuelle est une des tâches essentielles d’un système d’exploitation. Elle garantit l’isolation entre les différents processus, permet d’utiliser la mémoire physique le mieux possible (éventuellement en déplaçant certaines allocations peu utilisées vers un espace d’échange sur disque), et permet aussi aux différents processus de se partager des données.

Il s’agit également d’un composant très sollicité, et dont les performances impactent beaucoup le comportement du système. Une mauvaise gestion de la mémoire peut fortement ralentir le système ou le rendre instable.

Ajout d’assertions dans le code gérant les pages de mémoire, pour essayer d’intercepter ce type de correction plus rapidement si elles se reproduisent.

Dans l’arbre des areas globales : ajout d’assertions pour détecter les identifiants d’areas dupliqués (chaque area doit bien sûr avoir un identifiant unique).

Implémentation de PAT (Page Attribute Table) pour les processeurs x86. Les PAT permettent de configurer des zones de mémoires qui peuvent ou ne peuvent pas être mises en cache (complètement ou en write-through). Elles remplacent les MTRR en permettant un contrôle plus fin et plus flexible. Au passage, nettoyage de l’implémentation des MTRR (préservée pour les processeurs plus anciens incompatibles avec PAT), ajout de nouvelles commandes dans le debugger noyau. Renommage des constantes B_MTR_* pour indiquer précisément leur rôle indépendamment des dénominations utilisées dans les registres MTRR qui ne sont pas très claires (mmlr).

Lorsque le système utilise PAT, ajout d’assertions pour détecter les tentatives d’accéder à la même zone de mémoire physique avec des configurations de cache différentes. Elles ne sont pas activées lorqu'on utilise les MTRR, car ces dernières ne permettent pas une configuration aussi fine (waddlesplash).

Ajout d’informations supplémentaire dans le message de kernel panic indiquant qu’une page devrait être libre mais qu’elle ne l’est pas. Modification de la commande page du debugger noyau pour récupérer la liste des espaces d’adressage depuis les structures du kernel plutôt que d’itérer sur tout l’espace d’adressage (ce qui pouvait fonctionner sur un espace 32 bit, mais pas en 64 bit).

Correction du code de « guarded heap » du noyau qui ne compilait plus. Il s’agit d’un allocateur mémoire plus lent mais avec de nombreuses vérifications d’intégrité pour détecter les débordements de tampons, double free, et autres problèmes de gestion de la mémoire dans le noyau (kallisti5).

Le fichier swap est automatiquement supprimé, et l’espace disque libéré, lors de la désactivation de la swap. Auparavant, un redémarrage était nécessaire (waddlesplash).

Correction d’un problème dans l’allocation de mémoire « early boot » (avant que l’allocation normale soit mise en place), qui empêchait le démarrage sur les systèmes pouvant gérer de grandes quantités de mémoire (plusieurs centaines de Gio) (waddlesplash).

libroot

La libroot regroupe tous les composants de la librairie standard C (parfois découpée en libc, libm et libpthread pour d’autres systèmes). Elle contient en plus un certain nombre d’extensions spécifiques à Haiku et à BeOS.

Changements effectués par waddlesplash, sauf mentions spécifiques:

Nettoyage de code dans la classe WeakReferenceable, une classe de comptage de références intrusive qui autorise les références "faibles".

Correction de problèmes dans le code d’interfaçage avec ICU pour la conversion de dates (nipos et waddlesplash).

libnetwork

Nettoyage de code de compatibilité avec BeOS dans la libnetwork, pour faire en sorte qu’il ne soit plus du tout compilé sur les architectures n’offrant pas de compatibilité avec BeOS.

Compatibilité POSIX

Implémentation minimale de mknod et mknodat dans le seul cas spécifié par POSIX, qui permet de réaliser une opération équivalente à mkfifo. La gestion des devices dans Haiku est très différente de celle utilisée traditionellement par UNIX, et ne se prête pas à l’implémentation des autres utilisations de ces fonctions.

Rectification de l’implémentation des fonctions *at (par exemple linkat) qui permettent de réaliser une opération à partir d’un descripteur de fichier au lieu d’un path. Dans la libroot, ces fonctions envoyaient la valeur -1 aux appels systèmes pour implémenter AT_FDCWD. La valeur de AT_FDCWD a été modifiée pour choisir autre chose que -1 (qui est souvent utilisé pour indiquer une erreur dans le code de retour d’autres fonctions). Les appels systèmes acceptent pour l’instant les valeurs -1 et AT_FDCWD, mais rejettent maintenant toutes les autres valeurs négatives.

Remplacement d’une partie du code de gestion des flux d’entrée-sortie par la version de la glibc. La bibliothèque libroot est un patchwork d’implémentations provenant de la glibc, de musl, et de divers BSD, un objectif à terme est d’essayer de se rapprocher d’une de ces implémentations, mais on ne sait pas encore trop de laquelle. En tout cas, le code des I/O provient majoritairement de la glibc afin d’être très compatible avec ce qui était utilisé dans BeOS.

La fonction gmtime retourne une struct tm avec le champ tm_zone contenant la chaîne "GMT" (waddlesplash).

Correction de la conversion des "surrogate pairs" dans la fonction mbrtowc.

Mise en conformité de l’implémentation des threads avec POSIX :

• Ajustement de code d’erreurs retournés par les fonctions
• Suppression de la possibilité de retourner EINTR depuis un rwlock
• Correction de deadlocks dans les barriers
• Correction de plusieurs problèmes dans l’implémentation des sémaphores anonymes.

Mise en place systématique de l’utilisation de _DEFAULT_SOURCE pour protéger les extensions à la norme POSIX, ce qui permet de les activer automatiquement via l’inclusion de features.h lorsque c’est possible.

Nettoyage de quelques fichiers d’en-tête, dont en particulier <sys/select.h>, pour éviter de polluer l’espace global avec des macros et des définitions en double (waddlesplash).

Prise en compte correcte du drapeau O_NONBLOCK lors de l’ouverture d’un FIFO (korli).

runtime_loader

Le runtime_loader est le composant responsable du chargement en mémoire des exécutables et du lancement de nouveaux processus. Il réalise la résolution des dépendances et la recherche des bibliothèques partagées nécessaires pour l’exécution d’un programme.

Il reçoit des évolutions suite au portage d’applications complexes venues de Linux, qui nécessitent souvent plusieurs dizaines de bibliothèques partagées.

Correction de problèmes détectés en testant un portage expérimental et instable de Firefox: crash du runtime_loader dans certains cas si on charge une bibliothèque (via dlopen ou load_add_on) dont il manque des dépendances.

Retrait de l’option -fno-builtin dans les drapeaux de compilation du runtime_loader, comme cela avait déjà été fait pour la majorité de la libroot. Cela permet à gcc de remplacer des appels à des fonctions standardisées par une implémentation inline plus performante (waddlesplash).

Outils de debug

Développement d’outils pour enregistrer ce qu’il se passe pendant le démarrage du système et détecter d’éventuels problèmes de latence, de 'lock contention', etc. Au passage, correction de divers problèmes liés à ces outils : les barres de défilement de DebugAnalyzer, les permissions noyau dans transfer_area, etc.

Amélioration de la remontée des valeurs de retour des appels systèmes vers strace sur les plateformes x86 32-bit.

Pour terminer, un changement réalisé par mmlr : amélioration de l’allocateur mémoire "guarded heap" pour le rendre utilisable plus facilement, y compris comme allocateur pour tout le système. Cet allocateur permet de détecter les accès au-delà de la fin d’une zone mémoire allouée avec malloc(), ainsi que les accès à de la mémoire déjà libérée, mais au prix d’une consommation mémoire nettement plus élevée qu’un allocateur classique. La disponibilité d’un espace d’adressage de 64 bits permet de limiter les cas où une adresse mémoire est initialement utilisée pour une allocation, puis libérée et allouée à nouveau pour autre chose.

Un problème de gestion d’erreur dans l’interfaçage entre le Debugger et le noyau pouvait conduire à un gel complet du système dans certains cas de plantage du debug_server, en particulier s’il n’y a plus assez de mémoire RAM disponible.

Bootloader

Ajout d’une vérification manquante pour prendre en compte l’option « BlockedEntries » dans le bootloader. Cette option s’appelait précédemment « EntriesBlacklist » mais a été renommée pour utiliser un terme non entaché de racisme. L’ancien nom continue de fonctionner pour ne pas casser les installations existantes, mais n’est plus documenté.

Augmentation de la taille maximum autorisée pour les allocations « standard » sur la pile. L’allocateur mémoire du bootloader traite séparément les allocations de grande taille, mais ces allocations ne sont pas correctement libérées lors du transfert de contrôle vers le noyau, en particulier sur les machines utilisant un BIOS non EFI. Pour l’instant, une correction complète du problème semble compliquée à mettre en place, mais la modification permet de libérer de la mémoire allouée pour l’accès au packagefs (le bootloader a besoin d’y accéder pour trouver le noyau, qui est stocké dans un paquet). Ce changement permet de libérer plusieurs dizaines de Mio de mémoire, et complète les changements mentionnés plus haut sur la gestion des paquets après démarrage. Il est possible de configurer Haiku pour fonctionner avec moins de 100Mio de mémoire (waddlesplash).

Réparation de la ré-initialisation des ports série sur le bootloader EFI. Le port série est utilisé à des fins de debug, mais il peut être accédé de plusieurs façons différentes (en adressant directement le matériel, ou bien via des services EFI dédiés). Le bootloader doit passer d’une méthode à l’autre à différentes étapes du démarrage: accès direct au port physique dans les premières étapes (en détectant s’il est bien présent à une adresse standard), accès via les services EFI une fois ceux-ci initialisés, puis à nouveau accès direct au matériel après l’arrêt des services EFI pour la dernière étape de passage de contrôle au noyau (cette fois-ci à une adresse qui peut être configurée dans les options du bootloader et du noyau). Ce fonctionnement ne s’insère pas forcément très bien dans la logique du bootloader, qui n’avait à l’origine pas été conçu pour une gestion aussi complexe des entrées-sorties (VoloDroid).

Réduction de la quantité de logs liés à la mise en place de SMP (gestion de plusieurs processeurs) dans le bootloader pour BIOS (waddlesplash).

Le menu de démarrage affiche la version (numéro 'hrev') du paquet système correspondant à chaque point de restauration disponible, ce qui facilite l’identification des états qui correspondent à un changement de version du système, et pas une simple installation, désinstallation ou mise à jour de paquets logiciels (waddlesplash).

Documentation

Haiku Book

Le « Haiku Book » est un projet de documentation des APIs publiques de Haiku. Il doit à terme remplacer le « Be Book », qui documente les APIs de BeOS, mais ne peut pas être mis à jour à cause de se license CC BY-NC-ND. Actuellement, il faut jongler entre ces deux documentations.

La documentation de B_INFINITE_TIMEOUT (constante permettant d’indiquer à certaines fonctions qu’on veut les exécuter sans timeout, et attendre indéfiniment) a été mise à jour pour indiquer explicitement que sa valeur numérique est INT64_MAX (waddlesplash).

Correction de fautes de frappe dans la documentation des API liées aux entrées clavier (drea233).

Haiku Interface Guidelines

Ce document présente les bonnes pratiques et conventions pour la conception d’interfaces graphiques fonctionnant avec Haiku.

Ajout d’une section sur la gestion des fichiers récemment utilisés et la façon dont ils peuvent être exposés aux utilisateurs.

Wiki et documentation interne

Le wiki contient des informations utiles aux développeurs de Haiku.

La documentation « interne" documente le fonctionnement de Haiku en s’adressant principalement aux contributeurs du système, par opposition aux personnes qui souhaitent seulement développer ou porter des applications.

Mise à jour de la page « release cookbook » indiquant toutes les étapes à suivre lors de la publication d’une version de Haiku.

Notes d’administration système : mise à jour des instructions pour instancier des machines Google Cloud Platform (kallisti5).

Système de build, environnement de compilation

La compilation d’un système d’exploitation complet n’est pas chose facile. D’autant plus pour Haiku, qui présente les particularités suivantes:

• Utilisation de deux versions de gcc (gcc 2.95.3 et gcc 13) pour la version 32 bit de Haiku, afin d’assurer la compatibilité binaire avec BeOS,
• Possibilité de compilation croisée depuis Linux, Mac OS et d’autres systèmes, ou depuis un hôte Haiku,
• Compilation d’outils pour la machine hôte de la compilation croisée, avec si nécessaire une couche de compatibilité permettant d’écrire ces outils en utilisant des API et fonctionnalités spécifiques à Haiku,
• Possibilité de compiler des applications pour un système hôte existant (une autre version de Haiku) à des fins de test,
• Compilation d’un système complet (noyau, bibliothèques, applications, image disque) en une seule opération.

Pour ces raisons, l’utilisation d’un système de build haut niveau (CMake, Meson…) s’avère plutôt complexe. L’utilisation de make ou de ninja directement serait de trop bas niveau. Le choix de Haiku est donc d’utiliser l’outil jam, qui est malheureusement assez peu populaire et tombé à l’abandon dans sa version originale. Haiku maintient un fork de jam qui est concurrent de ceux maintenus par Boost et par Freetype.

Reformatage des fichiers Jamfile pour lister une seule cible par ligne au lieu de les rassembler, cela facilite les rebase et résolutions de conflits (x512).

Mise à jour de paquets en préparation pour la version beta 5: OpenSSL 3, Python 3.10, et autres mises à jour diverses (PulkoMandy, waddlesplash, kallisti5).

Ajout de l’inclusion de <features.h> dans <sched.h>. Le fichier d’en-tête features.h configure la visibilité des extensions GNU et BSD aux fichiers d’include standards C et POSIX, en fonction d’options de ligne de commande du compilateur. L’inclusion de ce fichier permet d’utiliser facilement et par défaut ces extensions (PulkoMandy).

Mise à jour des marque-pages fournis par défaut avec le navigateur WebPositive (waddlesplash).

Ajout des en-têtes de la bibliothèque linprog dans le paquet haiku_devel. Ces en-têtes sont nécessaires pour les applications associées au système de layout d’interfaces graphiques ALM (korli).

Correction de fautes de frappe dans des commentaires (jmairboeck) et d’un problème de compatibilité C89 dans un en-tête système (waddlesplash).

La taille des images « nightly build » de Haiku est maintenant de 650 Mo, ce qui laisse un peu plus de place disponible pour les utiliser et créer quelques fichiers (jscipione).

Diverses corrections pour une nouvelle fois essayer de faire fonctionner la compilation de Haiku avec Clang (waddlesplash, oanderso). Les choses en sont toujours au même point depuis plusieurs années, avec des corrections de temps en temps mais quelques parties du système qui ne fonctionnent toujours pas correctement.

La compilation du profil « nightly » n’a plus besoin de générer le paquet haiku_source contenant le code source de Haiku. Ce paquet est inclus uniquement dans les images de releases (pour faciliter le respect strict de la licence GPL de certains composants de Haiku), mais, pour des raisons de dépendances entre cibles dans le système de build, il était tout de même généré pour les autres profils, ralentissant la compilation (waddlesplash).

Améliorations du script ./configure (jessicah, OscarL et waddlesplash):

• Le script vérifie que les options passées fournies sont valides, et rejette immédiatement les configurations incohérentes plutôt que de laisser la compilation échouer bien plus loin.
• Validation que l’interpréteur Python sélectionné existe bien, et uniformisation de la syntaxe utilisée pour choisir un interpréteur avec la façon dont c’est fait pour d’autres outils.
• Détection des options disponibles pour demander à wget de ré-essayer un téléchargement en cas d’échec, ce qui permet d’assurer la compatibilité avec wget2.
• Utilisation automatique d’une version moderne de GCC pour compiler les outils « hôtes » lors de la compilation à partir d’une machine hôte fonctionnant sous Haiku en version 32 bit, en ignorant le compilateur par défaut qui est gcc 2 pour des raisons de compatibilité avec BeOS.

Réorganisation du code source de libroot pour déplacer les implémentations de malloc dans des sous-dossiers séparés, et faciliter l’expérimentation avec d’autres implémentations de malloc. L’allocateur hoard2 utilisé actuellement n’est pas adapté aux architectures 64 bits, une tentative a été faite il y a quelques années avec rpmalloc, mais ce dernier pose des problèmes sur les
architectures 32 bits. Des investigations sont en cours avec l’implémentation de malloc d’OpenBSD.

L’outil de dessin Wonderbrush est maintenant disponible sur toutes les architectures. Historiquement, le code de Wonderbrush n’était pas libre, mais une version gratuite était offerte aux utilisateurs de Haiku. Le développeur principal de Wonderbrush n’est plus très actif sur le projet et a décidé de publier les sources, ce qui a permis de recompiler le programme en version 64 bits et plus tard sur les autres architectures non x86. Mais ces nouvelles versions n’avaient jamais été incluses dans Haiku (PulkoMandy).

Nettoyage et centralisation des définitions préprocesseur pour la compatibilité avec BeOS. Désactivation de la compatibilité avec BeOS dans le noyau, la compatibilité avec les pilotes et modules noyau de BeOS n’étant plus assurée depuis quelque temps dans Haiku.

Suppression de définitions de règles obsolètes et inutilisées dans le Jamfile permettant de construire le fichier package_repo (CodeforEvolution).

Remise en service du test DiskDeviceManagerTest qui ne compilait plus (waddlesplash).

ARM & PowerPC

Actuellement, Haiku est disponible officiellement pour les architectures x86 32 et 64 bits. Une version RISC-V 64 bits expérimentale est également disponible mais pas encore totalement intégrée dans le dépôt de code principal, des discussions sont en cours sur la bonne façon de faire certains changements nécessaires. Les versions ARM (32 et 64 bits) et PowerPC sont les prochaines cibles sur la liste. La première, car c’est une architecture très populaire, la deuxième plutôt pour des raisons historiques : c’est l’une des architectures sur lesquelles fonctionne BeOS.

Renommage de structures qui étaient initialement spécifiques à l’architecture x86, mais qui sont finalement utilisées également sur d’autres CPU sans nécessiter de changements (waddlesplash).

Réparation de la console de texte du chargeur de démarrage OpenFirmware qui était cassée depuis l’adaptation pour OpenBOOT sur les machines SPARC (zeldakatze).

Sur ARM, utilisation de la bonne instruction CPU pour mettre le processeur en veille quand il n’y a rien à faire (archeYR).

oanderso continue le travail sur le portage ARM64:

• Correction de plusieurs problèmes liés à la gestion du cache et de la MMU dans le bootloader, ce qui permet de démarrer le noyau dans une machine virtuelle sur un hôte Apple M1.
• Correction de l’implémentation des timers dans le kernel qui ne fonctionnait pas dans les environnements virtualisés.
• Quelques avancées sur la gestion de la MMU : Implémentation de la table de translation de la mémoire virtuelle, du traitement des exceptions matérielles (défauts de page), des TLBs.
• Synchronisation du cache d’instructions.
• Correction de problèmes de double lock.

Ajout de messages sur le port série traçant l’exécution de méthodes spécifiques à une architecture qui ne sont pas encore implémentées. Ceci permet de détecter facilement quelle est la prochaine fonction à implémenter (waddlesplash).

Nettoyage et documentation du fichier ArchitectureRules pour simplifier la configuration des options en ligne de commande du compilateur (qui doit savoir traiter deux versions de gcc et clang) (waddlesplash).

Les deux parties précédentes ont présenté les principales évolutions dans le code de Haiku. Mais le code ne fait pas tout.

Cette troisième (et dernière) partie présente les nouveautés dans la documentation, ainsi qu’un court aperçu du rapport financier et aux dons qui permettent à Haiku d’employer un développeur à plein temps de façon durable.

Enfin, elle présente la participation au Google Summer of Code et les travaux réalisés par les cinq étudiants encadrés par Haiku cette année.

Sommaire

• Documentation
  • Documentation d’API
  • Documentation interne
• Un point sur le financement
• Google Summer of Code
  • Calisto Mathias — Re-design de la fenêtre de recherche de fichiers
  • Daniel Martin — Virtualisation matérielle accélérée avec NVMM
  • Diego Roux — Pilote pour les cartes sons virtuelles VirtIO
  • trungnt2910 — Portage de GDB
  • Zardshard — Migration du navigateur web WebPositive vers WebKit2

Documentation

La documentation de Haiku se découpe en 3 parties principales : un manuel de l’utilisateur, une documentation d’API, et une documentation interne pour les développeurs qui travaillent sur les composants du système.

Ces documents sont complétés par de nombreuses pages et articles sur le site Internet, et deux livres pour apprendre à programmer en C++ avec Haiku, ou encore un document de référence pour la conception d’interfaces graphiques et un autre pour le style graphique des icônes.

Documentation d’API

La documentation d’API de BeOS était assez complète et de bonne qualité. L’entreprise Access Co Ltd qui a hérité de la propriété intellectuelle de BeOS a autorisé le projet Haiku à la réutiliser et à la redistribuer. Malheureusement, cette autorisation est faite avec une licence Creative Commons n’autorisant pas les modifications. Cette documentation ne peut donc pas être mise à jour, ni pour corriger les erreurs, ni pour ajouter des informations sur toutes les nouvelles fonctions ajoutées par Haiku ou les différences entre les deux systèmes.

Il est donc nécessaire de réécrire une nouvelle documentation à partir de zéro. Ce travail est assez ingrat lorsqu’il s’agit de re-décrire ce qui est déjà très bien expliqué dans la documentation existante. La nouvelle documentation a donc tendance à se concentrer sur les nouvelles fonctions, et il faut souvent jongler entre les deux documentations, le contenu des fichiers .h, et des exemples de code d’applications existantes pour découvrir toutes les possibilités offertes.

Il ne semble pas utile de lister chaque fonction ou méthode qui a été documentée. On peut mentionner une page d’explications sur la bibliothèque C standard, comprenant des liens vers les spécifications POSIX qui documentent déjà la plupart des choses, et quelques détails sur les différences avec d’autres systèmes.

Une autre nouvelle page documente les primitives de synchronisation qui sont disponibles pour le code s’exécutant dans le noyau.

Documentation interne

La documentation interne était à l’origine simplement une accumulation de fichiers dans divers format dans un dossier « docs » du dépôt Git de Haiku. Depuis 2021, ces fichiers ont été rassemblés et organisés à l’aide de Sphinx, qui permet de mettre à disposition une version navigable en HTML et de donner une meilleure visibilité à ces documents.

D’autres pages sont petit à petit migrées depuis le site web principal de Haiku, qui n’est pas un très bon support pour de la documentation, et bénéficiera un jour d’une refonte pour être plus tourné vers les utilisateurs que vers les développeurs.

Quelques nouvelles pages ajoutées cette année:

• Une documentation sur l’utilisation de divers outils de complétion de code automatique avec le code source de Haiku
• Une page présentant l’organisation du code source et les principaux dossiers et sous-dossiers
• La documentation de l’outil rc utilisé pour compiler les « resources » attachées aux exécutables a été intégrée
• Le système de fichier FAT a reçu également une page de documentation à l’occasion de sa réécriture

Un point sur le financement

L’association Haiku inc qui gère le compte en banque de Haiku publie chaque année un rapport financier.

Le financement provient principalement de dons des utilisateurs et soutiens de Haiku. Le projet reçoit également une compensation financière de Google pour le temps passé à encadrer les participants du Google Summer of Code (voir le paragraphe suivant). La contribution de Google cette année est de 3 300$.

Les plateformes de don les plus utilisées sont Paypal et Github sponsor. Ce dernier est recommandé car, pour les dons reçus via Github, c’est Microsoft qui paie les frais bancaires de la transaction. 100% de l’argent donné arrive donc sur le compte de Haiku. Tous les autres opérateurs ont un coût, soit fixe lors des retraits, soit un pourcentage de chaque don, soit un mélange des deux.

En 2023, l’association a reçu 25 422$ de dons et a dépensé 24 750$. Elle dispose d’une réserve confortable de 100 000$ (accumulés avant 2021, alors qu’il n’y avait pas de développeur salarié) ainsi que d’environ 150 000$ en cryptomonnaies.

Les dons en cryptomonnaies sont pour l’instant bloqués sur un compte Coinbase suite à des problèmes administratifs (le compte n’est pas correctement déclaré comme appartenant à une association, il faudrait donc payer un impôt sur le revenu lors de la conversion en vraie monnaie). Il semble difficile de contacter Coinbase pour régler ce problème.

Du côté des dépenses, le poste le plus important est le paiement de 21 000$ à Waddlesplash, développeur employé par Haiku inc pour faire avancer le projet Haiku. Il travaille à temps partiel et avec un salaire très bas par rapport au marché, comme cela a été fait pour les précédents contrats entre Haiku inc et d’autres développeurs. Les finances de l’association ne permettent pas encore d’assurer un emploi à plein temps avec un salaire correct sur le long terme (c’est faisable sur le court ou moyen terme à condition de puiser dans les réserves de trésorerie).

Le reste des dépenses concerne principalement le paiement de l’infrastructure (serveurs pour le site Internet, l’intégration continue, hébergement cloud pour les dépôts de paquets) pour environ 3 000$.

Il faut enfin compter environ 500$ de frais Paypal, puis quelques dépenses administratives (déclaration de changement d’adresse de l’association, déclaration d’embauche) pour des montants négligeables (moins de 10$ au total).

En 2024, l’objectif fixé en janvier était de récolter 20 000$ de dons supplémentaires. Cet objectif a été atteint dès le mois de juillet, et a donc été révisé pour tenter d’atteindre les 30 000$. Cela permettra de rémunérer Waddlesplash pour un plus grand nombre d’heures cette année, ou bien d’envisager l’embauche d’une deuxième personne si un ou une candidate se présente parmi les personnes contribuant au projet (l’embauche d’une personne extérieure ne se fera pas tant que l’association ne peut pas se permettre de proposer une rémunération raisonnable).

Google Summer of Code

Haiku participe au Google Summer of Code depuis 2007. Il s’agit d’un programme où des étudiants (et d’autres participants pas forcément étudiants, ces dernières années) sont payés par Google pendant deux mois pour découvrir la contribution à des projets de logiciels libres.

Ce programme a été monté par « l’Open source program office » de Google. Leur intérêt est de défendre leur image d’entreprise sympathique (bien mise à mal ces dernières années, c’est devenu un géant de la publicité en ligne et de l’aspiration des données personnelles), et de contribuer à la richesse d’un écosystème de logiciels libres dont ils bénéficient beaucoup. Cela permet aussi d’encourager des personnes à s’essayer au développement logiciel, facilitant indirectement le recrutement chez Google en augmentant le nombre de candidats. Ces justifications peuvent sembler hypothétiques ou très indirectes, mais elles ont convaincu Google d’attribuer un budget de quelques millions de dollars à ce programme.

Une équipe de Google choisit les projets de logiciel libres participants parmi de nombreuses candidatures. Chaque projet participant propose une liste « d’idées » (un peu sous la forme d’un sujet de stage) et a ensuite la responsabilité de choisir parmi les candidats qui ont répondu à cette offre (en respectant les critères de non-discrimination imposées par Google ainsi que les embargos imposés par les USA), et d’assurer l’encadrement des personnes sélectionnées. Google rémunère les participants, et dédommage les projets participants pour le temps investi.

Cette année les développeurs de Haiku encadrent cinq participants :

Calisto Mathias — Re-design de la fenêtre de recherche de fichiers

Le système de fichier BFS utilisé par Haiku permet l’exécution de requêtes (comme une base de données) exploitant les attributs étendus des fichiers, qui peuvent être indexés.

Ce système permet de faire beaucoup de choses, et la fenêtre de recherche du navigateur de fichier essaie d’en tirer parti. Cependant, l’interface résultante est trop complexe, et peu de personnes prennent le temps de concevoir des requêtes améliorant leur façon de travailler, se cantonnant aux quelques exemples fournis.

L’objectif de ce projet est de refondre l’interface de cette fenêtre pour obtenir quelque chose de plus intuitif, et également d’afficher en temps réel les résultats de la requête dès qu’elle est modifiée, pour encourager les utilisateurs à expérimenter avec des requêtes plus complexes.

Daniel Martin — Virtualisation matérielle accélérée avec NVMM

Haiku n’est pas encore parfait, et certaines tâches nécessitent encore l’utilisation d’autres systèmes d’exploitation. Une partie des utilisateurs ont donc une configuration en double boot, ou bien lancent Haiku dans une machine virtuelle.

L’objectif de ce projet est de permettre d’utiliser Haiku comme système principal, et de lancer les autres systèmes dans des machines virtuelles. Cela sera réalisé à l’aide d’un portage de NVMM, qui a été développé à l’origine par NetBSD et Dragonfly BSD. Cette bibliothèque a l’avantage d’être bien documentée et conçue pour faciliter son adaptation vers d’autres systèmes.

NVMM sera complétée par l’utilisation de QEMU qui pourra fournir un « front-end » à cette mécanique.

Diego Roux — Pilote pour les cartes sons virtuelles VirtIO

Pour les personnes utilisant Haiku dans une machine virtuelle, il est intéressant d’utiliser autant que possible la famille de périphériques VirtIO.

Il s’agit de périphériques virtuels conçus sans s’inspirer de matériel existant, et plutôt pour avoir l’interface la plus simple possible entre la machine virtualisée et son hôte.

Haiku dispose déjà d’un jeu de pilote Virtio relativement complet (réseau, stockage de masse, affichage graphique). Le but de ce projet est de compléter cet ensemble avec un pilote pour les cartes son VirtIO.

trungnt2910 — Portage de GDB

Haiku dispose de son propre débugger (appelé Debugger, de façon assez peu originale). Ce dernier présente une interface graphique confortable, mais une interface en ligne de commande beaucoup plus limitée. Il souffre également de quelques problèmes de performances et d’un manque de prise en charge des fichiers exécutables et bibliothèques compilés avec autre chose que GCC. Il est également incapable de faire du debug à distance ou de s’intégrer dans une interface graphique existante (par exemple au sein d’un IDE).

L’objectif de ce projet est de ressusciter la version de GDB ciblant Haiku. Cette version très ancienne était utilisée avant l’apparition du Debugger natif. Le projet est en bonne voie, le code d’interfaçage a été entièrement réécrit pour s’adapter aux versions modernes de GDB, et plusieurs évolutions et corrections ont été intégrées dans le système de debugging de Haiku (par exemple, pour mettre en pause tous les threads nouvellement créés afin que le debugger puisse les intercepter).

Zardshard — Migration du navigateur web WebPositive vers WebKit2

Le navigateur WebPositive utilise le moteur de rendu webKit. Actuellement, il s’interface avec ce moteur via l’API WebKitLegacy. Cette API exécute tout le moteur de rendu web dans un seul processus, et ne fournit pas les garanties d’isolation nécessaires pour les navigateurs web modernes (que ce soit en termes de sécurité, ou en termes de fiabilité).

L’objectif de ce projet est de reprendre les travaux déjà entamés en 2019 pour migrer WebPositive vers la nouvelle API « WebKit2 », et bénéficier d’une séparation entre l’interface graphique, la communication réseau, et le rendu HTML/CSS/JavaScript dans des applications séparées. Ainsi, un crash d’un de ces composants peut être récupéré de façon transparente sans faire disparaître toute l’application (et les données non enregistrées de l’utilisateur avec).

Le projet est également en bonne voie, un navigateur de test permet déjà d’afficher quelques pages ce qui montre que les bases sont en place. Il reste à régler de nombreux problèmes de rendu de texte, ainsi qu’à implémenter la gestion des entrées (clavier et souris) pour avoir un navigateur web utilisable. Il faudra ensuite migrer WebPositive vers ces nouvelles APIs.

Haiku est un système d’exploitation libre destiné aux ordinateurs personnels ou de bureau (pas de serveurs, pas de systèmes embarqués, pas de tablettes ni de téléphones). Il s’agit au départ d’une réécriture libre de BeOS, préservant la compatibilité binaire avec ce dernier (les applications BeOS peuvent tourner sur certaines versions de Haiku).

Après la présentation des applications de Haiku, voici une incursion dans le noyau et la chaîne de compilation. Au menu de ce chapitre notamment : processeurs, réseau, périphériques, son et image, système de fichier, améliorations des performances, etc.

Sommaire

• Noyau
  • Pilotes
    • Processeurs
    • Réseau
    • Périphériques d’entrée
    • Son et image
    • Machines virtuelles
    • Autres
  • Systèmes de fichiers
  • Réseau
    • Sockets UNIX
    •  TCP
  • Autres
  • Portages ARM, RISC-V et autres
• Bootloader
• Amélioration de performances
  • Implémentation des IO vectorisées sur les périphériques de type bloc
  • Réparation du profiler
  • Réduction des verrouillages du device manager
  • DT_GNU_HASH dans les fichiers ELF
  • premapping de mmap
  • Suppression des zones mémoire
  • Calcul des sommes de contrôles des paquets réseau par le matériel
  • user_mutex
• Chaîne de compilation

Noyau

Le noyau de Haiku est similaire à celui de BeOS : il s’agit d’un noyau monolithique, avec du multitâche préemptif et protection mémoire. Rien de très inhabituel. Il est développé en C++ (comme le reste du système), ce qui permet de rendre le code plus lisible que du C tout en conservant des bonnes performances pour ce code bas niveau.

Un point intéressant, le noyau offre une API et une ABI stable pour les pilotes, ce qui fait qu’il est en théorie possible de développer un pilote hors du projet Haiku et de le faire fonctionner avec plusieurs versions du noyau. En pratique, peu de personnes se lancent dans ce genre de chose, il est plus simple d’intégrer les pilotes dans le dépôt de sources de Haiku pour l’instant.

Pilotes

Commençons justement par regarder les nouveautés du côté des pilotes matériels. Il s’agit pour tout système d’exploitation d’un point de difficulté, indispensable pour fonctionner sur une large variété de systèmes.

Processeurs

En principe, un processeur est un matériel assez bien standardisé, qui implémente un jeu d’instruction bien défini et ne devrait pas nécessiter de pilote spécifique. Cependant, le matériel moderne de plus en plus complexe, offrant de plus en plus de fonctionnalités dans une seule puce électronique, fait qu’il faut tout de même prendre en compte quelques cas particuliers.

• Ajout de nouvelles générations de machines Intel dans le driver PCH thermal (récupération de la température du CPU au travers du platform control hub).
• Implémentation du contournement pour la faille Zenbleed dans les processeurs AMD.
• La mise à jour du microcode pour les processeurs Intel n’est pas faite si le CPU est déjà à jour (pour gagner un peu de temps au redémarrage du système).

Réseau

Les cartes réseau restent aujourd’hui le composant le moins bien standardisé sur les ordinateurs. Il n’existe pas d’interface standardisée, et chaque fabricant propose sa propre façon de faire.

Aujourd’hui, la plupart des autres périphériques suivent des spécifications (xHCI pour les contrôleurs USB3, AHCI pour le SATA, Intel HDA pour les cartes son…) ou bien il ne reste que peu de concepteurs de composants (par exemple pour les cartes graphiques où on ne trouve que Intel, AMD et NVidia).

Écrire des pilotes pour toutes ces cartes réseau demanderait beaucoup trop de travail. C’est pourquoi, depuis 2007, Haiku s’est doté d’une couche de compatibilité avec FreeBSD, permettant de réutiliser les pilotes écrits pour ce dernier (une approche également utilisée par le système d’exploitation temps réel RTEMS).

Cependant, les développeurs de FreeBSD font face au même problème, et ont décidé d’adopter la même solution : une couche de compatibilité permettant d’utiliser les pilotes de Linux. Cela pose deux problèmes pour Haiku : il ne semble pas souhaitable d’empiler les couches de compatibilité, et il ne semble pas raisonnable d’écrire une couche de compatibilité avec Linux, dont les API internes évoluent beaucoup trop vite, ce qui nécessiterait une réécriture permanente de la couche de compatibilité pour suivre le rythme.

Finalement, la solution retenue pour Haiku est d’utiliser les pilotes activement développés par OpenBSD et en particulier par Stefan Sperling. La couche de compatibilité avec FreeBSD est également maintenue, et Haiku bénéficie donc des pilotes développés pour ces deux systèmes, en plus des siens propres.

Par exemple, les pilotes wifi iaxwifi200 et idualwifi7260 proviennent de OpenBSD, tandis que ipro1000 et intel22x sont ceux de FreeBSD 14. Les couches de compatibilité reçoivent régulièrement des corrections et améliorations.

En dehors des cartes réseaux physiques, Haiku dispose d’un nouveau pilote tun permettant de créeer des tunnels réseau. Celui-ci a été développé dans le cadre du Google Summer of Code 2023, et permet par exemple d’utiliser un client OpenVPN sous Haiku.

Enfin, une évolution qui concerne tous les pilotes réseaux : le nombre de paquets et d’octets reçus et envoyés pour une interface réseau est maintenant décompté par la pile réseau, plutôt que par chaque pilote d’interface réseau. Les pilotes doivent toujours tenir à jour les compteurs d’erreurs. Ce changement permet de regrouper le code de comptage à un seul endroit, et d’éviter des comportements différents entre pilotes. En particulier, le comptage des paquets pour l’interface localhost n’était pas correct.

Périphériques d’entrée

Haiku permet d’utiliser les claviers et souris connectés en USB et en PS/2 (encore utilisé dans certains ordinateurs portables, mais il semble en voie de disparition). Les pilotes pour les touchpads et claviers i2c sont encore en cours de développement, et le Bluetooth arrivera un peu plus tard.

Commençons par le pilote PS/2. Il reçoit relativement peu d’évolutions, cependant, les ordinateurs portables récents n’implémentent plus forcément complètement le matériel nécessaire (l’interface PS/2 étant simulée par l'embedded controller). Le pilote PS/2 de Haiku qui essaie de détecter de nombreux cas de configuration possibles est parfois un peu dérouté par ces écarts. Cela pouvait provoquer un blocage empêchant d’utiliser le clavier pendant plusieurs secondes après le lancement de la machine, le temps que le pilote finisse d’énumérer les périphériques PS/2. Le problème a été corrigé en réduisant le temps d’attente avant de décider qu’il n’y a aucun périphérique connecté.

Du côté de l’USB, une première correction concerne la prise en compte de l’attribut « minimum » dans les rapports HID. Le protocole HID permet de définir toutes sortes de périphériques (claviers, souris, mais aussi clubs de golf, simulateurs de tanks…). Les périphériques USB HID envoient à l’ordinateur une description des contrôles dont ils disposent (groupes de boutons, axes, etc). Pour les boutons et touches de clavier, la valeur « minimum » indique le code du premier bouton dans le groupe, les autres étant déduits en incrémentant la valeur pour chaque bouton présent. Ce cas n’était pas bien pris en compte par le pilote de clavier, ce qui provoquait l’envoi de mauvais codes aux applications pour les claviers concernés.

D’autre part, et de façon plus spécifique, le pilote de souris bénéficie maintenant d’un quirk, c’est-à-dire d’une procédure de contournement d’un problème, pour les souris et trackballs de la marque Elecom. Ces dernières utilisent en effet toutes le même descripteur HID, indiquant la présence de 5 boutons, alors que certains modèles ont en fait un 6^me bouton non déclaré. Le descripteur est corrigé à la volée pour les périphériques concernés.

Son et image

Haiku dispose d’un pilote pour les périphériques USB Audio. Ce pilote est en développement depuis très longtemps (cela remonte avant l’apparition de l’USB 2.0), mais il n’avait jamais pu être finalisé en raison du manque de prise en charge des transferts isochrones. Ces problèmes ont enfin été corrigés, mais le pilote nécessite encore des travaux pour le rendre compatible avec plus de matériel (en particulier les périphériques implémentant la version 2.0 de la spécification USB Audio) et probablement également quelques corrections dans le serveur média pour le préparer à l’apparition et la disparition de cartes son pendant que le système est en train de tourner (actuellement, cela nécessitera un redémarrage du serveur).

Du côté des cartes son PCI, pas de grande nouveauté, mais un gros nettoyage dans le cadre de travaux pour supprimer tous les avertissements du compilateur. Ce travail se fait petit à petit, dossier par dossier dans le code de Haiku. L’analyse du dossier contenant les pilotes de cartes son a révélé l’existence de trois pilotes ciblant le même matériel, ainsi que de plusieurs fichiers qui avaient été dupliqués dans plusieurs pilotes (développés avant leur rassemblement dans le dépôt de sources de Haiku à partir du mème exemple de code), puis qui avaient divergé au cours du développement de chaque pilote. Ce code a été réunifié dans une version partagée qui inclut toutes les corrections et améliorations de chaque version.

Du côté des cartes graphiques, des travaux sont en cours pour pouvoir piloter correctement les cartes graphiques Intel de 12^me génération. Le pilote existant fonctionne déjà dans certains cas, mais se repose beaucoup sur le travail fait par le firmware (BIOS ou EFI) pour initialiser l’affichage. Il est ainsi impossible d’utiliser un écran qui n’a pas été configuré au démarrage de la machine (passer d’une sortie HDMI à l’écran d’un PC portable ou inversement, par exemple).

Machines virtuelles

Haiku est utilisé dans des machines virtuelles pour diverses raisons : à des fins de test par les développeurs, pour l’infrastructure de compilation des paquets, ou encore par des utilisateurs qui veulent le tester sans l’installer sur une machine physique dédiée.

Des pilotes spécifiques et quelques adaptations sont nécessaires pour un bon fonctionnement sur ces machines. En particulier, des pilotes sont nécessaires pour certains périphériques virtio, qui permettent aux machines virtuelles d’émuler un matériel simplifié, ne correspondant pas à un matériel réel existant. Ceci permet de meilleures performances.

Le pilote virtio de Haiku a été mis à jour pour implémenter la version 1.0 de la spécification. Cela a permis de corriger des problèmes dans le pilote virtio_block (support de stockage virtualisé).

Un nouveau pilote virtio_gpu permet l’affichage de l’écran sans avoir à passer par un pilote pour une carte graphique, ni par les pilotes VESA ou framebuffer EFI qui montrent assez vite leurs limitations (choix de résolutions d’écran limité, par exemple). Plus tard, ce pilote pourrait permettre également d’expérimenter avec la virtualisation de OpenGL, et donc d’expérimenter avec l’accélération du rendu 3D sans avoir à développer un pilote graphique capable de le faire.

Ces pilotes virtualisés facilitent également le travail de portage de Haiku vers de nouvelles architectures : il est possible de lancer Haiku dans QEMU avec n’importe quel processeur, et un ensemble de périphériques virtio pour lesquels les pilotes ont pu d’abord être testés sur une autre architecture déjà fonctionnelle.

Autres

La bibliothèque ACPICA a été mise à jour avec la dernière version 20230628, et les changements nécessaires pour son fonctionnement dans Haiku ont été intégrées en amont, ce qui facilitera les prochaines mises à jour. ACPICA est développée par Intel et permet d’implémenter la spécification ACPI, pour la gestion d’énergie, l’énumération du matériel présent sur une machine, et diverses fonctionnalités liées (détection de la fermeture d’un ordinateur portable, récupération du niveau de charge des batteries, par exemple).

Le pilote poke, qui permet aux applications de manipuler directement la mémoire physique sans l’aide d’un pilote spécifique, a été remis à jour et finalisé. Il est utile principalement pour expérimenter avec le matériel avant de développer un pilote spécifique.

La pile Bluetooth a reçu un premier coup de nettoyage. Pas de grosses évolutions pour l’instant, seules les couches les plus basses sont implémentées, on pourra au mieux énumérer les périphériques Bluetooth présents à proximité. Le développement des fonctionnalités suivantes attendra au moins la publication de la version Bêta 5.

Systèmes de fichiers

Haiku implémente plusieurs systèmes de fichiers. Celui utilisé pour le système est BFS, hérité de BeOS et qui fournit quelques fonctions indispensables à Haiku (comme les requêtes qui permettent d’indexer des attributs étendus de fichiers dans une base de données). Mais de nombreux autres systèmes de fichiers peuvent être lus, et pour certains, écrits. Cela permet de facilement partager des fichiers avec d’autres systèmes d’exploitation.

Le système de fichier UFS2 est maintenant complètement implémenté (en lecture seule), inter-opérable avec FreeBSD, et sera disponible dans l’installation de base pour les prochaines versions de Haiku.

Du côté de Linux, l’interopérabilité est possible en lecture et en écriture avec les systèmes de fichiers ext2, 3, et 4 (tous les 3 implémentés dans un seul pilote qui sait les reconnaître et les différencier). Cette implémentation a reçu quelques corrections de bugs ainsi qu’une implémentation de F_SETFL.

Enfin du côté de Windows, la prise en charge de NTFS avait déjà été mise à jour et grandement améliorée (en réutilisant les sources de NTFS-3g). Cette année, c’est le tour des systèmes de fichiers FAT. Le pilote utilisé jusqu’à maintenant avait été publié par Be il y a très longtemps. Il avait été mis à jour pour Haiku mais comportait de nombreux problèmes : mauvaise gestion des dates de modification des fichiers, interopérabilité avec d’autres implémentations, voire crash du système lors de tentative de lecture de partitions corrompues. Ce code a été entièrement remplacé par un pilote utilisant l’implémentation du FAT de FreeBSD.

Enfin, le système de fichier ramfs (pour stocker des fichiers dans la RAM de l’ordinateur de façon non persistente) a reçu des corrections sur la fonction preallocate. Cela corrige en particulier des fuites de mémoire dans les navigateurs web basés sur QWebEngine, qui utilisent ce système de fichiers pour partager de la mémoire entre plusieurs processus.

Un changement un peu plus global, et pas lié à un système de fichier spécifique, est la réunification du code pour parser les requêtes. Il s’agit d’une méthode pour rechercher des fichiers à partir de leurs attributs étendus (xattrs) qui sont indexés à la façon d’une base de données. Au départ, cette fonctionnalité était propre au système de fichier BFS, mais elle a été implémentée également pour ramfs et packagefs (système de fichier permettant d’accéder au contenu des paquets logiciels sans les décompresser). Lors du développement de ces deux nouveaux systèmes de fichiers, le code permettant de convertir une chaîne de caractères exprimant une requête en opération exécutable avait été extrait du pilote BFS pour en faire un module générique. Mais le pilote BFS n’avait pas encore été mis à jour pour utiliser ce module. C’est désormais chose faite, ce qui assure que le comportement entre les 3 systèmes de fichiers est le même, et que les corrections de bugs bénéficieront à tous les trois.

Pour terminer sur les systèmes de fichiers, l’outil fs_shell, qui permet d’exécuter le code d’un système de fichier en espace utilisateur, a reçu deux nouvelles commandes : truncate et touch. Cet outil permet de tester les systèmes de fichiers en cours de développement dans un environnement plus confortable et mieux contrôlé, et il est aussi utilisé lors de la compilation de Haiku pour générer les images disques.

Réseau

La pile réseau proprement dite a principalement évolué avec de la mise en commun de code. Par exemple, l’implémentation de l’ioctl FIONBIO (non standardisé, mais largement implémenté) pour passer un descripteur de fichier en mode non bloquant a été réécrite pour partager du code avec le flag O_NONBLOCK configurable par fcntl et F_SETFL. Également, le flag MSG_PEEK qui permet de lire des données d’un socket sans les retirer de son buffer de réception, est maintenant implémenté directement par la pile réseau au lieu d’avoir une version spécifique à chaque type de socket.

Sockets UNIX

Les sockets de la famille AF_UNIX sont utilisés pour les communications locales entre applications sur une même machine. Ils sont en particulier utilisés par WebKit et de nombreux autres moteurs de rendu web, mais assez peu par les applications natives pour Haiku, qui disposent d’autres méthodes de communications (en particullier les BMessage et les ports).

L’implémentation des sockets UNIX est maintenant complète et suffisante pour faire fonctionner toutes les applications qui en ont l’utilité.

 TCP

La pile TCP de Haiku est devenue au fil du temps un goulot d’étranglement des performances. D’une part parce que toutes les autres parties du système se sont améliorées, et d’autre part parce que les interfaces réseaux sont de plus en plus rapides et de plus en plus sollicitées.

Le travail sur la pile TCP cette année a commencé par la remise en route de l’outil tcp_shell, qui permet de tester l’implémentation de TCP en espace utilisateur et en isolation du reste du système. Cet outil avait été utilisé au tout début du développement de la pile TCP, mais n’avait pas été tenu à jour depuis. Il permet maintenant de tester la pile TCP communiquant avec elle-même, et aussi d’injecter des paquets à partir de fichier pcap. Pour l’instant, la fonction permettant de communiquer avec l’extérieur n’a pas été remise en place.

Cet outil a permis d’identifier et d’analyser certains des problèmes rencontrés.

Le premier problème était un envoi d’acquittements TCP en double. À première vue, cela ne devrait pas poser de gros problèmes, il y a seulement un peu de redondance. Mais, en pratique, une implémentation de TCP qui reçoit des acquittements en double suppose qu’il y a eu un problème de congestion réseau lors de l’envoi de données dans l’autre sens. Les algorithmes de contrôle de la congestion se mettent en jeu, et le trafic ralentit pour éviter une congestion qui n’existe pas. Par exemple, la taille de la fenêtre de transmission TCP (le nombre maximum d’octets qui peuvent être envoyés sans attendre d’acquittement) peut être réduite.

Et, malheureusement, cela déclenche un autre problème : la taille de cette fenêtre peut atteindre 0 octet, et dans ce cas, HAiku ne s’autorisait plus à émettre aucun paquet. Cela pouvait se produire au même moment dans les deux directions sur une connexion TCP, ce qui fait qu’aucune des deux machines connectées ne s’autorise à envoyer de données à l’autre. Ce problème a été corrigé, les transmissions peuvent maintenant continuer à débit réduit, puis reprendre une vitesse optimale petit à petit.

Après ces corrections, une mesure des performances de TCP dans un environnement de test montre que la pile TCP est capable de traiter jusqu’à 5.4 Gbits/s de trafic, alors que le débit plafonnait à 45 Mbits/s auparavant. C’est donc un centuplage des performances.

Autres

Plusieurs autres évolutions diverses dans le noyau :

L’implémentation de kqueue, ajoutée l’année dernière, a reçu plusieurs corrections et améliorations. Elle couvre déjà plusieurs usages et permet l’utilisation de plus de logiciels portés depuis d’autres systèmes, mais les cas d’utilisation les plus avancés ne sont pas encore tout à fait fonctionnels.

Pour rappel, kqueue est une fonction des systèmes BSD permettant à un thread utilisateur de se mettre en attente de plusieurs types d’évènements et de ressources du noyau. L’usage est similaire à celui de epoll sous Linux mais l’API est différente.

La classe ConditionVariable, utilisée pour la synchronisation entre threads et interruptions dans le noyau, a reçu plusieurs mises à jour. Un article sur le site de Haiku détaille l’utilisation et le fonctionnement de cette classe.

La boucle principale du débugger noyau (KDL), qui prend la main sur tous les processeurs en cas de crash du système ou sur demande de l’utilisateur pour investiguer des problèmes, inclus maintenant une instruction PAUSE. Cela permet d’informer le CPU qu’il n’est pas nécessaire d’exécuter cette boucle à la vitesse maximale, évitant de faire surchauffer la machine sans raison. Cette boucle est principalement en attente d’instructions de l’utilisateur, via un clavier ou un port série.

Du refactoring sur les parties du code qui sont spécifiques à chaque architecture : arch_debug_get_caller est maintenant implémenté via un builtin gcc plutôt que du code assembleur à écrire à la main pour chaque machine. arch_debug_call_with_fault_handler appelait une fonction avec un mauvais alignement de pile sur x8_64, pouvant conduire à un crash si la fonction appelée utilisait des instructions SSE par exemple. Correction également d’un problème qui pouvait causer la perte d’une interruption inter-CPU (permettant à un cœur de processeur d’interrompre l’exécution de code en cours sur un autre cœur) dans certains cas.

Une modification sur la gestion des descripteurs de fichiers: la structure interne des descripteurs de fichiers était pourvue d’un champ indiquant le type (fichier, socket, pipe…). Ce champ et tout le code qui en dépendait ont été supprimés. Ceci permet à des add-ons du kernel de déclarer leurs propres types de fichiers sans avoir à modifier le noyau. Cela pourrait par exemple être utile pour développer une couche de compatibilité avec Linux, qui fait un usage généreux des descripteurs de fichiers de tous types (eventfd, signalfd, timerfd…).

Réécriture du code de debug activé par l’option B_DEBUG_SPINLOCK_CONTENTION qui permet d’investiguer les problèmes de performances liés à l’utilisation de spinlocks (attente active sur une interruption matérielle).

Un petit changement d’algorithme sur l’allocateur de pages du noyau. Cet allocateur alloue des pages mémoires par blocs multiples de 4Ko. Les pages libérées étaient réinsérées une par une dans une liste chaînée. Cela conduit à insérer les pages dans l’ordre inverse de leurs adresses (la dernière page d’une zone mémoire se retrouve au début de la liste). Lors des prochaines allocations, cette page se retrouve donc allouées en premier, puis celle qui se trouve juste avant, et ainsi de suite. La zone mémoire construite par toutes ses pages est donc considérée comme discontinue. En inversant l’ordre d’insertion des pages dans la liste, on préserve les pages dans un ordre globalement croissant d’adresse mémoire, et on augmente les chances qu’une allocation de plusieurs pages se trouve avec des pages contiguës et dans le bon ordre. Cela est utile en particulier pour les allocations qui vont être utilisées pour des transferts DMA: il sera possible de programmer un seul gros transfert DMA au lieu de plusieurs petits.

L’état de la FPU du processeur n’était pas complètement sauvegardé lors d’un changement de contexte. Certains drapeaux de configuration pouvaient donc rester positionnés avec les valeurs configurées par un thread, pendant l’exécution d’un autre. Au mieux cela donnait des résultats inattendus, au pire, un crash (par exemple si le FPU est configuré pour lever une exception matérielle, dans un thread qui ne s’y attend pas). Le nouveau code de sauvegarde utilise des instructions dédiées qui sauvegardent d’un coup tout l’état du FPU, ce qui fait qu’en plus de fonctionner correctement, il est plus rapide que ce qui était fait précédemment.

Une évolution sur les sémaphores: la fonction release_sem_etc permet de donner une valeur négative au paramètre « count ». Dans ce cas, le thread qui était en attente d’un acquire_sem sera réveillé, mais la fonction acquire_sem retournera une erreur indiquant que le sémaphore n’a pas pu être obtenu. Cela permet de simplifier un peu le code de certaines utilisations classiques des sémaphores.

Une correction de bug sur le code traitant les « doubles fautes ». Le fonctionnement d’un système d’exploitation est en partie basé sur l’interception des « fautes », par exemple, un programme qui essaie d’accéder à de la mémoire qui a été évacuée dans la swap. Cette mémoire n’est pas immédiatement accessible, le programme est donc interrompu, le noyau prend la main, va récupérer cette mémoire, puis rend la main au programme qui n’y voit que du feu et continue son exécution comme si de rien n’était. Les fautes peuvent également se produire dans le cas où un programme essaie d’accéder à une zone mémoire non allouée, on aura alors une erreur de segmentation.

Tout ça est très bien, mais que se passe-t-il si le code qui traite ces problèmes déclenche lui-même une faute ? C’est prévu : il existe un deuxième morceau de code qui va intercepter ces problèmes et tout arrêter pour lancer le debugger noyau, et permettre à un humain d’examiner la situation.

Oui, mais que se passe-t-il si ce code déclenche lui-même une faute ? C’est ce qu’on appelle une triple faute, dans ce cas, la solution de dernier recours est d’immédiatement redémarrer la machine.

Des utilisateurs se sont plaints de redémarrages intempestifs, et une étude attentive du code traitant les doubles fautes a révélé un problème qui déclenchait systématiquement une triple faute (difficile à analyser, car on n’a pas de journaux ou de moyen d’investiguer le problème). Espérons que l’accès au debugger noyau lors des doubles fautes permettra désormais de comprendre d’où elles proviennent.

Tout autre sujet, le noyau dispose maintenant d’APIs pour configurer l’affinité des threads, par exemple pour interdire à un thread de s’exécuter sur certains cœurs de processeurs. Cela peut être utile sur des machines avec des processeurs hétérogènes (par exemple ARM BIG.Little), ou encore si le développeur d’une application pense pouvoir faire mieux que l’ordonnanceur par défaut pour répartir ses threads sur différents cœurs.

Pour terminer sur les évolutions dans le noyau, la calibration du TSC peut maintenant être faite à partir d’informations obtenues via l’instruction CPUID. Le TSC est un compteur de cycles qui s’incrémente à une vitesse plus ou moins liée à la fréquence du processeur. Il est utile de connaître la durée en microsecondes ou nanosecondes d’un « tick » du TSC pour différents usages. Historiquement, cette durée est calculée en utilisant le Programmable Interval Timer, un composant présent dans les ordinateurs compatibles PC depuis le tout début. Ce composant n’a plus beaucoup d’autres utilités aujourd’hui, et certains chipsets ne l’implémentent plus, ou pas correctement. Ou encore, dans les machines virtuelles, l’émulation du processeur (virtualisé) n’est pas forcément exécutée de façon synchrone avec celle du timer, rendant cette mesure peu fiable. L’instruction CPUID permet de récupérer l’information de façon plus directe. Un changement similaire dans FreeBSD donne un bon aperçu de la situation.

Portages ARM, RISC-V et autres

Historiquement, Haiku est développé en premier pour les machines x86 32-bit. Une version 64 bit est apparue en 2012. D’autres versions pour les processeurs PowerPC, ARM (32 et 64 bits), RISC-V, Sparc ou encore Motorola 68000 sont dans des états d’avancement divers. Les versions ARM et RISC-V sont actuellement celles qui reçoivent le plus d’attention des développeurs. Il existe un fork de Haiku qui est entièrement fonctionnel sur certaines machines RISC-V, les changements sont intégrés petit à petit avec pas mal de nettoyage à faire.

Une des problématiques pour ces nouvelles architectures est la procédure de « bootstrap ». Pour gagner du temps et simplifier la procédure, la compilation de Haiku se base sur un certain nombre de dépendances qui sont pré-compilées depuis une machine fonctionnant sous Haiku. Cela permet de ne pas avoir à compiler des douzaines de bibliothèques tierces, avec un environnement de compilation peu contrôlé (on peut compiler Haiku depuis un système Haiku, depuis un grand nombre de distributions Linux, depuis Mac OS, depuis un BSD, ou même depuis Windows avec WSL).

Cependant, lors du développement de Haiku pour une nouvelle architecture, ces paquets précompilés ne sont bien entendu pas encore disponibles. Il est donc nécessaire d’utiliser une procédure de « bootstrap », qui va se baser sur un autre système et compiler ce qui est nécessaire en compilation croisée, pour aboutir à un système Haiku réduit au minimum de fonctionnalités, juste de quoi pouvoir lancer l’outil haikuports, qui va lui-même ensuite compiler tous les autres paquets.

Ce processus est assez complexe, et a été laissé un peu à l’abandon. Il a été récemment remis en route, avec des corrections de bugs dans l’outil haikuporter, des mises à jour dans les paquets cross-compilés (par exemple pour passer de Python 2 à Python 3), et divers autres petits problèmes. Il est maintenant à nouveau possible de construire une image disque de bootstrap au moins pour la version PowerPC.

Le portage RISC-V a reçu une mise à jour vers gcc 13 (c’était déjà le cas pour les autres architectures) et a pu être utilisé pour compiler LLVM puis Mesa (l’intégration dans la ferme de compilation de Haikuports n’est pas encore en place, donc ces compilations doivent être faites par un développeur qui lance les commandes haikuports nécessaire et patiente longtemps pendant la compilation de ces gros projets).

Les versions 68000 et PowerPC ont été un peu dépoussiérées, mais il manque toujours un certain nombre de pilotes matériels de base pour pouvoir les utiliser sur de vraies machines et même dans une certaine mesure dans QEMU (ce dernier permettant d’émuler une machine utilisant de nombreux périphériques VirtIO, ce qui pourrait simplifier un peu les choses).

La bibliothèque libroot a reçu plusieurs mises à jour dans les parties qui nécessitent du code spécifique à chaque architecture, pour ajouter en particulier le RISC-V, et au passage plusieurs autres familles de processeurs.

Une partie de Haiku qui nécessite de grosses évolutions est la gestion des bus PCI. Le pilote existant supposait la présence d’un BIOS pour effectuer la découverte du bus, ou pouvait également utiliser des tables ACPI, mais d’une façon un peu limitée, qui repose tout de même sur le BIOS ou un quelconque firmware pour assigner des adresses valides à toutes les cartes PCI. Un problème identifié depuis longtemps puisqu’il s’agit du bug numéro 3 dans l’outil de suivi de bugs de Haiku. Ce bug fêtera ses 20 ans en mars prochain, espérons qu’il soit corrigé d’ici là. Les choses avancent, puisque le pilote PCI va maintenant s’attacher correctement aux nœuds ACPI correspondants dans le device tree, ce qui permet ensuite d’interroger ACPI pour découvrir les plages d’adresses mémoires disponibles pour l’allocation d’une adresse à chaque carte PCI connectée. Du côté des nouveaux ports de Haiku, cela va également permettre d’avoir plusieurs bus PCI « racine » indépendants. Et ces développements pourraient également Être utiles pour une prise en charge complète de Thunderbolt et USB 4.

Un autre pilote qui sera utile pour les versions ARM et RISC-V est le pilote SDHCI, qui permet de s’interfacer avec les lecteurs de cartes SD ainsi que les modules eMMC. Initialement destiné uniquement aux modules connectés sur un bus PCI, le pilote a été conçu pour être facilement extensible, et permet maintenant d’utiliser également les contrôleurs SDHCI exposés via ACPI. Cependant, le pilote a encore quelques problèmes de fiabilité, et il manque une implémentation des commandes nécessaiers pour les modules eMMC, qui partagent le même protocole de communication que les cartes SD, mais utilisent un jeu de commandes différent (il y a une petite guerre de standards, le format SD s’est imposé pour les cartes amovibles, mais MMC qui n’a pas de royalties a pu prendre le marché des modules soudés sur les cartes mères, où l’interopérabilité avec le matériel existant ne pose pas autant problèmes).

Le portage sur ARM64 avance petit à petit, il parvient à démarrer une partie de l’espace utilisateur et a reçu dernièrement des corrections sur le code permettant les changements de contexte entre différents threads. L’affichage du bureau complet pour la première fois sur une machine ARM64 ne devrait donc plus être très loin.

Bootloader

Le démarrage de Haiku est pris en charge par un bootloader spécifique nommé haiku_loader. Contrairement au noyau Linux, qui peut s’initialiser tout seul quasiment dès le démarrage du matériel, le noyau de Haiku a besoin que son bootloader prépare une grande partie de l’environnement (activation de la mémoire virtuelle, initialisation de l’affichage et mise en place du « splash screen », par exemple). Le bootloader prend en charge toutes ces tâches et permet en plus de configurer des options de démarrage via un menu en mode texte, de démarrer via le réseau, d’utiliser un snapshot plus ancien du système si une mise à jour s’est mal passée.

Le bootloader a peu évolué cette année, le changement principal étant la suppression de logs de warning lors du chagement de fichiers ELF, pour les sections non traitées PT_EH_FRAME (généré par les versions modernes de gcc) ainsi que d’autres sections spécifiques aux processeurs RISC-V qui ne nécessitent pas de traitement spécifique dans ce cas.

Amélioration de performances

Beaucoup de travail a été fait sur l’amélioration des performances. C’est un sujet qui a été un peu laissé de côté au début du développement de Haiku. Le premier but était de faire fonctionner les choses, avant de les rendre plus rapides. Maintenant que les développements sont assez avancés, il est temps de commencer à étudier ce problème et à essayer de se rapprocher des perfomances d’autres systèmes.

Implémentation des IO vectorisées sur les périphériques de type bloc

Lorsqu’on veut lire ou écrire sur un disque, il faut envoyer une commande pour accéder à des secteurs consécutifs. Dans le cas normal, c'est le cache du système de fichiers qui se charge de regrouper les différents accès et de les ordonnancer de façon optimale.

Mais il y a un cas particulier pour les accès directs au disque. Par exemple, si on ouvre le disque directement (via son device dans /dev/disk/) ou encore lorsqu’un système de fichier veut écrire son journal (qui ne passe pas par le cache). Les écritures dans le journal sont faites avec des accès vectorisés (via readv ou writev) qui contiennent chacun une liste d’endroits où lire ou écrire des données. Ces accès étaient implémentés sous forme d’une boucle appelant plusieurs fois read ou write. Maintenant, la liste est directement transmise au pilote de disque qui peut ainsi mieux traiter ces accès.

Réparation du profiler

Haiku dispose d’un outil de profiling, mais celui-ci ne fonctionnait plus et retournait des données incohérentes. Plusieurs problèmes ont été corrigés pour faciliter les mesures de performances et vérifier que les optimisations rendent réellement les choses plus rapides.

Réduction des verrouillages du device manager

Le problème initial qui a conduit à ces améliorations était la lenteur du lancement de nouveaux processus. Un goulet d’étranglement qui a été identifié est le verrouillage du device_manager pour accéder au périphérique /dev/random pour initialiser le stack protector (qui a besoin d’écrire des valeurs aléatoires sur la pile). Toutes les ouvertures de fichiers dans /dev nécessitent d’acquérir un verrou qui empêche l’exécution en parallèle avec de nombreuses autres tâches liées aux périphériques matériels.

Le problème a été corrigé de deux façons : d’abord, le stack protector utilise une API permettant de générer des nombres aléatoires sans ouvrir de fichier dans /dev. D’autre part, une analyse a montré que la pile USB passait beaucoup de temps à exécuter du code en ayant verrouillé l’accès au device manager. Ce code a été modifié pour libérer le verrou plus souvent.

DT_GNU_HASH dans les fichiers ELF

Un autre aspect assez lent du lancement de processus est le chargement des bibliothèques et la recherche des symboles dans ces bibliothèques. Pour identifier si une bibliothèque contient un symbole, la recherche se fait par un hash du nom de la fonction recherchée.

Historiquement, c’est la section DT_HASH qui est utilisée, mais les utils GNU implémentent également DT_GNU_HASH, qui utilise une meilleure fonction de hash et ajoute également un bloom filter qui permet de tester très rapidement, mais de façon imparfaite, la présence d’un symbole dans une bibliothèque.

Le chargeur de bibliothèques de Haiku sait maintenant utiliser les tables DT_GNU_HASH, mais ce n’est pas encore déployé car les gains de performances ne justifient pas l’augmentation de taille des bibliothèques (il faut stocker les tables dans l’ancien et dans le nouveau format). Il sera toutefois possible de l’ajouter au cas par cas sur les bibliothèques où le gain est important (par exemple s’il y a beaucoup de symboles).

premapping de mmap

La fonction mmap permet de mapper un fichier directement en mémoire. Les écritures en mémoire sont ensuite directement enregistrées sur disque. Il n’est pas souhaitable de charger tout le fichier d’un coup au moment de l’appel à mmap, ce serait trop lent. Mais il ne fait pas non plus attendre que le logiciel accède à cette mémoire et remplir les données au goutte-à-goutte (ou plus précisément, une page de 4Kio à la fois).

Un cas particulier est le traitement des bibliothèques partagées, qui sont chargées en mémoire de cette façon. Dans ce cas, le fichier est probablement déjà chargé quelque part en mémoire pour un autre processus, et il devrait être possible de réutiliser les mêmes données. Le code testant cette possibilité ne fonctionnait pas à tous les coups, ce qui fait que des fichiers qui auraient pu être mappés tout de suite, ne l’étaient pas.

Une autre amélioration est d’utiliser plusieurs allocateurs séparés pour chaque processeur, pour réduire les blocages entre différents threads qui ont besoin de manipuler des pages de mémoire.

Suppression des zones mémoire

Les applications Haiku peuvent créer des zones de mémoires (appelées areas) qui disposent d’un identifiant unique et peuvent être partagées avec d’autres processus.

Lorsqu’une application s’arrête, il faut supprimer toutes les areas qui ont été créées. Cela était fait par une simple boucle supprimant ces zones une par une. Mais cela pose un problème: chaque suppression doit verrouiller la liste des areas puis la déverrouiller. Le code a été modifié pour verrouiller la liste une seule fois et retirer de la liste toutes les zones d’un seul coup, avant de faire les autres opérations de suppression qui n’ont pas besoin d’accéder à la liste.

Au total, toutes ces améliorations conduisent à une amélioration des performances de plus de 25% sur un test en conditions réelles (compilation d’une partie des sources de Haiku).

Calcul des sommes de contrôles des paquets réseau par le matériel

Dans un autre domaine, une perte de temps conséquente est le calcul des checksums pour les paquets réseau reçus et envoyés. En effet, ce calcul était fait systématiquement par le logiciel, même si le matériel est capable de s’en charger. Il est maintenant possible pour les pilotes réseaux qu’ils sont capables de vérifier et de générer ces checksums par eux-mêmes, et ainsi la pile réseau peut s’en dispenser. Cela permet aussi de se passer entièrement de checksums sur les interfaces localhost, qui ne devraient pas subir de corruption de paquets, et ne gagnent rien à cette vérification.

Cela a été également l’occasion de supprimer quelques copies des données des paquets réseau.

user_mutex

La structure user_mutex joue un rôle similaire aux futex de Linux. Elle est utilisée pour implémenter, par exemple, pthread_mutex et pthread_rwlock. L’implémentation avait plusieurs bugs (race conditions), et a été remplacée par un nouveau système plus efficace.

Au total, toutes ces améliorations permettent des performances 25% meilleures que la version beta 4 de Haiku. Il reste cependant de quoi faire, puisque certains benchmarks (compilation d’une partie du code source de Haiku) restent près de deux fois plus lent que l’opération équivalente sous Linux.

Chaîne de compilation

Haiku est compilé avec gcc, ld et les binutils. Ils nécessitent tout trois un petit nombre de patchs maintenus dans un dépôt git dédié et reversés dans les versions upstream autant que possible. Une version de gcc 2.95.3 est également utilisée pour les parties du système assurant encore la rétro compatibilité avec BeOS, les versions plus récentes utilisent un mangling différent et ne sont pas inter opérables.

L’outil de compilation utilisé est Jam, développé à l’origine par Perforce et dont il existe plusieurs forks dont un maintenu par Boost et un autre par Freetype. Haiku utilise sa propre version de Jam avec de nombreuses évolutions.

Commençons la liste des changements dans cette section avec des mises à jour de dépendances : Haiku est maintenant compilé avec GCC 13.2 (la version 14 sera intégrée prochainement). La bibliothèque ICU utilisée pour implémenter toutes les fonctions d’internationalisation (qui se trouve donc avoir un rôle assez important dans la bibliothèque C standard) a été mise à jour en version 74.

Le travail pour supprimer tous les avertissements du compilateur se poursuit petit à petit, mais les problèmes restants sont de plus en plus difficiles à corriger, soit parce qu’il s’agit de code tiers (qu’il est plus facile de garder en l’état pour le synchroniser avec de nouvelles versions), soit parce que l’avertissement ne peut pas être corrigé proprement sans perte de performance, ou encore d’une façon qui contente à la fois gcc 13 et gcc 2 pour les parties du code compilées avec ces deux versions.

On peut toutefois mentionner que tous les trigraphes présents dans le code (par accident, par exemple il est facile d’écrire « ??! » dans un commentaire) ont été supprimés. Ils ne sont plus disponibles dans C++ à partir de la version 17 et génèrent des erreurs de compilation.

D’autre part, l’option de compilation -Wno-error=deprecated a pu être désactivée, car plus aucun code ne déclenche cette erreur.

Puisqu’on parle d’options de compilation : l’optimisation « autovectorisation » pour la compilation du noyau a été désactivée pour l’instant. Cette option fait que le code utilise des instructions SSE, et faire cela dans le noyau problématique pour la plupart des machines virtuelles (QEMU, VMWare et Virtual Box). La plupart des autres noyaux n’utilisent pas ces instructions, ce qui fait que des bugs dans les hyperviseurs sont tout à fait possibles, par manque de tests. Mais le problème pourrait aussi venir de Haiku. L’investigation est, pour l’instant, remise à plus tard.

Un dernier changement dans le système de build consiste à permettre l’utilisation de git worktree. Quelques commandes git sont utilisées lors de la compilation pour calculer le numéro de version du code en train d’être compilé, et ça ne fonctionnait pas correctement dans ce cas de figure.

Haiku est un système d’exploitation libre destiné aux ordinateurs personnels ou de bureau (pas de serveurs, pas de systèmes embarqués, pas de tablettes ni de téléphones). Il s’agit au départ d’une réécriture libre de BeOS, préservant la compatibilité binaire avec ce dernier (les applications BeOS peuvent tourner sur certaines versions de Haiku).

Le projet Haiku (au départ nommé OpenBeOS) a démarré officiellement le 18 août 2001 avec le premier message sur la liste de diffusion : Ok, let's start (OK, allons-y). Cet anniversaire est l’occasion de faire un point sur les développements de l’année dans Haiku et ce qui est en préparation.

La dépêche a été un peu retardée cette année, pour être synchronisée avec la version R1 bêta 5 de Haiku, publiée le vendredi 13 septembre 2024.

Le projet emploie un développeur presque à plein temps depuis 2021 et le reste de l’équipe contribue bénévolement. La dernière version bêta a été publiée fin 2023 et la Bêta 5 est désormais disponible : l’occasion de revenir en trois parties sur ce que propose Haiku, d’abord des applications, un noyau et des améliorations de la documentation.

Sommaire

• Applications
  • AboutSystem
  • CharacterMap
  • CodyCam
  • Debugger
  • Deskbar
  • GLTeapot
  • HaikuDepot
  • Icon-O-Matic
  • Magnify
  • MediaPlayer
  • PowerStatus
  • SerialConnect
  • ShowImage
  • Terminal
  • Tracker
  • TV
  • WebPositive
  • Zip-O-Matic
  • Haikuports
    • Applications natives
    • Applications portées
• Panneaux de préférences
  • Appearance
  • Keymap (disposition clavier)
  • Screen (Affichage)
• Outils en ligne de commande
  • df
  • filteredquery
  • ping, traceroute, telnet, ftpd
  • pkgman
  • strace
  • whence
• Serveurs
  • app_server
  • input_server
  • registrar
• Kits
  • Interface
    •  BColumnListView
    • BTextView
    • BMenu
    •  BSpinner
    • rgb_color
  • Locale
  • Media
  • Support
    • BDataIO
• Bibliothèques C
  • Libroot
  • Libnetwork
  • LibBSD
  • LibGNU

Près de 350 tickets ont été clos dans le cadre du travail sur la version R1 bêta 5. Il y a bien sûr de très nombreuses corrections de bugs, qui ne seront pas listées dans cet article. On se concentrera plutôt sur les nouveautés, sauf dans les cas où la correction est vraiment importante ou permet d’ouvrir de nouvelles possibilités d’utilisation.

Applications

Haiku est un système d’exploitation complet, fourni avec un certain nombre d’applications permettant d’accomplir les tâches les plus courantes. En plus de ces applications de base, le gestionnaire de paquets HaikuDepot, alimenté principalement par le travail du projet HaikuPorts, apporte à la fois des applications portées depuis d’autres systèmes et des applications développées spécifiquement pour Haiku.

De façon générale, on trouve cette année dans les applications de Haiku des améliorations sur le rendu des nombres, l’utilisation d’un symbole de multiplication à la place d’une lettre x là où c’est pertinent, et de nombreuses petites corrections et améliorations sur la mise en page des fenêtres, des corrections de problèmes de traduction et ainsi de suite.

AboutSystem

AboutSystem est la fenêtre d’information sur le système Haiku. Elle fournit quelques informations sur la machine sur laquelle le système fonctionne (quantité de RAM, marque et modèle du CPU, uptime) ainsi que les noms des développeurs et autres logiciels libres ayant participé au développement de Haiku.

Cette application reçoit tout d’abord une mise à jour cosmétique : si le système est configuré en « mode sombre », le logo Haiku correspondant (avec un lettrage blanc et des dégradés de couleurs un peu différents) sera utilisé. Sinon, ce sera le logo avec lettrage noir.

Elle reçoit également quelques mises à jour de contenu : en plus de l’ajout de quelques nouveaux contributeurs qui ont rejoint le projet, on trouvera maintenant un lien vers la page web permettant de faire un don à Haiku. Plusieurs liens vers des bibliothèques tierces utilisées dans Haiku, qui ne fonctionnaient plus, ont été soit supprimés, soit remplacés par des liens mis à jour.

Enfin, il est désormais possible d’utiliser AboutSystem comme un « réplicant », c’est-à-dire de l’installer directement sur le bureau pour avoir en permanence sous les yeux les statistiques sur l’utilisation mémoire et l’uptime ainsi que le numéro de build de Haiku en cours d’exécution (ce qui peut être utile par exemple lorsqu’on lance beaucoup de machines virtuelles avec des versions différentes de Haiku pour comparer un comportement, ou si on veut stocker des captures d’écran de plusieurs versions et s’y retrouver facilement).

CharacterMap

L’application « table de caractères » permet d’étudier de près les différents glyphes et symboles présents dans une police de caractères. En principe, elle permet de choisir une police spécifique, mais le serveur graphique de Haiku substitue automatiquement une autre police si on lui demande d’afficher un caractère qui n’est pas disponible dans la police demandée.

Cela peut être gênant dans certains contextes, par exemple si on envisage d’embarquer une police dans un fichier PDF, il est difficile de savoir quelle police contient vraiment les caractères qu’on veut utiliser.

L’application a été améliorée pour traiter ce cas et affiche maintenant ces caractères en grisé.

CodyCam

CodyCam est une application permettant de tester une webcam et de l’utiliser pour envoyer périodiquement des images vers un serveur HTTP.

L’évolution principale a été la mise à jour de l’icône de l’application. L’utilité de CodyCam est limitée par le manque de pilotes : il faudra soit trouver une webcam Sonix du début des années 90, seul modèle USB à disposer d’un pilote fonctionnel, soit utiliser un ordiphone Android équipé d’un logiciel permettant de le transformer en caméra IP (ou encore une vraie caméra IP).

Le pilote pour les WebCams UVC — standard utilisé pour les caméras USB modernes — n’est pas encore au point et n’est pas inclus dans les versions publiées de Haiku.

Debugger

Debugger est, comme son nom l’indique, le debugger de Haiku. Il est développé spécifiquement pour le projet sans s’appuyer sur les outils existants (gdb ou lldb). Il dispose à la fois d’une interface graphique et d’une interface en ligne de commande, plus limitée. Cette dernière est surtout utilisée pour investiguer des problèmes dans les composants de Haiku qui sont nécessaires pour l’utilisation d’une application graphique : app_server, input_server ou encore registrar.

La version en ligne de commande a reçu quelques petites améliorations, mais la principale nouveauté est la prise en charge des formats DWARF-4 et DWARF-5 pour les informations de debug. Cela permet de charger les informations générées par les versions modernes de GCC, sans avoir besoin de forcer la génération d’une version plus ancienne du format DWARF.

Le désassembleur udis86, qui n’est plus maintenu et ne reconnaît pas certaines instructions ajoutées récemment dans les processeurs x86, a été remplacé par Zydis.

Enfin, un bug assez gênant a été corrigé : si une instance de Debugger était déjà en train de débugger une application et qu’une deuxième application venait à planter, il n’était pas possible d’attacher une deuxième instance de Debugger à cette application. Les problèmes impliquant plusieurs processus pouvaient donc être un peu compliqués à investiguer. C’est maintenant résolu.

Deskbar

L’application DeskBar fournit la « barre des tâches » de Haiku. Elle permet de naviguer entre les fenêtres et applications ouvertes, de lancer de nouvelles applications via un menu (similaire au « menu démarrer » de Windows), ou encore d’afficher une horloge et des icônes fournis par d’autres applications (sous forme de réplicants).

Elle fait partie, avec le Tracker, des applications qui ont été publiées sous license libre lors de l’abandon de BeOS par Be Inc.

Quelques changements dans la DeskBar :

• Tous les menus utilisent maintenant la police « menu » choisie dans les préférences d’apparence du système. Auparavant, la police « menu » et la police « plain » étaient mélangées. Ces deux polices étant identiques dans la configuration par défaut, le problème n’avait pas été repéré.
• Si un nom de fenêtre est tronqué dans la liste des fenêtres, le nom complet peut être affiché dans une infobulle.
• L’icône pour les fenêtres dans la DeskBar a été remplacée. La nouvelle icône indique plus clairement si une fenêtre se trouve dans un autre bureau virtuel (dans ce cas, activer cette fenêtre provoquera un changement de bureau).

GLTeapot

GLTeapot est une application permettant de tester le rendu OpenGL, en affichant un modèle 3D de la théière de l’Utah.

En plus de la théière, cette application affiche un compteur du nombre d’images affichées par secondes. Bien que les chiffres affichés ne soient pas du tout représentatifs des performances d’un rendu 3D réaliste, certains utilisateurs insistent lourdement pour pouvoir faire le concours de gros chiffres de nombre d’images par seconde.

Il est donc à nouveau possible de désactiver la synchronisation sur le rafraîchissement de l’écran, et demander au processeur de réafficher la théière plusieurs centaines de fois par seconde, bien que l’écran soit incapable de suivre le rythme. Par défaut, la synchronisation est activée et le rafraîchissement ne dépassera jamais 60 FPS, si toutefois le pilote graphique implémente les fonctions de synchronisation nécessaires.

HaikuDepot

HaikuDepot est un hybride entre un gestionnaire de paquets et un magasin d’applications.

Il se compose d’un serveur (développé en Java) fournissant une API REST et permettant de collecter les informations sur les applications (icônes, captures d’écrans, catégories, votes et revues des utilisateurs, choix de la rédaction pour les applications mises en avant…), d’un frontend web minimaliste et d’une application native C++ permettant d’afficher ces données.

La principale nouveauté est l’intégration du système de single-sign-on (SSO) permettant d’utiliser un compte utilisateur commun avec d’autres services en ligne de Haiku. Actuellement, l’outil de revue de code Gerrit
utilise ce même compte, mais ce n’est pas encore le cas pour Trac (outil de suivi des bugs) ni pour le forum. Ce sera mis en place plus tard.

De façon peut-être moins visible, mais pas moins importante, le code C++ de l’application a reçu de nombreuses améliorations et optimisations « sous le capot », rendant l’application plus rapide et plus fiable, mais qui sont un peu difficiles à résumer dans le cadre de cette dépêche.

Enfin, l’apparence de l’application a été légèrement retravaillée pour mieux s’adapter aux écrans à haute définition (ce qui nécessite d’avoir des marges et espacements de taille dynamique en fonction de la taille de texte choisie par l’utilisateur).

Icon-O-Matic

Icon-O-Matic est un éditeur d’icônes. Il permet d’exporter les fichiers au format HVIF, un format vectoriel compact qui permet de stocker les icônes dans l’inode d’en-tête des fichiers pour un chargement et un affichage rapide.

Cette application a bénéficié du travail de Zardshard pendant le Google Summer of Code 2023, elle a donc reçu plusieurs évolutions et corrections importantes (dont certaines sont mentionnées dans la dépêche anniversaire de l’année dernière).

Citons en particulier l’ajout d’un nouveau type de transformation, « perspective », qui permet de facilement déformer un ensemble de chemins vectoriels selon une projection de perspective, ce qui est assez utile pour concevoir plus facilement une icône avec un aspect tridimensionnel (bien qu’en pratique l’apparence habituelle des icônes de Haiku soit un intermédiaire entre une projection perspective et une vue isométrique, ne se prêtant pas forcément à l’utilisation de cette opération de transformation purement mathématique).

Une autre petite amélioration est l’ajout d’une vérification pour empêcher la fenêtre de Icon-O-Matic de se positionner en dehors de l’écran, par exemple si on a déplacé la fenêtre vers le bas de l’écran, enregistré cette position, puis relancé l’application dans une résolution d’écran plus réduite. Dans ce cas, la fenêtre sera automatiquement ramenée dans la zone visible de l’affichage.

Magnify

L’application Magnify permet d’afficher une vue zoomée d’une partie de l’écran. Elle peut servir pour améliorer l’accessibilité (mais n’est pas idéale pour cet usage), mais aussi pour les développeurs d’interfaces graphiques qui ont parfois besoin de compter les pixels pour s’assurer que leurs fenêtres sont bien construites.

En plus de l’affichage zoomé, l’application permet d’afficher l’encodage RGB de la couleur d’un pixel, ou encore de placer des « règles » permettant de vérifier l’alignement des objets. Ces dernières ont reçu une petite mise à jour, avec une amélioration de l’affichage de leur largeur et hauteur pour les rendre plus lisibles.

MediaPlayer

L’affichage des sous-titres ne fonctionnait pas correctement, il manquait une partie du texte. C’est maintenant corrigé.

PowerStatus

L’application PowerStatus permet de surveiller l’état de la batterie pour les ordinateurs qui en disposent.

Elle a reçu plusieurs améliorations importantes :

Une notification a été ajoutée pour un niveau de décharge très faible (en plus du niveau faible déjà présent). Ces deux niveaux peuvent être paramétrés à un pourcentage choisi de décharge de la batterie, et associé à des sons d’alerte spécifiques. Avant ces changements, il était facile de ne pas voir le message d’alerte (affiché seulement pendant quelques secondes) ou de se dire qu’avec 15% de batterie on a encore le temps de faire plein de trucs, puis se retrouver un peu plus tard avec une batterie vide sans autre avertissement.

L’état « not charging » est maintenant détecté et correctement affiché, pour une batterie au repos : ni en train de se charger, ni en train d’alimenter la machine. C’est en particulier le cas d’une batterie déjà chargée à 100%, si la machine reste connectée au réseau électrique.

L’icône de statut de la batterie s’installe automatiquement dans la DeskBar au premier démarrage de Haiku sur les machines disposant d’une batterie.

Le réglage du mode « performance » ou « économie d’énergie" est enregistré et ré-appliqué lors des prochains démarrages (ces modes configurent l’ordonnanceur du noyau pour exécuter un maximum de tâches sur tous les cœurs du processeur, ou bien au contraire pour essayer de garder ces cœurs en veille autant que possible s’ils ne sont pas nécessaires).

SerialConnect

SerialConnect est une application de terminal série, utile principalement aux développeurs de systèmes embarqués et autres gadgets électroniques.

Elle est encore en cours de développement et propose pour l’instant les fonctions les plus basiques. Il est maintenant possible de coller du texte depuis le presse-papier pour l’envoyer sur un port série, ce qui est pratique si on veut envoyer plusieurs fois la même séquence de commandes.

ShowImage

ShowImage est la visionneuse d’images de Haiku. Elle utilise les traducteurs, des greffons avec une API standardisée qui permettent de convertir différents formats de fichiers entre eux.

L’interface graphique de ShowImage a été mise à jour pour utiliser le « layout system ». Historiquement, dans BeOS, tous les éléments des interfaces graphiques devaient être positionnés manuellement avec des coordonnées en pixels, ce qui est pénible à faire, surtout si on doit traiter tous les cas (polices de caractères de différentes tailles, remplacement des textes lors de traductions, utilisation de thème d’interfaces différents), et aussi lors d’évolution de l’application (si on veut insérer un élément en plein milieu, il faut souvent décaler tout ce qui se trouve autour).

Le « layout system » fournit un ensemble d’outils pour automatiser ce travail, soit à l’aide d’éléments prédéfinis (grilles, groupes, « cartes » superposées), soit à l’aide d’un système de définition de contraintes et de programmation linéaire.

D’autre part, ShowImage dispose maintenant d’un menu permettant d’ouvrir l’image affichée dans un éditeur d’images.

Terminal

Le Terminal de Haiku permet d’exécuter un shell (c’est bash par défaut) et toutes les applications conçues pour un affichage en console.

Les principaux changements cette année sont la correction d’un problème sur la configuration des couleurs utilisées par le Terminal (il y avait un mélange entre le nom anglais et le nom traduit des couleurs, empêchant d’enregistrer et de relire correctement le fichier de configuration), ainsi que des modifications sur les raccourcis clavier utilisés par le Terminal lui-même (en particulier pour naviguer entre plusieurs onglets) qui entraient en conflit avec ceux utilisés par les applications lancées dans le terminal.

Le terminal est également capable de traiter les « bracketed paste », c’est-à-dire que les applications en console sont informées que des caractères en entrée proviennent du presse-papier. Cela permet par exemple à bash de ne pas exécuter directement des commandes qui sont collées, mais de les mettre en surbrillance et d’attendre que l’utilisateur valide cette saisie.

D’un point de vue plus bas niveau, les pilotes TTY utilisés pour les ports série et pour le Terminal, qui étaient indépendants, ont été unifiés afin d’éviter de devoir corriger tous les bugs deux fois dans deux versions du code presque identiques.

Tracker

Tracker est le navigateur de fichiers de Haiku. Tout comme la DeskBar, il fait partie des quelques rares morceaux de BeOS qui ont été publiés sous licence libre par Be et ont donc pu être repris directement par Haiku. Contrairement à la DeskBar, la publication du code du Tracker avait conduit à l’apparition de nombreux forks, chacun améliorant à sa façon le logiciel. La version utilisée par Haiku provient principalement du projet OpenTracker, mais a réintégré ou réimplémenté au fil du temps les modifications faites dans d’autres variantes.

Le Tracker est un composant central de l’interface de Haiku et a donc reçu un nombre assez important d’évolutions :

La taille des fichiers est maintenant affichée à l’aide de la fonction string_for_size qui s’adapte aux conventions de la langue et du pays choisi par l’utilisateur.

Les brouillons de courrier électronique disposent maintenant de leur propre type MIME et de l’icône associée. Ils s’ouvriront dans un éditeur de mail plutôt que dans une fenêtre de lecture de message.

Pour les fichiers qui disposent d’un attribut « rating » (évaluation), ce dernier est affiché avec des étoiles pleines ou vides selon la note attribuée. La note va de 0 à 10 mais il n’y a que 5 étoiles. Le caractère demi-étoile permet d’afficher la note exacte avec les versions récentes d’Unicode (depuis 2018 en fait, mais il a fallu attendre la disponibilité dans une police de caractères).

La gestion des dossiers en lecture seule a été améliorée. Ils sont affichés sur fond gris (au lieu d’un fond blanc pour les dossiers modifiables) et tous les menus correspondant à des opérations non autorisées sont désactivés (au lieu d’être activés, mais d’aboutir sur une erreur car le dossier est en lecture seule).

Dans le même esprit, le bouton « ouvrir » des boîtes de dialogues d’ouverture de fichier est désactivé si le fichier sélectionné ne peut pas être ouvert (c’était déjà le cas, mais tous les cas possibles n’étaient pas bien pris en compte).

Un problème d’affichage sur le système de fichier packagefs a été corrigé : les dossiers n’ont pas de taille et affichent donc - au lieu d’une taille fixe de 4 Kio qui n’a aucune signification.

La fenêtre de recherche a reçu quelques évolutions, voir plus bas dans la section dédiée au Google Summer of Code, qui détaille le travail réalisé à ce sujet.

Le menu « templates », utilisé quand on fait un 'clic droit -> Nouveau…' et qui permet de créer différents types de fichiers et de dossiers à partir de fichiers de référence, peut maintenant contenir des sous-dossiers, pour les personnes qui utilisent beaucoup cette possibilité, avec par exemple des modèles de documents pré-remplis pour différents usages.

Enfin, un peu de nettoyage interne : les classes NavMenu et SlowContextPopup, qui permettent la navigation dans les sous-dossiers via des menus popup, ont été fusionnées en une seule classe car elles sont toujours utilisées ensemble. Cela simplifie le code pour l’affichage de ces menus, qui a quelques particularités pour permettre une navigation confortable même sur un disque dur un peu lent.

TV

L’application TV utilisée pour recevoir la TNT à l’aide d’un tuner approprié a été déplacée dans le paquet haiku_extras et n’est donc plus installée par défaut. La plupart des gens ne disposant pas d’un tuner compatible sur leur ordinateur, cette application était source de confusion et de nombreuses questions sur le forum.

WebPositive

WebPositive est le navigateur web de Haiku. Il utilise le moteur WebKit développé conjointement par Apple, Igalia et Sony principalement.

En dehors de la mise à jour du moteur vers une version plus récente, WebPositive reçoit actuellement peu d’évolutions, les développeurs étant malheureusement trop occupés par ailleurs. On peut toutefois mentionner une correction sur la barre de signets : celle-ci ne s’affichait jamais lorsque la langue du système était autre chose que l’anglais.

Zip-O-Matic

Zip-O-Matic est un outil permettant de créer une archive zip facilement depuis le Tracker. Il a reçu une amélioration qui est en fait une correction d’un problème qui existait depuis longtemps : l’archive créée est maintenant automatiquement sélectionnée dans le navigateur de fichier à la fin du processus, ce qui permet de facilement la retrouver pour la renommer, la déplacer ou l'envoyer à son destinataire.

Haikuports

Haikuports est un projet indépendant de Haiku, il se charge d’alimenter le dépôt de paquets. Au départ il s’agissait principalement d’un projet pour le portage de bibliothèque et de programmes venant d’autres systèmes (d’où son nom), mais il est également utilisé pour la plupart des applications natives développées pour Haiku.

Le dépôt de paquets contient actuellement 4193 paquets, il est mis à jour en continu par une petite équipe de bénévoles qui ne sont pas forcément tous développeurs, mais tout de même capables de faire les tâches de maintenance ainsi que le développement de quelques patchs simples.

Il est impossible de lister toutes les mises à jour et ajouts, le projet HaikuPorts étant très actif. Donc voici une sélection arbitraire de quelques nouveautés et mises à jour.

Applications natives

• Mises à jour de Renga (client XMPP), PonpokoDiff (outil de diff), 2pow (clone de 2048), StreamRadio (lecteur de podcasts), NetSurf (navigateur web léger)…
• Genio, un IDE pour Haiku avec gestion de la complétion de code via le protocole LSP (compatible avec les outils développés pour VS Code par exemple).
• Ajout de HaikuUtils, un ensemble d’outils de développement et de debug divers.
• WorkspaceNumber, un replicant pour afficher le numéro du bureau actif dans la DeskBar.
• KeyCursor, un outil pour contrôler le curseur de souris à l’aide du clavier.
• BatchRename, un outil pour renommer automatiquement des fichiers par lot.

Applications portées

• Un gros travail a été fait sur le portage de KDE Frameworks et des applications l’utilisant. De très nombreuses applications Qt et KDE sont donc disponibles.
• Du côté de GTK, il n’existait pas de version de GTK pour Haiku, le problème a été résolu à l’aide d’une couche de compatibilité avec Wayland qui n’implémente pas le protocole Wayland mais réimplémente l’API de la libwayland. Les applications GTK arrivent petit à petit, mais l’intégration est pour l’instant beaucoup moins bonne qu’avec Qt, qui dispose lui d’un vrai port utilisant les APIs natives directement. L’apparence des applications est très visiblement différente, certaines touches du clavier ne fonctionnent pas. C’est donc encore un peu expérimental.
• Enfin, pour compléter les possibilités d’outils graphiques, la bibliothèque Xlibe implémente les APIs de la libx11 (mais pas le protocole de communication de X) et permet de porter les applications FLTK par exemple, ainsi que celles utilisant directement la libx11. Il reste encore des problèmes avec les applications utilisant Tk (si vous connaissez Tk ou X, les développeurs de Xlibe aimeraient bien un petit coup de main). En attendant, les applications Tk sont utilisables à travers un portage de undroidwish, mais ça reste peu confortable.

Du côté des compilateurs et des langages de programmation : LLVM a été mis à jour en version 17. GCC est disponible en version 13 et peut maintenant être utilisé pour compiler du FORTRAN et de l’Objective-C. Les dernières versions de Python sont disponibles, et en plus avec des performances améliorées. Node.JS est également mis à jour, ou si vous préférez le langage R, vous le trouverez également, avec son IDE associé rkward.

Bien sûr, la plupart des bibliothèques et outils disponibles sur d’autres systèmes sont aussi disponibles : ffmpeg (en version 6), Git, libreoffice, Wireshark…

Mentionnons enfin un pilote FUSE pour monter des volumes réseau NFS, qui vient compléter les deux implémentations de NFS présentes dans le noyau (une obsolète qui implémente NFS2, et une plus récente implémentant NFS4, mais qui est instable et pas activement maintenue actuellement).

Panneaux de préférences

Appearance

Les préférences « Appearance » permettent de configurer l’apparence du système et des applications : principalement les polices de caractères et les choix de couleurs.

C’est ce dernier qui reçoit une mise à jour en profondeur, avec l’ajout d’un mode automatique. Auparavant, chaque couleur utilisée par le système devait être configurée manuellement, ce qui permet un contrôle très fin, mais demande de passer un certain temps à faire des ajustements. Le mode automatique permet de configurer seulement 3 couleurs : le fond des fenêtres, les barres de titres, et une couleur d’« accentuation ». Les autres couleurs et nuances sont calculées automatiquement à partir de cette palette de base.

En particulier, il devient beaucoup plus facile de choisir un fond sombre pour se retrouver avec un système en mode sombre, très à la mode chez certain·e·s utilisateurices de Haiku.

Il est toujours possible d’activer le mode avancé pour affiner les réglages si nécessaire (ou si vous aimez les interfaces graphiques bariolées et multicolores).

Keymap (disposition clavier)

L’application Keymap permet de configurer la disposition de touches du clavier. Le point qui a reçu un peu d’attention est la gestion de la configuration des touches modificatrices.

Haiku est un dérivé de BeOS qui lui-même a été au départ inspiré de Mac OS. On conserve de cet héritage l’utilisation des touches commande et option au lieu de meta et alt sur les claviers de PC. Mais BeOS et Haiku sont conçus pour être utilisés avec des claviers de PC. La touche commande qui prend la place de la touche ALT est donc celle utilisée pour la plupart des raccourcis claviers. Cela se complique si on essaie d’utiliser un clavier fabriqué par Apple (les codes de touches renvoyés par le clavier pour des touches situées au même endroit ne sont pas les mêmes), ou encore si on a besoin d’une touche AltGr (historiquement utilisée comme touche option par BeOS, mais aujourd’hui ce rôle est plutôt attribué à la touche windows apparue un peu plus tard). Une page sur le wiki de développement de Haiku tente de résumer l’historique et la situation actuelle.

La configuration des touches modificatrices est donc un sujet complexe, et il est probable que le comportement sera à nouveau modifié plus tard. Quoi qu’il en soit, en attendant, l’application Keymap permet toutes les permutations possibles de configuration de ces touches.

Screen (Affichage)

Les préférences d’affichage, en plus de permettre de changer la résolution d’écran, affichent quelques informations essentielles sur la carte graphique et l’écran en cours d’utilisation. Pour les écrans, ces informations sont généralement extraites des données EDID, mais il y a une exception : les dalles d’affichage des PC portables n’implémentent en général pas ce protocole. Les informations sont donc récupérées par d’autres moyens parfois moins bien normalisés. Par exemple, l’identifiant du fabricant est un code à 3 lettres. En principe, les fabricants doivent s’enregistrer auprès d’un organisme qui attribue ces codes, afin d’en garantir l’unicité.

Cependant, certains fabricants ne l’ont pas fait, et se sont choisi eux-mêmes un code qui semblait inutilisé. La base de données officielle réserve donc ces codes et en interdit l’utilisation, afin d’éviter des conflits. Il arrivait donc que le fabriquant d’un écran soit affiché comme étant « DO NOT USE », ce qui a inquiété quelques utilisateurs de Haiku se demandant s’ils risquaient d’endommager leur matériel.

Ces entrées de la liste sont maintenant filtrées et remplacées par les noms des fabricants de panneaux d’affichages concernés (lorsqu’on sait de qui il s’agit).

Outils en ligne de commande

Haiku est fourni avec un terminal et un shell bash (par défaut, d’autres shells peuvent également être utilisés). Les outils définis dans la spécification POSIX sont fournis, ainsi que des compléments permettant d’utiliser les fonctionnalités supplémentaires de Haiku.

df

La commande df affiche l’espace disque disponible sur chaque volume de stockage actuellement monté.

Les colonnes de l’affichage ont été réorganisées, pour être plus lisibles, et se rapprocher un peu du format spécifié par POSIX (mais pas complètement lorsqu’on lance la commande sans options particulières : des informations supplémentaires sont alors affichées).

filteredquery

L’outil filteredquery permet d’effectuer une requête sur les attributs étendus du système de fichiers (permettant de requêter le système de fichiers comme une base de données, plutôt que de naviguer de façon hiérarchique dans les dossiers), puis de filtrer le résultat pour ne conserver que les réponses contenues dans un sous-dossier spécifique. En effet, les requêtes étant indépendantes de l’organisation des dossiers, il est nécessaire de faire ce filtrage par post-traitement des résultats (ce qui reste tout de même généralement plus rapide que de faire l’inverse : parcourir tous les fichiers d’un dossier pour trouver ceux correspondant à un critère particulier).

Cet outil n’a pas reçu de nouvelles fonctionnalités, mais de nombreuses corrections et nettoyages qui le rendent véritablement utilisable.

ping, traceroute, telnet, ftpd

Ces commandes liées à des opérations sur le réseau ont été remplacées par les dernières versions développées par FreeBSD, permettant de bénéficier d’une version moderne, avec plus de fonctionnalités et moins de bugs.

La commande ping6 est supprimée, car ping peut maintenant utiliser l’IPv6 aussi bien que l’IPv4.

pkgman

L’outil pkgman permet de télécharger et d’installer des logiciels et des mises à jour.

Il a peu évolué, mais on peut tout de même noter l’utilisation d’un algorithme de tri « naturel » pour l’affichage des résultats dans l’ordre alphabétique (par exemple, llvm12 sera affiché après llvm9).

Une fonction qui n’est toujours pas disponible dans pkgman est le nettoyage des dépendances non utilisées. Un script fourni dans le dépôt Git de Haiku permet de réaliser manuellement une analyse des paquets installés sur le système pour détecter ceux qui n’ont pas de dépendances, il faudra pour l’instant se contenter de cette solution.

strace

L’outil strace permet d’afficher les appels systèmes effectués par une application, pour comprendre son interfaçage avec le noyau et investiguer certains problèmes de performances ou de mauvais comportements.

L’interfaçage avec le noyau pour extraire ces informations étant assez spécifique, l’implémentation de strace est faite à partir de zéro, et ne partage pas de code avec la commande du même nom disponible par exemple sous Linux.

strace est mis à jour régulièrement et en fonction des besoins des développeurs de Haiku pour décoder et afficher de plus en plus d’informations. Par exemple, elle peut maintenant afficher le contenu des iovec (par exemple pour les fonctions readv ou writev), ainsi que les objets manipulés par wait_for_object et event_queue.

Un exemple de sortie de strace (traçant l’ouverture d’un fichier et le chargement d’une bibliothèque partagée) avant ces changements:

open(0x5, "plaintext", 0x2042, 0x0) = 0x8000000f () (49 us)
map_file("libicuuc.so.66 mmap area", 0x7f04c2675228, 0x6, 0x1ababd0, 0x1, 0x0, true, 0x3, 0x0) = 0x329a0 () (108 us)

et après :

open(0x5, "plaintext", O_RDWR|O_NOTRAVERSE|O_CLOEXEC, 0x0) = 0x8000000f Operation not allowed (57 us)
map_file("libicuuc.so.66 mmap area", [0x0], B_RANDOMIZED_ANY_ADDRESS, 0x1ababd0, B_READ_AREA, 0x0, true, 0x3, 0x0) = 0x73e8 ([0x6392223000]) (135 us)

whence

La commande whence permettait de trouver dans le PATH un exécutable à partir de son nom. Elle était implémentée sous forme d’une fonction bash dans le fichier profile par défaut. Cependant, cette implémentation posait problème pour charger le fichier profile avec d’autres shells, elle a donc été supprimée. La commande which peut être utilisée à la place, puisqu’elle remplit un rôle équivalent.

Serveurs

Les serveurs sont l’équivalent des daemons pour UNIX ou des services sous Windows : il s’agit d’applications lancées par le système pour rendre différents services et coordonner l’ensemble des applications.

app_server

app_server est le serveur graphique de Haiku, équivalent de X ou de Wayland. Il se distingue par un rendu graphique fait principalement côté serveur (pour les applications natives), ce qui permet de l’utiliser de façon fluide à travers une connexion réseau.

Bien que ce soit le serveur graphique, et qu’il ait reçu plusieurs améliorations importantes, les différences sont subtiles. Elles sont toutefois importantes pour proposer un système qui semble réactif et confortable à utiliser.

Un premier changement est une réarchitecture du code qui traite le rafraîchissement de l’écran. Ce rafraîchissement se fait en général en plusieurs étapes, par exemple, si on déplace une fenêtre :

• Le contenu de la fenêtre déplacée peut être directement recopié de l’ancienne position vers la nouvelle,
• La zone où se trouvait la fenêtre auparavant doit être re-remplie avec ce qui se trouvait en dessous de la fenêtre déplacée. Cela peut être plusieurs morceaux de fenêtres d’autres applications, qui vont devoir chacune ré-afficher une partie de cette zone.

Le problème étant que certaines applications peuvent mettre un peu de temps à répondre à cette demande de ré-affichage (par exemple parce qu’elles sont occupées ailleurs, ou alors parce que la zone à redessiner est relativement complexe).

Différentes stratégies peuvent être mises en place dans ce cas : laisser à l’écran le contenu obsolète, ou remplir la zone en blanc en attendant que les données deviennent disponibles, par exemple. Ou encore, tout simplement ne rien mettre à jour du tout tant que tout l’écran n’est pas prêt à être affiché. Il faut faire un compromis entre la réactivité (déplacer la fenêtre tout de suite), la fluidité (éviter les clignotements de zones blanches) et la précision (affichage d’information cohérente et à jour).

Plusieurs modifications ont permis d’obtenir un meilleur compromis.

Dans un autre domaine, la police de caractères par défaut « Noto Sans Display » a été remplacée par « Noto Sans », ce qui donne un affichage du texte légèrement différent. La police « display » avait été choisie suite à une mauvaise compréhension de la signification de ce mot en typographie : il signifie que c’est une police de caractères à utiliser pour des gros titres et autres textes courts. Il ne signifie pas que c’est une police à utiliser sur un écran d’ordinateur. De toutes façons la police Noto Display n’est plus maintenue par Google et a disparu des dernières versions du jeu de polices Noto.

Toujours dans le domaine des polices de caractères, app_server sait maintenant charger les fichiers « variable fonts ». Ces fichiers contiennent plusieurs polices de caractères définies à partir de glyphes de base, et d’algorithmes de transformation et de déformation (pour rendre une police plus ou moins grasse, plus ou moins italique…). Pour l’instant, app_server sait charger les valeurs de ces paramètres qui sont préconfigurées dans le fichier. Cela permet de réduire la place utilisée par les polices de caractères sur le media d’installation de Haiku (c’est l’un des plus gros consommateurs d’espace disque, qui nous empêche de faire tenir une version complète de Haiku sur un CD de démonstration par exemple).

Plus tard, il sera également possible de configurer plus finement ces paramètres pour générer des variantes intermédiaires des polices de caractères, ainsi que d’exploiter certaines polices qui offrent des paramètres configurables supplémentaires.

input_server

L’input_server se charge de lire les données venant des périphériques d’entrée (clavier et souris) et de les convertir en évènements distribués aux applications. Il est extensible par des add-ons qui peuvent générer ou filtrer des évènements, ce qui peut être utilisé pour de l’accessibilité (émuler une souris à partir de touches du clavier), de l’automatisation (envoi de commandes pré-enregistrées), du confort d’utilisation (bloquer le touchpad d’un ordinateur portable lorsque le clavier est en cours d’utilisation) et bien d’autres choses.

L’input_server a reçu des corrections de problèmes sur la gestion des réglages de souris, permettant en particulier d’utiliser des réglages différents pour plusieurs périphériques (souris, touchpad), et que ceux-ci soient bien enregistrés.

registrar

Le serveur registrar suit les applications en cours de fonctionnement, et leur permet de communiquer entre elles au travers de l’envoi de messages. Il assure également le suivi de la base de données des types MIME et des associations de types de fichiers avec les applications correspondantes.

L’implémentation de BMessageRunner, qui permet d’envoyer des messages périodiques (par exemple pour faire clignoter le curseur des zones de texte à la bonne vitesse), autorise maintenant des intervalles de répétition en dessous de 50 millisecondes. Cela permet d’utiliser ce système pour des animations fluides de l’interface graphique, par exemple.

D’autre part, la liste des applications et documents récemment lancés est maintenant limitée à 100 entrées. Cela évite un fichier qui grossit indéfiniment et finit par contenir surtout des vieilles informations sans intérêt.

Kits

Le système Haiku fournit les mêmes APIs que BeOS. Elles couvrent les usages basiques d’une application, et sont découpées (dans la documentation de BeOS et de Haiku, au moins) en « kits » qui prennent chacun en charge une partie spécifique (interface graphique, multimédia, jeux vidéos, accès au matériel, etc).

Interface

L’interface kit est la partie de la bibliothèque standard qui se charge des interfaces graphiques.

 BColumnListView

BColumnListView est un ajout de Haiku par rapport à BeOS. Il s’agit d’un élément d’interface permettant de présenter une liste avec plusieurs colonnes, de trier les lignes selon le contenu de ces colonnes, et aussi d’avoir des items hiérarchisés avec la possibilité de plier et déplier une partie de l’arborescence.

Cette classe remplace avantageusement BListView et surtout BColumnListView, les classes historiques de BeOS, qui sont beaucoup plus limitées.

Un certain nombre de type de colonnes prédéfinis sont également disponibles, ce qui facilite la construction d’interfaces présentant les données de différentes applications avec le même formatage.

La classe BColumnListView elle-même n’a pas changé. Par contre, les colonnes de type « taille » (pour afficher une taille en Kio, Mio, Gio…) et « date » utilisent la langue choisie dans les préférences système au lieu d’un format anglais par défaut.

BTextView

BTextView est une classe permettant d’afficher une zone de texte éditable. Elle implémente les fonctionnalités de base (curseur, sélection, retour à la ligne automatique) ainsi que quelques possibilités de mise en forme (couleurs, polices de caractères).

BTextView peut également être utilisée pour des zones de textes non éditables, souvent plus courtes. Cela permet de réutiliser une partie des algorithmes de mise en page et de formatage du texte dans différents contextes. Dans le cadre de l’utilisation du « layout system », une vue doit pouvoir indiquer sa taille minimale, maximale et optimale. Le « layout system » va ensuite calculer la meilleure disposition de fenêtre possible pour satisfaire ces contraintes.

Le cas des zones de texte est particulier, car la hauteur optimale dépend du nombre de lignes de texte, qui lui-même peut être plus ou moins grand si la largeur de la vue oblige à ajouter des retours à la ligne. Le « layout kit » prend en compte ce cas particulier, mais les algorithmes ne sont pas encore tout à fait au point et peuvent conduire à des résultats inattendus dans certains cas. Un de ces cas particuliers sur les zones de texte non éditables a été corrigé.

BMenu

La classe BMenu permet d’afficher un menu. Elle est utilisée de plusieurs façons, puisqu’on trouve des menus dans des barres de menu, dans des contrôles de type « popup », ou encore en faisant un clic droit sur certains éléments de l’interface.

Les menus sont également particuliers parce qu’ils peuvent d’étendre en dehors de la fenêtre dont ils sont originaires. Ils sont donc implémentés sous forme de fenêtres indépendantes. Mais cela pose un autre problème : dans Haiku, chaque fenêtre exécute son propre thread et sa propre boucle d’évènements. Si on navigue dans un grand nombre de menus et de sous-menus, cela peut causer quelques problèmes de synchronisation et de performances.

Le code contient également un grand nombre de cas particuliers pour, par exemple, aligner les raccourcis claviers et les flèches indiquant la présence de sous-menus ente les différents items d’un menu, ou encore détecter si un déplacement de souris a pour but de sélectionner un autre menu (en dessous ou au-dessus de celui actif), ou bien plutôt de naviguer vers un sous-menu.

Les nouveautés suivantes sont apparues cette année:

• Correction de problèmes de race condition lors de l’ajout d’items dans un menu pendant qu’il est affiché à l’écran. Ce problème se manifestait par exemple dans les menus affichant la liste des réseaux Wifi, qui sont mis à jour en temps réel.
• Finalisation de l’implémentation de la navigation au clavier (avec les flèches directionnelles) dans les menus.
• Affichage des symboles graphiques UNICODE pour « backspace » (⌫) et « delete » (⌦) si ces touches sont utilisées comme raccourcis clavier pour un item de menu.
• Utilisation d’un algorithme de tri stable pour la fonction SortItems. Ce type d’algorithme préserve l’ordre relatif des items qui sont égaux d’après la fonction de comparaison. Ce n’est pas le cas de certains algorithmes de tri classiques, notamment le quicksort. La conséquence était que trier un menu déjà trié pouvait changer l'ordre des items. C’était visible encore une fois sur le menu listant les réseaux Wifi, qui est trié par puissance du signal reçu.

 BSpinner

BSpinner est un contrôle permettant de choisir une valeur numérique, soit à l’aide de boutons +/- pour modifier la valeur par incréments, soit en entrant directement la valeur dans une zone de texte.

Il s’agit d’une extension de Haiku par rapport à BeOS qui ne proposait pas cette fonctionnalité.

Cette classe est encore en cours de développement. Elle a reçu des améliorations pour désactiver correctement les boutons +/- lorsque la valeur atteint le minimum ou le maximum autorisé, et aussi une correction sur le message de notification envoyé lors des changements de valeurs du spinner, qui ne contenaient pas la bonne valeur.

rgb_color

La structure rgb_color permet de représenter une couleur par la valeur de ses composantes rouge, vert, bleu (comme son nom l’indique) et alpha (comme son nom ne l’indique pas). Elle fournit également un certain nombre de fonctions pour mélanger des couleurs, les éclaircir ou les assombrir.

La méthode Brightness() dans la classe rgb_color implémentante maintenant l’algorithme perceptual brightness documenté par Darel Rex Finley, qui donne des meilleurs résultats que l’algorithme utilisé précédemment (qui était celui de la luminosité dans l’espace de couleurs Y'IQ. La fonction perceptual_brightness devenue redondante est supprimée.

Cette méthode permet en particulier de déterminer si une couleur est « sombre » ou « claire », et ainsi de décider si du texte affiché par-dessus doit être blanc ou noir (comme démontré ici par exemple).

Locale

Le locale kit se charge de tous les aspects liés à la localisation : traductions des applications, formatage des messages en utilisant les règles de pluralisation de chaque langue, formatage de dates, de nombres avec et sans unités, de pourcentages, nom des fuseaux horaires…

Il utilise ICU pour implémenter la plupart de ces fonctionnalités, mais fournit une surcouche avec une API s’intégrant mieux avec les autres kits.

La principale évolution cette année est l’implémentation de BNumberFormat, qui permet de formater des nombres. Elle permet de choisir une précision (nombre de décimales - pour les langues qui utilisent un système décimal), d’afficher ou non des séparateurs de groupes (de milliers en français, mais par exemple en Inde la séparation se fait traditionnellement par multiples de 10 000).

Media

Le media kit se charge de tous les aspects multimedia.

Il se compose de deux parties. D’une part, un système de gestion de flux média temps réel, permettant de transférer des données multimédia (son ou flux vidéo par exemple) entre différentes applications qui vont les manipuler, le tout avec un certain contrôle du temps de traitement ajouté par chaque opération, pour tenter de minimiser la latence tout en évitant les vidages de tampons qui produiraient une interruption dans le flux. D’autre part, des classes permettant d’encoder et de décoder des fichiers média et d’en extraire des flux de données (encodées ou décodées).

C’est surtout cette deuxième partie qui a reçu quelques évolutions. La version de ffmpeg utilisée pour le décodage de presque tous les formats audio et video est maintenant la dernière version ffmpeg 6. Quelques autres problèmes (erreurs d’arrondis, gestion des tampons partiels en fin de fichier) ont également été corrigés, ce qui permet de faire fonctionner à nouveau le jeu BePac Deluxe qui est extrêmement intolérant au moindre écart de comportement par rapport à l’implémentation du Media Kit dans BeOS.

Support

Le support kit contient un ensemble de classes basiques mais indispensables : gestion des chaînes de caractères, des tampons en mémoire, etc. Il fournit les briques de bases utilisées par les autres kits.

BDataIO

BDataIO est une classe abstraite avec des fonctions de lecture et d’écriture. Plusieurs autres classes sont des instances de BDataIO, par exemple BFile (représentant un fichier), mais aussi BMemoryIO (permettant d’accéder à une zone mémoire).

Plusieurs autres classes acceptent BDataIO (ou sa sous-classe BPositionIO, qui ajoute la possibilité de se déplacer à une position donnée dans le flux) comme entrée ou comme sortie. Il est donc facilement possible de réaliser les mêmes opérations sur un fichier, une zone de données en mémoire, un socket réseau, ou tout autre objet susceptible de fournir une interface similaire.

BDataIO elle-même n’a pas évolué, mais deux de ses implémentations, BBufferedDataIO et BAdapterIO, ont été améliorées. Ces deux classes permettent de construire un objet BDataIO à partir d’un autre, en ajoutant un cache en mémoire pour accélérer les opérations ou encore pour rendre compatible avec BPositionIO un objet qui ne l’est pas.

Ces classes sont en particulier utilisées par l’application StreamRadio, qui implémente la lecture de podcasts en connectant directement le résultat d’une requête HTTP (effectuée grace au network kit) dans un décodeur audio (via la classe BMediaFile du media kit). La mise en tampon permet de revenir en arrière dans la lecture d’un épisode, de télécharger en avance les données qui vont être lues, et d’éviter de conserver inutilement en mémoire les données qui sont déjà lues par l’application.

Bibliothèques C

Les « kits » mentionnés ci-dessus sont l’API en C++ utilisée par les applications Haiku.

Il existe aussi des APIs en C, en grande partie implémentant la bibliothèque C standard et les fonctions décrites dans la spécification POSIX.

Libroot

Libroot implémente la bibliothèque standard C. Elle regroupe entre autres la libc, la libm, et la libpthread, qui sont parfois implémentées comme 3 bibliothèques différentes pour d’autres systèmes. Les évolutions consistent à compléter l’implémentation de la spécification POSIX, et à suivre les évolutions de cette dernière ainsi que des nouvelles versions du langage C. On trouve également des corrections de bugs découverts en essayant de faire fonctionner de plus en plus d’applications sur Haiku, ce qui permet de mettre en évidence des différences de comportement avec d’autres systèmes.

• Ajout de getentropy pour initialiser les générateurs de nombres aléatoires
• Correction de problèmes de locks au niveau de l’allocateur mémoire lors d’un fork
• Plusieurs corrections sur l’implémentation de locale_t, remplacement de code écrit pour Haiku ou provenant de FreeBSD par une implémentation simplifiée mais suffisante, provenant de la bibliothèque C musl.
• Ajout de static_assert en C11
• Correction d’un crash lors de l’utilisation de certaines fonctions XSI
• Ajout de stpncpy
• La fonction open utilisée sur un lien symbolique pointant vers un fichier non existant peut maintenant créer le fichier cible.
• Il est possible d’utiliser mmap sur un fichier plus grand que la mémoire disponible sans avoir besoin de spécifier le flag MAP_NORESERVE
• Utiliser rename pour renommer un fichier vers lui-même ne retourne plus d’erreur (conformément à la spécification POSIX).
• Ajout de pthread_sigqueue

Libnetwork

La libnetwork implémente les APIs nécessaire pour se connecter au réseau (sockets, résolution DNS…). Elle est séparée de la bibliothèque C pour des raisons historiques : l’implémentation de TCP/IP pour BeOS avait été réalisée entièrement en espace utilisateur (le noyau n’offrant qu’une interface pour envoyer et recevoir des paquets ethernet sur la carte réseau). Cela a posé des problèmes de compatibilité avec d’autres systèmes, et des problèmes de performance. Haiku est donc compatible avec la version "BONE" de BeOS, qui implémente la pile réseau dans le noyau.

• Mise à jour du résolveur DNS à partir du code de NetBSD 9.3. Précédement le code utilisé était celui du projet netresolv de NetBSD, mais ce projet n’a pas connu de nouvelles publications et le code est à nouveau maintenu directement dans NetBSD sans publication séparée.
• Correction d’un crash lors de l’utilisation de multicast IPv4

LibBSD

La libbsd implémente plusieurs extensions fournies par la libc de certains systèmes BSD. Elle est séparée de la bibliothèque C principale pour limiter les problèmes de compatibilité: certaines applications préfèrent fournir leur propre version de ces fonctions, ou d’autres fonctions avec le même nom mais un comportement différent. Elles peuvent alors s’isoler en n’utilisant pas la libbsd pour éviter toute interférence.

• Ajout de arc4random pour générer des nombres aléatoires sans devoir passer par /dev/random (compatible avec OpenBSD, Theo de Raadt a réalisé une présentation expliquant le pourquoi et le comment en 2014).

LibGNU

De façon similaire à la libbsd, la libgnu fournit des fonctions qui sont disponibles dans la glibc (la bibliothèque C du projet GNU) mais ne font pas partie d’un standard (C ou POSIX).

• Ajout de sched_getcpu pour savoir sur quel cœur de CPU le thread appelant est en train de s’exécuter.
• Ajout de pthread_timedjoin_np, pour attendre la fin de l’exécution d’un thread (comme pthread_join mais avec un timeout.