URL: https://linuxfr.org/news/haiku-a-23-ans-haiku-r1-beta-5-partie-3-documentation-finances-et-gsoc Title: Haiku a 23 ans - Haiku R1 bĂȘta 5 (partie 3 : documentation, finances et GSOC) Authors: pulkomandy BAud, Ysabeau đŸ§¶, Arkem, palm123, bobble bubble et BenoĂźt Sibaud Date: 2024ćčŽ09月16æ—„T21:45:01+02:00 License: CC By-SA Tags: haiku, systĂšme_d'exploitation, documentation et ospo Score: 21 Les deux parties prĂ©cĂ©dentes ont prĂ©sentĂ© les principales Ă©volutions dans le code de Haiku. Mais le code ne fait pas tout. Cette troisiĂšme (et derniĂšre) partie prĂ©sente les nouveautĂ©s dans la documentation, ainsi qu’un court aperçu du rapport financier et aux dons qui permettent Ă  Haiku d’employer un dĂ©veloppeur Ă  plein temps de façon durable. Enfin, elle prĂ©sente la participation au Google Summer of Code et les travaux rĂ©alisĂ©s par les cinq Ă©tudiants encadrĂ©s par Haiku cette annĂ©e. ---- [dĂ©pĂȘche de l'annĂ©e prĂ©cĂ©dente pour les 22 ans](https://linuxfr.org/news/22-ans-de-haiku) [Site web de Haiku](https://www.haiku-os.org/) [Documentation utilisateur](https://www.haiku-os.org/docs/userguide/fr/) [Documentation d'API](https://www.haiku-os.org/docs/api/) [Documentation pour les dĂ©veloppeurs](https://www.haiku-os.org/docs/develop/) [Les rapports financiers de Haiku, inc.](https://www.haiku-inc.org/documents/) [Contributions GSoC pour Haiku](https://www.haiku-os.org/community/gsoc/) [Haiku a 23 ans - Haiku R1 beta 5 (partie 2 : le noyau)](https://linuxfr.org/news/haiku-a-23-ans-haiku-r1-beta-5-partie-2-le-noyau) [Haiku a 23 ans - Haiku R1 beta 5 (partie 1 : applications)](https://linuxfr.org/news/haiku-a-23-ans-haiku-r1-beta-5-partie-1-applications) [Haiku a 23 ans - Haiku R1 beta 5](https://pulkomandy.tk/_/_/_Haiku%20a%2023%20ans%20-%20Haiku%20R1%20beta%205) ---- Documentation ============= La documentation de Haiku se dĂ©coupe en 3 parties principales : un [manuel de l’utilisateur](https://www.haiku-os.org/docs/userguide/fr/), une [documentation d’API](https://api.haiku-os.org), et une [documentation interne](https://www.haiku-os.org/docs/develop/) pour les dĂ©veloppeurs qui travaillent sur les composants du systĂšme. Ces documents sont complĂ©tĂ©s par de nombreuses pages et articles sur le site Internet, et deux livres pour [apprendre Ă  programmer en C++ avec Haiku](https://github.com/theclue/programming-with-haiku), ou encore un document de rĂ©fĂ©rence pour la conception d’interfaces graphiques et un autre pour le style graphique des icĂŽnes. Documentation d’API ------------------- [La documentation d’API de BeOS](https://www.haiku-os.org/legacy-docs/bebook/index.html) Ă©tait assez complĂšte et de bonne qualitĂ©. L’entreprise Access Co Ltd qui a hĂ©ritĂ© de la propriĂ©tĂ© intellectuelle de BeOS a autorisĂ© le projet Haiku Ă  la rĂ©utiliser et Ă  la redistribuer. Malheureusement, cette autorisation est faite avec une licence Creative Commons n’autorisant pas les modifications. Cette documentation ne peut donc pas ĂȘtre mise Ă  jour, ni pour corriger les erreurs, ni pour ajouter des informations sur toutes les nouvelles fonctions ajoutĂ©es par Haiku ou les diffĂ©rences entre les deux systĂšmes. Il est donc nĂ©cessaire de réécrire une nouvelle documentation Ă  partir de zĂ©ro. Ce travail est assez ingrat lorsqu’il s’agit de re-dĂ©crire ce qui est dĂ©jĂ  trĂšs bien expliquĂ© dans la documentation existante. La nouvelle documentation a donc tendance Ă  se concentrer sur les nouvelles fonctions, et il faut souvent jongler entre les deux documentations, le contenu des fichiers ` .h`, et des exemples de code d’applications existantes pour dĂ©couvrir toutes les possibilitĂ©s offertes. Il ne semble pas utile de lister chaque fonction ou mĂ©thode qui a Ă©tĂ© documentĂ©e. On peut mentionner une page d’explications sur la bibliothĂšque C standard, comprenant des liens vers les spĂ©cifications POSIX qui documentent dĂ©jĂ  la plupart des choses, et quelques dĂ©tails sur les diffĂ©rences avec d’autres systĂšmes. Une autre nouvelle page documente les primitives de synchronisation qui sont disponibles pour le code s’exĂ©cutant dans le noyau. Documentation interne --------------------- La documentation interne Ă©tait Ă  l’origine simplement une accumulation de fichiers dans divers format dans un dossier « docs » du dĂ©pĂŽt Git de Haiku. Depuis 2021, ces fichiers ont Ă©tĂ© rassemblĂ©s et organisĂ©s Ă  l’aide de Sphinx, qui permet de mettre Ă  disposition une version navigable en HTML et de donner une meilleure visibilitĂ© Ă  ces documents. D’autres pages sont petit Ă  petit migrĂ©es depuis le site web principal de Haiku, qui n’est pas un trĂšs bon support pour de la documentation, et bĂ©nĂ©ficiera un jour d’une refonte pour ĂȘtre plus tournĂ© vers les utilisateurs que vers les dĂ©veloppeurs. Quelques nouvelles pages ajoutĂ©es cette annĂ©e: - Une documentation sur l’utilisation de divers outils de complĂ©tion de code automatique avec le code source de Haiku - Une page prĂ©sentant l’organisation du code source et les principaux dossiers et sous-dossiers - La documentation de l’outil `rc` utilisĂ© pour compiler les « resources » attachĂ©es aux exĂ©cutables a Ă©tĂ© intĂ©grĂ©e - Le systĂšme de fichier FAT a reçu Ă©galement une page de documentation Ă  l’occasion de sa réécriture Un point sur le financement =========================== L’association Haiku inc qui gĂšre le compte en banque de Haiku publie chaque annĂ©e un [rapport financier](https://www.haiku-inc.org/documents/). Le financement provient principalement de dons des utilisateurs et soutiens de Haiku. Le projet reçoit Ă©galement une compensation financiĂšre de Google pour le temps passĂ© Ă  encadrer les participants du Google Summer of Code (voir le paragraphe suivant). La contribution de Google cette annĂ©e est de 3 300$. Les plateformes de don les plus utilisĂ©es sont Paypal et Github sponsor. Ce dernier est recommandĂ© car, pour les dons reçus via Github, c’est Microsoft qui paie les frais bancaires de la transaction. 100% de l’argent donnĂ© arrive donc sur le compte de Haiku. Tous les autres opĂ©rateurs ont un coĂ»t, soit fixe lors des retraits, soit un pourcentage de chaque don, soit un mĂ©lange des deux. En 2023, l’association a reçu 25 422$ de dons et a dĂ©pensĂ© 24 750$. Elle dispose d’une rĂ©serve confortable de 100 000$ (accumulĂ©s avant 2021, alors qu’il n’y avait pas de dĂ©veloppeur salariĂ©) ainsi que d’environ 150 000$ en cryptomonnaies. Les dons en cryptomonnaies sont pour l’instant bloquĂ©s sur un compte Coinbase suite Ă  des problĂšmes administratifs (le compte n’est pas correctement dĂ©clarĂ© comme appartenant Ă  une association, il faudrait donc payer un impĂŽt sur le revenu lors de la conversion en vraie monnaie). Il semble difficile de contacter Coinbase pour rĂ©gler ce problĂšme. Du cĂŽtĂ© des dĂ©penses, le poste le plus important est le paiement de 21 000$ Ă  Waddlesplash, dĂ©veloppeur employĂ© par Haiku inc pour faire avancer le projet Haiku. Il travaille Ă  temps partiel et avec un salaire trĂšs bas par rapport au marchĂ©, comme cela a Ă©tĂ© fait pour les prĂ©cĂ©dents contrats entre Haiku inc et d’autres dĂ©veloppeurs. Les finances de l’association ne permettent pas encore d’assurer un emploi Ă  plein temps avec un salaire correct sur le long terme (c’est faisable sur le court ou moyen terme Ă  condition de puiser dans les rĂ©serves de trĂ©sorerie). Le reste des dĂ©penses concerne principalement le paiement de l’infrastructure (serveurs pour le site Internet, l’intĂ©gration continue, hĂ©bergement cloud pour les dĂ©pĂŽts de paquets) pour environ 3 000$. Il faut enfin compter environ 500$ de frais Paypal, puis quelques dĂ©penses administratives (dĂ©claration de changement d’adresse de l’association, dĂ©claration d’embauche) pour des montants nĂ©gligeables (moins de 10$ au total). En 2024, l’objectif fixĂ© en janvier Ă©tait de rĂ©colter 20 000$ de dons supplĂ©mentaires. Cet objectif a Ă©tĂ© atteint dĂšs le mois de juillet, et a donc Ă©tĂ© rĂ©visĂ© pour tenter d’atteindre les 30 000$. Cela permettra de rĂ©munĂ©rer Waddlesplash pour un plus grand nombre d’heures cette annĂ©e, ou bien d’envisager l’embauche d’une deuxiĂšme personne si un ou une candidate se prĂ©sente parmi les personnes contribuant au projet (l’embauche d’une personne extĂ©rieure ne se fera pas tant que l’association ne peut pas se permettre de proposer une rĂ©munĂ©ration raisonnable). Google Summer of Code ===================== Haiku participe au Google Summer of Code [depuis 2007](https://www.haiku-os.org/community/gsoc/). Il s’agit d’un programme oĂč des Ă©tudiants (et d’autres participants pas forcĂ©ment Ă©tudiants, ces derniĂšres annĂ©es) sont payĂ©s par Google pendant deux mois pour dĂ©couvrir la contribution Ă  des projets de logiciels libres. Ce programme a Ă©tĂ© montĂ© par « l’Open source program office » de Google. Leur intĂ©rĂȘt est de dĂ©fendre leur image d’entreprise sympathique (bien mise Ă  mal ces derniĂšres annĂ©es, c’est devenu un gĂ©ant de la publicitĂ© en ligne et de l’aspiration des donnĂ©es personnelles), et de contribuer Ă  la richesse d’un Ă©cosystĂšme de logiciels libres dont ils bĂ©nĂ©ficient beaucoup. Cela permet aussi d’encourager des personnes Ă  s’essayer au dĂ©veloppement logiciel, facilitant indirectement le recrutement chez Google en augmentant le nombre de candidats. Ces justifications peuvent sembler hypothĂ©tiques ou trĂšs indirectes, mais elles ont convaincu Google d’attribuer un budget de quelques millions de dollars Ă  ce programme. Une Ă©quipe de Google choisit les projets de logiciel libres participants parmi de nombreuses candidatures. Chaque projet participant propose une liste « d’idĂ©es » (un peu sous la forme d’un sujet de stage) et a ensuite la responsabilitĂ© de choisir parmi les candidats qui ont rĂ©pondu Ă  cette offre (en respectant les critĂšres de non-discrimination imposĂ©es par Google ainsi que les embargos imposĂ©s par les USA), et d’assurer l’encadrement des personnes sĂ©lectionnĂ©es. Google rĂ©munĂšre les participants, et dĂ©dommage les projets participants pour le temps investi. Cette annĂ©e les dĂ©veloppeurs de Haiku encadrent cinq participants : Calisto Mathias -- Re-design de la fenĂȘtre de recherche de fichiers --------------------------------------------------------------------- Le systĂšme de fichier BFS utilisĂ© par Haiku permet l’exĂ©cution de _requĂȘtes_ (comme une base de donnĂ©es) exploitant les [attributs Ă©tendus](https://fr.wikipedia.org/wiki/Attributs_%C3%A9tendus) des fichiers, qui peuvent ĂȘtre indexĂ©s. Ce systĂšme permet de faire beaucoup de choses, et la fenĂȘtre de recherche du navigateur de fichier essaie d’en tirer parti. Cependant, l’interface rĂ©sultante est trop complexe, et peu de personnes prennent le temps de concevoir des requĂȘtes amĂ©liorant leur façon de travailler, se cantonnant aux quelques exemples fournis. L’objectif de ce projet est de refondre l’interface de cette fenĂȘtre pour obtenir quelque chose de plus intuitif, et Ă©galement d’afficher en temps rĂ©el les rĂ©sultats de la requĂȘte dĂšs qu’elle est modifiĂ©e, pour encourager les utilisateurs Ă  expĂ©rimenter avec des requĂȘtes plus complexes. Daniel Martin -- Virtualisation matĂ©rielle accĂ©lĂ©rĂ©e avec NVMM ---------------------------------------------------------------- Haiku n’est pas encore parfait, et certaines tĂąches nĂ©cessitent encore l’utilisation d’autres systĂšmes d’exploitation. Une partie des utilisateurs ont donc une configuration en double boot, ou bien lancent Haiku dans une machine virtuelle. L’objectif de ce projet est de permettre d’utiliser Haiku comme systĂšme principal, et de lancer les autres systĂšmes dans des machines virtuelles. Cela sera rĂ©alisĂ© Ă  l’aide d’un portage de NVMM, qui a Ă©tĂ© dĂ©veloppĂ© Ă  l’origine par NetBSD et Dragonfly BSD. Cette bibliothĂšque a l’avantage d’ĂȘtre bien documentĂ©e et conçue pour faciliter son adaptation vers d’autres systĂšmes. NVMM sera complĂ©tĂ©e par l’utilisation de QEMU qui pourra fournir un « front-end » Ă  cette mĂ©canique. Diego Roux -- Pilote pour les cartes sons virtuelles VirtIO ------------------------------------------------------------- Pour les personnes utilisant Haiku dans une machine virtuelle, il est intĂ©ressant d’utiliser autant que possible la famille de pĂ©riphĂ©riques VirtIO. Il s’agit de pĂ©riphĂ©riques virtuels conçus sans s’inspirer de matĂ©riel existant, et plutĂŽt pour avoir l’interface la plus simple possible entre la machine virtualisĂ©e et son hĂŽte. Haiku dispose dĂ©jĂ  d’un jeu de pilote Virtio relativement complet (rĂ©seau, stockage de masse, affichage graphique). Le but de ce projet est de complĂ©ter cet ensemble avec un pilote pour les cartes son VirtIO. trungnt2910 -- Portage de GDB ------------------------------- Haiku dispose de son propre dĂ©bugger (appelĂ© Debugger, de façon assez peu originale). Ce dernier prĂ©sente une interface graphique confortable, mais une interface en ligne de commande beaucoup plus limitĂ©e. Il souffre Ă©galement de quelques problĂšmes de performances et d’un manque de prise en charge des fichiers exĂ©cutables et bibliothĂšques compilĂ©s avec autre chose que GCC. Il est Ă©galement incapable de faire du _debug_ Ă  distance ou de s’intĂ©grer dans une interface graphique existante (par exemple au sein d’un IDE). L’objectif de ce projet est de ressusciter la version de GDB ciblant Haiku. Cette version trĂšs ancienne Ă©tait utilisĂ©e avant l’apparition du Debugger natif. Le projet est en bonne voie, le code d’interfaçage a Ă©tĂ© entiĂšrement réécrit pour s’adapter aux versions modernes de GDB, et plusieurs Ă©volutions et corrections ont Ă©tĂ© intĂ©grĂ©es dans le systĂšme de debugging de Haiku (par exemple, pour mettre en pause tous les threads nouvellement créés afin que le debugger puisse les intercepter). Zardshard -- Migration du navigateur web WebPositive vers WebKit2 -------------------------------------------------------------------- Le navigateur WebPositive utilise le moteur de rendu webKit. Actuellement, il s’interface avec ce moteur via l’API WebKitLegacy. Cette API exĂ©cute tout le moteur de rendu web dans un seul processus, et ne fournit pas les garanties d’isolation nĂ©cessaires pour les navigateurs web modernes (que ce soit en termes de sĂ©curitĂ©, ou en termes de fiabilitĂ©). L’objectif de ce projet est de reprendre les travaux dĂ©jĂ  entamĂ©s en 2019 pour migrer WebPositive vers la nouvelle API « WebKit2 », et bĂ©nĂ©ficier d’une sĂ©paration entre l’interface graphique, la communication rĂ©seau, et le rendu HTML/CSS/JavaScript dans des applications sĂ©parĂ©es. Ainsi, un crash d’un de ces composants peut ĂȘtre rĂ©cupĂ©rĂ© de façon transparente sans faire disparaĂźtre toute l’application (et les donnĂ©es non enregistrĂ©es de l’utilisateur avec). Le projet est Ă©galement en bonne voie, un navigateur de test permet dĂ©jĂ  d’afficher quelques pages ce qui montre que les bases sont en place. Il reste Ă  rĂ©gler de nombreux problĂšmes de rendu de texte, ainsi qu’à implĂ©menter la gestion des entrĂ©es (clavier et souris) pour avoir un navigateur web utilisable. Il faudra ensuite migrer WebPositive vers ces nouvelles APIs.

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