CDG contre K² et sa pro-linuxerie - Page 8

Nil (./210) :

Flanker (./209) :

si tu veux être sûr que ton document protégé passe sur OpenOffice, il faut que tu regardes le code source d'OO en plus de la doc pour voir quels sont les hashages qu'il connaît...

Oui mais justement, c'est la force du truc (un peu comme les implémentations d'LDAP, tiens ) : chaque implémentation est libre d'utiliser des mécanismes de cryptages différents (il y en a 4 ou 5 qui sont dans la RFC, mais c'est "open", on peut mettre ce qu'on veut, pourvu que ça précède le mot de passe et que ça soit entre { }. Ainsi, on a une (toute relative) course aux méthodes d'encryptage, on est libre d'utiliser celle qu'on veut en fonction de la puissance des machines oui de migrer si la méthode de cryptage est cassée.

Oui, mais là ce n'est pas précisé que la méthode doit être en { } ^^ bref, tu ne sais rien...

./210> ouais comme ça un fichier que t'as fais avec un soft qui implémente ce format tu peux pas l'ouvrir avec l'autre soft qui implémente le même format mais qui a décidé d'avoir d'autres algos de cryptage..

Vouloir à la fois la norme pour la portabilité/compatibilité et le laisser-aller pour favoriser l'innovation, c'est un peu vouloir le beur et l'argent du beur...

edit: fr

Flanker (./211) :

Nil (./210) :

Flanker (./209) :

si tu veux être sûr que ton document protégé passe sur OpenOffice, il faut que tu regardes le code source d'OO en plus de la doc pour voir quels sont les hashages qu'il connaît...

Oui mais justement, c'est la force du truc (un peu comme les implémentations d'LDAP, tiens ) : chaque implémentation est libre d'utiliser des mécanismes de cryptages différents (il y en a 4 ou 5 qui sont dans la RFC, mais c'est "open", on peut mettre ce qu'on veut, pourvu que ça précède le mot de passe et que ça soit entre { }. Ainsi, on a une (toute relative) course aux méthodes d'encryptage, on est libre d'utiliser celle qu'on veut en fonction de la puissance des machines oui de migrer si la méthode de cryptage est cassée.

Oui, mais là ce n'est pas précisé que la méthode doit être en { } ^^ bref, tu ne sais rien...

Oui, oui mais là n'était pas mon propos. Je voulais juste dire que ça n'était pas forcément une faiblesse de ne pas spécifier le type de cryptage.

ben ça fout la portabilité des documents entre softs et plateformes complètement par terre ! Alors que c'est l'objectif premier d'une norme...

very (./214) :
ben ça fout la portabilité des documents entre softs et plateformes complètement par terre ! Alors que c'est l'objectif premier d'une norme...

Si on veut ajouter des autres types de chiffrement, on modifie la norme, mais bon, faut pas le faire tous les 6 mois, sinon ça sert à rien

Non, ça ne fout pas en l'air la portabilité des documents. Une norme décrit un certain nombre d'éléments, elle n'a pas besoin d'être exhaustive à ce niveau (en particulier parce que - à mon sens - ça n'a rien à faire là dedans... sinon on astreint une solution technique à une autre, en prenant le risque qu'elle se casse la figure dans 6 mois ou un an... c'est un peu comme la norme pour les sécurités de cartes bancaires : les méthodes changent régulièrement - parce que régulièrement cassées - mais c'est fait de façon indépendante à la fabrication des terminaux bancaires, qui ont comme pré-requis de pouvoir accepter les évolutions futures - que ça soit par mise à jour ou autre, après ça, par contre, ça doit être explicite, je suis d'accord).

Flanker (./215) :

very (./214) :
ben ça fout la portabilité des documents entre softs et plateformes complètement par terre ! Alors que c'est l'objectif premier d'une norme...

Si on veut ajouter des autres types de chiffrement, on modifie la norme, mais bon, faut pas le faire tous les 6 mois, sinon ça sert à rien

Ben la norme LDAP a... pfouuuu déjà quelques années, on a vu paraître de nouveaux systèmes de cryptage, et ça ne pose pas de soucis.

Nil (./217) :

Flanker (./215) :

very (./214) :
ben ça fout la portabilité des documents entre softs et plateformes complètement par terre ! Alors que c'est l'objectif premier d'une norme...

Si on veut ajouter des autres types de chiffrement, on modifie la norme, mais bon, faut pas le faire tous les 6 mois, sinon ça sert à rien

Ben la norme LDAP a... pfouuuu déjà quelques années, on a vu paraître de nouveaux systèmes de cryptage, et ça ne pose pas de soucis.

Ce n'est pas le même contexte, ni la même taille de doc ^^

Sans compter que le but de cette normalisation, c'est justement d'assurer la meilleure compatibilité possible entre les différents logiciels... si tu permets n'importe quoi, c'est mal parti...

Flanker (./209) :
Oui, enfin si les specs ne demandent d'avoir le même rendu, on s'en fout effectivement s'il est différent (je pensais qu'il fallait avoir le même rendu dans les mêmes conditions mais ça m'étonne quand même )

Heureusement que c'est une exigence, a police, et environement identique (dpi/taille ecran/zoom etc...) on doit avoir le meme rendu sinon on demanderais pas d'avoir un rendu au pixel pour les acid*

Flanker (./218) :
Sans compter que le but de cette normalisation, c'est justement d'assurer la meilleure compatibilité possible entre les différents logiciels... si tu permets n'importe quoi, c'est mal parti...

Si c'était vraiment ça, alors il y aurait eu une commission d'experts chargée de travailler sur une normalisation de 0. Une vraie norme, justifiée, en collaboration avec tous les acteurs du marché (IBM/Lotus, Sun/StarOffice, OASIS/OpenOffice, Microsoft/Office, et ainsi de suite).
En l'état actuel des choses, ni Microsoft ni l'OASIS ni Microsoft ne devraient avoir le privilège d'être "normalisés". C'est débile.

Nil (./220) :

Flanker (./218) :
Sans compter que le but de cette normalisation, c'est justement d'assurer la meilleure compatibilité possible entre les différents logiciels... si tu permets n'importe quoi, c'est mal parti...

Si c'était vraiment ça, alors il y aurait eu une commission d'experts chargée de travailler sur une normalisation de 0. Une vraie norme, justifiée, en collaboration avec tous les acteurs du marché (IBM/Lotus, Sun/StarOffice, OASIS/OpenOffice, Microsoft/Office, et ainsi de suite).
En l'état actuel des choses, ni Microsoft ni l'OASIS ni Microsoft ne devraient avoir le privilège d'être "normalisés". C'est débile.

Mais il faut assurer la compatibilité avec l'existant, et avoir un truc opérationnel rapidement, pas comme le css 2 qui 10 ans après, commence toujours à être utilisable. Si tu sors une norme qui n'est pas déjà implémentée, tu peux être sûr qu'elle ne servira jamais... Tu auras une première implémentation complète dans 4-5 ans, et qui l'utiliserait ? vu que les formats existants font la même chose, sont déjà utilisables et tu n'as pas de problème de compatibilité

Flanker (./221) :
Mais il faut assurer la compatibilité avec l'existant, et avoir un truc opérationnel rapidement, pas comme le css 2 qui 10 ans après, commence toujours à être utilisable. Si tu sors une norme qui n'est pas déjà implémentée, tu peux être sûr qu'elle ne servira jamais... Tu auras une première implémentation complète dans 4-5 ans, et qui l'utiliserait ? vu que les formats existants font la même chose, sont déjà utilisables et tu n'as pas de problème de compatibilité

Oui mais ça veut dire que tu favorises un concurrent au profit d'un autre (qui va avoir une sacrée avance, puisque les autres vont mettre "4-5 ans" à avoir une implémentation complète).
Et il ça ne peut se finir que de la façon dont c'est en train de se finir (et c'est ce qui s'est passé avec le BlueRay/l'HD-DVD) : une espèce de guerre où au final un des perdants majeurs sera le consommateur qui a fait un choix et qui, très rapidement, se retrouve avec des données inutilisables ou un logiciel poubelle.
Définir un format commun (même si c'est "juste" un format d'échange universel, lu et écrit par le plus de monde possible, comme l'est MusicXML) sera peut-être ùpo,s efficace qu'un format "définitif" et spécifique, mais sera largement plus utile à tout le monde.

Je reprends l'exemple de MusicXML (qui n'est pas normalisé, qui est en constante évolution, et qui a été adopté par tous les acteurs majeurs des éditeurs de logiciels de PAOMus). Il a fallu plusieurs années avant que les acteurs majeurs ne se décident à l'implémenter. Les enjeux sont énormes (il y a une guerre commerciale assez virulente entre les trois plus gros éditeurs). Mais au final, on en arrive exactement à la situation de la bureautique : aujourd'hui, tout le monde propose les mêmes fonctions. La différence se fait sur le détail, sur les plug-ins et sur l'interface utilisateur. Chaque logiciel a son propre format de données, spécifique, plus abouti que MusicXML (mais c'est justement pour ça que MusicXML est en constante évolution : pour coller à la réalité de la complexité des partitions).
Et ça marche : la politique actuelle des éditeurs est d'implémenter MusicXML parce que c'est devenu un atout marketing fort (ça résout les problèmes de compatibilité antérieure, d'échanges de données, etc.)

Bof, je ne suis pas convaincu par ce favoritisme : OpenOffice sait déjà écrire le doc, il y a des convertisseurs doc > odt. Bref, les deux gros concurrents sont plus ou moins à égalité.
Après, y a le problème de la complexité : on veut pouvoir représenter des documents extrêmement complexes sans perdre d'informations par rapport aux documents déjà existants, et à mon avis, même si tu reprends un nouveau format à 0, tu vas plus ou moins retomber sur l'un des deux déjà existants.

Et j'ai du mal à voir l'intérêt d'un format qui ne sert qu'à l'échange Fatalement, il va devenir le format de travail (quitte à se trimballer des conversions en interne), non ? Surtout des documents qui ont vocation à être échangés et modifiés souvent

Et encore une fois, tu fais quoi pendant ces 4-5 ans ? Il y avait un besoin pour un format bureautique XML et ouvert, pas forcément normalisé (c'est un plus pour certains marchés uniquement)... les 4-5 ans (sûrement plus, si on part d'un format from scratch) auraient suffit à un des deux formats pour s'imposer.

Flanker (./223) :

Et j'ai du mal à voir l'intérêt d'un format qui ne sert qu'à l'échange Fatalement, il va devenir le format de travail (quitte à se trimballer des conversions en interne), non ? Surtout des documents qui ont vocation à être échangés et modifiés souvent

Oui, le second point est peut-être vrai (avec les outils de PAOMus, on n'a rarement beaucoup d'échanges, c'est surtout pour récupérer le travail de quelqu'un).

pour les trolls sur odf/ooxml, rdv sur le topic dédié... ici c'était linux a la base

non, c'était k^2

y a plein de gens qui parlent de linux sans parler de kk, hein

Godzil (./219) :

Flanker (./209) :
Oui, enfin si les specs ne demandent d'avoir le même rendu, on s'en fout effectivement s'il est différent (je pensais qu'il fallait avoir le même rendu dans les mêmes conditions mais ça m'étonne quand même )

Heureusement que c'est une exigence, a police, et environement identique (dpi/taille ecran/zoom etc...) on doit avoir le meme rendu sinon on demanderais pas d'avoir un rendu au pixel pour les acid*

Ben y a des directives qui spécifient des trucs au pixel près, et d'autres non ...

Oui, on a des %ages, des points/pixels, des cm/in et a pars le %age tous sont lié a des grandeurs sensé être définies

le html c'est pas que des spécifications de taille ... d'ailleurs on peut très bien écrire un site sans spécifier une seule taille.

dualmoo (./231) :
le html c'est pas que des spécifications de taille ... d'ailleurs on peut très bien écrire un site sans spécifier une seule taille.

Évidemment que quand le rendu n'est pas spécifié, il n'a pas besoin d'être identique au pixel près entre les différentes implémentations

mais bon, si le HTML a été normalisé et quand il y a des mentions de taille (par exemple ), c'est tout de même pour être respecté, non ?

html est normalise ?

Godzil (./219) :

Flanker (./209) :
Oui, enfin si les specs ne demandent d'avoir le même rendu, on s'en fout effectivement s'il est différent (je pensais qu'il fallait avoir le même rendu dans les mêmes conditions mais ça m'étonne quand même )

Heureusement que c'est une exigence, a police, et environement identique (dpi/taille ecran/zoom etc...) on doit avoir le meme rendu sinon on demanderais pas d'avoir un rendu au pixel pour les acid*

acid est supporte par le W3C ?

acid est supporte par le W3C ?

Non. De même que la réponse à la question "Est-ce que les tests Acid sont des tests du respect des standards ?" est non.

Comme toute les suites de tests, les tests Acid ne montrent que l'absence de défauts sur un sous-ensemble des standards - et l'un au moins des tests Acid utilise à ma connaissance au moins un comportement non défini par les standards (mais exhibé par au moins un des browsers courants).

d'accord, parce que j'ai plutot tendance a penser comme moumou que le html n'A pas la vocation de donner un rendu identique qq soit le navigateur bien que certains se laissent a penser cette utopie.