URL: https://linuxfr.org/news/haiku-a-19-ans Title: Haiku a 19 ans Authors: pulkomandy Lawless, ZeroHeure, Francois Revol, Ysabeau đŸ§¶ et Davy Defaud Date: 2020ćčŽ07月28æ—„T21:49:57+02:00 License: CC By-SA Tags: haiku Score: 48 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](http://www.freelists.org/post/haiku/Ok-lets-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](https://raw.githubusercontent.com/haiku/haiku/master/data/artwork/HAIKU logo - black on transparent - big.png) ---- [Site Web de Haiku](http://www.haiku-os.org) [TĂ©lĂ©charger Haiku](https://linuxfr.org/get-haiku/r1beta2/) [La dĂ©pĂȘche anniversaire prĂ©cĂ©dente](https://linuxfr.org/news/haiku-a-18-ans) ---- 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](https://linuxfr.org/news/haiku-r1-beta-2). 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](https://discuss.haiku-os.org/t/buy-now-haiku-dvd/7861) (Ă  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_](https://hacktoberfest.digitalocean.com/), 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](http://pulkomandy.tk/stats/) et Ă  [HaikuPorts](http://pulkomandy.tk/stats_hp). Depuis quelques mois, l’outil utilisĂ© pour gĂ©nĂ©rer ces statistiques est [repostat](https://github.com/vifactor/repostat), en remplacement de [gitstats](https://github.com/hoxu/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](https://github.com/haikuports/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](https://echelog.com/) 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](https://lwjgl.org/), mais Ă©tait utilisĂ© par de nombreux autres projets Ă©galement. Haiku utilise dĂ©sormais [logbot](https://freenode.logbot.info/haiku/20200802) en remplacement. Haiku commence Ă  se poser la question de la migration des salons de discussion et des autres moyens de discussion. Historiquement, [IRC](https://www.haiku-os.org/community/irc/) et des [listes de diffusion](https://www.haiku-os.org/community/ml/) 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](http://github.com/haikuarchives/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](https://www.goodeveca.net/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](https://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.

AltStyle ă«ă‚ˆăŁăŠć€‰æ›ă•ă‚ŒăŸăƒšăƒŒă‚ž (->ă‚ȘăƒȘă‚žăƒŠăƒ«) /