Es-tu en mesure de nous donner un Hurd porté sur une implémentation de L4 disponible au grand public ? Je pense que la réponse devient assez simple.
Je ne pense pas qu'on perde actuellement du temps sur Mach. Il serait inacceptable de jeter ce qui existe déjà au nom du port sur L4 : tout le monde ne peut pas bosser sur la même chose, et si les serveurs de base n'ont pas été fait, on ne peut bosser sur des serveurs plus « haut niveau ». Mais celà fait longtemps que majoritairement rien de très spécifique à Mach n'a été fait autour du Hurd : le développement de GNU Mach lui même est arrêté depuis des lustres, et c'est bien le problème ! C'est aussi la raison pour laquelle on passe à OSKit-Mach (GNU Mach 2.x) maintenant: ça n'est pas en fait parce qu'on travaille sur Mach pour le rendre moins pire, mais principalement parce que personne ne veut y toucher, et qu'on délègue donc la partie essentielle des drivers à OSKit ce faisant.
Il est important de comprendre que si les nouveautés du Hurd aujourd'hui sont dévelopées et testées sur Mach, ça ne veut pas dire qu'elles en dépendent, ou tout du moins de façon significative. La nouvelle console, par exemple, ne dépend absolument pas de Mach - elle a besoin de translators, elle a besoin d'un /dev/mem à mapper (pour le VGA), et de quelques autres choses de l'ordre des outb, mais rien de très spécifique à Mach qui ne puisse être remplacé rapidement. Les Pthreads ont été à l'origine implémentés pour le port du Hurd sur L4, et puis backportés pour Mach. Dans les deux cas, écrire la chose pour L4 aurait empêché d'avancer et de tester, causant beaucoup plus de perte que ne causera le port sur L4 de ces nouveautés.
[^] # Re: Moi aussi j'ai une question !
Posté par Manuel Menal . En réponse à la dépêche Article de LinuxFrench sur GNU/Hurd. Évalué à 5.
Je ne pense pas qu'on perde actuellement du temps sur Mach. Il serait inacceptable de jeter ce qui existe déjà au nom du port sur L4 : tout le monde ne peut pas bosser sur la même chose, et si les serveurs de base n'ont pas été fait, on ne peut bosser sur des serveurs plus « haut niveau ». Mais celà fait longtemps que majoritairement rien de très spécifique à Mach n'a été fait autour du Hurd : le développement de GNU Mach lui même est arrêté depuis des lustres, et c'est bien le problème ! C'est aussi la raison pour laquelle on passe à OSKit-Mach (GNU Mach 2.x) maintenant: ça n'est pas en fait parce qu'on travaille sur Mach pour le rendre moins pire, mais principalement parce que personne ne veut y toucher, et qu'on délègue donc la partie essentielle des drivers à OSKit ce faisant.
Il est important de comprendre que si les nouveautés du Hurd aujourd'hui sont dévelopées et testées sur Mach, ça ne veut pas dire qu'elles en dépendent, ou tout du moins de façon significative. La nouvelle console, par exemple, ne dépend absolument pas de Mach - elle a besoin de translators, elle a besoin d'un /dev/mem à mapper (pour le VGA), et de quelques autres choses de l'ordre des outb, mais rien de très spécifique à Mach qui ne puisse être remplacé rapidement. Les Pthreads ont été à l'origine implémentés pour le port du Hurd sur L4, et puis backportés pour Mach. Dans les deux cas, écrire la chose pour L4 aurait empêché d'avancer et de tester, causant beaucoup plus de perte que ne causera le port sur L4 de ces nouveautés.