Tu as oublié de quoter les noms des personnes ce qui rend ce thread
illisible car on ne sait plus qui a dit quoi.
HFS+ est un vieux système de fichier qui n'est pas à la hauteur de Mac OS X,
le fait qu'il soit conçu sans toutes les contraintes Posix n'excuse pas son
utilisation actuelle.
C'est un format qui est beaucoup plus riche que la plupart des
systèmes de fichiers existant.
Crois-tu ? Il existe des fs unix avec des flots type données/ressources, et
ne parlons pas de NTFS qui a aussi cette notion, mais non limitée à 2 flux
comme sur HFS+.
Mais le plus important n'est pas ce qu'un fs peut faire,
c'est ce que l'on en fait couramment avec les outils du système. En 10 ans,
pratiquement aucun développeur sous Windows NT n'a fait une appli qui
utilisait les flots.
C'est bien sûr l'inverse sur Mac OS 9, mais Mac OS X
est en train d'inverser la tendance.
Ce qui est dommage, c'est qu'il n'est pas
toujours utilisé dans le maximum de ses capacités, et qu'il n'y a pas eu
de nouvelle version compatible unix (mais juste une adaptation avec des
hacks).
Personne sous unix ou Linux ne veut porter HFS+, et pourtant les sources
sont dispos pour darwin.
Quand un Macounet envoie par exemple un fichier Office par email à un
Windosien, 9 fois sur 10 il y a un problème lié aux ressources. Ce problème
remonte régulièrement.
Quelle idée aussi d'avoir deux fichiers identiques avec juste des
différences de casse.
L'idée est de relire des archives unix normales. Impossible de faire cela
sans perte de certains fichiers. Alors on peut, comme tu le fais, dire qu'il
faut que tout le monde arrête de gérer la casse, mais pour moi, je préfère
avoir le choix. Je n'aime pas perdre des données.Dans l'absolu, c'est inutile et sans intérêt.
Dans l'absolu c'est utile et vital dans certains cas. Apple, lui, l'a
compris en essayant d'introduire en douceur la gestion de la casse dans
HFS+. Si HFS+ doit être utilisé dans des serveurs de fichiers pour des
machines unix ou linux, c'est obligatoire.
Le problème sous Mac OS X c'est que le système gère la casse (plus ou moins
bien) à travers UFS et le nouvel HFS+, mais hélas de nombreuses applications
ne le font pas. C'est souvent la faute du programmeur (même pour certaines
application Apple).
- méta-données
Ce n'est absolument pas une source d'emmerdements, car ces données ne
sont interprétées que par les applications. Le système ne s'en sert
jamais. C'est tout de même très pratique, par exemple pour donner
l'encodage d'un fichier texte ou pour définir si un fichier est visible
ou non (c'est beaucoup plus propre que le "." en tête de nom)
Dit cela à ceux qui ne peuvent vider la poubelle à cause d'un drapeau HFS+
bien planqué.
Et le fait qu'HFS+ ne gère pas tous les caractères Unicode de Panther ?
Je pense qu'il parle des alias. Pour le système de fichier, un alias est
un document, c'est les couches du système qui l'interprète comme un
alias.
Et non, ce n'est pas le système qui interprète les alias, c'est chaque
application ! C'est la pire chose de Mac OS X ! Si encore le système gérait
en interne les alias, mais non ! Et cela entraîne problème sur problème.
Tu as oublié de quoter les noms des personnes ce qui rend ce thread
illisible car on ne sait plus qui a dit quoi.
HFS+ est un vieux système de fichier qui n'est pas à la hauteur de Mac OS X,
le fait qu'il soit conçu sans toutes les contraintes Posix n'excuse pas son
utilisation actuelle.
C'est un format qui est beaucoup plus riche que la plupart des
systèmes de fichiers existant.
Crois-tu ? Il existe des fs unix avec des flots type données/ressources, et
ne parlons pas de NTFS qui a aussi cette notion, mais non limitée à 2 flux
comme sur HFS+.
Mais le plus important n'est pas ce qu'un fs peut faire,
c'est ce que l'on en fait couramment avec les outils du système. En 10 ans,
pratiquement aucun développeur sous Windows NT n'a fait une appli qui
utilisait les flots.
C'est bien sûr l'inverse sur Mac OS 9, mais Mac OS X
est en train d'inverser la tendance.
Ce qui est dommage, c'est qu'il n'est pas
toujours utilisé dans le maximum de ses capacités, et qu'il n'y a pas eu
de nouvelle version compatible unix (mais juste une adaptation avec des
hacks).
Personne sous unix ou Linux ne veut porter HFS+, et pourtant les sources
sont dispos pour darwin.
Quand un Macounet envoie par exemple un fichier Office par email à un
Windosien, 9 fois sur 10 il y a un problème lié aux ressources. Ce problème
remonte régulièrement.
Quelle idée aussi d'avoir deux fichiers identiques avec juste des
différences de casse.
L'idée est de relire des archives unix normales. Impossible de faire cela
sans perte de certains fichiers. Alors on peut, comme tu le fais, dire qu'il
faut que tout le monde arrête de gérer la casse, mais pour moi, je préfère
avoir le choix. Je n'aime pas perdre des données.
Dans l'absolu, c'est inutile et sans intérêt.
Dans l'absolu c'est utile et vital dans certains cas. Apple, lui, l'a
compris en essayant d'introduire en douceur la gestion de la casse dans
HFS+. Si HFS+ doit être utilisé dans des serveurs de fichiers pour des
machines unix ou linux, c'est obligatoire.
Le problème sous Mac OS X c'est que le système gère la casse (plus ou moins
bien) à travers UFS et le nouvel HFS+, mais hélas de nombreuses applications
ne le font pas. C'est souvent la faute du programmeur (même pour certaines
application Apple).
- méta-données
Ce n'est absolument pas une source d'emmerdements, car ces données ne
sont interprétées que par les applications. Le système ne s'en sert
jamais. C'est tout de même très pratique, par exemple pour donner
l'encodage d'un fichier texte ou pour définir si un fichier est visible
ou non (c'est beaucoup plus propre que le "." en tête de nom)
Dit cela à ceux qui ne peuvent vider la poubelle à cause d'un drapeau HFS+
bien planqué.
Et le fait qu'HFS+ ne gère pas tous les caractères Unicode de Panther ?
Je pense qu'il parle des alias. Pour le système de fichier, un alias est
un document, c'est les couches du système qui l'interprète comme un
alias.
Et non, ce n'est pas le système qui interprète les alias, c'est chaque
application ! C'est la pire chose de Mac OS X ! Si encore le système gérait
en interne les alias, mais non ! Et cela entraîne problème sur problème.
Tu as oublié de quoter les noms des personnes ce qui rend ce thread
illisible car on ne sait plus qui a dit quoi.
HFS+ est un vieux système de fichier qui n'est pas à la hauteur de Mac OS X,
le fait qu'il soit conçu sans toutes les contraintes Posix n'excuse pas son
utilisation actuelle.
C'est un format qui est beaucoup plus riche que la plupart des
systèmes de fichiers existant.
Crois-tu ? Il existe des fs unix avec des flots type données/ressources, et
ne parlons pas de NTFS qui a aussi cette notion, mais non limitée à 2 flux
comme sur HFS+.
Mais le plus important n'est pas ce qu'un fs peut faire,
c'est ce que l'on en fait couramment avec les outils du système. En 10 ans,
pratiquement aucun développeur sous Windows NT n'a fait une appli qui
utilisait les flots.
C'est bien sûr l'inverse sur Mac OS 9, mais Mac OS X
est en train d'inverser la tendance.
Ce qui est dommage, c'est qu'il n'est pas
toujours utilisé dans le maximum de ses capacités, et qu'il n'y a pas eu
de nouvelle version compatible unix (mais juste une adaptation avec des
hacks).
Personne sous unix ou Linux ne veut porter HFS+, et pourtant les sources
sont dispos pour darwin.
Quand un Macounet envoie par exemple un fichier Office par email à un
Windosien, 9 fois sur 10 il y a un problème lié aux ressources. Ce problème
remonte régulièrement.
Quelle idée aussi d'avoir deux fichiers identiques avec juste des
différences de casse.
L'idée est de relire des archives unix normales. Impossible de faire cela
sans perte de certains fichiers. Alors on peut, comme tu le fais, dire qu'il
faut que tout le monde arrête de gérer la casse, mais pour moi, je préfère
avoir le choix. Je n'aime pas perdre des données.Dans l'absolu, c'est inutile et sans intérêt.
Dans l'absolu c'est utile et vital dans certains cas. Apple, lui, l'a
compris en essayant d'introduire en douceur la gestion de la casse dans
HFS+. Si HFS+ doit être utilisé dans des serveurs de fichiers pour des
machines unix ou linux, c'est obligatoire.
Le problème sous Mac OS X c'est que le système gère la casse (plus ou moins
bien) à travers UFS et le nouvel HFS+, mais hélas de nombreuses applications
ne le font pas. C'est souvent la faute du programmeur (même pour certaines
application Apple).
- méta-données
Ce n'est absolument pas une source d'emmerdements, car ces données ne
sont interprétées que par les applications. Le système ne s'en sert
jamais. C'est tout de même très pratique, par exemple pour donner
l'encodage d'un fichier texte ou pour définir si un fichier est visible
ou non (c'est beaucoup plus propre que le "." en tête de nom)
Dit cela à ceux qui ne peuvent vider la poubelle à cause d'un drapeau HFS+
bien planqué.
Et le fait qu'HFS+ ne gère pas tous les caractères Unicode de Panther ?
Je pense qu'il parle des alias. Pour le système de fichier, un alias est
un document, c'est les couches du système qui l'interprète comme un
alias.
Et non, ce n'est pas le système qui interprète les alias, c'est chaque
application ! C'est la pire chose de Mac OS X ! Si encore le système gérait
en interne les alias, mais non ! Et cela entraîne problème sur problème.
Non car on parlais de l'encodage du nom du fichier, pas de son contenu. Et
pour le nom, sous UFS c'est de l'octet libre, et sur HFS+ c'est de l'Unicode
16 bits.
- méta-données
Je ne vois pas l'utilité. C'est une très grosse source d'emmerdements.
- noms longs
Plus de 255 caractères ? Ou alors Unicode 4 ?
- aliasing (est-ce bien de niveau file system ?)
Je ne vois pas de quoi tu parles.
Il y a d'autres fonctionnalités d'un FS,
Non car on parlais de l'encodage du nom du fichier, pas de son contenu. Et
pour le nom, sous UFS c'est de l'octet libre, et sur HFS+ c'est de l'Unicode
16 bits.
- méta-données
Je ne vois pas l'utilité. C'est une très grosse source d'emmerdements.
- noms longs
Plus de 255 caractères ? Ou alors Unicode 4 ?
- aliasing (est-ce bien de niveau file system ?)
Je ne vois pas de quoi tu parles.
Il y a d'autres fonctionnalités d'un FS,
Non car on parlais de l'encodage du nom du fichier, pas de son contenu. Et
pour le nom, sous UFS c'est de l'octet libre, et sur HFS+ c'est de l'Unicode
16 bits.
- méta-données
Je ne vois pas l'utilité. C'est une très grosse source d'emmerdements.
- noms longs
Plus de 255 caractères ? Ou alors Unicode 4 ?
- aliasing (est-ce bien de niveau file system ?)
Je ne vois pas de quoi tu parles.
Il y a d'autres fonctionnalités d'un FS,
C'est un format qui est beaucoup plus riche que la plupart des
systèmes de fichiers existant.
Quelle idée aussi d'avoir deux fichiers identiques avec juste des
différences de casse. Dans l'absolu, c'est inutile et sans intérêt.
C'est un format qui est beaucoup plus riche que la plupart des
systèmes de fichiers existant.
Quelle idée aussi d'avoir deux fichiers identiques avec juste des
différences de casse. Dans l'absolu, c'est inutile et sans intérêt.
C'est un format qui est beaucoup plus riche que la plupart des
systèmes de fichiers existant.
Quelle idée aussi d'avoir deux fichiers identiques avec juste des
différences de casse. Dans l'absolu, c'est inutile et sans intérêt.
HFS+ est un vieux système de fichier qui n'est pas à la hauteur de Mac OS X,
Quand un Macounet envoie par exemple un fichier Office par email à un
Windosien, 9 fois sur 10 il y a un problème lié aux ressources. Ce problème
remonte régulièrement.
Là effectivement ce ne sont pas des fonctionnalités natives d'HFS+, et les
hacks d'Apple ne sont pas toujours très "stables".
C'est dommage...
C'est HFS+
Dit cela à ceux qui ne peuvent vider la poubelle à cause d'un drapeau HFS+
bien planqué.
Et le fait qu'HFS+ ne gère pas tous les caractères Unicode de Panther ?
Et non, ce n'est pas le système qui interprète les alias, c'est chaque
application ! C'est la pire chose de Mac OS X ! Si encore le système gérait
en interne les alias,
HFS+ est un vieux système de fichier qui n'est pas à la hauteur de Mac OS X,
Quand un Macounet envoie par exemple un fichier Office par email à un
Windosien, 9 fois sur 10 il y a un problème lié aux ressources. Ce problème
remonte régulièrement.
Là effectivement ce ne sont pas des fonctionnalités natives d'HFS+, et les
hacks d'Apple ne sont pas toujours très "stables".
C'est dommage...
C'est HFS+
Dit cela à ceux qui ne peuvent vider la poubelle à cause d'un drapeau HFS+
bien planqué.
Et le fait qu'HFS+ ne gère pas tous les caractères Unicode de Panther ?
Et non, ce n'est pas le système qui interprète les alias, c'est chaque
application ! C'est la pire chose de Mac OS X ! Si encore le système gérait
en interne les alias,
HFS+ est un vieux système de fichier qui n'est pas à la hauteur de Mac OS X,
Quand un Macounet envoie par exemple un fichier Office par email à un
Windosien, 9 fois sur 10 il y a un problème lié aux ressources. Ce problème
remonte régulièrement.
Là effectivement ce ne sont pas des fonctionnalités natives d'HFS+, et les
hacks d'Apple ne sont pas toujours très "stables".
C'est dommage...
C'est HFS+
Dit cela à ceux qui ne peuvent vider la poubelle à cause d'un drapeau HFS+
bien planqué.
Et le fait qu'HFS+ ne gère pas tous les caractères Unicode de Panther ?
Et non, ce n'est pas le système qui interprète les alias, c'est chaque
application ! C'est la pire chose de Mac OS X ! Si encore le système gérait
en interne les alias,
Tu as oublié de quoter les noms des personnes ce qui rend ce thread
illisible car on ne sait plus qui a dit quoi.
Parce que je ne le fais jamais car en général ça ne sert à rien. Il y a
toujours moyen de savoir qui à dit telle ou telle chose en remotant les
messages. Mais c'est vrai que dans ce cas, il y a pas mal de citations
imbriquées et que ça peut servir.
C'est bien sûr l'inverse sur Mac OS 9, mais Mac OS X
est en train d'inverser la tendance.
Oui, c'est vrai que les flux ne sont plus utiles, sauf pour des
questions de compatibilité.
Cependant, avec les resources, certaines fonctionnalité risque de
disparaître (ou d'être écrites moins proprement) comme les informations
stoqués par les éditeurs de texte brut (comme la position du curseur, la
taille des tabulations). À moins que ce puissent être enregistrer dans
des métadonnées.
Dit cela à ceux qui ne peuvent vider la poubelle à cause d'un drapeau HFS+
bien planqué.
C'est pas normal, un bug ? C'est quel drapeau ?Et le fait qu'HFS+ ne gère pas tous les caractères Unicode de Panther ?
Normalement, il gère tous les caractères Unicode 2.0, c'est déjà pas
mal.
Je pense que c'est une bonne idée d'avoir fixé une fois pour toute
le format d'encodage pour éviter les incompatibilités entre version du
même système de fichiers.
L'utilisation d'une suite arbitraire d'octet
pour coder un nom de fichier est la solution de simplicité qui à
l'inconvéniant de laisser à l'utilisateur de deviner l'encodage
approprié. On pourrait spécifier le type d'encodage dans un champs de la
table d'information du disque, mais lors de l'ajout d'un nouvel
encodage, il y aura perte de la compatibilité.
Tu as oublié de quoter les noms des personnes ce qui rend ce thread
illisible car on ne sait plus qui a dit quoi.
Parce que je ne le fais jamais car en général ça ne sert à rien. Il y a
toujours moyen de savoir qui à dit telle ou telle chose en remotant les
messages. Mais c'est vrai que dans ce cas, il y a pas mal de citations
imbriquées et que ça peut servir.
C'est bien sûr l'inverse sur Mac OS 9, mais Mac OS X
est en train d'inverser la tendance.
Oui, c'est vrai que les flux ne sont plus utiles, sauf pour des
questions de compatibilité.
Cependant, avec les resources, certaines fonctionnalité risque de
disparaître (ou d'être écrites moins proprement) comme les informations
stoqués par les éditeurs de texte brut (comme la position du curseur, la
taille des tabulations). À moins que ce puissent être enregistrer dans
des métadonnées.
Dit cela à ceux qui ne peuvent vider la poubelle à cause d'un drapeau HFS+
bien planqué.
C'est pas normal, un bug ? C'est quel drapeau ?
Et le fait qu'HFS+ ne gère pas tous les caractères Unicode de Panther ?
Normalement, il gère tous les caractères Unicode 2.0, c'est déjà pas
mal.
Je pense que c'est une bonne idée d'avoir fixé une fois pour toute
le format d'encodage pour éviter les incompatibilités entre version du
même système de fichiers.
L'utilisation d'une suite arbitraire d'octet
pour coder un nom de fichier est la solution de simplicité qui à
l'inconvéniant de laisser à l'utilisateur de deviner l'encodage
approprié. On pourrait spécifier le type d'encodage dans un champs de la
table d'information du disque, mais lors de l'ajout d'un nouvel
encodage, il y aura perte de la compatibilité.
Tu as oublié de quoter les noms des personnes ce qui rend ce thread
illisible car on ne sait plus qui a dit quoi.
Parce que je ne le fais jamais car en général ça ne sert à rien. Il y a
toujours moyen de savoir qui à dit telle ou telle chose en remotant les
messages. Mais c'est vrai que dans ce cas, il y a pas mal de citations
imbriquées et que ça peut servir.
C'est bien sûr l'inverse sur Mac OS 9, mais Mac OS X
est en train d'inverser la tendance.
Oui, c'est vrai que les flux ne sont plus utiles, sauf pour des
questions de compatibilité.
Cependant, avec les resources, certaines fonctionnalité risque de
disparaître (ou d'être écrites moins proprement) comme les informations
stoqués par les éditeurs de texte brut (comme la position du curseur, la
taille des tabulations). À moins que ce puissent être enregistrer dans
des métadonnées.
Dit cela à ceux qui ne peuvent vider la poubelle à cause d'un drapeau HFS+
bien planqué.
C'est pas normal, un bug ? C'est quel drapeau ?Et le fait qu'HFS+ ne gère pas tous les caractères Unicode de Panther ?
Normalement, il gère tous les caractères Unicode 2.0, c'est déjà pas
mal.
Je pense que c'est une bonne idée d'avoir fixé une fois pour toute
le format d'encodage pour éviter les incompatibilités entre version du
même système de fichiers.
L'utilisation d'une suite arbitraire d'octet
pour coder un nom de fichier est la solution de simplicité qui à
l'inconvéniant de laisser à l'utilisateur de deviner l'encodage
approprié. On pourrait spécifier le type d'encodage dans un champs de la
table d'information du disque, mais lors de l'ajout d'un nouvel
encodage, il y aura perte de la compatibilité.
Éric Lévénez wrote:HFS+ est un vieux système de fichier qui n'est pas à la hauteur de Mac OS X,
On dirait que tu as le même "aveuglement" pour MacOS X que celui que tu
reproches aux regular macounets pour MacOS.
Quand un Macounet envoie par exemple un fichier Office par email à un
Windosien, 9 fois sur 10 il y a un problème lié aux ressources. Ce problème
remonte régulièrement.
Ce problème pourrait être réglé intelligemment par les couches hautes
(envoi de mail par une application "end-user").
Pareil pour les
extensions de noms de fichiers.
MacOS X a au moins une grosse erreur dans ses fondations : vouloir
s'appuyer sur Unix en gardant HFS+.
Dit cela à ceux qui ne peuvent vider la poubelle à cause d'un drapeau HFS+
bien planqué.
Problème applicatif...
Et non, ce n'est pas le système qui interprète les alias, c'est chaque
application ! C'est la pire chose de Mac OS X ! Si encore le système gérait
en interne les alias,
Oui, c'est le cas dans Regular MacOS. Il y a une API standard de gestion
des alias.
Éric Lévénez <news@levenez.com> wrote:
HFS+ est un vieux système de fichier qui n'est pas à la hauteur de Mac OS X,
On dirait que tu as le même "aveuglement" pour MacOS X que celui que tu
reproches aux regular macounets pour MacOS.
Quand un Macounet envoie par exemple un fichier Office par email à un
Windosien, 9 fois sur 10 il y a un problème lié aux ressources. Ce problème
remonte régulièrement.
Ce problème pourrait être réglé intelligemment par les couches hautes
(envoi de mail par une application "end-user").
Pareil pour les
extensions de noms de fichiers.
MacOS X a au moins une grosse erreur dans ses fondations : vouloir
s'appuyer sur Unix en gardant HFS+.
Dit cela à ceux qui ne peuvent vider la poubelle à cause d'un drapeau HFS+
bien planqué.
Problème applicatif...
Et non, ce n'est pas le système qui interprète les alias, c'est chaque
application ! C'est la pire chose de Mac OS X ! Si encore le système gérait
en interne les alias,
Oui, c'est le cas dans Regular MacOS. Il y a une API standard de gestion
des alias.
Éric Lévénez wrote:HFS+ est un vieux système de fichier qui n'est pas à la hauteur de Mac OS X,
On dirait que tu as le même "aveuglement" pour MacOS X que celui que tu
reproches aux regular macounets pour MacOS.
Quand un Macounet envoie par exemple un fichier Office par email à un
Windosien, 9 fois sur 10 il y a un problème lié aux ressources. Ce problème
remonte régulièrement.
Ce problème pourrait être réglé intelligemment par les couches hautes
(envoi de mail par une application "end-user").
Pareil pour les
extensions de noms de fichiers.
MacOS X a au moins une grosse erreur dans ses fondations : vouloir
s'appuyer sur Unix en gardant HFS+.
Dit cela à ceux qui ne peuvent vider la poubelle à cause d'un drapeau HFS+
bien planqué.
Problème applicatif...
Et non, ce n'est pas le système qui interprète les alias, c'est chaque
application ! C'est la pire chose de Mac OS X ! Si encore le système gérait
en interne les alias,
Oui, c'est le cas dans Regular MacOS. Il y a une API standard de gestion
des alias.
Tout le monde connaît les problèmes d'HFS+ et des ses particularités. Ne
rien voir sous prétexte que ça existe depuis longtemps sur Mac n'est pas une
position tenable.
Le problème est que depuis l'introduction du Mac, il y a des problèmes
d'échange entre le Mac et le reste du monde. Alors pendant des annnées et
des années d'études Apple n'a rien pu faire. Pourquoi cela s'améliorerait-
il ?
Les extensions c'est bien.
J'aime voir .html ou .jpg sur mes fichiers.
J'aime bien ainsi savoir qui va les ouvrir (les icônes n'indiquent rien car
elles peuvent être changées).
On peut avoir un fichier qui ressemble à une
image normale, alors qu'en fait c'est un dangereux programme qui cache son
icône.
C'est en particulier pour cela que les extensions c'est bien et qu'il
faut toujours les afficher.
Et comme on en a déjà parlé, on peut cascader
les extensions pour connaître simplement la structure d'un fichier.
Tout le monde connaît les problèmes d'HFS+ et des ses particularités. Ne
rien voir sous prétexte que ça existe depuis longtemps sur Mac n'est pas une
position tenable.
Le problème est que depuis l'introduction du Mac, il y a des problèmes
d'échange entre le Mac et le reste du monde. Alors pendant des annnées et
des années d'études Apple n'a rien pu faire. Pourquoi cela s'améliorerait-
il ?
Les extensions c'est bien.
J'aime voir .html ou .jpg sur mes fichiers.
J'aime bien ainsi savoir qui va les ouvrir (les icônes n'indiquent rien car
elles peuvent être changées).
On peut avoir un fichier qui ressemble à une
image normale, alors qu'en fait c'est un dangereux programme qui cache son
icône.
C'est en particulier pour cela que les extensions c'est bien et qu'il
faut toujours les afficher.
Et comme on en a déjà parlé, on peut cascader
les extensions pour connaître simplement la structure d'un fichier.
Tout le monde connaît les problèmes d'HFS+ et des ses particularités. Ne
rien voir sous prétexte que ça existe depuis longtemps sur Mac n'est pas une
position tenable.
Le problème est que depuis l'introduction du Mac, il y a des problèmes
d'échange entre le Mac et le reste du monde. Alors pendant des annnées et
des années d'études Apple n'a rien pu faire. Pourquoi cela s'améliorerait-
il ?
Les extensions c'est bien.
J'aime voir .html ou .jpg sur mes fichiers.
J'aime bien ainsi savoir qui va les ouvrir (les icônes n'indiquent rien car
elles peuvent être changées).
On peut avoir un fichier qui ressemble à une
image normale, alors qu'en fait c'est un dangereux programme qui cache son
icône.
C'est en particulier pour cela que les extensions c'est bien et qu'il
faut toujours les afficher.
Et comme on en a déjà parlé, on peut cascader
les extensions pour connaître simplement la structure d'un fichier.
Éric Lévénez wrote:Les extensions c'est bien.
Ah bon.J'aime voir .html ou .jpg sur mes fichiers.
Ah, d'accord, pour toi, c'est bien, donc.J'aime bien ainsi savoir qui va les ouvrir (les icônes n'indiquent rien car
elles peuvent être changées).
Les méta-données peuvent aussi servir à ça.
On peut avoir un fichier qui ressemble à une
image normale, alors qu'en fait c'est un dangereux programme qui cache son
icône.
Les méta-données peuvent aussi résoudre cela.
C'est en particulier pour cela que les extensions c'est bien et qu'il
faut toujours les afficher.
Rien à voir. Tu pourrais dire "affiche-moi les types des fichiers".
Je te propose un truc : pour différencier les dossiers des fichiers,
faisons commencer les noms de nos dossiers par "d.", OK ? Ah, non ? Tu
trouves que les méta-données sont utiles, soudain ?
Et si un fichier ".html" est en fait un dangereux programme, le Finder
pourrait très bien te signaler par ailleurs que le type déclaré dans les
méta-données ne correspond pas au type par défaut de l'extension
".html".
Je comprends que tu aies bien saisi l'usage des extensions, et que cela
te satisfasse, mais si on recentre la réflexion sur l'utilisateur, on
peut être largement plus créatif, et ce au profit du fonctionnel.
Et comme on en a déjà parlé, on peut cascader
les extensions pour connaître simplement la structure d'un fichier.
Bof. Les extensions ne sont qu'un cas très primaire de méta-données.
Elles ne devraient être visibles que pour les techniciens qui le
désirent, et surtout pas pour le end-user.
Les fichiers .html, .jpg et autres sont un cas à part, car il peut
s'agir de les exporter vers un hébergement web, par exemple.
Mais pour un document Word, aucun intérêt d'avoir une terminaison
".doc".
En revanche, il est intéressant de connaître :
- son type
- avec quelle application l'ouvrir (pourquoi faudrait-il que tous mes
fichiers .html s'ouvrent avec le même navigateur ? -- j'ai eu des cas
où j'ai eu besoin de cette différenciation)
- son icône custom
- la dernière position du curseur
- l'URL d'où il a été téléchargé (éventuellement)
- la dernière date à laquelle il a été contrôlé par un antivirus
- la dernière date à laquelle il a été indexé
Et là où c'est fort, c'est que grâce aux méta-données tu peux avoir ces
informations pour un simple fichier texte ! -- oui, même la dernière
position du curseur (dépendra de l'appli, toutefois), son URL, etc.
Éric Lévénez <news@levenez.com> wrote:
Les extensions c'est bien.
Ah bon.
J'aime voir .html ou .jpg sur mes fichiers.
Ah, d'accord, pour toi, c'est bien, donc.
J'aime bien ainsi savoir qui va les ouvrir (les icônes n'indiquent rien car
elles peuvent être changées).
Les méta-données peuvent aussi servir à ça.
On peut avoir un fichier qui ressemble à une
image normale, alors qu'en fait c'est un dangereux programme qui cache son
icône.
Les méta-données peuvent aussi résoudre cela.
C'est en particulier pour cela que les extensions c'est bien et qu'il
faut toujours les afficher.
Rien à voir. Tu pourrais dire "affiche-moi les types des fichiers".
Je te propose un truc : pour différencier les dossiers des fichiers,
faisons commencer les noms de nos dossiers par "d.", OK ? Ah, non ? Tu
trouves que les méta-données sont utiles, soudain ?
Et si un fichier ".html" est en fait un dangereux programme, le Finder
pourrait très bien te signaler par ailleurs que le type déclaré dans les
méta-données ne correspond pas au type par défaut de l'extension
".html".
Je comprends que tu aies bien saisi l'usage des extensions, et que cela
te satisfasse, mais si on recentre la réflexion sur l'utilisateur, on
peut être largement plus créatif, et ce au profit du fonctionnel.
Et comme on en a déjà parlé, on peut cascader
les extensions pour connaître simplement la structure d'un fichier.
Bof. Les extensions ne sont qu'un cas très primaire de méta-données.
Elles ne devraient être visibles que pour les techniciens qui le
désirent, et surtout pas pour le end-user.
Les fichiers .html, .jpg et autres sont un cas à part, car il peut
s'agir de les exporter vers un hébergement web, par exemple.
Mais pour un document Word, aucun intérêt d'avoir une terminaison
".doc".
En revanche, il est intéressant de connaître :
- son type
- avec quelle application l'ouvrir (pourquoi faudrait-il que tous mes
fichiers .html s'ouvrent avec le même navigateur ? -- j'ai eu des cas
où j'ai eu besoin de cette différenciation)
- son icône custom
- la dernière position du curseur
- l'URL d'où il a été téléchargé (éventuellement)
- la dernière date à laquelle il a été contrôlé par un antivirus
- la dernière date à laquelle il a été indexé
Et là où c'est fort, c'est que grâce aux méta-données tu peux avoir ces
informations pour un simple fichier texte ! -- oui, même la dernière
position du curseur (dépendra de l'appli, toutefois), son URL, etc.
Éric Lévénez wrote:Les extensions c'est bien.
Ah bon.J'aime voir .html ou .jpg sur mes fichiers.
Ah, d'accord, pour toi, c'est bien, donc.J'aime bien ainsi savoir qui va les ouvrir (les icônes n'indiquent rien car
elles peuvent être changées).
Les méta-données peuvent aussi servir à ça.
On peut avoir un fichier qui ressemble à une
image normale, alors qu'en fait c'est un dangereux programme qui cache son
icône.
Les méta-données peuvent aussi résoudre cela.
C'est en particulier pour cela que les extensions c'est bien et qu'il
faut toujours les afficher.
Rien à voir. Tu pourrais dire "affiche-moi les types des fichiers".
Je te propose un truc : pour différencier les dossiers des fichiers,
faisons commencer les noms de nos dossiers par "d.", OK ? Ah, non ? Tu
trouves que les méta-données sont utiles, soudain ?
Et si un fichier ".html" est en fait un dangereux programme, le Finder
pourrait très bien te signaler par ailleurs que le type déclaré dans les
méta-données ne correspond pas au type par défaut de l'extension
".html".
Je comprends que tu aies bien saisi l'usage des extensions, et que cela
te satisfasse, mais si on recentre la réflexion sur l'utilisateur, on
peut être largement plus créatif, et ce au profit du fonctionnel.
Et comme on en a déjà parlé, on peut cascader
les extensions pour connaître simplement la structure d'un fichier.
Bof. Les extensions ne sont qu'un cas très primaire de méta-données.
Elles ne devraient être visibles que pour les techniciens qui le
désirent, et surtout pas pour le end-user.
Les fichiers .html, .jpg et autres sont un cas à part, car il peut
s'agir de les exporter vers un hébergement web, par exemple.
Mais pour un document Word, aucun intérêt d'avoir une terminaison
".doc".
En revanche, il est intéressant de connaître :
- son type
- avec quelle application l'ouvrir (pourquoi faudrait-il que tous mes
fichiers .html s'ouvrent avec le même navigateur ? -- j'ai eu des cas
où j'ai eu besoin de cette différenciation)
- son icône custom
- la dernière position du curseur
- l'URL d'où il a été téléchargé (éventuellement)
- la dernière date à laquelle il a été contrôlé par un antivirus
- la dernière date à laquelle il a été indexé
Et là où c'est fort, c'est que grâce aux méta-données tu peux avoir ces
informations pour un simple fichier texte ! -- oui, même la dernière
position du curseur (dépendra de l'appli, toutefois), son URL, etc.
Moi je veux que tout mes fichier .html s'ouvrent avec mon navigateur, ne pas
savoir intuitivement avec quoi un fichier va s'ouvrir est une horreur. Il
faut toujours vérifier dans les infos du fichier pour ne pas faire de bêtise
(voir plus haut sur ces problèmes de sécurité).
Moi je veux que tout mes fichier .html s'ouvrent avec mon navigateur, ne pas
savoir intuitivement avec quoi un fichier va s'ouvrir est une horreur. Il
faut toujours vérifier dans les infos du fichier pour ne pas faire de bêtise
(voir plus haut sur ces problèmes de sécurité).
Moi je veux que tout mes fichier .html s'ouvrent avec mon navigateur, ne pas
savoir intuitivement avec quoi un fichier va s'ouvrir est une horreur. Il
faut toujours vérifier dans les infos du fichier pour ne pas faire de bêtise
(voir plus haut sur ces problèmes de sécurité).
Et comme on en a déjà parlé, on peut cascader
les extensions pour connaître simplement la structure d'un fichier.
Bof. Les extensions ne sont qu'un cas très primaire de méta-données.
Elles ne devraient être visibles que pour les techniciens qui le
désirent, et surtout pas pour le end-user.
Le end-user il sait ce qu'est un fichier .jpg, un fichier .doc, un fichier
.mp3... Il ne faut pas au contraire confondre les volontés d'un technicien
qui veut mettre des méta-datas partout (en XML ce serait encore mieux) parce
que ça fait hi-tech et l'utilisateur final qui veut du simple.
Et là où c'est fort, c'est que grâce aux méta-données tu peux avoir ces
informations pour un simple fichier texte ! -- oui, même la dernière
position du curseur (dépendra de l'appli, toutefois), son URL, etc.
Ce qui est fort, ces que l'on peut se passer entièrement de toutes ces
meta-données et que la vie devient plus simple.
Et comme on en a déjà parlé, on peut cascader
les extensions pour connaître simplement la structure d'un fichier.
Bof. Les extensions ne sont qu'un cas très primaire de méta-données.
Elles ne devraient être visibles que pour les techniciens qui le
désirent, et surtout pas pour le end-user.
Le end-user il sait ce qu'est un fichier .jpg, un fichier .doc, un fichier
.mp3... Il ne faut pas au contraire confondre les volontés d'un technicien
qui veut mettre des méta-datas partout (en XML ce serait encore mieux) parce
que ça fait hi-tech et l'utilisateur final qui veut du simple.
Et là où c'est fort, c'est que grâce aux méta-données tu peux avoir ces
informations pour un simple fichier texte ! -- oui, même la dernière
position du curseur (dépendra de l'appli, toutefois), son URL, etc.
Ce qui est fort, ces que l'on peut se passer entièrement de toutes ces
meta-données et que la vie devient plus simple.
Et comme on en a déjà parlé, on peut cascader
les extensions pour connaître simplement la structure d'un fichier.
Bof. Les extensions ne sont qu'un cas très primaire de méta-données.
Elles ne devraient être visibles que pour les techniciens qui le
désirent, et surtout pas pour le end-user.
Le end-user il sait ce qu'est un fichier .jpg, un fichier .doc, un fichier
.mp3... Il ne faut pas au contraire confondre les volontés d'un technicien
qui veut mettre des méta-datas partout (en XML ce serait encore mieux) parce
que ça fait hi-tech et l'utilisateur final qui veut du simple.
Et là où c'est fort, c'est que grâce aux méta-données tu peux avoir ces
informations pour un simple fichier texte ! -- oui, même la dernière
position du curseur (dépendra de l'appli, toutefois), son URL, etc.
Ce qui est fort, ces que l'on peut se passer entièrement de toutes ces
meta-données et que la vie devient plus simple.
