Le 4 mars 2007 toujours sur l'excellent Formats-ouverts.org, Thierry STOEHR écrivait : "Il est aussi certain que la bataille va faire rage en public ou dans les coulisses pour définir ce qu'est un standard ouvert."
Mais il y a un élément nouveau en date du 19 mars 2007 :
"For exchanging documents between public authorities, the ministry proposes the use of either ISO standard Open Document Format (ODF) or Microsoft's standard, Office OpenXML."
(http://ec.europa.eu/idabc/en/document/6768/469)
Verrons-nous la même chose en France pour le RGI ? Il y a lieu d'être inquiet à la lecture des déclaration de Marc Mossé, directeur des affaires juridiques et publiques Microsoft France dans Neteco le 12 mars 2007 :
"Nous soutenons depuis le début l'objectif d'interopérabilité voulu par les pouvoirs publics. C'est pourquoi, nous espérons une approche pluraliste et neutre fondée sur des standards ouverts tel OpenXML et d'autres."
"OpenXML est un format et non celui de Microsoft."
Aller plus loin
- Formats-Ouverts.org :Danemark : le parlement vote pour les standards ouverts ! (1 clic)
- Formats-Ouverts.org : Le Danemark continue avec les standards ouverts (1 clic)
- IDABC : DK: Open standards made mandatory (1 clic)
- Neteco : Mossé : (1 clic)
- Linuxfr : RGI : Parution du décret au journal officiel (1 clic)
- Apitux.org : Formats ouverts et interopérabilité (1 clic)
# OOXML
Posté par Nico C. . Évalué à 5.
Si MS Office OpenXML passe l'ISO, il est tres probable que ca arrive en France.
Mais comme il est peu probable qu'il passe l'ISO en l'etat alors il est tres peu probable qu'il figure sur la joyeuse liste des formats ouverts autorises par le RGI.
M'enfin, je dis ca mais je suis pas oracle...
D'ailleurs, le RGI ne cite t il pas OpenDocument explicitement comme LE format standard a utiliser ??
[^] # Re: OOXML
Posté par netchaiev . Évalué à 4.
Oui mais comme le RGI n'est pas encore définitif, des coquilles [du genre OpenXml] peuvent toujours se glisser ...
Mais j'aimerais quand même avoir ton optimisme ...
# A défaut, il y aura toujours l'argument financier ...
Posté par netchaiev . Évalué à 6.
Un truc mi-figues/mi-raisins pour ne pas heurter la sensibilité des 2 camps.
Mais il y a qd même une lueur d'espoir :
Nous tournons (secteur hospitalier, 500 postes) sous MsOffice97 [certes nous avons commencé une migration vers OO mais il y a pas mal d'ilôts de resistance (au sein même de l'équipe de direction)].
Mais bientôt l'heure du choix arrivera :
MsOffice 2003 (minimum requis pour lire les formats ODF/Oxml) ou OpenOffice .
Et là , la facture suffira d'elle même à faire taire les + réfractaires ...
[^] # Re: A défaut, il y aura toujours l'argument financier ...
Posté par floriang . Évalué à 4.
Tout dépend de *qui * fait la migration : une SSII/SSLL ou le responsable informatique ?
Dans le 1er cas, appel d'offre obligatoire (service public) et là les prix peuvent changer : une société désireuse d'avoir le projet peut ...
Enfin voilà quoi. Vaut mieux être dans le 2e cas (et ne pas faire passer la migration vers MSO 2003 ou 2007 pour une màj, sinon, l'OpenDocument obligatoire ne s'applique pas (car il est obligatoire pour une migration, mais pour une màj...)).
[^] # Re: A défaut, il y aura toujours l'argument financier ...
Posté par vincent mary . Évalué à 1.
Malheureusement, les éditeurs de logiciels hospitalier n'intègrent pas encore assez bien OO dans leur produit, ce que fait que les établissements restent captifs de la suite microsoft.
On ne choisi pas son logiciel de dossier médical en fonction de la suite bureautique ... :/
# comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 10.
D'après le document MS qui suit, le format OpenXML est libre (pas de droit d'utilisation ou d'implémentation à régler) :
http://www.microsoft.com/interop/osp/default.mspx
Certes MS peut ne pas respecter sa propre norme, mais il ne peuvent pas le faire à court terme. Ils doivent attendre qu'OpenXML soit largement diffusé (comprendre qu'on soit dépendant de MS-Office).
Si on tente d'être neutre et qu'on oublie l'animosité qu'on (que j'ai au moins) envers MS quel sont les atouts de ODF par rapport à OpenXML et vice versa.
Avantages d'ODF :
* ODF est ISO pas OpenXML. C'est un petit atout.
* Dans la pratique d'aujourd'hui, ODF est indépendant de l'OS. On le trouve partout.
* Le format ODF est le résultat de la participation de nombreux acteurs du logiciel. ODF a de nombreux acteur du logiciel derrière lui.
* ODF est mieux foutu. Entre autre il n'y a pas de "blob".
* ODF est un standard de fait car il est déjà utilisé par OOo, KOffice et Abiword (gnumeric aussi ?).
Faiblesses d'ODF :
* Peu déployé. Le nombre de document au format ODF reste encore limite confidentiel.
Avantages d'OpenXML :
* Il a la puissance de MS derrière lui. C'est un atout énorme.
* Il devrait y avoir un passage en douceur de .doc etc à OpenXML. C'est encore un atout énorme.
* La base d'utilisateur de MS-Office est énorme. Encore un énorme atout.
* MS-Office roxe. Je sais, je vais être moinsé massivement mais c'est vrai.
Faiblesses d'OpenXML :
* Il a la puissance de MS derrière lui. Donc aussi un fort potentiel de dérive comme MS en a le secret.
* Il est mal foutu.
* N'est pas un standard ISO.
* N'est pas un vrai standard car il n'y a que MS-Office qui le supporte réellement.
* N'est bien supporté que pour Windows.
Pour un organisme sans "idéologie", il y a de quoi hésiter.
Par contre pour le libre et aussi pour les utilisateurs il faut un standard comme il n'y a qu'un standard pour le web, tcp/ip, etc...
Le libre ira vers ODF. Il faut "tout faire" pour que MS aille aussi vers ODF comme il est allé version tcp/ip, comme il est allé (en trainant des pieds) vers les normes w3c.
C'est crucial.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à 4.
Le probleme avec ca c'est que MS n'avait pas d'autre choix que TCP/IP et les normes W3C, il n'existait rien d'autre qui offre les memes possibilites.
La, MS domine le marche et a son propre format. Les faire aller vers ODF c'est un peu une utopie. A long terme(>5 ans) qui sait vu la vitesse des changements en informatique, mais d'ici la aucune chance.
A part ca, tout a fait d'accord avec ton post.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 2.
Pour W3C, c'est un peu faux. MS voulait laisser tomber html/etc. Mais comme Firefox grimpe, MS a sortit IE7 par exemple.
[^] # Re: comparaison ODF et OpenXML
Posté par Anonyme . Évalué à 8.
Faux dans les deux cas. Avant la percée de firefox, le web dérivait de plus en plus vers quelque chose de visionable uniquement sous IE.
Quand à TCP/IP, c'est bien contraint et forcé que Microsoft a dû l'adopter. Tout le monde a déjà oublié la nature de MSN (MicroSoft Network) à sa sortie ? Un protocole internet propriétaire et concurrent de TCP/IP ! Ça a fait un flop, donc MSN a été reconverti en portail puis c'est devenu l'acronyme de la messagerie instantanée de Microsoft.
« Embrace, extend and extinguish »... Comment Microsoft Office s'est-il imposé ? Ah, la bonne blague du RTF ! C'est être naïf de croire que Microsoft respecte les standards qu'ils mettent ou participent à mettre en place. S'ils peuvent faire passer en force un de leurs standards propriétaires ils n'hésitent pas : Microsoft siège au W3C depuis longtemps, même à la grande époque des sites IE-only.
http://fr.wikipedia.org/wiki/Embrace,_extend_and_extinguish
Et il faut malheureusement compter sur le fait qu'ils vont continuer à essayer chaque fois qu'ils le pourront. Et pour la bureautique, je doute fortement qu'ils aient l'intention de lâcher ou même partager la vache à lait. Surtout que les formats msoffice sont en quelque sorte l'avant-dernier rempart du monopole de Windows, le dernier étant la compatibilité binaire.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à 1.
IE c'est du W3C, qu'il ne respecte pas 100% les normes n'y change rien, Firefox ne les respecte pas completement non plus.
Tout le monde a déjà oublié la nature de MSN (MicroSoft Network) à sa sortie ? Un protocole internet propriétaire et concurrent de TCP/IP !
Perdu, c'etait un ISP a la AOL(partie du contenu limite aux membres), mais ca tournait sur TCP/IP
C'est être naïf de croire que Microsoft respecte les standards qu'ils mettent ou participent à mettre en place. S'ils peuvent faire passer en force un de leurs standards propriétaires ils n'hésitent pas : Microsoft siège au W3C depuis longtemps, même à la grande époque des sites IE-only.
Tout comme Netscape a l'epoque, mais tout le monde considere Netscape comme un heros, rigolo quand meme.
[^] # Re: comparaison ODF et OpenXML
Posté par benja . Évalué à 2.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 5.
IE fait (ou faisait) exprès de ne pas respecter les standards, Firefox fait tout pour les respecter. Quand Firefox ne respecte pas le standard w3c, c'est un bug. Quand c'est IE, on ne sait pas.
Il n'y a que depuis quelques mois que MS nous joue du pipo sur son soucis du respect des standards, l'ouverture et toussa, alors qu'il en a rien à foutre. MS fait du standard avec IE car il y a Firefox, car les administrations gueulent, etc...
Ne met pas IE dans le même panier que Firefox (ou Opera) pour le respect des standard. Si MS avais les mains libre, il saboterait les standards comme il l'ont fait avec IE 4 et IE 5.
> Tout comme Netscape a l'epoque, mais tout le monde considere Netscape comme un heros, rigolo quand meme.
N'importe quoi.
Netscape ne respectait pas les standards pour la même raison que IE. Netscape était aussi con que IE.
Mais Netscape est devenu un héro quand (et pas avant) ils ont créé mozilla et abandonné les manies mesquines à la MS.
De plus Netscape a été pionnier dans le web. Il a créé des choses qui n'existait pas dans les standards. Comme Mozilla crée des choses qui n'existe pas dans les standards (xul par exemple). Mais s'il y a un standard, la version spécifique est abandonnée.
[^] # Re: comparaison ODF et OpenXML
Posté par jcs (site web personnel) . Évalué à 1.
J'ai déjà lu ça plusieurs fois. N'étant pas un spécialiste du domaine et des problèmatiques liées à ce genre de formats, je me demandais ce qui dans ce format le rendais mal foutu ?
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 3.
Idem
> je me demandais ce qui dans ce format le rendais mal foutu ?
Parce que OpenXML veut offrir une grosse compatibilité avec les fonctionnalités .doc .xls, etc.
Donc les trucs mal foutus des anciens formats se retourne dans OpenXML. Il y a même des parties qui sont des "blobs" sur des formats partiellement documentés (wmf par exemple).
[^] # Re: comparaison ODF et OpenXML
Posté par Mithfindel (site web personnel) . Évalué à 2.
[^] # Re: comparaison ODF et OpenXML
Posté par Éric (site web personnel) . Évalué à 6.
Typiquement il y avait l'exemple des dates, où MS a fait bidouille sur bidouille. Donc dans le format, avant d'interpréter une date, il faut savoir si le fichier vient de mac ou windows, et éventuellement retrancher 1 au nombre de jour dans un des deux cas si la date est inférieur a un certain palier. Pour cette simple lecture/écriture de date il faut tout un code complexe.
Ce genre de cochonnerie existe dans les structures internes de MS Excel pour compatibilité avec les différentes génération de xls, et ça c'est bien. Mais du coup ça se retrouve dans le format openXML et ça c'est moins bien. En gros celui qui implémente openXML doit finir par réimplémenter tous les bugs de MSO depuis ses premières versions, et tous les workaround qui vont avec.
Si quelqu'un retrouve le doc là dessus ça m'intéresse, j'ai fait l'idiotie de ne pas sauvegarder le lien.
[^] # Re: comparaison ODF et OpenXML
Posté par zebra3 . Évalué à 4.
http://en.wikipedia.org/wiki/OpenXML#Criticism
Sinon, je pense que le lien dont tu parles, c'est celui-ci : http://www.grokdoc.net/index.php/EOOXML_objections
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: comparaison ODF et OpenXML
Posté par Mimoza . Évalué à 1.
Sinon pour le "mal foutue" je suis d'accord, je n'arrive plus à retrouver la page mais une orientation m'avais fait tiqué sur la manière dont s'ecrit OpenXML, ils ont préférere les balises courtes, CAD une lettre, pour alléger la taille, alors que OpenDocument avait mis en avant la lisibilité du code donc des balises plus explicite ... si je retrouvait cette page
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 3.
Tu peux développer ?
Le format OpenXML permet des outils que ne permet pas le format ODF ?
Ou c'est simplement que ces outils n'ont pas encore été développé pour ODF ?
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à -7.
Tu vas t'amuser a editer un fichier OpenXML ou ODF de 200Ko a la main ? Moi non.
Les balises, elles seront traitees par des softs dans 99% des cas, et ces softs ils s'en foutent que la balise fasse 1 ou 10 caracteres ou que la balise ait un nom explicite ou pas.
Que qqe developpeurs soient legerement genes car les balises sont courtes et non-explicites et reellement sans importance, ils seront legerement embetes une fois lors du dev. initial(devront jeter un oeil a la doc plus souvent) et c'est tout , en retour ca donne des fichiers plus legers et qui se chargent plus rapidement pour 100 millions de personnes sur la duree de vie du format.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 5.
Si les balises ont des noms compréhensibles, ça aide les développeurs, ça aide les échanges. Un standard qui est difficile pour les développeurs, ce n'est pas in fine un plus pour les utilisateurs.
Si le standard est utilisé que par un logiciel, pourquoi pas.
Mais ODF est utilisé par les développeurs de OOo, KOffice, Abiword, Gnumeric, etc... Comme c'est un standard, il y aura des outils pour convertir en pdf, en html, pour y faire des requêtes, alimenter une base de données, faire de la doc d'API depuis des sources par exemple en C vers ODF, etc...
Il est important que le standard soit accessible aux développeurs. C'est important aussi pour les utilisateurs.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à -2.
Si je te mets :
<OOo:bold attr="sds">mme michu</OOo:bold>
ou
<OOo:b a="sds">mme michu</OOo:b>
et la doc dit clairement ce que b et a sont, c'est du pareil au meme quasiment pour le developpeur, il met le define qu'il faut dans son code et c'est tout.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 2.
Pourquoi pas une API de ce type (j'ai gardé les mots clés C) :
/* t_qngr_arj() returns an invalid date, you then have to _frg() stuff
* to get a usable object. You can also allocate a TQngr statically,
* then call t_qngr_pyrne() to initialize.
*/
TQngr* t_qngr_arj (void);
TQngr* t_qngr_arj_qzl (TQngrQnl qnl,
TQngrZbagu zbagu,
TQngrLrne lrne);
TQngr* t_qngr_arj_whyvna (thvag32 whyvna_qnl);
void t_qngr_serr (TQngr *qngr);
/* check t_qngr_inyvq() after doing an operation that might fail, like
* _cnefr. Almost all t_qngr operations are undefined on invalid
* dates (the exceptions are the mutators, since you need those to
* return to validity).
*/
tobbyrna t_qngr_inyvq (const TQngr *qngr);
tobbyrna t_qngr_inyvq_qnl (TQngrQnl qnl) T_TAHP_PBAFG;
tobbyrna t_qngr_inyvq_zbagu (TQngrZbagu zbagu) T_TAHP_PBAFG;
tobbyrna t_qngr_inyvq_lrne (TQngrLrne lrne) T_TAHP_PBAFG;
tobbyrna t_qngr_inyvq_jrrxqnl (TQngrJrrxqnl jrrxqnl) T_TAHP_PBAFG;
tobbyrna t_qngr_inyvq_whyvna (thvag32 whyvna_qngr) T_TAHP_PBAFG;
tobbyrna t_qngr_inyvq_qzl (TQngrQnl qnl,
TQngrZbagu zbagu,
TQngrLrne lrne) T_TAHP_PBAFG;
TQngrJrrxqnl t_qngr_trg_jrrxqnl (const TQngr *qngr);
TQngrZbagu t_qngr_trg_zbagu (const TQngr *qngr);
TQngrLrne t_qngr_trg_lrne (const TQngr *qngr);
TQngrQnl t_qngr_trg_qnl (const TQngr *qngr);
thvag32 t_qngr_trg_whyvna (const TQngr *qngr);
thvag t_qngr_trg_qnl_bs_lrne (const TQngr *qngr);
/* First monday/sunday is the start of week 1; if we haven't reached
* that day, return 0. These are not ISO weeks of the year; that
* routine needs to be added.
* these functions return the number of weeks, starting on the
* corrsponding day
*/
thvag t_qngr_trg_zbaqnl_jrrx_bs_lrne (const TQngr *qngr);
thvag t_qngr_trg_fhaqnl_jrrx_bs_lrne (const TQngr *qngr);
thvag t_qngr_trg_vfb8601_jrrx_bs_lrne (const TQngr *qngr);
Même si c'est documenté, c'est brise couille.
La version originale :
/* g_date_new() returns an invalid date, you then have to _set() stuff
* to get a usable object. You can also allocate a GDate statically,
* then call g_date_clear() to initialize.
*/
GDate* g_date_new (void);
GDate* g_date_new_dmy (GDateDay day,
GDateMonth month,
GDateYear year);
GDate* g_date_new_julian (guint32 julian_day);
void g_date_free (GDate *date);
/* check g_date_valid() after doing an operation that might fail, like
* _parse. Almost all g_date operations are undefined on invalid
* dates (the exceptions are the mutators, since you need those to
* return to validity).
*/
gboolean g_date_valid (const GDate *date);
gboolean g_date_valid_day (GDateDay day) G_GNUC_CONST;
gboolean g_date_valid_month (GDateMonth month) G_GNUC_CONST;
gboolean g_date_valid_year (GDateYear year) G_GNUC_CONST;
gboolean g_date_valid_weekday (GDateWeekday weekday) G_GNUC_CONST;
gboolean g_date_valid_julian (guint32 julian_date) G_GNUC_CONST;
gboolean g_date_valid_dmy (GDateDay day,
GDateMonth month,
GDateYear year) G_GNUC_CONST;
GDateWeekday g_date_get_weekday (const GDate *date);
GDateMonth g_date_get_month (const GDate *date);
GDateYear g_date_get_year (const GDate *date);
GDateDay g_date_get_day (const GDate *date);
guint32 g_date_get_julian (const GDate *date);
guint g_date_get_day_of_year (const GDate *date);
/* First monday/sunday is the start of week 1; if we haven't reached
* that day, return 0. These are not ISO weeks of the year; that
* routine needs to be added.
* these functions return the number of weeks, starting on the
* corrsponding day
*/
guint g_date_get_monday_week_of_year (const GDate *date);
guint g_date_get_sunday_week_of_year (const GDate *date);
guint g_date_get_iso8601_week_of_year (const GDate *date);
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à -2.
Ton API, que le nom fasse 20 caracteres ou 2, ca ne change rien au code final(il est identique) et il est donc stupide de rendre la chose illisible.
XML par contre, la taille des balises influe sur le resultat final en terme de vitesse et espace.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 4.
Il est stupide aussi de rendre du xml illisible.
> XML par contre, la taille des balises influe sur le resultat final en terme de vitesse et espace.
Si XML est illisible, ça influe sur le développement (toujours avoir le nez dans la doc, problèmes de communication, etc...) et négativement.
Mauvais développement => mauvais programme => utilisateur pas content.
Et ne c'est pas les 0,2 % de gain en performance qui vont changer grand chose.
Quand tu codes, que t'utilises des noms cours ou des noms longs, la compilation n'est pas significativement plus courte ou plus longue.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à 1.
Ca influe legerement sur le developpement, ca influerait bcp si les gens lisaient constamment du XML, ce qui n'est pas du tout le cas vu qu'a 99% c'est des softs qui les lisent.
Les developpeurs que le tag soit < b> ou < bold> ils doivent se referer a la doc pour savoir exactement ce que le tag implique, bref, legere gene mais sans plus.
Quand tu codes, que t'utilises des noms cours ou des noms longs, la compilation n'est pas significativement plus courte ou plus longue.
Tout a fait, alors qu'avec XML c'est different, raison pour laquelle MS le fait.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 1.
Je ne sais pas comment tu fais pour être aussi "con" ou qu'elle force te pousse à être aussi "con".
<a>
<b>
<c>/schemas/desktop/gnome/applications/terminal/exec</c>
<d>/desktop/gnome/applications/terminal/exec</d>
<e>gnome-vfs</e>
<f>string</f>
<g>gnome-terminal</g>
<h i="C">
<j>Default terminal application</j>
<k>The default terminal application to use for applications that require a terminal.</k>
</h>
<h i="af">
<j>Verstekterminaaltoepassing</j>
<k>Die verstekterminaaltoepassing wat gebruik moet word vir toepassings wat 'n terminaal vereis.</k>
</h>
<h i="ar">
<j>ﺏﺮﻧﺎﻤﺟ ﺎﻠﺷﺎﺷﺓ ﺎﻠﻃﺮﻔﻳﺓ ﺍﻼﻔﺗﺭﺎﻀﻳ</j>
<k>ﺎﻠﺷﺎﺷﺓ ﺎﻠﻃﺮﻔﻳﺓ ﺍﻼﻔﺗﺭﺎﻀﻳﺓ ﺎﻠﺘﻳ ﺲﺘﺴﺘﻌﻤﻟ ﻼﻠﺘﻄﺒﻴﻗﺎﺗ ﺎﻠﺘﻳ ﺖﺘﻄﻠﺑ ﺵﺎﺷﺓ ﻁﺮﻔﻳﺓ.</k>
</h>
C'est illisible. Et encore ça pourrait être pire si le "mot clé" "string" je le remplace pas "s", etc...
Ça c'est lisible, t'as pratiquement pas besoin de la doc :
<schemalist>
<schema>
<key>/schemas/desktop/gnome/applications/terminal/exec</key>
<applyto>/desktop/gnome/applications/terminal/exec</applyto>
<owner>gnome-vfs</owner>
<type>string</type>
<default>gnome-terminal</default>
<locale name="C">
<short>Default terminal application</short>
<long>The default terminal application to use for applications that require a terminal.</long>
</locale>
<locale name="af">
<short>Verstekterminaaltoepassing</short>
<long>Die verstekterminaaltoepassing wat gebruik moet word vir toepassings wat 'n terminaal vereis.</long>
</locale>
<locale name="ar">
<short>ﺏﺮﻧﺎﻤﺟ ﺎﻠﺷﺎﺷﺓ ﺎﻠﻃﺮﻔﻳﺓ ﺍﻼﻔﺗﺭﺎﻀﻳ</short>
<long>ﺎﻠﺷﺎﺷﺓ ﺎﻠﻃﺮﻔﻳﺓ ﺍﻼﻔﺗﺭﺎﻀﻳﺓ ﺎﻠﺘﻳ ﺲﺘﺴﺘﻌﻤﻟ ﻼﻠﺘﻄﺒﻴﻗﺎﺗ ﺎﻠﺘﻳ ﺖﺘﻄﻠﺑ ﺵﺎﺷﺓ ﻁﺮﻔﻳﺓ.</long>
</locale>
Quand tu programmes, se rappeler de locale::long c'est 50 fois plus facile que h:k .
Si un mec te dit qu'il a un problème avec locale::long, tu comprends 50 fois plus vite ce que ça veut dire que s'il te dit qu'il a un problème avec h:k .
> Tout a fait, alors qu'avec XML c'est different
C'est ridicule. Quel gain ? T'as un bench ? On gagne combien ?
0,1 % au maximum sur une opération load/save.
[^] # Re: comparaison ODF et OpenXML
Posté par Pol' uX (site web personnel) . Évalué à 3.
Si le développeur doit passer par un moteur de recherche pour à chaque fois retrouver à quoi correspond quel mnémonique, on est pas rendu !
Et ça me fait bien rire que bricosoft (ou PbPg) parle d'optimisation à l'exécution ; c'est qui qui a pondu ce vloatware nommé Bista ?
Adhérer à l'April, ça vous tente ?
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à 0.
Le developpeur il passe par la doc, pas par un moteur de recherche, c'est a ca qu'elle sert.
Voir un tag qui s'appelle "bold" ne signifie rien, il faut lire la doc pour savoir exactement ce que ce tag fait, quels sont les effets de bord,... si tu te referes simplement au contenu XML tu ne fais rien d'autre que du reverse-engineering et c'est une maniere assuree d'avoir des bugs.
Quand aux performances, je dirais rien, je laisse les chiffres parler : http://blogs.zdnet.com/Ou/?p=120
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 3.
MS a des moyens délirants pour MS-Office. Rien à voir pour OOo.
Le jour où OOo sera aussi rapide que MS-Office, ce qui devrait tarder car OOo n'en est pas à la phase où l'optimisation est une priorité, ça ne sera sûrement pas car OOo aura adopté des tags de 2 caractères.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à 0.
Ah oui ? Alors en voyant ce XML t'es capable de deviner quels sont les attributs facultatifs de chaque tag ? T'es capable de deviner si tel tag peut etre reproduit plusieurs fois voir aucune ? ...
T'es fort, moi il me faut la doc pour ca.
Quand tu programmes, se rappeler de locale::long c'est 50 fois plus facile que h:k .
Non, parce que quand tu programmes t'as pas a te rappeler du texte "h:k" ou de "local:long", tu te rappelles du #define/const que tu lui a donne dans ton code.
C'est ridicule. Quel gain ? T'as un bench ? On gagne combien ?
0,1 % au maximum sur une opération load/save.
Ben tu y reflechis un peu, combien de temps il faut pour parser un fichier de 200'000 caracteres compare a un fichier de 40'000 ? Combien d'espace il faut pour stocker(selon la maniere dont le soft le fait, c'est dependant de ca et pas completement proportionel) 10 caracteres compare a 2 ?
[^] # Re: comparaison ODF et OpenXML
Posté par Pol' uX (site web personnel) . Évalué à 4.
Le reste c'est peanut.
Bon moi j'arrête, la mauvaise fois à la PbPg ça me gave.
Adhérer à l'April, ça vous tente ?
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à -1.
Quand a la mauvaise foi, t'es libre de me demontrer que les resultats du bench du dessous sont faux.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 3.
Le bench en dessous, ne montre absolument pas le gain d'avoir des symbols de 2 caractère au-lieu de 10.
Pour la place mémoire, si tu ne codes pas comme un porc, ça se joue à 10 voire grand maximum 50 ko de différence.
Sans intérêt.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 2.
Je n'ai jamais dit que les resultats sont faux mais que ta conclusion est fausse.
Tu dis que des tags courts sont indispensables pour des bonnes performances et je disait que pour parser les symbols long ça se fait en 1 ms pour un document de 200 ko (taille que tu as proposé).
Voilà un bench (vieux de 3 ans) :
http://xmlbench.sourceforge.net/results/benchmark200402/inde(...)
Il n'y a pas que la mesure du parsage des symbols. Et bien ça se joue à la milli-seconde.
NB : Les fichiers de test ont des tabs longs et pas des trucs de 2 caractères.
Donc pour gagner une seconde, il faut des documents de 200 Mo (dans cet ordre de grandeur).
Et encore, je le répète, il n'y a pas que la mesure de l'impacte de la taille des tags. Mais le bench est fait avec des tags "non optimisé à la OpenXML".
Notes aussi la consommation mémoire. Certaine librairie utilise manifestement une table de symbole. Donc la longue des tags à un impacte ridicule (quelques ko comme je l'ai déjà dit).
Bref, en rendant OpenXML illisible, OpenSML gagne au mieux 1 ms pour des documents de taille respectable (au moins 200 ko).
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à 1.
Si c'etait 1ms de difference ils se seraient pas emmerdes a le faire pour certains tags et pas d'autres, le truc c'est que eux ils profilent leur soft pour savoir ou est-ce que les couts CPU / RAM sont, raison pour laquelle ils ont fait ce changement entre le format XML d'Office 2003 et celui d'Office 2007.
[^] # Re: comparaison ODF et OpenXML
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à -1.
[^] # Re: comparaison ODF et OpenXML
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Je n'ai jamais regardé le code d'OpenOffice mais j'image qu'il parse le fichier odt via un parseur SAX et remplit sa structure interne. Avec la décompression à la volée, la différence entre un XML verbeux et un XML cryptique ne se voit qu'au chargement et à la sauvegarde du document.
Au final, avec un document de 200 pages contenant pas mal de photos, a mon avis, on blablate dans le vide...
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 1.
Il y a des éditeurs xml pour ça. Mais tu fais bien de rappeler que MS et les trucs lisible ça fait deux. D'où les gros blob dans OpenXML. Blob sans documentation...
Puis tu mélanges tout. Je n'ai jamais dit qu'une doc était inutile, j'ai dit qu'avec ton système il faut avoir tout le temps le nez dans la doc et ça pose des problèmes de communication.
> tu te rappelles du #define/const que tu lui a donne dans ton code.
Toi tu vas faire ton "wrapeur", un autre va en faire un autre, etc...
Je lis ton code, je dois lire tes #define, puis je dois lire la doc.
Super... Que du bonheur.
> il faut pour parser un fichier de 200'000 caracteres compare a un fichier de 40'000 ?
Aucune idée. 200 000 = 5 * 40 000, ça ne veut ABSOLUMENT pas dire que le "gros" fichier va prendre 5 fois plus de temps à traiter.
Si c'est pour le débit (lire les symbols et les comparer avec une table), ne t'inquiète il y a beaucoup de marge. Les cpu base de gamme d'aujourd'hui te bouffent du 1 Go/s les doigts dans le nez. Donc traitement des symbols du gros fichier en moins d'un millième de seconde sans problème. Oui oui.
Il faut que le fichier fasse plus de 200 Mo pour espérer gagner une seconde.
Optimisation totalement ridicule.
> Combien d'espace il faut pour stocker(selon la maniere dont le soft le fait, c'est dependant de ca et pas completement proportionel) 10 caracteres compare a 2 ?
Mémoire vive : il y a une table de symbol et des pointeurs.
Combien de symbol il y a ?
Imaginons 2000 pour ODF, voyons large.
2000*10 = 20 ko.
2000*2 = 4 ko.
Bravo, tu as gagné 16 ko (et j'ai la gentillesse de considérer qu'il y a autant de symbol dans OpenXML).
Pour info, combien de mémoire recommende Vista ?
1 ou 2 Go ?
Sur disque, il n'y a pas de problème puisque c'est compressé. M'enfin, on va dire que ça ajoute 20 ko pour être gentil.
> Quand aux performances, je dirais rien, je laisse les chiffres parler : http://blogs.zdnet.com/Ou/?p=120
Et tout ça cas il y a des symbols de 2 caractères au-lieu de 10.
Tu insultes mon intelligence.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à 0.
Des editeurs XML pour quoi ? Pour developper un soft ? Tu me fais bien rire.
Toi tu vas faire ton "wrapeur", un autre va en faire un autre, etc...
Je lis ton code, je dois lire tes #define, puis je dois lire la doc.
Super... Que du bonheur.
Que ton tag soit < bold> ou < b> c'est du pareil au meme, tu vas pas t'amuser a mettre en dur "bold" partout dans ton code ou bien ?
Aucune idée. 200 000 = 5 * 40 000, ça ne veut ABSOLUMENT pas dire que le "gros" fichier va prendre 5 fois plus de temps à traiter.
Si c'est pour le débit (lire les symbols et les comparer avec une table), ne t'inquiète il y a beaucoup de marge. Les cpu base de gamme d'aujourd'hui te bouffent du 1 Go/s les doigts dans le nez. Donc traitement des symbols du gros fichier en moins d'un millième de seconde sans problème. Oui oui.
Wow, t'arrives a parser, valider et representer un fichier ODF de 200Ko en moins d'un millieme de seconde ? Tu devrais penser a aider OOo alors, parce qu'ils ont des problemes de ce cote la.
Mémoire vive : il y a une table de symbol et des pointeurs.
Combien de symbol il y a ?
Imaginons 2000 pour ODF, voyons large.
2000*10 = 20 ko.
2000*2 = 4 ko.
Ah si seulement c'etait si simple qu'une table de symbols et pointeurs...
Et tout ça cas il y a des symbols de 2 caractères au-lieu de 10.
Tu insultes mon intelligence.
Certainement pas, par contre il y a de quoi se demander pourquoi OOo prend 7x plus de temps qu'Office 2003 pour charger un fichier quasi-identique tu crois pas ?
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 4.
Si je veux dire "bold", je vais mettre "bold". Point barre.
> Wow, t'arrives a parser, valider et representer un fichier ODF de 200Ko en moins d'un millieme de seconde ?
T'es con ou tu le fais exprès ?
Je parle du coût d'avoir des symbols long au-lieu de symbols cours. Parser un fichier xml, même si les symbols sont longs, le temps passer à lire les symbols et les comparer à une table est ridicule.
> Tu devrais penser a aider OOo alors, parce qu'ils ont des problemes de ce cote la.
Quel problème ? Des problèmes de symbol long ?
Tu fais une affirmation gratuite.
> Ah si seulement c'etait si simple qu'une table de symbols et pointeurs...
Il y a forcément une table des symbols avec OpenXML :
- a
- b
- ...
Il y a une table des symbols avec ODF :
- blablabla
- claclacla
- pliplipli
La longueur des symbols ne va jouer qu'ici. Si un symbol est répété 5000 fois, il est claire qu'on ne va pas le recopier 5000 fois mais le référencer 5000 fois. Idem pour OpenXML (sinon malloc, fragmentation mémoire, etc...).
> Certainement pas, par contre il y a de quoi se demander pourquoi OOo prend 7x plus de temps qu'Office 2003 pour charger un fichier quasi-identique tu crois pas ?
Oui. Mais la longueur des symbols doit avoir un impact insignifiant.
Tu crois qu'avec :
<t b=0 c=0 p=4>
au lieu de :
<table border=0 cellspacing=0 cellpadding=4>
ça va accélérer le traitement des pages html ?
N'importe quoi.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à 0.
C'est genial, t'es en train de me dire que le jour ou cette partie de texte devra changer tu devras t'amuser a tout changer plutot que changer un unique #define/const ? T'as des techniques de programmation geniales.
Je parle du coût d'avoir des symbols long au-lieu de symbols cours. Parser un fichier xml, même si les symbols sont longs, le temps passer à lire les symbols et les comparer à une table est ridicule.
http://blogs.msdn.com/brian_jones/archive/2006/10/26/perform(...)
The simplest way to see the impact for yourself is to just take an application like OpenOffice, and get a decent sized spreadsheet (I took a file with just one worksheet, that was 15 columns by 15,000 rows). Save it in ODF and make 2 copies. In one of the copies open content.xml and change some of the namespace prefixes to make them much longer. I aimed to make it so that the resulting content.xml file was about 3 times larger than the original since this helps replicate the size difference you would see if we changed SpreadsheetML so that it's tag length was longer and more descriptive like ODF (it would probably be more than that, but I found that making content.xml 3 times larger was more than enough to get a noticable slowdown in load times). I used namespace prefix approach because it's the easiest way to replicate the effect of a larger element name without changing the actual element names (since that would prevent the file from being readable by OpenOffice). In my test, by essentially tripling the size of the element names, I found that the file went from loading in about 9 seconds to taking about 11 seconds.
Voila, je te proposes de faire l'essai toi meme...
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 2.
On sent que tu as la culture microsoft.
Si c'est un standard, ça ne change pas !
Ou alors hypra rarement.
M'enfin, tu nous montres que MS prévoit tout pour modifier ses """standards""".
> In my test, by essentially tripling the size of the element names, I found that the file went from loading in about 9 seconds to taking about 11 seconds.
Et ben ce n'est pas optimisé, c'est tout. Je n'ai jamais dit que OOo était optimisé. J'ai dit que pour OOo l'optimisation n'était pas de ses priorité actuellement.
> Voila, je te proposes de faire l'essai toi meme...
Fais l'essai avec OpenXML/MS-Office et montre que c'est un drame au niveau performance. Là tu nous prouveras quelque chose, puisque l'optimisation est un objectif de MS-Office selon toi.
Je suis percuadé qu'OOo optimisera tout ça en temps utile. Et ce jour là, qu'es-ce que tu va nous inventer pour proner les formats illisibles ?
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à 1.
Tu commences par nous dire que le parsing n'a aucune influence sur le chargement, et quand je te montres le contraire preuve a l'appui tu viens nous sortir que c'est "parce que c'est pas optimise", faut te decider mon cher, et penser a arreter de me traiter de "con" et "mauvaise foi" alors que j'ai raison.
Fais l'essai avec OpenXML/MS-Office et montre que c'est un drame au niveau performance. Là tu nous prouveras quelque chose, puisque l'optimisation est un objectif de MS-Office selon toi.
Moi je te propose de lire le blog de Brian Jones plus regulierement, la tu y apprendras notamment que :
a) Les tags qui sont rarement presents dans le format sont long, car ca n'aura aucun impact sur les perfs
b) Office 2003 avait un format avec des tags longs, et il etait lent a charger les fichiers, raison pour laquelle ils ont change ca pour OpenXML
Je suis percuadé qu'OOo optimisera tout ça en temps utile. Et ce jour là, qu'es-ce que tu va nous inventer pour proner les formats illisibles ?
Ouais, ils vont optimiser en sortant ODF 2.0 qui aura des tags de 1-2 caracteres, et apres ca on rigolera bien.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 2.
Tu en fais le pari ?
Prouve tes convictions.
Je fais le pari qu'il n'y aura pas de mini-tags.
[^] # Re: comparaison ODF et OpenXML
Posté par Joël SCHAAL . Évalué à 1.
Et c'est exactement ce que tout le monde ici dit. Prendre des noms de balises longues sera évidemment plus long à traiter, mais cette différence devient négligeable quand on tient compte de tout le processus de chargement.
On ne saura pas exactement le coût que peux avoir des noms de balises et d'attributs longs sans développer une appli de test qui se chargera de lire les 2 formats différents de la même manière.
J'aimerais aussi connaitre ton point de vue sur la présence des blobs dans un standard dit "ouvert". Dans quelle documentation pourra-t-on aller rechercher les informations qui nous manquent ?...
[^] # Re: comparaison ODF et OpenXML
Posté par Guillaume Rossignol . Évalué à 3.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à -1.
Ben justement si, si tu prends la meme app, et tu charges le meme fichier, mais une fois avec des tags longs et une fois avec des tags courts(en changeant le nom du namespace tout simplement), tu as la reponse.
J'aimerais aussi connaitre ton point de vue sur la présence des blobs dans un standard dit "ouvert". Dans quelle documentation pourra-t-on aller rechercher les informations qui nous manquent ?...
Ben la question est: quels sont donc ces blobs inconnus sans documentation ? Qu'il y ait des blobs je veux bien, que leur contenu soit totalement inconnu j'y crois bcp moins.
Genre WMF dont les gens disent qu'il n'est pas documente, ben ... http://www.faqs.org/faqs/graphics/fileformats-faq/part3/sect(...)
The Microsoft Knowledge Base (available at ftp://ftp.microsoft.com/kb/ and on the Microsoft Developer Network CD) also contains the complete specification of WMF.
[^] # Re: comparaison ODF et OpenXML
Posté par Nelis (site web personnel) . Évalué à 4.
Ou ils ont choisi l'XML juste pour faire hype ?
[^] # Re: comparaison ODF et OpenXML
Posté par Anonyme . Évalué à 2.
Non, simplement parce que bon nombre d'administrations sont en train de comprendre les avantages des formats ouverts et les imposent progressivement. Ils essayent de rester dans la course.
Après à nous de communiquer pour faire comprendre que l'OpenXML n'est pas le meilleur choix.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à 1.
C'est ca l'avantage d'XML, et c'est pour ca qu'il est utilise, mais ca n'a jamais ete prevu pour etre un format modifiable par un humain.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 2.
Ben si. Ce qui ne veut pas dire que c'est pertinent de le faire.
Par contre ce qui est créé/modifié à la main doit être contrôlé (si on ne fait pas les choses comme un porc, c'est très facilement faisable).
Tu oublies aussi par exemple les scripts php/etc qui générent du xml quasiment à la main.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 4.
http://www.w3.org/TR/2006/REC-xml-20060816/
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à -2.
Alors apres on peut rendre son format arbitrairement gros pour satisfaire 0.1% des gens, mais c'est legerement inutile et a un impact negatif(temps de chargement,...) sur 99.9% des gens,
[^] # Re: comparaison ODF et OpenXML
Posté par Drakho . Évalué à 5.
C'est ce qui nous a apporté un defragmenteur de disque pour la FAT, des incompatibilités chroniques entres différentes versions d'une application (Word, par exemple) et tant d'autres trucs bien rigolos :D
En théorie, si on code proprement, ça a plus de chances de tomber en marche... mais bon... "la théorie, on s'en fout" =)
Je sors [ ] :D
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 2.
C'est comique.
MS fait des trucs illisible et en plus MS ne fournit pas la doc :
http://reddevnews.com/news/devnews/article.aspx?editorialsid(...)
Et après tu nous fais du pipo.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à 0.
Comme je l'ai dit et repete, c'est une _legere_ gene. Mais visiblement tu es incapable de comprendre que quand on developpe un parser pour un format, on doit lire la doc de toute facon histoire de comprendre les subtilites, et que quand on code on ne le fait pas un porc en mettant en dur le texte partout mais en utilisant un #define/const avec la valeur definie en un endroit unique.
Quand a ton lien c'est du n'importe quoi, il s'agit de nouveaux softs, donc nouveaux protocols, donc ajoutes a la liste des protocoles sous licence, rien de bien nouveau.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . Évalué à 2.
C'est un STANDARD !
Tu fais de même avec les fonctions de l'api Windows ?
#define crer_fenetre CreateWindow
main(...)
creer_fenetre(...)
Ne soit pas ridicule.
> Quand a ton lien c'est du n'importe quoi, il s'agit de nouveaux softs, donc nouveaux protocols
Et alors ?
> rien de bien nouveau.
C'est clair, c'est le proces MS/UE qui continu. Rien de nouveau, MS se comporte comme un porc.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à 1.
Tu fais de même avec les fonctions de l'api Windows ?
#define crer_fenetre CreateWindow
main(...)
creer_fenetre(...)
On parle de texte, donnees qui viennent de l'exterieur. Genre pour XML t'as typiquement le nom du schema suivi du nom du tag (bob:michu), tu vas t'amuser la aussi a mettre en dur "bob:michu" ? ou bien tu vas faire la chose intelligente et mettre des variables/const ?
Parce que si tu mets ca en dur mon cher, t'as pas un parser valide.
Ton fichier XML il peut avoir des noms de schema redefinis et il sera toujours un fichier ODF valide, mais ca visiblement tu ne l'as pas compris(c'est exactement ce qui permet a Brian Jones de changer la taille des tags dans le fichier).
Bref, tu es sympa, mais avant de dire aux gens qu'ils sont ridicules, de sortir des conneries sur MS qui ferait ca car ils aiment changer les standards, ... je te propose d'aller prendre qqe cours de programmation et apprendre a faire les choses proprement.
Ca t'apprendra notamment a faire un parser qui fonctionne plutot qu'un parser qui ne lit que des fichiers avec un nom de schema predefini en dur a 403 endroits differents dans ton code.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à 0.
[^] # Re: comparaison ODF et OpenXML
Posté par Nelis (site web personnel) . Évalué à 6.
Maintenant arrête ta mauvaise foi, tu n'es pas obligé de te ridiculiser pour essayer de défendre MS à tous les coups. Répète après moi : à part rendre le format plus obscur, il n'y a aucun intérêt à réduire le nom d'un tag XML.
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à -1.
Tu auras aussi l'info que les tags rarement presents ont des noms long, justement car leur rarete fait que cela n'influe pas sur les perfs.
[^] # Re: comparaison ODF et OpenXML
Posté par Pol' uX (site web personnel) . Évalué à 5.
De plus, penser que des balises plus courtes feront des fichiers plus légers est un leurre. Si la balise apparaît un nombre suffisant de fois dans le document, les codages entropiques se feront une joie de compresser ça, par exemple zip pour l'ODF.
Adhérer à l'April, ça vous tente ?
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . Évalué à -1.
Pour la compression c'est en partie vrai, par contre au parsing ton parser devra se taper toute la balise, et la avoir une petite balise accelere les choses.
# Je profite de ce journal...
Posté par euroxers (site web personnel) . Évalué à 2.
[^] # Re: Je profite de ce journal...
Posté par Pol' uX (site web personnel) . Évalué à 5.
L'interopérabilité nécessite :
* Un format stable
* Une documentation précise, et accessible sans condition particulières, avec des coût d'accès limités aux seuls coûts administratifs
* Une permission de réutilisabilité du format sans contrainte, i.e. pas de brevets, ou de NDA ...
Dans le cas d'un logiciel "ouvert", l'accès au source peux te fournir un semblant de documentation, mais quid des conditions d'accès ? Quid des conditions de réutilisabilité ?
De plus, il est important de souligner que l'interopérabilité n'est possible qu'avec un format stable, et donc les décisions relatives à ce format doivent être mis dans les mains d'un consortium compétent. Pas d'un unique acteur capricieux (ni d'une masquarade de commission !)
C'est quand même impressionnant de voir que MS à pris tous ceux qu'il pouvait en levrette depuis plus de 10 ans, et qu'aujourd'hui, alors que les politiques ont l'occasion de faire un grand pas en avant, ils ont décidé d'avoir une curieuse amnésie.
Personnellement, depuis que j'ai découvert les formats ouvert et les logiciel libres, j'ai arrêté d'hurler sur mon ordinateur, et j'ai oublié les galères à répétition.
Adhérer à l'April, ça vous tente ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.