Je trouve qu'effectivement l'histoire du temps de chargement est moisie.
Par contre, que ce soit vectoriel est pas mal. Ce n'est pas ce qui est mis en avant.
"moisi" peut-être aujourd'hui, mais à l'époque ou ce format a été conçu, ça a vraiment fait une grosse différence avec Zeta, une version de BeOS qui avait elle choisi d'utiliser des icônes en SVG. Le stockage et les processeurs ayant fait des progrès depuis 20 ans, ça se voit probablement moins sur un ordinateur moderne.
Ces attributs sont stockés dans l'inode d'en-tête du fichier qui ne peut pas contenir de données, c'est donc de la place qui était autrement "perdue". Et de toutes façons on y stocke déjà d'autres trucs (type mime,etc).
Ce n'est pas clair dans l'article mais le stockage de l'icône dans un attribut est loin d'être systématique: en gros c'est pour les applications et quelques dossiers du système. Pour les fichiers ayant un icône générique correspondant à leur type, on stocke le type mime en attribut et ça permet de retrouver l'icône approprié dans la base mime du système. On a aucun intérêt à dupliquer l'icône par défaut dans tous les fichiers.
Merci pour la réponses j'espèrais que tu passe par là :-)
C'est donc quelque chose de véritablement à la marge. Pour moi qui n'utilise pas d'explorateur de fichier je trouve ça assez inutile (je parle de l'usage en meta données et pas du format en lui même). Stocker des l'exif des images, les id3tags des musiques,… Me paraît bien plus utile s'il faut trouver un usage à ses espaces.
On fait ça aussi. Le lecteur d'image ShowImage recopie certaines données EXIF dans ces attributs, et pour la musique il faut utiliser, par exemple, ArmyKnife. Ces attributs sont en plus indexés, ce qui fait qu'on peut les utiliser pour générer des playlists dynamiques ou bien retrouver des photos en utilisant ces données (il faudrait qu'on mette un geohash ou ce genre de chose pour que ça soit vraiment intéressant, cela dit).
Pour les icônes, effectivement c'est "marginal", mais avoir les icônes qui s'affichent instantanément dans la DeskBar pour toutes les applications, c'est quand même plus propre. Et comme de toutes façons il n'y a pas vraiment d'autres métadonnées à stocker pour une application en général, et que l'espace disponible est assez large, ça ne coûte pas grand chose (un inode est par défaut à 2 ou 4Ko, et l'icône utilise en général quelques centaines d'octets, donc il reste largement la place pour les autres métadonnées éventuelles).
# Bonne idée ?
Posté par barmic 🦦 . Évalué à 3.
Autant réfléchir à la performance des icônes est intéressante et toujours utile, autant l'objectif affiché me paraît une mauvaise idée.
On économise pas une lecture en le mettant dans les meta données, les icônes sont un ensemble d'asset que tu peux memoiser.
Grossir le volume des attributs c'est un impact bien plus large que le gestionnaire de fichier.
Changer une icône oblige à passer sur tout le système de fichier.
Tu fais quoi pour les fichiersn n'ayant pas cet attribut ?
Bref c'est une microoptimisation qui sert à un cas particulier mais qui impact bien plus que ça
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bonne idée ?
Posté par Kerro . Évalué à 3.
Je trouve qu'effectivement l'histoire du temps de chargement est moisie.
Par contre, que ce soit vectoriel est pas mal. Ce n'est pas ce qui est mis en avant.
[^] # Re: Bonne idée ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
"moisi" peut-être aujourd'hui, mais à l'époque ou ce format a été conçu, ça a vraiment fait une grosse différence avec Zeta, une version de BeOS qui avait elle choisi d'utiliser des icônes en SVG. Le stockage et les processeurs ayant fait des progrès depuis 20 ans, ça se voit probablement moins sur un ordinateur moderne.
[^] # Re: Bonne idée ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Ces attributs sont stockés dans l'inode d'en-tête du fichier qui ne peut pas contenir de données, c'est donc de la place qui était autrement "perdue". Et de toutes façons on y stocke déjà d'autres trucs (type mime,etc).
Ce n'est pas clair dans l'article mais le stockage de l'icône dans un attribut est loin d'être systématique: en gros c'est pour les applications et quelques dossiers du système. Pour les fichiers ayant un icône générique correspondant à leur type, on stocke le type mime en attribut et ça permet de retrouver l'icône approprié dans la base mime du système. On a aucun intérêt à dupliquer l'icône par défaut dans tous les fichiers.
[^] # Re: Bonne idée ?
Posté par barmic 🦦 . Évalué à 1.
Merci pour la réponses j'espèrais que tu passe par là :-)
C'est donc quelque chose de véritablement à la marge. Pour moi qui n'utilise pas d'explorateur de fichier je trouve ça assez inutile (je parle de l'usage en meta données et pas du format en lui même). Stocker des l'exif des images, les id3tags des musiques,… Me paraît bien plus utile s'il faut trouver un usage à ses espaces.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bonne idée ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
On fait ça aussi. Le lecteur d'image ShowImage recopie certaines données EXIF dans ces attributs, et pour la musique il faut utiliser, par exemple, ArmyKnife. Ces attributs sont en plus indexés, ce qui fait qu'on peut les utiliser pour générer des playlists dynamiques ou bien retrouver des photos en utilisant ces données (il faudrait qu'on mette un geohash ou ce genre de chose pour que ça soit vraiment intéressant, cela dit).
Pour les icônes, effectivement c'est "marginal", mais avoir les icônes qui s'affichent instantanément dans la DeskBar pour toutes les applications, c'est quand même plus propre. Et comme de toutes façons il n'y a pas vraiment d'autres métadonnées à stocker pour une application en général, et que l'espace disponible est assez large, ça ne coûte pas grand chose (un inode est par défaut à 2 ou 4Ko, et l'icône utilise en général quelques centaines d'octets, donc il reste largement la place pour les autres métadonnées éventuelles).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.