Manuel Menal a écrit 516 commentaires

Ça n'est pas si évident. Comme les membres des différents ports de Debian - *BSD, GNU/Hurd, .. - l'ont tous successivement évoqué, l'ensemble de la gestion des architectures dans le projet Debian serait à revoir, si l'on souhaite avoir quelque chose qui tienne la route dans le futur, et qui soit en accord avec la vision de Debian - qui ne se veut pas seulement une distribution, et c'est capital. Pour plus d'informations à ce sujet, lire le thread, et le papier de Marcus qui l'a engendré : http://lists.debian.org/debian-bsd/2002/debian-bsd-200202/msg00033.html

Ben l'avenir de hurd, c'est surtout le micro noyau l4. Et sur le portage hurd vers l4, on peut considérer qu'il n'y a q'une seule personne (neil walfield, celui qui a ajouté les pthreads à hurd). Non. C'est extrêmement réducteur. Il est vrai que l'avenir du Hurd est certainement L4 - j'en suis persuadé, et je pense que même Roland McGrath, un des développeurs principaux et originels du Hurd, moins "enthousiaste" que d'autres, l'est maintenant. Mais, il est important de noter que ça ne veut pas dire que ce sera un nouveau Hurd, ni que les parties existantes et développées actuellement seront à revoir. Ainsi, si peu de personnes travaillent directement sur le portage du Hurd sur L4, la majorité des changements faits sur le Hurd actuellement (console+XKB, pthreads, CThread2Pthread, travaux sur shadowfs, ftpfs, ..) sont adaptables, voire adaptés, au Hurd sur L4. De plus, Neal Walfield n'est pas vraiment le seul à travailler sur le port du Hurd sur L4. Bon, les mailing lists de commits étant privées, et les échanges ayant été majoritairement privés dans la première phase de « test », ça ne se voit pas, mais Wolfgang (Jährling, auteur du Hurd Hacking Guide[0], de petits programmes[1], et de patches réguliers) et votre serviteur ont régulièrement contribué au début de code qui a, cependant, été majoritairement écrit par Neal. Ce début de code est celui qui a donné la libpthread; il vaut ce qu'il vaut, mais il a donné à chacun d'entre nous, y compris ceux qui n'y ont pas participé (je pense évidemment à Marcus Brinkmann, notre project leader^W^W^W^H^H) la posibilité de penser aux problèmes, interfaces, choses requises, à repenser les mythes et réalités des avantages comme des difficultés. La majorité sera à reprendre. (les programmes qui permettent de monter un serveur ftp comme un dur par exemple) Si je peux me permettre, plutôt accéder. Il manque vraiment des programmeurs sur le "coeur" (pour ne pas dire kernel) du hurd, histoire par exemple qu'ils ne se retrouvent pas avec 200 types de systèmes de fichiers supportés, mais tous limités à 2Go (comme c'est le cas pour ext2 et jfs en ce moment). Effectivement, il manque du monde. On manque toujours de monde. On manque aussi et surtout de gens motivés pour acquérir les compétences nécessaires à une telle tâche - parce que ça veut dire avoir une vue d'ensemble des buts du Hurd assez importante. Dans le cas de la limite de 2GO (un peu moins, en fait), c'est lié à un problème qui n'a pas été résolu directement à la création du Hurd, en le laissant comme solution temporaire; tant de choses étant arrivées dans le développement du Hurd, le temporaire est resté. Le travail n'est pas forcément très dur : il nécessite une compréhension globale des FS, de la VM, et de la façon de gérer la mémoire de Mach (memory objects, etc.). Il consisterait principalement à réfléchir, en implémentant, les solutions proposées, pour les comparer, voir les problèmes rencontrés, etc. Honnêtement, c'est un projet de fin d'étude tout à fait intéressant, et même un projet en général tout à fait passionnant - vous y êtes donc invités :-p Bon, on continue à faire notre petit tour ;-)

Bon, je sais très bien qu'il est interdit par la Netiquette de corriger les fautes d'orthographe et de français, et je ne me le permettrais pas en temps normal ; mais s'agissant d'un site public et d'une "faute" récurrente que nombre de gens commettent sans connaître la règle, allons-y pour une petite explication, pour la culture.

Baser est un terme d'origine militaire, plus précisément maritime, qui s'emploie pour un bateau, un sous-marin, ou une flotte. L'Académie Française n'accepte pas d'autre sens à « baser », et encore moins le sens figuré qui le rapprocherait de « fonder ». Il n'est donc pas, officiellement, correct d'utiliser baser dans ce sens.

Certes, il s'agit d'un point de détail sans aucune importance, puisque tout le monde comprend et que ça n'apporte aucune confusion, à ma connaissance. Cependant je crois utile que tout le monde connaisse les subtilités du français .. aussi bête que ça puisse paraître, ça peut jouer dans un entretien d'embauche, dans une lettre de motivation, ou que sais-je. Utiliser « fonder » là où le commun des mortels aurait mis « baser » confère une telle classe à votre prose que, si elle a le bonheur de comporter en plus un indicatif suivant « après que », ou, subtilité parmi les subtilités, un « malgré qu'il en ait », votre lecteur en mal de gens de cultivés ne saura rien vous refuser. :-)

Pour plus d'informations, la mine habituelle : http://www.langue-fr.net/index/F/fonder-baser.htm(...) . Je m'excuse de ne pas mettre -1 - mais c'est bien indépendant de ma volonté, soyez-en persuadés.

Hmm, c'est exact. Mais je disais bien que ça ne me semblait pas être une précision essentielle ici, dans la mesure où d'abord l'on précise que les performances sont réellement très limitées, par rapport à un logiciel de virtualisation tel que Plex86, et ensuite où les utilisations présentées sont sans ambiguïté. Enfin bon, il est toujours bon de faire de la pédagogie en distingant les deux.

En passant, outre le « Madrake » qui fait très CRS :-), le Intel 386 de la news me gêne un peu, à l'heure justement où l'on parle du support MMX, SSE, etc. :-) IA-32 m'aurait beaucoup plus convenu, dans la mesure où ils font partie de l'ISA défini pour l'IA-32 dans les documentations à propos du PIV - redéfinissant donc constamment l'IA-32. Bon, ceci dit, se pose ensuite le problème qu'il n'émule pas que ça, donc les I/O devices, le rôle du standard PC, etc. Mais bon, Intel 386 fait vraiment bizarre :-)

Je rajouterai qu'il est également très utile aux gens intéressés par le développement de système d'exploitations qui souhaitent tester aisément, sur du matériel émulé - je ne suis pas persuadé que « simulé » soit plus adaté ici -, au préalable, leur code. Travaillant moi-même sur un noyau et sur des pilotes de périphérique au dessus, il m'est souvent très utile, permettant de tracer les erreurs à l'instruction près, permettant aussi d'avoir des messages de débug spécifiques à Bochs (en utilisant un hack concernant le port 0xE9), de tracer l'utilisation au cycle près, etc., etc., etc. (réellement pratique quand on veut voir combien de cycles prend ce !@# de changement de contexte sans jouer de partout avec du rdtsc ou des trucs du genre.

En ce sens, l'augmentation des performances, si importante et super soit-elle, ne me semble pas un résumé pertinent des changements, dans la mesure où ce serait ne prendre que le point de vue d'une partie des utilisateurs. Les supports MMX, SSE, SSE2, x86-64, un DMA bien[tm], le PCI register, le charmap change, GDB, ont par exemple bien plus de valeur pour moi - et je remercie énormément l'équipe de Bochs pour ça! :-) Ceci n'est bien entendu pas à prendre comme une réelle critique, juste comme un ajout - et puis d'abord, j'utilise Bochs 2.0 depuis le 21, donc j'aurais pu passer la news.

Ah oui, au fait, comme l'indique le ChangeLog, Bochs 2.0.1 est sorti, avec à la clef des bugfixes bien intéressants!

J'abonde dans ce sens en répétant que MacOS X est aujourd'hui un OS non-libre, et vraiment fermé.

Cependant, j'aimerais savoir ce que tu veux dire par et ne venez pas pas parler de darwin, c'est une version allégée et meme pas libre d'une partie de macosx. À ma connaissance, MacOS X inclut directement Darwin, le Darwin libre disponible via CVS par n'importe qui, et ça n'a rien à voir avec une version allégée. Effectivement, il ne s'agit que du coeur de MacOS X, à savoir le kernel, les outils de base (toute la base pour avoir un système compatible Unix classique, en fait. Le côté `Apple', via Quartz, Aqua, etc., n'étant, lui, absolument pas libre). Cela reste une partie intéressante à voir, notamment le support USB. Mais tu as aussi raison de préciser que pour l'instant, Darwin reste non-libre dans la mesure où il oblige tout un chacun à publier les modifications qu'il pourrait faire sur le logiciel.

En revanche, je ne suis pas sûr de ce qui te pousse à dire MacOS X est un des OS les plus fermés, à part un test pour voir si Arnaud lit les news :-)

Et debian/NetBSD, c'est aussi du 100 % ? Mais de quoi ? De BSD ou de GNU ?

Je pense que le monsieur voulait dire une distribution autonome, ce que n'est en aucun cas Fink. Fink se propose juste d'apporter un système à la apt-get pour profiter des logiciels libres habituellement utilisés sous GNU/Linux sur votre MacOS X - ce qui n'est pas si simple, le portage s'avère quelques fois compliqué. Le port de Debian sur NetBSD est bien autonome.

Ou peut-être le monsieur voulait-il dire qu'il s'agit d'un OS 100% libre (au sens des DFSG), ce qui n'est en aucun cas le cas de MacOS X (ni de Darwin), mais ce que le port de Debian sur NetBSD est.

D'ailleurs apt-get fonctionne-t-il sur Hurd ?

Encore heureux. Le port de Debian pour GNU/Hurd est réellement un port de Debian, il contient toutes les composantes habituelles d'un système Debian, dont évidemment apt-get.

translators : traducteurs

Déjà fait, mais je ne peux m'empêcher de trouver le terme anglais plus élégant. J'ai une certaine attirance vers la langue de Shakespeare :-)

pagers : pagineur (beurk)

Oui, peut mieux faire. Pager rend bien :-)

schedulleur : ordonnanceur

Iiirk. Que j'aime pas ça :-)

le Hurd : la Horde :-))

Il existe en fait déjà une traduction que RMS emploie souvent dans les conférences, explications, etc., en français, afin de bien faire comprendre aux francophones le jeu de mot, et les raisons du le, et de la majuscule, etc. : le Troupeau. Bon, on perd un jeu de mot puisqu'on perd l'acronyme recursif double (Hurd -> Hird -> Hurd), et les variations autour de « Herd », mais c'est déjà pas mal. :-)

DMC seulement, je peux te l'assurer. Et tu sors, et tu ne reviens plus.

Oh, je ne l'ai pas pris comme une critique, ça va :-) Je me justifiais peut-être, mais c'était tout juste pour expliquer où ça en est (non, pas DTC, pas DMC, même pas DLCDW).

Et bon courage pour tester. Tu sais où me trouver .. ;-)

Ne penses-tu pas que Thierry Stoehr, membre fondateur de l'AFUL, et secrétaire de l'association, membre reconnu et important de la communauté des logiciels libres francophone, a un peu plus de crédit que n'importe quel inconnu t'envoyant un hoax, ou l'envoyant à un site de news ?

Je rajouterai de plus qu'une personne impliquée dans l'équipe francophone d'OpenOffice.org - chargée de la « pub » :-) - avait rendez-vous le soir du 22 novembre au Ministère pour de telles discussions. Oh, je suis un auteur de hoax aussi, peut-être ? On m'aurait menti ? :-)

C'est effectivement le problème. Mais étant donné que le temps que prendrait d'écrire un µk qui boote et fournisse les interfaces de L4 - notamment sachant que les interfaces définies dans le X.2 ne sont pas assez précises, notamment au niveau des types, des I/O etc. - serait largement supérieur à celui qui nous sépare de la sortie officielle de Pistachio, le jeu n'en vaut pas pour l'instant la chandelle..

Oh, si ce n'est que ça, j'ai des sources de Pistachio, merci. :-)

*sifflote* que quoi comment ? Yé né compRRend pas, yé soui étlanger. *grin*

Bon, sans déconner, tu sais à quel point je déteste faire les choses salement; et le faire avec quelques device_open, un set_filter et des jeux sur l'interface de BPF de Mach aurait été pas très sympathique, et encore moins élégant. Et surtout, ça n'aurait pas été la bonne chose à faire, la bonne solution. La bonne solution, c'était d'avoir des device drivers en user space et une pile TCP/IP bien construire, en user space. Comme le premier m'intéressait, j'ai étudié l'affaire, d'où L4, d'où mon boulot actuel.
Pour le deuxième, le secrétaire d'HurdFr, Olivier conçoit actuellement une toute nouvelle couche réseau qui inclut d'ores et déjà (dans le design) PPPoE.

Comme la mode est de dire que les LL sont plus sécures (ou plus rapides ou plus bidule) que le proprio etc. (ceci dit, j'entend peu de monde critiquer QNX dans le coin) je suppose que le but est d'avoir de fortes exigeances. Comment allez-vous assurer à vos "clients" que vous tenez votre rang ? Comment allez-vous vous l'assurer à vous-même déjà ?

Tu te doutes que c'est aussi un objectif très difficile à atteindre pour un LL. Mais, je ne pense pas que la question s'applique tant que ça. GNU/Hurd doit avant tout être adaptable et modulable: notre fameuse scalability que le « mettable à l'échelle » traduit tellement mal. Dans le cas d'un tel système d'exploitation, il doit pouvoir s'adapter à toutes les situations ou presque. Ceci dit, il n'est certainement pas recommandable d'utiliser le Hurd dans des choses très précises d'embarqué, ou où des performances maximales seront critiques (là où µcLinux, QNX font rire, vraiment). Je ne peux pas franchement te répondre plus.

si la voie de pistachio est bloquée, tout le temps aura été perdu pour rien, il faudra recréer un noyau de toute façon, pourquoi ne pas l'avoir comencé dès le bloquage ? S'il est réellement si petit que ça, il doit pas être long à bootstrapper.

La voie de Pistachio n'est pas bloquée. Elle ne le sera pas. Et, euh, si, justement, le caractère petit le rend peu facile à réaliser. J'en sais quelque chose, à force de tests je finis peu à peu par réécrire un L4-like, et ça n'est pas du tout évident de faire quelque chose de rapide, maintenable, compréhensible, relativement portable, etc. Celà demande déjà énormément de travail à toute l'équipe de L4Ka, et celà demanderait beaucoup de développeurs du Hurd à plein temps - ce que nous n'avons pas.

(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.

Auquel je rajoutrai rapidement un http://www.debian.org/ports/hurd/hurd-devel-debian(...)
que Kilobug devrait mettre à jour, clairement. Entre autres choses ;-P

(et en rédiger rapidement une traduction pour HurdFr. Juste une suggestion, hein? =)

Ni y a-t-il pas tout de même [ sans vouloir troller, ce n'est pas ce que je cherche ] du temps perdu à passer de Mach à OSKit-Mach puis L4, même si bien entendu, certaines partis sont/seront, heureusement, réutilisables ?

Je ne le pense pas. D'abord parce que le passage à OSKit-Mach ne demande pas tant de travail: justement, le code de gestion d'OSKit que Roland a écrit très rapidement - Roland McGrath est aussi un des créateurs d'OSKit - ne fait que 5klignes. L'avantage de ce passage est d'abord qu'il nécessite quelques changements, justement ! La console de OSKit ne suffisant pas à nos besoins, et la console de GNU Mach disparaissant, nous avons hérité d'une nouvelle console absolument sublime - merci marcus.

Ensuite, le peu de travail que ça demande nous rapport beaucoup : en ayant des device drivers plus à jour, on attire plus de gens. Donc plus de gens testent. Et plus de gens sont susceptibles de trouver des bugs dans auth, password, la console, les pthreads, et autres serveurs/bibliothèques qui sont faits pour rester. De plus, celà nous permet d'apporter une plus grande stabilité - malgré tout, les drivers de Linux 2.0.3{6,8} n'étaient pas franchement stables, alors en plus gluecodés .. - et donc de distinguer déjà une part des bugs du Hurd des bugs d'autre part - notamment, de Mach.

Ce n'est pas navrant/démoralisant pour les developpeurs de/du HURD ? Car à ce rythme là, sans vouloir troller, quand le système sera quasiment opérationnel, tout le monde considéra L4 comme obselète [ enfin je n'espère pas ].

Non. L4 ne sera pas considéré comme obsolète de si tôt - je doute qu'on puisse aller plus loin techniquement dans les micro-noyaux (certains parlent déjà de nano-noyaux) sur les architectures actuelles (et oui, je parle bien de toutes les architectures actuelles. L'Itanium, le Power4, etc., n'y changeront rien). L4 a été conçu et écrit en '95, par Jochen Liedtke : celà fait donc 7 ans. C'est bien moins de temps de ce qu'il faut pour qu'une telle technologie soit intégrée dans les grands systèmes, alors dépassée ! Comme je te le disais, il faudra une révolution - une nouvelle architecture tout à fait différente, sans les mêmes conceptions de kernel, etc. (je ne connais même pas de papiers de recherche aboutis à ce sujet).

j'ai déjà doné mon avis là-dessus

Je ne m'en souviens pas.

pour foutre ma merde un peu plus, quid de la qualité ? La notion de plan d'assurance qualité est proscrite (comme linux, apache, openssl etc.) ?

Il va te falloir développer si tu tiens à avoir une réponse. L'assurance qualité est un terme pour le moins général qui peut s'appliquer à nombre de domaines (on parle aussi d'assurance qualité en français pour le QoS que sont censés garantir les contrats de scheduling et de VMM, etc.)

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.

La réponse rapide: non.

La réponse plus longue : non, pas encore. Le portage du Hurd sur L4 dont je parlais est un début de code des serveurs de base qui sont nécessités par le port du Hurd sur L4 : L4 fournissant beaucoup moins de choses que Mach, il laisse une grande liberté au Hurd, en lui déléguant beaucoup de tâches - l'entiéreté de la VMM, du scheduling, de la gestion des tâches, threads, la sécurité de l'IPC, etc. La première étape est donc de concevoir et d'écrire ces serveurs - et c'est loin d'être simple! les choix faits pour la GNU VMM, le scheduler, la sécurité de l'IPC, etc., seront décisifs quant au reste du Hurd.

La seconde phase sera de porter les serveurs existants ne nécessitant pas une réécriture complète - probablement password, auth, ftpfs, hostmux, usermux, iso9660fs, la console (hopefully), etc. Ce sera la phase bien entendu la moins difficile, dans la mesure où ces serveurs ne dépendent pas de façon très importante de Mach - pour beaucoup, ils utilisent des facilités de MiG, par exemple, qui font qu'ils ne manipulent pas les primitives d'IPC de Mach directement, mais le font faire via du stubcode généré automatiquement - il n'y aura donc qu'à changer ces interfaces à partir desquelles sont générés les stubcodes.

Il faut bien comprendre qu'il n'aurait aucun sens de dire que tel ou tel serveur du Hurd peut d'ores et déjà tourner sur L4. Il faudra d'abord implémenter tous les serveurs de base cités ci-dessus, ainsi qu'un port de la GNU Libc - ou en attendant, comme c'est fait actuellement pour le port du Hurd sur L4 - nécessaire pour implémenter le système des translators.

DISCLAIMER: Je ne sais pas dans quelle mesure ce que j'écris est compréhensible ; je suis conscient d'être un peu « dans ma bulle » - un peu trop au goût de mes profs (\o_ Kikoo Christian) :-]. Si ça vous intéresse, et que ça n'est pas compréhensible, demandez moi point par point! J'adore ça. (-;

Mince, j'aurais dû mettre le warning d'usage:

/!\ Ceci ne nécessite aucune connaissance préalable, mais un cerveau en état de marche, et une personne ayant envie de s'en servir /!\

Dommage que y'ait pas de -1.

Oh, c'est en réalité un peu plus compliqué, mais on le résumera simplement par:

The problem is that we need to sign some type of NDA to use Pistachio before there is a public release.

Le problème est récurrent et classique dans le cas des projets universitaires - il n'est pas évident pour un universitaire de releaser du code non fini, notamment parce qu'on peut le retourner contre lui (si bizarre que ça puisse paraître).

Un début de port du Hurd sur L4 existe - environ 2^15 lignes de code. Ça n'est pas beaucoup, et il reste beaucoup de travail. Mais de nombreux pas ont été franchis: d'abord, dans la compréhension de ce que nécessite *vraiment* le port du Hurd sur L4. Ensuite, dans le fait que maintenant tous les développeurs du Hurd sont convaincus de l'intérêt, de la nécessité, de faire ce port. Et, ont été designés à l'occasion de ce port un nouvelle GNU VMM - voir http://web.walfield.org/papers/gnu-virtual-memory-management-system(...) - ont été pensés un nouveau système quant au scheduling (notamment sur la même approche de contrat, et une approche de contrat économique que la VMM). Sans compter que le travail fourni sur le DDF (notamment par votre serviteur).

Neal H. Walfield et beaucoup de développeurs du Hurd, et du peu de développeur de L4Hurd sont actuellement très occupés à poursuivre leurs études. Ce port n'est donc que peu actif actuellement - il reprendra probablement de l'activité avec la sortie officielle de Pistachio, prévue dans maintenant un ou deux mois.

Bon, ça dépend de ce qu'est réellement la question.

Oui, GNU/Hurd peut actuellement faire tourner un serveur web (apache), POP (plusieurs marchent, à ma connaissance, et si votre préféré ne marche pas, il est plus que probable qu'une simple recompilation, et au pire un patch de l'ordre du MAXPATHLEN mentionné en début d'article) suffisent), et un FTPd. Il tiendra une petite charge raisonnablement. Pour te donner une idée, il y'a de ça environ deux ans, un système GNU/Hurd faisant tourner Apache s'était fait slashdotter : le système a tenu tout le temps, mais la pile TCP/IP (pfinet, qui est basée sur la pile TCP/IP de Linux 2.2.14, en gros) a crashé quelques fois, révélant au passage un bug Mach et quelques bugs de la pile - et laissant quelques bugs inexpliqués, mais il faut avouer que pfinet étant en cours de réécriture et de redesign, ça ne nous intéresse guère. Bien entendu, cela pose considérablement moins de problème qu'on pourrait le croire: avec le système des translators passifs, la pile TCP/IP s'est relancée automatiquement, et il n'y a pas plus de dommages que quelques clients qui ont dû reloader. :-)

Ensuite, je serais malhonnête en te conseillant de le faire. Non, GNU/Hurd n'est pas prêt pour être utilisé en production. Celà prendra encore quelques temps - mois? années? ça dépendra de qui vient participer au projet. (je ne peux être qu'optimiste quant à cet avenir: plus le développement avance depuis 1998-99 environ, plus le nombre de développeurs et de projets autour augmentent. espérons que la croissance sera exponentielle) La stabilité est un réel problème - beaucoup du code est jeune, peu testé, et GNU Mach est réellement buggy. De même, beaucoup de code n'est pas optimisé - je pense qu'on peut aisément comprendre que l'optimisation du code du Hurd en lui-même ne soit pas la priorité des priorités right now, et la nature multi-serveurs du Hurd fait qu'en conjonction avec GNU Mach, il y'a une perte de performance significative.

J'avoue que l'emploi du terme « infrastructure » prête à confusion. Bien sûr, dans l'absolu, GNU/Hurd est adapté à ce genre d'utilisation - il présente même d'énormes avantages dans ce genre de situations, notamment avec le système de gestion des privilèges ! Aujourd'hui, dans l'état actuel du projet, il ne l'est malheureusement pas.

Oui, mais il faut dire ce qu'il est: XEmacs sucks. Et de plus en plus.