Haiku a 19 ans

Posté par  (site web personnel, Mastodon) . Édité par Lawless, ZeroHeure, Francois Revol, Ysabeau 🧶 🧦 et Davy Defaud. Modéré par Ysabeau 🧶 🧦. Licence CC By‑SA.
Étiquettes :
48
5
août
2020
Haiku

Comme vous le savez si vous suivez les dépêches annuelles de Haiku, la date de naissance du projet est le 18 août 2001, avec l’envoi du premier message « Ok, let's start » sur la liste de diffusion du projet (nommé OpenBeOS à l’époque).

C’est l’occasion de faire un point sur les principales avancées du projet dans l’année (et d’avoir un peu d’activité sur LinuxFr.org au milieu de l’été).

Logo de Haiku

Sommaire

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 de l’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.

La version bêta 2

La deuxième version bêta de Haiku a été publiée avec environ six mois de retard sur la date prévue. Vous trouverez les détails dans la dépêche qui lui est dédiée. Comme cette version est encore toute récente, cette dépêche ne va pas s’attarder sur les nouveautés déjà détaillées dans l’annonce de cette version. Nous allons donc plutôt essayer de voir les travaux en cours et les perspectives pour les années à venir.

Enfin, comme il reste encore de nombreux DVD de la bêta 1 (à prix libre), il n’est pas prévu d’en faire presser de nouveaux, d’autant plus qu’après installation de ceux‑ci le système d’exploitation peut être mis à jour vers la bêta 2.

Participation au Google Summer of Code

Haiku participe régulièrement au Google Summer of Code depuis 2006. Le principe est d’accueillir dans le projet des étudiants qui contribuent pendant trois mois en étant rémunérés par Google. Cela permet à ces étudiants de se concentrer à plein temps sur leur travail pour Haiku (et plus d’une centaine d’autres projets participants), en étant rémunéré par Google. Les projets participants assurent l’encadrement et sont libres du choix des sujets (Google n’a donc pas d’influence sur les développements par ce moyen, si cela vous inquiétait).

Cette année, quatre étudiants ont été retenus pour améliorer Haiku.

L’amélioration des paramètres des périphériques d’entrée

Le travail sur ce sujet avait été démarré l’été dernier dans le cadre d’Outreachy. Il s’agissait dans un premier temps de regrouper dans une seule fenêtre les réglages du clavier et de la souris (qui étaient configurables auparavant dans deux applications séparées). Cet été, le travail se poursuit pour pouvoir configurer chaque périphérique de pointage différemment (par exemple, pour avoir une vitesse de pointeur différente pour un pavé tactile et une souris).

La prise en charge des systèmes de fichiers XFS et UFS2

Afin d’améliorer l’interopérabilité avec les autres systèmes d’exploitation, deux étudiants travaillent actuellement sur la prise en charge des systèmes de fichiers XFS et UFS2.

UFS2 va permettre, d’une part d’accéder aux fichiers sur les partitions de FreeBSD (et probablement des autres *BSD). Il permettra aussi de construire des images disque amorçables sur les stations de travail Sun lorsque le portage de Haiku sur SPARC sera un peu plus avancé.

XFS est un système de fichiers développé au départ par Silicon Graphics pour IRIX, les développeurs de Haiku l’utilisent souvent pour leurs installations de GNU/Linux en raison de sa meilleure prise en charge des attributs étendus de fichiers, nécessaire pour compiler Haiku.

La réécriture de l’API réseau

Haiku dispose d’une implémentation d’un client HTTP, mais celle‑ci est complexe à utiliser et peu performante. Un des projets du Summer of Code de cet été est une refonte de cette API encore expérimentale, pour corriger ces problèmes.

Participation à Outreachy et au Google Code‑In

Outreachy est un programme similaire au Google Summer of Code organisé par l’association Software Freedom Conservancy. Le but est d’encourager la participation des minorités (quelles qu’elles soient) dans les projets libres.

Le fonctionnement est similaire à celui du Summer of Code, avec la différence importante que les projets doivent financer eux‑mêmes le paiement des participants. Haiku a participé l’été dernier, mais ne peut pas se permettre pour l’instant de renouveler la chose, en attendant de trouver un ou plusieurs sponsors qui permettraient de le faire à nouveau.

Le Google Code-In était un concours visant les adolescents de treize à dix‑sept ans, dont le principe était de proposer des tâches à réaliser pour différents projets libres. Haiku est le seul projet à avoir participé tous les ans depuis la création du Code‑In en 2010, grâce aux efforts de Scott McCreary et d’une équipe de « mentors » s’occupant de relire et de valider le travail des participants (la plupart n’étant pas des développeurs actifs de Haiku, mais des membres de la communauté ou des anciens participants au Code‑In). Malheureusement, Google a choisi de ne pas renouveler ce programme en 2020. Différentes idées sont en cours de réflexion pour le remplacer : monter un concours similaire sans l’aide de Google, ou rejoindre d’autres évènements existants comme Hacktoberfest, par exemple.

Des idées pour la suite

La publication de la version bêta 2 en juin a beaucoup mobilisé les contributeurs depuis le début de l’année. L’été est assez calme pour l’instant. La rentrée sera sûrement l’occasion de discuter d’un plan d'attaque pour la version bêta 3.

Comme après chaque publication de version, les rapports de bogues ont été nombreux. Un effort de tri a été fait depuis quelques années sur le système de suivi des bogues pour séparer les tickets « indispensables » dans la version R1 de Haiku, de ceux qui pourraient être traités plus tard. Cela laisse un peu moins de 1 130 tickets à traiter avant la version R1 au dernier décompte.

Le travail se poursuit pour corriger ces problèmes un par un. Tous les domaines sont concernés, par exemple, en ce moment, un développeur s’occupe du « Media Kit » et des pilotes pour les cartes sons, qui sont pour l’instant plutôt capricieux (silence pendant plusieurs minutes au démarrage avant de se mettre à fonctionner, matériel non reconnu sur certaines machines, pilote qui fonctionne uniquement si la carte a été initialisée préalablement par un autre système d’exploitation…) ; tandis que plusieurs autres améliorent le serveur graphique pour accélérer l’affichage (en particulier des pages Web complexes), améliorer la mise à l’échelle pour les écrans à haute résolution, etc.

D’autre part, on ne peut pas empêcher les développeurs de s’amuser avec des développements qui ne rentrent pas dans la feuille de route. C’est ainsi que le travail continue sur le portage de Haiku vers les architectures SPARC, ARM ou Motorola 680x0 ; ou encore les pilotes pour les cartes SD et les puces eMMC. Si ces apports ne sont plus vraiment utiles pour certains, ou pas encore pour d’autres sur des machines actuelles, ils permettent néanmoins d’améliorer le code en le factorisant par exemple, ou grâce à un meilleur alignement des données, nécessaire sur une architecture exotique mais augmentant aussi les performances sur x86.

Avant d’arriver à une version complètement satisfaisante, il faudrait aussi s’occuper de tous les aspects concernant la gestion des imprimantes, de corriger les problèmes restants dans l’implémentation du protocole TCP, et encore bien d’autres choses. Il est probable que cela nécessite encore plusieurs versions bêta et quelques années de développement supplémentaires.

Statistiques de contribution

Comme c’est bien de savoir où on en est, PulkoMandy publie de temps en temps des statistiques sur les contributions au dépôt Git de Haiku et à HaikuPorts. Depuis quelques mois, l’outil utilisé pour générer ces statistiques est repostat, en remplacement de gitstats qui n’était plus maintenu et n’a jamais été migré en Python 3. Avant de pouvoir migrer, il a cependant fallu ajouter quelques fonctionnalités manquantes à repostat, et le rendre beau, en remplaçant les graphiques statiques générés avec Gnuplot par des graphes générés en JavaScript et SVG en utilisant NVD3.

Des détails pour Haiku

Pour Haiku, on peut constater que l’activité est stagnante depuis 2016 avec 1 300 à 1 500 commits par an. On est loin du record de 5 555 commits atteint en 2009. Cependant, chaque année ce sont plus d’une cinquantaine de contributeurs qui participent à Haiku, et depuis 2016 ce chiffre semble également augmenter, même si pour l’instant le record est toujours en 2012 avec soixante‑douze contributeurs. En 2018 et 2019, un seul contributeur a réalisé à lui seul plus d’un tiers puis plus de la moitié des commits. L’année 2020 semble pour l’instant mieux équilibrée.

Le nombre de fichiers (un peu plus de 30 000) et de lignes de code (entre cinq et six millions) n’évoluent pas beaucoup depuis 2015 (ou il avait fortement baissé suite à la suppression de nombreuses bibliothèques tierces qui avaient été copiées dans le dépôt Git, et qui sont maintenant téléchargées lors de la compilation).

Des détails pour HaikuPorts

Du côté de HaikuPorts, l’activité a été importante en 2017 et 2018, juste avant la sortie de la première version bêta. Elle se maintient bien depuis, avec plus de 2 000 commits par an (plus de cinq par jour).

Le nombre de contributeurs est assez élevé pour HaikuPorts (une soixantaine chaque année). Cependant on voit que les dix contributeurs les plus actifs sont responsables de 75 % des recettes de construction de paquet. Cela s’explique en partie par des contributions de personnes qui maintiennent des recettes pour empaqueter leurs propres logiciels, avec donc une activité assez restreinte.

Le dépôt contient actuellement des recettes pour 2 762 logiciels et bibliothèques.

Des moyens de communications

Le service de journalisation echelog pour les canaux IRC de Freenode a été arrêté. Ce service avait été développé au départ pour les canaux de Haiku et lwjgl, mais était utilisé par de nombreux autres projets également. Haiku utilise désormais logbot en remplacement.

Haiku commence à se poser la question de la migration des salons de discussion et des autres moyens de discussion. Historiquement, IRC et des listes de diffusion par courriel sont principalement utilisés. Cependant, ces outils ne sont plus aussi courants aujourd’hui et pas forcément appropriés dans toutes les situations (pas accessibles facilement avec un ordiphone, par exemple) et cela freine la participation de certains contributeurs. De plus, il manque un certain nombre de fonctionnalités (par exemple, la modération sur les listes de diffusion permettant de supprimer un message et de bloquer un fil de discussion pour empêcher des réponses inutiles), ou bien il y a du travail à faire pour les mettre en place (les journaux du canal IRC, par exemple).

Les conditions qui semblent indispensables pour la migration font cependant qu’il n’y a pas beaucoup d’alternatives :

  • utilisation de logiciels libres avec un protocole documenté et standardisé ;
  • pas de contraintes sur les personnes qui peuvent utiliser le service (par exemple, certains services de discussion sont interdits aux moins de treize ans) ;
  • disponibilité de clients pour la plupart des systèmes, y compris Haiku (sans avoir besoin d’installer Qt ou autre grosse bibliothèque multi‑plate‑forme).

Le candidat le plus avancé est probablement XMPP (avec le client Renga), mais cela demandera encore du temps avant d’avoir un client complet et de commencer à envisager une migration.

En attendant, il est possible de trouver des développeurs et utilisateurs de Haiku sur divers services tels que Matrix, Telegram, Discord, BeShare (un système de clavardage et partage de fichiers en pair à pair développé pour BeOS à l’origine), ainsi que sur le forum discuss.haiku-os.org ou encore sur Reddit.

Des ponts ont été mis en place entre IRC et Matrix, et entre IRC et BeShare. Les salons Telegram restent séparés car leur usage est un peu différent (beaucoup d’envoi d’images ou de vidéos, voire de messages vocaux) et cela serait plus dérangeant qu’autre chose sur le canal IRC.

La situation actuelle nous empêchant d’organiser des rencontres dans la vie réelle pour probablement encore quelque temps, cette réflexion prend un peu plus d’importance en ce moment.

Aller plus loin

  • # HTTP ?

    Posté par  . Évalué à 6.

    Haiku dispose d’une implémentation d’un client HTTP, mais celle-ci est complexe à utiliser et peu performante.

    Je ne comprends pas bien. Les OS exposent une API de socket plutôt qu'un protocole applicatif (il y a des fonctionnalité de plus haut niveau proposé comme la résolution de nom, mais c'est plus qu'un protocole). Là il est question d'API du noyau, d'une bibliothèque inclue de base, d'un utilitaire type curl ?

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: HTTP ?

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

      Il s'agit d'une API native du Network Kit, qui est utilisé notamment par WebPositive, navigateur utilisant WebKit. Il reste bien sûr possible d'utiliser cURL ou d'autres bibliothèques ou les sockets BSD si on veut.

    • [^] # Re: HTTP ?

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

      C'est un peu ce qui fait la différence entre Haiku et un OS quelconque :)

      On fournit dans Haiku des APIs pour plein de choses (applications graphiques, réseau, multimédia, décodage et encodage d'images…). On fait, en gros, l'équivalent d'un KDE ou d'un GNOME avec tout ce qu'il faut en-dessous pour que ça fonctionne.

      Et donc, oui, il y a certes des APIs pour faire des sockets directement, mais aussi une API de plus haut niveau pour faire facilement du HTTP. Ça permet d'intégrer facilement le code réseau avec le reste, en particulier avec les boucles d'évènements BLooper/BHandler, et de faciliter la vie des développeurs d'applications.

      On peut facilement combiner ça avec les APIs multimédia pour écouter de la musique ou regarder un flux vidéo en streaming. Ou avec le parser json pour interroger une API en quelques dizaines de lignes de code.

      Quelques exemples d'applications reposant là dessus:
      - https://github.com/haikuarchives/streamradio
      - https://github.com/haikuarchives/weather
      - https://github.com/haikuarchives/maps
      - https://github.com/pulkomandy/friss

      Ainsi que le gestionnaire de paquets de Haiku (aussi bien la version en ligne de commande pour le téléchargement des paquets, que l'interface graphique pour en plus récupérer les captures d'écran, icônes, commentaires des utilisateurs, …)

Suivre le flux des commentaires

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