Haiku a 18 ans

Ça bouge pour Haiku cette année, puisqu’il y a enfin une version bêta !

Cette dépêche annuelle est l’occasion de faire le point sur les progrès accomplis et le travail à venir (il en reste toujours).

Sommaire

• Présentation de Haiku
  • Pourquoi un clone de BeOS ?
• Les avancées de l’année
  • Des optimisations
  • De la sécurité
  • Les pilotes matériels
  • La gestion des écrans haute résolution
  • Les finitions
  • Des corrections de bogues
  • Compatibilité POSIX
  • Portage sur d’autres architectures
  • Participation à Outreachy
  • Analyse du code par PVS-studio
• En route pour la bêta 2

Présentation de Haiku

Note : cette section est reprise de la dépêche de l’année dernière, les objectifs du projet n’ont pas changé depuis.

Pour ceux qui n’auraient jamais entendu parler de Haiku, il s’agit d’un système d’exploitation pour les ordinateurs personnels (par opposition, d’une part aux serveurs, d’autre part aux smartphones, tablettes, et autres systèmes embarqués). Il est une réécriture de BeOS, un système propriétaire abandonné en 2001.

D’un point de vue technique, ses particularités sont une base de code presque intégralement en C++ (oui, même le noyau) et généralement reconnue pour sa clarté et sa lisibilité (oui, même si c’est du C++), son approche de la programmation très parallélisée (chaque fenêtre ouverte par une application a son propre fil d’exécution, par exemple), et la présence d’une API complète et cohérente pour faciliter le travail des développeurs d’applications.

D’un point de vue utilisateur, l’objectif est d’avoir un système facile à utiliser et à appréhender (pas de surprise ou de comportements inattendus), réactif, tout en restant flexible et capable de faire ce qu’on attend de lui.

Pourquoi un clone de BeOS ?

À l’origine, Haiku est pensé pour fournir une continuité aux utilisateurs de BeOS et aux développeurs d’applications qui ne souhaitaient pas migrer vers un autre système.

Dix‐huit ans plus tard, BeOS est mort et enterré, et Haiku n’a pas réussi à fournir une version stable dans les temps. La plupart des développeurs d’applications sont passés à autre chose depuis.

Cependant, Haiku reste un projet pertinent aujourd’hui, car aucun système libre n’a vraiment pris la place que BeOS a libérée (dit autrement, non, ce n’est toujours pas l’année de GNU/Linux sur le bureau).

Le maintien de la compatibilité avec BeOS garde également un intérêt, pas pour les utilisateurs mais pour l’organisation du projet :

• elle permet de garder un objectif à peu près raisonnable en vue, c’est‐à‐dire qu’on peut rejeter les propositions de nouvelles fonctionnalités en disant « ce n’était pas dans BeOS » ;
• elle permet de comparer l’implémentation des API avec celle de BeOS, pour décider si un problème vient d’une application ou d’un problème d’implémentation côté Haiku ;
• elle permet enfin d’expérimenter les difficultés à maintenir pendant plus de quinze ans la compatibilité de l’ABI, et à réfléchir à la meilleure façon de procéder pour assurer la compatibilité entre les futures versions de Haiku.

Les désavantages de cette approche (utilisation de GCC 2, impossibilité d’implémenter certaines choses ou de résoudre certains problèmes de sécurité qui nécessiteraient de changer l’API) se font toutefois de plus en plus pressants, c’est pourquoi il existe maintenant une version 64 bits de Haiku qui peut s’affranchir de certaines de ces contraintes.

Les avancées de l’année

Des optimisations

L’entrée dans la phase bêta signifie qu’il n’y a plus de grosses fonctionnalités en cours de développement. On entre donc dans une phase où on va s’occuper de nettoyage du code, de correction de bogues, et aussi d’optimisation.

Dans de nombreux cas, c’est un aspect qui a été un peu laissé de côté dans Haiku jusqu’à présent : le but était d’abord d’avoir un code très lisible et simple, permettant déjà d’avoir une plate‐forme fonctionnelle. Maintenant que c’est le cas, il est possible de commencer à optimiser certains aspects (en pouvant faire des « benchmarks » en environnement réel).

L’objectif est à la fois de réduire la consommation mémoire (il n’est actuellement plus possible d’installer Haiku sur une machine avec 256 Mio de mémoire), et d’augmenter les performances (réduire les durées de compilation, par exemple).

Divers aspects sont passés en revue, par exemple l’utilisation de « pools » d’objets évitant de trop recourir à l’allocateur mémoire générique, ou encore une meilleure utilisation des primitives de blocage entre fils d’exécution (verrous en producteur/consommateur, etc.)

L’allocateur mémoire a également été remplacé, Haiku utilise aujourd’hui rpmalloc, qui remplace le vieillissant hoard2 après une analyse des différentes options disponibles.

De la sécurité

Haiku est toujours un système conçu pour un cas d’utilisation spécifique : un seul utilisateur sur son ordinateur de bureau. À l’époque de BeOS, cela avait conduit à la décision d’avoir un seul utilisateur au sens UNIX (l’équivalent du root), avec tous les droits sur le système.

Cependant, les usages ont évolué, et les ordinateurs d’aujourd’hui sont en permanence connectés à Internet. Il est donc plus que temps de se préoccuper un peu de sécuriser certains aspects et de mieux isoler certaines parties du système.

Haiku permet déjà de créer des utilisateurs UNIX et offre la gestion habituelle des permissions. Cependant, cela n’est pas toujours fonctionnel comme il le faudrait car ces fonctions restent relativement peu utilisées. C’est donc un travail sur le long terme de vérifier que le nécessaire a été fait partout pour qu’un utilisateur n’ait pas plus de droits que ce qu’il faudrait.

Les réflexions sont en cours également pour aller plus loin que ce que propose UNIX dans ce domaine, qui ne nous semble pas suffisant. Il est possible par exemple que dans les prochaines versions, Haiku se dote d’un système de permissions par application, un peu similaire à celui d’Android.

Au niveau du noyau, il n’y a désormais plus aucune zone de mémoire à la fois exécutable et accessible en écriture, ce qui devrait compliquer la vie d’un attaquant potentiel car il devient ainsi plus compliqué d’injecter du code dans le noyau.

Les pilotes matériels

Même si le système lui‐même est de plus en plus complet, les pilotes sont un aspect qui demandera toujours du travail.

Cette année, de gros progrès ont été faits sur la stabilisation des pilotes xHCI pour l’USB 3. Le travail continue à ce sujet pour pouvoir enfin utiliser les cartes son USB (un pilote incomplet existe depuis une dizaine d’années). Il y a également eu encore du travail sur les pilotes pour les convertisseurs USB - RS-232 (le travail sur les versions ARM, SPARC et RISC-V de Haiku n’y est pas pour rien).

Un ajout de taille (inclus dans la version bêta 1 mais encore amélioré depuis) est la prise en charge des systèmes UEFI, avec un nouveau chargeur d’amorçage. L’intégration n’est pas tout à fait complète, en particulier il reste quelques étapes à effectuer manuellement lors de l’installation sur une nouvelle machine, mais il existe au moins un moyen d’installer le système sans devoir repasser en mode « legacy » (compatible BIOS).

Un nouveau pilote pour les disques NVMe est également inclus. Il est basé sur la bibliothèque libnvme qui a pu être intégrée facilement, ce qui a grandement réduit le temps de développement et de déverminage.

Haiku continue donc de suivre les évolutions du matériel récent et l’on peut l’utiliser sur la plupart des ordinateurs.

Mais les pilotes pour du matériel plus ancien ne sont pas en reste, avec des corrections dans les appels au BIOS dans le gestionnaire d’amorçage qui faisaient planter certains BIOS en leur fournissant un tampon mémoire un peu trop grand lors de certains appels. La plupart des pilotes ont été corrigés suite à l’ajout de SMAP et SMEP, qui nécessitent de bien faire la différence entre la mémoire du noyau et celle de l’espace utilisateur, en indiquant clairement lorsqu’on souhaite accéder à l’une ou à l’autre.

Mentionnons également la fusion des pilotes pour les lecteurs de disquettes et les autres périphériques de stockage USB (contrairement à Linux, Haiku ne prévoit pas d’abandonner la gestion des lecteurs de disquettes dans l’immédiat).

Enfin, du travail sur le pilote PS/2 (encore utilisé pour de nombreux pavés tactiles, même si les PC portables les plus récents utilisent apparemment un pavé tactile connecté via SMBus à la place) pour considérer les nouveaux « clickpads » comme des pavés tactiles à un seul bouton (en principe, l’interface graphique devrait être utilisable avec, un souvenir des vieilles souris de chez Apple) et pour pouvoir utiliser les boutons du trackpoint de certains Thinkpads qui sont en fait des boutons supplémentaires du pavé tactile.

La gestion des écrans haute résolution

L’interface de BeOS était pensée pour des écrans avec une résolution quelque part entre 640 × 480 et 1024 × 768 pixels.

Pendant assez longtemps, les densités de pixels sont restées sensiblement les mêmes : on trouve aujourd’hui des écrans en 1920 × 1080 pixels, mais ce sont des écrans 22″ et donc chaque pixel n’est pas beaucoup plus petit que sur un écran 15″ en 1024 × 768 pixels.

Mais on trouve aujourd’hui des écrans avec une densité beaucoup plus importante : du « full HD » sur une dalle 12″, voire des écrans 4K de cette taille, sont aujourd’hui de plus en plus courants.

Certains systèmes ont choisi de « tordre » la définition d’un pixel et d’abstraire complètement ces différences. Les applications indiquent donc des tailles dans une unité arbitraire et le système se débrouille pour afficher les choses correctement.

Pour Haiku, une solution un peu différente a été choisie. L’idée est de laisser l’utilisateur choisir une taille de police de caractères pour le texte, puis de laisser les applications (et en grande partie, la bibliothèque graphique et son système de « layout ») faire le travail pour ajuster tous les éléments en conséquence.

Cette approche ne pose pas trop de problèmes puisque la plupart des icônes sont déjà dans un format vectoriel. Et les applications qui le souhaitent peuvent toujours facilement afficher ce qu’elles souhaitent en bénéficiant de la résolution complète de l’écran et sans redimensionnement.

Cependant, certaines vieilles applications et certaines parties du système fonctionnaient encore avec des éléments dont la taille été fixée en dur en nombre de pixels. C’était par exemple le cas des icônes des « replicants » dans la DeskBar, forcés de se contenter d’un carré de seize pixels de côté. Aujourd’hui, cette taille s’ajuste comme le reste de l’interface graphique.

Les finitions

« Le diable est dans les détails », selon l’expression consacrée.

Un travail important est consacré aux petits détails : ajouter une marge de quelques pixels par ci, améliorer un message d’erreur par là, etc. La cohérence de l’apparence et du comportement de Haiku sont à ce prix.

Citons par exemple une nouvelle fenêtre d’erreur spécifique lors du crash d’un programme, un travail sur la remontée d’erreurs du gestionnaire de paquets jusqu’à l’utilisateur, ou encore le message indiquant si un redémarrage est nécessaire après une mise à jour de paquets.

Le code en charge du rendu de l’interface graphique (BControlLook) a été déplacé dans un « add‐on » (un greffon). Ceci permet donc de le remplacer et l’on peut faire ressembler Haiku à CDE ou à Windows 3.11 si on le souhaite. Le travail est en cours pour reproduire au pixel près l’apparence de BeOS R5. Si vous pensiez que l’interface de Haiku a l’air datée, on pourra maintenant vous montrer à quel point ça pourrait être pire.

L’application Mandelbrot qui affiche des fractales a été complètement réécrite. Le code original était un exemple fourni pour BeOS mais il avait besoin d’un gros nettoyage. Les fractales sont plus jolies et le code aussi.

Sous le capot, le travail continue également pour faciliter le débogage de Haiku, avec par exemple du travail sur le pilote mem permettant de lire et écrire dans la mémoire, le nommage des zones mémoire créées par mmap en fonction de la fonction appelante, ou encore des changements sur la pile SCSI et la gestion des « weak symbols » pour se rapprocher du comportement d’autres systèmes et faciliter le portage d’applications.

Des corrections de bogues

Il y en a trop pour toutes les lister. Mentionnons une correction de la gestion du temps dans l’implémentation de DHCP, qui l’empêchait de fonctionner dès que la réponse à une requête n’était pas reçue quasi immédiatement. La connexion à des réseaux Wi‐Fi publics fonctionne maintenant beaucoup mieux.

D’autres exemples sont la correction de raccourcis clavier qui ne fonctionnaient pas dans l’application Magnify (Loupe), un problème qui empêchait la synchronisation NTP de s’effectuer correctement au démarrage du système, ou encore un plantage systématique lors du démarrage de Haiku sur une machine comportant plus de trente deux processeurs.

Du côté du matériel, une amélioration de la couche de compatibilité avec FreeBSD a permis de supprimer une interruption déclenchée toutes les millisecondes, pour laisser le processeur faire autre chose (ou rien, auquel cas la consommation électrique est réduite). Une autre correction concerne la synchronisation des données sur les disques durs, ces derniers peuvent en effet garder des données en cache et il convient de s’assurer que ces données sont vraiment sur le disque avant de couper l’alimentation électrique.

Compatibilité POSIX

Haiku essaie d’être compatible avec les spécifications POSIX, mais un certain nombre d’interfaces sont encore manquantes. Cette année a vu l’ajout de posix_spawn, pthread_attr_getstack, pthread_attr_setstack, (et au passage, pthread_getattr_np, qui n’est pas dans la spécification POSIX mais est implémentée par Linux et la plupart des BSD), des améliorations dans fcntl et la gestion des descripteurs de fichiers dupliqués.

De nombreuses corrections ont été faites également pour bien traiter la fermeture des descripteurs de fichiers (qui peut être plus complexe qu’il ne semblerait, par exemple lorsqu’une application ferme un fichier alors qu’il est également accessible via un mmap), ou encore sur des situations de compétition (race conditions) lors du démarrage d’un nouveau processus.

L’outil locale en ligne de commande traite correctement l’option -a telle qu’elle est spécifiée par POSIX (c’est utilisé par certains systèmes de construction logicielle pour détecter les « locales » disponibles).

Ces diverses corrections permettent aujourd’hui de faire fonctionner de façon fiable la machine virtuelle Java OpenJDK par exemple, ou encore de lancer LibreOffice ou de nombreuses autres applications utilisant Qt.

Portage sur d’autres architectures

Actuellement, Haiku fonctionne sur les architectures x86 (32 et 64 bits).
Différents portages (PowerPC, ARM, Motorola 68000) existent à des niveaux d’avancement divers, mais aucun n’est vraiment utilisable.

Suite à des problèmes sur la version ARM dont on ne parvenait pas à dire s’ils étaient causés par la version de GCC utilisée ou par une particularité de l’architecture ARM, deux nouveaux portages ont été démarrés : pour les machines SPARC 64 bits (suite au don d’une Sun Ultra 60 à l’un des développeurs), ainsi que pour les processeurs RISC-V, également en 64 bits.

Cela a permis de s’assurer que le problème était bien spécifique aux processeurs ARM, et a permis de débloquer la situation par une mise à jour du compilateur (toutes les architectures utilisent désormais GCC 8, sauf pour la compatibilité avec BeOS) et l’utilisation de l’éditeur de liens de LLVM à la place de GNU ld.

Participation à Outreachy

En plus du Google Summer of Code et du Google Code‐In, cette année Haiku participe à Outreachy et accueille une stagiaire qui travaille sur une refonte de l’interface pour la configuration des souris, claviers, pavés tactiles et autres périphériques d’entrée.

Dans le cadre du Google Summer of Code, nous avons eu quelques avancées pour l’écriture sur les systèmes de fichiers Btrfs, ainsi qu’un gros travail sur la mise à jour de notre version de WebKit pour utiliser WebKit 2, qui permet une meilleure isolation des composants du navigateur Web dans différents processus. C’est la façon recommandée d’utiliser WebKit aujourd’hui (on utilisait encore les interfaces « legacy » jusque‐là).

Analyse du code par PVS-studio

PVS-studio est un outil (malheureusement pas libre) d’analyse statique du code source. L’entreprise qui le développe, OOO “Program Verification Systems”, effectue régulièrement des « scans » de projets libres afin de tester son analyseur et de voir s’il ne lève pas trop de faux positifs. Elle publie ses conclusions avec une liste des bogues les plus intéressants selon elle.

Elle avait déjà effectué une analyse de Haiku il y a quelques années, qui avait demandé pas mal de travail puisqu’à l’époque ses outils fonctionnaient uniquement sous Windows. L’analyse effectuée le mois dernier a été beaucoup plus simple à mettre en place et pourrait être déployée dans un conteneur Docker.

Les développeurs de Haiku sont en train d’analyser les bouts de code suspects trouvés par PVS, afin de voir si des corrections sont nécessaires.

En route pour la bêta 2

Le projet Haiku va essayer de publier des versions à peu près tous les ans. L’absence de versions pendant six ans entre la version alpha 4 et la bêta 1 s’explique par un gros chantier pour la mise en place du système de gestion de paquets, qui était le dernier gros changement prévu. Maintenant qu’on est dans la phase « bêta », il ne devrait plus y avoir de tels gros changements.

Si tout se passe bien, la nouvelle version devrait donc arriver cet automne.

Aller plus loin

• La dépêche de l’année dernière (53 clics)
• Le site officiel de Haiku (440 clics)
• Télécharger Haiku (99 clics)