pas forcement comparable

• [^]Re: pas forcement comparable

  Posté par el_mickey () le 03/01/2007 à 10:50. (lien). É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 manatlan (Jabber id, page perso, ) le 03/01/2007 à 10:58. (lien). Évalué à 2.

    oui, j'ai oublié de préciser dans mon journal que ça utilisait bien evidemment dbus pour communiquer

    --
    manatlan.com

    • [^]Re: pas forcement comparable

      Posté par el_mickey () le 03/01/2007 à 11:07. (lien). Évalué à 1.

      Ouai c'est bien mais encore faut il que les objets dbus soient communs à tous les "desktop-search"

• [^]Re: pas forcement comparable

  Posté par manatlan (Jabber id, page perso, ) le 03/01/2007 à 10:55. (lien). É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 ...

  --
  manatlan.com

  • [^]Re: pas forcement comparable

    Posté par Laurent A. () le 03/01/2007 à 18:14. (lien). É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 Éric (Jabber id, page perso, ) le 03/01/2007 à 20:56. (lien). É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 Laurent A. () le 03/01/2007 à 21:10. (lien). É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 TImaniac (page perso, ) le 03/01/2007 à 21:22. (lien). É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 ?

          --
          MonoFrance

          • [^]Re: pas forcement comparable

            Posté par Laurent A. () le 03/01/2007 à 22:06. (lien). É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 TImaniac (page perso, ) le 03/01/2007 à 22:09. (lien). Évalué à 1.

              ok tu me rassures :)

              --
              MonoFrance

      • [^]Re: pas forcement comparable

        Posté par TImaniac (page perso, ) le 03/01/2007 à 21:18. (lien). É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 :)

        --
        MonoFrance

    • [^]Re: pas forcement comparable

      Posté par Aurélien Bompard (Jabber id, page perso, ) le 04/01/2007 à 18:20. (lien). É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 Laurent A. () le 04/01/2007 à 19:30. (lien). É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 Krunch (Jabber id, page perso, ) le 06/01/2007 à 21:43. (lien). Évalué à 2.

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

      --
      Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
      pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

Pour ma part

• [^]Re: Pour ma part

  Posté par Johann Ollivier-Lapeyre (page perso, ) le 03/01/2007 à 10:40. (lien). É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

  --
  ----------------------------------------------------------------
  KDE - Kopete - Oxygen - KDEgames

  • [^]Re: Pour ma part

    Posté par manatlan (Jabber id, page perso, ) le 03/01/2007 à 11:06. (lien). É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 ...

    --
    manatlan.com

    • [^]Re: Pour ma part

      Posté par Johann Ollivier-Lapeyre (page perso, ) le 03/01/2007 à 12:26. (lien). É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é.

      --
      ----------------------------------------------------------------
      KDE - Kopete - Oxygen - KDEgames

      • [^]Re: Pour ma part

        Posté par marseillais (page perso, ) le 03/01/2007 à 12:41. (lien). É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 Jérôme Pinot (page perso, ) le 03/01/2007 à 13:00. (lien). Évalué à 9.

      Je n'ai pas reussi à faire fonctionner pinot

      
      
      Il faut me demander gentiment.

      • [^]Re: Pour ma part

        Posté par liberforce (Jabber id, page perso, ) le 03/01/2007 à 13:31. (lien). Évalué à 9.

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

      • [^]Re: Pour ma part

        Posté par manatlan (Jabber id, page perso, ) le 03/01/2007 à 18:12. (lien). É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é )

        --
        manatlan.com

        • [^]Re: Pour ma part

          Posté par djibb (Jabber id, page perso, ) le 03/01/2007 à 19:16. (lien). É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.

          --
          http://astrolix.org

          • [^]Re: Pour ma part

            Posté par marseillais (page perso, ) le 03/01/2007 à 20:03. (lien). É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 Fabrice Colin (page perso, ) le 13/01/2007 à 08:26. (lien). É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 Fabrice Colin (page perso, ) le 13/01/2007 à 08:15. (lien). É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...

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

  Posté par lasher () le 03/01/2007 à 14:17. (lien). É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 djibb (Jabber id, page perso, ) le 03/01/2007 à 14:49. (lien). É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

    --
    http://astrolix.org

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

      Posté par RB () le 03/01/2007 à 21:52. (lien). É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 Vador Dark (Jabber id, ) le 04/01/2007 à 12:39. (lien). É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 !

• [^]Re: enfin !

  Posté par Arkeos () le 03/01/2007 à 17:36. (lien). É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 el_mickey () le 03/01/2007 à 19:48. (lien). É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 Laurent A. () le 03/01/2007 à 20:56. (lien). É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 Fabrice Colin (page perso, ) le 13/01/2007 à 08:30. (lien). É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 manatlan (Jabber id, page perso, ) le 04/01/2007 à 09:43. (lien). É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 ?!

  --
  manatlan.com

  • [^]Re: enfin !

    Posté par TImaniac (page perso, ) le 04/01/2007 à 11:21. (lien). É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 :)

    --
    MonoFrance