Journal Traducteurs : LeHurd vs Linux !

Posté par (page perso) .
Tags : aucun
1
17
avr.
2005
Bonjour,

En lisant l'article sur Hurd dans le dernier GNU/Linux Mag, je suis tombé sur un truc du tonnerre : Les traducteurs ! Pour ceux qui, comme moi il y a peu, ne connaissent pas, je vais tenter de résumer.
Avec le Hurd, un traducteur est un process qui s'intercale entre l'utilisateur et "un fichier". C'est à dire que lorsqu'on va accéder à ce fichier (read(), cat ...) on aura en fait les entrées/sorties du process. Et cela fonctionne pour tout fichier : un point de montage, un periph (/dev/...) ou un simple fichier texte et en plus en espace utilisateur.
Pour des explications plus claires, je vous renvoie la : [1]

Il se trouve que c'est LA solution à un problème que j'ai récemment rencontré.
[mavie]
Je voulais avoir une playlist avec les dernières vidéos du vrai journal de C+, bien sur actualisée chaque semaine. En plus je ne voulais ni cron ni démon car c'est sur une box de salon.
[/mavie]
J'ai résolu ce problème avec un script cgi sur le serveur d'une autre machine.
J'avais aussi envisagé un tube nommé alimenté par un démon.

D'ou ma question : comment implémenter un tel mécanisme sous GNU/Linux ? Suis-je passé à coté de quelque chose ou est-ce un gros avantage de Hurd ?

[1] http://www.hurdfr.org/index.php?page=pages/doc/traducteur(...)
  • # PS

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

    [message certifié sans troll]

    ... non je n'installerai pas Hurd même si c'est sans doute très enrichissant.
    D'une part ma carte sat. n'est pas supportée et en plus je ne veux pas casser ma box de salon !
    Tant que ca marche ...
  • # FUSE

    Posté par . Évalué à 10.

    > Suis-je passé à coté de quelque chose

    Oui :
    Filesystem in Userspace
    http://fuse.sourceforge.net/(...)
    • [^] # Re: FUSE

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

      Super, c'est exactement ca !
      En plus y'a même un binding perl http://search.cpan.org/~dpavlin/Fuse-0.05/Fuse.pm(...) (et Python aussi)
      Merci, je plussoie dans la joie !
    • [^] # Re: FUSE

      Posté par . Évalué à 10.

      FUSE est intéressant, mais n'est pas vraiment équivalent aux translators (j'aime pas trop traduire les termes techniques précis) du Hurd.

      D'une part, il y a beaucoup de problèmes quant à la sémantique que tu obtiens avec FUSE par rapport aux permissions (voir le thread suivant de la LKML: http://thread.gmane.org/gmane.linux.kernel/295707(...) )

      Ensuite, les performances ne suivent pas du tout avec FUSE, parce que c'est un hack assez intelligent autour du noyau, mais que ça reste un hack. Le noyau n'étant pas conçu dans ses principes même pour faire ça, le coup en terme de performances est assez prohibitif.

      Un autre problème est une question de sécurité/stabilité: rajouter FUSE, c'est rajouter un module qui tourne en espace noyau, module faisant un tas d'interactions complexes avec l'espace utilisateur, et donc étant sujet à bug(s). Si ton FUSE crash, ton noyau est par terre. Si une personne trouve une faille de sécurité dans FUSE, pouf il a un exploit local (et même peut-être distant) pour faire tout ce qu'il veux.

      Ca fait un bout de temps qu'on peut voir sur Internet FUSE cité comme un exemple de "le Hurd ça sert à rien, on peut déjà tout faire sous Linux". Mais c'est pas vraiment la même chose. Les translators font parti de la base même du fonctionnement de Hurd, avec tout ce que ça apporte comme avantages en terme de performances, de scalabilité (un mot meilleur ?), de sécurité, ... FUSE offre un équivalent en terme de fonctionnalités pures, mais pas avec la même facilité/élégance. On pourrait dire que comparer FUSE aux translators du Hurd en les présentant comme équivalents, c'est comme utiliser Cygwin pour dire "Linux, ça sert à rien, on peut faire tourner ce qu'on veut comme programme UNIX sous Windows". Dans un cas comme dans l'autre, les fonctionnalités sont les mêmes, mais pas avec le même confort.

      Cela dit, 'me faites pas dire ce que j'ai pas dit: j'ai pas affirmé que le Hurd était utilisable, génial, révolutionnaire, ou quoi que ce soit. (c'qu'il faut pas faire pour couper l'herbe sous le pied des trolls :))
      • [^] # Re: FUSE

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

        > scalabilité (un mot meilleur ?)

        "Passage à l'échelle".
        • [^] # Re: FUSE

          Posté par . Évalué à 5.

          Ne dit-on pas plutôt montée en charge ?
          • [^] # Re: FUSE

            Posté par . Évalué à 1.

            La montée en charge, c'est plutôt l'augmentation des volumes traités. La "scalabilité", ça peut aussi concerner l'extension des possibilités fonctionnelles.

            Cela étant dit, je n'ai pas de meilleur mot...
      • [^] # Re: FUSE

        Posté par . Évalué à 3.

        Au passage j'ai eu l'occasion de jouer avec et j'ai pas trouve l'api vraiement genial :
        - pas de methode seek, tout passe par un read, du coup si on veut faire un truc un peu optimiser (c'est deja assez lent comme ca), une des premiere chose qu'on fait dans le read c'est de regarder si on a fait un seek
        - pas moyen de preciser forcer un blocksize pour l'ecriture/lecture. Du coup on doit passer par des buffers intermediares/se prendre la tete qd on commence/fini au milieu d'un block
        - pas de reel gestion de cache : par default fuse lit par page, du coup on lit beaucoup, on attend que le buffer se vide, on relit beaucoup, ce qui peut parfois entraine des delai lors de la lecture sur des medias lent.

        Je dis pas que soit doit forcement etre implementer dans le noyau, mais au moins la lib fuse pourrait proposer des solutions generiques pour eviter d'avoir a coder plus de glue generique que le reste...
    • [^] # Re: FUSE

      Posté par . Évalué à 2.

      Je vais te donner un exemple réel d'usage de fuse où je me suis mordu les doigts :
      j'écrivais pour voir un peu les capacités de fuse en python une tentative de FS lié à une base de données sqlite.
      Connement j'ai fait une faute de frappe dans une requête sql... => exception déclenchée non capturée
      Pour remonter mon système de fichier, la seule solution a été le redémarrage !
      Donc oui fuse c'est bien, mais c'est très contraignant, t'as pas droit à l'erreur sinon reboot ! Donc le top pour faire un fs avec fuse c'est encore de tester dans un UML ou autre pseudo émulateur ... vive la légèreté !

      (Note : je sais que c'est ma faute pour l'exception non capturée, j'aurais du faire gaffe)
      • [^] # Re: FUSE

        Posté par . Évalué à 1.

        Je n'ai jamais utilisé FUSE.
        T'as peut-être un problème de mise au point de FUSE (qui est récent).
        Je ne vois pas pourquoi si FUSE est au point, il nécessiterait un reboot en cas de problème.
        • [^] # Re: FUSE

          Posté par . Évalué à 2.

          J'utilisais pourtant la version 2.2 de fuse, et la dernière version de fuse-python !
          Néanmoins, mon exemple montre tout de même que fuse reste un mix kernel / user space, alors que les translators ont l'avantage d'être 100% user space.
          Quoiqu'ils fassent, fuse ne pourra pas atteindre les capacités des translators, à moins que linux ne devienne un micro-noyau, ce qui me paraît franchement impossible
          • [^] # Re: FUSE

            Posté par . Évalué à 1.

            > J'utilisais pourtant la version 2.2 de fuse, et la dernière version de fuse-python !

            Je ne mets pas en cause la véracité de ton "témoinage. Mais FUSE n'est toujours pas en upstream par exemple.

            > alors que les translators ont l'avantage d'être 100% user space.

            Là, tu rèves. Si ne n'était que du user space alors il pourrait aussi toujours sous Linux. Non ?
            Hurd (le noyau) fournit un support pour les translators. Ce support fontionne en mode noyau. C'est obligé.
            • [^] # Re: FUSE

              Posté par . Évalué à 2.

              Là, tu rèves. Si ne n'était que du user space alors il pourrait aussi toujours sous Linux. Non ?
              Hurd (le noyau) fournit un support pour les translators. Ce support fontionne en mode noyau. C'est obligé.

              Non, sous linux il y a dans le noyau la bête noire des mecs de Reiser4 : la VFS, qui les empêche d'avoir 10000 trucs super classes dans leur reiser4...
              Pour les translateurs, dans Hurd à base de GNU Mach, y'a une partie kernel space apparemment... mea culpa
              Par contre pour le futur Hurd/L4, vu que même les drivers seront en user space, je pense que tout sera en user space !

              Enfin je connais trop peu hurd, je ne m'aventurerai pas dans des domaines que je connais mal... Si manuel passe, il pourrait te l'expliquer très bien
              • [^] # Re: FUSE

                Posté par . Évalué à 1.

                T'auras beau faire, tout appel système passe par le noyau. Donc pour avoir un appel système qui tire profit des caractéristiques de reiser 4, il faut une partie noyau équivalente. C'est O-BLI-GA-TOI-RE.
                Sinon, c'est un exemple parmis d'autre, ça veut dire que le noyau ne fait plus les contrôles de sécurité et que n'importe quel programme utilisateur peut faire les contrôles de sécurité.
                Ça te plais comme type de fonctionnement ?
                Pas moi.

Suivre le flux des commentaires

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