> t'es libre de me demontrer que les resultats du bench du dessous sont faux.
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é).
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).
> Et comment expliques tu le succes de la Wii dans ce cas ?
Je ne parle pas de succès ...
Je parle de faire un évènement avec une console de jeux. Certe la Wii a créé un évènement.
Mais c'est comme ça pour toute les nouvelles technologies qui ne le sont plus, elles ne créent plus l'évènement.
Dans l'automobile il n'y a plus d'évènement, ce qui n'empêche pas les succès et les échecs.
> 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 ?
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 ?
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.
> 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.
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.
> 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 ?
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.
> Quand a la mauvaise foi, t'es libre de me demontrer que les resultats du bench du dessous sont faux.
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.
> Ah oui ? Alors en voyant ce XML t'es capable de deviner quels sont les attributs facultatifs de chaque tag ?
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.
> 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.
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>
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 IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... É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: 00:01
Posté par IsNotGood . En réponse au journal 1er acheteur de la PS3.... Évalué à 2.
[^] # Re: Catastrophe
Posté par IsNotGood . En réponse au journal 1er acheteur de la PS3.... Évalué à -1.
Une console qui n'a aucune exclusivité et peu faire tourner tous les jeux a un gros avantage.
Tu ne crois pas ?
Et quel avantage ? Car la console serait meilleur ? C'est pûrement de la stratégie commerciale, de l'exercice monopolistique.
L'avantage du libre, c'est son absence d'exclusivité. Ce que tu trouves sur Bidule, tu le trouves sur Gnagna (pour peu qu'il s'en donne la peine).
L'exclusivité c'est mal™.
[^] # Re: 00:01
Posté par IsNotGood . En réponse au journal 1er acheteur de la PS3.... Évalué à 7.
[^] # Re: Catastrophe
Posté par IsNotGood . En réponse au journal 1er acheteur de la PS3.... Évalué à 2.
Glorifions l'exclusivité.
Ce mois ci, en exclusivité pour Windows : DRM !
Youpi !!!
[^] # Re: Catastrophe
Posté par IsNotGood . En réponse au journal 1er acheteur de la PS3.... Évalué à 4.
Je ne parle pas de succès ...
Je parle de faire un évènement avec une console de jeux. Certe la Wii a créé un évènement.
Mais c'est comme ça pour toute les nouvelles technologies qui ne le sont plus, elles ne créent plus l'évènement.
Dans l'automobile il n'y a plus d'évènement, ce qui n'empêche pas les succès et les échecs.
> Faut vraiment avoir de la merde dans les yeux
Je n'ai jamais dit que la PS3 était un succès.
# Catastrophe
Posté par IsNotGood . En réponse au journal 1er acheteur de la PS3.... Évalué à 1.
La prochaine XBox 3600 ne fera pas mieux.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... Évalué à 2.
Tu en fais le pari ?
Prouve tes convictions.
Je fais le pari qu'il n'y aura pas de mini-tags.
[^] # Re: Mise à jour automatique du noyau
Posté par IsNotGood . En réponse au journal Cooker ; The Inside Man VI ( version française ). Évalué à 1.
A : fait un truc scandaleux mais prépare le terrain en disant qu'il n'y a que les cons pour trouver ça scandaleux
B : gueule au scandale
A : ben vous voyez.
C'est une tactique politicienne de base.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... É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 IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... É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 IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... É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: Mise à jour automatique du noyau
Posté par IsNotGood . En réponse au journal Cooker ; The Inside Man VI ( version française ). Évalué à -1.
[^] # Re: Parodie de Windows
Posté par IsNotGood . En réponse au journal Parodies des pubs Mac par Novell, le retour. Évalué à 2.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... É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: Parodie de Windows
Posté par IsNotGood . En réponse au journal Parodies des pubs Mac par Novell, le retour. Évalué à -5.
# Parodie de Windows
Posté par IsNotGood . En réponse au journal Parodies des pubs Mac par Novell, le retour. Évalué à -5.
Comme c'est étrange...
La prochaine étape est que Novell fasse des parodies de Linux.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... É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 IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... É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: Et Google ?
Posté par IsNotGood . En réponse au journal Microsoft , une entreprise franchement douteuse.. Évalué à 2.
http://www.live.com/
Merde, ça marche.
Ici on ne demande pas que les pro-libres qui configurent les proxy interdisent l'accès à http://www.live.com/
Ne mélanges pas tout.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... É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 . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... É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: Eté 2007 : il va faire chaud sous les trolls
Posté par IsNotGood . En réponse au journal KDE4.0 : Sortie prévue le 23 octobre !. Évalué à 2.
Et si je me trompe et qu'il sort avec KDE 4.0, ça ne va pas me déranger.
# Re:
Posté par IsNotGood . En réponse au journal Microsoft , une entreprise franchement douteuse.. Évalué à 3.
Dans quelques mois MS va donner du pognon aux entreprises qui virent Linux ou interdisent Firefox.
[^] # Re: comparaison ODF et OpenXML
Posté par IsNotGood . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... É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.