Haiku n'est pas plus rapide qu'un autre OS (en fait, il est même plutôt plus lent car le noyau est compilé en mode debug pour le moment). Mais, chaque fenêtre fonctionne dans son propre thread, et ces threads en question ont une priorité plus élevée que les autres. Du coup, même si le CPU est très occupé, le système reste toujours réactif et fluide.
ça ne veut pas dire qu'il n'y a jamais besoin d'attendre, par exemple lors des accès disque, mais au moins on n'a pas une fenêtre complètement gelée et qui ne se redessine plus coincée au milieu de l'écran.
Cela dit, c'est aussi pour ça que Haiku a son propre navigateur, qui lui, n'a pas besoin de plusieurs Go de RAM (là, il utilise 375Mo avec 5 onglets ouverts).
Le toolkit graphique a une particularité: chaque fenêtre fonctionne dans son propre thread, aussi bien au niveau de l'application que du serveur graphique. C'est ce qui permet la réactivité légendaire de BeOS et de Haiku: même si le thread principal de l'application est bloqué par une tâche de calcul intensif (ou en attente sur des E/S ou autre chose), les fenêtres ont leurs threads dédiés et ne gèleront pas. (ceci justifie l'importance du travail en cours sur le scheduler mentionné dans la dépêche)
Pour que cela fonctionne bien, la plupart des communications se font via des messages envoyés entre threads, dans le même processus ou pas, d'ailleurs. BMessage est une classe qui fonctionne comme un conteneur dans lequel on peut ajouter des types primitifs (entiers, chaînes de caractères), des pointeurs, des blocs de données bruts, ou même des objets C++ si la classe implémente BArchivable ou BFlattenable. Toutes les données sont contenues dans le message ce qui évite de gérer manuellement le partage de mémoire entre threads et tous les problèmes de partage de ressources. Les messages peuvent être envoyés et reçus par chaque vue dans une fenêtre. On peut rapprocher ça du système de signaux et slots en Qt, mais l'implémentation est uniquement en C++, là ou Qt a besoin du préprocesseur moc.
Les messages étant un composant central dans la programmation avec la BeAPI, leur implémentation doit être optimisée autant que possible. C'est une des raisons pour lesquelles le noyau de Haiku implémente les "ports", un mécanisme plus bas niveau qui permet l'implémentation des messages de façon plus performante qu'on pourrait le faire avec les seules APIs POSIX. C'est un exemple de l'interêt que l'on a a maîtriser l'ensemble du système dans Haiku, là ou une implémentation utilisant un noyau tiers aurait du soit utiliser une solution plus lente, par exemple avec des pipe ou des sockets unix, soit modifier le noyau en question pour y ajouter un mécanisme similaire aux ports (et soit réussir à le faire accepter aux développeurs du noyau, soit maintenir un fork). Il y a d'ailleurs eu une tentative avec le projet BlueEyedOS de porter la BeAPI sur un système à base de noyau Linux. Ce projet n'est malhereusement plus maintenu.
Pour les serveurs: non. Haiku est un système destiné uniquement aux ordinateurs de bureau. Il est possible de lancer un serveur web (PoorMan, qui est fourni avec Haiku, ou encore Cherokee, par exemple), mais ça a peu d'interêt.
Pour le bureau, c'est vrai que Linux a fait beaucoup de progrès depuis 2001 et le lancement du projet Haiku. Et du coup, Haiku utilise effectivement du code développé ailleurs, comme freetype, wpa_supplicant, bash, et encore beaucoup d'autres.
Cependant, il y a des différences de taille, comme par exemple l'absence d'un serveur X. Dans le monde Linux/BSD/…, on a souvent des projets qui doivent fonctionner dans plusiurs cas. Le serveur X.org fonctionne aussi bien sur Linux que sur un FreeBSD, par exemple, certaines applications peuvent utiliser GTK 2 ou 3, qui lui-même peut fonctionner avec Wayland ou X, et ainsi de suite. Cela complexifie le code pour tout le monde, oblige à avoir plusieurs couches d'abstraction à tous les étages, et il reste tout de même des différences de comportement entre les différents systèmes. Dans Haiku au contraire, il n'y a en général qu'une façon de faire les choses.
Un deuxième avantage de Haiku est une stabilité des APIs mais aussi des ABIs. Dans le monde de Linux on n'hésite pas à remplacer ou modifier plein de choses dans le système à chaque version. Les logiciels doivent s'adapter en permanence. C'est résolu la plupart du temps par les distributions qui vont essayer de packager un ensemble cohérent de logiciels qui fonctionnent ensemble. Fort hereusement, une très grande partie de ces logiciels sont libres, et peuvent être patchés pour fonctionner correctement. ça représente tout de même beaucoup de travail, et c'est souvent un problème pour intégrer des logiciels distribués uniquement sous forme de binaires. Ces derniers ne pourront fonctionner qu'avec une version bien précise d'une ou deux distributions.
Ceci permet aux applications de mieux s'intégrer dans le système. Citons par exemple les "translators" (traducteurs) qui permettent de décoder des images (png, jpeg, …) sans en connaître le format. Des applications écrites avant l'apparition d'un format donné pourront donc le décoder si le système dispose du traducteur approprié. La même chose est possible pour d'autre types de fichiers (texte, RTF par exemple). Le Media Kit dispose également d'un mécanisme similaire pour le décodage des fichiers sons et vidéo. Là encore, des codecs peuvent être ajoutés au système et toutes les applications pourront les utiliser. Alors c'est vrai, maintenant, sous Linux il y a GStreamer, mais tout le monde ne l'utilise pas.
Dès le début du projet Haiku est prévu pour permettre à certaines applications non-libres de continuer à exister après la disparition de BeOS. à l'époque, il était encore possible que BeOS continue d'exister d'une façon ou d'une autre, donc, le choix de la licence MIT a été fait, ce qui permettrait une éventuelle réintégration du code de Haiku dans une nouvelle version de BeOS. La compatibilité avec ce dernier est assurée (les applications écrites avant 2001 pour BeOS fonctionnent toujours aujourd'hui), même pour les pilotes matériels, qui peuvent être compilés indépendement du noyau. Un exemple d'application non-libre qui fonctionne sous Haiku après avoir utilisé BeOS pendant assez longtemps: http://www.tunetrackersystems.com/
Enfin, au niveau de l'apparence, moi je la trouve très bien. L'interface est compacte et discrète et permet de se concentrer sur ce qu'on fait. Elle est assez équilibrée, quelque part entre Mac OS X qui met des arrondis et des dégradés partout, et Windows 8 qui est quand même très minimaliste.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 3.
En fait, si!
Haiku n'est pas plus rapide qu'un autre OS (en fait, il est même plutôt plus lent car le noyau est compilé en mode debug pour le moment). Mais, chaque fenêtre fonctionne dans son propre thread, et ces threads en question ont une priorité plus élevée que les autres. Du coup, même si le CPU est très occupé, le système reste toujours réactif et fluide.
ça ne veut pas dire qu'il n'y a jamais besoin d'attendre, par exemple lors des accès disque, mais au moins on n'a pas une fenêtre complètement gelée et qui ne se redessine plus coincée au milieu de l'écran.
Cela dit, c'est aussi pour ça que Haiku a son propre navigateur, qui lui, n'a pas besoin de plusieurs Go de RAM (là, il utilise 375Mo avec 5 onglets ouverts).
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 10.
Quelques informations sur la stack graphique (app_server) et l'architecture des drivers pour les cartes vidéo:
https://www.haiku-os.org/tags/app_server
https://www.haiku-os.org/legacy-docs/writing-video-card-drivers/04-accelerant
Le toolkit graphique a une particularité: chaque fenêtre fonctionne dans son propre thread, aussi bien au niveau de l'application que du serveur graphique. C'est ce qui permet la réactivité légendaire de BeOS et de Haiku: même si le thread principal de l'application est bloqué par une tâche de calcul intensif (ou en attente sur des E/S ou autre chose), les fenêtres ont leurs threads dédiés et ne gèleront pas. (ceci justifie l'importance du travail en cours sur le scheduler mentionné dans la dépêche)
Pour que cela fonctionne bien, la plupart des communications se font via des messages envoyés entre threads, dans le même processus ou pas, d'ailleurs. BMessage est une classe qui fonctionne comme un conteneur dans lequel on peut ajouter des types primitifs (entiers, chaînes de caractères), des pointeurs, des blocs de données bruts, ou même des objets C++ si la classe implémente BArchivable ou BFlattenable. Toutes les données sont contenues dans le message ce qui évite de gérer manuellement le partage de mémoire entre threads et tous les problèmes de partage de ressources. Les messages peuvent être envoyés et reçus par chaque vue dans une fenêtre. On peut rapprocher ça du système de signaux et slots en Qt, mais l'implémentation est uniquement en C++, là ou Qt a besoin du préprocesseur moc.
Les messages étant un composant central dans la programmation avec la BeAPI, leur implémentation doit être optimisée autant que possible. C'est une des raisons pour lesquelles le noyau de Haiku implémente les "ports", un mécanisme plus bas niveau qui permet l'implémentation des messages de façon plus performante qu'on pourrait le faire avec les seules APIs POSIX. C'est un exemple de l'interêt que l'on a a maîtriser l'ensemble du système dans Haiku, là ou une implémentation utilisant un noyau tiers aurait du soit utiliser une solution plus lente, par exemple avec des pipe ou des sockets unix, soit modifier le noyau en question pour y ajouter un mécanisme similaire aux ports (et soit réussir à le faire accepter aux développeurs du noyau, soit maintenir un fork). Il y a d'ailleurs eu une tentative avec le projet BlueEyedOS de porter la BeAPI sur un système à base de noyau Linux. Ce projet n'est malhereusement plus maintenu.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 10.
Pour les serveurs: non. Haiku est un système destiné uniquement aux ordinateurs de bureau. Il est possible de lancer un serveur web (PoorMan, qui est fourni avec Haiku, ou encore Cherokee, par exemple), mais ça a peu d'interêt.
Pour le bureau, c'est vrai que Linux a fait beaucoup de progrès depuis 2001 et le lancement du projet Haiku. Et du coup, Haiku utilise effectivement du code développé ailleurs, comme freetype, wpa_supplicant, bash, et encore beaucoup d'autres.
Cependant, il y a des différences de taille, comme par exemple l'absence d'un serveur X. Dans le monde Linux/BSD/…, on a souvent des projets qui doivent fonctionner dans plusiurs cas. Le serveur X.org fonctionne aussi bien sur Linux que sur un FreeBSD, par exemple, certaines applications peuvent utiliser GTK 2 ou 3, qui lui-même peut fonctionner avec Wayland ou X, et ainsi de suite. Cela complexifie le code pour tout le monde, oblige à avoir plusieurs couches d'abstraction à tous les étages, et il reste tout de même des différences de comportement entre les différents systèmes. Dans Haiku au contraire, il n'y a en général qu'une façon de faire les choses.
Un deuxième avantage de Haiku est une stabilité des APIs mais aussi des ABIs. Dans le monde de Linux on n'hésite pas à remplacer ou modifier plein de choses dans le système à chaque version. Les logiciels doivent s'adapter en permanence. C'est résolu la plupart du temps par les distributions qui vont essayer de packager un ensemble cohérent de logiciels qui fonctionnent ensemble. Fort hereusement, une très grande partie de ces logiciels sont libres, et peuvent être patchés pour fonctionner correctement. ça représente tout de même beaucoup de travail, et c'est souvent un problème pour intégrer des logiciels distribués uniquement sous forme de binaires. Ces derniers ne pourront fonctionner qu'avec une version bien précise d'une ou deux distributions.
Ceci permet aux applications de mieux s'intégrer dans le système. Citons par exemple les "translators" (traducteurs) qui permettent de décoder des images (png, jpeg, …) sans en connaître le format. Des applications écrites avant l'apparition d'un format donné pourront donc le décoder si le système dispose du traducteur approprié. La même chose est possible pour d'autre types de fichiers (texte, RTF par exemple). Le Media Kit dispose également d'un mécanisme similaire pour le décodage des fichiers sons et vidéo. Là encore, des codecs peuvent être ajoutés au système et toutes les applications pourront les utiliser. Alors c'est vrai, maintenant, sous Linux il y a GStreamer, mais tout le monde ne l'utilise pas.
Dès le début du projet Haiku est prévu pour permettre à certaines applications non-libres de continuer à exister après la disparition de BeOS. à l'époque, il était encore possible que BeOS continue d'exister d'une façon ou d'une autre, donc, le choix de la licence MIT a été fait, ce qui permettrait une éventuelle réintégration du code de Haiku dans une nouvelle version de BeOS. La compatibilité avec ce dernier est assurée (les applications écrites avant 2001 pour BeOS fonctionnent toujours aujourd'hui), même pour les pilotes matériels, qui peuvent être compilés indépendement du noyau. Un exemple d'application non-libre qui fonctionne sous Haiku après avoir utilisé BeOS pendant assez longtemps: http://www.tunetrackersystems.com/
Enfin, au niveau de l'apparence, moi je la trouve très bien. L'interface est compacte et discrète et permet de se concentrer sur ce qu'on fait. Elle est assez équilibrée, quelque part entre Mac OS X qui met des arrondis et des dégradés partout, et Windows 8 qui est quand même très minimaliste.