Oui oui on parle de l'incomparable, de l'unique Miguel de Icaza.
Il a sorti quelques perles de toutes beautes recemment. Ca fait longtemps qu'il defend microsoft openxml, c'est lui qui a dit que les 6000 pages de microsoft openxml c'etait la meme chose que 600 pages pour ODF. Son raisonnement etant que si tu rajoutais la definition des normes reutilisaient par ODF cela arrivait a un truc comme 5000 pages. En gros pour lui le SVG, openformula (qu'il a reclame a grand cris...), les dates, les unites cela doit etre redefini (avec des bugs) par toutes nouvelles normes...
Enfin voici les deux plus belles phrases:
OOXML is a superb standard
ce qui se traduit par:
OOXML est un magnifique standard
Il a un esprit critique absolument fabuleux... Enfin la raison pour laquelle il dit ca c'est que c'est plus simple de traduire des documents microsoft office (format binaire) dans microsoft openxml... Le coup de l'interoperabilite et de perennite c'est pas tres important.
et surtout, en reponse a la question si silverlight n'a pas de probleme de brevet:
Not as long as you get/download Moonlight from Novell which will include patent coverage.
ce qui se traduit par:
Non pas de probleme (ndt: avec les brevets) tant que vous obtenez/downloadez Moonlight a partir de Novell qui fournira une couverture (ndt: legale) incluant les brevets
En resume, Moonlight (la version silverlight developpe par de Icaza et Novell) c'est un logiciel qui ne risque rien uniquement si vous le recuperez depuis chez Novell. Ce qui veut dire qu'il ne peut pas etre inclu dans aucune autre distribution. C'est un certain point de vue (tres microsoftien) sur le logiciel libre je trouve. Je trouve ca assez ironique surtout en pensant qu'il a lance le projet Gnome parceque KDE n'etait pas libre.
Enfin en disant cela il admet bien que C# est blinde de brevet et que mono en violent pas mal de facon connu.
oups j'ai failli oublier le lien:
http://groups.google.com/group/tiraniaorg-blog-comments/brow(...)
# Hmm
Posté par gnumdk (site web personnel) . Évalué à 10.
>exemple)
En quoi Corba est une techno microsoftienne?
[^] # Re: Hmm
Posté par abramov_MS . Évalué à -1.
[^] # Re: Hmm
Posté par Pat _ . Évalué à 5.
[^] # Re: Hmm
Posté par Antoine . Évalué à 8.
C'est surtout de la mauvaise foi absolument minable vu que tu avais déjà sorti cet argument (Corba == Microsoft) et qu'on t'avait déjà répondu que c'était faux.
# Esprit critique, quand tu nous tiens ...
Posté par Thomas Douillard . Évalué à 10.
C'est dangereux l'invocation de l'esprit critique. On pourrait s'intéresser au tien après.
[^] # Re: Esprit critique, quand tu nous tiens ...
Posté par abramov_MS . Évalué à 9.
[^] # Re: Esprit critique, quand tu nous tiens ...
Posté par Anonyme . Évalué à 7.
rien de mechant hein ! c'est juste que ton pseudo rejoins la faune influente de linuxfr, pbpg, etc...
oui je vais faire un blog
[^] # Re: Esprit critique, quand tu nous tiens ...
Posté par briaeros007 . Évalué à 3.
[^] # Re: Esprit critique, quand tu nous tiens ...
Posté par Bozo_le_clown . Évalué à 5.
Ca doit doit être un usurpateur parce que le vrai Albert a pris congé de DLFP pour une période indéterminée et ne s'intéresse plus à OOXML
http://linuxfr.org/comments/864368.html#864368
[^] # Re: Esprit critique, quand tu nous tiens ...
Posté par beagf (site web personnel) . Évalué à -2.
Vu ton orthographe, on est en droit de se poser des questions à ce sujet...
# c'est bô l'amour :-)
Posté par Laurent Carlier . Évalué à 1.
http://www.cafepress.com/miggysellout
sympa un T-shirt pour chien :-)
-->[]
# ATTENTION
Posté par alexissoft . Évalué à 2.
[^] # Re: ATTENTION
Posté par GCN (site web personnel) . Évalué à 2.
--> http://linuxfr.org/comments/864736.html#864736
[^] # Re: ATTENTION
Posté par Laurent Carlier . Évalué à 6.
On a plus facilement 100% de participants à Hawaï, qu'a Nancy :-)
[^] # Re: ATTENTION
Posté par Rémi Pannequin . Évalué à 2.
Sur les listes, oui ! Dans les salles, j'ai comme un doute...
Pi c'est très bô Nancy d'abord. « Nancy au printemps c'est presque le midi... » (Joe Dassin). Na ! même pas ironique...
[^] # Re: ATTENTION
Posté par Sylvain Sauvage . Évalué à 8.
Ça dépend : elle a combien de places Nancy ? (Daniella, on pouvait y aller à trois…)
[^] # Re: ATTENTION
Posté par IsNotGood . Évalué à 5.
Donc évitez Moonlight.
[^] # Re: ATTENTION
Posté par mats . Évalué à 4.
http://tirania.org/blog/archive/2007/Sep-05.html
En gros, pour ceux qui n'ont pas le temps de lire, ça dit :
- que Microsoft rend accessible l'ensemble des outils permettant de tester une implémentation des spécifications de Silverlight ;
- que Microsoft rend accessible l'ensemble des spécifications de Silverlight ;
- que Microsoft rend accessible les codecs audio et video pour qu'ils soient utilisés par Moonlight (les plateformes supportées sont x86 et x86_64, pour le reste, il faudra rester avec ffmpeg qui a la mauvaise idée d'avoir une licence pas cool pour le commerce :-) ;
- ...
donc qu'il existe une réelle collaboration entre Microsoft et Novell.
En bref, Silverlight va nous être imposé aux forceps (quand on connaît la force commerciale du géant) et c'est même totalement assumé :
« To me, Moonlight is of crucial importance because I believe that Microsoft will be successful in getting Silverlight deployed in many sites, and as a Linux desktop user (unlike some outraged open source advocates that stick to OSX :-) I want to make sure that I have access to the Silverlight content from my Linux box. » (http://tirania.org/blog/archive/2007/Sep-07.html )
Voilà
# mouais faudrait pas pousser
Posté par nazcafan . Évalué à 10.
Après, c'est vrai que je suis particulièrement dubitatif concernant certaines de ses prises de positions, mais de là à le peindre en grand guignol, c'est un peu facile. Personnellement, je trouve que ses affirmations sur son blog (au sujet d'OOXML) sont presque gratuites (il ne cite pas grand chose pour soutenir ses dires) mais force est de reconnaître que je n'ai pas la moindre compétence pour lire une spécification de ce type (une fois, j'ai dû consulter les draft papers du C++, et c'était moyen drôle). Finalement mon opinion (très défavorable) sur ce format ne s'est elle pas faite parce que je lis /. et dlfp ?
J'avoue que ma position sur ce sujet est un peu subjective, parce que j'ai lu les critiques faites par les entités du genre no-ooxml (qui s'appuient effectivement sur des arguments techniques), mais ai-je fait l'effort de rechercher des réponses techniques à ces critiques ? non ! Donc finalement, je n'ai vu la question que d'un seul point de vue.
De là à dire que ces réponses existent, c'est autre chose. Donc si quelqu'un pouvait jouer le rôle de l'avocat du diable (non, pas PBPG, avec lui ça finit toujours en guerre des tranchées contre Albert) et m'expliquer posément les aspects techniques positifs de OOXML, je serais ravi de l'écouter.
[^] # Re: mouais faudrait pas pousser
Posté par phytos . Évalué à 10.
Il aurait pu rendre le reste de gnome utilisable aussi... ;)
[^] # Re: mouais faudrait pas pousser
Posté par IsNotGood . Évalué à 1.
C'était pour Gnome 2.0. Et il a quitté Gnome depuis Gnome 1.4. Aujourd'hui (et depuis de nombreuses années) son influence dans Gnome est quasi nulle (à part son lobbying pro-C#).
[^] # Re: mouais faudrait pas pousser
Posté par IsNotGood . Évalué à 2.
On trouvera peut-être une explication dans son compte en banque...
[^] # Re: mouais faudrait pas pousser
Posté par benoar . Évalué à 7.
Je pense qu'avec ce qu'il a exposé ici, il y a de quoi se faire une bonne idée (oui c'est long à lire 300 commentaires par news, mais déjà prend les commentaires de pbpg à plus de 0 (oui, yen a pas beaucoup) et tu pourra voir quelques trucs intéressants)
# Je suis mauvaise langue...
Posté par windu.2b . Évalué à 9.
Avant de lire cette phrase, jai cru que tu faisais une dépêche sur PBPG!
Comme quoi...
:-p
[^] # Re: Je suis mauvaise langue...
Posté par Laurent Carlier . Évalué à 8.
# Mon avis ca fait longtemps
Posté par TImaniac (site web personnel) . Évalué à 2.
Au contraire, son problème c'est l'interopérabilité et la pérennité de 90% des documents Office dans le monde : et c'est à ca que sert OOXML : être interopérable avec la principale suite du marché et apporter une "certaine" pérénité aux documents historiquement créé avec un format binaire alacon.
En cela OOXML est superbe : il autorise la traduction de vieux documents depuis un format non sûr vers quelque chose de plus pérenne dans le temps.
OOXML n'a pas le même but qu'ODF, non seulement ca justifie bon nombre de ses défauts (sans les excuser), mais sa justifie son existence et quelque part le fait qu'il ne fait pas double emploi avec ODF.
D'ailleur c'est rigolo de constater que niveau interopérabilité, il est beaucoup plus facile d'implémenter OOXML que ODF, tout simplement parcque OOXML se base sur l'existant qui est bien souvent déjà implémenté. C'est pas moi qui le dit, ni MDI, c'est un développeur de Gnumeric.
http://blogs.gnome.org/jody/2007/09/10/odf-vs-oox-asking-the(...)
En résumé : il y a 2 problématiques dans le support d'un format 'externe' : lire et interpréter le contenu d'une part, et le convertir dans le format natif de l'outil. OOXML cherche à résoudre le premier point : la lecture et l'interprétation sont largement facilité par l'utilisation de technos connues (XML + nombreux outils existant). En conservant la sémantique des vieux documents, il permet aux outils ayant déjà implémentés la conversion vers leur format natif de récupérer une bonne partie du code existant. ODF oblige à repartir "from scratch" en se basant sur la sémantique orientée OOo.
Donc d'un point de vue interopérabilité, si on parle de l'existant, OOXML a tout à fait sa place.
Alors oui, sinon le format a pleins de trucs "crades" qu'on aimerait plus voir, mais ils ont une raison d'être, et heuresement c'est en cela différent de l'ODF, l'OOXML a une raison d'exister : être crade mais dans un but valable : l'interopérabilité.
C'est pas l'avenir, mais une bonne transition.
Pour ce qui est de l'interopérabilité au sens monde des bisounours où on a un format unique Office lisible nativement par tous les outils sans problème, c'est un saint graal inaccessible, les formats Office étant par définition la représentation sous forme de données d'un ensemble de fonctionnalités, à moins de contraindre toutes les suites à avoir exactement les mêmes fonctionnalités et comportement...
Suffit de constater toutes les difficultés autour de l'ODF : tout le monde veut y ajouter ses modifs qui l'arrangerait dans sa suite, et personne ne veut d'un truc qu'il ne peut pas supporter. Au final statu-quo, on s'éloignera jamais vraiment de l'implémentation de référence OOo.
Alors un joli format qui au final ne sera vraiment interopérable qu'avec lui même ou un format crade qui permet d'assurer un minimum d'avenir à des milliards de documents existant...
et surtout, en reponse a la question si silverlight n'a pas de probleme de brevet: Not as long as you get/download Moonlight from Novell which will include patent coverage.
Oui, Novell offre une couverture juridique à ceux qui télécharge Moonlight depuis leur serveur. Et ? Protéger des utilisateurs contre un système de merde c'est mal ? Si ca te plaît pas, tu fais comme pour tous les autres softs libre que tu télécharges tous les jours sur sourceforge où ton repository deb/rpm : tu ne demandes pas de protection à Novell le jour où telle ou telle boîte t'attaque : ils t'offrent une protection, t'es pas obligé de l'utiliser.
C'est pas parcqu'ils t'offrent cette protection qu'il faut en déduire fallacieusement que le produit est dangereux à utiliser sans la protection : tous les autres softs libres violent une floppée de brevets (sans le savoir ou pas), ils sont tous potentiellement dangereux.
Alors oui, chercher à démolir l'OOXML auprès de l'ISO comme le fait IBM est ridicule, quand avant un format prétendu "universelle et interopérable" comme l'ODF a été normalisé alors qu'il n'était pertinemment pas implémentable dans la principale suite Office du marché.
Si l'ODF a le droit d'exister en tant que norme ISO (ce qui est largement compréhensible pour un tas de raison), l'OOXML a également le droit de l'être puisqu'il bouche largement des lacunes de l'ODF.
Après il faut utiliser le processus de l'ISO pour profiter d'une révision du format OOXML et l'améliorer là où ca peut l'être, sans chercher à singer OOo. En cela la proposition de l'AFNOR me paraît tout à fait pertinente : séparer ce qui est le coeur du format et les spécificités à l'interopérabilité avec l'existant.
[^] # Re: Mon avis ca fait longtemps
Posté par TImaniac (site web personnel) . Évalué à 2.
C'est pas parcqu'ils t'offrent cette protection qu'il faut en déduire fallacieusement que le produit est dangereux à utiliser sans la protection : tous les autres softs libres violent une floppée de brevets (sans le savoir ou pas), ils sont tous potentiellement dangereux.
-->
C'est pas parcqu'ils t'offrent cette protection qu'il faut en déduire fallacieusement que le produit est plus dangereux que les autres softs à utiliser sans la protection : tous les autres softs libres violent potentiellement une floppée de brevets (sans le savoir ou pas), ils sont tous potentiellement dangereux.
[^] # Re: Mon avis ca fait longtemps
Posté par Gilles G. . Évalué à 10.
Mais bien sur. En réfléchissant comme ça , on va normaliser tous les formats tant qu'on y est.
Tu penses ce que tu veux du format OOXML, bien ou mal. Mais ce format n'est pas une norme.
Une norme ne dit pas: "Un extincteur qui respecte la norme ISO312 est fabriqué suivant le procédé non documenté de la société TRUC."
Une norme de sécurité sur les voitures ne redéfinit pas les normes sur les pneus.
Une norme est rédigée suivant un processus ouvert au différents acteurs du marché.
C'est pourtant simple à comprendre non? OOXML n'est pas une norme, et cela sans jugement de qualité sur le format lui-même.
[^] # Re: Mon avis ca fait longtemps
Posté par TImaniac (site web personnel) . Évalué à 0.
Dans la pratique, l'ODF a été normalisé dans sa V1 sans OpenFormula, ce qui revient à ta réflexion :
" "Un extincteur qui respecte la norme ISO312 est fabriqué suivant le procédé non documenté de la société TRUC."
En fait c'était encore pire, c'était : pour respecter la norme ISO312, il faut y mettre... ce que vous voulez on a oublié de le préciser.
Concrêtement, le processus de normalisation de l'ODF a été laxiste parcque tous les partis étaient d'accord pour accepter son passage ISO, même MS.
Une norme est rédigée suivant un processus ouvert au différents acteurs du marché.
Bah que je sache, l'ODF et l'OOXML suivent le même parcours à l'ISO, avec les mêmes acteurs potentiels. Tous peuvent participer à l'amélioration du format. Comme ils pouvaient d'ailleur également le faire à l'ECMA ou à l'OASIS auparavant.
Mais bon là c'est pareil, c'est la thoérie. Dans la pratique c'est uniquement un rapport de force et d'influence des plus grosses boîtes.
OOXML n'est pas une norme, et cela sans jugement de qualité sur le format lui-même.
Partant de là, l'ODF n'aurait jamais dû être normalisé, et je suis prêt à parier qu'une floppée de trucs standardisés à l'ISO ont dû avoir les mêmes entorses.
Cela dis, ca n'empêche pas de chercher à améliorer l'OOXML là où il est critiquer, du moment qu'il ne pert pas son intérêt premier : l'interopérabilité avec l'existant, ce que n'offre pas l'ODF.
[^] # Re: Mon avis ca fait longtemps
Posté par Gilles G. . Évalué à 6.
Ça n'a donc rien à voir, il y a une différence entre
* ne pas préciser comment faire par oubli (ça a été corrigé dans les versions suivantes)
* préciser que la façon de faire _est_ non documentée. Il ne s'agit pas d'une omission, c'est intentionnel.
Tu sais mal.
Microsoft essaie de faire passer OOXML en procédure fast-track, ce qui implique que les éventuelles contestations soient formulées dans un délai d'un mois (pour une norme de 6000 pages).
C'est donc bien une tentative d'élimination des autres acteurs du marché.
Tu peux m'expliquer ton raisonnement, j'ai du mal à comprendre. Je te dis que OOXML ne peux pas être normalisé parce qu'il réinvente la roue, qu'il y a des éléments non documentés, et que le processus n'est pas ouvert, et tu me dis: "Partant de là, l'ODF n'aurait jamais dû être normalisé"
????
OK.
Mais OOXML n'est pas une norme.
[^] # Re: Mon avis ca fait longtemps
Posté par TImaniac (site web personnel) . Évalué à -2.
* préciser que la façon de faire _est_ non documentée. Il ne s'agit pas d'une omission, c'est intentionnel.
Le résultat est le même : c'est pas implémentable. Et c'est quelle ligne dans la doc OOXML qu'il est écrit que tel ou tel truc doit être utilisé et que c'est explicitement dis que ce n'était pas documenté ?
Ensuite OpenFormula n'était pas un vrai "oubli", c'était "on sait, mais on verra plus tard, pas le temps, faut le logo ISO au plus vite avant MS". Bref pareil, voir pire, le but n'est même pas le support d'un vieux truc non documenté par soucis de compatibilité, c'est un but purement marketing, on se dépêche pour avoir le logo avant le concurrent. Ca en dit long sur l'envie d'être interopérable avec le dis concurrent au passage.
Mais prenons un exemple plus parlant : ODF fait explicitement référence à la possibilité d'intégrer une applet Java. C'est pas normalisé, c'est pas à l'ISO. Tu vas me dire c'est quand même documenté, spécifié. Oui et ? L'implémentation de Java dépend d'une foultitude d'autres normes, ne serais-ce que, au pif, MPEG-4. Ensuite cette référence à Java aurait pu au moins avoir le bon goût de faire référence à la spec Java publiée par Sun, pour au moins savoir quelle version implémenter. Enfin si y'a également une vague référence à JDBC en bas du document, à noter que c'est dans un autre contexte que l'intégration d'Applet Java.
L'ODF est-il intégralement implémentable dans ces conditions autrement que par Sun ?
On gueule après MS qui fait référence à des formats non standard alors qu'à l'ISO il existe des équivalent normalisés, et qu'un format ISO devrait faire référence à d'autres normes ISO plutôt que réinventer la roue : ben pourquoi l'ODF ne fait pas référence à la norme ISO du CLR/C# ?
Bizzarement personne n'a rien trouvé à redire au moment du processus de normalisation ISO. Par contre le moindre détail similaire dans OOXML est décrit comme un scandale.
De la même manière dans l'ODF il est fait mention de JavaScript comme langage de script possible (à noter que la porte est laissé ouverte à n'importe quoi comme langage de script, avis aux implémenteurs du format qui vont s'arracher les cheveux si demain quelqu'un choisi autre chose que ce fait Sun) : aucune référence à la norme ECMA, et encore moins à la version qui serait bon d'utiliser.
Autre constat rigolo, on gueule après MS qui propose de faire référence à des trucs non documentés et des blobs binaires, notamment parcqu'il est possible d'intégrer des composants externe style OLE.... ben la norme ODF autorise l'inclusion de composant OLE.
Microsoft essaie de faire passer OOXML en procédure fast-track, ce qui implique que les éventuelles contestations soient formulées dans un délai d'un mois (pour une norme de 6000 pages).
C'est donc bien une tentative d'élimination des autres acteurs du marché.
Oui MS tente le fast-track. Et ? C'est pas tant pour éliminer les autres acteurs du marché, s'ils avaient voulu faire ca, ils seraient pas passé par l'ECMA avant. Le fast-track, c'est pour avoir l'ISO le plus vite possible, étant donné qu'il y a un intérêt commercial à avoir le label "ISO". Ca n'élimine pas les autres acteurs, au contraire, cela leur fait prendre des risques supplémentaires, la preuve en est la rébellions de certains acteurs (IBM par exemple) qui pousse à un vote négatif.
Quand à l'ECMA, pourquoi Sun & IBM sont pas allez y faire un tour ? Personne ne les en a empêché que je sache. Non la réalité c'est qu'ils en avaient rien à battre, leur seul intérêt, c'est que l'ODF soit le seul a avoir le logo ISO pour mieux le vendre en tant que caution auprès des grands organismes.
, qu'il y a des éléments non documentés, et que le processus n'est pas ouvert, et tu me dis: "Partant de là, l'ODF n'aurait jamais dû être normalisé"
Bah ODF y'a des éléments qui n'étaient pas documenté (cf exemples plus haut), et le processus était aussi "ouvert" que celui de l'OOXML : à savoir viendez tous, faites 2 ou 3 modifs du moment que c'est compatible avec notre produit ; faites parler Sun avec OOo d'un côté, MS avec MS Office de l'autre, c'est kif kif bourriquot la même sitatution : MS s'en est rendu compte et à claquer la porte de l'OASIS, de l'autre côté Sun s'attendait au même comportement est a même pas été voir ce qui se passait à l'ECMA.
Tout ca pour dire que pour moi ODF n'est pas plus ou moins respectable que l'OOXML, les 2 ont leurs raisons d'êtres, ont beaucoup de défauts en commun, ont suivit un processus de normalisation à peu prêt similaire... Ah non, pour l'ODF il n'y a pas eu une bande blogger anti-MS à FUDer en permanence. Et c'est ce qu'essai de dire MDI, qui lui a le mérite d'être un développeur ayant déjà touché au domaine à travers le développement de Gnumeric.
[^] # Re: Mon avis ca fait longtemps
Posté par ndesmoul . Évalué à 4.
En même temps la procédure fastrack ne peut être mise en oeuvre que si la proposition est normalisée ailleurs. Le plus facile est de passer par l'ECMA qui accepte des propositions d'industriels selon un processus sans doute beaucoup moins contraignant que d'autres organismes de standardisation. Donc pour passer en fasttrack à l'ISO le passage par l'ECMA était pour MS la meilleure stratégie.
D'autre part il me semble qu'IBM (et SUN?) ont participé au vote à l'ECMA sur OpenXML. IBM a voté contre (SUN je sais pas).
Le problème avec l'ECMA c'est que les propositions ne sont pas examinées avec autant d'intensité qu'à l'ISO. La proposition n'a guère été modifiée lors de son passage à l'ECMA. Pourtant il est maintenant évident après le vote à l'ISO que la proposition en l'état pose problème et qu'elle devra être remaniée.
[^] # Re: Mon avis ca fait longtemps
Posté par IsNotGood . Évalué à 6.
Le classique argument à la con. Étant donné ce que veut faire MS de OOXML, cette "interopérabilité et périnnité" ala MS, MS peut l'avoir sans labélisation ISO, sans XML, sans spèc, etc...
MS le fait très bien depuis des années. Et c'est encore ce que va faire MS, sauf que cette fois il y a la doc (mal foutue, compliqué, partiellement documenté, etc...). En passant, il n'y a que la version actuelle de OOXML qui ne pose pas de problème de brevet (et encore, ce n'est pas claire). Il n'y a aucune garantie pour les versions suivantes (contrairement à ODF).
MS veut l'intéropérabilité avec MS. MS veut la pérennité de son monopole sur les suites bureautique et sur le format de document des suites bureautiques.
> Au contraire, son problème c'est l'interopérabilité et la pérennité de 90% des documents Office dans le monde : et c'est à ca que sert OOXML
Pas de problème, au moins 95 % des documents MS-Office sont importables dans ODF. Et avec ODF il y a une meilleur intéropérabilité, pas de dépendance envers une société, pas de problème de brevet, le format est bien foutu et s'assimile bien plus facilement que OOXML (ce qui garantit son ouverture à plusieurs sociétés), etc...
Bref, pour 95 % des documents MS, ODF est un meilleur choix.
[^] # Re: Mon avis ca fait longtemps
Posté par TImaniac (site web personnel) . Évalué à -1.
Un coup la doc est trop longue, un coup il manque des trucs, un autre coup elle est compliquée, bla bla bla.
Y'a sûrement du vrai dans ce que tu dis, mais pourquoi personne ne se plonge dans le foutu format ODF pour vraiment comparer ? Tout ce qu'on a, c'est une bande de geek libriste anti-MS qui répètes les arguments de 2 ou 3 personnes qui ont regarder avec une impartialité toute relative un seul format, le format à abattre : OOXML.
Ils auraient fait le même boulot sur l'ODF, on aurait pas vu des choses aussi absurde que l'absence d'OpenFormula dans la V1.
La vérité c'est qu'il y a une véritable campagne de dénigrement, et même si beaucoup de critiques techniques sont valables, elles ne justifient que rarement à elle seul la non-acceptation à l'ISO, sinon l'ODF n'aurait jamais dû passé. Par contre je le répète, ca peut être une bonne base pour améliorer l'OOXML.
De plus dans la vraie vie, je l'ai déjà dis plus haut, les développeurs constatent quoi :
- ODF est plus difficile à implémenter que OOXML, parcqu'OOXML se base sur des concepts largement connus (ca fait longtemps qu'on cherche à importer/exporter les .doc & co).
- l'ODF qui existe déjà depuis un bon moment, et aucune suite bureautique n'offre de support acceptable en dehors de OOo.
Bref, l'ODF n'a toujours pas atteind son objectif (enfin si, l'objectif profond était juste pour SUN d'avoir le logo commercial ISO, tout comme MS avec OOXML d'ailleur), y'a que les barbus pour y croire.
Allez bonne soirée, ce post sera de toute façon moinsser, je constate que le niveau des possibilités de discussion sur ce site ne se sont pas améliorer depuis la dernière fois.
[^] # Re: Mon avis ca fait longtemps
Posté par TImaniac (site web personnel) . Évalué à -3.
D'après les exemples proposés, on peut inclure des images .gif. Pourquoi gif ? Pourquoi ne pas faire référence explicitement à la norme ISO du format PNG largement implémenté et bien plus performant ?
Plus loin je vois une référence à un JPG... mais où est la liste exhaustive de tous les formats d'images à implémenter ? Je peux utiliser n'importe quoi ? Non je suppose que là encore, la référence c'est OOo, c'est comme pour OpenFormula : z'avez qu'à regarder ce que fait le soft de référence.
Attention, là encore je ne dis pas que OOXML est mieux sur ce point, mais je cherche à attirer l'attention sur le fait que l'ISO normalise des trucs qui théoriquement ne devrait pas l'être, comme l'ODF, et des trucs gros comme ca que je trouve en 5 minutes. Pas des détails qui plus est. Donc faire chier l'OOXML pour son manque de documentation (et quand on voit les chipotages des critiques techniques, on se pose des questions), je trouve ca vraiment pitoyable, pour MS et SUN encore je comprend, y'a une raison commercial, pour le libre, c'est de l'anti-MS primaire.
[^] # Re: Mon avis ca fait longtemps
Posté par Zenitram (site web personnel) . Évalué à 9.
Plus pérenne???
Dis-moi comment.
Car OOXML, c'est une peinture XML autour de blocs binaires non documentés : on documente un peu l'enveloppe, et les gens disent "super, c'est plus pérenne"
Sauf qu'on s'en fou de l'enveloppe si le contenu est toujours à la sauce MS, et que MS.
OOXML est autant pérenne que le vieux .doc, jamais "plus" pérenne : seul MS peut le lire, et dépend donc de la pérennité de MS.
Autant garder les vieux .doc dans ce cas, autant normaliser les vieux .doc avec ton argumentation. Et autant normaliser MS Windows, pour la pérennité aussi. Ton argumentation ne tient pas une seule seconde, je ne comprend pas que tu puisses te sentir bien avec ce mensonge ne toi.
[^] # Re: Mon avis ca fait longtemps
Posté par TImaniac (site web personnel) . Évalué à 1.
Affirmation gratuite de quelqu'un qui n'a ni lu les specs, ni utilisé concrêtement le dis format.
Dans la vraie vie, je me suis amusé à tester certains export doc vers docx, dans la plupart des scénarios il n'y a pas le moindre bloc binaire dans le document XML généré.
Bon après c'est ma petite expérience sur des documents pas forcement représentatif (je me suis pas amusé avec des trucs style OLE), le fait est qu'il y a des situations où ton affirmation n'est pas vérifiée.
Après si tu prends un document ODF, tu peux très bien inclure dedans un bout de Java, tu peux aussi considérer cela comme un blob binaire (pas spécialement standardisé à l'ISO au passage, et qui a sa propose spécification qui évolue de manière entièrement désynchronisé avec ODF).
Sauf qu'on s'en fou de l'enveloppe si le contenu est toujours à la sauce MS, et que MS.
Et le format ODF qui est à la sauce Sun, c'est pas pareil ? Non bien sûr, Sun c'est le gentil, MS c'est le vilain. Argument de poids ca.
seul MS peut le lire, et dépend donc de la pérennité de MS.
Faut pas abuser, comme je l'ai dis c'est du XML, et faut pas être abruti pour comprendre la structure du document avec un éditeur de texte lambda, même sans la doc de référence. Donc même si certaines parties sont peut être mal documentées et difficilement implémentable, la plus grande partie d'un document "standard" est largement interprétable et exportable vers un autre outil que celui de MS. Bref, même si la pérénité de l'intégralité des documents n'est sans doute pas assurée sans le support de MS, c'est quand même mieux que le vieux .doc pas documenté, quoique t'en dise.
Ensuite la structure même XML du document permet de "récupérer" un document corrompu (erreur lors de l'écriture sur disque), avec n'importe quel éditeur de texte. Même d'un point de vue technique, les documents sont en soit plus pérenne qu'un .doc binaire.
autant normaliser les vieux .doc avec ton argumentation.
Ca aurait supposé un minimum de doc, ce qui aurait effectivement déjà été une grande avancée.
Et autant normaliser MS Windows, pour la pérennité aussi.
Si normaliser veut dire documenter obligatoirement, là encore ca ne peut être que bénéfique, même si ca veut rien dire "normaliser" un OS. Enfin bon comme toute comparaison, celle ci est plus que douteuse, on parle d'un format de données, et de la pérénité des informations représentées, pas d'un OS.
[^] # Re: Mon avis ca fait longtemps
Posté par Bozo_le_clown . Évalué à 6.
Moi aussi je pensais comme toi jusqu'à ce que je découvre la diférence entre "interopérabilité" et "compatibilité'.
http://fr.wikipedia.org/wiki/Interop%C3%A9rabilit%C3%A9
Les 10% d'applications qui ne pourront jamais lire l'OOXML font de ce format un format de compatibilité mais pas d'interopérabilité.
Il s'agit peut-être d'un standard mais pas d'une norme
http://fr.wikipedia.org/wiki/Standard
[^] # Re: Mon avis ca fait longtemps
Posté par Éric (site web personnel) . Évalué à 2.
Wikipedia est un très beau projet et c'est un très bon moyen de s'informer et de ce documenter. Par contre c'est le dernier endroit où il faut aller chercher des définitions. Surtout des définitions de mots pris d'assaut par la communauté informatique comme "norme", "standard", "brevet", "droit d'auteur", etc.
Prenons des sources un peu moins biaisées pour ce genre d'exercices, des dictionnaires.
"Standard" n'apparait ni dans le Littré ni dans l'Académie française. On le trouve tout de même dans le portail lexical de l'atilf/cnrs. On y lit
Difficile de dissocier ensuite "norme" de "standard" vu qu'on définit un standard comme quelque chose de conforme à la norme ou comme une norme de fabrication.
Cherchons plus loin. "Norme" apparaît lui dans le dico de l'Académie française. On y lit :
Et là c'est clair : Non une norme n'est pas forcément édictées par un organisme public, il n'en est nulle part mention. Mais ça va même plus loin, la norme n'est même pas forcément édictée ou documentée tout court. Un comportement directeur *observé* chez le plus grand nombre est qualifiable de norme.
Les informaticiens ont fait évoluer le terme pour leurs propres intérêts. La première étape c'est de dissocier ce qu'ils (nous) appellent "standard de fait" de la "norme documentée" -- alors que la définition de "norme" est justement celles qu'ils attribuent au "standard de fait" -- afin de nier le terme aux formats/logiciels en quasi monopole. Plus récemment on trouve l'idée qu'une norme est forcément publique, je n'ai cependant vu cette idée que pour disqualifier OOXML, jamais dans un autre débat.
Il va falloir se faire une raison. Je ne parle pas de se faire une raison vis à vis de OOXML. Je parle d'apporter de vrais arguments contre OOXML, il y en a bien assez sans tenter des pirouettes de vocabulaire pour détourner les termes à notre avantage.
[^] # Re: Mon avis ca fait longtemps
Posté par Bozo_le_clown . Évalué à 3.
La question serait alors : Un format se doit-il d'être seulement "compatible" ou "intéropérable" pour être validé par un organisme de normalisation ?
Sinon je ne cherche pas à "disqualifier" OOXML sur une pirouette de vocabulaire mais simplement à mieux comprendre ce à quoi correspond un standard/norme et partant de là si OOXML peut s'y conformer.
Et plus d'un m'en est témoin ici.
[^] # Re: Mon avis ca fait longtemps
Posté par Éric (site web personnel) . Évalué à 2.
Le fond vaut à mon avis fortement d'être signalé. La forme un peu agressive que je regrette juste après coup (comme à chaque fois) vient probablement du fait de wikipedia. Je m'énerve à chaque fois que je vois que ma communauté (le libre) en fait un outil de propagande et/ou y casse trop souvent l'objectivité et le NPOV. Enfin, j'ai réagit là bas aussi.
[^] # Re: Mon avis ca fait longtemps
Posté par Bozo_le_clown . Évalué à 2.
Moi aussi, j'ai eu un doute en lisant "En langue française"
Mais ma question reste valable.
Dans un autre thread, il y eu des [litote]échanges[/litote] sur le fait que certaine parties de OOXML faisaient référence à des formats propriétaires et disqualifiaient de ce fait OOXML en tant que norme.
Je pose la question à la cantonade:
Y a t'il des critères précis d'acceptation à l'ISO qui mentionnent quels sont les mécanisme d'extensions acceptables ou est-ce du domaine de l'arbitraire ?
Timaniac y fait aussi allusion avec ODF et Java.
[^] # Re: Mon avis ca fait longtemps
Posté par abramov_MS . Évalué à 1.
C'est assez rigolo de voir exactement les memes arguments (faux) et les memes techniques dans vos messages que ceux donne et utilise par pbpg :)
Ah vivement des voitures aux roues carres pour redefinir une nouvelle norme!!! Cela sera plus pratique pour descendre les escaliers. Imagine donc la scene dans un des film avec Bournes ou la mini descend les escaliers de montmartre tout en douceurs.
[^] # Re: Mon avis ca fait longtemps
Posté par TImaniac (site web personnel) . Évalué à 2.
Implémenter entièrement ODF suppose d'implémenter Java par exemple plutôt que de réutiliser les normes ISO qui existent (bah oué CLR/C# c'est ISO) : ca te choque pas ?
Gueuler après l'OOXML qui propose l'inclusion de blob binaire, notamment les composants OLE, quand l'ODF propose également d'inclure des composants OLE, ca te choque pas que la critique n'aille que dans un sens ?
ODF oublie de préciser les formats d'images qui doivent être supportés, on peut en déduire d'après les exemples de la norme ODF qu'il doit être possible d'inclure les formats JPG et GIF (alors que pour ce dernier y'a PNG qui est norme ISO) : où s'arrête-t-on dans le support des formats ? Un format d'image qui n'est pas utilisé par OOo mais par une autre suite est considéré comme un blob binaire ? Pourtant ca respecte bien la norme qui "oublie" de proposer une liste finie de formats à utiliser. Ca te choque pas ?
L'ODF propose d'inclure des scripts qui peuvent là encore être "par exemple" en Javascript... ca suppose encore implémenter ce langage si on veut supporter intégralement un document pondu par OOo ? Et si j'utilise un autre format de script, à priori l'ODF ne m'en empêche pas, comme pour les images non ? Ca te choque pas d'un point de vue interopérabilité ?
Ca te choque pas que tout ca soit passer comme une lettre à la poste à l'ISO ? Tu trouves que c'est des "détails" ? Tu trouves normal que l'ISO est accepté sans bronché qu'un format de feuille de calcul ne propose pas dans la V1 de documentation sur comment écrire... les formules? (corrigé avec OpenFormula dans la V1.1) ?
Dernier point : ca te choque pas que j'ai trouvé la plupart de ces "énormités" en lisant en diagonale les specs d'ODF ? Que vais-je trouver si je lis toute la norme ?
Si rien de tout ca ne te choque (ce qui ne m'étonnerait pas vu comment ton objectivité et ta haine viscérale de MS t'ouvre l'esprit), je vois même pas ce que trouves à redire sur l'OOXML, il est au moins aussi "magnifique" qu'ODF.
[^] # Re: Mon avis ca fait longtemps
Posté par abramov_MS . Évalué à 2.
C# 1.0 est passe en fast-track a l'ISO en effet. Pourquoi ne pas l'utiliser dans ODF? Peut etre que le fait que C# 2.0 et C# 3.0 ne sont pas ISO, casse la compatibilite avec la norme ISO.
Pourquoi Java plutot que C# 1.0? A mon avis pour 2 raisons, la premiere c'est que Microsoft a refuse de faire partie du comite definissant ODF, ca aide pas a pousser ses technos, la deuxieme c'est que C# 1.0 n'etait pas mure (vu les changement avec les versions suivantes c'est assez evident.
Enfin bon tu me montres les manques dans la doc de Java STP. Parceque bon les VML et autre joyeusete ca manque "legerement" de doc. De meme pour javascript, la doc est la ou pas?
Ca te choque pas que tout ca soit passer comme une lettre à la poste à l'ISO ? Tu trouves que c'est des "détails" ? Tu trouves normal que l'ISO est accepté sans bronché qu'un format de feuille de calcul ne propose pas dans la V1 de documentation sur comment écrire... les formules? (corrigé avec OpenFormula dans la V1.1) ?
Ah non non il est pas passe comme une lettre a la poste, il est carrement passe a l'unanimite et pas en fast-track.
Si Microsoft avait des commentaires a faire sur le format ODF ils avaient qu'a le faire avant de voter.
Un peu comme l'on fait les personnes qui ne voulaient pas du format en l'etat microsoft openxml. Si toutes les corrections demandes sont mises en place pour fevrier, je ne vois pas pourquoi le format ne passerait pas la norme ISO. Le seul probleme c'est que je vois assez mal Microsoft faire evoluer son format de facon a respecter cela car il faudrait mettre a jour tous les Microsoft Office 12 vendu.
Cela me ferait bien chier d'avoir 2 formats totalement redondant de format office mais si microsoft openxml est change suffisemment, c'est a dire que d'autre personnes que Microsoft puisse l'implementer je n'aurai pas grand chose a dire. En attendant la proposition de norme tel que presente n'etait pas en etat pour etre une norme ISO.
[^] # Re: Mon avis ca fait longtemps
Posté par TImaniac (site web personnel) . Évalué à -1.
Mouarf ! L'excuse bidon. Déjà on parle pas du langage, mais d'un bytecode d'applet, on parle donc de la CLR vs Java. Donc C# 2.0 ou C# 3.0, s'est pareil, c'est la CLR 2.0. Cette dernière est en cours de normalisation ISO. Et je vois pas ce qui empêche de supporter la CLR 1.0 dans la version actuelle d'ODF et de passer à la CLR 2.0 lors du prochain draft ODF.
De toute façon c'était juste un exemple pour montrer 2 choses :
- ODF utilise aussi des trucs non ISO, même quand y'a des trucs à l'ISO : d'après vos théories à 2 balles, ODF "réinvente la roue" et ne devrait pas être ISO.
- La présence de Java et autres JDBC qui non rien d'ISO ou même OASIS/ECMA/cquetuveux montre clairement l'influence omniprésente de Sun sur l'ODF, et relativise complètement vos arguments bidon concernant l'ouverture du processus de standardisation à l'OASIS et l'indépendance vis-à-vis d'une entreprise. Dans la vraie vie, ODF est aussi liée à Sun que l'est OOXML à MS.
Enfin bon tu me montres les manques dans la doc de Java STP.
Mais on sait même pas de quoi on parle ! C'est juste marqué "applet Java", ca inclu quoi ? Quelle version de la plateforme ? Quelles bibliothèques ? On sait même pas quelle doc lire !
De meme pour javascript, la doc est la ou pas?
Quelle version ? L'ECMAScript (là encore ils parlent de Javascript, ca en dit long sur l'indépendance envers Sun) a plein de version, la dernière étant peu implémentée, je prend laquelle ? ECMAScript 4 qui apparaîtra dans le futur Mozilla ? Un plus vieux ? Lequel ?
De plus c'est clairement mis "for example", je peux très bien y mettre du Python ou du Ruby, voir du Perl ou n'importe quoi, non seulement certains de ces langages sont notoirement mal spécifiés (Python) et il est impossible de supporter universellement tout et n'importe quoi !
Ah non non il est pas passe comme une lettre a la poste, il est carrement passe a l'unanimite et pas en fast-track.
Oui excuse moi, même à la poste ils ne sont pas aussi efficace. T'as saisie l'idée : certaines énormités n'auraient jamais dû passé. Ou alors si ca n'a dérangé personne à l'époque, faut pas venir faire chier l'OOXML avec des critiques du genre.
Si Microsoft avait des commentaires a faire sur le format ODF ils avaient qu'a le faire avant de voter.
MS ne remet pas en cause la normalisation à l'ISO d'ODF je te rappelle.
Si toutes les corrections demandes sont mises en place pour fevrier, je ne vois pas pourquoi le format ne passerait pas la norme ISO.Sauf que grosso-merdo, les détracteurs d'OOXML comme IBM & Co ne veulent pas de corrections, ils cherchent juste un maximum d'arguments pour que le format ne soit pas normalisé du tout, en tout cas le plus tard possible, pour que seul ODF est le logo ISO.
Le seul probleme c'est que je vois assez mal Microsoft faire evoluer son format de facon a respecter cela car il faudrait mettre a jour tous les Microsoft Office 12 vendu.
Je ne vois pas où est le caractère obligatoire. Après MS sort toujours des services packs, des plugins d'import/export, des patchs, et des versions majeurs. Y'a que l'embarras du choix pour diffuser ce support.
Cela me ferait bien chier d'avoir 2 formats totalement redondant
C'est pour ca que j'ai tenté d'expliqué que ces formats ne sont pas totalement redondant, même si une grande partie se recoupe, ils n'ont pas le même objectif, ce qui se voit facilement aux différents arguments des détracteurs de tout bord : les avantages de l'un sont des inconvénients pour l'autre.
attendant la proposition de norme tel que presente n'etait pas en etat pour etre une norme ISO.
Je suis bien d'accord, même mine de rien quand on y réfléchi, l'ODF était pas plus prêt. La V1.1 comble la plus grosse énormité, mais y'a encore du boulot.
Mais sérieusement ca te choque pas tout ce que j'ai trouvé sans être expert et que ca soit passé à l'ISO ???
[^] # Re: Mon avis ca fait longtemps
Posté par abramov_MS . Évalué à 2.
Donc toutes tes critiques sur ODF sont nulles et non avenus. Si le format a l'epoque de la normalisation etait si nul il n'y avait qu'une chose a faire: dire "Non avec commentaires". Microsoft ne l'a pas fait tout simplement parceque bien sur qu'il y a des manques, des erreurs et des trucs qui ne devraient pas etre dans ODF 1.0 mais ce format est totalement implementable dans n'importe quel suite office. Le format microsoft openxml tel que presente en fast track ne pouvait etre implementable que dans Microsoft Office, de plus je vais encore poser la meme question que je pose a pbpg:
Pourquoi avoir voulu absolument repeter les erreurs de ODF et du format binaire?
C'etait un combo perdant comme cela a ete montre. Maintenant microsoft a 6 mois pour montrer sa veritable volonte d'avoir un format de fichier office reellement interoperable et perenne avec les autres acteurs du marche, donc wait and see.
Pour en revenir au sujet du journal, de Icaza est soit un idiot (ce dont je doute malgre ses declarations a l'emporte piece sur les brevets) soit il prend ses interlocuteurs pour des cons lorsqu'il dit que le format est "superbe".
Aller juste pour la route:
Am (Miguel) personally proud that Jody and Michael made Microsoft add ~650 pages or so to the spec that documented the formulas
Ce qui veut dire que Microsoft a presente a l'ECMA un document qui n'avait pas les formules documentes. Ca te rappelle rien ca? Pourquoi ne pas avoir pris la decision d'utiliser le standard qui etait en train de se mettre en place pour corriger exactement le meme manque dans ODF, je parle d'openformula?
C'est rigolo comme on l'a entendu sur le sujet et se moquer de ODF alors que le probleme etait 1) connu 2) en train d'etre regler et qu'il n'a fait aucune publicite que au meme moment le draft de la norme microsoft openxml etait dans le meme cas.
[^] # Re: Mon avis ca fait longtemps
Posté par TImaniac (site web personnel) . Évalué à -1.
Mais c'est quoi cette conclusion de merde ? Je suis pas représentant MS que je sache ! Je donne mon avis.
Microsoft ne l'a pas fait tout simplement parceque bien sur qu'il y a des manques, des erreurs et des trucs qui ne devraient pas etre dans ODF 1.0 mais ce format est totalement implementable dans n'importe quel suite office.
J'ai montré par A + B qu'il n'était pas implémentable entièrement dans la vraie vie. La vraie vie me donne raison, puisque personne n'a encore réussi et ca maintenant un petit moment que le standard existe.
MS a voté Oui par pragmatisme : ce format n'est pas 100% interopérable, c'est un saint graal de toute façon inaccessible, proposons un autre format qui n'atteindra pas non plus l'objectif mais qui répondra à un autre : la compatibilité avec des millions de documents existants.
Pourquoi avoir voulu absolument repeter les erreurs de ODF et du format binaire?
Parcqu'il y a des contraintes techniques ? Les objets OLE, c'est du bon gros blob binaire, mais des gens s'en serve, et il faut que ces gens puissent sauvegarder leurs documents quand même dans un format moderne : tant pis si certains bouts seront potentiellement illisible plus tard. C'est pour ca que ODF et OOXML supporte OLE.
. Maintenant microsoft a 6 mois pour montrer sa veritable volonte d'avoir un format de fichier office reellement interoperable et perenne avec les autres acteurs du marche, donc wait and see.
ODF est pourtant passé depuis en 1.1 à l'ISO (l'année dernière, donc relativement recemment), et pourtant il n'a pas beaucoup été amélioré niveau interopérabilité : impossible d'être 100% compatible avec 90% des suites déployés sur le marché, balo pour un format d'interopérabilité non ? Sauf si on est pragmatique, et qu'on accepte ces entorses pour avoir quand mêmes des formats normalisés, et on accepte l'OOXML comme on accepte l'ODF.
Un peu de cohérence bon sang, les 2 ou aucun.
Ca te rappelle rien ca? Pourquoi ne pas avoir pris la decision d'utiliser le standard qui etait en train de se mettre en place pour corriger exactement le meme manque dans ODF, je parle d'openformula?
Pourquoi prendre OpenFormula, un truc neuf, pas encore normalisé à l'époque, et qui est rien d'autre qu'une copie à peine modifiée du format d'OOo ? MS a son propre format, déjà éprouvé. Pourquoi prendre le truc concurrent qui n'a pas plus de légitimité ?
Enfin je vois que t'as pas répondu sur la moitié de mes exemples.
[^] # Re: Mon avis ca fait longtemps
Posté par Bozo_le_clown . Évalué à 4.
Ou ça ?
Jusqu'ici tu as juste démontré que OOXML souffrait des mêmes lacunes qu'ODF vis à vis de l'interopérabilité pas qu'obtenir un format véritablement opérable était irréalisable.
Peu m'importe que MS fasse un format de stockage OOXMLBis non normalisé qui inclut des images en RAW ou que sais-je du moment qu'il fournit un export vers un standard qui attend du PNG.
Et si le besoin d'extension pour du OLE est nécessaire qu'ils prevoient un autre format d'echange qui ne prétende pas devenir une norme.
[^] # Re: Mon avis ca fait longtemps
Posté par TImaniac (site web personnel) . Évalué à 0.
Ben y'a pas de liste exhanstive des formats d'image à supporter : comment veux tu implémenter ce format sans savoir quoi supporter comme codec d'image ?
Y'a pas de liste exhaustive des langages de scripts possible, et encore moins de référence à une quelconque norme/version : que dois-je implémenter pour avoir un document qui exécute correctement les scripts ?
Pareil pour les applets Java : on sait pas quelle version de Java est référencée, laquelle implémenter, avec quelles libs (on suppose que JDBC en fait parti, sans savoir quelle version).
Peu m'importe que MS fasse un format de stockage OOXMLBis non normalisé qui inclut des images en RAW
Justement, selon la norme actuelle, tu peux très bien mettre une image RAW, la norme ODF est parfaitement respectée. Mais tu peux pas relire ton document si OOo (ou autre) ne supporte pas ce format d'image. C'est couillon non ?
Ca te suffit pas à prouver qu'il est impossible d'implémenter ODF correctement ?
C'est pas pour ca qu'il faut jeter ODF, juste qu'il faut accepter qu'une norme est pas parfaite, et chercher à l'améliorer. mais faut pas la rejeter, rien n'est parfait.
[^] # Re: Mon avis ca fait longtemps
Posté par abramov_MS . Évalué à 2.
Comme dit par Bozo. Tu as montre ca ou? Tu as pointe des points de la norme que tu consideres problematique (peut etre a raison la question n'est pa la) mais tu n'as absolument pas montre que la norme ne pouvait pas etre implemante.
MS a voté Oui par pragmatisme
Non ils ont vote Oui parceque ils auraient ete les seuls a ne pas voter pour et donc 1) cela aurait bien montre l'ouverture de Microsoft pour l'interoperabilite 2) ils attendaient un renvoie d'ascenseur et que personnes ne fasse une seul remarque technique sur le format qu'il etait en train de preparer a faire passer de force en fast-track. Je tiens a rappeler que ODF malgre tout ses defauts n'est pas passe en fast-track.
la compatibilité avec des millions de documents existants
Encore une fois comme cela a ete demontre pas de nombreuses personnes ici et de bien plus competente que moi (ce n'est pas difficile) c'est faux et archi faux. La seul veritable compatibilite avec les anciens documents ne peut venir que de la documentation du format de ces documents sans points obscure connu d'un seul editeur. De plus cette pseudo compatibilite n'a pas lieu d'etre, les anciens documents devront etre ouvert par un filtre et sauvegarder par un autre. La compatibilite doit donc se trouver dans les filtres et pas ailleurs. Il ne faut pas rever Microsoft Office 97 ne saura jamais ouvrir un document docx de facon native.
impossible d'être 100% compatible avec 90% des suites déployés sur le marché
Tu parles pbt de Microsoft office? Parceque microsoft openxml est lui interoperable avec d'autre suites office? Non meme pas il est tellement simple a implemente que Microsoft n'a pas reussi a le faire pour la version Mac de sa suite office 2007 et que cela sera peut etre pour la version 2008 mais probablement sous la forme d'un plugin. Donc niveau interoperabilite, microsoft openxml il est interoperable avec une version (la version 12) d'une suite office (microsoft office) sur une plateforme (Windows). Ca c'est de l'interoperabilte. En face tu as ODF implemente dans un certains nombre de suite office: Openoffice.org, Lotus Notes, Google office et et sur la grande majorite des OS. Niveau interoperabilite c'est "legerement" mieux tu ne trouves pas?
A moins que tu trouves que la definition d'interoperabilite d'un format c'est le fait que le logiciel sur lequel il a ete cree doit etre capable de le relire correctement? C'est rigolo ca me rappelle un vieux truc sous MS office 97, windows 98 et deux pc different ou le rendu du document doc etait pas le meme...
MS a son propre format, déjà éprouvé.
Non documente a l'epoque de la creation de openformula et de la soumission a l'ECMA, avec des erreurs dans les formules (toujours presente) et j'en passe.
Enfin je vois que t'as pas répondu sur la moitié de mes exemples.
Parceque je n'ai aucun avis sur ces points particulier, je ne sais pas si c'est vraiment genant (au passage VBA c'est normalise et documente? Parceque bon microsoft openxml a lui aussi exactement le meme probleme) et que je n'ai jamais dit que ODF etait parfait. Jamais! J'ai toujours dit que microsoft openxml fait totalement doublon comme standard et n'a pas lieu d'etre. Que les soupcons sur l fait qu'il etait non completement decrit etaient fondes, que le passage en fast-track pour un truc pareil est une aberration de premiere ordre et une facon de "forcer" la normalisation ISO, etc.
[^] # Re: Mon avis ca fait longtemps
Posté par Bozo_le_clown . Évalué à 2.
Ceci te dispense de répondre à chacun des arguments qui sont d'ailleurs moinssés comme à l'habitude lorsque la passion l'emporte sur la pertinence.
Toutes ses réponses sont fondées mais tu esquives .
[^] # Re: Mon avis ca fait longtemps
Posté par Bozo_le_clown . Évalué à 3.
Qui a placé un espoir démesuré dans cette croisade en pensant mettre à terre le monstre alors qu'il ne s'agit peut-être que d'un leurre (un moulin ?)
On est tous le Don Quichotte de quelqu'un d'autre, Hein !
Ce qui est sûr c'est que Timaniac argumente, que je n'ai jamais pris position pour OOXML (d'autant que j'utilise OO), que tu ne te contentes que de vulgaires attaques ad hominem, amalgames et autres métaphores foireuses lorsque tu es à court d'argument.
Que ODF et OOXML soient sur le même pied d'égalité, car ils acceptent tous 2 des extensions qui peuvent être non standards, non documentées voire fermées est indéniable.
La question est donc de savoir si c'est une faille dans le processus de normalisation ISO ou si c'est une vision pragmatique (mais criticable):
Ne pas obliger les vieux logiciels à être patché pour supporter des extensions standards, tout en ne fermant pas la porte a ceux qui visent l'interopérabilité complète.
Dans ce cas on n'oblige pas une société à faire la mise de son parc d'install d'Office 97 pour exporter avec du PNG au lieu d'un fomat d'image proprio pour que ses doc en Office 97 puissent être lu par la dernière version d'Office qui supporte déjà le format d'image proprio.
En même temps, ca empêche des suite concurrentes d'être pleinement compatibles avec ces docs et ca fausse la concurrence.
Pragmatisme aussi parce que comme essaye de te l'expliquer Timaniac l'interopérabilité totale s'avère être une utopie (ce avec quoi je suis en désaccord)
Pour moi c'est l'ISO qui détient la clé et qui doit clarifier ses positions vis à vis de ces critères. Ainsi on évite de se retrouver dans l'arbitraire :
Pour être standard peux t'on ou non accepter qu'une extension au moins ne soit pas standardisée.
Dans la négative selon ce critère ODF ne devrait pas plus être un standard que OOXML
Il y a peut être d'autres raisons qui font que OOXML n'est pas acceptable mais celle-ci n'en est pas une si l'on se réfère à ODF.
Plutôt que de te remettre en question en acceptant que cet argument est caduque et en trouver d'autres, tu prefères te réfugier dans le fait que "MS c'est pas pareil c'est des maichants" ou que nous sommes tous des suppôts de Satan ou que sais-je encore.
[^] # Re: Mon avis ca fait longtemps
Posté par Axone . Évalué à 3.
Ah bon ? Quelle est la différence de but ? Il me semblait justement que MS mettait la pression sur les administrations pour qu'elles ne passent pas au standard ODF car le format MS allait être normalisé.
Pourquoi pas implémentable ? Surtout que maintenant MS office sait produire du xml, y'a déjà une partie du boulot qui est fait. J'ai pas l'impression d'une quelconque difficulté technique.
[^] # Re: Mon avis ca fait longtemps
Posté par TImaniac (site web personnel) . Évalué à -2.
Y'a des buts communs :
- proposer le logo commercial "ISO"
- proposer un format avec une certaine pérénité dans le temps (suppose des choix techniques type XML et une documentation relativement complète).
Des buts différents :
- ODF veut proposer un standard qui repose sur OOo. En cela historiquement le format proposé est plus "clean" et s'affranchi plus du passé.
- OOXML veut proposer un standard qui repose sur MS Office. Moins clean, il offre cependant l'avantage d'être compatible avec l'énorme historique de documents existant.
Bref OOXML est un bon format de transition pour une administration qui vient du monde MS Office.
ODF est un bon format pour qui veut passer à autre chose.
Pourquoi pas implémentable ? Surtout que maintenant MS office sait produire du xml, y'a déjà une partie du boulot qui est fait. J'ai pas l'impression d'une quelconque difficulté technique.
Lis mes différents exemples sur les grosses lacunes de la norme ODF et les liaisons (trop) fortes avec les technos de Sun.
Lis également les difficultés rencontrées par ceux qui tentent d'implémenter ODF (KOffice, Gnome Office). C'est parfois surmontable, mais au prix d'hypothèse techniques qui consiste à "singer" OOo pour être compatible. Je vois mal MS "singer" OOo juste pour être compatible avec lui.
# mouais
Posté par Éric (site web personnel) . Évalué à 3.
Sa réponse ne correspond pas à l'éventuelle question sur les brevets, il a une vision très partielle et on ne peut certes pas se contenter de savoir que la version Novell est couverte ..... mais *NON*, il n'admet rien (et d'ailleurs ce n'est pas à lui de le faire, il n'est pas plus légiste ou responsable MS que toi ou moi).
Moi je vois tout au plus sa réponse comme un "c'est possible mais ceux qui veulent être couverts dans l'utilisation de cette techno le peuvent via notre distribution". En gros un "après moi le déluge". Par contre en rien il ne confirme ni n'infirme le potentiel déluge. Je vois mal au nom de quoi il pourrait le faire d'ailleurs.
[^] # Re: mouais
Posté par Colin Leroy (site web personnel) . Évalué à 5.
Juriste ;-)
[^] # Re: mouais
Posté par Bozo_le_clown . Évalué à 3.
# Bah ...
Posté par Sébastien B. . Évalué à 1.
C'est en étant pas tous du même avis qu'on évolue, je pense ... (bien qu'il soit connu pour être un trolleur)
[^] # Re: Bah ...
Posté par freeze . Évalué à 7.
Il bosse pour novell, et dit "si vous avez peur de MS, achetez Novell, et MS fait du super boulot"
...
Moi je ne trouve pas sa position particulièrement neutre.
# Les brevets logiciels valable en UE ?
Posté par benoar . Évalué à 5.
En gros, pour lui, les brevets logiciels sont tout à fait valables en Europe : d'un côté, il n'a pas tord, car ils sont actuellement acceptés par l'EOB, même s'ils ne sont pas applicables. Et c'est là qu'il m'étonne : il dit qu'ils le seraient tout à fait.
Je n'ai encore jamais vu une poursuite judiciaire en Europe qui concerne un brevet logiciel, mais je serais surpris si cela était arrivé. Il a l'air de considérer ça "normal" d'avoir des brevets partout dans le monde (voir la suite de ses mails) même s'il se dit "contre" les brevets logiciels (voir aussi ses autres réponses).
Mais en tous cas, dans ses réponses, il est toujours très vague quant à ces questions de brevets ("pas de problème pour utiliser nos logiciels, tant que vous les téléchargez depuis Novell, qui a la protection" -> qu'est-ce que ça veut dire "télécharger" depuis Novell ?! et pourquoi avoir besoin d'une protection si ce n'est "certainement" pas couvert par des brevets ? Et aucune réponse claire si c'est vraiment "free as in freedom"), ce qui me fait dire que ce mec n'est pas très net avec toutes ces histoires et son affiliation à Microsoft. Bref, il FUD bien.
Sinon, je trouve qu'il a en général un ton très hautain dans ses mails; je ne sais pas si c'est très agréable d'avoir une discussion argumentée avec lui...
[^] # Re: Les brevets logiciels valable en UE ?
Posté par Éric (site web personnel) . Évalué à 2.
Il dit ce qui est répété et rerépété mais qu'on ne veut pas entendre ici. Rien n'interdit qu'un brevet fasse intervenir du logiciel. Rien n'interdit même qu'un brevet ne puisse (actuellement) être couvert que par du logiciel.
Ce qui est interdit c'est faire breveter du logiciel "en lui même", que ce soit en tant que logiciel qu'on le fasse breveter.
On brevette une procédure pour un effet technique innovant. C'est la procédure qui est brevetable, qu'elle fasse intervenir du logiciel importe peu.
Sa vision du "pour un brevet logiciel en Europe il suffit de reformuler" peut certainement être juste pour certains trucs, ou en tout cas certainement être effectivement ce que font certaines boites.
[^] # Re: Les brevets logiciels valable en UE ?
Posté par briaeros007 . Évalué à 2.
Ça veut dire quoi 'être couvert' ?
Parce qu'actuellement le brevet pour un logiciel, pour qu'il soit accepté, il doit faire partie d'un appareillage plus complexe (donc pas que logiciel) agissant sur 'les forces de la nature'.
Bref pas qu'un logiciel tout court.
Donc sortir que mono est bel et bien breveter en europe (parce que c'était ça le sujet) mais qu'on ne veut pas l'entendre me semble légèrement déformer la réalité.
[^] # Re: Les brevets logiciels valable en UE ?
Posté par Éric (site web personnel) . Évalué à 2.
> logiciel) agissant sur 'les forces de la nature'.
Je peux me tromper mais l'histoire des forces de la nature c'était une proposition quand le sujet était passé à l'assemblée, ce n'est pas dans les règles actuelles.
> Donc sortir que mono est bel et bien breveter en europe
Ce n'est pas ce que j'ai dit (ni ce qu'il a dit). Je ne suis même pas convaincu d'avoir lu quelque part des faits montrant qu'il est même breveté aux US.
[^] # Re: Les brevets logiciels valable en UE ?
Posté par briaeros007 . Évalué à 2.
Au temps pour moi alors, c'est ce que j'avais compris.
pour le cas des 'forces de la nature' :
en ce qui concerne les brevets voila ce que wikipedia dis :
Donc effectivement il n'indique pas les forces de la nature, toutefois il interdit explicitement le cas du programme d'ordinateur, ainsi que les principes et méthodes générales, et les théorie mathématique.
(par contre le (3) j'avoue ne pas vraiment bien le saisir).
[^] # Re: Les brevets logiciels valable en UE ?
Posté par Éric (site web personnel) . Évalué à 3.
Ce veut dire que ton brevet peut tout à fait avoir des théories mathématiques et des logiciels mais qu'on ne peut pas breveté le logiciel en lui même ne fait pas un sujet de brevet (son effet ou son utilisation peut lui faire un sujet de brevet).
Il y avait un très bon article sur la question dans un vieux linuxmag : http://jjdj.free.fr/article/
J'en conseille la lecture, et en particulier la section "Des autres critères de validité, et des logiciels" qui parle de cette question.
[^] # Re: Les brevets logiciels valable en UE ?
Posté par benoar . Évalué à 2.
Mais ce que je me demande, c'est pourquoi pour l'instant aucune poursuite n'a été intentée en Europe : toutes les grandes actions médiatisées l'ont été aux US, et en plus j'ai rarement vu une entreprise européenne impliquée dedans (alors que MDI dit que ce sont elles qui détiennent une grande par des brevets)(ha si, je viens de penser à Thomson et les brevets sur le mp3).
Et tout le combat contre la création d'un "brevet logiciel européen" qui s'est joué il y a quelques années (déjà !), pour éviter de se retrouver comme aux US : cela est quand même un signe que la brevetabilité logicielle en Europe n'est pas si certaine que ça...
Franchement, j'aimerais bien savoir si en Europe, on peut poursuivre quelqu'un pour une violation de brevet logiciel .... ? Et si "oui", pourquoi on ne voit pas de procès autour de ces problèmes ?
# Mon cher Albert,
Posté par Jb Evain (site web personnel) . Évalué à 6.
Tout d'abord mettons les choses dans leur contexte. Je suis ingénieur dans l'équipe de Mono, et participe à ce titre au développement de Moonlight. Ce qui fait, que, si j'avoue ne pas pouvoir être impartial, j'ai au moins une vision de la technologie que tu te plais à critiquer ouvertement, que toi, tu n'as de toute évidence pas.
Je vais passer directement l'attaque sur Miguel (mon responsable direct), que tu connais bien évidemment bien plus que moi, ce qui te permet de dire le fond de sa pensée, et encore mieux, ses passions et ses lubies. Tu es quelqu'un de formidable mon cher Albert.
Parlons un peu d'OpenOffice. OpenOffice permet de lire et même écrire des fichiers qui sont crées ou lisibles par Microsoft Office dans des versions antérieures à leur version OpenXML. Quoi qu'il arrive, pour rester compétitif, OpenOffice va DEVOIR être capable de lire et écrire l'OpenXML. C'est dans ce sens qu'OpenXML est quand même appréciable, parce que les développeurs d'OpenOffice, ou de l'extension d'OpenOffice vont pourvoir utiliser au moins une spécification, qui par ses 6000 pages à l'avantage d'être complète. Spécification qui même si elle présente des failles, sera de toute façon plus facile à implémenter que si il fallait re faire du reverse engineering sur les fichiers, pour savoir à quoi correspond quoi.
D'autant plus qu'OpenXML est un standard ECMA, et donc protégé des brevets par une clause RAND. Ce qui fait qu'OpenOffice serait plus protégé en regard de l'implémentation d'OpenXML que de l'implémentation de l'ancien format binaire.
Incroyable non.
Continuons avec tes idioties, le coeur de Mono et le language C# sont aussi protégés des brevets par la clause RAND des standards ECMA 334 et 335. La seule surface d'attaque, est celle de l'implémentation des libraires non standardisées, et qui sont téléchargeables séparément. Si les packagers de ta distribution favorite le veulent, ils peuvent tout à faire la séparation. D'autant que je ne vois pas des masses d'applications purement Mono qui utilisent ces couches sous Linux. Donc tu peux très bien ne pas les télécharger, et hop, tu ne crains rien.
Incroyable non.
Maintenant, parlons d'un projet qui bien qu'hébergé sur sourceforge et accessible sous forme de packet, est téléchargé spécifiquement à l'installation. Je parle de http://corefonts.sourceforge.net/ . Et bien ici ça va être exactement le même fonctionnement, et tous les système de packages que je connais sont capable de faire ça. Encore une fois, si les packageurs font bien leur boulot, tu devrais pouvoir télécharger Moonlight comme n'importe quel packet, mais celui si sera téléchargé pour de vrai sur le site de Novell, et te voilà directement couvert.
Et tu sais que tu es couvert, alors que si tu utilises une version OpenSource de flash, rien ne te dit que tu ne crains rien.
Bref, à part monter des films, fuder, attaquer Miguel, et raconter des anneries, tu ne sers pas à grand chose.
Pour informations, Mono n'est pas le seul projet à être inquiété par le système idiots des brevets. Prenons en trois autres qui sont potentiellement beaucoup plus inquiétés: Le noyau Linux lui même, Samba, les drivers ntfs. Et soyons réaliste rajoutons OpenOffice. Si Microsoft devait attaquer, ce n'est sûrement pas à Mono qu'ils s'en prendraient directement en premier. Bref, moi je retourne bosser, toi, tu peux rester à soulever ton indignation et ton ignorance.
Bisous
[^] # Re: Mon cher Albert,
Posté par ndesmoul . Évalué à 7.
Si OpenXML passe par une processus de révision sérieux à l'ISO pour gommer les plus gros problèmes repérés, ça serait très bien. J'aime bien la proposition de l'AFNOR d'ailleurs sur ce point.
Par contre si Microsoft voulait vraiment faire preuve d'ouverture ils publieraient les spec de leurs formats binaires. Pas besoin d'en faire une norme, juste les publier. Évidemment je conçoit qu'il y a pleins de raisons pour lesquelles ils n'ont pas intérêt de le faire...
[^] # Re: Mon cher Albert,
Posté par briaeros007 . Évalué à 0.
Il est ou l'argument la ?
Je vois nada que dalle.
Tu dis juste 'tu sais rien petit padawan'. Ca c'est un argument, qui pour un ingénieur, fait froid dans le dos.
Quand tu défend un choix technique tu dis 'écoute tout ce que tu dis ce n'est que des préjugés. Moi je te dis que c'est comme ca et c'est tout , compris ?'
Quoi qu'il arrive, pour rester compétitif, OpenOffice va DEVOIR être capable de lire et écrire l'OpenXML.
Ah et pourquoi ?
Si OOxml fait un flop, OOo ne devra pas etre capable de lire et d'écrire sur ce format.
Il le devra SEULEMENT si ms FORCE son format (abus de position dominante).
Je rappelle que le format ACTUEL d'office n'EST PAS OOXML. Il y en a une partie, mais il n'est pas complètement conforme à la norme.
Alors OOo devra suivre quoi, la norme ? le format implémenté ? Il suivra comment les balises de compatibilité ?
C'est dans ce sens qu'OpenXML est quand même appréciable, parce que les développeurs d'OpenOffice, ou de l'extension d'OpenOffice vont pourvoir utiliser au moins une spécification, qui par ses 6000 pages à l'avantage d'être complète
C'est pas franchement l'avis des personnes qui ont étudié la norme, mais c'est pas grave hein.
Spécification qui même si elle présente des failles, sera de toute façon plus facile à implémenter que si il fallait re faire du reverse engineering sur les fichiers, pour savoir à quoi correspond quoi.
Ben tu peux me dire alors comment implémenter les fameuses balises 'doasword97' ou semblables ?
D'autant plus qu'OpenXML est un standard ECMA, et donc protégé des brevets par une clause RAND. Ce qui fait qu'OpenOffice serait plus protégé en regard de l'implémentation d'OpenXML que de l'implémentation de l'ancien format binaire.
Euh tu sais pas de quoi tu parle alors.
Un clause RAND tient pour Reasonnable and Non discriminant (enfin en franglais). Ca ne devient pas automagiquement 'libre d'utiliser les brevets à notre guise'.
C'est quoi les fameuses conditions 'raisonnables' ?
Ne demandent'elles pas par définition la fermeture du code : si je forke OOo devrais je a nouveau ré établir une licence d'utilisation des brevets ?
mais celui si sera téléchargé pour de vrai sur le site de Novell, et te voilà directement couvert.
Et quid de la clause de liberté de redistribution ?
Peut etre que ca n'intéresse pas les dvp de mono , mais moi ca m'intéresse, désolé.
Et tu sais que tu es couvert, alors que si tu utilises une version OpenSource de flash, rien ne te dit que tu ne crains rien.
Affirmation sans fondement ni argument, n'ayant pour autre choix que d'instiller la peur. Ce qu'on nomme traditionellement 'FUD'.
Comme tu le dis si bien
Bref, à part monter des films, fuder, attaquer Albert, et raconter des anneries, tu ne sers pas à grand chose.
(ben voui ca marche tout seul quand on montre rien).
Pour informations, Mono n'est pas le seul projet à être inquiété par le système idiots des brevets. Prenons en trois autres qui sont potentiellement beaucoup plus inquiétés: Le noyau Linux lui même, Samba, les drivers ntfs. Et soyons réaliste rajoutons OpenOffice. Si Microsoft devait attaquer, ce n'est sûrement pas à Mono qu'ils s'en prendraient directement en premier. Bref, moi je retourne bosser, toi, tu peux rester à soulever ton indignation et ton ignorance.
1°) As tu une preuve qu'il y a des brevets sur linux ou OOo? Si oui tu serais aimable de donner des liens vers les brevets. Je te jure qu'on va recoder pour ne plus avoir ce genre de probleme.
2°) pour samba ou ntfs je ne peux dire, mais je subodore qu'ils sont bien moins important que ce que tu veux bien le laisser entendre.
3°) Donc tu fait du FUD à la ms (on a 235 brevets mais on ne dis pas lesquels ...)
4°) et pourquoi mono ne serait pas attaquer en premier?
Tu peux tres bien attaquer un soft ou tu as 97% de chance de gagner, pour ensuite t'attaquer aux autres en faisant prévaloir justement ton succés passé.
[^] # Re: Mon cher Albert,
Posté par Nicolas Schoonbroodt . Évalué à 2.
Ben tu reprend le code qui le fait pour l'instant dans OOo, vu que ce logiciel est capable de lire et d'écrire le format de word 97.
[^] # Re: Mon cher Albert,
Posté par Bozo_le_clown . Évalué à 5.
[^] # Re: Mon cher Albert,
Posté par Jb Evain (site web personnel) . Évalué à 4.
Désolé, je ne suis pas meilleur que la majorité des êtres humains, et à attaque personnelle, je réponds parfois par la même chose. C'est triste. Alors non, quand je dis que Albert attaque Miguel, alors qu'il ne le connais pas, je ne donne pas d'arguments. Désolé pour ton dos.
Ensuite je parle de l'OpenXML. Forcément, sur Linuxfr, dire que l'OpenXML peut apporter des choses positives, c'est s'accroupir et attendre la foudre. Désolé d'avoir une vision plus nuancée que certains, où ODF et OpenXML cohabitent. Malgré les entreprises qui poussent l'un et l'autre. Pour le bien de l'utilisateur final. C'est vrai que si j'étais pas un peu utopiste, j'aurais pas passé les deux dernières années de ma vie à bosser pour des sociétés essayant de gagner le vie avec du logiciel libre. C'est vrai, c'est du business, du coca-cola (ami du fosdem, bonjour).
Je suis content que l'OpenXML ne soit pas passé tel quel, et que Microsoft va fournir des efforts. Pour ceux qui vont l'implémenter, comme AbiWord et OpenOffice. Et j'espère que grace à ça, quand on m'enverra des fichiers docx, je pourrais les lire dans mon OpenOffice.
Mais bon encore une fois, je ne donne pas d'arguments. Je me contente de donner le fond de ma pensée.
Effectivement la clause RAND ne protège pas de manière directe des brevets, le 335 et 334 sont sous RAND + Royalty Free, ce qui est différent d'un Patent Grant. Mais, et encore une fois si j'ai bien compris, selon les termes RAND de l'Ecma, Microsoft pourrait en être exclu en cas d'utilisation offensive de brevets. Et donc se fermerait la porte de l'ISO qu'ils utilisent.
Ensuite bravo, tu découvres avec stupéfaction que le système des brevets est pourri, et que donc, on ne peut faire que des suppositions. Formidable. Non je ne peux pas dire les brevets que Linux enfreint, ni même si seulement il en enfreint. Formidable. On en est tous là. Mon seul point est de dire que Mono, dans ce bordel, n'est pas plus vulnérable qu'autre chose. Que ça ne sert à rien de cracher dessus, ni sur Miguel. Et c'est monnaie courante par ici.
Bon allez, au plaisir de te revoir proposer des patchs pour Mono.
[^] # Re: Mon cher Albert,
Posté par briaeros007 . Évalué à 2.
Donc tu estime que c'est mal(tm) que albert fasse des attaques perso sur Miguel parce qu'il le connait pas, mais toi tu peu en faire sur Albert, quand bien meme tu ne le connais pas.
Et il n'y a rien qui te choque la dedans ?
Ensuite je parle de l'OpenXML. Forcément, sur Linuxfr, dire que l'OpenXML peut apporter des choses positives, c'est s'accroupir et attendre la foudre.
Ah bon? pourquoi ca ?
Personellement j'attend beaucoup d'information du format de photo HD de microsoft, comme quoi c'est pas parce que c'est MS que c'est mal, en tout cas pas pour moi.
Allez tiens d'ailleur, j'ai meme une xbox première du nom , alors...
Par contre il y a eu un certain nombre d'argument pour ou contre.
Il s'agit DONC d'un sujet polémique.
Et dire que "c'est bien(tm)" sans argumentation derrière, non désolé la oui c'est normal d'attendre la foudre ... si tant est qu'elle arrive.
ésolé d'avoir une vision plus nuancée que certains, où ODF et OpenXML cohabitent. Malgré les entreprises qui poussent l'un et l'autre. Pour le bien de l'utilisateur final. C'est vrai que si j'étais pas un peu utopiste, j'aurais pas passé les deux dernières années de ma vie à bosser pour des sociétés essayant de gagner le vie avec du logiciel libre. C'est vrai, c'est du business, du coca-cola (ami du fosdem, bonjour).
Ta position philosophique ne donne pas des arguments quant à tes affirmations sur OOXML. Ne t'en déplaise.
Mais bon encore une fois, je ne donne pas d'arguments. Je me contente de donner le fond de ma pensée.
Et c'est la ou le bas blesse amha.
Qu'OOXML fasse part de tous les commentaires qu'il a recu.
Qu'office suive les specs OOXML (ce qui n'est pas le cas) , et oui OOXML sera sans doute bien reçu.
C'est peut etre un peu facile de dire 'ouais ils refusent OOXML c'est simplement qu'ils sont contre MS'. Ca peut être AUSSI parce que d'un point de vue TECHNIQUE ben il nous convient pas, tu en pense quoi?
Ensuite bravo, tu découvres avec stupéfaction que le système des brevets est pourri,
On va oublier ces petites piques, en t'accordant le bénéfice du doute.
Non je ne peux pas dire les brevets que Linux enfreint, ni même si seulement il en enfreint.
Donc sous entendre très fortement que linux en enfreint (je rapelle ce que tu as dit
Pour informations, Mono n'est pas le seul projet à être inquiété par le système idiots des brevets. Prenons en trois autres qui sont potentiellement beaucoup plus inquiétés: Le noyau Linux lui même,
) ce n'est pas du tout faire du FUD et jouer au jeu de microsoft, pas du tout.
Que ça ne sert à rien de cracher dessus,
Oh je peux cracher sur mono si je veux allez exemple con :
race condition
memory leak si on utilise pas gc
a été fait en tant que concurrent à java plutot que d'essayer d'y contribuer
les nouvelles versions ne sont normalisé
ni sur Miguel.
Je ne me souviens pas avoir dit grand chose sur Miguel, meme si tu peux reconnaitre que certaines de ces prises de positions ne sont pas exactement comme celle de RMS.
[^] # Re: Mon cher Albert,
Posté par Jb Evain (site web personnel) . Évalué à 3.
Comme ça ne me choque pas de défendre un peu OpenXML, quitte à passer pour l'avocat du diable. Je suis parfaitement conscient que dans sa forme actuelle ce format peut laisser à désirer. Mais je trouve ça mieux que rien. Par principe je suis donc bien sur contre ceux qui vont clamer que OpenXML est nul parce qu'il vient de Microsoft. Et je suis content que tu affirmes ne pas en faire parti.
Quant à mes affirmations sur OpenXML, je les résume ici:
* Standardiser OpenXML va aider les développeurs du libre à implémenter ce format. Voilà, comme pour les versions précédentes d'office on n'aura peut être pas une compatibilité totale, et sûrement pas dès le début. Et c'est la même chose côté Microsoft. Si pour l'instant ils n'implémentent pas complétement OpenXML, ils vont converger vers son implémentation complète. Comme OpenOffice converge vers une implémentation complète d'ODF il me semble.
* OpenXML, étant un standard ECMA, n'est pas complètement couvert en cas de problème de brevets. Mais la faible protection qu'apporte l'ECMA ici, est pour moi mieux que rien. Il y a ceux qui disent que comme ils sont pourris, il ne faut pas légitimer les brevets logiciels. Moi je pense que malheureusement, il va encore falloir faire avec. Et donc, entre un minimum de couverture, et aucune en cas de reverse engineering, je préfère le minimum de couverture.
C'est mes deux seules prises de position sur OpenXML ici non?
Concernant le FUD, les brevets, et le fait que je fais le jeu de Microsoft. Encore une fois, malheureusement, je pense qu'on doit faire encore avec ces (foutus) brevets logiciels. Que la situation est merdique. Mais quand la tête de Microsoft hurle que Linux viole des brevets (premier lien google).
http://www.technologyreview.com/Wire/18737/
Ici Microsoft donne carrément des noms de logiciels. Ça m'effraie autant que tout le monde ici. Mais voilà, par rapport à Mono, la situation est globalement merdique. Et Mono n'est donc pas le seul en danger. Alors peut être que mettre un lien vers cette information c'est pour toi faire le jeu de Microsoft. Mais voilà, ils l'ont dit, ils l'ont dit. Et je ne peux pas faire autrement que de le prendre en compte. Et surtout, les sociétés ne peuvent pas faire autrement non plus.
Concernant tes exemples cons (comme tu les surnommes affectueusement), il y a peu de logiciels de cet envergure qui peuvent se targuer d'être sans memory leak, sans deadlock, et autres joyeusetés. Mais tu es bien sur le bienvenu pour reporter ces bugs, et même les corriger.
Et finalement, pour Miguel, si je ne suis pas d'accord avec tout ce qu'il dit, je me trouve assez en accord avec sa vision, d'essayer de faire du business avec du logiciel libre, et de la nécessité d'intérop avec l'existant. Et quand je parle du fait que cracher sur Mono et Miguel est monnaie courante, je ne parle bien sur pas de toi, mais d'une certaine ambiance, où ici, il fait bon de le faire. J'adhère pas. Normal tu me diras :)
[^] # Re: Mon cher Albert,
Posté par benoar . Évalué à 8.
[mode parano-conspirationniste]
Je pense que c'est une des tactiques de MS pour faire accepter le système de brevets en général, car avec tout le monde qui pousse vers l'interopérabilité, ils perdent leur position monopolistique et leur pouvoir. Bref, ils ont trouvé le brevet comme autre arme de "monopolisation massive".
Une fois que tout le monde aura cette idée dans la tête (que le brevet logiciel est indispensable), ils les utiliseront comme ils veulent contre qui ils veulent. Je rappelle que toutes leurs "protections" sont uniquement des promesses : aucune garantie que ça ne s'arrête pas un jour. Avoir une épée de Damoclès au dessus de la tête, ce n'est pas ce que j'appelle être libre.
[/mode]
Bref, je suis contre tous ces systèmes de brevets, et pour le combattre, le mieux est encore de ne pas s'en préoccuper : utilisez des logiciels brevetés, ou recodez les bouts de logiciels si vous préferrez. Mais n'allez pas demander la "protection" de MS (ou Novell, mais c'est pareil) pour un système qui ne leur est pas encore acquis (surtout en Europe).
[^] # Re: Mon cher Albert,
Posté par briaeros007 . Évalué à 2.
[^] # Re: Mon cher Albert,
Posté par Jb Evain (site web personnel) . Évalué à 2.
Prenons par exemple le cas de Ogg/Vorbis/Theora. Apple refuse d'implémenter le support parce qu'ils ont très peur de ce qu'ils appellent des `submarine patents` (Je n'ai pas le lien sur moi, c'est texto ce que dit un ingénieur apple dans une mailing list à propos du support de la balise dans WebKit). En gros, les gens attendent qu'un gros poisson utilise une technologie brevetée, et leur tombe sur la gueule.
Encore une techno que j'apprécie, mais qui a du mal à sortir de sa niche à cause des brevets. Dur de ne pas s'en préoccuper dans ces cas là.
Et puis si le mot d'ordre est de ne pas s'en préoccuper, et d'utiliser des logiciels brevetés, dans ce cas là utiliser Mono n'est un problème pour personne, que Mono enfreigne ou pas des brevets non ? :)
[^] # Re: Mon cher Albert,
Posté par benoar . Évalué à 2.
En ce qui concerne Apple, je pense qu'ils ont assez de brevets eux-même pour faire pression sur les gens qui les attaqueraient, mais c'est un cas particulier qui ne peut pas s'appliquer à n'importe quelle entreprise (genre la petite PME qui n'a aucun brevet et qui voudrait faire pareil). Mais les "brevets sous-marins", étant donné qu'ils payent déjà surement pour utiliser H264 & co, je ne pense pas que ça les gène beaucoup plus (quoique, il faut peut-être payer le double si les brevets s'appliquent à deux codecs différents qu'une entreprise utilise ?). En tous cas, dans tout ce qui est brevets sur les codecs vidéo & audio, je ne vois pas en quoi ogg/vorbis/theora est plus dangereux qu'un autre : au pire il viole autant de brevets que les autres technos genre MPEG-4 (même si on en n'est pas sûr).
Pour ta conclusion, je m'attendais à cette remarque à laquelle j'ai pensé : effectivement, autant faire comme le reste des technos libre qui risquent d'être brevetées, et utiliser Mono, si on est dans ma logique. Mais le fait que MS fasse à ce point du FUD sur cette techno me fait un peu peur, et à mon avis ils ont une idée derrière la tête. Ça fait un peu irrationnel comme réaction, et ça fait surement anti-microsoftien primaire, mais je n'ai pas envie d'utiliser de techno qui joue si dangereusement avec le feu. Pourtant, je trouve .Net et C# techniquement très bons, même s'ils ne sont qu'une évolution de Java.
[^] # Re: Mon cher Albert,
Posté par Jb Evain (site web personnel) . Évalué à 2.
Ça c'est assez exceptionnel. Si d'ordinaire Microsoft est friand de FUD envers le libre, Microsoft a été incroyablement discret sur Mono. Et on doit surtout l'agitation à la communauté du libre. «Oh mon dieu encore une implémentation d'un truc Microsoft par Miguel de Icaza. On va tous y laisser notre peau».
Mais après ça, si on rentre dans l'irrationnel, bien par définition, c'est irrationnel quoi :)
[^] # Re: Mon cher Albert,
Posté par briaeros007 . Évalué à 2.
Le problème n'est pas le but (louable) mais le moyen (a mon sens).
Et c'est la même chose côté Microsoft. Si pour l'instant ils n'implémentent pas complétement OpenXML, ils vont converger vers son implémentation complète.
Le problème c'est qu'ils divergent déjà.
Alors vont il finir par converger et est ce juste un accident de parcours ?
J'aimerais le croire, mais le embrace extend and extinguish cher a notre ms (inter)national me semble ancré pronfondément dans les esprits quand même.
Ensuite, comme tout le monde, je ne détient pas la véritée.
Et donc, entre un minimum de couverture, et aucune en cas de reverse engineering, je préfère le minimum de couverture.
Il y a deux problèmes
- 'que couvre la couverture' ?
- 'accepter que le système rentre par la petite porte ne vas t'il pas pousser qu'il envahisse la place' ?
Ce sont ensuite le plus souvent des opinions personnels, mais je crois qu'il ne faut pas perdre de vue ces deux points.
Alors peut être que mettre un lien vers cette information c'est pour toi faire le jeu de Microsoft. Mais voilà, ils l'ont dit, ils l'ont dit.
Non pour moi faire le jeu de microsoft c'est de le dire SANS spécifier que c'est ms qui dis qu'il y a plein de brevets sur tutux. Bref donner l'impression que c'est vrai.
il y a peu de logiciels de cet envergure qui peuvent se targuer d'être sans memory leak,
Euh 8 Go en 4 min, c'est pas un petit memory leak hein XD (j'ai précisé en virant GC).
Mono a certainement évolué depuis mes derniers tests (de l'année dernière).
C'était juste pour montrer que l'on peut toujours trouver quelquechose si on veut raler ;)
[^] # Re: Mon cher Albert,
Posté par Jb Evain (site web personnel) . Évalué à 2.
Sinon ça n'a aucun sens, ça va complètement à l'encontre du fonctionnement même d'une VM comme Mono/.net/Java.
[^] # Re: Mon cher Albert,
Posté par briaeros007 . Évalué à 2.
Ou que GC est tellement merdique* que quand on commence a chatouiller un peu trop les threads il part en sucette :P
Sinon ça n'a aucun sens, ça va complètement à l'encontre du fonctionnement même d'une VM comme Mono/.net/Java.
Ben vous êtes pas obligé d'utiliser gc pour faire du garbage collecting non plus ;)
/me aime bien demander la lune.
*J'avais fait un test reltivement simple
J'utilisais gc, je lancais 1000 threads, et ils faisaient juste un 'malloc'.
(pas de free)
Je lance le truc en désactivant gc : ca passe sans probleme.
en l'activant, ou bout d'un certains nombre de thread, j'avais des erreurs et autre amusement du style.
Alors ca a peut être évolué depuis (l'année dernière) je ne sais pas, mais pour ce qu'on comptait en faire .
Sans compter que gc est pas forcément trés propre (envoie de signal 'exotique' pour ses coms, comme SIGPWR de tête).
[^] # Re: Mon cher Albert,
Posté par Jb Evain (site web personnel) . Évalué à 1.
Bah le problème c'est que si hein :) Sans GC, Mono va donc mallocer tous les objets managés, mais comme le langage ne met pas a disposition un mécanisme de libération de la mémore, et bien, elle ne sera jamais libérée. Donc effectivement, ça va te péter au nez très vite.
Pour information, pour l'instant on utilise le GC dit Boehm GC, du nom de son créateur. Le moins que l'on ne peut dire c'est qu'il est quand même très utilisé:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/#users
Certes le GC utilise les signaux SIGPWR, SIGXCPU, SIG33 et SIG35 en interne. Mais bon effectivement ça peut paraitre sale, mais c'est comme les eboueurs, ils manipulent des déchets, mais ça les empêche pas d'être sympa. (Si je gagne pas le titre de l'analogie la plus foireuse avec ça). Et au final, c'est quand même bien pratique.
Par contre je doit avouer que ton test est quand même surprenant. Réel besoin de 1000 threads simultanés? J'ai des doutes. Dans ces cas là on utilise un Thread pool, ce qui t'assure une réutilisation de threads. Mais bon, comme n'importe quelle utilisation assez extrême (1000 threads pour un processus, ça reste extrême pour moi). Ça peut déstabiliser le bouzin.
Sinon on a un gars qui est en train de re-écrire un nouveau GC, ça avance, c'est dur, et c'est pas encore réellement utilisable:
http://www.advogato.org/person/lupus/diary.html?start=23
http://www.mono-project.com/Compacting_GC
Tiens, marrant ce que google renvois pour `1000 threads`:
http://linuxfr.org/comments/103624.html#103624
http://linuxfr.org/comments/108955.html#108955
Faut pas qu'il passe par là lui, ou il va t'expliquer tout le bien qu'il pense de ton test :)
[^] # Re: Mon cher Albert,
Posté par briaeros007 . Évalué à 2.
Je voulais dire le gc de bohem (bien comme ca que ca c'écrit, non ? ).
/me s'est mal exprimé et s'en excuse.
Faut pas qu'il passe par là lui, ou il va t'expliquer tout le bien qu'il pense de ton test :)
Oh je suis près a l'écouter. Sachant que si je teste sur 1000 threads, c'est peut être qu'il y a une raison (une raison qui m'a fait découvrir des races condition et sortir un patch pour mono entre autre, et avoir un stage pendant 2 mois aussi ;) )
Et j'ai jamais dit que l'on ne faisait pas les tests en MxN ... Mais si gc supporte pas les 1000 threads posix, alors ça sert à rien d'essayer en rajoutant des structures plus complexes au milieu.
On ne testait pas les performances, on testait les capacité de parallélisation de gc. En ce sens je vois pas en quoi testait 1000 threads 'saismal' (tm).
Sans compter que c'était pas pour un serveur les tests. M'enfin je dis ca je dis rien .
[^] # Re: Mon cher Albert,
Posté par briaeros007 . Évalué à 2.
Si ca plante à 1000 threads sans raison apparente, il y a donc un bug.
Un bug qui risque d'apparaitre avec moins de threads mais qui durent bien plus longtemps.
L'avantage de faire de ce test, c'est que c'est facile a montrer que ca plante en 1 minute. un test simple pour appuyer ses arguments dans une présentation ;)
(Si j'ai fait ce test, c'est qu'on a testait avant et ca marchait pas super. Donc voir si ca valait vraiment la peine de supporte GC. Parce que c'est particulièrement chiant si on change le style de thread , GC geule facilement).
[^] # Re: Mon cher Albert,
Posté par briaeros007 . Évalué à 2.
J'avais oublié ca . Si dans mon précédent message (pas celui auxquel tu répond) j'ai parlé de race condition, c'est qu'il y avait une raison ;)
[^] # Re: Mon cher Albert,
Posté par TImaniac (site web personnel) . Évalué à 0.
Bah voyons. Si OOXML est utilisé, c'est uniquement parcque MS va abuser de sa position dominante. Il est où l'argument là ?
Je rappelle que le format ACTUEL d'office n'EST PAS OOXML. Il y en a une partie, mais il n'est pas complètement conforme à la norme.
Forcement, la norme existe toujours pas, elle risque encore de bouger. Mais tu peux quand même conserver 90% de la doc, et ca aide vachement les développeurs, quoique t'en dise.
C'est pas franchement l'avis des personnes qui ont étudié la norme, mais c'est pas grave hein.
Y'a 3 types de personnes qui ont étudiés la normes :
- IBM & Co : ils sont partisan, et n'y ont cherché que des bugs.
- les bloggers et autres amateurs (comme moi) : ils s'improvisent spécialistes, ca vaut pas grand chose.
- Les développeurs, ceux à qui s'adresse la doc, qui s'y connaissent en suites bureautique. MDI en fait parti. D'autres développeur (j'ai cité un de Gnumeric plus haut). Et eux sont content, ils la trouvent pertinente cette doc, même si elle est loin d'être parfaite, c'est un putain de pas en avant.
Après tu prends l'avis de qui tu veux, mais pour moi l'avis des derniers me paraît beaucoup plus pertinent.
Et quid de la clause de liberté de redistribution ?
Bah c'est du logiciel "libre", tu peux redistribuer sans problème Moonlight. Novell t'offre pas de protection c'est tout (ce qui est normal, tu n'offres pas de garantie sur un truc potentiellement modifié). Pas plus que quand tu télécharges la grande majorités des softs libres sur ton repository favori : t'as pas de garantie. (A moins de payer un service à RedHat ou Novell par exemple, qui t'offrent différents niveaux de garantie, logicielle, juridique, etc.).
C'est marrant ca : Novell essai de couvrir ses utilisateurs contre un système de merde, c'est pire que de ne rien faire ?
Ce qu'on nomme traditionellement 'FUD'.
Voilà, t'as tout compris le système de brevets : c'est un FUD permanent. Ce qu'il t'explique, c'est que ce FUD ne s'applique pas uniquement à Moonlight, mais à l'ensemble des logiciels (libres ou pas d'ailleur). Le vrai FUD c'est oublier de mentionner que le risque des brevets n'est pas cantonner à Moonlight.
1°) As tu une preuve qu'il y a des brevets sur linux ou OOo? Si oui tu serais aimable de donner des liens vers les brevets. Je te jure qu'on va recoder pour ne plus avoir ce genre de probleme.
Le problème, c'est qu'avec les brevets, par définition on est sûr de rien : déjà des brevets potentiellement impliqués, des softs potentiellement impliqués, et du véritable risque juridique. Ce qui est sûr, c'est que les grosses boîtes comme Novell, RedHat et autres Philips ont monté un consortium pour protéger certains produits "à risque", et bizzarement le kernel et OOo sont explicitement cité comme étant cibles "à protéger".
Enfin si tu veux un exemple pour ODF, c'est facile : ODF nécessite Java (applet, JDBC) qui nécessite MPEG-4. C'est de renommée notoire que MPEG-4 est couvert de brevets.
4°) et pourquoi mono ne serait pas attaquer en premier?
Rien ne peu le dire. Mais un peu d'étude stratégique permet de faire des suppositions à peu prêt intelligentes : Mono va dans le sens de l'expension de .NET, il contribue à étendre la techno. MS supporte officiellement Mono à travers ce partenariat avec Novell autour de Moonlight (ca vous paraît anodin, mais c'est une reconnaissance explicite de la légitimité du produit). OOo ne participe pas vraiment à l'expansion des technos MS : c'est un concurrent. Ne parlons pas de Samba, qui ouvre un protocole dont MS tirait de gros avantages à le garder fermer (Il faut une machine Windows pour accéder à ce genre de partage).
Après personnellement je vois pas MS attaquer ni Samba ni OOo, parcqu'ils se décrédibiliserait et ces softs sont protégés par le consortium dont j'ai parlé, qui regroupent des boîtes qui ont les moyens de se défendre.
Mais Mono ou Moonlight n'est pas plus dangereux que le reste c'est tout.
Ce qui est rigolo, c'est que tout le monde s'accorde à dire que MS passe son temps à FUDer sur l'insécurité des logiciels libres, et vous reprenez exactement leur FUD pour tenter de décrédibiliser... un logiciel libre, tout ca parcque vous aimez pas le produit.
Tu peux tres bien attaquer un soft ou tu as 97% de chance de gagner
Sauf qu'ils n'ont aucune chance de gagner, rappelons que Novell détient des brevets... sur .NET, et mono est couvert par le dis consortium. Dans ce genre de procès, il n'y a de toute façon pas de gagnant ou de perdant officielle, juste des tractations financières au bout sous la table, et un rejet de la plainte. (système US inside).
Bref, dire que Moonlight est dangereux en supposant une éventuelle attaque de MS, c'est la définition même du FUD. C'est pas faux, mais c'est absurde de le prendre comme argument pour pousser à utiliser d'autres technos qui sont exactement dans la même solution.
Discussion entre revendeurs d'armes :
- Achetez pas ses armes, elles tues !
- Oué un peu comme les tiennes.
[^] # Re: Mon cher Albert,
Posté par briaeros007 . Évalué à 2.
Ben je rapelle que la seule suite implémentant( et de facon incorrecte) ooxml en lecture et écriture c'est la suite office.
De la tu en tire ce que tu veux bien sur.
Le vrai FUD c'est oublier de mentionner que le risque des brevets n'est pas cantonner à Moonlight.
Le vrai FUD c'est joué a microsoft en disant 'attention y a des brevets' et quand on demande les brevets 'ben euh je sais pas, y en a c'est tout'.
Pour tes suppositions :
Supposons que mono se soit bien implémenter, que linux se soit bien dvp. A tel point que mono soit utilisé sur une plateforme linux , et qu'eux ils couvrent 50% des pc (on peut réver).
Tu vas attaquer quoi toi ?
Mono, où tu es SUR d'avoir des brevets
Linux, où tu es sur que si il y a une once de brevet qui apparait le code va etre réecris ?
Moi le choix est vite fait.
Sauf qu'ils n'ont aucune chance de gagner, rappelons que Novell détient des brevets...
Rappellons que Novell peut se faire racheter par exemple.
Bref, dire que Moonlight est dangereux en supposant une éventuelle attaque de MS, c'est la définition même du FUD.
J'ai dis ca moi ?
attend que je regarde
4°) et pourquoi mono ne serait pas attaquer en premier?
Je n'ai meme jamais parler de moonloght dans mon argumentaire.
Ensuite on se demande qui argumente (plus ou moins) correctement et qui ...
[^] # Re: Mon cher Albert,
Posté par TImaniac (site web personnel) . Évalué à 1.
Vois toujours pas l'argument. MS Office propose toujours d'enregistrer en vieux .doc. L'utilisateur a toujours le choix, notamment en entreprise où il est facile d'imposer des règles.
MS Office 2003 avait un format XML, pas grand l'a utilisé malgré la position "dominante" de MS...
Mais bon c'est plus simple pour toi, si OOXML marche, c'est uniquement un abus de position dominante. grosso merdo MS est condamné à abuser de sa position.
Le vrai FUD c'est joué a microsoft en disant 'attention y a des brevets' et quand on demande les brevets 'ben euh je sais pas, y en a c'est tout'.
Oué c'est aussi du FUD. C'est pas parcque MS se permet de FUDer qu'il faut faire pareil.
Tu vas attaquer quoi toi ?
Comme tu le dis, ton hypothèse part d'un rêve. Partant de là c'est pas très crédible ton scénario. Et ca ne dit d'ailleur pas pourquoi les autres softs comme OOo ne seront pas attaqués.
Linux, où tu es sur que si il y a une once de brevet qui apparait le code va etre réecris ?
Tu vas rire, c'est exactement la même politique officielle de Mono (cf FAQ). Dans la vraie vie c'est pas toujours possible, comme ca ne sera pas toujours possible dans Linux. C'est EXACTEMENT pareil. C'est marrant de prendre 2 situations identiques et de bien sûr imaginer 2 scénarios différents, comme ca arrange.
Rappellons que Novell peut se faire racheter par exemple.
Oué, IBM peut changer de stratégie, RedHat peut se faire rachter, MS peut couler, les poules peuvent se mettre à avoir des dents, bla bla bla. Tu pourras toujours imaginer des scénarios, c'est pas un argument pour autant.
Tu peux imaginer que Novell se fasse racheter... par RedHat ou IBM aussi tiens. Tu peux imaginer que Novell soit racheter par MS mais que le portefeuille de brevets soit vendu... à IBM.
T'as que l'embarras du choix. Mais on est plus dans le domaine de la science fiction que dans la réalité.
J'ai dis ca moi ?
Je n'ai meme jamais parler de moonloght dans mon argumentaire.
Comme souvent, vous vous exprimez avec tellement de sous-entendus... Mais bon jolie pirouette, bravo. Désolé d'avoir supposé que tu parlais du journal qui parle de Moonlight. Met Mono dans ma phrase tu préfères ?
[^] # Re: Mon cher Albert,
Posté par briaeros007 . Évalué à 2.
Ben on verras bien ce qui sortira alors :
La version de OOXML 'officisé' ou la version de OOXML aux normes?
Je pense déjà savoir ce qui va se passer, eu égart aux nombreuse expérience que nous a offert windows sur ses pratiques commerciales.
Mais si tu es persuadé qu'il va s'imposer par son seul intérêt technique, je suis prêt a prendre les paris.
Comme tu le dis, ton hypothèse part d'un rêve.
Ben oui c'est une suppositions. Peu de suppositions parte de fait, sinon ce n'est plus des suppositions.
C'est EXACTEMENT pareil.
Si tu en es si sur, au temps pour moi.
Mais tu me permet de conserver quelques doutes quand mêmes.
Ne serait ce par 'qui pousse' mono, et 'quel est le nombre de personne pouvant contribuer aux deux projets'.
Oué, IBM peut changer de stratégie, RedHat peut se faire rachter, MS peut couler, les poules peuvent se mettre à avoir des dents, bla bla bla.
Ah ben si tu suppose que le futur est exactement identique au présent, c'est sur il n'y aura JAMAIS aucun probléme. D'ailleur qui pensait que snort allait changer de licence? Que nessus aussi ?
T'as que l'embarras du choix. Mais on est plus dans le domaine de la science fiction que dans la réalité.
Le futur n'est PAS la réalité, par définition.
Met Mono dans ma phrase tu préfères ?
Voui, parce que je répondais a un ingénieur de mono.
Mais bon maintenant c'est nous qui faisons des pirouette parce qu'on a oser ne pas parler ce sur quoi tu nous engueule XD
[^] # Re: Mon cher Albert,
Posté par Pinaraf . Évalué à 2.
Une question me vient à l'esprit : pourquoi on se fait chier avec les brevets quand ça concerne les logiciels libres, alors qu'à ma connaissance les logiciels propriétaires sont loin d'être à l'abris ?
Il me semble que par exemple Microsoft a eu un problème à cause d'un brevet (très) (très) stupide qui touchait IE (un truc sur les plugins si mes souvenirs sont bons).
[^] # Re: Mon cher Albert,
Posté par abramov_MS . Évalué à 2.
[^] # Re: Mon cher Albert,
Posté par Pinaraf . Évalué à 2.
(Monde de merde !)
[^] # Re: Mon cher Albert,
Posté par abramov_MS . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.