Haiku a 17 ans

56
18
août
2018
Haiku

Les années passent, et Haiku est toujours là !

Le projet, inspiré du système d'exploitation BeOS, a démarré le 18 août 2001, avec le fameux message « So, let’s start » (« Bon, allons‐y ») sur sa liste de discussion. Alors nommé OpenBeOS, le projet avait été créé peu après l’annonce du retrait de Be du marché des ordinateurs de bureau.

Cet anniversaire est l’occasion de faire le point sur les progrès de Haiku cette année (en l’absence de nouvelle version publiée depuis la version alpha 4 en 2012, il faut bien trouver un prétexte pour donner des nouvelles de temps en temps).

Sommaire

Présentation de Haiku

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 multi‐thread (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.

Cependant, 17 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. Cet objectif initial n’a donc pas été atteint en temps utile.

Cependant, Haiku reste un projet pertinent aujourd’hui, car aucun système libre n’a vraiment pris la place que BeOS a libéré (dit autrement, non, ce n’est toujours pas l’année de GNU/Linux sur le Desktop).

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 d’un problème d’implémentation côté Haiku ;
  • elle permet enfin d’expérimenter les difficultés à maintenir pendant plus de 15 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.

Cependant les désavantages (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 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.

Toujours pas de version bêta

La dernière version publiée par Haiku est la version R1 alpha 4.1, qui date de novembre 2012. De très nombreux progrès ont été faits depuis, et en particulier un gros chantier sur l’infrastructure d’hébergement du projet permettant de mettre en place un dépôt de paquets pour tous les utilisateurs (ce sera l’une des grosses nouveautés de la prochaine version R1 bêta 1).

Si on avait su que cela prendrait autant de temps, on se serait probablement organisé autrement, afin de pouvoir publier quelques versions alphas supplémentaires et faire patienter les gens. Pour l’instant, il vaut vraiment mieux télécharger un « nightly build » pour essayer Haiku.

Nouveautés de l’année

Corrections de bogues

Il y en a beaucoup trop pour les détailler. Haiku est de plus en plus stable. Le portage d’applications venues d’autres systèmes, et la mise en place de machines fonctionnant sous Haiku pour la compilation des paquets présents dans les dépôts a permis (même si ce n’était pas le but initial) de tester le système de façon beaucoup plus intense. De nombreux problèmes difficiles à reproduire ont ainsi pu être plus facilement identifiés, puis résolus.

La compatibilité POSIX s’améliore, le noyau fait de plus en plus de vérifications pour éviter les « panics » lors d’appels systèmes avec des paramètres invalides.

Un bogue mérite une mention spéciale, la méthode Split() permettant de découper une chaîne de caractères à l’endroit où elle contient un séparateur ne fonctionnait pas correctement. Il est surprenant que ce problème n’ait jamais été détecté auparavant.

Nous avons également corrigé plusieurs problèmes d’alignement de la pile (dans le fil d’exécution principal, les handlers de signaux, et dans le noyau) qui empêchaient l’utilisation fiable d’instructions SSE2. Le problème a été mis en évidence au départ dans le navigateur web, il a donc fallu creuser assez loin dans le système pour le corriger !

Infrastructure

Le vénérable serveur baron, qui hébergeait l’ensemble des services de Haiku (système de suivi, dépôts Git, site Web…) depuis fin 2009 est en train d’être mis à la retraite.

Il est remplacé par maui, un serveur plus récent, qui utilise des conteneurs docker plutôt que des machines virtuelles pour isoler les différents services.

C’est une opportunité pour revoir entièrement la façon de gérer le serveur. Baron était administré principalement par une personne qui faisait les changements directement. Mais avec le temps, de plus en plus de services ont été mis en place et il devenait trop difficile pour une seule personne de tout suivre. Le nouveau serveur est configuré à partir de dockerfiles qui peuvent donc être relus et modifiés par plusieurs personnes.

D’autre part, un gros changement est le déploiement de Gerrit pour la revue de code. Précédemment, les contributeurs attachaient des correctifs dans leurs rapports de bugs et la revue était faite à partir de ces fichiers, ce qui est assez peu pratique. Gerrit permet de faire une revue plus facilement, et il est donc également utilisé par les développeurs (qui pourraient directement envoyer leurs changements sur la branche principale du dépôt Git) pour obtenir une relecture de leurs changements.

En ce qui concerne l’hébergement des dépôts de logiciels, nous avons enfin tout mis en place pour compiler automatiquement les logiciels à partir de recettes fournies par le projet haikuports. Un système de miroirs est en train de se mettre en place, avec pour l’instant deux serveurs situés aux États‐Unis et en Nouvelle‐Zélande (en plus du serveur principal situé en Allemagne).

Les paquets binaires sont donc rapidement disponibles dans HaikuDepot (le gestionnaire de paquets de Haiku) dès la publication des recettes permettant de les construire.

Pilotes de périphériques

Comme pour n’importe quel système d’exploitation, un point délicat est de pouvoir fonctionner correctement sur le plus d’ordinateurs possibles. Cela passe par l’écriture de pilotes pour tous les périphériques.

C’est donc une partie de Haiku qui est assez active et il serait difficile de recenser précisément tous les changements intervenus dans l’année. Mentionnons quand même le support des boutons « étendus » pour les pavés tactiles Synaptics et un début de support de leur « clickpad » ; la possibilité d’utiliser une imprimante connectée sur un port série; des évolutions sur les pilotes graphiques Intel et Radeon pour prendre en charge plus de versions du matériel; et de petites améliorations sur le pilote de cartes son hda (qui est utilisé sur tous les ordinateurs à base de chipset Intel).

Mise à jour des pilotes réseau

Pour gagner du temps, Haiku réutilise les pilotes développés pour FreeBSD via une couche de compatibilité.

Jusqu’à l’année dernière, les pilotes de FreeBSD 9 étaient utilisés, mais aujourd’hui nous utilisons ceux de FreeBSD 11. Cela augmente le nombre de cartes réseau prises en charge et corrige de nombreux problèmes d’instabilité de la connexion.

D’autre part, un gros travail a été fait sur la pile TCP pour compléter l’implémentation de diverses RFC permettant d’obtenir de meilleures performances.

Prise en charge de l’USB 3

Le pilote xHCI est maintenant fonctionnel sur la plupart des machines, même s’il ne fonctionne pas encore parfaitement. Cela devenait nécessaire, car de plus en plus d’ordinateurs ne proposent plus du tout de ports USB 2.

Pilotes VirtIO

Les pilotes VirtIO sont maintenant pleinement fonctionnels. VirtIO est un bus utilisé par des machines virtuelles pour remplacer certains périphériques et éviter d’émuler un matériel réel. En utilisant une interface simplifiée, l’écriture des pilotes est facilitée et les performances sont meilleures.

Haiku peut maintenant utiliser les cartes réseau, le « ballonnement » de la mémoire (mémoire vive qui peut être redimensionnée en fonction des besoins de l’hôte et des machines émulées), et le stockage de masse sur VirtIO.

Mise à jour du navigateur Web

Le navigateur fourni avec Haiku est basé sur un portage de WebKit. Nous avions l’an dernier un an et demi de retard sur la version de WebKit en amont. Nous avons rattrapé une partie de ce retard puisque nous utilisons aujourd’hui une version datant de janvier 2018.

Ceci permet d’accéder à des sites Web modernes, même si de nombreux problèmes subsistent au niveau du rendu ainsi que de l’implémentation du protocole HTTP (moins simple qu’il n’y paraît à mettre en œuvre correctement).

En attendant, les navigateurs Qupzilla et Otter browser, en Qt, permettent de visiter certains sites que WebPositive, le navigateur natif, ne parvient pas encore à traiter.

Media Kit

Le Media Kit prend en charge tous les aspects multimédia (audio et vidéo, principalement) dans Haiku. Il permet aux applications d’exposer des nœuds qui sont connectés dans un graphe, un peu à la façon de Jack ou GStreamer sous GNU/Linux.

Ajout du BMediaClient

L’écriture de nœuds média demande beaucoup de travail répétitif et inutilement complexe. Une nouvelle classe BMediaClient a donc été introduite qui propose de prendre en charge la plupart de cet effort et donc de proposer une interface plus simple à aborder aux développeurs.

Passage à FFmpeg 4

Haiku utilisait encore pour sa version GCC 2 une version 0.10 de FFmpeg, car il était impossible de compiler des versions plus récentes. Cela empêchait l’utilisation des API modernes de FFmpeg et commençait à poser problème pour la prise en charge de formats de fichiers récents.

La solution mise en place consiste à compiler ffmpeg avec GCC 7, mais à faire l’édition de lien de façon compatible avec GCC 2. Pour l’instant, cela semble fonctionner dans ce cas précis. Nous allons donc pouvoir moderniser le greffon de décodage audio et vidéo basé sur FFmpeg, qui traite dans Haiku la plupart des formats de fichiers.

Gestion du mode hybride 32/64 bits

La version 64 bits de Haiku ne peut actuellement pas exécuter d’applications 32 bits. Il est probable que la version 32 bits soit un jour complètement abandonnée, mais pour cela il faudra proposer une solution pour que les utilisateurs puissent migrer vers la version 64 bits en conservant leurs applications.

La gestion de l’exécution des applications 32 bits sur un noyau 64 bits est donc un des chantiers en cours. Cela pose un certain nombre de problèmes au niveau de l’interface entre le noyau et l’espace utilisateur, les appels systèmes devant traiter les données dans le bon format selon l’application utilisée.

La première étape déjà franchie est l’intégration de SMAP et SMEP, qui permettent de s’assurer que le noyau n’accède pas par erreur aux données en espace utilisateur (la protection dans l’autre sens étant déjà assurée par la MMU). On a pu grâce à cette vérification clairement identifier tous les endroits ou de tels accès sont effectués, ce qui permettra de repérer facilement s’il est nécessaire ou pas de faire une conversion 32 <=> 64 bits. De plus, on gagne en sécurité puisqu’il sera plus compliqué pour une application d’utiliser un appel système de façon détournée pour lire ou écrire dans la mémoire du noyau.

Passage à GCC 7

Haiku dans sa version 32 bits est fourni avec deux compilateurs, une version 2.95.3 de GCC qui permet d’assurer la compatibilité binaire avec BeOS, et un GCC plus récent permettant de compiler les applications modernes (la version 64 bits de Haiku n’assure pas pour l’instant de compatibilité, et donc fournit uniquement une version moderne de GCC).

L’année dernière, la version « moderne » utilisée était GCC 5.4. Nous utilisons maintenant la version 7.3. La migration a été l’occasion de corriger quelques bogues dans Haiku qui l’empêchaient de démarrer avec les nouvelles optimisations proposées par GCC.

Le travail est déjà en cours pour le passage à GCC 8, qui lève de nouveaux warnings (une grande partie de Haiku est bien entendu compilée avec le drapeau -Werror, donc les warnings ne sont pas admis).

Le retour de Cosmoe

Cosmoe est un projet consistant à porter l’espace utilisateur de Haiku sur un noyau Linux ou BSD. Il n’a jamais abouti à quelque chose de fonctionnel, mais plusieurs développeurs (impliqués dans Haiku ou pas) ont repris le projet de temps en temps pour y faire quelques mises à jour.

Cette fois, le projet a été repris par Dario Casuolinovo alias Barrett, qui a travaillé sur Caya (notre client de messagerie instantanée) et sur le Media Kit de Haiku. Son travail sur le Media Kit l’a convaincu que le noyau utilisé dans Haiku n’était plus pertinent aujourd’hui et qu’il valait mieux l’abandonner pour quelque chose d’autre. Nous verrons si Cosmoe arrive à percer cette fois‐ci.

Les membres du projet Haiku pensent que leur noyau reste pertinent (pour diverses raisons, en particulier le fait qu’il est écrit en C++ et qu’il offre une ABI stable pour les pilotes de périphériques) mais sont heureux de voir émerger d’autres projets inspirés par BeOS.

LibreOffice pour Haiku

Ça y est ! après plusieurs tentatives (quand on a commencé, le projet s’appelait encore OpenOffice…), nous avons enfin une version de LibreOffice pour Haiku.

Cela a été rendu possible par le gros travail chez LibreOffice pour simplifier leur système de compilation, et également par le système de paquets de Haiku qui a permis de capitaliser et de mutualiser le portage des dépendances de LibreOffice.

Bien qu’une grande partie des efforts a été faite pour avoir une version native, c’est finalement l’apparition d’un back‐end Qt dans LibreOffice qui a permis d’avoir une version fonctionnelle le plus rapidement.

La disponibilité d’une suite bureautique moderne est un point important, d’une part parce qu’on peut maintenant présenter Haiku sérieusement comme un système utilisable pour faire un peu de bureautique et de navigation Web, et d’autre part parce que LibreOffice remplace GoBe Productive, l’une des dernières applications BeOS non libres et encore utilisées (la prochaine sur la liste est Sync Modular — avis aux volontaires). On peut donc commencer à envisager plus sereinement l’abandon de la compatibilité binaire avec BeOS.

D’autres langages de programmation

Le langage Rust est à la mode, il était donc indispensable d’avoir une version pour Haiku et c’est maintenant chose faite. Rust 1.28 contient tous les correctifs nécessaires pour compiler directement sur Haiku, sans modifications.

Mentionnons aussi une version de Swift qui est arrivée cette année, la prise en charge de Fortran disponible par défaut dans GCC, et des progrès pour avoir une version de Free Pascal complètement opérationnelle. Ceci, bien sûr, en plus de tous les langages qui fonctionnaient déjà très bien auparavant : Python 2 et 3, Lua, Perl, C, C++ et de nombreux autres.

Java et Go ont été disponibles quelque temps, mais ont disparu des dépôts lors de l’automatisation des builds. L’ancien paquet pour Java 7 fonctionne, la version de Java 8 disponible plante au démarrage, et il n’y a pas encore eu de tentative pour les versions suivantes. Du côté de Go, une version assez ancienne était fonctionnelle, mais il est maintenant impossible de la compiler, car les sources référencent des dépôts hébergés par code.google.com, maintenant fermé. Avis aux volontaires pour remettre tout ça en route.

Enfin, il semble utile de présenter yab, une divergence de yabasic qui permet de développer des applications graphiques pour Haiku. Il n’était plus vraiment maintenu, mais quelques développeurs l’utilisant se sont un peu mis au C++ pour faire les évolutions nécessaires. Il est maintenant disponible dans les dépôts, l’interpréteur étant distribué sous forme d’une bibliothèque partagée qui peut être utilisée par tous les programmes écrits en yab.

Prise en charge de l’UEFI

Il est maintenant possible d’installer Haiku sur une machine UEFI. Actuellement ce n’est pas intégré dans les « nightly builds » générés par nos buildbots, il s’agit d’une image séparée contenant uniquement un chargeur de démarrage UEFI. Plus tard, ce sera intégré aux images « anyboot » (qui disposent également d’un MBR pour démarrer depuis une clé USB, et d’un chargeur « el torrito » pour démarrer quand elles sont gravées sur un CD).

Améliorations de l’interface utilisateur

Là encore, beaucoup trop de changements pour tous les lister, mais les applications fournies avec Haiku ont vu de nombreux petits changements. Cela va du comportement des menus ouverts trop près du bord de l’écran, à une meilleure prise en charge des écrans haute résolution (il suffit de choisir une taille de police de caractères appropriée, le reste de l’interface doit s’adapter en fonction).

Launch Daemon

Le Launch Daemon est chargé de l’exécution des services, et du séquençage du démarrage et de l’arrêt du système.

Les évolutions cette année portent sur la gestion des logs, une réécriture de la procédure d’arrêt pour éviter d’éteindre la machine avant que l’utilisateur ait pu enregistrer tous les changements dans des applications ouvertes (dans certains cas tordus). Il reste néanmoins bien plus léger que systemd.

Évènements et conférences

Comme chaque année, Haiku était présent au FOSDEM, au Capitole du Libre, aux JDLL et aux RMLL. L’occasion de donner plusieurs conférences, de rencontrer les développeurs d’autres projets et d’en profiter pour porter quelques logiciels vers Haiku avec l’aide des contributeurs principaux (mentionnons cette année Poezio, Dead Ascend, ou encore le Godot Engine, qui avait déjà un portage mais non maintenu). Nous avons également pu constater lNincompatibilité de Haiku avec les machines Purism Librem, sans avoir le temps de se pencher de plus près sur la question, malheureusement.

La conférence BeGeistert, qui regroupe depuis très longtemps les utilisateurs et développeurs de Haiku (et de BeOS et Zeta), a pris une pause cette année, l’équipe organisatrice n’ayant plus la motivation pour s’en occuper étant donné le peu de personnes présentes.

Le projet Haiku mettait à profit cette conférence pour organiser un « coding sprint », qui consiste à mettre le plus grand nombre possible de développeurs dans une salle de réunion pendant cinq jours avec un stock approprié de sodas, et une cantine et des lits à disposition. Le coding sprint étant un moyen étonnamment efficace de faire avancer les choses, nous avons décidé de le maintenir, et de l’organiser cette année juste après le Capitole du Libre, à Toulouse. Le changement de lieu a été plutôt apprécié par les développeurs présents, qui ont pu en particulier travailler sur le portage de LibreOffice, des corrections de bugs dans le navigateur web, l’amélioration de l’application HaikuDepot (le gestionnaire de paquets graphique) pour régler divers problèmes de performance et faire quelques améliorations cosmétiques, ou encore ajouter le réglage de la luminosité de l’écran sur les PC portables utilisant un chipset vidéo Intel.

Bonne nouvelle, après cette année sans BeGeistert, l’évènement sera de retour en octobre prochain. Nous retournerons en Allemagne mais nous quitterons Düsseldorf, dont l’auberge de jeunesse qui nous a souvent accueilli n’offre plus des tarifs accessibles pour le budget de HSA (l’association qui finance l’évènement). Le format retenu est un évènement sur quatre jours, le détail sera décidé par la suite, sans doute un intermédiaire entre une conférence (avec quelques présentations) et un coding sprint.

GCI et GSoC

Haiku candidate tous les ans au Google Code‐In et au Google Summer of code.

Google Summer of Code

Il s’agit d’un programme organisé par Google dont le principe est de payer des étudiants pour qu’ils puissent travailler à plein temps sur des projets libres. Les membres de chaque projet s’occupent de l’encadrement, et ont toute liberté dans les sujets proposés.

Haiku a accueilli trois étudiants cette année, travaillant sur le système de fichiers XFS (mais cela n’a pas donné grand‐chose), un pilote pour les périphériques SDHCI (lecteurs de cartes SD sur de nombreuses plates‐formes ARM et certains portables x86), et un client graphique pour Git intégré dans le système de suivi (largement inspiré de TortoiseGit sous Windows). Les deux derniers projets sont en bonne voie.

Google Code‐In

Code‐In, quant à lui, cible les enfants de 13 à 17 ans, le but étant de leur faire découvrir le logiciel libre et plus généralement le développement de logiciels.

Il s’agit d’un concours où les participants doivent compléter différentes tâches assez simples proposées par un projet libre. Chaque projet choisit ensuite deux gagnants qui pourront passer une semaine à San Francisco, assister à des conférences de personnes travaillant chez Google, et obtenir de nombreux auto‐collants, T‐shirts, et autres goodies.

Haiku participe tous les ans depuis la création du Google Code-In en 2010. Cela nécessite un investissement important de toute la communauté autour du projet, en effet il n’est pas facile de gérer l’arrivée massive des participants sur les canaux IRC et listes de diffusion du projet. Cependant, l’habitude est prise et l’organisation est un peu meilleure chaque année.

Les tâches proposées sont diverses, on trouve des choses techniques (par exemple porter et packager un logiciel pour Haiku), graphiques (concevoir un autocollant à distribuer lors des conférences ou un poster présentant Haiku), de la documentation, ou encore du test (trouver des bugs dans un logiciel, écrire un plan de test, vérifier si des bugs reportés dans le passé sont toujours présents), et enfin une catégorie « outreach » (par exemple, préparer une présentation sur Haiku et la présenter à d’autres élèves, ou encore faire une vidéo présentant une fonctionnalité particulière).

L’intérêt principal de ces deux programmes est l’accueil de nouveaux contributeurs et l’amélioration de la diversité de notre équipe, en effet la communication de Google et des différents projets participants permet de faire découvrir Haiku à des personnes qui ne seraient pas autrement venues contribuer.

On ne compte plus vraiment sur ces projets pour faire avancer les choses directement : le temps nécessaire pour l’encadrement dépasse largement le temps qu’un développeur expérimenté aurait utilisé pour faire le travail directement. Cependant l’expérience est intéressante et nous permet aussi d’améliorer notre documentation et notre façon de travailler pour être plus accueillants aux nouveaux contributeurs.

Aller plus loin

  • # Content, enfin presque :)

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

    C'est toujours bon de voir Haiku qui bouge, y compris la petite échauffourée de la semaine passée sur la ML ;)
    J'attends de pouvoir enfin booter Haiku ailleurs que dans une VM, parce que pour le moment sur mes machines physiques, c'est un échec (après je n'ai pas des machines faciles - un asus n73 et un acer aspire switch 10, Linux à eu parfois du mal aussi, surtout sur le dernier)
    J’investiguais bien un peu plus, mais ce sont des machines qui me sont utiles au quotidien, je ne peux me permettre de les rendre indisponibles.

    Pour revenir sur Cosmoe, je me demandais, comment assure t'on la greffe du user-land sur un autre kernel sans tout casser dans les APIs ? POSIX est une explication partielle seulement. Et Haiku n'a pas, il me semble, la notion de window manager aussi profonde que Xorg.
    En tout cas à défaut de voir Haiku enfin démarrer sur un de mes raspberry pi, son user-land serait certainement appréciable de par sa légèreté :)

    Coté drivers, le choix des drivers FreeBSD est il suffisant ou est il envisagé un jour d'ouvrir un pont vers les drivers Linux ? Des questions de licences peut être ?

    • [^] # Re: Content, enfin presque :)

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

      Pour Cosmoe, une partie du code devra être modifiée pour fournir les mêmes APIs de façons différente. Par exemple, les BMessages et une grande partie du Media Kit sont implémenté dans Haiku via les "ports", une IPC qui n'existe pas dans POSIX. Mais il est possible de réaliser la même chose en utilisant d'autres IPCs. On est curieux de voir ce que cela donnera au niveau des performances.

      D'autres choses sont et resteront impossibles sur un noyau Linux, par exemple la possibilité d'ouvrir un fichier en connaissant uniquement son numéro d'inode (ce qui est possible dans l'API de BeOS mais un gros trou de sécurité).

      La notion de window manager est plus ou moins présente. Il ne s'agit pas d'un exécutable séparé, mais plutôt d'un add-on du serveur graphique (appelé "decorator"). Cela dit, l'un ou l'autre choix est valable et n'a pas vraiment d'influence sur l'API publique.

      Pour les drivers, en dehors du problème des licences, les deux gros soucis du côté de Linux sont que le code est souvent assez peu lisible (peu de commentaires, etc), et que les API internes ont tendance à beaucoup changer d'une version à l'autre. FreeBSD est, en comparaison, relativement stable, ce qui nous permet de suivre plus facilement leurs évolutions.

      On regarde quand même du côté de Linux, par exemple pour les drivers graphiques. Supposément, Gallium3D permet d'avoir des drivers en userland, portables d'un OS à l'autre, mais ça n'a pas l'air d'avoir vraiment marché comme ça. On va peut-être s'inspirer de ce qu'on fait FreeBSD ou DragonFlyBSD pour récupérer les pilotes Linux.

      En ce qui concerne les licences, d'une part, certains pilotes Linux sont sous licence BSD, ce qui nous va très bien (par exemple pour les cartes graphiques Intel, il me semble). D'autre part, même si un pilote est sous GPL, il peut être compilé indépendament du noyau et installé séparément, donc ce ne serait pas forcément un problème (l'avantage d'avoir une ABI propre et stable pour les pilotes de périphériques ;) ).

  • # Avenir de Haiku

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

    J'ai pu m'entretenir de ce sujet avec François Revol aux RMLL à Strasbourg. Faire Haiku est un challenge remarquable mais malgré tout, je me pose encore des questions : Si l'objectif de faire fonctionner des logiciels conçus pour BeOS est maintenant à peu près atteint, quel sera l'objectif suivant ? Quelle sera la feuille de route ?

    • [^] # Re: Avenir de Haiku

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

      Je vais répondre en reprenant la description présente sur le site de Haiku:

      Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.

      L'objectif est donc de fournir un système open source, taillé spécialement pour l'informatique personelle (on entend par là: pas les smartphones, pas l'embarqué, et pas les serveurs). On le voudrait rapide, simple à utiliser et à apprendre, mais cependant puissant (que je traduirait plutôt par flexible).

      Un certains nombres de contributeurs à Haiku ne croient pas à "Linux sur le Desktop". Les contraintes sont différentes entre un système embarqué, un serveur, et un PC de bureau, et il nous semble difficile d'arriver à répondre à tous ces besoins à la fois de façon optimale. L'adaptabilité d'un système GNU/Linux à tous ces marchés le force à faire des compromis pour aller plus dans un sens que dans un autre. Et actuellement, on a avec Android des gens qui poussent le support des smartphones, et avec RedHat des gens qui poussent plutôt le côté serveurs. Il y a Ubuntu qui essaie de s'attaquer au segment du desktop, mais je ne sais pas si ça durera encore longtemps. Visiblement leur succès n'a pas été aussi grand qu'attendu.

      Il y a donc toujours une place pour un système libre sur ce marché.

      Maintenant, la question qui fache, c'est comment on s'y prend pour arriver à prendre cette place avec Haiku. On va avoir besoin de faire évoluer encore plein de choses. Certaines ne posent pas vraiment question, par exemple, il va falloir mettre des efforts sur l'accélération 3D, un meilleur support des imprimantes, améliorer encore le port de LibreOffice. Mais à un peu plus long terme, on a un gros travail à faire pour prendre des décisions importantes pour la version "R2" de Haiku. Quelques exemples: doit-on remplacer les APIs de BeOS par celles de Qt (éventuellement avec quelques extensions)? Combien de temps va-t-on encore s'embêter à maintenir une version à base de gcc2 pour faire fonctionner les applications BeOS? Comment procèdera-t-on pour faire une transition en douceur? Jusqu'à quel point doit-on assurer la maintenance des vieilles applications BeOS? Doit-on conserver le système de fichiers BFS, essayer d'utiliser un système concurrent (par exemple ZFS, XFS ou btrfs), ou bien doit-on développer notre propre système de fichiers pour conserver les particularités de BFS (en particulier l'indexation des attributs étendus)? Jusqu'à quel point doit-on encourager le portage et l'intégration d'applications Qt et est-ce qu'il ne vaudrait pas mieux pousser les gens à écrire des applicatons natives?

      Pour l'instant, ces sujets n'ont pas vraiment été abordés. La priorité est d'arriver à faire une version R1, et ensuite de voir si on arrive à construire un écosystème d'applications autour de notre OS. Si vous avez déjà vu ce qu'on démontre sur notre stand, il y a beaucoup d'idées intéressantes (gérer les mails ou une collection de medias avec des attributs étendus, par exemple), mais souvent on fait ça sous forme de démo bricolée avec le navigateur de fichier. La technologies est là mais ça manque souvent d'une interface utilisateur vraiment bien pensée, et au final personne n'utilise vraiment toutes ces belles fonctions. Je pense que le gros du travail va se trouver là dans les années à venir. Et une fois qu'on aura plein d'applications modernes, on aura un peu plus de recul sur les évolutions à apporter à l'API (même si on a déjà quelques idées).

      Voilà, c'est ma vision des choses. Cependant j'en ai pas forcément beaucoup discuté avec tous les autres contributeurs du projet, et nous n'avons donc pas forcément fait converger nos idées sur ces différents points, pour l'instant.

  • # Logiciels disponibles

    Posté par  . Évalué à 4.

    Bonjour,
    Tout d'abord, félicitation pour continuer à développer HaikuOS après tout ce temps ! Vouloir se faire une place sur le marché de l'OS de bureau est louable, cependant par le passé, on a constaté qu'une des clefs principales de la popularité d'un OS auprès des utilisateurs finaux est la quantité d'applis disponibles. Vis-à-vis de ça, comment comptez-vous obtenir une quantité respectables de logiciels modernes pour attirer les gens ? En montant une forge qui compilera les logiciels libres pour BeOS ? En faisant une couche de compatibilité avec les logiciels GNU/LInux ? Ou en espérant que des développeurs soient intéressés pour créer des logiciels pour HaikuOS ?

    Emacs le fait depuis 30 ans.

    • [^] # Re: Logiciels disponibles

      Posté par  . Évalué à 3.

      Si c'est pour faire une couche de compatibilité pour attirer des utilisateurs, j'irais plutôt vers un portage de Wine.

      Il y a plus d'utilisateurs derrière Windows que derrière Linux…

    • [^] # Re: Logiciels disponibles

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

      Le projet HaikuArchives essaie de récupérer le code source d'un grand nombre d'applications pour BeOS. On assure la maintenance de ces applications mais pour les tenur vraiment à jour ce serait un travail beaucoup plus important, donc on fait le minimum pour l'instant…

      En parallèle, on a des applications Qt qui sont portées avec une assez bonne intégration (c'est ce qui nous permet d'avoir LibreOffice, par exemple). Mais ces applications ne sont pas "natives", et ne s'intègrent jamais parfaitement dans l'environnement de Haiku, donc on les considère comme une étape de transition, ça permet de combler les trous quand une application native pour Haiku n'existe pas encore.

      On pourrait faire la même chose avec GTK, mais pour l'instant on considère plus important le travail sur l'OS et les applications natives.

      • [^] # Re: Logiciels disponibles

        Posté par  . Évalué à 3.

        C'est chouette d'essayer de maintenir les logiciels BeOS mais … ils ne sont pas légèrement dépassés après 17 ans ? Ca risque de ne pas trop attirer de nouveaux utilisateurs, au contraire :/
        Et du coup, le but c'est d'avoir de nouveaux logiciels développés avec les API de BeOS ? Comment comptez-vous attirer de nouveaux devs sur cette plateforme ? Avec peu d'utilisateurs, ca ne pas intéresser la plupart d'entre eux.

        Emacs le fait depuis 30 ans.

        • [^] # Re: Logiciels disponibles

          Posté par  . Évalué à 5.

          AMHA ça permet de trouver un endroit où tout reste à faire. Loin des vieux BSD, Linux, Windows ou MacOS où tout a déjà était fais ou tenté. Haïku est terre en friche où pleins de choses restent à faire. Une conquête de l'ouest pour développeur. Le fait qu'il possède quelques concepts différents d'unix et qu'il s'adresse uniquement au bureau lui confère un aspect particulier bien à lui. Ça lui permet de faire des choix différents. Il y a quelques années Linus avait du trancher entre 2 ordonnanceurs de tâches, il a choisi celui qui est fait par un contributeur payé plutôt que celui qui se vanter d'être plus efficace sur informatique personnelle (là où appartement celui qui a était choisi était très bon à partir d'un grand nombre de CPU). Pour trouver des infos, il s'agissait de BFS.

          • [^] # Re: Logiciels disponibles

            Posté par  . Évalué à 2.

            Pour la partie OS j'avais bien compris l'intérêt de HaikuOS de ce point de vu là, qu'on retrouve aussi chez ReactOS. Je trouve même super de continuer à développer des OS différents, la diversité n'étant pas forcément une mauvaise chose à mon sens.
            Ma question se portait vraiment sur les logiciels et l'augmentation de la base d'utilisateurs. Pour le moment, je ne pense pas que beaucoup d'utilisateurs finaux se retrouvent dans HaikuOS, même parmi les libristes (j'ai pas dit aucun non plus hein)

            Par contre effectivement, je l'avais pas vu de ce point de vu là pour le développement de logiciels. C'est vrai que vu comme ça, c'est carrément intéressant et ça permet de faire finalement de petits logiciels simples, loin des gros machins qu'on trouve ailleurs. Y a même peut-être un créneau intéressant sur le segment des OS légers et efficace sur PC, avec ces superbes PC-hybrides qui galèrent avec leur petit Atome ou pour continuer à utiliser normalement un vieil ordi.

            Emacs le fait depuis 30 ans.

        • [^] # Re: Logiciels disponibles

          Posté par  (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 20 août 2018 à 07:44.

          Ce n'est pas parce qu'un logiciel a commencé à être développé il y a 17 ans qu'il est obsolète. Je ne comprend pas cette manie de vouloir tout réécrire à partir de zéro tous les 5 ans.

          Comme l'a dit devnewton plus bas, en 2003 on avait plein d'environnements de bureau sympa sous Linux, mais ils ont tous décidé de tout jeter et de recommencer. C'est pas comme ça qu'on arrivera à quoi que ce soit.

          L'API de Haiku a pas mal changé par rapport à celle de BeOS, et les habitudes au niveau des interfaces utilisateur aussi. Mais ça reste quand même largement moins cher de mettre à jour une application existante que de refaire tout le dev.

          • [^] # Re: Logiciels disponibles

            Posté par  . Évalué à 4.

            Ce n'est pas parce qu'un logiciel a commencé à être développé il y a 17 ans qu'il est obsolète. Je ne comprend pas cette manie de vouloir tout réécrire à partir de zéro tous les 5 ans.

            Je n'ai pas dit qu'un logiciel commencé il y a 17 ans est obsolète, bien au contraire, le kernel Linux par exemple est même très loin d'être hors-course. Je n'ai pas parlé de jeter le vieux code et je n'ai pas non plus dit qu'un logiciel dont le dev est arrêté n'est plus capable de remplir sa tâche.
            Je demandais plutôt si un logiciel dont le développement s'est terminé il y a 17 ans n'était pas quelque peu dépassé. Je pensais en terme de fonctionnalité, les besoins des utilisateurs ayant évolués, mais aussi en terme d'UI, les règles d'ergonomies ayant évoluées, en terme d'esthétique, les bibliothèques graphiques ayant également évoluées, et en terme de sécurité, les morceaux de code plus maintenus pouvant avoir d'énormes trous béants.

            Comme l'a dit devnewton plus bas, en 2003 on avait plein d'environnements de bureau sympa sous Linux, mais ils ont tous décidé de tout jeter et de recommencer. C'est pas comme ça qu'on arrivera à quoi que ce soit.

            Les WM managers de cette époques sont toujours là et utilisable, mon FVWM se portant très bien. Également une partie des DE a continué à évoluer au lieu de tout jeter, je pense en particulier à XFCE et E17. Mais bon, tout ceci n'a rien à voir avec ce que je disais plus haut.

            Mais ça reste quand même largement moins cher de mettre à jour une application existante que de refaire tout le dev.

            Je suis on ne peut plus d'accord, mais encore faut-il des gens qui le fasse, et même qui puisse le faire, ce qui n'est pas forcément le cas des anciens logiciels de BeOS, contrairement à ceux qu'on trouve dans les dépôts GNU/Linux ou *BSD par exemple.

            Emacs le fait depuis 30 ans.

            • [^] # Re: Logiciels disponibles

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

              Même après une pause de 17 ans, on peut toujours reprendre le code source d'un logiciel et le faire évoluer. C'est ce que fait le projet HaikuArchives et on a pu récupérer des centaines de logiciels de cette façon.

              Il y en a encore plein d'autres dont nous n'avons pas pu récupérer les sources. Je pense par exemple à SynC Modular, qui est un logiciel de synthèse musicale dont on a pas encore réussi à contacter l'auteur pour obtenir une copie du code. Et là, ce sera difficile de faire quoi que ce soit, il faudra donc le remplacer…

        • [^] # Re: Logiciels disponibles

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

          Si moi ça m'interresse, je rêve d'essayer Gobe Productive

  • # Projet intéressant académiquement

    Posté par  . Évalué à 7.

    Bonjour,
    cela me fait penser aux EFL, ça avance, ça devient plus efficace mais au final cela ne sort pas.
    A part pour le côté intellectuel, académique…quel est le but final ?
    Car faire tourner des applications BeOS d'il y a 17ans c'est bien mais elles ont été remplacées depuis longtemps ces applications.
    Et essayer de prendre la place de Windows, iOS c'est mort aussi. Remplacer les linux, FreeBSD…ce sera difficile aussi.
    Merci d'éclairer ma lanterne.

    • [^] # Re: Projet intéressant académiquement

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

      En ce qui me concerne, Haiku est mon système principal depuis quelques années et j'ai vraiment du mal à utiliser Windows et même GNU/Linux (ou j'ai réussi à avoir un système qui fonctionne à peu près comme je veux après plusieurs années à ajuster des fichiers de configuration).

      Même si on ne remplace pas Windows sur les PC de bureau, ça fonctionne au moins sur ma machine et c'est dans mon intérêt qu'il y aie plus d'utilisateurs et j'espère, plus de contributeurs. Même si les ambitions ne sont pas forcément gigantesques.

      Le côté expérience est également un point important. J'ai appris plein de choses sur le C++ en travaillant dans Haiku, mais aussi sur la façon de gérer un projet libre avec des contributeurs bénévoles, un management sans chef de projet, ce qui a ses avantages et ses inconvénients. Et aussi l'encadrement d'étudiants dans le cadre du Google Summer of Code et du Google Code-In, qui nous oblige à réfléchir à la façon dont de nouveaux contributeurs peuvent aborder le projet.

      Il y a aussi un peu un intérêt historique à découvrir le fonctionnement de ces applications BeOS, qui parfois ont essayé de faire des choix différents, en profitant d'être sur une plateforme toute nouvelle, qui pouvait se permettre de bousculer un peu les habitudes. On peut donc avoir un regard avec un peu de recul sur ce qui a marché ou pas.

    • [^] # Re: Projet intéressant académiquement

      Posté par  . Évalué à 7.

      Et essayer de prendre la place de Windows, iOS c'est mort aussi. Remplacer les linux, FreeBSD…ce sera difficile aussi.

      Mon but dans la vie ? conquérir le monde !

      La mode du cloud et du tout dans le navigateur web a cet avantage qu'il est désormais moins pénalisant d'être sur une plateforme exotique : de plus en plus de choses passent, lourdement, mais passent avec un navigateur web.
      Du coup, pourquoi faudrait-il avoir pour seul but d'être premier sur un marché ? Nous ne sommes pas sur un projet d'entreprise mais un projet d'individus qui s'amusent. Et ça fait un bien fou…

      • [^] # Re: Projet intéressant académiquement

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

        Mais avoir un bon navigateur web, c'est pas évident non plus. Le port de WebKit sur Haiku nous a fait trouver plein de bugs et de limitations dans nos APIs, et c'est un travail conséquent juste de garder notre version à jour avec les nouveaux développement.

        Le HTML5 change en permanence, donc il faut régulièrement ajouter de nouvelles fonctionnalités pour que la dernière web app à la mode puisse se lancer correctement. Actuellement on est en train de travailler sur Web Crypto pour pouvoir utiliser WhatsApp, par exemple.

      • [^] # Re: Projet intéressant académiquement

        Posté par  . Évalué à 4. Dernière modification le 31 août 2018 à 10:25.

        Ouais enfin, t'as beau passer pas le tout Web, si ton OS a pas de pilotes graphiques et sonores décents pour ton matériel faute d'intérêt de la part des constructeurs ou hackers, et faute d'une base d'utilisateurs assez conséquente pour tester, ton expérience Web Cloud 3.0 SAAS ProutProut va en pâtir fortement.

        Je dis ça, je dis rien.

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # Retour vers le futur

    Posté par  (site web personnel) . Évalué à 9. Dernière modification le 19 août 2018 à 18:02.

    non, ce n’est toujours pas l’année de GNU/Linux sur le Desktop

    L'année du bureau GNU/Linux, c'était 2003: Gnome 2, KDE 3, XFCE 4, les meilleurs environnements étaient enfin matures.

    Depuis les deux premiers sont retournés à l'adolescence :-(

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Retour vers le futur

      Posté par  . Évalué à -1.

      XFCE 4

      J'ai du louper la fin de XFCE 4, et visiblement ma distribution aussi.

      Emacs le fait depuis 30 ans.

      • [^] # Re: Retour vers le futur

        Posté par  (Mastodon) . Évalué à 6. Dernière modification le 23 août 2018 à 16:05.

        T'as surtout oublié de lire la fin du commentaire.
        Tu sais quand il est écrit que « les deux premiers sont retournés à l'adolescence », laissant de fait le troisième parfaitement mature et adulte et utilisable depuis toutes ces années.

        Yth, de rien :)

Suivre le flux des commentaires

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