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