pasBill pasGates a écrit 16349 commentaires

Faut te mettre a jour, ca a change depuis 2005 :

http://www.microsoft.com/interop/osp/default.mspx

Q: Is this Promise consistent with open source licensing, namely the GPL? And can anyone implement the specification(s) without any concerns about Microsoft patents?

A: The Open Specification Promise is a simple and clear way to assure that the broadest audience of developers and customers working with commercial or open source software can implement the covered specification(s). We leave it to those implementing these technologies to understand the legal environments in which they operate. This includes people operating in a GPL environment. Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can’t give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s).

C'est principalement une question de prix. La transaction c'est 50% cash / 50% action

Tu remarqueras que la reponse de Yahoo c'est "vous sous-evaluez le prix de Yahoo", bref, ils veulent plus de fric.

Tes 2 paragraphes sont un gros caca nerveux qui n'a rien a voir avec la discussion.

La realite, c'est que les 2 standards ont exactement la meme assurance.

La realite c'est que les 2 societes sont aussi orientees fric l'une que l'autre et qu'il est donc impossible de leur faire confiance.

Tous tes delires sur le fait que MS c'est des maichants et que Sun est un chevalier blanc on s'en tape, c'est la realite qui compte.

Le truc etant qu'a part les moutons du libre, personne ne fait confiance a Sun non plus.

Avec une "legere" difference tout de meme... koffice il y a 3 developpeurs et meme pas a plein temps. Je te trouve tres tres rigolo de comparer un suite office developpe par 3 personnes a temps partiel et une suite office developpe par des centaines a plein temps. Tu veux dire que les devs du libre soit (x*100)% meilleur que ceux de ta boite :)

Oh mais rassures-toi, je compares pas KOffice a Office pour Mac, on sait tous les 2 qu'Office pour Mac est bcp plus complet que KOffice et bcp plus compatible avec Office Windows que KOffice ne l'est avec OO.

Le probleme avec KOffice c'est toi qui le cree, si tu veux t'amuser a compter KOffice comme une suite office a part entiere et le mettre dans le meme sac qu'OO et MS Office, fais le, mais un soft on le compare sur ses capacites, pas sur le nombre de gens qui le developpent. L'utilisateur il s'en fout de savoir si il sont 3 ou 300, soit le soft fait ce qu'il veut, soit il ne le fait pas.

je vais tout de meme repondre a cela. T'es tres gentil mais nulle part dans la doc de ODF il est dit que le java qu'il est possible d'inclure dans ODF comprend le JVM+framework. En l'occurence cela ne concerne que l'inclusion d'applet et il me semble bien que, curieusement, les applets java fonctionne sur des telephones portables.

Perdu, comme je te l'ai montre sur la page de Sun directement dans ce commentaire : http://www.linuxfr.org/comments/903716.html#903716

Les telephones portables et la plupart des PDAs ne supportent pas les applets, car ce support n'est dispo que dans le Personal Profile.

En ce qui concerne microsoft oxml et les plateformes mobile:
1) le meme probleme que java existe a cause de activx

Il n'y a aucun ActiveX specifie dans OpenXML, je te mets au defi de prouver le contraire

2) la theorie c'est un chouilla different de la pratique comme cela a bien ete montre avec tous les formats binaires de microsoft successif ayant soit-disant une compatibilite parfaite avec le format precedent ou encore avec Vista qui devait etre mieux que tous les OS ayant existe. Le jour ou toi ou ton compere pbpg nous montrera un telephone ayant des caracteristitique de fevrier 2008 (je soupconne que dans quelques annees les telephones portables auront autant de memoire voir de puissance que certains pc aujourd'hui) supportant une suite office supportant microsoft oxml on reparlera du probleme de la dependance de java dans ODF. D'ici la theoriquement la teleportation d'etre humain existe, theoriquement.

Comme je te l'ai deja dit, nulle besoin d'implementer une suite office, si tu veux implementer un viewer(ce qui est extremement utile), t'as besoin de bcp moins de ressources.
Le truc etant que ton viewer ne sera pas conforme ODF sans le support Java, mais pourra etre conforme OpenXML vu qu'il n'y a aucune techno empechant son implementation sur un PDA/smartphone.

Tu aimes raconter n'importe quoi. Reste dans ton domaine, tu es bien plus brillant.

Il existe des smartcard qui supportent java depuis longtemps et crois moi, elle n'ont pas quelques centaines Mo de RAM mais quelques centaines Ko.

En parlant de raconter n'importe quoi, je t'invite a aller lire la spec d'ODF, qui comme tu le verras mentionne clairement qu'il faut supporter des applets Java.

Ensuite, tu vas sur le site Java de Sun pour tout ce qui est mobile : http://java.sun.com/javame/technology/index.jsp et tu verras que les applets ne sont supporte que dans le Personal Profile.
Resultat, pas de support d'applets sur telephones mobiles et la plupart des PDAs, et bien sur, pas de support d'applets sur ta smartcard.

Java nécessite une infinité moins de puissance que n'importe quelle traitement de texte. Tu as déjà vu une suite Office sur un téléphone portable ? Parce que Java y existe depuis longtemps.

Tu sais ce que je peux faire sur mon smartphone ? Je peux lire des documents PDF par exemple.
Je pourrais tout a fait avoir un viewer pour OpenXML, pas besoin d'implementer une suite Office complete.
Le truc, c'est que je ne pourrais pas avoir un viewer ODF 100% standard car il n'y a pas de support des applets Java...

Cela permet aussi d'avoir un code en moyenne 20% plus rapide par exemple...

Tout depend de ce que tu fais. Etre 20% plus rapide pour un soft qui passe la plupart de son temps a attendre que l'utilisateur presse les touches du clavier c'est sans interet.

Ils n'ont jamais parle de le mettre dans un SP.

Quand a changer des trucs, probablement autant qu'avec OO et ODF aujourd'hui si tu veux mettre une formule dans ton document...

Resultat, je te conseille d'utiliser des fichier ASCII.

Java applets are described as native objects in the OpenDocument specification (§9.3.4). This means any full implementations will require a Java Virtual Machine present from within the application. However, conformance to the standard does not require a full implementation.

source wikipedia

Super !!

Et tu sais quoi ? Si tu lis la spec d'OpenXML, tous ces trucs dont tu te plains (autoSpaceLikeWord95, ...) sont optionels aussi, pourtant tu ne t'es pas prive de dire que cela rendait impossible une implementation.

Comment se faire prendre a son propre jeu...

T'as beau le repeter c'est faux.

J'ai pas besoin de le repeter, c'est un fait etabli, suffit de lire la spec pour s'en rendre compte.

Tu regardes la spec d'OpenXML et tu n'y verras aucune technologie lourde.

Tu regardes la spec d'ODF, et tu verras qu'il est clairement specifie qu'il faut pouvoir faire tourner des applets Java.
Ensuite, tu vas sur le site Java de Sun, et tu verras que les applets Java ne sont supportes qu'a partir de certains types d'appareils(gros PDA), pas en dessous.
Resultat, tu ne _peux pas_ implementer ODF en te conformant au standard sur des plateformes plus legeres.

Quand au ActiveX, inutile d'y repondre, nulle part la spec OpenXML parle d'ActiveX.

ah ah ah voyons voir ah oui mon telephone a java a l'interieur et il a vraiment rien comme memoire.

Non il a Java Mobile, mais visiblement une fois de plus (difference CPU 32<->64bit, etc...) tu ne comprends rien au sujet.

Le support des applets est uniquement present dans le Personal Profile, qui n'est pas supporte sur les telephones mobiles et petits PDA.

http://developers.sun.com/mobility/midp/articles/models/

On the J2ME platform, applet support is currently found only in the Personal Profile.

cf. http://java.sun.com/javame/technology/index.jsp pour le support.

Enfin de tout de facon tu parles de ODT avec Java a l'interieur et que cela est trop lour je pense que le meme argument est tout a fait utilisable pour un document ppt (je connais pas l'extension pour microsoft oxml) avec une video de plusieurs dizaines de megs a l'interieur. Ca marchera pas comme un document ODT avec du java a l'interieur ou une video.

De nouveau, rien a voir.
Sur Windows Mobile, Symbian, ... je peux creer une implementation 100% conforme d'OpenXML. Qu'il ne puisse pas lire tous les fichiers par manque de ressources c'est un autre probleme, tout comme Office ne pourrait pas ouvrire un document de 1Go sur une machine avec 128Mo de RAM.

Par contre avec ODF, ton implementation elle n'est pas conforme, car il manque un element. Il est techniquement impossible d'implementer un lecteur ODF 100% conforme sur ces OS.

Tu remarqueras en passant aussi qu'OpenXML ne mandate pas un format de video particulier...

Ton argument sans aucune preuves vu qu'il n'existe aucune implementation de microsoft oxml sur des configs tres legeres est assez ridicule.

Fais seulement, trouves moi une techno dans OpenXML qui force l'OS hote a avoir des ressources serieuses pour etre conforme. La spec est la, fais donc.


ps: va faire tourner un microsoft office 12 sur un pentium 166. C'est pas faisable, OOo ca le fait meme avec java, c'est pas un foudre de guerre loin de la mais cela demarre et est a peu pres utilisable.

Encore une fois, tu melanges spec et implementation. A croire que tu n'y comprends rien.

Je peux t'ecrire un soft bien plus leger qu'Office(ou OO), ayant une utilite bien particuliere (afficher uniquement par exemple), qui lui a besoin de bcp moins de ressources qu'Office/OO.

Avec ODF, ce soft ne sera pas conforme si il ne supporte pas Java, ce qui disqualifie a peu pres toutes les plateformes mobiles, avec OpenXML pas de contrainte de ce type.

Va lire des bouquins d'informatique, prends des cours, ... je sais pas, mais apprends la difference entre une implementation et une spec, c'est pas sorcier.

sur quel plateorme java n'est pas implementable?

Plateformes mobiles au hasard. T'as pas l'air de comprendre que le probleme n'est pas que le code n'est pas portable/ouvert/... mais qu'il faut des ressources pour faire tourner une JVM complete et son framework.

tiens pourtant mon telephone portable a java dedans et c'est un truc tout basique... Ton "argument" est assez foireux car tu n'amenes strictement aucune preuve de tes affirmations.

De nouveau, tu ne comprends rien au niveau technologique. Java c'est un ensemble : JVM+framework.
Ce qu'il y a dans ton telephone mobile, cest Java Mobile, pas le Java que tu as sur ton PC. Le framework est different et limite.
Essaie de faire tourner Eclipse sur ton mobile qu'on rigole...

Mais oui mon cher du coup vous vous tapez des trucs style chroot avec des redondances de librairies etc. Je comprend mieux la dizaine de gigas pour installer un systeme nu Microsoft Vista.

Ah oui c'est vrai, Linux ne fait pas cela lui hein ?

Ah si tiens, ils font de meme... Rigolo non ?

ODT c'est pas portable car java existe pas partout
microsoft oxml n'existe que sous x86 windows et macos X mais ca c'est portable.

ODT n'est pas totalement portable car Java _ne peut pas exister_ partout.

OpenXML, bien que n'ayant que des implementations sur x86 sur plusieurs OS cependant est portable car _il est possible_ de l'implementer sur les autres plateformes.

Pour t'aider a comprendre : Il est possible de supporter OpenXML sur un systeme avec qqe megaoctets de RAM et un cpu peu puissant, avec ODF par contre, tu ne peux pas avoir une implementation conforme, car ton systeme n'est pas assez puissant pour supporter Java.

Visiblement t'as toujours du mal a comprendre la difference entre ce qui est fait, ce qui est faisable, et ce qui n'est pas faisable.

Apres j'ai gentiment devie sur le x64 car TU as parle de support sur autre plateforme. Cela me fait rigoler que ta boite soit toujours aussi incapable de sortir des softs x64. Tu veux des exemples d'utilite? Pour un tableur faire des calculs plus precis a oui zut je comprend maintenant ta remarque et pourquoi c'est inutile pour Microsoft Office vu comme excel est doue pour les calculs... :)

Merci de passer pour un idiot complet.
La difference entre un CPU 64bit et un 32bit ce n'est pas de faire des calculs sur 64bit, les CPU x86 d'hier en etaient deja capable, ca donne la possibilite d'addresser 2^64 bytes en RAM a comparer aux 2^32 bytes des CPU x86 .
Bref, aucune difference en precision de calcul, ca te permet juste d'avoir un document Word ou Excel de >3Go en RAM si l'envie te passe.

Si tu comprenais un minimum l'informatique mon cher, tu aurais compris que MS n'a pas sorti Office pour x64 alors qu'il a sorti Exchange, SQL Server, ... pour x64 car c'est totalement inutile. Personne au jour d'aujourd'hui n'est limite dans son utilisation d'Office par la limite des 4Go de RAM du x86

Dis moi, tu fais expres de ne pas comprendre hein ?

Java, ca a beau etre ouvert, GPL, libre, etc... ca n'en fait pas moins une dependance extremement lourde et inutile. Implementer Java sur une plateforme requiert que la plateforme ait une quantite de ressources CPU/memoire/... non negligeable, par sa spec, Java limite les plateformes sur lesquelles il est implementable car certaines de ces plateformes ne peuvent tout simplement pas l'implementer efficacement par manque de ressources.

OpenXML n'a rien de cela, tu remarqueras qu'il n'y a aucune dependance sur C# et sa machine virtuelle par exemple.

Yahoo! ira a celui qui donne la meilleure offre aux actionnaires, vu qu'il va falloir leur acheter leurs actions pour avoir >50% , et la, ben a part le prix, il n'y a pas grand-chose d'autre qui compte ...

Puisque tu insistes pour passer pour un idiot:

Et si nous donnais l'utilite aujourd'hui d'une version x64 d'Office ? Elle amenerait quoi de plus par rapport a la version actuelle ?

Vraiment, si tu veux lancer des piques, choisis les mieux, parce que la tu donnes le baton pour te faire battre.

Je me demandes si tu fais expres ou si tu es tout simplement incompetent...

Tu connais la difference entre une spec et l'implementation d'une spec ?

La spec : ODF requiert Java, c'est un fait, et cela limite son applicabilite aux plateformes supportant Java.

Implementation: MS Office est _une_ implementation d'OpenXML, le fait qu'il n'existe que sur Mac/Windows ne signifie pas que la spec est limitee a ces 2 plateformes.

Ce qui est impensable.

AOL n'a absolument pas les moyens financiers pour contrer MS.

Tiens c'est marrant : http://xml.coverpages.org/ODF-Adoption-CFP.html

Voyons voir les membres fondateurs :

Gary Edwards, Open Document Foundation, Inc., gary.edwards@opendocument.us
Sam Hiser, Open Document Foundation, Inc., sam.hiser@opendocument.us
Don Harbison, IBM, donald_harbison@us.ibm.com
Suchitra Pyarelal, National Informatics Center of the Government of India, suchitra@nic.in
Charles-H Schulz, Ars Aperta, charles-h.schulz@arsaperta.com
Ryan Singer, Open Document Foundation, Inc., ryan.singer@opendocument.us
...

Tiens, il y 3 guignols parmis les gens qui ont fonde ODF.

Voyons un peu ce que ton grand guru Rob Weir pense:
http://www.robweir.com/blog/2007/11/document-formats-guide-f(...)

@Sam, The Foundation's previous contributions are not being questioned here. You are beating up on a strawman of your own invention. par Rob Weir, tiens, on dirait qu'il considere les gens de la fondation avec un minimum de respect lui.

Voyons donc qui etait membre fondateur d'OpenFormula : http://lists.oasis-open.org/archives/office-formula/200602/m(...)

Marrant, 2 gars de la fondation !

Voyons un peu qui est _aujourd'hui_ le Chair du TC d'OpenFormula : http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=o(...)

Marrant tiens, ce meme gars qu faisait partie de la fondation...

A se demander, avec tant de guignols comme tu les appelles a des postes aussi importants, la spec ODF doit etre sacrement pourrie...

Mais la confiance on s'en fout mon cher.
Ici ce qui compte c'est une *assurance*, et aucun des 2 cote ne garantit quoi que ce soit de plus que l'autre.

Tu veux dire que en 15 ans les quelques centaines de developpeurs Office chez microsoft ont pas reussi a implementer cela???? Ouhaou je suis impressionne!!!!!

Qui te dit qu'ils ont essaye ?

Au fait le lien sur ce sujet puis aussi le lien sur le meme truc pour windows car exactement le meme probleme existe dessus ;) (transformation d'un champ equation en image ca fait 15 ans que ca existe et 15 ans que c'est tres chiant).

Pas besoin d'un lien, suffit de comprendre que l'editeur d'equations sauve l'equation comme une image dans le document, ce qui rend evidemment l'edition a peu pres impossible sur Mac.

Les gens insastisfaits ont plusieurs autres options (une s'appelle MacType notamment) pour pouvoir inclure et editer des equations en passant de windows a mac et vice-versa.

Entre koffice (je sais vraiment pas ce que tu as contre les 3 pauvres developpeurs de cette suite) et OOo c'est presque vrai mais entre OOo et OOo que ce soit sous Unix, sous windows ou sous Mac (x86 ou x64) je recupere exactement la meme chose. Ce qui est rigolo c'est que la meme chose avec MS Office windows ou Mac (seulement 2 petites plateformes supporte) ca marche pas. J'obtiens pas le meme resultat...

Office Windows et Office Mac ne sont pas les memes produits. C'est pas du tout le meme code, pas les memes developpeurs, pas forcement les memes fonctionalites non plus. Bref, c'est un cas similaire a KOffice<->OO, pas a OO Linux <-> OO Windows

Ok c'est un peu complexe deux plateformes differentes on va tenter entre windows et windows et deux versions differentes... Ah zut la aussi ca foire ben cest pas de bol tout de meme.

T'as raison c'est drole.
Le probleme c'est que le probleme se produit avec OO entre differentes versions aussi.

Marrant je me demande comment ca va se passer pour les documents microsoft oxml pre-ISO (si cela passe). Je sens que ca va etre comme avec le fabuleux format xml qui devait tout ecraser de microsoft office 2007): les utilisateurs vont acheter de la vaseline...

Ca s'appelle une conversion.

Perdu, Mac Office 2008 est sorti le 15 janvier.

J'imagines que tu dois te fatiguer, ca doit etre dur de gratter a droite a gauche pour essayer de trouver une phrase ici ou la qui a peu pres supporte ta position bancale.

ODT est clairement pas un format qui a ete concu pour etre un standard a la base, l'inclusion de Java etant l'exemple flagrant vu que cela limite fortement la disponibilite du format sur des plateformes n'ayant pas de JVM decente ou n'ayant pas les ressources CPU/memoire pour faire tourner une JVM en plus du soft qui lit le document ODT.

Ce qui fait tout de meme beaucoup moins de monde et qui plus est il est bien indique que le support des versions actuelles de koffice pour ODF est incomplet mais cela tu le sais pertinnement.

Tout comme il a toujours ete indique que le support des formules etait incomplet dans Office pour Mac...

Quand au nombre de gens affectes, tu me fais bien rire. C'est pas le nombre absolu de gens qui compte, mais la proportion par rapport au nombre de documents, et la, c'est pas gagne: 3-4% de gens ayant un Mac par rapport a Windows, combien de gens ont KOffice par rapport a OO ?

Tu fais de l'ascii art aussi? Ca doit etre rigolo a lire tes documents...

Avec OO et KOffice c'est pourtant la seule possibilite si tu veux ouvrire tes documents soi-disant standards ODF.


Et oui que veux tu ma formation scientifique me fait preferer un manque que des erreurs. Un manque tu le combles les erreurs tu es dans la merde.

Marrant, j'etais pourtant convaincu que les erreurs se corrigent vu que le standard n'a pas encore ete accepte. Chose qu'on ne peut pas dire d'ODF.

Super, ODF 1.2 est couvert, est 1.3 peut-etre pas, t'as gagne 6 mois, yeay !!!

De tout de facon il est clairement pas dans l'interet de SUN de se retirer de OASIS donc le risque pour la version 1.3 il tend a peu pres vers 0.

Tiens, tu predis le futur maintenant ?