Sommaire
Il est difficile de lister tous les changements et évolutions qui ont eu lieu depuis la version beta3 publiée l'année dernière. Et une grande partie de la liste serait de toutes façons assez laborieuse à lire. Il y a eu plus de 280 tickets fermés, sans compter les changements qui n'ont pas fait l'objet d'un ticket de suivi.
La liste ci-dessous est donc loin d'être exhaustive et donne seulement un petit apperçu des nouveautés.
Améliorations de la libbe
La libbe est la bibliothèque qui contient la majorité de l'API C++ de Haiku.
On y trouve principalement des nouveautés dans la partie concernant les interfaces graphiques :
- Il est désormais possible d'afficher du texte souligné, c'est utilisé par exemple dans AboutSystem pour mettre en valeur les liens hypertextes.
- Il est possible de demander au serveur graphique de calculer la taille d'un rectangle permettant de contenir n'importe quel caractère d'une police donnée. Par exemple la table de caractères utilise cela pour dimensionner l'espace réservé aux caractères affichés.
- Il est également possible de trier les items d'un menu après les avoir ajoutés dans le menu. Par exemple, le menu permettant d'afficher la liste des réseaux Wifi utilise cette possibilité pour afficher les réseaux avec le meilleur signal en premier. Auparavant, il fallait pour cela à chaque fois supprimer puis reconstruire le menu.
D'autre part, l'API pour l'accès au réseau (HTTP, FTP) est à nouveau en cours de réécriture, les versions précédentes sont trop complexes à utiliser sans apporter grand chose au niveau des performances (au contraire).
Un bug assez gênant a été éradiqué. Il concernait la façon dont certaines applications sont lancées. Sous Haiku il y a deux principales façons de lancer une application. Soit, à la façon Unix, comme un processus "enfant" d'une autre application en cours d'exécution (par exemple avec fork() et exec(), mais diverses fonctions permettent d'atteindre le même résultat). Dans ce cas, l'application nouvellement lancée hérite des variables d'environnement de son processus parent. Soit, à la façon BeOS, par exemple en utilisant BRoster::Launch(). Dans ce cas, sous BeOS, l'application est lancée sans dépendre d'une application parente spécifique. Cependant, dans Haiku, elle est rattachée à la session en cours de l'utilisateur et démarrée par l'instance correspondante du launch_daemon (cela fait partie du travail en cours pour pouvoir avoir plusieurs utilisateurs sur le même système).
Dans ce deuxième cas, un problème dans l'implémentation de ces fonctions faisait que l'application lancée se retrouvait avec un environnement totalement vide. Ce cas se présentait par exemple pour les applications lancées via un raccourci clavier, ou encore à partir du lanceur QuickLaunch. Cela conduisait à toutes sortes de problèmes étranges avec les applications lancées par ce moyen, et ce bug s'est retrouvé parmi ceux évalués comme les plus importants par les utilisateurs de Haiku. Il est maintenant corrigé et ces applications sont lancées avec l'environnement par défaut qu'elles étaient en droit d'attendre.
Du côté du package kit qui permet de gérer les paquets logiciels au format HPKG, la possibilité de compresser ces derniers au format Zstd a été ajoutée et est maintenant utilisée par défaut. Cela permet un gain de vitesse sur la décompression des paquets tout en obtenant une meilleure compression. Il reste des possibilités d'amélioration cependant, car la compression des paquets est faite par blocs de quelques kibi-octets afin de permettre l'accès non séquentiel au contenu. Chaque bloc étant compressé séparément, il ne peut pas référencer des données présentes dans les blocs précédents. Il est possible avec Zstd de faire cela plus efficacement, en construisant lors de la compression un dictionnaire qui peut ensuite être référencé pour la décompression de tous les blocs.
Enfin, on peut signaler l'ajout d'un translateur pour les images AVIF parmi ceux fournis par défaut avec le translation kit. Ce format d'image peut donc être utilisé dès maintenant par n'importe quelle application utilisant les translateurs.
Amélioration de la pile réseau
Haiku utilisait jusqu'à présent certains pilotes de cartes réseau de FreeBSD, à l'aide d'une couche de compatibilité (cette approche a également été adoptée par la suite par le système temps réel RTEMS). Cependant, ces dernières années, les pilotes de FreeBSD sont de moins en moins bien maintenus, et actuellement les développeurs de FreeBSD préfèrent utiliser eux-même une couche de compatibilité avec Linux, qui semble complexe à mettre au point et à maintenir. En réalité, une partie des corrections sur les pilotes Wifi de FreeBSD proviennent de problèmes identifiés par les utilisateurs de Haiku et corrigés par ses développeurs.
Haiku s'est donc mis en quête d'un autre endroit où trouver des pilotes facilement réutilisables. La solution est venue de OpenBSD, dont la pile réseau est similaire (mais pas identique) à celle de FreeBSD. La couche de compatibilité de Haiku est maintenant compatible avec ces deux systèmes, et de plus, les pilotes Wifi de OpenBSD sont compatibles avec le Wifi haut débit (802.11ac). Haiku est donc le troisième système libre après Linux et OpenBSD à pouvoir utiliser cette technologie.
La compatibilité avec les pilotes de FreeBSD a également été étendue pour pouvoir réutiliser les pilotes pour les adaptateurs Wifi connectés en USB (en plus de ceux connectés en PCI). Cela fournit une solution pour les machines dont l'adaptateur Wifi interne n'est pas encore compatible avec les drivers de Haiku.
Enfin, un nouveau pilote natif a été ajouté, pour les périphériques compatibles MS-RNDIS. C'est par exemple le cas du partage de connexion via USB des téléphones Android, qui peut donc maintenant être utilisé avec Haiku.
Ce n'est pas tout : en plus des pilotes, des corrections à d'autres niveaux dans la pile réseau permettent d'utiliser des "Jumbo frames" (trames Ethernet jusqu'à 9000 octets, utilisées par exemple pour l'Ethernet Gigabit). Il y avait également des problèmes dans la gestion des délais dans le client DHCP, qui conduisait à inonder le réseau de requêtes et à considérer toute tentative de réponse du serveur comme obsolète.
Enfin, il est de nouveau possible de démarrer Haiku depuis le réseau, en chargeant le noyau en PXE puis en montant un système de fichier mis à disposition par remote_disk_server.
Pilotes graphiques et affichage
Du côté de l'affichage, c'est surtout le pilote pour les cartes graphiques Intel qui a reçu l'attention des développeurs cette année pour assurer la compatibilité avec les nouvelles générations de processeurs graphiques de cette marque. Cela a été l'occasion de corriger également des problèmes et des fonctionnalités manquantes pour les cartes plus anciennes, par exemple le contrôle du rétro-éclairage sur les PC portables fonctionne sur un plus grand nombre de machines.
Dans ce pilote et aussi celui pour les cartes Radeon, le travail se poursuit pour arriver à afficher une image sur les écrans utilisant un connecteur DisplayPort. La configuration du protocole DisplayPort est relativement complexe, avec de nombreuses étapes à franchir avant d'obtenir une configuration complète.
Le pilote VESA peut maintenant patcher le BIOS VESA des cartes graphiques pour y injecter des modes vidéo personalisés. Cependant, cela ne fonctionne pas sur les cartes nVidia et AMD modernes, ce qui limite beaucoup l'utilisation de cette fonctionalité. Ce code ne sera peut-être pas conservé car il y a aussi un risque de "planter" le BIOS de la carte graphique, or le pilote VESA est celui normalement utilisé pour un mode "sans échec". Il faudra donc au moins protéger ce code par une option du fichier de configuration du noyau, et peut-être le désactiver par défaut.
Les pilotes VESA et framebuffer ont été séparés proprement. Ils avaient été fusionnés parce que le serveur applicatif app_server ne pouvait avoir qu'un seul pilote "de secours", mais ce problème a depuis été corrigé. Il n'y avait donc plus de raison de faire cohabiter le code spécifique à VESA avec le code pour les framebuffers dans le même pilote, ce qui était la source de nombreux bugs.
À un niveau beaucoup plus haut, le travail continue pour exploiter correctement les écrans à haute densité de pixels. Les bordures de fenêtres s'adaptent maintenant pour ne pas être ridiculement petites. La police de caractères du debugger noyau dispose maintenant d'une version agrandie pour ces écrans.
Périphériques d'entrée-sortie
Le pilote USB HID comprend maintenant les claviers utilisant le "N-key rollover". Les claviers classiques utilisent un buffer de 8 octets qui permet d'indiquer au maximum 8 touches enfoncées, en indiquant le numéro de chacune d'entre elles. C'est insuffisant en particulier pour l'utilisation dans les jeux vidéos, il existe donc des claviers dit "N-key rollover" qui utilisent un protocole différent, et envoient un tableau de bits dont chacun correspond à une touche du clavier. Cela prend un petit peu plus de bande passante sur l'USB (14 octets au lieu de 8) mais permet d'avoir n'importe quelle combinaison de touches.
Le pilote HID de Haiku n'était pas capable de décoder la réponse envoyée par ces claviers correctement, et la plupart des touches ne fonctionnaient pas. Le problème est maintenant corrigé. De plus, le code de gestion du HID a été retravaillé afin de pouvoir le partager entre les pilotes USB, mais aussi I2C et Bluetooth qui sont encore en chantier et utilisent les mêmes formats de donnéees.
Le pilote PS/2 a reçu quelques corrections pour éviter une réinitialisation du clavier lors de la détection de la présence d'un contrôleur PS/2 avec "active multiplexing" Synaptics. Le code a également été retravaillé pour déplacer une grosse partie de la gestion des touchpads en espace utilisateur, ce qui rendra plus facile les évolutions sur cette partie du code et l'ajout des touchpads Elantech. De plus, ce code pourra aussi être réutilisé pour les nouveaux touchpads connectés en I2C plutôt qu'en PS/2.
Du côté des ports série, le code de gestion des TTY a été retravaillé pour intégrer les évolutions faites dans une copie de ce code utilisée uniquement pour le Terminal. Ceci a permis d'identifier un problème dans la gestion des locks entre les différents morceaux de code interragissant avec le TTY, qui pouvait dans certains cas (assez facile à reproduire) bloquer l'exécution, ou pire, faire planter le noyau. Ces problèmes sont maintenant tous corrigés.
Toujours pour les ports série, un nouveau pilote pour les composants USB série CH340 de l'entreprise chinoise WCH est maintenant disponible (en plus des composants de chez Prolific, FTDI, Silicon Image, et du standard USB-ACM qui est utilisé par exemple pour les modems 3G). Le CH340 se trouve par exemple sur certaines cartes Arduino.
Autres pilotes
La pile USB a reçu encore de nombreuses corrections et elle est à peu près complète pour l'USB2 et l'USB3. Il reste probablement encore des problèmes avec les transferts isochrones, ce qui empêche de finaliser les pilotes pour l'audio USB et pour les webcams. Pour ces dernières, une solution de contournement est disponible : une application Android permet de transformer un téléphone en caméra IP, qui peut être ensuite utilisée dans Haiku.
Il y a eu également quelques évolutions du côté du PCI, en particulier avec la gestion des "BARs" 64bits dans la plupart des pilotes. Il reste encore du travail, par exemple pour résoudre le bug numéro 3, ouvert il y a 17 ans, et qui a été partiellement résolu pour les architectures RISC-V et ARM64, mais pas encore pour x86 et x86_64, car il est plus complexe de traiter les différents mécanismes historiques sur les machines compatible PC en plus du mécanisme moderne utilisant ACPI.
Ces progrès sur le PCI deviennent plus importants d'une part parce que le firmware des ordinateurs modernes ne propose plus forcément de faire l'initialisation nécessaire (c'était le cas autrefois pour assurer la compatibilité avec MS-DOS) et d'autre part parce qu'il n'est plus garanti que tous les devices PCI sont présents lors du démarrage du système. Ça n'est en fait plus le cas depuis pas mal de temps, par exemple avec les cartes ExpressCard, mais c'est de plus en plus courant d'avoir des bus et des périphériques PCI apparaissant (et même disparaissant !) après le démarrage de la machine. On rencontre ce cas de figure avec certaines stations d'accueil pour PC portables, et aussi avec les ports Thunderbolt (aussi appelé USB4) qui est en fait un port PCI avec un connecteur USB-C.
Portage sur de nouvelles architectures
La version RISC-V de Haiku était déjà annoncée dans la dépêche anniversaire de l'année dernière, elle était alors encore en chantier. La plupart des corrections ont été intégrées dans le dépôt Git de Haiku et cette version est maintenant installable à partir des "nightly builds" (elle est encore considérée "expérimentale").
Le travail de X512, le principal développeur de cette version, a été récompensé par Haiku inc qui lui a offert une carte mère pour une machine avec un processeur RISC-V, lui permettant de travailler sur du matériel réel (après avoir fait une première partie du portage en utilisant QEMU et d'autres émulateurs de machines RISC-V).
L'intégration de ce travail a permis de revoir le code de certaines parties de Haiku qui étaient problématiques pour des machines autres que x86. Cela a débloqué la situation pour les versions ARM 32 et 64bits qui sont, sur certains points, assez proches de ce qu'on trouve sur les machines RISC-V. En particulier, la découverte du matériel disponible à partir soit d'un FDT, soit de tables ACPI, est maintenant fonctionnelle. Il est probable que la version ARM de Haiku deviennent très bientôt utilisable.
On peut enfin mentionner la disponibilité d'un chargeur de démarrage EFI 32bit pour les machines x86. Il a été développé principalement en préparation de la version ARM 32bit, mais il peut être utile sur les quelques machines qui n'ont ni BIOS, ni EFI 64bit (les premiers modèles de machines Apple x86, et certaines tablettes par exemple).
Pour la version ARM, une première tentative avait démarré il y a plusieurs années en essayant d'utiliser une API fournie par u-boot pour, par exemple, envoyer des messages vers un port série ou vers l'écran. Cependant, cette API n'était pas toujours disponible sur les machines ciblées. Il fallait donc que le bootloader stage2 se débrouille "tout seul", avec uniquement le FDT comme point de départ pour trouver et initialiser le matériel.
En effet, Haiku dispose d'un chargeur de démarrage en 2 étapes : la première est soit un chargeur minimaliste (par exemple sur x86), soit un bootloader existant (tel que uboot ou un firmware UEFI). Le deuxième niveau est un bootloader spécifique à Haiku et qui est plus complexe. Il permet d'afficher un menu de démarrage dans lequel on peut configurer différentes options (mode sans échec, …), choisir une version de Haiku à démarrer, désactiver des pilotes problématiques, et ainsi de suite. Ce bootloader est également responsable de l'initialisation de la MMU avant de passer la main au noyau, et même d'afficher l'écran de démarrage.
Pour un fonctionnement confortable, ce chargeur a donc besoin d'accéder à pas mal de matériel : écran en mode framebuffer, clavier, ou à défaut un port série. Sur PC, cela peut être fait en utilisant le BIOS ou EFI, et sur les versions PowerPC ou Sparc de Haiku, c'est le firmware OpenBoot ou OpenFirmware qui joue ce rôle. Rien de tel n'était possible avec u-boot.
Cette situation est maintenant résolue puisque u-boot implémente aujourd'hui la spécification EFI. Il est donc possible de réutiliser le code écrit pour les processeurs x86_64 pour la version ARM. Tout le code pour tenter de démarrer à partir d'un u-boot simple sans EFI a été supprimé… enfin presque. Il reste une plateforme PowerPC (la carte Sam440ex) sur laquelle u-boot ne fournit pas l'API UEFI. En effet, le fabricant de cette carte a fait un fork de u-boot dans lequel il a changé énomément de choses sans raison, et ce travail ne sera jamais intégré avec une version mise à jour de u-boot. Il faudra donc trouver une autre solution pour cette carte.
Systèmes de fichiers et périphériques de stockage
Haiku essaie d'être interopérable avec les autres systèmes d'exploitation. Pour cette raison, il est capable au moins de lire, et parfois d'écrire, un assez grand nombre de systèmes de fichiers.
FAT16/FAT32
Le nom de volume des partitions formattées en FAT par mkfs n'était pas initialisé correctement, c'est maintenant chose faite. Au passage, l'outil mkdos a été supprimé (il faut utiliser mkfs comme pour tous les autres systèmes de fichiers).
NTFS
Le pilote NTFS a reçu une grosse mise à jour (en fait c'est plutôt une réécriture) pour être synchronisé avec la dernière version de NTFS-3G. Le pilote existant avait d'abord été développé pour BeOS et n'avait été que partiellement adapté pour Haiku. Cela a permis de corriger de nombreux bugs, et l'intégration de nouvelles versions de NTFS-3G sera beaucoup plus simple.
EXT4
Ajout des dernières fonctionnalités développées dans EXT4 pour pouvoir continuer à utiliser les partitions créées par les nouvelles versions de Linux.
Ajout de la gestion des "spare files" (fichiers dont le contenu comporte des "trous" qui ne sont pas stockés sur le système de fichiers).
XFS
XFS est un des systèmes de fichiers disponibles pour Linux. Il est populaire parmi les développeurs de Haiku en raison de son assez bon support des attributs étendus, qui permet la compilation croisée de Haiku depuis Linux sans avoir besoin d'une couche d'émulation des attributs étendus comme c'est le cas avec EXT4.
Mashijams, un des 4 étudiants participant au Google Summer of Code pour Haiku cette année, est en train d'ajouter au pilote XFS la lecture du système de fichier XFS version 5. Actuellement seule la version 4 était disponible.
UserlandFS
UserlandFS permet d'exécuter des systèmes de fichiers en espace utilisateur. Au départ c'était un outil de debug pour aider au développement de nouveaux systèmes de fichiers, mais il a depuis trouvé d'autres usages.
UserlandFS expose 3 API : la première est compatible avec les systèmes de fichiers écrits pour le noyau de Haiku, la deuxième pour celui de BeOS, et la troisième est compatible avec libfuse (l'équivalent de UserlandFS sous Linux).
C'est cette dernière API qui a reçu une importante mise à jour pour être compatible avec la version 2.9.9 de libfuse, et ajouter les API "lowlevel" exposées par cette dernière. En particulier cela permet d'utiliser android-file-transfer-linux pour monter un téléphone Android utilisant le protocole MTP comme un support de stockage classique.
WebSearchFS
Historiquement appelé GoogleFS, ce système de fichier répond au queries, une fonctionalité qui permet normalement de trouver des fichiers à partir de leurs attributs étendus, qui peuvent être indexés de façon similaire à une base de données. Cependant, plutôt que de chercher dans des fichiers locaux, ce système de fichier va effectuer une recherche sur Internet et exposer les résultats sous forme de fichiers marque-pages qui peuvent ensuite être ouverts avec un navigateur web.
Le scrapping des résultats de recherche de Google est devenu beaucoup trop compliqué, le système de fichiers a été modifié pour se baser sur la version html de DuckDuckGo qui fournit des réponses beaucoup plus faciles à digérer.
Cache
Les systèmes de fichiers implémentés pour Haiku doivent s'interfacer avec le "file cache" afin de stocker en RAM les informations sur les fichiers et limiter les accès disque inutiles.
Cet interfaçage a été complété pour les pilotes btrfs, exfat, et ext4.
"trim"
Sur les SSD, il est possible de fournir au contrôleur de disque une liste des secteurs non utilisés par le système de fichiers. Le contrôleur peut alors effacer ces secteurs et les utiliser au mieux pour le "wear leveling" de la mémoire (répartition des écritures sur tous les secteurs du disque).
Dans Haiku, cela peut être fait à l'aide de la commande fstrim, pour l'instant uniquement pour le système de fichiers BFS.
Différentes corrections ont permis de finaliser l'implémentation pour les contrôleurs SATA, puis peu de temps après, le code nécessaire a été ajouté au pilote NVMe. Cela s'ajoute aux possibilités existantes d'utiliser fstrim: sur un RAMdisk pour libérer de la RAM pour d'autres usages, et sur les cartes SD connectées au travers d'un contrôleur SDHCI (standard défini par la SD association pour interfacer un lecteur de cartes SD sur un bus PCI).
Autres changements
Cela a également été l'occasion de corriger différents problèmes dans le pilote NVMe, qui est maintenant plus rapide et compatible avec la très grande majorité des disques disponibles.
Les derniers problèmes au niveau du stockage concernaient les disques de très grande capacité (plus de 232 secteurs soit 2Tio). Ces problèmes ont enfin été corrigés à différents niveaux (USB, BFS) et tout fonctionne maintenant sans problème.
Compatibilité POSIX et C11
Les API de localisation de POSIX n'étaient pas toutes présentes, celles qui manquaient ont été ajoutées.
La gestion des "weak symbols" a été corrigée. Il s'agit d'une particularité des fichiers ELF qui peut être utilisée de deux façons :
- On peut exporter une fonction en indiquant que le symbole exporté est "faible". Dans ce cas, si une autre bibliothèque ou exécutable fournit une autre fonction avec le même nom, cette deuxième version est utilisée.
- On peut aussi utiliser un marqueur "faible" sur un symbole importé (c'est à dire, par exemple, une fonction qu'on veut appeler). Dans ce cas, si la fonction est présente quelque part, le symbole pointera dessus.
Il y avait un gros problème dans ce deuxième cas si la fonction concernée n'est pas définie : le symbole aurait du prendre la valeur 0, mais il était laissé non initialisé et le résultat était un crash lorsque le code essayait d'appeler une fonction qui n'existait pas.
La nouvelle version C11 du langage C (publiée en 2011 comme son nom l'indique) nécessite des changements dans la bibliothèque standard. Par exemple, une nouvelle APIs pour les threads (qui est simplement implémentée par une surcouche de l'API pthread, en réutilisant le code écrit à cet effet par FreeBSD), ou encore la fonction timespec_get.
Haiku est un peu en retard sur l'implémentation de C11, mais pas sur l'implémentation de POSIX puisque les travaux pour la prochaine version ont déjà commencé. Le groupe d'Austin, qui se charge de faire évoluer la spécification POSIX, a déjà standardisé une liste de nouvelles fonctions qui feront partie de la version "Issue 8" de la spécification POSIX. De plus, il est possible de suivre les discussions sur cette spécification à travers l'outil de suivi des bugs du groupe.
Certaines des fonctions proposées (strlcpy par exemple) étaient déjà implémentées depuis longtemps par Haiku (et par les systèmes *BSD). Dans ce cas il faut simplement vérifier que le comportement correspond précisément à ce qui est décrit, et dans le cas de Haiku, éventuellement déplacer les fonctions concernées de la libbsd vers la libroot et mettre à jour les fichiers d'en-tête pour activer ces fonctions dans les cas où elles doivent l'être.
Dans d'autres cas, les fonctions standardisées n'étaient pas encore présentes dans Haiku et ont du être ajoutées. C'est le cas par exemple de ppoll, de qsort_r, et des fonctions permettant de spécifier quelle horloge il faut utiliser pour les timeouts sur l'acquisition d'un mutex ou d'une condition variable.
Enfin, l'outil strace (qui ne fait pas partie du standard POSIX) a reçu plusieurs mises à jour pour correctement afficher les paramètres de certains appels systèmes.
Applications
Après avoir avancé sur la version RISC-V de Haiku, X512 ne s'est pas arrêté là, et il a réussi à faire fonctionner Wine. Pour l'instant, seules les applications Windows 64bit peuvent être exécutées.
Waddlesplash, quant à lui, souhaitait plutôt utiliser des applications disponibles sous Linux. Comme Haiku n'a pas de serveur X (ni Wayland), cela rend l'utilisation de certains toolkits graphiques sous Haiku un peu compliquée. Sa solution a été d'écrire une bibliothèque fournissant une API compatible avec Xlib, mais qui utilise l'app_server de Haiku pour l'affichage. Cela permet de faire fonctionner facilement les applications utilisant, par exemple, GTK ou python-tk (ou tcl-tk), ainsi que les applications utilisant directement la Xlib.
Cette approche fonctionne plutôt bien, mais X11 n'est pas vraiment une technologie d'avenir. X512 est donc en train de se pencher sur la possibilité d'une approche similaire pour les toolkits et applications utilisant libwayland-client, et quelques captures d'écran d'applications GTK4 fonctionnant sous Haiku circulent déjà.
Cela dit il ne faut pas oublier les applications natives! C'est pourquoi Harshit Sharma (étudiant participant au Google Summer of Code) améliore l'application Agenda avec une refonte de son interface et l'ajout de nouvelles fonctionnalités de synchronisation et de gestion des rendez-vous.
Dans la prochaine version de Haiku on trouvera aussi des améliorations sur le gestionnaire de paquets HaikuDepot (affichage de la taille des paquets installés, affichage de la date de publication des mises à jour de logiciels); un bouton "Enregistrer sous" qui fonctionne correctement dans la visionneuse d'images; un bouton pour éjecter un CD en cours de lecture depuis le lecteur média; l'affichage de la fréquence des processeurs dans ActivityMonitor; plusieurs petits changements dans les applications impliquées dans le premier démarrage et l'installation de Haiku; ou encore une amélioration de l'affichage des octets dans l'éditeur hexadécimal DiskProbe.
Une autre nouveauté importante est l'affichage de vignettes pour les images dans Tracker (l'explorateur de fichiers). Ces vignettes sont bien sûr stockées dans les attributs étendus de chaque fichier, ainsi, si on copie le fichier (même d'une machine vers une autre) il n'est pas nécessaire de regénérer la vignette. Tracker est capable de générer les vignettes pour des images mais il est possible pour chaque application qui enregistre un fichier, quel que soit le format, de générer sa propre vignette si c'est utile.
Le navigateur web WebPositive remonte maintenant dans son User-Agent l'architecture CPU utilisée. Ainsi vous pourrez facilement tracer les deux personnes qui utilisent Haiku avec un processeur RISC-V si vous êtes un GAFAM et que ce genre d'information vous intéresse.
Le navigateur a reçu de nombreuses autres corrections, par exemple pour utiliser les CSS sombres si le système est configuré avec un thème sombre, ou encore la possibilité de glisser un onglet vers une fenêtre du Tracker pour créer un fichier marque-page.
Il devrait également recevoir une mise à jour du moteur WebKit pendant la procédure de publication de la beta 4 (cela ne peut pas être fait avant car la nouvelle version de WebKit a besoin de fonctionnalités qui ne sont pas disponibles dans la beta3, et l'infrastructure de compilation des paquets ne permet pas de facilement maintenir deux versions en parallèle).
Pour terminer, et pour les gens qui préfèrent éviter les interfaces graphiques, quelles qu'elles soient : le Terminal n'est pas oublié ! On peut maintenant configurer la couleur par défaut des 16 couleurs ANSI prédéfinies. De nombreuses séquences d'échappement ont été améliorées, par exemple pour permettre aux applications en console de changer la couleur du curseur, de changer la définition des 256 couleurs personnalisables y compris en utilisant des espaces de couleurs autre que le RGB, et plusieurs petits problèmes de compatibilité ont été résolus.
Et parmi les changements sur les applications en ligne de commande, pkgman peut maintenant afficher un avertissement s'il est contraint, pour résoudre des dépendances, de réinstaller une version plus ancienne d'un paquet.
Système de build
Haiku est désormais compilé avec gcc 11.2 et bientôt 11.3. Le noyau est compilé avec ce compilateur, y compris pour la version x86 32-bits de Haiku qui est la seule à utiliser encore gcc2 pour certaines parties du système afin d'assurer la compatibilité binaire avec les applications écrites pour BeOS. Il n'était déjà plus possible depuis plusieurs années d'utiliser les pilotes écrits pour BeOS, et personne ne s'en est plaint. Continuer à compiler le noyau avec gcc2 était donc inutile.
Certaines règles de compilation ont été nettoyées pour retirer des scripts de link inutiles et des flags de compilation incorrects. Ceci simplifie le portage vers d'autres architectures.
Dominic Martinez participe au Google Summer of Code pour terminer le développement de Ham, un projet commencé il y a une dizaine d'années pour remplacer Jam.
Jam est l'outil utilisé pour compiler Haiku, il est inspiré de Make mais en essayant de définir des règles réutilisables (par exemple "comment fabriquer un fichier .o à partir d'un fichier .c") plutôt que des règles spécifiques pour chaque fichier. Jam n'est plus maintenu par Perforce, et le code de l'outil n'est pas assez propre pour pouvoir facilement le faire évoluer nous-même. Ham ("jambon", en anglais) va donc remplacer Jam ("confiture") pour compiler Haiku. Il sera compatible non seulement avec la version de Jam utilisée par Haiku, mais aussi avec la version originalement développée par Perforce, et avec B2, un autre fork de Jam maintenu par le projet Boost.
Ham sera non seulement un outil en ligne de commande, mais aussi une bibliothèque qui pourra être intégrée dans un IDE ou autre outil graphique de gestion de compilation.
Enfin, pour accompagner Ham, une mise à jour du Jamfile engine a été mise à disposition des développeurs d'applications. Il s'agit d'un ensemble de règles utilisables dans un projet utilisant Jam pour facilement compiler une application (ou une bibliothèque ou un add-on) pour Haiku. Cependant, le Jamfile engine dans sa version actuelle est loin d'être satisfaisant et il sera probablement complètement réécrit.
D'autre part, le travail de fond pour compiler l'intégralité de Haiku sans aucun warning du compilateur se poursuit. Chaque nouvelle version de gcc apporte son nouveau lot de problèmes à corriger. Malheureusement, une bonne partie d'entre eux vient de code tiers qui n'est pas maintenu par l'équipe de Haiku. Parfois les modifications peuvent être envoyées aux auteurs originaux, mais ce n'est pas toujours le cas.
La prochaine version, c'est pour quand?
Il y a encore 14 tickets dans la liste de choses à faire pour la beta4, dont quatre sont en priorité "bloquante" et un en priorité "critique". Votre aide est la bienvenue si vous pensez pouvoir aider à résoudre l'un de ces problèmes. Les autres tickets listés pourront être repoussés vers la prochaine version (après tout, ce n'est qu'une version beta et il y en aura d'autres).
Un petit résumé de ces 5 tickets à résoudre :
Un travail en cours pour cacher par défaut tous les symboles exportés par la bibliothèque statique libshared. Cette bibliothèque contient des API expérimentales pour lesquelles il n'y a pas de garantie de compatibilité lors des mises à jour de Haiku. Cependant, une grande partie du code est dans ce cas, et cette bibliothèque est utilisée à peu près partout, y compris dans d'autres bibliothèques de Haiku.
Suite à une erreur de configuration de l'éditeur de lien, une bibliothèque partagée qui est liée avec la libshared finit par ré-exporter une partie de cette API expérimentale. Et comme c'est le cas depuis un certain temps, quelques applications ont fini par utiliser les fonctions ainsi ré-exportées. Il faut donc identifier et corriger ces applications avant de corriger le problème dans Haiku.
Sur certaines machines équipées de CPU Intel de 11ème génération, par exemple les PC portables modulaires de la marque Framework, Haiku détecte une fréquence d'horloge de plusieurs dizaines de GHz, ce qui est bien sur incorrect. Cela conduit à un système fortement ralenti, à moins que ce soit le ralentissement du système qui cause la mauvaise détection.
Toutes les machines utilisant ces CPU ne sont pas concernées et pour l'instant les développeurs de Haiku n'ont pas trouvé d'ou le problème pourrait venir.
Une régression sur le pilote VESA qui empêche le système de démarrer sur au moins une machine. Comme cela a été mentionné plus haut dans le paragraphe sur le pilote VESA, l'approche la plus simple est de désactiver le patching du BIOS pour ajouter des résolutions d'écran personnalisées.
Le correctif est en cours de relecture.
Une mise à jour de FFmpeg. Elle ne pose pas de problème pour Haiku, mais tous les paquets de Haikuports qui dépendent de FFmpeg vont devoir être recompilés. Comme ces paquets vont aussi être recompilés en préparation de la release, c'est une bonne idée de faire ces deux mises à jour simultanément.
Il s'agit d'une fuite mémoire assez importante, a priori liée à l'utilisation d'un réseau où il y a beaucoup de trafic multicast. La principale difficulté pour investiguer ce problème est de connecter un réseau aussi chargé à la machine d'un développeur, à un moment ou il est disposé à se lancer dans une investigation (pas au milieu d'un hall de gare ou d'aéroport avec un Wifi public en correspondance entre 2 trajets, par exemple).
Et la version 1, alors?
Après plus de 20 ans, on peut se demander si le projet avance vraiment. Le meilleur outil de suivi pour mesurer cela est la feuille de route sur l'outil de suivi de tickets Trac.
L'objectif de départ pour la version 1 de Haiku était initialement de fournir un remplacement complet, composant par composant, de la dernière version officielle de BeOS R5 (5.0.3), plus la mise à jour "Bone" qui remplaçait la pile réseau de BeOS implémentée entièrement dans l'espace utilisateur par une implémentation plus classique intégrée dans le noyau.
Ces objectifs ont été revus en 2010, après la sortie de la version alpha1, avec un sondage de la communauté d'utilisateurs et des développeurs pour voir s'il fallait ajouter d'autres objectifs. L'époque était plutôt optimiste et pas mal de choses ont donc été ajoutées : le Wifi, la possibilité d'installer des mises à jour du système, etc.
Tous ces objectifs ont été atteints, ce qui a permis d'entrer en phase "beta", phase dans laquelle on se consacre à la correction de bugs et à l'amélioration des performances.
Ces deux dernières années, du tri a été fait dans les tickets pour mieux définir ceux qui sont vraiment indispensables à la version 1. De plus, les tickets résolus sont maintenant déplacés dans le jalon correspondant à la prochaine version publiée.
Cela permet de voir que la version beta 4 (un peu plus d'un an de travail) contient plus de 270 corrections par rapport à la version précédente. Et d'autre part qu'il ne reste que 641 tickets ouverts avant d'arriver à la version R1. Si aucun bug n'est découvert d'ici là, il faudrait donc encore 3 ou 4 ans de travail pour arriver à publier une version 1 (ce n'est bien sûr qu'une estimation très imprécise).
Cependant, tous les développeurs ne sont pas concentrés exclusivement sur la correction de bugs et les autres tâches ennuyeuses conduisant à la version R1. De nouvelles fonctionnalités continuent d'être développées et l'écriture de pilotes pour du matériel récent demande aussi beaucoup de temps.
Financement
Pour progresser plus vite, il faut augmenter le nombre de contributeurs, ou bien le temps qu'ils peuvent consacrer au projet. Pour cette deuxième solution, une solution en ce moment est d'embaucher un développeur (Waddlesplash) 32 heures par semaine ce qui le dispense d'avoir un travail rémunéré en plus de ses activités sur Haiku. Le paiement proposé est en dessous du prix du marché pour un développeur avec son niveau d'expérience. On en parlait l'automne dernier sur LinuxFr.org.
Ce n'est pas la première fois que Haiku embauche un développeur à plein temps. Le précédent contrat le plus long a duré près d'un an, c'était PulkoMandy qui avait travaillé en 2014, entre autres choses, sur la mise à jour du moteur WebKit pour le navigateur web de Haiku. Depuis 2015 il n'y avait pas eu d'autre contrat aussi ambitieux, mais Haiku inc a continué de recevoir des donations ainsi qu'une compensation financière pour sa participation au Google Summer of Code. ce qui lui a permis d'accumuler des réserves de trésorerie suffisantes pour pouvoir proposer à nouveau un contrat à long terme.
Cependant, sans une augmentation importante des finances de l'association, ce contrat ne pourra durer qu'un an ou deux, après quoi l'association sera à court d'argent. L'objectif est donc de réussir à attirer de nouveaux donateurs, et il faudrait quadrupler leur nombre pour avoir une situation durable avec un employé. Dans ce cadre, plusieurs choses ont été mises en place :
-
Une boutique sur le site Freewear permettant d'acheter des vêtements et autres goodies aux couleurs de Haiku, avec un pourcentage des ventes reversé à l'association,
-
Un compte Liberapay qui permet de recevoir des dons via Stripe, et donc avec des virements SEPA (compliqués à mettre en place sur un compte en banque Américain),
- L'ouverture des dons via Github sponsors, option la plus intéressante car il n'y a aucun frais des opérateurs de paiement (c'est Microsoft qui paie).
- Une meilleure communication de l'association sur son budget et ses besoins financiers
L'association essaie également de convertir ses Bitcoins (donations reçues il y a longtemps alors que les cryptomonnaies n'avaient que peu de valeur) en vrai argent, cependant, pour l'instant, des problèmes administratifs avec l'opérateur Coinbase empêchent cette transaction (débloquer les fonds nécessiterait de payer des taxes personellement pour l'un des membres de l'association).
Le rapport financier 2021 donne quelques chiffres :
- L'association a reçu environ 24000$ de dons (c'est mieux que l'année précédente, seulement 17000$)
- Elle a dépensé environ 17000$ dont 13000$ pour rémunérer Waddlesplash pour 300 heures (réparties sur 4 mois en fin d'année)
- Les réserves sont de 111000$, plus environ 172000$ en cryptomonnaies (mais ces dernières ont perdu beaucoup de valeur depuis)
L'objectif pour 2022 est de continuer à augmenter les dons reçus. Les dépenses vont également augmenter puisque Waddlesplash travaille pendant l'année complète. Le budget 2022 sera donc probablement déficitaire. Il faudra atteindre 80000$ de dons par an pour pouvoir rémunérer Waddlesplash de façon permanente. Puis continuer à augmenter ce chiffre pour embaucher un.e deuxième développeur.se par la suite?
Statistiques de contribution
Statistiques pour Haiku
Statistiques pour HaikuPorts
L'an dernier, Haiku comptait 305 contributeurs. Cette année il y en a 324. Ce sont donc 19 personnes qui ont proposé pour la première fois cette année un patch ou un changement qui a été intégré dans le code.
L'année 2021 a été la moins active pour le projet depuis le début de l'utilisation de Subversion (par la suite le projet a migré à Git en conservant l'historique Subversion), avec seulement 1106 commits. Il n'y a eu que 51 personnes qui ont contribué au moins un changement en 2021, ce qui est peu.
Cependant, le projet HaikuPorts (qui contient les "recettes" permettant de compiler des logiciels pour Haiku se porte beaucoup mieux : le nombre de commits se maintient, et le nombre de contributeurs pendant l'année 2021 est de 72, battant le record de l'année précédente (70). HaikuPorts commence à recevoir des contributions de développeurs qui mettent à jour ou empaquettent leurs propres logiciels.
Il y a actuellement 3172 logiciels empaquetés dans HaikuPorts, dont 1357 nécessitent encore un patch qui n'a pas été intégré par les développeurs des logiciels concernés (ils n'ont pas forcément tous étés soumis aux projets upstream par l'équipe de Haikuports).
Il y a 25 nouveaux contributeurs pour Haikuports cette année (on passe de 250 à 275 personnes ayant contribué au moins un patch).
Aussi bien dans Haiku que dans HaikuPorts, de nouveaux contributeurs ont fait leur apparition dans le top 6 annuel des contributeurs les plus actifs.
