Système Haiku : 22 ans déjà !

[Animateur]

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)

[Animateur]

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.

Site : https://www.haiku-os.org

Téléchargement : https://www.haiku-os.org/get-haiku/r1beta4/

Source linuxfr.org