pasBill pasGates a écrit 16168 commentaires

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 ?

Ben si ils sont si peu credibles, ca en dit long sur la credibilite d'ODF mon cher, parce qu'ils etaient parmis les rares membres actifs du TC.

T'imagines la qualite d'un format en partie decide par des guignols...

tu peux tu peux les utlisateurs des equations sous Microsoft Office qui echangent des documents n'en doutent pas eux, ils pleurent!

A peu pres autant que ceux qui echangent des documents entre KOffice et OO

Ah non non pas du tout effaces c'est 0 lettres en ecriture :) La suite de Apple elle sait pas le faire point barre. Si c'est que pour lire comme dit plus haut autant envoyer un document PDF.

Si c'est pour lire/editer du texte uniquement, autant envoyer un fichier ASCII plutot qu'ODF.

A ce jour micorosft oxml ne sait toujours pas faire des statistiques c'est couillon tout de meme.

J'adores ta comparaison, une ou deux erreurs dans les fonctions statistiques compare a un manque total de support pour les formules. C'est dingue jusqu'ou tu peux aller pour soutenir tes positions intenables.

Soi tu n'as visiblement rien compris soi tu fais expres.

Si demain Sun quitte le comite ODF, alors ODF 1.2 n'aura pas la couverture de brevets, fini les futures versions d'ODF, faudra creer un nouveau format.

Bref, exactement le meme topo que si MS decidait que la prochaine version d'OOXML n'est pas couverte par la promesse.

b) Perdu, Sun a fait cette promesse uniquement pour les versions auquel il participe, si demain Sun stoppe sa participation, fini la couverture de brevets.

Super, il a dit que c'etait pas lui, et tu le crois sur parole bien entendu ? J'esperes que tu fais de meme avec MS alors...

Ce document si il etait sur le web il devrait etre trouvable, on ne va pas me dire qu'un document sur un sujet autant discute et controverse n'a pas de copies qqe part...

donc ils vont utiliser la 2e, et franchement, meme si c'est de maniere légale, je ne suis pas sur que ca va etre quelque chose de super éthique.

Parce qu'IBM a ete ethique avec eux ? Oh non loin de la. Faut pas esperer que MS tende l'autre joue dans ce cas la.

En meme temps, c'est décourageant de voir que son comportement ne change pas. Meme toi tu avoues a moitié penser que c'est pas net ce qu'ils ont fait en Suede.

Leur comportement vis-a-vis du passage a l'ISO est tout a fait normal.
Ils ont laisse passer ODF a l'ISO sans soulever le moindre probleme, ils proposent leur propre format ouvert et se trouvent confronte a une veritable guerre de religion carburant au FUD lancee par les pro-LL et IBM. Il est evident qu'avec un comportement de ce genre, MS va se defendre et contre attaquer. Ce qui s'est passe en Suede, ni toi ni moi ne savons si c'etait planifie ou si c'etait un incident isole par un employe seul dans son coin, tout comme le cas IBM, donc on ne va pas speculer.

Ce qui est sur, c'est que lorsque vous (pro-LL) et IBM avez lance cette gue-guerre, vous avez en quelque sorte conforte dans leurs idees certains chez MS qui pensent que seule une guerre va resoudre le conflit plutot qu'une approche pacifique entre les 2 cotes. Je suis pas sur que cela en valait la peine.