URL: https://linuxfr.org/news/nouvelles-de-haiku-hiver-2024-25 Title: Nouvelles de Haiku - Hiver 2024-25 Authors: pulkomandy cli345, Julien Jorge, orfenor, BenoĂ®t Sibaud, palm123 et Ysabeau 🧶 Date: 2024-12-17T13:08:40+01:00 License: CC By-SA Tags: haiku et beos Score: 4 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](https://git.haiku-os.org/haiku/log/?qt=range&q=hrev58292..hrev58583) 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. ---- [Rapport d'activitĂ© de novembre 2024](https://www.haiku-os.org/blog/waddlesplash/2024-12-10-haiku_activity_contract_report_november_2024/) [Repport d'activtĂ© de dĂ©cembre 2024](https://www.haiku-os.org/blog/waddlesplash/2025-01-13-haiku_activity_contract_report_december_2024/) [Rapport d'activitĂ© de janvier 2025](https://www.haiku-os.org/blog/waddlesplash/2025-02-10-haiku_activity_contract_report_january_2025/) ---- Rapport financier 2024 ====================== Recettes -------- L’association Haiku inc (association de type 501(c)3 aux USA) publie chaque annĂ©e un [rapport financier](https://www.haiku-inc.org/docs/haiku_inc-financial-report-2024.pdf). 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](https://en.wikipedia.org/wiki/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](https://fr.wikipedia.org/wiki/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](#toc-gestion-de-la-m%C3%A9moire). 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](https://dwheeler.com/essays/fixing-unix-linux-filenames.html)) 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 »](https://www.haiku-os.org/docs/userguide/fr/tracker.html#navigating)). 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](https://github.com/FreeBSDFoundation/proj-laptop/issues/5). 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](https://fr.wikipedia.org/wiki/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](https://fr.wikipedia.org/wiki/Bug_de_l%27an_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](https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/) 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](https://austingroupbugs.net/view_all_bug_page.php). 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](https://pubs.opengroup.org/onlinepubs/9699919799/functions/ioctl.html) 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](https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/posix_devctl.html). 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](https://i18n.haiku-os.org). 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](https://i18n.kacperkasper.pl).