GNU/Linux est mort, vive GNU !

Posté par  . Modéré par orebokech.
Étiquettes :
0
13
mar.
2002
GNU
La FSF a annoncé qu'une version utilisable en production du Hurd sortirait dans le courant de l'année 2002.

Et Richard Stallman de rajouter dans une interview à PCWorld : "We actually have the GNU kernel working, and we can now produce the GNU system, as opposed to the GNU/Linux system that people have been using so far". (TdM: "Le kernel GNU fonctionne, et nous sommes maintenant en mesure de produire le système GNU, par opposition au système GNU/Linux que les gens utilisaient jusqu'à maintenant".)

La mort annoncée de GNU/Linux ?

Note du modérateur : j'ajoute les liens vers l'interview en question et vers Hurdfr.org. La news originale contenait un lien vers OSNews qui semble cassé, je le remplace par un lien vers Slashdot.

Aller plus loin

  • # Retour vers le futur

    Posté par  (site Web personnel) . Évalué à 10.

    The Hurd kernel of FSF's GNU system is more powerful than
    Linux because it is designed using a microkernel instead of a
    monolithic architecture, Stallman said.


    C'est marrant, j'ai deja entendu ca :)
    • [^] # Re: linux is obsolete

      Posté par  . Évalué à 4.

    • [^] # Re: Retour vers le futur

      Posté par  . Évalué à 10.

      Tout dépend de ce que l'on veut dire par "more powerful", mais d'un certain point de vue, un µnoyau est quand meme très intéressant !

      Sans vouloir relancer le tro^H^H débat, le noyau Linux se fait quand meme de plus en plus volumineux...
      • [^] # Re: Retour vers le futur

        Posté par  . Évalué à -10.

        > le noyau Linux se fait quand meme de plus en plus volumineux...

        prend une distribution qui utilise un 1.2.x si c'est un critere important et que t'as pas 50 Euro pour 256 Mo.

        Ca me souale ces gnagna gnagni... Ces gus jamais content alors qu'ils ont pour gratos le top (ou presque).
        • [^] # Re: Retour vers le futur

          Posté par  . Évalué à -2.

          Et tu les place ou tes 256Mo sur ton grille pain ?

          Y a pas que les 'PC' qui font tourner Linux... Et puis on ne parle pas des applications autour de Linux qui sont lourdes : on parle du noyau...
          • [^] # Re: Retour vers le futur

            Posté par  (site Web personnel) . Évalué à 10.

            Evidemment, si tu prend le code source de linux avec les drivers de plein de périphériques, c'est énorme, mais le 2.4 prend moins de place qu'un 2.2 en mémoire... (avec les mêmes pilotes de périphériques...), de même, il est plutôt plus rapide... donc... je vois pas trop d'où vient le problème.
            • [^] # Re: Retour vers le futur

              Posté par  . Évalué à 0.

              Le probleme, c'est que si on suit la tendance actuelle, et en exagérant un peu, on va finir par se retrouver avec emacs dans le noyau !

              Note que j'aime bien emacs, et que ca serait pas mieux avec vi, mais la conception des µnoyaux découpe plus, et ne met normalement en mode noyau que le strict nécessaire, et ca, c'est a priori une bonne idée (d'un point de vue propreté / stabilité, pas forcément performances).
              • [^] # Retour vers le futur IV

                Posté par  . Évalué à 8.

                Le HURD est bientôt là....
                Il y a 10 ans, c'était l'arlésienne, la vaporware hypothétique de demain loin-là-bas...
                On l'appellait pas encore "LE" hurd, mais simplement HURD. gcc, emacs, c'était pour les affranchis. Désormais, tout le monde les utilise, alors le monde est mûr pour HURD.

                Le simple fait qu'il parvienne à éclore, c'est déjà la réalisation d'un rêve.

                HURD et Linux ne sont pas ennemis mais frères, un peu différents, comme tous les frères qui ne sont pas jumeaux. HURD est plus vieux, encore immature, et Linux est le petit frère précoce qui n'en veut.

                Celui qui prétend le contraire n'a quà répondre à la question suivante: Avec quoi fut compilé Linux le premier jour ? GCC.
                Qu'est-ce que gcc ? La première fondation du GNU HURD.

                Demain ne peut être que meilleur, car HURD est sur le point de naître. La liberté gagne la terre et vaincra
              • [^] # Re: Retour vers le futur

                Posté par  . Évalué à 1.

                Linus déteste emacs (et Stallman et et les unoyaux (donc Hurd) comme tout le monde sait), donc ca m'étonnerait vraiment que le noyau de Linux se mettent à ressembler à Emacs. Le noyau officiel est très nettement conservateur et seule les fonctionnalités que Linus trouve vraiment importantes sont ajoutées, contrairement à la branche maintenu par Alan Cox.
                • [^] # Re: Retour vers le futur

                  Posté par  . Évalué à 4.

                  Le noyau officiel est très nettement conservateur et seule les fonctionnalités que Linus trouve vraiment importantes sont ajoutées,

                  Sauf que Linus a parfois des goûts très bizarres: un serveur Web dans le noyau, un changement de VM en plein milieu d'une branche stable, refus d'intégrer des patchs pour le PCI 64-bits ou les nouvelles normes ATA, intégration de ReiserFS dans le 2.4.1 qui devait ne contenir que des bugs fixes, ...

                  Je respecte beaucoup Linus et je trouve que globalement il fait du très bon boulot, mais il commet aussi parfois de grosses erreurs AMHA, et son obstination à dénigrer les micro-noyaux et le Hurd frise parfois le ridicule (par exemple sur le coup du MAP_COPY où il reproche à l'équipe du Hurd quelque chose qui est lié à GNU Mach et non au Hurd)
        • [^] # Re: Retour vers le futur

          Posté par  . Évalué à 1.

          Euh, mettre 256Mo sur mon 486 qui fait Gateway ou sur mon Amiga 1200, c'est un peu plus cher que 50Euros, et un peu moins facile aussi.....
    • [^] # Re: Retour vers le futur

      Posté par  . Évalué à -5.

      The Hurd kernel of FSF's GNU system is more powerful than Linux because it is designed using a microkernel instead of a monolithic architecture, Stallman said.

      Puissant => bouffe plus le CPU => plus lent ;)
      • [^] # Re: Retour vers le futur

        Posté par  . Évalué à 10.

        Lis les docs que l'on trouve sur http://www.l4ka.org/publications/(...) et en particulier http://os.inf.tu-dresden.de/pubs/sosp97/(...) et tu verras que les performances d'un système à base de micro-noyau ne sont pas nécessairement beaucoup plus faibles que celles des systèmes à base de noyau monolithique.
        • [^] # Re: Retour vers le futur

          Posté par  . Évalué à 6.

          En l'occurence, pour l'instant, sur un système "monolithique" du genre PC, entre Linux et Hurd, pour l'instant y'a pas photo ...

          Par contre sur une machine bien parallèlle, peut être que la tendance s'inverse.

          Mais comme aujourd'hui la plupart des systèmes que l'on rencontre sont des PC ...
          • [^] # Re: Retour vers le futur

            Posté par  . Évalué à 10.

            Euh... lis les articles justement. Un simple port brutal de Linux sur L4 ne donne que 5% de perte de performances, alors que ce port n'utilise pas les capacités particulières des micro-noyaux, et que ce test a été réalisé il y a longtemps et que beaucoup de progrès sur l'IPC ont été fait dans L4 depuis.

            Actuellement le Hurd est plutôt lent car non optimisé (par contre les développeurs savent comment faire pour l'optimiser, ce n'est pas la priorité c'est tout) et qu'il utilise GNU Mach, qui n'est pas non plus un modèle de vélocité.

            Mais à terme, lorsque le Hurd sera sur L4, la différence de vitesse entre GNU et GNU/Linux devrait être négligeable, surtout comparé à tout ce que GNU apporte (et à la puissance des machines qui s'accroit sans cesse, le CPU étant rarement le facteur limitant d'une machine)
            • [^] # Re: Retour vers le futur

              Posté par  (site Web personnel) . Évalué à -1.

              De plus, sur ce qui a été précisé au dessus , la plus part des kernels linux utilisé sont modulaires, et non monolythique ...

              est ce que le modulaire et le monolythique sont aussi rapide ?

              @++
              Code34
              • [^] # Re: Retour vers le futur

                Posté par  . Évalué à 10.

                Le noyau Linux est monolithique dans le sens où en mémoire le noyau est un seul gros programme qui tourne en mode noyau, et où un bug dans un module noyau peut avoir des conséquences sur tout le reste du noyau. Par contre c'est un noyau modulaire, puisqu'il est possible de charger/décharger des modules en cours d'exécution (Linux est donc monolithique modulaire).

                D'un point de vue performances, il y a un très léger surcoût à utiliser des modules, de l'ordre de quelques cycles CPU par appel système se trouvant dans un module (la valeur exacte se trouve dans "Le noyau Linux" de chez O'Reilly, je pourrais regarder chez moi), mais concrètement c'est totalement négligeable (sachant qu'un kernel trap a déjà un coût moyen estimé d'environ 170 cycles, sans compter le traitement de l'appel système, les quelques cycles de plus ne sont vraiment pas importants).
    • [^] # Re: Retour vers le futur

      Posté par  . Évalué à 1.

      Monolithique mais très modulaire !!
      Donc si t'as pas besoin, tu prends pas.

      Je pense que la taille du noyau n'est pas un critère puisque ce qui ne sera pas dans le noyau pour HURD, le sera dans un module en mode user.
      • [^] # Re: Retour vers le futur

        Posté par  . Évalué à 10.

        Oui, mais c'est une différence de taille.
        Un programme sans bugs ça n'existe pas. Un plus un programme est gros, plus il a de risques d'être buggué (à toutes autres choses égales). Donc plus tu as de code qui s'exécute en mode noyau, plus tu as de bugs potentiels en mode noyau. Or, un bug d'un programme s'exécutant en mode noyau peut avoir des conséquences gravissimes, allant du plantage au trou de sécurité, en passant par la corruption de données, voir des dégâts sur le matériel dans des cas extrêmes.

        Dans le cas du Hurd où on a une collection (un troupeau ;) ) de serveurs indépendants qui tournent en mode utilisateur, un bug dans l'un de ces serveurs a des conséquences beaucoup plus réduites sur le système en général. Sans compter que pour débugguer un module noyau c'est beaucoup plus compliqué qu'un serveur du Hurd, qui lui se débugue comme un programme normal avec gdb, la libefence et autres.

        Mettre un "module" en mode noyau, c'est jouer avec le feu, c'est lier le sort du système entier au sort du programme, et c'est donc à éviter autant que possible.
        • [^] # Re: Retour vers le futur

          Posté par  (site Web personnel) . Évalué à -5.

          C'est pas vraiment fonction de la taille c'est fonction de la compléxité.
          Par exemple, faire un petit tableur en assembleur modulaire aura surement plus de bug qu'un intégré à la xxxxx office. Et la complexité vient avant tout de la conception.

          Le débat est vieux d'au moins 10 ans:
          http://www2.educ.umu.se/~bjorn/mhonarc-files/obsolete/msg00000.html(...)
          Je ne dirais qu'une chose à propos de Linux :
          et pourtant il tourne.


          De toute façon, GNU n'est pas un logiciel, c'est au mieux une secte
          • [^] # Trop gros, passera

            Posté par  . Évalué à 2.

            De toute façon, GNU n'est pas un logiciel, c'est au mieux une secte


            ................_---________---__________.............................
            ...............|..........PLEASE.........}............................
            ...............|.........................}............................
            ............../....DO.NOT.FEED.THE.TROLL.\............................
            ..............\____....................__/............................
            ...................-------------------`...............................
            ...........................|#:|.......................................
            ...........................|#:|.......................................
            ...........................|#:|.......................................
            ........................\\\|#:|/./....................................
            ............~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.......................


            -1
        • [^] # la guerre des kernels

          Posté par  . Évalué à 8.

          Personnellement, du point de vue de la rapidité, je ne pense pas qu'il puisse y avoir une différence flagrante.

          Je vois cependant un avantage MAJEUR aux microkernels : rappelez des OS du style BE, dans le repertoire utilisateur, on peut charger ses modules, qui fonctionnement en mode utilisateur, j'avais adoré ca. si le module deconne, on efface.
          C'est idéal pour tester une config pour eventuellement la valider et généraliser le module qu'on aura préalablement testé en faisant un simple copier-coller en root. Les utilisateurs pourront choisir les modules de leur choix et chaque utilisateur pourra avoir son hurd perso.
          C'est quand même assez génial à mon avis.

          Je vois un inconvénient, cependant. Si les modules utilisateurs sont trop nombreux, ils peuvent peut-être vite encombrer la ram, non ?
          Si quelqu'un est plus éclairé que moi sur le sujet, j'aimerais bien qu'il m'explique.

          Je pense donc que les microkernels c'est assez génial, je ne sais pas quels seront les inconvenients.... il n'y a rien a voir entre un petit BeOS et un gros serveur linux...
          • [^] # Re: la guerre des kernels

            Posté par  . Évalué à 6.

            Personnellement, du point de vue de la rapidité, je ne pense pas qu'il puisse y avoir une différence flagrante.

            Si on ne fait pas attention, si, l'échange de messages entre les différents serveurs peut venir devenir très très couteux. Mais en prenant quelques précautions, en implémentant l'IPC de manière performante, ... on arrive à réduire grandement les pertes.

            Si les modules utilisateurs sont trop nombreux, ils peuvent peut-être vite encombrer la ram, non ?

            En théorie oui, sans doute, mais les serveurs sont des programmes normaux qui peuvent être swappés s'ils ne sont pas utilisés par exemple, et puis comparé aux couches types Gnome-VFS ou kioslave qui sont nécessaires sous Linux pour avoir des fonctionnalités équivalentes, ça me semble quand même beaucoup plus léger.
        • [^] # Re: Retour vers le futur

          Posté par  (site Web personnel) . Évalué à 5.

          "plus un programme est gros, plus il a de risques d'être buggué"

          Je suis d'accord mais si l'on veut comparer Linux et le Hurd, je suppose qu'il faut comparer la quantité totale de code, et si les deux sysèmes doivent remplir les memes fonction, ils doivent representer plus ou moins la meme quantite de code donc de bugs...

          Alors il est vrai qu'un bug dans un des serveurs du Hurd ne compromet que ce serveur, pas le système entier, alors que pour le noyau Linux, c'est tout le systeme qui se vautre. Certes. Mais AMHA le probleme est peu different : dans tous les cas il faut corriger le bug ou le service en question ne marchera pas. Alors redemarrer juste le service au lieu du systeme entier, c'est pas la solution miracle. Et puis en ce qui me concerne, j'ai rencontré beaucoup plus de bugs dans les programmes user space (donc que l'on peut redemarrer simplement sans rebooter) sous Linux que de bugs liés au noyau lui-meme et aboutissant a un reboot violent, donc l'architecture actuelle de Linux et le fait qu'il tourne en mode noyau ne me parait pas etre un problème si sérieux, et le fait que le Hurd utilise des serveurs et pas le mode noyau ne me parait pas non plus etre l'arme supreme... Enfin bon je demande à tester :o)
    • [^] # RMS est mort, vive Linus

      Posté par  . Évalué à -7.

      Les micros noyau, ca pue
      Hurd = 10 ans de développement et toujours pas pret
      Linux = Pret en moins d'1 an, fonctionnel en une poignée d'années
      Le but d'un micro-noyau c'est surtout pour les développeurs, possibilité de développer des modules en mode utilisateur, possibilité d'avoir des systèmes de fichier en tournant en mode utilisateur, ...
      Le problème c'est que si le passage de messages et la communication entre les processus rend le développement tellement compliqué qu'il multiplie le temps de développement par 10 je vois pas trop l'intéret pour les développeurs d'utiliser un m icro-noyau.
      De plus rajouter des interfaces et des couches d'abstraction c'est peut-etre beau sur le papier, mais à chaque fois ca entraine des chutes de performance terribles. Certes il y aura toujours des articles pour dire que la perte de performance n'est pas si terrible que ca, mais il y a toujours des articles pour dire n'importe quoi. Il suffit de se baser sur certaines mesures précises pour prouver ce qu'on veut prouver. Personnellement Java => ajout d'un couche d'abstraction (vm) => super long. De meme le fait que X est un processus dans l'espace utilisateur est certe une très bonne chose niveau conception (et je pense que pour le coup on a eu raison) cependant, je trouve qu'un des seules avantages de windows sur Linux est justement d'etre plus rapide au niveau de l'affichage (car le système de fenêtrage et justement dans le noyau). Et pour les micros noyaux, c'est encore le meme probleme, belle conception en apparence => chute de performance. Les belles idées sur le papier on a vu ce que ca a donné avec le communiste et apparemment on peut généraliser à pas mal de domaine la leçon. Le seul micro noyau que j'ai utilisé pour l'instant est minix (qui est nettement plus long que linux), mais j'ai des copains qui ont utilisés Hurd et Mac OS X et il m'ont dit que les performances étaient moins bonne que sur les OS monolithiques.
      De plus j'ai lu qq part que de toutes facon on n'avait de plus en plus de ressources processeurs et donc que les performances n'étaient pas si primordiales que ca. Cet argument est l'argument (récurrent) e plus débile de l'histroire de l'informatique. On aura _jamais_ trop de ressource et donc on se doit de concevoir les systèmes le plus efficacement possible.
      Quand à la modularité, avec Linux on a la modularité au niveau du source. De plus les modules ne constituent pas du rafistolage mais plutot le juste milieu.

      D'ou ma conclusion :

      Hurd ne remplacera _jamais_ Linux car si Hurd devait triompher Hurd aurait _déjà_triompher. N'en déplaise à Stallman et à son égo surmesurer.
      • [^] # Re: RMS est mort, vive Linus

        Posté par  . Évalué à 8.

        Les micros noyau, ca pue

        Ca c'est de l'argumentation ! Chapeau !

        Hurd = 10 ans de développement et toujours pas pret

        Le développement Hurd a été (presque) complètement stoppé pendant des années, c'est 1999 que Marcus l'a relancé.

        Le problème c'est que si le passage de messages et la communication entre les processus rend le développement tellement compliqué qu'il multiplie le temps de développement par 10 je vois pas trop l'intéret pour les développeurs d'utiliser un micro-noyau.

        Le passage de messages ne complique pas vraiment le développement, mais par contre le fait d'avoir des programmes en user-space normaux que l'on débugguer avec gdb, qui n'obligent pas à redémarrer la machine lors d'un segfault, ... augmente nettement la facilité de développement.

        mais à chaque fois ca entraine des chutes de performance terribles.

        Tu as lu les autres commentaires sur cette page ? Tu es allé voir les articles sur L4Linux, L4KA et les techniques d'optimisation de l'IPC ? Alors renseigne-toi avant de parler et de sortir des arguments bidons que tu as lu l'aveille sur /. Et crois-moi, je ne dis pas ça pour être méchant, vu que ce genre d'arguments je les sortais il y a quelques mois avant que je ne me renseigne vraiment sur la question (j'ai un peu honte de moi maintenant mais bon... errare humanum est)

        mais j'ai des copains qui ont utilisés Hurd et Mac OS X et il m'ont dit que les performances étaient moins bonne que sur les OS monolithiques.

        Encore une fois, lis ce qui a été dit ici. Le Hurd n'est pas optimisé pour l'instant. Les développeurs savent où sont les principales lacunes, savent comment y remédier, mais ce n'est pas la priorité. Pour Mac OS X c'est plus la couche Quark/Aqua qui rame que Darwin.

        Quand à la modularité, avec Linux on a la modularité au niveau du source. De plus les modules ne constituent pas du rafistolage mais plutot le juste milieu.

        Tu as lu tout ce que Manuel Menal et moi (entre autres) avons dit sur les possibilités du Hurd ? Comment tu fais le translator FTP + Hostmux sous Linux ? Ou le générateur de fortune ? Ou le serveur Apache qui n'a jamais besoin des droits root pou binder le port 80 ? Ou le serveur FTP non anonyme qui n'est pas suidé root ? Et le fait qu'un bug dans un module fasse cracher la totalité du système ? Alors relis tout ce qu'on a dit sur cette page avant de sortir des phrases toutes faites comme ça.

        Hurd ne remplacera _jamais_ Linux car si Hurd devait triompher Hurd aurait _déjà_triompher. N'en déplaise à Stallman et à son égo surmesurer.

        Le but du Hurd n'est pas de remplacer Linux, mais de proposer une alternative mieux conçue et plus puissante. Quand à la personnalité de RMS, déjà je ne suis pas du tout d'accord avec ton jugement sur lui, et en plus je ne vois pas ce qu'il a à voir que le Hurd.
        • [^] # Re: RMS est mort, vive Linus

          Posté par  . Évalué à -1.


          >>Les micros noyau, ca pue
          >Ca c'est de l'argumentation ! Chapeau !

          L'argumentation vient après. On t'a pas appris quand tu étais petit qu'il fallait commencer les paragraphes avec l'idée principale est l'argumenter après.


          Le développement Hurd a été (presque)
          complètement stoppé pendant des a
          nnées, c'est 1999 que Marcus l'a relancé.


          Justement ca montre bien que les micros noyaux rendent la conception plus difficile. Je ne pense pas que les développeurs HURD soient des brels, alors s'ils se sont découragés c'est bien que ca devait etre difficile.


          Et crois-moi, je ne dis pas ça pour être méchant, vu que ce genre d'arguments je les sortais il y a quelques mois avant que je ne me renseigne vraiment sur la question (j'ai un peu honte de moi maintenant mais bon... errare humanum est)

          Et oh, faut pas etre gentil comme ca, une réputation de trolleur ca ce travail ;)


          Le Hurd n'est pas optimisé pour l'instant. Les développeurs savent où sont les principales lacunes, savent comment y remédier, mais ce n'est pas la priorité

          La performance n'est pas une priorité, je crois réver. La performance devrait toujours etre une priorité.


          Tu as lu tout ce que Manuel Menal et moi (entre autres) avons dit sur les possibilités du Hurd ? Comment tu fais le translator FTP + Hostmux sous Linux ? Ou le générateur de fortune ? Ou le serveur Apache qui n'a jamais besoin des droits root pou binder le port 80 ? Ou le serveur FTP non anonyme qui n'est pas suidé root ? Et le fait qu'un bug dans un module fasse cracher la totalité du système ? Alors relis tout ce qu'on a dit sur cette page avant de sortir des phrases toutes faites comme ça.

          Ces fonctionnalités sont interessantes au niveau de la sécurité et du développement, mais bon je préfère un système ou l'on prend plus de risque et on l'on favorise avant tout les performances. De la même facon je préfère coder en C qu'en Java. Certes en java il y a un demi milliards de mécanismes pour prendre des précautions qui n'existe pas en C. Un code C a ainsi beaucoup plus de chance de planter à l'exécution qu'un code Java. Mais il est aussi beaucoup plus rapide (Je sais je n'aurais pas du prendre l'exemple de Java car la lenteur est principalement du à la vm, mais j'ai assez peu d'expérience avec le C++). Et les tests ca existent. La communauté Linux jouent sur la rapidité de développement et le feed back rapide des problèmes pour avoir un système sur et sécurisé. Je préfère cette approche que l'approche : on prend énormément de précaution et on optient une chute de performances.


          Quand à la personnalité de RMS, déjà je ne suis pas du tout d'accord avec ton jugement sur lui, et en plus je ne vois pas ce qu'il a à voir que le Hurd.

          Tu ne vois pas ce qu'il a avoir avec le Hurd !!!????!!?!. Le système GNU ca te dit qqchose ? Le Hurd est le noyau officiel du système, pas Linux. Et Stallman est bien verreux que Linux (ou Linus si tu préfère) lui ait piqué la chandelle : les messieurs tout le monde dans la rue connaissent moins stallman que Linus.
          • [^] # Re: RMS est mort, vive Linus

            Posté par  . Évalué à 2.

            Je ne pense pas que les développeurs HURD soient des brels, alors s'ils se sont découragés c'est bien que ca devait etre difficile.

            Non, c'est parce qu'il y avait déjà Linux et que la priorité n'était donc plus au niveau du "noyau".

            La performance n'est pas une priorité, je crois réver.

            Et ben non, quand tu développes un programme tu commences par le faire robuste et fiable, et après tu optimises. L'optimisation de l'implémentation n'est pas une priorité dans le début du développement d'un programme.

            mais bon je préfère un système ou l'on prend plus de risque et on l'on favorise avant tout les performances.

            T'es bouché ou tu le fais exprès ? La perte de performance peut être dimunée au point d'être négligeable ! Pendant que tu y es aussi on fait tourner en mode noyau sans protection mémoire ni rien pour économiser un peu de perf ? Et compare des choses qui sont comparables STP, un micro-noyau c'est beaucoup moins lourd et coûteux qu'une JVM et ça apporte beaucoup plus AMHA.

            Tu ne vois pas ce qu'il a avoir avec le Hurd !!!??

            Ce n'est pas RMS qui contrôlle le Hurd, qui prend les décisions de design ou autres. Il ne participe même au code IIRC. Quand a ton mépris pour RMS, ça ne concerne que toi et je ne partage pas du tout ton avis. Si tu n'as pas compris que les différents entre RMS et Linus sont plus idéologiques qu'autre chose (RMS défendant le logiciel libre pour des raisons éthiques, Linus ne s'intéressant qu'au côté technique), et bien c'est dommage.
            • [^] # Re: RMS est mort, vive Linus

              Posté par  . Évalué à 1.


              un micro-noyau c'est beaucoup moins lourd et coûteux qu'une JVM et ça apporte beaucoup plus AMHA.


              C'est vrai. Mais le problème de base reste le meme : en ajoutant des couches logiciels on s'éloigne du hard et on perd en performance.


              Si tu n'as pas compris que les différents entre RMS et Linus sont plus idéologiques qu'autre chose (RMS défendant le logiciel libre pour des raisons éthiques, Linus ne s'intéressant qu'au côté technique), et bien c'est dommage.

              Bien sur que je connais les différents idéologique entre le mouvement Open Source et la FSF. Bien sur que je sais que les 9 clauses de l'OSD sont plus pragmatique qu'idéologique.
              Maintenant les différents sont aussi technique. Linus n'aime pas emacs et Hurd. RMS aime les unoyaux, Linus ne les aime pas. Tu ne vas pas me dire qu'il ne s'agit pas de différent technique. D'une facon générale les différents entre les 2 sont avant tout basé sur une vision différente du monde : d'un coté il y a un pragmatique qui tire ces idées de l'expérience, de l'analyse du réel et de l'autre il y a un théoricien qui préfère les belles idées. Moi je me reconnais parfaitement dans la première vision du monde et pas du tout dans la deuxième. C'est mon droit maintenant tu es libres de penser différemment.
              • [^] # Re: RMS est mort, vive Linus

                Posté par  . Évalué à 2.

                Mais le problème de base reste le meme : en ajoutant des couches logiciels on s'éloigne du hard et on perd en performance.

                Mais on ajoute pas de couches logicielles... tu n'as pas compris ce qu'était un µ-noyau justement.

                Linus n'aime pas emacs et Hurd. RMS aime les unoyaux, Linus ne les aime pas.

                Emacs c'est un micro-noyau ? Et la marmotte ? Le rapport entre Emacs et le Hurd STP (à part que ce sont des projets GNU ?)

                Et encore une fois je te répète que RMS n'a pas grand chose à voir avec le Hurd et qu'il ne contrôle pas du tout l'évolution du projet.
                • [^] # Re: RMS est mort, vive Linus

                  Posté par  . Évalué à 0.

                  emacs n'est pas un micro noyau, mais un maxi-kernel =)

                  <donotfeedthetroll figlet="yes">
      • [^] # Re: RMS est mort, vive Linus

        Posté par  . Évalué à 1.

        Je ne suis absolument pas d'accord.
        Je vois personnellement Hurd, non pas prenant aujourd'hui la place de Linux , mais comme une expérience afin de créer un nouvel OS libre pour demain.
        Sa structure micro-noyau, le freine aujourd'hui, mais tout évolue; avec la rapide évolution de la technologie (matériel et logiciel), peut on être sûr que Hurd ne peut avoir une place demain (sécurité, parallélisme, ...)
        Toute expérience prend du temps (surtout quand on change d'avis en cours de route ;), commence par des essais (souvent non optimisés) et apporte des réponses différentes (j'adore la gestion des droits et le VFS sous Hurd).
        Le premier système Unix fut écrit en assembleur puis réécrit en C, pour le rendre plus facile à dévolopper; le premier java était très lent, mais on est passé à l'air du JustInTime.
        Oui, Linux est actuellement très défendu car c'est un peu grâce à lui que nous sommes ici, mais je pense que chacun peut avoir sa place, chacun peut surement quelque chose à l'autre.
      • [^] # Re: RMS est mort, vive Linus

        Posté par  . Évalué à 2.

        >Le but d'un micro-noyau c'est surtout pour les >développeurs [snip]

        bon j'ai coupe mais ca ne change rien. L'interet est aussi grand pour les utilisateurs : avec un micro noyau, on met ce qu'on veut autour, mais vraiment ce que l'on veut --> on peut a peu pres tout faire, et ce sur des configs tres modestes si on ne fait presque rien tourner autour du noyau.

        >mais il y a toujours des articles pour dire >n'importe quoi

        l'argument peut etre retourne : il y aura tjs des articles pour dire que ca ralentit tout mais...

        >Les belles idées sur le papier on a vu ce que ca >a donné avec le communiste

        bon la avis perso, vous auriez pu trouver une autre comparaison :)

        >Il suffit de se baser sur certaines mesures >précises pour prouver ce qu'on veut prouver.

        et plus loin

        >mais j'ai des copains qui ont utilisés Hurd et >Mac OS X et il m'ont dit que...

        J'ai appris a mes depends que se baser sur "ce que disent les copains" est *tres* mauvais. N'y voyez aucune agressivite de ma part, mais je ne pense pas que cet argument soit recevable.

        >Hurd ne remplacera _jamais_ Linux car si Hurd >devait triompher Hurd aurait _déjà_triompher

        Linux a mis plus de qqes annees a s'imposer en tant qu'alternative viable a tout le reste (enfin aux OS proprios), je ne pense donc pas que le Hurd puisse etre le sujet de telles pensees. Et surtout il ne me semble pas qu'il soit question que Hurd remplace Linux.
        • [^] # Re: RMS est mort, vive Linus

          Posté par  . Évalué à 2.


          >mais j'ai des copains qui ont utilisés Hurd et >Mac OS X et il m'ont dit que...

          J'ai appris a mes depends que se baser sur "ce que disent les copains" est *tres* mauvais. N'y voyez aucune agressivite de ma part, mais je ne pense pas que cet argument soit recevable.


          Je suis tout à fait d'accord. Personnellement tous mes jugements repose principalement sur _mon_ expérience. Je considère que l'expérience est au dessus de tout article, avis d'expert, avis de copain. Maintenant mieux vaut avoir l'information d'un copain que pas d'information du tout.


          Et surtout il ne me semble pas qu'il soit question que Hurd remplace Linux.

          Je n'ai rien contre le Hurd, ce qui m'énerve c'est le quasi mépris de Stallman envers Linux. Et le mépris de Linus envers le Hurd me direz vous ? Je vous l'accorde ca doit etre un truc de chef d'etre braqué. D'un autre coté faut bien qu'ils prennent des décisions. Et as nous de choisir notre camp.
          • [^] # Re: RMS est mort, vive Linus

            Posté par  . Évalué à 3.

            Maintenant mieux vaut avoir l'information d'un copain que pas d'information du tout.
            Oui mais tant qu'on ne s'est pas fait son propre avis, ce n'est pas la peine de partager l'opinion de ses copains, sinon avec des avis de copains de copains ca peut aller loin.

            D'un autre coté faut bien qu'ils prennent des décisions. Et as nous de choisir notre camp.

            Il n'est pas question de choisir un camp, la communauté n'est pas en guerre. On a encore le droit de faire du multiboot Linux/Hurd/Bsd/Atheos et tout ce qu'on veut.
      • [^] # Re: RMS est mort, vive Linus

        Posté par  (site Web personnel) . Évalué à 6.

        Mon Dieu.. On en tient un beau. Je me demandais quand ils allaient arriver, les gens qui, en dépit de tout ce qu'on peut leur répondre, tienne toujours le même discours, toujours le même, uniforme, sans rien.

        Les micros noyau, ca pue

        J'ai déjà répondu à ça, exactement le même titre. Je t'invite à consulter: http://linuxfr.org/comments/thread.php3?news_id=6461&com_id=889(...)
        et si tu as des arguments, de venir nous voir, sur #hurdfr sur OpenProjects, notamment.

        Hurd = 10 ans de développement et toujours pas pret

        Où ? Quand ? Le Hurd n'est pas activement développé depuis dix ans. Du tout. Son développement a commencé en '90, il est vrai. Mais, il est généralement admis que son développement a été arrêté pendant près de sept ans, pour n'être repris environ qu'en 99, et que de façon très progressive, le temps que le Hurd sorte de cette réputation de projet du passé dont tu es la preuve vivante qu'elle n'a pas cessé.

        Le but d'un micro-noyau c'est surtout pour les développeurs, possibilité de développer des modules en mode utilisateur, possibilité d'avoir des systèmes de fichier en tournant en mode utilisateur, ...

        De quoi ? Si le Hurd apporte de nombreux avantages aux développeurs, il me semble avoir suffisamment dit et montré comment une architecture basée sur un micro-noyau pouvait apporter nombre d'avantages à l'utilisateur, notamment en lui permettant d'avoir ses propres montages - notamment, NFS - très facilement, comment il pouvait, via un « addauth » acquérir facilement des droits plus élevés sans avoir le mot de passe root, etc. De plus, il me semble que c'est l'affaire de tous d'avoir une machine qui ne reboote pas pour un rien, une machine extrêmement sécurisée, qui n'a
        pas besoin d'être rebootée de façon régulière pour mise à jour du noyau, etc.

        Le problème c'est que si le passage de messages et la communication entre les processus rend le développement tellement compliqué qu'il multiplie le temps de développement par 10 je vois pas trop l'intéret pour les développeurs d'utiliser un m icro-noyau.


        As-tu déjà regardé une seule fois les sources d'un programme qui fait usage du système d'IPC que tu évoques ? Le développement de telles applications n'a _rien_ de complexe. Ce qui est complexe, en revanche, effectivement, c'est de repenser une architecture de fond en comble, d'essayer de faire tout de la meilleure façon possible plutôt que de le faire de façon à ce que ça marche maintenant, et qu'après, on se rende compte que c'est absolument immaintenable, inadaptable, et qu'il faut tout refaire un nombre impressionant de fois..

        Effectivement, le développement de Linux a été beaucoup plus facile, puisque, comme le disait très justement Linus il n'y a pas longtemps, Linux n'a pas de design, il se contente de reprendre tous les principes utilisés par Unix - dont l'utilité a certes été prouvée, mais 30 ans d'utilisation d'Unix a aussi montré que ce système avait un certaines nombres d'erreurs de conceptions, et qu'il n'était pas forcément adapté
        aux systèmes d'aujourd'hui de bien des manières. Mais, devrait-on pour autant se contenter de refaire à chaque fois la même chose, par des gens différents ? (avec la différence, certes, que Linux est un logiciel libre, ce qui était son avantage majeur.) L'évolution serait donc totalement condamnée dans le monde de l'informatique ? Je ne l'espère pas.

        De plus rajouter des interfaces et des couches d'abstraction c'est peut-etre beau sur le papier, mais à chaque fois ca entraine des chutes de performance terribles.

        De quelle couche d'abstraction parles-tu ? De quelle interface ? J'avoue ne pas comprendre à quoi tu fais référence. En revanche, pour aborder le thème de la performance des systèmes à base de micro-noyaux, il est claire qu'elle n'est pas évidente, étant donner qu'un système multi-serveurs à micro-noyau implique une multiplication des changements de contexte, et des appels noyaux concernant l'IPC. L'important est justement à ce niveau: pour qu'un système à base de micro-noyau soit rapide, au moins aussi rapide si ce n'est plus qu'un système à base de noyau monolithique, il faut que ces appels concernant l'IPC soient extrêmement lightweight, extrêmement rapides, et n'entraînes pas le même coût en performance qu'un appel système « traditionnel. ».
        Dans le cas de Mach, c'était déjà le cas: les appels à mach_msg étaient _extrêmement_ moins coûteux que les autres kernel traps. Cependant, Mach n'est pas un modèle de vélocité, et faire un système performant basé sur ce micro-noyau n'est pas évident. La rapidité, et la concision, ont été tdepuis le début le but du projet L4, comme je l'ai déjà dit. Ils y sont _vraiment_ parvenus, grâce à des moyens très intéressants et très savants, expliqués pour beaucoup sur http://www.l4ka.org/publications/(...) . De plus, une fois le problème de l'IPC réglé, l'architecture à base de micro-noyaux peut s'avérer plus performante qu'une architecture à base de noyaux monolithiques. En effet, nombre d'appels qui sont traditionellement des appels systèmes ne sont plus implémentés dans le noyau, mais dans la libc (C Library), et ne se servent que de RPC vers les programmes chargés de l'exécution réelle de tels appels. Ainsi, ils économisent le gros overhead produit par un appel système « traditionnel » dans un programme.. (qui n'est pas négligeable: vous êtes vous déjà interrogés sur le pourquoi de la stdio - bufferisée, donc - alors qu'on pourrait utiliser read() et write() - comme woof - ? Avez-vous déjà comparé les performances d'un programme effectuant des opérations d'I/O fréquentes utilisant read()/write() ou printf()/fgets() ?)


        ertes il y aura toujours des articles pour dire que la perte de performance n'est pas si terrible que ca, mais il y a toujours des articles pour dire n'importe quoi.

        Argument frappant, je dois le dire. Quand l'article, d'une dizaine de pages, te décris en détail les modifications effectuées sur Linux pour qu'il soit porté sur L4, ce qu'on a testé précisément - et pourquoi - et qu'il te donne les performances obtenues par différentes batteries de tests réalisées par des logiciels _indépendants_ des auteurs, et qui ont été choisis parmi les meilleurs, et qu'il se trouve que ce benchmark est très facilement reproductible, qu'il l'a été fait, et que les résultats ont toujours été dans le même ordre d'idée, voire même meilleurs que ceux proposés dans le document, je sais pas que demander de plus.. Si tous les benchmarks pouvaient être aussi clairs, impartials, ...
        D'autant plus que ce benchmark n'a pas été fait dans un but de FUD, puisqu'il ne s'agit pas pour l'équipe de L4Ka - des universitaires, principalement - de vendre leur produit, mais bien de tester leurs avancées _réelles_, pour eux-même, dans un but scientifique...

        Il suffit de se baser sur certaines mesures précises pour prouver ce qu'on veut prouver.

        Soit plus précis. Que proposerais-tu de tester que les réalisateurs du benchmark n'ont pas testés ? J'ai sous la main un L4Linux tout à fait disponible, et en mesure d'exécuter tout test que tu désirerais lui faire subir.

        Personnellement Java => ajout d'un couche d'abstraction (vm) => super long.

        Quel rapport ? Il n'y a pas de « couche d'abstraction », ou en tous pas à la base, dans le Hurd. Le micro-noyau n'est pas du tout une couche d'abstraction.

        cependant, je trouve qu'un des seules avantages de windows sur Linux est justement d'etre plus rapide au niveau de l'affichage (car le système de fenêtrage et justement dans le noyau).

        Cela reste à prouver.. De plus, de telles pratiques s'avèrent être, de fait, des pratiques courantes dans des énormes développements propriétaires comme l'est Windows, où les développeurs cèdent souvent à la facilité - car l'utilisation d'un « fourre-tout ·» reste toujours plus aisée dans un premier temps que la séparation laire, la modularité. Ainsi, le programmeur débutant a toujours tendance à faire un seul fichier source, une seule fonction, etc. La programation d'un système multi-serveurs à base de micro-noyau demande effectivement plus de rigueur.
        De plus, les principes des développeurs du Hurd - toujours au mieux, toujours différent - rendent effectivement le développement du Hurd un peu plus difficile. Mais je suis convaincu que, comme la séparation interface/reste, la séparation en modules, fonctions, etc., cette rigueur, difficile à acquérir au début, rend beaucoup de tâches pour la suite des choses beaucoup plus faciles.

        Notamment, le fait que toutes ces facilités ayant recours à des hacks x86-only - mais performants - aient été refusés de tout temps par les concepteurs du Hurd a permis à des gens de porter le Hurd sur PPC en à peine quelques jours et 2/3 modifications.. Comparez avec le temps qu'il a fallu pour un port de Linux sur PPC, et sur l'avancée de ce port.

        les belles idées sur le papier on a vu ce que ca a donné avec le communiste et apparemment on peut généraliser à pas mal de domaine la leçon.

        C'est cette partie qui me fait franchement penser qu'il s'agit d'un fake - voire d'un piège à Kilobug. Mais, ces arguments étant extrêmement classiques, je tiens à y répondre une fois pour toutes.

        Le seul micro noyau que j'ai utilisé pour l'instant est minix (qui est nettement plus long que linux), mais j'ai des copains qui ont utilisés Hurd et Mac OS X et il m'ont dit que les performances étaient moins bonne que sur les OS monolithiques.

        Le Hurd, basé sur GNU Mach, est aujourd'hui nettement moins performant que Linux, pour de multiples raisons. On ne peut pas comparer les performances d'un logiciel se voulant être à la base de systèmes utilisés partout dès maintenant, et un projet qui n'est pas abouti et dont le développement est loin d'être fini..

        De plus j'ai lu qq part que de toutes facon on n'avait de plus en plus de ressources processeurs et donc que les performances n'étaient pas si primordiales que ca. Cet argument est l'argument (récurrent) e plus débile de l'histroire de l'informatique. On aura _jamais_ trop de ressource et donc on se doit de concevoir les systèmes le plus efficacement possible.

        Ceux qui profèrent ce genre de non-sens sont des ânes. Mais, qu'est-ce que cela a à voir avec le sujet qui nous occupe ?

        Quand à la modularité, avec Linux on a la modularité au niveau du source. De plus les modules ne constituent pas du rafistolage mais plutot le juste milieu.

        Tu compares des choses qui n'ont rien à voir.. Ai-je cité, dans tous mes posts, des choses qui seraient faisables avec les modules Linux ? Je ne le pense sincèrement pas. Les modules ont été une grande avancée pour Linux, et ce sont de très bonnes choses. D'ailleurs, les modules chargeables dynamiquement existent également dans certaines versions de Mach - puisque traditionellement, les drivers matériels sont dans Mach et non en user space, bien que ce micro-noyau le permette - en offrant la possibilité d'envoyer des messages spéciaux au micro-noyau qui se chargent de les traduire en interruptions matérielles.

        Hurd ne remplacera _jamais_ Linux car si Hurd devait triompher Hurd aurait _déjà_triompher.

        Pourquoi viens-tu parler du Hurd, alors ? Tu n'es pas devin, ni moi. Je ne peux prévoir l'avenir du Hurd, l'avenir de GNU, ni l'avenir de GNU. Si tu veux montrer que le Hurd n'a aucun avenir, attends. Et s'il ne triomphe jamais, tu pourras jubiler en te disant « j'avais raison! ». En attendant, tu n'as pas de moyen de démontrer tes propos, si ce n'est d'attendre. Alors, je te propose que tu attendes en faisant autre chose, pendant qu'on continue notre projet. Et voyons bien ce qui arrivera.

        N'en déplaise à Stallman et à son égo surmesurer.

        Encore un non-argument, trollesque, sans _aucun_ intérêt - nous sommes pas là pour juger des personnes, que tu ne connais pas personellement, qui plus est. Et je ne pense pas que la mort du Hurd soit un tel drame pour Stallman: il l'a cru mort - Stallman suit peu le développement du Hurd, il faut l'avouer - pendant longtemps, et il a l'air de tenir le choc.
        • [^] # Re: RMS est mort, vive Linus

          Posté par  . Évalué à 0.

          Bon j'avais déjà répondu mais le message n'a pas été posté :((

          Mon Dieu.. On en tient un beau

          Merci

          J'ai déjà répondu à ça, exactement le même titre

          Ce n'était exactement le même titre, les micro-noyaux, ca pue, c'est plus percutant que les micro-noyaux, c'est nul.

          qui n'a pas besoin d'être rebootée de façon régulière pour mise à jour du noyau

          Je ne sais pas si tu es au courant mais Linux est de plus en plus utilisé par des personnes qui ne savent même pas ce qu'est un noyau. Avancé cet argument pour démontrer que le HURD n'est pas seulement destiné aux développeurs c'est vraiment nul.


          De quelle couche d'abstraction parles-tu ? De quelle interface ? J'avoue ne pas comprendre à quoi tu fais référence.

          Avec un noyau monolithique, un appel système va directement tapé dans le noyau.
          Avec un micro-noyau, les appels systèmes sont implémentés au niveau des serveurs (1ère interface), les serveurs font appels aux services fournis par les taches d'entrées sorties (2 ème interface) et enfin les taches d'entrées sorties font appels au micro-noyau qui s'occupe de gérer les ressources et de passer les messages (3ème interface). Voila ce que j'appelle ajout de niveaux d'abstraction. (Enfin c'est ce qui se passe sous minix, je connais très mal HURD)


          Cependant, Mach n'est pas un modèle de vélocité, et faire un système performant basé sur ce micro-noyau n'est pas évident.

          Alors pourquoi l'utiliser s'il y a moyen de faire mieux ?

          <i>
          > Certes il y aura toujours des articles pour
          > dire que la perte de performance n'est pas si
          > terrible que ca, mais il y a toujours des
          > articles pour dire n'importe quoi.

          Argument frappant, je dois le dire.
          <i>

          Je confirme, et j'en suis fier ;)


          > Il suffit de se baser sur certaines mesures
          > précises pour prouver ce qu'on veut prouver.

          Soit plus précis. Que proposerais-tu de tester que les réalisateurs du benchmark n'ont pas testés ?

          Moi ce que je souhaiterais pour changer mon avis sur les micro-noyaux c'est que Hurd soit aussi rapide (au niveau de l'utilisation j'entends) que Linux et que ce soit une _priorité_.


          Pourquoi viens-tu parler du Hurd, alors ? Tu n'es pas devin, ni moi.

          Pipo Argument

          Prédiction de l'avenir => Test sur la compréhension du présent. Il est toujours bon d'essayer de prévenir l'avenir. Les personnes qui prédisent très mal l'avenir sont des personnes qui ont une mauvaise compréhension du présent et inversement. Ainsi pour savoir si l'on a une bonne compréhension du présent, il est bon de faire des prédictions, de les retenir et de voir quand le futur devient présent si l'on avait raison ou non. Et si l'on avait tort ils est bon de se poser des questions

          > N'en déplaise à Stallman et à son égo surmesurer.

          Encore un non-argument, trollesque, sans _aucun_ intérêt

          Si les trolls n'ont aucun intérêt, que fais-tu sur linuxfr ! Les trolls sont primordiales car ils permettent de se défouler ! Et se défouler c'est important, sinon comment expliquer le succès des doom-like, quake-like, des films violents et ... de linux (qui permet de se défouler sur microsoft)


          nous sommes pas là pour juger des personnes, que tu ne connais pas personellement

          Tu es le roi des arguments à la con à ce que je vois. Je ne connais pas personnellement les hommes politiques et cela ne m'empeche pas de les juger et ne m'empechera pas d'aller voter pour l'un d'eux aux prochaines élections. C'est meme mon devoir de citoyen.
          • [^] # Re: RMS est mort, vive Linus

            Posté par  . Évalué à -1.

            mr , vous n'avez manifestement aucune connaissance objective sur HURD

            vous ne répondez pas aux arguments techniques sur les possibilités de HURD que linux ne peut _pas_ reproduire.

            vous melangez tout
            vous ne repondez pas sur le fait que HURD permettrait de se passer de gnome-vfs ou les kioslave (et faire la même chose en plus rapide)

            vous dites :
            " Si les trolls n'ont aucun intérêt, que fais-tu sur linuxfr ! Les trolls sont primordiales car ils permettent de se défouler ! Et se défouler c'est important, sinon comment expliquer le succès des doom-like, quake-like, des films violents et ... de linux (qui permet de se défouler sur microsoft)"

            je pense plutot que c'est vous qui avez rien à faire sur linuxfr. les trolls sont une pertes de temps. vous répondez, ecrivez a coté du sujet, vous servez à rien.

            on se fiche que vous vous defouliez, linuxfr est un site d'informations et une place publique pour discuter autour de linux et les logiciels libres (et hurd s y inscrit)
            manifestement il y a des gens ici qui connaissent bien mieux que vous linux ou hurd.
  • # La mort annoncée de GNU/Linux ?

    Posté par  . Évalué à 10.

    Pas vraiment pour tout de suite, non plus... pour commencer, il faut que le µnoyau sur lequel repose le Hurd supporte plus de matériel...

    Et AMA, quoique puisse en dire RMS, Linux est bien trop populaire et implanté (même si, relativement à une certaine situation monopolistique, c'est faible) pour que GNU remplace GNU/Linux.

    Les éditeurs ont déjà du mal à se tourner vers Linux, je vois pas pourquoi ils se tourneraient plus vers le Hurd et son µnoyau (en plus, je suis persuadé que cette histoire de µnoyau va faire peur).

    Et qu'on ne me réponde pas que les drivers de linux seront portés, ça veut bien dire ce que ça veut dire : GNU aura encore besoin de Linux...

    Le problème du Hurd, AMA, c'est qu'il arrive un peu trop tard (d'ailleurs, il est pas encore arrivé), au moment même où les gens se tournent de plus en plus vers les LL en général et vers GNU/Linux en particulier...

    Enfin, on verra bien...
    • [^] # Re: La mort annoncée de GNU/Linux ?

      Posté par  (site Web personnel) . Évalué à 10.

      Je ne suis pas totalement d'accord, le fait qu'un nouvel OS arrive est toujours, AMHA, une bonne chose. Je ne pense pas que l'on arrive à la disparition de Linux ou de Hurd et donc à un GNU uniforme.
      Quand on regarde ce qui permets de faire tourner les logiciels GNU, on trouve déjà plus d'un noyeau (Linux évidement, Hurd mais aussi les BSD et peut-être d'autre unix que je ne connais pas).
      Ce que j'apprécie dans Gnu, c'est le choix, alors un nouveau noyeau utilisable en production est pour moi une bonne nouvelle.
      Dans un premier temps, je n'imagine pas Hurd inquiéter réellement les autres noyeau libre mis en place pour les raisons que tu donnes mais par la suite, si celui ci s'avére meilleurs dans certains domaines, pourquoi ne pas l'y mettre?
      On continuera d'avoir le choix et celui-ci se sera étoffé, tant mieux.
    • [^] # Re: La mort annoncée de GNU/Linux ?

      Posté par  (site Web personnel) . Évalué à 10.

      Linux est bien trop populaire et implanté (même si, relativement à une certaine situation monopolistique, c'est faible) pour que GNU remplace GNU/Linux.
      Je pense que le but est pas de "remplacer" definitivement Linux.

      Peut-etre que la FSF se mettra a utiliser le Hurd et seulement le Hurd, mais c'est leur probleme et c'est tout naturel vu que le Hurd est leur projet.

      Maintenant, beaucoup continueront a utiliser Linux, certains utiliseront Hurd, d'autres FreeBSD, et d'une maniere generale chacun fera ce qu'il voudra.

      Perso je trouve ca bien qu'il y ait plein d'OS comme le Hurd, Atheos, etc...

      Honnetement, je pense qu'une plate-forme comme le Hurd sera delaissee par les "editeurs" de logiciels proprietaires. Maintenant, je pense sincerement que la FSF s'en fiche un peu qu'Oracle porte ses produits pour Hurd. A moins qu'Oracle sorte ses produits sous une license libre evidemment 8-)
      • [^] # Re: La mort annoncée de GNU/Linux ?

        Posté par  . Évalué à 10.

        Je suis d'accord sur le fond: la diversité est une bonne chose.

        Par contre, il faut faire attention à ce que l'on dit: le Hurd n'est pas un OS, ce n'est même pas vraiment un noyau, c'est un ensemble de serveurs pour micro-noyau pouvant être utilisés (en conjonction avec un µ-k) pour remplacer un noyau monolithique dans un système (ici le système GNU).

        GNU/Linux et GNU ne sont donc pas deux système complétement différents comme le sont GNU/Linux et FreeBSD par exemple.

        Pour les applications propriétaires, si la compatibilité binaire entre GNU/Hurd et GNU/Linux n'existe pas actuellement, elle ne pose aucun problème théorique et sera implémentée dés que quelqu'un jugera bon de le faire (et l'intéret premier de ça n'est pas de faire tourner des applis propriétaires AMHA, mais de faciliter les dual-boots GNU/Linux-GNU/Hurd).
        • [^] # Re: La mort annoncée de GNU/Linux ?

          Posté par  (site Web personnel) . Évalué à 10.

          > faciliter les dual-boots GNU/Linux-GNU/Hurd

          C'est clair que si on pouvait partager un meme /usr/bin entre un systeme GNU/Linux et un GNU/Hurd, ca serait plutot pas mal...
          • [^] # Re: La mort annoncée de GNU/Linux ?

            Posté par  (site Web personnel) . Évalué à 2.

            Pour /usr/bin c'est peu probable, mais poourquoi pas une utilisation commune de /etc /var /proc /home ?
            A priori, cela ne me semble pas du tout impossible, et je le crois souhaitable.
            • [^] # Re: La mort annoncée de GNU/Linux ?

              Posté par  . Évalué à 3.

              mais poourquoi pas une utilisation commune de /etc /var /proc /home
              pour /etc ca peut etre envisageable a la limite mais il y a le probleme des scripts d'init qui ne seront pas les meme, et la crontab qui doit faire appel exclusivement a des programmes disponibles sur les 2 systemes. D'ailleurs je ne suis pas sur qu'on ait le droit de monter /etc sur une partition differente de /.
              pour /var, il faut malgre tout faire attention, on ne peut pas partager par exemple les fichiers syslog sinon ca devient vite la pagaille. Pour le mail /var/mail c'est une bonne idee
              /proc n'est pas une partition du disque dur, c'est un repertoire qui contient des informations sur le systeme mais qui est gere par le noyau sans etre ecrit nul part.
              /home se partage certainement tres bien si on a le meme systeme de fichier et que l'on fait attention a avoir les memes UID pour les memes utilisateurs.

              Etienne
            • [^] # Re: La mort annoncée de GNU/Linux ?

              Posté par  (site Web personnel) . Évalué à 3.

              Pour /etc, tu risques d'avoir des surprises lors des mises à jour. Genre ta Debian GNU/Linux a mis à jour /etc, et derrière ta Debian Hurd tente de faire la même chose. Le problème se pose aussi sur /var (création éventuelle de nouveaux répertoires/suppression des anciens), et sur /home : par exemple entre Gnome sur Potato et Gnome sur Woody, il faut faire une conversion via machinmetadb par exemple (donc avoir la conf correspondant aux version des logiciels installés). Bref à moins d'avoir une Debian GNU+GNU/Linux avec mise à jour des 2 simultanément, ça va poser des problèmes.

              Déjà c'est chiant de partager des binaires entre deux glibc différentes.
    • [^] # Re: La mort annoncée de GNU/Linux ?

      Posté par  . Évalué à 10.

      il faut que le µnoyau sur lequel repose le Hurd supporte plus de matériel

      Ce sera fait d'ici quelques mois avec le passage à OSKit Mach. Sinon, l'un des gros avantages des µ-noyau (et de Mach) c'est qu'il possible d'implémenter énormément de drivers uniquement en user space.

      Linux est bien trop populaire et implanté pour que GNU remplace GNU/Linux.

      Le passage de GNU/Linux est presque transparent (ou le sera lorsque les problèmes du Hurd seront corrigés), et une immense majorité d'applications ne demandent qu'un portage minimal. En particulier avec la Debian GNU/Hurd (http://www.debian.org/ports/hurd/index(...)).

      Les éditeurs ont déjà du mal à se tourner vers Linux, je vois pas pourquoi ils se tourneraient plus vers le Hurd et son µnoyau

      Pour des raisons de sécurité ? De fiabilité (lorsque tout marchera bien) ? Pour tous les avantages qu'il apporte(ra) ?
    • [^] # Re: La mort annoncée de GNU/Linux ?

      Posté par  (site Web personnel) . Évalué à 10.

      J'ai surtout l'impression que c'est un effet d'annonce. Un moyen pour dire : "Le Hurd existe bel et bien et avance, ainsi que GNU par la même occasion."

      C'est un peu un piqure de rappel que fait RMS aux développeurs et utilsateurs de LL. Mais ça ne changera rien aux destinés de Linux et du Hurd. Si ce dernier veut percer, c'est avant tout avec ses qualités techniques qu'il devra le faire. Pas parce que RMS le veut.

      Mais bon, moi je suis favorable à la diversité alors bonne chance aux deux.

      Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

      • [^] # Re: La mort annoncée de GNU/Linux ?

        Posté par  . Évalué à 3.

        Je suis tout à fait d'accord, et je suis moi aussi pour la diversité, mais en fait, je réagissais au titre (certainement volontairement) provocateur.

        Cela dit, RMS ne présente pas les choses sous cette forme (encore heureux).
    • [^] # Re: La mort annoncée de GNU/Linux ?

      Posté par  . Évalué à 3.

      > Les éditeurs ont déjà du mal à se tourner vers Linux, je vois pas pourquoi ils se tourneraient
      > plus vers le Hurd et son µnoyau (en plus, je suis
      >persuadé que cette histoire de µnoyau va faire peur)

      Je ne vois pas pourquoi tu penses que le micronoyau leur ferait peur!
      Les éditeurs logiciels se fichent éperdument de savoir si le système d'exploitation utilise un micro-noyeau, un exo-kernel ou un pico-kernel ce qui les interesse c'est de pouvoir vendre leurs produits en quantité suffisante pour faire du bénéfice, un point c'est tout!

      Ce qui AMHA n'est pas pres d'arriver pour GNU déja que pour Linux c'est pas (encore) le cas (ça dépend des domaines, bien sur).
  • # rms l'utilise deja ...

    Posté par  . Évalué à 10.

    mais depuis peu seulement

    si je me souviens bien, il avait dit lors de son speech du samedi matin au fosdem que depuis qq jours il utilisait le hurd sur son portable
    alors si meme rms l'utilise depuis peu seulement, le public vise par une release cette annee ne peut-etre que des 100%-geeks

    a part ca, ca fait quand meme plaisir d'entendre qu'un nouveau systeme devient utilisable et ca ne peut qu'amener des developpeurs a s'y interesser

    ca serait bien que des gens qui l'utilise deja postent des commentaires pour faire un peu de propagande (j'ai pas dit pour troller ...)
    • [^] # Re: rms l'utilise deja ...

      Posté par  (site Web personnel) . Évalué à -5.

      C'est déjà une très mauvaise nouvelle : ca veut dire que emacs tourne sur GNU.

      Beurk :(=

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: rms l'utilise deja ...

      Posté par  (site Web personnel) . Évalué à 1.

      Quelqu'un aurait déjà testé ce noyau ?

      Par ce que j'en ai entendu dire que des "on dit"...

      Et surtout, qu'apporte-t-il de plus que le noyau Linux que l'on connait bien ?
      • [^] # Re: rms l'utilise deja ...

        Posté par  . Évalué à 9.

        J'avais essaye l'an dernier de l'installer sur un vieux PC et ca avait ete une grosse galere parcequ'il n'avait pas d'acces internet et pas de lecteur CD...

        Une fois le noyau installe, c'est assez facile d'ajouter des programmes : Debian/Hurd oblige...

        Par contre on a pas pousse jusqu'a l'installation d'un serveur graphique...

        http://www.hurdfr.org/Docs/Hurd_fr/Guide(...) avait ete notre guide...
      • [^] # Re: rms l'utilise deja ...

        Posté par  (site Web personnel) . Évalué à 10.

        Oui, j'ai « testé » le Hurd. Non, ce n'est pas un noyau. Au risque de passer pour un vieux radoteur, ce que je suis probablement, me direz-vous, « est noyau tout code qui tourne avec les permissions spéciales du proc' réservées au .. noyau, soit le fameux 0 sur processeurs Intel ». C'est ce qui différencie, d'ailleurs, le mode noyau du mode utilisateur. (kernel space.. user space). Tout le code du Hurd tourne en mode utilisateur. Il s'agit juste d'une série d'applications _normales_, n'ayant pas plus de permissions que les autres.

        Ces précisisons étant dîtes, répondons. Qu'apporte-t-il ? Il faudrait bien plus d'un commentaire pour répondre à cette question. (la partie de ma présentation sur le Hurd à ce sujet fait déjà plus de cinq pages, et j'en suis à juste un peu plus du tiers :). À la base, l'esprit du Hurd est l'esprit du GNU - ou ce qu'il devrait être: étudier et reprendre les logiciels existants, essaye d'en retirer les avantages et les limites, et essayer de les casser, en faisant au maximum novateur, au maximum repensé. Pas juste une réécriture. C'est là où le Hurd diffère de Linux: Linux n'est qu'une réécriture d'Unix, où les améliorations résident dans l'implémentation. Le Hurd est différent d'Unix, puisque GNU's not Unix.

        Les différences sont multiples. La première, et la principale, à laquelle on pense automatiquement est l'architecture d'un système GNU: au lieu d'un très gros programme - monolithique, donc - fournissant un tas de fonctionnalités dîtes de base pour un OS - là, la définition de ce qu'est un service de base n'est pas claire, puisque la seule vraiment rigoureuse serait de dire que c'est ceux fournit par le noyau Unix à la base - on a une serie de petits programmes indépendants, qui se chargent chacun d'une tâche - pfinet, pour tout ce qui est PF_INET (PF <=> Protocol Family, je vous laisse deviner pour INET), nfs pour le NFS, ext2fs pour ext2, password pour le serveur de passwords, etc, ces applications -- appelées serveurs -- communiquant entre elles via le micro-noyau. Ceci présente plusieurs avantages:

        * Une plus grande modularité, au sens où l'on peut bâtir facilement des systèmes extrêmement minimaux ne contenant que les quelques services de base - les quatre ou cinq serveurs nécessaires au Hurd.

        * Une plus grande stabilité. Entendons nous bien,
        le Hurd n'apporte pas la stabilité absolue, les programmeurs sont malgré tout humains. :). Cependant, ce que peut faire un OS-base, c'est de réduire la gravité de ces bugs afin qu'un problème dans une application puisse difficilement rendre l'ensemble du système totalement inutilisable.
        Il est clair que plus le programme est gros, plus il y'a de chance qu'un bug arrive. Ainsi, Linux devenant de plus en plus gros, il arrive, fréquemment - quasiment de plus en plus ;-) - qu'un bug dans une partie non-essentielle de Linux survienne, ce qui provoque, bien évidemment, un crash de l'ensemble du noyal. Sous le Hurd, dans la majorité des cas - c'est à dire, dans les cas où le bug survient sur un des serveurs n'étant pas essentiel a la « survie » du système - seule l'application responsable crashera, et ça n'ira pas plus loin. Par exemple, lorsque Jeff Bailey a mis, il y'a quelques temps de ça un serveur Web sous GNU, et l'a annoncé un peu partout, et que la nouvelle s'est retrouvée sur /., pfinet n'étant pas très solide, il n'a évident pas tenu la charge d'un slashdottage en règle.. (pensez bien, un truc comme ça). Dans le cas de Linux, cela aurait causé un crash du système et une non-disponibilité pendant quelques temps. Dans le cas du Hurd, il a suffit de relancer pfinet, et c'était reparti pour un tour. De plus, les opérations risquées peuvent facilement être faîtes dans un sub-Hurd, équivalent de UML - User-Mode Linux - qui est totalement naturel pour le Hurd, puisqu'il ne s'agit que de relancer des applications normales, et ne pose aucun problème -- contrairement à UML qui évolue lentement, nécessite des patches, et, du fait que Linux n'est pas prévu pour ça, pose pas mal de problèmes encore..

        * Une plus grande disponibilité, en partie pour les questions de stabilité décrites ci-dessus, et également parce qu'il est plutôt rare d'avoir à changer le noyau, et que le changement de presque tout le reste peut se faire « à chaud ». De plus, la flexibilité pourrait imaginer deux pfinet tournant en parallèle, l'un relayant l'autre dès que le premier a fini, ceci permettant d'éviter les déconnexions en cas de problème, et par exemple, d'effectuer un changement de pfinet sans aucune déconnexion. Ce n'est qu'un exemple: la flexibilité qu'apporte la modularité du Hurd peut autoriser _nombre_ de choses très intéressantes comme cela, qui n'ont pas toutes été implémentées à l'heure actuelle.

        * Enfin, il me semble que c'est quand même beaucoup plus beau, clean. Les rôles sont beaucoup mieux repartis, et chaque partie peut être facilement remplacée sans perturber les autres.

        Mais ce n'est pas tout. On ne peut limiter le Hurd a son architecture: elle n'est qu'un élément de la recherche du toujours mieux, toujours plus novateur. On citera par exemple:

        * Le principe des translators. Comme dit précédemment, les différentes applications - serveurs - du Hurd communiquent entre eux via un micro-noyau, actuellement, et encore pour un bon bout de temps, Mach. Le rôle de ce micro-noyau est de passer des messages - on dit qu'il est message-passing. Pour ce faire, il introduit le concept de ports. Un port est un canal unidirectionnel qui n'est matérialisé que par un droit sur ce port: un droit d'envoi, un droit « send-once » (envoi d'un seul message, utile pour les réponses vu que c'est unidirectionnel), et un droit de réception. (ce dernier n'étant bien entendu détenu que par une seule tâche..). C'est par le biais de ces ports que les applications communiquent entre elles, et par ce biais par exemple qu'une application du Hurd - ext2fs, par exemple - peut authentifier un utilisateur - via le serveur password, en lui envoyant un message, ou vérifier qu'il a le droit de faire telle ou telle opération -- en envoyant un message au serveur 'auth', etc... Le problème qui se pose alors, généralement, dans la conception de tel système est: comment une application - une tâche, au sens Mach - peut-elle obtenir un droit sur un port en direction de telle ou telle application ? Le moyen standard, et logique, est de faire un serveur de noms, exactement comme pour la résolution de noms via DNS. Vous m'accorderez cependant que c'est une solution relativement lourde, et peu élégante, puisqu'elle nécessite que chaque application s'enregistre au préalable, etc.. Dans le Hurd, l'idée est radicalement différente: on n'utilise plus un serveur de noms, mais on considère le file system comme un espace de nom! Ainsi, chaque fichier est attaché à une application, et écrire dans un fichier revient à envoyer un message à l'application qui écoute sur ce fichier. Pour un fichier « classique », il s'agira probablement d'un translator ext2fs - qui « écoute » sur tous les fichiers du système de fichiers montés, donc - qui agira à peu près comme
        la gestion des FS de Linux. Cependant, cela permet des choses qui sont très difficilement faisables sous GNU/Linux. L'exemple le plus courant est celui du translator - un translator est une application qui « écoute » sur un fichier - de fortunes: votre client mail ne supporte pas les signatures aléatoires, or, vous voulez mettre des fortunes dans votre signature ? Aucun problème! Il vous suffira d'avoir un translator 'fortune', qui écrira, par exemple, dans ~/.signature (~ <=> le home de l'utilisateur qui a lancé le translator), mettant à jour la fortune grâce à l'utilitaire fortune à chaque fois que le fichier est accédé. Et voilà, votre application supporte maintenant les signatures aléatoires! :-) Je voua laisse imaginer les autres applications du principe des translators..

        * La refonte du VFS - utilisant tout ce que permet la modularité du Hurd. Le nouveau VFS permet d'implémenter facilement - de façon stable, fonctionnelle - des systèmes de fichiers distribués (je pense principalement à ftpfs, qui permet de « monter » (si tant est que cela veuille dire quelque chose avec le Hurd) un FTP comme une partition), des nouveaux systèmes de fichiers - très intéressants.. - comme ShadowFS (cf. http://lists.debian.org/debian-hurd/1999/debian-hurd-199909/msg0004(...)),
        etc.

        Une application du concept des translators est montrée par le log suivant:

        mmenal@dryden:~$ settrans -c /home/mmenal/ftp/ /hurd/hostmux /hurd/ftpfs /
        mmenal@dryden:~$ cd /home/mmenal/ftp/ftp.fr.debian.org
        mmenal@dryden:~/ftp/ftp.fr.debian.org$ ls
        debian debian-cd debian-non-US
        mmenal@dryden:~/ftp/213.245.76.60$ cd /home/mmenal/ftp/213.245.76.60/debs/
        mmenal@dryden:~/ftp/213.245.76.60/debs$ ls
        libdianewcanvas0-dev_0.6.4-1_i386.deb libdianewcanvas0_0.6.4-1_i386.deb libglade2-dev_1.99.5-1_i386.deb libglade2_1.99.5-1_i386.deb sources


        Ainsi, on voit qu'on sort bien du concept classique des fichiers sous Unix, pour permettre au translator écoutant sur le répertoire /home/mmenal/ftp -- hostmux, pour host deMUXer -- de gérer comme il veut un accès à un fichier - en l'occurence, donc, en se connectant au ftp de même nom que le même fichier, et en le passant à ftpfs pour qu'il fasse son boulot à son tour.

        C'est-y pas magnifique? :)

        Enfin, le dernier avantage que je citerai est le système de sécurité. Pour résumer très brièvement (j'espère): on casse le modèle une application à un UID (et EUID, etc.). On considère ces « UIDs »
        comme des jetons t'autorisant à un certain nombres de choses -- disant au serveur auth que tu as le droit de faire, telle, telle, ou telle opération. Ainsi, la gestion des UGIDs ne se limite plus à quelques changements, mais arrive à une vraie gestion de collections de droits: on peut rajouter des droits (addauth, en s'authentifiant, en demandant au serveur password si l'authentification est bonne), en enlever. On note par exemple qu'il existe ainsi un _vrai_ cas où une application n'a plus de droit: le cas où elle ne possède plus aucun jeton. La possibilité d'ajouter simplement des droits - ce qui n'existe pas naturellement dans le cadre d'Unix - permet ainsi d'éviter beaucoup de passages en root, et de n'avoir que les permissions nécessaires à chaque opération, pour limiter au *maximum* les dégâts potentiels d'une faille.

        Bon, je pense que je vais m'arrêter là. Je suis désolé pour vous avoir encore donné un post immondede, indigeste, trop long, verbeux, et j'espère faire mieux en reprenant tout ça de façon bien organisée dans ma présentation à venir..
        • [^] # Enfin !

          Posté par  . Évalué à 5.

          Oui, je dis bien, enfin !

          Enfin, un post constructif, qui apporte des réponses claires à des questions que je me posais depuis un moment, à savoir ce que le Hurd avait de si intéressant. Maintenant , j'ai un petit aperçu, qui me donne envie de voir un peu plus loin, si j'en ai le temps (ça, c'est pas gagné).

          Merci Manuel, je préfère un commentaire comme cela dans les news, plutôt qu'un troll de plusieurs jours sur la tribune. Je comprends que les hurdistes s'offusquent des propos qui s'y tiennent, mais la tribune libre n'est décidément pas un espace de discussions très sérieux, ou est en tout cas inadapté à ce genre de sujet.

          Petit bémol quand même : http://www.hurdfr.org(...) laisse vraiment un goût d'inachevé dans la bouche.

          Trouvant ridicules les batailles de tribus dans la communauté des logiciels libres, je souhaite longue vie au hurd ! Et à sa cohabitation avec le système GNU/Linux.

          (Là, j'espère pas avoir dit trop de bêtises sur les termes utilisés, style Le Hurd, ou GNU/Linux. De toute façon, j'en connais deux qui rectifieront. ;) )
        • [^] # Et la programmation parallèle ?

          Posté par  (site Web personnel) . Évalué à 2.

          Enfin qqn qui connait un peu !

          Tout ceci me donne envie des poser quelques questions...

          Si j'ai bien compris, au niveau du noyau, l'interaction par messages est grandement augmentée pour améliorer la modularité du système...

          Or, maintenant que les réseaux Gbits se développent de + en +, ceci permettra-t'il d'avoir une gestion de l'OS répartie entre diverses machine ?

          Pour prendre un exemple tout con sera-til possible de passer un message au serveur de passwords situé dans la machine C si le serveur X tourne su la mcahine B ?

          Ceci ouvrirait de splendides possibilitées dans le clustering, mais ouvrirait aussi des problèmes de sécurité non négligeables !

          Alors ?
  • # Un petit regret

    Posté par  (site Web personnel) . Évalué à -10.

    C'est dommage, http://www.hurdfr.org(...) , malgre son nom, ne fonctionne meme pas sous daCode! C'est dommage avec http://www.linuxfr.org(...) et http://www.muttfr.org(...) on commencait a s'habituer...

    Bon, hum, desole...
  • # Troll des cavernes

    Posté par  (site Web personnel) . Évalué à 7.

    Juste pour relever une phrase et un titre :
    "A Freer Cousin"

    "Distributions of GNU/Linux include commercially licensed software, and that diverts the user and developer community from the goal of freedom, according to Stallman."

    Je ne vois pas en quoi le système GNU va changer la donne, il sera toujours possible de faire des distributions avec GNU et d'y mettre des applis commerciales. En fait, on dirait que Stallman veut faire un HurdBSD qui serait le vrai OS libre, et pas l'imitation à la sauce finlandaise.
    • [^] # Re: Troll des cavernes

      Posté par  . Évalué à 1.

      "A Freer Cousin"

      Peut-être est-ce une réaction à l'utilisation de BitKeeper par Linus et une partie des développeurs du noyau ?

      -1 ça n'apporte pas grand chose
    • [^] # Re: Troll des cavernes

      Posté par  (site Web personnel) . Évalué à 0.

      RMS a a mon avis d'autant plus tort que l'hurd permet à l'utilisateur de se passer du root, en gros si j'ai bien compris.
      Ca veut aussi dire que n'importe quel soft à la windows a plus d'affinités avec l'hurd qu'avec linux... (à mon avis à moi)
      • [^] # Re: Troll des cavernes

        Posté par  (site Web personnel) . Évalué à 2.

        Doucement tu vas un peu vite en besogne. Les serveurs dont parlent l'article sont un peu comme des modules, il faut avoir les droits requis pour les installer.
        Donc si RMS a tort ici ce n'est pas dans l'avis qu'il a sur Hurd mais sur l'avis qu'il a sur le reste.
        • [^] # Re: Troll des cavernes

          Posté par  . Évalué à 9.

          Non, un serveur ce n'est pas du tout comme un module noyau. Un module noyau s'exécute en mode noyau sur le processeur et peut absolument tout faire, il est donc normal que seul root puisse en lancer. Un serveur du Hurd est un programme comme un autre, qui tourne avec l'indentité de l'utilisateur qui l'a lancé et ne peut rien faire de plus que ce que l'utilisateur a le droit de faire.

          Donc oui, n'importe qui peut lancer un serveur, mais ce serveur ne pourra faire que ce que l'utilisateur peut faire. Typiquement pour un translator lancé sur une image ISO, il faut que l'utilisateur puisse lire l'image ISO et possède le répertoire où l'image va être montée.
      • [^] # Re: Troll des cavernes

        Posté par  . Évalué à 10.

        l'hurd permet à l'utilisateur de se passer du root

        Déjà on dit le Hurd, pas l'hurd, merci. Ensuite, le Hurd ne permet à l'utilisateur de se passer du root et ne nuit pas du tout à la sécurité, au contraire. Il permet à l'utilisateur de faire des choses qui ne nuisent pas à l'intégrité du système mais qui sont impossibles à faire avec un noyau monolithique.

        Par exemple, avec Linux, si tu veux faire du ftpfs (monter un répertoire FTP dans ton VFS), il faut passer root, charger le module ftpfs, et introduire donc un nouveau programme, potentiellement buggué, dans le noyau. Avec le Hurd, tu lances un translator FTP, qui tourne sous ton identité, qui a tes privilèges, comme une application normale.

        <i>n'importe quel soft à la windows a plus d'affinités avec l'hurd qu'avec linux.</i<

        Que veux-tu dire par là ??
        • [^] # Re: Troll des cavernes

          Posté par  . Évalué à 1.

          En fait il voulait juste te provoquer parce qu'il trouvait que tu n'avais pas posté assez de commentaires dans cette nouvelle :)
        • [^] # Re: Troll des cavernes

          Posté par  (site Web personnel) . Évalué à 2.

          Déjà on dit le Hurd, pas l'hurd, merci.
          ben quoi t'as vu l'hurd qu'il est ?
          Il permet à l'utilisateur de faire des choses qui ne nuisent pas à l'intégrité du système mais qui sont impossibles à faire avec un noyau monolithique.
          jamais dit le contraire !
          Justement, comme linux interdit aux utilisateurs de monter ne serait-ce qu'un cdrom ou faire ce qu'ils veulent avec leur FS, ou se faire un tunnel ssh à eux, il n'est pas l'ami des sharewares ou applis gadgets.
          En revanche, un système comme l'hurd (il va me mettre un [-] vous allez voir !) permet des backdoors qui ne mettent pas en danger la securite du système, seulement des données de l'utilisateur.
          Evidemment, de telles backdoors ne proviendront pas du LL. Mais en donnant à l'utilisateur la possibilité de s'installer n'importe quoi, on fait de ce système le paradis du logiciel commercial investigateur de type .NET.
          • [^] # Re: Troll des cavernes

            Posté par  . Évalué à 2.

            En revanche, un système comme l'hurd (il va me mettre un [-] vous allez voir !) permet des backdoors qui ne mettent pas en danger la securite du système, seulement des données de l'utilisateur.

            Sous Linux c'est la même chose. Si quelqu'un lance un programme qui crée une backdoor sous ton compte, tes données sont en péril. De même si quelqu'un lance un serveur sur le Hurd avec ton identité, tes données son en péril. Les serveurs du Hurd sont simplement des programmes qui communiquent avec le micronoyau.

            Etienne
            • [^] # Re: Troll des cavernes

              Posté par  (site Web personnel) . Évalué à 7.

              C'est vrai, j'avais oublié qu'on pouvait quand même surveiller les process.
              On a juste beaucoup plus de possibilités avec la hurd qu'avec linux (et c'est pour cela que la hurd est mieux).
          • [^] # Re: Troll des cavernes

            Posté par  . Évalué à 4.

            Justement, comme linux interdit aux utilisateurs de monter ne serait-ce qu'un cdrom ou faire ce qu'ils veulent avec leur FS

            Il est possible sous Linux de laisser un utilisateur monter des cd-roms avec l'option "user" du fstab, mais ça nécessite un mount suider-root, ... c'est pas génial génial niveau sécurité tout ça.

            il va me mettre un [-] vous allez voir !

            Je mets très rarement des -, et là je ne t'en ai pas mis.

            un système comme l'hurd permet des backdoors

            Pas plus que sous Linux. Dans les deux cas si tu lances un logiciel propriétaire (ou que tu n'as pas vérifié) toutes les données auxquelles tu peux accéder sont potentiellement en danger. Le Hurd ne compromet pas la sécurité à ce niveau là.
            • [^] # Re: Troll des cavernes

              Posté par  . Évalué à -1.

              Il est possible de monter des partages samba avec smbmount en tant qu'utilisateur, sans pour autant que smbmount soit en setuid...
              • [^] # Re: Troll des cavernes

                Posté par  . Évalué à 2.

                Ne parle pas trop vite:
                man smbmount:

                NOTE: smbmount calls smbmnt(8) to do the actual mount. You must make sure that smbmnt is in the path so that it can be found.


                (kilobug@drizzt, 12) ~/download $ ls -l `which smbmnt`
                -rwsr-xr-x 1 root root 429192 mar 5 23:24 /usr/bin/smbmnt

                Qu'est-ce que tu disais à propos du suidé-root ?
                • [^] # Re: Troll des cavernes

                  Posté par  . Évalué à 1.

                  Au temps pour moi. Note, ça me paraissait bizarre, aussi, que samba soit une exception :o)
          • [^] # Re: Troll des cavernes

            Posté par  (site Web personnel) . Évalué à -1.

            Ben si, on peut monter mon CDRom sans se mettre root...

            Sur ma mandrake, je peux faire ça sur tous les systèmes de fichiers que j'ai décrit dans /etc/fstab...
    • [^] # Re: Troll des cavernes

      Posté par  (site Web personnel) . Évalué à 4.

      Peut etre qu'il voulait parler de la note de Linus Torvalds a propos de la licence qui permet d'utiliser du logiciel propriétaire avec le noyau.


      NOTE! This copyright does *not* cover user programs that use kernel
      services by normal system calls - this is merely considered normal use
      of the kernel, and does *not* fall under the heading of "derived work".
      Also note that the GPL below is copyrighted by the Free Software
      Foundation, but the instance of code that it refers to (the Linux
      kernel) is copyrighted by me and others who actually wrote it.
  • # La mort annoncée de GNU/Linux ?

    Posté par  . Évalué à 7.

    C'est les utilisateurs qui "tueront" ou non GNU/Linux.

    Les annonces de RMS (que j'admire) n'y changeront rien.
    • [^] # Re: La mort annoncée de GNU/Linux ?

      Posté par  (site Web personnel) . Évalué à 7.

      Non c'est clair que linux n'est pas prêt de mourir. (mais je ne crois pas que RMS dise celà d'ailleurs).

      J'admire les convictions de RMS et respecte son choix. Avec GNU on est sûr d'avoir du 100% libre face au 100% propriétaire de MS.

      Ce ne sera peut-être pas forcément à la pointe ni super fonctionnel mais ça existera en cas de problème. Les utilisateurs eux navigueront entre ces deux pôles selont les besoins.
      • [^] # Re: La mort annoncée de GNU/Linux ?

        Posté par  . Évalué à 8.

        J'admire les convictions de RMS et respecte son choix. Avec GNU on est sûr d'avoir du 100% libre

        La distribution GNU/Linux Debian n'est pas 100% libre ?
        • [^] # Re: La mort annoncée de GNU/Linux ?

          Posté par  . Évalué à 1.

          Ha non, pas encore, je rapelle pour la niéme fois que nonfree et conrtib ne font pas officiellement partie de GNU/Debian.
          Les répertoires (nonfree et contrib) sont simplemment "tolérés" sur les sites ftp de Debian (et donc absents sur les Cdrom's officiels).
          Bon, j'avoue que c'est un peu tiré par les cheveux mais "Officielement" il n'y a pas de logiciels à licence non libre dans GNU/Debian

          -1,HS
        • [^] # Re: La mort annoncée de GNU/Linux ?

          Posté par  . Évalué à 3.

          Il me semble bien que si. La partie non-free ne fait pas partie de la distribution, c'est une sorte de service qui est rendu en plus.
          Je vous accorde que c'est une pirouette mais la distribution Debian est 100% libre.

          Etienne
      • [^] # Re: La mort annoncée de GNU/Linux ?

        Posté par  . Évalué à 7.

        Ce ne sera peut-être pas forcément à la pointe ni super fonctionnel

        Qu'est-ce qui te permet d'affirmer ça ? A court terme peut-être, mais à long terme je pense que c'est plutôt Linux qui aura du mal à ce maintenir au niveau du Hurd sur les possibilités, la sécurité, ...

        Il suffit de voir comment on galère juste pour avoir du ftpfs sous Linux...

        Ou bien explique moi comment tu fais un serveur FTP non-anonyme sans lui donner les droits root...
        • [^] # Re: La mort annoncée de GNU/Linux ?

          Posté par  . Évalué à -5.

          Qu'est-ce qui te permet d'affirmer ça ? A court terme peut-être, mais à long terme ... / ...

          Moi ca me rappelle ce que j'ai lu à propos d'Unix, et de la multiplicité des versions qui a causé sa "perte"...
          Trop d'OS tue l'OS...
          • [^] # Re: La mort annoncée de GNU/Linux ?

            Posté par  (site Web personnel) . Évalué à 5.

            c'est ou qu'il est mort unix, tu m'explique ?
            • [^] # Re: La mort annoncée de GNU/Linux ?

              Posté par  . Évalué à -2.

              Chais pas pourquoi j'étais sûr que les guillemets entourant le mot "perte" ne suffiraient pas :)
              Replonge dans toi dans l'histoire de l'informatique de ces 15 dernières années, et tu verras que s'il n'est pas mort, Unix a quand même bien souffert...

              ++
              • [^] # Re: La mort annoncée de GNU/Linux ?

                Posté par  . Évalué à 1.

                Oui, la multiplication des unices a contribué à leur perte. Mais la grosse différence, AMHA, c'est qu'ici il ne s'agit pas de différences d'implémentation des normes Unix mais simplement un changement de noyau. Donc, à part l'incompatibilité binaire, le système GNU - Hurd est (kilobug corrige moi si je me trompe..) compatible POSIX et à priori un programme devrait être facilement portable d'un système à l'autre.
                • [^] # Re: La mort annoncée de GNU/Linux ?

                  Posté par  . Évalué à 7.

                  kilobug corrige moi si je me trompe

                  Arf :) je suis loin d'être l'expert sur le Hurd et les micro-noyaux ici, cela fait juste quelques mois que je m'intéresse au sujet et que je me docuemente, m'enfin bon....

                  Oui, GNU (GNU/Hurd si vous voulez) respectera les normes POSIX, tout en offrant d'avantages de possibilités, comme c'est toujours le cas dans le projet GNU. Bash est un shell POSIX avec des extensions, gcc 3.x est un compilateur C ISO 99 avec des extensions, ...

                  Maintenant à l'heure actuelle, l'intégralité de la norme POSIX ne doit pas encore être supportée par le Hurd (il manque les pthreads par exemple)
                  • [^] # Re: La mort annoncée de GNU/Linux ?

                    Posté par  (site Web personnel) . Évalué à 4.

                    Comment je fais pour mes programmes threadés ?
                    Ca gère mon SMP ?
                    La NVidia, elle fonctionne ?
                    Et mon modem ADSL ?

                    Je sens que je vais prendre un coup de vieux quand vont sortir les pilotes Fast-Ethernet en
                    user-space. Mon P133 aussi d'ailleurs.

                    > Pour des raisons de sécurité ? De fiabilité (lorsque tout marchera bien) ? Pour tous les avantages qu'il apporte(ra) ?

                    Est-ce que c'est fun ? Parce qu'avec Linus c'est fun.
                    RMS, le lisp, Emacs, Hurd...

                    Je crois que je commence à comprendre Al. Viro quand il se dit prêt à écrire sa libc.

                    Garçon, une vodka-Tranxen.

                    --
                    Ueimor
                    • [^] # Re: La mort annoncée de GNU/Linux ?

                      Posté par  (site Web personnel) . Évalué à 8.

                      Bon, avais répondu à ce comment, mais il semble avoir disparu totalement. Alors, j'y reréponds..

                      Comment je fais pour mes programmes threadés ?

                      Le Hurd lui-même est multi-threadé jusqu'à la moëlle. Il y'a donc bien gestion des threads. Il s'agit en fait des C-Threads, seule interface gérée par Mach pour ses threads kernel -- il avait été question d'un support des POSIX Threads, qui est évoqué dans les docs du CMU Mach, mais il semble n'avoir jamais vu le jour. Maintenant, il est vrai que rares sont les programmes qui utilisent les C-Threads, et qu'ils présentent des inconvénients majeurs par rapport aux pthreads..

                      Cependant, une implémentation des pthreads pour le Hurd, mais devant être un maximum portable - contrairement aux LinuxThreads de Xavier Leroy - est en cours de développement. (cf. <http://savannah.gnu.org/projects/pthreads/>(...)). Si elle n'est pas encore finie, elle réprésente un enjeu majeur selon tout le monde, et les meilleurs développeurs du Hurd y sont impliqués - Marcus Brinkmann, Roland McGrath (auteur de la GNU Libc, un des maintainers de GNU Emacs, co-auteur de GNU Make, un des deux concepteurs du Hurd...), ce qui pourrait amener une version stable avant l'été.

                      Ca gère mon SMP ?

                      En théorie, oui. Le SMP n'est pas la priorité du Hurd à l'heure actuelle, mais le support est bien présent, et il devrait le gérer à merveiller. Il reste un certain nombre de choses à faire pour qu'il exploite totalement ce SMP, mais ce ne sont pas des trucs vraiment difficiles à faire - même très faciles..

                      La NVidia, elle fonctionne ?

                      La NVidia, via le driver nv, oui. Si tu voulais parler des drivers NVidia propriétaires et du module Linux fourni, il est évident que non. Mais, c'est propriétaire ...

                      Et mon modem ADSL ?

                      Ça dépend. Le support USB n'est pas au programme. Concernant les modems ethernet utilisant PPPoE, le support PPPoE n'est pas encore fonctionnel, mais votre serviteur travaille actuellement sur un port de RP-PPPoE - comme cela a été fait pour FreeBSD, ce qui ne pose pas de problème majeur, le support PPP étant parfaitement fonctionnel.

                      Wala, wala, comment utiliser un troll pour présenter l'état actuel de la chose :-)
                      • [^] # Re: La mort annoncée de GNU/Linux ?

                        Posté par  (site Web personnel) . Évalué à 1.

                        L'état actuel de la chose est impressionant d'optimisme: "en cours", "pour bientôt", "pas dur".
                        Le Hurd dispose peut-être de codeurs de combat mais amtha tous les problèmes sont loins d'être
                        aussi simples qu'annoncé.

                        Pour l'instant, je n'ai pas vu *un* problème technique de la vie de tous les jours ou du
                        monde de la production que Hurd puisse prétendre résoudre mieux que la concurrence.
                        "aussi bien" ne passe pas mieux. :o(

                        Je ne suis pas sûr de bien savoir quels sont les objectifs du Hurd mais si gcc où Emacs pouvaient
                        prétendre innover d'une certaine manière, le Hurd semble lui encore un peu en retard.
                        Tant mieux, ca m'arrange de ne pas avoir à regarder tout de suite les sources :o)

                        --
                        Ueimor
                        • [^] # Re: La mort annoncée de GNU/Linux ?

                          Posté par  (site Web personnel) . Évalué à 4.

                          <i> L'état actuel de la chose est impressionant d'optimisme: "en cours", "pour bientôt", "pas dur". <i>

                          Non, ce n'est pas particulièrement optimiste. Les choses dont je parle précédemment sont presque prêtes, et, si il y'a encore quelques mois on ne pouvait avancer de date pour leur intégration, il est évident que toutes ces avancées majeurs auront lieu au premier trimestre 2001, avant l'été - ou un peu pendant. Par exemple, le passage à la libio et la libc0.3 est prévu pour juste après le mariage de Jeff Bailey - :) - soit courant avril..
                          OSKit-Mach est depuis longtemps bootable, assez stable, 'tc.. Il lui manquait particulièrement un support console décent, qui avance à grands pas, et sera bientôt prêt de l'avis même de son créateur.. Pour ces projets, on peut clairement dire qu'ils seront bientôt prêts. Maintenant, il y'a d'autres objectifs à long terme qu'il sera plus dur d'atteindre: le port du Hurd sur L4 ne sera pas fait d'ici un bout de temps, sera dur, demandera énormément de travail. Il vient tout juste d'ailleurs de _vraiment_ commencer. (c'est ce genre de signes qui montre que le Hurd _avance_.. L4-Hurd existe depuis des années et des années, et commence _maintenant_, c'est qu'on est à une période clé..). De même, la réécriture de pfinet sera quelque chose de long, passionant, mais extrêmement difficile, et peu de gens dans le Hurd possède les compétences nécessaires - s'il y'en a. Donc, pour ça, je ne me hasarderai pas à donner une date..


                          Pour l'instant, je n'ai pas vu *un* problème technique de la vie de tous les jours ou du
                          monde de la production que Hurd puisse prétendre résoudre mieux que la concurrence.
                          "aussi bien" ne passe pas mieux. :o(


                          Reprenons mon "gros" post:

                          1) une disponibilité sans pareille, notamment en terme de local down time (entendez, quand la machine est éteinte, ou en tous caa pas utilisables en local), mais aussi en down time "traditionnel", c'est à dire, le moment où la machine est up & running, mais pas joignable depuis le Net, ou le LAN où elle est utile. La modularité du Hurd permet notamment d'avoir des pfinet en relai - c'est _possible_, pas _fait_ - qui éviteraient pas mal de problèmes..

                          2) Une sécurité bien plus avancée, via le système des jetons d'authentification, qui permettent d'avoir un réel unknown, et de n'avoir que les permissions nécessaires - et donc, les permissions root que quand c'est absolument nécessaire.

                          La possibilité d'avoir un login shell peut s'avérer aussi tout à fait intéressante, même en production..

                          le Hurd semble lui encore un peu en retard.

                          Ça ne veut strictement rien dire. Un projet en développement serait nécessairement en retard ? Je l'ai dit et répété - alors, merci de bien vouloir _lire_ avant de parler - le Hurd est un projet en cours de développement, qui n'est pas abouti, et on ne prétend pas que GNU soit capable de remplacer GNU/Linux dans la vie de tous les jours dans un futur très proche.

                          À croire que certains sont incapables de sortir de leur logique de consommateur, pour s'intéresser à des avancées technologiques d'importance même si elles ne sont pas prêtes à être utilisées couramment sur leur petite machine, pour rendre leur vie so coooool. Tu m'étonnes qu'on manque de feedback dans les logiciels libres..
        • [^] # Re: La mort annoncée de GNU/Linux ?

          Posté par  . Évalué à 2.

          Ou bien explique moi comment tu fais un serveur FTP non-anonyme sans lui donner les droits root...

          Ben je vois pas ce qui empêche de créer un serveur ftp sur un port > 1024 et de creer des logins d'accès dans un système d'authentification quelconque (LDAP, SQL, fichier...)

          Et si tu veux utiliser les comptes système, alors là, je m'insurge ! Il n'y a rien de pire pour la sécurité d'un système que de donner la possibilité à un utilisateur de lancer un service avec une authentification qui utilise les mots de passe dudit système.

          La personne en question peut de ce fait TRÈS facilement récupérer les mots de passe des autres utilisateurs.

          Très franchement, sur ce coup là, l'exemple est TRÈS mal choisi...
          • [^] # Re: La mort annoncée de GNU/Linux ?

            Posté par  . Évalué à 2.

            Je parle du cas où tu (= admin de la machine) veux avoir un serveur FTP qui permette aux utilisateurs d'utiliser leur login/mot de passe et droits Unix.

            Sous GNU/Linux et tous les autres Unix, tu es obligé de lancer un serveur FTP avec les droits root pourqu'il puisse ensuite faire setuid() avec l'UID de celui qui vient de s'authentifier. Ton serveur FTP est donc un énorme trou de sécurité potentielle puisqu'il est root.

            Sous GNU, tu dois toujours lancer ton serveur avec des droits spéciaux pour qu'il puisse faire un bind() sur le port 21. Mais ensuite il peut abandonner tout privilège, toute identité, et lorsque quelqu'un lui donnera un login/mdp il demandera alors des droits au serveur de mot de passes.

            Dans les deux cas, seul l'admin (ou quelqu'un de privilégié) a pu lancer le serveur FTP sur le port 21, donc tu ne compromets pas du tout la sécurité de la manière dont tu parles. Mais par contre un trou dans ton serveur FTP n'aura que des conséquences mineures, et ne pourra jamais donner un shell root à un cracker.

            Bien sur, un user normal peut lancer un serveur FTP de ce type sur un port > 1024, mais là c'est celui qui est suffisament inconscient pour donner son mdp dans de telles conditions qui commet une faute, et pas une erreur de conception du Hurd.
  • # Une distribution, deux noyaux, c'est comme ca que ca va finir

    Posté par  . Évalué à 2.

    Aprés tout,il y a deja des 2.2 et des 2.4 dans les distrib. Pourquoi pas un Hurd en plus ?
    Sans vérifier, ca doit être compatible binaire Linux, puisque Linux utlise deja les outils GNU.

    En tout cas, plus il y a de choix, mieux c'est.
    Surtout si ze Hurd est/devient super super, Linux devrat lui aussi s'amméliorer encore plus.

    C'est ou Hurdfr.org deja ?
    • [^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir

      Posté par  . Évalué à 10.

      La compatibilité binaire entre GNU et GNU/Linux n'existe pas à l'heure actuelle, il faut recompiler les applications.

      Il y aussi d'autres choses qui sont légèrement différentes, par exemple LILO ne sait pas charger le Hurd, il faut utiliser Grub, le système de translator est légèrement différent du système de points de montages (avec les translators passifs par exemple il n'est pas nécessaire de relancer un mount /dev/hda2 /home à chaque boot, ...)

      Mais il existe une Debian GNU/Linux Sid et une Debian GNU/Hurd qui sont assez proches et ont beaucoup d'applications en commun. Pour un utilisateur final, les différences sont peu visibles, si ce n'est que le Hurd offre plus de possibilités, et surtout de manière plus propre (plus de besoin d'une couche gnome-vfs ou kioslave pour acceder à un répertoire FTP ou un .tar de manière transparente, ...)
      • [^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir

        Posté par  (site Web personnel) . Évalué à 0.

        La compatibilité binaire est prévue ?
        Comme les 2 OS ne diffèrent pas de grand chose (le kernel et l'interface avec le kernel), ca ne doit pas etre trop dur non ?
        En tout cas un freebsd et un GNU/linux ont moins en commun que les 2 versions du GNU
        (sauf si certaines applis passent du userland linux au serverland (???) Hurd)
        • [^] # Re: compatibilité binaire

          Posté par  (site Web personnel) . Évalué à 10.

          Bon, encore un commentaire auquel j'avais déjà répondu, mais la réponse n'est pas apparue. :(

          La compatibilité binaire est effectivement prévue, comme un objectif à long terme, mais n'y comptez pas dans le futur proche.

          Mais je tiens à réagir sur ton affirmation disant que « Comme les 2 OS ne diffèrent pas de grand chose (le kernel et l'interface avec le kernel) ».

          C'est complètement faux. FreeBSD et GNU/Linux ont bien plus de points communs que GNU. Ils sont tous deux extrêmement proche d'Unix, alors que GNU n'est pas à la base proche d'Unix - le Hurd et la GNU Libc s'efforcent juste de fournir une compatibilité POSIX.

          En particulier, concernant le Hurd, nombre de notions classiques sous Unix n'existent plus:

          * La notion de fichier en soi. Comme déjà dit dans mon commentaire précédent, le fichier n'est plus à la base qu'une interface permettant de joindre une application, et le système de fichiers n'est plus qu'un espace de nom pour obtenir des ports. Il est évident que le Hurd supporte néanmoins ext2fs, et UFS, et donc la notion de fichier tradionelle. Cependant, ça n'est pas un concept propre au Hurd, et les appels systèmes habituels de manipulation des fichiers ne sont que des interfaces de compatibilité - pour les basiques, réalisables via de simples RPC (Remote Procedure Call) à l'application qui écoute derrière, mais beaucoup plus difficilement pour certains autres, et en particulier, pour retourner des erreurs dans des cas précis définis par POSIX...

          * Les notions traditionneles d'UGIDs (entendez, UID et GID). Le modèle « un programme, un (e)UID » est complètement cassé pour faire place au principe des jetons d'authentification (authentification tokens), modèle bien plus puissant, où l'on peut acquérir - via le serveur password - plus de droits dynamiquement - sans pour autant devenir root, vu que l'on peut avoir plusieurs jetons correspondant aux droits de plusieurs utilisateurs, en soustraire - jusqu'à ne plus en avoir du tout, permettant l'existence d'un _réel_ nobody - il est dit « unknown » - qui n'est __pas_ un utilisateur, et n'a à la base aucun droit - si ce n'est utiliser ce que l'application a créé avec des droits supérieurs auparavant bien entendu, sauf si l'administrateur lui en donne - il y'a maintenant plus seulement ugo, mais aussi ugok, pour unKnown. Cela est particulièrement intéressant concernant les applications devant ouvrir un port « sécurisé » - comme un FTPd - (< 1024), requierant les droits root: on lance l'application en root, on ouvre le socket, on bind, listen, et dès que tout cela est fini, on s'enlève tous les droits. Ainsi, une faille à ce niveau n'aurait _aucune_ conséquence, puisqu'il ne pourrait _rien_ faire.. Par la suite, il n'y a plus qu'à transmettre les données fournies par l'utilisateur au prompt de son client FTP au serveur password, l'authentifier, et le voilà avec ses propres droits d'utilisateur et pas plus, sans
          aucune difficulté.
          De même, ce concept de serveur auth à qui on demande l'autorisation avant de faire n'importe quelle opération permet d'implémenter facilement, de façon jolie, performante, et native, le système
          des capabilities Linux - connu pour son inflexibilité, ce qui explique pourquoi il est si peu utilisé.. - et les prétendus systèmes révolutionnaires comme LIDS.

          Par faute de temps je m'arrêterais là, mais il faut savoir qu'il y'a encore de nombreux exemples, et qu'au fur et à mesure, si la compatibilité POSIX devrait s'améliorer, le Hurd devra s'éloigner d'Unix, essayant de faire mieux pour tous les domaines - par exemple, concevoir un nouveau système d'init, pour remplacer les init SysV et BSD, qui ne sont pas des modèles de propreté et d'efficacité ANHA. Cependant, ça n'est pas spécifique au Hurd: c'est une idée générale derrière le GNU, et beaucoup des codes faits pour le Hurd sont en fait réutilisés dans les autres ports de la GNU Libc - pensons à argp, aux pthreads, au futur système d'init justement..

          Ah oui, dernière chose: ta distinction entre userland et serverland n'a pas du tout lieu d'être. Les applications qui composent le Hurd - le micro-noyau ne faisant PAS partie du Hurd - sont des applications e-x-a-c-t-e-m-e-n-t c-o-m-m-e les autres, certaines ayant des rôles similaires à des applications que tu peux trouver sous GNU/Linux.

          Commentaires, questions, tout cela est bienvenu, je me sens tout seul sans réponse. :)
      • [^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir

        Posté par  . Évalué à 3.

        plus de besoin d'une couche gnome-vfs ou kioslave pour acceder à un répertoire FTP ou un .tar de manière transparente, ...

        Mouais, c'est un argument qui ne me convaint (c'est comme ça qu'on conjugue convaincre ?) pas...

        Le seul inconvénient de gnome-vfs ou kioslave, c'est qu'ils sont 2 et que si on utilise à la fois une appli gnome et une appli kde qui utilisent ces fonctionnalités, on a des trucs qui font double emploi.

        Mais en l'absence d'une solution technique à un problème, on va toujours se retrouver dans le même genre de cas, que ce soit facile ou pas à faire, il y aura toujours de multiples implémentations de la même chose...

        Par ailleurs, gnome-vfs et kioslave étant en userspace, il n'y aurait pas de différence flagrante s'il existait des translators, si ce n'est l'organisation autour du µ-noyau.
    • [^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir

      Posté par  . Évalué à -1.

      ca doit être compatible binaire Linux, puisque Linux utlise deja les outils GNU.
      Sans vérifier, Windows doit avoir une compatibilité binaire avec Linux, puisque on peut utiliser Gimp sous Windows.

      Comment ca j'ai dit une connerie ?

      Percision : il suffit de recompiler les outils GNU pour les faire fonctionner sur un OS ou un autre, tout simplement. Ce n'est pas pour ca qu'il y a compatibilité binaire.
      Maintenant rien n'empêche que ce soit le cas, effectivement.
    • [^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir

      Posté par  . Évalué à 3.

      ca doit être compatible binaire Linux, puisque Linux utlise deja les outils GNU.
      Sans vérifier, Windows doit avoir une compatibilité binaire avec Linux, puisque on peut utiliser Gimp sous Windows.

      Comment ca j'ai dit une connerie ?

      Percision : il suffit de recompiler les outils GNU pour les faire fonctionner sur un OS ou un autre, tout simplement. Ce n'est pas pour ca qu'il y a compatibilité binaire. C'est compatible source (si l'expression existe).
      Maintenant rien n'empêche que ce soit le cas, effectivement.
    • [^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir

      Posté par  . Évalué à 3.

      Attention la compabilité binaire c'est de la connerie !!!

      Une application linux native ne tournera pas aussi bien sous linux qu'en compatibilité binaire sous Hurd, puisqu'elle ne profitera pas de la conception µnoyau de GNU/Hurd. Si un serveur Hurd de compatibilité binaire linux doit exister un jour, il fera un boulot de porc.

      Les applis linux native n'auront pas une performance optimale et on dira que Hurd c'est lent tout ca à cause d'une bande d'abrutis qui ont eu la flemme de recompiler leurs applis (il me semble que Hurd est conforme posix, ou du moins y est destiné, donc la compil ne doit pas poser de problème) ou qui ont envie (honte sur eux !!! :) d'utiliser du propriétaire linux avec Hurd.

      alors bon, la compatibilité binaire, oui mais avec modération (vachement même !).
      • [^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir

        Posté par  . Évalué à 4.

        >Une application linux native ne tournera pas >aussi bien sous linux qu'en compatibilité >binaire sous Hurd

        hum, je crois que tu as un peu inverse ce que tu voulais dire :)
        Une appli tournera mieux sur le systeme vise que sur une "emulation" (je ne trouve que ce mot), ce qui semble logique...
  • # Différences

    Posté par  (site Web personnel) . Évalué à 4.

    Pour les softs, il faut changer quoi entre un système /Hurd et un /Linux ?
    la glib est changée mais garde la meme API du point de vue user je présume.
    Xfree doit etre modifié pour les drivers (le DRI)
    Les fs sont les memes a priori
    Les executables peuvent rester au meme format aussi
    L'init par contre, ca se passe comment ?

    Certains utilitaires doivent etre changés, bien que ca dépende des détails d'implémentation de la l'interface (si le /proc est compatible ca peut aider)

    Si les mainteneurs font bien leur travail, on devrait pouvoir passer d'un kernel a l'autre de maniere presque transparente ou est ce qu'il faudra maintenir 2 OS complets ?
    • [^] # Re: Différences

      Posté par  . Évalué à 10.

      L'API de la glibc (attention, ne pas confondre glibc (GNU Lib C) et la GLib (bibliothèque de base de GTK)) est la même sur GNU et sur GNU/Linux, modulo quelques extensions (je pense).

      XFree doit être modifié pour le DRI uniquement, actuellement c'est simple: il n'y a pas de DRI sous GNU, il faut le désactiver.

      Les FS peuvent être les mêmes ou bien ils peuvent être différents, pour l'instant la Debian GNU/Hurd utilise ext2fs par défaut. Un FS sous GNU ce n'est qu'un translator, un programme user-space normal, et il est donc possible d'en rajouter relativement simplement.

      Les éxécutables sont en ELF, mais la compatibilité binaire ne fonctionne pas actuellement.

      Pour l'init, ça dépend de la distrib je dirais... L'init n'est pas la même entre une Slackware te une Debian je crois, par exemple. Actuellement la Debian GNU/Hurd utilise une init System V comme la Debian GNU/Linux. Un nouveau système d'init est actuellement à l'étude.

      Si les mainteneurs font bien leur travail, on devrait pouvoir passer d'un kernel a l'autre de maniere presque transparente ou est ce qu'il faudra maintenir 2 OS complets ?

      Actuellement il faut des OS complets à cause du manque de compatibilité binaire, mais ce sont les mêmes programmes qui tournent sur les deux OS (en gros)
      • [^] # Curiosité

        Posté par  (site Web personnel) . Évalué à 1.

        Ça tourne sur combien de plate-formes Hurd (en dehors des déclinaisons de x86) ?
        • [^] # Re: Curiosité

          Posté par  . Évalué à 2.

          Ça tourne sur combien de plate-formes Hurd (en dehors des déclinaisons de x86) ?

          sur le site hurdfr.org, on peut lire :

          Actuellement, le Hurd tourne sur des machines IA32 (architecture x86). Le Hurd devrait, et probablement va, être porté sur d'autres architectures ou d'autre micronoyaux (voir OSKit-Mach et le projet L4).
        • [^] # Re: Curiosité

          Posté par  . Évalué à 3.

          Le Hurd tourne pour l'instant de façon sûre et testée sur x86 et PPC. Mais, c'est basé sur GNU Mach, qui est à la base un OSF Mach dont la licence a été changée - avec l'autorisation de l'OSF/CMU - et OSF Mach est porté - des implémentations pas toujours libres, cependant.. - sur de nombreuses plate-formes (cf http://www-2.cs.cmu.edu/afs/cs/project/mach/public/FAQ/platforms(...) )
  • # utilisable ?

    Posté par  (site Web personnel) . Évalué à 10.

    Je suis les liens de HurdFR et je tombe sur une FAQ qui m'orifie pour un systeme qui se veut bientot utilisable en prod :

    - 2.7. Pourquoi `/usr' est-il un lien symbolique vers `.'?
    {MB} La distinction entre / et /usr a une justification historique, du temps où les systèmes Unix étaient amorcés à partir de deux bandes, une petite bande root et une plus grosse bande usr. Ajourd'hui, il est toujours pratique d'avoir des partitions séparées pour ces deux espaces. Hurd se débarasse de ces rebuts historiques, parce que nous pensons avoir trouvé une solution plus souple, les systèmes de fichiers cachés. Malheureusement shadowfs n'est pas encore implémenté.

    Ok, ils ont trouvé une solution plus souple, mais qui n'est pas implémentée, donc pour l'instant on se trouve comme des cons non ?

    - Vous utilisez le partage d'IRQ; GNU Mach ne supporte pas cela
    Limite tout de meme. Je sais que sur un serveur le nombre de cartes est limitées mais bon ...


    - 3.6. Puis-je utiliser des partitions de plus d'1 Go?
    {NHW} Non, pas avant que libdiskfs soit réécrite et LFS implémenté. Des efforts sont faits en ce moment, cependant, ce n'est pas une priorité pour les développeurs.

    Là c'est du foutage de gueule ...
    Qu'un systeme tourne sur de partoches de 1Go je veux bien, mais de là à dire qu'il peut etre utilisable en prod ...
    Bonne chance votre serveur avec des partitions de 1Go. Et si c'est pour un poste de loisir ne cherchez pas trop à y mettre films ou jeux.
    Pas une priorité, suporter des disques de plus d'1 Go ..... arghhh, même dos il supporte 2Go non ?

    - 3.7. De combien de swap ai-je besoin?
    {NHW} Généralement, beaucoup ; dès qu'elle s'épuise, Mach panique. J'ai au moins 128Mo de ram et 256Mo de swap sur toutes mes machines Hurd.

    Pas top non plus pour de la prod ca .... si un process part en boucle et fait de l'affectation de mémoire en boucle (oui, je sais ca n'est pas sencer arriver .. mais ca arrive tout de meme) c'est le systeme qui panique ... génial ... surtout que la partition de swap doit pas pouvoir etre de plus d'1 Go non plus ? si ? bon là je suis de mauvaise foi, on n'a qu'a en mettre plusieurs. Mais le kernel qui panique c'est moyen je trouve


    Non, franchement, utilisable en prod ? soit ce doc date d'avant guerre (j'ai suivi un bete lien de debian/hurd ou de hurdfr, pas un truc trouvé au bout de 150 pages de recherche) soit c'est du foutage de gueule que de dire que c'est bientot utilisable en prod.
    • [^] # Re: utilisable ?

      Posté par  (site Web personnel) . Évalué à 3.

      > c'est du foutage de gueule que de dire que c'est bientot utilisable en prod.
      2002 n'est pas fini, il reste grosso-modo 9 mois, j'appelle pas ca "bientot". Donc il leur reste du temps pour coder et tester j'imagine...
      • [^] # Re: utilisable ?

        Posté par  (site Web personnel) . Évalué à 5.

        Par ce que tu penses que tout cela peut être implémenté et testé dans les neufs mois...

        Je trouve ça très très ambitieux...
        Il restera des problèmes ! c'est certain !

        Ne serait-ce que le système de partage IRQ... tous les tests qu'ils ont pu réalisé jusqu'à maintenant seront à refaire ! Absolument tous... !

        Alors, pour le serveur de prod, je suis entièrement d'accord avec daGanf : c'est impossible dans un futur proche.
    • [^] # Re: utilisable ?

      Posté par  . Évalué à 7.

      Ok, ils ont trouvé une solution plus souple, mais qui n'est pas implémentée, donc pour l'instant on se trouve comme des cons non ?

      ShadowFS est implémenté maintenant je crois.

      Limite tout de meme. Je sais que sur un serveur le nombre de cartes est limitées mais bon ...

      Le Hurd va passer sur OSKit Mach d'ici peu.

      Là c'est du foutage de gueule ...

      Ce sera corrigé d'ici la fin de l'année, et ce n'est pas du "foutage de gueule" pour une version de développement. Et la limite n'est pas d'1 Go partout elle varie de 1 Go à 4 Go suivant les machines.

      Pas top non plus pour de la prod ca ....

      Idem, c'est une limitation de GNU Mach qui n'existe pas dans OSKit Mach, pas une limitation du Hurd.
  • # GNU/Linux vs GNU/*

    Posté par  . Évalué à 3.

    Meme si le hurd progresse à grand pas je suis pas sure qu'il soit pour le moment un candidat serieux au remplacement de notre cher GNU/linux...

    Je pense que Gnu/linux est effectivement en danger de mort, mais pour d'autres raisons, certaines grosses distribs proposent de plus en plus des packages proprietaires, ils pensent peut etre attirer de cette facons les gros poissons. Et si cette tendance se generalise, je pense qu'une grande partie de la communaute cherchera rapidement une solution de remplacement.

    Mais bon, Gnu/linux a quand meme de beaux jours devant lui "because code matters most than commercial..."
    • [^] # Re: GNU/Linux vs GNU/*

      Posté par  . Évalué à 10.

      Meme si le hurd progresse à grand pas je suis pas sure qu'il soit pour le moment un candidat serieux au remplacement de notre cher GNU/linux...

      Le Hurd n'est pas un remplacement de GNU/Linux, juste de Linux. Tous les outils (glibc, ld, gcc, XFree, emacs, ...) restent à peu près les mêmes.

      Pour le moment, non, il n'est pas un candidat sérieux pour remplacer Linux sur les machines de prod. Pour le moment. RMS est optimiste et prévoit qu'il sera en 2002, pour ma part je dirais plutôt mi-2003, mais ni lui ni moi ne sommes des devins, ni même les mieux placés pour faire des prédictions.
    • [^] # Re: GNU/Linux vs GNU/*

      Posté par  . Évalué à -1.

      Passer sous GNU/Hurd, ne change rien au probleme.
      Ou veux-tu en venir ?
      • [^] # Re: GNU/Linux vs GNU/*

        Posté par  . Évalué à 1.

        Je sais bien que passer sous GNU/Hurd ne change rien au probleme, mais il laisse peut etre plus de temps a la reflection et la prise de positions sur les mesures à adopter pour ne pas faire la meme chose... Meme si repouser un probleme, ne resout en rien le probleme :)
    • [^] # Re: GNU/Linux vs GNU/*

      Posté par  . Évalué à 1.

      Ces distributions n'obligent personnes à utiliser les packages propriétaires. Le mec qui installe la nouvelle TotoLinux 9.4, il peux ne pas choisir ces paquets.
      • [^] # Re: GNU/Linux vs GNU/*

        Posté par  . Évalué à 1.

        Sauf la SuSE puisque YAST c'est pas libre...

        -1 [jeretournesurlatribune]
        • [^] # Re: GNU/Linux vs GNU/*

          Posté par  . Évalué à -1.

          Arf c'est vrai. Mais tout le monde sait que LA SUSE C'EST MAL, C'EST PAS GPL!

          -1 troll gratuit [ilfaitchaudsurlatribune]
          • [^] # Re: GNU/Linux vs GNU/*

            Posté par  . Évalué à -1.

            LA SUSE C'EST MAL, C'EST PAS GPL!

            La Debian non plus (à moins que tu désinstalles X, LILO, et tout un tas de trucs... Serait-ce encore utilisable ?)

            -1 Troll GPL
  • # Hurd, ça fonctionne ?

    Posté par  (site Web personnel) . Évalué à 1.

    Qui peut nous donner son meilleur uptime avec GNU/Hurd ?

    Perso, j'ai pas essayé. Mais je parie qu'il y en a pas mal d'autres qui n'ont pas essayé et qui peuvent m'assurer que c'est super parce que c'est du µK (je suppose que ca doit vouloir dire microkernel). Pfff encore du buzz. Et pour une fois c'est pas µ$ qui le fait.


    If a camel is a horse designed by a committee, then a consensus forecast is a
    camel's behind.
    -- Edgar R. Fiedler

    (repris des excellentes fortune BSD)
    • [^] # Re: Hurd, ça fonctionne ?

      Posté par  (site Web personnel) . Évalué à 2.

      Fortunes du jours linux au moment de la validation précédent poste :

      Ils l'ont fait exprès
      <tt>
      <_seb_> sammy; pas envie de rentrer dans des querelles d'OS à la con; une
      becane, ca me sert à bosser. avec hurd, tu t'amuses.

      - #francaise
      <tt>
      Au fait, j'aimerais vraiment connaître le meilleur uptime hurd.
      • [^] # Re: Hurd, ça fonctionne ?

        Posté par  . Évalué à 2.

        Une petite recherche sur google me donne :
        http://www.vicenza.linux.it/~vicenza/mailing-list/lugvi-fans-200008(...)

        un uptime de 8 jours.

        et sur :
        http://hurd.dyndns.org/age.html(...)

        Il dit avoir eu un uptime maximum de 6 semaines.

        Si tout ceci est vrai, je trouve ca pas mal pour un système en plein développement
        • [^] # Re: Hurd, ça fonctionne ?

          Posté par  (site Web personnel) . Évalué à 8.

          Tout ceci est vrai.J'ai moi-même tenu environ 6-7 semaines. Un bug de zmalloc - de GNU Mach, donc - fait qu'il est difficile de tenir plus que ça. En réalité, le Hurd pourrait tenir probablement bien plus longtemps, les limitations à ce niveau sont vraiment au niveau de GNU Mach, qui n'est que très peu développé, et délaissé depuis quelques temps pour OSKit Mach (<devin> j'estime que le passage à OSKit-Mach devrait se faire d'ici l'été, un peu après la libc0.3 - avec libio - et hopefully avec les pthreads </devin>). Il faut voir que GNU Mach n'est qu'un OSF Mach pour lequel la FSF a obtenu la permission de le mettre en GPL, et qui n'a été que peu modifié. - de façon quand même conséquente, mais bon.. Le rôle principale de GNU Mach était surtout de développer le Hurd. Pas de refaire un micro-noyau tout neuf, etc.. On verra ça avec L4, plutôt. :-)

          Sinon, pour répondre au comment précédemment sur la FAQ: non, GNU n'est pas encore usable en production. Non, il n'est pas aujourd'hui envisageable de l'utiliser dans la vie de tous les jours à la place de GNU/Linux avec un gain; Il peut faire à peu près tout ce que fait GNU/Linux, le problème est qu'actuellement, il n'est pas du tout optimisé, et il y'a encore de nombreuses limitations et problèmes d'instabilité.

          Pour commenter les déclarations de RMS: Il n'a pas rendu service, AMHA, au Hurd, en disant cela. Et les premiers surpris ont été les développeurs du Hurd. Marcus (Brinkmann, qui a relancé le développement du Hurd en '98-99 après environ 7 ans au ralenti, fondé Debian GNU/Hurd, etc.) a franchement fait la gueule quand il a vu la news sur /. et imaginé le nombre de conneries qui allait se dire :-) Tout ça pour dire: ne le prenez pas _trop_ au sérieux. Ça ne veut pas se dire qu'il faut se déinstéresser du Hurd: il mérite à mon avis qu'on y jette un oeil, et, c'est un projet qui a vraiment besoin de participants, et celà à tous les niveaux. En plus, on se sent vite important, et on est très encouragés :)

          Moralité: Le Hurd? Engagez-vous, rengagez-vous!
          • [^] # Re: Hurd, ça fonctionne ?

            Posté par  . Évalué à -1.

            Il faut voir que GNU Mach n'est qu'un OSF Mach pour lequel la FSF a obtenu la permission de le mettre en GPL
            Donc OSF Mach n'est pas GPL ? Ca veut dire que la FSF va utiliser un micro-noyau non libre ? Je ne comprends pas trop, quelqu'un peut m'expliquer ?

            Tout ça pour dire: ne le prenez pas _trop_ au sérieux.
            Moi, personnellement, ce genre d'effet d'annonce me fait furieusement pensé à ... Mr Bill Gates. Juste pour que l'on s'interesse à son projet. Bon, je pousse un peu quand même, je le reconnais (=> -1).
            • [^] # Re: Hurd, ça fonctionne ?

              Posté par  (site Web personnel) . Évalué à 2.

              Donc OSF Mach n'est pas GPL ? Ca veut dire que la FSF va utiliser un micro-noyau non libre ? Je ne comprends pas trop, quelqu'un peut m'expliquer ?

              Relis donc mon post. Jamais nous n'utiliseront OSF Mach qu'à des fins de portages, et ce de façon tout à fait temporaire. Les seuls noyaux que le Hurd utilise officiellement, c'est GNU Mach, et sa variante utilisant les drivers du projet OSKit <http://www.cs.utah.edu/flux/oskit/>(...) , OSKit-Mach, qui est la seule version développée depuis quelques temps et qui avance vite - notamment au niveau du joli nouveau support console, avec support de l'internationalisation excellent, multi-head, splitvt, équivalent de screen -rx, etc..

              Moi, personnellement, ce genre d'effet d'annonce me fait furieusement pensé à ... Mr Bill Gates. Juste pour que l'on s'interesse à son projet. Bon, je pousse un peu quand même, je le reconnais (=> -1).

              Il faut voir aussi que son post a été détourné. Il n'a pas dit explicitement que GNU remplacerait GNU/Linux partout dans toutes les machines d'ici la fin de l'année. En revanche, il a annoncé une release de GNU, ce qui veut dire en réalité que la FSF prépare sa propre version du GNU, qui reprendra probablement beaucoup de Debian GNU/Hurd, mais qui sera indépendant de Debian.
              Il me semble que ça méritait d'être annoncé, mais ne méritait peut-être pas toute la réutilisation qui en a été fait sur /. et ici même.
      • [^] # Re: Hurd, ça fonctionne ?

        Posté par  (site Web personnel) . Évalué à -1.

        il me semble que la fortune a été un peu détournée ;-)

        la version originale est "pas envie de rentrer dans des querelles d'OS à la con; une
        becane, ca me sert à bosser. avec linux, tu t'amuses.
        "
  • # Oui mais...

    Posté par  (site Web personnel) . Évalué à 1.

    Linux ça tourne sur pas mal d'archi, comme MIPS, PPC, etc etc et même sur des archis sans MMU.
    De plus, Linux commencent à avoir des extensions temps réels.
    Qu'en est-il du Hurd ?
    Est-ce que l'architecture µnoyau permet de s'en tirer avec une empreinte mémoire moins importante que Linux. Est-ce qu'on peut facilement tailler des croupières au Hurd pour le faire tourner sur un IPaQ ?

    Si les réponses sont non, Linux à de très beaux jours devant lui...
    • [^] # Re: Oui mais...

      Posté par  (site Web personnel) . Évalué à 4.

      Renseigne-toi un peu sur les micro-noyaux..

      Le Hurd est actuellement porté sur x86 et sur PPC, comme cela a été dit plus tôt. Cependant, il faut savoir que le Hurd lui-même est extrêmement portable - le port PPC n'a nécessité que très très peu de modifications au Hurd lui-même - et qu'il suffit donc de porter le micro-noyau - Mach actuellement. Ce micro-noyau, sous la forme d'OSF Mach - identique à GNU Mach modulo quelques modifications mineures, a été porté sous de nombreuses plate-formes, que ce soit des ports officiels (DEC Alpha, m68k, etc.) ou des ports non officiels (plus récemment, MIPS, et plein d'autres architectures..).

      Porter le Hurd n'est donc vraiment pas chose difficile, d'autant plus qu'il a toujours été conçu pour être tout à fait portable. Concernant les architectures sans MMU, je ne sais pas vraiment ce qu'il en est des ports Mach, donc je ne m'avancerais pas. D'autant plus que je connais pas trop ce genre d'architectures..

      Concernant le temps réel, c'est quelque chose qui est assez naturel, bien que le Hurd n'ait pas été conçu pour être temps réel, et ne l'est pas à l'heure actuelle. Si tu veux parler de simples extensions temps réel comme celles définies par le standard POSIX, leur support est partiel, mais est complètement possible, et même, pas très dur à implémenter.

      Pour ta dernière phrase, j'avoue que j'ai du mal à la comprendre. S'il s'agit de faire un « light Hurd » pour le faire tourner sur des architectures
      matérielles disposant de peu de mémoire, oui, c'est tout à fait possible. Il est notamment tout à fait possible d'élaguer considérablement le Hurd, en ne compilant que les serveurs essentiels,
      ce qui réduira sa taille de façon très importante très facilement. De plus, l'indépendance de chaque application permet de facilement remplacer les serveurs qui pourraient poser problème pour le portage sur ces « petites » machines par d'autres, ne fournissant qu'un subset basique de ce que l'application d'origine fournissait. C'est ce genre de flexibilité que permet une architecture à micro-noyau, et un système multi-serveurs comme le Hurd, justement ..

      Ceci dit, je le répète, le Hurd n'est pas fini, et GNU n'est pas une alternative viable à GNU/Linux pour l'utilisation quotidienne, à l'heure actuelle. Non pas tellement par son manque de fonctionnalités - ça se rebouche très vite.. - mais pour des questions de stabilité - sachant que l'ensemble du feature set n'est pas encore tout à fait implémenté, la stabilité n'est pas _la_ considération principale - et de performances. (le Hurd n'est pas du tout optimisé, ni GNU Mach, et GNU Mach n'est probablement pas le meilleur choix pour les performances - bien qu'il présente de nom breux avantages).
      • [^] # Re: Oui mais...

        Posté par  . Évalué à 1.

        Je vais surement passer pour un imbécile mais j'assume : HURD qu'est ce que c'est ? Un parralèle à Linux ? Il y a une différence fondamentale ? C'est la FSF qui devellope HURD et Linus qui devellope Linux c'est ça ??

        Nico - perdu -
        • [^] # Re: Oui mais...

          Posté par  . Évalué à 3.

          HURD qu'est ce que c'est ?

          Le Hurd est un ensemble de serveurs tournant par dessus un micro-noyau et proposant aux programmes des fonctionnalités équivalentes (ou supérieures) à celles fournies par les noyaux monolithiques comme Linux.

          Un parralèle à Linux ?

          Si on veut, disons qu'un micro-noyau (GNU Mach, OSKit Mach, ...) + le Hurd peut (pourra) remplacer Linux dans un système.

          Il y a une différence fondamentale ?

          Oui, plusieurs différences fondamentales, tout a déjà été expliqué plus haut par Manuel Menal et moi (entre autres), relis les commentaires.

          C'est la FSF qui devellope HURD et Linus qui devellope Linux c'est ça ??

          C'est plus compliqué que ça. Linux est développé par un grand nombre de programmeur, dont Linus qui est "l'architecte"; dans le cas du Hurd "l'architecte" serait plutôt Marcus.

          Le Hurd est un projet GNU officiel, au même titre que GNU Emacs, gcc, la GNU libc ou GNU bash, mais il n'est pas développé directement par la FSF, mais plus par des contribueurs de part le monde, comme Linux ou les autres projets libres.
          • [^] # Re: Oui mais...

            Posté par  (site Web personnel) . Évalué à 10.

            C'est plus compliqué que ça. Linux est développé par un grand nombre de programmeur, dont Linus qui est "l'architecte"; dans le cas du Hurd "l'architecte" serait plutôt Marcus.

            Pas tout à fait. Marcus Brinkmann est actuellement probablement le développeur principal du Hurd, celui
            qui est le plus actif. Il a de plus le mérite d'être arrivé dans le monde du Hurd autour de '98-'99, à un moment où le Hurd était un projet plutôt inactif depuis plusieurs années - environ 7 ans -, et de l'avoir relancé à lui tout seul, en créant Debian GNU/Hurd, etc. Mais, les architectes principaux du Hurd sont Thomas Bushnell et Roland McGrath, les deux ayant été un temps employés par la Free Software Foundation, et le deuxième étant un grand personnage - comme dit précédemment, auteur de la GNU Libc, co-auteur de GNU Make, maintainer d'une partie de GNU Emacs, etc. Thomas ne participe plus aujourd'hui au Hurd que pour donner son avis, et parce qu'il connaît bien le sujet, quand même. Mais, il consacre son temps à la philosophie. :)

            Roland participe encore aujourd'hui au Hurd, même s'il ne le peut pas très activement étant donné qu'il doit quand même vivre - par sa propre boîte, FrobTech.

            Alors, donnez à la FSF pour qu'elle emploie Roland! :-)

            Pour reprendre la deuxième partie, je suis tout à fait d'accord. Il faut noter de plus que la FSF n'a aidé le Hurd qu'à ses débuts, et qu'elle n'a pas été une grande aide du tout pendant pas mal d'années, le considérant comme un projet mort jusqu'il y'a peu de temps - à tort, je l'affirme, et en conséquence, ne donnant aucun moyens aux développeurs - développer un tel logiciel demande pas mal de moyens, car cela nécessite généralement plusieurs PC, des PCs très performants. Ainsi, il aurait été d'une grande aide qu'on ait accès plus tôt à plusieurs machines sous GNU via SSH, mais il a fallu attendre que l'université de Massachusetts
            Lowells, où étudie Neal Walfield, donne deux/trois machines.. Espérons que l'annonce de RMS s'accompagnera des moyens qui seraient nécessaires pour avoir un système GNU parfaitement utilisable rapidement, notamment en terme d'emploi de personnes par la FSF.
  • # Pourquoi ?

    Posté par  . Évalué à 1.

    Salut à tous

    Pourquoi les opposer ?
    L'émulation est bonne à prendre, on installera les 2 sur nos machines.

    Bye
  • # n'en déplaise aux opposants du Hurd

    Posté par  (site Web personnel) . Évalué à 1.

    Je leur rappelerai que les systèmes à base de micro noyau ont largement prouvé leurs capacités et qu'ils peuvent être tout aussi performant que des systèmes à noyau monolithique.
    Je prendrais comme premier exemple BeOs (même si commercialement parlant ca a été un flop...)
    Et en deuxieme exemple, l'un des plus stable et des plus performants (lui au moins sait faire du vai temps réèl) : QNX.
    Ce système existe depuis le debut des années 80 et est beaucoup utilisé dans les systèmes embarqués, environnement qui necessite une stabilité à toute épreuve...

Suivre le flux des commentaires

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