URL: https://linuxfr.org/news/haiku-se-lache-enfin Title: Haiku se lâche enfin Authors: vincent LECOQ Nÿco, BAud, Thomas Debesse, palm123, ZeroHeure, M5oul, Anonyme, Davy Defaud, mfoucrier, pamputt, j, Benoît Sibaud, zeuxis, jseb, NeoX, reno et Pierre Jarillon Date: 2014年11月03日T11:18:27+01:00 License: CC By-SA Tags: haiku, lennart_poettering et mplayer Score: 95 Le projet Haiku est une réminiscence de feu BeOS. Pour les plus jeunes, [BeOS](http://fr.wikipedia.org/wiki/BeOS) était un système d'exploitation propriétaire développé en C++ par Be Inc. de 1990 à 2000. Son architecture était totalement indépendante, tout en ayant beaucoup de traits POSIX, ce qui permettait avec peu de travail d'y retrouver Qt, Mozilla, SDL, QEMU, Bash et bon nombre d'autres références classiques aux côtés de la logithèque propre de BeOS. Haiku, anciennement OpenBeOS, reprend donc le flambeau de BeOS, avec cette ré-écriture libre, entreprise en 2001, avec l'appui de l'association à but non lucratif créée à cet effet. D'après Wikipédia, « ...une version alpha de Haiku R1 est distribuée le 14 septembre 2009. La R1 Alpha 2 est sortie le 9 mai 2010, la R1 Alpha 3 le 20 juin 2011, et la R1 Alpha 4 le 12 novembre 2012. ». Nous couvrons ici les plans pour Haiku Bêta 1 et R1. Pour information ou rappel, toujours d'après Wikipedia : « Le développement d'Haiku est actuellement focalisé sur la R1, qui doit être quasiment identique à la dernière version distribuée par Be, la R5. ».  ---- [Le site d'Haiku](https://www.haiku-os.org/) [L'annonce d'origine sur la liste de discussion Haiku](https://www.freelists.org/post/haiku-development/Beta1-and-R1-release-plan) [L'écosystème Haiku moderne](http://www.haikuware.com/) [Haiku Slideshow](https://www.haiku-os.org/slideshows/haiku-1) [Le tag "Haiku" sur superuser.com](https://superuser.com/tags/haiku/) ---- Haiku qu’est-ce donc ? =========== Il était une fois BeOS, un système d’exploitation propriétaire né sur les processeurs d'[architecture Hobbit](http://en.wikipedia.org/wiki/AT%26T_Hobbit), puis porté sur PPC (en fait une machine hybride utilisant 2 Hobbits, 3 DSP et 2 PPC). C'était la période des [[BeBox]]. BeOs a tenté l'aventure Intel sur un marché où seul Windows 9x dominait le Bureau, dans le but de sortir de la confidentialité. La philosophie de développement était de ne pas s'encombrer du passé, de toujours profiter au mieux du matériel récent. - BeOS était avant tout un OS orienté multimédia et performances temps réel _(N. D. L. A. : à l’époque, je redémarrais sour BeOs pour lire les vidéos qui étaient trop lourdes pour mplayer sur mon pauvre Cyrix à 133 MHz)_. - BeOS avait un système de fichiers journalisé transactionnel 64 bits appelé [BFS](https://www.haiku-os.org/legacy-docs/practical-file-system-design.pdf) qui fait encore rêver bien des concepteurs de systèmes de fichiers modernes. - BeOS démarrait en moins de temps qu’il ne faut à bien des OS récents pour sortir de veille, un certain Lennart en rêve encore. - BeOS, même s’il avait un véritable terminal, démarrait directement en mode graphique, un certain Rasterman en rêve encore. ;-) - BeOS imposait une structure _multi‐threadée_ au code des applications natives, ce qui leur donnait une réactivité impressionnante, même sur des machines aujourd’hui (et à l’époque) considérées comme limitées. Pour la petite histoire, Be Inc. était dirigée par un français, [Jean-Louis Gassée](http://fr.wikipedia.org/wiki/Jean-Louis_Gass%C3%A9e), qui a failli ravir la place de Steve Jobs durant les années creuses d'Apple. Oui, Mac OS X aurait pu être sur une base BeOS plutôt que NextStep. La chose ne s'est point faite et Be Inc. ne trouvant pas sa place sur le marché a fini par sombrer. Une nouvelle Release 6 (dite Zeta) devait sortir et corriger bien des erreurs de jeunesses du système (comme sa gestion calamiteuse du réseau), mais Be Inc. fut rachetée et enterrée par Palm. Et pour l'histoire encore plus petite, le projet s’appelle Haiku car c’est sous cette [forme poétique](https://fr.wikipedia.org/wiki/Ha%C3%AFku) qu’étaient diffusés [les messages d’erreurs du navigateur NetPositive](http://8325.org/haiku/). Trop beau, trop tôt. C'est en 2001 que Michael Phipps décide de lancer le projet Haiku (OpenBeOS au commencement). Son objectif pour la première release (dite R1) est d'être iso-fonctionnel avec BeOS R5. Cela implique de conserver la compatibilité binaire, le compilateur de reférence (gcc2), la configuration, toutes les API, les pilotes... Où en sommes‐nous ? ========= Après quelques discussions enflammées sur la liste de diffusion Haiku, il y a quelques semaines, concernant la sortie d'une N^ième alpha, il a été décidé lors du _BeGeistert_ 2014 qu'il fallait accélérer les choses. Nombre de contributeurs se sentaient en effet coincés dans une logique d'archéologie concernant les contraintes techniques sus-citées du projet.  Nous sommes en 2014 et la bêta 1 pointe le bout de son nez, après 4 alphas. Haiku est presque BeOS, parfois moins bien, souvent bien mieux. La pile TCP/IP issue de FreeBSD en est un bon exemple. L'accent va désormais se porter rapidement sur la R2 et la gigantesque aire de jeux qu'elle représente pour les hackers de tous poils. L’annonce de la bonne nouvelle =========== C'est Adrien Destugues qui a posté la bonne nouvelle ce 2 novembre, ce qui suit est une traduction libre : _Salut les devs,_ _Pendant le BeGeistert coding sprint nous avons eu une longue discussion avec Ingo, Oliver et Ithamar à propos du futur d'Haiku et des difficultés que nous avons à produire une release. Nous avons cherché à nous mettre d'accord et nous aimerions proposer un plan pour atteindre la R1 et passer à l'étape suivante du développement._ _Les objectifs sont multiples :_ * _Enfin fournir une version stable avec le nécessaire pour les développeurs_ * _Mettre au point un cycle de développement plus efficace qui permettra des releases plus fréquentes_ * _Permettre aux développeurs de travailler sur des choses plus passionnantes sans se sentir coupable de ne pas contribuer à l'objectif primaire de la R1_ _Notre raisonnement est qu'aujourd'hui la compatibilité binaire n’intéresse que peu de développeurs, probablement de même que les utilisateurs. Nous savons que la plupart des gens utilisent plus des applications Qt ou Java que natives de BeOs R5, d'autant qu'au cours des deux dernières années, l'équipe de HaikuArchives a été occupée à récupérer les sources de bon nombre d'applications BeOS, afin qu'elles puissent être mises à jour pour les prochaines releases. En outre, nous pensons qu'une R1 stable permettra d'inciter plus de développeurs à s'impliquer pour Haiku, apporter de nouvelles applications qui ne sont simplement pas concernées par la compatibilité binaire._ _Nous avons fait un premier jet du plan qui assurera une transition douce vers le futur d'Haiku_ _Cela inclut la Bêta 1 puis les étapes vers la R1 incluant une branche de maintenance, ainsi que le développement pour la R2 et les choses amusantes qui vont descendre dans notre dépôt git comme d'habitude._ ## _Pré-requis pour la Bêta1_ _À ce stade, nous avons atteint le checkpoint « fonctionnalités complètes » défini par le sondage « futures fonctionnalités de Haïku » de 2010. La dernière grande chose qui manquait était le gestionnaire des paquets, qui a été fusionné dans Haiku il y a un an et est maintenant stable et utilisable._ _Il reste cependant quelques points de blocage qui empêchent la Beta 1 de passer la porte. La plupart ne sont pas les tâches de développement pour Haiku lui-même, et se rapportent à l'infrastructure PM. Nous avons besoin d'un processus automatisé pour construire les paquets à partir des applications produites par Haikuports afin de les intégrer aux releases. La pratique actuelle qui est de donner à un développeur un accès de commit pour télécharger des paquets n'est pas acceptable car il y a trop de travail et elle conduit à des problèmes de maintenance pour tous les paquets (un paquet est mis à jour, car il est une dépendance d'un autre, mais cela en casse un troisième qui ne peut fonctionner qu'avec une version plus ancienne, etc.)._ _Il y a aussi quelques questions ouvertes telles que l'absence de prise en charge IMAP dans les versions actuelles. Cela a disparu depuis l'Alpha3 et il existe des alternatives acceptables (en utilisant Beam ou un webmail), de sorte que la prise en charge d'IMAP pourrait être laissée de côté._ ## _Plan pour la Bêta1_ _Sans les quelques points indiqués précédemment, il est inutile d'essayer de produire une release. Alors essayons d'abord de les résoudre. Oliver a travaillé pour y arriver, mais plus d'aide serait évidemment la bienvenue. Cela implique des travaux sur HaikuPorter (Python), ainsi que l'infrastructure serveur pour produire des builds. C'est peut-être le bon moment pour des non adeptes du C++ de rejoindre le projet._ _Une fois ces points résolus, le temps de la release sera venu. Je prends la charge de coordinateur de release. Mon plan est d'utiliser plus ou moins le même schéma que pour les versions alpha et bêta._ ## _Plans pour la R1_ _J'ai été mandaté pour mettre au point un plan pour la R1 et au-delà plutôt que des sorties au coup par coup chaque année des nouvelles Alpha. Voici ma proposition à cet effet._ _À partir de la version bêta1, le tronc de Haiku sera consacré à la R2. Le contenu exact de cette nouvelle version doit être décidé entre les développeurs, mais il doit y avoir un consensus à passer à gcc4 ou clang comme compilateur principal, se débarrasser de notre ancienne libc customisée et la remplacer par une officielle et un peu de nettoyage des strates de l'API . C++11 va également commencer à être plus utilisé._ _La prise charge de l'API R1 et/ou la compatibilité BeOS R5/gcc2 dans R2 peuvent être maintenues si quelques-uns sont motivés pour le faire – aucun des participants du BeGeistert code sprinters n'est intéressé, mais d'autres développeurs peuvent vouloir le faire. Cela n'a même pas besoin de rester dans le tronc d'Haiku, nous pourrions le fournir au besoin en third-party – similaire à la façon dont notre port Qt est actuellement distribué. Il reste quelques efforts pour y arriver et des gens devront en prendre soin._ _Pendant ce temps, la branche de Bêta1 vit sa vie et deviendra un jour la R1. Ensuite, le plan est d'être à l'écoute des rapports de bugs des utilisateurs et développeurs et de rétroporter depuis la branche principale quand ce sera nécessaire. Quand la bêta1 sera complète, aucune nouvelle fonctionnalité ne sera plus jamais ajoutée. En tant que coordinateur de la Bêta1, je peux aussi prendre le rôle de responsable de la R1 et m'occuper du rétro-portage. Après un délai raisonnable (peut-être 3 à 6 mois - selon le nombre de bugs trouvés) après release de la Bêta1, une version R1 sera construite depuis cette même branche. Dès lors, la branche pourra vivre et produire de nouvelles version (R1.1, etc.) si de nouveaux problèmes sont détectés. Ou bien on peut basculer sur un mode « rolling release » où les mises à jour sont poussées en utilisant le gestionnaire de paquets. Aucune nouvelle fonctionnalité ne devra être ajoutée dans cette branche._ _Nous pensons que ce plan permet une sortie de la R1 relativement indolore et à court terme. En tant que développeurs Haiku, nous devons admettre que ce ne sera pas une sortie parfaite. Il serait plus souple et lisse que les Bêtas s'appuient sur les branches des Alphas, mais il y aura forcement des bugs et limitations. Je ne pense pas qu'il y ait un moyen d'obtenir une release parfaite et sans bug dans un délai raisonnable avec notre main-d'œuvre actuelle._ _Suite à la publication R1, la compatibilité BeOS R5 pourra continuer à exister dans la R2, soit dans une branche, soit comme un paquet externe. La branche R1 continuera à recevoir des correctifs pour que ceux qui utilisent Haiku en production (nous pensons à [TuneTracker](http://www.tunetrackersystems.com/about_haiku.html)) puissent compter sur une version solide et stable comme base pour leurs produits. De cette façon, les gens peuvent continuer à utiliser la R1 ou migrer vers la R2 et profiter de toutes les nouvelles fonctionnalités, mais au risque de découvrir de nouveaux bugs._ _-- Adrien_ Que faire maintenant ? =========== Haiku n'a d'avenir que s'il trouve ses utilisateurs. Il offre un environnement simple, rapide et efficace tout en donnant accès à des outils de qualité auprès desquels les habitués de GNU/Linux ne sont pas dépaysés.  Installez-le dans une VM ou sur une machine qui s'ennuie, vivez au quotidien avec et il deviendra vite votre indispensable compagnon. Débusquez les bugs, remontez-les, proposez des corrections si vous le pouvez : le challenge est plus accessible qu'avec GNU/Linux, profitez en !  On n'attend plus que vous !