Je ne vois pas bien en quoi un OS complet serait nécessaire. La partie bas niveau ne fais que de gérer le matériel. Je peux imaginer qu'il y a des tweaks différent pour serveur, bureau, smartphone, IoT,... Mais en soit ça ne me paraît qu'être de la configuration.
Alors, en principe oui. Mais ça a en fait des impacts assez profonds sur pas mal de choses. Par exemple, l'ordonnanceur du noyau. Sur un système de bureau, Haiku fait le choix de privilégier les threads qui sont liés à tout ce qui est sortie son et affichage. Pour ce faire, toutes les APIs natives de Haiku pour créer un thread obligent à donner un niveau de priorité, et les niveaux sont nommés ("display priority", "realtime priority", "background priority", etc). Sous Linux, la plupart des logiciels existants n'ont pas ce type d'info, et donc, l'ordonnanceur doit se débrouiller tout seul pour identifier les choses à prioriser, ou bien il faut le configurer à la main avec des fonctions comme nice, et, les valeurs choisies étant arbitraires, chaque application risque de toujours essayer de mettre "plus que les autres" pour passer devant.
On pourrait se dire que pourtant, Linux a plein d'APIs pour configurer des priorités, mais:
For threads scheduled under one of the normal scheduling policies (SCHED_OTHER, SCHED_IDLE, SCHED_BATCH), sched_priority is not used in scheduling decisions (it must be specified as 0).
Donc on oublie, ça ne concerne que les algorithmes d'ordonnancement "realtime". Cela dit, Linux est plutôt bien équipé au niveau de l'ordonnancement realtime, par exemple avec SCHED_DEADLINE, mais ça demande de développer les applications d'une façon bien précise et plus complexe que ce qu'on a l'habitude de faire.
L'ordonnanceur de Linux est très bon pour des sysèmes serveurs ou il faut surtout gérer des connexions réseau et des I/O disque. Pour ce type de tâche, il vaut mieux exécuter les choses pendant plutôt longtemps et faire peu de changements de contexte. Au contraire, Haiku va plutôt changer de tâche plus souvent, pour donner l'occasion à toutes les fenêtres affichées à l'écran de se rafraîchir en une ou deux dizaines de millisecondes par exemple. Dans l'absolu, cela a un coût sur les performances, mais le ressenti est que c'est beaucoup plus réactif.
Est-ce que ce serait faisable sur une base de noyau Linux? Oui, sans doute. Il existe déjà quelques options de configuration du noyau (PREEMPT et PREEMPT_VOLUNTARY) qui vont changer le comportement pour être plus approprié pour un PC de bureau. Mais, comme toutes les distributions Linux actuelles ciblent à la fois le bureau et le serveur, c'est rare de voir ces options activées dans les noyaux proposés.
Voilà, c'était juste un petit exemple en regardant le cas de l'ordonnanceur, il se trouve que je connaît un peu le sujet à la fois dans Haiku et dans Linux. On a le même genre de questionnements avec l'allocation de la mémoire (s¡il n'y a plus de mémoire, sur un PC de bureau on peut afficher un message d'erreur demandant quoi faire, sur un serveur, il n'y aura personne pour répondre, il faut donc se débrouiller tout seul), la sécurité (les problématiques sur une machine de bureau et sur un serveur hébergeant des douzaines de machines virtuelles ne sont pas du tout les mêmes), etc.
Donc, oui, tout est possible, ça serait peut être un peu moins de travail.
Les autres aspects qui ont poussé Haiku à faire ce choix sont:
Le fait d'avoir une seule équipe qui maîtrise tout l'OS, et de ne pas dépendre de quelqu'un d'autre pour le développement du noyau ou d'autres composants essentiels,
Le manque de maturité de Linux (c'était en 2001, aujourd'hui cet argument ne serait probablement plus valable). Pour rappel en 2001 (au tout début de Linux 2.6 pour ceux qui se souviennent): il y avait à peine le support de l'USB, le système de fichier EXT3 n'existait pas encore (alors que BeOS avec BFS disposait déjà d'un système de fichiers journalisé), et plein d'autres problèmes de ce type.
La volonté d'offrir une compatibilité totale avec BeOS, y compris de pouvoir réutiliser les pilotes matériels écrits pour ce dernier (là aussi, si c'était à refaire, Linux a aujourd'hui une bien meilleure liste de pilotes).
Il existe également plusieurs tentatives de réimplémenter quelque chose de proche de BeOS sur une base d'un noyau existant (Linux, BSD, ou même Windows). Aucun de ces projets n'est vraiment actif aujourd'hui. Peut-être simplement parce que ledéfi d'implémenter un nouveau noyau a attiré plus de développeurs, ou peut-être parce que c'était vraiment le meilleur choix technique à l'époque, même si aujourd'hui la décision serait peut-être différente. Cela dit, on entend plus parler de RedOX OS ou de Serenity que de la trente huit millième distribution Linux (même si certaines comme Hello System méritent probablement qu'on y jette un oeuil si on s'intéresse aux systèmes de bureau).
[^] # Re: Incroyable !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Coroutines, histoire d'un nouvel inutilitaire.... Évalué à 10.
Alors, en principe oui. Mais ça a en fait des impacts assez profonds sur pas mal de choses. Par exemple, l'ordonnanceur du noyau. Sur un système de bureau, Haiku fait le choix de privilégier les threads qui sont liés à tout ce qui est sortie son et affichage. Pour ce faire, toutes les APIs natives de Haiku pour créer un thread obligent à donner un niveau de priorité, et les niveaux sont nommés ("display priority", "realtime priority", "background priority", etc). Sous Linux, la plupart des logiciels existants n'ont pas ce type d'info, et donc, l'ordonnanceur doit se débrouiller tout seul pour identifier les choses à prioriser, ou bien il faut le configurer à la main avec des fonctions comme nice, et, les valeurs choisies étant arbitraires, chaque application risque de toujours essayer de mettre "plus que les autres" pour passer devant.
On pourrait se dire que pourtant, Linux a plein d'APIs pour configurer des priorités, mais:
Donc on oublie, ça ne concerne que les algorithmes d'ordonnancement "realtime". Cela dit, Linux est plutôt bien équipé au niveau de l'ordonnancement realtime, par exemple avec SCHED_DEADLINE, mais ça demande de développer les applications d'une façon bien précise et plus complexe que ce qu'on a l'habitude de faire.
L'ordonnanceur de Linux est très bon pour des sysèmes serveurs ou il faut surtout gérer des connexions réseau et des I/O disque. Pour ce type de tâche, il vaut mieux exécuter les choses pendant plutôt longtemps et faire peu de changements de contexte. Au contraire, Haiku va plutôt changer de tâche plus souvent, pour donner l'occasion à toutes les fenêtres affichées à l'écran de se rafraîchir en une ou deux dizaines de millisecondes par exemple. Dans l'absolu, cela a un coût sur les performances, mais le ressenti est que c'est beaucoup plus réactif.
Est-ce que ce serait faisable sur une base de noyau Linux? Oui, sans doute. Il existe déjà quelques options de configuration du noyau (PREEMPT et PREEMPT_VOLUNTARY) qui vont changer le comportement pour être plus approprié pour un PC de bureau. Mais, comme toutes les distributions Linux actuelles ciblent à la fois le bureau et le serveur, c'est rare de voir ces options activées dans les noyaux proposés.
Voilà, c'était juste un petit exemple en regardant le cas de l'ordonnanceur, il se trouve que je connaît un peu le sujet à la fois dans Haiku et dans Linux. On a le même genre de questionnements avec l'allocation de la mémoire (s¡il n'y a plus de mémoire, sur un PC de bureau on peut afficher un message d'erreur demandant quoi faire, sur un serveur, il n'y aura personne pour répondre, il faut donc se débrouiller tout seul), la sécurité (les problématiques sur une machine de bureau et sur un serveur hébergeant des douzaines de machines virtuelles ne sont pas du tout les mêmes), etc.
Donc, oui, tout est possible, ça serait peut être un peu moins de travail.
Les autres aspects qui ont poussé Haiku à faire ce choix sont:
Il existe également plusieurs tentatives de réimplémenter quelque chose de proche de BeOS sur une base d'un noyau existant (Linux, BSD, ou même Windows). Aucun de ces projets n'est vraiment actif aujourd'hui. Peut-être simplement parce que ledéfi d'implémenter un nouveau noyau a attiré plus de développeurs, ou peut-être parce que c'était vraiment le meilleur choix technique à l'époque, même si aujourd'hui la décision serait peut-être différente. Cela dit, on entend plus parler de RedOX OS ou de Serenity que de la trente huit millième distribution Linux (même si certaines comme Hello System méritent probablement qu'on y jette un oeuil si on s'intéresse aux systèmes de bureau).