Les barres de titre peuvent être utilisées comme des onglets. On peut empiler plusieurs fenêtres et passer de l'une à l'autre facilement. Sous BeOS il fallait gérer ça à la main, mais pour Haiku il y a "Stack and Tile" qui permet de laisser le window manager s'en occuper. C'est encore assez récent et peu d'application l'utilisent directement, mais cela devrait remplacer les fenêtres à onglet, par exemple dans le navigateur web ou le terminal.
Pour la DeskBar, quand elle est placée à droite, elle est facilement accessible même quand elle est sous une autre fenêtre, grace au trou laissé par la barre de titre de cette dernière. Avoir une barre verticale permet d'avoir la place pour lister beaucoup plus de fenêtres ouvertes que sur une barre horizontale, ce qui est assez utile quand on utilise le navigateur de fichiers en mode spatial (1 dossier = 1 fenêtre), par exemple.
Le rendu est fait par un thread dédié (pour chaque fenêtre) dans l'app_server. Dans ce cas, le thread de l'application n'accède pas directement à la mémoire écran, il envoie des instructions de dessin au thread correspondant dans l'app_server (via les APIs de BView.
Comme tout le travail de dessin est fait par l'app_server, la façon dont il travaille n'impacte pas l'application. Actuellement, tout est fait dans un buffer de la taille de l'écran qui est ensuite recopié dans la mémoire vidéo. BeOS utilisait les fonctions d'accélération 2D de la carte graphique disponibles à l'époque (tracé de lignes, copie de blocs, remplissage de rectangles, …). Il est théoriquement possible de passer à un fonctionnement avec un compositeur et un tampon mémoire dédié à chaque fenêtre. On y a déjà réfléchi ici, par exemple. Ou encore, on peut utiliser remote_app_server qui fait le rendu sur une autre machine (de la transparence réseau!).
Au passage, BView peut aussi être utilisée pour dessiner dans un BBitmap, ce qui permet de travailler hors mémoire écran, puis d'afficher le bitmap à l'écran plus tard (via une autre BView avec DrawBitmap), de l'imprimer sur papier, de le stocker dans une image PNG (ou autre) via les translators, etc.
Pour OpenGL, tout ceci est court-circuité. On utilise alors BDirectWindow ou BWindowScreen qui permettent un accès direct à la RAM vidéo en empêchant app_server de toucher à la fenêtre en question. Actuellement, on utilise uniquement du rendu logiciel (avec Mesa) pour OpenGL, qui vient donc écrire dans le buffer d'écran directement. Mais pour l'accélération matérielle, BDirectWindow permet d'appeler directement des méthodes de l'accelerant de la carte graphique (partie du driver fonctionnant dans l'app_server et non dans le noyau). C'est ce qui était utilisé sous BeOS pour l'accélération 2D, et ça devrait permettre également l'accélération 3D en ajoutant de nouveaux points d'entrées.
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é à 1.
Les barres de titre peuvent être utilisées comme des onglets. On peut empiler plusieurs fenêtres et passer de l'une à l'autre facilement. Sous BeOS il fallait gérer ça à la main, mais pour Haiku il y a "Stack and Tile" qui permet de laisser le window manager s'en occuper. C'est encore assez récent et peu d'application l'utilisent directement, mais cela devrait remplacer les fenêtres à onglet, par exemple dans le navigateur web ou le terminal.
Pour la DeskBar, quand elle est placée à droite, elle est facilement accessible même quand elle est sous une autre fenêtre, grace au trou laissé par la barre de titre de cette dernière. Avoir une barre verticale permet d'avoir la place pour lister beaucoup plus de fenêtres ouvertes que sur une barre horizontale, ce qui est assez utile quand on utilise le navigateur de fichiers en mode spatial (1 dossier = 1 fenêtre), par exemple.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 6.
Le rendu est fait par un thread dédié (pour chaque fenêtre) dans l'app_server. Dans ce cas, le thread de l'application n'accède pas directement à la mémoire écran, il envoie des instructions de dessin au thread correspondant dans l'app_server (via les APIs de BView.
Comme tout le travail de dessin est fait par l'app_server, la façon dont il travaille n'impacte pas l'application. Actuellement, tout est fait dans un buffer de la taille de l'écran qui est ensuite recopié dans la mémoire vidéo. BeOS utilisait les fonctions d'accélération 2D de la carte graphique disponibles à l'époque (tracé de lignes, copie de blocs, remplissage de rectangles, …). Il est théoriquement possible de passer à un fonctionnement avec un compositeur et un tampon mémoire dédié à chaque fenêtre. On y a déjà réfléchi ici, par exemple. Ou encore, on peut utiliser remote_app_server qui fait le rendu sur une autre machine (de la transparence réseau!).
Au passage, BView peut aussi être utilisée pour dessiner dans un BBitmap, ce qui permet de travailler hors mémoire écran, puis d'afficher le bitmap à l'écran plus tard (via une autre BView avec DrawBitmap), de l'imprimer sur papier, de le stocker dans une image PNG (ou autre) via les translators, etc.
Pour OpenGL, tout ceci est court-circuité. On utilise alors BDirectWindow ou BWindowScreen qui permettent un accès direct à la RAM vidéo en empêchant app_server de toucher à la fenêtre en question. Actuellement, on utilise uniquement du rendu logiciel (avec Mesa) pour OpenGL, qui vient donc écrire dans le buffer d'écran directement. Mais pour l'accélération matérielle, BDirectWindow permet d'appeler directement des méthodes de l'accelerant de la carte graphique (partie du driver fonctionnant dans l'app_server et non dans le noyau). C'est ce qui était utilisé sous BeOS pour l'accélération 2D, et ça devrait permettre également l'accélération 3D en ajoutant de nouveaux points d'entrées.
[^] # 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.