Si tu (ou un autre) veux reprendre le journal et en faire une news, t'es libre.
Je te demande qu'un petit truc (mais tu n'es pas obligé de le respecter) :
- si tu fais une modification et me cite en même temps (genre "fabb nous apprend que ...") mets un lien sur ce journal.
Donc, tant que tu ne me cite pas, tu fais ce que tu veux.
Affirmes l'inverse si tu veux. Mais avances quelques arguments comme des exemples concrèts.
Je ne connais pas de cas qui ont posé problème.
Exemple, le protocole utilisé par le service rhn de Red Hat n'est pas documenté. Or il y a les sources du client (up2date). Avec ça il y a eu des serveurs compatible avec up2date et sans grande difficulté.
> Un peu d'histoire informatique ne te ferait pas de mal je pense.
Un cerveau ne te ferait pas de mal je pense.
> A cette epoque, un des OS les plus "frequent" c'etait CP/M, pas Unix
Où ça ? À la maison ?
Quand ? durant la courte période où CP/M était en vogue ?
Tu peux aussi parler du TO7. Il était très populaire à une époque.
> Et ? Il y a un standard qui dit que c'est inacceptable ?
Le standard html ne dit pas que c'est inacceptable de ne pas suivre le standard html, mais il n'empêche que le non respect des standards par IE est inacceptable.
Oui ou non ?
> On n'a plus le droit de faire quoi que ce soit sans qu'il y ait un standard qqe part ?
Sauf qu'après il faut faire des clients ftp avec les options "binary" et "ascii" par exemple.
Qu'il faut ajoute l'option 'b' à fopen() pour la libc (une librairie *starndard*) pour faire plaisir à MS (man fopen) :
- "Le ‘‘b’’ est ignoré sur tous les systèmes compatibles POSIX, y compris Linux. (D’autres systèmes peuvent traiter les fichiers de texte et les fichiers binaires différement, et l’ajout du ‘‘b’’ peut être une bonne idée si vous faites des entrées-sorties binaires et que votre programme risque d’être porté sur un environnement non-Unix)."
Pourquoi ?
Pour rien. Le seul truc "positif" c'est lorsque tu faisais un "type program.exe" il affichait quelque chose comme "MS-Dos Program" puis quittait.
Toi tu vois une inovation là dedans, moi j'ai vois une incompatibilité gratuite.
> Quand a etre une horreur, il n'y aurait pas eu le mot MS accroche a ca ca t'aurais passe sous le nez, ah les tetes de turc...
Tu joues le rôle de la victime ? Tu vas nous développer la théorie du complot anti-MS ?
Tu devrais aller lire les liens de la news.
MS a aussi fait son kerberos à lui tout seul qui marche avec personne d'autre. Encore une incompatibilité qui ne sert à rien et "comme par hazard", c'est mal documenté. C'est le team samba qui apprécier (encore). Quand MS utilise un standard, il utilise "le standard selon MS et sans documenter" et pas le standard.
Je parle d'incompatibilités gratuites. Je ne parle pas des innovations MS (comme OLE2, etc).
Il n'est pas nécessaire de créer des incompatibilités, de polluer des standards, pour innover.
Si MS veut son propre HTML, il fait le ms-html avec les entêtes qui vont bien. Mais MS n'a pas à polluer l'html standard.
Quand Mozilla fait un rendu qui ne respecte pas la norme, c'est une erreur, un bug. Mais quand IE fait une erreur de rendu, c'est très très souvent une incompatibilité gratuite qu'a créé MS car MS ne veut pas corriger IE et respecter les standards (sinon ça serait fait depuis longtemps). """grace""" à IE, il faut deux moteurs pour parser l'html dans mozilla. Par exemple : http://www.microsoft.com/(...) utilise "Quirks mode" http://linuxfr.org/(...) utilise "Standards compliance mode"
Le logiciel libre innove et il n'y a pas de d'incompatibilité, de standards qui sont pollués. Je ne dis pas que ça n'arrive jamais avec le libre mais que ça arrive "seulement" 100 ou 1 000 fois moins que sous Windows :-)
> Oh ca oui je sais, le moindre truc que MS fait de travers ou de different il est remarquable pour vous et vous en profitez pour hurler vos frustrations, tout le reste vous oubliez comme par hasard.
Imaginons. Toi t'as à l'opposé, tu fais amen à toutes les actions de MS, donc ça équilibre.
PS : oui je sais, netscape 4.x était aussi une horreur en terme de respect des standards.
> Pour faire de l'interop tout le monde est sense suivre le format Unix qui n'est qu'un des nombreux OS disponibles ? C'est nouveau ca, j'etais pas au courant.
Il sagit de ne pas ajouter des incompatibilités pour rien. Au début de MS-DOS, MS-DOS était "rien" en part de marché (par définition).
> En passant, tu devrais jeter un oeil a ASCII, tu serais des lors surpris de voir qui c'est qui n'a pas respecte le standard en n'utilisant pas crlf pour un retour au debut de la ligne suivante.
Zut, pour une fois que MS suit un standard.
MS a aussi inventé les fichiers "texte" et les fichiers "binaire". Plus précisément, je ne sais pas si c'est MS qui a inventé ce truc, mais j'ai vu cette horreur que sous Windows (d'où le caractère EOF (je dis bien "caractère" et pas entier) qui n'existe dans aucun standard).
Enfin, on n'a pas à démontrer que MS est la société qui respecte le moins les standards et qui ajoute le plus d'incompatibilité pour rien. Si tu en doutes, regarde du côté de IE.
Ce n'est pas spécifique à MS, les Unix l'ont fait aussi. Mais c'est particulièrement remarquable chez MS.
> Non, l'ouverture d'un code source n'est pas une garanti d'interopérabilité.
Si tu as les sources, tu as l'interopérabilité. Après que les gens n'est pas envis ou les compétences de lire les sources est une autres histoire et se sont de cas très rare (s'ils existent). Je peux te garantir que samba serait très satisfait de n'avoir "que" les sources.
Si on prolonge ton raisonnement, on peut aussi dire que d'avoir la doc sur le format (par exemple html sur w3c) n'est pas une garantie d'interopérabilité. D'où IE par exemple qui n'est pas un modèle d'intéropérabilité et lit mal l'html alors que le format est parfaitement documenté.
Faut pas si tromper, c'est car le logiciel libre (via mozilla, openoffice, gnu/linux) commence à poser un sérieux problème à MS.
La concurrence à du bon.
Ou tout simplement car l'Europe l'a exigé de Microsoft. Là MS prend de l'avance et veux nous faire croire qu'ils sont des ""anges"" et non qu'ils plient suite à un procès entre l'Europe et MS.
Wait and see car MS n'a jamais été un modèle dans ce domaine et ce depuis ses débuts (séparateur de path '\' au-lieu de '/', <cr><lf>, etc).
Mais comme d'habitude MS nous fait un peu de FUD anti-open-source (du mail de bilou) : Sometimes interoperability is also confused with open source software. Interoperability is about how different software systems work together. Open source is a methodology for licensing and/or developing software – that may or may not be interoperable. Additionally, the open source development approach encourages the creation of many permutations of the same type of software application, which could add implementation and testing overhead to interoperability efforts.
La disponibilité des sources est une garantie d'intéropérabilité (ça évite de faire de l'ingénierie à rebour par exemple, ce qui est laborieux, interdit au US, et aux résultats hazardeux).
> Moi non plus je ne vais pas y passer des plombes.
> TOUS les MySQL 4.0.X et les MySQL 4.1.Y avec Y < 8 utiliseront Linuxthreads par défaut si il est disponible.
Sous RH et FC il y a nptl *ET* linuxthread. L'appli qui veut linuxthread doit être linké à /lib/i686 (ou autre) mais pas à /lib/tls/libpthread.so. MySQL fait de lui même le choix d'utiliser nptl s'il est présent.
Ce que tu ne veux pas comprendre, est que nptl est compatible linuxthread (sauf quelques cas particulier) et donc ont peut avoir un code fait pour linuxthread qui marche avec nptl. C'est ce qui se passe avec *plein* *plein* *plein* d'applis et aussi avec mysql.
Je répète, mysql est codé ala linuxthread mais utilise nptl.
> Pour X<23 MySQL 4.0.X ne compilera même pas.
Je n'ai jamais dit le contraire. Relis le thread. Je dis qu'il est codé en utilisant les entêtes linuxthread mais qu'il utilise l'implémentation des thread nptl.
C'est comme Gtk. Ton applis peut nécessiter les entêtes Gtk+ 2.0 et ne pas compiler avec Gtk+ 2.6 mais elle peut utiliser gtk+ 2.6 (la librairie binaire, avec un file selector "mignon", etc) et dans ce cas, je dis que l'applis utilise gtk+ 2.6 pour la simple raison qu'elle utilise gtk+ 2.6.
Si tu ne comprends pas ça, je n'y peux rien.
> Je parle des MySQL vanilla, à savoir le code source tel qui est fourni par MySQL sur le site MySQL.
Moi aussi (et ./configure n'utilise pas "--with-pthread"). Ici, mysql utilise nptl et est compilé avec les entêtes de linuxthread.
> Donne moi une raison valable, une seule ça me suffit, pour que MySQL sur une émulation de thread Linuxthread sur les threads posix sur les threads Natifs BSD soit plus rapide que MySQL directement sur les threads natifs BSD. Bonne chance.
J'ai aucune raison à donner. Mais ce n'est pas une émulation de linuxthread, c'est linuxthread. C'est différent.
Le bench, même s'il ne donne pas de raison, montre que Mysql est plus lent avec l'implémentation native qu'avec linuxthread. Point final.
Maintenant soit tu remets en cause l'intégrité du test en refaisant les tests, soit tu considères que MySQL est mal codé lorsqu'il utilise l'implémentation native, soit tu considères que l'implémentation *BSD est plus lente que linuxthread.
> Hint : Les locks et les unlocks de mutexs sont des appels système qui se font forcément en natif.
Et alors ?
C'est toi qui dit que le problême est autour des mutex. Moi, je n'en sais rien. Je constate seulement que c'est plus rapide avec linuxthread.
Je vais pas y passer des plombes mais même mysql 3 (fournis par Red Hat ou Fedora) utilise nptl (linké avec nptl). Il n'y a pas de patch spécifique pour ça.
> MySQL uses LinuxThreads on Linux. If you are using an old Linux version that doesn't have glibc2, you must install LinuxThreads before trying to compile MySQL.
Car il n'y a pas de thread du tout pour glibc < 2 et que d'ailleur il n'y a que Linux 2.6 qui fourni des fonctionnalités pour les threads. Les linux plus anciens s'appuient sur clone() et le reste est fait en userland.
> le testeur démontre avec brio que
Que MySQL sous *BSD est plus lent que MySQL sous Linux.
Pourquoi ?
Certains pensent car c'est à cause de *BSD et d'autres (toi ?) pensent que MySQL est codé avec les pieds pour le port BSD.
Dans 99 % des cas, c'est /usr/include/pthread.h qui est utilisé.
linuxthread est une implémentation de la norme Posix 1003.1c : http://pauillac.inria.fr/~xleroy/linuxthreads/(...)
et jouer avec ce qui est spécifique à linuxthread ou nptl est rare.
> On retrouve pas mal de rapprots de bugs sur NPTL, notamment dans les forums Debian,
Sous Red Hat/Fedora et depuis RH9 nptl est utilisé par défaut : http://fr2.rpmfind.net/linux/redhat/9/en/os/i386/RELEASE-NOTES.html(...) This thread library is designed to be binary compatible with the old LinuxThreads implementation; however, applications that rely on the places where the LinuxThreads implementation deviates from the POSIX standard will need to be fixed
Donc, comme je le supposais plus haut, nptl est compatible linuxthread.
Il n'y a que deux façon d'utiliser linuxthread avec RH9 ou > :
- linker directement (en dure) avec /lib/i686/ ou /lib (par défaut c'est linké avec /lib/tls).
- utiliser la variable d'environnement LD_ASSUME_KERNEL
En pratique toutes les applis (à 99%) et depuis RH9 utilisent nptl. Depuis RH9, il n'y a qu'une appli que j'ai utilisé avec linuxthread : realplay (à lancer en fixant LD_ASSUME_KERNEL).
Le seul problème que je connais avec nptl est qu'il nécessite des instructions i686 pour marcher "nickel". Entre autre berkeley db est connu pour sucker sur arch < i686. Il n'y aura pas de correctif pour ce "bug" (c'est la conséquence du design de nptl).
J'ai vérifié, mysql sous RH9 (noyau 2.4.20 patché nptl), sans le moindre patch ou options à ./configure utilise nptl (la librairie, pas l'entête).
Pour "réellement" utiliser nptl, c'est-à-dire ne pas utiliser l'entête linuxthread et être le plus proche possible du standard posix, Le "standard" maintenant est d'utiliser "-pthread" avec gcc (compilation et link) et de ne pas "réfléchir" (sous FC3, /usr/include/nptl/pthread.h sera utilisé lors d'un "#include <pthread.h>").
Pour revenir plus ou moins à l'origine du thread, il me semble que gentoo n'a pas nptl par défaut (par défaut c'est aussi linux 2.4). Donc le test a utilisé linuxthread (entête et librairie) sous Linux alors que nptl est plus rapide que linuxthread.
Donc ce test n'a pas "honteusement" favorisé linux comme sous-entendu ici.
De plus le "testeur" c'est fait chié avec freeBSD pour avoir linuxthread (qui est plus rapide que la version native). S'il n'avait pas installé linuxthread les résultats seraient pires.
> la seule réponse possible est "Ca dépend, vous voulez poser des vitres ou ravaler une façade ?"
Là c'est pour mysql uniquement et pour une version spécifique. Ce n'est pas une comparaison :
- *BSD/Mysql
- Win/SQLServer
qui conclus que Win (ou *BSD) est plus rapide.
> Quel est l'OS le plus adapté pour faire tourner MySQL
Ou : quel est le meilleur OS pour utiliser MySQL (en terme de performance).
> favorise grandement les OS Linux.
J'ai regardé les sources, ça ne va pas bien loin (sauf pour les mutex). Normal.
Je doute que ça justifie un tel écart de performance.
Ce n'est pas la première foi que les *BSD se font "bouffés" par Linux :-)
> MySQL 4.x utilisera systématiquement LinuxThreads sous Linux
Il y n'a aucun doute que MySQL utilise nptl ici. Linké avec -lpthread, reconnu lors du "./configure", HAVE_LIBPTHREAD est défini mais aussi HAVE_LINUXTHREAD.
Les includes systèmes sont des includes qui donnent aussi les fonctionnalités spécifiques de linuxthread et il y a sûrement un minimum de compatibilité fournit par nptl et on peut peut-être (sûrement?) utiliser certaines (toutes?) caratéristiques de linuxthread avec nptl.
> MySQL 5.x par contre a corrigé le tir comme je le disais, et utilisera bien le NTPL
Je ne doute pas que mysql 4.1.9 utilise nptl (au moins ici). Mais en regardant les sources il y a effectivement utilisation de fonctionnalités spécifiques à linuxthread.
De "loin" (car je n'ai pas assez de compétence), mysql est codé pour linuxthread (pour la cible linux) mais utilise nptl car nptl est compatible linuxthread.
Bref, j'ai la vive sensation que tu as raison (dépence de Mysql à linuxthread actuellement). Désolé pour la confusion.
> Au final la conclusion que l'on peut tirer de ce benchmark est que MySQL via les APIs système "façon Linux" est beaucoup plus rapide sur Linux que sur *BSD. Le contraire eut été surprenant.
Bizarre ton raisonnement. Les BSD ne remonte pas leur patch en upstream ?
Tu préfères que le testeur compare avec des versions différente de MySQL ?
Tu sembles remettre en cause la configuration automatique (détection) faite par MySQL ? Qu'es-ce qui ne va pas dans le boulot fait par Mysql ?
> MySQL est un des ports les plus patchés sous les *BSD.
> Les mutexs "rapides" sont une spécificité non portabl des linux threads.
T'es sûr ?
Avec Linux 2.6 et glibc > 2.3.? c'est nptl par défaut. Et nptl veut dire Native POSIX Thread Linux. Ça suit le norme Posix : http://people.redhat.com/drepper/(...)
NB : linuxthread (pour les sources et être portable) suit aussi la norme Posix.
Ceci dit, j'ignore si durant le test c'est nptl ou linuxthread qui a été utilisé. Même s'il y a Linux 2.4 (non-nptl) et Linux 2.6, normalement si l'appli est compilé pour nptl (auto-détection), elle switche automatiquement vers linuxthread si c'est linux 2.4 qui est utilisé.
En gros, le test montre qu'il n'y a pas de différence entre linuxthread et nptl pour ce test :-)
> je ne pense pas que le choix du FS ait un impact sur les performances d'une telle base de données.
Ça dépend. Pour l'écriture certaines opérations requièrent un flush pour l'intégrité des donnée et donc attente de l'écriture sur le disque (on est donc dépendant du FS).
Certains FS sont un peu "léger" et ne garantissent pas l'ordre d'écriture lors d'un flush. C'est plus rapide mais il y a des risques de corruptions potentiels.
La capacité du FS à ne pas fragmenter est importante pour les performances. Sur Linux 2.6.10 est apparue ext3-reservation pour améliorer ext3 sur ce point (gain très significatif sous forte charge avec plusieurs opérations d'écriture à la foi).
Et merde :-)
Et ce n'est pas la première fois que je me fais avoir avec dutch/deutsch/german.
> Pour info, les Allemands se sont prononcés contre les brevets logiciels
Ouais, mais lorsqu'il faut faire quelques choses au niveau européen ils bougent peu (donc merci la Pologne). Ils sont contres mais considèrent presque que la proposition actuelle est le bon "consensus".
> En general c'est mieux d'avoir un simulateur sous la main, pour reproduire les cas pourris.
D'ailleur j'ai fais un simulateur (sommaire) pour l'applis dont je parle. Ça simulait l'automate et le "truc" très cher. Pratique pour tracker les bugs et bosser avec le client.
> Parce que ca vaut plusieurs millions d'euro, tu crois qu'on ne peut pas faire de test ?
Il y avait trois fournisseurs :
- l'appli (ma boîte)
- l'automate (une autre boîte)
- le "truc" très cher (un autre boîte)
Ma boîte se s'occupait pas de tout. On a un budget (qui n'est pas de plusieurs millions d'Euro), il faut faire avec.
> Ah, tu vois qu'on se comprend finalement.
Je n'ai JAMAIS dit que j'était contre les tests (unitaire ou pas) et j'ai déjà dit 50 fois que je fais aussi des tests unitaires. Mais pas systématiquement.
> - un test unitaire qui valide le code: "je suis sur que ca marche".
Alors là tu rève (en tout cas pour les modules compliqués). Un test unitaire teste les scénarios que tu as prévus. Pas forcément ce qui arrive dans la réalité.
> De fait, si tu les as utilise et que tu as vu leur valeur, je ne comprends pas pourquoi tu me critiques de facon aussi acharnee.
CAR CE N'EST PAS LA PANACÉ TOUT LE TEMPS !!!
Tu milites pour des tests unitaire partout et tout le temps car selon toi c'est LA méthode qui permet d'assurer la qualité alors que c'est seulement une méthode parmis d'autre.
Linux marche bien sans test unitaire (ou très peu). J'imagine déjà que tu vas dire que si Linux utilisait plus les tests unitaires il serait encore "plus mieux bien", les développements iraient plus vite, et au aurait allégé le noyau en virant le fichier kernel/panic.c car devenu inutile.
> Alors c'est quoi la solution ? Ne rien tester car on ne peut pas tout tester ?
Fermes ta gueule.
Je n'ai pas dit que je ne testait jamais, je n'ai jamais dit de ne jamais faire de test unitaire.
Je teste et je fais aussi des tests unitaires.
> C'est de cette maniere que les plus gros softs de la planete(y compris non-MS) sont developpes, et il y a une raison pour cela : c'est plus efficace.
J'oubliais que MS est particuliairement brillant en terme de qualité et qu'il faut copier ses méthodes.
Si c'est parfait chez MS, pourquoi il y a tant de bug dans MS-Office et IE ?
Pourquoi leurs supers procédures qui roxent le marketing laissent passer des trous de sécurité béants à tour de bras ?
Si les tests unitaires et tout le "coincoin" déployé chez MS est indispensable pour un minimum qualité (selon toi), expliques comment fait Mozilla, KDE, Linux, etc qui ne font pas tous ces "tests unitaires et tout le "coincoin" déployé chez MS" ?
Merci pour les leçons, mais tu repasseras plus tard.
[^] # Re: evince
Posté par fabb . En réponse au journal RHEL 4 est sorti. Évalué à 3.
Je ne connais pas kpdf
> ou gpdf
Il est mieux. Pas de révolution. Son principal avantage est d'avoir la recherche de texte.
J'en parle ici car il est peu connu. Comme indiqué, c'est de la pub.
[^] # Re: Merci pour toutes ces infos
Posté par fabb . En réponse au journal RHEL 4 est sorti. Évalué à 7.
La modération de linuxfr me gonfle.
Si tu (ou un autre) veux reprendre le journal et en faire une news, t'es libre.
Je te demande qu'un petit truc (mais tu n'es pas obligé de le respecter) :
- si tu fais une modification et me cite en même temps (genre "fabb nous apprend que ...") mets un lien sur ce journal.
Donc, tant que tu ne me cite pas, tu fais ce que tu veux.
[^] # Re: naturellement...
Posté par fabb . En réponse à la dépêche Déclarations de Microsoft à propos de l'interopérabilité, et réactions. Évalué à 2.
Donc, si on te fait une prise de sang et qu'elle prouve que tu as pris du cannabis, tu as une amende ?
Ben non.
Il n'est pas interdit de consommer du cannabis. Ceci dit, je déconseille de fumer du cannabis.
[^] # Re: naturellement...
Posté par fabb . En réponse à la dépêche Déclarations de Microsoft à propos de l'interopérabilité, et réactions. Évalué à -5.
Remontes ta remarque à pasBill pasGate.
> Ton post ne mérite pas d'être lu au delà de ta première phrase
T'es libre de t'arrêter aux "petites phrases".
[^] # Re: naturellement...
Posté par fabb . En réponse à la dépêche Déclarations de Microsoft à propos de l'interopérabilité, et réactions. Évalué à 1.
[^] # Re: naturellement...
Posté par fabb . En réponse à la dépêche Déclarations de Microsoft à propos de l'interopérabilité, et réactions. Évalué à 3.
Affirmes l'inverse si tu veux. Mais avances quelques arguments comme des exemples concrèts.
Je ne connais pas de cas qui ont posé problème.
Exemple, le protocole utilisé par le service rhn de Red Hat n'est pas documenté. Or il y a les sources du client (up2date). Avec ça il y a eu des serveurs compatible avec up2date et sans grande difficulté.
[^] # Re: naturellement...
Posté par fabb . En réponse à la dépêche Déclarations de Microsoft à propos de l'interopérabilité, et réactions. Évalué à 2.
Un cerveau ne te ferait pas de mal je pense.
> A cette epoque, un des OS les plus "frequent" c'etait CP/M, pas Unix
Où ça ? À la maison ?
Quand ? durant la courte période où CP/M était en vogue ?
Tu peux aussi parler du TO7. Il était très populaire à une époque.
> Et ? Il y a un standard qui dit que c'est inacceptable ?
Le standard html ne dit pas que c'est inacceptable de ne pas suivre le standard html, mais il n'empêche que le non respect des standards par IE est inacceptable.
Oui ou non ?
> On n'a plus le droit de faire quoi que ce soit sans qu'il y ait un standard qqe part ?
Sauf qu'après il faut faire des clients ftp avec les options "binary" et "ascii" par exemple.
Qu'il faut ajoute l'option 'b' à fopen() pour la libc (une librairie *starndard*) pour faire plaisir à MS (man fopen) :
- "Le ‘‘b’’ est ignoré sur tous les systèmes compatibles POSIX, y compris Linux. (D’autres systèmes peuvent traiter les fichiers de texte et les fichiers binaires différement, et l’ajout du ‘‘b’’ peut être une bonne idée si vous faites des entrées-sorties binaires et que votre programme risque d’être porté sur un environnement non-Unix)."
Pourquoi ?
Pour rien. Le seul truc "positif" c'est lorsque tu faisais un "type program.exe" il affichait quelque chose comme "MS-Dos Program" puis quittait.
Toi tu vois une inovation là dedans, moi j'ai vois une incompatibilité gratuite.
> Quand a etre une horreur, il n'y aurait pas eu le mot MS accroche a ca ca t'aurais passe sous le nez, ah les tetes de turc...
Tu joues le rôle de la victime ? Tu vas nous développer la théorie du complot anti-MS ?
Tu devrais aller lire les liens de la news.
MS a aussi fait son kerberos à lui tout seul qui marche avec personne d'autre. Encore une incompatibilité qui ne sert à rien et "comme par hazard", c'est mal documenté. C'est le team samba qui apprécier (encore). Quand MS utilise un standard, il utilise "le standard selon MS et sans documenter" et pas le standard.
Je parle d'incompatibilités gratuites. Je ne parle pas des innovations MS (comme OLE2, etc).
Il n'est pas nécessaire de créer des incompatibilités, de polluer des standards, pour innover.
Si MS veut son propre HTML, il fait le ms-html avec les entêtes qui vont bien. Mais MS n'a pas à polluer l'html standard.
Quand Mozilla fait un rendu qui ne respecte pas la norme, c'est une erreur, un bug. Mais quand IE fait une erreur de rendu, c'est très très souvent une incompatibilité gratuite qu'a créé MS car MS ne veut pas corriger IE et respecter les standards (sinon ça serait fait depuis longtemps). """grace""" à IE, il faut deux moteurs pour parser l'html dans mozilla. Par exemple :
http://www.microsoft.com/(...) utilise "Quirks mode"
http://linuxfr.org/(...) utilise "Standards compliance mode"
Le logiciel libre innove et il n'y a pas de d'incompatibilité, de standards qui sont pollués. Je ne dis pas que ça n'arrive jamais avec le libre mais que ça arrive "seulement" 100 ou 1 000 fois moins que sous Windows :-)
> Oh ca oui je sais, le moindre truc que MS fait de travers ou de different il est remarquable pour vous et vous en profitez pour hurler vos frustrations, tout le reste vous oubliez comme par hasard.
Imaginons. Toi t'as à l'opposé, tu fais amen à toutes les actions de MS, donc ça équilibre.
PS : oui je sais, netscape 4.x était aussi une horreur en terme de respect des standards.
[^] # Re: naturellement...
Posté par fabb . En réponse à la dépêche Déclarations de Microsoft à propos de l'interopérabilité, et réactions. Évalué à 0.
Il sagit de ne pas ajouter des incompatibilités pour rien. Au début de MS-DOS, MS-DOS était "rien" en part de marché (par définition).
> En passant, tu devrais jeter un oeil a ASCII, tu serais des lors surpris de voir qui c'est qui n'a pas respecte le standard en n'utilisant pas crlf pour un retour au debut de la ligne suivante.
Zut, pour une fois que MS suit un standard.
MS a aussi inventé les fichiers "texte" et les fichiers "binaire". Plus précisément, je ne sais pas si c'est MS qui a inventé ce truc, mais j'ai vu cette horreur que sous Windows (d'où le caractère EOF (je dis bien "caractère" et pas entier) qui n'existe dans aucun standard).
Enfin, on n'a pas à démontrer que MS est la société qui respecte le moins les standards et qui ajoute le plus d'incompatibilité pour rien. Si tu en doutes, regarde du côté de IE.
Ce n'est pas spécifique à MS, les Unix l'ont fait aussi. Mais c'est particulièrement remarquable chez MS.
[^] # Re: naturellement...
Posté par fabb . En réponse à la dépêche Déclarations de Microsoft à propos de l'interopérabilité, et réactions. Évalué à 2.
Si tu as les sources, tu as l'interopérabilité. Après que les gens n'est pas envis ou les compétences de lire les sources est une autres histoire et se sont de cas très rare (s'ils existent). Je peux te garantir que samba serait très satisfait de n'avoir "que" les sources.
Si on prolonge ton raisonnement, on peut aussi dire que d'avoir la doc sur le format (par exemple html sur w3c) n'est pas une garantie d'interopérabilité. D'où IE par exemple qui n'est pas un modèle d'intéropérabilité et lit mal l'html alors que le format est parfaitement documenté.
# naturellement...
Posté par fabb . En réponse à la dépêche Déclarations de Microsoft à propos de l'interopérabilité, et réactions. Évalué à 8.
La concurrence à du bon.
Ou tout simplement car l'Europe l'a exigé de Microsoft. Là MS prend de l'avance et veux nous faire croire qu'ils sont des ""anges"" et non qu'ils plient suite à un procès entre l'Europe et MS.
Wait and see car MS n'a jamais été un modèle dans ce domaine et ce depuis ses débuts (séparateur de path '\' au-lieu de '/', <cr><lf>, etc).
Mais comme d'habitude MS nous fait un peu de FUD anti-open-source (du mail de bilou) :
Sometimes interoperability is also confused with open source software. Interoperability is about how different software systems work together. Open source is a methodology for licensing and/or developing software – that may or may not be interoperable. Additionally, the open source development approach encourages the creation of many permutations of the same type of software application, which could add implementation and testing overhead to interoperability efforts.
La disponibilité des sources est une garantie d'intéropérabilité (ça évite de faire de l'ingénierie à rebour par exemple, ce qui est laborieux, interdit au US, et aux résultats hazardeux).
PS : très bonne news, d'excellents liens.
[^] # Re: Désolé pour les trolls
Posté par fabb . En réponse au journal La guerre des OS. Évalué à 1.
> TOUS les MySQL 4.0.X et les MySQL 4.1.Y avec Y < 8 utiliseront Linuxthreads par défaut si il est disponible.
Sous RH et FC il y a nptl *ET* linuxthread. L'appli qui veut linuxthread doit être linké à /lib/i686 (ou autre) mais pas à /lib/tls/libpthread.so. MySQL fait de lui même le choix d'utiliser nptl s'il est présent.
Ce que tu ne veux pas comprendre, est que nptl est compatible linuxthread (sauf quelques cas particulier) et donc ont peut avoir un code fait pour linuxthread qui marche avec nptl. C'est ce qui se passe avec *plein* *plein* *plein* d'applis et aussi avec mysql.
Je répète, mysql est codé ala linuxthread mais utilise nptl.
> Pour X<23 MySQL 4.0.X ne compilera même pas.
Je n'ai jamais dit le contraire. Relis le thread. Je dis qu'il est codé en utilisant les entêtes linuxthread mais qu'il utilise l'implémentation des thread nptl.
C'est comme Gtk. Ton applis peut nécessiter les entêtes Gtk+ 2.0 et ne pas compiler avec Gtk+ 2.6 mais elle peut utiliser gtk+ 2.6 (la librairie binaire, avec un file selector "mignon", etc) et dans ce cas, je dis que l'applis utilise gtk+ 2.6 pour la simple raison qu'elle utilise gtk+ 2.6.
Si tu ne comprends pas ça, je n'y peux rien.
> Je parle des MySQL vanilla, à savoir le code source tel qui est fourni par MySQL sur le site MySQL.
Moi aussi (et ./configure n'utilise pas "--with-pthread"). Ici, mysql utilise nptl et est compilé avec les entêtes de linuxthread.
> Donne moi une raison valable, une seule ça me suffit, pour que MySQL sur une émulation de thread Linuxthread sur les threads posix sur les threads Natifs BSD soit plus rapide que MySQL directement sur les threads natifs BSD. Bonne chance.
J'ai aucune raison à donner. Mais ce n'est pas une émulation de linuxthread, c'est linuxthread. C'est différent.
Le bench, même s'il ne donne pas de raison, montre que Mysql est plus lent avec l'implémentation native qu'avec linuxthread. Point final.
Maintenant soit tu remets en cause l'intégrité du test en refaisant les tests, soit tu considères que MySQL est mal codé lorsqu'il utilise l'implémentation native, soit tu considères que l'implémentation *BSD est plus lente que linuxthread.
> Hint : Les locks et les unlocks de mutexs sont des appels système qui se font forcément en natif.
Et alors ?
C'est toi qui dit que le problême est autour des mutex. Moi, je n'en sais rien. Je constate seulement que c'est plus rapide avec linuxthread.
[^] # Re: Désolé pour les trolls
Posté par fabb . En réponse au journal La guerre des OS. Évalué à 1.
> MySQL uses LinuxThreads on Linux. If you are using an old Linux version that doesn't have glibc2, you must install LinuxThreads before trying to compile MySQL.
Car il n'y a pas de thread du tout pour glibc < 2 et que d'ailleur il n'y a que Linux 2.6 qui fourni des fonctionnalités pour les threads. Les linux plus anciens s'appuient sur clone() et le reste est fait en userland.
> le testeur démontre avec brio que
Que MySQL sous *BSD est plus lent que MySQL sous Linux.
Pourquoi ?
Certains pensent car c'est à cause de *BSD et d'autres (toi ?) pensent que MySQL est codé avec les pieds pour le port BSD.
[^] # Re: Désolé pour les trolls
Posté par fabb . En réponse au journal La guerre des OS. Évalué à 0.
Ici j'ai :
/usr/include/pthread.h (linuxthread)
/usr/include/nptl/pthread.h (nptl)
Dans 99 % des cas, c'est /usr/include/pthread.h qui est utilisé.
linuxthread est une implémentation de la norme Posix 1003.1c :
http://pauillac.inria.fr/~xleroy/linuxthreads/(...)
et jouer avec ce qui est spécifique à linuxthread ou nptl est rare.
> On retrouve pas mal de rapprots de bugs sur NPTL, notamment dans les forums Debian,
Sous Red Hat/Fedora et depuis RH9 nptl est utilisé par défaut :
http://fr2.rpmfind.net/linux/redhat/9/en/os/i386/RELEASE-NOTES.html(...)
This thread library is designed to be binary compatible with the old LinuxThreads implementation; however, applications that rely on the places where the LinuxThreads implementation deviates from the POSIX standard will need to be fixed
Donc, comme je le supposais plus haut, nptl est compatible linuxthread.
Il n'y a que deux façon d'utiliser linuxthread avec RH9 ou > :
- linker directement (en dure) avec /lib/i686/ ou /lib (par défaut c'est linké avec /lib/tls).
- utiliser la variable d'environnement LD_ASSUME_KERNEL
En pratique toutes les applis (à 99%) et depuis RH9 utilisent nptl. Depuis RH9, il n'y a qu'une appli que j'ai utilisé avec linuxthread : realplay (à lancer en fixant LD_ASSUME_KERNEL).
Le seul problème que je connais avec nptl est qu'il nécessite des instructions i686 pour marcher "nickel". Entre autre berkeley db est connu pour sucker sur arch < i686. Il n'y aura pas de correctif pour ce "bug" (c'est la conséquence du design de nptl).
J'ai vérifié, mysql sous RH9 (noyau 2.4.20 patché nptl), sans le moindre patch ou options à ./configure utilise nptl (la librairie, pas l'entête).
Pour "réellement" utiliser nptl, c'est-à-dire ne pas utiliser l'entête linuxthread et être le plus proche possible du standard posix, Le "standard" maintenant est d'utiliser "-pthread" avec gcc (compilation et link) et de ne pas "réfléchir" (sous FC3, /usr/include/nptl/pthread.h sera utilisé lors d'un "#include <pthread.h>").
Pour revenir plus ou moins à l'origine du thread, il me semble que gentoo n'a pas nptl par défaut (par défaut c'est aussi linux 2.4). Donc le test a utilisé linuxthread (entête et librairie) sous Linux alors que nptl est plus rapide que linuxthread.
Donc ce test n'a pas "honteusement" favorisé linux comme sous-entendu ici.
De plus le "testeur" c'est fait chié avec freeBSD pour avoir linuxthread (qui est plus rapide que la version native). S'il n'avait pas installé linuxthread les résultats seraient pires.
[^] # Re: Désolé pour les trolls
Posté par fabb . En réponse au journal La guerre des OS. Évalué à 1.
Pas d'accord et au moins pour ça :
http://people.redhat.com/drepper/assumekernel.html(...)
The code in /lib/tls is the new NPTL POSIX thread library.
$ ldd /usr/libexec/mysqld | grep thread
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00cf4000)
$ LD_ASSUME_KERNEL=2.4.1 ldd /usr/libexec/mysqld | grep thread
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x00c76000)
[^] # Re: Désolé pour les trolls
Posté par fabb . En réponse au journal La guerre des OS. Évalué à 0.
Là c'est pour mysql uniquement et pour une version spécifique. Ce n'est pas une comparaison :
- *BSD/Mysql
- Win/SQLServer
qui conclus que Win (ou *BSD) est plus rapide.
> Quel est l'OS le plus adapté pour faire tourner MySQL
Ou : quel est le meilleur OS pour utiliser MySQL (en terme de performance).
> favorise grandement les OS Linux.
J'ai regardé les sources, ça ne va pas bien loin (sauf pour les mutex). Normal.
Je doute que ça justifie un tel écart de performance.
Ce n'est pas la première foi que les *BSD se font "bouffés" par Linux :-)
[^] # Re: Désolé pour les trolls
Posté par fabb . En réponse au journal La guerre des OS. Évalué à -1.
Il y n'a aucun doute que MySQL utilise nptl ici. Linké avec -lpthread, reconnu lors du "./configure", HAVE_LIBPTHREAD est défini mais aussi HAVE_LINUXTHREAD.
Les includes systèmes sont des includes qui donnent aussi les fonctionnalités spécifiques de linuxthread et il y a sûrement un minimum de compatibilité fournit par nptl et on peut peut-être (sûrement?) utiliser certaines (toutes?) caratéristiques de linuxthread avec nptl.
> MySQL 5.x par contre a corrigé le tir comme je le disais, et utilisera bien le NTPL
Je ne doute pas que mysql 4.1.9 utilise nptl (au moins ici). Mais en regardant les sources il y a effectivement utilisation de fonctionnalités spécifiques à linuxthread.
De "loin" (car je n'ai pas assez de compétence), mysql est codé pour linuxthread (pour la cible linux) mais utilise nptl car nptl est compatible linuxthread.
Bref, j'ai la vive sensation que tu as raison (dépence de Mysql à linuxthread actuellement). Désolé pour la confusion.
[^] # Re: Désolé pour les trolls
Posté par fabb . En réponse au journal La guerre des OS. Évalué à 1.
Bizarre ton raisonnement. Les BSD ne remonte pas leur patch en upstream ?
Tu préfères que le testeur compare avec des versions différente de MySQL ?
Tu sembles remettre en cause la configuration automatique (détection) faite par MySQL ? Qu'es-ce qui ne va pas dans le boulot fait par Mysql ?
> MySQL est un des ports les plus patchés sous les *BSD.
Où on peut les voirs ces patchs ?
[^] # Re: Désolé pour les trolls
Posté par fabb . En réponse au journal La guerre des OS. Évalué à -1.
T'es sûr ?
Avec Linux 2.6 et glibc > 2.3.? c'est nptl par défaut. Et nptl veut dire Native POSIX Thread Linux. Ça suit le norme Posix :
http://people.redhat.com/drepper/(...)
NB : linuxthread (pour les sources et être portable) suit aussi la norme Posix.
Ceci dit, j'ignore si durant le test c'est nptl ou linuxthread qui a été utilisé. Même s'il y a Linux 2.4 (non-nptl) et Linux 2.6, normalement si l'appli est compilé pour nptl (auto-détection), elle switche automatiquement vers linuxthread si c'est linux 2.4 qui est utilisé.
En gros, le test montre qu'il n'y a pas de différence entre linuxthread et nptl pour ce test :-)
[^] # Re: Précisions
Posté par fabb . En réponse au journal La guerre des OS. Évalué à 2.
Ça dépend. Pour l'écriture certaines opérations requièrent un flush pour l'intégrité des donnée et donc attente de l'écriture sur le disque (on est donc dépendant du FS).
Certains FS sont un peu "léger" et ne garantissent pas l'ordre d'écriture lors d'un flush. C'est plus rapide mais il y a des risques de corruptions potentiels.
La capacité du FS à ne pas fragmenter est importante pour les performances. Sur Linux 2.6.10 est apparue ext3-reservation pour améliorer ext3 sur ce point (gain très significatif sous forte charge avec plusieurs opérations d'écriture à la foi).
[^] # Re: L'allemagne s'oppose à la procédure en cours
Posté par fabb . En réponse à la dépêche Brevets Logiciels : le Parlement néerlandais à la rescousse. Évalué à 2.
J'en ai fait plein (comme suggéré par la ffii). Et aussi à quelques média (et une au medef). Je dois avouer que je n'y crois plus en cette démarche.
[^] # Re: Méprise
Posté par fabb . En réponse à la dépêche Brevets Logiciels : le Parlement néerlandais à la rescousse. Évalué à 1.
Et merde :-)
Et ce n'est pas la première fois que je me fais avoir avec dutch/deutsch/german.
> Pour info, les Allemands se sont prononcés contre les brevets logiciels
Ouais, mais lorsqu'il faut faire quelques choses au niveau européen ils bougent peu (donc merci la Pologne). Ils sont contres mais considèrent presque que la proposition actuelle est le bon "consensus".
# L'allemagne s'oppose à la procédure en cours
Posté par fabb . En réponse à la dépêche Brevets Logiciels : le Parlement néerlandais à la rescousse. Évalué à 0.
Et que fait la France. Rien.
[^] # Re: ???
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.
D'ailleur j'ai fais un simulateur (sommaire) pour l'applis dont je parle. Ça simulait l'automate et le "truc" très cher. Pratique pour tracker les bugs et bosser avec le client.
> Parce que ca vaut plusieurs millions d'euro, tu crois qu'on ne peut pas faire de test ?
Il y avait trois fournisseurs :
- l'appli (ma boîte)
- l'automate (une autre boîte)
- le "truc" très cher (un autre boîte)
Ma boîte se s'occupait pas de tout. On a un budget (qui n'est pas de plusieurs millions d'Euro), il faut faire avec.
> Ah, tu vois qu'on se comprend finalement.
Je n'ai JAMAIS dit que j'était contre les tests (unitaire ou pas) et j'ai déjà dit 50 fois que je fais aussi des tests unitaires. Mais pas systématiquement.
> - un test unitaire qui valide le code: "je suis sur que ca marche".
Alors là tu rève (en tout cas pour les modules compliqués). Un test unitaire teste les scénarios que tu as prévus. Pas forcément ce qui arrive dans la réalité.
> De fait, si tu les as utilise et que tu as vu leur valeur, je ne comprends pas pourquoi tu me critiques de facon aussi acharnee.
CAR CE N'EST PAS LA PANACÉ TOUT LE TEMPS !!!
Tu milites pour des tests unitaire partout et tout le temps car selon toi c'est LA méthode qui permet d'assurer la qualité alors que c'est seulement une méthode parmis d'autre.
Linux marche bien sans test unitaire (ou très peu). J'imagine déjà que tu vas dire que si Linux utilisait plus les tests unitaires il serait encore "plus mieux bien", les développements iraient plus vite, et au aurait allégé le noyau en virant le fichier kernel/panic.c car devenu inutile.
[^] # Re: Quelle version ?
Posté par fabb . En réponse à la dépêche La norme Linux Standard Base s'enrichit. Évalué à 1.
Ça c'est fort.
Dans ce cas, je me torche de la LSB.
> - Fedora
> Conforme et certifié LSB 1.3
Peut-être conforme et pas certifié :
http://fedora.redhat.com/about/rhel.html(...)
[^] # Re: ???
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à -5.
Fermes ta gueule.
Je n'ai pas dit que je ne testait jamais, je n'ai jamais dit de ne jamais faire de test unitaire.
Je teste et je fais aussi des tests unitaires.
> C'est de cette maniere que les plus gros softs de la planete(y compris non-MS) sont developpes, et il y a une raison pour cela : c'est plus efficace.
J'oubliais que MS est particuliairement brillant en terme de qualité et qu'il faut copier ses méthodes.
Si c'est parfait chez MS, pourquoi il y a tant de bug dans MS-Office et IE ?
Pourquoi leurs supers procédures qui roxent le marketing laissent passer des trous de sécurité béants à tour de bras ?
Si les tests unitaires et tout le "coincoin" déployé chez MS est indispensable pour un minimum qualité (selon toi), expliques comment fait Mozilla, KDE, Linux, etc qui ne font pas tous ces "tests unitaires et tout le "coincoin" déployé chez MS" ?
Merci pour les leçons, mais tu repasseras plus tard.