Posté par Éric (Jabber id, page perso, ) le 12/09/2007 à 06:24. (lien). Évalué à 2.

> Et c'est là qu'il m'étonne : il dit qu'ils le seraient tout à fait.

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.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 11/09/2007 à 21:18. (lien). Évalué à 2.

Désolé de m'être emporté.

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.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 11/09/2007 à 20:56. (lien). Évalué à 2.

Étonnante affirmation. Mais en même temps pas vraiment quand on y réfléchit. Wikipedia est majoritairement contrôlée par des informaticiens et les sujets qui tiennent à coeur à cette catégorie reflètent souvent leur opinion.
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

Modèle, norme de fabrication à suivre dans la réalisation de produits en série; ce qui est conforme à la norme.

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 :

Type, état, comportement qui peut être pris pour référence ; modèle, principe directeur qu'on tire de l'observation du plus grand nombre

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.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 11/09/2007 à 15:28. (lien). Évalué à 3.

Enfin en disant cela il admet bien que C# est blinde de brevet et que mono en violent pas mal de facon connu.

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.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 27/08/2007 à 13:16. (lien). Évalué à 3.

Le problème ce n'est pas leur sécurité hein, mais un cheval de troie bien connu. Bref, la faute aux pirates. Pire, il s'agit d'une variante d'un cheval de troie, alors vous pensez s'ils y sont pour rien.

Le fait que le nom du cheval de troie soit "Infostealer.Monstres" n'est qu'un pur hasard. On ne laisserait certainement pas entendre que ce sont simplement quelques lignes de code qui exploitent une faille de *leur* infrastructure.

Bref, on a exploité un problème de leur côté, le gentil gars de la société antivirus a nommé le machin "tiens, un truc fait pour voler les infos à monsters, on va le nommer infostealer.monster" et tout de suite au lieu d'être une faille de sécurité ça devient "une variante d'un cheval de troie".

C'est beau la communication.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 21/08/2007 à 19:37. (lien). Évalué à 2.

Il existe un workaround simple de notre côté : poser une iframe (même vide) dans la page.

Ca pourrait être fait par la toolbar elle même, donc ne nécessite pas grand chose de plus que 4 lignes de javascript.

Perso j'ai fait un petit greasemonkey pour cela :
http://ganfset.free.fr/linuxfr/linuxfr.user.js

Aucune garantie à part que ça fonctionne chez moi.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 21/08/2007 à 19:35. (lien). Évalué à 7.

Bon, je confirme qu'avec une iframe le problème est résolu. Comme workaround je vous propose un script greasemonkey :
http://ganfset.free.fr/linuxfr/linuxfr.user.js

Aucune garantie à part que ça fonctionne chez moi.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 21/08/2007 à 19:20. (lien). Évalué à 3.

Le bug est résolu dans ff3. Il est possible qu'entre temps mettre une iframe dans la page puisse résoudre le problème.

https://bugzilla.mozilla.org/show_bug.cgi?id=282109
https://bugzilla.mozilla.org/show_bug.cgi?id=263686

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 18/08/2007 à 17:15. (lien). Évalué à 9.

Il y a encore des développeurs C à qui on n'a pas appris que le travail sur les flottant c'est de l'approximation, avec tous les problèmes que ça pose quand on fait une troncature ou un test d'égalité ?

Quand je vois ça en PHP ou dans les scripts j'accepte que le développeur ne sache pas, mais quand on travaille à bas niveau comme dans le C, ça fait partie des pré-requis je pense.

Le pire c'est quand le développeur ne peut penser que à un bug des outils, jamais à se remettre en cause.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 18/08/2007 à 15:33. (lien). Évalué à 2.

par contre c'est le _but_ du convertisseur de lire les anciens formats.

Oui, mais c'est dans les objectifs du format d'arriver de faire en sorte qu'un tel convertisseur soit réalisable et d'en faciliter l'écriture. Ca peut vouloir dire parfois faire perdurer un ancien comportement même s'il était contestable, ou prévoir des comportements à tiroirs qui sont à choisir dans l'entête du format de fichier. Et ... c'est justement ce que fait OOXML.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 17/08/2007 à 13:01. (lien). Évalué à 2.

Je répond en même temps au commentaire au dessus.

Il faut arrêter de vivre dans votre bulle. Une norme n'a que pour unique but de définir des règles communes et explicites. Ce n'est pas une loi ni même un idéal.

Une norme c'est même tout l'inverse en général : c'est bourré de compromis et de trucs pas forcément idéaux mais qui ont constitué une solutions que le groupe dans son ensemble a été capable d'accepter.

Une norme a toute légitimité pour prendre compte l'existant et la compatibilité. Que cet existant ait raison d'exister ou pas n'intervient nullement dans l'équation. Concretement il est là, ça fait donc partie des problématiques, ça fait logiquement partie de certaines solutions, donc de certaines normes.

Et que l'historique ne soit pas normalisé n'est pas non plus bloquant. L'important c'est que la manière de le prendre en compte soit normalisée, bref, qu'on ait justement cet algo de gestion de date dans le détail.

> ils n'ont qu'à assumer les conséquences

Dans l'ensemble on fait des outils pour fournir des solutions aux gens, on ne fait pas des rêves idéaux. Les conséquences elles sont à prendre en compte, d'autant que ce sont les utilisateurs qui vont se les manger, pas MS.

Couper la compatibilité aurait été défendable, mais la garder est tout à fait légitime, oui, même dans une norme.

> M$ sont les propriétaires de leur ancien format pourri, ils n'ont qu'à assumer les conséquences dans leur logiciel et non dans la norme .

Mais oui, et après on va leur reprocher de pas l'avoir normalisé ....


J'encourage ceux qui voient dans les compromis et la compatibilité uniquement la venue du malin (comprendre "MS"), de regarder un peu le travail fait pour normaliser la future version 5 de HTML. Là je doute que vous arriviez à diaboliser qui que ce soit. Pourtant, la spécification d'anciens bugs des implémentations et de comportements idéalement "mauvais" il y en a plein l'algorithme. Justement parce que tout ça ... ça compte.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 17/08/2007 à 08:49. (lien). Évalué à 2.

Le format OOXML a été conçu spécialement pour maintenir des compatibilités avec un seul système.

Le format OOXML a été fait pour maintenir la compatibilité avec les anciens formats MS. Sur ce point je vois mal comment on peut leur reprocher, surtout sachant que leur format était *tres* largement le plus répandu (à tort ou à raison ce n'est malheureusement pas la question, il faut faire avec).

C'est fait avec la comptabilité du système majoritaire en tête. Certes ils ont le beau rôle vu que le système majoritaire c'est le leur, mais factuellement ça reste ça.

Pour le bug de dates, on aurait très bien pu s'en sortir en enregistrant la bonne date et en faisant la conversion dans les filtres d'import pour les anciens softs (ceux qui ont le bug). Alors forcément c'est moins simple, mais ils demande une normalisation ISO!!

Tu crois qu'ils n'y ont pas pensé peut être ?
Ils sont vraiment stupides chez MS d'avoir fait perdurer dans le format toutes ces années un bug d'une des versions de départ (même pas toutes). Ca fait longtemps qu'ils auraient pu faire une moulinette à l'ouverture et à la fermeture hein ?
Sauf que ça impacte bien plus de choses, et en particulier tous les calculs de macro et de formules qui jouent sur les dates. Ca veut dire qu'à chaque fois qu'un nombre ou un texte est en dur dans une formule ou dans une macro, ça peut se baser sur l'ancien comportement des dates.
Ca veut dire que si on corrige le bug on doit aussi corriger toutes les formules et macro dont on tient à assurer la compatibilité. C'est malheureusement virtuellement impossible car ça demande de comprendre le rôle et l'utilisation des différents chiffres et textes dans les formules.

Faut tenter de se mettre aussi à la place des gens qui doivent tenter de faire un format qui permet une conversion avec un minimum de perte. Autant je suis content avec ODF, autant je suis tout de même content que tous les docs MS Office puissent être convertis vers un nouveau format ouvert qui garde fonctionnelles les formules par exemple, donc que OOXML existe.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 16/08/2007 à 21:38. (lien). Évalué à 2.

Je te sais tout de même trop au courant des enjeux pour croire que Sun ou IBM font une révolution et non comme pbpg le dit une simple guerre économique.

Je ne nie pas que cela puisse révolutionner des choses côté utilisateur et que cela puisse être "bien", mais ne nous voilons pas non plus la face ni sur les motivations ni sur les méthodes de ceux qui agissent au bout (ici principalement sun et ibm).

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 16/08/2007 à 21:10. (lien). Évalué à 1.

Le coup du bug de date c'est effectivement très bien pour se moquer, et je ne m'en prive pas. Mais :

- c'est un point de détail, franchement
- l'alternative c'est de casser la compatibilité de toutes les macros et du coup la portabilité des anciens docs office

Et pour le second point je comprend franchement que c'est difficile à accepter. Que le format soit libre ou pas n'y change malheureusement pas grand chose : il y a eu des conneries de faites avant, c'est dommage, mais maintenant il faut faire avec quand même.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 16/08/2007 à 20:22. (lien). Évalué à 2.

Ce n'est pas (forcément) une question de manque à gagner, c'est simplement qu'on part d'une situation où l'auteur à un droit exclusif de contrôle sur son oeuvre.
On lui retire une partie de son droit d'exploitation en autorisant les copies privées, et on le compense ainsi.

Tu peux voir ça comme une licence globale ;)

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 16/08/2007 à 14:59. (lien). Évalué à 5.

Rien en contre-partie pour "l'honnête citoyen"

Ah si, y'a la copie privée en contre-partie.

Parce que contrairement à ce qui est encore insinué par les habituelles assimilations, cette taxe, bien que contestable, n'est aucunement liée au piratage, mais uniquement là comme contre-partie à la copie privée.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 16/08/2007 à 13:17. (lien). Évalué à 2.

> OOXML nécessite, d'après certaines analyses, un système Windows

Source ? avec le FUD ambiant sur le sujet de la part des deux "camps", je pense que ce genre d'affirmation ne devrait pas être avancée sans source factuelle fiable (la non implémentation actuelle dans la suite Mac ne me semble pas un élément de preuve quelconque).

> J'ai parcouru au pif la norme et on y trouve des références à MS Word,

Note, le format ODF fait lui aussi référence à des comportements d'anciennes versions de MS Word (ou plutot "devrait" parce que si j'en crois plus haut ça fait justement partie des choses non documentées comme config).

Ceci n'est pas forcément un point négatif. Prendre en compte les formats existant les plus répandus lors de la conception d'un nouveau format, et y faire des références, m'apparait plutot comme un comportement sain.

> MS fait des trucs biens, mais OOXML c'est vraiment clairement juste pour tenter d'étouffer la concurrence

Certes, mais l'un n'empêche pas forcément l'autre.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 16/08/2007 à 13:13. (lien). Évalué à 2.

Sans perte ?

Moi je veux bien que *tu* n'aies pas eu de pertes, mais de là à dire qu'on a compatibilité ...

Je n'ai pas testé koffice, je me fie aux informations officielles. Sur le site koffice je trouve, pour la dernière version stable (1.6.3) :

- import ooo writer : "some features might be missing or might not work correctly yet."
- export ooo writer : "The filter generally works although it is not finished, and it may suffer from some instability"


- import ooo calc : "The filter generally works although it is not finished, and it may suffer from some instability"
- export ooo calc : "Work has begun on the filter although the code is still at an early stage of development, and does not work properly"

Je te fais grâce de la compatibilité affichée sur OOo draw ;)

Après peut être que ces informations ne sont pas à jour mais dans l'ensemble je doute qu'on puisse prouver à partir de koffice que le format OOo fait preuve d'une excellente implémentation ailleurs que dans OOo lui même.


Pire, pour OOo writer, le site de koffice (toujours explicitement pour la version stable courante, donc information à priori à jour) marque sur http://www.koffice.org/filters/1.6/kword/oowriter.php je cite "depending on the documents, it might be better to use RTF (Rich Text Format.)"

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 16/08/2007 à 12:55. (lien). Évalué à 2.

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....

A leur décharge, qu'on le veuille ou non leur format est très très répandu. Du coup, il apparait comme utile de proposer des fonctionnalités pour faciliter la conversion et la relecture des anciens formats MS.

C'est vrai qu'on parle de OOo et d'un format ouvert ou qu'on parle d'une autre suite avec un format fermé. Le format de MS Word 98 aurait été ouvert et documeté, ça n'aurait rien changé à la nécessiter de rajouter cette règle sur l'espacement. Du coup le terme "pourrir" m'apparait vraiment comme abusé.

Et tout cela ne retire pas l'idée que oui, ces critères de compatibilités ne sont (seraient, parce que je vous fais confiance) pas documentés dans ODF, et que c'est justement le genre de fonctionnalités qu'on reproche à OOXML. Bref, restons cohérent ici.

[ Répondre ]

Posté par Éric (Jabber id, page perso, ) le 16/08/2007 à 12:51. (lien). Évalué à 10.

La netiquette voudrait que sur ce genre de forums le tutoiement soit la norme.
Et quand bien même je comprend qu'on puisse opter pour l'inverse, personnellement je vois beaucoup plus comme insultant la remarque du type "on n'a pas gardé les cochons ensemble" en réponse au tutoiement.
Le message auquel je répond m'apparait par exemple très agressif alors que la remarque de pbpg qui en est à l'origine me semble beaucoup moins l'être.

Bref, c'est une question de point de vue. Et même si je suis plus que souvent en désaccord avec son opinion exprimée, j'ai plutôt l'impression que c'est lui qui fait cible de mépris, d'insultes et de réponses agressives hors sujet. Je le félicite au contraire de rester assez calme est le plus souvent dans le factuel en réponse, ça ne doit pas être si simple ici.

[ Répondre ]