Chaque fenêtre est associée à un thread. Du coup, on ne peut pas faire facilement fonctionner un appel au destructeur "normal", il faut que la destruction se fasse forcément depuis le thread propre à la fenêtre.
Pour la détruire, on lui envoie un message (B_QUIT_REQUESTED, en l'occurence) qui sera traité par sa boucle d'évènements. La fenêtre peut d'ailleurs refuser de se fermer (par exemple si elle contient un document non enregistré et qu'elle veut d'abord demander à l'utilisateur s'il est d'accord pour perdre ses changements).
Le traitement du message se termine par la libération de la mémoire occupée par la fenêtre, puis l'arrêt de l'exécution du thread.
Si on fait un delete sans arrêter la boucle d'évènements, l'application va probablement se planter dès que la fenêtre en question va recevoir un évènement. Cependant, il y a quelques sécurités pour avoir un genre de weak reference vers une fenêtre pour lui envoyer des messages seulement si elle existe encore. Dans ce cas, le thread continuera d'exister mais ne recevra plus de messages. Pour éviter cela, l'appel du destructeur de la fenêtre ouvre directement le debuger avec un message d'erreur clair pour le développeur ("you can't call delete on a BLooper object once it is running"). Et donc, normalement ce genre de code ne devrait pas survivre très longtemps.
Version obsolète, c'est un peu exagéré. On utilise actuellement un WebKit de mars 2016. Alors certes, ce n'est pas la toute dernière version, mais c'est quand même pas si ancien que ça.
Pour les sandboxes, ce n'est pas encore fait (c'est ce qu'apporte webkit2 - le moteur de rendu étant le même entre webkit1 et webkit2). ça viendra un jour mais c'est un assez gros travail de passer de webkit1 à webkit2 et on a pas encore eu le temps de s'y mettre. De plus, cela devient plus facile avec les versions plus récentes de WebKit qui commencent à mieux séparer les parties spécifiques à chaque plateforme du code commun à toutes. Donc on préfère d'abord rattraper un peu notre retard sur les versions à jour du moteur, avant de se pencher sur ce problème.
Cependant, si on faisait un processus par page, on pourrait afficher la fenêtre principale encore plus vite, et lancer ces processus seulement lorsque les onglets sont affichés pour la première fois. Du coup, l'apparition de la fenêtre serait encore plus rapide, mais par contre l'apparition de la page dans la fenêtre, serait elle un peu plus lente (encore que, lancer un process, c'est pas forcément un truc qui prend des heures non plus).
De mon point de vue, ça semble bien: je clique sur l'icône du navigateur, et paf, la fenêtre apparaît. Ensuite, la page se charge, mais j'ai une barre de progression en bas de l'écran qui m'indique qu'une opération potentiellement lente est en cours (téléchargement depuis le réseau, lancement du process de rendu, et tout le bazar). C'est ce genre de chose qui me semble importantes pour une interaction confortable avec un ordinateur. Que les traitements soit longs, ça ne me pose pas de problème, par contre, les actions de l'utilisateur doivent être prises en compte immédiatement et avec un retour rapide à l'écran, pour qu'on sache que l'ordre est reçu.
Un splash screen est l'exemple le moins discret. En réfléchissant un peu on peut faire quelque chose de plus subtil et qui passe inaperçu. Exemple amusant: sur iOS, les applications sont packagées avec une capture d'écran de la première chose qu'elles affichent. Cette image est affichée tout de suite quand on lance l'application. Du coup, on a l'impression que le système réagit très vite, et éventuellement que c'est l'application qui met du temps à s'activer. Mais on a au moins un retour sur le fait que l'application est lancée.
Qu'est-ce qui est arrivé à Firefox pour qu'il soie si lourd? Haiku a un navigateur web basé sur WebKit, certes pas parfait, mais qui permet quand même d'afficher un grand nombre de pages web sans trop de problèmes. Je ne dirais pas que WebKit est une bibliothèque légère, mais ce n'est que quelques méga-octets de code à charger. Et comme les autres applications, le navigateur affiche une fenêtre et est prêt à fonctionner en moins d'une seconde.
Pourtant, je pense que c'est l'une des applications qui fait le plus "mal" les choses. En effet, l'architecture de WebKit (et surtout de WebKit 1 qui est encore utilisé dans Haiku) se prête très mal au fonctionnement avec plusieurs threads. En conséquence, une grande partie du rendu graphique est faite dans le thread de l'application et pas dans celui de la fenêtre. Mais ça, ça ne ralentit pas le temps de démarrage.
Alors certes, on ne fait pas tout ce que fait Firefox, mais quand même, je pense que pour démarrer le navigateur et afficher une fenêtre, il ne devrait pas y avoir tant de choses à faire que ça? Ce n'est que plus tard, quand on commence à navigure sur des pages compliquées pleines de Javascript et d'effets graphiques animés, qu'on devrait commencer à avoir des problèmes.
Pourquoi donc Firefox met-il tant de temps à se charger et à ouvrir une fenêtre?
Tu remarqueras l'absence de delete dans ce code. C'est volontaire: ces deux classent se suppriment toute seules, respectivement lorsque la fenêtre est fermée, et lorsque l'application est quittée. L'utilisation d'un smart pointer est donc inutile ici.
Pour OpenGL, on commence par créer une BWindow comme ci-dessus, puis on lui ajoute une BGlView qui permet d'obtenir un contexte OpenGL. On peut également utiliser EGL, qui se chargera alors de créer la fenêtre.
Le serveur graphique lui-même va créer un thread de son côté pour gérer les interactions avec l'application. Donc ça fait au moins un thread.
De l'autre côté, si on veut attaquer les choses en bas niveau, on a un protocole à base de communication inter-process avec des "ports", qui permettent d'envoyer et de recevoir des messages. Le protocole utilisé n'est pas documenté, et peut changer d'une version à l'autre de Haiku. Alors oui, en théorie c'est possible de réécrire tout le framework côté applicatif à partir de ça, mais franchement, pourquoi on ferait une chose pareille?
int main(void)
{
BApplication* app = new BApplication("x-vnd/PulkoMandy-test");
BWindow* window = new BWindow(BRect(100, 100, 400, 400), "Une fenêtre!", B_DOCUMENT_WINDOW_LOOK, B_QUIT_ON_WINDOW_CLOSE);
window->Show();
app->Run();
return 0;
}
Voilà à quoi va ressembler le main() de la plupart des applications pour Haiku. En 4 lignes de code, on a donc:
- Créé et affiché une fenêtre (ce qui lance un thread pour traiter les évènements de cette fenêtre: redimensionnement, fermeture, etc),
- Créé une boucle d'évènement pour l'application (BApplication) qui tourne dans le thread principal (Run() ne rend pas la main tant que l'application n'est pas quittée).
Il peut y avoir quelques variantes, du genre, créer la fenêtre plutôt dans le constructeur de l'application ou au pire dans son callback ReadyToRun(). Mais dans les trois cas ce sera très tôt au lancement de l'application, et je ne vois pas pourquoi il faudrait plusieurs secondes pour instancier 2 objets C++ (même compliqués).
Une application native pour Haiku utilisera pour cela le "Media Kit" (dans la bibliothèque libmedia.so). Au chargement de l'application, il y a juste besoin de charger cette lib, qui est de toutes façons déjà en mémoire puisque par exemple, elle est utilisée par l'icône "systray" pour le contrôle du volume.
Le chargement des codecs spécifiques ne se fera qu'à la demande lorsque l'application voudra décoder (ou encoder) un fichier média. Du coup, le temps nécessaire pour cela est reporté au moment où le décodage commence, et pas au chargement de l'application.
Dans Haiku, tu ne peux pas créer une fenêtre sans créer un thread qui va gérer sa boucle d'évènement. A ma connaissance, sur tous les autres systèmes, si tu veux faire une fenêtre avec son propre thread pour gérer les évènements, c'est possible, mais il faut créer le thread explicitement. Du coup, sous Haiku, pour faire une application qui n'arrive pas à afficher rapidement sa fenêtre, il faut le faire exprès.
La deuxième chose: sous Linux, chaque application utilise un ensemble de bibliothèques qu'il va falloir charger. Sous Haiku, le système de base fournit déjà pas mal de fonctionnalités dans deux ou trois bibliothèques partagées, qui du coup sont tout le temps chargées en RAM puisque tout le monde les utilise. Du coup, il y a beaucoup moins besoin d'accès disques pour charger toutes les dépendances de chaque application. D'où, je suppose, un lancement plus rapide.
J'en avais déjà parlé dans les commentaires de la dépêche de l'an dernier, SamWang a mis un lien vers mes réponses de l'époque dans un de ses commentaires.
Ce n'est pas évident de corréler mon ressenti avec des explications concrètes sur ce qu'il se passe vraiment (surtout sur les systèmes Linux et Windows, que je connaît moins bien).
Dans les faits, si on fait un benchmark, on verra que dans la plupart des cas, Haiku met plus de temps à faire les choses. Cela s'explique par plusieurs raisons, dont les plus évidentes:
- L'utilisation de gcc2 là où un compilateur plus récent optimiserait mieux (sauf sur la version 64bits de Haiku, qui utilise un compilateur à jour),
- Le fait que l'on privilégie la lisibilité et la clarté du code, sans forcément pousser très loin la recherche de performance (on a pas les mêmes besoins qu'un Linux qui doit gérer des serveurs avec plusieurs milliers d'utilisateurs connectés, et on a pas assez de développeurs pour faire ce genre de choses non plus)
- Le fait que les versions actuellement diffusées de Haiku ont un noyau en mode "paranoïaque", c'est à dire qu'il effectue des opérations coûteuses pour simplifier le débugage (par exemple, effacer la mémoire avant de la libérer pour avoir plus de chances de détecter un accès après libération).
Mais malgré tout, à l'utilisation, Haiku réagit toujours immédiatement quand on clique sur un bouton, et ce même sur les machines les plus modestes (on a encore quelques utilisateurs avec des CPUs dépassant péniblement les 400MHz).
La raison tient principalement à la conception de l'API de Haiku, dans laquelle chaque fenêtre affichée à l'écran possède deux threads dédiés (un dans l'application, un dans le serveur graphique) et indépendants du thread principal de l'application. Avec ce modèle, une fenêtre n'est jamais bloquée en attente d'un quelconque évènement, et elle réagit toujours quand on la manipule. Même si c'est pour afficher une barre de progression et dire que le traitement en cours va prendre un moment.
Aussi bien sous Linux que sous Windows, j'ai en permanence un indicateur de la charge CPU et de l'activité du disque dur. C'est souvent le seul moyen que j'ai de savoir que l'ordinateur est en train de réfléchir, après avoir appuyé sur un bouton. À force d'utiliser Haiku, j'ai peu de tolérance aux applications qui mettent plus d'une seconde à se lancer, par exemple.
J'ai pourtant essayé d'alléger mon Linux autant que possible. J'utilise IceWM, un environnement de bureau très peu gourmand avec aucun service en arrière plan. Cependant j'ai toujours l'impression de devoir attendre que l'ordinateur réagisse dès que je fais quelque chose.
Voilà, je n'ai qu'un ressenti et quelques pistes pour tenter de l'expliquer. Et je préfère investir mon temps à rendre Haiku encore plus rapide qu'à essayer de comprendre pourquoi les autres sont à la traîne.
Pour un projet mature il me semble normal qu'il y aie peu d'activité: il n'y a plus rien à faire, plus de bugs à corriger, pas de nouvelles fonctionalités à ajouter.
On peut pas à la fois se plaindre que KDE 5 est tout le temps tout cassé et pas stable, et que Trinity n'évolue pas assez.
Contribuer ce n'est pas forcément écrire du code. Les rapports de bugs, ou même écrire une documentation "par où commencer" lorsqu'il n'y en a pas, ça peut être une bonne façon de commencer à aider un projet.
Par contre, c'est vrai que tous les gens qui contribuent au libre, et toutes les communautés, ne sont pas forcément accueillantes. Mais là, c'est tant pis pour eux, tu peux les laisser se débrouiller tout seuls :)
D'abord, attention pour le multi-utilisateur, il y a bien une prise en charge des utilisateurs au sens UNIX, même si elle est imparfaite. Cependant, c'est avant tout un mécanisme de sécurité, et il est possible qu'on ne l'utilise pas (ou en tout cas, pas directement) pour faire un système multi-utilisateur. Il y a encore eu peu de travail de ce côté, mais l'idée est que la gestion des permissions et le fait d'avoir plusieurs utilisateurs sont des choses différentes et qui ne doivent pas être liées aussi fortement qu'elles le sont sous Linux.
Qiand on dit que Haiku ne gère pas plusieurs utilisateurs, c'est dans le sens où on ne peut avoir qu'une seule session graphique pour le moment. ça n'empêche pas de créer des utilisateurs différents qui pourront se connecter en ssh, par exemple (et qui ne pourront pas lancer d'applications utilisant le serveur graphiques ou certains autres services).
Sur la compatibilité avec BeOS: il existe déjà une version 64-bit de Haiku, qui n'est pas compatible avec BeOS. Elle sera officiellement supportée et diffusée dès la release beta1 (bientôt, enfin j'espère). La version R1 de Haiku sera la dernière compatible avec BeOS, ensuite on travaillera sur la version R2, qui elle, sera compatible avec la version R1 et introduira en parallèle de nouvelles APIs. Et ainsi de suite. Il est essentiel que chaque version soit compatible au moins avec la précédente, car cela permet aux développeurs d'application de pouvoir migrer d'une version majeure de l'API à la suivante dans un délai assez long. Le but de la compatibilité avec BeOS, plus que le fait de continuer à faire fonctionner les applications, est, d'une part de pouvoir comparer notre comportement avec celui de BeOS (parfois, on se demande pourquoi une application plante, et on se rend compte qu'elle ne fonctionnait pas non plus sous BeOS et donc que Haiku n'y est pour rien), et d'autre part, de faire nos armes sur la façon de gérer les problèmes de compatibilité et la façon de concevoir nos APIs et nos ABIs pour pouvoir assurer une certaine évolutivité tout en restant compatibles.
Pour l'idée de transporter certaines choses sur un noyau Linux, c'est possible, mais pas pour tout. Une raison pour cela est justement liée à des problématiques de sécurité. Par exemple, l'API de BeOS permet de référencer un fichier directement par son numéro d'inode. Ce qui est pratique dans certains cas (pour communiquer efficacement l'emplacement d'un fichier d'une application vers une autre), mais impossible sous Linux car cela permettrait de contourner les droits sur les fichiers. Du coup, cette API ne peut pas être reproduite telle quelle. Il existe, ou plutôt il a existé, au moins deux projets avec ce but: BlueEyedOS et Cosmoe. Personellement je serais plutôt content de les voir vivre, en plus de Haiku, de la même façon qu'il y a plein d'implémentations de UNIX ou POSIX aujourd'hui.
Ensuite pour l'aspect novateur: les idées ne manquent pas, mais les moyens pour les réaliser, un peu plus. Mais on a déjà accompli pas mal de choses. Il y a le gestionnaire de paquets, et il y a aussi des travaux de recherche de l'université d'Aukland, avec par exemple la possibilité de faire du tiling et des tabs dans le gestionnaire de fenêtres, ou encore un système de gestion du layout des interfaces graphiques utilisant un solveur de contraintes linéaires (en principe, il doit pouvoir faire le layout de la fenêtre "tout seul" en fonction des contraintes indiquées par le programmeur). Et il y a toutes sortes de choses dans les cartons et que l'on verra peut être fonctionner un jour.
En ce qui concerne la gestion de la RAM (commentaire en-dessous, je réponds à tout le monde en même temps): sous Haiku, s'il n'y a pas assez de mémoire disponible, une application qui fait une allocation se voit retourner un pointeur NULL, ce qui lui permet de gérer l'erreur proprement. Malhereusement, beaucoup d'applications supposent un comportement proche de celui de Linux et ne prennent pas la peine de vérifier.
Haiku étant écrit en C++ et avec de gros efforts faits sur la lisibilité du code, plutôt que sur la performance, je pense qu'il y a du potentiel pour obtenir du code sécurisé à terme. Mais ça ne marche que si les gens prennent le temps d'inspecter et de remonter les erreurs trouvées. Haiku utilise Coverity (un outil d'analyse statique du code qui détecte de nombreux cas de failles potentielles), et la plupart des erreurs trouvées sont dans du code tiers (la bibliothèque de résolution DNS importée de NetBSD, ou la librairie de résolution des dépendances du gestionnaire de paquets empruntée à SUSE, par exemple). Maintenant, je ne m'avancerai pas plus loin vu qu'il n'y a pas vraiment eu de tests ou d'investigations menées de ce côté.
La beta n'est pas encore disponible, mais sur http://download.haiku-os.org tu peux trouver des "nightly builds" qui s'en rapprochent et que je recommande d'utiliser. En particulier, le gestionnaire de paquets est disponible ce qui simplifie pas mal de choses.
Il n'y a plus tellement de travail à faire sur le code, les nightlies sont plutôt stable (même si ce n'est jamais parfait). Le gros du travail sur la beta est plutôt sur la mise en place de l'infrastructure pour construire et distribuer les paquets, chose qu'on a pas trop l'habitude de faire pour le moment.
Haiku a besoin de 192Mo de RAM et d'un processeur avec support du MMX (soit à peu près n'importe quoi fabriqué après 1995). Pour utiliser le navigateur web, il y a besoin de SSE (soit à peu près n'importe quoi fabriqué après 1999).
Bien sûr, il fonctionne mieux sur des machines plus puissantes, et si c'est possible, tu peux prendre la version 64-bit qui utilise un compilateur plus récent et est donc mieux optimisée.
On ne peut pas encore tout faire (le navigateur web est encore un peu en chantier et il n'y a pas encore de suite office - mais on y travaille).
Il est facile de tester en live USB pour voir ce que ça donne avant de se lancer pour une installation permanente.
En ce qui me concerne, j'ai appris beaucoup en contribuant à Haiku. J'ai commencé en tant qu'étudiant lors du Google Summer of Code. Je ne pense pas pouvoir parler de nostalgie, puisque je n'ai découvert BeOS que vers 2006 ou 2007 (c'était déjà mort depuis 5 ans) et que j'ai continué avec Haiku dès que cela a été possible (en gros vers 2009 avec la sortie de la première version alpha).
Mais même maintenant, mes machines sous Linux ou Windows sont loin d'avoir la fluidité de Haiku. Tout me semble insupportablement lent et pas pratique. Je suis bien content de pouvoir utiliser Haiku chez moi et pour faire de plus en plus de choses.
On connaît tous la blague de "l'année de Linux sur le Desktop". Pourtant, ça n'arrive toujours pas. Et peut-être, qui sait, ça marcherait mieux sans Linux? Mais bon, je ne me prends pas trop au sérieux là-dessus. J'ai eu la chance de pouvoir travailler un an à plein temps sur Haiku grâce aux dons de la communauté d'utilisateurs, et ça, c'est déjà super.
Il y a aussi le fait que la communauté des développeurs autour de Haiku est plutôt ouverte et accueillante aux nouveaux contributeurs. Comme je l'ai mentionné dans la dépêche, c'est un des 3 projets à avoir survécu à 7 ans de Google Code-In, et il y a d'autres exemples d'utilisateurs qui sont parti de rien et qui ont fini par apprendre le C++ et développer leurs propres applications.
Enfin, il y a bien des utilisateurs sérieux qui vendent des systèmes fonctionnant sous Haiku. Il y a au moins TuneTracker Systems (http://tunetrackersystems.com) et il est question de projets en cours chez iZ Corp (http://www.izcorp.com), qui sont probablement les derniers utilisateurs de BeOS.
Ce n'est pas monolithique. L'architecture du système est modulaire et on peut remplacer des composants. Cependant, il semble préférable d'avoir une seule équipe en charge de tout le système pour apporter de la cohérence.
On peut également réutiliser des morceaux de code venu d'ailleurs. Le shell est bash, le serveur graphique utilise AGG et Freetype, l'internationalisation est assurée par ICU, les drivers réseau viennent de FreeBSD, le décodage média est fait par ffmpeg et il y a plein d'autres exemples. Cependant, ceci est invisible des applications qui n'ont affaire qu'à l'API de Haiku. Donc, on peut à tout moment décider de remplacer une de ces bibliothèques par autre chose (soit une autre implémentation, soit simplement une version plus récente). Le tout sans le moindre changement dans les applications. Ainsi des applications écrites pour BeOS peuvent se lancer sur Haiku et décoder des fichiers vidéo dans des formats modernes qui n'existaient même pas quand elles ont été écrites, par exemple.
Le portage ARM de Haiku est malhereusement laissé de côté par manque d'intérêt ou de temps. De plus, on a choisi de laisser le Pi de côté en raison de son CPU ARMv6 (alors que tout le monde fait au moins de l'ARMv7). Il y a eu pas mal de travail sur le support de la Beagleboard xM, qui a l'avantage d'utiliser un CPU plutôt bien documenté. Et dernièrement, un peu de travail sur le Raspberry Pi 3, mais on a pas encore de driver fonctionnel pour le framebuffer, du coup le système plante au démarrage en essayant d'afficher le splash screen (et il manque plein d'autres trucs derrière avant d'espérer arriver sur le bureau de Haiku).
Mais on accepte toutes les contributions pour de nouveaux portages (ARM ou autres). Et il y a plein de gens prêt à partager leurs connaissances pour aider à faire avancer les choses, même s'ils n'ont pas forcément le temps d'écrire le code eux-même.
Le projet Haiku a été créé dans ce but: fournir une continuité à BeOS. La première étape, c'est de remplacer BeOS par un système entièrement libre. Comme c'est mentionné dans la dépêche, on essaie quand même de rester pertinents avec des choses comme le passage au 64-bit, qui de toutes façons casse la compatibilité. À partir de la version R2 de Haiku, on ne sera donc plus compatibles et on pourra se poser plein de questions sur le shell par défaut, les APIs, et tout plein d'autres trucs.
Mais pour le moment, on essaie de rester concentrés sur ce premier objectif.
Pour les applications BeOS encore utilisées, il y a au moins GoBe Productive (une suite bureautique, pour laquelle d'une part il n'y a pas vraiment de remplacement, et d'autre part, il faudrait pouvoir convertir les fichiers dans un format lisible par d'autres outils), et SynC Modular (un synthétiseur musical modulaire). Pour ces deux là, on a pas réussi à avoir accès au code source pour les mettre à jour pour une version 64-bits. Il y a sûrement plein d'autres logiciels pour BeOS qui fonctionnent avec Haiku et qui sont encore utiles.
La migration vers des applications plus à jour se fait petit à petit. Ce qui nous permettra par la suite de passer à un système entièrement 64bit et sans les contraintes de BeOS. Mais c'est pas quelque chose qu'on peut faire du jour au lendemain.
En ce qui me concerne, j'utilise Haiku autant que possible pour tout ce que je fais. Il me manque encore une suite office correcte, le support de l'impression qui marche complètement, et un client dropbox. Pour le reste j'arrive à m'en sortir.
Après il y a plein de besoins spécifiques (par exemple si je veux faire des schémas électroniques, j'aurais bien besoin de Kicad ou un outil du même genre).
Mais finalement, les trucs qui me manquent sont plutôt des applications. Donc je suppose que le système lui-même est prêt?
Après il y aura toujours des gens pour râler sur l'absence de drivers pour les webcams, les problèmes de compatibilité du navigateur web, ou l'absence de support de l'USB3, par exemple. C'est de ce côté là qu'on a le plus de travail, finalement: fournir des pilotes de périphériques pour du matériel qui continue d'évoluer tout le temps. Heureusement, on peut s'inspirer du travail de FreeBSD ou de Fuchsia/Magenta pour les drivers, et même parfois leur emprunter des morceaux de code (on n'utilise pas celui de Linux, car il est sous GPL - trop restrictive pour nous, on préfère la licence MIT - et aussi car en général le code est peu lisible, peut être par manque d'habitude).
Pour le terminal, on est parti de code existant, à l'époque c'était un terminal pour BeOS avec la prise en charge des caractères Japonais (qui font 2 fois la largeur des caractères latins, même avec une police monospace).
Mais en effet, il y a dans les cartons un projet de remplacer une partie du code du terminal par libvterm. Mais pour cela il faudrait que les performances soient acceptables, et avec le portage actuel de libvterm, ce n'est pas le cas.
Pour la gestion des fichiers modifiables, c'est prévu, certains dossiers sont accessible en écriture (la hiérarchie n'est pas la même que sous Linux, donc pas de /var et de /etc, mais l'idée est la même). Les paquets peuvent copier des fichiers dans ces dossiers lors de leur installation, avec une gestion des fichiers existants (soit remplacés, soit conservés, selon la décision du paquet).
Pour la décision de refaire les composants, je peux prendre l'exemple récent du gestionnaire de paquets. Avant de se lancer, on a fait une revue de tout ce qui existait, en essayant de prendre en compte les demandes de nos utilisateurs. La conclusion était que rien ne nous convenait. On a donc choisi de développer notre propre système. Cependant, on utilise libsolv, qui gère très bien la résolution des dépendances entre paquets et qui provient de SUSE.
L'un des objectifs de Haiku est de fournir un système cohérent et fortement intégré. Cela veut dire qu'on peut modifier le noyau ou le bootloader pour faire fonctionner notre système de paquets. Qu'on peut modifier le serveur graphique pour y ajouter les primitives nécessaires pour accélérer le rendu des pages par notre navigateur web. Ce genre de chose prend des années à coordonner dans un écosystème de type GNU/Linux, avec un assemblage hétéroclyte de plein de projets. D'autre part, avoir tout le système écrit par la même équipe et avec les mêmes conventions fait que écrire une application est beaucoup plus confortable - pas besoin de jongler entre différentes bibliothèques pour arriver à faire des choses.
Cela dit, il est vrai que cela marche surtout parce que c'est intéressant et enrichissant pour les développeurs. Il y avait d'autres projets plus pragmatiques autour de BeOS, allant de la "simple" distribution Linux avec un maquillage de l'interface graphique (ZevenOS) à un système entièrement nouveau mais pas forcément compatible (AtheOS puis Syllable), en passant par un système compatible au niveau du code source, mais sur une base de noyau Linux (BlueEyedOS) ou BSD (Cosmoe). Mais ils sont tous morts. Et pour les projets qui ne font que environnement de bureau, y'en a déjà plein :)
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 3.
Chaque fenêtre est associée à un thread. Du coup, on ne peut pas faire facilement fonctionner un appel au destructeur "normal", il faut que la destruction se fasse forcément depuis le thread propre à la fenêtre.
Pour la détruire, on lui envoie un message (B_QUIT_REQUESTED, en l'occurence) qui sera traité par sa boucle d'évènements. La fenêtre peut d'ailleurs refuser de se fermer (par exemple si elle contient un document non enregistré et qu'elle veut d'abord demander à l'utilisateur s'il est d'accord pour perdre ses changements).
Le traitement du message se termine par la libération de la mémoire occupée par la fenêtre, puis l'arrêt de l'exécution du thread.
Si on fait un delete sans arrêter la boucle d'évènements, l'application va probablement se planter dès que la fenêtre en question va recevoir un évènement. Cependant, il y a quelques sécurités pour avoir un genre de weak reference vers une fenêtre pour lui envoyer des messages seulement si elle existe encore. Dans ce cas, le thread continuera d'exister mais ne recevra plus de messages. Pour éviter cela, l'appel du destructeur de la fenêtre ouvre directement le debuger avec un message d'erreur clair pour le développeur ("you can't call delete on a BLooper object once it is running"). Et donc, normalement ce genre de code ne devrait pas survivre très longtemps.
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 3.
Version obsolète, c'est un peu exagéré. On utilise actuellement un WebKit de mars 2016. Alors certes, ce n'est pas la toute dernière version, mais c'est quand même pas si ancien que ça.
Pour les sandboxes, ce n'est pas encore fait (c'est ce qu'apporte webkit2 - le moteur de rendu étant le même entre webkit1 et webkit2). ça viendra un jour mais c'est un assez gros travail de passer de webkit1 à webkit2 et on a pas encore eu le temps de s'y mettre. De plus, cela devient plus facile avec les versions plus récentes de WebKit qui commencent à mieux séparer les parties spécifiques à chaque plateforme du code commun à toutes. Donc on préfère d'abord rattraper un peu notre retard sur les versions à jour du moteur, avant de se pencher sur ce problème.
Cependant, si on faisait un processus par page, on pourrait afficher la fenêtre principale encore plus vite, et lancer ces processus seulement lorsque les onglets sont affichés pour la première fois. Du coup, l'apparition de la fenêtre serait encore plus rapide, mais par contre l'apparition de la page dans la fenêtre, serait elle un peu plus lente (encore que, lancer un process, c'est pas forcément un truc qui prend des heures non plus).
De mon point de vue, ça semble bien: je clique sur l'icône du navigateur, et paf, la fenêtre apparaît. Ensuite, la page se charge, mais j'ai une barre de progression en bas de l'écran qui m'indique qu'une opération potentiellement lente est en cours (téléchargement depuis le réseau, lancement du process de rendu, et tout le bazar). C'est ce genre de chose qui me semble importantes pour une interaction confortable avec un ordinateur. Que les traitements soit longs, ça ne me pose pas de problème, par contre, les actions de l'utilisateur doivent être prises en compte immédiatement et avec un retour rapide à l'écran, pour qu'on sache que l'ordre est reçu.
Un splash screen est l'exemple le moins discret. En réfléchissant un peu on peut faire quelque chose de plus subtil et qui passe inaperçu. Exemple amusant: sur iOS, les applications sont packagées avec une capture d'écran de la première chose qu'elles affichent. Cette image est affichée tout de suite quand on lance l'application. Du coup, on a l'impression que le système réagit très vite, et éventuellement que c'est l'application qui met du temps à s'activer. Mais on a au moins un retour sur le fait que l'application est lancée.
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 1.
Qu'est-ce qui est arrivé à Firefox pour qu'il soie si lourd? Haiku a un navigateur web basé sur WebKit, certes pas parfait, mais qui permet quand même d'afficher un grand nombre de pages web sans trop de problèmes. Je ne dirais pas que WebKit est une bibliothèque légère, mais ce n'est que quelques méga-octets de code à charger. Et comme les autres applications, le navigateur affiche une fenêtre et est prêt à fonctionner en moins d'une seconde.
Pourtant, je pense que c'est l'une des applications qui fait le plus "mal" les choses. En effet, l'architecture de WebKit (et surtout de WebKit 1 qui est encore utilisé dans Haiku) se prête très mal au fonctionnement avec plusieurs threads. En conséquence, une grande partie du rendu graphique est faite dans le thread de l'application et pas dans celui de la fenêtre. Mais ça, ça ne ralentit pas le temps de démarrage.
Alors certes, on ne fait pas tout ce que fait Firefox, mais quand même, je pense que pour démarrer le navigateur et afficher une fenêtre, il ne devrait pas y avoir tant de choses à faire que ça? Ce n'est que plus tard, quand on commence à navigure sur des pages compliquées pleines de Javascript et d'effets graphiques animés, qu'on devrait commencer à avoir des problèmes.
Pourquoi donc Firefox met-il tant de temps à se charger et à ouvrir une fenêtre?
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 4.
Tu remarqueras l'absence de delete dans ce code. C'est volontaire: ces deux classent se suppriment toute seules, respectivement lorsque la fenêtre est fermée, et lorsque l'application est quittée. L'utilisation d'un smart pointer est donc inutile ici.
Pour OpenGL, on commence par créer une BWindow comme ci-dessus, puis on lui ajoute une BGlView qui permet d'obtenir un contexte OpenGL. On peut également utiliser EGL, qui se chargera alors de créer la fenêtre.
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
Le serveur graphique lui-même va créer un thread de son côté pour gérer les interactions avec l'application. Donc ça fait au moins un thread.
De l'autre côté, si on veut attaquer les choses en bas niveau, on a un protocole à base de communication inter-process avec des "ports", qui permettent d'envoyer et de recevoir des messages. Le protocole utilisé n'est pas documenté, et peut changer d'une version à l'autre de Haiku. Alors oui, en théorie c'est possible de réécrire tout le framework côté applicatif à partir de ça, mais franchement, pourquoi on ferait une chose pareille?
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 3.
Voilà à quoi va ressembler le main() de la plupart des applications pour Haiku. En 4 lignes de code, on a donc:
- Créé et affiché une fenêtre (ce qui lance un thread pour traiter les évènements de cette fenêtre: redimensionnement, fermeture, etc),
- Créé une boucle d'évènement pour l'application (BApplication) qui tourne dans le thread principal (Run() ne rend pas la main tant que l'application n'est pas quittée).
Il peut y avoir quelques variantes, du genre, créer la fenêtre plutôt dans le constructeur de l'application ou au pire dans son callback ReadyToRun(). Mais dans les trois cas ce sera très tôt au lancement de l'application, et je ne vois pas pourquoi il faudrait plusieurs secondes pour instancier 2 objets C++ (même compliqués).
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
Parlons décodage de médias alors:
Une application native pour Haiku utilisera pour cela le "Media Kit" (dans la bibliothèque libmedia.so). Au chargement de l'application, il y a juste besoin de charger cette lib, qui est de toutes façons déjà en mémoire puisque par exemple, elle est utilisée par l'icône "systray" pour le contrôle du volume.
Le chargement des codecs spécifiques ne se fera qu'à la demande lorsque l'application voudra décoder (ou encoder) un fichier média. Du coup, le temps nécessaire pour cela est reporté au moment où le décodage commence, et pas au chargement de l'application.
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 3.
Dans Haiku, tu ne peux pas créer une fenêtre sans créer un thread qui va gérer sa boucle d'évènement. A ma connaissance, sur tous les autres systèmes, si tu veux faire une fenêtre avec son propre thread pour gérer les évènements, c'est possible, mais il faut créer le thread explicitement. Du coup, sous Haiku, pour faire une application qui n'arrive pas à afficher rapidement sa fenêtre, il faut le faire exprès.
La deuxième chose: sous Linux, chaque application utilise un ensemble de bibliothèques qu'il va falloir charger. Sous Haiku, le système de base fournit déjà pas mal de fonctionnalités dans deux ou trois bibliothèques partagées, qui du coup sont tout le temps chargées en RAM puisque tout le monde les utilise. Du coup, il y a beaucoup moins besoin d'accès disques pour charger toutes les dépendances de chaque application. D'où, je suppose, un lancement plus rapide.
[^] # Re: Ça existe encore ça ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le Développement Très Rapide d'Applications Libre. Évalué à 2.
Tu as déjà du retard, le futur c'est le "personal cloud":
http://www.seagate.com/fr/fr/consumer/backup/personal-cloud/
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 5.
J'en avais déjà parlé dans les commentaires de la dépêche de l'an dernier, SamWang a mis un lien vers mes réponses de l'époque dans un de ses commentaires.
Ce n'est pas évident de corréler mon ressenti avec des explications concrètes sur ce qu'il se passe vraiment (surtout sur les systèmes Linux et Windows, que je connaît moins bien).
Dans les faits, si on fait un benchmark, on verra que dans la plupart des cas, Haiku met plus de temps à faire les choses. Cela s'explique par plusieurs raisons, dont les plus évidentes:
- L'utilisation de gcc2 là où un compilateur plus récent optimiserait mieux (sauf sur la version 64bits de Haiku, qui utilise un compilateur à jour),
- Le fait que l'on privilégie la lisibilité et la clarté du code, sans forcément pousser très loin la recherche de performance (on a pas les mêmes besoins qu'un Linux qui doit gérer des serveurs avec plusieurs milliers d'utilisateurs connectés, et on a pas assez de développeurs pour faire ce genre de choses non plus)
- Le fait que les versions actuellement diffusées de Haiku ont un noyau en mode "paranoïaque", c'est à dire qu'il effectue des opérations coûteuses pour simplifier le débugage (par exemple, effacer la mémoire avant de la libérer pour avoir plus de chances de détecter un accès après libération).
Mais malgré tout, à l'utilisation, Haiku réagit toujours immédiatement quand on clique sur un bouton, et ce même sur les machines les plus modestes (on a encore quelques utilisateurs avec des CPUs dépassant péniblement les 400MHz).
La raison tient principalement à la conception de l'API de Haiku, dans laquelle chaque fenêtre affichée à l'écran possède deux threads dédiés (un dans l'application, un dans le serveur graphique) et indépendants du thread principal de l'application. Avec ce modèle, une fenêtre n'est jamais bloquée en attente d'un quelconque évènement, et elle réagit toujours quand on la manipule. Même si c'est pour afficher une barre de progression et dire que le traitement en cours va prendre un moment.
Aussi bien sous Linux que sous Windows, j'ai en permanence un indicateur de la charge CPU et de l'activité du disque dur. C'est souvent le seul moyen que j'ai de savoir que l'ordinateur est en train de réfléchir, après avoir appuyé sur un bouton. À force d'utiliser Haiku, j'ai peu de tolérance aux applications qui mettent plus d'une seconde à se lancer, par exemple.
J'ai pourtant essayé d'alléger mon Linux autant que possible. J'utilise IceWM, un environnement de bureau très peu gourmand avec aucun service en arrière plan. Cependant j'ai toujours l'impression de devoir attendre que l'ordinateur réagisse dès que je fais quelque chose.
Voilà, je n'ai qu'un ressenti et quelques pistes pour tenter de l'expliquer. Et je préfère investir mon temps à rendre Haiku encore plus rapide qu'à essayer de comprendre pourquoi les autres sont à la traîne.
[^] # Re: KDE presque un 10 sur 10 comme DE.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 2.
Et donc?
Pour un projet mature il me semble normal qu'il y aie peu d'activité: il n'y a plus rien à faire, plus de bugs à corriger, pas de nouvelles fonctionalités à ajouter.
On peut pas à la fois se plaindre que KDE 5 est tout le temps tout cassé et pas stable, et que Trinity n'évolue pas assez.
[^] # Re: KDE presque un 10 sur 10 comme DE.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 2.
Pour ça il y a Trinity, qui continue de faire évoluer KDE3: https://www.trinitydesktop.org
[^] # Re: Est ce utilisable tout les jours?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 3.
Haiku a besoin du jeu d'instruction MMX qui est apparu… après le i586 (avec le Pentium Pro). Donc si ça marche, ton CPU est compatible i586.
[^] # Re: Le troll n'est pas sorti ?!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 3.
Contribuer ce n'est pas forcément écrire du code. Les rapports de bugs, ou même écrire une documentation "par où commencer" lorsqu'il n'y en a pas, ça peut être une bonne façon de commencer à aider un projet.
Par contre, c'est vrai que tous les gens qui contribuent au libre, et toutes les communautés, ne sont pas forcément accueillantes. Mais là, c'est tant pis pour eux, tu peux les laisser se débrouiller tout seuls :)
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 9.
On fait ce qu'on peut.
D'abord, attention pour le multi-utilisateur, il y a bien une prise en charge des utilisateurs au sens UNIX, même si elle est imparfaite. Cependant, c'est avant tout un mécanisme de sécurité, et il est possible qu'on ne l'utilise pas (ou en tout cas, pas directement) pour faire un système multi-utilisateur. Il y a encore eu peu de travail de ce côté, mais l'idée est que la gestion des permissions et le fait d'avoir plusieurs utilisateurs sont des choses différentes et qui ne doivent pas être liées aussi fortement qu'elles le sont sous Linux.
Qiand on dit que Haiku ne gère pas plusieurs utilisateurs, c'est dans le sens où on ne peut avoir qu'une seule session graphique pour le moment. ça n'empêche pas de créer des utilisateurs différents qui pourront se connecter en ssh, par exemple (et qui ne pourront pas lancer d'applications utilisant le serveur graphiques ou certains autres services).
Sur la compatibilité avec BeOS: il existe déjà une version 64-bit de Haiku, qui n'est pas compatible avec BeOS. Elle sera officiellement supportée et diffusée dès la release beta1 (bientôt, enfin j'espère). La version R1 de Haiku sera la dernière compatible avec BeOS, ensuite on travaillera sur la version R2, qui elle, sera compatible avec la version R1 et introduira en parallèle de nouvelles APIs. Et ainsi de suite. Il est essentiel que chaque version soit compatible au moins avec la précédente, car cela permet aux développeurs d'application de pouvoir migrer d'une version majeure de l'API à la suivante dans un délai assez long. Le but de la compatibilité avec BeOS, plus que le fait de continuer à faire fonctionner les applications, est, d'une part de pouvoir comparer notre comportement avec celui de BeOS (parfois, on se demande pourquoi une application plante, et on se rend compte qu'elle ne fonctionnait pas non plus sous BeOS et donc que Haiku n'y est pour rien), et d'autre part, de faire nos armes sur la façon de gérer les problèmes de compatibilité et la façon de concevoir nos APIs et nos ABIs pour pouvoir assurer une certaine évolutivité tout en restant compatibles.
Pour l'idée de transporter certaines choses sur un noyau Linux, c'est possible, mais pas pour tout. Une raison pour cela est justement liée à des problématiques de sécurité. Par exemple, l'API de BeOS permet de référencer un fichier directement par son numéro d'inode. Ce qui est pratique dans certains cas (pour communiquer efficacement l'emplacement d'un fichier d'une application vers une autre), mais impossible sous Linux car cela permettrait de contourner les droits sur les fichiers. Du coup, cette API ne peut pas être reproduite telle quelle. Il existe, ou plutôt il a existé, au moins deux projets avec ce but: BlueEyedOS et Cosmoe. Personellement je serais plutôt content de les voir vivre, en plus de Haiku, de la même façon qu'il y a plein d'implémentations de UNIX ou POSIX aujourd'hui.
Ensuite pour l'aspect novateur: les idées ne manquent pas, mais les moyens pour les réaliser, un peu plus. Mais on a déjà accompli pas mal de choses. Il y a le gestionnaire de paquets, et il y a aussi des travaux de recherche de l'université d'Aukland, avec par exemple la possibilité de faire du tiling et des tabs dans le gestionnaire de fenêtres, ou encore un système de gestion du layout des interfaces graphiques utilisant un solveur de contraintes linéaires (en principe, il doit pouvoir faire le layout de la fenêtre "tout seul" en fonction des contraintes indiquées par le programmeur). Et il y a toutes sortes de choses dans les cartons et que l'on verra peut être fonctionner un jour.
En ce qui concerne la gestion de la RAM (commentaire en-dessous, je réponds à tout le monde en même temps): sous Haiku, s'il n'y a pas assez de mémoire disponible, une application qui fait une allocation se voit retourner un pointeur NULL, ce qui lui permet de gérer l'erreur proprement. Malhereusement, beaucoup d'applications supposent un comportement proche de celui de Linux et ne prennent pas la peine de vérifier.
Haiku étant écrit en C++ et avec de gros efforts faits sur la lisibilité du code, plutôt que sur la performance, je pense qu'il y a du potentiel pour obtenir du code sécurisé à terme. Mais ça ne marche que si les gens prennent le temps d'inspecter et de remonter les erreurs trouvées. Haiku utilise Coverity (un outil d'analyse statique du code qui détecte de nombreux cas de failles potentielles), et la plupart des erreurs trouvées sont dans du code tiers (la bibliothèque de résolution DNS importée de NetBSD, ou la librairie de résolution des dépendances du gestionnaire de paquets empruntée à SUSE, par exemple). Maintenant, je ne m'avancerai pas plus loin vu qu'il n'y a pas vraiment eu de tests ou d'investigations menées de ce côté.
[^] # Re: Est ce utilisable tout les jours?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 5.
La beta n'est pas encore disponible, mais sur http://download.haiku-os.org tu peux trouver des "nightly builds" qui s'en rapprochent et que je recommande d'utiliser. En particulier, le gestionnaire de paquets est disponible ce qui simplifie pas mal de choses.
Il n'y a plus tellement de travail à faire sur le code, les nightlies sont plutôt stable (même si ce n'est jamais parfait). Le gros du travail sur la beta est plutôt sur la mise en place de l'infrastructure pour construire et distribuer les paquets, chose qu'on a pas trop l'habitude de faire pour le moment.
[^] # Re: Est ce utilisable tout les jours?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
Le mieux, c'est d'essayer!
Haiku a besoin de 192Mo de RAM et d'un processeur avec support du MMX (soit à peu près n'importe quoi fabriqué après 1995). Pour utiliser le navigateur web, il y a besoin de SSE (soit à peu près n'importe quoi fabriqué après 1999).
Bien sûr, il fonctionne mieux sur des machines plus puissantes, et si c'est possible, tu peux prendre la version 64-bit qui utilise un compilateur plus récent et est donc mieux optimisée.
On ne peut pas encore tout faire (le navigateur web est encore un peu en chantier et il n'y a pas encore de suite office - mais on y travaille).
Il est facile de tester en live USB pour voir ce que ça donne avant de se lancer pour une installation permanente.
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 7.
Un peu tout ça.
En ce qui me concerne, j'ai appris beaucoup en contribuant à Haiku. J'ai commencé en tant qu'étudiant lors du Google Summer of Code. Je ne pense pas pouvoir parler de nostalgie, puisque je n'ai découvert BeOS que vers 2006 ou 2007 (c'était déjà mort depuis 5 ans) et que j'ai continué avec Haiku dès que cela a été possible (en gros vers 2009 avec la sortie de la première version alpha).
Mais même maintenant, mes machines sous Linux ou Windows sont loin d'avoir la fluidité de Haiku. Tout me semble insupportablement lent et pas pratique. Je suis bien content de pouvoir utiliser Haiku chez moi et pour faire de plus en plus de choses.
On connaît tous la blague de "l'année de Linux sur le Desktop". Pourtant, ça n'arrive toujours pas. Et peut-être, qui sait, ça marcherait mieux sans Linux? Mais bon, je ne me prends pas trop au sérieux là-dessus. J'ai eu la chance de pouvoir travailler un an à plein temps sur Haiku grâce aux dons de la communauté d'utilisateurs, et ça, c'est déjà super.
Il y a aussi le fait que la communauté des développeurs autour de Haiku est plutôt ouverte et accueillante aux nouveaux contributeurs. Comme je l'ai mentionné dans la dépêche, c'est un des 3 projets à avoir survécu à 7 ans de Google Code-In, et il y a d'autres exemples d'utilisateurs qui sont parti de rien et qui ont fini par apprendre le C++ et développer leurs propres applications.
Enfin, il y a bien des utilisateurs sérieux qui vendent des systèmes fonctionnant sous Haiku. Il y a au moins TuneTracker Systems (http://tunetrackersystems.com) et il est question de projets en cours chez iZ Corp (http://www.izcorp.com), qui sont probablement les derniers utilisateurs de BeOS.
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 9.
Ce n'est pas monolithique. L'architecture du système est modulaire et on peut remplacer des composants. Cependant, il semble préférable d'avoir une seule équipe en charge de tout le système pour apporter de la cohérence.
On peut également réutiliser des morceaux de code venu d'ailleurs. Le shell est bash, le serveur graphique utilise AGG et Freetype, l'internationalisation est assurée par ICU, les drivers réseau viennent de FreeBSD, le décodage média est fait par ffmpeg et il y a plein d'autres exemples. Cependant, ceci est invisible des applications qui n'ont affaire qu'à l'API de Haiku. Donc, on peut à tout moment décider de remplacer une de ces bibliothèques par autre chose (soit une autre implémentation, soit simplement une version plus récente). Le tout sans le moindre changement dans les applications. Ainsi des applications écrites pour BeOS peuvent se lancer sur Haiku et décoder des fichiers vidéo dans des formats modernes qui n'existaient même pas quand elles ont été écrites, par exemple.
[^] # Re: divers
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 4.
Le portage ARM de Haiku est malhereusement laissé de côté par manque d'intérêt ou de temps. De plus, on a choisi de laisser le Pi de côté en raison de son CPU ARMv6 (alors que tout le monde fait au moins de l'ARMv7). Il y a eu pas mal de travail sur le support de la Beagleboard xM, qui a l'avantage d'utiliser un CPU plutôt bien documenté. Et dernièrement, un peu de travail sur le Raspberry Pi 3, mais on a pas encore de driver fonctionnel pour le framebuffer, du coup le système plante au démarrage en essayant d'afficher le splash screen (et il manque plein d'autres trucs derrière avant d'espérer arriver sur le bureau de Haiku).
Mais on accepte toutes les contributions pour de nouveaux portages (ARM ou autres). Et il y a plein de gens prêt à partager leurs connaissances pour aider à faire avancer les choses, même s'ils n'ont pas forcément le temps d'écrire le code eux-même.
[^] # Re: shell
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 5.
J'ai pas dit que c'était une bonne raison :D
Le projet Haiku a été créé dans ce but: fournir une continuité à BeOS. La première étape, c'est de remplacer BeOS par un système entièrement libre. Comme c'est mentionné dans la dépêche, on essaie quand même de rester pertinents avec des choses comme le passage au 64-bit, qui de toutes façons casse la compatibilité. À partir de la version R2 de Haiku, on ne sera donc plus compatibles et on pourra se poser plein de questions sur le shell par défaut, les APIs, et tout plein d'autres trucs.
Mais pour le moment, on essaie de rester concentrés sur ce premier objectif.
Pour les applications BeOS encore utilisées, il y a au moins GoBe Productive (une suite bureautique, pour laquelle d'une part il n'y a pas vraiment de remplacement, et d'autre part, il faudrait pouvoir convertir les fichiers dans un format lisible par d'autres outils), et SynC Modular (un synthétiseur musical modulaire). Pour ces deux là, on a pas réussi à avoir accès au code source pour les mettre à jour pour une version 64-bits. Il y a sûrement plein d'autres logiciels pour BeOS qui fonctionnent avec Haiku et qui sont encore utiles.
La migration vers des applications plus à jour se fait petit à petit. Ce qui nous permettra par la suite de passer à un système entièrement 64bit et sans les contraintes de BeOS. Mais c'est pas quelque chose qu'on peut faire du jour au lendemain.
[^] # Re: Corrections
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
Je me rends compte que je n'ai pas pensé à mettre un lien vers le site de Haiku au début de la dépêche:
www.haiku-os.org - site officiel
download.haiku-os.org - page de téléchargement
[^] # Re: divers
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 3.
En ce qui me concerne, j'utilise Haiku autant que possible pour tout ce que je fais. Il me manque encore une suite office correcte, le support de l'impression qui marche complètement, et un client dropbox. Pour le reste j'arrive à m'en sortir.
Après il y a plein de besoins spécifiques (par exemple si je veux faire des schémas électroniques, j'aurais bien besoin de Kicad ou un outil du même genre).
Mais finalement, les trucs qui me manquent sont plutôt des applications. Donc je suppose que le système lui-même est prêt?
Après il y aura toujours des gens pour râler sur l'absence de drivers pour les webcams, les problèmes de compatibilité du navigateur web, ou l'absence de support de l'USB3, par exemple. C'est de ce côté là qu'on a le plus de travail, finalement: fournir des pilotes de périphériques pour du matériel qui continue d'évoluer tout le temps. Heureusement, on peut s'inspirer du travail de FreeBSD ou de Fuchsia/Magenta pour les drivers, et même parfois leur emprunter des morceaux de code (on n'utilise pas celui de Linux, car il est sous GPL - trop restrictive pour nous, on préfère la licence MIT - et aussi car en général le code est peu lisible, peut être par manque d'habitude).
[^] # Re: shell
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 6.
Y'a une raison: c'est le shell de BeOS, et Haiku est compatible avec BeOS.
Mais ça n'empêche pas d'installer zsh, bien sûr.
[^] # Re: divers
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 7.
Pour le terminal, on est parti de code existant, à l'époque c'était un terminal pour BeOS avec la prise en charge des caractères Japonais (qui font 2 fois la largeur des caractères latins, même avec une police monospace).
Mais en effet, il y a dans les cartons un projet de remplacer une partie du code du terminal par libvterm. Mais pour cela il faudrait que les performances soient acceptables, et avec le portage actuel de libvterm, ce n'est pas le cas.
Pour la gestion des fichiers modifiables, c'est prévu, certains dossiers sont accessible en écriture (la hiérarchie n'est pas la même que sous Linux, donc pas de /var et de /etc, mais l'idée est la même). Les paquets peuvent copier des fichiers dans ces dossiers lors de leur installation, avec une gestion des fichiers existants (soit remplacés, soit conservés, selon la décision du paquet).
Pour la décision de refaire les composants, je peux prendre l'exemple récent du gestionnaire de paquets. Avant de se lancer, on a fait une revue de tout ce qui existait, en essayant de prendre en compte les demandes de nos utilisateurs. La conclusion était que rien ne nous convenait. On a donc choisi de développer notre propre système. Cependant, on utilise libsolv, qui gère très bien la résolution des dépendances entre paquets et qui provient de SUSE.
L'un des objectifs de Haiku est de fournir un système cohérent et fortement intégré. Cela veut dire qu'on peut modifier le noyau ou le bootloader pour faire fonctionner notre système de paquets. Qu'on peut modifier le serveur graphique pour y ajouter les primitives nécessaires pour accélérer le rendu des pages par notre navigateur web. Ce genre de chose prend des années à coordonner dans un écosystème de type GNU/Linux, avec un assemblage hétéroclyte de plein de projets. D'autre part, avoir tout le système écrit par la même équipe et avec les mêmes conventions fait que écrire une application est beaucoup plus confortable - pas besoin de jongler entre différentes bibliothèques pour arriver à faire des choses.
Cela dit, il est vrai que cela marche surtout parce que c'est intéressant et enrichissant pour les développeurs. Il y avait d'autres projets plus pragmatiques autour de BeOS, allant de la "simple" distribution Linux avec un maquillage de l'interface graphique (ZevenOS) à un système entièrement nouveau mais pas forcément compatible (AtheOS puis Syllable), en passant par un système compatible au niveau du code source, mais sur une base de noyau Linux (BlueEyedOS) ou BSD (Cosmoe). Mais ils sont tous morts. Et pour les projets qui ne font que environnement de bureau, y'en a déjà plein :)