Article de LinuxFrench sur GNU/Hurd

Posté par (page perso) . Modéré par Pascal Terjan.
Tags : aucun
0
2
déc.
2002
GNU
Vu sur LinuxFrench, une présentation assez succinte et pourtant intéressante du Hurd, faite suite à la conférence de Gaël Le Mignot que nous vous annoncions précédemment.
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.
  • # Re: Article de LinuxFrench sur GNU/Hurd

    Posté par . Évalué à -10.

    Attention la populasse, ca va troller!

    [-1]
  • # Re: Article de LinuxFrench sur GNU/Hurd

    Posté par . Évalué à 6.

    Hurd peut - il être utilisé d'emblée pour en faire un serveur WEB, POP et FTP ?

    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 (page perso) . Évalué à 10.

      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.
  • # Moi j'ai une question !

    Posté par . Évalué à 2.

    Au sujet de L4. J'avais entendu une histoire au sujet de l'utilisation de Pistacho (l'implémentation, encore en dvp, de la dernière version de l'API), qui obligait à signer un contrat de non divulgation (!), ce qui est «légérement» génant pour un projet libre. Ça en est où cette histoire ?
    • [^] # Re: Moi j'ai une question !

      Posté par (page perso) . Évalué à 5.

      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.
      • [^] # Re: Moi aussi j'ai une question !

        Posté par (page perso) . Évalué à 1.

        Ce que j'aimerais juste savoir, car ca reste encore flou à mon avis, c'est si les serveurs HURD ( du moins quelques uns ) peuvent tourner au dessus de L4 en ce moment même.
        • [^] # Re: Moi aussi j'ai une question !

          Posté par (page perso) . Évalué à 4.

          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. (-;
          • [^] # Re: Moi aussi j'ai une question !

            Posté par . Évalué à 0.

            demandez moi point par point! J'adore ça.

            Pourquoi perdre du temps sur Mach ?
            • [^] # Re: Moi aussi j'ai une question !

              Posté par (page perso) . Évalué à 5.

              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 . Évalué à 1.

                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.


                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 (page perso) . Évalué à 1.

                  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.)
                  • [^] # Re: Moi aussi j'ai une question !

                    Posté par . Évalué à 3.

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

                    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 (page perso) . Évalué à 2.

                      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.
                      • [^] # Re: Moi aussi j'ai une question !

                        Posté par . Évalué à 1.

                        Si c'est pour développer L4Hurd en attendant pistachio, t'en as rien à carrer que ce soit rapide, maintenable, compréhensible... tout ce que tu veux c'est qu'en le substituant par pistachio le moment venu, y ait plus qu'à continuer ce qui a été avancé...
                        • [^] # Re: Moi aussi j'ai une question !

                          Posté par (page perso) . Évalué à 1.

                          Oh, si ce n'est que ça, j'ai des sources de Pistachio, merci. :-)
                          • [^] # Re: Moi aussi j'ai une question !

                            Posté par . Évalué à 1.

                            tes petits camarades qui voudraient bien travailler dessus et qui sont pas sous NDA, eux, ils les ont pas...
                            • [^] # Re: Moi aussi j'ai une question !

                              Posté par (page perso) . Évalué à 2.

                              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..
                    • [^] # Re: Moi aussi j'ai une question !

                      Posté par (page perso) . Évalué à 1.

                      Désolé, mais il faut que je reagisse.

                      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 (page perso) . Évalué à 1.

                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 ?
                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 (page perso) . Évalué à 2.

                  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 encore une question !

                    Posté par (page perso) . Évalué à 1.

                    Mais pour des types, qui comme moi, voudraient voir à quoi ca ressemble, car ca me semble tout de même très intéressant, tu ne pense pas que ca peut les dérouter.
                    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 . Évalué à 2.

                      Actuellement, tu auras GNU Mach 1.3. Tu peux installer GNU Mach 1.9 (le futur GNU Mach 2.0 aka OSKit Mach), il "suffit" d'installer OSkit (apt-get sur une deb), de faire un checkout du CVS de GNU Mach et de compiler (la procédure exacte est expliquée sur les mailing lists). Le même système marchera avec GNU Mach 1.3 et GNU Mach 1.9, tu n'as donc pas à réinstaller.

                      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 . Évalué à 0.

        Pour ceux qui ne parle pas courament le "^", 2^15 c'est 1 suivi de 15 zero en binaire. Soit 1 000 000 000 000 000. Ou en decimal 32 768 . Notons que l'emploi d'expression comme 2^15 est vivement encouragé sur l'Internet. En effet "2^15" utilise 2 caractères de moins que "32 768" et çà permet de sauver une bande passante précieuse permettant ainsi aux c0wb0yz de base du web de downloader comme des ouf des mp3 et des xxx cum fuck amateur hot.avi.

        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 . Évalué à 6.

          L'interet principal de compter en 2^15, c'est que tu peux compter sur tes doigts.
          2^15 correspond donc à gros orteil gauche levé et tous les autres doigts baissés.
        • [^] # Re: Moi j'ai une response !

          Posté par (page perso) . Évalué à 1.

          çà permet de sauver une bande passante précieuse

          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 . Évalué à 0.

    il avait été évoqué dans les commentaires de la précédente dépêche concernant cette conférence la possibilité de faire un enregistrement (avec mise en ligne au format ogg bien sûr ;) .

    Est-ce que ça a été fait ? plusieurs personnes dont moi étaient intéressées je crois.
  • # Re: Article de LinuxFrench sur GNU/Hurd

    Posté par . Évalué à 2.

    J'aime bien la critique de Linux : trop compliqué, réservé à une poignée de développeur, ne peut plus évoluer. Ben quand on voit la vitesse de développement de hurd on se demande qui est le plus accessible.
    • [^] # Re: Article de LinuxFrench sur GNU/Hurd

      Posté par . Évalué à 3.

      Et pourtant, ils ont tout-à-fait raison : le code de Linux est de plus en plus difficile à maintenir, mais il y a un nombre très important de gens qui s'en occupe. De l'autre côté, ils sont à peine une dizaine, si j'ai bien suivi.
    • [^] # Re: Article de LinuxFrench sur GNU/Hurd

      Posté par (page perso) . Évalué à 2.

      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.
  • # Re: Article de LinuxFrench sur GNU/Hurd

    Posté par . Évalué à -3.

    Pfff, c'est quoi ce systeme d'exploitation qui ne gere meme pas les partitions de plus de 2GB, et qui part en kernel panique des qu'il manque de swap, c'est pas un OS pour travailler, il est tout juste bon pour s'amuser, alors que la je test LongHorn qui tourne sans aucun soucis, et a vraiment des fonctionnalites interessantes, de plus avec l'avenement de palladium sur les systemes Microsoft j'espere bien voir se reduir l'odieuse pratique du piratage, aussi bien dans les domaines de la musique, que du cinema et du logiciel, et ainsi revenir a de saines pratiques, et helas, je ne vois pas ce genre de fonctionnalites implantes dans THE GNU/HURD, bon d'un autre cote grace aux translators, ca ne devrait pas etre trop difficile a integrer, et ainsi donner une image plus serieuse a cette environnement, qui pour l'instant en l'etat n'est qu'un jouet pour geek.

    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.

  • # HOWTO

    Posté par (page perso) . Évalué à 4.

    Existe t'il un simili "HOWTO porter les applications vers Hurd" ?
    • [^] # Re: HOWTO

      Posté par . Évalué à 2.

      Non, mais tu peux l'écrire après avoir porté quelques applications :)

      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 (page perso) . Évalué à 1.

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

        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 . Évalué à 2.

          Tout dépend de la version de Linux où le driver existe et de la version de GNU Mach pour laquelle on veut le porter.

          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 (page perso) . Évalué à 2.

          (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.
          • [^] # propositions de traduction

            Posté par (page perso) . Évalué à 1.

            fine-grained : à granularité fine tout simplement
            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 (page perso) . Évalué à 2.

              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. :-)
      • [^] # Re: HOWTO

        Posté par (page perso) . Évalué à 2.

        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? =)
  • # Re: Article de LinuxFrench sur GNU/Hurd

    Posté par . Évalué à 1.

    <mavie> C'est Meumeuh qui va être content, avec ma nouvelle machine et sa passerelle, j'ai pas besoin d'attendre pppoeoh (Over Hurd) pour essayer le bidule. </mavie>
    • [^] # Re: Article de LinuxFrench sur GNU/Hurd

      Posté par (page perso) . Évalué à 2.

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

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.