Environ une semaine après le 25ème anniversaire de Haiku, c'est le moment de publier la sixième version beta de Haiku R1. Nous avons parcouru beaucoup de chemin depuis le lancement du projet en 2001, il y a un quart de siècle. Merci à toutes les personnes qui nous ont soutenus et encouragés dans cette aventure, et souhaitons plein de belles choses pour les 25 prochaines années de Haiku !

Haiku est développé par une petite équipe principalement bénévole, et sans utilisation d'"intelligence artificielle" dans les composants développés au sein du projet. Si notre mission, le développement d'un système d'exploitation pour les ordinateurs personnels, vous attire, n'hésitez pas à nous rejoindre !

Cette version est le résultat de plus de deux ans de travail de l'équipe de développeurs de Haiku pour améliorer la stabilité, ajouter de nouvelles fonctionnalités, et rendre possible le portage de nombreux logiciels. Plus de 530 rapports de bugs et demandes d'améliorations ont été traitées.

Haiku reste en version beta, ce qui signifie que toutes les fonctionnalités prévues pour la version R1 sont disponibles, mais qu'il reste des bugs (connus et inconnus). Nous sommes de plus en plus confiant en ce qui concerne la stabilité du système, mais il n'y a aucune garantie par exemple contre les pertes de données.

Durant ce cycle de publicaction, waddlesplash a été embauché et rémunéré pour travailler sur Haiku. Ce contrat se poursuit, grâce aux donations généreuses d'utilisateurs et autres soutiens de Haiku à l'association Haiku, inc. (association à but non lucratif sous le statut États-Unien 501(c)3).

Sommaire

• Configuration matérielle
  • MINIMUM (32-bit)
  • RECOMMANDÉE (64-bit)
• Nouvelles fonctionnalités
  • Mozilla Firefox
  • Virtualisation matérielle pour QEMU (sur x86_64)
• Logiciels portés
  • Go
• Modifications & corrections de bugs
  • Optimisation des performances du système
  • Amélioration de l'interface utilisateur
    • Tracker: Mise à jour en direct des menus lors de l'utilisation de modificateurs clavier
    • Tracker : Filtrage par dossier des résultats de requêtes
    • Nettoyage disque dans SoftwareUpdater & pkgman
    • Screenshot : sélection de zone à capturer
    • Team monitor : regroupement des équipes de processus
    • DriveSetup : menu "Images disque"
    • app_server : récupération des applications au redémarrage
    • PowerStatus : Meilleure gestion des machines avec plusieurs batteries
    • Amélioration du "mode sombre" et de l'affichage HiDPI dans de nombreuses applications
    • launch_roster : résumé du statut
  • Amélioration de la gestion de la mémoire
    • Nouvelle implémentation de malloc pour l'espace utilisateur
    • Améliorations sur le découpage de zones mémoire (areas)
    • Amélioration du comportement lorsque la mémoire est presque pleine
    • Améliorations de guarded_heap
  • Améliorations sur les systèmes de fichiers
  • Compatibilité matérielle
    • Cartes son
    • Modifications volatile du BIOS VESA
    • Pilotes pour toujours plus d'interfaces USB ethernet & WiFi
  • Compatibilité POSIX améliorée
  • Stabilisation du système
• Les scènes coupées
  • ARM64
  • WebKit multiprocessus
• Nouveau contributeurs
• Code source
• Remonter des problèmes

Configuration matérielle

Cette version est disponible pour les machines utilisant un processeur compatible x86, 32 ou 64-bit.

Seule la version 32-bit permet de lancer les exécutables compilés pour BeOS R5.

MINIMUM (32-bit)

• Processeur : Intel Pentium II; AMD Athlon
• Mémoire : 256Mio
• Écran : 800x600
• Espace disque : 2Gio

RECOMMANDÉE (64-bit)

• Processeur : Intel Core i3; AMD Phenom II
• Mémoire : 2Gio
• Écran : 1366x768
• Espace disque : 16Gio

Le jeu d'instructions SSE2 est nécessaire pour lancer le navigateur web WebPositive. Sur les machines où SSE2 n'est pas disponible, le navigateur NetSurf peut être utilisé à la place.

Nouvelles fonctionnalités

Mozilla Firefox

Quelques mois après la publication de la version R1 beta5, les premiers navigateurs basés sur Mozilla Firefox ont fait leur apparition dans les dépôts logiciels de Haikuports. Ils étaient assez instables et n'utilisaient pas les marques officielles de Mozilla. Au cours des deux années suivantes, la stabilité s'est beaucoup améliorée, avec du travail aussi bien du côté de Haiku que du côté du portage. La dernière étape a été d'obtenir la permission de Mozilla pour utiliser le nom et le logo "Firefox". Donc, si quelqu'un vous demande "Mais est-ce que Firefox fonctionne sur Haiku?", maintenant vous pouvez répondre : "Oui, bien sûr !"

Un large choix de logiciels basés sur le code de Firefox est également disponible dans HaikuDepot, comprenant LibreWolf, Waterfox, Floorp, Icedove (une version de Thunderbird dégriffée) et quelques autres.

(Notez que Firefox est disponible uniquement pour les systèmes x86_64 pour l'instant. Et, puisque Haiku est toujours en version beta, si vous rencontrez des fonctionnalités manquantes ou incomplètes par rapport aux versions de Firefox pour d'autres systèmes, c'est probablement de notre faute et pas celle de Mozilla. Merci de remonter ces problèmes dans l'outil de suivi de bugs de HaikuPorts).

Virtualisation matérielle pour QEMU (sur x86_64)

Haiku permet maintenant d'utiliser "NVMM", le NetBSD Virtual Machine Monitor (qui a été développé pour NetBSD, mais a déjà été porté également vers DragonflyBSD avant Haiku). Cela permet d'utiliser l'accélération matérielle de la virtualisation dans QEMU, sur les systèmes x86_64 qui disposent des instructions Intel VT-x ou AMD-V. Les machines virtualisées peuvent être en 32 ou 64 bits, avec SMP, et le large choix de périphériques matériels émulés par QEMU, le tout pour un large choix de systèmes invités. Ajoutez simplement -accel nvmm aux arguments en ligne de commande de QEMU.

(L'accélération NVMM est encore en phase expérimentale. Merci de remonter tous les problèmes rencontrés sur le bug tracker de Haiku.)

Logiciels portés

Le projet HaikuPorts continue de maintenir une large sélection de logiciels pour Haiku. Il y en a beaucoup trop pour tout lister ici, y compris de nombreuses applications KDE et GTK. Mais voici l'un des plus remarquables :

Go

Le compilateur et l'environnement d'exécution pour le langage Go sont disponibles dans les dépôts de paquets. C'est une version un peu ancienne (1.26.1) et le code n'a pas encore été soumis aux développeurs de Go; mais de nombreux paquets fonctionnent bien sous Haiku, avec éventuellement quelques ajustements. Par exemple, il est possible d'utiliser Hugo, l'outil de génération de sites statique qui permet d'éditer le site de Haiku.

Modifications & corrections de bugs

Des centaines de bugs, corrections mineures et demandes d'améliorations ont été traitées depuis la version précédente. Il y en a beaucoup trop pour tout énumérer, les rapports d'activité trimestriels sur Linuxfr (ou mensuels en version originale) vous permettront d'avoir une vision plus détaillée de ces changements.

Presque toutes les parties du système ont bénéficié d'au moins un peu d'attention, et le résultat est que cette version beta 6 et la plus stable et la mieux finie jusqu'à présent. Il reste cependant encore quelques points de friction à certains endroits, ce qui explique que cela reste une version beta.

Optimisation des performances du système

Cette version comprend un grand nombre de changements et de refactorisations pour améliorer les performances générales. Voici une liste (assez technique) des principaux points:

• Refonte de la gestion des tampons mémoire du renifleur de types MIME (la détection des types de fichiers est au moins 5 à 10 fois plus rapide)
• Fonctions de hachage de chaîne de caractères plus rapides (et avec de meilleures propriétés)
• granularité des verrous dans plusieurs composants du noyau : le gestionnaire de mémoire (réservations et dé-réservations de mémoire), le VFS (recherche de descripteurs de fichiers, changement d'état des vnode inutilisés, recherhce de la racine des contexte E/S), timers utilisateur, et encore d'autres.
• évitement d'un verrou exclusif dans les FIFO (pipe()), ce qui permet de traiter des données à plusieurs Gio/s au lieu de quelques centaines de Mio/s auparavant
• utilisation d'allocateurs "arena" pour les allocations de mémoire de travail (par exemple dans les FIFOs, et dans packagef`), ce qui permet d'esquiver tout un tas de changements et d'invalidation de la table des pages dans le noyau
• omission de certaines tâches réalisées par une opération fork traditionelle lors de l'utilisation de vfork (il ne s'agit pas d'un vrai vfork, mais d'une approximation compatible avec les utilisations raisonnables)
• remplacement ou réécriture de fonctions de bases de la bibliothèque C par des versions optimisées : memmove, strlen, strcmp, memcmp, et bien d'autres
• recalibration des classes de taille de l'allocateur malloc du noyau (les valeurs utilisées avaient été sélectionnées en 2007 et pas vérifiées depuis)
• ajout d'heuristiques pour pré-mapper les gros fichiers (ce qui bénéficie aux grosses applications qui sont lancées à mainte reprises, par exemple gcc)
• utilisation de verrous non-exclusif et d'opérations atomiques lorsque c'est possible dans les primitives du noyau pour l'envoi de messages entre cœurs de processeur
• Le cache d'entrées de répertoire n'a plus besoin d'un verrou en écriture pour insérer des éléments. De plus, il stocke la valeur de hash des chaînes pour éviter des comparaisons de chaînes inutiles
• Utilisation de verrous en lecture-écriture dans le cache de blocs disque (utiliser pour mettre en cache les inodes et métadonnées des systèmes de fichiers).

Les deux derniers points en particulier ont un effet spectaculaire sur les opérations qui accèdent à beaucoup de fichiers d'affilée, comme git status. Lors d'un test de ces modifications, la durée d'exécution de git status sur un dépôt comportant plus de 160000 fichiers est passé de 33 à 20 secondes sans préchargement du cache disque, et de 15 à 2.5 secondes une fois le cache préchargé !

L'effet cumulé de toutes ces optimisations (et aussi des changements sur la gestion de la mémoire, détaillés plus bas) sur le temps de compilation est assez significatif. Les travaux de compilation assez simples ne sont qu'un peu plus rapide qu'avant (on partait d'assez loin, avec environ 40% de performance en moins par rapport à Linux), mais pour des tâches plus complexes, cela change tout. La compilation de HaikuWebKit (même version, même compilateur, même machine, ensemble de dépendances très proche) durait 4h53 avec la version beta 5, mais seulement 2h33 avec la version beta 6, soit une réduction presque de moitié !

Amélioration de l'interface utilisateur

Tracker: Mise à jour en direct des menus lors de l'utilisation de modificateurs clavier

Dans Tracker - le navigateur de fichiers de Haiku -, certains opérations modifient leur comportement lorsqu'elles (ou leur raccourci clavier) sont invoquées avec la touche Shift enfoncée. Maintenant, si vous enfoncez ou relachez cette touche alors qu'un menu est ouvert, les éléments du menu se mettent à jour pour montrer ce qu'il va effectivement se passer si vous cliquez dessus.

Tracker : Filtrage par dossier des résultats de requêtes

Haiku a hérité certaines fonctionnalités uniques de BeOS. L'une d'entre elles est un système de fichiers qui se comporte également comme une base de données, permettant l'indexation des attributs étendus des fichiers et permettant d'exécuter des requêtes sur l'ensemble d'un système de fichier pour trouver rapidement les fichiers correspondant à certains critères.

Ces requêtes fonctionnent nécessairement sur l'ensemble du système de fichiers (car l'indexation ne stocke pas d'informations sur le chemin du fichier). Cependant, il est parfois utile de restreindre les résultats à une hiérarchie de dossiers spécifique. Cela est maintenant possible via la fenêtre de recherche du Tracker, qui effectuera un filtrage des résultats de requêtes aux dossiers sélectionnés.

(L'outil en ligne de commande query permet maintenant également de filtrer les résultats par dossier.)

Nettoyage disque dans SoftwareUpdater & pkgman

Les paquets logiciels pour Haiku sont des images de système de fichier compressées par blocs. Elles sont montée au démarrage dans une "union" permettant de construire le système de fichier du dossier système. Cela signifie que l'installation et la désinstallation de logiciels sont des opérations peu coûteuses, il s'agit s'implement d'ajouter ou d'enlever des paquets du point de montage en union. De plus, le système peut conserver les anciens paquets et l'état précédent du système. Cela permet de revenir facilement à une ancienne version d'un logiciel, ou même de rembobiner l'état complet du système, via le menu de démarrage.

Jusqu'à présent, ces points de restauration n'étaient jamais supprimés automatiquement (à moins d'utiliser un outil tiers pour s'en charger), et ils pouvaient donc s'accumuler indéfiniment, remplissant petit à petit tout l'espace disque disponible. Maintenant, SoftwareUpdater nettoie automatiquement les états les plus anciens (ce comportement est désactivable dans la fenêtre de réglages), et l'outil en ligne de commande pkgman affiche un message lorsqu'il y a beaucoup d'états sauvegardés, recommandant de lancer la commande pkgman cleanup pour faire du ménage.

# pkgman install/uninstall/full-sync...
[system] Changes applied. Old activation state backed up in "state_2026-08-22_22:38:28"
[system] Cleaning up ...
[system] Done.
[system] 3 old state(s) can be cleaned up. Use "pkgman cleanup" to remove them.

$ pkgman cleanup
Clean up 3 old states (166.27 MiB)? [yes/no] (yes) :

Screenshot : sélection de zone à capturer

L'outil de capture d'écran (déclanché par la touche Impr Écr de votre clavier) peut maintenant vous laisser sélectionner une zone rectangulaire de l'écran à capturer. Cela se rajoute aux possibilités existantes : capture de tout l'écran ou d'une seule fenêtre.

Team monitor : regroupement des équipes de processus

"Team monitor", l'outil de gestion des processus qui apparaît lorque vous appuyez sur Ctrl+Alt+Suppr, groupe maintenant les processus en tâche de fond lancés par une application graphique dans une liste en-dessous de cette application. Cela rend plus confortable l'utilisation de cette fenêtre lorsqu'un terminal est ouvert avec de très nombreux onglets, ou encore un navigateur web multiprocessus.

DriveSetup : menu "Images disque"

DriveSetup, l'outil de configuration des partitions, sait maintenant utiliser des images de disques. Le nouveau menu ajouté à cet effet permet de créer une image disque à partir d'une partition, d'écrire une image disque sur une partition, et aussi d'"enregistrer" une image disque dans le noyau pour y accéder directement comme à un disque réel (montage, démontage, création de partitions, etc).

app_server : récupération des applications au redémarrage

app_server, le serveur d'applications de Haiku (qui est aussi le serveur d'affichage, gestionnaire de fenêtres et responsable du tracé du contenu des fenêtres), est un composant central de Haiku. En cas de crash ou de redémarrage intentionnel, il peut maintenant se reconnecter aux applications en cours d'exécution et remettre en place leurs fenêtres comme si de rien n'était. Il n'est donc plus nécessaire de redémarrer le système ou la session utilisateur en cas de plantage. Dans la plupart des cas, les applications pourront reprendre leur fonctionnement normal après seulement une poignée de secondes.

PowerStatus : Meilleure gestion des machines avec plusieurs batteries

PowerStatus, l'application qui affiche l'information sur les batteries et l'icône de batterie dans la Deskbar, fonctionne mieux sur les machines avec plusieurs batteries, en particulier si certaines batteries sont enlevées alors que la machine est en fonctionnement, ou si une batterie se chage pendant qu'une autre se décharge.

Amélioration du "mode sombre" et de l'affichage HiDPI dans de nombreuses applications

Il y a eu un grand nombre de corrections et d'améliorations dans les applications inclues dans Haiku pour l'affichage en mode sombre et sur les écrans à haute densité : certaines couleurs étaient codées en dur, des dégradés n'étaient pas cohérents, des tailles d'éléments en nombre de pixels fixes, et ainsi de suite.

launch_roster : résumé du statut

L'outil en ligne de commande launch_roster permet d'interagir avec le gestionnaire de services de Haiku (launch_daemon). Il a reçu une grosse mise à jour, pour afficher une table réacapitulant l'état de tous les jobs et services :

$ launch_roster
                           Name  Type     State    Enabled
----------------------------------------------------------
     check-daylight-saving-time  job      stopped  yes
                    first-login  job      stopped  yes
                    update-time  job      stopped  yes
                  x-vnd.be-trak  service  running  yes
                  x-vnd.be-tskb  service  running  yes
         x-vnd.haiku-app_server  service  running  yes
          x-vnd.haiku-autologin  job      stopped  yes
       x-vnd.haiku-debug_server  service  running  yes
       x-vnd.haiku-media_server  service  running  yes
       x-vnd.haiku-mount_server  service  running  yes
         x-vnd.haiku-net_server  service  running  yes
x-vnd.haiku-notification_server  service  stopped  yes
     x-vnd.haiku-package_daemon  service  running  yes
       x-vnd.haiku-power_daemon  service  running  yes
          x-vnd.haiku-registrar  service  running  yes

Amélioration de la gestion de la mémoire

En plus des autres optimisations de performances déjà mentionnées, il y a eu un gros travail sur plusieurs aspects liés à la gestion de la mémoire, dont certains pour rendre les choses plus rapides, et d'autres simplement pour simplifier le code ou pour réduire la consommation de mémoire. Voici quelques-uns des plus intéressants :

• optimisation des structures de données de packagefs, réduisant l'occupation mémoire d'environ 20% (la quantité exacte dépend du nombre de paquets installés, par exemple environ 15Mio sur une installation représentative utilisée pour tester ces changements)
• gestion plus rapide et plus correcte des attributs de la mémoire (sur x86 et x86_64)
• correction de la gestion du copy-on-write pour les zones protégées par mprotect. Le nouveau code est plus rapide et moins buggé.
• plusieurs améliorations pour pouvoir démarrer Haiku sur des machines avec beaucoup de RAM (plus de 128Gio)
• Tracker ne surveille plus les fichiers un par un via le node monitor, il surveille plutôt des dossiers entiers, ce qui économise de la mémoire du côté du noyau
• unification du système de réservation de zones mémoires pour la mémoire RAM et la swap
• correction d'allocations faites avec le mauvais allocateur dans le bootloader, des allocations qui devaient être temporaires n'étaient pas libérées avant le démarrage du noyau et restaient réservées pour toute la vie du système (jusqu'à 100Mio de mémoire perdus et rendus inutilisables par le noyau dans certains cas)

L'accumulation de tous ces changements fait qu'il est maintenant possible de démarrer la version 32-bit de Haiku avec seulement 128Mio de mémoire (et même encore moins si on utilise un système dégraissé), et arriver à lancer quelques applications. Bien sûr, difficile de lancer un navigateur web moderne dans ces conditions !

Mais ce n'est pas fini, certains changements encore plus importants méritent leurs propres paragraphes d'explications:

Nouvelle implémentation de malloc pour l'espace utilisateur

Haiku utilisait depuis très longtemps une version modifiée de l'allocateur hoard2 pour implémenter la famille de fonctions malloc dans la bibliothèque C standard. Cet allocateur est d'une conception assez ancienne, et ne tient plus la comparaison avec les derniers développements dans le domaine (y compris les versions plus récentes de hoard). Le remplacement de cet allocateur était donc un sujet de discussion parmi les développeurs depuis quelques années déjà.

Aprés l'évaluation et l'expérimentation de plusieurs alternatives, le choix s'est finalement porté sur la réutilisation de code écrit par OpenBSD, avec des perfectionnements supplémentaires pour l'adapter à notre usage (par exemple, un cache global limitant la nécessité d'appels système). Ce nouvel allocateur est légèrement plus rapide dans la plupart des cas, et beaucoup plus rapide dans certains cas particuliers qui mettaient en évidence les problèmes de l'architecture de hoard2. Surtout, cet allocateur est bien meilleur que ses concurrents pour remettre rapidement la mémoire inutilisée par une application à la disposition du reste du système, ce qui est particulièrement utile pour des applications qui restent lancées longtemps, et sur du matériel où la quantité de mémoire disponible est limitée. Il est également économe en termes d'utilisation de l'espace d'adressage, ce qui est important pour les systèmes 32 bits qui sont laissés de côté par d'autres allocateurs récents.

Améliorations sur le découpage de zones mémoire (areas)

Lorsqu'une application demande un gros morceau de mémoire (par exemple avec la fonction mmap), puis libère un petit morceau situé au milieu de cette zone (avec munmap), le noyau doit réorganiser ses structures de données et remplacer la gestion d'une zone unique et contigüe par deux zones séparées. Cette opération n'est pas simple à implémenter, surtout si la zone mémoire concernée est partagée avec d'autres processus, a des restrictons d'accès par pages (mprotect), ou d'autres cas particuliers.

L'implémentation de cette opération de découpage dans Haiku était incomplète, mais l'implémentation précédente de Haiku n'en faisait pas usage. Les problèmes éventuels ne concernaient donc que les applications implémentant leur propre gestion de la mémoire: ramasse-miettes, ou utilisation d'une implémentation alternative de malloc par exemple. Ces cas sont relativement rares, donc les problèmes n'avaient pas forcément été détectés. Le nouvel allocateur, ainsi que plusieurs navigateurs web récemment portés sur Haiku, quant à eux, font un usage beaucoup plus important de cette possibilité. Le code a donc du être repris pour pouvoir réagir correctement dans toutes les situations.

Amélioration du comportement lorsque la mémoire est presque pleine

Haiku n'implémente pas d'overcommit de la mémoire par défaut (et ne dispose donc pas d'un "OOM killer"). Les applications qui ont besoin de zones allouées avec overcommitting doivent le demander explicitement, avec un contrôle par area ou par region, et le manque de mémoire lors de l'accès effectif à ces zones n'impacte que les applications concernées (qui peuvent alors intercepter le problème et réagir en libérant des ressources si possible). Dans tous les autres cas, la mémoire est réservée (mais pas allouée) dès que l'application en fait la demande, et s'il n'y a pas de mémoire disponible, la fonction d'allocation retourne une erreur (par exemple ENOMEM).

Cependant, il ne suffit pas de retourner une erreur, encore faut-il que tous les composants du système sachent comment y réagir. Puisque toutes les allocations qui ne sont pas faites avec de la mémoire réservée à l'avance peuvent échouer, le noyau et tous les pilotes de périphériques doivent traiter le cas ou une fonction comme malloc retourne une erreur ENOMEM. Certains autres systèmes garantissent que l'implémentation de malloc dans le noyau n'échoue jamais (quitte à tuer des applications pour faire de la place).

Une mauvaise gestion de ces erreurs - ou de leurs conséquences qui peuvent mettre le système dans un état inhabituel - peuvent déclencher des comportements inattendus, dans le pire des cas, des crash ou des softlock (le système devient tellement lent qu'il est inutilisable). Un certain nombre de problème de ce type ont été corrigés, et il y a de bonnes chances que le système finisse par retourner dans un état stable une fois la mémoire libérée.

Améliorations de guarded_heap

En plus des implémentations par défaut de malloc dans l'espace utilisateur et dans le noyau, qui sont conçues pour une utilisation généraliste "en production", Haiku offre un choix d'implémentations de malloc pour l'aide au débuggage. L'une d'entre elles s'appelle guarded_heap, et place chaque allocation à la fin d'une page de mémoire et juste avant une autre page qui n'est pas mappée. Ceci gaspille énormément de place, mais permet de détecter immédiatement 100% des débordements de tampons. Cet allocateur permet même de désactiver la réutilisation de la mémoire libérée, dans ce cas il détecte en plus l'accès à de la mémoire libérée. Tout ceci se fait sans avoir besoin d'instrumenter le code, et donc, sans avoir besoin de recompiler l'application ou les bibliothèques concernées (contrairement par exemple aux options -fsanitize de gcc et llvm).

L'implémentation de guarded_heap pour le noyau a été complètement réécrite, pour y ajouter toutes les fonctionnalités disponibles dans la version pour l'espace utilisateur. Elle peut maintenant être activée sans recompiler le noyau (via une option du bootloader). Ceci n'est cependant possible que dans les versions "nightly builds" de Haiku, les versions stables désactivant cette option pour améliorer les performances.

Améliorations sur les systèmes de fichiers

Les systèmes de fichiers ont bien avancés dans cette version de Haiku. Les changements principaux sont :

• FAT : gestion des disques de plus de 2Tio, gestion des secteurs disque de 4 Kio, préchargement des blocs pour accélérer le montage
• NFSv4 : nettoyage et corrections de bugs, meilleure gestion des opérations E/S asynchrones
• BFS : optimisation de la recherche de blocs libres, meilleure sélection d'index pour accélérer les requêtes, évitement des enchaînements de get/put inutiles pour des blocs de cache identiques
• RAMFS (utilisé pour /var/shared_memory & shm_open) : nombreuses corrections, nettoyage, améliorations, dont une grande partie suite à l'utilisation intensive de mémoire partagée par Gecko/Firefox

En dehors des systèmes de fichiers eux-mêmes, des changements concernent de façon plus générale la mise en cache du contenu des fichiers. En particulier, la file d'attente des données à écrire a été découpée pour avoir une file par disque au lieu d'une seule file globale. Ces files peuvent estimer la vitesse d'écriture du disque associé, et le cache disque utilise cette information pour éviter d'accumuler trop d'écritures en attente (par exemple, lors de la copie de fichiers d'un disque rapide vers un autre plus lent).

Cela corrige le problème, également constaté sur certains systèmes Linux, où l'écriture vers un disque semble incroyablement rapide, mais le démontage ou l'exécution de sync est très lent, puisque l'écriture sur disque n'a réellement lieu qu'à ce moment là. À présent, le cache disque va détecter cette situation et bloquer les écritures sur le disque concerné le temps que les écritures en attente puissent être traitées. La progression de la copie de fichiers est donc représentative de l'écriture effective sur disque, et l'exécution de sync ne devrait jamais nécessiter plus de quelques secondes.

Compatibilité matérielle

Cette version de Haiku met à jour de nombreux pilotes, en particulier pour les machines fabriquées ces 5 dernières années. Si vous n'aviez pas réussi à installer une version précédente de Haiku, c'est l'occasion de refaire un essai et de voir si les choses se sont améliorées.

Cartes son

Des problèmes de son distordu ou complètement silencieux ont été corrigés, en particulier pour les machines les moins puissantes. Dans ce cadre, l'initialisation de la carte son est désormais faite à la demande, lorsqu'une application a effectivement besoin d'émettre un son. Cela économise de l'énergie et du temps de calcul pour le CPU.

Modifications volatile du BIOS VESA

Lorsqu'il n'existe pas de pilote speçifique pour une carte graphique, Haiku doit utiliser une solution de secours: un framebuffer minimal pour EFI, et VESA pour les systèmes BIOS. VESA permet de changer de mode vidéo pendant l'exécution du système, mais ne permet que de choisir parmi une liste de modes prédéfinis par le fabricant de la carte graphique. Cette liste est souvent assez limitée et n'inclus parfois même pas la résolution native du matériel.

La solution idéale est bien sûr le développement d'un pilote graphique pouvant programmer directement la carte graphique. Cependant, cette solution peut être assez complexe à mettre en oeuvre, surtout si le fabricant du chipset graphique ne fournit pas de documentation. Une solution plus simple est de modifier le BIOS VESA, pour y injecter de nouveaux modes vidéo à la demande. Haiku est maintenant capable de faire cette modification (de façon volatile, dans une copie en RAM du BIOS original) sur certains modèles de cartes graphiques où les modifications à faire ont pu être identifiées.

Pilotes pour toujours plus d'interfaces USB ethernet & WiFi

Haiku dispose d'une couche de compatibilité permettant de réutiliser les pilotes réseau de FreeBSD et OpenBSD, quasiment sans les modifier. Cette couche de compatibilité était limitée aux pilotes PCI, mais elle permet maintenant d'utiliser également des adaptateurs USB. De plus, les pilotes ont été synchronisés avec les dernières versions développées par FreeBSD et OpenBSD, ce qui augmente encore la compatibilité matérielle.

Compatibilité POSIX améliorée

Haiku essaie de suivre autant que possible le standard POSIX, afin de faciliter l'interopérabilité et le portage de logiciels existants. La spécification POSIX a été mise à jour quelques mois avant la version beta 5, et donc les nouveautés correspondantes arrivent seulement maintenant dans Haiku. Ici encore, il est impossible de lister l'immense nombre de changements liés à ce travail, mais voici quelques exemples :

• O_CLOFORK
• MSG_CMSG_CLOEXEC, MSG_CMSG_CLOFORK pour les sockets
• SOCK_SEQPACKET, MSG_TRUNC, MSG_PEEK pour les sockets de la famille AF_UNIX
• WCOREDUMP
• getresuid, setresuid, getresgid, setresgid
• pipe3, dup2, mkostemp
• reallocarray, memmem, qsort_r
• posix_devctl
• pthread_getcpuclockid
• posix_spawn_file_actions_add[f]chdir

En plus de la spécification POSIX, Haiku implémente également des fonctions supplémentaires disponibles dans les systèmes GNU, BSD ou même Solaris lorsqu'elles sont nécessaires ou pertinentes. Dans cette catégorie on trouve les nouveautés suivantes :

• RTLD_NOLOAD, RTLD_GROUP
• getloadavg
• closefrom, closerange
• EV_RECEIPT et l'utilisation d'objets spécifiques à Haiku (ports, sémaphores) avec kqueue
• utilisation de baudrates arbitraires pour les ports série (via cfsetspeed)
• meilleure compatibilité avec l'API FUSE

Ces extensions sont maintenant activées par défaut dans les en-tête C et C++, sauf dans le cas où l'environnement de compilation a demandé l'application d'un standard spécifique. Par exemple, la définition de __STRICT_ANSI__ ou _POSIX_C_SOURCE désactive ces extensions. Ces macros sont activées automatiquement par l'utilisation d'options comme -std=c++11, pour bénéficier des extensions on peut par exemple utiliser -std=gnu++11.

Stabilisation du système

De façon générale, un effort conséquent a été porté sur la stabilisation du système, en corrigeant des crash du noyau et des pilotes, des gels du système, des corruptions, l'échec du démarrage sur certaines machines. Ces problèmes ont été investigués, identifiés et corrigés pour fournir une version plus stable que toutes les précédentes.

Les scènes coupées

Malheureusement, une partie du travail en cours ces deux dernières années n'a pas pu être terminé à temps pour être intégré dans cette version. Certaines choses sont encore en chantier, d'autres sont trop expérimentales et désactivées par défaut. Cela donne peut-être une idée de ce à quoi s'attendre dans la prochaine version !

ARM64

Suite au travail de plusieurs personnes, la version ARM64 de Haiku démarre jusqu'au bureau sur les systèmes virtualisés ! Il existe même une branche de développement, en cours d'intégration, qui permet de démarrer Haiku sur les machines Apple M1. Ce travail est loin d'être terminé, mais les progrès sont remarquables par rapport à l'état des choses lors de la publication de la version beta 5.

WebKit multiprocessus

Le navigateur WebPositive fourni avec Haiku utilise encore une version de WebKit s'exécutant intégralement dans un seul processus. Le travail sur la version multiprocessus est bien avancé, cela fonctionne pour l'affichage de site simples, mais ce n'est pas encore prêt pour convertir WebPositive à ce nouveau mode de fonctionnement.

Nouveau contributeurs

Depuis la publication de la version précédente, un nouveau contributeur de Haiku a obtenu les permissions de commit : il s'agit de Zardshard, qui a travaillé par exemple sur Icon-O-Matic et sur d'autres applications natives. Bienvenue à lui !

On peut également mentionner le retour de Philippe Houdoin, qui avait laissé de côté le projet pendant quelques temps pour se consacrer à d'autres choses, mais a récemment recommencé à participer.

Le nombre de contributeurs est relativement stable depuis plusieurs années, entre 50 et 65 personnes participent à Haiku chaque année avec au moins un patch. Du côté de HaikuPorts, l'activité a tendance à augmenter, avec un record de 82 participants en 2024 et une deuxième position pour l'année 2025 avec 75 personnes. L'amélioration continue du système permet de plus en plus aux développeurs de se consacrer au développement et au portage de logiciels, sans tomber dans des bugs critiques nécessitant de mettre les mains dans les couches plus bas niveau du système.

Code source

Le code source est téléchargeable via un mirroir sur Github (si le site n'est pas cassé) ou alors depuis le serveur Git auto-hébergé de Haiku. Les patchs et contributions sont les bienvenus via Gerrit.

Remonter des problèmes

La sortie d'une nouvelle version de Haiku déclenche habituellement un déluge de nouveaux rapports de bugs. Il y a actuellement plus de 3900 tickets ouverts (et plus de 16000 déjà fermés) dans l'outil de suivi. Si vous pensez avoir identifié un problème, vous pouvez faire une recherche dans l'outil pour voir si le problème a déjà été remonté (ou même déjà corrigé), et dans le cas contraire, créer un ticket sur l'outil de suivi de bugs.

En cas de gros problèmes identifiés avec cette version, ils seront ajoutés sur la page notes de versions additionnelles.

Si vous avez besoin d'aide, commencez par la 'Visite Rapide' puis consultez le manuel d'utilisation, ils sont tous les deux accessibles via des raccourcis sur le bureau de toute nouvelle installation de Haiku. WebPositive s'ouvre par défaut sur notre page de bienvenue qui offre des informations utiles et de nombreux liens, de même que le site web du projet.

Si vous ne trouvez toujours pas de réponse à vos questions ou si vous souhaitez rencontrer d'autres utilisateurs et développeurs de Haiku, vous pouvez rejoindre les forums de discussion, l'un des canaux IRC (accessibles aussi par Matrix ou XMPP), ou envoyer un message sur l'une de nos listes de diffusion où une communauté sympathique pourra vous aider.