Le Hurd bientôt au niveau de l'Everest !

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
5
mar.
2003
GNU
La toute dernière version de la distribution entièrement libre Debian GNU/Hurd vient de sortir !

Elle est nommée K2, et se compose de 5 CD. (NdM: comme indiqué dans le mail en pièce jointe, seules 2 iso sont actuellement sur le FTP)

Vous avez donc une formidable opportunité de tester GNU pour de vrai, toutes les docs figurent sur le CD1 (ce CD contient tous les paquets principaux et indispensables, et peut donc être utilisé seul pour débuter).
Il manque (cf mail ci-dessous) un paquet pour faire fonctionner Xfree, mais celui-ci devrait être disponible assez prochainement.

Amusez-vous bien avec GNU ! Mail de l'annonce officielle de Philip Charles envoyé ce matin (pas encore dans les archives) :

The first two K2 images are now on ftp.gnu.org/iso thanks to Andrew Mitchell. The next two should be available in the next day or so.

The main change has been a revision of how the packages are placed on the CDs and the introduction of install.sh which installs the required,
important and standard packages as defined in the Priority field.

gui.sh is still there despite xfree not working. [Note: en fait il manque un seul package pour faire fonctionner X, il devrait être dispo bientot...]

More *hurd-i386.deb's are being forced onto the second CD and people
installing without a network connection may find that the need the second
image. Could I have feed-back about this please.

I have been stupid enough to allow myself to become over committed for the
next three months, but I hope that the present scripts will allow me to
build the K3 series with little hassle. I would suggest that this could
be done once xfree is working again. Would someone inform me when this
happens.

Enjoy GNU.

Phil.

Aller plus loin

  • # Re: Hurd bientot au niveau de l'Everest !!!

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

    Premier troll dans moins de 15 secondes. -1 ==> []
  • # Re: Hurd bientot au niveau de l'Everest !!!

    Posté par  . Évalué à 10.

    Ah, c'est bien ! Depuis le temps qu'on en parle. Mais sachant que du GNU, ça devrait être du bon. Si j'ai du temps, j'essaierai. J'espère que ce système a de l'avenir. Mais il ne semble pas y avoir beaucoup de monde dessus actuellement. Est-ce que d'autres distrib seraient compatibles ? Comme Gentoo par exemple. Allez bon courage ! Vous le méritez !
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

      Posté par  . Évalué à 4.

      oui, gentoo pourrait être compatible, ce serait d'ailleurs je pense un projet super intéressant.... Je t'en reparle bientot... ;)
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

      Mais il ne semble pas y avoir beaucoup de monde dessus actuellement. Ben l'avenir de hurd, c'est surtout le micro noyau l4. Et sur le portage hurd vers l4, on peut considérer qu'il n'y a q'une seule personne (neil walfield, celui qui a ajouté les pthreads à hurd). Par contre pour compiler des packages pour debian hurd, là il y a pas mal de monde. Il y a aussi pas mal de gens qui écrivent des translators (les programmes qui permettent de monter un serveur ftp comme un dur par exemple). Il manque vraiment des programmeurs sur le "coeur" (pour ne pas dire kernel) du hurd, histoire par exemple qu'ils ne se retrouvent pas avec 200 types de systèmes de fichiers supportés, mais tous limités à 2Go (comme c'est le cas pour ext2 et jfs en ce moment).
      • [^] # Re: Hurd bientot au niveau de l'Everest !!!

        Posté par  . Évalué à 1.

        question bête car je ne suis pas developpeur: Comment s'organiser pour developper des bouts de systèmes sans risquer de crasher le reste de son disque dur. Peut-on utiliser vmware par exemple pour éviter de casser tout son disque ? Personnellement, je n'ai pas de machine dispo pour faire ça. Y a-t-il un émulateur bien ? Peut-être ne peut-on pas le faire dans un émulateur PC ?
        • [^] # Re: Hurd bientot au niveau de l'Everest !!!

          Posté par  . Évalué à 10.

          Tu peux le tester avec Bochs, qui est libre... :) Sinon, tu as les sub-hurd, à savoir que tu fais tourner deux ou trois hurds au-dessus de Mach (c'est assez facile à faire) et du coup tu as un système stable, et un ou deuxpour tester. (comment ca, ca change les habitudes ? ;)
      • [^] # Re: Hurd bientot au niveau de l'Everest !!!

        Posté par  . Évalué à 10.

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

          Posté par  . Évalué à 8.

          Dans la série boulet intergalactique, après chris, je voudrai .. mmenal ! Bref, j'ai oublié les notes que je voulais laisser. Les voici : [0]: http://www.gnu.org/software/hurd/hacking-guide/hhg.html [1]: http://www.8ung.at/shell/ en allemand, mais tout à fait compréhensible :-)
  • # Re: Hurd bientot au niveau de l'Everest !!!

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

    GNU/Linux <==> le systeme GNU avec le noyau Linux. GNU/HURD <==> systeme GNU avec le micro-noyau HURD ==> de toutes façons, on fait toujours du GNU. Le reste c'est la gueguerre noyau monolythique vs Micro-noyau. Qu'importe le noyau du moment qu'on a livresse du GNU. ^^
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

      > GNU/HURD <==> systeme GNU avec le micro-noyau HURD Raah, il a mal appris sa leçon ! HURD, c'est la collection de serveurs qui tourne sur le micro-noyau mach. Linux ne fait pas partie du projet GNU. C'est un remplacement bien utile, et plus ou moins la seule solution pour rendre GNU opérationel en production. Il y a de grandes divergences d'opinion entre RMS et Linus, donc, ne dit surtout pas à des gens de la FSF que Linux, c'est du GNU ;-)
      • [^] # Re: Hurd bientot au niveau de l'Everest !!!

        Posté par  . Évalué à 1.

        Je croyais pourtant que c'etait RMS lui-meme qui insistait pour qu'on ne dise pas Linux mais GNU/Linux. Me trompe-je ?
        • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

          Non, pas du tout. (Mais moi non plus :-P)

          Quand je dis Linux, je pense "Noyau Linux". C'est un composant ajouté qui permet de faire tourner un système basé sur GNU, auquel on substitue Hurd par Linux. On obtient ainsi un système qui est /prèsque/ GNU, à savoir GNU/Linux.

          Donc, GNU/Linux, c'est prèsque GNU.
          Linux tout court n'a rien à voir avec GNU.

          Bon, enfin, je suis pas extrêmiste non plus, je fais souvent l'abus de langage Linux = GNU/Linux, mais pour être précis, c'est différent.

          Par exemple, quand on dit "Sous Linux, ls toto -l est accepté alors que ce n'est pas le cas sous Solaris" ou "Le make de Linux gère plus de chose que le make POSIX", c'est en fait de GNU qu'on parle.
          • [^] # Re: Hurd bientot au niveau de l'Everest !!!

            Posté par  . Évalué à 1.

            Salut

            > Par exemple, quand on dit "Sous Linux, ls toto -l est accepté alors que
            > ce n'est pas le cas sous Solaris" ou "Le make de Linux gère plus de
            > chose que le make POSIX", c'est en fait de GNU qu'on parle.

            Pourtant ce sont deux outils GNU. Autant je trouve que Linux est un nom plus juste que GNU/Linux pour désigner le système d'exploitation basé sur le noyau Linux, autant je pense qu'il faut rendre à César ce qui est à César (enfin, à RMS... ;-)

            @+
            • [^] # Re: Hurd bientot au niveau de l'Everest !!!

              Posté par  . Évalué à 5.

              Pourtant ce sont deux outils GNU. Autant je trouve que Linux est un nom plus juste que GNU/Linux pour désigner le système d'exploitation basé sur le noyau Linux, autant je pense qu'il faut rendre à César ce qui est à César (enfin, à RMS... ;-)

              Note qui'il y'a une contradiction évidente dans ta phrase : tout d'abord, tu admets l'unicité d'un système d'exploitation utilisant Linux : or, peut-on réellement et sérieusement dire qu'un système utilsant Linux, busybox, une libc minimalle (diet-libc, ou une des autres), est le même qu'un système utilisant Linux, les outils GNU, la GNU C Library, etc. ? Le problème ici, c'est que l'on admet que le système le plus courant est le seul : c'est bien évidemment faux. Bien que Linux ne soit pas le plus adaptable des noyaux, il existe des systèmes utilisant Linux dans l'embarqué, et ces systèmes n'ont décidément *rien* à voir avec le tien - celui que j'appelle GNU/Linux. Tu serais mis devant, tu ne verrais pas la ressemblance ..

              Le problème que soulève cette non-unicité des systèmes d'exploitations utilisant Linux est celui classique du nommage : il faut trouver un compromis entre une appellation suffisamment large pour accepter toute la variété des systèmes qu'on rapprocherait naturellement comme étant « les mêmes » (on dira, la variabilité intra-classe), et suffisamment spécifique pour permette de différencier deux systèmes précisément, si l'expérience de notre jugement nous dirait qu'ils sont des systèmes différents - et deux systèmes utilisant Linux peuvent l'être (séparabilité des classes, donc.). Linux ne permet pas une séparabilité des classes.

              GNU/KDE/Gnome/Samba/Apache/Linux et autres aberrations maintes fois proposées - encore récemment par Tim O'Reilly - par des gens n'ayant pas compris les vrais raisons de la critique de Linux comme nom du système dans son ensemble - ne permettent *absolument* pas d'avoir une variabilité intra-classe suffisante : elle permet en revanche d'avoir un compromis suffisamment précis pour désigner sa propre installation du système d'exploitation, et encore. Et comme je le disais dans une news précédente[0], je préférerais alors utiliser "Ma Debian GNU/Linux", qui me semble là, tout à fait correct.

              [0]: http://linuxfr.org/comments/118290.html(...)
              • [^] # Re: Hurd bientot au niveau de l'Everest !!!

                Posté par  . Évalué à 1.

                Salut

                > or, peut-on réellement et sérieusement dire qu'un système utilsant
                > Linux, busybox, une libc minimalle (diet-libc, ou une des autres), est le
                > même qu'un système utilisant Linux, les outils GNU, la GNU C Library,
                > etc. ?
                > [...]
                > il existe des systèmes utilisant Linux dans l'embarqué, et ces systèmes
                > n'ont décidément *rien* à voir avec le tien - celui que j'appelle
                > GNU/Linux. Tu serais mis devant, tu ne verrais pas la ressemblance ..

                Le fait que l'on puisse faire tout ce que l'on veut avec du Logiciel Libre, dans la limite de ses capacités bien sur, n'est pas nouveau.

                Cela ne m'empeche pas de considérer que le système d'exploitation historique qui s'est concu autour du noyau Linux a pour nom le plus évident Linux, et pas GNU/Linux.

                Après, RMS et ses partisans peuvent donner tout un tas d'arguments, mais je me poserais toujours la question : et pourquoi pas BSD ? et pourquoi pas tous les autres logiciels libres ? Au final, et pourquoi pas "Logiciels Libres & Co / Linux" ?

                @+
                • [^] # Re: Hurd bientot au niveau de l'Everest !!!

                  Posté par  . Évalué à 3.

                  Le fait que l'on puisse faire tout ce que l'on veut avec du Logiciel Libre, dans la limite de ses capacités bien sur, n'est pas nouveau.

                  Ça n'était point mon propos. Mon propos était de dire : il faut trouver un terme qui identifie un système bien particulier, qui est le tien, qui est le mien, mais qui n'a que très très peu à voir avec d'autres systèmes exploitant Linux. Linux n'est pas satisfaisant, pour deux raisons principales :

                  • La première, c'est l'ambiguïté que celà crée. Je ne pense pas qu'il soit bon, dans le cas de nommage d'un logiciel, de quelque chose de concret, d'employer un terme pour quelque chose et quelque chose d'autre - c'est peut être une pensée orientée par les maths, ou par ma vigoureuse opposition à la surcharge ;-) Dans tous les cas, je trouve ça assez mauvais, parce que je peux critiquer Linux, mes critiques ne s'appliqueront pas à l'ensemble que j'appelle GNU/Linux.

                  • Même si l'on admettait que l'on peut appeler le tout par la partie (oui, référence évidente), ce que je trouve tout à fait inadmissible dans le cas présent, le nom « Linux » désignerait « l'ensemble des systèmes utilisant Linux. » ; même dans cette hypothèse, le terme ne serait pas assez spécifique pour désigner un système, mais un ensemble de systèmes. Et pour le coup, appeler un ensemble par un de ses éléments me paraît encore plus injustifiable - et menant à la confusion.


                  Cela ne m'empeche pas de considérer que le système d'exploitation historique qui s'est concu autour du noyau Linux a pour nom le plus évident Linux, et pas GNU/Linux.

                  Mais, d'où vient l'évidence ? L'évidence est plutôt dans ta façon de faire que dans une réalité objective. Pour autant que je m'efforce d'observer une réalité objective, je vois une réalité historique qui est: "GNU a développé un certain nombres d'outils formant la base d'un système d'exploitation. Linus a, bien plus tard, développé un noyau, Linux, sur lequel ces outils furent portés. Le nom le plus logique serait une fusion des deux : LiGNUx ? Pas façile à dire. GNU/Linux? Bien, ça me paraît correct."


                  Après, RMS et ses partisans

                  Ah, je suis un partisan de RMS ? :-) Intéressant :-) Je peux partager un certain nombre d'opinions avec RMS, on peut avoir des vues convergentes sur un nombre important de sujet, je peux avoir un respect pour lui en tant qu'homme comme en tant que chercheur (hé, le dependency-directed backtrack, quand même), mais je ne me considère pas comme un partisan de RMS - je ne suis partisan de personne. Attention aux termes, dans une discussion sur des termes :-)

                  .. peuvent donner tout un tas d'arguments, mais je me poserais toujours la question : et pourquoi pas BSD ? et pourquoi pas tous les autres logiciels libres ? Au final, et pourquoi pas "Logiciels Libres & Co / Linux" ?

                  Sincèrement, je me demande parfois si en fait, la majorité des gens n'ont pas des réponses préparées dans leur tête qu'ils vont donner même si elles n'ont aucun sens vu les éléments donnés dans le message auxquels ils répondent. C'est assez impressionnant. D'aucuns attribueront ça à la lecture globale, lecture absolument inappropriée au débat, et pourtant habituelle, encore plus sur le Web. Dans tous les cas, la réponse à ta question est plus haut. Et dans le mail que je citais. Question de déterminant : ça, c'est la partie que je développais dans le mail cité. Question ensuite de spécificité : "GNU/Linux" est assez large et pourtant assez spécifique pour regrouper tout ce qu'une personne de bonne foi, et avec des connaissances correctes, regrouperait dans la même "classe" naturellement, mais pas plus. "Logiciels Libres & Co / Linux" signfierait : "tout système dont Linux constitue la base et qui utilise des logiciels libres & co" ; comme plus haut, trop générique. BSD/GNU/XFree86/Samba/Quesaisje/Linux, lui, serait trop spécifiquer pour désigner un système, mais plus une catégorie d'installations, un ensemble d'installations (voir la différence système/installation dans le premier mail).

                  Oh, au fait, l'URL donnée quand on clique sur ton nom ne marche pas : tu as dû oublier de marquer le 'http://'(...) ou quelque chose du genre, et les templates de LinuxFR ne doivent pas savoir gérer ça.
                  • [^] # Re: Hurd bientot au niveau de l'Everest !!!

                    Posté par  . Évalué à 1.

                    Le nom le plus logique serait une fusion des deux : LiGNUx ? Pas façile à dire. GNU/Linux? Bien, ça me paraît correct." Personnellement, j'utilise le terme gnunux qui est sympathique et se prononce assez facilement :)
                    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

                      Posté par  . Évalué à 1.

                      Personnellement, j'utilise le terme gnunux qui est sympathique et se prononce assez facilement :) Plutôt sympathique. À la manière d'Opalpag, quoi :-) Pour la petite histoire, LiGNUx avait été effectivement proposé, par RMS. Il avait l'avantage d'être marrant, et de conserver les noms entiers des deux forces en présence ; bon, pour des raisons évidentes (et pour des raisons plus mauvaises, que je dénonçais plus haut), les développeurs de Linux n'étaient pas très chauds :-) Enfin, dans tous les cas, je maintiens que GNU/Linux est un terme acceptable, Linux ne l'est pas. Ensuite, d'autres termes peuvent exister, je n'ai aucun moyen de prouver l'unicité, ni même que GNU/Linux soit le meilleur terme, d'un point de vue esthétique, prononçabilité, etc. etc. ; j'avoue que Gnunux est plutôt sympa, doit y'avoir des variations pas mal :-) Opalpag semble correct puisqu'il fait référence à un terme correct, GNU/Linux. Maintenant, va falloir un comité de standardisation et de vocabulaire du LL ;-)
            • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

              > Pourtant ce sont deux outils GNU.

              Euh, c'est bien ce que je dis, non ?

              Bon, je la refais :

              La phrase "Sous Linux, ls toto -l est accepté alors que ce n'est pas le cas sous Solaris" est un abus de language, car ls n'a rien à voir avec Linux. Par contre, la version "Sous GNU, ..." ou "Sous GNU/Linux, ...", elles, sont correctes, car dans ce cas, "ls" fait effectivement partie de "GNU". Donc, le mot "Linux" était utilisé dans cette phrase pour désigner "GNU".

              Maintenant, encore une fois, c'est un abus de langage que je fais moi-même très souvent, je ne vais pas faire la guerre à tous ceux qui le font ...

              Mon message était une réponse à quelqu'un qui disait "De toutes façons, GNU/Linux, c'est GNU". Là, c'est un peu plus qu'un abus de language ...
              • [^] # Re: Hurd bientot au niveau de l'Everest !!!

                Posté par  . Évalué à -2.

                Pardon, mais je ne pretends pas que GNU=Linux, je ne m'y connais pas suffisamment. Seulement, le fait de dire que les gens de GNU n'aiment pas qu'on les associe a Linux alors que RMS insiste pour que justement, on les associe, me semblait contradictoire. Pour apporter ma pierre au debat sterile d'aujourd'hui, je dirai que je prefere Linux sans le terme GNU. C'est vraiment mesquin de vouloir a tout prix mettre son nom partout, surtout quand on se veut un philanthrope comme RMS.
            • [^] # Re: Hurd bientot au niveau de l'Everest !!!

              Posté par  . Évalué à 5.

              > Autant je trouve que Linux est un nom plus juste que GNU/Linux pour désigner le système d'exploitation basé sur le noyau Linux, autant je pense qu'il faut rendre à César ce qui est à César (enfin, à RMS... ;-)

              Je préfère GNU/Linux à Linux. S'il y a GNU/*BSD, GNU/Hurd, GNU/Linux, il y a une certaine unité. Le problème est dans une distribe GNU/Linux, et n'y a pas que GNU et Linux. Il y a aussi, Apache, MySQL, Xfree86, postgreSQL etc...
              • [^] # Re: Hurd bientot au niveau de l'Everest !!!

                Posté par  . Évalué à 2.

                La différence, c'est que pour compiler et utiliser Apache (version 2), MySQL, XFree86 (c'est encore un peu différent), PostgreSQL, etc. tu utilises GNU Autoconf, GNU Automake, GNU Make, et la GNU Libc. Tu peux toujours utiliser une autre libc, un autre make, un autre automake, un autre autoconf, mais l'écrasante majorité des distribs communément appelées Linux utilisent les versions GNU de ces logiciels.
                Sans compter les paquets coreutils, fileutils, sans lesquels ta distrib n'est rien.

                Bref, tu peux utiliser ton système sans Apache, sans MySQL (d'ailleurs je te le conseille ;), sans XFree86 (je conçois que ça peut être assez chiant), sans PostgreSQL. Peux-tu l'utiliser sans coreutils, fileutils, une libc (généralement la glibc), ou même gcc (GNU C Compiler) ?

                Ce que je m'efforce de dire, c'est que le système a bien plus de raison de s'appeler GNU/Linux que GNU/Apache/MySQL/XFree86/Linux. Ensuite, je parle couramment de Linux, tout en ayant à l'esprit que sans GNU, on est foutus ! D'ailleurs, si on enlève GNU, j'enlève Linux, et je ne parle plus que de Debian :-p
                • [^] # Re: Hurd bientot au niveau de l'Everest !!!

                  Posté par  . Évalué à 6.

                  C'est de moins en moins le cas, mais il y a beaucoup de projet qui ce compile sans les outils gnu sur les unix commerciaux. Et même des outils Gnu (make, find, gawk, bison, etc... ya aussi des raisons évidentes de bootstrap, sinon tu ne peux pas installer les outils GNU sur un système Unix).

                  Sinon je suis d'accord pour dire qu'un distribe est basée sur GNU/Linux. Mais la distribe complète, n'est pas GNU/Linux. D'où le GNU/PostgreSQL/.../Linux. Mais ne chipotons pas.

                  > tout en ayant à l'esprit que sans GNU, on est foutus !

                  Pareil.
                  Et Linux serait arrivé beaucoup, beaucoup plus tard sans les outils GNU qui ont été développés sur les unix commerciaux bien avant le début du développement de Linux.
  • # En fait, ça fait quoi hurd ?

    Posté par  (site web personnel, Mastodon) . Évalué à 9.

    En théorie, je sais plus ou moins ce que sont Hurd, Mach et les micro-noyaux. Bon, mais si j'installe debian/hurd, je verrais quoi comme différence par rapport à ma debian/linux ? (maintenant et théoriquement quand Hurd sera opérationnel)

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: En fait, ça fait quoi hurd ?

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

      Euh, tu verras un gnou a la place d'un manchot au démarage? ;) Je ne m'y connais pas trop mais ce qui a l'air cool c'est les serveurs : tu peux lancer des serveurs pour vraiment tout. Exemple : tu peux lancer un serveur qui se connecte a un serveur ftp et qui te l e montera comme un système de fichier local, donc tu y accèdes de manière toute bête. Bon, c'est qu'un example, d'ailleurs je crois que tu peux aussi le faire avec Linux, mais il y a plein d'autres utilisations possibles.
    • [^] # Re: En fait, ça fait quoi hurd ?

      Posté par  . Évalué à 10.

      Tout le système des translateurs; vois : http://hurdfr.org/index.php?page=pages/doc/strategie&sid= Tout un tas de fonctionnalités sortent du noyau, et deviennent donc accessible à qui a le droit de les utiliser; plus besoin d'être root pour tout faire (monter une partition, configurer une pile réseau, ...). Au niveau de l'utilisation, tu as effectivement ftpfs qui permet de monter automatiquement un site ftp sir ton système de fichiers, et d'y exécuter les commandes classiques : $ settrans -a ftp /hurd/ftpfs ftp://ftp.gnu.org/ / $ cp /ftp/iso/hurd-K2/hurd-K2-CD1.iso . $ Et voila, tu as téléchargé le CD 1 !!!!
      • [^] # Re: En fait, ça fait quoi hurd ?

        Posté par  . Évalué à 2.

        d'après ce que j'ai cru comprendre dans un truque que j'ai lu je sais plus ou su rleur site, tu peut aussi monter le translator dans un répertoire et faire un truque du style : $ cp /ftp/ftp.gnu.org/iso/hurd-K2/hurd-K2-CD1.iso. et quand tu fera un ls , ftp.gnu.org apparaîtra dans /ftp/, ils apparaissent dès la première utilisation. le principe et génial, tu poura faire un translator nfs et smb, et après, plus besoin de navigateur de fichier sépcial pour accèder aux partage de fichiers sans devoir le monter dans un répertoir. je suis en train de télécharger l'image et je suis impatient de l'essayer (j'avais déjà essaye une version d'il y'a longtemps mais j'ai jamais réussi à booter dessus)
      • [^] # Re: En fait, ça fait quoi hurd ?

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

        je tiens juste à dire que ca peut se faire sous linux aussi via lufs.

        (et là je ne parle meme pas de l'exemple enthousiasmant qu'un wget remplacerait avec plus de simplicité)
        • [^] # Re: En fait, ça fait quoi hurd ?

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

          et lufs il il marche comment? sans a aucun moment les droits root ni aucun module dans le noyau?
          • [^] # Re: En fait, ça fait quoi hurd ?

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

            sisi, mais .... tu as souvent besoin d'utiliser une telle fonctionnalité sur une machine que tu ne controle pas directement ou indirectement ?

            Les cas où les utilisateurs ne controlent pas leur machine sont de plus en plus rare. Je ne dis pas que GNU n'a aucun intéret, mais la transparence type ftp est déjà un gadget plus qu'autre chose pour beaucoup de monde, si en plus on restreint ce nombre à ceux qui ne sont pas root et ne peuvent faire installer le module en question ... on arrive à vraiment plus grand monde.

            Autant je suis interressé en tant qu'utilisateur par la flexibilité qu'entraine gnu, autant pour ce qui est du coté fs via ftp/ssh/smb, les outils existant sont assez souvent correctement utilisable, et quand ca n'est pas le cas un module type lufs et dans la plupart des cas envisageable.
            Enfin ca ne reste que mon avis
            • [^] # Re: En fait, ça fait quoi hurd ?

              Posté par  . Évalué à 3.

              Je ne pense pas que le problème soit d'avoir les droits root au départ. Le problème, c'est d'éviter qu'un bug dans lufs permette à quiconque d'obtenir les droits root. Si aucune partie du logiciel ne tourne avec les droits root et dans le noyau, les implications sur la sécurité sont, encore une fois, très réduites par rapport à un module noyau.
              Il suffit de voir qu'un des moyens les plus sophistiqués pour un attaquant de masquer sa prise de possession sur une machine Linux est d'installer un module noyau pour modifier le comportement de certains exécutables.
    • [^] # Re: En fait, ça fait quoi hurd ?

      Posté par  . Évalué à 5.

      Je l'avais essayé il y a quelque temps déjà, et ce qui m'avait beaucoup plus, c'est le concept de "traducteur" (http://www.hurdfr.org/index.php?page=pages/doc/traducteur&sid=) En gros, tu as un entrepot, un endroit ou tu souhaites mettre tes données à disposition, et entre les deux tu mets le fameux traducteur. Exemple: un site ftp, un point de montage, et le traducteur te fera voir le site ftp comme faisant partie de ton arborescence Autre exemple: les images iso. Contrairement à Linux, pas de montage loopback, tu utilise le traducteur iso9660, le même qui te permet de monter ton cdrom. Tu retrouve ce concept de traducteur vraiment partout, meme pour la souris sous X si je me souviens bien. En tout cas, le Hurd mérite tout sauf le dédain
    • [^] # Re: En fait, ça fait quoi hurd ?

      Posté par  . Évalué à 10.

      À mon avis, la plus grande avancée du Hurd en terme de design c'est sa souplesse: le code dans le noyau est très très difficile à débugguer, une erreur et c'est le crash fatal. Certes, certains projets tels kksymoops et User Mode Linux (qui permet de lancer un Linux sur un autre) peuvent faciliter la découverte des bugs et leur résolution. Mais il est bien plus simple et propre de ne laisser que le strict minimum dans le noyau. Comme chacun sait, un logiciel compliqué a statistiquement bien plus de bugs qu'un logiciel simple, à compétence de programmeurs égale. Un micro-noyau présente donc une sécurité et une fiabilité théorique bien supérieure à un noyau monolithique style Linux ou *BSD. Ensuite, si tu codes les serveurs (un serveur est une partie de code tournant en espace utilisateur et remplissant les fonctions habituellement contenues dans le noyau monolithique) comme un goret, les trous de sécurité seront légion. En résumé, le Hurd (comme tout micro-noyau) permet en théorie (et à terme) d'accroitre la fiabilité et la sécurité d'un système. J'ai bien dit en théorie... Niveau performances, étant donné qu'il faut plus de changements de contexte (passage espace noyau <-> espace utilisateur), il peut paraître logique qu'un micro-noyau soit plus lent. Néanmoins, certaines études tendent à montrer qu'il est possible de limiter ces pertes au strict minimum, grâce aux communications inter-processus rapides (fast IPC), cf le projet L4 http://os.inf.tu-dresden.de/L4/ Donc, concept intéressant, développement constant, le tout est encore un peu jeune, mais c'est typiquement le moment de tester et d'aider. Pour les vieux, rappelez-vous Linux il y a 8 ou 10 ans...
      • [^] # Re: En fait, ça fait quoi hurd ?

        Posté par  . Évalué à 7.

        Un autre avantage de l'espace utilisateur est que l'on peut linker les translateurs à des librairies, donc lpus besion de constamment réinventer la roue...
        • [^] # Re: En fait, ça fait quoi hurd ?

          Posté par  . Évalué à 2.

          Depuis quelque temps déjà, il existe une partie "Library routines" qui contient une libraire de CRC dans mon "make menuconfig" favori. La différence n'est-elle que dans le fait que les libraires doivent être chargées dans l'espace d'adressage du noyau (et donc bouffer de la place sans pouvoir être swappées si j'ai bien compris), ou y'a-t-il un truc plus subtil ?
          • [^] # Re: En fait, ça fait quoi hurd ?

            Posté par  . Évalué à 10.

            C'est que, dans ce cas, le code sous GNU s'exécute de manière non privilégiée (ie: pas dans le noyau) ce qui limite la casse en cas de bug (c)(tm) et permet un développement/debuggage plus facile. Mais prenons le cas de mboxfs, un translateur qui permet de transformer le contenu d'un fichier contenant des mails en système de fichiers navigable. Pour cela, une partie du code de Mutt a été repris. Or mettre ca dans le noyau, ce serait plutot crado. Avec GNU, pas de souci. Et puis un translateur, ca peut être bien plus qu'une fonctionnalité noyau : lprtrans (translateur qui permettrait de recueillir les fichiers à imprimer, et de les formatter et les envoyer tout tranquillement à la bonne imprimante, faire $ cp toto.ps /imprimantes/celle-au-fond-du-couloir-a-gauche est moins pénible que le lpr -Pbj12c3-15Ncouleur toto.ps habituel... et pas seulement pour des histoires de complétion ;)
    • [^] # Re: En fait, ça fait quoi hurd ?

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

      J ai vaguement installe un GNU/Hurd, et disons que : - t a un system qui crashe tu tu appui sur le clavire pendant le boot - tu peut mounter des serveurs FTP - tu a une ligne de commande meme sans te loguer - le pakage screen deviens superflus, vu que par default, toutes les cessions sont des cessions virtuelles ... - il parait que si tu connais les points faibles ( comme le clavier au boot ... ), et que tu te debrouille pour passer outre, le system est assez stable evidment, le jour ou ils auront code sftp-fs, la vous pourrez oublier le NFS, le ftpfs et autres FS reseaux ... bref du roxage en vue ... d autres choses pour l avenire : la possibilite en tant que developeur de driver de developper un driver sur un peripherique instable, de sorte que si le driver vautre, ou si le peripherique crash, tout le system ne s affole pas ( cf les monolytiques ... j ai deja vu tout un serveur planter sous linux, juste parceque on avait fait un modprobe UHCI, et que le chip USB de la carte mere plnatait toutes les 12h => rebooter toutes les 12h si on a vraiment besoin du dit peripherique sur la dite machine, alors qu un Hurd se contenterai de re-initialiser le peripherique mort, et relancer le driver qui va bien ... sans rebooter ) ( c est aussi aplicable aux cartes graphiques, si un jour Nvidia donnais des pilotes meme au format binaire de leur CV ... donc tres interessant ... idem pour ma salete de bt848, idem pour ... je liste pas tout ) bref .... on nous promet un avenire en rose :=) Pourvu qu ils tiennent leur promesses ...
      • [^] # Re: En fait, ça fait quoi hurd ?

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

        tu penses vraiment qu'un sftpfs suffirait a remplacer NFS & Cie? Il me semble quand même que sftp n'est pas très adapté à ce genre de tâche, mais je me plante peut etre... De plus il a déjà été écris par quelqu'un il y a déjà un petit moment, faudrait fouiller dans la ml bug-hurd.
      • [^] # Re: En fait, ça fait quoi hurd ?

        Posté par  . Évalué à 10.

        - t a un system qui crashe tu tu appui sur le clavire pendant le boot

        C'est GNU Mach, pas sur toutes les machines, et on s'en fout un peu non ?

        - tu a une ligne de commande meme sans te loguer

        Précisons bien qu'il s'agit d'un shell "noauth", qui n'a donc aucun privilège particulier; et qu'il nécessite de plus un accès physique à la machine (ce n'est pas comme si tout le monde pouvait accéder à du noauth à distance), donc on ne peut pas considérer qu'il s'agisse d'un pb de sécu.

        - le pakage screen deviens superflus

        Pas vraiment... mais presque ;)
        Attention, la console de Marcus (celle qui supporte tout ça) n'est pas activée par défaut, et, AFAIK, pose des conflits avec X (plus exactement, le driver pckbd de la console et X se battent pour le contrôle du cla, avec des effets... intéressants), mais cela va être réglé.

        le jour ou ils auront code sftp-fs

        Lis les MLs, ça a été fait :) Mais je ne l'ai pas testé.

        donnais des pilotes meme au format binaire de leur CV

        Hum, ça me dérange bcp que l'on vente les avantages de GNU pour... l'utilisation de logiciel non-libre ! La force de GNU, et donc du Hurd, c'est d'abord la Liberte !

        Pourvu qu ils tiennent leur promesses ...

        On ne fait aucune promesse, et c'est à vous tous de contribuer si vous souhaitez que GNU devienne ce qu'il pourrait être.
  • # Re: Hurd bientot au niveau de l'Everest !!!

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

    Au fait, est ce que quelqu'un sait s'il y a toujours la limite de 2go pour les partitions?
  • # Re: Hurd bientot au niveau de l'Everest !!!

    Posté par  . Évalué à 2.

    pris d'un doute je suis aller vérifier sur ftp.fr.debian.org en effet les paquets hurd font officiellement partie de debian sid/unstable ! voici un exemple pour 3dchess (qui est un programme X): http://ftp.fr.debian.org/debian/pool/main/3/3dchess/
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

      Posté par  . Évalué à 1.

      Ces images ne sont que des snapshots, il n'a jamais été dit que le GNU était en version stable...
      • [^] # Re: Hurd bientot au niveau de l'Everest !!!

        Posté par  . Évalué à 2.

        il n'a jamais été dit que le GNU était en version stable... en effet j'ai bien précisé sid/unstable, ce qui dans la nomenclature Debian est mieux que "experiemental", mais moins bien que testing et stable
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

      Posté par  . Évalué à 5.

      a noter que HURD est au meme niveau que les architectures materielles linux dans la nomenclature debian: 3d-chess_alpha.deb 3d-chess_arm.deb 3d-chess_i386.deb (sous entendu linux hein) et 3d-chess_hurd-i386.deb il faudra donc tout renommer en 3d-chess_linux-alpha.deb 3d-chess_linux-arm.deb 3d-chess_linux-i386.deb avant que GNU/RMS ne pete un cable !!!!
      • [^] # Re: Hurd bientot au niveau de l'Everest !!!

        Posté par  . Évalué à 8.

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

    Posté par  . Évalué à 10.

    Petite correction de français, car la faute est répandue : on dit "occasion" et non "opportunité", ce dernier étant une mauvaise traduction de l'anglais "opportunity" (mode lancée par les marketeux et les DRH), dont la traduction exacte est "occasion favorable". On ne peut pas dire "une opportunité" et encore moins "des opportunités", car le mot s'emploie comme le mot "pertinence". On parle de l'opportunité d'une décision ou d'un acte, c'est à dire du caractère opportun (approprié) de la décision ou de l'acte. Vous êtes encouragés à remplacer l'usage anglicisant de "opportunité" par "occasion", "possibilité", voire "perspective" dans certains cas.
    • [^] # Re: une formidable <b><span style=</b>

      Posté par  . Évalué à 2.

      On peut faire tourner des services sur gnu/hurd en tant que serveur ? apache ? ftp ?etc.. si oui je teste ce week end ;p
      • [^] # Re: une formidable <b><span style=</b>

        Posté par  . Évalué à 0.

        oui Bon test... :)
      • [^] # Re: une formidable <b>span style</b>

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

        J ai entendu parler d un serveur web en production ... il avait a l epoque des petits soucis avec la carte reseau ( pilote instable ) : le service etait en moyenne redemarre une fois par jour, mais les visiteurs ne s en apercevait pas ( le redemarage des modules necessaires etait si rapide que les routeurs prenaient ca pour un PL, donc re-envoie du paket reseau ... soit un lag total de environ une seconde par jour ... ) ... rien d alarmant ... Au bout d un mois le test a ete considere comme concluant ... mais par securite, ils ont remis le site web sur un serveur plus "sure" ...
    • [^] # Re: une formidable <b><span style=</b>

      Posté par  . Évalué à 10.

      Je saisis l'opportunité de t'apprendre que "marketeux" n'existe pas non-plus en Français...
    • [^] # Et pourquoi pas ?

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

      Je ne suis pas d'accord. Certes, le mot n'existe pas en français, mais pourquoi tant de gens tiennent tant à ce que le français reste une langue figée ? Dans les cas où un mot n'existe pas en français pour désigner un concept, en général nos chers académiciens préfèrent créer un mot à partir de la sonorité anglaise, ce qui donne un résultat ridicule (ex : mél, fioul...). Pourquoi ne pas importer le mot étranger, tout simplement ? C'est ce que les anglo-saxons font (cul-de-sac, rendez-vous...), et les allemands aussi (tous les verbes en -ieren), et pour les autres langues je connais pas. Pourquoi ne ferait-on pas de même chez nous , surtout à l'heure de l'Europe ? C'est vrai dans le cas d' "opportunité", un mot existe déjà en français. Mais finalement, ça ne ferait qu'ajouter à la richesse de notre langue, et ce n'est pas un mal. Si assez de gens l'uilisent pour que tout le monde comprenne, pourquoi ne pas laisser la liberté d'utiliser les deux ? Voilà, quelques reflexions sur un sujet qui revient souvent... Gauret P.S. : ca n'a rien à voir, mais en faisant répondre à ce post, le titre par défaut déconne complètement (il finit par un span=), et la moitié de la page de visualisation se retrouve en gras
      • [^] # Re: Et pourquoi pas ?

        Posté par  . Évalué à -1.

        dans les cas où un mot n'existe pas en français pour désigner un concept, en général nos chers académiciens préfèrent créer un mot à partir de la sonorité anglaise, ce qui donne un résultat ridicule (ex : mél, fioul...).

        Rappelons encore une fois que "mél" est une abréviation comme "tel" et non un substantif. Ca n'est pas fait pour être écrit dans une phrase.

        Pourquoi ne pas importer le mot étranger, tout simplement ?

        Tu ne sembles pas réaliser que d'une part le mot anglais "opportunity" vient du français (d'une racine latine plus probablement), et que son sens a dérivé. C'est ce qu'on appelle un faux-ami, comme "money" # "monnaie", "journey" # "journée", etc... D'autre part sa traduction exacte est "occasion" (cf un dico). Il est même précisé dans des dicos français récents (quelques années) pour la définition de "opportunité" : "2) usage critiqué : occasion favorable"

        Mais finalement, ça ne ferait qu'ajouter à la richesse de notre langue, et ce n'est pas un mal.

        Mais pas du tout, nous avons tous les mots qu'il nous faut en français, c'est juste qu'on ne doit pas dire "une opportunité" c'est tout. Par exemple, on a toujours dit "une occasion de but", et bien l'autre jour un gugusse a cru parler un français plus soutenu (j'imagine) en disant "une opportunité de but". Franchement je ne vois pas où la langue y gagne.
        • [^] # Re: Et pourquoi pas ?

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

          > Franchement je ne vois pas où la langue y gagne.

          La meme chose que ce qu'a toujours gagner une langue vivante à évoluer.
          Toute la langue telle que nous la connaissons vient de plusieures langues différentes, de nombreux mots ont une origine grecs ou latine, d'autres anglo saxone ou italienne. Il n'y a rien de mal, au contraire, je pense que personne ne souhaite parler comme il y a trois siècles.

          Visiblement c'est la mode de chercher à "fixer" la langue et essayer de dire "c'est comme ca qu'il faut dire" ou "ca n'existe pas". Dans un cadre général c'est bien à petite dose, histoire qu'on ai une langue homogène. Mais si opportunité n'existait pas personnellement je considère que désormais il existe (c'est à dire que tout le monde comprendra le terme si je l'utilise).

          Le français est une langue riche justement parce qu'elle a su évoluer et échanger avec ses voisins. N'en faites pas une langue morte.


          > > Pourquoi ne pas importer le mot étranger, tout simplement ?
          > Tu ne sembles pas réaliser que d'une part le mot anglais "opportunity" vient du
          > français

          Ou et ? l'échange à double sens est interdit ?

          > et que son sens a dérivé

          Ou évolué, comme presque tous les mots de la langue française si on les compare à une période de 50 ans (rien qu'au niveau des connotations ca se voit très vite entre deux générations successives).
          C'est mal ?


          --
          -1 car rien à faire ici, ha ben non, pas de -1 présent
  • # Re: Hurd bientot au niveau de l'Everest !!!

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

    Microsoft à fait le choix du micro-noyau depuis Windows NT, mais ils mettent quand même pas mal de chose dans le kernel principalement pour des raisons de performance. Coté libre on a Linux pour le monolithique à fond (simplicité, performances) et Hurd pour le micro-noyau jusqu'au bout des ongles (souplesse, sécurité si j'ai bien compris). L'approche moitié-moitié est-elle vraiment moins bonne ? (interêt des deux mondes, mais inconvénient des deux mondes) Les BSD c'est monolithique ?
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

      Posté par  . Évalué à 3.

      Les *BSD, c'est monolithique. L'approche moitié-moitié est une approche plutôt batarde à mon avis: c'est faire du micro-noyau "pour le style" et bourrer le micro-noyau de choses qui devraient être en dehors... bref, je trouve cette approche pas géniale.
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

      La belle structure théorique et annoncée vers 1994 des micro-noyaux de NT avec sa couche HAL (Hardware Abstractrion Layer) s'est effondrée depuis longtemps. Sinon, NT serait toujours présent sur toutes les architectures. Linux est présent sur toutes les architectures matérielles, espérons que HURD le devienne aussi car en principe, il n'y a pas d'impossibilité.
      • [^] # Re: Hurd bientot au niveau de l'Everest !!!

        Posté par  . Évalué à 2.

        La belle structure théorique et annoncée vers 1994 des micro-noyaux de NT avec sa couche HAL (Hardware Abstractrion Layer) s'est effondrée depuis longtemps. Sinon, NT serait toujours présent sur toutes les architectures. NT a disparu des autres archis pour des raisons de marche, pas des raisons techniques. Les marches MIPS et PPC etaient si insignifiants qu'ils ne valaient pas les efforts en packaging/support/dev... , meme chose pour Alpha un peu plus tard.
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

      Posté par  . Évalué à 8.

      va faire un petit tour sur http://reactos.com/rosdocs/tutorials/bk02pt02ch07.html pour avoir un avis assez répandu sur ce qu'est vraiment l'architecture noyau de NT. Although Microsoft claims that the architecture is a modified micro-kernel (combining aspects of both micro-kernels and layered operating systems), at ReactOS we have a different definition of the architecture. The NT, and therefore ReactOS architecture, is modular and layered. The small traces of microkernel architecture are not enough for it to be described as a modified micro-kernel. Dire que Windows NT est architecturé autour d'un micro-noyau n'a en réalité pas beaucoup de sens. Il faut aussi remarquer MS ne communique plus du tout sur cet aspect technique. Les seuls documents officiels sont datés de la version NT 3.51. J'ai le Stalling 4ième édition au boulot et je crois qu'il mentionne le coté micro-noyau d'après les information de Microsoft. Ce grand homme semble ne pas beaucoup donner de crédit à cette affirmation sur les dernières incarnations des OS de MS. Il semble par contre apprécier le méchanisme de communication en "couches". (inutile de dire qu'il ne semble pas être un grand fan de l'architecture de Linux :) ) Encore une info, des personnalités disponibles par dessus le noyau de NT, seul Win32 a migré dans sa totalité dans le noyau. Les autres personnalités (dont la couche POSIX) sont restées dans le user-land. Probablement histoire qu'elles se prennent 2 aller-retour userland/kernel en passant par une API d'échange lente. Comme ça MS est sûr que les autres personnalités soient bien plus lentes que la personnalité Win32.
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

      Posté par  . Évalué à 7.

      juste une tout petite precision concernant the HURD et la notion de micro-noyau. Hurd tourne sur MACH qui est officiellement un micro-noyau. Mais MACH n'est pas non plus un micro-noyau jusqu'au bout des ongles : les performances de MACH etant au depart tellement catastrophique, certaines parties ont ete reintegrees au kernel (exemple : scheduler, drivers, etc...).

      The Hurd sera effectivement micro-noyau jusqu'au bout des ongles lorsqu'il tournera sur L4 (pas demain la veille), qui lui est un veritable micro-noyau n'imposant aucune politique que ce soit en matiere de scheduling, de gestion de la memoire (pager), ou quoi que ce soit : le L4 est tout specialement concu pour utiliser l'architecture autour de serveurs qui permettent de choisir la politque voulue.

      Je ne sais pas si j'ai ete tres clair, mais c'etait mes 2 sous !
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

      Posté par  . Évalué à 6.

      L'approche moitié-moitié est-elle vraiment moins bonne ?

      Oui, cf "µ-kernels can and must be small" sur l4ka.org.
      L'approche moitié-moitié, ce serait celle de Mach: un micro-noyau qui fait pas mal de choses... et on voit que niveau performances, c'est assez catastrophique.

      La seule façon d'avoir un système utilisant abondamment les méchanismes d'IPC (et donc une architecture multi-serveurs) est d'avoir de l'IPC extrêmement rapide, ce qui n'est possible qu'avec un noyau minimal ne faisant quasiment que de l'IPC.

      De plus, tout ce qui est mis dans le kernel (la VM, le scheduler, ...) perd instantanément en flexibilité et en possibilités de "customization", et donc en efficacité (cf les différentes VMs sous Linux, aucune n'est meilleure dans l'absolu, mais en avoir plusieurs dans le noyau est impossible. Alors qu'avec une VM en espace utilisateur, il est possible de la changer facilement, voir même d'en avoir plusieurs qui cohabitent pour différents types programmes est possible.)

      Les BSD c'est monolithique ?

      Tout autant que Linux.
  • # Re: Hurd bientot au niveau de l'Everest !!!

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Perso j'attends surtout l'usb dans GNU/Hurd. Parce qu'un OS sans le net (modem usb..) je peux pas :p

    WeeChat, the extensible chat client

    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

      Posté par  . Évalué à 4.

      Tu le codes quand ? Ca a en tout cas l'air de potentiellement pouvoir bien te motiver.... :P
      • [^] # Re: Hurd bientot au niveau de l'Everest !!!

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        Que le sujet me motiver est une chose, avoir le temps de le faire en est une autre :p Au vu du nombre de projets que je gère en même temps, je n'ai malheureusement pas le temps... Et de plus je ne pense pas avoir les compétences nécessaires pour faire ça... :)

        WeeChat, the extensible chat client

    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

      Moi c'est le son =) J'ai pas le temps de le coder donc je patiente dans mon coin *sans raler*, je suis sur que GNU/Hurd c'est l'avenir =)
      • [^] # Re: Hurd bientot au niveau de l'Everest !!!

        Posté par  . Évalué à 6.

        Le son et l'USB, même combat ! :) En fait l'élément manquant pour les périphériques en mode caractère n'est pas des drivers (ca existe ...) mais une librairie avec une interface 'comme il faut' pour pouvoir accéder aux devices.... on connait déjà son nom : libchannel ;) Une fois cette librairie écrite (vu le nombre de personnes nit'eressées, ca pourrait se faire vite si chacun s'y met un peu) l'ajout des drivers son, USB mais aussi pour les cartes TV ne sera pas forcément très dur...
        • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

          J'ai une mauvaise nouvelle pour vous les mecs : Le GNU/Hurd dans son etat actuel ne supporte ni l IRQ sharing, ni le PCMCIA, et sans ca, dites adieu a tout ce qui marche sur PCMCIA ( carte reseau surtout ), quand a l IRQ sharing, ceux qui conaissent comprendront de quoi je parles, ceux qui ne conaissent pas encore, risquent de decouvrire a leur depends a quel point c est important : en gros, c est ce qui autorise deux cartes PCI a avoir la meme IRQ: le GNU/Hurd ne reconaitra qu un seul peripherique ... donc si vous avez un peripherique critique ( carte IDE, carte reseau, carte video ) qui partage et qui n est pas en tete des attributions, c est mort :=) Un remede existe sur cetains PC , mais il y a des BIOS mal fait ( 80% ? ) ou il n y a aucun remede :/ ... c un autre truc qu il serait urgent de deboguer ... enfin bref ... A VOS CLAVIERS :)
          • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

            pour le PCMCIA il existe des patch pour oskit et donc ca apporte un support (pour l'instant assez léger, limité aux carte réseau je crois, à vérifier) léger à oskit-mach.
            Sans doute que olivp saurait en dire plus car il me semble qu'il tripatouille un peu avec ca, et qu'il a meme fait marcher sa carte wireless (à vérifier)
          • [^] # Re: Hurd bientot au niveau de l'Everest !!!

            Posté par  . Évalué à 6.

            Pour tout ce qui concerne les drivers, il faut voir que là le travail effectué sur Mach ne sera que très peu réutilisable sur L4, et donc se serait, à mon avis, une perte de temps sur le long terme.

            Écrire la libchannel d'une manière portable serait bien, mais pour ce qui est de corriger GNU Mach pour le support des IRQs paratagées ou lui intégrer le support de l'USB, je ne pense pas que ça en vaille la peine... maintenant si quelqu'un a envie de le faire, pourquoi pas :)
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

      Posté par  . Évalué à -10.

      Parce qu'un OS sans le net (modem usb..) je peux pas :p Parceque le net c'est l'usb ?
  • # Hurd sur L4 et Hurd/GNUMach sur PPC ?

    Posté par  . Évalué à 3.

    Je profite de la news pour reposer deux questions qui n'ont rien à voir... -Il y a sur savanah un projet l4hurd consacré au port de Hurd sur micronoyau L4. C'est tellement actif que ça a l'air abandonné depuis 6 mois? Quelqu'un a des infos sur ce projet ? -Il y a des réussite de hurd/GnuMach sur PPC, d'après Google... Quelqu'un a un lien qui explique comment faire que je me tente ça aussi ? (ne pas poser deux questions à la fois, il y en a toujours une qui passe à l'as)
    • [^] # Re: Hurd sur L4 et Hurd/GNUMach sur PPC ?

      Posté par  . Évalué à 3.

      l4 hurd n'est pas abandonné, il est dans tous les esprits.... dans l'attente de la sortie de l'impl'ementation basée sur la version X2 de l'interface, et plus particulièrement de sa licence !!! On devrait être fixés dans les jours à venir. Pour ce qui est du port PPC, il y a une port qui a été fait en se basant sur Mach OSF, mais avec oskit et l4, il devrait être possible d'en avior une implémentation à jour. :)
      • [^] # Re: Hurd sur L4 et Hurd/GNUMach sur PPC ?

        Posté par  . Évalué à 2.

        Et si jamais la licence n'est pas sympathique du tout, qu'est-ce qui se passe ? Réimplémentation libre de la version X2 de l'interface ? Abandon du projet L4Hurd ? On l'utilise en attendant une réimplémentation libre ou un changement de licence ? (à la manière de KDE et Qt à leurs débuts) Bref, qu'est-ce qui se passe ?
        • [^] # Re: Hurd sur L4 et Hurd/GNUMach sur PPC ?

          Posté par  . Évalué à 0.

          Qui vivra verra? Je te rappelle quand meme que c'est de logiciel libre dont on parle les "master plan" ne marche pas trop, cf le temps que met Hurd pour se developper. Donc si la license du nouveau L4 n'est pas satisfaisante, il arrivera ce que les contributeurs a Hurd voudront faire! Et la je n'ai pas ma boule de crystal sur moi ;-)
        • [^] # Re: Hurd sur L4 et Hurd/GNUMach sur PPC ?

          Posté par  . Évalué à 10.

          Bon, j'en profite pour répondre à l'ensemble du thread.

          -Il y a sur savanah un projet l4hurd consacré au port de Hurd sur micronoyau L4. C'est tellement actif que ça a l'air abandonné depuis 6 mois? Quelqu'un a des infos sur ce projet ?

          Les problèmes d'organisation à L4Hurd .. :-) Bien difficile à expliquer. En fait, à l'origine, L4Hurd - c'est le nom qu'on donne habituellement au port du Hurd sur L4, n'y voyez aucun caractère officiel ou logique, il a juste le mérite de ne comporter aucune ambiguïté - est en fait un projet discuté depuis d'assez nombreuses années. La mailing list l4-hurd a été créée en octobre 2000, si mes souvenirs sont bons, et à l'époque, c'était Yoshinori K. Okuji, qui avait participé à pas mal de choses concernant le Hurd et GNU Mach, et qui est l'auteur de Grub, qui voulait le démarrer. Farid Hajji, à l'époque, voulait également participer au port. Les deux sont des gens que je respecte, ayant un niveau de connaissances techniques générales, et sur le Hurd et Mach en particulier, qui dépasse la plupart des gens - qui dépasse le mien, sans hésiter, même si on finit par atteindre des niveaux similaires. Mais, ils n'ont pas la même vision, je pense, que Thomas, Marcus ou Neal, du développement, et étaient plus dans une approche pragmatique de perfection technique quant aux rouages internes. Ainsi, une VMM à peu près « monolithique » (bien qu'en user space) qui reprendrait les bases de UVM (la VM de NetBSD (les médisants (et les épitéens) disent que c'est la seule chose de bien dans NetBSD .. :-> (et les intelligents que lisp ownaize)) avait été prévue. Ce port se fondait sur la version des API précédente, qui a abouti à Hazelnut, dernière implémentation de L4 sortie du projet L4Ka. Mais, rien de concret n'a *vraiment* été fait, Okuji et Farid ayant très peu de temps.

          Là-dessus est arrivé Neal H. Walfield, développeur du Hurd depuis environ 1999, qui a eu la chance de rencontrer, lors du 18C3 (18ème Chaos Communication Congress (où Neal avait donnée une conf sur le Hurd dont on peut trouver les transparents sur http://web.walfield.org/papers/hurd-conference-ccc-20011228/(...) )), un certain nombre de gens travaillent sur L4, principalement les gens de l'université de Dresden - projet L4Ka. C'est à cette occasion là que Neal, comme Marcus, furent convaincus de la nécessité du port sur L4 - et suite à ça que le premier pas de L4Hurd va être suivi, avec la décision de Neal de passer son été avec les gens de L4Ka pour coder le portage. Ne rêvez pas, ça ne veut pas dire qu'il avait fini au bout :-) Il est très difficile de définir autant de nouvelles interfaces en si peu de temps, surtout quand on a pas envie de vivre reclus, et Neal n'est pas tout à fait le genre à vivre reclus ;-) Dans tous les cas, un certain nombre de choses avaient été définies, dont notamment l'ensemble des serveurs nécessaires, la gestion de choses comme les privileged system calls, la façon dont serait gérée le VMM[0].

          Ian Duggan, et le projet L4Hurd enregistré sur Savannah, font partie de la suite du projet de Okuji et Farid, fondé sur Pistachio, et pour lequel peu ou rien n'a été fait - Pistachio est réellement le seul à nous intéresser, en réalité. Il est donc normal qu'il soit inactif. Le code fait par Neal H. Walfield et auquel on a contribué n'est disponible que dans un CVS privé - il ne mérite pas réellement l'attention, c'est plus les mails et les idées qui en ont résulté qui la mérite. Et, surtout, il repose entièrement sur l'API d'un Pistachio pas encore sorti, donc ..

          -Il y a des réussite de hurd/GnuMach sur PPC, d'après Google... Quelqu'un a un lien qui explique comment faire que je me tente ça aussi ?

          Tous les détails ici : http://lists.debian.org/debian-hurd/2002/debian-hurd-200204/msg0003(...) ; pour les patches manquants, les différents détails, simplement chercher les mails de Peter sur bug-hurd[1], et voir les plus à jour. Au passage : Pistachio est porté sur PowerPC.

          Et si jamais la licence n'est pas sympathique du tout, qu'est-ce qui se passe ? Réimplémentation libre de la version X2 de l'interface ? Abandon du projet L4Hurd ? On l'utilise en attendant une réimplémentation libre ou un changement de licence ? (à la manière de KDE et Qt à leurs débuts) Bref, qu'est-ce qui se passe ?

          Une très bonne question, que je vous remercie d'avoir posée :-) Bon, d'abord, ce qui ne se passera pas : en aucun, aucun cas, il n'y aura abandon du projet L4Hurd. Et, on n'utilisera pas une version non-libre, il n'en est évidemment absolument pas question - bien que le problème soit différent que KDE et Qt, parce que l'exception de la GPL concernant les bibliothèques et outils essentiels au système serait facilement exploitable « légalement ». Bon, dans tous les cas, il est clair, net, et précis, que la licence de Pistachio, dont des pre-releases devraient être publiées d'ici quelques semaines à peine, des dires des développeurs qui s'y affairent, devrait être « sympathique ». C'est à dire, probablement quelque chose autour du BSD. Dans cette perspective, et vu le bon boulot des gens de L4Ka, une réimplémentation à nous utilisant les interfaces X2 (de Version4, plus généralement) n'est pas à l'ordre du jour.
          [0]: http://web.walfield.org/papers/better-best-effort-20021026/(...)
          [1]: http://mail.gnu.org/archive/cgi-bin/namazu.cgi?query=pjbruin&su(...)
  • # GNU/Hurd vs GNU/Linux ?

    Posté par  . Évalué à 9.

    salut tous, C'est vrai que c'est formidable d'avoir (enfin) un autre système d'exploitation libre et (gnu)ial face aux proprio. Cela va sans aucun doute offrir de nouvelles occasions de montrer que le libre est bouillonnant d'idées et de savoir faire. L'image du "boutonnneux binoclard" est en passe de devenir de l'histoire ancienne. Mais voilà je me pose des questions et incidemment à vous tous, à savoir : Première question : Le GNU/Linux est considéré comme un noyau monolithique. Mais alors peut on encore parler de système de noyau en bloc, à partir du moyen où l'utilisation des modules kernels reduisent le role du kernel à un simple "gestionnaire" de modules externes ? Peut on encore parler de noyau monolithique à partir du moment où le plantage d'un module n'entraine pas l'arret complet du système ? Deuxième question : La multiplication des systèmes d'exploitation "libres" (xBSD, Linux, Hurd), et je ne parle pas des multiples distributions linux ou version xBSD, ne risque t-il pas d'amener un peu plus de confusion chez les utilsateurs des dits systèmes, alors qu'une certaine cohésion commence (enfin) à se faire jour autour de GNU/Linux ? Troisième question : Si l'on ne parle pas d'opposition, alors j'ai un peu de mal à comprendre la complémentarité entre les deux systèmes. Existe t-il un système "libre" plus performant que l'autre (vitesse, éxécution des programmes, gestion de la MC, gestion des périphériques), de telle manière que le système le plus rapide pourrait servir pour "des expérimentations" et l'autre pour une production en entreprise ? Quatrième question : Cette dernière question est la suite logique de la troisième, à savoir : Ces deux systèmes (diamétralement) opposées dans leur conception de base, peuvent ils etre compatibles au niveau des binaires, comme cela existe avec les Unix commerciaux et le GNU/linux avec le module IBCS ? Il me semble que la définiton d'un micro-kernel est justement de modulariser au maximun la gestion des périphériques (la notion de périphérique étant ici associée à la notion de fichiers). Alors j'ai un peu de mal à saisir la distinction fondamentale entre le GNU/Linux et le GNUS/Hurd qui sont souvent deux systèmes opposés, à part le fait que Hurd est 100% gnu et que linux est (disons) "une pièce rapportée" à gnu. Ni trolls ni batons, je veux juste connaitre l'intéret d'un nouveau système libre avec les risques de dislocation des énergies que cela comporte.
    • [^] # Re: GNU/Hurd vs GNU/Linux ?

      Posté par  . Évalué à 7.

      Q1 : les modules sont juste une facilité pour gérer les drivers, mais ils s'exécutent malgré tout en mode noyau. Il ne faut pas confondre module noyau et serveur dans l'espace utilisateur !!! Le plantage d'un module entraine le plantage plus ou moins rapide du système. Q2 : bof.... non ? Q3 : Il n'y a pas de raison qu'il y ait opposition. Le modèle propriétaire amène les entreprises à tenter de détruire l'autre, car il faut survivre.... Sortons de cette optique ! On fait du libre, les systèmes peuvent cohabiter, on utilise chacun en fonction de ses capacités et des fonctionnalités qu'il offre, opint à la ligne. Tout placer dans un contexte de concurrence n'a rien de plaisant ni de judicieux. Q4 : Je ne suis pas sur qu'ils soient compatibles au niveau des binaires... Ils sont compatibles au niveau des sources (ou presque) et ceci est du à entre autres à l'utilisation d'une même libc (la GNU libc).
    • [^] # Re: GNU/Hurd vs GNU/Linux ?

      Posté par  . Évalué à -2.

      1 : ça se ressemble effectivement, la différence, c'est que les modules linux s'exécutent en root, pas les serveurs hurd 2 : je suis d'accord, mais hurd est plus innovant que le kernel Linux, à long terme c'est bien (je connais pas les BSD, mais perso j'aime pas parce que c'est pas GPL). Pour l'instant, Linux c'est mieux (car il y a beaucoup d'applis, style mp3-tv-jeux en particulier) 3 : ils sont pas complémentaires, hurd est censé remplacé linux (d'ici quelques annés) 4 : oui, de même que les binaires windows tournent sous linux, tant que c'est un binaire compilé pour l'archi de l'OS et que le format du binaire est documenté
      • [^] # Re: GNU/Hurd vs GNU/Linux ?

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

        ils sont pas complémentaires, hurd est censé remplacé linux (d'ici quelques annés) Juste pour éviter tout malentendu, Hurd n'a la prétention de remplacer Linux que dans le cadre du projet GNU. Je dis ça pour ceux qui seraient tentés de voir ici de l'intégrisme... Mais je me fais du soucis pour rien, hein !? :)
        • [^] # Re: GNU/Hurd vs GNU/Linux ?

          Posté par  . Évalué à 3.

          Hurd n'a la prétention de remplacer Linux que dans le cadre du projet GNU.

          Euh, le Hurd est et a toujours été le "coeur" officiel du projet GNU. Linux ne fait pas partie du projet GNU, et GNU/Linux est bien "le système GNU au-dessus du noyau Linux" en opposition au système GNU (= GNU/Hurd) qui contient le Hurd.

          Maintenant, si on parle de remplacer dans la pratique, le Hurd n'est pas encore près pour ça, mais à terme je pense que dans pas mal de situations on pourra avantageusement remplacer GNU/Linux par GNU/Hurd. Ce qui n'empêche pas que GNU/Linux restera un OS libre de très bonne qualité, et ce qui ne siginifie pas la disparition de Linux - ce n'est en tout cas le but de personne ici.
    • [^] # Re: GNU/Hurd vs GNU/Linux ?

      Posté par  . Évalué à 10.

      Le GNU/Linux est considéré comme un noyau monolithique. Mais alors peut on encore parler de système de noyau en bloc, à partir du moyen où l'utilisation des modules kernels reduisent le role du kernel à un simple "gestionnaire" de modules externes ?

      Oui, définitivement, oui. Tu dois remarquer toi-même, dans ta phrase, une contradiction flagrante : tu parles de module noyau. Tu es bien conscient que ces modules n'ont aucune autonomie, et qu'il s'agit juste de bouts de code qui seront ajoutés ou enlevés dynamiquement - c'est le principe des LKM. Ces bouts de code, une fois intégrés, font partie du noyau au même titre que ceux qui n'auront pas été chargés dynamiquement. Alors, le noyau n'est plus un gestionnaire de modules externes, puisqu'il comporte les parties qui étaient dans les modules. La modularité qu'implique l'utilisation de LKMs - très intéressante, cependant - n'est qu'une astuce pratique pour facilité la vie des utilisateurs : elle ne constitue en aucun cas une modularité de design, en aucun cas une modularité « logique » : si tu dois faire un schéma des différentes fonctions de l'OS, et par qui elles sont assurées, tu devras toujours faire un schéma avec un énorme (puisqu'il contiendra plein de cases avec ce qu'il fait, donc pas au sens de l'espace disque) noyal au milieu : un noyal monolithique.

      Il faut bien aussi voir que s'il est difficile de discriminer parfaitement un micro-noyau d'un noyau monolithique, c'est parce qu'il s'agit également d'une question d'esprit, d'évolution, de volonté dans la conception du noyau, et pas seulement qu'une question des fonctionnalités que l'on peut avoir en espace utilisateur et superviseur (et en aucun cas, une question de taille). Mach, par exemple, bien que fournissant la majeure partie de son VMM en kernel space (toute la partie concernant la décision de quelles pages est swapped ou swapped in se trouve dans le noyau), fournit un certain mouvement vers l'espace utilisateur en fournissant le principe de memory objects et de backing store, délégant la responsabilité du choix du traitement de ces pages swapped out à un pager (page fault handler), qui sera chargé de les restituer quand y'en aura besoin (en cas de page fault). C'est, en fait, sur ce principe que sont implémentés les systèmes de fichier en espace utilisateur - et on imagine l'avantage qu'une telle approche fournit par rapport à des systèmes distribués, avec une mémoire distribuée, par exemple. Ces innovations, cette optique, plus le fait qu'une grande partie soit déjà délocalisée, en fait vraiment un micro-noyau. Ce qu'on ne peut pas dire de Linux. Linux, lui, a pour optique, de l'avis même de Linus Torvalds, une optique qui n'est pas celle du design, mais celle d'un pragmatisme technique. Ainsi, le cas de la VMM est intéressant : si l'on prend par exemple la VM rmap, on ne peut dire qu'elle n'est pas designée : elle est réfléchie, pensée, structurée, articulé autour d'un principe de reverse-mapping qui se justifie totalement, et le fait est que techniquement, c'est, à mon avis, une excellente VM.

      En revanche, a-t-elle un vrai design de structure ? De la même façon que Linux, je ne le pense pas : il s'agit simplement d'une entité monolithique, ou tout est ensemble, les fonctions pas ou peu séparées logiquement, juste un programme, comme ça. Le cas de Mach évoqué ci-dessus montre un réel effort de design, puisqu'il y'a une séparation logique entre le "Who?" et le "Where?", permettant déjà une modularité et une adaptabilité qui change la vie. Voilà, ce que veut dire la modularité, et le design du Hurd. C'est encore plus vrai dans le cas de la VMM qui a été concue pour le Hurd sur L4[0].

      Peut on encore parler de noyau monolithique à partir du moment où le plantage d'un module n'entraine pas l'arret complet du système ?

      Euuuuh, ce ne serait plus des modules, mais des entités séparées. Ce qui n'est pas le cas actuellement. Je le dis et le répète : ce qui change dans un module, c'est la façon d'arriver dans le kernel, et le fait qu'on puisse le virer puis le remettre dynamiquement. C'est uniquement une facilité technique. Ils ont donc exactement les mêmes droits que ceux qui sont déjà dans le noyau. Ils peuvent provoquer l'arrêt complet du système, le plantage complet du noyau. Pensons par exemple aux drivers (libres) du winmodem du portable de Kilobug qui plantent quand on joue un ogg en se connectant :-)

      La multiplication des systèmes d'exploitation "libres" (xBSD, Linux, Hurd), et je ne parle pas des multiples distributions linux ou version xBSD, ne risque t-il pas d'amener un peu plus de confusion chez les utilsateurs des dits systèmes, alors qu'une certaine cohésion commence (enfin) à se faire jour autour de GNU/Linux ?

      C'est réellement une fausse question. Le problème est, il faut que les utilisateurs aient une vue d'ensemble assez globale du paysage disponible. Celà ne veut pas dire, des préjugés à deux balles qu'ils répandent sur les newsgroups du genre « Nunux c'est pour les débutants, ensuite c'est BSD pour les vrais proZ, etc. ». Ça veut dire avoir quelques éléments de base théorique, qui vont permettre de dire « Bon, voilà, les deux sont des trucs qui sont de la même famille, compatibles, y'a les mêmes logiciels dessus, c'est donc ce qui est très bas niveau qui change, genre tout ce qui va concerner le matos, etc. ». Ça va pas très loin, ça nécessite pas grand chose, mais ce serait heureux qu'un utilisateur basique sache un minimum d'informatique. Comment ça, utopiste ? (:


      Si l'on ne parle pas d'opposition, alors j'ai un peu de mal à comprendre la complémentarité entre les deux systèmes. Existe t-il un système "libre" plus performant que l'autre (vitesse, éxécution des programmes, gestion de la MC, gestion des périphériques), de telle manière que le système le plus rapide pourrait servir pour "des expérimentations" et l'autre pour une production en entreprise ?

      Si l'on ne parle pas d'opposition, c'est plus pour éviter le sous-entendu de rejet mutuel et de non communication entre les deux mondes. Linux, de par son excellence technique, a beaucoup à nous apprendre. Le Hurd pourrait apprendre pas mal de choses aux développeurs Linux. Pour l'instant, il n'y a pas « compétition » : les développeurs de GNU/Hurd utilisent GNU/Linux pour travailler, et l'un sert à l'autre. Il sert aussi à l'autre dans la mesure où il permet la promotion du libre, et le développement de logiciels libres, qui marcheront ensuite sous GNU/Hurd. Cependant, il ne faut pas se leurrer : GNU/Linux et GNU/Hurd se veulent des systèmes adaptables à à peu près toutes les possibilités - GNU/Hurd surtout, bien entendu ;-) Ils s'adressent donc au même public : tous ! Ensuite, le minoritaire pourra être utilisé pour des tâches où les avantages de l'autre ne comptent pas vraiment - changer le coeur d'un OS change beaucoup de choses, mais il ne peut pas tout.


      Cette dernière question est la suite logique de la troisième, à savoir : Ces deux systèmes (diamétralement) opposées dans leur conception de base, peuvent ils etre compatibles au niveau des binaires, comme cela existe avec les Unix commerciaux et le GNU/linux avec le module IBCS ?

      Oui, ils peuvent l'être, moyennant un effort. GNU/Hurd fournit une couche de compatibilité POSIX dans la GNU C Library, dans une certaine mesure il fournit aussi une compatibilité plus spécifiquement Linux et avec le port Linux de la GNU C Library, bien qu'à l'origine, il ait plus tendance à se rapprocher de BSD au niveau de ses interfaces - origines de Mach obligent, on retrouve les slices, la gestion des interruptions (niveaux de priorités, soft interrupts en « couches », ...). Il suffirait de presque rien, peut-être quelques symboles de plus, pour que te je dise : il y'a compatibilité binaire. (comment ça, c'est mauvais ?! :-). Cependant, je ne pense pas que ce soit une priorité, pour moi comme pour tous les développeurs de GNU/Hurd. Il me semble que la compatibilité sources devrait être assez, et qu'une compatibilité binaire ne peut engendre qu'une série de problèmes qui n'ont que peu d'intérêts. Ah, à moins que vous vouliez parler de logiciels propriétaires .. auquel cas vous oubliez qu'on parle ici du système GNU, l'officiel, le seul système d'ailleurs (« There is no system but GNU »), et que la possibilité du propriétaire ne rentrera aucunement dans nos priorités.

      [0]: http://web.walfield.org/papers/better-best-effort-20021026/(...)
      [1]:
      • [^] # Re: GNU/Hurd vs GNU/Linux ?

        Posté par  . Évalué à 1.

        Salut Manuel Menal,

        Tres bonne argmentation de ton point de vue. Pour résumer, tu considères que la différence principale entre les deux systèmes en question GNU/Linux et GNU/Hurd, se place au niveau de la gestion des périphériques et de la MC, à savoir :

        - Linux active ou non les modules périphériques une fois pour toute et de manière globale. Les modules sont donc intégrés au noyau minimal de départ. Chaque utilisateur aura la meme configuration matériel.

        - Hurd, par contre applique la modularité de manière plus complète en ne chargeant les modules périphériques qu'en fonction d'un utilisateur et non de manière globale. L'utilisateur plante son espace mais pas le noyau central.

        Mais alors en quoi le Hurd est différent des possibilités du User-Mode Linux (UML), permettant à tout utilisateur d'avoir son propre espace (périphérique et environnemental) sans compromettre l'ensemble du système central ?
        • [^] # Re: GNU/Hurd vs GNU/Linux ?

          Posté par  . Évalué à 2.

          UML, si je ne m'abuse, utilise des modules noyau. Ces modules noyaux sont, comme tout programme informatique, sujets à bug. S'il y a une seule différence à retenir entre le Hurd et Linux en tant que noyaux, c'est bien que les modules Linux ont d'énormes privilèges, qui sont très certainement disproportionnés par rapport à ce qu'ils devraient: un module a accès, à travers le noyau, à l'ensemble de l'espace d'adressage du noyau, il peut foutre une merde noire s'il est mal codé, et faire planter toute la machine alors meme qu'il ne sert qu'à une fonction très particulière.
          Les serveurs Hurd n'ont pas ce type de privilèges. Ils tournent dans l'espace utilisateur. Je pense qu'on peut tenter un parallèle (corrigez moi si je me trompe) avec les serveurs DNS, FTP, Web, etc. bref les applications serveurs sous n'importe quel OS, qui tournent sous un utilisateur quelconque, et dont les droits sont restreints à ceux de cet utilisateur.

          Ainsi (et là je parle de quelque chose dont je n'ai qu'une connaissance très imparfaite, donc merci de me corriger), je pense qu'on peut assigner à un certain serveur Hurd un utilisateur (par exemple, l'utilisateur "fs" au serveur de systèmes de fichiers), et ainsi limiter les retombées d'un bug ou d'un trou de sécurité quelconque. Bien sur, un bug dans le serveur de systèmes de fichiers peut etre catastrophique: après tout, celui qui gère le système de fichiers a un accès privilégié aux fichiers, il peut donc les foutre en l'air ! L'idée est qu'il ne peut pas faire de mal en dehors de ce qu'il est censé gérer. Un peu l'idée d'un chroot, ou l'utilisateur peut bien sur massacrer tous ses fichiers, mais ça n'affectera pas les autres utilisateurs.
        • [^] # Re: GNU/Hurd vs GNU/Linux ?

          Posté par  . Évalué à 5.

          Hum, il ne faut pas confondre "espace utilisateur" / "espace noyau" et la notion d'utilisateur du système.

          Un programme tournant en espace noyau (comme Linux, y compris ses modules) ont un pouvoir complet sur le système: ils peuvent accéder à toute la mémoire, ont accès aux périphériques, ont accés à toutes les instructions du processeur. Un bug dans un programme de ce type peut donc entrainer un plantage du système, des corruptions de données, voir même des dégâts matériels si des périphériques sont trop sensibles.

          Un programme tournant en espace utilisateur est soumis à des restrictions par la matériel, restrictions configurées par le noyau, et ne peut donc pas faire tout et n'importe quoi. C'est nécessaire pour assurer une sécurité au sens utilisateurs Unix (si un programme lancé par "kilobug" tournait en mode noyau, il pourrait aller modifier et prendre le contrôle d'un programme tournant en "root" ou accéder directement au disque dur pour lire des données personnelles, ...), mais pas seulement.

          Sous GNU/Hurd, même si le translator ext2fs de /home (le programme gérant le système de fichier ext2 sur /home) tourne en root, dans le cas d'une défaillance de ce programme, il segfault comme un programme normal, si qui ne plante pas l'ensemble du système et ne peut pas créer de corruptions de données sur /. D'ailleurs, au prochain accès à /home, par le biais des translators passifs, le serveur sera relancé, et le système toujours utilisable.
      • [^] # Re: GNU/Hurd vs GNU/Linux ?

        Posté par  . Évalué à 1.

        Bon, je n'y connais rien en conception d'OS... Mais le plus important pour l'utilisateur final est que ça marche, il s'en fiche si l'OS est monolithique ou à micro-noyau, ce sont des concepts d'informaticien, pas d'utilisateur... Alors, je pose la question : Quel sera le bénéfice (réel) d'un tel OS (j'ai jamais essayé Hurd) par rapport à d'autres, l'utilisateur moyen peut-il l'utiliser sans être informaticien confirmé??
        • [^] # Re: GNU/Hurd vs GNU/Linux ?

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

          Je n'ai jamais essayé le GNU(/Hurd) mais bon, il me semble que tes questions sont suffisement vagues pour s'appliquer à tout système alors je tente d'y répondre :)

          Quel sera le bénéfice (réel) d'un tel OS (j'ai jamais essayé Hurd) par rapport à d'autres
          Un comportement différent qui sera plus adapté à certaines utilisations que d'autres systèmes et probablement moins adapté a certaines situations.
          Dans le cas du système GNU, si j'ai tout bien compris, on a une machine qui a l'air d'être très adaptée pour faire un serveur haute disponibilité (stabilité générale accrue, attribution des droits plus fine, etc.) et qui l'est moins pour une utilisation 'calcul brut' (système globalement plus lent qu'un noyau monolythique).

          l'utilisateur moyen peut-il l'utiliser sans être informaticien confirmé ?
          Je vois pas ce qui le différencierait de tout autre système d'exploitation :
          - pour utiliser les logiciels "métier" : à priori, pas besoin d'être un expert en info
          - pour configurer, maintenir et installer : il faut avoir un minimum de connaissances liées à ce que tu veux installer, maintenir ou configurer (réseau, son, etc.)
          • [^] # Re: GNU/Hurd vs GNU/Linux ?

            Posté par  . Évalué à 1.

            En fait ce que je voulais savoir est si Hurd est plus difficile (d'accès) que Linux qui n'est déjà pas si simple que ça...
            • [^] # Re: GNU/Hurd vs GNU/Linux ?

              Posté par  . Évalué à 1.

              Comme le dit Manuel, GNU (donc le Hurd) s'adresse a l'ensemble des utilisateurs quels qu'ils soient, a terme il est donc probable (bien qu'il soit souhaitable que les utilisateurs connaissent quelques bases de l'informatique ;-) que des efforts soient faits dans ce sens (en tout cas j'en suis persuade). Pour ce qui est de GNU/Linux, nous avons bien des distributions (Knoppix ?) faciles a installer.
        • [^] # Re: GNU/Hurd vs GNU/Linux ?

          Posté par  . Évalué à 3.

          Bon, c'est une question bien difficile, et que je ne trouve pas d'une pertinence extrême, en réalité. Je m'étais pourtant tenté à quelques éléments de réponse dans une précédente nouvelle ici-même, sur le sujet, intitulée de façon très ... polémique « GNU/Linux est mort, vive GNU ! » [0] .

          Je compléterai - je ne pense pas l'avoir assez dit dans ces précédents commentaires, depuis lesquels ma façon de voir les choses et, surtout, de les expliquer a pas mal changé - en insistant sur le fait qu'on parle ici de deux variantes du système GNU[1], donc la comparaison au niveau de l'utilisateur final est quelque peu biaisée : la base du système d'exploitation n'a qu'une influence indirecte - ce qui ne signifie pas qu'elle n'est pas capitale - sur ce que voit, peut faire, et fait un utilisateur « de base ». Les repercussions sont quand même très importantes : la stabilité - un utilisateur de base ne voit peut-être pas que c'est le driver à deux balles de son périphérique quelconque à deux balles qui crashe, mais le crash, il le sent :-) ; la rapidité - la flexibilité entraîne une amélioration de la rapidité et de la « légèreté » importante; on pense notamment à la possibilité d'échanges de contrats concernant les ressources systèmes, comme dans le cas du VMM du Hurd pour L4[2] ; la sécurité - le système complètement modulaire, adaptable à tout type de sécurité (les « authentication tokens » sont génériques, ils peuvent s'appliquer aux capabilities, aux UIDs, mais aussi à une gestion des droits beaucoup plus fine) permet de limiter les dégâts occasionnés par un trou de sécurité.

          Tous ces points, je les ai développés ailleurs et en d'autres temps ; je suis ouvert à toutes questions, ici ou ailleurs (le temps se resserre ici, sur DLFP coulent les news et nos questions). Au hasard, sur la ML HurdFr[3] :-)


          [0]: http://linuxfr.org/2002/03/13/7530.html(...)
          [1]: http://linuxfr.org/comments/118290.html(...) pour ma justification de l'appellation GNU/Linux
          [2]: http://web.walfield.org/papers/better-best-effort-20021026/(...) et, pour pas faire genre « Je donne toujours la même URL », http://citeseer.nj.nec.com/ferguson96economic.html(...) :-)
          [3]: http://hurdfr.org(...) dans les dernières nouvelles.
      • [^] # Re: GNU/Hurd vs GNU/Linux ?

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

        Salut,
        Juste pour te féliciter de la qualité de tes posts, vraiment passionnants. J'y ai appris plein de trucs, merci.
  • # Re: Hurd bientot au niveau de l'Everest !!!

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

    Alors, mon humble avis, oui le hurd, c'est peut etre l'avenir pour le système GNU au niveau des serveurs. Mais pour le reste, je vois mal commant le hurd pourrait détronner linux. Nous serions en 1991, je ne serais pas aussi affirmatif, mais la c'est différent, linux s'est imposé comme le noyau du système GNU( != Linux fait parti du projet GNU) et il me semble impossible(je me trompe peut etre) que le hurd puisse reprendre la place de linux. Certe, les informaticiens comme nous utiliseront surement le hurd quand il sera stable, mais pour les autres... Une autres chose, il ne faut pas dire que Hurd apporte la possibilité de faire plus de choses que linux, avec un modules approprié, il ne me semble pas impossible de monter un serveur ftp distant dans le système de fichier. Dans ce cas la, la seul difference se trouverait dans le fait que le hurd fait tourner le service dans l' espace utilisateur. Je ne suis pas non plus rassuré par le temps que prend le devel du hurd, depuis le temps que le devel a commencé(vers 91 je pense), que le système ne soit pas stabilisé montre bien que le nombre de personnes travaillant dessus est bien trop faible.
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

      Posté par  . Évalué à 3.

      > «linux s'est imposé comme le noyau du système GNU( != Linux fait parti du projet GNU) et il me semble impossible(je me trompe peut etre) que le hurd puisse reprendre la place de linux.» Dans la mesure où à terme on pourra retrouver les mêmes applications utilisateurs de part et d'autre, ça ne me paraît si impossible. Un KDE sous Hurd ou sous Linux, quel différence pour l'utilisateur de base ? Aucune. En fait, comme ça n'aura aucune importance pour l'utilisateur de base, le choix sera fait par les différents développeurs de distributions.
      • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

        Le problème n'est pas un niveau des applications mais bien au niveau de la réputation de linux et du temps que cela a pris. Aujourd'hui de nombreuse multinationales supportent linux mais quand sera t'il du Hurd! Maintenant que les non informaticiens qui connaissent de plus en plus l'existance de linux, je vois mal comment ils pourraient vouloir utiliser le hurd(surtout que eux, ils s'en tamponnent que ce soit un micro noyau).
        • [^] # Re: Hurd bientot au niveau de l'Everest !!!

          Posté par  . Évalué à 3.

          > «Maintenant que les non informaticiens qui connaissent de plus en plus l'existance de linux, je vois mal comment ils pourraient vouloir utiliser le hurd(surtout que eux, ils s'en tamponnent que ce soit un micro noyau).» Tout à fait, mais comme je le dis ci-dessus, il me semble que ce choix sera celui des développeurs, bien plus que celui des utilisateurs purs. Or, si le Hurd finit par révéler tout son potentiel, les développeurs, eux, ne s'arrêteront pas à la notoriété actuelle de Linux pour rejetter tous les avantages techniques apportés par le Hurd. Ils auront les capacités pour juger sur pièce et le feront.
        • [^] # Re: Hurd bientot au niveau de l'Everest !!!

          Posté par  (Mastodon) . Évalué à 7.

          C'est probablement pour ça que Stallman insiste tant pour que GNU soit mentionné quand on parle de GNU/Linux... Sinon les gens, entendant parler de GNU/Hurd, diront "encore un autre système ?" alors qu'il s'agit du même système avec un autre noyau.
      • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

        Oui mais non :

        Si il n'y a pas compatibilité des binaires, il faudra que les applications commerciales soient portées aussi. Or, il y a des domaines (Par exemple, le design hardware) ou Linux est beaucoup utilisé comme système libre pour des applications propriétaires.

        Et puis il y a aussi tout ce qui est lié aux drivers : Si on obtient des constructeurs qu'ils fassent des drivers Linux, il faudra aussi faire le portage vers Hurd.

        La différence devrait être du même ordre que la différence entre win 9X/ME et NT/2000/XP : Différence pour les développeurs mais pas trop pour les utilisateurs finals quand les développeurs font leurs boulot.
        • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

          Dans GNU y'a GNU :)
          Il me semble pas que les devs fassent tout ce qu'il peuvent pour facilité aux boites telles que nvidia de mettre ses drivers proprio sous GNU, ce système ayant pour but d'être libre ;)
          Si on peut pas avoir les source, c'est pas libre, et ça n'a pas franchement sa place dans GNU... me trompe-je?
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

      > Je ne suis pas non plus rassuré par le temps que prend le devel du hurd, depuis le temps que le devel a commencé(vers 91 je pense), que le système ne soit pas stabilisé montre bien que le nombre de personnes travaillant dessus est bien trop faible. le developpement d'UNICS a commence en 1967-1968, celui de Windows en 1993 windows est installe sur >94% des ordinateurs dans le monde ... juste deux commentaires : -1- le Hurd manque de developpeurs, -2- ce qu on veut c'est du GNU ... je laisse toutes les ( autres ) questions possibles en suspends ...
    • [^] # Re: Hurd bientot au niveau de l'Everest !!!

      Posté par  . Évalué à 10.

      Le problème pour hurd par rapport à Linux est son manque d'expérience. Linux a acquit une expérience énorme. Son niveau de performance le prouve.

      Linux a joliment géré les soucis de clarté de conception et des coups de canif à la conception nécessaires pour les performances ou les fonctionnalités.

      Bref, Linux a fait preuve de beaucoup de réalisme au détriment d'idéaux de conception. C'est typique de Linus.
      Le noyau d'un SE est maintenant extrèmement cher (années homme, compétences, testes) si on ambitionne d'avoir une place significtive. Les acteurs d'Unix, IBM, SUN, etc.. le comprenne et envisage à plus ou moins long terme d'abandonner leur solution propriétaire pour ce tourner vers Linux.

      Au-delà des qualités intrinseques de Hurd, rattraper Linux va prendre beaucoup d'années même si le développement de Linux est figé.
      • [^] # Re: Hurd bientot au niveau de l'Everest !!!

        Posté par  . Évalué à 6.

        > rattraper Linux va prendre beaucoup d'années

        Je parle de la mise au point pour les performances de la vm, la partie réseau, etc...

        Hurd est déjà en avance sur d'autres aspects.
      • [^] # Re: Hurd bientot au niveau de l'Everest !!!

        Posté par  . Évalué à 3.

        Bref, Linux a fait preuve de beaucoup de réalisme au détriment d'idéaux de conception.
        [...]
        Au-delà des qualités intrinseques de Hurd, rattraper Linux va prendre beaucoup d'années même si le développement de Linux est figé.


        Est-ce que le but du projet HURD est de remplacer Linux ?
        Une des motivations de ce projet n'est elle pas de proposer une alternative dans l'alternative ?
        Autrement dit est que HURD apporte ou apportera des réponses différentes de Linux à un problème donné qui ferai de ce dernier un outil indipensable et complémentaire au noyau linux ?
        S'il s'agit de remplacer une brique du système (GNU) par une autre simplement alors l'intérêt du HURD est faible à mon avis.
        Par contre si des concepts s'avèrent plus efficaces dans la réalité et sont repris/diffusés/adaptés alors HURD est interressant.
        Je vois HURD comme un laboratoire d'idées et je pense que ce projet se veut avant tout experimental.
        Je ne verrai pas l'intérêt de débugguer des drivers pour HURD alors que ça marche parfaitement sous Linux par exemple.
        • [^] # Re: Hurd bientot au niveau de l'Everest !!!

          Posté par  . Évalué à 7.

          > Est-ce que le but du projet HURD est de remplacer Linux ?
          Non.
          Mais un système HURD pourra remplacer un Linux. Tant pis pour Linux.
          Un système HURD pourra remplacer un Windows. Tant mieux pour tout le monde.

          Ce n'est pas parce qu'à moyen terme Hurd restera confidenciel qu'il n'a pas d'interêt, de raison d'être. C'est la même chose pour *BSD, etc... . Je répondais à un post Hurd/Linux.
          • [^] # Re: Hurd bientot au niveau de l'Everest !!!

            Posté par  . Évalué à 1.

            Bien d'accord sur la dernière phrase. A mon avis, Hurd restera confidentiel et je ne serais pas surpris que les premiers benchs sérieux entre Hurd et Linux ne tournent à l'avantage du dernier de manière presque indécente. Mais pour autant, si des gens trouvent leur compte en Hurd, alors pourquoi pas?
            Personnellement, je passerai en Hurd si c'est mieux. Pas au niveau de l'architecture ou des trucs de théoriciens à la noix, juste si c'est mieux à l'usage. Et j'espère qu'on me parlera d'autre chose que de monter un serveur ftp distant, parce que pour le moment, ca semble être la seule chose que ca apporte. Et plein d'autres choses que personne ne parvient jamais à nommer. :-)

            Cordialement,
            • [^] # Re: Hurd bientot au niveau de l'Everest !!!

              Posté par  . Évalué à 1.

              Moi je passerais a Hurd quand j'aurais le temps et quand il supportera les fs de plus de 2go. Si au niveau des benchs (temps des differents appels systeme ?) il est un peu moins bien que linux je m'en moque.

              J'ai l'impression qu'il apporte des fonctionnalites vraiment bien (pas seulement des trucs de theoriciens). Le truc des translators c'est genial. Imagine, tu monte un systeme de fichier base sur un fichier .bz2 qui se trouve sur une machine distante, et apres c'est tout transparent. Avoir la vm au niveau user, c'est super aussi. Bref, j'ai l'impression qu'il y a pleins de choses nouvelles, mais j'ai pas envie que ca soit instable donc j'attend. Ma crainte principale : au niveau du materiel (chipset, disque, gfx) ca marche sur quoi ?
            • [^] # Re: Hurd bientot au niveau de l'Everest !!!

              Posté par  . Évalué à 5.

              D'oh, je sais à peine pourquoi je réponds. Si, en fait, je le sais : parce que c'est malheureusement ce genre de propos qu'on entends le plus, et qui sont peut-être les plus difficiles à combattre. Tellement dommage que tant d'histoire nous apprenne si peu, et qu'on revienne encore plus aujourd'hui à « du pratique, du concret, le reste ça sert à rien ! ».

              Les trucs de théoricien à la noix ne sont pas faits pour rien. Ils ne sont pas faits pour faire beau. Il y'a des gens qui réfléchissent - si, si, ça peut te sembler difficile à concevoir, mais même toi, tu en es capable, au fond, et qui le fond pour le bien de tous. L'informatique est une science, et certains essayent de la construire. Je crois avoir employé beaucoup de temps à montrer, dans mes différents commentaires, dans ceux que j'ai cités, et dans bien d'autres endroits, à montrer en quoi ces choses, difficiles à appréhender il est vrai - et donc facilement critiquées, à la façon post-moderniste, mais pourtant si magiques, apportent énormément à tous les niveaux, à tout le monde, à toutes les utilisations - et c'est ça, l'adaptabilité de GNU/Hurd. Une question, une critique fondée en raison serait intéressante - mais pour celà, il va falloir lire, argumenter, reprendre. Pas se contenter de vagues allusions entendues, réferrant à un faux - je l'espère - consensus comme quoi « tout ce qui est théorie est inutile. »

              Concernant les benchmarks, je m'étonnais déjà que personne ne l'ait mentionné. Ça a été suffisamment développé ailleurs[0], je ne pense pas que ça mérite de l'être encore sans aucune question précise. Si critique ou question il y a, cependant, je serais ravi de te répondre. Mais pour celà, il faudra garder en tête le maître mot : argumentation.

              [0]: http://www.linuxfr.org/2002/10/23/10070.html(...)
        • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

          Petite précision :

          Hurd était là bien avant Linux, donc, c'est plutôt Linux qui remplace Hurd.

          Mais Linus a commencé "Pour le fun" principalement, et ne voulais pas reprendre Hurd.

          Voir le post original de Linus dans les archives des newsgroups pour les détails.
          • [^] # Re: Hurd bientot au niveau de l'Everest !!!

            Posté par  . Évalué à 1.

            Hurd était là bien avant Linux, donc, c'est plutôt Linux qui remplace Hurd.

            Non, le Hurd, tout comme Linux, a été commencé en 1991.
            • [^] # Re: Hurd bientot au niveau de l'Everest !!!

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

              "Bien avant", j'exagérais en effet.

              Par contre, je confirme que Hurd a commencé avant Linux, en 1990 :

              "RMS explains the relationship between the Hurd and Linux in The Hurd and Linux, where he mentions that the FSF started developing the Hurd in 1990. As of [Gnusletter, Nov. 1991], the Hurd (running on Mach) is GNU's official kernel."
              (http://www.gnu.org/software/hurd/history.html(...))

              Dans le post original de Torvalds, on trouve :

              "I can (well, almost) hear you asking yourselves "why?". Hurd will be
              out in a year (or two, or next month, who knows), and I've already got
              minix. This is a program for hackers by a hacker. I've enjouyed doing
              it, and somebody might enjoy looking at it and even modifying it for
              their own needs. It is still small enough to understand, use and
              modify, and I'm looking forward to any comments you might have. "
              (http://groups.google.fr/groups?hl=fr&lr=&ie=UTF-8&oe=UT(...))

              (Remarquez au passage que le in a year a pris un peu plus que prévu ;-)

Suivre le flux des commentaires

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