pasBill pasGates a écrit 16280 commentaires

Faudra expliquer ca a ma machine qui a tous les patchs et qui n'a pas IE7.

tu crois qu'il n'y a aucune contradiction ?

Bon je rephrase: si tu passes de monothread a multithread, tu ne verras aucune difference, car la lib multithread ne fait rien de moins ou moins bien que la monothread.

ah, l'argument historique, imparable. "bouh, z'êtes ringards !", aucune protestation possible. les gus qui en ont besoin, qui ont constaté des différences - ont dû être ravis d'être traités de dinosaures condammnés depuis longtemps

Si tu me donnes une difference ou la multithread se comporte differement de la monothread dans un environnement monothread, je serai ravi de ravaler mes paroles.

boom, voila, d'un coté ils te tartinent qu'il faut utiliser la version multithreaded et comment faire vroom vroom avec, et à coté ils te disent que certaines fonctions à la con (chiantes, connues comme telles depuis 20 ans et plus, comme strtok(), non réentrante) vont faire que des conneries avec le runtime multithread (divers programmes vont utiliser la même librairie et se marcher dessus via des variables statiques partagées d'un coup par tout le monde, une vraie tournante madame)

Il n'y a AUCUNE difference.

La lib monothread n'a strictement aucun avantage sur la lib multithread, c'etait une relique du passe.

Ton soft il est soit multithread soit non.

Si il l'est, tu utilises la CRT monothread, t'es dans la merde, tu utilises la CRTE multithread, tu l'es moins.
Si il ne l'est pas, quelque soit la lib utilisee, t'es tout bon.

Faut bien comprendre qu'une librairie elle a beau avoir des variables statiques, ces variables ne sont pas partagees par tous les processus, mais par tous les threads d'un meme processus. Il y a une copie differente par processus.

Si tu passes de monothread a multithread, _rien_ ne casse. La lib multithread fait des choses en plus et mieux, elle ne fait rien de moins ou moins bien.

Ah oui c'est vrai excusez-moi, l'explication du soi-disant probleme n'est absolument pas pertinente et merite d'etre cachee.

Par contre les aneries sur MS elles elles sont bien sur pertinentes.

Quel systeme de merde ces XP quand meme, ca permet a qqe attardes mentaux de jouer aux ayatollahs au detriment de tout le monde.

Je lui conseillerai d'ouvrir Explorer, d'aller dans \Windows\system32 , click droit sur command.com, aller dans la tab "memory" et changer les valeurs.

Mes 2 centimes suisses.

Cette soif de monopole qui s'étend maintenant à tous les domaines liés au multimédia, oui ça me glace...

La seule difference entre MS et les autres, c'est que MS a reussi, mais faut arreter de rever, ils(entreprises) veulent tous la meme chose.

Et que dire de cette politique de dénigrement outrancière qui vise à lacher des FUDs sur le dos des concurrents sachant que ça sera relayé par la presse spécialisée (laquelle vit grace aux annonceurs, dois-je le rappeler?).

C'est vrai tiens, il n'y a bien que MS qui fasse du FUD, les autres n'en font ABSOLUMENT pas...

A ce sujet, j'espère qu'ils donneront suite à cette fameuse histoire de vol de brevets...

Quel vol de brevet ? Alcatel / Lucent ? MS a paye le fraunhofer institute, comme tout le monde. Si MS perd la dessus, tous ceux qui utilisent mp3 tomberont dans le meme bateau.

De la part d'un mastodonte comme Microsoft on est en droit d'attendre un minimum de fair-play et de respect... C'est mon avis, qu'il te plaise ou pas.

T'es libre d'avoir ton avis, mais faudrait simplement penser a traiter tout le monde de la meme maniere et realiser que les autres societes sont loin d'etre toutes blanches aussi.

J'avais lu il y a quelques mois (fin 2006) un article qui donnait une liste non exhaustive des bugs considérés non critiques par Microsoft (et toujours pas corrigés)...

Si ce sont des failles de securite et elles sont serieuses, elles seront corrigees, si ce ne sont pas des problemes de securite, faut vraiment que ce soit un reel probleme, on parle d'un OS qui a 7 ans quand meme.

De plus, cette fameuse maintenance gratuite elle va durer encore combien de temps ? Qui dit que dans 6 mois ou 12 mois vous continuerez a fournir gracieusement des correctifs pour d'eventuelles failles dites critiques ?

On fait pas les choses au hasard, les durees de support sont definies a l'avance : http://support.microsoft.com/lifecycle/?p1=3071

Pour Windows 2000, les patchs de securite sont gratuit jusqu'en en 2010

Maintenant trouves moi une distrib qui donne 10 ans de support...

Je ne voudrais pas troller mais cette pratique, on la retrouve chez les pourvoyeurs de drogue... un échantillon gratuit pour commencer... après, tu vois. La façon de faire est habile ou immonde selon qu'on est commercial aux dents longues ou consommateur.

Ah ouais tiens, un peu comme les distrib Linux gratuites quoi, mais evidemment quand c'est MS c'est Mal(TM) et quand c'est du Linux c'est de la charite chretienne. Je connais l'histoire.

Les failles de securite pour Win2k on les corrige toujours et les patchs de securite sont dispo gratos sur le site de MS.

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.

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.

Il n'y a pas bcp de gens qui se plaignent de la qualite de la distrib en elle-meme(a part les trolls habituels bien sur), la plainte c'est sur tout le cote management /vente de Mandriva. C'est une boite qui ne sait pas vendre ni marketer ses produits et a encore moins de qualite quand il s'agit de s'addresser a des grands comptes du fait de leur profile, et qui se plaint apres qu'on n'achete pas chez elle.

La plupart ici seraient ravi qu'ils gagnent de l'argent, c'est bien le probleme. Ils sont pas foutus d'en gagner alors qu'ils ont un produit qui devrait pouvoir leur ramener un minimum.

Les américains savent très bien, eux, que Microsoft est une boîte américaine, même si IE7 est conçu en Inde et que les actionnaires sont internationaux

J'ai un pote qui va pas etre content d'apprendre qu'il a subitement demenage de Seattle a Dehli sans le savoir.

Quand a Mandriva, le jour ou ils se sortiront les pouces du c*l et qu'ils feront les choses correctement, je compatirais, d'ici la ils ne font rien d'autre que donner l'image d'une societe totalement incapable de communiquer dans le monde de l'entreprise et donc incapable de gagner le moindre marche.

Ce que tu oublie c'est que OOo / Office ils ne font pas que charger un fichier dans un parser XML et le jeter, ils le parcourent aussi en jetant un oeil aux tags, le blog de Brian Jones l'explique assez clairement.

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.

Tu lis plus haut et tu auras la preuve par les faits(reproduisible par toi meme) que la taille des tags ralentit la sauvegarde/chargement.

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.

Et je passes sur le fait que si tu t'amuses a mettre le meme texte en dur partout dans ton code, tu t'exposes a la possibilite d'oublier/ajouter un caractere dans qqe uns de ces endroits ce qui ne se verrait pas et finirait en bug bien dur a trouver, chose impossible si la valeur etait stockee dans une variable/un const car le compilo t'avertirais que le nom de variable est inconnu

C'est un STANDARD !
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.

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.

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.

waitpid te permet d'attendre jusqu'a ce qu'un processus fils se termine.

Il te suffit d'ecrire un petit soft qui lance lui-meme les commandes que tu veux, et qui attend avec waitpid, des qu'un des fils meure tu reprends la main et tu tues tout ce qui reste.

Tu essaies d'expliquer que MS a "sacrifié" ses développeurs pour le bien des utilisateurs ?

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.

Si je veux dire "bold", je vais mettre "bold". Point barre.

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

En tout cas c'est un peu comme la logique d'inciter les éditeurs de jeux à utiliser directx pour la 3D au lieu d'opengl, comme la logique d'inciter les webmestres à utiliser du code html compatible uniquement IE et hors des standards w3c, comme d'utiliser les formats ms office au lieu du format opendocument etc

Ah oui ? Google c'est un standard ? J'etais pas au courant...

Remarque, OpenGL c'est pas vraiment un standard non plus, pas ISO, pas ECMA, pas IEEE, ... quand a OpenDocument, c'est pas plus un standard que OpenXML alors bon si la critique c'est que MS essaie de vendre son truc plutot que celui du voisin, c'est un peu normal je te dirais...

Et tu as vu ou que MS demande d'interdire Google ?

Non pas que je trouve le procede intelligent, bien au contraire, mais MS ne demande pas d'interdire les autres moteurs de recherche.

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

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 ?

On parle en RAM, pas sur disque, avec les disques de 200Go d'aujourd'hui 1Mo de plus ou de moins est ridicule.

Le parsing du XML lui-meme oui, mais un traitement de texte ca fait legerement plus que charger un fichier XML dans un parser, il doit traverser le contenu pour l'interpreter aussi mon cher.

Quand a la mauvaise foi, t'es libre de me demontrer que les resultats du bench du dessous sont faux.

Ça c'est lisible, t'as pratiquement pas besoin de la doc :

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 ?