URL: https://linuxfr.org/news/haiku-est-vivant Title: Haiku est vivant Authors: needs Francois Revol, palm123, Nÿco, Benoît Sibaud, Florent Zara, NeoX, pulkomandy, Jiehong, jcr83 et giant_teapot Date: 2013年02月01日T18:47:51+01:00 License: CC By-SA Tags: haiku et beos Score: 86 Voici quelques nouvelles du monde Haiku, le système d'exploitation libre sous licence MIT, anciennement OpenBeOS (version libre de BeOS, qui fut abandonné en 2001, suite à la fermeture de la société Be, qui a également produit les BeBox). ![Haiku OS](http://upload.wikimedia.org/wikipedia/commons/4/47/Haikulogov2.png) ---- ---- #Ports ## Port [ARM](https://www.haiku-os.org/tags/arm) Le port ARM avance au niveau du noyau, l'espace utilisateur suit. Débuté lors du Google Summer of Code de 2009, le port d'Haiku sur ARM continue d'avancer et en décembre 2012, les développeurs ont annoncé que tous les éléments de l'image de base sont compilables sur ARM. Il reste cependant beaucoup de travail à accomplir et c'est pourquoi le développeur principal de la branche ARM songe à proposer un contrat à la [fondation Haiku Inc.](http://www.haiku-os.org/about/haiku_inc) pour avancer plus rapidement. ## Port [PPC Sam460ex](https://github.com/mmuman/haiku/branches/sam460ex) Un portage sur [Sam460ex](http://www.acube-systems.biz/index.php?page=hardware&pid=5), une carte à base de PowerPC embarqué, utilisée dans les AmigaOne 500, est démarré. Pour l'instant le noyau compile, le gestionnaire de démarrage le charge et lui passe la main. La suite nécessite une modification du code gérant la MMU, car elle diffère des PowerPC "Classic", les processeurs embarqués répondant à la spécification "Book E". Les progrès seront détaillés lors de l'[Alchimie X](https://linuxfr.org/news/alchimie-x-le-salon-de-la-creation-numerique). Au passage, des corrections au support OpenFirmware sont apportées pour permettre un démarrage dans QEMU, dont le firmware OpenBIOS pose quelques problèmes. ## Port [M68K](http://www.haiku-os.org/tags/m68k) Un portage sur l'architecture 68k existe mais reste peu avancé. Il s'agit surtout de tenter de supporter des machines mythiques comme l'Atari Falcon ou l'Amiga... pour le fun ! # WebPositive, le navigateur basé sur WebKit Le navigateur basé sur Webkit avance bien. Début septembre, [Adrien Destugues](http://pulkomandy.tk/) est [une nouvelle fois embauché](https://www.haiku-os.org/blog/pulkomandy/2013-08-29_working_webpositive) pour travailler cette fois-ci sur WebPositive et le portage de [WebKit](https://github.com/haiku/webkit). Ses objectifs sont : * Documenter le "Service Kit" (le composant qui gère les différents protocoles de communication : HTTP, FTP, ...) * Effectuer un travail de fond sur le port Haiku de WebKit, notamment s'assurer qu'il prend en charge le plus grand nombre possible de sites web. * Améliorations en tout genre : retravailler le moteur de recherche, ... * Mettre à jour WebKit, l'évolution rapide du moteur de rendu rend difficile la synchronisation avec le port Haiku. * Mettre en place un système de compilation automatisé de WebKit ( _buildbot_ ) afin de faciliter les mises à jour et aussi avoir un moyen aisé pour faire de la cross-compilation. Vous pouvez consulter les dépots WebKit et Haiku sur [Github](https://github.com/haiku) sur le sujet ou consulter les infos directement sur le site d'Haiku : [1](https://www.haiku-os.org/search/node/webpositive) ou [2](https://www.haiku-os.org/tags/webpositive) # Gestionnaire de paquets Fin mars, la fondation a [annoncé l'embauche de deux développeurs pour une durée de deux mois afin de travailler sur le système de paquets](http://www.haiku-os.org/blog/bonefish/2013-03-25_package_management_new_season_starts) : [Olivier Tappe](https://github.com/olta/) et [Ingo Weinhold](https://github.com/weinhold). Le système de compilation des paquets a été grandement amélioré. Le principal objectif de ces deux mois de travail était de pouvoir compiler un paquet donné ainsi que toutes ses dépendances. Ingo et Olivier avaient donné une conférence au BeGeistert 024 fin novembre 2011 a propos de l'état des paquets et de ce qu'ils prévoyaient. Le tout est disponible en vidéo sur Youtube en cinq parties : [partie 1](http://www.youtube.com/watch?v=rNZQQM5zU-Q), [partie 2](http://www.youtube.com/watch?v=bV1zOCBP_uY), [partie 3](http://www.youtube.com/watch?v=uGU5t6TMbG0), [partie 4](http://www.youtube.com/watch?v=mprRf9Yw090), [partie 5](http://www.youtube.com/watch?v=-cF0cr2xI7w). Ce qui suit est un bref résumé du travail accompli sur la gestion des paquets pour Haiku, Olivier et Ingo ont régulièrement communiqué à la communauté [l'avancement de leurs travaux](https://www.haiku-os.org/tags/package_management). Malgré la fin de leur contrat, ils ont continué d'améliorer le système de paquet à tel point qu'Ingo a été de nouveau embauché début juin par la fondation pour une durée d'au moins trois mois. ## Format des paquets et technologies utilisées ## Haiku possédait déjà un système de paquets un peu rudimentaire, mais néanmoins fonctionnel. Un des objectifs était d'améliorer son fonctionnement et lui ajouter quelques fonctionnalités essentielles, comme la gestion des dépendances. Chaque paquet Haiku était décrit par un fichier BEP, une sorte de recette de cuisine qui permettait entre autres d'indiquer les dépendances, la manière de compiler et la manière d'installer un paquet. Bien que pratique, ces fichiers demandaient du temps pour être conçus et maintenus. Pour faciliter la conception des fichiers BEP, l'idée était d'extraire un maximum d'informations des systèmes de paquets déjà existant. Plusieurs systèmes de paquet furent considérés et les EBuild de Gentoo furent retenus, en partie car ce sont de simples scripts shell. Afin de faciliter la conversion EBuild vers BEP, il a été décidé que les BEP devaient être eux aussi des scripts shell. De plus, `haikuporter` - le programme chargé de compiler un paquet à partir du BEP - alors écrit en Python devait dans l'idéal être réécrit avec Bash ou C/C++. Il s'est finalement avéré qu'il n'y avait pas de difficulté majeure à continuer d'utiliser Python pour `haikuporter`. Seule la conversion des BEP en script shell a été effectuée. Ce changement de format a aussi occasionné un changement de nom : les fichiers BEP sont dorénavant appelés 'recettes' (_recipes_ en anglais) et doivent être nommés `nom_du_paquet.recipe`. L'utilisation des EBuild de Gentoo fut abandonné, notamment car le nombre d'applications empaquetées pour Haiku est d'environ 50. ## Réorganisation du système et cross-compilation ## Afin d'avoir un système le plus cohérent possible, beaucoup de programmes dits "tiers" étaient inclus dans le dépot officiel des sources. Ces programmes sont nécessaires pour une installation basique d'Haiku, ils comprennent entre autre les outils GNU (coreutils), les classiques `grep` et `sed`, mais aussi `haikuporter`, essentiel puisqu'il permet d'installer d'autres logiciels. Néanmoins, cette manière de faire avait quelques défauts, notamment le fait d'avoir plusieurs systèmes de compilation à maintenir. C'est pourquoi il a été décidé d'enlever tous ces programmes tiers pour en faire des paquets, qui seront pré-compilés et inclus par la suite à l'image de base. ### La poule ou l’œuf ? Maintenant que le compilateur est lui aussi un paquet, un nouveau problème se pose. Sur une nouvelle architecture, comment compiler un paquet pour la première fois, alors que l'on a besoin de lui pour le compiler ? La solution utilisée est la compilation croisée (cross-compilation) : l'idée est de construire le paquet sur une autre architecture (et en n'utilisant pas forcément Haiku). ## Construction d'un paquet ## ### Une histoire de recette ### Chaque paquet est dorénavant décrit par une recette, qui est en fait un script shell avec quelques contraintes de fonctionnement. Voici un exemple simple de fichier recette, `haikuporter-0.recipe`, tout droit tiré du [dépôt git dédié aux recettes des programmes de "base"1](https://bitbucket.org/haikuports/haikuports.cross) : ```bash SUMMARY="tool for building packages from build recipes" DESCRIPTION="haikuporter drives the process of building Haiku packages from recipe files." HOMEPAGE="http://ports.haiku-files.org/wiki/HaikuPorterForPM" SRC_URI="git+https://bitbucket.org/haikuports/haikuporter.git#c2e271a220019327dc66edc24314dfb4177212b7" LICENSE="MIT" COPYRIGHT="2007-2013 Brecht Machiels et al" REVISION="1" ARCHITECTURES="any" PROVIDES=" haikuporter = $portVersion cmd:haikuporter = $portVersion " REQUIRES=" cmd:python " BUILD_REQUIRES=" " BUILD_PREREQUIRES=" " BUILD() { true } INSTALL() { haikuporterDir=$libDir/haikuporter mkdir -p $installDestDir$haikuporterDir cp -r haikuporter HaikuPorter $installDestDir$haikuporterDir mkdir -p $installDestDir$binDir ln -s $haikuporterDir/haikuporter $installDestDir$binDir } ``` À noter qu'en plus de `BUILD` et `INSTALL`, il existe une troisième action nommée `PATCH`, afin d'appliquer les éventuels patchs. Le passage du format BEP aux scripts shell a aussi été l'occasion de revoir quelques points fondamentaux du système de paquets : * Afin de rendre l'installation d'un paquet plus souple, seuls les chemins relatifs et/ou les variables du système de paquet doivent être utilisés * Toutes sortes de documentation doivent aller dans le répertoire dédié : `documentation/` * Les anciens répertoires `etc/` et `share/` doivent être répartis dans `documentation/`, `settings/` ou `data/` * Les fichiers d'en-tête auparavant situés dans `include/` sont déplacés dans `develop/headers/` * Enfin, les bibliothèques de développement sont placées dans `develop/lib/` Pour les curieux, consultez [l'organisation des répertoires utilisée pour Haiku](http://dev.haiku-os.org/wiki/PackageManagement/DirectoryStructure). À noter qu'il est possible de générer plusieurs paquets à partir d'une recette, par exemple générer un programme et sa documentation dans deux paquets distincts. (1) : Ce dépôt contient les recettes pour les programmes de base, c'est-à-dire absolument nécessaires pour faire fonctionner une installation d'Haiku. C'est pourquoi ils doivent avoir le moins possible de dépendances. Par exemple, la recette pour le programme `grep` de ce dépôt n'est pas la même que pour le `grep` classique. ### Compilation ### Le paquet est ensuite construit par `haikuporter` dans un environnement chrooté. Tout les outils nécessaires à la compilation du programme sont installés dans cet environnement. Bien que `haikuporter` soit écrit en Python, il n'y a pas eu de difficulté particulière pour mettre en place un environnement chrooté. ## Gestion des paquets ## Pour gérer les paquets d'un système, un démon a été conçu. Ce tout nouveau programme a plusieurs missions : * Il doit gérer les paquets activés ou désactivés * Il doit veiller sur les fichiers utilisés par les différents paquets. * Il se charge de résoudre les dépendances et de détecter les conflits lors de l'installation ou la suppression de paquets. Le dernier état des lieux concernant ce démon précise que toutes les fonctionnalités prévues n'ont pas encore été implémentées. ### Tout est (système de) fichier ### L'originalité de cette nouvelle gestion de paquets tient surtout à la façon dont leur contenu est publié. En effet, un `packagefs` monté au dessus de certaines parties de l'arborescence publie dans le système de fichier le contenu agrégé des paquets activés. Ce changement ne s'est pas effectué sans problème. En effet, une partie importante de l'arborescence est maintenant en lecture seule, imposant de corriger de nombreux scripts, ainsi que certaines applications mal élevées se permettant d'écrire dans leur répertoire d'installation, ce qui est traditionnellement possible sous BeOS qui ne supportait pas le fonctionnement multi-utilisateurs. Il a été tenté d'introduire des répertoires `non-packaged/` par ailleurs dont le contenu serait superposé par `packagefs` au contenu des paquets mais les performances étaient dégradées significativement. Certains débats sont encore en cours, concernant notamment le répertoire [/boot/common](http://www.freelists.org/post/haiku-development/Removing-bootcommon), qui était l'équivalent de /usr mais a été supprimé, alors qu'il n'existait pas sous BeOS. La sortie de la commande `df` : ``` ~/Desktop> df Mount Type Total Free Flags Device --------------- -------- --------- --------- ------- -------------------------- /boot bfs 299.7M 147.4M QAM-P-W /dev/disk/ata/0/master/raw /boot/system packagefs 4.0K 4.0K QAM-P-- /boot/home/config packagefs 4.0K 4.0K QAM-P-- ``` Il reste à savoir si cette idée originale passera à l'échelle, en tout cas c'est une manière originale d'installer un paquet ! # Optimisations de l'[ordonnanceur](https://github.com/pdziepak/Haiku/tree/scheduler) # Paweł Dziepak, qui a rejoint l'équipe des contributeurs Haiku durant l'édition 2012 du Google Summer of Code en contribuant un client NFSv4, est embauché par Haiku, Inc. pour améliorer l'ordonnanceur utilisé par Haiku. Il s'agit d'un élément important du système, la gestion des priorités des threads permettant de rendre Haiku plus réactif et plus rapide. Les différents objectifs sont: * Verrouillage des threads sur un coeur de processeur, autant que possible, afin de mieux utiliser le cache de niveau 1, * Répartition de la charge sur différents coeurs en tenant compte de la topologie, ce qui permet de diminuer la consommation électrique en désactivant ou ralentissant les coeurs non nécessaires, et d'augmenter les performances en utilisant au mieux les caches partagés entre coeurs (cache L1 avec HyperThreading, cache L2 unifié entre plusieurs coeurs). * Découpage plus fin des verrous pour les structures utilisées par l'ordonnanceur pour la gestion des threads. Il publie régulièrement sur son [blog](http://www.haiku-os.org/blog/pawe%C5%82_dziepak) à ce sujet. D'autre part, Julian Harnath a réalisé plusieurs améliorations sur l'implémentation des ports de communication (une des [[IPC]] natives) pour également réduire les [problèmes de blocage](http://dev.haiku-os.org/ticket/8007) qui rendaient Haiku difficilement utilisable avec une charge processeur trop élevée. Il poursuit son travail avec des améliorations au niveau du Media Kit, afin de diminuer la latence constatée sur le traitement temps réel du son avec l'implémentation actuelle.

AltStyle によって変換されたページ (->オリジナル) /