GNU Debian GNU/Hurd G1

Posté par . Modéré par oliv.
Tags :
0
19
oct.
2001
GNU
"G1" est la première distribution (en alpha) de Debian GNU/Hurd. Elle comprend 3 CDs, le premier étant suffisant pour avoir un système utilisable. Le 3ème contient tout et n'importe quoi concernant le développement de l'OS, mais les deux premiers sont relativements "propres et consistants", dixit Debian.
C'est pour l'instant plus une curiosité qu'un système utilisable, mais avec cette distribution, l'installation de Hurd devient (enfin!) relativement accessible.
  • # essai...

    Posté par . Évalué à  -10 .

    ARF ARF... On va enfin pouvoir la tester !
    • [^] # Re: essai...

      Posté par . Évalué à  -10 .

      Heeuuu, peux-tu préciser le fond de la pensée profonde de ton commentaire, parce que là, je ne capte pas grand chose: des CD d'install sont disponible, on nous dit que c'est plutôt pour tester, et toi tu nous apprends qu'on va enfin pouvoir tester!! Ouaaaa, mazette...
      • [^] # Re: essai...

        Posté par . Évalué à  -10 .

        Depuis le temps qu'ils en parlent !
        • [^] # Re: essai...

          Posté par . Évalué à  -9 .

          Les commentaires inutils sont réservés à la tribune libre... si tout le monde dit 'Ouais, c'est cool' à chaque fois que quelque chose de cool est annoncé sur linuxfr, on risque d'avoir de plus en plus de mal à trouver les commentaires intéressants!
          • [^] # Re: essai...

            Posté par . Évalué à  -8 .

            >à chaque fois que quelque chose de cool est annoncé sur linuxfr

            ça devient de plus en plus rare...
          • [^] # Re: essai...

            Posté par (page perso) . Évalué à  -7 .

            >si tout le monde dit 'Ouais, c'est cool' à chaque fois que quelque chose de cool est annoncé sur linuxfr, on risque d'avoir de plus en plus de mal à trouver les commentaires intéressants!
            Ouais, t'as raison, c'est cool.
          • [^] # Re: essai...

            Posté par . Évalué à  -8 .

            Sur la tribune on n'a pas le plaisir de voir les gros cons mettre -15, ca n'a donc pas d'interet alors qu'ici c'est super marrant de voir la bêtise humaine a l'état pur.
            • [^] # Re: essai...

              Posté par . Évalué à  -6 .

              Merci les gros cons, je vois l'imbicilité est toujours le maitre mot ici.
    • [^] # Re: essai...

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

      En effet moi j'avais essayé il y a quelques mois la H1 et j'avais pas reussi.
      Bon d'accord je n'y avais passé que quelques heures.
  • # La "Task List " est plustôt impressionnante

    Posté par . Évalué à  10 .

    http://www.debian.org/ports/hurd/hurd-devel-tasks(...)

    Je ne pensais pas qu'il manquait autant de choses : pas de character device (donc pas de X), pas de ppp, pas de POSIX Thread... la liste est bien longue.

    Mais le moins qu'on puisse dire c'est que les développeurs semblent très bien organisés et méthodiques.
    J'ai vraiment hâte que ce projet avance un peu pour voir ce que donne le noyau Gnu Mach en terme de performances.
    • [^] # Re: La "Task List " est plustôt impressionnante

      Posté par . Évalué à  10 .

      Je me suis intéressé dernièrement au Hurd, et contrairment à ce que tu dis, il semble que X fonctionne (je sais plus trop où je l'ai lu, qq part sur http://www.gnu.org/software/hurd/(...)). Par contre effectivement, le support pthread n'est pas au point et donc pas question de faire tourner Gnome ou KDE. Par contre Windowmaker, fvwm ou encore Blackbox fonctionnent très bien.
    • [^] # Re: La "Task List " est plustôt impressionnante

      Posté par . Évalué à  10 .

      Si j'ai bien tout comprit, les performances ne seront pas le point fort du Hurd. (d'ailleurs ce n'est pas dans la liste d'avantage qu'il y a sur leur site : free, compatible, built to survive, scalable, extensible, stable, exists)

      En gros le but est de faire un noyau extrement modulable, avec la possibilité pour les utilisateurs de charger des "modules" (server) qui pourrons crouter sans embêter les autres.

      Ce qui parrait très sympatique par contre, c'est la mécanique de "translator" qui doit permettre de très simplement monter un site ftp sur le filesystem ou bien crypter ou compresser des fichiers à la volée.

      De la lecture sur le Hurd pour les transports en communs :
      http://www.gnu.org/software/hurd/hurd-paper.html(...)
      http://www.gnu.org/software/hurd/hurd-talk.html(...)

      (le premier m'a fait rater une gare de RER il y a deux ans vers 1h30 du matin. Resultat : 2 heures d'attente dehors en hivers avant d'en avoir un autre dans l'autre sens. Heureusement que j'avais de la lecture)
    • [^] # Re: La "Task List " est plustôt impressionnante

      Posté par . Évalué à  9 .

      Effectivement, j'ai l'impression que Hurd, c'est un noyau pas fini et des translators*... c'est tout ?

      Ce qui m'étonne, c'est que des distrib comme mkLinux étaient basées sur un noyau Mach, mais bon c'était un noyau mach qui ne lance qu'un seul serveur : un noyau linux... mais MacOS-X lui-même n'est t'il pas basé sur un noyau Mach ? J'aimerais savoir : comment se fait t'il qu'il soit si peu avancé ? (le noyau Mach, pas MacOSX...)

      Sinon, pour ceux qui veulent tester, les packages Debian sont juste à recompiler : apt-get source -b <pkg> à la place de apt-get install <pkg>.



      *Translator : (fr. traducteur) un daemon qui permet d'avoir un interface type file-system est un translator. Les translators permettent d'accéder aux partitions, CD, nfs et meme de transformer une connexion ftp en partition locale, par exemple.
      • [^] # Re: La "Task List " est plustôt impressionnante

        Posté par . Évalué à  7 .

        Il n'y a pas un noyau Mach, mais tout plein.

        The Hurd est passé sur un noyau GNUMach qui n'est pas forcement au même état d'avancement que ceux de MacOSX ou mkLinux.
        • [^] # Re: La "Task List " est plustôt impressionnante

          Posté par . Évalué à  10 .

          ok, je comprend mieux... je ne pensait pas qu'ils avaient refait leur implémentation Mach. Ca fait assez longtemps qu'ils sont dessus, quand meme.

          Hurd m'intrigue... j'ai l'impression que c'est un fantasme d'ingénieurs informaticiens (interdiction de rire, le terme à été pourri il y a peu) : Hurd propose une plateforme qui ne reboote jamais...un micronoyau ne s'occupant pas de grand chose, seuls les services sont à gerer ?

          Si Hurd arrive à ses fins, il fera plus mal aux Unix que linux, mais bon ca sera d'ici 4 à 6 ans, le temps qu'il soit terminé, stabilisé, emancipé et surtout promu.
          --
          Vivement demain !
          • [^] # Re: La "Task List " est plustôt impressionnante

            Posté par . Évalué à  9 .

            Si je ne me trompe pas le hurd tourne sous 2 micro kernel gnu mach et os-kit mach. Le second étant une implémentation de mach avec os-kit ( cf http://www.cs.utah.edu/flux/oskit/(...) ). gnumach doit fonctionner avec les drivers linux 2.0.x os-kit driver linux 2.2.x.
            Des personnes veulent aussi porter le hurd sur L4 ( cf http://mail.gnu.org/mailman/listinfo/l4-hurd(...) et http://www.l4ka.org/(...) ).
            Le noyau L4 aurait pour avantage d'être plus activement développer que mach. Et L4 est déjà porté sur plusieurs plateformes.
            • [^] # Re: La "Task List " est plustôt impressionnante

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

              Bon on vas clarifier un les choses,

              il y a un projet, ou plutot une idee de porte Hurd sur d'autre micro noyaux et en particulier L4.

              Mais Hurd a ete depuis le debut developper pour Mach, il n'est pas vraiment portable.

              GNUmach, c'est Mach 4 du CMU (en gros) adopté par le projet GNU.
              Le probleme de GNUmach c'est qu'il est out of date
              depuis le debut. Il est uniquement utilisable sur plateforme x86 (bien que le noyau Mach original a été porté sur la pluparts des architectures). Il ne supporte quasiment aucun materiel recent
              (bien qu'une implementation de GNUmach utilisant
              l'oskit existe, ce n'est pas encore la panacé mais c'est une voie a suivre),
              et ce qui me parait le plus grave pour un
              micro noyau (pour ma definition personnelle, et je ne parle pas de sa taille mais des fonctionnalités) c'est qu'il embarque en dur tout
              ses drivers, pas de kernel module, ni la possibilité d'avoir des drivers tournant comme une tache en mode pseudo utilisateur (comme les autres serveurs de Hurd).

              Le principe du micro noyau est excellent (quoiqu'en pense Linus), associé au principe du multi serveurs (comme Hurd, pas comme les systemes qui utilisaient un unique serveur emulateur d'unix), ca me parait etre la solution la plus pertinente, souple, fiable, etc..., mais cette solution demande beaucoup de reflexion et une rigueur extreme.

              Le seul projet presque de ce type est a ma connaissance Amoeba.

              Si avec les ISOs de la Debian Hurd, le systeme GNU
              peut gagner plus de developpeur ce seras parfait
              mais il ne faut pas que ca devienne l'anarchie comme Linux ...
              • [^] # Re: La "Task List " est plustôt impressionnante

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

                _quoiqu'en pense Linus_

                AMHA aussi d'ailleurs, toutes c'est figures de style bouffe BEAUCOUP de CPU, c'est un peu le probleme. Mon noyeau j'aime k'il bosse, pas k'il fasse de politesse...
                Je me trompe probablement mais perdre tout ce temps, pour les quelques fonctionnalite apportees c'est vraiment cher paye le mount -t FTP...

                _mais il ne faut pas que ca devienne l'anarchie comme Linux_

                peut tu detailler ce point parce que la, je ne te suis pas (sans mechancete aucune)
                • [^] # Re: La "Task List " est plustôt impressionnante

                  Posté par . Évalué à  2 .

                  pour le mount -t ftp , il y a un projet sur linux.
                  Il me semble que c'est http://sourceforge.net/projects/ftpfs/(...)

                  ca permet de faire un
                  $ mount -t ftpfs ...
                • [^] # Re: La "Task List " est plustôt impressionnante

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

                  Quand je parle d'anarchie, je parle du manque
                  de continuité, de stabilité dans le developpement:
                  o changements d'api,
                  o tout les drivers integré dans la meme arboresence
                  o les differentes branches

                  Au niveau performance, c'est sur que l'on peu se poser des questions,
                  voici encore la mon point de vue:
                  - un kernel monolithique super optimiseé (voire meme ecrit en assembleur ;)
                  Il sera forcement rapide (le code), mais pas gerable a long terme, presque immodifiable
                  et a terme les performances seront diminué car
                  le systeme deviendra un gros melange de tache intercroise pour pouvoir assuer toutes les nouvelles fonction.

                  - micro noyau et des serveurs: lenteur du a la commutation des taches, mais les elements sont
                  mieux concus, mieux reparti, le systeme peut etre plus scalable. Il sera plus facilement evolutif
                  et meme plus simple a comprendre

                  De plus je pense que le parametre vitesse, est un peu obsolete, compte tenu des architectures modernes.
                  • [^] # Re: La "Task List " est plustôt impressionnante

                    Posté par . Évalué à  3 .

                    (voire meme ecrit en assembleur ;)

                    Ah bah bravo la portabilité ;)

                    Bon, plus sérieusement, il y a quand même un avantage non négligeable au micro-noyau, c'est qu'on peut remplacer à chaud les serveurs qui tournent dessus. Ce qui fait qu'on peut patcher un OS sans avoir à rebooter... (tant que ce n'est pas le micro-noyau qu'il faut patcher)
                    Sur des gros serveurs qui peuvent mettre plusieurs dizaines de minutes pour booter (si, si, ça existe), ça peut être très pratique...
                  • [^] # Re: La "Task List " est plustôt impressionnante

                    Posté par . Évalué à  1 .

                    Quand je parle d'anarchie, je parle du manque
                    de continuité, de stabilité dans le developpement:


                    ben ce n'est pas de l'anarchie ça, au contraire, c'est de la désorganisation...
          • [^] # Re: La "Task List " est plustôt impressionnante

            Posté par . Évalué à  1 .

            j'ai l'impression que c'est un fantasme d'ingénieurs informaticiens
            Non, plutôt orienté recherche universitaire.
        • [^] # Re: La "Task List " est plustôt impressionnante

          Posté par . Évalué à  1 .

          On dirait que c'est surtout les serveurs et les libs qui sont pas trop finis.
          En gros (simplifions, simplifions, ...) MkLinux avait un seul serveur qui émulait un linux. MacOS X a un seul serveur qui émule un FreeBSD. Et Hurd a tout plein de serveurs qui font , euh, tient ça se complique là, je crois que je vais aller relire la doc...
  • # Une FAQ sur Hurd en fr

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

    Voici une petite faq en français sur Hurd pour savoir de quoi il retourne exactement...
    http://www.multimania.com/nek/os/hurd.htm(...)

    -1 parce que ca fait pas avancer le schmilblik :)
    • [^] # Re: Une FAQ sur Hurd en fr

      Posté par . Évalué à  10 .

      Pour une doc sur le HURD en francais on peut voir aussi :
      http://www.hurd-fr.org/docfr.php(...)
    • [^] # Re: Une FAQ sur Hurd en fr

      Posté par . Évalué à  3 .

      "ca fait pas avancer le schmilblik"
      Non, au contraire la page est très instructive.

      La section 4 (le net est à vous) laisse rêveur :
      "Les noeuds du reseau apparaissent comme des sous-repertoires dans votre arborescence..."
      "Vous savez creer un lien sur un fichier? Vous pouvez creer de la meme maniere un lien sur le serveur du Centre National de Mycologie Appliquee du Djibouti."
    • [^] # Re: Une FAQ sur Hurd en fr

      Posté par . Évalué à  6 .

      Lu sur cette FAQ: "En gros, c'est l'Emacs des systemes d'exploitation."

      Vous avez frissoné en regardant Emacs, vous trrrremblerrrez en essayant Stallman II, le Retour (dit The Hurd)

      Euh, le vi des systèmes d'exploitation c'est quoi ?

      (oui bon ok, -1)
      • [^] # Re: Une FAQ sur Hurd en fr

        Posté par . Évalué à  -9 .

        Euh, le vi des systèmes d'exploitation c'est quoi ?

        C'est DOS ?
      • [^] # Re: Une FAQ sur Hurd en fr

        Posté par . Évalué à  -5 .

        >Vous avez frissoné en regardant Emacs, vous trrrremblerrrez en essayant Stallman II, le Retour (dit The Hurd)

        Tous à vos GNU, ca va guilder grave !
  • # C'EST PAS LA MANDRAKE

    Posté par . Évalué à  -10 .

    premiere distrib en 18 ans
    alors que notre distrib nationale, c 18 distribs en un an
  • # Et sinon?

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

    Moi j'aimerais bien savoir sur quel genre de matos on peut l'installer ?
    J'ai un 486 avec 200Mo de dd (ram ?, cpu ? ), est ce que ça passe?
    Parce que c'est bien beau de vouloir le faire tester, mais a la fin je suis en panne de machines moi.
    • [^] # Re: Et sinon?

      Posté par . Évalué à  -6 .

      En dessous du descriptif de la news, il y a des liens.
      • [^] # Re: Et sinon?

        Posté par . Évalué à  -2 .

        bah y a pas grand chose sur la conf minimale requise.
    • [^] # Re: Et sinon?

      Posté par . Évalué à  -1 .

      merde, pas de lecteur cdrom sur cette machine -> Hurd c'est pour plus tard
    • [^] # Re: Et sinon?

      Posté par (page perso) . Évalué à  -3 .

      et sinon, je peux repasser le prendre vers quelle heure ?
    • [^] # Re: Et sinon?

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

      Non, cf le changelog : la fpe ne fonctionne pas encore.

      Ceci-dit, ils cherchent des contributeurs pour porter celle de Linux. ;-)
  • # POO ?

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

    Y'a un truc que je ne saisie pas, HURD est Orienté Objet, et je viens de mater les sources en C.

    Le C n'est pas orienté objet ? à moins que j'ai raté une étape ?
    • [^] # Re: POO ?

      Posté par . Évalué à  10 .

      Tu peux faire de la "conception objet" dans à peu près n'importe quel langage.

      Les langages dit "objets" ou "à objets" apportent une syntaxe et des mécaniques qui favorisent la conception objet.

      Voili voilou.
    • [^] # Re: POO ?

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

      Tu n'as pas besoin d'un langage objet pour programmer en objet. Ca aide, mais c'est pas strictemement nécessaire. Quand tu compiles un programme OO en C++, ça te génère de l'ASM, qui n'est pas à proprement parler un langage objet, et pourtant ton programme est orienté objet.
      • [^] # prem's

        Posté par . Évalué à  -7 .

        Prem's.
        Nananair-heu !
      • [^] # Re: POO ?

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

        Pourrais tu me montrer un petit exemple en C ou autre, car ca m'interesse de savoir comment il font. Si j'ai bien compris, c'est eux meme qui gerent les pointeurs des fonctions herité, etc ... ?
        • [^] # Re: POO ?

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

          Pour programmer en OO en C, voici un point de départ :
          http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html(...)

          Il s'agit d'une bibliothèque qui permet de programmer OO en C.
          L'intérêt est de le faire sur des plateformes qui ne peuvent supporter un compilateur C++

          HTH
        • [^] # Re: POO ?

          Posté par . Évalué à  2 .

          Tu peux aussi regarder le code de gtk+ ( http://www.gtk.org(...) ) qui utilise son propre mécanisme objet en C.
        • [^] # Re: POO ?

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

          Regarde du coté de gtk ( http://www.gtk.org(...) ). C'est totalement objet, mais en C. Si tu veux une implémentation d'un système d'objets en C qui ne soit pas lié à un toolkit, regarde: http://developer.gnome.org/doc/API/2.0/gobject/index.html(...)

          En gros, pour l'héritage, en Gtk/GObject c'est fait ainsi:


          struct _bar_t
          {
          struct _foo_t foo;
          ...
          }


          Et tu as 'bar' qui hérite de 'foo'...
          Et après tu peux utiliser les fonctions de plus bas niveau (par exemple en Gtk tu peux faire un
          gtk_widget_show() sur tous les widget, que ce soit un GtkButton ou un GtkFileSelectionDialog)
          • [^] # Re: POO ?

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

            Pour compléter un peu l'explication de Kilobug:

            Bien evidemment, il faut faire du forcage de type quand tu appelle les functions s'appliquant à _foo_t avec _bar_t. Et en cas d'héritage multiple, tu n'as pas d'autre choix que de faire un peu d'arithmétique de pointeur... Mais ça marche très bien. A moins que quelqu'un ne connaisse une autre solution?
          • [^] # Re: POO ?

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

            Si j'ai bien compris, tu aura ceci.

            struct Object2
            {
            struct Object1 // qui lui meme contient ObjectAbstract ?;
            ...
            }

            et

            struct Object1
            {
            struct ObjectAbstract;
            ...
            }

            Ca veux donc dire que les structures peuvent avoir des fonctions ou procedures (Méthode) ? Si ce le cas, je ne le savais pas, d'autant plus qu'en C++ il conseille d'utiliser des Classes (Object) par raport aux structures.

            Et par exemple si ObjectAbstract à une procedure (méthode) "Run", comment tu l'appelle depuis Object1 ?
            • [^] # Re: POO ?

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

              C'est relativement simple. Object1 est le premier élément de Object2, et ObjectAbstract le premier élément de Object1. Ce qui veut dire qu'en mémoire, si tu prends un pointeur vers un Object1 ou un Object2, il pointera vers les données de l'ObjectAbstract.
              En ce qui concerne les classes, elles n'existent bien sûr pas en C, mais on peut facilement contourner le problème. En fait ce qui suit n'est que la manière donc le code C++ est interprété par le compilateur.

              Disons que tu as une classe A (de mercedes):
              class A
              {
              public:
              A();
              ~A();
              Run (int n);

              private:
              int i;
              };
              Comment le compilo peut-il traduire cela en C? Tout d'abord on regroupe les données de la classe en une struct (dont le données privées ne sont bien sûr pas accessible, mais ça en C c'est dur à controller):

              struct A_struct
              {
              int i;
              }
              Et ensuite on écrit l'interface de la classe avec des fonctions C, dont le premier paramètre sera TOUJOURS un pointeur vers la structure dont elles sont l'interface:

              /* constructeur et destructeur */
              void A_init (struct A_struct * a);
              void A_cleanup (struct A_struct * a);
              /* Méthodes */
              void A_Run (struct A_struct * a, int n);
              Evidemment tu dois toi même appeler le constructeur et destructeur manuellement, et toujours passer ta structure aux méthodes de l'interface. Mais j'insiste sur le fait que c'est ainsi que cela se passe en interne. Si tu lances gdb sur un programme C++, tu verras que ça se passe en fait comme cela.

              Ensuite, l'héritage... Soit la classe B:
              class B : public A
              {
              ....
              };

              En C on traduira comme Kilobug l'a dit par:
              struct B
              {
              struct A struct_a;
              }
              Et comme les données en mémoire au début du pointeur de B sont les données de A (car elle a été déclarée au début de B), tu peux appeler A_Run comme ceci:

              struct B monB;

              A_Run ((A*)&monB, 2);

              En faisant un simple forcage de type. Pour l'héritage multiple, comme je l'ai dit plus haut tu peux t'en sortir avec un peu d'arithmétique de pointeurs. C'est bien sûr moins pratique qu'un compilo C++ qui fera le boulot à ta place, mais ca peut être grandement utile et c'est bon à savoir.

              Voila, j'espère avoir été clair :)
              • [^] # Re: POO ?

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

                >> struct B monB;
                >>A_Run ((A*)&monB, 2);

                Pas mal cette finte, d'utiliser le meme emplacement pour les pointeurs, ca ressemble un peux au UNION en C++, je supose que c'est ca qu'il utilise d'ailleur.

                gnurou, merci pour ton exemple, il me permet de mieux comprendre.
            • [^] # Re: POO ?

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

              tu utilises des pointeurs de fonctions.
              et il n'y a pas de différence fondamentale entre object et struct, ce n'est qu'une différence de protection par défaut des proprietes et methodes.
              • [^] # Re: POO ?

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

                Tu peux utiliser des pointeurs de fonction pour émuler les méthodes, mais ça a le gros désavantage de te bouffer 4 octets (sur une machine 32 bits) par méthode que tu as déclaré dans ta classe pour chaque objet alloué, et surtout ce n'espt pas la manière de faire du C++ en interne, l'astuce consistant, comme je l'ai décrit plus haut, à faire passer un pointeur vers la structure en premier paramètre (caché, mais visible avec un débugger par exemple) aux méthodes de l'interface.
                • [^] # Re: POO ?

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

                  L'utilisation des pointeurs de fonctions est nécessaire pour émuler les méthodes "virtuelles" du C++. Les compilo C++ en utilisent aussi. Sinon, comment fait-il lorsqu'il ne peut pas connaitre le type à l'exécution?

                  Si je définis une méthode foo virtuelle dans la classe a, et deux méthodes réelles différentes dans les classes b et c (héritant toutes les deux de a) et une fonction du type:

                  void bar(class_a *a)
                  {
                  a->foo();
                  }

                  Le compilo est bien obligé d'avoir des pointers de fonctions pour savoir quelle méthode appeler.

                  Il y a aussi une autre solution (utilisée dans GObject je crois) qui consiste a avoir une structure 'classe' contenant les pointeurs de fonctions, de l'instancier une fois lors de la création du premier objet d'un type donné. On a ainsi un pointeur vers la classe (donc 4 octets) par objet et non par coupe (méthode, objet).

                  Cependant, il faut voir que le principal problème des pointeurs de fonctions n'est pas les 4 octets de mémoire, mais le coût CPU. En effet, pour la plupart des processeurs, un 'indirect call' (appel à un pointeur de fonction) est beaucoup plus lent qu'un 'call' avec une adresse constant.
                  • [^] # Re: POO ?

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

                    Peu de compilateurs se servent de pointeurs de fonction dans les objets eux mêmes. Le mécanisme le plus utilisé est celui de la vtable, qui est une table contenant les pointeurs des fonctions virtuelles pour chaque CLASSE (et non objet). Pour les détails, voir l'excellent livre de Bruce Eckel "Thinking in C++" qui est disponible gratuitement en ligne, une vraie bible. En revanche, faire une implémentation du type vtable en C est relativement embêtant, étant donné que les appels de fonction virtuelles sont alors "spéciaux" et qu'il faut les gérer manuellement... On retrouve le même problème avec les pointeurs de fonction (amoindri certes) puisqu'il faut l'assigner manuellement... Enfin bref dans tous les cas c'est un beau bordel quand même, et quand on en vient à utiliser ces fonctionnalités (corrigez moi si je dis des conneries mais il me semble que les fonctions virtuelles ne sont pas spécifiquement de la POO) il vaut mieux changer pour un compilo C++ :)

                    Pour les appels à des pointeurs de fonction, je ne pense pas qu'il y ait le moindre surcoût. Après tout en assembleur x86, les fonctions sont appelés par leur adresse, non? Il ne s'agirait donc que du mécanisme naturel.

                    Ca devient Da Programmers French Page ici... ;)
                    • [^] # Re: POO ?

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

                      * Pour les vtable et le fait que les pointers sont mémorisés par classe et non par objets, j'en ai parlé. Ce n'est ni compliqué, ni embètant de gérer tout ça en C, et ça évite d'avoir la lourdeur et les problèmes du C++ (comme la non-compatibilité entre les libs compilées avec g++ 3.0 et celles compilées 2.95)

                      * Pour les pointers de fonctions, si c'est beaucoup plus coûteux parce que les plupart des processeurs n'arrivent pas à prédire le branchement si l'adresse n'est pas constante, et donc il fait une 'misprediction' qui se solde par un flush du pipeline et un risque de cache-miss... Et tout ça ça coûte TRES cher en terme de perf.
                      Maintenant je n'ai plus fait d'assembleurs depuis les PII/K6 et donc je ne sais pas trop comment se comportent les processeurs + récents.
                      • [^] # Re: POO ?

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

                        Uhhh exact pour les pointeurs de fonctions. Je n'avais pas pensé au pipeline.

                        Pour le système de vtable en C, tu t'y prendrait comment? Ne faudrait-il pas rajouter des macros plein le code pour déterminer si une fonction est virtuelle ou non? Car comme durant la compilation le compilo C++ examine chaque appel de fonction pour savoir s'il doit être virtuel ou pas, il faut mettre un système similaire en place, et je ne vois pas trop comment faire sans noyauter chaque appel de fonction d'un objet avec une macro. Non pas que ce soit inefficace ou très lourd, mais je suis curieux de savoir s'il y a moyen de faire autrement.
                      • [^] # Re: POO ?

                        Posté par . Évalué à  2 .

                        Les processeur récents ont des pipelines plus longs (le ponpon, c'est le P4 et son pipeline à 20 étages) donc ça doit sans doute couter de plus en plus de cycles...
    • [^] # Re: POO ?

      Posté par . Évalué à  4 .

      Ce qui fait qu'un programme est orienté objet c'est la conception et pas le langage, je me souviens avoir fait un petit programme "oriente objet" avec turbo pascal 4 qui n'etait pas du tout objet
    • [^] # Re: POO ?

      Posté par . Évalué à  3 .

      De façon générale, un système orienté objet n'est pas obligatoirement codé avec un language que supporte l'objet.

      Il suffit de consulte la librarie Xt d'X11 pour en être persuadé.
    • [^] # Re: POO ?

      Posté par . Évalué à  2 .

      On peut faire de l'objet dans pratiquement tout les langages. La question est : quel est l'intérêt ?
      Personnellement, il me semble que le choix d'un langage comme le C++ ou le Java serait plus adapté pour faire de la POO. Qui essaierait de faire du café avec une machine à laver ? Pour moi c'est un peu l'équivalent de faire de l'objet en C.
      Je ne comprend pas l'acharnement de certain à utiliser le C coute que coute. Chaque langage a ses spécifictés, ses avantages, ses domaines de prédilection autant les utiliser.
      Faire du calcul mathématique en POO n'est, par exemple, pas une super bonne idée. A titre d'exemple je rapporte une discussion entre 2 objets.

      Dialogue entre l'objet "2" et l'objet "3" :

      2> Salut 3 tu veux t'additionner avec moi ?
      3> wi pourquoi pas
      2> ok on y va
      3> oula attends ... c'est quoi pour toi l'addition ?
      ...


      Pas très efficace. Maintenant, je suppose qu'il y'a une raison au niveau du choix du C comme langage pour Hurd. Moi je la connais pas mais quelqu'un pourrait m'éclairer :-)
      • [^] # Re: POO ?

        Posté par . Évalué à  1 .

        deja pas mal de personnes ont appris le C et n'ont pas envie de passer au C++ (y'en a qui codent encore en fortran)

        enfin, surtout, le C est plus 'universel'. tu vas toujours tomber sur un compilateur C++ qui ne va pas supporter les namespace/template/RTTI, etc...
        • [^] # Re: POO ?

          Posté par . Évalué à  1 .

          >deja pas mal de personnes ont appris le C et n'ont pas envie de passer au C++ (y'en a qui codent encore en fortran)

          Ca fait toujours plaisir de voir les gens qui melangent les torchons et les serviettes. Le Fortran est un langage pour faire de l'analyse numerique, et non pas pour ecrire un systeme d'exploitation.
      • [^] # Re: POO ?

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

        l'interet, c'est que tu peux utiliser le style et les methodes objets quand cela t'apporte quelque chose au niveau des algo ou de la simplicite de programmation, mais que quand tu veux optimiser, tu obtiens des perf correctes bien plus facilement (à ce sujet il y avait un article edifiant dans le dernier ou avant dernier LMF) ; et effectivement la portabilite joue.
  • # HURD, successeur de linux?

    Posté par . Évalué à  9 .

    L'architecture du HURD a été etudiée pour étre trés facilement évolutive, donc s'il faut changer tel ou tel partie du systéme la tache sera grave plus facile qu'avec un noyau monolithique.
    Dans 6/8 ans, hurd remplacera peut étre linux...
    • [^] # Re: HURD, successeur de linux?

      Posté par . Évalué à  2 .

      arrête ta psychohistoire Seldon...

      La Fondation serait en marche ? :)

      -1
      • [^] # Re: HURD, successeur de linux?

        Posté par . Évalué à  5 .

        La Fondation serait en marche ? :)

        Comme Seldon, RMS va réduire la période de développement de Hurd de 30000 ans à seulement 1000 ans.
        • [^] # Re: HURD, successeur de linux?

          Posté par . Évalué à  0 .

          Dans 6/8 linux sera mort aussi.
          Hurd, mais quelle arlésienne ! Hm depuis quand deja que ca frémit dans la soupière ? 8 ans ?

          1000 ans c'est optimiste :)
  • # La G1 n'est pas la premiere...

    Posté par . Évalué à  5 .

    Petite rectification : la G1 n'est pas la<<premiere>> distribution de Debian/Hurd, loin de la.
    Les CDs de la serie F permettaient aussi d'installer Hurd et de l'utiliser. Et je n'ai pas vu d'annonce sur un changement si significatif entre la serie F et la serie G (me trompe-je ?) -

    Ronan
    • [^] # Re: La G1 n'est pas la premiere...

      Posté par . Évalué à  0 .

      D'ailleurs l'install se faisait avec des disquettes Debian GNU/Linux modifiées. Il fallait donc booter un linux pour installer Hurd :o)
    • [^] # Re: La G1 n'est pas la premiere...

      Posté par . Évalué à  4 .

      C'est la première de la série G, considérée accessible. Elle n'est pas seulement destinée aux développeurs Hurd et passionnés d'OS, mais accessible aux utilisateurs de Linux qui s'y connaissent un minimum.
      Ca reste du développement, donc la première sera la 1.0, mais celle-ci est la première à "sortir" du cercle des développeurs et passionnés.
  • # Hurd

    Posté par . Évalué à  -1 .

    yeaaaaaaaaaaaaaaah Debian et Hurd roulaize a donf !!!!

Suivre le flux des commentaires

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