Un ORB dans le noyau Linux !

Posté par  . Édité par Benoît Sibaud. Modéré par I P.
Étiquettes :
0
10
déc.
2000
Noyau
Une bande de fous furieux a réussi à intégrer ORBit (l'ORB de GNOME) dans le noyau ! Après le serveur HTTP, on a donc un nouveau joujou pour prendre de la place dans la RAM ; les auteurs y voient des possibilités impressionnantes comme, je cite, « écrire des pilotes en Perl, et les faire tourner sur l'iMac à l'autre bout de la salle » ou, plus sérieusement, implémenter des systèmes de fichiers distants comme des objets CORBA (des fois que vous en ayez marre de NFS) ; mais jusqu'où iront-ils ? ! ?

Aller plus loin

  • # Where to you want to go today ?

    Posté par  . Évalué à 1.

    Vivement kXfree86 .

    • [^] # Re: Where to you want to go today ?

      Posté par  . Évalué à 0.

      Ca s'appele pas windows ça ?

      Shift (non logué car test mozilla)

    • [^] # Re: Where to you want to go today ?

      Posté par  . Évalué à 0.

      a vrai dire xfree86 tourne en root, donc il est déja plus ou moins dans le noyau (et encore plus avec les modules agp ;)

      • [^] # Re: Where to you want to go today ?

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

        Justement XFree 4 est censé renverser la tendance en ne lançant plus que le driver en root, non ?

      • [^] # Re: Where to you want to go today ?

        Posté par  . Évalué à 1.

        L'intéret d'avoir un module noyau, c'est justement d'avoir un device sur lequel on peut mettre les bonnes permissions pour ne plus avoir à tourner en root. Un driver bien écrit protège le système des programmes bogués qui s'en servent, donc c'est nettement plus sur comme ça. Le seul danger, c'est effectivement d'aboutir à un noyau énorme...

    • [^] # Re: Where to you want to go today ?

      Posté par  . Évalué à 1.

      En fait c'est pas si con que ça: l'integration de l'inteface graphique au kernel permettrait d'obtenir un gain de performance pour une perte de fiabilité negligeable, vu que de toute façon l'utilisateur de base éteint et rallume sa machine au moindre problème :-)

      • [^] # Re: Where to you want to go today ?

        Posté par  . Évalué à 0.

        l'ORB (sujet de cette nouvelle) n'a rien a voir avec une interface graphique. C'est plus un middleware ou un "bus". Gnome l'utilise pour faire communiquer ses applis entre elles, mais ce bus pourrait aussi servir a faire communiquer d'autres composants/logiciels sur la machine. En fait c'est plus un remplacant pour les IPC/sockets. un soft peut communiquer avec un autre quel que soit leurs emplacements (meme machine, machines reliées en reseau ...).
        Ca ne veut pas dire que j'approuve l'arrivée d'un ORB dans le noyau (corba est pas tout a fait mur, alors appuyer des modules kernel dessus ...)

        • [^] # Re: Where to you want to go today ?

          Posté par  . Évalué à 0.

          >remplacer les IPC/Sockets

          Qu'utilisent les Orb (en bas niveau) pour faire communiquer des machines entre-elles ?
          Ce serait-y pas toujours des sockets ?


          wadael

          • [^] # Re: Where to you want to go today ?

            Posté par  . Évalué à 1.

            Disons que Corba permet de mettre une jolie (?) robe sur les sockets. En anglais, on appelle ça "overhead".
            Je suis méchant, ça doit aussi apporter de l'abstraction qui peut simplifier le développement.
            Maintenant, l'intérêt de mettre ça dans le noyau, si ce n'est déclencher une crise d'apoplexie chez les tenants des micronoyaux (que l'on devrait appeler "pépin"), n'est pas évident.

      • [^] # Re: Where to you want to go today ?

        Posté par  . Évalué à 1.

        Les gens qui se servent de Linux pour leurs serveurs (et il existe quelques uns dans le monde;) risquent de ne pas etre d'accord.
        Implemanter l'interface graphique dans le noyau n'apporterait sans doute pas de gain de performance (sinon au niveau du context switch, peut-etre).
        Pour ce qui est de la stabilite, je ne pense pas qu'on y gagnerait grand chose (pourquoi un driver noyau serait plus stable qu'un driver XFree ?).
        Enfin, l'interface graphique n'a aucun interet pour un serveur.

        Jusqu'ici, le langage C etait fortement lie a Unix. C'est encore le langage de predilection pour communiquer avec le noyau. De nos jours, la mode est au tout objet. La ou on parlait de processus communiquant par IPC, on parle aujourd'hui de composants communiquant par CORBA.
        CORBA doit faire partie de l'OS, mais l'OS n'est pas seulement le noyau. Bravo quand meme aux gars qui ont implante l'ORB dans le noyau. Ca ouvre de nouvelles possibilites pour faire joujou avec Linux, meme si c'est pas utilisable hors du cadre ludique.

        • [^] # Re: Where to you want to go today ?

          Posté par  . Évalué à 0.

          Pour ce qui est des histoires d'interfaces graphiques inclues dans le noyau, il me semble qu'il existe au moins un projet de portage de kde sur FrameBuffer qqu'un aurait plus de niouzes sur le sujet?

      • [^] # Re: Where to you want to go today ?

        Posté par  . Évalué à 1.

        Non, l'intégration de l'interface graphique au noyau n'est pas à mon sens une bonne idée.

        Par contre, il serait bien de pouvoir intégrer la partie driver de X (pure gestion du matériel, puis la partie serveur en espace utilisateur qui va faire tampon entre les applications et le driver).

        Pendant qu'on y est, il serait interressant d'intégrer le serveur son à X (toujours avec le driver séparé du serveur et inclus dans le noyau) (c'est vrai quoi, la carte video est un périphérique tout comme le disque dur ou le modem).

        En parlant d'inclusion de drivers dans le noyau, je pense qu'il serait utile aussi d'inclure les drivers pour imprimante dans le noyau (tout en conservant le serveur le serveur d'impression en user space.

        En gros, il faudrait définitivement supprimer la gestion du materiel de l'espace utilisateur et ne plus y laisser à la rigueur que les démons et serveurs en temps que tampon entre les applications et le driver.

        Je pense que ces modifications seraient utiles pour la stabilité et la sécurité.

        Qu'en pensez-vous?

        • [^] # Re: Where to you want to go today ?

          Posté par  . Évalué à 0.

          oui ... sauf pour l'imprimante !!
          le driver imprimante est DEJA dans le noyau (EPP/ECP). Il n'y a besoin de rien d'autre ...

          • [^] # Re: Where to you want to go today ?

            Posté par  . Évalué à 1.

            Ah bon, et je fais comment pour choisir le type d'imprimante ? ;)
            Non, ce que tu dis n'est que pour la gestion du port parallèle je crois (je regarderais plus en détail ce soir pour en être sur).

        • [^] # Re: Where to you want to go today ?

          Posté par  . Évalué à 1.

          Je pense qu'une architecture telle que celle du HURD est bien plus intéressante/souple. En effet, avec ton truc, il faudrait soit compiler le noyau une fois au début avec tous les drivers (ou le + possible) en modules, et c'est pas génial dès qu'il faut installer un matériel plus récent que le noyau => recompil :(( , soit recompiler le noyau dès que l'on a besoin de qqch de nouveau => inappliquable. Le HURD (pour ne citer que lui, principalement parce que c'est le seul que je connaisse ;) se sert de "serveurs" qui s'interfacent entre le micronoyau et les logiciels. Dès que tu veux installer ton imprimante USB flambant neuve, tout ce que tu as à faire est d'installer le serveur correspondant (ceci est un exemple totalement farfelu, je n'ai pas la moindre idée de ce que le HURD supporte comme matériel). Je trouve ça infiniment plus pratique.

          • [^] # Re: Where to you want to go today ?

            Posté par  . Évalué à 1.

            Peut-être as-tu raison, je n'en sais rien car je n'ai pas essayé le HURD, mais la je parlais de linux. Lui en tout cas ne pourra pas être changé facilement en micro kernel car il n'a pas été concu pour ça.

            Et puis, recompiler le noyau n'est pas la mort pour un privé (il n'a pas beaucoup de machines en général). Pour une entreprise, ce n'est pas la même chose, mais de toute façon ils utilisent des imprimantes réseaux postscript, alors bon, il n'y a pas de problème.

  • # A quand le noyau 2.4 ?

    Posté par  . Évalué à 0.

    Linus nous avait promis le noyau 2.4 pour debut decembre 2000, nous y somme et il n'est toujours pas en vu, sauf un modeste 2.4 Test12 Pre8

    A t-on vraiment de gros probleme pour ce noyau ?

    • [^] # Re: A quand le noyau 2.4 ?

      Posté par  . Évalué à 0.

      Attends au moins le 15 (mi-decembre) ! :-)
      De toutes facons, il me semble qu'en matiere de planning, aucun logiciel n'est jamais vraiment pret comme promis a la date fixee.

      Alors quand en plus, il n'y a pas de date fixee, et que le seul declencheur de la distribution d'un noyau stable est justement sa stabilite, je pense qu'un peu de patience ne fait pas de mal.

    • [^] # Re: A quand le noyau 2.4 ?

      Posté par  . Évalué à 1.

      Il ne me semble pas que Linus ait _promis_ le 2.4 pour début décembre. Je dirais plutôt qu'il a dit qu'il essaierait de le sortir pour début décembre, histoire de pas être emmerdé avec pour la période de Noël, mais que c'était pas sûr.

    • [^] # Re: A quand le noyau 2.4 ?

      Posté par  . Évalué à 0.

      J'utilise le noyau 2.4.0-test9 depuis sa sortie
      (40 jours environ) sur mon portable du boulot (redhat 6.2) et a la maison (redhat 7.0). Les configs sont differentes (ide/scsi/pcmcia) et tout fonctionne a merveille. Le scheduleur, la vm et le driver IDE ont ete revu pour de bien meilleures performances. J'invite tout les gens pressés a faire le saut, il faut upgrader pas mal de packages sur une redhat 6.2 (la 7.0 est prete pour le 2.4.0) et ya pas mal de doc a lire dans le source du noyau. Donc autant s'y prendre a l'avance, de toutes facon maintenant ils ne font que des reglages et des corrections de bugs mineurs pour certains peripheriques. Ya de grandes chances que ces periperiques ne soient pas chez vous ...

    • [^] # Re: A quand le noyau 2.4 ?

      Posté par  . Évalué à 1.

      Linus a dit fin Décembre 2000, début 2001.
      Pas de retard...

  • # A propos d initrd

    Posté par  . Évalué à 1.

    Quelqu un sait pourquoi dans la distrib Mandrake l iniltrd a ete supprime des parametres de boot ??

    J ai des problemes sur les cartes Raid Perc2/3.
    Le plus marrant c'est que le systeme s installe
    mais au reboot, n ayant pas les modules a preloade
    celui-ci clapse @#{|}!!!

    Resultat des courses, pour installer mes Raid, je passe par le mode Rescue et un noyau de Redhat 7.0 :(

  • # Désolé

    Posté par  . Évalué à 1.

    Je fais du Corba dans le noyau avec un client en Perl.
    Ça marche bien. :-)

    --|-- Signoff Bartman (Kernel panic)

  • # Trollons un peu

    Posté par  . Évalué à 0.

    Désolé pour mon humeur trollesque du jour ;)
    voici l'email original envoyé à la mailing list du kernel:
    http://www.uwsg.indiana.edu/hypermail/linux/kernel/0012.1/0159.html(...)
    <TROLL>
    Maintenant, le plus drôle, c'est les réponses, pas des super grands noms du Kernel:

    Alex Viro:
    >Frankly, judging by the GNOME codebase people who designed the thing are culturally incompatible with UNIX.
    ou
    ><shrug> From what I've seen in GNOME it's mostly about avoiding pipes religiously and putting everything and a kitchen sink into the same process. I'm not saying that it has no valid uses, but it definitely had contributed to the bloat in case of GNOME.

    Alan Cox
    >If you needed a demonstration that Miguel does not get Unix that URL you cited is the favoured one 8)

    Okay, Kernel, ça commence avec un K (comme KDE) ;)

    </TROLL>

Suivre le flux des commentaires

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