Journal meta-tracker, le tueur de beagle ...

Posté par  (site web personnel) .
Étiquettes :
0
3
jan.
2007
Je crois pas qu'on en est parlé sur dlfp. Mais un outsider des "desktop-search" est en train de voir clairement le jour.
Bien que la mode soit aussi à la suppression des applis "mono" (cf accord novell-ms), meta-tracker affiche des performances bien meilleures que beagle, notamment sur des petites configs (c'est du C pure, avec un backend sqllite)
Il est fort probable qu'il vienne remplacer beagle dans ubuntu (gnome?). Il est freedesktop-compliant (non lié à un DM particulier). C'est en fait un framework complet, permettant d'y venir y stocker d'autres infos applicatives (certaines applis l'utilise déjà). Il existe déjà des frontend gtk et qt.

Le site officiel : http://www.gnome.org/~jamiemcc/tracker/
D'autres infos : https://wiki.ubuntu.com/Tracker?highlight=%28tracker%29
Des debs pour ubuntu/edgy : http://www.gnome.org/~jamiemcc/tracker/DEB/Edgy/
Il s'intègre très bien déjà avec nautilus, et la deskbar-applet : http://www.madman2k.net/comments/56/ (et permet même de faire la recherche dans des tags, dans l'url précédente, il y a une extension de nautilus qui permet de tagguer ses fichiers/dossiers)
Le blog du dev leader : http://jamiemcc.livejournal.com/ (où l'on apprends plein d'infos sur la genèse de tracker)

C'est à suivre

  • # pas forcement comparable

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

    meta-tracker affiche des performances bien meilleures que beagle, notamment sur des petites configs (c'est du C pure, avec un backend sqllite)
    Oué enfin faudrait comparer ce qui est comparable... meta-tracker ne gère pas la moitié des sources de données que Beagle gère, à commencer par toutes les sources de données liées aux applications (IM, mail, navigateur web, etc.).

    Bon cela dis, c'est vraiment cool d'avoir un truc freedesktop-compliant, ca me paraît tellement indispensable de ne pas être dépendant d'un environnement particulier (Gnome ou KDE) pour ce genre d'appli.

    • [^] # Re: pas forcement comparable

      Posté par  . Évalué à 3.

      Ils y pensent aussi du coté de beagle : http://mail.gnome.org/archives/dashboard-hackers/2006-Decemb(...) Je sais pas ce que ça donnera.

      J'ai vu trainé sur le site freedesktop une norme pour accéder aux "moteurs de desktop search" à travers dbus et ça me semble une meilleur idée. Ce qui compte c'est d'avoir une interface unifié plutot qu'un programme unique.

      PS : Désolé pour la norme mais j'arrive pas à accéder a freedesktop.

    • [^] # Re: pas forcement comparable

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

      > meta-tracker ne gère pas la moitié des sources de données que
      > Beagle gère, à commencer par toutes les sources de données
      > liées aux applications (IM, mail, navigateur web, etc.).

      faut pas se fier au site officiel, qui n'est pas mis à jour régulièrement !
      meta-tracker cherche déjà dans les mails par exemple (Evolution, Thunderbird and KMail ... ainsi que les dossiers génériques de mails (cf tracker.conf) )
      http://jamiemcc.livejournal.com/3782.html

      Ils developpent plus vite qu'ils ne communiquent ...

      • [^] # Re: pas forcement comparable

        Posté par  . Évalué à 10.

        Pour les mails, c'est plutôt en cours disons...

        Là, je développe justement le code pour Evolution et KMail. Jamie a balancé du code pour avoir le support des emails dans SQLite et j'ai connecté une partie de mon code dessus. Donc j'arrive à enregistrer des mails :-)

        Néanmois je ne sais pas encore quel est le format des URI servant à ouvrir un mail précis dans Evolution lors de l'utilisation de MH ou Maildir. Pour Evo toujours, je ne sais pas encore parser les fichier summary-meta qui me permettraient de trouver plus rapidement des mails... Ils servent de sommaire aux mails, mais dans un format encore plus court que celui proposé par les fichiers summary ; et c'est du binaire. Mais bon, ça avance.

        Pour Thunderbird, je dirais que j'ai envie de tuer le type qui a inventé le format des fichiers Mork... VRAIMENT.

        • [^] # Re: pas forcement comparable

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

          Pour evolution il ne vaudrait pas mieux communiquer au démon local ? il me semble que justement ils ont des API spécialement faites pour les programmes externes (dont beagle). Le but étant justement que tu ne te tapes pas les fichiers à la main (et accessoirement que tu puisses aussi indexer du distant par exemple)

          • [^] # Re: pas forcement comparable

            Posté par  . Évalué à 3.

            Si je fais dépendre le daemon trackerd à une bibliothèque GNOME, je vais me faire incendier par tous ceux qui ne veulent pas du bureau du même nom... Le daemon a vocation a rester indépendant de tout bureau, au pire, on se contente d'essayer d'appeller des exécutables spécifiques à ces bureaux et de ne rien faire s'ils ne marchent pas. De cette façon, on a une dépendance non imposée à l'utilisateur.

            Evolution utilise la bibliothèque Camel. Je n'ai pas vraiment besoin de tout ce qu'elle offre, très loin de là... Donc au final, je n'ai fait que la lire un peu et en extraire des choses à recoder. Mais la perte de temps est surtout dans le fait de chercher quelles données arrivent aux fonctions Camel ! Lorsque je vois une fonction appellée avec une variable « url » par exemple, ça veut dire pour moi que je dois me débrouiller pour savoir ce quelle contient à ce moment là et pourquoi...

            Beagle n'interroge pas evo-data-server pour les mails mais lit des fichiers summary et summary-meta (ce dernier type a d'ailleurs été ajouté dans Evo 2.8 spécifiquement pour Beagle !). Et le code pour parser ces fichiers vient tout simplement de Camel. ;-)

            • [^] # Re: pas forcement comparable

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

              Si je fais dépendre le daemon trackerd à une bibliothèque GNOME, je vais me faire incendier par tous ceux qui ne veulent pas du bureau du même nom...
              Rassure moi, y'a quand même un système de plugins, qui permette d'ajouter des modules sans se préocuper de ce genre de problème de dépendance non ? Si je veux ajouter un filtre dépendant de Qt ou GTK je peux j'espère ?

              • [^] # Re: pas forcement comparable

                Posté par  . Évalué à 2.

                Le support des emails est le daemon directement pour des raisons de perfs et de complexité... Pour le reste, trackerd ne fait qu'appeller un exécutable pour extraire des metadata.

                Ces exécutables, tu les fais dépendre sur ce que tu veux... Si trackerd ne trouve pas un exécutable, il ne sortira pas les données qu'il y avait dans le fichier associé. Beagle fonctionne de la même façon.

          • [^] # Re: pas forcement comparable

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

            le daemon local gère toutes les données d'evolution... sauf les mails. Sans doute les types d'evolution ont estimés que ces données (les mails) n'avaient pas besoin d'être partagées. Ca reste discutable mais c'est comme ca :)

        • [^] # Re: pas forcement comparable

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

          Intéressant ça. J'ai tracker 0.5.3 et on dirait qu'il n'arrive pas à indexer mes mails de KMail. Est-ce que le fait que je n'utilise que des maildir (et pas des mbox) peut en être la cause ? Quand je lance trackerd il me dit que l'indexation des mails de KMail est désactivée alors que je l'ai bien activée dans tracker.cfg.
          Je sais que c'est pas bugzilla ici, mais comme j'arrive pas à trouver sur votre site où on est censés rapporter les bugs, voilà... :)

          • [^] # Re: pas forcement comparable

            Posté par  . Évalué à 1.

            Le support des mails est, pour l'instant, partiel et désactivé directement dans le code source. Donc inutile de tenter quoique ce soit avec le fichier de configuration.

        • [^] # Re: pas forcement comparable

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

          Vous pouvez vous cotiser pour payer un tueur à gages.
          http://jwz.livejournal.com/312657.html

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Pour ma part

    Posté par  . Évalué à 4.

    J'attendais ca avec impatience, parce que un truc d'indexation/recherche ne peut pas se permettre le moindre méga octet d'extra : il est tout le temps chargé et tourne en arrière plan, et de ce fait doit être le plus léger possible.

    Sans parler du temps d'indexation des fichiers, qui est censée se faire a la volée/avec peu de délai.

    Et puis bon, je suis pas le genre a pleurer quand le vois un troll a l'agonie.

    • [^] # Re: Pour ma part

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

      pas grave, un nouveau arrive, meta-tracker Vs Strigi . Car strigi est super puissant, rapide, écrit en C++ "neutre" (ni gtk, ni qt) pour etre freedesktop-compliant ... bla bla bla

      • [^] # Re: Pour ma part

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

        oui, en surfant là dessus, suis également tombé sur strigi, et le frenchy pinot ...
        Je n'ai pas reussi à faire fonctionner pinot (un repository pour edgy : http://gauvain.tuxfamily.org/repos/ ) ... Quant à strigy ( http://www.vandenoever.info/software/strigi/ ), pour l'instant, je n'ai rien pu en faire (ça a l'air trop qt-oriented quand même)

        tracker j'ai pu l'installé, faire l'indexation (ultra rapide), l'intégrer dans nautilus, l'intégrer dans la deskbar ... en moins de temps qu'il n'en faut pour l'écrire ...

        • [^] # Re: Pour ma part

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

          Peut etre au niveau du/des front end existant, mais sinon, je crois que strigi, c'est surtout un moteur et des interfaces qui l'interrogent. Le dev principal tiens justement a cette neutralité.

          • [^] # Re: Pour ma part

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

            En effet strigi est développer en C++ de maniére trés modulaire avec plusieurs backend d'indexation disponible et utilisant dbus. Il n'y a dans le code de strigi aucune dépendance a QT. Il suffit pour l'utiliser de créer un applet qu'il soit en QT, KDE, GTK ou gnome. Par contre a ma connaissance seul les frontend kde existe.

        • [^] # Re: Pour ma part

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

          Je n'ai pas reussi à faire fonctionner pinot


          Il faut me demander gentiment.

          • [^] # Re: Pour ma part

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

            Il n'a pas pris la dernière version, tout simplement: il faut Pinot Q.
            ====> [ ]

          • [^] # Re: Pour ma part

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

            Je m'en doutais que tu devais trainer sur dlfp ...

            Mais de là à te demander directement pour mes soucis de test/fonctionnement (dans le sens je veux pas embêter)
            (j'avais le daemon qui tournait pendant 1h, mais le search-tool ne renvoyait rien)

            Par contre ton avis m'interesserait (et certainement d'autres), sur tracker/beagle/strigi/pinot ... bref, les desktop-search

            J'ai pas mal surfé là dessus hier soir ...(d'ailleurs j'ai lu qqpart que pinot était interessant, mais son plus gros reproche, c'est que personne n'arrivait à trouver l'endroit où il est développé )

            • [^] # Re: Pour ma part

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

              je viens d'installer strigi... la compil se passe plutot bien... mais l'utilisation ca galère pas mal quand meme !! 1 Go le fichier d'indexation...
              ca fait beaucoup. (j'ai 15 Go de données)

              Je vais regarder tracker pour voir.

              • [^] # Re: Pour ma part

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

                c'est surprenant. Le dev de strigi essaie au maximum de faire que l'index ne fasse pas plus d'un pourcent de la taille totale des fichiers indexé (il utilise un répertoire assez hétérogène. Lors de précédents essai ça se confirmait toujours. Néanmoins j'ai eu plusieurs fois des problèmes lorsque Inotify était activé (le fichier était indexé lui même).

                donc voila soit ton système de fichier est bourré de fichiers spéciaux qui consomme beaucoup de mémoire dans l'index, soit tu es sujet a ce bug de récursivité. (je ne suis plus au courant de l'état de développement depuis 2 semaines)

            • [^] # Re: Pour ma part

              Posté par  . Évalué à 1.

              Tu parles du daemon de Pinot ? Quels etaient les symptomes ? Jette un oeil au log du daemon dans ~/.pinot/pinot-dbus-daemon.log.
              Pas mal de bugs ont ete corriges depuis 0.62, essaie 0.65 si tu as le temps. En passant --enable-debug=yes a configure, le log aura plus d'informations.

              > pinot était interessant, mais son plus gros reproche, c'est que personne n'arrivait à trouver l'endroit où il est développé
              Bah, Pinot est developpe chez moi :-)
              Pourquoi est ce si important ?

        • [^] # Re: Pour ma part

          Posté par  . Évalué à 1.

          Salut, je suis l'auteur de Pinot... le programme pas Jerome :-)
          Quel probleme as tu rencontre avec le paquet Edgy ? N'hesite pas a poster un descriptif sur la liste pinot-discuss.
          As tu eu l'occasion d'essayer 0.65 ? Le paquet Edgy, contrairement a celui pour Feisty, est toujours a 0.62.

  • # j'y connais rien de chez rien mais...

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

    Tracker n'aurait pas intérêt à se baser, du moins pour la première recherche (dès l'install en somme) sur les lib de Hachoir pour récupérer les métadatas ?

    C'est du python... ok... cad emande surement plus de ressources que du C pour faire ceci, mais au moins c'est efficace. Et ca permettrait sans doutes de passer en revue un certain nombre de fichiers non encore gérés par Tracker.

    • [^] # Re: j'y connais rien de chez rien mais...

      Posté par  . Évalué à 3.

      D'un autre côté, ajouter une dépendance à python est loin d'être négligeable. Et si c'est fait en C, c'est sans doute aussi dans une optique de performance (et pour ce qui est de l'indexation, c'est à mon avis important) ; même si python n'est pas non plus un boulet dans le domaine, il est quand même un sacré facteur limitant dans cette optique.

      • [^] # Re: j'y connais rien de chez rien mais...

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

        sur de l'incrémental, le C me parait hyper intéressant mais dès le démarrage... l'indexation avec hachoir pourrait peut etre permettra d'avoir un gros pool de métadatas

        • [^] # Re: j'y connais rien de chez rien mais...

          Posté par  . Évalué à 3.

          Si ton code en C peut par la suite compléter les données acquises via le hachoir, cela signifie que le parser de données C est aussi complet que celui en python. Dans ce cas là, même pour l'indexation initiale il faudrait utiliser celui en C.

          Mais moi j'aurais dit le contraire que toi à la limite: un parseur C initial ne sachant pas trouver toutes les meta-datas mais faisant un pool en gros et assez rapidement, puis utilisation d'un parser plus complet et dans un language plus lent pour l'incrémental.

          Après tout, si la tâche est avec une priorité basse il n'y a pas de raison qu'elle gêne vraiment. Toutefois sous linux, les accès disques ont tendances à tirer le système en bas (faire tout ramer). Par exemple la je grave un DVD et le texte que je tape apparait avec plusieurs secondes de retard et pourtant j'ai un dual-core. Bon j'ai aussi du SATA et je crois que mon chipset est pas des mieux supporté, mais c'est un problème que j'ai déjà eu et j'ai l'impression que linux souffre plus des accès disque que windows (quelqu'un sait pourquoi ?)

          • [^] # Re: j'y connais rien de chez rien mais...

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

            Moi je sais.

            T'es en PIO.
            Un disque SATA pourri me posait le même problème.
            Là actuellement, mon lecteur DVD est en PIO, et il m'est impossible de lire un film(sur un dual-core également) car sacadé.

            Le problème du PIO, c'est que le processeur reste bloqué pendant les opérations de lectures/écritures.
            Normalement, (sauf systèmes antiques), lors d'une opération de lecture/écriture(en très gros):
            -Le système place en mémoire les infos nécessaires(données à écrire par exemple).
            -Il dit au périphériques: "écrit moi ça"/"lit moi ça".
            -Le périphérique a directement accès à la mémoire, il se démerde, le processeur peut continuer son travail tranquil(genre par exemple, gérer l'affichage des touches à l'écran). Le thread demandant la lecture étant mis en attante.
            -Lorsque la lecture est terminée, une interruption a lieu, le scheduler redonne alors la main au thread qui pourra traiter la donnée.

            En PIO:
            -Le système demande au périphérique la lecture d'une donnée.
            -Le processeur attend le résultat. Pendant ce temp, il maintient le contact, et reste complètement bloqué jusqu'à ce qu'arrive le résultat.
            -Une fois le résultat arrivé, le système rend la main à l'application avec la donnée. Ce qui, pour un disque dur/lecteur CD, peut représenter des millions de cycles d'horloges.

            Mais ça, c'est pareil sous Windows comme sous Linux. Et si les accès disques tiraient tant notre système vers le bas, Linux ne serait pas tant utiliser sur les serveurs web/de bases de données. Ce qu'il faut, c'est un chipset bien supporté, et bien configuré quoi.

  • # enfin !

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

    Personnellement, je n'ai jamais pu utiliser réellement beagle. En effet, ses périodes d'indexation font ramer complètement la machine pendant quelques secondes +/- tous les 1/4h.

    Quand tu ne fais rien de particulier, tu ne t'en rends pas compte, mais quand tu joues ou que tu regardes un DVD, c'est extrêmement ennuyeux.

    Si tracker n'a pas ce problème, je serais absolument ravi ! En plus, il semble bien plus intéressant. Notamment leaftag, rhythmbox et epiphany veulent l'utiliser comme backend, ce qui me semble une idée extrêmement intéressante.

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

    • [^] # Re: enfin !

      Posté par  . Évalué à 3.

      J'avais exactement le même problème avec Beagle, mais tracker est vraiment rapide sur ma machine (Duron 900, 384mo de ram).

      J'espère vraiment que des applis comme Rhythmbox ou F-Spot l'utiliseront à la place de leurs base de données... Une photo dans ~/ serait immédiatement importée, peut importe si on la déplace dans l'arborescence, et de plus la gestion des tags de tracker serait ici parfaitement appropriée. De même pour la musique :)

      • [^] # Re: enfin !

        Posté par  . Évalué à 1.

        Ce serait parfait au niveau du desktop d'avoir une abstraction du systéme de fichier. Mais pour que ce soit vraiment utile, il faudrait que le moteur utilisé par kde, gnome ou xfce ait les même interfaces d'accés. D'ailleurs puisqu'on à l'auteur d'un de ces moteurs d'indexation sous la main si il pouvait nous dire ce qu'il en est au niveau de la normalisation.

        Mais franchement une méthode d'accés unique pour les bases de données audio, photo, vidéo ça péterait et d'ailleurs ça pourrait même rappeler un OS...

        • [^] # Re: enfin !

          Posté par  . Évalué à 2.

          http://wiki.freedesktop.org/wiki/WasabiDraft
          http://wiki.freedesktop.org/wiki/WasabiDraft2

          Je suis au courant de l'initiative Wasabi pour créer une interface DBus commune à tous les systèmes d'indexation/recherche de contenu. Mikkel Kamstrup Erlandsen intervient régulièrement sur la ML de Tracker et Jamie McCracken (le dév principal de Tracker) suit l'avancée de cette initiative. Le dév principal de Strigi y participe aussi et il a de bon rapport avec Jamie.
          Donc pour l'instant cette initiative pourrait tout fait être adoptée par Strigi et Tracker. Pour d'autres, je n'en sais trop rien... Je crois que les dév de Beagle étaient intéressés par l'écriture d'une interface DBus, mais je ne sais pas si elle suivra Wasabi.

          • [^] # Re: enfin !

            Posté par  . Évalué à 1.

            > Donc pour l'instant cette initiative pourrait tout fait être adoptée par Strigi et Tracker.
            Et aussi par Pinot et Recoll, deux solutions "made in France".

    • [^] # Re: enfin !

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

      Hier soir, je mattais un divx(*) via freeplayer/homeplayer sur ma tv (* : "j'irai dormir chez vous, au quebec")
      Il s'est mis à saccader ...
      Je suis allé voir sur l'ordi, un htop ... et "beagled" processait fort ...
      je l'ai coupé, et un "sudo apt-get remove beagle" ont définitivement réglé le problème.

      je ne garde que tracker

      Pourquoi donc beagle se met il a indexe les fichiers ainsi ?! il ne marche pas avec inotify ?!

      • [^] # Re: enfin !

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

        Pourquoi donc beagle se met il a indexe les fichiers ainsi ?! il ne marche pas avec inotify ?!
        Il marche avec inotify quand ce dernier est installé et beagle configuré pour, autrement il s'en passe. Sinon beagle est censé "bosser" lors des périodes d'inactivités de la machine, je soupçonne leur algorithme de détection d'inactivité d'être foireux dans ce contexte :)

Suivre le flux des commentaires

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