22 ans de Haiku

51
7
oct.
2023
Haiku

C’était le mois d’août, plein de monde était en vacances à la plage, c’était le moment de la dépêche anniversaire de Haiku… mais bon, en fait, il y avait tellement plein de nouveautés cette année qu’on a dû publier un peu plus tard que prévu…

Le projet Haiku (au départ nommé OpenBeOS) a démarré officiellement le 18 août 2001 avec le premier message sur la liste de diffusion : Ok, let's start (OK, allons-y).

L’idée était de donner une suite à BeOS, un système d’exploitation non libre développé par Be Inc. Au début de l’année précédente, Be avait annoncé la mise en téléchargement gratuit de son système BeOS et un changement de stratégie pour se concentrer sur les « Internet appliances », ce qu’on appellerait aujourd’hui l’Internet des objets. Un certain nombre d’utilisateurs et de développeurs de BeOS ne souhaitaient pas voir ce système disparaître, et se sont rassemblés pour essayer d’y donner suite.

Haiku continue son développement, et depuis 2 ans il y a un développeur payé pour faire avancer les choses plus vite, grâce aux dons de la communauté autour de Haiku et au sponsoring de Google au travers du Google Summer of Code. La version beta 4 a été publiée cet hiver avec pas mal de nouveautés.

Sommaire

Comme il y a vraiment beaucoup de nouveautés cette année, cette dépêche reprend uniquement les informations à partir de janvier 2023, juste après la sortie de la version Beta 4. Pour les nouvelles précédentes, consultez la dépêche sur la sortie de la version beta 4.

Il y a également un très grand nombre de corrections de bugs (et probablement quelques ajouts de nouveaux bugs aussi). Cette dépêche se concentre sur les nouveautés les plus intéressantes, sinon elle serait vraiment beaucoup trop longue. Allez plutôt lire directement l’historique des commits sur le dépôt Git si vous en voulez plus.

Amélioration de la compatibilité POSIX et non-POSIX

L’avancée du projet Haiku avec un système d’exploitation de plus en plus stable et complet fait que des utilisateurs se lancent dans des portages de logiciels de plus en plus ambitieux. Cela met souvent en évidence des problèmes de comportement dans l’implémentation de fonctions standardisées dans POSIX, ou, parfois, on se rend compte que d’autres systèmes (par exemple Linux ou BSD) ont ajouté des fonctionnalités supplémentaires que Haiku ne propose pas.

Citons par exemple le travail sur Wine, Node.js (disponible depuis 2019 mais mis à jour cette année), Haskell et C# / .NET, ce dernier étant un projet Google Summer of Code mené par trungnt2910.

Une petite liste de choses qui ont été ajoutées ou améliorées dans ce cadre:

kqueue

Haiku implémente un sous-ensemble du système kqueue de BSD qui permet d’être notifié d’« évènements » arbitraires venant du système d’exploitation.

Il s’agit d’une évolution des APIs UNIX standard poll() et select(), avec comme principales différences:

  • kqueue n’est pas limitée aux descripteurs de fichiers, mais permet aussi de recevoir des évènements pour d’autres types d’objets (en cela elle est similaire à la fonction wait_for_objects déjà existante dans Haiku).
  • kqueue permet d’établir une liste d’objets à surveiller (stockée dans l’espace noyau), puis de recevoir des notifications autant de fois que nécessaire (de façon similaire à epoll dans Linux), ce qui résoud un problème de performance avec poll et select qui eux doivent renvoyer la liste des descripteurs de fichiers à tester à chaque appel au noyau.
  • kqueue permet des notifications de type « edge trigger » : lorsqu’un descripteur de fichier devient lisible, l’application n’est notifiée qu’une seule fois, et ce, même si elle ne consomme pas immédiatement toutes les données disponibles.

Gestion de la mémoire

  • Corrections sur mmap() et mprotect()

Sockets

  • Possibilité de créer des sockets locaux AF_UNIX de type SOCK_DGRAM, y compris en utilisant socketpair()

Autres

Plusieurs corrections de problèmes, dont certains remontés par des développeurs de GNULib qui essaient de limiter le nombre de patchs qu’ils ont besoin de rajouter pour assurer un bon fonctionnement sous Haiku:

  • uchar.h inclut stdint.h
  • correction de FP_ILOGB0 qui n’était pas conforme à la spécification
  • réécriture de getlogin_r
  • synchronisation de random avec l’implémentation de FreeBSD et remplacement de rand_r et rand par les versions de musl
  • Correction de problèmes dans ONCE_INIT (une fonction du standard C11)
  • Correction de la valeur de retour de strxfrm, wcstrxfrm, et mbrtowc
  • Correction de la fonction duplocale qui ne fonctionnait pas
  • Correction de l’initialisation du stack protector qui ne fonctionnait pas dans un chroot
  • Correction de problèmes dans l’utilisation de locales pour les fonctions de formatage de nombres
  • Réécriture des files de messages XSI
  • Ajout de cfsetspeed pour configurer la vitesse des ports série
  • Implémentation de crypt_r
  • Définitions des variables d’environnement standard XDG (permettant de trouver le dossier « home » de l’utilisateur et certains sous-dossiers courants, par exemple) y compris pour les applications lancées via le Tracker, et de façon générale hors d’un terminal
  • Ajout de arc4random pour générer des nombres aléatoires, et de getentropy dans le noyau après une refonte du pilote fournissant /dev/urandom
  • Ajout de sched_getcpu, une extension GNU de la libc permettant à un thread de savoir sur quel cœur de CPU il est en train de s’exécuter

L’équipe de Haiku garde également un œil sur le travail en cours sur la version « Issue 8 » de POSIX (via des brouillons du groupe de travail et l’outil de suivi de bugs) et a déjà commencé à implémenter certaines des nouvelles fonctions et autres changements.

Amélioration de performances

Réécriture de user_mutex

user_mutex est la partie du code du noyau qui traite de tout ce qui concerne les sections critiques et verrous accessibles depuis le code en espace utilisateur. Par exemple les APIs pthread_mutex (sections critiques), pthread_cond (« condition variables »), pthread_barrier, sémaphores anonymes sem_open, verrous en lecture-écriture, et encore bien d’autres. En termes de fonctionnalités, c’est un peu similaire aux futex de Linux (fast userspace mutex), mais l’implémentation est très différente.

Le code de user_mutex est assez ancien dans Haiku, puisque c’est une des premières choses qui ont été mises en place. Il a reçu notre attention suite à divers problèmes rencontrés lors du portage de logiciels de plus en plus complexes et exploitant beaucoup le parallélisme et donc les sections critiques.

Le premier problème corrigé est une confusion entre les adresses physiques et adresses logiques. Historiquement, Haiku utilisait (comme son ancêtre BeOS) uniquement des adresses 32 bits (suffisantes pour les machines de l’époque). Une version 64 bits est apparue plus tard, dans laquelle toutes les adresses (physiques et logiques) étaient en 64 bits. À ce moment-là, toutes les adresses étaient représentées par un seul type, addr_t, un entier sur 32 ou 64 bits selon le cas. Cependant, sur la version 32 bits de Haiku, cela rendait impossible l’utilisation de plus de 4Gio de mémoire (un peu moins en fait : une partie de ces 4Gio sont utilisés pour l’accès à certains périphériques matériels comme la mémoire des cartes graphiques).

Les machines avec 2 ou 4 Gio de mémoire ou plus étant devenues très courantes. Pour pouvoir utiliser toute cette mémoire, même dans la version 32 bits, Haiku a été modifié pour utiliser PAE, Page Address Extension : l’idée est de continuer à utiliser des adresses logiques sur 32 bits, mais des adresses physiques sur 64 bits. Ainsi, chaque application est limitée à 32 bits, mais le système peut utiliser plus de mémoire, partagée entre les applications ou allouée à d’autres usages (cache du système de fichiers par exemple).

Dans ce cadre, le noyau de Haiku doit maintenant bien distinguer les adresses physiques (représentées par phys_addr_t des adresses logiques (représentées par addr_t) et tenir compte de la différence de taille entre les deux.

Quel est le rapport avec user_mutex? Certaines des fonctions implémentées par user_mutex peuvent servir à synchroniser des choses entre différentes applications. Or, les adresses logiques sont spécifiques à chaque application (la même adresse logique peut représenter deux choses différentes dans deux applications). Il faut donc utiliser des adresses physiques. C’était bien le cas, mais, le code ayant été écrit avant l’apparition de PAE dans Haiku, ces adresses étaient stockées avec le mauvais type. Sur la version 32 bits de Haiku, elles étaient donc tronquées. Le code a donc été corrigé pour utiliser le type phys_addr_t pour régler ce problème.

Malheureusement, ce n’était pas le seul souci avec le code. L’implémentation de pthread_barrier, par exemple, ne fonctionnait pas du tout, et son utilisation avait été désactivée par exemple dans Mesa. Elle a donc été entièrement réécrite, des petits programmes de tests complétés ou ajustés pour reproduire tous les problèmes connus. La nouvelle implémentation est non seulement plus correcte, mais elle est aussi plus rapide.

L’étape suivante a été un travail sur pthread_mutex_lock dans les cas avec beaucoup de threads en attente sur le même verrou. Ce problème, qui est celui qui a lancé tout ce travail sur user_mutex, a été découvert lors d’une mise à jour du compilateur GHC pour Haskell. La compilation de GHC se bloquait régulièrement sans explication valable.

Enfin, une fois ces problèmes réglés, le travail s’est poursuivi avec des améliorations de performance consistant à utiliser des verrous plus fins: passage de certains verrous en mode « lecture-écriture » (il peut y avoir plusieurs accès en lecture concurrents, mais un seul en écriture), découpage de structures globales pour séparer les informations appartenant à chaque processus utilisateur, et dans certains cas où c’est possible, utilisation d’adresses virtuelles au lieu des adresses physiques, ce qui permet d’utiliser les verrous sans avoir à bloquer une adresse physique (ils peuvent donc être déplacés dans le fichier swap, puis rétablis à une autre adresse physique plus tard).

Ces changements ont permis une importante amélioration de performances, par exemple sur la démonstration GLTeapot (qui affiche une théière en 3D, sans accélération matérielle), on passe de 340 à 600 images par secondes dans des conditions de test identiques. De façon moins quantifiable, quelques utilisateurs ont confirmé que leur ressenti est que le système est plus réactif, par exemple sur l’ouverture des menus (qui utilisent plusieurs threads avec beaucoup de synchronisation).

Enfin, la commande user_mutex a été ajoutée dans le debugger noyau et permet d’analyer les structures de données concernées par ces développements.

Outils de débogage

strace

strace est un outil permettant de lister et analyser tous les appels systèmes effectués par un thread, un processus, ou un arbre de processus. Il est similaire à l’outil du même nom disponible sous Linux, mais il est implémenté de façon indépendante (le fonctionnement des appels systèmes étant trop différent pour réutiliser le même code).

Chaque appel système et chaque structure de données qui peut être passée en paramètre a besoin d’un peu de code spécifique dans l’outil strace, bien que la plupart de ce code est générée automatiquement à partir du fichier de définition des appels systèmes du noyau.

  • Décodage des flags dans la plupart des fonctions (par exemple les flags O_* de open)
  • Décodage des codes de retours typés comme ssize_t
  • Affichage du contenu de struct sockaddr et des détails de divers appels liés au réseau
  • Affichage des arguments de exec() et load_image()
  • Affichage des drapeaux passés à user_mutex()
  • Affichage d’information complètes sur les signaux

Un exemple avant/après ces changements :

open(0x5, "plaintext", 0x2042, 0x0) = 0x8000000f () (49 us)
map_file("http://libicuuc.so.66 mmap area", 0x7f04c2675228, 0x6, 0x1ababd0, 0x1, 0x0, true, 0x3, 0x0) = 0x329a0 () (108 us)
open(0x5, "plaintext", O_RDWR | O_NOTRAVERSE | O_CLOEXEC, 0x0) = 0x8000000f Operation not allowed (57 us)
map_file("http://libicuuc.so.66 mmap area", [0x0], B_RANDOMIZED_ANY_ADDRESS, 0x1ababd0, B_READ_AREA, 0x0, true, 0x3, 0x0) = 0x73e8 ([0x6392223000]) (135 us)

Debugger

Haiku est fourni avec un debugger graphique.

  • Correction de problèmes dans le décodage des informations DWARF qui empêchaient de débugger un portage en cours de Firefox
  • Ajout d’une option « ne plus demander » pour le téléchargement des informations de debug
  • Possibilité d’ouvrir une application dans Debugger en utilisant le menu « ouvrir avec" du Tracker ou un glisser-déposer sur l’icône du Debugger
  • Des améliorations sur l’aide de certaines commandes dans l’interface en ligne de commande du Debugger
  • Double cliquer sur un fichier « core dump » dans le Tracker ouvre le fichier directement dans Debugger
  • Complétion du support des informations de debug au format DWARF v4 (malheureusement, juste à temps pour que gcc se mette à générer du DWARF v5 par défaut…)

Outils de développement

gcc

Haiku est maintenant compilé et fourni avec gcc 13.2.

gcc2 reste utilisé, uniquement dans la version 32 bits pour processeurs x86, dans les parties du code qui assurent la compatibilité avec BeOS.

Icon-O-Matic

Zardshard travaille sur l’éditeur d’icônes vectoriels dans le cadre du Google Summer of Code. Il a ajouté:

  • Les images de référence, permettant d’afficher une image bitmap dans l’éditeur (pour redessiner une icône vectorielle imitant son contour par exemple)
  • Les transformations « perspective », en plus des transformations existantes (rotation, translation, mise à l’échelle et shear), permettant de faire des icônes avec une apparence « 3D » plus facilement.

Applications

PowerStatus

PowerStatus (qui affiche le statut de la batterie dans la DeskBar) peut déclencher des alertes sonores lorsque la batterie est déchargée à différents niveaux prédéfinis.

ShowImage

La visionneuse d’images empêche l’écran de se mettre en veille lorsqu’un diaporama d’images est en cours.

Mail

  • De nombreuses corrections de bugs de layout dans différentes fenêtres, amélioration de la localisation, de l’affichage sur les écrans à très haute résolution.
  • La notification de nouveaux messages peut être cliquée pour afficher la boîte de réception
  • Les messages non lus mais placés dans la corbeille ne sont plus comptés comme non lus
  • Les liens dans les messages sont affichés en utilisant la couleur choisie pour les liens dans les préférences système

Tracker

  • Les images de fond des dossiers s’affichent correctement en mode « fenêtre unique ».
  • Il est à nouveau possible de définir des icônes personnalisées pour les dossiers
  • Améliorations sur l’affichage des dossiers en lecture seule : affichage sur fond gris indiquant que rien ne peut être modifié (ce fond gris était déjà utilisé pour les résultats de requêtes BFS et pour les « dossiers bleus”, un type de dossiers virtuels utilisé pour combiner le contenu de plusieurs dossiers en un seul) ; désactivation des menus qui ne peuvent pas être utilisés.
  • De nouvelles icônes spécifiques pour les brouillons de mails et les fichiers « patch »

DeskBar

  • Le « Vulcan Death Grip » fonctionne maintenant aussi sur la DeskBar en mode miniature
  • Les icônes de la DeskBar sont toutes vectorisées (il restait quelques icônes bitmap datant de BeOS)

WebPositive

Les icônes des pages web dans leurs onglets peuvent être glissé-déplacées vers la barre de favoris où vers un dossier dans le Tracker pour créer un marque-page.

Terminal

Le copier-coller est amélioré avec l’utilisation de la méthode « bracketed paste » qui permet à une application fonctionnant dans un terminal de savoir que le texte reçu vient d’un copier-coller et n’est pas tapé directement par l’utilisateur. Par exemple, nano l’utilise pour ne pas modifier l’indentation du texte collé, et bash l’utilise pour ne pas valider immédiatement une commande collée dans le terminal (même si elle contient un retour à la ligne).

Les soulignements ondulés sont disponibles (permettant par exemple de souligner les fautes d’orthographe dans vim)

Les thèmes de couleurs dans le Terminal peuvent être modifiés (et le résultat peut être exporté dans un fichier et partagé avec d’autres utilisateurs).

SerialConnect

Il est possible de coller du texte dans le terminal série sans avoir besoin de le recopier à la main.

Outils en ligne de commande

  • pkgman dispose d’une nouvelle sous-commande info qui affiche la description d’un paquet (y compris pour les paquets qui ne sont pas installés)
  • listdev affiche maintenant tous les périphériques présents dans le device tree, et pas seulement les périphériques PCI. Cela prépare l’outil à une utilisation sur les machines ARM et RISC-V où une plus grande partie du matériel est exposée seulement via un fichier FDT ou des nœuds ACPI.
  • Améliorations de la commande setvolume pour ajuster le volume des sorties audio. La commande permet de couper et remettre le son, ainsi que d’incrémenter et baisser le volume d’une certaine valeur (plutôt que de configurer directement une valeur absolue). Cela permet de l’utiliser avec l’application Shortcuts pour les touches multimédia disponibles sur les PC portables et certains claviers. Les pilotes USB et PS/2 ont d’ailleurs reçu quelques améliorations pour pouvoir utiliser ces touches.

Divers

Plusieurs applications mises à jour pour utiliser BNumberFormat pour le formatage de nombres (permettant d’utiliser le format de la locale active).

Remplacement du caractère « x » par un vrai symbole de multiplication là où c’est pertinent (par exemple, la liste des résolutions d’écrans, les informations sur la taille d’une image ou d’une vidéo).

Les paquets hpkg sont maintenant compressés avec Zstd plutôt que zlib. Ils sont à la fois plus petits et plus rapides à décompresser.

libbe

La libbe est la bibliothèque principale de Haiku contenant la plupart des fonctionnalités du système.

  • Ajout de BIconUtils::GetSystemIcon permettant aux applications d’utiliser des icônes standardisées présentes dans le système (par exemple les icônes par défaut des boîtes de dialogue BAlert)
  • Implémentation de BSerialPort::WaitForInput pour attendre l’arrivée de données sur un port série
  • De très nombreuses corrections de bugs dans l’Interface Kit : sur BOutlineListView, BTextView, BAboutWindow…
  • Une nouvelle classe « BarberPole » permettant d’afficher une barre de chargement infinie animée.
  • Des fonctions utilitaires pour déterminer une taille de texte appropriée pour afficher un texte dans une zone donnée (par exemple dans la barre d’état d’une application, où l’espace vertical est assez limité).

Traducteurs

Les traducteurs permettent de charger et enregistrer différents formats de fichiers de façon transparente pour les applications. De nouveaux formats peuvent ainsi être ajoutés aux applications existantes.

Un nouveau traducteur pour les fichiers AVIF a été ajouté.

Panneaux de préférences

Screen

La liste des modes vidéo disponibles est affichée dans un menu en grille plutôt qu’en liste, ce qui occupe moins de place et permet d’afficher beaucoup de modes différents.

Devices

Le gestionnaire de périphériques a été nettoyé pour retirer des onglets vides et inutilisés.

Pilotes de périphériques

  • Le pilote framebuffer (utilisé lorsqu’il n’y a pas de pilote plus spécifique sur les machines démarrant en UEFI) permet de récupérer les données EDID de l’écran utilisé. Cela permet par exemple de déterminer la taille de l’écran.
  • Le pilote PS/2 fonctionne correctement avec le clavier des Chromebooks et de certaines machines Fujitsu.
  • Les corrections se poursuivent suite à l’activation de SMAP et SMEP (protection contre certaines méthodes d’accès indirect à la mémoire du noyau), tous les drivers doivent être ajustés pour signaler clairement les opérations qui accèdent à la mémoire utilisateur (en utilisant la fonction user_memcpy)
  • Pilote pour les touchpad I2C Elantech

USB

Les pilotes USB sont maintenant des pilotes « new style » s’affranchissant de certaines limites de l’API des pilotes de BeOS.

De nombreux problèmes ont été corrigés également, sur l’USB3, l’USB mass storage et de nombreux autres pilotes.

PCI

Le pilote PCI (et PCI express, qui est très similaire d’un point de vue logiciel) a été retravaillé en profondeur. D’abord, une partie du pilote a été réécrite pour la version RISC-V de Haiku, qui nécessitait de faire beaucoup de choses de façon différente: pas de BIOS comme sur les machines x86, découverte des bus PCI depuis un fichier FDT plutôt que depuis des informations ACPI. Il a fallu également implémenter l’allocation de plages mémoires aux périphériques PCI, ce qui est habituellement fait par le firmware (BIOS ou EFI) sur les machines x86, mais pas sur les machines RISC-V.

Cette première ré-implémentation a abouti à beaucoup de code dupliqué et n’était pas facilement réutilisable pour la version ARM de Haiku. De plus, certains PC modernes ne font plus complètement l’allocation de ressources, cette partie du code devrait donc être partagée aussi avec ces machines.

L’étape suivante a donc été de ré-unifier le code du pilote PCI, une fois bien identifiées les parties qui sont réellement spécifiques à chaque plateforme. Ce travail n’est pas encore tout à fait terminé.

Stockage et système de fichiers

Amélioration du mécanisme IORequest (à la base du cache disque) et de son utilisation dans les pilotes NVMe et SD/MMC.

Migration du pilote USB mass storage en pilote « new style » et amélioration de la gestion des erreurs (un périphérique USB défectueux ne fait plus planter tout le noyau et déclenche seulement une erreur sur les opérations de lecture et écriture).

Améliorations diverses sur les systèmes de fichiers XFS et BTRFS.

Le système de fichier UFS2 est maintenant complètement implémenté (en lecture seule), permettant d’accéder aux volumes FreeBSD et OpenBSD.

Réécriture du pilote NTFS à partir de la dernière version de NTFS-3G. Ce pilote avait été développé pour BeOS et seulement partiellement adapté pour les nouvelles APIs de Haiku (l’interface entre le système de fichier est assez différente dans les deux systèmes, en particulier au niveau de la gestion des caches disque, mais aussi par exemple des permissions sur les fichiers). Le nouveau pilote est plus rapide et plus stable.

Réécriture et renommage de GoogleFS en WebSearchFS. Il s’agit d’un exemple de système de fichiers qui répond aux queries par des résultats de moteurs de recherche récupérés sur Internet. Il utilisait auparavant Google, mais il a été migré vers DuckDuckGo dont les résultats sont présentés en HTML propre et beaucoup plus facile à analyser. WebSearchFS n’est pas inclus dans les images disques de Haiku car les conditions d’utilisation de DuckDuckGo n’autorisent pas clairement cette utilisation.

Améliorations et corrections sur userlandfs et FUSE (systèmes de fichiers en espace utilisateur) : ils utilisent maintenant le cache de fichiers (ce qui permet d’exécuter des programmes chargés depuis un tel système de fichier), et les noms de fichiers à moins de 2 caractères sont maintenant utilisables. Cela augmente le confort d’utilisation de sshfs ou du système de fichier partagé avec l’hôte de VMWare.

Finalisation du support de « trim » pour indiquer aux SSDs les secteurs non utilisés par le système de fichier BFS :
- Affichage de la taille en Mio qui a été libérée plutôt que du nombre de secteurs,
- Correction d’un bug dans BFS qui oubliait de libérer le dernier bloc non utilisé,
- Correction de la taille libérée calculée par le pilote NVMe

Optimisations de PackageFS en utilisant un object_cache au lieu d’allocations simples à base de malloc/free (ou new/delete) dans les parties du code qui créent et suppriment beaucoup d’objets. object_cache permet de préallouer des blocs de la bonne taille pour un objet (ou une structure) donnée et de les réutiliser plusieurs fois. Les opérations concernées sont 5 fois plus rapides.

Un ramfs (système de fichier stockant les données en RAM de façon non persistante) est maintenant disponible et monté par défaut dans /var/shared_memory. Il peut être utilisé pour toutes sortes de fichiers temporaires qui n’ont pas besoin d’encombrer le disque dur.

Le système de fichier rootfs vérifie maintenant les permissions sur les fichiers et dossiers. (Note: ce système de fichiers fournit le dossier / dans lequel tous les autres disques sont montés. Dans Haiku la partition système est montée dans /boot et pas dans / comme c’est le cas sur la plupart des systèmes UNIX).

Pilotes réseau

La plupart des pilotes de carte réseau sont ceux de FreeBSD, recompilés pour Haiku à l’aide d’une couche de compatibilité implémentant les APIs du noyau FreeBSD nécessaires. Ainsi, Haiku peut récupérer le travail de FreeBSD sur ces pilotes assez facilement.

La gestion des "callouts" dans la couche de compatibilité FreeBSD a été entièrement réécrite pour augmenter les performances et la fiabilité.

En plus des pilotes de FreeBSD, il est maintenant possible d’utiliser ceux d’OpenBSD, ce dernier est maintenant beaucoup plus en avance en particulier sur les cartes Wifi grâce à l’excellent travail de Stefan Sperling (entre autres). FreeBSD a l’air de plutôt faire le choix de développer une couche de compatibilité permettant d’utiliser les drivers de Linux, ce qui ne se prête pas bien à notre usage (on ne veut pas faire une couche de compatibilité pour leur couche de compatibilité).

Le pilote loopback implémente une MTU (taille maximale des paquets transmis) beaucoup plus large que les ports ethernet classiques, ce qui permet de meilleures performances et évite une différence inutile avec les autres systèmes.

La pile IPv6 a reçu de nombreuses corrections. Elle fonctionne plutôt bien maintenant, mais il manque encore certains protocoles pour une utilisation totalement transparente (il faut encore configurer les adresses IPv6 à la main). Cela s’est aussi accompagné de corrections de problèmes dans TCP, la gestion des routes, et quelques autres sujets liés au réseau.

Réécriture du pilote PTY

Haiku avait deux implémentations séparées des TTY. L’une était utilisée uniquement pour les pseudo-TTY (principalement le Terminal) et l’autre pour les « vrais » ports série. Historiquement, BeOS ne permettait pas d’associer un tty à un port série. Cela avait été ajouté dans Haiku à partir d’une copie du code pour les PTY et les deux implémentations avaient divergé au cours du temps. Elles ont été resynchronisées plusieurs fois, mais maintenant le pilote PTY utilise le pilote tty au lieu de dupliquer son code.

ACPI

Correction des conversions d’unités et d’erreurs d’arrondi dans le pilote ACPI thermal qui permet de récupérer la température de différents capteurs dans l’ordinateur.

Architectures ARM et RISC-V

  • Corrections sur la gestion de la mémoire et la MMU pour les machines ARM.
  • Ajout d’ioctl pour accéder au FDT depuis l’espace utilisateur.
  • Ajout de plus de pilotes dans les images (pilotes Wifi par exemple).
  • Amélioration de la gestion des ports séries à travers EFI pour la console de démarrage, permettant d’avoir des logs fonctionnels sur un port série dès le début du démarrage du noyau.

La version RISC-V est fonctionnelle dans QEMU et sur quelques machines.

La version ARM est presque fonctionnelle dans QEMU pour l’instant.

Chargeur de démarrage

La gestion des ports série et des logs dans le bootloader UEFI a été réécrite et simplifiée.

Serveurs

Les serveurs sont équivalents aux démons UNIX et remplissent différents services.

app_server

  • Correction d’une boucle infinie sur les systèmes qui n'ont pas de carte graphique reconnue (pas même par les pilotes VESA ou framebuffer).
  • Il est maintenant possible d’utiliser une police de caractères sans avoir besoin de l'installer dans le dossier "fonts" du système. Cette fonctionnalité est utilisée par exemple pour le navigateur web, qui peut télécharger des polices arbitrairement choisies par les sites internet.
  • Il est possible de créer un BBitmap (un objet contenant une image raster) à partir d’une zone de mémoire (area) déjà allouée et sans recopier les données. Auparavant, la création d’un tel objet nécessitait forcément une allocation de mémoire par le serveur graphique, puis une copie des données dans la zone allouée. Cela permet des améliorations de performances, mais surtout de partager la mémoire d’un objet BBitmap entre plusieurs processus (un qui le remplit, un qui l’affiche). Ce fonctionnement est indispensable par exemple dans les versions modernes de WebKit ou le navigateur web sous-traite le rendu des pages à un processus séparé à des fins d’isolation.

Nouveaux logiciels dans HaikuDepot

Haikudepot propose près de 4000 paquets. Les mises à jour et les nouveaux paquets sont signalés dans le sujet de forum New/updated in HaikuDepot, et dans une mailing list dédiée.

Python

Haiku est maintenant distribué avec Python 3.10 (la version beta 4 utilisait Python 3.9 et auparavant c’était Python 3.7).

Tous les paquets utilisant encore Python 2.7 ont été mis à jour vers Python 3 ou supprimés.

Wine

Une version de Wine pour Haiku est maintenant disponible, uniquement en version 64 bits pour l’instant. Elle ne fonctionne pas sur Haiku 32 bits et elle ne permet pas non plus de lancer des exécutables compilés pour Windows en 32 bits.

Quelques exemples de programmes fonctionnant avec Wine sous Haiku :

  • Notepad ++
  • vkQuake
  • OGRE 3D Vulkan mode
  • OGRE 3D Direct3D 9 mode with DXVK (!).
  • WinMerge
  • HeidiSQL (complètement fonctionnel mais comme MariaDB/MySQL n’est pas disponible il faudra se connecter à une base externe)

Plus d’informations sont disponibles dans le sujet dédié sur le forum de Haiku

TeX

La distribution TexLive est repackagée par l’équipe de Haikuports et disponible dans le gestionnaire de paquets. Cela a permis de proposer divers logiciels qui utilisent TeX, comme Lilypond qui permet d’éditer des partitions musicales.

Documentation

Documentation interne

La documentation « interne » de Haiku, qui était auparavant un assemblage de fichiers dans divers formats sans cohérence, est maintenant générée à l’aide de Sphinx et disponible en ligne.

Cette documentation plus facilement accessible a poussé les contributeurs à Haiku à compléter quelques chapitres supplémentaires de la documentation.

Documentation d’API

Cette documentation (également disponible en ligne) est destinée aux personnes développant des applications pour Haiku, sans toucher à l’intérieur du système.

Elle est maintenant disponible en mode sombre, dispose d’un moteur de recherche fonctionnel, et est de plus en plus complète même s’il reste nécessaire de consulter le Be Book, documentation équivalente pour BeOS, l’ancêtre de Haiku. Des discussions sont en cours avec Access, l’entreprise qui a racheté les droits sur BeOS, pour modifier la licence du Be Book (actuellement une licence CC BY-NC-ND) pour autoriser les travaux dérivés, et ainsi pouvoir fusionner cette documentation avec celle de Haiku. Si cela n’aboutit pas, le travail se poursuivra pour réécrire tous les chapitres un par un.

Google Summer of Code

Cette année, trois participants au Google Summer of Code ont été sélectionnés pour travailler pour Haiku, voici quelques détails sur leurs projets

Améliorations de l’éditeur d’icônes Icon-O-Matic

Haiku est connu entre autres choses pour son format d’icônes vectorielles très compact (appelé, de façon pas très créative, HVIF pour Haiku Vector Icon Format). Icon-O-Matic est l’éditeur qui permet de dessiner ces icônes en prenant en compte les contraintes et avantages du format.

Les évolutions consistent, en plus de nombreuses améliorations sur l’interface utilisateur :

  • à ajouter des images de référence en surimpression à l’icône en cours d’édition (utile par exemple pour redessiner une icône existante),
  • à ajouter une transformation « perspective » permettant de déformer un ensemble d’objets selon les règles de la perspective. Ainsi une forme peut facilement être dessinée « à plat » avant d’être placée là où elle doit se trouver.

Pilote réseau TUN/TAP

Ces pilotes réseau permettent à une application de se comporter comme une interface réseau virtuelle, pouvant recevoir et injecter du trafic dans la pile réseau. Cela permet par exemple d’utiliser un VPN comme OpenVPN, ou encore d’établir une connexion réseau « pont » entre le monde extérieur et une machine virtuelle QEMU.

Portage de C#/.net vers Haiku

Microsoft a publié tous les outils permettant de compiler et d’exécuter du code développé en C#. Ce projet a consisté à poursuivre le portage de ces outils vers Haiku. Il a également conduit à identifier et corriger de nombreux problèmes de compatibilité et de manques dans les couches de compatibilité POSIX.

Aller plus loin

  • # synchro

    Posté par  (Mastodon) . Évalué à 10. Dernière modification le 07 octobre 2023 à 11:51.

    J'ai commencé il y a deux jours un test de deux semaines où j'essaie d'utiliser exclusivement Haiku sur mon laptop[1] et où je documente mes succès et souçis.

    Je pense que je ferais un journal plus complet à ce sujet mais j'ai pour l'instant eu peu de succès avec wine (pour y faire tourner firefox, il crashe à l'installeur), avec le bluetooth (pas réussi à sortir du son) et je n'ai pas non plus réussi à booter une vm linux depuis aqemu sans que le kernel linux panique.

    [1] Personnel uniquement. Dans le cadre professionel où je continue à utiliser ma Fedora.

    • [^] # Re: synchro

      Posté par  (site web personnel, Mastodon) . Évalué à 9.

      Pour le bluetooth, la base de la pile logicielle est en place mais il n'y a aucun pilote qui l'utilise pour l'instant. Donc, à part appairer des appareils, on ne peut rien faire.

      Pour Wine, je ne sais pas, je n'ai pas testé.

      Pour QEMU, ça devrait marcher, mais pas efficacement: il n'y a pas de pilote de virtualisation (type KVM) et donc l'émulation du CPU se fait logiciellement.

    • [^] # Re: synchro

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Je suis emballé à l'idée de lire ce journal. Ça fait des plombes que je me dis qu'il faut que j'essaie sans jamais trouver le temps…

      • [^] # Re: synchro

        Posté par  . Évalué à 3. Dernière modification le 09 octobre 2023 à 07:08.

        Je suis emballé à l'idée de lire ce journal.

        Date un peu, mais reste d'actualité :

        https://linuxfr.org/users/zurvan-0/journaux/haiku-l-os-zen

        J'ai depuis installé haiku sur deux autres PC à la maison 😀. Ça tourne toujours aussi bien…

        « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

      • [^] # Re: synchro

        Posté par  (site web personnel) . Évalué à 2.

        Hello, tu as reçu mes mails? (Oui je squatte honteusement les commentaires linux pour faire des notifications).

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: synchro

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Hello, j'ai prévu de t'y répondre aujourd'hui (j'aurais dû te le dire directement au lieu de squatter moi aussi les commentaires linuxfr - honte à moi).

    • [^] # Re: synchro

      Posté par  . Évalué à 1.

      où je documente mes succès et souçis.

      AAH !! Mes yeux !!! Mes YEUX !!!
      Il y a jamais de cédille devant un "i" ou un "e".
      J'ai mal à ma France dirait le petit Nicolas (Sarkozy).

      • [^] # Re: synchro

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        En plus on dit six sous, même en anglais où on inverse (on me souffle dans l’oreillette que je confonds avec l’adjectif.)
        Ceci dit, tu devrais mettre en examen tes petites références casher :)

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: synchro

          Posté par  . Évalué à 3.

          Ceci dit, tu devrais mettre en examen tes petites références casher Kärcher :)

          Désolé pour la référence, (il y a aucun truc politique derrière) mais à chaque fois que j'y repense ça me fait marrer.

      • [^] # Re: synchro

        Posté par  . Évalué à 2.

        Ou devant un e-grèque.

  • # 22 ans ? wow

    Posté par  . Évalué à 1.

    Ah oui je m'en rapelle, ça fait assez longtemps que j'ai pas touché haiku, j'aurais bien aimé que Haiku est plus de support au niveau graphique, malheursement haiku n'avance pas beaucoup mais, ça avance en terme de dévéloppement

    Quoi qu'il en soit, c'est un très bon OS.

    C'est la coalition des glandus !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.