(je laisse la question des drivers pour la fin ; c'est une question ardue et je n'ai pas envie de m'avancer loin)
Lorsque l'on parle de la connaissance nécessaire du noyau Linux avant de pouvoir s'y attaquer, j'ai l'impression que l'on retrouve un peu la meme (enfoiré d'accent circonflexe qui veut pas passer) problématique avec HURD: une connaissance mais qui se déplace vers les services fonctionnant au-dessus du mirco-noyau.
Bien, en fait, je ne pense pas qu'on parle de la même complexité qu'il y'a à comprendre l'ensemble du noyau Linux. La compréhension globale du fonctionnement de Linux est assez simple : c'est la base d'un point de vue technique et design d'un système d'exploitation, et le design étant celui d'Unix, il est archi-connu, et n'importe qui ayant jamais lu un simple article d'OSDev, ayant suivi quelques cours, etc., le connaitra. Il est vrai qu'une compréhension globale du Hurd est beaucoup plus difficile, dans la mesure où il met en oeuvre des concepts qui ne sont pas si simples (les pagers, les translators, etc.).
Cependant, nous parlions en fait d'une compréhension plus fine du fonctionnement même, *interne* de chaque partie, qui ne doit être requise dans un aussi gros logiciel, si l'on veut permettre une évolution rapide et des temps de développement réduits. Je ne sais pas si tu suis le développement de Linux, mais un des gros problèmes est que régulièrement des bugs importants ne trouvent pas de réelles explications, apparaissent et disparaissent comme ils sont venus, ou sont corrigés après pas mal de recherches, dus aux effets de bord qu'implique les modifications d'une partie d'un tel ensemble sur d'autres parties. De plus, les changements d'interface étant monnaie courante, il faut avoir une assez bonne connaissance pour savoir quelle interface utiliser - laquelle est obsolète, susceptible de disparaître, de changer, etc.. Ce sont les problèmes d'un manque de définition d'interfaces claires et stables, que tente de résoudre le Hurd - et il y réussit bien : il n'y a eu qu'un changement réel d'interface depuis la création, et qui ne concernait que des types (gestion des gros fichiers et 64). Normalement, un programmeur travaillant sur une partie du Hurd ne doit avoir à comprendre que les interfaces des programmes avec lesquels il communique, sauf dans certains cas bien précis. On peut dire que c'est parfois réussi dans Linux, mais avec de très grandes difficultés et dans une certaine mesure - je pense notamment à Netfilter, et les restrictions sont d'Harald Welte lui-même.
Sans vouloir renier l'efficacité de HURD, j'ai un peu peur que ce projet n'arrive pas vraiment à obtenir la faveur des foules. Malgré la qualité de cette approche, elle n'est vraiment intéressante que dans des cas assez précis, dans des environements complexes.
Je pense encore une fois que le problème n'est pas spécifique au Hurd. C'est le problème des innovations à un si bas niveau: ce n'est que pour les personnes ayant un accès direct à ce bas niveau (bien entendu, les développeurs d'applications relativement bas niveaux) et les gens ayant des besoins tout à fait spéciaux (embarqué, temps réel, drivers, des cas très précis effectivement) qui voient réellement les changements de façon évidente. Les autres ne le verront qu'indirectement : on peut dire une meilleure sécurité, dans la mesure où le système de sécurité permet un contrôle plus « fine-grained » (traduction?), les fonctionnalités des translators, des pagers, du scheduling configurable et changeable à merci, des contrats, des contrats de la VMM (on peut dire une augmentation des performances, en particulier dans des applications critiques comme les bases de donnée), la possibilité d'implémenter un système de fenêtrage très puissant (je l'évoquais dans http://linuxfr.org/comments/150869.html(...) ), etc. Malheureusement, si les développeurs d'applications ne l'adoptent pas au début, pour une raison ou une autre, les utilisateurs ne verront pas l'avantage sur des systèmes existants. C'est en même temps l'inconvénient et l'avantage : c'est que dans ce genre de cas, la transition sera aisée (mêmes interfaces, mêmes outils, etc.), mais les avantages pas évidents.
Et ce n'est pas le fait qu'hurd soit 100% GNU qui risque de changer quelque chose chose...
C'est un facteur minime de persuasion, il est vrai. Ça reste quelque chose d'important, ceci dit, dans la protection des logiciels libres (du code pour lequel la FSF détient le copyright ne risque pas d'être relicensé sous une licence pourrie *grin*).
Le succès de HURD viendra surtout avec la base de drivers disponibles. Concernant un portage d'un drivers noyau Linux vers HURD, quelles sont les principales difficultées ?
Urgl. Question difficile. Actuellement, le portage est simple: il s'agit de porter le driver vers Linux 2.0.36 pour GNU Mach 1.x, 2.2.12 pour OSKit (donc GNU Mach 2.x), comme le disait Gaël. Dans la suite des évènements, ce sera différent. Très différent. Ce qui est sûr, c'est que ce ne sera pas une simple adaptation des drivers de Linux, comme c'est dans le cas dans GNU Mach. Une fois n'est pas coutume, je me cite (citant d'autres personnes): http://mdss.free.fr/manuel/ideas(...)
Il s'agit d'un vieux document, peu ou pas remis à jour, qui ne contient que quelques petits éléments, et probablement nombre d'erreurs. Je pense qu'il répondra cependant pas mal à ta question.
[^] # Re: HOWTO
Posté par Manuel Menal . En réponse à la dépêche Article de LinuxFrench sur GNU/Hurd. Évalué à 2.
Lorsque l'on parle de la connaissance nécessaire du noyau Linux avant de pouvoir s'y attaquer, j'ai l'impression que l'on retrouve un peu la meme (enfoiré d'accent circonflexe qui veut pas passer) problématique avec HURD: une connaissance mais qui se déplace vers les services fonctionnant au-dessus du mirco-noyau.
Bien, en fait, je ne pense pas qu'on parle de la même complexité qu'il y'a à comprendre l'ensemble du noyau Linux. La compréhension globale du fonctionnement de Linux est assez simple : c'est la base d'un point de vue technique et design d'un système d'exploitation, et le design étant celui d'Unix, il est archi-connu, et n'importe qui ayant jamais lu un simple article d'OSDev, ayant suivi quelques cours, etc., le connaitra. Il est vrai qu'une compréhension globale du Hurd est beaucoup plus difficile, dans la mesure où il met en oeuvre des concepts qui ne sont pas si simples (les pagers, les translators, etc.).
Cependant, nous parlions en fait d'une compréhension plus fine du fonctionnement même, *interne* de chaque partie, qui ne doit être requise dans un aussi gros logiciel, si l'on veut permettre une évolution rapide et des temps de développement réduits. Je ne sais pas si tu suis le développement de Linux, mais un des gros problèmes est que régulièrement des bugs importants ne trouvent pas de réelles explications, apparaissent et disparaissent comme ils sont venus, ou sont corrigés après pas mal de recherches, dus aux effets de bord qu'implique les modifications d'une partie d'un tel ensemble sur d'autres parties. De plus, les changements d'interface étant monnaie courante, il faut avoir une assez bonne connaissance pour savoir quelle interface utiliser - laquelle est obsolète, susceptible de disparaître, de changer, etc.. Ce sont les problèmes d'un manque de définition d'interfaces claires et stables, que tente de résoudre le Hurd - et il y réussit bien : il n'y a eu qu'un changement réel d'interface depuis la création, et qui ne concernait que des types (gestion des gros fichiers et 64). Normalement, un programmeur travaillant sur une partie du Hurd ne doit avoir à comprendre que les interfaces des programmes avec lesquels il communique, sauf dans certains cas bien précis. On peut dire que c'est parfois réussi dans Linux, mais avec de très grandes difficultés et dans une certaine mesure - je pense notamment à Netfilter, et les restrictions sont d'Harald Welte lui-même.
Sans vouloir renier l'efficacité de HURD, j'ai un peu peur que ce projet n'arrive pas vraiment à obtenir la faveur des foules. Malgré la qualité de cette approche, elle n'est vraiment intéressante que dans des cas assez précis, dans des environements complexes.
Je pense encore une fois que le problème n'est pas spécifique au Hurd. C'est le problème des innovations à un si bas niveau: ce n'est que pour les personnes ayant un accès direct à ce bas niveau (bien entendu, les développeurs d'applications relativement bas niveaux) et les gens ayant des besoins tout à fait spéciaux (embarqué, temps réel, drivers, des cas très précis effectivement) qui voient réellement les changements de façon évidente. Les autres ne le verront qu'indirectement : on peut dire une meilleure sécurité, dans la mesure où le système de sécurité permet un contrôle plus « fine-grained » (traduction?), les fonctionnalités des translators, des pagers, du scheduling configurable et changeable à merci, des contrats, des contrats de la VMM (on peut dire une augmentation des performances, en particulier dans des applications critiques comme les bases de donnée), la possibilité d'implémenter un système de fenêtrage très puissant (je l'évoquais dans http://linuxfr.org/comments/150869.html(...) ), etc. Malheureusement, si les développeurs d'applications ne l'adoptent pas au début, pour une raison ou une autre, les utilisateurs ne verront pas l'avantage sur des systèmes existants. C'est en même temps l'inconvénient et l'avantage : c'est que dans ce genre de cas, la transition sera aisée (mêmes interfaces, mêmes outils, etc.), mais les avantages pas évidents.
Et ce n'est pas le fait qu'hurd soit 100% GNU qui risque de changer quelque chose chose...
C'est un facteur minime de persuasion, il est vrai. Ça reste quelque chose d'important, ceci dit, dans la protection des logiciels libres (du code pour lequel la FSF détient le copyright ne risque pas d'être relicensé sous une licence pourrie *grin*).
Le succès de HURD viendra surtout avec la base de drivers disponibles. Concernant un portage d'un drivers noyau Linux vers HURD, quelles sont les principales difficultées ?
Urgl. Question difficile. Actuellement, le portage est simple: il s'agit de porter le driver vers Linux 2.0.36 pour GNU Mach 1.x, 2.2.12 pour OSKit (donc GNU Mach 2.x), comme le disait Gaël. Dans la suite des évènements, ce sera différent. Très différent. Ce qui est sûr, c'est que ce ne sera pas une simple adaptation des drivers de Linux, comme c'est dans le cas dans GNU Mach. Une fois n'est pas coutume, je me cite (citant d'autres personnes): http://mdss.free.fr/manuel/ideas(...)
Il s'agit d'un vieux document, peu ou pas remis à jour, qui ne contient que quelques petits éléments, et probablement nombre d'erreurs. Je pense qu'il répondra cependant pas mal à ta question.