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