Y sont retracés quelques avantages techniques du Hurd, son historique, et l'état de son avancement.
À lire donc, en complément des slides, si vous n'avez pas pu assister à la conférence ! Notez par ailleurs que les membres de l'association HurdFr, dont Gaël et moi-même, serons ravi de répondre à vos questions, dans la « vraie vie » comme sur IRC, dans les commentaires, ou par mail.
Aller plus loin
- L'article (25 clics)
- La dépêche précédente (7 clics)
- HurdFr (16 clics)
# Re: Article de LinuxFrench sur GNU/Hurd
Posté par Merlin Lenchanteur . Évalué à -10.
[-1]
# Re: Article de LinuxFrench sur GNU/Hurd
Posté par LiNX_ . Évalué à 6.
Possède til une infrastructure suffisante pour etre pleinement exploité pour des services de base comme ceux précédemment cités?
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par Manuel Menal . Évalué à 10.
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.
# Moi j'ai une question !
Posté par JSL . Évalué à 2.
[^] # Re: Moi j'ai une question !
Posté par Manuel Menal . Évalué à 5.
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.
[^] # Re: Moi aussi j'ai une question !
Posté par beny (site web personnel) . Évalué à 1.
[^] # Re: Moi aussi j'ai une question !
Posté par Manuel Menal . Évalué à 4.
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. (-;
[^] # Re: Moi aussi j'ai une question !
Posté par Dugland Bob . Évalué à 0.
Pourquoi perdre du temps sur Mach ?
[^] # Re: Moi aussi j'ai une question !
Posté par Manuel Menal . É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.
[^] # Re: Moi aussi j'ai une question !
Posté par Dugland Bob . Évalué à 1.
j'ai déjà doné mon avis là-dessus
pour le reste, si c'est _réellement_ pas trop dépendant de mach, c'est plein de bon-sens.
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.) ?
[^] # Re: Moi aussi j'ai une question !
Posté par Manuel Menal . Évalué à 1.
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.)
[^] # Re: Moi aussi j'ai une question !
Posté par Dugland Bob . Évalué à 3.
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.
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.)
La qualité c'est la satisfaction du client, quelles que soient ses exigeances (faibles : Windows se vent bien, ou fortes : Ariane 5 pête en vol pour une connerie).
En gros, tu choisis un niveau d'exigeances et tu t'y tiens.
Toute la feinte consiste à appliquer des méthodes qui te permettent de tenir le niveau choisi. Ce que quasiment personne ne fait dans les LL.
Et c'est pour ça qu'on se retrouve avec un vers exploitant une bibliothèque de crypto (comment tu peux affirmer "j'ai pas de faux négatif dans mon controle de certificats" après par ex., soit ta qualité est inégale : on peut pas avoir confiance, soit elle est égale et c'est de la merde de bout en bout).
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à ?
Et la question n'est pas simple, Théo de Raadt c'est déjà planté dessus.
Les méthodes classiques reposent sur une organisation industrielle, les ha><ors de la mort qui tue ont plutôt tendance à la diminuer (pas de doc, code obscur, volonté d'impressioner les grand-parents par leur maîtrise de trucs complètements inutiles), et cette culture est très loin du milieu des LL.
[^] # Re: Moi aussi j'ai une question !
Posté par Manuel Menal . Évalué à 2.
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.
[^] # Re: Moi aussi j'ai une question !
Posté par Anonyme . Évalué à 1.
[^] # Re: Moi aussi j'ai une question !
Posté par Manuel Menal . Évalué à 1.
[^] # Re: Moi aussi j'ai une question !
Posté par Anonyme . Évalué à 1.
[^] # Re: Moi aussi j'ai une question !
Posté par Manuel Menal . Évalué à 2.
[^] # Re: Moi aussi j'ai une question !
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 1.
Le principe de développement des LL, grâce aux libertés offertes par les licences, est que le client peut modifier le logiciel. Bien sûr, les clients/utilisateurs n'ont pas forcément les compétences pour développer, mais ils peuvent influencer le développement : par exemple en demandant des développements plus rapides (cycle release->test_utilisateur->anomalie->release) ou un processus de développement plus sûr (avec des tests de non-regression, des circuits de relecture, des métriques à chaque version, etc.).
Bref, le client est forcément satisfait puisqu'il décide/influence directement. D'après ta definition de la qualité, je serais donc d'avis de conlure que les LL sont un très bon moyen de garantir la qualité d'un logiciel.
Par contre, il est évident que le principe de fonctionnement est différent de celui du monde industriel.
Je pense que tu as tort quand tu pose la question Comment allez-vous assurer à vos "clients" que vous tenez votre rang ? C'est au client de definir la réponse à cette question et de donner les moyens (en participant) d'y parvenir.
Professionnellement, je suis ingénieur dans une SSII (pour le spatial). Nos clients nous bassinent avec la QUALITE mais ils sont bien incapables de mettre une définition derriere ce terme, et ils sont rarement prets à mettre les moyens pour l'obtenir. Du coup, la QUALITE se traduit par d'interminables TRACES (grand terme de la QUALITE) que personne n'exploite et qui incite à TORCHER le code car y'a des rapports à produire et temps nous est compté.
Avec ma petite expérience, la qualité du logiciel est finalement obtenue grâce aux compétences des développeurs plus que grâce aux règles qui sont imposées par des gens qui n'ont plus les compétences de développer (Lois de Peter).
[^] # Re: Moi aussi j'ai une question !
Posté par beny (site web personnel) . Évalué à 1.
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 ].
[^] # Re: Moi aussi j'ai une question !
Posté par Manuel Menal . Évalué à 2.
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 encore une question !
Posté par beny (site web personnel) . Évalué à 1.
Exemple : si je l'installe maintenant ( enfin en réalité je l'installerais que dans quelques semaines ) quel µnoyau j'aurais ? GnuMach ou OSKit-Mach ? Lequel des 2 est le plus opérationnel ?
[^] # Re: J'ai encore une question !
Posté par Gaël Le Mignot . Évalué à 2.
Par contre, la console de Marcus ne marche pas sur GNU Mach 1.9 pour la version se trouvant dans la Debian (il faut la version CVS je crois) et XFree doit être partiellement reporté (l'accès à la carte graphique ayant changé).
[^] # Re: Moi j'ai une response !
Posté par matiasf . Évalué à 0.
PS:
Une définition précise de "c0wb0yz de base du web" peut-être trouvé ici :
http://membres.lycos.fr/azerty0/(...)
[^] # Re: Moi j'ai une response !
Posté par Neryel . Évalué à 6.
2^15 correspond donc à gros orteil gauche levé et tous les autres doigts baissés.
[^] # Re: Moi j'ai une response !
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 1.
Vu qu'il faut un post d'environ 450 caracteres pour expliquer cette representation, je suis pas sur du gain en bande passante ;-)
OK, -1 (des qu'on nous le rendra)
# Enregistrement de la conférence ?
Posté par phq . Évalué à 0.
Est-ce que ça a été fait ? plusieurs personnes dont moi étaient intéressées je crois.
[^] # Re: Enregistrement de la conférence ?
Posté par Gaël Le Mignot . Évalué à 1.
Désolé pour les .ogg, mais personne n'a pu le faire.
# Re: Article de LinuxFrench sur GNU/Hurd
Posté par matiasf . Évalué à 2.
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par Jak . Évalué à 3.
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par Manuel Menal . Évalué à 2.
/!\ 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.
# Re: Article de LinuxFrench sur GNU/Hurd
Posté par Frank-N-Furter . Évalué à -3.
De plus Suse n'en a meme pas fait une distribution, il n'y a que ces intaigriste de debian pour le pakager, vraiment pfff, vraiment quoi !!!!!
Et accessoirement c'est une presentation faite par des guss de l'epita, alors bon ...
Depending on the time of day, the French go either way.
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par philip . Évalué à -1.
p'tain merde mon trollometre est foutu...
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par PloufPlouf (site web personnel) . Évalué à 1.
hehe !!
--
Plouf !
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par Frank-N-Furter . Évalué à 0.
Depending on the time of day, the French go either way.
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par PloufPlouf (site web personnel) . Évalué à 0.
Etre multiserveur, tu devras,
pour vaincre le vilain microsoft
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par Frank-N-Furter . Évalué à 0.
Depending on the time of day, the French go either way.
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par Moby-Dik . Évalué à 3.
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par Gaël Le Mignot . Évalué à 0.
# HOWTO
Posté par Julien CARTIGNY (site web personnel) . Évalué à 4.
[^] # Re: HOWTO
Posté par Gaël Le Mignot . Évalué à 2.
En gros, il y a principalement trois types de problèmes:
* les applications qui utilisent MAXPATHLEN ou autres constantes qui n'existent pas sous GNU; la version plus sournoise étant les applications qui utilisent une constante codée en dur (genre 512), car celles-là compilent mais segfault (voir pire...) parfois lors de l'utilisation
* les applications qui utilisent des fonctionnalités manquantes, comme les locks POSIX sur les fichiers (que Marcus est entrain d'implémenter je crois), ou l'IPC System V, ... dans ce cas, c'est plus chaud. Il faut soit bidouiller l'application pour qu'elles n'utilisent plus ces fonctionalités, soit, mieux, les coder pour le Hurd
* et enfin, les applications qui font ressurgir un bug d'une autre partie du système (de GNU Mach, de la libc, ou du Hurd principalement); dans ce cas, il faut débugguer cette partie, ou au moins faire un bug report aussi détaillé que possible.
Enfin, le mieux, c'est d'essayer avec quelques petits programmes d'abord, et de voir au cas par cas. Bien sûr, l'écriture d'un HOWTO serait une bonne chose :) A vos emacs !
[^] # Re: HOWTO
Posté par Julien CARTIGNY (site web personnel) . Évalué à 1.
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. Ma crainte est de voir HURD rester dans son ghetto, à la manière des *BSD (mes excuses pour cette déclaration trollesque, mais il faut etre réaliste: le nombre d'utilisateurs ne suivent pas la qualité croissante des BSD). Et ce n'est pas le fait qu'hurd soit 100% GNU qui risque de changer quelque chose chose...
[^] # Re: HOWTO
Posté par Gaël Le Mignot . Évalué à 2.
Pour porter un driver de Linux 2.2.x vers GNU Mach 2.0 (aka OSKit Mach), le plus souvent il suffit de recopier le fichier au bon endroit, de rajouter trois lignes dans un fichier de définitions OSKit et de recompiler OSKit. Parfois, quelques fonctions n'existent pas (come schedule_timeout) et il faut bidouiller un peu; mais globalement c'est facile.
Si le driver n'existe que sous Linux 2.4, il s'agit en gros de le backporter vers le 2.2, ni plus ni moins. Maintenant, si on veut porter un driver sur GNU Mach 1.3, c'est à peu près l'équivalent de le backporter pour Linux 2.0, donc ça peut être plus délicat.
Tout ça étant pour GNU Mach, le port sur L4 dépendra du framework de drivers utilisé à ce moment là, qui est encore en cours de défintion (demande à Manuel si tu veux plus d'infos là dessus).
PS: on dit "le Hurd" (donc "du Hurd" et pas "de HURD", merci ;) )
[^] # Re: HOWTO
Posté par Manuel Menal . É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.
[^] # propositions de traduction
Posté par darkleon (site web personnel) . Évalué à 1.
même sens qu'en anglais et utilisé réguliérement dans les articles scientifiques en français (que ce soit en informatique ou en physique).
D'autre proposition en fonction de son attachement à la langue de molière et de l'envie de garder un vocabulaire commun en anglais pour avoir une cohérence dans le discours.
translators : traducteurs
pagers : pagineur (beurk)
schedulleur : ordonnanceur
le Hurd : la Horde :-))
Autrement, bonne chance pour le développement de la Horde.
[^] # Re: propositions de traduction
Posté par Manuel Menal . Évalué à 2.
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. :-)
[^] # Re: HOWTO
Posté par Manuel Menal . Évalué à 2.
que Kilobug devrait mettre à jour, clairement. Entre autres choses ;-P
(et en rédiger rapidement une traduction pour HurdFr. Juste une suggestion, hein? =)
# Re: Article de LinuxFrench sur GNU/Hurd
Posté par Pierre Tramo . Évalué à 1.
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par Manuel Menal . Évalué à 2.
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.
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par Pierre Tramo . Évalué à 1.
Fais gaffe, tu fréquentes trop kb. :P
Pkus sérieusement, je vais vraiment penser à charger une iso un des ces jours pour essayer. Advienne que pourra.
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par Manuel Menal . Évalué à 1.
Et bon courage pour tester. Tu sais où me trouver .. ;-)
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par pasBill pasGates . Évalué à 1.
DTC ou DLCDW ?
Bon ok --> []
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par Manuel Menal . Évalué à 1.
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par Pierre Tramo . Évalué à 1.
Hem, nan, j'ai rien dit.
[^] # Re: Article de LinuxFrench sur GNU/Hurd
Posté par Gaël Le Mignot . Évalué à 1.
C'est censé vouloir dire quoi, ça ?
[-42]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.