Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de aurelieng :
- [30/03@14:57] nid a troll inter-distrib
- [14/02@09:05] FPS: Sin + Linux -> cannot execute binary file ??
- [12/02@15:25] Fedora Core 2 test release 1 dispo
- [26/01@21:38] Extreme: voltages carte mère et instabilité.
- [23/01@22:20] FPS: Sin
- [09/12@14:36] Live-CD GPL et sponsorisé recherche contributeurs
- [10/11@11:43] Fedora Core 1 sur un Dell Inspiron: impression mitigée
Après la lecture de http://www.lemonde.fr/web/article/0,1-0@2-3238,36-396308,0.html(...) sur les moteurs d'indexation et de recherche ds un filesystem local, je me suis dit que windows était bien fourni de ce coté là, et même microsoft pourrait se faire doubler si son WinFS est trop en retard. Coté Apple, il existe SpotLight, intégrée a Tiger, nouvelle version d'OSX qui sera disponible probablement en juin http://www.apple.com/macosx/tiger/spotlight.html(...) .
Je me demandais donc si l'équivalent était à l'étude pour linux. Des infos à ce sujet ? Des feedback sur d'autres plateformes ?
Merci pour vos contributions !
> Lire le journal (21 commentaires, moyenne: 4).
beagle
Ça existe : c'est beagle, en cours de développement...
http://nat.org/demos/(...)
-
[^]Re: beagle
-
[^]Re: beagle
Posté par vincent LECOQ (Jabber id, page perso, ) le 01/02/2005 à 22:05. (lien). Évalué à 6.non, beagle est un deamon a la base, il existe aussi un client KDE et des outils ligne de commande. Et puis l'outil graphique s'integre dans un systray, API commune a KDE et GNOME.
--
Ma signature ici-
[^]Re: beagle
Posté par TImaniac (page perso, ) le 02/02/2005 à 12:20. (lien). Évalué à 3.Beagle tourne même sous Windows (merci Mono ;-p)
-
-
D'un autre coté...
D'un autre coté si les gens laissent trainer leur fichier n'importe où au lieu de creer des hierarchies de répertoire, c'est leur problème :)
Est-ce qu'on prévoit de créer des robots de recherches automatique d'objets pommés dans le foutoir de certaines chambres aussi (la mienne par exemple ;) ?
-
[^]Re: D'un autre coté...
Posté par Pinaraf (Jabber id, ) le 01/02/2005 à 18:46. (lien). Évalué à 8.Oui mais l'arborescence ne résoud pas tout !
Comment trier facilement un fichier qui rentre dans plusieurs catégories ?
Puis fouiller dans l'arborescence reste plus chiant que de taper le mot que tu veux dans l'appli de recherche...-
[^]Re: D'un autre coté...
Posté par Toto () le 01/02/2005 à 18:56. (lien). Évalué à 0.Pour les fichiers qui rentrent dans plusieurs catégorie : les liens.
Et puis fouiller une arbo bien faites, c'est rapide, il suffit pour cela que chaque repertoire commence par une lettre différente pour profiter au maximum de la completion automatique-
[^]Re: D'un autre coté...
Posté par aurel (page perso, ) le 01/02/2005 à 19:26. (lien). Évalué à 7.Une arborescence est un classement. Unique classement. Gérer avec des liens impose de les mettre a jours lorsque des items se balade d'un repertoire a l'autre. Tu peux trier tes fichiers à ta convenance en fonction du classement qui te semble le plus intuitif, mais :
- multiplier les classement a l'aide de lien ne propose que des classement alternatifs qui ne seront jamais exhaustifs,
- ce ne sont pas forcément ces classements qui sera le plus intuitifs pour des tiers (probleme d'espace disque commun a plusieurs personnes, gestion de projets a plusieurs)
- pour une recherche sur des documents anciens dont le classement était complexe, il peut dans certains cas etre très difficile de s'y retrouver.
Par exemple concernant les photos numériques: tu peux les classer par date puis par lieu, ou par lieu puis par date. Mais si tu recherches toutes les photos prises en juillet 2003 ou toute les photos prises pdt des vacances a tombouctou, tu sera obligé de faire plusieurs recherches. D'où l'intéret d'un soft comme kimdaba par exemple. Et d'où l'intéret d'élargir le concept à d'autres types de fichiers.
En gros, ce n'est pas pour rien que sur internet, tout le monde ou presque utilise une recherche par mot clé plutot qu'une recherche par catégorie, meme si les deux cohabitent.-
[^]Re: D'un autre coté...
Posté par Barbapapa () le 01/02/2005 à 21:28. (lien). Évalué à 2.Je n'ai bien compris comment ces systèmes de fichiers avec recherche fonctionneront en pratique. Mes photos de vacances à Tombouctou en 2003 je les mets dans le répertoire vacances/2003/tombouctou et c'est fini. Un système où je peux rechercher par mots clés signifie que l'utilisateur a indiqué pour chaque photo une série de mots clés. A moins d'être maniaque, l'utilisateur va rapidement se lasser. Les répertoires c'est peut-être pas parfait mais c'est rapide à utiliser.
-
[^]Re: D'un autre coté...
Posté par Larry Cow () le 01/02/2005 à 23:15. (lien). Évalué à 4.Pas forcément.
Si tu l'année suivante tu as des photos d'un séminaire à tombouctou, tu vas avoir un second répertoire de photos: boulot/2004/tombouctou. Si tu veux voir la liste de toutes tes photos de tombouctou? facile, un simple ls */*/tombouctou/*.jpg. Ok. Mais tu commences à pressentir que ça sera pas aussi facile tout le temps. Si tu commences à avoir des photos sur plusieurs niveaux, ça devient carrément bancal. Et pourtant, tu n'as associé à chacune de tes photos aucune métainformation, excepté le répertoire dans lequel elle est rangée.-
[^]Re: D'un autre coté...
Posté par cykl (Jabber id, ) le 02/02/2005 à 10:00. (lien). Évalué à 3.une technique est de repeter l'information de la hierarchie dans le nom de fichier exemple :
boulot/2004/tombouctou/toto.jpg -> boulot/2004/tombouctou/boulot_2004_tombouctou_toto.jpg
Ca permet des recherches plus faciles et surtout en cas de deplacement de fichier intempestif de pouvoir retrier tout ca. Par ce que bon en 10 ou 20 ans d'archivage on arrivera facilement a faire au moins une connerie :-)
-
-
-
-
[^]Re: D'un autre coté...
Posté par cykl (Jabber id, ) le 01/02/2005 à 20:18. (lien). Évalué à 7.Dans mon ~/Doc je dois avoir pres de 3000 fichiers qui ne sont pas de moi mais qui est de la doc interessante. Ca va du C99, aux rapports USENIX, en passant par des RFCs et autres conneries des choses sur lesquels j'ai bossé.
Tu penses que j'ai que ca a faire que ce trier ca ? Et de leur donner un nom significatif. Ranger *ton* travail est une chose, pour un developpeur de tout facon c'est dans un svn et ranger son ~ se resume a rm. Pour le mec qui ecrit 4 .doc par jour c'est une hierarchie.
Mais vouloir tout trier ca ne marche pas toujours et ca marche même rarement.
Pour ce qui est des liens laisse moi rire. Je gère aussi un repository en ligne, qui doit arriver à 30 000 fichiers textes. Je te laisse t'amuser avec tes liens dans tout les sens.
Le moteur de recherche à un sens car le volume d'information que l'on manipule tout les jours est tellement important que c'est perdre son temps de l'ordonner a la main. Est ce que tu tri tes mails ? Je pense que comme tout le monde tu as 4..15 dossiers et après tu utilises la fonction recherche ? Après tout l'informatique c'est le traitement automatique de l'information non ?
-
-
-
[^]Re: D'un autre coté...
Posté par Florimond Simonklein (page perso, ) le 01/02/2005 à 18:55. (lien). Évalué à 4.Et pourquoi s'arrêter à la recherche sur nom de fichier quand on peut faire de la recherche sur le contenu ? Avec une seule arbo', tu arrives à tout classer impeccablement selon tout un tas de critères ?
c'est presque ca
Personnellement quand je veux faire une recherche j'utilise ou :
find / -name "mon_fichier" -print
Ca marche mais attention ca rame, sinon il y a plus propre :
slocate mon_fichier
Au préalable il faut avoir créé la base qui va bien
slocate -u /
Il manque plus qu'une belle interface graphique et ca pourrait être bien.
-
[^]Re: c'est presque ca
Posté par aurel (page perso, ) le 01/02/2005 à 19:15. (lien). Évalué à 2.ca irait pour un simple listing, mais pas de classement par pertinence ou par par catégorie, ni de recherche dans les fichiers. Un grep recursif pourrait presque aller, mais serait limité au matching dans des fichiers textes, et donc pas aux PDF, ni openoffice, ni archives, ni images, ni tags des fichiers audio, etc).
-
[^]Re: c'est presque ca
Posté par Matthieu C () le 01/02/2005 à 19:24. (lien). Évalué à 3.ca irait pour un simple listing, mais pas de classement par pertinence ou par par catégorie, ni de recherche dans les fichiers. Un grep recursif pourrait presque aller, mais serait limité au matching dans des fichiers textes, et donc pas aux PDF, ni openoffice, ni archives, ni images, ni tags des fichiers audio, etc).
Tu peux toujour faire un script qui pour chaque fichier regarde son type et en consequence utilise la commande adequate (pdf2text | grep, ...)
Comment ça, ça va ramer...-
[^]Re: c'est presque ca
Posté par aurel (page perso, ) le 01/02/2005 à 19:28. (lien). Évalué à 1.déjà fait, mais impossible de donner une pertinence à moins de remettre a jours des index toutes les 2 secondes et faire des stats sur "les mots de plus de deux lettres, avec une majuscule, et dans une seule langue"... => solution ingérable...
-
[^]Re: c'est presque ca
Posté par Erwan (page perso, ) le 02/02/2005 à 02:40. (lien). Évalué à 8.Allez-y, continuez le brainstorming. Alors finalement ce serait bien de garder un index des fichiers pour pas que ca rame a chaque fois. Et il faudrait savoir quand un fichier est modifie/cree pour mettre a jour l'index de ce fichier.
Et bien voila, vous avez reinvente Beagle.
-
-
-
[^]Re: c'est presque ca
Posté par Uvoguine () le 01/02/2005 à 19:25. (lien). Évalué à 5.Il manque plus qu'une belle interface graphique et ca pourrait être bien.
Si t'as KDE, installe kio-locate et tappe "locate:recheche" dans la barre d'url de konqueror (ou du selecteur de fichiers), ça t'affiche la liste des fichiers correspondant à la recherche.
http://kde-look.org/content/show.php?content=17201(...)-
[^]Re: c'est presque ca
Posté par Philippe (page perso, ) le 04/02/2005 à 19:07. (lien). Évalué à 2.Pas de bol, sur mon petit portable Kde ou Gnome sont trop lourd. Je tourne avec Xfce 4.2.
-
Possibilités existent déjà
Le problème existe depuis longtemps, et j'ai envie de dire que les solutions aussi. Mais bon, ces derniers temps, pas mal de "bruits" à été fait autour des moteurs de recherche locaux, et les gens en redécouvrent l'intérêt (Google, Yahoo, Microsoft).
Donc, sous Linux, comment faire pour retrouver des infos contenues dans les documents (donc, on exclu les solutions à base de find, locate, etc) ? Je me souviens d'un post précédent, cfr http://linuxfr.org/forums/12/5120.html
Grosso modo, on peut installer un moteur de recherche (Lucene, swish++, htdig, etc), et organiser les choses de manière à ce que les fichiers que l'on souhaite indexer le soit.
Entretemps, j'ai continué mes recherches et mes lectures dans le domaine, et j'ai encore trouvé 3 autres outils :
- mg
- seft
- libbow
Pour le premier outil, il s'agit d'un soft développé pour illustrer le contenu d'un bouquin : "Managing gigabytes : compressing and indexing documents and images" / Ian H. Witten, Alistair Moffat, Timothy C. Bell. Il est vraiment chouette, mais bon, à utiliser dans le cadre académique. A compiler soi-même, et tout le tralala.
Pour seft, il existe un front-end en GTK+. Son objectif est de faire des recherches full-text. J'ai peu d'info (j'ai trouvé le programme dans la liste des outils offerts à partir de la page d'accueil du bouquin sus-mentionné). A compiler soi-même et tout le tralala.
Pour libbow, contrairement aux autres, existe pour debian. Il se compose d'une bibliothèque, et de 3 programmes. Un pour chercher, un pour classer automatiquement des documents, et je ne sais plus ce que fait le troisième. De loin mon préféré.
En ce qui me concerne, je n'ai pas vraiment envie de voir indexé l'entièreté de mon disque dur. Je peux comprendre l'intérêt, mais je trouve que c'est un choix qui revient à l'utilisateur. Pour le reste, je pense mettre en place une solution personnelle, cela me donnera l'occasion de mettre en pratique les connaissances acquises dans la lecture du bouquin ci-dessus.
J'espère que cela pourra aider.
Cette page a été générée par Templeet en 0.0891s (dont 0.0083 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.