pasBill pasGates a écrit 16169 commentaires

Tu trouves ? Moi je regardes OOXML et il n'a aucun de ces defauts :
a) Les formules sont clairement definies
b) L'encryption est clairement definie
c) Il n'y a pas de balises binaires non definies

C'est pas une question a poser, parce qu'aucune solution n'est acceptable toute simplement.

Tu sais si Symphony va gagner un marche avec, je sais pas, le gouvernement du Japon, et prendre 150'000 postes ? Si oui, ben pas de bol pour l'interaction avec eux...

La meilleure solution est de rester neutre.

Quel humour quand meme, ils ont biaise quoi dans le processus de standardisation d'ODF ?

Ben dans ce cas precis, MS etait sense faire quoi ?

Etre compatible avec OOo 2.x et Symphony ou etre compatible avec OOo 3.x ?

Super comme choix... Resultat, MS a decide de pas jouer ce genre de jeu, et l'a dit bien clairement, de cette maniere aucun risque que l'utilisateur soit trompe par ce qu'il voit.

Moi je te demandes comment tu sais que avec OOo/Symphony c'est une erreur innocente, alors qu'ils bossent sur l'implementation d'ODF depuis plus de 4 ans, et qu'avec MS Office c'est une erreur volontaire, alors qu'ils bossent dessus depuis genre 1 an.

A part des prejuges, tu as quoi pour affirmer que MS fait expres d'empecher l'interop ?

Prend l'exemple du blog, et dis-moi si il raconte n'importe quoi...

Pourtant c'est Symphony, base sur OOo et OOo 3.1

Tout le monde est d'accord la-dessus, le probleme est que les gens font des erreurs de temps en temps, c'est humain, et vu les lacunes de la spec, certains softs vont t'afficher un resultat qui semble correct mais qui ne l'est pas, d'autres pourraient te donner une erreur et te dire que tu peux pas le faire, d'autres pourraient te donner le resultat correct. C'est ce que montre son exemple : Symphony donne un resultat correct(2(texte)+1=3), OOo non(2(texte)+1=1).

Bonne chance pour savoir dans quel cas tu es quand tu recois une feuille de calcul ODF...

Qui te dit que c'est la faute a IBM ? Qui te dit que OOo n'a pas change de comportement entre la 2.x et la 3.x ? J'en sais rien personnellement, mais c'est trop facile de dire automatiquement "OOo est sans reproche".

Je trouves quand meme assez gros la maniere dont vous evitez absolument de mettre la moindre faute sur ODF lui-meme ou OOo lui-meme, faudrait un minimum d'impartialite quand meme.

Et tu penses quoi du fait que 2 suites libres, toutes les 2 basees originellement sur le meme code, soient incapables de s'echanger des documents ODF correctement ?

Vu le temps qu'ils ont eu pour implementer ODF compare a MS, j'imagines que tu classes ca dans la categorie mauvaise volonte aussi ?

Dans le monde des bisounours, les standards ouverts sont parfaits et suffisants pour permettre l'interopérabilité. Dans la réalité, l'utilisation de standards ouverts n'est qu'une condition nécessaire et en aucun cas un but en soit. Deux points importants que ne semblent toujours pas avoir digérer les trolleurs de billou.

Un format auquel il manque de larges blocs empechant l'interop, alors qu'il se veut etre un format permettant l'interop, ne merite manifestement pas la denomination de standard, ca me semble evident.

Mettre la faute sur MS en particulier alors que visiblement meme 2 suites basees sur le meme code libre sont incapable de s'echanger correctement des documents du meme format n'est rien d'autre que de l'hypocrisie.

Suite bureautique basee sur OOo faite par IBM : http://symphony.lotus.com/software/lotus/symphony/home.nsf/h(...)

On regarde la realite :

a) Plusieurs gouvernements ont mandate l'usage d'ODF
b) Plusieurs gouvernements on specifie qu'il leur fallait minimum FIPS 140-2, voire utiliser leur propre algo pour ce qui est de la confidentialite.

a) et b) ne sont pas contradictoire, ils signifient simplement qu'ODF ne sera pas utilise pour des documents confidentiels(et evidemment il y a des pays qui n'ont pas cette demande).

Maintenant a moi de te poser une question: Vu la quantite de problemes serieux dans ODF, est-ce que tu trouves normal qu'il ait ete ratifie a l'ISO comme format de document standard pour suite office ?

Prouver à coup de chiffres ne me fera pas changer d'avis sur la question, c'est pas le nombre de failles connues passées ou à venir qui est intéressant, mais le temps pris à corriger la faille et les communications faites autour de celles-ci qui vont indiquer au niveau de la sécurité d'un logiciel. Et là, Microsoft n'est pas toujours aussi bien placé, que tu le veuilles ou non.

Ah oui ? C'est drole, parce qu'a l'epoque ou MS etait inonde de failles, tout le monde ici repetait a tut tete que le nombre de failles etait important...

La securite d'un logiciel et sa qualite, c'est directement en rapport avec le nombre de problemes dans le code, ca tombe sous le sens.

Pas de bol, FF a plus de failles que IE...

Bof, vu qu'on a moins de failles qu'un certain OS GPL je me dis qu'on a pas vraiment de lecons a recevoir de ce cote la.

Si il n'y a pas bijection => il faudra un moment faire une conversion dans les fonctionnalitées (par ex ne pas sauvegarder la liste des modifications apporté au fichier, ...), et on perd l'intérêt du support natif.

C'est pas blanc et noir, il y a des niveaux de gris la dedans.

Enfin ce n'est que mon avis, et je peux me tromper, mais là j'avoue qu'entre un plugin de conversion "intégré" (ie que l'utilisateur ne voit pas) qui convertis bien , et un support natif qui supporte mal, chez moi le choix est vite fait.

Dans le cas present, plugin ou pas n'y aurait rien change, si MS avait reutilise le code d'OOo dans un plugin, tout le plugin aurait du etre GPLise, et le code de ce plugin, c'est pas seulement les formules, et c'est totalement inacceptable d'un point de vue commercial.

Il ne faut pas pousser non plus. Il suffit qu'ils se basent sur un format ouvert. Or c'est ce qui est fait. A partir de ce moment, il reste à l'implémenter par Microsoft.

Le probleme c'est que le truc dont on parle, il est pas decrit dans le format car ODF a ete bacle.

Donner un code source sous BSD pour permettre l'implémentation d'un format alors que toutes les specs sont disponibles, il ne faut pas déconner non plus. En plus, si jamais Microsoft avait un doute, il pouvait toujours lire le code source de OOo tant qu'il ne le copiait pas.

Les devs MS ne peut pas lire les sources d'OOo, meme si en theorie c'est possible, de la meme maniere que les gars de la FSF ont dit aux devs du libre de ne pas lire le code de softs non-GPL-compatible.

Investir signifie avoir un retour sur l'investissement.

Comment tu veux avoir un retour sur investissement pour un truc qui sera obsolete dans 6 mois ?

2) Tu lis plus bas, tu verras qu'ODF _est_ defectueux vis-a-vis de la definition de l'encryption, il ne permet qu'un algo, qui n'est pas FIPS 140-2 alors que nombre de gouvernements demandent de pouvoir utiliser leur algo ou qu'il soit au minimum FIPS 140-2, et il ne specifie pas quels fichiers dans le package doivent etre encryptes, ce qui donne par exemple OOo qui n'encrypte que certains fichiers et pas tous.

Bref, cette features est franchement inutile, car les clients qui sont principalement des entites gouvernementales ne peuvent tout simplement pas l'utiliser.

Cherchez donc un peu, vous verrez que les USA et la France par exemple requierent FIPS 140-2 , que la Chine doit pouvoir utiliser son propre algo, ...

On sent bien qu'ODF a ete pondu a la va vite et souffre de serieuses deficiences, faudra penser a regarder la verite en face un des ces jours et reconnaintre que le probleme est du cote d'ODF.

D'un autre cote, tu dis a tes enfants de ne pas s'approcher du barbecue, tu te vois dire a tes enfants de ne pas passer sous les ampoules a la maison ?

Le probleme, c'est que quand tu ne connais pas les details, tout ce que tu vois c'est : Office ne supporte pas les fichiers ODF encryptes, alors que la spec les definit.

Maintenant regardons un peu les details :

1) Oui ODF definit l'encryption, mais il y a de jolis problemes :
a) Il supporte uniquement Blowfish qui n'est pas approuve FIPS 140-2 , ce qui est une contrainte forte chez bcp de gouvernements comme les USA ou la France
b) ODF ne permet pas de definir d'autres algos, hors certains gouvernements (Chine par exemple) requierent l'utilisation de leur propres algos
c) La spec ne definit pas si il faut encrypter tous les fichiers ou juste quelque uns, OOo par exemple n'encrypte pas tous les fichiers, super pour l'interop !

Bref, c'est une fonctionnalite a peu pres inutile car elle a ete mal definie dans ODF !

Ca laisse pas grand monde au final, parce que KOffice et Abiword sont pas vraiment des references non plus.

Va falloir se coltiner Emacs ou vi alors.

Il n'y a _absolument aucune erreur_ de MS sur ces crochets.

Cet element qui contient l'addresse des cellules est dans le namespace XML d'Office, pas dans le namespace d'ODF, et la spec ne dit absolument rien sur le contenu des autres namespaces.

Que tu te foutes des millions, honnetement tout le monde s'en fout aussi.

Si tu veux rester fixe sur tes frustrations vis-a-vis de MS plutot qu'essayer de reflechir et comprendre comment un gros projet logiciel est developpe c'est ton droit, c'est triste, mais c'est ton droit.

Faudrait sortir la liste pays par pays, c'est un peu chiant a faire.

En Finlande : Cap Gemini, Nordea Bank, Ministere des finances de Finlande, Federation finlandaise de communication et informatique, WM-Data, ...

Aux USA : EMC, HP, Lexmark, Sony, Department of Defense, Department of Homeland Security, NIST

A l'ECMA lui-meme : Apple, Barclays Capital, BP, The British Library, Essilor, The Gnome Foundation, Intel, The Library of Congress, NextPage, Novell, Statoil, Toshiba

etc...

Sinon un truc rigolo : http://idippedut.dk/post/2009/04/16/IBM-Thumbs-up-for-OOXML!(...)

IBM a approuve OOXML comme standard americain, rigolo comme ils changent d'avis...