TImaniac a écrit 6423 commentaires

mais ils disent qu'ils ont 60 000 chansons (putain comment ils font pour en avoir autant?
Euh en 2004 chez Wippit ils en avaient 500 000 :
http://www.bucheron.net/weblogs/index.php?2004/10/19/1066
chez Virgin c'est le million...

On peu parler de la merdouille qu'est le format MS qui fout un image en binaire dans le fichier xml directement,
Non on peut pas en parler parcque le format OpenXML de MS utilise un zip comme ODF :)

Cela m'etonnerait un chouilla (non je ne vais pas verifier je n'ai pas signe le NDA sur le format puis j'y connais rien au XML) vu qu'elle est cense fonctionner qu'avec un seul logiciel les autres voulant l'utiliser ayant interet a avoir la meme semantique et les memes formules que la suite office de MS sinon le meme probleme se posera.
Comprend rien à ton raisonnement. En tout cas les formules sont définis dans le draft qu'ils ont soumis à l'ECMA. Pour t'en convaincre, ben t'as qu'à vérifier, y'a pas de NDA et ca parle pas XML :-p

Et là, on tombe dans le « ouais, mais si ça se trouve, ils y arriveront pas ». Avant de dire que Koffice a des problèmes avec ODF, attends qu'ils les ai vraiment.
Ben justement ils ont eu le problème des formules. Ils ont en partis contourné le problème en s'accordant avec OOo, mais reste qu'à la base l'ODF posait problème.
J'ai justement mis ce lien comme argument, je vois pas où est le FUD.

Ton exemple montre un truc qui n'est pas couvert par ODF.
D'où les lacunes du format ODF : avoir un format de document pour un tableur en ayant de grosses lacunes sémantique sur les formules c'est quand même balo, quoiqu'ils en disent:) KOffice se retrouvait dans l'impossibilité de ganratir l'interopérabilité de ses formules avec celles de OOo parcque l'ODF était mal foutu sur ce point là, ce que je voulais démontrer.

it. C'est un peu comme si tu disais que HTML, c'est nul, parce que ça ne dit pas comment décoder un .jpg
Non c'est comme si je disasis que l'HTML c'est nul parcque je sais pas comment créer un hyperlien. Ca sert à rien de dire "oué mais non c'est pas à l'ODF de gérer ca", les formules sont un des points clés d'un document de tableur, au même titre que les hyperliens sont des points clés du HTML.

Comme dis dans le commentaire précédent, ce que tu décris est le PDF.

En fait faut en revenir au problème initiale :
le format PDF n'est pas une solution en soit car il ne constitue pas l'original, mais plutôt une photocopie sur lequel il est difficile de revenir en arrière.
Pour de nombreuses raisons, beaucoup de monde a besoin de conserver les originaux (tout bêtement pour travailler dessus), notamment les grands organismes. Une partie s'est apercu que ses informations étaient stockées dans ces documents, et ont commencé à se poser des questions sur la pérénité mais aussi l'opacité de ce moyen de stockage : c'est ainsi que certains organismes ont commencé à remettre en cause le format .doc. le format de OOo a le gros avantage d'être ouvert et utilise des technos standarisées, il permet donc d'obtenir une transparence technique et donc un gage de pérénité pour ces organismes.
MS s'est trouvé dans une situation délicate : on risque de perdre des clients. Ils ont donc fait le format MS Office XML dans Office 2003. Problème : ce format bien qu'utilisant des technos ouverte restait fermé. De son côté Sun a décidé de standarisé son format, histoire d'obtenir un label relativement convoité : "Standard" (alors qu'une normalisation suffirait, sans la notion de "standard" qui rappelle trop le W3C qui lui a besoin de vrais standards).
Si sur le papier l'idée peut sembler bonne, visiblement les efforts de coopération avec MS ont tournés court. Quand on voit le résultat (c'est à dire la prise en compte de la suite MSOffice dans l'ODF), on se dit que Sun et l'OASIS n'ont pas fait grand chose pour intégrer le lourd passif de MS en matière de documents dans son format propriétaire (il suffit de constater que les formats gérés par l'ODF correspondent aux formats gérés par OOo et non par MS Office qui contient différentes applications). Bref, Sun s'est retrouvé à faire un standard "tout seul", pas seul physiquement, mais en tout cas sans le principal acteur du marché. Balo pour un standard. Bref, en tant que standard, l'ODF est mort, sans doute à cause de conflits entre MS et Sun. Reste qu'il est normalisé et c'est tant mieux.
Reste que le label "standard" reste toujours vendeur, et c'est Sun qui risque d'y gagner quelques part de marché. MS ne veut pas lâcher le morceau, et en réaction à ce qui s'est passé à l'OASIS, et pour satisfaire les besoins de nouveau clients, ils se lancent dans la normalisation de leur format XML.

Par rapport au problème initiale, qui est "l'emprisonnement des données", les 2 solutions se valent et répondent à leurs objectifs. Reste que Sun et une partie du libre a fait tourner le débat vers un autre point : l'interopérabilité. Bah oui, qui dit standard, dit interopérabilité. Et maintenant on part dans des débats sur quel est le meilleur format, tel format est le standard il doit être implémenté par tout le monde, blablabla. Alors qu'il n'y a pas de standard, juste des formats ouverts.

Je vais reprendre un exemple que j'aime bien , qui concerne toujours MS et Sun : .NET et Java sont 2 plateformes, toutes 2 plus ou moins normalisées à travers différents organismes/comité, mais aucun n'a la prétention de s'occtroyer le titre de "standard". Y'a 2 alternatives (et beaucoup plus), et c'est tant mieux.

Enfin Sun a bien joué son coup, en faisant basculer le débat de la a dépendance des données vis-à-vis d'un format au faux débat de l'interopérabilité avec comme solution SON standard, qui a conduit inévitablement vers le même débat qu'au W3C : IE ca pu, ca implémente pas les standards... MS Office ca pu ca n'implémente pas les standards. Pourtant c'est pas du tout la même situation et le même type d'informations/documents.

Techniquement, les 2 formats ont leurs avantages et inconvénients, il en fait aucun doute que le format ODF est très bien conçu comme le dis Normal Walsh. Il faut noter qu'il dit "techniquement". (DocBook est pour moi nettement plus élégant sur le typage de l'information que l'ODF, mais c'est pas le sujet, et les 2 formats n'ont pas les mêmes objectifs).

l'ODF est très orienté fonctionnalités de OOo : c'est un format de travail.
l'OpenXML est très orienté MS Office : c'est un autre format de travail.

La bataille actuelle montre clairement que ces formats sont "stratégiques", justement parcque ce sont des formats de travail, et que de leurs structures sont fortement liées aux informations manipulées par l'outil. Hors ces informations sont intrinséquement définies par les fonctionnalités de l'application.

Pour ces raisons :
- Une suite bureautique utilise le format de travail d'une autre suite mettra la première en retrait de la 2ème, les 2 risquant d'être à terme fonctionnement identique. C'est empêcher l'innovation de la première. KOffice se condamne ainsi pour moi sur le long terme à être un clone de OOo, avec comme seul atout l'intégration à KDE.
- Chaque suite doit garder une liberté dans l'évolution de son format de travail et donc maîtriser son propre format.
- Cela ne sert donc à rien de vouloir imposer l'ODF ou l'OpenXML comme unique standard. Que les 2 soient normalisés peut avoir de nombreux avantages, mais chercher à décrêter qu'il n'y a qu'un seul standard (au sens W3C par exemple, mais c'est pas du tout la même situation) me paraît absurde.
- Il faut un vrai format d'échange pour les documents Office. Un format non pas de travail mais un format d'interopérabilité. Ce format ne doit pas être aussi puissant que OpenXML ou ODF, il doit reprendre les points communs de ces principaux formats. Ce format ne doit pas être le format de travail d'une suite, mais doit s'intégrer en import/export.

Sinon une petite remarque sur l'article de Wikipedia : c'est à ce genre d'articles qu'on peut remettre en doute la qualité d'une encyclopédie telle que Wikiepedia. Heuresement qu'on tombe pas trop souvent sur ce genre d'article. C'est bourré de subjectivité, de mauvaise foi, d'inexactitude, bref, c'est vraiment à virer de l'encyclopédie. Détrompez vous j'aime wikipedia, mais pas toutes les contributions ;)

C'est pas parcqu'ils ont pris cette décision qu'ils sont sûr d'implémenter à 100% l'ODF... Sans parler des lacunes sémantiques de ce format qui risque de voir des différences entre OOo et d'autres suites, alors que les 2 respectent le format.
Un exemple qui montre clairement que l'OASIS n'a pas fait son boulot (ou alors l'OASIS ne sert à rien) :
http://software.newsforge.com/article.pl?sid=05/09/09/192250(...)

Si ca à voir. Les auteurs de mod_perl ont cassé la compatibilité parcqu'ils étaient essentiellement constitués d'API "perlisé" de Apache. Apache a cassé la compatibilité, mod_perl a donc pété au passage. Et donc toutes les applis qui les utilise comme talweg.
.NET propose pour talweg tous les API dont ils avaient besoins qui se trouvait dans mod_perl, mais cette fois si avec l'indépendance vis-à-vis du serveur Apache 1, puisqu'on peut facilement imaginer faire tourner l'appli sur un autre serveur web comme Apache 2 ou IIS.
C'est tout l'intérêt de plateforme complètes et intégrées comme .NET ou Java : les APIs sont unifiés et on y trouve de tout en "standard", évitant d'avoir à se trimbaler des dépendances vers 15000 bibliothèques externes dont on n'est pas sûr de la pérénité dans le temps.

Sans cela, il est probable que M$ n'aurait meme pas pense a commencer a essayer de tenter de la faire.
Je penses que MS comme SUN cherche à standardisé leurs formats respectifs pour "appater" des clients potentiels. Le logo "standard" étant vendeur.

Sinon pour le plugin on ne se comprend pas.
Sun a fait sa part de boulot en faisant le "plugin office" dans OOo.
Reste a M$ a faire la sienne avec le "plugin OOo" dans Office.
A la différence prêt que SUN avait un intérêt à supporter le format MS : utiliser les millions de documents existant dans ce format. MS n'a aucun intérêt à utiliser le format OOo. Si SUN croît que son format peut servir de standard d'interopérabilité et qu'il gagnerait à être supporter par MS Office, c'est à lui de le démontrer.

u as dit que gcc n'offrait pas ça (
elle est où l'option --gc dans le compilo ? :)

Oui, tu remarqueras que c'est exactement ce que je dis dans le post auquel tu réponds
Bah oué je confirmes mes doutes également c'est tout :) Mais comme quoi y'a bien des services qui sont propres aux environnement d'exécutions "managés" ;)

pas la compilation. C++ est beaucoup plus difficile à compiler que Java, par exemple.
Compiler Java n'est pas difficile, mais compiler Java en natif comme le fait GCC c'était visiblement pas évident puisqu'ils avaient l'air d'être tout fier de le faire et qu'ils sont le seul à le proposer...

Quant au bench que tu cites, c'est de la merde. Il faut vraiment être un âne (je ne parle pas de toi) pour utiliser des benchs qui tournent aussi vite et prétendre que c'est représentatif de quelque chose...
Autant pour comparer 2 langages je trouves effectivement que c'est de la merde généralement, autant pour comparer 2 implantations je vois pas en quoi c'est de la merde, sachant que le temps de 'lancement' n'est généralement pas pris en compte...
En tout cas les bench semblent refléter la réalité, il suffit de comparer gcc et le compilo d'intel par exemple pour voir qu'on retrouve bien graphiquement ce qu'on constate de manière empirique :)

L'intérêt, c'est l'occupation mémoire plus faible, la facilité de distribution, etc.
En fait GCJ est parti dans "Extra" me demande pas pourquoi...
http://shootout.alioth.debian.org/sandbox/benchmark.php?test(...)
Ben même si ce sont des benchs de merde, visiblement l'occupation mémoire semble pas spécialement améliorée avec GCJ... Après faut voir sur une appli réelle et comparer... Mais bon des premiers tests de Eclipse sur Fedora que j'avais fais, question rammmage ca avait pas l'air d'apporter quoique ce soit :)

Quand à la facilité de distribution, je trouve que c'est plutôt un désavantage : le bytecode a l'avantage d'être portable, la phase de JIT est pour moi le meilleur compromis : tu distribues un seul binaire, et tu profites de l'exécution native.

Effectivement, mais autant je trouve le copyright de Adobe sur PostScript douteux, je comprends mieux le cas Java, qui peut être une marque déposée. (je suppose que c'est d'ailleur le cas). J'avais jamais penser à ca, cela dis ca peut aussi s'inscrire dans des exceptions comme le reverse engineering, parfoislégitimisé par l'interopérabilité qui en découle.

Tu as des sources SVP ?
Des sources de ? Du fait que le format a était fait par Sun tout seul ? Ben pas vraiment de sources mais un constat :
Specif avant de rentrer à l'OASIS fait par Sun - Specif à la sortie de l'OASIS = aucune modification.
En gros les membres ont votés, et ils ont approuvé le format de Sun, sans rien toucher. Yahoo.
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=o(...)

Sinon le plugin en question il ressemble tout betement a OOo. Ben oui OOo sait lire et ecrire les formats Office et Open Document. 100 % des fonctionnalites pour Open Document (logique) pour les formats Office je ne sais pas (donc je ne balance pas de chiffres) mais en ce qui concerne la lecture je constate qu'OOo me relit bien (pas parfaitement certes mais tres bien quand meme) les documents Office.
Ben vas-y fait le plugin, comme ca tous les utilisateurs d'office pourront enfin lire nos documents ODF qu'on fait sous notre OS libre.

Personne ne demande a Microsoft d'utiliser le format ODT comme format par defaut !
Euh... le journal pointe une FAQ (Frequently != personne) :
Why is Microsoft offering a new standard, rather than simply supporting the file format for the Open Office product (sometimes called ODF)?
Donc si, des gens se demande pourquoi MS a besoin d'un autre format que ODF.

Ce qu'on lui demande est de pouvoir exporter/importer, out-of-the-box, le format ouvert ODT
Justement ce que j'ai voulu montrer : c'est pas possible. Aussi vrai qu'il n'est pas possible que OOo gère intégralement MS Office à moins d'être fonctionnelement identique. Je vois pas l'intérêt qu'à MS à supporter "partiellement ODF" sachant qu'il sera perpétuellement critiqué justement pour ce côté "partiel" (lié à l'ODF lui même, pas à MS pourtant). En refusant d'utiliser l'ODF, ils se démarquent du courant que veut faire passer Sun : "l'ODF est un standard". En n'incluant aucun support pour l'ODF, MS montre clairement son opposition à ce format. MS implémentera donc le support de l'ODF peut être un jour, non pas parcque c'est un standard, mais parqu'il y aura beaucoup de demande de la part de ses clients (comme ils le font pour le PDF qu'ils se décident à supporter face aux demandes)

Comme ca il est a peu pres sur que c'est ce format qui sera utilise et que Word conservera sa position "en avance"
Evidemment. Et Sun tu crois qu'il tente de faire quoi en "standardisant" l'ODF ? Exactement pareil. La décision de MS est donc tout à fait logique.

La rapidite ? c'est important pour le format par defaut qu'on utilise en interne mais ce n'est pas critique pour un format d'echange, qu'on utilise qu'a l'exportation.
Si l'ODT devenait un standard de fait (comprendre répendu), t'aurais d'un côté la suite MS Office qui se coltinerait à chaque fois la lecture puis l'écriture avec en permanence une conversion : résultat lenteurs permanente (je prends l'exemple con d'un document qui circule dans une boîte où ce n'est pas comme tu dis le format d'échange mais directement le document de travail). De l'autre côté t'aura la suite OOo qui gère nativement le format et qui sera clairement avantagé.
Le problème de l'ODF, c'est de vouloir faire d'un format de travail un format d'échange. C'est avantager exclusivement une suite Office, il est tout à fait normal que MS refuse celà.

Et pour un traitement de texte 99% des fonctionnalites courantes sont gerees a la fois par OOo et Office, et sont disponibles dans le format OOo.
99% ! Genre ! Et c'est moi qui suis de mauvaise foi. Alors pourquoi OOo ne gère pas intégralement le format XML Office 2003 qui est documenté ?
Pourquoi KOffice a de nombreux problèmes à gérer le format ODF ?

S'il y a des facilités entre OOo et MS Office, c'est uniquement parcque OOo essai de "copier" MS Office (fonctionnelement) contrairement à KOffice : si comme tu dis 99% des fonctionnalités étaient identiques, on aurait 2 produits identiques : quel es l'intérêt ? Chaque concurrent (Sun, KOffice, MS) ont besoin d'avoir une liberté pour innover, et pour cela il faut un format neutre qui soit un vrai format d'échange, bref qui ne soit pas le format de travail de OOo.

Sun a voulu imposer son format tout seul, bien, bah qu'il démontre qu'il est interopérable en écrivant un plugin à Word qui fait l'import/export.

Ah oui tiens la réaction de RSF :
http://www.pcinpact.com/actu/news/26270-Censure-de-Google-en(...)
Citation :
La liberté d’expression n’est pas un principe accessoire, que l’on peut mettre de côté lorsqu’on opère dans une dictature. C’est une valeur reconnue par la Déclaration universelle des Droits de l’Homme et inscrite dans la Constitution chinoise

Des explications ? Ben j'en ai donné : les logiciels n'ont pas les mêmes fonctionnalités. Si tel soft propose une fonctionnalité et permet sa sauvegarde les informations associées dans un format de document, et que tel autre soft ne propose pas la même fonctionnalité, il sera bien impossible pour lui de traiter correctement ces informations.
Tu prends n'importe quel différence entre les 2 suites OOo et MS Office, ca te fait autant de problème potentiels dans les 2 formats (MS et ODF).

Un format interopérable doit être indépendant et reprendre les points communs, quitte à ne pas être aussi puissant que format dédié à chaque soft. Mais ca demande la création d'un vrai standard par les principaux acteurs.

De toute façon le format ODF ne pose pas de problème uniquement à MS, il pose aussi problème aux autres suite office, comme KOffice, qui ne peut supporter tout le format, ce qui en montre clairement les limites.

Comment peuvent ils parler de compatibilité ascendante quand on sait pertinament qu'on ne pourra pas ouvrir un doc office 2003 avec office 95 (
Forcement tu prends le cas extrême. Mais leur intention est bien d'intégrer dans Office 2000/XP/2003 des filtres d'import/export vers leur nouveau format.

Leur truc génial dont ils parlent, des feuilles de styles non définis par microsoft mais personnalisé, avec du xml, ça me rappelle quelque chose... ah oui, le XML et les feuilles de style...
Tu dis n'importe quoi. Ils ne parlent pas de feuille de style à aucun moment. Essaye d'utiliser InfoPath dans Office 2003, tu comprendras mieux après de quoi ils parlent.

* Donc pour rendre les choses plus rapides il faut parser du xml qui n'est pas du xml ? Ou bien faire un décompresseur/parseur plus performant, ou un format de compression adapté au logiciel ?
La manière dont est structurée un document XML influence énormément les performances des outils qui l'utilise. Si un grand nombre de transformations est nécessaire pour passer de la représentation XML à la représentation métier de l'appli, tu peux mettre un temps fou à charger les gros documents. Suffit de voir le temps nécessaire pour charger un document MS Office dans OpenOffice.org : non pas que OOo est mal codé et super lent, c'est juste que OOo doit "transformer" un format dans un autre.

Ce n'est pas une justification pour ne pas utiliser ODF, n'importe quel format peut être robust-testé.
Non mais c'est une justification pour utiliser
Techniquement parlant. Après il y a toujours l'aspect "je veux imposer mon format à moi le mien"
Il est à peu prêt normal qu'ils préfèrent choisir un format dont ils ont testé la robustesse dans leurs applications à eux (donc entre autre testé en interne) que de se baser sur un truc nouveau inconnu pour eux. OOo fait exactement pareil en utilisant leur propre format : ils le maîtrise et c'est stratégique.

Ce ne sont que des déclarations d'intention. Je suppose qu'en tant que tel ils n'y aura pas de refus de vente, mais des conditions dans la licence qui font qu'un éditeur de LL n'aura aucun intérêt à achter la dite licence.

Justement, pourquoi pas ODF ?
Euh... t'as lu mon post en entier ? L'ODF est étroitement lié aux fonctionnalités de OOo. Il n'est donc pas adapté à servir de standard d'interopérabilité. Sun a tout à fait le droit d'avoir ce format, c'est même ce que je préconise, OOo doit avoir un format supportant toutes les fonctionnalités d'OOo. Mais qu'on arrête de l'appeler "pompeusement" standard tout en y trouvant un gage d'interopérabilité avec d'autres suites Office qui n'ont pas les mêmes fonctionnalités.

Ah oui et pour troller un peu, je trouve leur commentaire sur Sun et l'OASIS tout à fait pertinent, je ne trouves pas que ce soit de la propagande : le processus de "standardisation" de l'ODF a été du foutage de gueule, en gros Sun a simplement obtenu le label "Standard" sans rien toucher à son format, hors celui-ci est tout sauf parfait, notamment en ce qui concerne l'interopérabilité, ce qui est plutôt balo pour standard. Comme je l'ai dis plus haut, l'ODF est un format liés aux fonctionnalités de OOo, point barre (bref, c'est pas pour MS Office ou KOffice par exemple).

Boh, remarquez: du moment qu'on a les specs, rien n'interdit de se faire un filtre XSLT pour transformer de l'ODF en OpenXML et vice versa.
Faut bien voir que les formats des suites offices ne sont pas des formats d'échanges de données "génériques". Les formats sont étroitement liés aux fonctionnalités des softs pour lesquels ils sont créés. Créer un filtre de transformation d'un format dans l'autre sera forcement imparfait et des informations seront forcement perdues.
Vu à quoi ressemble d'ODF, il aurait été idiot pour MS de le supporter natif. (un filtre import/export je dis pas). Comme il aurait été idiot que OOo utilise le format de MS en natif (au risque d'avoir un clone fonctionnel sans possibilité d'innovation).

L'idée serait peut être de réfléchir à un format d'interopérabilité (un vrai, pas ODF), qui soit assez relativement générique, et où les éditeurs de suite Office seraient réellement impliquées. Bref un format qui ne permettent pas d'avoir une compatibilité à 100% des fonctionnalités, mais qui permette au moins d'échanger un contenu, en laissant chaque acteur faire évoluer son propre format (et donc évoluer les fonctionnalités de leurs softs).

mais si tu veux t'implanter en chine c'est normal de les respecter.
Je dis pas que ce que fais Google est anormal, il respecte les lois chinoises et c'est très bien. Mais bon je penses pouvoir affirmer sans me tromper que la pratique de la censure telle qu'elle est pratiqué là bas relève plus du non respect des droits de l'homme que d'autre chose. D'où le fait que j'en conclu que Google préfère se plier au règles du "marché" potentiel chinois que d'avoir un peu d'éthique, quitte à laisser passer un marché juteux.

Parmis tes choix :
1 - le premier est éthique et respecte leurs lois.
2 - pas possible, ils deviennent hors la loi.
3 - respecte les lois mais pas éthique.

Contrairement à ce que tu penses, je trouve le dernier choix comme moins respectable que les 2 autres.

En même temps personne ne les obliges à s'implanter en Chine... Mais bon les intérêts commerciaux ont été plus fort que l'éthique. Mais bon ca devient de plus en plus utopique de demander à une entité commerciale de penser de manière "humaine".

En même temps rien ne t'obliges à mettre ".exe" à la fin de ton fichier, t'es sous Linux, pas sous Windows, l'OS ne charge pas un exécutable en fonction de l'extension ;)

C'est de bonne guerre, il me sort bien le coup des (TM) et (C) tu trouves ca mieux toi :)

Le framework .NET 1 (et donc Visual Studio 2003) propose déjà ca grâce à ngen.exe :
http://msdn.microsoft.com/library/default.asp?url=/library/e(...)

C'est pas bien compliqué de faire en sorte que l'installeur effectue cette opération.

En même temps t'es pas censé glandouiller sur le net depuis un win2003... c'est dédié aux fonctionnalités serveur normalement :)