pulkomandy a écrit 2019 commentaires

Où peut-être une intersection route/tram mal pensée. en vélo, traverser un rail de tramway perpendiculairement ne pose pas trop problème. Traverser à un angle de 30° ou moins deviens dangereux, surtout si on a des pneus pas trop larges qui risquent de s'insérer dans la rainure du rail.

ça va un peu dans le sens de ce que je dis: en conduisant une automobile moderne, avec airbag, carrosserie amortissante, ceintures, et qui roule à 130km/h sans vibrer de partout, tu vas avoir tendance à faire moins attention à ta sécurité.

Globalement, les mesures de sécurité sont quand même suffisamment efficace pour que ça soit un progrès (mais y'a pas que ça pour expliquer la baisse du nombre de morts sur les routes, les infrastructures ont aussi beaucoup évolué, il y a les radars automatiques, etc).

si tu sors du choc frontal/latéral de base ton auto 5 étoiles euro NCAP peut dans certains cas être aussi peu sûre qu'une vieille fiat panda des années 80.

Plus dangereuse, car elle roule plus vite et comme elle ne vibre pas de partout comme si elle allait se disloquer, tu fais moins attention.

Donc selon toi, la ceinture de sécurité ne devrait pas être obligatoire car on part du principe que les gens sont tous assez intelligents, matures et responsables pour se gérer eux même ?

C'est pas ça: le casque devrait être obligatoire aussi pour les piétons et les automobilistes. Y'a pas de raison, ils prennent autant voir plus de risques que les cyclistes.

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).

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.

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.

Tu as déjà du retard, le futur c'est le "personal cloud":

http://www.seagate.com/fr/fr/consumer/backup/personal-cloud/

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.

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.

Pour ça il y a Trinity, qui continue de faire évoluer KDE3: https://www.trinitydesktop.org

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.

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 :)

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é.

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.

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.

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.

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.

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.