benoar a écrit 4229 commentaires

Bah, c'est quand même plus facile d'acheter un ordi tout prêt. T'as pas à te faire chier à le monter, tu le ramène dans son carton directement de la fnac, et t'as le petit sticker de la marque ... bref, la vie moderne, facile, pas fatiguante.

Gueuler ça demande pas trop d'effort, alors que monter un PC...

Et moi j'en connais qui ont des grandes gueules mais qui de toutes façons finiront par acheter leur PC sous Vista, en essayant de se justifier par un quelconque argument à 2fr.

Ça aide peut-être un peu, mais chez moi, même sans Flash, il bouffe quand même une quantité astronomique de RAM.

Ce que voulais dire briaeros007, à mon avis, c'est que si OOXML offre au moins toutes les possibilités de formatage des anciens formats (.doc, .xls, ...), c'est à dire si ces anciens formats sont un "sous ensemble" de OOXML, alors la conversion est possible sans perte et sans ajout de balise de compatibilité, dans les deux sens. Alors peut-être qu'il ne s'est pas complètement bien exprimé, mais ce n'est pas en attaquant les gens que tu va améliorer ta crédibilité.

Si tu arrêtais de réagir aux trolls (car c'est vrai que sur OOXML, il y en a pas mal qui sont vraiment de mauvaise foi) par des phrases assassines, tu t'en prendrait peut-être moins dans la gueule. Il y en aura toujours qui ne comprendront rien, ça personne ne peut l'empêcher, mais on est ici pour argumenter ses positions dans le "calme". Après cette intervention, je ne vois pas en quoi cela va t'aider à reconnaître que sur le coup, tu avais tort, et que cette conversion .doc <-> OOXML est possible.

Je suis d'accord avec ton analyse de ce que doit être une norme, et des contraintes à prendre en compte. Tout n'est pas idéal, et on doit tenir compte de l'existant.

Mais le problème ici, c'est que tout se base sur le travail d'un unique acteur : Microsoft. Et tout n'est fait que dans un seul but : satisfaire Microsoft. Personne n'a son mot à dire (Novell ? c'est kif kif) et tout cela est fait pour imposer encore plus les logiciels de la firme monopolistique pour la rendre encore plus monopolistique (despotique ?).

Implémenter OOXML dans un autre logiciel sera long, très long. Alors oui, les normes, c'est pas toujours facile, mais là c'est quand même énorme les hacks présents partout. Alors que pendant ce temps, MS aura juste à changer son parser (même pas son lexer !), et voilà.

HTML5 est un travail prenant beaucoup en compte l'existant, et c'est clair qu'il doit y avoir des parties qui sont pas belles à voir. Mais c'est le travail de tous les acteurs du Web, qui travaillent ensemble sur un format qui était déjà ouvert avant (même si sujet à interprétation particulière de la part de chacun). Et en plus, il existe déjà plusieurs implémentations de navigateurs HTML4, libres et propriétaires. Cette procédure de normalisation me paraît quand même plus "normale" que celle d'OOXML.

Tiens, on voit aussi que dans la journée du 13/08, il y a eu un volume d'échange de 6 millions d'action (à 1,5$) : ça fait quand même pas mal pour quelqu'un qui a voulu s'en débarasser.

Introuvable ... c'est le deuxième lien sur Google avec "OpenOffice 1.1 line spacing" ...

Sinon, je suis d'accord que tu dénonçais ce problème non pas pour montrer que c'en est un, mais pour dire que ODF avait les mêmes lacunes que OOXML. Et c'est justement sur ce point là, je crois, qu'on arrive pas à s'entendre (ainsi que pas mal d'autres personnes ici envers toi) : pour moi, ce n'est pas normal pour un standard d'avoir ce genre de problème. C'est dommage qu'ODF ait ce genre de truc bizarre non-spécifié, mais je trouve ça quand même minime par rapport au nombre beaucoup plus élevé de choses étranges qu'on trouve dans OOXML. Et de plus, même si ça n'est pas la panacée, on peut toujours aller voir l'implémentation d'OOo; mais c'est clair que ce n'est pas idéal.

Bref, je pense que beaucoup de gens ici sont pour un standard complètement ouvert et complètement spécifié. Il est clair que même ODF ne respecte pas à 100% ces directives, et c'est ce que beaucoup de gens ont effectivement du mal à accepter ici, que ce standard ne soit pas parfait. Mais ce n'est pas une raison pour ne pas chercher à corriger ces problèmes (bon ok, le standard est déjà publié, le mal est fait...).

Mais par contre, ce que les gens ont, et je trouve, à raison, du mal à accepter, c'est que tu mettes ces problèmes sur le même pied d'égalité : OOXML en a clairement plus. Alors après tu dis que ce sont des attaques injustifiées, que c'est uniquement parce que pour les libristes, MS c'est le mal, etc ... Mais je pense que ce que tout le monde veut dire ici, c'est que OOXML contient quand même beaucoup plus de problèmes qui le rendent beaucoup moins acceptables en tant que norme que l'ODF.

Ha merde, j'aime bien la bière belge, mais je ne suis pas du tout dans le coin : je suis à l'ouest... tant pis.

Oui, c'est utile de proposer des fonctionnalités présentes dans le traitement de texte le plus utilisé au monde.

Mais ce que je trouve assez fort, c'est que, comme le dit Olivier Faurax, cette option "bizarre" dénoncée par les pro-OOXML a justement été créée pour être plus compatible avec Word...

Et quand tu fais l'hypothèse d'un format de MSWord ouvert : si ça avait été le cas, on aurait jamais eu tous ces problèmes d'interopérabilité, et on n'en serait pas à se battre comme ça aujourd'hui.

Certes, il est important de ne pas avoir de fonctions non-documentées dans un format standard, et je trouve regrettable cette histoire de "line spacing" dans ODF. Mais je trouve que ça reste quand même marginal comme problème, par rapport à toutes les incohérences, bizarreries et autres hacks pour la rétro-compatibilité inclus dans OOXML.

Hopla : http://marketing.openoffice.org/2.0/featureguide.html
Rechercher "line spacing" :

The formatting of text lines with a given proportional line spacing has been adjusted for better conversion from / to Writer documents and Microsoft (R) Word documents.

Donc en fait, cette option qui a l'air de faire débat ici, permet de réactiver l'ancienne règle pour l'espacement de ligne, qui n'était pas assez "MS office compliant". Bref, avec le nouveau OOo, on est encore plus près du fonctionnement non documenté de Word ! \o/ Formidable.

Donc tous ces débats pour dire que ODF a des parties "sombres" dans sa spec, c'était juste en fait pour satisfaire les exigences du format de données de MS....

La morale de cette histoire : MS continuera surement a pourrir les standards encore longtemps...

Pour la bière, soit tu l'offre à Google, soit tu me dis dans quel coin tu comptes aller me l'offrir ;-)

Et bien justement, on t'attendait \o/
Oublie pas de ramener tes copines ...

Oui c'est vrai qu'au niveau de la com, ça n'a pas été très largement diffusé (je n'en ai entendu parler que par mon LUG). Je ne fais pas partie des orgas, mais j'espère qu'avec un peu de pub ici il y aura quelques libristes attirés.

Alors, comme défense, on a vu mieux : il reste complètement flou.

I know our deal with Microsoft is controversial, but it is necessary for our customers who have to deal with both Linux and Windows in their data centers. Virtualization is also going to have to deal with both of those operating systems

Je ne vois pas le rapport avec la choucroute : on peut très bien virtualiser un Linux et un Windows sur une même machine sans avoir "l'autorisation" de MS.

On parle du deal sur les brevets, bordel de merde, il essaye de noyer le poisson en faisant croire que c'est un accord qui rend nécessaire aujourd'hui d'avoir une licence de MS pour "utiliser Linux"... sans expliquer pourquoi.

Je ne suis pas d'accord avec ta définition de l'interopérabilité. Comme le dit briaeros007, être intéropérable c'est diffuser les specs de son format sans restriction. Pouvoir être utilisé presque partout (comme Flash) n'est pas un gage d'interopérabilité, c'est juste un "standard de fait". Alors avec ta définition, faire un logiciel Windows-only c'est être intéropérable, puisqu'il va marcher sur 95% des PCs ?
Alors peut-être que tout le monde arrive à manipuler du flash plus simplement que du SVG (remarque, tu viens de tomber sur un des (rares) mecs qui ne pourra pas lire de flash alors qu'il lit très bien du SVG) mais cela est dû au monopole de Flash qui s'est imposé sans alternative grâce à son format fermé, un peu comme MS quoi. Si tu trouves que c'est une bonne méthode pour mettre tout le monde d'accord, je ne pense pas qu'on va arriver à s'entendre ...

Désolé, mais quand je vais sur youtube, que je fais "rechercher les plugin", il me dit qu'il ne trouve aucun plugin qui correspond. Devine pourquoi.

Je ne fais donc pas partie du "commun des mortels" ? Sûrement, je suis un sale barbu intégriste. Et il faut absolument supprimer les personnes qui ne sont pas comme tout le monde. Je suis désolé, mais prôner l'utilisation du Flash, sans rien faire à part attendre que quelqu'un veuille bien te "proposer" un lecteur libre, c'est du foutage de gueule doublé d'intolérance.

Heu, il est à noter que le modèle fixe est vendu avec une carte vidéo NVidia 8300GS ... Bref, niveau compatibilité, ça ne garantie rien si on est attaché au libre. C'est compatibilité OK si on aime bien les gros blobs proprios.

Je viens de voir que les specs du format de la version 9 viennent de sortir il y a quelques semaines seulement :
http://weblogs.macromedia.com/emmy/archives/2007/07/finallys(...)
Mais bon, toujours avec la même licence de merde.
Pour rappel, le player version 9 est sorti en juin 2006..

Alors oui, forcément, pour la création de contenu Flash, il existe beaucoup de logiciels puisque la spécification "l'autorise". Mais déjà, rien que le fait de devoir mettre "Adobe(c) Flash(tm)" je trouve ça contraire au principe d'interopérabilité.

Ensuite, au niveau des players, ils ont tous été fait à partir de reverse-engineering, puisque les specs du format interdisent de faire un player : je trouve ça absolument abjecte de faire ça, franchement, pour moi, c'est illégal d'empêcher quelqu'un d'implémenter un format quelconque. Et être obligé de faire du reverse et être dans la semi-légalité pour faire un player, ce n'est pas du tout ce que j'appelle de l'interopérabilité.

Franchement, j'invente un format de musique (très basique), sans dont la grammaire BNF est la suivante :
CHANSON ::= e | NOTE " "
NOTE ::= do | re | mi | fa | sol | la | si | do
Le premier qui implémente un prog pour lire ça va en prison. Voilà. Franchement, c'est débile.

Et quand tu parles de licencier sa techno, encore une fois, ce n'est pas de l'interopérabilité. C'est de la captivité.

Autant sur les autres arguments, je n'ai pas d'avis particulier sur flash car je ne le connais pas vraiment, mais sur l'interopérabilité, tu y va fort : quels sont les clients et éditeurs alternatifs dont tu parles ? Ne parle pas de ceux basés sur le SDK d'Adobe, ce n'est pas ce que j'appelle de "l'aternatif".

Et sur les clients qui marchent sur d'autres plateformes que celles qu'Adobe veut bien supporter : quels sont les faites selon toi ? Tu veux parler des plateformes mobiles/embarquées ? Je n'ai aucune précision sur ceux là, si tu en as ça m'intéresse. Mais je pense qu'ils sont tous basés sur une bonne partie du code d'Adobe, et avec des contrats très restrictifs : ce n'est pas ce que j'appelle de l'interopérabilité. (OK ce sont des suppositions, je serais heureux que tu me montres que j'ai tort)

Je viens de voir que la nouvelle version de la suite d'Apple, iWork '08, supporte le OOXML en lecture :
http://www.apple.com/fr/iwork/pages/#compatible
(là c'est juste pour le traitement de texte, mais c'est pareil pour le tableur et le "présenteur")
Bon, Apple n'étant pas toujours connu pour son ouverture à ce niveau (son format de fichier maison est à moitié proprio / à moitié ouvert mais à chier), ça ne m'étonne pas, mais je trouve ça dommage que OOXML commence à si "facilement" se diffuser : je pensais qu'un "opposant" comme Apple aurait plutôt rechigné à implémenter ce format. D'un côté, niveau suite bureautique, ils n'essayent pas vraiment de se battre puisque MS Office est le dernier logiciel encore porté aujourd'hui sur Mac, et il ne risque pas de s'éteindre à mon avis.
Enfin bon, comme c'est qu'en lecture, ils n'ont dû avoir qu'à modifier leur parser (les précédentes versions de iWork lisaient déjà les anciens format de MSO) étant donné la ressemblance troublante entre OOXML et ses prédécesseurs...

Ca m'a toujours fait ça lors de certains overclocking un peu trop élevés : sous windows, ça tournait "a peu près", même s'il y avait des corruptions de partout, alors que sous linux j'arrivais même pas à la fin de l'initialisation du kernel.

Sauf que si tu avais lu la news, ceci concerne des softs embarqués dans un "téléphone Skype" qui sont sous GPL. Téléphone que tu achètes et qui t'appartient.

Il est même peut-être hasardeux de réduire la question des « performances desktop » à l'ordonanceur ou au pré-chargement de la mémoire virtuelle (par exemple ce n'est pas forcément ce qui compte le plus pour les « performances » du rendu 3D d'un jeux, ou le décodage d'un flux h264, ...). L'interactivité a en outre le désavantage d'être difficile à mesurer (ce qui explique surement une bonne part de ce que Kolivas considère comme un manque d'intérêt des autres développeurs pour son travail, il le reconnaît mais sous-estime peut-être un peu l'influence de ce facteur sur les décisions).

Tout à fait d'accord, je pense que beaucoup de problèmes de réactivité du desktop sont dûs à différents problèmes concernant les couches graphiques (X11, GTK, etc ...) plutôt que le noyau. Quand on voit la "réactivité" d'une console...

Menteur ;) Je suis sur que toi aussi tu fais de temps en temps un speech a tes petits camarades, collegues de boulot, famille etc pour leur expliquer pourquoi tu es un sale gnou barbu.

Ouai, bon c'est vrai, j'ai dû bassiner pas mals de personnes avec ça :-)

L'emmerdant c'est que même ça, dans les faits on en est pas si surs :/ Certains te diront que si, d'autres te dirons que non (et ce, chez les 'spécialiste de la propriété intellectuelle et des brevets').

Ça c'est embêtant, mais il faudra bien un jour savoir... Mais vu comme aucune entreprise n'attaque aujourd'hui, je suis assez confiant qu'avec la législation actuelle, les brevets logiciels ne passent pas.

Je suis un slackeux et Slackware n'est pas vraiment une distro intégriste en ce qui concerne les licences et autres brevets donc je ne sais pas trop. Pourtant j'aurais cru que chez les purs et durs (Fedora / Debian) les dépots sont justement assez bien séparés (au point que ça fait des trolls réguliers pour animer nos longues soirées d'hiver).

Oui, les dépôts complètement libres (et sans brevets) sont séparés du dépôt "mauvais" (non-free) qui contient aussi bien des logiciels non-libres que des logiciels libres, mais brevetés. Et c'est sur ces deux derniers cas que je veux faire la distinction !

Sans vouloir troller, il me semble pourtant que l'orientation d'Ubuntu est d'abord de fournir une distro 'for human being' et ensuite de fournir une distro libre. Ceci explique sans doute celà : une distro sans mpeg 4 ou mp3 de base (pourtant soumis à brevets) ne peut pas (à mes yeux) prétendre à être une distro pour le quidam moyen.

Oui, je suis d'accord, mais la séparation que je demande permetterait aussi de montrer que, si on ajoute l'hypothétique dépôt "libre mais breveté", on peut avoir une distribution _totalement libre_, sans logiciels proprios, même si certaines parties libres sont brevetées.

Si tu pousses le raisonement plus loin, il faudrait mettre le noyau linux dans un dépot à part car lui même viole au moins 243 brevets appartenant à MS (hohoho.ogg). D'ailleurs, la plupart des logiciels doivent violer 243 brevets au minimum. Je ne crois pas que les mettre dans un dépot à part va changer quoi que ce soit : tu vas juste montrer que 99% de la production logicielle libre viole des brevets tout comme 99% de la production logicielle tout court, sauf que les éditeurs de softs proprios oublient gentiment de le rappeler.

Le truc c'est que pour le noyau ce n'est pas complètement avéré, même si je pense qu'il doit forcément y en avoir quelques un. Pour tout ce qui est MPEG, le standard précise tout de suite que l'implémentation qu'on en fera sera forcément couverte par certains brevets, donc là au moins on est sûr. Mais c'est vrai qu'au final, tout serait dans une section "brevetée". Et c'est là que je m'insurge contre ce dépôt "non-free" qui mélange allègrement logiciels libres mais couverts par des brevets, et logiciels proprios (couverts ou non d'ailleurs).

A mon avis, le barbu moyen comme toi et moi, il a déjà un rôle à jouer à son niveau : faire de l'information sur les dangers des brevets logiciels (et autres joyeusetés comme EUCD) et expliquer pourquoi l'idée même d'un brevet logiciel ne peut pas fonctionner. Même si 99.9% des gens s'en tapent, quand ils rencontrent les premiers inconvéniants de ces saloperies, ils se rappellent qu'un jour tu les as bassinés avec ça et reviennent généralement te demander de réexpliquer ce qu'ils n'avaient pas écouté avant.

J'essaye aussi de faire ce que je peux niveau information, sans trop gaver les gens (généralement il ne faut pas que ton speech dépasse 30s sinon c'est mort .... pas facile).

Mais je n'ai pas l'impression que tu aies sasi le combat sur lequel j'essaye de me concentrer : c'est contre les logiciels proprios, tout en affirmant que les brevets sont débiles. Mais c'est d'abord pour réunir tous les logiciels libres ensembles, et pas mettre certains à part parce qu'ils ne sont soit-disant "pas libres" parce que couverts par des brevets, alors que, comme tu le dis, ça concerne sûrement une grande majorité des LLs. Et qu'en Europe, je n'ai pas "besoin" d'avoir la distinction breveté/non-breveté, mais je veux vraiment avoir la distinction libre/non-libre.

Je pensais plutôt à DCOP -> DBUS