IsNotGood a écrit 5009 commentaires

Tu veux un autographe ?

> Les brevets logiciels créent de facto une insécurité juridique (ie personne n'est à l'abris d'un procès) car ils brevètent des idées.

Formulé comme ça pourquoi pas. Tout développeur peut coder une idée sans se rendre compte qu'elle fait l'objet d'un brevet. Les petites boites n'ont pas les moyens de vérifier ça.

Mais ta formulation ne colle pas au cas MS/Alcatel. MS sait que mp3 est breveté.

> Ton commentaire est pertinent si tu considère que seuls les méthodes sont brevetables

La méthode en logiciel c'est le code source. Le code source est déjà protégé par le droit d'auteur. D'ailleurs le droit d'auteur protège plus longtemps que les brevets.

Faire les brevets logiciels sur les méthodes n'a pas de sens. C'est déjà protégé par le droit d'auteur.

> Ça montre au moins qu'il n'y a pas que dans le cas du logiciel que les brevets posent problème

Il ne pose pas de problème dans l'industrie (où on ne brevette que des moyens pour obtenir une fonctionnalité et jamais la fonctionnalité).

Il y a deux domaines ou les brevets tels qu'ils sont appliqués posent problème :
- Le logiciel (car on brevete une idée)
- La chimie/medecine quand on brevete une molécule. Une molécule est une invention ou une découverte (comme on découvre une étoile). Ainsi des molécules qu'on trouve dans la nature ont été breveté (ce qui est une abhération complète). On a ici un cas rare où un brevet a été annulé en justice (la boite avait obtenu un brevet pour une molécule qu'on trouve dans la nature). Notons qu'ici il y a une insécurité juridique, puisque le brevet a été annulé, mais on ne va pas s'en plaindre.

Mais ce n'est pas l'"insécurité juridique" des brevets logiciels le problème.
Le problème c'est les brevets logiciels. C'est le principe de breveter une idée qui est mauvais. Ce principe était mauvais/néfaste, qu'il y ait ou non une "insécurité juridique" ne change pas grand chose.

Tu préfères les brevets logiciels (le principe de breveter une idée) sans insécurité juridique ?
Moi, je ne suis pas convaincu.

> Même MS qui avait pourtant payé une licence pour utiliser les MP3 s'est retrouvé attaqué pour violation d'un autre brevet.

Ça c'est ce que dit MS. Les juristes ne sont pas des abrutis. Et si MS c'est pris une amende dans la gueule, c'est bien que MS n'avait pas acquité les droits mp3.
Si ce n'est pas le cas, je conseille à Alcatel-Lucent de faire un nouveau procès pour décrocher encore le jackpot. D'ailleurs ils pourraient plannifier d'en faire un par mois (ça permet à MS de mettre de l'argent de côté).

Tu peux me donner une définition d'"insécurité juridique" ?

> Pour rappel, des boites comme SCO ou MS mettent en garde les organismes publics voulant passer à Linux contre une prétendue insécurité juridique des logiciels libres (Attention, ils violent des brevets et bla bla bla).

Oublions le "insécurité juridique" qui est utilisé à toutes les sauces.
http://showusthecode.com/

Une lois néfaste dans son principe (comme c'est le cas pour les brevets logiciels je pense) est une lois néfaste. Si elle a des points qui crée une "insécurité juridique" alors elle doit être corrigée (c'est le boulot des juristes/législateurs). Et si elle est corrigée, ça reste toujours une lois néfaste car son principe est néfaste (ici reconnaitre qu'une idée est brevetable).

Donc à quoi ça sert de souligner ou s'en prendre à une supposée "insécurité juridique" des brevets logiciels ? Si cette "insécurité juridique" est virée, les brevets logiciels restent toujours néfastes.
Je me trompe ?

Et par rapport aux brevets logiciels et sa présupposés "insécurité juridique" ?

C'est bien qu'il ait une "insécurité juridique" pour les homicides ou c'est mal ?
D'ailleurs, il y a-t'il une "insécurité juridique" pour les homicides ?
Si oui, c'est bien ou c'est mal de la retrouver dans les brevets logiciels ?
Si non, alors pourquoi il y a une "insécurité juridique" avec les brevets logiciels ?
Qu'es-ce qu'il y a de spécifique, juridiquement parlant, dans les lois liées aux brevets logiciels qui crée une "insécurité juridique" ?

Je suis contre les brevets logiciels, ça ne fait pas l'ombre d'un doute. Mais ce n'est pas parce que je suis contre les brevets logiciels que je vais dire, pour ne pas dire inventer, que les brevets logiciels créent une insécurité juridique. Les brevets logiciels mettent les PME (et pas seulement elles) dans l'insécurité, j'en suis convaincu. Mais pas dans l'insécurité juridique. Les textes de lois sont claires, si tu violes un brevet, c'est panpancucu.

D'ailleurs, ne serait-il pas mieux pour le logiciel libre qu'il y ait une insécurité juridique ?
Je pense que oui. Donc pourquoi s'en plaindre ?
Le problème des brevets logiciels est d'autant plus grave qu'il n'y a pas d'insécurité juridique (comme pour les homicides).

A-t-on vu une fois un tribunal ne pas mettre de peine à une boite qui viole des brevets ? Je ne crois pas.

Ces derniers arguments sont plus pertinents :-)

> Les Pros sous Suse/Novell ou RHEL seront tres difficiles a convaincre car Ubuntu n'apporte pas (tout comme Debian d'ailleurs) d'outils de configurations confortables....

Je ne crois que ça se joue ici. Fedora a les mêmes outils que RHEL. Mais RHEL (idem pour Novell) a des constructeurs (Dell, IBM, etc) qui certifient l'OS et sont des partenaires de RHEL, RHEL a des formations, des logiciels certifiés (c'est-à-dire que l'éditeur propose un support), un support solide (des experts pour faire des propositions de solutions voire les réaliser), garantit la compatibilité source et binaire pour 7 ans, etc...

C'est pas drole et pas compréhensible.
Si c'était "Rendre kde simple c'est aussi naturel que Sarkozy rejoignant l'équipe de campagne de Royal", ça ne serait peut-être toujours pas drole, mais ça serait compréhensible. Quoique Royal regardant Sarkozy de haut, ça peut être rigolo.

> Elle veut dire qu'avec les brevets logiciel tu risque de te faire attaqué en justice à tout moment.

Désolé, mais ça n'a aucun sens. Toute lois crée alors de l'insécurité juridique car avec toute lois tu risque de te faire attaqué en justice à tout moment.

L'insécurité juridique peut-être par exemple lorsque la justice n'a pas statué sur un cas. Par exemple avec la GPL il y avait une insécurité juridique car on ne savait pas comme la GPL pouvait être interprété par la justice (le débat est maintenant fermé je crois). Ça c'est de l'insécurité juridique. Du moins c'est comme ça que je le comprend. Par contre ne pas aquiter les droits d'utilisation d'un brevet ne présente pas d'insécurité jurique. Dans ce cas tu sais que "tu vas t'en prendre plein la gueule et le plaignant plein les fouilles".

> Insécurité juridique signifie : Risque important de contentieux , de procés , etc ....

L'homicide présente alors une insécurité juridique ?

Dave Jones (populaire pour être souvent responsable du noyau Fedora et pour ses contributions à Linux) a fait la remarque.
Je ne suis pas de son niveau (vraiment pas) et je préfère m'effacer. On ne boxe pas dans la même catégorie :-)

> l'insécurité juridique liée aux brevets logiciels ne relève pas du fantasme, Microsoft vient d'être confronté à cette dure réalité car il a été condamné à verser 1,5 milliard de dollars à Alcatel-Lucent pour violation de brevet concernant le format de compression mp3. Les brevets logiciels créent donc de l'insécurité juridique, pas les logiciels libres.

???
Je ne vois pas ce que vient foutre l'insécurité juridique dans cet exemple.
J'ai raté un épisode ?
Que veut dire "insécurité juridique" ?

> Personne ne croyait que Debian sortirait en Decembre et ce fut vrai....

Il semble que des gens haut placé chez Debian y croyaient...

> Si Debian sort avant ..buntu ou peu apres les decideurs choisiront Debian car Debian est l'original et non la copie Ubuntu.

Bof. Vu le nombre de contributeur qu'il y a chez Ubuntu, on peut se demander qui copie qui.

> Si Debian sort avant ..buntu ou peu apres les decideurs choisiront Debian car Debian est l'original et non la copie Ubuntu.

Rebof. Considère RHEL et Fedora. La copie c'est RHEL (c'est un travail dérivé de Fedora). Les décideurs (les entreprises) prennent RHEL.

> Debian Etch est une distribution complete...

Bof encore. Fedora est plus complète que RHEL. RHEL n'inclut qu'une partie des paquets de Fedora. Il n'y a que Directory Server qui est encore spécifique à RHEL. Mais ça ne devrait plus être le cas pour F7 (fds est dans Fedora Extras depuis le 14 février) :
http://directory.fedora.redhat.com/wiki/FDS_Into_FedoraCore

> Si Debian sortait jusqu'en Juin il est fort a parier que l'avenir commercial d'Ubuntu serait plutot turbulent.

Vrai si Ubuntu n'est qu'une copie de Debian. Mais ce n'est pas (ou plus) que ça.

> il te suffisait de me moucher en postant la CONFIG_DEBUG de RHEL.

Mais ça flirt avec le coup de chance.
Tu as peut-être remarqué que FC6 a deux ou trois CONFIG_DEBUG de plus que RHEL. Il y a des CONFIG_DEBUG qui sont ajoutés effectivement pour débugguer car un bug n'a pas été corrigé. Ça arrive quand en phase de test l'existance d'un bug ne fait pas de doute mais que les développeurs Red Hat n'arrivent pas à savoir où il se cache et comment il se déclenche. Ce type de bug touche en général peu de bécane/configuration. Il est raisonnable compte tenu des objectifs de Fedora (le développement rapide de GNU/Linux) d'activer des options de debug, ainsi les développeurs récoltent plus d'information et peuvent corriger le bug.
L'autre cas est quand il faut faire le "grand saut". Par exemple lorsque Fedora est passé à ACPI. On sait que ça va merder car il y a un nombre considérable de configuration, mais corriger le tout uniquement en phase de test (donc avec une poingnée de testeur) peut prendre des plombes pour ne pas dire que c'est quasi impossible. Fedora n'a pas la base de testeurs de Windows par exemple (via les beta testeurs, les fabricants de hardware, etc...). Ce type de démarche reste exceptionnel et murement réfléchi. Par exemple par deux fois acl était activé en phase beta mais désactivé pour la version finale. Acl n'était pas assez mûr pour le "grand saut". Pour ACPI et SeLinux c'est arrivé une fois. Fedora n'a pas laissé les choses activés en espérant les débugguer avec les utilisateurs. Fedora le fait, mais c'est exceptionnel et mûrement réfléchi.
Alors oui, Fedora aura souvent plus de CONFIG_DEBUG d'activé que RHEL. Mais qui fait avancer le logiciel libre ? Fedora ou RHEL ? Ben c'est Fedora. RHEL fait le financement.

Maintenant prend le problème d'une autre façon. Considère qu'il n'y a pas RHEL (imagine qu'il y a un généreux milliardaire pour financer Fedora) et considère les objectifs de Fedora. Crois-tu que Fedora n'aurait jamais de bonne raison d'activer des CONFIG_DEBUG même pour la version finale ? Les raisons précédentes que j'ai donné sont toujours valides.

Autre façon de regarder le "problème". Considère qu'il n'y a que RHEL et pas de Fedora (pourquoi pas puisque Red Hat ne fait pas d'argent avec Fedora). Ta critique tombe définitivement à l'eau. Mais crois-tu que le logiciel libre y gagne ? Crois-tu que l'influence de la "communauté" du libre y gagne ?

Je ne vais pas nier la liaison entre RHEL et Fedora. Elle est affichée. Par exemple SeLinux a été mis dans Fedora non à l'initiative de Fedora ou de la communauté mais car Red Hat voulait SeLinux dans RHEL. Idem pour Xen. Le libre y a gagné. Mais je crois que Red Hat en a un peu rien à foutre d'avoir AIGLX dans RHEL, et RHEL ne serait pas passé à yum s'il n'y avait pas Fedora. Mais c'est Red Hat qui finance Fedora (et presque massivement) en plus d'être le plus gros contributeur. Donc il est normal que Red Hat ait son mot à dire. Et si Red Hat n'a pas son mot à dire, Red Hat ferme Fedora car il n'y gagne rien (ou trop peu) et le libre y perd.

Red Hat a trouvé un modèle sympa, gagnant-gagnant, entre le business et le libre. Tant mieux et je dois dire que ça m'énerve de le voir critiqué. Ce modèle est un compromis, et comme tout compromis perfectible lorsqu'on le regarde sans recul. Ce modèle a été repris par Sun (OpenSolaris/Solaris) et par Novell (OpenSuSE/Novell). Ce modèle n'est pas une révolution. Il couvait depuis un moment. Il est judicieux.

Certes Fedora et RHEL ont DEBUG_SPINLOCK. Mais avant tout un développeur Red Hat va regarder ce problème (qu'il existe ou non dans RHEL). Ce n'est peut-être pas dans son top10, mais les performances de Fedora ne sont pas négligées. Et lorsque le problème sera corrigé, la correction sera dans Fedora ET dans Linux (il y a aussi ce problème avec un noyau vanilla).

Fedora n'est pas un projet annexe de Red Hat. Red Hat communique sur Fedora (il y a un lien sur toutes les pages de http://www.redhat.com/ ) et il y a toujours au moins un article sur Fedora dans Red Hat Magazine. Un article récent et sympa :
http://www.redhatmagazine.com/2007/02/15/professional-audio-(...)
D'autres articles : http://www.redhatmagazine.com/category/fedora/

Si Red Hat communique sur Fedora, il est claire que Red Hat ne veut pas que Fedora soit un produit pourri même si Red Hat obtient de Fedora ce qu'ils veulent pour RHEL.

J'arrête mon verbiage insupportable.

> le test n'est pas suffisamment « fair »

Je pense que le testeur est « fair » . Ce qui n'est pas juste est qu'il connait moins bien Linux que FreeBSD. Mais on ne peut pas tout connaitre.
Il lui a été demandé de tester avec la dernière mise à jour de Fedora, il l'a fait. De tester avec un 2.6.20.1, il l'a fait. De tester avec la même version de Mysql pour FreeBSD et Linux, il l'a fait aussi. Il a été très coopératif pour quelqu'un qui ne travail pas pour Linux.
Sans plus d'élément, la conclusion est : Linux/Fedora c'est pris une branlée par FreeBSD. Ce sont des choses qui arrivent.
Maintenant c'est à Linux de chercher ce qui sucks et de remercier jeffr_tech d'avoir trouvé un lièvre.
On peut relativer et dire que ce n'est qu'un bench sur une bécane, mais le fait est là.

> Pourquoi des options de debug sont-elles activées par défaut dans une distribution définitive qui est releasé auprès du public ?

Il y a toujours du subjectif dans ces choix.
Pourquoi conserver la sortie du kernel (dmesg) si la distribution est sensée marcher sans accro ? D'ailleur cette sortie n'est pas affichée.
Pourquoi fournir SeLinux alors que les programmes livrés ne doivent pas avoir de trou de sécurité et marcher de façon sûr sans SeLinux ?
Pourquoi Fedora détecte les mauvais free (). exemple : "*** glibc detected *** gedit: free(): invalid pointer: 0x0858cb08 ***" ?
etc...

Pour spécifiquement CONFIG_DEBUG_SPINLOCK d'activité, je n'en sais rien.
Pour info, voilà les options de debug du dernier noyau FC6 :
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_LIST=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y

Pour le noyau rawhide (développement) actuel :
CONFIG_DEBUG_DEVRES=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_LIST=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_RWSEMS=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUG_VM=y

On voit déjà que la version de développement à plus de debug. Je ne crois pas 2 second que les CONFIG_DEBUG* de FC6 soit uniquement pour débuggeur le noyau (sauf cas particulier) si c'est au prix d'une perte de performance significatif connue. Et ce pour plusieurs raisons :
- Fedora est développé de façon ouverte et ça gueulerait sévère sur les mailing list.
- Fedora n'a aucun intérêt à fournir un noyau lent, bien au contraire.
- Fedora a la branche développement pour ça et la branche testing pour les mises à jour.

Donc, pourquoi CONFIG_DEBUG_SPINLOCK ?
Voilà mon interprétation (je ne connais pas l'avis de Fedora).
Il va de soit que Fedora est aussi utilisé pour développer des applications. Il est dans les objectifs de Fedora d'être une plateforme pour le développement d'application. Le développement d'appli multi-thread est compliqué et se planter avec les futex est très courrant. Je crois qu'avec CONFIG_DEBUG_SPINLOCK le développeur sait s'il fait un unlock sur un mutex qui n'est pas locké ou sur un mutex créé depuis un autre processus mais dont on n'a pas mis le flag pour l'utiliser en inter-processus, etc... (Je dis peut-être des conneries ici, je n'ai pas vérifié dans le détail).
Génial tout ça !
Le problème est d'évaluer la contre partie. Pour une utilisation de mysql comme dans le bench de ce journal, la contre partie est intolérable (en imaginant que le problème vient de DEBUG_SPINLOCK, je n'en ai pas la preuve, je me suis hazardé dans une explication). Mais si la contre partie est en général une perte de performance de 0,01 %, et que DEBUG_SPINLOCK permet aussi aux développeurs d'appli de développer plus vite, alors DEBUG_SPINLOCK est (peut-être) justifié.
Pour les quelques cas où la contre partie est intolérable, il suffit de recompiler le noyau (les sources c'est aussi fait pour ça).
Notes que FC6 est sorti depuis plusieurs mois et c'est la première fois que CONFIG_DEBUG_SPINLOCK fait parlé de lui.

Un mot sur ce bench. Linux/Fedora a de moins bon résultat que FreeBSD pour un bench et pour un système à 8 cpus (seulement 1 à ce jour).
Et si le bench n'était pas représentatif ?
Et si le bench (ou mysql) avait un bug spécifique pour Linux qui n'impacte pas FreeBSD ? Ce n'est pas exactement le même code (il y a des #ifdef Linux etc..).
Se sont aussi des hypothèses à creuser. Quoique personnellement je ne chercherai pas là en premier. Même si le test est buggé il faut comprendre pourquoi Linux/Fedora s'écroule en monté en charge.

> Ne me dit pas que ce serait une manière d'utiliser Fedora comme une version beta de RHEL et ce au détriment des performances des utilisateurs de Fedora ! Non ce serait trop machiavélique.....

Pour le troll fait en voulant nous faire croire que tu ne veux pas troller (alors que ce n'est pas la première fois que tu le fais...).
Les CONFIG_DEBUG de RHEL 4 (noyau 2.6.9, dernière mise à jour) :
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y

Pour info, RHEL 5 en cours de développement utilise et utilisera un 2.6.18 (compatibilité binaire/source de RHEL oblige). FC6 a actuellement un 2.6.19 (le 2.6.20 ne devrait pas tarder) et la branche de développement de Fedora est en 2.6.20.

> ce serait une manière d'utiliser Fedora comme une version beta de RHEL et ce au détriment des performances des utilisateurs de Fedora !

Comme tu pourrais dire ça pour Mandriva "classique" et Mandriva Corporate Server, etc...
Comme on pourrait dire qu'Ubuntu débuggue RHEL. Et oui, il y a des paquets dans Ubuntu qui seront dans RHEL. Tous les bug trouvés dans Ubuntu (idem pour Mandriva, Fedora, OpenSuSE, etc) profitent à RHEL (et aussi à Debian Etch :-))
Ta remarque est tout simplement ridicule, grotesque et il serait bon que t'arrêtes.
Et notes qu'en moyenne il n'y a qu'une Fedora sur 3 qui est utilisée comme base de RHEL :
RHEL 3 => RH9
RHEL 4 => FC3
RHEL 5 => FC6
Les bugs corrigés en phase de test de RHEL 5 sont repportés sur FC6 (et la branche développement) et aussi en upstream (Red Hat est très impliqué en upstream). Donc, ce n'est pas à sens unique. Ça profite à tout le monde.

Pourquoi RHEL 5 sort après FC6 tu vas demander. Excellente question.
FC6 n'a pas de partenaire. Pour sortir elle n'a pas besoin d'attendre que Dell ait vérifié que FC6 marche sur ses bécanes, elle n'a pas besoin d'attendre la certification d'Oracle, elle n'a pas besoin d'attendre que des formations pour l'administrer soient mise en place, etc...
FC6 n'est pas supportée (via de l'argent, un contrat entre un client et un fournisseur) et n'est pas destinée aux missions critiques où le moindre de bug est un scandale. Son contexte lui permet de sortir rapidement, ce qui fait le bonheur de beaucoup d'utilisateur qui veulent des trucs "flashy", et ce qui fait aussi le bonheur des développeurs qui peuvent se concentrer sur la version à venir au-lieu de buller car l'équipe de documentation n'a pas fini son taff (NB : la doc de RHEL est libre).

Tu trouves peut-être scandaleux le prix de RHEL ? RHEL étant un produit basé sur du libre et sur une distribution qui demande la contribution de la communauté.
Pas de problème, il y a Centos (et d'autres) pour toi : http://www.centos.org/
C'est un clone de RHEL (recompilation des sources de RHEL disponibles sur http://ftp.redhat.com/ et ses mirroirs), et je ne doute pas que Centos 5 va sortir au pire 2 semaines après la sortie de RHEL 5.
Donc Fedora (gratuite) donne RHEL (payante) qui donne Centos (gratuite). Pas de problème, la boucle est bouclée et l'argent de RHEL est utilisé pour développer Fedora (gratuite) et Centos (gratuite).

Notes que Red Hat ou Fedora n'a rien contre Centos. Par exemple le projet Extras Packages for Entreprise Linux :
http://fedoraproject.org/wiki/Extras/Schedule/EnterpriseExtr(...)
Suis les liens et tu verras que tout est fait pour que ça marche aussi pour Centos et autres clones d'RHEL.


La communauté du libre a déjà assez à faire pour combattre les FUD de MS contre le logiciel libre. Voir par exemple : http://showusthecode.com/ .
Moi, et la communauté du libre, on se passerait volontier des FUD qui viennent de supporter du libre contre RHEL/Fedora qui est du logiciel libre. RHEL finance Fedora pour développer des technologies qu'on retrouve par exemple dans Mandriva (voir le buzz qu'il y avait pour AIGLX développé principalement par Fedora). RHEL finance aussi Centos qui est gratuit.

A bon entendeur...


PS : je le répète, je ne sais pas si le problème vient de CONFIG_DEBUG_SPINLOCK. J'ai dit qu'il est probablement que l'essai qu'a fait FreeBSD avec un 2.6.20.1 vanilla (sans patch Fedora) soit fait avec CONFIG_DEBUG_SPINLOCK. Mais j'en ai pas la preuve. Donc pour l'instant on ne sait pas que ça vient de CONFIG_DEBUG_SPINLOCK. J'ai seulement émis cette hypothèse.

> Sous Fedora par défaut il y a d'activé CONFIG_DEBUG_SPINLOCK et CONFIG_DEBUG_SPINLOCK_SLEEP. Il faudrait un bench sans ses options.

J'ai vu que le test a été fait avec 2.6.18 (noyau d'origine de FC6), 2.6.19 (update FC6) et 2.6.20.1 vanilla. Le 2.6.20.1 n'est pas un noyau Fedora, mais s'il a été configuré sans précaution (make config && make), CONFIG_DEBUG_SPINLOCK reste actif. Lors d'un "make config" ou "make menuconfig", la configuration en cours est reprise.

> C'et surtout que Madame Michu ne comprendra rien du tout quand elle appuiera sur "d" et qu'à la place de "d", ca coupe...

Je ne vois vraiment pas où tu veux en venir. Les éditeurs par défaut c'est gedit (kwrite KDE).

Madame Michu et monsieur Bidon ne vont pas installer un linux en ligne de commande.

Par défaut vim est installé (vim a aussi une option pour être toujours en mode insertion et vim c'est aussi gvim (version graphique avec menu)). Vim est installé car il est très connu des administrateurs.
Mais par défaut les distributions installent aussi gedit (kwrite pour KDE). Les bureau sont configurer pour utiliser par défaut gedit/kwrite et non vim.
Bref, je ne vois pas où tu veux en venir.

Tu pourrais aussi pester contre gcc.

> Et pour moi, les raccourcis clavier pour copier-coller sont plutôt ctrl+ins et shift+ins !

Pareil.
Mais au boulot je suis sous Windows et j'ai un clavier sans ins. Putain ce que ça me casse les couilles... Surtout que j'ai une culture Unix ligne de commande et ^C c'est BREAK et pas copier.

> Et quand les boites européennes engrangeront des sousous avec des brevets et en faisant des brevets en amérique, comment les gouvernements européens pourront dire aux américains; nous ne croyons pas aux brevets, nous ne croyons pas à votre système de brevets, nos entreprises n'en veulent pas?

C'est un non sens. Le système de brevet impose de déposer des brevets.
Si ce que tu dis était un rien sensé, le logiciel libre en aurait rien à foutre des brevets.

Red Hat pose des brevets mais milite contre les brevets. Sun a aussi milité contre les brevets en Europe.

> "Pourquoi devrais je leur payer des royalties puisqu'ils sont étrangers donc ne dépendant pas de la loi américaine?"

Non sens encore. Les brevets au USA c'est pour les produits utilisés au USA.
MS paye des brevets aux USA (mp3, etc) et ne paye rien en Europe. Idem pour les boites européennes.

T'es sûr ? Je vais faire chauffer mon cray.

Je t'ai plussé pour tes deux commentaires même si tes commentaire me laisse limite indifférent.
Même si je ne suis pas un fan de Debian, je ne vois pas pourquoi ceux qui aiment debian et le disent se font moinser.
Et en plus je n'aime pas le système de score de linuxfr.

> Quelqu'un dans la salle peut commenter les résultats, la pertinence ou l'impertinence de ce benchmark ?

NB : Mysql a la réputation d'être très exigent en futex.

Petite intro sur les futex/spinlock.
Un futex est un verrou.
Imaginons :
étape 1- thread (a) obtient le futex F
étape 2- thread (b) demande le futex F et bloque
étape 3- thread (a) libère le futex F
étape 4- thread (b) obtient le futex F et continu

En première approche on peut se dire qu'à l'étape 2 le thread (b) est mis en sommeil. C'est obligatoire pour du mono-cpu. On a un changement de contexte (userland / kernel). Ce changement est cher, 1000 instructions machine voire plus. Sur les systèmes smp et s'il y a plus de cpu que de thread actif, le mieux est de faire tourner le thread (b) en boucle comme ça il continue dès que le futex est dispo.
Sans la pratique, il faut trouver un compromise entre les deux scénarios précédent (mise en sommeil et spinlock). Comme un changement de contexte est cher, on a un mix entre les deux. Lorsqu'un futex est demandé et qu'il est déjà utilisé, on boucle (spinlock) un petit moment (très court) au cas où le futex est libéré durant cette boucle. S'il n'est pas dispo, le thread passe en sommeil. C'est pertinant à faire si la boucle spinlock coûte moins cher qu'une mise en sommeil du thread puis réveille. Lorsque les futex sont pris un très court instant (ce que les développeurs essaient normalement de faire) et sur un système smp, les spinlock offrent un gain important.

J'imagine que durant le bench lorsque nombre de thread <= nombre coeur, lorsqu'un thread demande un futex il l'obtient de suite et s'il boucle dans un spinlock, c'est sans conséquence car sinon le cpu qui exécute le thread n'a rien à faire.
Les performances chutent lorsqu'il y a plus d'un thread par cpu et je pense que lorsqu'un thread demande un futex il ne l'obtient de suite. Le thread est dans le spinlock un très cours instant avant de passer en wait.
Les boucles spinlock sont extrèmement rapides. On a une dizaine d'instruction cpu par boucle. Mais si des options de DEBUG sont activés, ça peut être une tout autre histoire et on peut avoir une centaine d'instruction machine (en fait, j'en sais rien, mais c'est envisagable). On peut imagine que dans ce cas et pour ce bench, les cpu passent beaucoup de temps dans les spinlock.

Sous Fedora par défaut il y a d'activé CONFIG_DEBUG_SPINLOCK et CONFIG_DEBUG_SPINLOCK_SLEEP. Il faudrait un bench sans ses options.

Hummmm non :
http://translate.google.com/translate?u=http%3A%2F%2Flinux.o(...)

Que signifie l'absence du second point d'interrogation ??