Articles : Une nouvelle manière de stocker ses données : GLScube
Posté par Xavier Teyssier (Jabber id, page perso, ). Modéré le 17 juillet 2006.
Dans ce but, GLSCube est capable d’extraire un certain nombre de données des fichiers qu’il manipule, mais permet aussi à l’utilisateur de définir ses propres attributs.
GLScube est utilisable en “espace utilisateur” via FUSE.
Il est sous licence GPL.
![[en]](../images/en.png)
Page d’accueil du projet (1063 hits)-
PDF (408K) avec le pourquoi et le comment du projet (222 hits)
> Lire la dépêche (31 commentaires, moyenne: 3,3).
Vous avez demandé le commentaire #737826.
Run by 
Cette page a été générée par Templeet en 0.1048s (dont 0.0129 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
D'autres systèmes
Il existe aussi[1] :
Tracker http://freedesktop.org/wiki/Software/Tracker
Beagle http://beaglewiki.org/Main_Page
Strigi http://strigi.sourceforge.net/index.php/Main_Page
Ce sont vraiment des développement intéressants. Je me dis que nos applications webs pourraient bien profiter de ces fonctionnalités dans un futur proche... particulièrement l'utilisation des attributs étendus du système de fichiers.
[1] liens trouvés sur http://freedesktop.org/wiki/Standards_2fshared_2dfilemetadat(...)
[^]Re: D'autres systèmes
Les devs d'Ubuntu se posaient justement la question d'intégrer tracker car il ne prenait pas trop de ressources (en tout cas cela est incomparable par rapport à Beagle par exemple).
Personellement je n'ai pas vraiment saisi l'engouement et l'interet de ce genre de technos : je range mes fichiers à la main dans des repertoires bien defini, mon lecteur de musique me permet si je le veut de trier ma musique, et je ne voit pas l'utilité d'une couche supplementaire pour faire cela.
[^]Re: D'autres systèmes
sauf quand tu as quelques centaines/milliers de fichiers et que tu veux sortir , par exemples si ce sont des photos, tous ceux qui ont été pris avec une vitesse < à 1/2 secondes
Bon perso je me suis déja fait a la 'main' ma bd avec toutes les infos exifs de mes photos pour faires des stats toussa mais bon ;)
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: D'autres systèmes
Il faut remettre la techno dans le contexte général des méta données et du comment les stocker et faire une recherche dessus.
Le très grand intérêt est de ne pas avoir à implémenter à chaque fois la même chose dans chaque application. On se retrouve avec une manière standard de stocker/rechercher les méta données. On peut ainsi imaginer que les "tags" que tu as dans f-spot puissent être utilisés aussi dans d'autres applications. Que par exemple quand tu "mets à la poubelle" un fichier il garde trace d'où il vient pour pouvoir le "restaurer".
Le problème d'aujourd'hui est le manque d'intégration transparente de ces informations. Pousser cela au niveau du système de fichiers permet de standardiser l'accès à ces infos. Et les standards pour l'accès et le stockage de l'info, c'est bon.
Ce sont ces petites briques qui vont transformer le desktop. Un peu HS, voici un post intéressant à lire : http://www.jonobacon.org/?p=710
[^]Re: D'autres systèmes
Voilà un cas pratique:
je viens de faire passer un festival de théâtre sous Linux. Ils ont 19 gigas de données partagées, plus les emails (quelques centaines par jour). C'est essentiellement du texte (OpenOffice) et quelques milliers de photos. 3 personnes accèdent à ces données.
Ca va à peu près, tant qu'on se rappelle ce qu'il y a dans les données. Parce que c'est pas tout de ranger et de bien nommer (et sur 19 gigas il y a bien 5 gigas de bordel), ça n'indique pas vraiment ce que contiennent les fichiers.
Autre exemple: il y a les emails envoyés par les compagnies de théâtre, les sites web qu'on visite, le programme du festival, ... c'est à dire des documents qu'il faut souvent relier à d'autres, plus vieux.
Et encore un: d'ici 4 ans, 2 des 3 personnes seront parties. Comment tout retrouver ?
Bref, autant de cas, où "ce genre de technos" serait très utiles. C'est sûr qu'on a de la cervelle en réserve, et qu'on est à peu près capable de s'y retrouver dans notre bazar, mais c'est le nôtre justement. Dans une équipe, c'est complètement différent.
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
[^]Re: D'autres systèmes
ok, la je vois mieux...
Mais pour un utilisateur plus basique j'avoue que cela ne m'as pas plus convaincu, à part peut-etre l'aspect "metadonnées accessibles à tout le système" mais pour arriver à une telle intégration je pense qu'il faudrait à ce moment la tout intégrer au fs, et éviter de stocker les metadonnées dans les fichiers directement (id3, exif ne feraient-ils pas doublon ?)
[^]Re: D'autres systèmes
je pense qu'il faudrait à ce moment la tout intégrer au fs, et éviter de stocker les metadonnées dans les fichiers directement (id3, exif ne feraient-ils pas doublon ?)
J'ai surement pas compris quelque chose dans cette phrase.
AMHA, il faut faire la difference entre les données intrinsèques au fichier, et les données de l'utilisateur sur le fichier.
Je m'explique :
L'exif d'une photo, generalement, on trouve de base les informations suivantes : date de prise de vue, resolution de l'image, modele de l'appareil photo etc ...
Quelque soit la personne qui consulte l'image, ces données sont réelles, et permettent de definir l'image en elle meme.
Maintenant, tu as des "utilisateurs" de cette photo qui vont lui appliquer des tags. Ceux-ci seront plus subjectifs : par exemple, admettons qu'on aie une photo de l'arc de triomphe, pour certain cela rappellera les vacances de l'ete 2006, tandis que d'autres classeront ca dans une categorie "Monuments", et encore d'autre "la vue depuis la fenetre de mon appartement"
Donc, autant l'exif de la photo restera valable quelque soit l'utilisateur, autant le reste est lié a ce dernier.
On retrouve tres bien ce phenomene avec les gestionnaires de collections de fichiers mulitmedias a la itunes ou amarok : les id3tags sont contenus dans les fichiers et dupliqués dans la base de donnée.
Par contre, d'autres informations (emplacement, nombre de fois joué, date ajout, date modification, note fournie etc ... ) sont specifique a l'utilisateur sur son pc, et ne sont donc contenus que dans la BDD.
Donc, oui, AMHA il faut que les doublons reste. Ca fait de la redondance d'information mais c'est le plus logique egalement.
[^]Re: D'autres systèmes
Ces raisonnements sont valables si les systèmes de transfert de fichiers gèrent pas les tags (c'est sans doute pas demain la veille).
Sinon on peux imaginer un système de tags transférés ou pas. Cela dit, un autre avantage des tags à l'intérieur du fichier c'est qu'ils sont standardisés et que chaque appli va pas s'amuser à réinventer la roue avec des noms différents.
Une utilisation à laquelle j'ai pensé récemment : les blind tests. On peux rajouter à des morceaux le tag bt, catégorie machin, ... et retrouver le bt en question en un rien de temps, ou encore retrouver les morceaux qui sont pas encore passés en blind test, etc.
En bref, pour ceux qui en voient pas l'intérêt, c'est comme pour pleins de trucs : on en imagine pas trop l'intérêt avant d'avoir cherché à les utiliser, ca débride l'imagination ;)
[^]Re: D'autres systèmes
Cela dit, un autre avantage des tags à l'intérieur du fichier c'est qu'ils sont standardisés et que chaque appli va pas s'amuser à réinventer la roue avec des noms différents.
D'un autre cote, si tu stockes les tags a l'interieur du fichier, imagines ca :
T'as un utilisateur qui peut lire certains repertoires, mais pas y ecrire.
Il peut tager les fichiers pour s'y retrouver ? Si oui, si les infos sont dans le fichier, alors ca veut dire qu'il peut ajouter une quantite incalculable de donnees dans ce repertoire, remplissant la partition, essaye de tirer partie de vulnerabilites dans des softs lisant les tags, ...
Alors que si les infos specifiques a l'utilisateur sont stockees chez cet utilisateur, la separation est claire et il ne peut causer de problemes a personne a part lui-meme.
Il peut pas tager les fichiers qu'il n'a pas le droit d'ecrire ? Ca rend tous les scenarios de collections media read-only impossible a implementer avec une technique "tags dans le fichier".
[^]Re: D'autres systèmes
Pas faux, mais en fait je pensais surtout aux tags "de base" genre auteur,album,etc pour une chanson, qui varient pas trop, qui sont les mêmes pour tout le monde, et qu'on a pas a priori trop de raisons de personnaliser, sauf peut être en cas d'erreurs ou d'infos incomplètes. Mieux, ces infos permettent d'identifier de manière relativement précise le fichiers, et en ce sens en dont pas trop discociables.
Bien sûr, les deux systèmes sont complémentaires, mais dans le cas d'un transfert de fichier, ça permet d'assurer le trasnfert des infos minimales sur un fichier en l'absence de gestion des tags "fs" par la source, la destination ou le protocole de transfert.
[^]Re: D'autres systèmes
les deux systèmes sont complémentaires
c'est sûr.
dans le cas que j'évoquais plus haut (petite équipe), il vaut mieux des infos accessibles par tous.
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
[^]Re: D'autres systèmes
Et ben moi si , je vois l'interet, meme si il est limité.
Pour information etant donné que j'utilise MacOSX je parlerai donc de mon experience avec spotlight, qui propose les memes services.
Par exemple, j'ai une collection de fichiers multimédias, ceux ci sont extremement bien rangés, puisque chacun a son propre repertoire. (c'est meme fait automatiquement par d'autres logiciels)
Par contre, je dois dire que c'est ennuyeux d'ouvrir a la main chacun des repertoires quand je veux juste avoir une liste de ces fichiers.
Là, je fais une recherche sur la partie du nom commune, ainsi que sur le type et pof ! J'ai une liste de fichiers qui apparait.
Effectivement par rapport a une recherche 'normale', l'interet est moindre. par contre, etant donné que c'est intégré au FS et adossé a une DB, c'est beaucoup plus rapide.
Et c'est drolement appréciable.
[^]Re: D'autres systèmes
je fais une recherche sur la partie du nom commune
Un peu comme un "find . -type f" dans une interface graphique ? Personnellement, je n'ai pas besoin d'avoir plus la plupart du temps.
[^]Re: D'autres systèmes
La partie commune peut eventuellement etre l'extension le probleme c'est que pour un meme type de fichier il peut y en avoir plusieurs.
.mp3 .ogg
.png .jpeg.jpg .tiff
à la limite tu peut te baser sur le type mime, gnomevfs-ls l'affiche.
[^]Re: D'autres systèmes
Tu oublies que "find" n'est pas vraiment optimisé pour traiter un gros volume de données. Ta recherche risque de prendre beaucoup de temps.
[^]Re: D'autres systèmes
Pour faire une recherche sur des fichiers, j'utilise un locate associé à un grep, c'est quasi intantané aussi.
Le problème c'est qu'un FS reste un arbre hiérarchique, et selon les jours, on a pas envie de chercher un fichier selon l'humeur que l'on avait pour le classer ce jour là.
L'exemple typique est la collection de musique, je range par genre/année/nom
année/genre/nom
nom/année/genre
Par exemple perso je range par nom, car c'est plus facile de lire une liste alphabétique que de se poser à priori la question, dans quel genre je l'ai rangé, ou c'est de quelle année déjà ?
Par contre si je dois faire une soirée théme année 80, c'est à moi de faire le tri.
Il y a plein de soft qui permettent de faire ça maintenant, ils utilisent une BDD.
Est-ce que la notion de filesystem est toujours pertinente pour stocker les données qui de toute manière seront une suite de 0 et de 1 sur la surface du disque dur ?
Et que penser d'un système "CVS" intégré pour versionner automatiquement les modifications (ça serait top pour le répertoire /etc) ce qui permetrait de retrouver le sens des modifications quand on est pas rogoureux et que l'on ne note pas tout dans un fichier ou un cahier !
D'une redondance automatique des données répartis sur la surface maintenant que les HD font plusieurs centaines de giga.
La notion de filesystem me semble bien désuéte, on la garde pour des raisons historiques et de compatibilité, mais ça reste du bas niveau au niveau conceptuel.
[^]Re: D'autres systèmes
Et que penser d'un système "CVS" intégré pour versionner automatiquement
si le système de fichiers était une base de données on pourrait facilement remonter dans les versions non (rollback)?
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
[^]Re: D'autres systèmes
déjà possible avec bazaar-ng par exemple : http://bazaar-vcs.org/VersioningEtc
ne te prive pas :)
La Roue du Temps
[^]Re: D'autres systèmes
... ou SVK.
http://lists.debian.org/debian-devel/2005/02/msg00495.html
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
[^]Re: D'autres systèmes
Je n'ai pas vu de notion "d'auto-commit" dans vos 2 exemples.
Je pourrais déjà mettre mon /etc sous un systéme de versionning quelconque, faire une tâche cron pour faire les comits (mais autant faire un rsync dans ce cas)
Il faudrait que le système de versionning soit totalement transparent (aucune modification des applications, on sauve le fichier avec vi/emacs/nano/... et c'est le FS qui fait le versionning)
Du coup on y accèderait uniquement quand il y a un problème, ou pour comprendre l'historique des modifications qu'on a effectué.
[^]Re: D'autres systèmes
En fait on en a déjà parlé ici notamment : http://linuxfr.org/~g78/21409.html#701990Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
[^]Re: D'autres systèmes
Merci pour l'info, malheureusement, il va falloir que je repartitionne mon disque pour avoir un /etc séparé.
[^]Re: D'autres systèmes
C'est sans doute pas une bonne idée. /etc fait partie des trucs indispensables qui sont censés faire partie de / de manière à ce que le répertoire soit accessible même si les autres partitions ne peuvent pas être montées (runlevel 1, toussa).
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
[^]Re: D'autres systèmes
En fait je ne comptais pas être aussi extréme, vu que /etc n'est pas trés gros.
J'y réfléchirais pour la prochaine installation, si je me sens assez fou pour suivre le guide du parfait petit administrateur qui crée pleins des partitions pour chaque partie de son système :-)
[^]Re: D'autres systèmes
Tu peux toujours créer un un /etc minimaliste dans ton / (genre fstab, initscripts, etc...), le montage de l'autre (cvs/svn/etc) par dessus ne posera pas de problème sérieux ;)
Il faudra que tu génère a la main ton mkinitrd pour avoir les modules et tout ce qui va bien pour monter /etc au boot ;)
site perso : http://rapsys.free.fr/