pasBill pasGates a écrit 16060 commentaires

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...

Tu peux m'expliquer en quoi donner les modifications apportées au code "coupe le bras" de microsoft ?
Ils peuvent très bien faire un système de plugin basé sur un programme externe pour ne pas avoir à fournir l'ensemble du code de leur suite...

Justement non, c'est toute la difference entre un plugin de conversion et un support natif, le support natif permet bcp plus de choses mais requiert une integration dans la suite(a moins de tout exposer, mais la c'est le bordel). C'est pas par hasard si ils ont choisi la route du support natif, qui est plus couteuse et complexe plutot que le support par plugin hein, ils aiment pas se faire chier pour rien...

Sans parler des risques de cannibalisation/fork/... du code qui sont commercialement un sacre probleme niveau support.

Ben si tu ne geres pas la decryption c'est dur de lire le document quand meme...

ODF est en gros le format natif d'OOo avec des changements, OOo bosse depuis 5 ans sur une conformance a 100% au standard, ils ont presque fini le boulot.

ODF n'est pas du tout le format natif d'Office, MS y bosse dessus depuis peut-etre 1 an, par je ne sais quel miracle on devrait faire aussi bien qu'OOo dont c'est le format natif et qui bosse dessus depuis 5 ans ?

Perso je me demandes si vous avez deja bosse sur des gros projets logiciels, vous avez une totale incomprehension du boulot que ca represente, du genre de choix a faire, des couts de developpement et des couts de maintenance.

Les 3/4 de la planete sont partenaires MS, meme IBM est partenaire MS, tu m'expliques qui devrait etre sur cette liste alors.

Cites moi _une_ autre societe informatique developpant un soft de taille et complexite similaire, qui aurait ete prete a injecter des millions supplementaires et retarder la sortie de plusieurs mois pour supporter un truc batard qui sera obsolete dans 8 mois.

PERSONNE ne s'amuse à développer le support d'un format en ne testant pas une seule fois l'interopérabilité du résultat avec les principaux logiciels déjà largement déployés et supportant ce format, aussi "mauvais" ce format soit-il.

Mais qui t'a donc dit qu'ils ne l'avaient pas teste et ne le savaient pas ??

Ils l'ont documente il y a 5 mois, ont averti les membres du TC OASIS lors d'un meeting des mois avant cela, et l'opinion generale des membres du TC etait de comprendre la position de MS.
Il y a un gars du TC qui a cru bon de ne pas venir, car visiblement avoir la suite detenant 90% du marche supportant ODF n'etait pas important, c'est Rob Weir, et comme par hasard c'est lui qui se plaint...

Oui, il n'y a pas de standard donc chacun fait comme il veut.

Sun et ses developpeurs ont bosse sur OOo depuis des annees pour le support d'ODF, le travail n'est pas encore fini. Par je ne sais quel miracle, MS et Office sont sense faire aussi bien des la 1ere version que ce que Sun a fait depuis 5 ans ?

Faudrait penser a etre un minimum realiste, je sais qu'on est fort, mais quand meme...

Je peux te sortir une liste tout aussi longue de societes ayant estime qu'OOXML etait bon a standardiser, qqe chose me dira que tu n'es pas du meme avis qu'eux.