Haiku a 17 ans

Les années passent, et Haiku est toujours là !

Le projet, inspiré du système d'exploitation BeOS, a démarré le 18 août 2001, avec le fameux message « So, let’s start » (« Bon, allons‐y ») sur sa liste de discussion. Alors nommé OpenBeOS, le projet avait été créé peu après l’annonce du retrait de Be du marché des ordinateurs de bureau.

Cet anniversaire est l’occasion de faire le point sur les progrès de Haiku cette année (en l’absence de nouvelle version publiée depuis la version alpha 4 en 2012, il faut bien trouver un prétexte pour donner des nouvelles de temps en temps).

Sommaire

• Présentation de Haiku
  • Pourquoi un clone de BeOS ?
  • Toujours pas de version bêta
• Nouveautés de l’année
  • Corrections de bogues
  • Infrastructure
  • Pilotes de périphériques
    • Mise à jour des pilotes réseau
    • Prise en charge de l’USB 3
    • Pilotes VirtIO
  • Mise à jour du navigateur Web
  • Media Kit
    • Ajout du BMediaClient
    • Passage à FFmpeg 4
  • Gestion du mode hybride 32/64 bits
  • Passage à GCC 7
  • Le retour de Cosmoe
  • LibreOffice pour Haiku
  • D’autres langages de programmation
  • Prise en charge de l’UEFI
  • Améliorations de l’interface utilisateur
  • Launch Daemon
• Évènements et conférences
• GCI et GSoC
  • Google Summer of Code
  • Google Code‐In

Présentation de Haiku

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 multi‐thread (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.

Cependant, 17 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. Cet objectif initial n’a donc pas été atteint en temps utile.

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

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 15 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.

Cependant les désavantages (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 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.

Toujours pas de version bêta

La dernière version publiée par Haiku est la version R1 alpha 4.1, qui date de novembre 2012. De très nombreux progrès ont été faits depuis, et en particulier un gros chantier sur l’infrastructure d’hébergement du projet permettant de mettre en place un dépôt de paquets pour tous les utilisateurs (ce sera l’une des grosses nouveautés de la prochaine version R1 bêta 1).

Si on avait su que cela prendrait autant de temps, on se serait probablement organisé autrement, afin de pouvoir publier quelques versions alphas supplémentaires et faire patienter les gens. Pour l’instant, il vaut vraiment mieux télécharger un « nightly build » pour essayer Haiku.

Nouveautés de l’année

Corrections de bogues

Il y en a beaucoup trop pour les détailler. Haiku est de plus en plus stable. Le portage d’applications venues d’autres systèmes, et la mise en place de machines fonctionnant sous Haiku pour la compilation des paquets présents dans les dépôts a permis (même si ce n’était pas le but initial) de tester le système de façon beaucoup plus intense. De nombreux problèmes difficiles à reproduire ont ainsi pu être plus facilement identifiés, puis résolus.

La compatibilité POSIX s’améliore, le noyau fait de plus en plus de vérifications pour éviter les « panics » lors d’appels systèmes avec des paramètres invalides.

Un bogue mérite une mention spéciale, la méthode Split() permettant de découper une chaîne de caractères à l’endroit où elle contient un séparateur ne fonctionnait pas correctement. Il est surprenant que ce problème n’ait jamais été détecté auparavant.

Nous avons également corrigé plusieurs problèmes d’alignement de la pile (dans le fil d’exécution principal, les handlers de signaux, et dans le noyau) qui empêchaient l’utilisation fiable d’instructions SSE2. Le problème a été mis en évidence au départ dans le navigateur web, il a donc fallu creuser assez loin dans le système pour le corriger !

Infrastructure

Le vénérable serveur baron, qui hébergeait l’ensemble des services de Haiku (système de suivi, dépôts Git, site Web…) depuis fin 2009 est en train d’être mis à la retraite.

Il est remplacé par maui, un serveur plus récent, qui utilise des conteneurs docker plutôt que des machines virtuelles pour isoler les différents services.

C’est une opportunité pour revoir entièrement la façon de gérer le serveur. Baron était administré principalement par une personne qui faisait les changements directement. Mais avec le temps, de plus en plus de services ont été mis en place et il devenait trop difficile pour une seule personne de tout suivre. Le nouveau serveur est configuré à partir de dockerfiles qui peuvent donc être relus et modifiés par plusieurs personnes.

D’autre part, un gros changement est le déploiement de Gerrit pour la revue de code. Précédemment, les contributeurs attachaient des correctifs dans leurs rapports de bugs et la revue était faite à partir de ces fichiers, ce qui est assez peu pratique. Gerrit permet de faire une revue plus facilement, et il est donc également utilisé par les développeurs (qui pourraient directement envoyer leurs changements sur la branche principale du dépôt Git) pour obtenir une relecture de leurs changements.

En ce qui concerne l’hébergement des dépôts de logiciels, nous avons enfin tout mis en place pour compiler automatiquement les logiciels à partir de recettes fournies par le projet haikuports. Un système de miroirs est en train de se mettre en place, avec pour l’instant deux serveurs situés aux États‐Unis et en Nouvelle‐Zélande (en plus du serveur principal situé en Allemagne).

Les paquets binaires sont donc rapidement disponibles dans HaikuDepot (le gestionnaire de paquets de Haiku) dès la publication des recettes permettant de les construire.

Pilotes de périphériques

Comme pour n’importe quel système d’exploitation, un point délicat est de pouvoir fonctionner correctement sur le plus d’ordinateurs possibles. Cela passe par l’écriture de pilotes pour tous les périphériques.

C’est donc une partie de Haiku qui est assez active et il serait difficile de recenser précisément tous les changements intervenus dans l’année. Mentionnons quand même le support des boutons « étendus » pour les pavés tactiles Synaptics et un début de support de leur « clickpad » ; la possibilité d’utiliser une imprimante connectée sur un port série; des évolutions sur les pilotes graphiques Intel et Radeon pour prendre en charge plus de versions du matériel; et de petites améliorations sur le pilote de cartes son hda (qui est utilisé sur tous les ordinateurs à base de chipset Intel).

Mise à jour des pilotes réseau

Pour gagner du temps, Haiku réutilise les pilotes développés pour FreeBSD via une couche de compatibilité.

Jusqu’à l’année dernière, les pilotes de FreeBSD 9 étaient utilisés, mais aujourd’hui nous utilisons ceux de FreeBSD 11. Cela augmente le nombre de cartes réseau prises en charge et corrige de nombreux problèmes d’instabilité de la connexion.

D’autre part, un gros travail a été fait sur la pile TCP pour compléter l’implémentation de diverses RFC permettant d’obtenir de meilleures performances.

Prise en charge de l’USB 3

Le pilote xHCI est maintenant fonctionnel sur la plupart des machines, même s’il ne fonctionne pas encore parfaitement. Cela devenait nécessaire, car de plus en plus d’ordinateurs ne proposent plus du tout de ports USB 2.

Pilotes VirtIO

Les pilotes VirtIO sont maintenant pleinement fonctionnels. VirtIO est un bus utilisé par des machines virtuelles pour remplacer certains périphériques et éviter d’émuler un matériel réel. En utilisant une interface simplifiée, l’écriture des pilotes est facilitée et les performances sont meilleures.

Haiku peut maintenant utiliser les cartes réseau, le « ballonnement » de la mémoire (mémoire vive qui peut être redimensionnée en fonction des besoins de l’hôte et des machines émulées), et le stockage de masse sur VirtIO.

Mise à jour du navigateur Web

Le navigateur fourni avec Haiku est basé sur un portage de WebKit. Nous avions l’an dernier un an et demi de retard sur la version de WebKit en amont. Nous avons rattrapé une partie de ce retard puisque nous utilisons aujourd’hui une version datant de janvier 2018.

Ceci permet d’accéder à des sites Web modernes, même si de nombreux problèmes subsistent au niveau du rendu ainsi que de l’implémentation du protocole HTTP (moins simple qu’il n’y paraît à mettre en œuvre correctement).

En attendant, les navigateurs Qupzilla et Otter browser, en Qt, permettent de visiter certains sites que WebPositive, le navigateur natif, ne parvient pas encore à traiter.

Media Kit

Le Media Kit prend en charge tous les aspects multimédia (audio et vidéo, principalement) dans Haiku. Il permet aux applications d’exposer des nœuds qui sont connectés dans un graphe, un peu à la façon de Jack ou GStreamer sous GNU/Linux.

Ajout du BMediaClient

L’écriture de nœuds média demande beaucoup de travail répétitif et inutilement complexe. Une nouvelle classe BMediaClient a donc été introduite qui propose de prendre en charge la plupart de cet effort et donc de proposer une interface plus simple à aborder aux développeurs.

Passage à FFmpeg 4

Haiku utilisait encore pour sa version GCC 2 une version 0.10 de FFmpeg, car il était impossible de compiler des versions plus récentes. Cela empêchait l’utilisation des API modernes de FFmpeg et commençait à poser problème pour la prise en charge de formats de fichiers récents.

La solution mise en place consiste à compiler ffmpeg avec GCC 7, mais à faire l’édition de lien de façon compatible avec GCC 2. Pour l’instant, cela semble fonctionner dans ce cas précis. Nous allons donc pouvoir moderniser le greffon de décodage audio et vidéo basé sur FFmpeg, qui traite dans Haiku la plupart des formats de fichiers.

Gestion du mode hybride 32/64 bits

La version 64 bits de Haiku ne peut actuellement pas exécuter d’applications 32 bits. Il est probable que la version 32 bits soit un jour complètement abandonnée, mais pour cela il faudra proposer une solution pour que les utilisateurs puissent migrer vers la version 64 bits en conservant leurs applications.

La gestion de l’exécution des applications 32 bits sur un noyau 64 bits est donc un des chantiers en cours. Cela pose un certain nombre de problèmes au niveau de l’interface entre le noyau et l’espace utilisateur, les appels systèmes devant traiter les données dans le bon format selon l’application utilisée.

La première étape déjà franchie est l’intégration de SMAP et SMEP, qui permettent de s’assurer que le noyau n’accède pas par erreur aux données en espace utilisateur (la protection dans l’autre sens étant déjà assurée par la MMU). On a pu grâce à cette vérification clairement identifier tous les endroits ou de tels accès sont effectués, ce qui permettra de repérer facilement s’il est nécessaire ou pas de faire une conversion 32 <=> 64 bits. De plus, on gagne en sécurité puisqu’il sera plus compliqué pour une application d’utiliser un appel système de façon détournée pour lire ou écrire dans la mémoire du noyau.

Passage à GCC 7

Haiku dans sa version 32 bits est fourni avec deux compilateurs, une version 2.95.3 de GCC qui permet d’assurer la compatibilité binaire avec BeOS, et un GCC plus récent permettant de compiler les applications modernes (la version 64 bits de Haiku n’assure pas pour l’instant de compatibilité, et donc fournit uniquement une version moderne de GCC).

L’année dernière, la version « moderne » utilisée était GCC 5.4. Nous utilisons maintenant la version 7.3. La migration a été l’occasion de corriger quelques bogues dans Haiku qui l’empêchaient de démarrer avec les nouvelles optimisations proposées par GCC.

Le travail est déjà en cours pour le passage à GCC 8, qui lève de nouveaux warnings (une grande partie de Haiku est bien entendu compilée avec le drapeau -Werror, donc les warnings ne sont pas admis).

Le retour de Cosmoe

Cosmoe est un projet consistant à porter l’espace utilisateur de Haiku sur un noyau Linux ou BSD. Il n’a jamais abouti à quelque chose de fonctionnel, mais plusieurs développeurs (impliqués dans Haiku ou pas) ont repris le projet de temps en temps pour y faire quelques mises à jour.

Cette fois, le projet a été repris par Dario Casuolinovo alias Barrett, qui a travaillé sur Caya (notre client de messagerie instantanée) et sur le Media Kit de Haiku. Son travail sur le Media Kit l’a convaincu que le noyau utilisé dans Haiku n’était plus pertinent aujourd’hui et qu’il valait mieux l’abandonner pour quelque chose d’autre. Nous verrons si Cosmoe arrive à percer cette fois‐ci.

Les membres du projet Haiku pensent que leur noyau reste pertinent (pour diverses raisons, en particulier le fait qu’il est écrit en C++ et qu’il offre une ABI stable pour les pilotes de périphériques) mais sont heureux de voir émerger d’autres projets inspirés par BeOS.

LibreOffice pour Haiku

Ça y est ! après plusieurs tentatives (quand on a commencé, le projet s’appelait encore OpenOffice…), nous avons enfin une version de LibreOffice pour Haiku.

Cela a été rendu possible par le gros travail chez LibreOffice pour simplifier leur système de compilation, et également par le système de paquets de Haiku qui a permis de capitaliser et de mutualiser le portage des dépendances de LibreOffice.

Bien qu’une grande partie des efforts a été faite pour avoir une version native, c’est finalement l’apparition d’un back‐end Qt dans LibreOffice qui a permis d’avoir une version fonctionnelle le plus rapidement.

La disponibilité d’une suite bureautique moderne est un point important, d’une part parce qu’on peut maintenant présenter Haiku sérieusement comme un système utilisable pour faire un peu de bureautique et de navigation Web, et d’autre part parce que LibreOffice remplace GoBe Productive, l’une des dernières applications BeOS non libres et encore utilisées (la prochaine sur la liste est Sync Modular — avis aux volontaires). On peut donc commencer à envisager plus sereinement l’abandon de la compatibilité binaire avec BeOS.

D’autres langages de programmation

Le langage Rust est à la mode, il était donc indispensable d’avoir une version pour Haiku et c’est maintenant chose faite. Rust 1.28 contient tous les correctifs nécessaires pour compiler directement sur Haiku, sans modifications.

Mentionnons aussi une version de Swift qui est arrivée cette année, la prise en charge de Fortran disponible par défaut dans GCC, et des progrès pour avoir une version de Free Pascal complètement opérationnelle. Ceci, bien sûr, en plus de tous les langages qui fonctionnaient déjà très bien auparavant : Python 2 et 3, Lua, Perl, C, C++ et de nombreux autres.

Java et Go ont été disponibles quelque temps, mais ont disparu des dépôts lors de l’automatisation des builds. L’ancien paquet pour Java 7 fonctionne, la version de Java 8 disponible plante au démarrage, et il n’y a pas encore eu de tentative pour les versions suivantes. Du côté de Go, une version assez ancienne était fonctionnelle, mais il est maintenant impossible de la compiler, car les sources référencent des dépôts hébergés par code.google.com, maintenant fermé. Avis aux volontaires pour remettre tout ça en route.

Enfin, il semble utile de présenter yab, une divergence de yabasic qui permet de développer des applications graphiques pour Haiku. Il n’était plus vraiment maintenu, mais quelques développeurs l’utilisant se sont un peu mis au C++ pour faire les évolutions nécessaires. Il est maintenant disponible dans les dépôts, l’interpréteur étant distribué sous forme d’une bibliothèque partagée qui peut être utilisée par tous les programmes écrits en yab.

Prise en charge de l’UEFI

Il est maintenant possible d’installer Haiku sur une machine UEFI. Actuellement ce n’est pas intégré dans les « nightly builds » générés par nos buildbots, il s’agit d’une image séparée contenant uniquement un chargeur de démarrage UEFI. Plus tard, ce sera intégré aux images « anyboot » (qui disposent également d’un MBR pour démarrer depuis une clé USB, et d’un chargeur « el torrito » pour démarrer quand elles sont gravées sur un CD).

Améliorations de l’interface utilisateur

Là encore, beaucoup trop de changements pour tous les lister, mais les applications fournies avec Haiku ont vu de nombreux petits changements. Cela va du comportement des menus ouverts trop près du bord de l’écran, à une meilleure prise en charge des écrans haute résolution (il suffit de choisir une taille de police de caractères appropriée, le reste de l’interface doit s’adapter en fonction).

Launch Daemon

Le Launch Daemon est chargé de l’exécution des services, et du séquençage du démarrage et de l’arrêt du système.

Les évolutions cette année portent sur la gestion des logs, une réécriture de la procédure d’arrêt pour éviter d’éteindre la machine avant que l’utilisateur ait pu enregistrer tous les changements dans des applications ouvertes (dans certains cas tordus). Il reste néanmoins bien plus léger que systemd.

Évènements et conférences

Comme chaque année, Haiku était présent au FOSDEM, au Capitole du Libre, aux JDLL et aux RMLL. L’occasion de donner plusieurs conférences, de rencontrer les développeurs d’autres projets et d’en profiter pour porter quelques logiciels vers Haiku avec l’aide des contributeurs principaux (mentionnons cette année Poezio, Dead Ascend, ou encore le Godot Engine, qui avait déjà un portage mais non maintenu). Nous avons également pu constater lNincompatibilité de Haiku avec les machines Purism Librem, sans avoir le temps de se pencher de plus près sur la question, malheureusement.

La conférence BeGeistert, qui regroupe depuis très longtemps les utilisateurs et développeurs de Haiku (et de BeOS et Zeta), a pris une pause cette année, l’équipe organisatrice n’ayant plus la motivation pour s’en occuper étant donné le peu de personnes présentes.

Le projet Haiku mettait à profit cette conférence pour organiser un « coding sprint », qui consiste à mettre le plus grand nombre possible de développeurs dans une salle de réunion pendant cinq jours avec un stock approprié de sodas, et une cantine et des lits à disposition. Le coding sprint étant un moyen étonnamment efficace de faire avancer les choses, nous avons décidé de le maintenir, et de l’organiser cette année juste après le Capitole du Libre, à Toulouse. Le changement de lieu a été plutôt apprécié par les développeurs présents, qui ont pu en particulier travailler sur le portage de LibreOffice, des corrections de bugs dans le navigateur web, l’amélioration de l’application HaikuDepot (le gestionnaire de paquets graphique) pour régler divers problèmes de performance et faire quelques améliorations cosmétiques, ou encore ajouter le réglage de la luminosité de l’écran sur les PC portables utilisant un chipset vidéo Intel.

Bonne nouvelle, après cette année sans BeGeistert, l’évènement sera de retour en octobre prochain. Nous retournerons en Allemagne mais nous quitterons Düsseldorf, dont l’auberge de jeunesse qui nous a souvent accueilli n’offre plus des tarifs accessibles pour le budget de HSA (l’association qui finance l’évènement). Le format retenu est un évènement sur quatre jours, le détail sera décidé par la suite, sans doute un intermédiaire entre une conférence (avec quelques présentations) et un coding sprint.

GCI et GSoC

Haiku candidate tous les ans au Google Code‐In et au Google Summer of code.

Google Summer of Code

Il s’agit d’un programme organisé par Google dont le principe est de payer des étudiants pour qu’ils puissent travailler à plein temps sur des projets libres. Les membres de chaque projet s’occupent de l’encadrement, et ont toute liberté dans les sujets proposés.

Haiku a accueilli trois étudiants cette année, travaillant sur le système de fichiers XFS (mais cela n’a pas donné grand‐chose), un pilote pour les périphériques SDHCI (lecteurs de cartes SD sur de nombreuses plates‐formes ARM et certains portables x86), et un client graphique pour Git intégré dans le système de suivi (largement inspiré de TortoiseGit sous Windows). Les deux derniers projets sont en bonne voie.

Google Code‐In

Code‐In, quant à lui, cible les enfants de 13 à 17 ans, le but étant de leur faire découvrir le logiciel libre et plus généralement le développement de logiciels.

Il s’agit d’un concours où les participants doivent compléter différentes tâches assez simples proposées par un projet libre. Chaque projet choisit ensuite deux gagnants qui pourront passer une semaine à San Francisco, assister à des conférences de personnes travaillant chez Google, et obtenir de nombreux auto‐collants, T‐shirts, et autres goodies.

Haiku participe tous les ans depuis la création du Google Code-In en 2010. Cela nécessite un investissement important de toute la communauté autour du projet, en effet il n’est pas facile de gérer l’arrivée massive des participants sur les canaux IRC et listes de diffusion du projet. Cependant, l’habitude est prise et l’organisation est un peu meilleure chaque année.

Les tâches proposées sont diverses, on trouve des choses techniques (par exemple porter et packager un logiciel pour Haiku), graphiques (concevoir un autocollant à distribuer lors des conférences ou un poster présentant Haiku), de la documentation, ou encore du test (trouver des bugs dans un logiciel, écrire un plan de test, vérifier si des bugs reportés dans le passé sont toujours présents), et enfin une catégorie « outreach » (par exemple, préparer une présentation sur Haiku et la présenter à d’autres élèves, ou encore faire une vidéo présentant une fonctionnalité particulière).

L’intérêt principal de ces deux programmes est l’accueil de nouveaux contributeurs et l’amélioration de la diversité de notre équipe, en effet la communication de Google et des différents projets participants permet de faire découvrir Haiku à des personnes qui ne seraient pas autrement venues contribuer.

On ne compte plus vraiment sur ces projets pour faire avancer les choses directement : le temps nécessaire pour l’encadrement dépasse largement le temps qu’un développeur expérimenté aurait utilisé pour faire le travail directement. Cependant l’expérience est intéressante et nous permet aussi d’améliorer notre documentation et notre façon de travailler pour être plus accueillants aux nouveaux contributeurs.

Aller plus loin

• La dépêche de l’année dernière (227 clics)
• Le site officiel de Haiku (750 clics)