Jerome Lambert a écrit :faux positifs de Robert". En terme de volume de travail, j'ai
nettement moins à faire.
Eh ben, si je dois passer plusieurs semaines à apprendre à mon PC à
reconnaitre mes photos, mes morceaux de musique, mes vidéos, mes
programmes, mes archives, mes documents...
Jerome Lambert a écrit :
faux positifs de Robert". En terme de volume de travail, j'ai
nettement moins à faire.
Eh ben, si je dois passer plusieurs semaines à apprendre à mon PC à
reconnaitre mes photos, mes morceaux de musique, mes vidéos, mes
programmes, mes archives, mes documents...
Jerome Lambert a écrit :faux positifs de Robert". En terme de volume de travail, j'ai
nettement moins à faire.
Eh ben, si je dois passer plusieurs semaines à apprendre à mon PC à
reconnaitre mes photos, mes morceaux de musique, mes vidéos, mes
programmes, mes archives, mes documents...
Tant que tu ne comprendras pas qu'il est parfois nécessaire de perdre
temps maintenant pour en gagner plus tard, je ne pourrai rien pour
toi...
Tant que tu ne comprendras pas qu'il est parfois nécessaire de perdre
temps maintenant pour en gagner plus tard, je ne pourrai rien pour
toi...
Tant que tu ne comprendras pas qu'il est parfois nécessaire de perdre
temps maintenant pour en gagner plus tard, je ne pourrai rien pour
toi...
Non, ce n'est justement pas efficace: tu crées ton arborescence suivant
un critère que tu ne peux pas modifier aisément. Si tu fais p.ex. une
arborescence chronologique, il est impossible de faire un regroupement
thématique, et inversément. Avoir un système qui permette, suivant le
besoin, de faire un regroupement thématique ou chronologique en
quelques clics me semble largement préférable, et bien plus efficace
*à terme*.
Non, ce n'est justement pas efficace: tu crées ton arborescence suivant
un critère que tu ne peux pas modifier aisément. Si tu fais p.ex. une
arborescence chronologique, il est impossible de faire un regroupement
thématique, et inversément. Avoir un système qui permette, suivant le
besoin, de faire un regroupement thématique ou chronologique en
quelques clics me semble largement préférable, et bien plus efficace
*à terme*.
Non, ce n'est justement pas efficace: tu crées ton arborescence suivant
un critère que tu ne peux pas modifier aisément. Si tu fais p.ex. une
arborescence chronologique, il est impossible de faire un regroupement
thématique, et inversément. Avoir un système qui permette, suivant le
besoin, de faire un regroupement thématique ou chronologique en
quelques clics me semble largement préférable, et bien plus efficace
*à terme*.
totof2000 a écrit :
> C'est valable pour n'importe quelle solution de mise à disposition
> distante (exemple : le wifi).
Ben oui, et quand tu vois comment l'abonné de base peut galérer pour
installer sa box, s'il a une manip équivalente à faire sur chacun de ses
appareils, c'est sur, on va encore faire un grand pas en avant vers
l'ergonomie, la convivialité, la simplicité.
Et tout ça pour remplacer un con de bout de plastique qui répond
parfaitement au besoin de mobilité d'un volume modéré de données.
Mais ce fil, c'est devenu un brainstorming pour écrouler les perfs,
perdre ses petits, couter cher et perdre toutes ses données...
A+
JF
totof2000 a écrit :
> C'est valable pour n'importe quelle solution de mise à disposition
> distante (exemple : le wifi).
Ben oui, et quand tu vois comment l'abonné de base peut galérer pour
installer sa box, s'il a une manip équivalente à faire sur chacun de ses
appareils, c'est sur, on va encore faire un grand pas en avant vers
l'ergonomie, la convivialité, la simplicité.
Et tout ça pour remplacer un con de bout de plastique qui répond
parfaitement au besoin de mobilité d'un volume modéré de données.
Mais ce fil, c'est devenu un brainstorming pour écrouler les perfs,
perdre ses petits, couter cher et perdre toutes ses données...
A+
JF
totof2000 a écrit :
> C'est valable pour n'importe quelle solution de mise à disposition
> distante (exemple : le wifi).
Ben oui, et quand tu vois comment l'abonné de base peut galérer pour
installer sa box, s'il a une manip équivalente à faire sur chacun de ses
appareils, c'est sur, on va encore faire un grand pas en avant vers
l'ergonomie, la convivialité, la simplicité.
Et tout ça pour remplacer un con de bout de plastique qui répond
parfaitement au besoin de mobilité d'un volume modéré de données.
Mais ce fil, c'est devenu un brainstorming pour écrouler les perfs,
perdre ses petits, couter cher et perdre toutes ses données...
A+
JF
Jerome Lambert a écrit :
> clics me semble largement préférable, et bien plus efficace *à te rme*.
Ca semble pas intéresser beaucoup de monde ton idée. Peut-être parc e que
dès le départ c'est dans le flou le plus absolu.
Enfin, puisqu'on parle de complications, envisageons le côté perfs. U n
disque dur ordinaire d'aujourd'hui a un temps d'accès de l'ordre de 8ms .
Prenons une machine en desktop d'un utilisateur qu'on pourrait qualifier
"d'ordinaire", quelqu'un qui aurait quelques 40Go de musique, quelques
milliers de photos, quelques centaines de vidéos, et quelques milliers
de fichiers divers (de son CV au dernier pdf de l'Echo des savanes que
le fameux Robert a envoyé par courriel hier). Tout ça est assez faibl e
comme collection de fichiers, mais on se retrouve avec une base de
données de quelques centaines de milliers de lignes sur laquelle on va
passer des requêtes (au pluriel, hein) pour tenter d'identifier LE
fichier recherché, et ce pour chaque fichier que l'utilisateur va
vouloir accéder. Quand bien même les requêtes ne prendraient que 40 ms,
elles multiplient par 6 le temps d'accès au fichier. Et ça, c'est san s
prendre en compte les problématiques d'accès concurrents au disque, o n
parle d'un user lambda, il va pas acheter des disques à 15000tours pour
stocker sa base et garder ceux à 7200 pour les fichiers (surtout qu'il
n'y a plus d'arborescence, alors tu ne peux pas le faire).
Et c'est pas tout ça, mais une base, ça se maintient. Tu fais comment ?
Tu laisses le système se débrouiller tout seul pour reconstruire ses
indexes, faire ses analyses, ses tris...?
Et pour conclure, le biais essentiel de ton système est qu'au final tou t
repose uniquement sur la saisie de l'utilisateur, alors que tu voulais
justement affranchir cet utilisateur de définir le système de
classement. Pourtant, au retour à la maison, quand l'utilisateur va
insérer la carte de son APN(*) dans le lecteur, le système va lui
demander de décrire toutes les photos qu'elle contient. Aujourd'hui, ça
va, le user rentre seulement de WE avec seulement 200 photos. A raison
d'une minute par photo, il en a pour plus de 3h. Ah, on a une super
photo de Robert qui rigole à côté de la piscine avec un bob ricard sur
la tête, sa femme, Ginette, porte une robe à fleurs ridicule.
L'utilisateur doit (en moins d'une minute pour rappel) trouver la
description de la photo qui fait que dans 3 ou 5 ans, quand il cherchera
cette photo, il la retrouvera. Même pas en rêves. Et si par miracle i l a
réussi, il faut que le système, dans 3 ou 5 ans ne confonde pas avec la
photo où Ginette, la femme de Robert surnommé bob, rigole après un
plongeon dans la piscine de ricard, ce qui la rend ridicule.
Dans la vraie vie, la photo est là:
~/Photos/20090905_WE_en_Normandie/Robert_rigole.jpg, elle est accessible
en lecture à tous les utilisateurs du groupe "famille", est archivée sur
le pool de media "photos", publiée sur un album web, et quand on cherch e
une photo, le logiciel d'album photo permet de le faire. En outre, il
propose des tris pré-renseignés comme les photos les plus consultée s,
les dernières ajoutées...
(*) sur cette carte, il y a un FS FAT32 et une arbo classique, insérer
la carte dans un cadre numérique permet de voir les photos. Plus simple ,
je vois pas.
A+
JF
Jerome Lambert a écrit :
> clics me semble largement préférable, et bien plus efficace *à te rme*.
Ca semble pas intéresser beaucoup de monde ton idée. Peut-être parc e que
dès le départ c'est dans le flou le plus absolu.
Enfin, puisqu'on parle de complications, envisageons le côté perfs. U n
disque dur ordinaire d'aujourd'hui a un temps d'accès de l'ordre de 8ms .
Prenons une machine en desktop d'un utilisateur qu'on pourrait qualifier
"d'ordinaire", quelqu'un qui aurait quelques 40Go de musique, quelques
milliers de photos, quelques centaines de vidéos, et quelques milliers
de fichiers divers (de son CV au dernier pdf de l'Echo des savanes que
le fameux Robert a envoyé par courriel hier). Tout ça est assez faibl e
comme collection de fichiers, mais on se retrouve avec une base de
données de quelques centaines de milliers de lignes sur laquelle on va
passer des requêtes (au pluriel, hein) pour tenter d'identifier LE
fichier recherché, et ce pour chaque fichier que l'utilisateur va
vouloir accéder. Quand bien même les requêtes ne prendraient que 40 ms,
elles multiplient par 6 le temps d'accès au fichier. Et ça, c'est san s
prendre en compte les problématiques d'accès concurrents au disque, o n
parle d'un user lambda, il va pas acheter des disques à 15000tours pour
stocker sa base et garder ceux à 7200 pour les fichiers (surtout qu'il
n'y a plus d'arborescence, alors tu ne peux pas le faire).
Et c'est pas tout ça, mais une base, ça se maintient. Tu fais comment ?
Tu laisses le système se débrouiller tout seul pour reconstruire ses
indexes, faire ses analyses, ses tris...?
Et pour conclure, le biais essentiel de ton système est qu'au final tou t
repose uniquement sur la saisie de l'utilisateur, alors que tu voulais
justement affranchir cet utilisateur de définir le système de
classement. Pourtant, au retour à la maison, quand l'utilisateur va
insérer la carte de son APN(*) dans le lecteur, le système va lui
demander de décrire toutes les photos qu'elle contient. Aujourd'hui, ça
va, le user rentre seulement de WE avec seulement 200 photos. A raison
d'une minute par photo, il en a pour plus de 3h. Ah, on a une super
photo de Robert qui rigole à côté de la piscine avec un bob ricard sur
la tête, sa femme, Ginette, porte une robe à fleurs ridicule.
L'utilisateur doit (en moins d'une minute pour rappel) trouver la
description de la photo qui fait que dans 3 ou 5 ans, quand il cherchera
cette photo, il la retrouvera. Même pas en rêves. Et si par miracle i l a
réussi, il faut que le système, dans 3 ou 5 ans ne confonde pas avec la
photo où Ginette, la femme de Robert surnommé bob, rigole après un
plongeon dans la piscine de ricard, ce qui la rend ridicule.
Dans la vraie vie, la photo est là:
~/Photos/20090905_WE_en_Normandie/Robert_rigole.jpg, elle est accessible
en lecture à tous les utilisateurs du groupe "famille", est archivée sur
le pool de media "photos", publiée sur un album web, et quand on cherch e
une photo, le logiciel d'album photo permet de le faire. En outre, il
propose des tris pré-renseignés comme les photos les plus consultée s,
les dernières ajoutées...
(*) sur cette carte, il y a un FS FAT32 et une arbo classique, insérer
la carte dans un cadre numérique permet de voir les photos. Plus simple ,
je vois pas.
A+
JF
Jerome Lambert a écrit :
> clics me semble largement préférable, et bien plus efficace *à te rme*.
Ca semble pas intéresser beaucoup de monde ton idée. Peut-être parc e que
dès le départ c'est dans le flou le plus absolu.
Enfin, puisqu'on parle de complications, envisageons le côté perfs. U n
disque dur ordinaire d'aujourd'hui a un temps d'accès de l'ordre de 8ms .
Prenons une machine en desktop d'un utilisateur qu'on pourrait qualifier
"d'ordinaire", quelqu'un qui aurait quelques 40Go de musique, quelques
milliers de photos, quelques centaines de vidéos, et quelques milliers
de fichiers divers (de son CV au dernier pdf de l'Echo des savanes que
le fameux Robert a envoyé par courriel hier). Tout ça est assez faibl e
comme collection de fichiers, mais on se retrouve avec une base de
données de quelques centaines de milliers de lignes sur laquelle on va
passer des requêtes (au pluriel, hein) pour tenter d'identifier LE
fichier recherché, et ce pour chaque fichier que l'utilisateur va
vouloir accéder. Quand bien même les requêtes ne prendraient que 40 ms,
elles multiplient par 6 le temps d'accès au fichier. Et ça, c'est san s
prendre en compte les problématiques d'accès concurrents au disque, o n
parle d'un user lambda, il va pas acheter des disques à 15000tours pour
stocker sa base et garder ceux à 7200 pour les fichiers (surtout qu'il
n'y a plus d'arborescence, alors tu ne peux pas le faire).
Et c'est pas tout ça, mais une base, ça se maintient. Tu fais comment ?
Tu laisses le système se débrouiller tout seul pour reconstruire ses
indexes, faire ses analyses, ses tris...?
Et pour conclure, le biais essentiel de ton système est qu'au final tou t
repose uniquement sur la saisie de l'utilisateur, alors que tu voulais
justement affranchir cet utilisateur de définir le système de
classement. Pourtant, au retour à la maison, quand l'utilisateur va
insérer la carte de son APN(*) dans le lecteur, le système va lui
demander de décrire toutes les photos qu'elle contient. Aujourd'hui, ça
va, le user rentre seulement de WE avec seulement 200 photos. A raison
d'une minute par photo, il en a pour plus de 3h. Ah, on a une super
photo de Robert qui rigole à côté de la piscine avec un bob ricard sur
la tête, sa femme, Ginette, porte une robe à fleurs ridicule.
L'utilisateur doit (en moins d'une minute pour rappel) trouver la
description de la photo qui fait que dans 3 ou 5 ans, quand il cherchera
cette photo, il la retrouvera. Même pas en rêves. Et si par miracle i l a
réussi, il faut que le système, dans 3 ou 5 ans ne confonde pas avec la
photo où Ginette, la femme de Robert surnommé bob, rigole après un
plongeon dans la piscine de ricard, ce qui la rend ridicule.
Dans la vraie vie, la photo est là:
~/Photos/20090905_WE_en_Normandie/Robert_rigole.jpg, elle est accessible
en lecture à tous les utilisateurs du groupe "famille", est archivée sur
le pool de media "photos", publiée sur un album web, et quand on cherch e
une photo, le logiciel d'album photo permet de le faire. En outre, il
propose des tris pré-renseignés comme les photos les plus consultée s,
les dernières ajoutées...
(*) sur cette carte, il y a un FS FAT32 et une arbo classique, insérer
la carte dans un cadre numérique permet de voir les photos. Plus simple ,
je vois pas.
A+
JF
C'est l'avenir ... la réponse de l'industrie informatique à la cris e.
C'est l'avenir ... la réponse de l'industrie informatique à la cris e.
C'est l'avenir ... la réponse de l'industrie informatique à la cris e.
... Pas assez compliqué, mon fils .... Et surtout, quelle horreur, tu
dois accéder aux parties intimes du système (l'arborescence). Tu te
rends compte ? Ya des utilisateurs qui en sont choqués ...
... Pas assez compliqué, mon fils .... Et surtout, quelle horreur, tu
dois accéder aux parties intimes du système (l'arborescence). Tu te
rends compte ? Ya des utilisateurs qui en sont choqués ...
... Pas assez compliqué, mon fils .... Et surtout, quelle horreur, tu
dois accéder aux parties intimes du système (l'arborescence). Tu te
rends compte ? Ya des utilisateurs qui en sont choqués ...
totof2000 a écrit :
> ... Pas assez compliqué, mon fils .... Et surtout, quelle horreur, tu
> dois accéder aux parties intimes du système (l'arborescence). Tu te
> rends compte ? Ya des utilisateurs qui en sont choqués ...
Ben... même pas. AmaroK peut gérer les périphériques USB façon iTunes
pour les synchroniser, par exemple. Tu peux sélectionner toutes les
polonaises de Chopin pour les mettre sur ton baladeur sans même savoir
ce qu'est une copie de fichiers. C'est un des points importants qui me
font penser que cette abstraction de l'arborescence ne servirait à rien :
on peut déjà le faire sans.
A+
JF
totof2000 a écrit :
> ... Pas assez compliqué, mon fils .... Et surtout, quelle horreur, tu
> dois accéder aux parties intimes du système (l'arborescence). Tu te
> rends compte ? Ya des utilisateurs qui en sont choqués ...
Ben... même pas. AmaroK peut gérer les périphériques USB façon iTunes
pour les synchroniser, par exemple. Tu peux sélectionner toutes les
polonaises de Chopin pour les mettre sur ton baladeur sans même savoir
ce qu'est une copie de fichiers. C'est un des points importants qui me
font penser que cette abstraction de l'arborescence ne servirait à rien :
on peut déjà le faire sans.
A+
JF
totof2000 a écrit :
> ... Pas assez compliqué, mon fils .... Et surtout, quelle horreur, tu
> dois accéder aux parties intimes du système (l'arborescence). Tu te
> rends compte ? Ya des utilisateurs qui en sont choqués ...
Ben... même pas. AmaroK peut gérer les périphériques USB façon iTunes
pour les synchroniser, par exemple. Tu peux sélectionner toutes les
polonaises de Chopin pour les mettre sur ton baladeur sans même savoir
ce qu'est une copie de fichiers. C'est un des points importants qui me
font penser que cette abstraction de l'arborescence ne servirait à rien :
on peut déjà le faire sans.
A+
JF
photographie), mais pour certains, ça va pas : il faut que ce soit
l'OS qui fasse _TOUT_ ....
photographie), mais pour certains, ça va pas : il faut que ce soit
l'OS qui fasse _TOUT_ ....
photographie), mais pour certains, ça va pas : il faut que ce soit
l'OS qui fasse _TOUT_ ....
Cumbalero a écrit :
> Jerome Lambert a écrit :
>> clics me semble largement préférable, et bien plus efficace *à t erme*.
> Ca semble pas intéresser beaucoup de monde ton idée.
Déjà répondu: ce n'est pas parce que le système classique de
l'arborescence interdit ce genre de manoeuvre que le besoin n'est pas l.
> A mon sens il y a un gros biais de raisonnement dès le départ: les
> applications, et par conséquent les utilisateurs de ces applis se
> foutent généralement de où sont les données, elles leur sont d éjà
> présentées dans un format tel que tu l'attends. Quand tu écoutes des
> MP3s, tu as besoin de savoir où ils sont dans l'arbo? Et les photos? Moi
> non.
Moi non plus. La demande est de justement étendre ce système aux autr es
fichiers.
> De plus, je voudrais bien que tu m'expliques un peu ton système de
> descripteurs de fichiers (les "tags"). Parce que j'envisage
> difficilement qu'un ensemble de ces descripteurs puisse contenir autre
> chose que "taille" et "date de dernière modification" dès que tu va s
> regrouper plusieurs types de fichiers. La tonalité d'une photo par
> exemple, c'est comme l'ouverture pour un morceau de musique, c'est
> précis et ça qualifie un et un seul type de doc. Seulement, la tona lité
> d'un morceau de musique ou l'ouverture pour une photo, ce sont des info s
> qui m'intéressent et que je veux exploiter. Dans le système actuel, je
> peux le faire. Dans le tiens, j'ai un très gros doute.
Déjà répondu aussi: pour les documents autres que photos et audio, on
peut indexer en fonction du contenu, exactement comme un moteur de
recherche indexe des pages web.
(...)
> Enfin, puisqu'on parle de complications, envisageons le côté perfs. Un
> disque dur ordinaire d'aujourd'hui a un temps d'accès de l'ordre de 8 ms.
> Prenons une machine en desktop d'un utilisateur qu'on pourrait qualifie r
> "d'ordinaire", quelqu'un qui aurait quelques 40Go de musique, quelques
> milliers de photos, quelques centaines de vidéos, et quelques millier s
> de fichiers divers (de son CV au dernier pdf de l'Echo des savanes que
> le fameux Robert a envoyé par courriel hier). Tout ça est assez fai ble
> comme collection de fichiers, mais on se retrouve avec une base de
> données de quelques centaines de milliers de lignes sur laquelle on va
> passer des requêtes (au pluriel, hein) pour tenter d'identifier LE
> fichier recherché, et ce pour chaque fichier que l'utilisateur va
> vouloir accéder. Quand bien même les requêtes ne prendraient que 40ms,
> elles multiplient par 6 le temps d'accès au fichier. Et ça, c'est s ans
> prendre en compte les problématiques d'accès concurrents au disque, on
> parle d'un user lambda, il va pas acheter des disques à 15000tours po ur
> stocker sa base et garder ceux à 7200 pour les fichiers (surtout qu'i l
> n'y a plus d'arborescence, alors tu ne peux pas le faire).
Ça, c'est la théorie. En pratique, une recherche bien sentie avec
Spotlight est ici quasi immédiate, avec un disque dur 7200t/min tout ce
qu'il y de classique, et pour info mon profil fait près de 140 Go.
> Et c'est pas tout ça, mais une base, ça se maintient. Tu fais comme nt?
> Tu laisses le système se débrouiller tout seul pour reconstruire se s
> indexes, faire ses analyses, ses tris...?
Ça, j'avoue que d'un point de vue strictement utilisateur je m'en fiche
un peu: je veux un système qui fonctionne, à charge pour ceux dont c' est
le métier de le mettre au point. Après tout, pour reprendre le
comparatif avec un moteur de recherche, je me fiche pas mal de savoir
comment il indexe les pages.
> Et pour conclure, le biais essentiel de ton système est qu'au final t out
> repose uniquement sur la saisie de l'utilisateur, alors que tu voulais
> justement affranchir cet utilisateur de définir le système de
> classement.
Je n'ai pas dis ça, justement. La question ne porte pas sur la
définition du classement mais bien sur le fait qu'en le faisant via
arborescence classique, on obtient quelque chose de *figé*, et c'est ça
qui m'embête.
> Pourtant, au retour à la maison, quand l'utilisateur va
> insérer la carte de son APN(*) dans le lecteur, le système va lui
> demander de décrire toutes les photos qu'elle contient. Aujourd'hui, ça
> va, le user rentre seulement de WE avec seulement 200 photos. A raison
> d'une minute par photo, il en a pour plus de 3h. Ah, on a une super
> photo de Robert qui rigole à côté de la piscine avec un bob ricar d sur
> la tête, sa femme, Ginette, porte une robe à fleurs ridicule.
> L'utilisateur doit (en moins d'une minute pour rappel) trouver la
> description de la photo qui fait que dans 3 ou 5 ans, quand il chercher a
> cette photo, il la retrouvera. Même pas en rêves. Et si par miracle il a
> réussi, il faut que le système, dans 3 ou 5 ans ne confonde pas ave c la
> photo où Ginette, la femme de Robert surnommé bob, rigole après u n
> plongeon dans la piscine de ricard, ce qui la rend ridicule.
> Dans la vraie vie, la photo est là:
> ~/Photos/20090905_WE_en_Normandie/Robert_rigole.jpg,
Non. Dans la vraie vie, elle est là:
~/Photos/20090905_WE_en_Normandie/IMGP01234.jpg
Et là, clairement, il n'y a *aucune* chance de la retrouver, sauf à
passer tout en revue, y compris celles où n'apparaissent ni Robert, ni
Ginette.
Avec un système qui indexe p.ex. via une détection faciale, il me suf fit
p.ex. de demander les photos datées de septembre 2009 où apparaissent
Robert et Ginette et de regarder celle qui correspond.
C'est justement le but de ce genre de systèmes: restreindre la
vérification (toujours nécessaire) aux éléments obéissants aux critères
voulus, et non à tous les éléments situés dans un endroit particu lier de
l'arborescence.
Cumbalero a écrit :
> Jerome Lambert a écrit :
>> clics me semble largement préférable, et bien plus efficace *à t erme*.
> Ca semble pas intéresser beaucoup de monde ton idée.
Déjà répondu: ce n'est pas parce que le système classique de
l'arborescence interdit ce genre de manoeuvre que le besoin n'est pas l.
> A mon sens il y a un gros biais de raisonnement dès le départ: les
> applications, et par conséquent les utilisateurs de ces applis se
> foutent généralement de où sont les données, elles leur sont d éjà
> présentées dans un format tel que tu l'attends. Quand tu écoutes des
> MP3s, tu as besoin de savoir où ils sont dans l'arbo? Et les photos? Moi
> non.
Moi non plus. La demande est de justement étendre ce système aux autr es
fichiers.
> De plus, je voudrais bien que tu m'expliques un peu ton système de
> descripteurs de fichiers (les "tags"). Parce que j'envisage
> difficilement qu'un ensemble de ces descripteurs puisse contenir autre
> chose que "taille" et "date de dernière modification" dès que tu va s
> regrouper plusieurs types de fichiers. La tonalité d'une photo par
> exemple, c'est comme l'ouverture pour un morceau de musique, c'est
> précis et ça qualifie un et un seul type de doc. Seulement, la tona lité
> d'un morceau de musique ou l'ouverture pour une photo, ce sont des info s
> qui m'intéressent et que je veux exploiter. Dans le système actuel, je
> peux le faire. Dans le tiens, j'ai un très gros doute.
Déjà répondu aussi: pour les documents autres que photos et audio, on
peut indexer en fonction du contenu, exactement comme un moteur de
recherche indexe des pages web.
(...)
> Enfin, puisqu'on parle de complications, envisageons le côté perfs. Un
> disque dur ordinaire d'aujourd'hui a un temps d'accès de l'ordre de 8 ms.
> Prenons une machine en desktop d'un utilisateur qu'on pourrait qualifie r
> "d'ordinaire", quelqu'un qui aurait quelques 40Go de musique, quelques
> milliers de photos, quelques centaines de vidéos, et quelques millier s
> de fichiers divers (de son CV au dernier pdf de l'Echo des savanes que
> le fameux Robert a envoyé par courriel hier). Tout ça est assez fai ble
> comme collection de fichiers, mais on se retrouve avec une base de
> données de quelques centaines de milliers de lignes sur laquelle on va
> passer des requêtes (au pluriel, hein) pour tenter d'identifier LE
> fichier recherché, et ce pour chaque fichier que l'utilisateur va
> vouloir accéder. Quand bien même les requêtes ne prendraient que 40ms,
> elles multiplient par 6 le temps d'accès au fichier. Et ça, c'est s ans
> prendre en compte les problématiques d'accès concurrents au disque, on
> parle d'un user lambda, il va pas acheter des disques à 15000tours po ur
> stocker sa base et garder ceux à 7200 pour les fichiers (surtout qu'i l
> n'y a plus d'arborescence, alors tu ne peux pas le faire).
Ça, c'est la théorie. En pratique, une recherche bien sentie avec
Spotlight est ici quasi immédiate, avec un disque dur 7200t/min tout ce
qu'il y de classique, et pour info mon profil fait près de 140 Go.
> Et c'est pas tout ça, mais une base, ça se maintient. Tu fais comme nt?
> Tu laisses le système se débrouiller tout seul pour reconstruire se s
> indexes, faire ses analyses, ses tris...?
Ça, j'avoue que d'un point de vue strictement utilisateur je m'en fiche
un peu: je veux un système qui fonctionne, à charge pour ceux dont c' est
le métier de le mettre au point. Après tout, pour reprendre le
comparatif avec un moteur de recherche, je me fiche pas mal de savoir
comment il indexe les pages.
> Et pour conclure, le biais essentiel de ton système est qu'au final t out
> repose uniquement sur la saisie de l'utilisateur, alors que tu voulais
> justement affranchir cet utilisateur de définir le système de
> classement.
Je n'ai pas dis ça, justement. La question ne porte pas sur la
définition du classement mais bien sur le fait qu'en le faisant via
arborescence classique, on obtient quelque chose de *figé*, et c'est ça
qui m'embête.
> Pourtant, au retour à la maison, quand l'utilisateur va
> insérer la carte de son APN(*) dans le lecteur, le système va lui
> demander de décrire toutes les photos qu'elle contient. Aujourd'hui, ça
> va, le user rentre seulement de WE avec seulement 200 photos. A raison
> d'une minute par photo, il en a pour plus de 3h. Ah, on a une super
> photo de Robert qui rigole à côté de la piscine avec un bob ricar d sur
> la tête, sa femme, Ginette, porte une robe à fleurs ridicule.
> L'utilisateur doit (en moins d'une minute pour rappel) trouver la
> description de la photo qui fait que dans 3 ou 5 ans, quand il chercher a
> cette photo, il la retrouvera. Même pas en rêves. Et si par miracle il a
> réussi, il faut que le système, dans 3 ou 5 ans ne confonde pas ave c la
> photo où Ginette, la femme de Robert surnommé bob, rigole après u n
> plongeon dans la piscine de ricard, ce qui la rend ridicule.
> Dans la vraie vie, la photo est là:
> ~/Photos/20090905_WE_en_Normandie/Robert_rigole.jpg,
Non. Dans la vraie vie, elle est là:
~/Photos/20090905_WE_en_Normandie/IMGP01234.jpg
Et là, clairement, il n'y a *aucune* chance de la retrouver, sauf à
passer tout en revue, y compris celles où n'apparaissent ni Robert, ni
Ginette.
Avec un système qui indexe p.ex. via une détection faciale, il me suf fit
p.ex. de demander les photos datées de septembre 2009 où apparaissent
Robert et Ginette et de regarder celle qui correspond.
C'est justement le but de ce genre de systèmes: restreindre la
vérification (toujours nécessaire) aux éléments obéissants aux critères
voulus, et non à tous les éléments situés dans un endroit particu lier de
l'arborescence.
Cumbalero a écrit :
> Jerome Lambert a écrit :
>> clics me semble largement préférable, et bien plus efficace *à t erme*.
> Ca semble pas intéresser beaucoup de monde ton idée.
Déjà répondu: ce n'est pas parce que le système classique de
l'arborescence interdit ce genre de manoeuvre que le besoin n'est pas l.
> A mon sens il y a un gros biais de raisonnement dès le départ: les
> applications, et par conséquent les utilisateurs de ces applis se
> foutent généralement de où sont les données, elles leur sont d éjà
> présentées dans un format tel que tu l'attends. Quand tu écoutes des
> MP3s, tu as besoin de savoir où ils sont dans l'arbo? Et les photos? Moi
> non.
Moi non plus. La demande est de justement étendre ce système aux autr es
fichiers.
> De plus, je voudrais bien que tu m'expliques un peu ton système de
> descripteurs de fichiers (les "tags"). Parce que j'envisage
> difficilement qu'un ensemble de ces descripteurs puisse contenir autre
> chose que "taille" et "date de dernière modification" dès que tu va s
> regrouper plusieurs types de fichiers. La tonalité d'une photo par
> exemple, c'est comme l'ouverture pour un morceau de musique, c'est
> précis et ça qualifie un et un seul type de doc. Seulement, la tona lité
> d'un morceau de musique ou l'ouverture pour une photo, ce sont des info s
> qui m'intéressent et que je veux exploiter. Dans le système actuel, je
> peux le faire. Dans le tiens, j'ai un très gros doute.
Déjà répondu aussi: pour les documents autres que photos et audio, on
peut indexer en fonction du contenu, exactement comme un moteur de
recherche indexe des pages web.
(...)
> Enfin, puisqu'on parle de complications, envisageons le côté perfs. Un
> disque dur ordinaire d'aujourd'hui a un temps d'accès de l'ordre de 8 ms.
> Prenons une machine en desktop d'un utilisateur qu'on pourrait qualifie r
> "d'ordinaire", quelqu'un qui aurait quelques 40Go de musique, quelques
> milliers de photos, quelques centaines de vidéos, et quelques millier s
> de fichiers divers (de son CV au dernier pdf de l'Echo des savanes que
> le fameux Robert a envoyé par courriel hier). Tout ça est assez fai ble
> comme collection de fichiers, mais on se retrouve avec une base de
> données de quelques centaines de milliers de lignes sur laquelle on va
> passer des requêtes (au pluriel, hein) pour tenter d'identifier LE
> fichier recherché, et ce pour chaque fichier que l'utilisateur va
> vouloir accéder. Quand bien même les requêtes ne prendraient que 40ms,
> elles multiplient par 6 le temps d'accès au fichier. Et ça, c'est s ans
> prendre en compte les problématiques d'accès concurrents au disque, on
> parle d'un user lambda, il va pas acheter des disques à 15000tours po ur
> stocker sa base et garder ceux à 7200 pour les fichiers (surtout qu'i l
> n'y a plus d'arborescence, alors tu ne peux pas le faire).
Ça, c'est la théorie. En pratique, une recherche bien sentie avec
Spotlight est ici quasi immédiate, avec un disque dur 7200t/min tout ce
qu'il y de classique, et pour info mon profil fait près de 140 Go.
> Et c'est pas tout ça, mais une base, ça se maintient. Tu fais comme nt?
> Tu laisses le système se débrouiller tout seul pour reconstruire se s
> indexes, faire ses analyses, ses tris...?
Ça, j'avoue que d'un point de vue strictement utilisateur je m'en fiche
un peu: je veux un système qui fonctionne, à charge pour ceux dont c' est
le métier de le mettre au point. Après tout, pour reprendre le
comparatif avec un moteur de recherche, je me fiche pas mal de savoir
comment il indexe les pages.
> Et pour conclure, le biais essentiel de ton système est qu'au final t out
> repose uniquement sur la saisie de l'utilisateur, alors que tu voulais
> justement affranchir cet utilisateur de définir le système de
> classement.
Je n'ai pas dis ça, justement. La question ne porte pas sur la
définition du classement mais bien sur le fait qu'en le faisant via
arborescence classique, on obtient quelque chose de *figé*, et c'est ça
qui m'embête.
> Pourtant, au retour à la maison, quand l'utilisateur va
> insérer la carte de son APN(*) dans le lecteur, le système va lui
> demander de décrire toutes les photos qu'elle contient. Aujourd'hui, ça
> va, le user rentre seulement de WE avec seulement 200 photos. A raison
> d'une minute par photo, il en a pour plus de 3h. Ah, on a une super
> photo de Robert qui rigole à côté de la piscine avec un bob ricar d sur
> la tête, sa femme, Ginette, porte une robe à fleurs ridicule.
> L'utilisateur doit (en moins d'une minute pour rappel) trouver la
> description de la photo qui fait que dans 3 ou 5 ans, quand il chercher a
> cette photo, il la retrouvera. Même pas en rêves. Et si par miracle il a
> réussi, il faut que le système, dans 3 ou 5 ans ne confonde pas ave c la
> photo où Ginette, la femme de Robert surnommé bob, rigole après u n
> plongeon dans la piscine de ricard, ce qui la rend ridicule.
> Dans la vraie vie, la photo est là:
> ~/Photos/20090905_WE_en_Normandie/Robert_rigole.jpg,
Non. Dans la vraie vie, elle est là:
~/Photos/20090905_WE_en_Normandie/IMGP01234.jpg
Et là, clairement, il n'y a *aucune* chance de la retrouver, sauf à
passer tout en revue, y compris celles où n'apparaissent ni Robert, ni
Ginette.
Avec un système qui indexe p.ex. via une détection faciale, il me suf fit
p.ex. de demander les photos datées de septembre 2009 où apparaissent
Robert et Ginette et de regarder celle qui correspond.
C'est justement le but de ce genre de systèmes: restreindre la
vérification (toujours nécessaire) aux éléments obéissants aux critères
voulus, et non à tous les éléments situés dans un endroit particu lier de
l'arborescence.
