Journal Où sont les filesystems orientés DB?

Posté par  . Licence CC By‑SA.
Étiquettes :
32
11
sept.
2019

Bonjour à tout le monde et aux autres aussi,

Un exposé, une question et un rêve

Exposé : de quoi est-il question?

En tentant d'organiser les dizaines de milliers de fichiers que j'ai amassés en quelques décennies de vie numérique, je me suis rappelé des technos qui ont existé ou sont restées à l'état de projet, mais dont je ne connais aucune implémentation actuelle. Je veux parler des systèmes de fichiers orientés DB.

L'idée est que les fichiers ne sont plus classés en répertoires hiérarchiques mais indexés selon leur contenu et leurs métadonnées. Je donne un exemple simple: dans une société, on peut créer un répertoire par année (2017, 2018, 2019), puis un niveau plus bas un répertoire par client (Dupont, Martin, Durand), et dans chaque répertoire client un répertoire par type de document (offres, factures, relances…). On a donc Année -> Client -> Type_document. Mais on aurait pu organiser ça autrement, par exemple Client -> Type_document -> Année.

Si je veux retrouver les factures de M. Dupont pour l'année 2018, ce qui compte en réalité n'est pas cet ordre d'accès, mais le fait que je cherche quelque chose qui est à l'intersection des critères {2018, Dupont, Facture}. Et une recherche sur des critères, c'est quelque chose que les bases de données font très bien. D'où l'idée d'intégrer les services d'un moteur de DB au filesystem sous-jacent.

L'idée est réellement différente d'une indexation automatique qu'on applique à une arborescence. Je sais que ça existe mais ce n'est pas de cela que je veux parler ici.

La question : où en sommes-nous?

Il y a bien eu BeOS avec son merveilleux BFS. Je sais aussi que Reiser4 aurait dû à terme intégrer ce genre de chose. Il y a eu le projet WinFS chez Microsoft. Mais on parle là de technos respectivement sorties ou abandonnées en 1995, 2004 et 2006. Si je ne parle pas de Spotlight de nos amis à la pomme, c'est seulement parce que je n'ai jamais eu l'occasion de l'utiliser, n'y voyez aucune censure. Et donc je me pose cette question: Un quart de siècle après BFS, alors que le besoin est encore là, où en est-on?

Le rêve : ce que j'aimerais pouvoir utiliser un jour

Mon système idéal fonctionnerait à peu près comme ceci:

  • quand on y dépose un fichier, le système commence par vérifier que ce fichier n'est pas déjà présent quelque part. En fonction des paramètres, cette vérification pourrait être stricte (identité bit à bit du contenu et des métadonnées), sur le contenu seul, ou plus souple (par exemple, si une photo identique à l'orientation près est trouvée, on peut décider de s'arrêter là ou non, de manière paramétrée ou interactive)
  • si un fichier est considéré comme nouveau, il est ajouté au système avec quelques tags qui sont générés automatiquement (type, date de création,…)
  • en fonction du type, des plugins analysent le fichier pour en extraire des [méta]données qui sont proposées comme tags: les tags ID3 d'un MP3, les données EXIF d'un JPEG, les mots d'un document PDF ou ODT (avec un dictionnaire des mots à ne pas indexer, par exemple)
  • l'utilisateur peut aussi ajouter ses propres tags: sur la photo, c'est Durand, c'est l'anniversaire de la petite dernière, c'est le voyage de noces…

Des plugins système pourraient permettre de taguer d'autres choses, comme les emails, par exemple (BeOS les indexait, je crois). En une recherche, on pourrait trouver les mails envoyés par Dupont et les photos sur lesquelles il apparaît et sa vCard.

Bien sûr, je parle ici de tout ce qu'on peut considérer comme un document. Les besoins sont propres à chacun: bien que ce soient des fichiers, je ne me vois pas taguer mon noyau Linux ou mon .bash_history, mais vous avez peut-être d'autres pratiques que moi.

Au final en tout cas, une masse de fichiers plus organisée et une interface de recherche par tags qui me semble plus appropriée que les répertoires quand il s'agit de dizaines de milliers de documents.

Je suis bien incapable de créer un tel système, mais qu'est-ce que j'aimerais l'utiliser!

  • # Facile

    Posté par  . Évalué à 6.

    Suffit de mettre en tant que nom de fichier : année-client-type

    • [^] # Commentaire supprimé

      Posté par  . Évalué à -10. Dernière modification le 11 septembre 2019 à 16:41.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # le roi est mort, vive le roi

        Posté par  . Évalué à 3. Dernière modification le 11 septembre 2019 à 21:30.

        Je sais bien qu'il ne faut pas nourrir le troll, mais puisque je n'avais pas "moinßé" (rassure-toi le terme ne prend qu'un seul "s") depuis 2001 et que je ne suis pas barbu (sauf le WE), je ne résiste pas à l'envie de te répondre.
        Ne pourrais-tu pas utiliser ton verbe et ton temps à poster des commentaires plus constructifs ? Je t'y invite, ainsi qu'à éviter l'utilisation abusive du subjonctif qui trahit ton caractère pédant, car nous sommes sur linuxfr tributaires des barbus (ou pas) nés à partir du 4 février 1943.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à -2.

          Ce commentaire a été supprimé par l’équipe de modération.

  • # Pas de marché, pas d'applis donc pas d'implem

    Posté par  . Évalué à 10.

    Quasiment aucun humain ne sait tagger ses fichiers. Déjà que les gens savent pas ranger Mes Documents, le combat est perdu d'avance. Et tous les projets de filesystem façon base de données sont toujours tombés sur un couac : les nouvelles features, c'est bien, mais de toute façon 99.99% des applis existantes considèrent et considèreront qu'un filesystem est une arbo et juste une arbo.
    C'est une solution qui est en cherche d'un problème que ça pourrait résoudre mieux que l'existant.
    - Si c'est pour tagger des fichiers et les requêter, t'as soit les tags internes aux différents formats de fichiers ou les milliers de solutions de gestion documentaire qui font déjà ça.
    - Si c'est pour la vitesse de requête de ces infos, tous les OS orientés GUI et les environnements de bureau ou presque ont un index avec grosso modo les infos dont tu parles. Ça s'appelle Windows Search sous Windows par exemple.
    - Si c'est pour optimiser le stockage des fichiers avec une structure style base de données, ben les bases de données le font déjà avec les blobs ou les pointeurs vers des fichiers sur le disque avec index fulltext.
    Bref, toutes les solutions existent déjà, sans le besoin pureté magnifique d'un filesystem hypothétique avec ce modèle. La réalité moche a déjà gagné face au beau design.

    • [^] # Re: Pas de marché, pas d'applis donc pas d'implem

      Posté par  . Évalué à 8.

      Il me faut malheureusement te donner raison et en particulier sur le point qui fait que les applis développeurs ne voient le fs que comme une arborescence, je n'avais pas pensé à ce point important.

      Sauf peut-être sur BeOS, où les développeurs qui écrivaient pour ce système en connaissaient les spécificités et en tenaient compte. C'est dur d'être en avance sur son temps!

      Je retourne donc classer mes photos dans des boîtes à chaussures ;-)

      • [^] # Re: Pas de marché, pas d'applis donc pas d'implem

        Posté par  . Évalué à 9.

        Je retourne donc classer mes photos dans des boîtes à chaussures ;-)

        Les photos, c'est un besoin spécifique, et Digikam répond à tous tes besoins décrits pour un système de fichiers DB : détection des doublons, navigation suivant les metadonnées.

        Je me régale avec depuis des années, et mes photos remontent aux années 60 sans souci.

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # De l'importance de l'organisation spatiale des documents

    Posté par  . Évalué à 7.

    Souvenons-nous des débats au sujet du gestionnaire de fichiers Nautilus de GNOME quand il est passé au mode spatial.

    Le débat fait encore rage, mais il reste que bon nombre d'êtres humains abordent plus facilement le classement de leurs fichiers ou de leurs mails de manière spatiale.
    Il suffit de voir à quel point le système de tags de Gmail peut être perturbant.

    Et comme dit plus haut, il y a un gros problème d'UX dans la gestion des meta-données : c'est pas agréable et facultatif alors la solution de facilité de ne pas les renseigner est trop tentante.
    Il faudrait des UI vraiment bien pensées couplées à des "IA" pour suggérer voir pré-renseigner ces meta-données pour que ça prenne vraiment.

    BeOS le faisait il y a 20 ans !

    • [^] # Re: De l'importance de l'organisation spatiale des documents

      Posté par  . Évalué à 6.

      Bien vu, c'est sans doute un domaine où l'IA pourrait apporter un début de solution au problème de l'étiquetage qui —quelle que soit la méthode utilisée— reste une tâche fastidieuse.

    • [^] # Re: De l'importance de l'organisation spatiale des documents

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

      Je ne comprends pas cette focalisation sur la gestion de tags, y compris dans le billet de départ.

      Prenons un tel système de fichiers. On peut facilement imaginer (et un projet que j’avais suivi il y a des années — je ne me souviens plus du nom — avait une approche similaire) que :

      • Ça présente une arborescence classique, dans laquelle les programmes divers se retrouvent facilement.
      • Un mkdir toto à la racine crée implicitement un tag toto.
      • Déposer un fichier dans le « répertoire » toto enregistre cet objet-fichier avec le tag toto, automatiquement.
      • Créer un lien avec ln toto/nom1 titi/nom2 assigne implicitement le tag titi au document pointé par nom1 ou nom2, en plus du tag toto.

      Évidement, ça ne répond pas à toutes les questions :

      • Que signifie un lien symbolique ? Vers le même FS ; vers un autre FS ?
      • Que se passe-t-il si on dépose à la racine du FS ? Non-classifié ?
      • Quid des « sous-répertoires » ? repA/repB/file serait-il simplement l’assignation du tag repA/repB au document file ?

      En tout cas, ça forme une base qui me semble extrêmement simple, que l’utilisateur lambda peut utiliser aussi naturellement qu’un ext4, sans être obligé de profiter des fonctionnalités avancées.

      Bon… mais… finalement, tout ceci n’est-il pas déjà réalisable avec ext4, justement ? Les liens pas symboliques peuvent aider. Il suffirait (presque) d’être organisé. Le hic, c’est les applications qui, quand elles enregistrent une modifications, créent un nouveau fichier (inode) puis suppriment l’ancien. Donc non, on n’y est pas encore, mais il ne manque pas grand chose pour que ça convienne.

  • # Aucun intérêt réel.... voir même une totale ineptie.

    Posté par  . Évalué à 10.

    Je te rejoins sur ce besoin d'indexation.
    Par contre, implémenter ça sur un filesystem, c'est juste totalement insensé !

    Mais on parle là de technos respectivement sorties ou abandonnées en 1995, 2004 et 2006.

    C'est peut être pas pour rien …

    Pour répondre à ton "système" idéal:

    quand on y dépose un fichier, le système commence par vérifier que ce fichier n'est pas déjà présent quelque part. En fonction des paramètres, cette vérification pourrait être stricte (identité bit à bit du contenu et des métadonnées), sur le contenu seul, ou plus souple (par exemple, si une photo identique à l'orientation près est trouvée, on peut décider de s'arrêter là ou non, de manière paramétrée ou interactive)

    1. Wow, paye ton overhead lorsque tu copies les 14GiB de photo de la SD de 16GiB de ton reflex numérique sur ton FS et que ce dernier va devoir se palucher l'analyse de XXX * 2 (JPEG + RAW) fichiers de 40 MPixel… D'ailleurs, comment sont gérés les "duplicats logiques" dans ce cas (Aka: le RAW qui ressemble comme deux gouttes d'eau au JPEG de preview ?).
    2. J'ai aucune envie que mon FS soit intelligent à ma place. Au contraire, il y a des fois ou la duplication est nécessaire et voulue (le RAW + JPEG de l'exemple précédent, FW livré à deux clients différents qui est en fait le même, la clef de crypto utilisé pour X produits différents, le .h commun à deux toolchains différentes, le morceau de tel artiste dans le CD de l'album ET dans le best of, etc…)

    si un fichier est considéré comme nouveau, il est ajouté au système avec quelques tags qui sont générés automatiquement (type, date de création,…)

    Bein c'est déjà ce qui est fait dans la "base de données" propre au filesystem.

    en fonction du type, des plugins analysent le fichier pour en extraire des [méta]données qui sont proposées comme tags: les tags ID3 d'un MP3, les données EXIF d'un JPEG, les mots d'un document PDF ou ODT (avec un dictionnaire des mots à ne pas indexer, par exemple)

    Non, définitivement non.
    Pour peu que ton système soit pas customisée, tu vas rajouter encore de l'overhead en veux tu en voilà sans que le besoin réel existe dans 90% des cas (le webmaster qui pousse ses bannières & co, ses PDFs, etc…).
    Sans compter que tu sembles oublier qu'il y a des tonnes de PDF, MP3, JPG, PNG installés sur le FS par ton gestionniaire de paquet et pour lesquels il n'y a aucun besoin d'indexation (icones, son de notification, docs, …).
    Et même si tu limites l'usage de ton FS au $HOME d'un desktop, tu vas te retrouver à analyser une tonne de choses inutilement (le cache de ton browser par exemple).

    l'utilisateur peut aussi ajouter ses propres tags: sur la photo, c'est Durand, c'est l'anniversaire de la petite dernière, c'est le voyage de noces…

    Ce n'est pas le rôle d'un FS.

    Des plugins système pourraient permettre de taguer d'autres choses, comme les emails, par exemple (BeOS les indexait, je crois). En une recherche, on pourrait trouver les mails envoyés par Dupont et les photos sur lesquelles il apparaît et sa vCard.

    On a déjà vu le résultat de ce type de features sur les smartphone ou dans les environnements de bureau tout intégrés (GNOME avec Evolution, Pidgin & co; Kde aussi j'imagine): ça marche mal. Parce qu'un coup, Dupont envoie ses mails depuis son téléphone, et là t'as "Benjamin D." dans le From:, d'autres coups depuis son PC et t'as "Ben Dupont", l'autre fois depuis son PC du taf et tu te choppes "Benjamin Dupont - Evil Corp. - Software Engineer"…

    Bien sûr, je parle ici de tout ce qu'on peut considérer comme un document

    Ok… et c'est quoi un document ?
    Chaque usage à sa définition, le fan de retouche photo, le gamer, l'écrivain en herbe, les besoins sont aussi nombreux que les gouts de chacun.

    Après, tu évoques plusieurs fois un système de plugin … mais tu parles de filesystem !
    Pour rappel, tu as:
    * Les filesystems kernel-land, les plus performants et robustes.
    * Les filesystems type FUSE, moins performants car implémentés en user-land et de robustesse très variable.

    J'imagine que dans ton idéal de FS, tu le voudrais kernel-land … vu l'overhead que tu vas ajouter, si en plus c'est full user-land, tu vas avoir l'impression que ton SSD s'est transformé en disque IDE UDMA33 !
    Et donc, de ce coup, pour remplir ton besoin, il va falloir implémenter en kernel-land:
    * Le parsing des JPEGs.
    * Le parsing des EXIFS.
    * Le parsing des MP3.
    * Le parsing des PDFs.
    * Le parsing de …
    * Des algos de reconnaissance faciales
    * Des algos de reconnaissance de son (MP3 en 128kbit/s d'un côté, MP3 en 256kbit/s ou FLAC de l'autre)

    Tu vois ou je veux en venir ? Le kernel, c'est une librairie C très limitée et il n'y a rien aujourd'hui pour faire ce que tu évoques…
    La seule chose pour répondre partiellement à ton besoin, ça va être le sous-système crypto qui va te permettre de faire des hash de fichier pour vérifier les duplicats…

    En outre, tu sembles oublier l'un des principes les plus importants de la philosophie Unix: le Principe_KISS.

    Un système de fichiers, c'est fait pour stocker des fichiers. POINT. La force d'un système de fichier avec cette hierarchisation par répertoire, c'est que ça marche bien et que tout est fichier. C'est simple à backuper, que ce soit en bourrin ou en incrémental, c'est simple de rechercher les différences, c'est simple de lister, et c'est simple d'organiser à sa sauce.

    Si tu veux indexer les dits fichier, utilise un soft qui est fait pour ça, configure le pour qu'il indexe les fichiers qui t'intéressent dans les repertoires qui t'intéressent selon les critères qui t'intéresse.

    Je te rejoins totalement sur la pertinence du besoin.
    Mais de mon humble point de vue, il ne faut pas implémenter ça dans un filesystem en kernel-land.

    Il faut plutôt faire un daemon qui se configure (analyse les PDF || JPG dans ~/Documents, mes MP3 dans ~/Musique, …) et utilise ensuite inotify pour surveiller les fichiers et faire l'indexation en tâche de fond. Si le soft découvre des doublons, il pousse une notification sur D-bus, notification récupérée par l'applet dédiée qui t'informe du doublon et te demande l'action à prendre.

    Je crois qu'il y a pas mal de soft existant dans ce domaine, une recherche google "file indexer linux" renvoie pas mal de résultat en tout cas…

  • # Ça existe... partiellement

    Posté par  (Mastodon) . Évalué à 5. Dernière modification le 11 septembre 2019 à 14:58.

    Au moins pour le MP3 : https://khenriks.github.io/mp3fs/

    EDIT : ah merde non, je suis allé un peu vite, c'est pas exactement l'objet du journal.

    En tous cas utiliser FUSE est sûrement la bonne idée. On laisse le FS natif de l'OS s'occuper des octets, et ensuite par dessus on met une couche d'abstraction basée sur le besoin utilisateur.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Tout l'ecosystem est à revoir

    Posté par  (Mastodon) . Évalué à 6.

    Un tel type de filesystem ne peut fonctionner sans remplacer toutes les applications, voilà pourquoi. Chaque application utilisée doit pouvoir utiliser les metadonnées pour te donner accès aux dits fichiers. Sans ça c'est voué à l'échec.

    Et pour ça il faudrait réussir à imposer un standard, et une ludothèque qui remplace complètement et surpasse ce qu'on trouve sous linux, mac et windows réunit. Ce qui est impossible par une organisation seule.

    Voilà pourquoi ça n'a jamais pris. À la place de ça on a des indexeurs sur chaque OS plus ou moins gourmands selon les implémentations qui vont remplir une DB pour te donner accès aux documents les plus pertinents. C'est peut-être moins bien mais c'est mieux que rien.

    • [^] # Re: Tout l'ecosystem est à revoir

      Posté par  . Évalué à 3.

      Et même plus dur, il faut que les « ontologies » quand tu passes d’un système à l’autre soient cohérentes entre elles, donc faut standardiser un minimum les métadonnées. C’est ce qui se fait à l’échelle du web avec des projets comme https://schema.org/ mais ça pose sans doute des tas de problème à prendre comme base dans un fs : évolution des ontologies et versioning, incompatibilité éventuelles des métadonnées si jamais personne n’a réussi à se mettre d’accord …

      Si on prend l’exemple d’une application maison qui veut écrire des données quelconques sur disque dans un format interne, que mettre en métadonnées à part « blob » ?

  • # tags, spotlight, dossiers intelligents dans macOS

    Posté par  . Évalué à 3.

    une description de l'usage des tags
    https://forums.cnetfrance.fr/topic/1209488-mac-os-x-mavericks--bien-utiliser-les-tags-du-finder/

    dans les programmes on peut aussi le gérer (et aussi renommer/déplacer un fichier pendant qu'il est ouvert)
    https://www.macrumors.com/how-to/files-folders-tags-macos/
    section "How to Tag Open Files You're Working On"

    le système de fichier HFS+ de macOS et donc aussi d'iOS à su évoluer au cours du temps, sans reformater, il a maintenant des capacités intéressantes comme la déduplication, acl en plus des droits Unix de base, métadonnée, commentaire…
    voici un avis éclairé ;) :
    https://www.macg.co/os-x/2015/01/hfs-est-certainement-le-pire-systeme-de-fichiers-selon-linus-torvalds-86727

    Je me sers beaucoup de spotlight pour retrouver, par le contenu ou nom, pdf et doc type word ou excel

    Pour les fichiers de dev c'est souvent via l'IDE

    Je me sers pas mal des dossiers intelligents, ça agit comme des requêtes spotlight en live sur le file système

    Dans Mail d'Apple sur macOS, ou j'ai plusieurs comptes, j'utilise

    • Des règles pour classer des emails envoyés par des taches, robots…

    • Des dossiers intelligents (ou j'ai exclu certains dossiers) :

    • non lu

    • moins de 24 heures

    • moins de 7 jours

    • qui ont un suivi

    • les notes du fiston non lu

    J'ai du arriver un jour avec plus de 400 000 emails quand je bossais sur macOS maintenant je suis sur Windows et je pleure, je connais bien Linux, mais en ligne de commande pas en desktop.

  • # Commentaire supprimé

    Posté par  . Évalué à 7.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Voir le «Semantic Desktop»

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

    Où des outils indexent pour toi tout ce qui passe par ta machine (fichiers, emails, vcards…) et te permettent des recherches.

    Il y a eu des recherches autour de Nepomuk, intégré dans KDE. L'outil d'indexation des fichiers en tache de fond se nomme Baloo, il crash encore un peu trop souvent à mon gout, et j'ai eu quelques surprises sur le volume occupé par l'index.

    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

    • [^] # Re: Voir le «Semantic Desktop»

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

      justement l'idée était, au moins chez GNOME, la disparition des gestionnaires de fichiers au profit d'applications dédiées sur tel ou tel usage ; or ça n'a pas pris.

      Le problème du fichier et du gestionnaire de fichier c'est qu'étonnement, en dépit d'une métaphore un peu foireuse, les gens comprennent extrêmement bien ce point. (Et pourtant les gens sont idiots, je le rappelle.)

    • [^] # Re: Voir le «Semantic Desktop»

      Posté par  . Évalué à 5. Dernière modification le 12 septembre 2019 à 15:36.

      La vision de ce qui est décrit, est, il me semble, la vision originelle qui a mené à écrire Tracker. Ça reste encore assez explicite sur la page de description du projet.

      Users may completely move away from a folder-hierarchy based home folder, and instead organise their data into collections using tags.

      (traduction)

      Les utilisateurs peuvent se détacher entièrement d'un dossier personnel de type arborescence de dossier et au lieu de cela organiser leurs données en collections, en utilisant des étiquettes.

      Le seul hic en général c'est que Tracker est resté un peu confidentiel, par manque d'interfaces autour, par son développement lent et par manque de mise en avant par les distributions. De fait la fonctionnalité la plus visible pour beaucoup est l'entrée "Récents" de Gnome File (aka Nautilus).

      Tracker lui même a profité du travail sur Nepomuk et les ontologies fabriquées par le projet.
      voir la page des fonctionalités

      The Nepomuk ontologies are followed as closely as possible.

      (traduction)

      Les ontologies Nepomuk sont suivies au plus près possible.

      Perso j'ai toujours trouvé ce projet très intéressant, mais je ne le suis pas d'assez prêt !

  • # Android?

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

    Le système que tu décris corresponds à l'IHM d'Android.

    Résultat: les gens ne savent pas où sont leurs fichiers, galèrent pour les récupérer et les perdent régulièrement parce oh zut c'était sur la carte sd et pas sur la mémoire du téléphone?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Android?

      Posté par  . Évalué à 3.

      C’est pas plus un soucis d’implémentation qui néglige d’exposer une information fondamentale pour les utilisateurs, genre si ils vont réussir à copier leurs données en bougeant la carte SD, qu’un soucis fondamental de l’approche ?

      On peut considérer qu’un bon système exposerait le(s) emplacements physiques des fichiers si c’est important pour les utilisateurs (et ça l’est bien souvent). Cela dit avec les approches « cloud » ça les arrange plus de forcer l’utilisateur à cocher « faites automatiquement une copie de sauvegarde, ne vous souciez de rien, tu es un sanglierhttps://totoz.eu/img/sanglier%20tu%20es

      • [^] # Re: Android?

        Posté par  . Évalué à 3.

        En effet je pense que le cloud est une des raisons de cela. De plus, gdrive n'a aucune notion de chemin réel, c'est une métadata comme les autres du coup tu peux avoir des comportements "rigolos" avec deux fichiers avec le meme nom dans le "meme repertoire" (seul le "chemin" et le nom sont commun).

    • [^] # Re: Android?

      Posté par  . Évalué à 1.

      oh zut c'était sur la carte sd et pas sur la mémoire du téléphone?

      C'est donc pour ça que les constructeurs tendent à retirer le support des cartes SD pour ne laisser qu'une mémoire interne ? :)

      • [^] # Re: Android?

        Posté par  (Mastodon) . Évalué à 2. Dernière modification le 12 septembre 2019 à 09:01.

        C'est donc pour ça que les constructeurs tendent à retirer le support des cartes SD

        Entre autre oui. En fait cette phrase est partiellement fausse, Google veut (inutile de dire que pour lui tout devrait être dans le cloud), mais les autres OEM résistent parce que c'est un sacré argument marketing.

        J'ai bossé côté constructeur dans l'integration Android, et la gestion de la carte SD amovible est un enfer. Pour mille petits détails, mais disons que généralement c'est "ok, je suis censé écrire sur la carte SD et elle n'est pas là, je fais quoi ?".

        Il existe depuis qques Android récents (je ne saurais dire, j'ai arrêté le suivi des versions) une option pour "fixer" la carte SD : elle fait maintenant partie du système et t'es plus censé l'enlever. Ainsi plus de questions (je suppose) : si ça marche pas, c'est la faute de l'utilisateur.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Android?

          Posté par  . Évalué à 2.

          La phrase était à prendre au second degré ;) (j'ai mis un simple smiley faute de savoir faire un point d'ironie sans aller le copier depuis ailleurs).
          Google n'est d'ailleurs pas le seul à vouloir. Xiaomi fait pareil sur ses flagship et propose justement une offre de stockage cloud très (trop?) intégrés à ses applications (des fonctionnalités a priori locales ne sont pas accessible sans acceptation de la synchro cloud :( ).

  • # certains ont été vaccinés...

    Posté par  . Évalué à -4.

    Je pense en particulier avec Microsoft. Le dev de ce FS pour Longhorn a fait qu'ils ont pris tellement de retard que un petit systeme meme pas dans le rétroviseur a été sur le point de les dépasser. Heureusement ils avaient la vente liés, SCO et les brevets puis ils ont sortie la merde de Vista pour gagner du temps.

  • # Sur macOS

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

    Sur macOS, le moteur d'indexation (Spotlight) fonctionne depuis 13 ans environ, concerne l'ensemble du système et fonctionne avec le moteur d'historique (TimeMachine).
    C'est séparé du système de fichiers mais chaque application peut lui amener des infos.
    Par défaut, les métadonnées ID3, EXIF, PDF, et autres classiques sont analysées et enregistrées automatiquement.

    De plus, le Finder vient avec un système de tags (un simple couple couleur/nom, par exemple rouge/important, vert/travail, bleu/maison, etc.). Je peux ajouter des tags et des commentaires à n'importe quel fichier.

    J'ai un champ de recherche accessible en permanence. Si j'y tape le nom d'une personne, par exemple Nicolas Bourbaki, j'ai accès à :
    - sa fiche de contact qui contiendra au hasard l'adresse nb@ens.fr et son surnom «Cauchy»,
    - tous les mails qui contiennent nb@ens.fr, Nicolas Bourbaki ou Cauchy,
    - les pages web qui parlent de lui dans mon historique de navigation internet,
    - les morceaux de musique qui y font référence,
    - de façon générale, les fichiers qui y font référence (dans le titre, le contenu ou les métadonnées),

    Mais ça va un peu plus loin, vu que si j'ouvre l'application Photos et que je vais dans la rubrique « Personnes », j'aurais toutes les photos de Nicolas Bourbaki dès que j'aurais associé son nom à son visage sur une seule photo. Je peux également chercher les photos faites à proximité d'un lieu (si les coordonnées sont enregistrées, souvent le cas avec les téléphones ou si c'est fait a posteriori dans le logiciel).

    Si j'ouvre le calendrier, je peux rechercher tous les événements ajoutés depuis un mail de Bourbaki ou qui y font référence directement.

    Si j'ouvre Plans et que j'y tape son nom, il va m'afficher son adresse s'il la connaît (via mes contacts, par exemple).

    Maintenant, ce n'est pas encore fini : la plupart des applications permettent de faire des « dossiers intelligents » (autrement dit, des critères de recherche enregistrés) qui se basent sur cette indexation :
    - Contacts aura un dossier « contacts dont l'adresse est à Paris, qui ont été ajoutés dans les 6 derniers mois et dont l'anniversaire est dans les 15 jours »,
    - Mail aura un dossier « mails non lus de la semaine qui contiennent le mot urgent »,
    - Finder aura un dossier « fichiers avec le tag rouge/important »,
    - Photos aura un dossier « photos de Bourbaki prises par un Sony Coolpix »,
    - iTunes aura un dossier « chansons des années 80 les moins écoutées ».

    Pour finir, je parlais de TimeMachine : toutes ces possibilités fonctionnent avec le « voyage dans le temps » :
    - je supprime Bourbaki de mes contacts,
    - je lance l'application Contacts et j'ouvre la liste des mathématiciens,
    - j'appelle TimeMachine,
    - je choisi la semaine précédente,
    - la fiche de Bourbaki apparaît à nouveau et je peux alors la restaurer.

    Bref, j'ai l'impression que ce que tu souhaites existe déjà, dans une large mesure.

    • [^] # Re: Sur macOS

      Posté par  . Évalué à -1.

      c'est vraiment révolutionnaire, as tu la vidéo de la keynote où cela a été introduit ?

    • [^] # Re: Sur macOS

      Posté par  . Évalué à 4.

      Merci pour l'info, faudra vraiment que j'essaie un Mac à l'occasion. Les dossiers intelligents existaient dans BeOS, ce n'est donc pas une nouveauté mais une incarnation du concept qui a le mérite d'être dans un système qui n'est pas mort.

      Reste qu'associer Bourbaki à un seul visage, c'est, comment dire… ;-)

    • [^] # Re: Sur macOS

      Posté par  . Évalué à 3. Dernière modification le 12 septembre 2019 à 14:35.

      Ce qui m'inquiète dans ce genre de techniques, c'est que quand elles se font dans un système à code fermé, lequel est connu pour communiquer en permanence et de manière opaque avec les serveurs de l'éditeur (et je ne parle pas seulement d'Apple, évidemment, MS et surtout, surtout Google font la même, en mieux, ainsi que les fabricants de spyphones — je parle du pont de données entre notre ordi ou phone et leurs serveurs), le transfert des données personnelles en devient beaucoup plus efficace.

      En fait, ça revient pour les aspirateurs de données à charger les victimes de faire eux-mêmes une bonne partie du traitement sur leurs données pour qu'elles soient prêtes (ou mieux préparées) à être avalées par les fermes de données.

      De même, on peut imaginer que la police, dont le but avoué est maintenant de pouvoir contrôler indifféremment n'importe quel citoyen, puisse trouver avantage à ce système, pouvant télécharger sélectivement le contenu qui les intéresse (par ex. dans ton cas faire une recherche dans les contenus et s'intéresser de plus près à cet ordi précis si la simulation d'une IA leur a prouvé que Bourbaki est un dangereux terroriste qui cherche à grouper dans un ensemble commun les extrémistes chiites et sunnites) (en plus, avec un nom comme ça… :-P). Une recherche dans les index de millions d'ordis serait infiniment plus efficace, plus rapide et moins gourmande qu'une recherche dans les données brutes de ces ordis.

      Il est bien dommage qu'on soit arrivés à une époque où tout progrès dans l'interface de manipulation de nos données puisse être indifféremment interprété également comme progrès de l'espionnage.

      Nous avons nous l'avantage d'avoir un système qui nous permette de maintenir le contrôle sur nos données (et encore, le paragraphe sur la police pourrait bien s'appliquer aux moins bien protégés de nous), mais comme on le sait, cela représente une très petite minorité des ordis personnels et ordiphones en circulation.

  • # À la souris ?

    Posté par  . Évalué à -4.

    Un FS orienté DB, c'est une super idée mais ça ne marcherait pas car on ne peut pas le parcourir à la souris. Ça oblige à taper des trucs et donc le public n'en voudra pas… :(

  • # GED

    Posté par  . Évalué à 6.

    En fait ce que tu décrit a toutes les caractéristiques d'une GED. On en trouve à foison sur le marché que ce soit libre ou propriétaire

  • # Besoin d'une surcouche ?

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

    Comme dit précédemment, je suis assez ok pour que ça ne soit pas le FS qui fasse tout ça. Du coup, une idée serait de rajouter une surcouche au FS un peu à la iRODS.

  • # BFS

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

    BFS existe toujours et fonctionne très bien sur Haiku. Par contre ça manque toujours d'application exploitant vraiment ces fonctions. On passe beaucoup par le gestionnaire de fichier pour faire certains trucs, mais ça suppose d'utiliser la même interface pour gérer les mails, la musique, les photos, etc, et c'est pas super pratique.

    Il y a aussi un tas de problèmes d'interopérabilité, quand on copie un fichier vers une clé usb en FAT, les attributs qui permettent d'indexer les fichiers ne sont pas préservés par exemple, et plus embêtant, on risque de perdre ces atttributs si on essaie de faire un "cp" en ligne de commande, par exemple, parce que par défaut ça ne copie que le contenu.

    Il y a aussi le problème que la plupart des formats de fichiers (mp3 avec les tags id3, jpeg avec exif, …) ont développé des solutions pour stocker les attributs plutôt dans le fichier, et du coup, il faut synchroniser ces deux modes de fonctionnement (et la correspondance n'est pas toujours directe).

    Donc techniquement, on sait faire, mais pour l'expérience utilisateur, c'est pas encore ça.

  • # Et pourquoi pas utiliser recoll sous Linux?

    Posté par  . Évalué à 3. Dernière modification le 13 septembre 2019 à 09:34.

    Avec Recoll, il suffit d'ajouter les fichiers python pour accéder aux différents formats, indexer la première fois, et le résultat est fulgurant, on est même étonné de tout ce qui traîne sur un dd

Suivre le flux des commentaires

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