Linus aurait choisi CFS plutôt que SD à cause de l'attitude quelque peu « religieuse » de Kolivas et de ses fans (considérer SD comme parfait, nier les problèmes ou troller avec ceux qui rapportent les bugs au lieu d'essayer d'en savoir plus et d'améliorer les choses).
Oui. Je mettais l'accent sur la lenteur des disques (et, dans un autre post, sur l'importance des I/O schedulers plutôt que du scheduler CPU), parce je n'ai pas rencontré les problèmes dont parle Kolivas (lecture audio saccadée à cause d'autres processus qui consomment du temps de calcul, par ex.) depuis plusieurs années sous Linux. Je me suis même demandé si Kolivas a vraiment testé un kernel vanilla (sans les patchs "-ck") récemment.
Par contre j'ai parfois de tels symptômes (audio ou vidéo saccadée, souris et rafraîchissement des fenêtres qui lagguent un peu) lorsqu'un processus en arrière plan consomme beaucoup d'I/O block (ou, cas similaire, lorsque Firefox ou Amarok ont tellement avalé de RAM que le système doit jongler avec la swap, très lente du fait des accès disques).
(ps: briaeros007, tu parle à point nommé des 5400 dans les portables, et comme justement les ventes de portables sont - en proportion avec les ventes de machines desktop classiques - en croissance constante, ça fait de l'utilisation de ce type de disques un cas d'utilisation de plus en plus représentatif du « desktop Linux », je crois. Les disques SSD seront peut-être une bonne solution).
Et vous, avez-vous rencontré ces problèmes de saccade et lenteurs uniquement lié à la répartition CPU (sans grosse charge I/O concomitante), avec des kernels récents et en utilisation « desktop » ?
> la limite a 64 sur Windows est purement artificielle
Clair, c'est d'ailleurs pour ça que Windows est si populaire sur les grands systèmes.
> Quand a IPSEC, bah vu que tout le traffic chez MS est sous IPSEC, faut croire que ca marche plutot bien.
Avec autre chose que du 3DES et MD5 ou SHA-1, et en ESP mode tunnel (pas l2tp hein) ? Pour avoir déployé de l'IPsec sous FreeBSD, OpenBSD, Linux et Windows XP (oui, j'ai pas vu ce qui s'est fait ensuite), j'ai un point de comparaison : Windows est une merde.
> arreter de melanger Win95 et NT si tu veux etre pris au serieux.
On parle de desktop. Avant 2000, la version « desktop » de Windows, c'était NT ou Win95 ?
> T'as Adobe Acrobat pour Linux 64 bits ? Flash peut-etre ? Maya peut-etre alors ? Bon RealPlayer ? Quake 4 alors ?
Seulement des applications propriétaires, dont la moitié ont des équivalents libres (evince, n'importe quel média player), l'autre moitié (quake 4 ou Maya) n'est pas franchement ce qui fait le quotidien moyen de l'utilisateur de desktop). Manque Flash, ok. Pour le reste j'ai environ 15000 applications packagées dans mes dépots: à peut près pareil qu'en x86_32. Désolé de te décevoir, mais on est quelques un à trouver très confortable un environnement totalement libre (donc, n'utilisant aucune des applications que tu cite).
> tu ne sais absolument pas de quoi tu parles.
Ah bah, j'ai cité OpenXML à dessein : avec les specs, contrairement aux logiciels propriétaires, on peut voir les entrailles à l'oeil nu. Et là, mais les sales hacks pour respecter une rétrocompatbilité par impératif commercial (rq, c'est aussi péniblement visible dans les bugs non corrigés d'ie7), le réinventage de roue systèmatique, l'agenda marketing, le bloatage, vous ne pouvez plus les cacher.
>> 1) Tout d'abord il fait le constat que le développement de Linux se focalise sur le marché des serveurs et que le desktop est sacrifié
> Le constat est juste, et Con n'est pas le seul à le dire. Le desktop n'est pas "sacrifié", il n'y a pas autant de ressource que pour le serveur. C'est tout.
Par ailleurs, je me demande si ce n'est pas un peu artificiel d'opposer ainsi desktop et serveur.
Dans bien des cas, les fonctionnalités « serveur » d'hier sont le desktop d'aujourd'hui (par exemple : le réseau, le 64b et le SMP). C'est là qu'on peut apprécier les choix et la vision à long termes des mainteneurs de Linux (d'Unix en général, en fait).
Puisque visiblement les discussion sur ce journal portent souvent sur la comparaison avec Windows, on peut jouer à retracer les décisions pertinentes, à l'époque « orientées serveurs », qui font de Linux un noyau très puissant (je ne parle pas du userland) et de Windows le playskool que l'on connait :
- Le SMP. Il y a 2 ou 3 ans seulement, c'était considéré comme une fonctionnalité purement serveur. Désormais c'est (disons, les CPU multicoeurs) le moyen d'évolution principal annoncé pour les futures CPU, même grand public. Linux supporte le SMP massif depuis longtemps, et a pris une sacrée avance sur Windows dans le domaine (IBM fait tourner des Linux sur des machines à 1024 processeurs, Windows Sever 2003 plafone à 64 CPU, et Vista, c'est du desktop, seulement 2 !), ainsi que dans le calcul distribué (grands clusters, ...).
- Un OS vraiment architecturé pour le réseau (au lieu du TCP/IP ajouté comme un furoncle sur un OS pour dactylos). Si l'on compare les fonctionnalités réseau « avancées » de Windows et de Linux aujourd'hui, on se marre. Néanmoins de nos jours le réseau est considéré comme un compostant standard d'un environnement desktop (plus seulement des serveurs). Pour demain, ce sera IPv6 (Vista le supporte assez mal, parrait-il, sans même parler d'IPsec, Linux a une pile très avancée qui suit quasiment les derniers drafts de RFC au fure et à mesure).
- Un OS multiutilisateur, et un OS utilisant la MMU pour isoler les processus, même sur le desktop. Ok Windows a fini par le faire (mais le multiutilisateur quand presque tout est prévu pour fonctionner à la souris en premier lieu...). Rappelez vous de la « puissance du desktop » Win95. Le fonctionnement multiutilisateur est un élément complètement naturel sous Linux, dès le début, cependant que Microsoft en est encore à batailler pour désapprendre à ses utilisateurs à tout faire tourner en root (en « administrateur », pardon), et sortir des bouts de gui du noyau, c'est dire le chemin restant.
- Le support d'architectures 64 bits. Ça fait pas mal d'années que le « desktop Linux » tourne en 64 bits. Résultat, virtuellement toutes les applis fonctionnent en 64bits sur x86_64 Microsoft n'y arrivera sans doute pas avant longtemps (puisque, notamment, ils n'ont pas habitué les éditeurs tiers à supporter cette architecture : drivers manquants, applications pas portées, cercle vicieux du manque d'utilisateurs qui switchent et donc des éditeurs de logiciels peut encouragés : à mon avis il manquera pendant longtemps des composants cruciaux pour que le bureau Windows 64b soit viable, bien que dés à présent quasiment toutes les CPU x86 pour le desktop peuvent fonctionner en 64bits).
- Une pile SCSI bien soignée. Ça c'était très « serveur » il y a peu, mais aujourd'hui c'est mis à profit et réutilisé pour la gestion du très grand public SATA (et même le PATA en fait) sous Linux. Les développements « serveurs » ont fini par profiter au « desktop ».
- Les gestionnaires de volumes disques (Le LVM). Là encore, une fonctionnalité qui vient des systèmes unix (Linux était assez en retard par rapport à HP-UX ou AIX). L'utilisation « desktop » de LVM est en train d'être redécouverte (chiffrement de volumes/partitions, redimentionnement transparent, snapshots en guise de sauvegardes/"way back machine", ...).
- Le RAID. Une fonctionnalité « très serveur » qu'on trouve désormais salement implémentée en semi-hard sur la plupart des cartes mères desktop, je ne sait pas trop pourquoi d'ailleurs (heureusement, on a une vraie implémentation logicielle dans le noyau qui vaut bien mieux que ça).
- Patches temps réel, high resolution timers, dynticks : ça c'est plutôt l'influence de l'embarqué industriel que celle des serveurs, et c'est pas encore totalement mergé, mais ça fera une sacrée différence sur le « desktop Linux » (lorsque les patchs realtime seront intégrés, le noyau par défaut offrira, pour le traitement de signal/multimédia, une latence extraordinairement faible).
- ...
Donc oui, du gros travail est fait pour les fonctionnalités serveur, et oui, les mainteneurs de Linux sont exigeants là dessus. Mais si, ça profite et profitera au « desktop ». C'est bien l'intérêt d'avoir un noyau qui cherche le « one size fit all », de l'embarqué sur téléphone aux très grands clusters du top500.org.
C'est autre chose qu'un OS où les dirigeants et décideurs sont des services commerciaux, marketing, des actionnaires, où l'on s'impose de conserver une compatibilité arrière avec un ancêtre calamiteux parce que le marché importe plus que la rationalité technique, où l'on est prét à tout dupliquer, réinventer la roue, empiler les quick hacks (bonjour, OpenXML) pour sortir la fonctionnalité wizz bang desktop plus vite, où l'on réimplémente tout pour chaque plateforme un peu différente (Windows CE pour ARM/MIPS, un fork de NT sur ppc pour la xobx, ...). C'est du long terme, quoi. Et on a une terrible avance, les amis :)
Les performances du scheduler en terme d'intéractivité, ce n'est pas tout.
(ps: mais pour être honnête, si l'on compare le merdier de l'audio et des pilotes 3D sous Linux avec ce que font Windows et Mac, on n'est pas au point).
> why does it take longer than ever for our computers to start, for the applications to start and so on?
En grande partie parce que, si les performances des CPU, la vitesse des bus mémoire et ATA, la quantité de mémoire vive, la capacité de stockage, les fonctionnalités (donc la taille) des logiciels ont considérablement augmenté, la rapidité des disques durs, elle, à quasiment stagné. La rapidité des disques durs a un rôle considérable dans le temps de démarrage des application ou de l'OS.
En somme nous subissons les conséquences d'une évolution peu harmonieuse des systèmes informatiques (matériel et logiciel). Ici, l'ordonancement des entrées/sorties, les caches, les queues d'accès disques, le prelinking et l'éditeur de liens dynamique, les systèmes de fichiers, etc. sont certainement plus cruciaux que le bon ordonancement des processus (CPU).
Il me semble que la vitesse et le débit des disques durs grand public (pas SCSI) n'ont même pas doublé en 10 ans.
> [mode mauvaise langue]Même pour MS ça leur fait un scheduler de moins à repomper...)[/mode]
À ce sujet, et parce que j'ai lu plus haut des remarque laissant entendre que le noyau (ou seulement l'ordonanceur ?) de Windows était meilleur que celui de Linux, une petite info pour relativiser.
Il est tout à fait clair que les développeurs du noyau Linux essaient de trouver un ordonanceur CPU (mais aussi un ordonanceur pour les E/S, ce qui est encore plus important) qui marche le mieux possible pour tout le monde, y compris les desktops et les serveurs, de façon propre, maintenable et globale. Donc pas de hacks/cochonneries, bien que ce soit facile et tentant d'en introduire à ce niveau.
Voici comment Windows (et Solaris) s'y prend, selon la description du développeur de l'ordonanceur « ULE » de FreeBSD, Jeff Robberson :
« Solaris and windows actually both hook into the window manager. The window manager tells the scheduler which x task or windows application is in the foreground. The scheduler then uses this to give an extra boost to those tasks. » (source : http://jeffr-tech.livejournal.com/6602.html ).
Ou, si vous préferez une source plus officielle ( http://www.microsoft.com/mspress/books/sampchap/4354c.aspx ) : « The foreground process is the process that owns the thread that owns the window that's in focus. When the foreground window changes to one owned by a thread in a process higher than the Idle priority class, the Win32 subsystem changes the quantum values for all the threads in that process [...] » (etc., lire le reste de la page).
En bref et en français: le noyau Windows ne « devine » pas vraiment quelles sont les taches interactives à privilégier. L'environnement graphique de Windows indique au noyau le processus dont la fenêtre graphique a le focus, pour que le noyau lui donne une plus grande priorité.
C'est pour le moins inélégant, et c'est une solution à courte vue pour améliorer l'interactivité en environnement graphique fenêtré (windows...), qui n'améliorera en rien le fonctionnement sur des serveurs, par exemple (à l'inverse d'une solution totalement algorithmique pour trouver quel processus mérite du temps CPU sans sale hack, comme Linux essaie de faire) ! Et ce n'est certainement pas adapté à un environment souple et non-monolhitique comme Linux, où l'environement/interface utilisateur n'est pas un « builtin » indélogeable, mais peut être de natures très différentes, nativement réseau et multiutilisateur (X11, protocole X en réseau, console, framebuffer, qtpe, tinyx, ...: il faudrait implémenter ce sale hack partout, et en pondérant l'usage simultané de plusieurs d'entre eux ou par plusieurs utilisateurs, et faire transiter une telle information sur le réseau,...).
>> 3) Mais les autres développeurs n'incorporent pas son code en mainline car ils se fichent complètement des performances desktop
> Ce qui est faux. Beaucoup (peut-être insuffisament) a été fait pour les performances du desktop.
Et aussi, dans cette interview, Kolivas glisse parfois de ses préoccupations particulières vers un jugement d'ordre très général concernant, pour résumer, « la qualité du desktop sous Linux pour l'utilisateur lambda ». Or son travail porte essentiellement sur un aspect très spécifique de « l'expérience desktop », à savoir les rapports entre la latence et l'intéractivité. C'est une dimension très importante, mais est-ce tout ? est-ce seulement l'essentiel ?
De ce que je peut entendre et lire (par exemple sur linuxfr), il me semble franchement que les utilisateurs finaux de desktops sous Linux sont bien plus souvent préoccupés par les problèmes de support du matériel (cartes graphiques et accélération 3D, cartes wifi, imprimantes, webcams, ...) ou de codecs, que du punch de leur ordonanceur. (évaluation herodiade, certifiée "à la louche"(c) ;-).
Il est même peut-être hasardeux de réduire la question des « performances desktop » à l'ordonanceur ou au pré-chargement de la mémoire virtuelle (par exemple ce n'est pas forcément ce qui compte le plus pour les « performances » du rendu 3D d'un jeux, ou le décodage d'un flux h264, ...). L'interactivité a en outre le désavantage d'être difficile à mesurer (ce qui explique surement une bonne part de ce que Kolivas considère comme un manque d'intérêt des autres développeurs pour son travail, il le reconnaît mais sous-estime peut-être un peu l'influence de ce facteur sur les décisions).
> Notons que Xen a été refusé (il n'y a qu'une partie de Xen qui vient d'être accèptée)
Quelqu'un aurait plus d'infos sur les projets de merge / l'état d'avancement de la partie restante (si je ne me trompe, c'est tout le support pour dom0 qui n'est pas entré durant la fenêtre des gros merges du 2.6.23) ?
Et à titre indicatif, un ordre d'idée de l'investissement actuel des diverses grandes sociétés dans le noyau Linux, en nombre de développeurs employés.
Je compte ici le nombre de développeurs distincts utilisant une email contenant le nom d'une de ces grosses sociétés et dont au moins un patch a été mergé dans le git de Linus entre la sortie du 2.6.22 et aujourd'hui. Ces chiffres ne sont pas précis ni très justes (par exemple certains développeurs n'utilisent pas leur email corporate dans les patchs, ...), c'est plutôt pour avoir un ordre de grandeur et de comparaison approximatif (pour des chiffres plus précis cf. LWN, où J. Corbet publie des études pointues) :
Sa remarque concernant les priorité des développeurs (et surtout, de leurs employeurs) est intéressante, et semble assez juste lorsqu'on considère les employeurs jusqu'à cette année (ou, disons, jusqu'en 2006) :
- Oracle et IBM emploient beaucoup de développeurs, et il est très clair que le desktop n'est pas vital pour le business autour de Linux.
- La RHEL de Red Hat n'était peut-être pas non plus très desktop-centrique (?)
- Je crois qu'Intel employait surtout du monde pour le SMP, leurs (mauvais) chipsets RAID, l'architecture Itanium etc.
- Rien à voir avec les priorités du monde corporate, mais le verrouillage de XFree86 ralentissait lourdement les progrès aussi.
Mais il semble qu'ironiquement, c'est au moment où Con Kolivas nous quitte que les priorités basculent (en fait ça à commencé un peu plus tôt, mais les fruits commencent à peine à être récoltés, ie. dynticks, network-manager, l'ordonanceur CFS qui vient à peine d'être intégré dans 2.6.23, mac80211, ...), en particulier grâce au monde de la mobilité bon marché :
- Intel emploie une _foultitude_ de développeurs pour travailler spécifiquement sur le desktop, comme : les principaux développeurs de Xorg, du sous-système drm/dri du kernel, l'économie d'énergie, les principaux développeurs du nouveau framework wifi du noyau (mac80211 et cfg80211), vient de lancer une plateforme semi mobile (moblin), etc. Leur investissement dans "Linux pour le desktop" semble croitre à grande échelle, de jours en jours.
- Red Hat est fortement impliqué dans le projet OLPC (totalement "desktop"), et sort une version de son produit commercial, RHEL5, spécialement orientée desktop (sans parler de leur fort investissement dans Fedora). Ils ont aussi lancé à grands efforts le projet "Mugshot"/Global Desktop. Ils sont aussi l'employeur d'Ingo Molnar, qui a consacré pas mal de temps sur dynticks et sur le nouvel ordonnanceur "fair" CFS (n'en déplaise à CK).
- Ubuntu gagne en popularité, en nombre d'utilisateurs finaux (ce qui doit probablement secouer les à priori et priorités des distros plus anciennes et traditionnellement plus orientées "serveur"). Et Ubuntu dispose désormais de quelques développeurs noyau actifs (or le succès sur le desktop est clairement une priorité stratégique pour Canonical/Ubuntu).
- Apparition de sociétés qui développent essentiellement des produits pour le desktop libre (par ex. autour de Gizmo, Gstreamer, ...)
- L'affaire Dell + Linux a certainement du montrer aux constructeurs que les enjeux (ne serait-ce qu'en terme d'image auprès des "leader d'opinions" que nous sommes) de Linux concernent aussi les produits très "grand public".
La (récente) disponibilité de chipsets mobiles très bon marchés (autour des AMD Geode ou Intel Dothan) permet depuis peu de produire des ordinateurs ultramobiles à très bas prix, où le cout de l'OS est donc extrêmement sensible et significatif : du fait de son prix, Linux a une superbe fenêtre pour s'imposer sur le desktop par ce biais.
À mon avis, c'est ce qu'on compris les boites qui emploient maintenant de nombreux devs pour travailler sur la mobilité et le desktop (Intel et ses projets moblin/classmate/asus eee, Ubuntu et sa future version "semi-embarquée", openmoko, ...)..
D'un autre coté, la cadence d'horloge d'une montre à aiguille est de 1 Hz. Ce qui en fait des machines assez modestes, comparées aux ordinateurs récents, je trouve (sauf les couteuses Rolex).
3 à 5 Watts selon le lien digg dans le journal (5W selon le site de l'engin : http://www.fit-pc.com/ ).
Ce chiffre me semble peu réaliste, voir franchement mensonger, d'autant que la machine inclue un vrai disque dur (pas du SD/CF), une carte graphique et un bus USB (des périphériques assez gourmands).
Pour comparaison, un portable de bonne qualité, finement tuné contre la consommation, écran éteint, réseau coupé, dans le plus bas P-State ACPI (la fréquence la plus basse que le proc supporte) et complétement idle (C-state ACPI C4 99.9 % du temps, c'est à dire que même le cache de la CPU est éteint) se situe généralement aux alentours de 10W, jamais moins de 7W (un exemple : http://thinkwiki.org/wiki/Idle_consumptions ).
Ah et bien justement, on parle de ça dans l'édition du LWN ouverte au public aujourd'hui[1].
Il serait vraiment intéressant que quelqu'un rédige un article sur la programmation économe en énergie pour linuxfr (ou mieux Linux Magazine) : utilisation des évènements plutôt que polls réguliers, utilisation de hal, de inotify ou de gamin, des timers regroupés, regroupement des accès aux block devices, réduction des animations graphiques (elles réveillent xorg), stracer régulièrement son application juste pour vérifier qu'elle ne fait vraiment rien lorsqu'elle est au repos, utiliser le système de notification d'Alsa (plutôt que poller le mixer), audit et disagnostic avec block_dump, strace, ltrace, powertop, lm-profiler et blktrace, ...
Les ventes de portables par an ont maintenant dépassé les ventes de stations de bureau[2][3] : la consommation est donc devenue une problématique majeure pour le succès de « Linux sur le desktop ». Et Linux est une option considérée depuis peu avec beaucoup d'attention par les intégrateurs, maintenant - c'est récent - qu'ils disposent de chipsets x86 mobiles tout-en-un à très bas prix : le coût d'une licence Windows sur le portable final est dans ce cas proportionnellement très significatif. C'est probablement un critère déterminant dans le choix de Linux pour l'Asus EEPC, l'Intel Classmate ou encore l'OLPC, et de l'investissement d'Intel (qui commercialise de tels chipsets bons marché) qui paye des développeurs comme Arjan van de Ven pour travailler à plein temps sur la consommation électrique de Linux.
Linux dispose d'une belle perspective pour s'imposer à travers ce nouveau marché des portables (en particulier des ultraportables à bas prix), mais il faut pour cela qu'on apprenne à programmer de façon économe. Jusqu'à présent, on ne considérait pas vraiment cet aspect spécifique, au coté, par exemple, des améliorations des performances ou de la consommation de mémoire vive. Mais les développeurs noyau essaient d'attirer notre attention sur ce sujet[4].
En même temps, sur le fond, il n'a pas tord. Les gens sont souvent intimidés par l'idée de faire un rapport de bug pour le noyau : c'est dommage. Si vous pensez n'avoir pas assez d'informations à reporter, les développeurs vous indiqueront comment obtenir les informations utiles.
L'idéal serait peut-être que Grégory fasse un git-bissect, qui permettrai de trouver l'exact patch fautif. Bissecter entre les noyaux 2.6.21 et 2.6.22 (environ 7000 patches) demande 13 recompiles & reboots (+1 pour tester le 2.6.22 avec le seul patche fautif reverté). Un peu long (surtout les recompiles), mais pas insurmontable.
C'est pour ça qu'il faut compter les lignes avec un utilitaire comme sloccount : il ne compte que les lignes de code, et zappe les fichiers autres que le code (makefiles, doc, ...), et les lignes de commentaires.
C'est déjà le cas. Il y a dans le noyau, depuis la version 2.6.19 (ou 2.6.20 ?) les fonctions round_jiffies() et round_jiffies_relative() qui arrondissent à la seconde pleine les valeurs de jiffies passées en argument.
L'idée est que dans de très nombreux cas, on a besoin de programmer une tâche dans le futur, ou à intervalle régulier, mais on n'a pas nécessairement besoin que la date d'exécution de cette tache soit vraiment précise à la fraction de seconde près. On souhaite seulement que « cet (évènement|tache à exécuter) ai lieu approximativement (dans|toutes les) X seconde(s) ».
Ainsi, si nous avions 10 pilotes de périphériques différents qui programmaient l'exécution d'une tâche toutes les secondes environ, mais n'avaient pas initialisé leurs timers en même temps (ou bien avec un intervalle légèrement différent), ils réveillaient le noyau 10 fois par seconde. Si ces 10 pilotes sont modifiés pour programmer leur réveil à une date arrondie avec round_jiffies, ils s'exécuteront en même temps, causant un seul réveil par seconde (un seul réveil à la seconde entière, qui, au passage, aurai de toutes façon eu lieu, même en l'absence de ces 10 pilotes, car il y a déjà d'autres choses converties au round_jiffies).
Il reste beaucoup de travail pour tirer pleinement parti de cette nouvelle API partout où le noyau pourrait le faire, mais certains y travaillent visiblement, et chaque petite conversion réduit le nombre de réveils par seconde dont le noyau à besoin.
Note : s'il y a des développeurs GTK/Gnome dans le coin : c'est exactement comme g_timeout_add_seconds_full() ou g_timeout_add_seconds() (au lieu de g_timeout_add()). Cette fonction permet d'économiser de l'énergie en réduisant les réveils de la CPU, car elle regroupe tout les évènements programmés à la prochaine seconde entière. Svp, si vous n'avez pas besoin d'une granularité/précision très fine, par ex. si vous avez besoin de programmer une action « approximativement toutes les X secondes », préférez utiliser celle-ci au lieu de g_timeout_add().
> entre parenthèse la liste des régressions du 2.6.22 me semble minuscule par rapport à l'ampleur des changements
Remarque qu'il ne s'agit que des régressions connues : le noyau est toujours mieux testé juste après la sortie d'une nouvelle version (malheureusement !). Et il ne s'agit (presque) que de régressions, les bugs touchant des nouvelles fonctionnalités ou architectures ne sont pas des régressions. Pendant la phase de développement cette liste a été très longue, par moments. Elle a effectivement été sérieusement réduite (preuve, peut-être, de son efficacité : les problèmes n'ont pas été négligés).
Je suis moins optimiste en ce qui concerne l'ancienne couche Wi-Fi : je n'ai pas l'impression que qui que ce soit travaille à l'adaptation des pilotes prism2.5 ou encore ipw2200, par exemple. Peut-être parce que mac80211 n'est (ou du moins n'était, récemment) pas encore tout à fait adapté aux chipsets fullmac (me semble-t-il avoir lu, je ne suis pas 100% sur que ce soit toujours vrai), et qu'il suffira d'attendre quelques mois de maturation. Peut-être aussi parce qu'il est difficile de restructurer complètement un logiciel éprouvé par le temps sans causer de grosses régressions.
Mais il ne faut pas oublier qu'un certain nombre d'entre eux furent développées en interne par des sociétés commercialisant le chipset mais ne donnant pas les specs, ou sous NDA seulement, et qu'Intel, par exemple, n'a aucune envie de consacrer des ressources pour re-développer un produits qu'ils ne vendent plus, alors qu'il est tellement plus simple d'encourager les utilisateurs à changer de matériel. Quand on disait que « donner les specs, sans NDA, c'est beaucoup mieux que donner un driver GPL » ...
J'aime en particulier la question déontologique (voir légale) soulevée par David.Monniaux : si les étudiants de Sciences Po' veulent évaluer la rapidité des services de nettoyage municipaux, ils vont graffer les murs de la ville ? S'ils veulent tester la rapidité de la police, vont-ils voler des sacs à main ?
Sinon, notez que Pierre Assouline est acharné détracteur de Wikipédia, de longue date, et qu'il est journaliste (ce qui explique probablement que Libé se fasse echo d'un simple exposé d'étudiants peu sérieux, copinages, ...).
Maintenant que la liste des régression connues est maintenue sur un site web, ce serait bien d'inclure le lien dans les dépêches relatives à la sortie de nouvelles versions du noyau : http://kernelnewbies.org/known_regressions
Quelques précisions et compléments d'informations, en vrac :
* Puisqu'on parle de la liste des régressions. Adrian Bunk maintenait une telle liste durant les derniers mois, qu'il postait chaque semaine sur LKML. Fâché de l'insuccès de son travail (il considère que le 2.6.21 n'aurait pas du sortir en l'état), Bunk a décidé d'abandonner cette tache ingrate, au grand dam des autres développeurs (y compris de Linus) (cf. http://kerneltrap.org/node/8110 ). À cette occasion Google a rappelé qu'ils cherchent à embaucher un « bug master » pour le noyau Linux. Finalement Michal Piotrowski a pris les choses en main et maintient une liste des régression dans un wiki (à l'adresse citée plus haut).
* La nouvelle couche Wi-Fi (<- ça s'écrit comme ceci en fait) s'appelle mac80211 (ou encore d80211). Outres les fonctionnalités citées dans la dépêche, elle mutualise une implémentation MAC logicielle commune pour les divers pilotes, souvent nécessaire avec les chipsets modernes et sots, dits « softmac ». Son intégration dans le noyau standard a parait-il permis de la stabiliser, et simplifiera grandement l'intégration des pilotes récents (nombreux sont ceux qui l'utilisait déjà auparavant, bien qu'elle n'était pas incluse dans le noyau), comme iwlwifi (Intel 4965AGN), les pilotes ralink rt2x00, le nouveau pilote pour le chipset Marvel Libertas, le Broadcom bcm43xx, et bien d'autres. L'ancienne couche Wi-Fi (qui s'appelle ieee80211) est conservée dans le noyau (de nombreux « vieux » pilotes l'utilisent). La perspective d'une telle cohabitation - et du travail de maintenance qui s'en trouve doublé - fut la cause de nombreux débats sur les listes de diffusion. Remarquez aussi que l'API de configuration WEXT du ieee80211 est rendue obsolète par le nouveau mécanisme nommé cfg80211, basé sur netlink (API nl80211). Une couche de compatibilité est toutefois maintenue (avec l'aide, si je me souviens bien, d'une bibliothèque en espace utilisateur).
* La nouvelle couche FireWire (<- ça s'écrit ainsi) est certes plus dense (moins de lignes de codes) mais n'est pas tout à fait complète encore. Par exemple l'eth1394 (émulation ethernet sur FireWire) n'est pas encore porté, si vous utilisez cette fonctionnalité, attendez encore un peu.
Matt Dillon est le « Linus Torvalds » (ou le « Theo de Raadt » si vous préférez, bref, le lead developer quoi) de DragonFlyBSD et fut un de contributeurs majeur de la VM de FreeBSD (travaille qui le qualifie justement pour évaluer l'impact de certains de ces bugs), cf. http://en.wikipedia.org/wiki/Matt_Dillon_%28computer_scienti(...)
Il a livré un rapide commentaire sur les principaux bugs dévoilés dans les récentes erratas d'Intel :
- Ici celles concernant les Core 2, dont ne parle pas vraiment le message de TdR (en dépit du titre de son email) : http://hardware.slashdot.org/comments.pl?sid=242663&cid=(...)
(et qui font dire à Dillon, au sujet des core/core2 duo : « So, in summary, AE3 scares the hell out of me, and for the others AE5, AE8, AE21, and AE30 look serious. »).
Notez que les descriptions des problèmes dans l'errata d'Intel semblent souvent très vagues (d'où des incertitudes dans l'appréciation des conséquences possibles, selon les développeurs).
Concernant la possibilité de corriger ces problèmes par upgrade du microcode, donnez vous la peine de regarder le pdf d'Intel : la plupart de ces bugs sont marqués : "Plan : No Fix".
dans le cas des core2duo, la mise a jour pour corriger les bugs étaient relativement aisé
À condition que tout ces problèmes soit corrigeables par mise à jour du microcode.
Lorsqu'on parle de la nécessité de mettre à jour le BIOS, dans notre cas, il peut s'agir seulement de ça (le BIOS contenant aussi le microcode, et donc là pas de problème on sait aussi le mettre à jour depuis l'OS), ou bien d'un changement ou d'un workaround pour contourner le bug très différent (le BIOS, ce n'est pas que le microcode hein).
A tu des elements de comparaisons pour dire qu'il y a plus de bugs que dans les versions precedentes/chez les concurents ?
Ce n'est généralement pas comme ça qu'on procède dans le domaine de la sécu informatique : on parle des bugs connus (« n'utilisez pas le produit x version y pour faire telle chose, il présente des déficiences notable sur le plan sécurité »). Ne serait-ce que pour encourager ceux qui maintiennent le produit à corriger leur failles prompto (et à tacher d'éviter d'en faire d'autres du même genre la prochaine fois), ou permettre à ceux qui utilisent le produit de ne pas tomber dans le cas d'utilisation qui expose le problème. Le boulot des journalistes et des professionnels de la sécurité informatique est de nous avertir pour faire bouger les choses : Cyrix, qui produisait des procs sensiblement buggués en sait quelque chose : ils l'ont senti passer, et heureusement qu'on n'a pas gardé le silence.
Deuxièmement, on parle ici d'un type de bugs un peu particulier, surtout pour le monde du matériel : ce sont des bugs ayant un potentiel fort d'impact sur la sécurité.
Concernant les hypothétiques mais probables bugs « dont on ne sait rien », on peut bien sûr se perdre en conjectures... mais est-ce bien utile ? ça ne l'est surement pas s'il s'agit de dédouaner ceux dont les bugs sont connus !
Tout les cores aussi complexe que les x86 ont forcement des bugs
Et ? faut-il s'abstenir de faire état des problèmes dont on apprend l'existence ? Tu imagine si nous réagissions comme ça pour le logiciel « (n'en parlons pas | ne jetons pas la pierre ) parce que tout logiciel de plus de 1000 lignes contient forcément des bugs » ?
Certains fournisseurs ne publient pas les bugs
Souhaitons que quelques bonnes vieilles full disclosure vienne leur boter le train. Encore une fois, le précédent de Cyrix devrait les inciter à la prudence (je pense à ce sujet qu'AMD est méchamment sur le déclin, et depuis leur rachat d'ATI ils sont sur ma liste noire de constructeurs travaillant comme des cochons, ne filant ni specs ni code libre pour leurs chipsets).
>> tu peux avoir besoin d'interagir avec des modules sous licence incompatibles
> ah, oui effectivement, ça peut être gênant avec la licence PHP c'est ce à quoi tu penses ?
J'ai pensé à ça immédiatement aussi, et aux licences de PEAR et à celle de python, ... mais surtout à la GPLv2. Avec autant de restrictions, ça va être difficile d'utiliser AGPL.
Je ne comprend pas ton argument plus haut, où tu me répond que restreindre la compatibilité à la "v3 ou plus" seulement (au lieu de v2 ou plus) simplifie les choses.
Si des développeurs choisissent la GPLv2 plutôt que la GPLv3, c'est peut être pas par « misunderstandings », comme dirait Eben Moglen, mais peut-être parce que le code était là avant la v3, ou par choix personnel en toute conscience. Tenter de leur forcer la main en créant une incompatibilité arbitraire et articifielle... c'est vraiment les prendre pour des cons.
Mais on parle bien de critiques venant de « libristes » : Linus (quand même), et même mes modestes réserves (pas vraiment des critiques), à moins que tu ne me considère comme un social-traitre (pas très sympa) ?
Personnellement je pense qu'adopter une lecture critique - sans refreiner son enthousiasme lorsqu'on a pesé les arguments - est salutaire. Une lecture critique, ce n'est pas une contestation, ce n'est pas diminuer la grandeur de nos leaders (la FSF, Linus, ...), c'est simplement se réserver le droit de penser par soi même. La FSF mérite mieux que des gens qui accepterai tout sans réfléchir.
> - ils partagent le même idéal, mais ne sont pas d'accord avec la méthode utilisée.
C'est tout à fait ce que je voulais dire, entre linuxfriens nous partageons généralement les mêmes idéaux, mais il n'y a pas de raisons que nous ne discutions pas de la méthode adaptée pour y parvenir.
> (l'exemple de Bush était peut-être un peu trop fort), mais d'opinions et d'idéaux.
Dans ce très récent et très intéressant thread : http://kerneltrap.org/node/8382
Linus Torvalds utilise aussi l'administration Bush pour une métaphore :
And then the FSF has the gall to call themselves the "protector of
freedoms", and claim that everybody else is evil. What a crock.
[...]
I don't know if you've followed US politics very much over the last six
years, but there's been a lot of "protecting our freedoms" going on. And
it's been ugly. Maybe you could realize that sometimes "protecting your
freedom" is *anything*but*!
Linus
# Explications de Linus Torvalds
Posté par herodiade . En réponse au journal L'interview vérité de Con Kolivas. Évalué à 2.
Cf. http://kerneltrap.org/node/14008
[^] # Re: Super interview
Posté par herodiade . En réponse au journal L'interview vérité de Con Kolivas. Évalué à 3.
Par contre j'ai parfois de tels symptômes (audio ou vidéo saccadée, souris et rafraîchissement des fenêtres qui lagguent un peu) lorsqu'un processus en arrière plan consomme beaucoup d'I/O block (ou, cas similaire, lorsque Firefox ou Amarok ont tellement avalé de RAM que le système doit jongler avec la swap, très lente du fait des accès disques).
(ps: briaeros007, tu parle à point nommé des 5400 dans les portables, et comme justement les ventes de portables sont - en proportion avec les ventes de machines desktop classiques - en croissance constante, ça fait de l'utilisation de ce type de disques un cas d'utilisation de plus en plus représentatif du « desktop Linux », je crois. Les disques SSD seront peut-être une bonne solution).
Et vous, avez-vous rencontré ces problèmes de saccade et lenteurs uniquement lié à la répartition CPU (sans grosse charge I/O concomitante), avec des kernels récents et en utilisation « desktop » ?
[^] # Re: Regrettable
Posté par herodiade . En réponse au journal L'interview vérité de Con Kolivas. Évalué à 9.
Clair, c'est d'ailleurs pour ça que Windows est si populaire sur les grands systèmes.
> Quand a IPSEC, bah vu que tout le traffic chez MS est sous IPSEC, faut croire que ca marche plutot bien.
Avec autre chose que du 3DES et MD5 ou SHA-1, et en ESP mode tunnel (pas l2tp hein) ? Pour avoir déployé de l'IPsec sous FreeBSD, OpenBSD, Linux et Windows XP (oui, j'ai pas vu ce qui s'est fait ensuite), j'ai un point de comparaison : Windows est une merde.
> arreter de melanger Win95 et NT si tu veux etre pris au serieux.
On parle de desktop. Avant 2000, la version « desktop » de Windows, c'était NT ou Win95 ?
> T'as Adobe Acrobat pour Linux 64 bits ? Flash peut-etre ? Maya peut-etre alors ? Bon RealPlayer ? Quake 4 alors ?
Seulement des applications propriétaires, dont la moitié ont des équivalents libres (evince, n'importe quel média player), l'autre moitié (quake 4 ou Maya) n'est pas franchement ce qui fait le quotidien moyen de l'utilisateur de desktop). Manque Flash, ok. Pour le reste j'ai environ 15000 applications packagées dans mes dépots: à peut près pareil qu'en x86_32. Désolé de te décevoir, mais on est quelques un à trouver très confortable un environnement totalement libre (donc, n'utilisant aucune des applications que tu cite).
> tu ne sais absolument pas de quoi tu parles.
Ah bah, j'ai cité OpenXML à dessein : avec les specs, contrairement aux logiciels propriétaires, on peut voir les entrailles à l'oeil nu. Et là, mais les sales hacks pour respecter une rétrocompatbilité par impératif commercial (rq, c'est aussi péniblement visible dans les bugs non corrigés d'ie7), le réinventage de roue systèmatique, l'agenda marketing, le bloatage, vous ne pouvez plus les cacher.
[^] # Re: Regrettable
Posté par herodiade . En réponse au journal L'interview vérité de Con Kolivas. Évalué à 10.
> Le constat est juste, et Con n'est pas le seul à le dire. Le desktop n'est pas "sacrifié", il n'y a pas autant de ressource que pour le serveur. C'est tout.
Par ailleurs, je me demande si ce n'est pas un peu artificiel d'opposer ainsi desktop et serveur.
Dans bien des cas, les fonctionnalités « serveur » d'hier sont le desktop d'aujourd'hui (par exemple : le réseau, le 64b et le SMP). C'est là qu'on peut apprécier les choix et la vision à long termes des mainteneurs de Linux (d'Unix en général, en fait).
Puisque visiblement les discussion sur ce journal portent souvent sur la comparaison avec Windows, on peut jouer à retracer les décisions pertinentes, à l'époque « orientées serveurs », qui font de Linux un noyau très puissant (je ne parle pas du userland) et de Windows le playskool que l'on connait :
- Le SMP. Il y a 2 ou 3 ans seulement, c'était considéré comme une fonctionnalité purement serveur. Désormais c'est (disons, les CPU multicoeurs) le moyen d'évolution principal annoncé pour les futures CPU, même grand public. Linux supporte le SMP massif depuis longtemps, et a pris une sacrée avance sur Windows dans le domaine (IBM fait tourner des Linux sur des machines à 1024 processeurs, Windows Sever 2003 plafone à 64 CPU, et Vista, c'est du desktop, seulement 2 !), ainsi que dans le calcul distribué (grands clusters, ...).
- Un OS vraiment architecturé pour le réseau (au lieu du TCP/IP ajouté comme un furoncle sur un OS pour dactylos). Si l'on compare les fonctionnalités réseau « avancées » de Windows et de Linux aujourd'hui, on se marre. Néanmoins de nos jours le réseau est considéré comme un compostant standard d'un environnement desktop (plus seulement des serveurs). Pour demain, ce sera IPv6 (Vista le supporte assez mal, parrait-il, sans même parler d'IPsec, Linux a une pile très avancée qui suit quasiment les derniers drafts de RFC au fure et à mesure).
- Un OS multiutilisateur, et un OS utilisant la MMU pour isoler les processus, même sur le desktop. Ok Windows a fini par le faire (mais le multiutilisateur quand presque tout est prévu pour fonctionner à la souris en premier lieu...). Rappelez vous de la « puissance du desktop » Win95. Le fonctionnement multiutilisateur est un élément complètement naturel sous Linux, dès le début, cependant que Microsoft en est encore à batailler pour désapprendre à ses utilisateurs à tout faire tourner en root (en « administrateur », pardon), et sortir des bouts de gui du noyau, c'est dire le chemin restant.
- Le support d'architectures 64 bits. Ça fait pas mal d'années que le « desktop Linux » tourne en 64 bits. Résultat, virtuellement toutes les applis fonctionnent en 64bits sur x86_64 Microsoft n'y arrivera sans doute pas avant longtemps (puisque, notamment, ils n'ont pas habitué les éditeurs tiers à supporter cette architecture : drivers manquants, applications pas portées, cercle vicieux du manque d'utilisateurs qui switchent et donc des éditeurs de logiciels peut encouragés : à mon avis il manquera pendant longtemps des composants cruciaux pour que le bureau Windows 64b soit viable, bien que dés à présent quasiment toutes les CPU x86 pour le desktop peuvent fonctionner en 64bits).
- Une pile SCSI bien soignée. Ça c'était très « serveur » il y a peu, mais aujourd'hui c'est mis à profit et réutilisé pour la gestion du très grand public SATA (et même le PATA en fait) sous Linux. Les développements « serveurs » ont fini par profiter au « desktop ».
- Les gestionnaires de volumes disques (Le LVM). Là encore, une fonctionnalité qui vient des systèmes unix (Linux était assez en retard par rapport à HP-UX ou AIX). L'utilisation « desktop » de LVM est en train d'être redécouverte (chiffrement de volumes/partitions, redimentionnement transparent, snapshots en guise de sauvegardes/"way back machine", ...).
- Le RAID. Une fonctionnalité « très serveur » qu'on trouve désormais salement implémentée en semi-hard sur la plupart des cartes mères desktop, je ne sait pas trop pourquoi d'ailleurs (heureusement, on a une vraie implémentation logicielle dans le noyau qui vaut bien mieux que ça).
- Patches temps réel, high resolution timers, dynticks : ça c'est plutôt l'influence de l'embarqué industriel que celle des serveurs, et c'est pas encore totalement mergé, mais ça fera une sacrée différence sur le « desktop Linux » (lorsque les patchs realtime seront intégrés, le noyau par défaut offrira, pour le traitement de signal/multimédia, une latence extraordinairement faible).
- ...
Donc oui, du gros travail est fait pour les fonctionnalités serveur, et oui, les mainteneurs de Linux sont exigeants là dessus. Mais si, ça profite et profitera au « desktop ». C'est bien l'intérêt d'avoir un noyau qui cherche le « one size fit all », de l'embarqué sur téléphone aux très grands clusters du top500.org.
C'est autre chose qu'un OS où les dirigeants et décideurs sont des services commerciaux, marketing, des actionnaires, où l'on s'impose de conserver une compatibilité arrière avec un ancêtre calamiteux parce que le marché importe plus que la rationalité technique, où l'on est prét à tout dupliquer, réinventer la roue, empiler les quick hacks (bonjour, OpenXML) pour sortir la fonctionnalité wizz bang desktop plus vite, où l'on réimplémente tout pour chaque plateforme un peu différente (Windows CE pour ARM/MIPS, un fork de NT sur ppc pour la xobx, ...). C'est du long terme, quoi. Et on a une terrible avance, les amis :)
Les performances du scheduler en terme d'intéractivité, ce n'est pas tout.
(ps: mais pour être honnête, si l'on compare le merdier de l'audio et des pilotes 3D sous Linux avec ce que font Windows et Mac, on n'est pas au point).
[^] # Re: Super interview
Posté par herodiade . En réponse au journal L'interview vérité de Con Kolivas. Évalué à 2.
Tu en connais beaucoup, toi, des disques durs SATA ou PATA qui délivrent 300 MB/s ?
[^] # Re: Super interview
Posté par herodiade . En réponse au journal L'interview vérité de Con Kolivas. Évalué à 3.
En grande partie parce que, si les performances des CPU, la vitesse des bus mémoire et ATA, la quantité de mémoire vive, la capacité de stockage, les fonctionnalités (donc la taille) des logiciels ont considérablement augmenté, la rapidité des disques durs, elle, à quasiment stagné. La rapidité des disques durs a un rôle considérable dans le temps de démarrage des application ou de l'OS.
En somme nous subissons les conséquences d'une évolution peu harmonieuse des systèmes informatiques (matériel et logiciel). Ici, l'ordonancement des entrées/sorties, les caches, les queues d'accès disques, le prelinking et l'éditeur de liens dynamique, les systèmes de fichiers, etc. sont certainement plus cruciaux que le bon ordonancement des processus (CPU).
Il me semble que la vitesse et le débit des disques durs grand public (pas SCSI) n'ont même pas doublé en 10 ans.
[^] # Les « mérites » de l'ordonanceur de MS Windows [was Re: BSD ]
Posté par herodiade . En réponse au journal L'interview vérité de Con Kolivas. Évalué à 7.
À ce sujet, et parce que j'ai lu plus haut des remarque laissant entendre que le noyau (ou seulement l'ordonanceur ?) de Windows était meilleur que celui de Linux, une petite info pour relativiser.
Il est tout à fait clair que les développeurs du noyau Linux essaient de trouver un ordonanceur CPU (mais aussi un ordonanceur pour les E/S, ce qui est encore plus important) qui marche le mieux possible pour tout le monde, y compris les desktops et les serveurs, de façon propre, maintenable et globale. Donc pas de hacks/cochonneries, bien que ce soit facile et tentant d'en introduire à ce niveau.
Voici comment Windows (et Solaris) s'y prend, selon la description du développeur de l'ordonanceur « ULE » de FreeBSD, Jeff Robberson :
« Solaris and windows actually both hook into the window manager. The window manager tells the scheduler which x task or windows application is in the foreground. The scheduler then uses this to give an extra boost to those tasks. » (source : http://jeffr-tech.livejournal.com/6602.html ).
Ou, si vous préferez une source plus officielle ( http://www.microsoft.com/mspress/books/sampchap/4354c.aspx ) : « The foreground process is the process that owns the thread that owns the window that's in focus. When the foreground window changes to one owned by a thread in a process higher than the Idle priority class, the Win32 subsystem changes the quantum values for all the threads in that process [...] » (etc., lire le reste de la page).
En bref et en français: le noyau Windows ne « devine » pas vraiment quelles sont les taches interactives à privilégier. L'environnement graphique de Windows indique au noyau le processus dont la fenêtre graphique a le focus, pour que le noyau lui donne une plus grande priorité.
C'est pour le moins inélégant, et c'est une solution à courte vue pour améliorer l'interactivité en environnement graphique fenêtré (windows...), qui n'améliorera en rien le fonctionnement sur des serveurs, par exemple (à l'inverse d'une solution totalement algorithmique pour trouver quel processus mérite du temps CPU sans sale hack, comme Linux essaie de faire) ! Et ce n'est certainement pas adapté à un environment souple et non-monolhitique comme Linux, où l'environement/interface utilisateur n'est pas un « builtin » indélogeable, mais peut être de natures très différentes, nativement réseau et multiutilisateur (X11, protocole X en réseau, console, framebuffer, qtpe, tinyx, ...: il faudrait implémenter ce sale hack partout, et en pondérant l'usage simultané de plusieurs d'entre eux ou par plusieurs utilisateurs, et faire transiter une telle information sur le réseau,...).
Remarquez que l'idée n'est pas neuve : https://db.usenix.org/publications/library/proceedings/cinci(...)
[^] # Re: Regrettable
Posté par herodiade . En réponse au journal L'interview vérité de Con Kolivas. Évalué à 6.
> Ce qui est faux. Beaucoup (peut-être insuffisament) a été fait pour les performances du desktop.
Et aussi, dans cette interview, Kolivas glisse parfois de ses préoccupations particulières vers un jugement d'ordre très général concernant, pour résumer, « la qualité du desktop sous Linux pour l'utilisateur lambda ». Or son travail porte essentiellement sur un aspect très spécifique de « l'expérience desktop », à savoir les rapports entre la latence et l'intéractivité. C'est une dimension très importante, mais est-ce tout ? est-ce seulement l'essentiel ?
De ce que je peut entendre et lire (par exemple sur linuxfr), il me semble franchement que les utilisateurs finaux de desktops sous Linux sont bien plus souvent préoccupés par les problèmes de support du matériel (cartes graphiques et accélération 3D, cartes wifi, imprimantes, webcams, ...) ou de codecs, que du punch de leur ordonanceur. (évaluation herodiade, certifiée "à la louche"(c) ;-).
Il est même peut-être hasardeux de réduire la question des « performances desktop » à l'ordonanceur ou au pré-chargement de la mémoire virtuelle (par exemple ce n'est pas forcément ce qui compte le plus pour les « performances » du rendu 3D d'un jeux, ou le décodage d'un flux h264, ...). L'interactivité a en outre le désavantage d'être difficile à mesurer (ce qui explique surement une bonne part de ce que Kolivas considère comme un manque d'intérêt des autres développeurs pour son travail, il le reconnaît mais sous-estime peut-être un peu l'influence de ce facteur sur les décisions).
> Notons que Xen a été refusé (il n'y a qu'une partie de Xen qui vient d'être accèptée)
Quelqu'un aurait plus d'infos sur les projets de merge / l'état d'avancement de la partie restante (si je ne me trompe, c'est tout le support pour dom0 qui n'est pas entré durant la fenêtre des gros merges du 2.6.23) ?
[^] # Re: Manque d'intéret pour le desktop : toujours d'actualité ?
Posté par herodiade . En réponse au journal L'interview vérité de Con Kolivas. Évalué à 8.
Je compte ici le nombre de développeurs distincts utilisant une email contenant le nom d'une de ces grosses sociétés et dont au moins un patch a été mergé dans le git de Linus entre la sortie du 2.6.22 et aujourd'hui. Ces chiffres ne sont pas précis ni très justes (par exemple certains développeurs n'utilisent pas leur email corporate dans les patchs, ...), c'est plutôt pour avoir un ordre de grandeur et de comparaison approximatif (pour des chiffres plus précis cf. LWN, où J. Corbet publie des études pointues) :
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*redhat | sort | uniq | wc -l
41
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*suse | sort | uniq | wc -l
23
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*ubuntu | sort | uniq | wc -l
3
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*mandr | sort | uniq | wc -l
0
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*oracle | sort | uniq | wc -l
9
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*google | sort | uniq | wc -l
15
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*ibm.com | sort | uniq | wc -l
72
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*intel.com | sort | uniq | wc -l
25
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*amd | sort | uniq | wc -l
6
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*sgi | sort | uniq | wc -l
8
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*mips | sort | uniq | wc -l
5
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*fujitsu | sort | uniq | wc -l
7
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*sony | sort | uniq | wc -l
6
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*hp.com | sort | uniq | wc -l
7
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*atmel | sort | uniq | wc -l
6
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*qlogic | sort | uniq | wc -l
14
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*freescale | sort | uniq | wc -l
10
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*mvista.com | sort | uniq | wc -l
9
Sur un total de :
pouet$git log v2.6.22..HEAD | egrep ^Author: | sort | uniq | wc -l
754
# Manque d'intéret pour le desktop : toujours d'actualité ?
Posté par herodiade . En réponse au journal L'interview vérité de Con Kolivas. Évalué à 10.
- Oracle et IBM emploient beaucoup de développeurs, et il est très clair que le desktop n'est pas vital pour le business autour de Linux.
- La RHEL de Red Hat n'était peut-être pas non plus très desktop-centrique (?)
- Je crois qu'Intel employait surtout du monde pour le SMP, leurs (mauvais) chipsets RAID, l'architecture Itanium etc.
- Rien à voir avec les priorités du monde corporate, mais le verrouillage de XFree86 ralentissait lourdement les progrès aussi.
Mais il semble qu'ironiquement, c'est au moment où Con Kolivas nous quitte que les priorités basculent (en fait ça à commencé un peu plus tôt, mais les fruits commencent à peine à être récoltés, ie. dynticks, network-manager, l'ordonanceur CFS qui vient à peine d'être intégré dans 2.6.23, mac80211, ...), en particulier grâce au monde de la mobilité bon marché :
- Intel emploie une _foultitude_ de développeurs pour travailler spécifiquement sur le desktop, comme : les principaux développeurs de Xorg, du sous-système drm/dri du kernel, l'économie d'énergie, les principaux développeurs du nouveau framework wifi du noyau (mac80211 et cfg80211), vient de lancer une plateforme semi mobile (moblin), etc. Leur investissement dans "Linux pour le desktop" semble croitre à grande échelle, de jours en jours.
- Red Hat est fortement impliqué dans le projet OLPC (totalement "desktop"), et sort une version de son produit commercial, RHEL5, spécialement orientée desktop (sans parler de leur fort investissement dans Fedora). Ils ont aussi lancé à grands efforts le projet "Mugshot"/Global Desktop. Ils sont aussi l'employeur d'Ingo Molnar, qui a consacré pas mal de temps sur dynticks et sur le nouvel ordonnanceur "fair" CFS (n'en déplaise à CK).
- Ubuntu gagne en popularité, en nombre d'utilisateurs finaux (ce qui doit probablement secouer les à priori et priorités des distros plus anciennes et traditionnellement plus orientées "serveur"). Et Ubuntu dispose désormais de quelques développeurs noyau actifs (or le succès sur le desktop est clairement une priorité stratégique pour Canonical/Ubuntu).
- Apparition de sociétés qui développent essentiellement des produits pour le desktop libre (par ex. autour de Gizmo, Gstreamer, ...)
- L'affaire Dell + Linux a certainement du montrer aux constructeurs que les enjeux (ne serait-ce qu'en terme d'image auprès des "leader d'opinions" que nous sommes) de Linux concernent aussi les produits très "grand public".
La (récente) disponibilité de chipsets mobiles très bon marchés (autour des AMD Geode ou Intel Dothan) permet depuis peu de produire des ordinateurs ultramobiles à très bas prix, où le cout de l'OS est donc extrêmement sensible et significatif : du fait de son prix, Linux a une superbe fenêtre pour s'imposer sur le desktop par ce biais.
À mon avis, c'est ce qu'on compris les boites qui emploient maintenant de nombreux devs pour travailler sur la mobilité et le desktop (Intel et ses projets moblin/classmate/asus eee, Ubuntu et sa future version "semi-embarquée", openmoko, ...)..
[^] # Re: Cadence d'horloge
Posté par herodiade . En réponse au journal [digg] Mini-pc 100% silencieux sous linux pour 260¤. Évalué à 5.
[^] # Re: Cadence d'horloge
Posté par herodiade . En réponse au journal [digg] Mini-pc 100% silencieux sous linux pour 260¤. Évalué à 3.
Ce chiffre me semble peu réaliste, voir franchement mensonger, d'autant que la machine inclue un vrai disque dur (pas du SD/CF), une carte graphique et un bus USB (des périphériques assez gourmands).
Pour comparaison, un portable de bonne qualité, finement tuné contre la consommation, écran éteint, réseau coupé, dans le plus bas P-State ACPI (la fréquence la plus basse que le proc supporte) et complétement idle (C-state ACPI C4 99.9 % du temps, c'est à dire que même le cache de la CPU est éteint) se situe généralement aux alentours de 10W, jamais moins de 7W (un exemple : http://thinkwiki.org/wiki/Idle_consumptions ).
[^] # Re: CFS dans 2.6.23 !
Posté par herodiade . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 7.
Il serait vraiment intéressant que quelqu'un rédige un article sur la programmation économe en énergie pour linuxfr (ou mieux Linux Magazine) : utilisation des évènements plutôt que polls réguliers, utilisation de hal, de inotify ou de gamin, des timers regroupés, regroupement des accès aux block devices, réduction des animations graphiques (elles réveillent xorg), stracer régulièrement son application juste pour vérifier qu'elle ne fait vraiment rien lorsqu'elle est au repos, utiliser le système de notification d'Alsa (plutôt que poller le mixer), audit et disagnostic avec block_dump, strace, ltrace, powertop, lm-profiler et blktrace, ...
Les ventes de portables par an ont maintenant dépassé les ventes de stations de bureau[2][3] : la consommation est donc devenue une problématique majeure pour le succès de « Linux sur le desktop ». Et Linux est une option considérée depuis peu avec beaucoup d'attention par les intégrateurs, maintenant - c'est récent - qu'ils disposent de chipsets x86 mobiles tout-en-un à très bas prix : le coût d'une licence Windows sur le portable final est dans ce cas proportionnellement très significatif. C'est probablement un critère déterminant dans le choix de Linux pour l'Asus EEPC, l'Intel Classmate ou encore l'OLPC, et de l'investissement d'Intel (qui commercialise de tels chipsets bons marché) qui paye des développeurs comme Arjan van de Ven pour travailler à plein temps sur la consommation électrique de Linux.
Linux dispose d'une belle perspective pour s'imposer à travers ce nouveau marché des portables (en particulier des ultraportables à bas prix), mais il faut pour cela qu'on apprenne à programmer de façon économe. Jusqu'à présent, on ne considérait pas vraiment cet aspect spécifique, au coté, par exemple, des améliorations des performances ou de la consommation de mémoire vive. Mais les développeurs noyau essaient d'attirer notre attention sur ce sujet[4].
[1] http://lwn.net/Articles/240253/ (voir aussi http://lwn.net/Articles/228143/ et http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0959.ht(...) ).
[2] http://www.usatoday.com/tech/news/2005-01-23-laptop_x.htm
[3] http://www.msnbc.msn.com/id/8090448
[4] Je pense à PowerTOP d'Arjan van de Ven, mais aussi au fameux Why Userspace Sucks—Or 101 Really Dumb Things Your App Shouldn’t Do, Dave Jones (Red Hat), Proceedings of the Linux Symposium, 2006, Ottawa [https://ols2006.108.redhat.com/reprints/jones-reprint.pdf]
[^] # Re: Tentative d'explication
Posté par herodiade . En réponse au journal 2.6.22 a tué HAL.... Évalué à 2.
L'idéal serait peut-être que Grégory fasse un git-bissect, qui permettrai de trouver l'exact patch fautif. Bissecter entre les noyaux 2.6.21 et 2.6.22 (environ 7000 patches) demande 13 recompiles & reboots (+1 pour tester le 2.6.22 avec le seul patche fautif reverté). Un peu long (surtout les recompiles), mais pas insurmontable.
[^] # Re: Fast forward
Posté par herodiade . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 3.
En bonus, il décompose le décompte en sous-totaux par langages (ANSI C, C++, asm, ...). voir http://www.dwheeler.com/sloccount/ (ok, pour l'utiliser sous Windows, il faut Cygwin, mais il existe des outils équivalents et natifs, voir par ex. sur http://www.qsm.com/CodeCounters.html ou http://www.programurl.com/code-counter-pro.htm ).
[^] # Re: CFS dans 2.6.23 !
Posté par herodiade . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 6.
L'idée est que dans de très nombreux cas, on a besoin de programmer une tâche dans le futur, ou à intervalle régulier, mais on n'a pas nécessairement besoin que la date d'exécution de cette tache soit vraiment précise à la fraction de seconde près. On souhaite seulement que « cet (évènement|tache à exécuter) ai lieu approximativement (dans|toutes les) X seconde(s) ».
Ainsi, si nous avions 10 pilotes de périphériques différents qui programmaient l'exécution d'une tâche toutes les secondes environ, mais n'avaient pas initialisé leurs timers en même temps (ou bien avec un intervalle légèrement différent), ils réveillaient le noyau 10 fois par seconde. Si ces 10 pilotes sont modifiés pour programmer leur réveil à une date arrondie avec round_jiffies, ils s'exécuteront en même temps, causant un seul réveil par seconde (un seul réveil à la seconde entière, qui, au passage, aurai de toutes façon eu lieu, même en l'absence de ces 10 pilotes, car il y a déjà d'autres choses converties au round_jiffies).
Il reste beaucoup de travail pour tirer pleinement parti de cette nouvelle API partout où le noyau pourrait le faire, mais certains y travaillent visiblement, et chaque petite conversion réduit le nombre de réveils par seconde dont le noyau à besoin.
Note : s'il y a des développeurs GTK/Gnome dans le coin : c'est exactement comme g_timeout_add_seconds_full() ou g_timeout_add_seconds() (au lieu de g_timeout_add()). Cette fonction permet d'économiser de l'énergie en réduisant les réveils de la CPU, car elle regroupe tout les évènements programmés à la prochaine seconde entière. Svp, si vous n'avez pas besoin d'une granularité/précision très fine, par ex. si vous avez besoin de programmer une action « approximativement toutes les X secondes », préférez utiliser celle-ci au lieu de g_timeout_add().
[^] # Re: Regressions et mac80211
Posté par herodiade . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 9.
Remarque qu'il ne s'agit que des régressions connues : le noyau est toujours mieux testé juste après la sortie d'une nouvelle version (malheureusement !). Et il ne s'agit (presque) que de régressions, les bugs touchant des nouvelles fonctionnalités ou architectures ne sont pas des régressions. Pendant la phase de développement cette liste a été très longue, par moments. Elle a effectivement été sérieusement réduite (preuve, peut-être, de son efficacité : les problèmes n'ont pas été négligés).
Je suis moins optimiste en ce qui concerne l'ancienne couche Wi-Fi : je n'ai pas l'impression que qui que ce soit travaille à l'adaptation des pilotes prism2.5 ou encore ipw2200, par exemple. Peut-être parce que mac80211 n'est (ou du moins n'était, récemment) pas encore tout à fait adapté aux chipsets fullmac (me semble-t-il avoir lu, je ne suis pas 100% sur que ce soit toujours vrai), et qu'il suffira d'attendre quelques mois de maturation. Peut-être aussi parce qu'il est difficile de restructurer complètement un logiciel éprouvé par le temps sans causer de grosses régressions.
Mais il ne faut pas oublier qu'un certain nombre d'entre eux furent développées en interne par des sociétés commercialisant le chipset mais ne donnant pas les specs, ou sous NDA seulement, et qu'Intel, par exemple, n'a aucune envie de consacrer des ressources pour re-développer un produits qu'ils ne vendent plus, alors qu'il est tellement plus simple d'encourager les utilisateurs à changer de matériel. Quand on disait que « donner les specs, sans NDA, c'est beaucoup mieux que donner un driver GPL » ...
# Réponse des wikipédiens
Posté par herodiade . En réponse au journal Encore Wikipédia. Évalué à 7.
http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/9_juil(...)
J'aime en particulier la question déontologique (voir légale) soulevée par David.Monniaux : si les étudiants de Sciences Po' veulent évaluer la rapidité des services de nettoyage municipaux, ils vont graffer les murs de la ville ? S'ils veulent tester la rapidité de la police, vont-ils voler des sacs à main ?
Sinon, notez que Pierre Assouline est acharné détracteur de Wikipédia, de longue date, et qu'il est journaliste (ce qui explique probablement que Libé se fasse echo d'un simple exposé d'étudiants peu sérieux, copinages, ...).
# Regressions et mac80211
Posté par herodiade . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 10.
Quelques précisions et compléments d'informations, en vrac :
* Puisqu'on parle de la liste des régressions. Adrian Bunk maintenait une telle liste durant les derniers mois, qu'il postait chaque semaine sur LKML. Fâché de l'insuccès de son travail (il considère que le 2.6.21 n'aurait pas du sortir en l'état), Bunk a décidé d'abandonner cette tache ingrate, au grand dam des autres développeurs (y compris de Linus) (cf. http://kerneltrap.org/node/8110 ). À cette occasion Google a rappelé qu'ils cherchent à embaucher un « bug master » pour le noyau Linux. Finalement Michal Piotrowski a pris les choses en main et maintient une liste des régression dans un wiki (à l'adresse citée plus haut).
* La nouvelle couche Wi-Fi (<- ça s'écrit comme ceci en fait) s'appelle mac80211 (ou encore d80211). Outres les fonctionnalités citées dans la dépêche, elle mutualise une implémentation MAC logicielle commune pour les divers pilotes, souvent nécessaire avec les chipsets modernes et sots, dits « softmac ». Son intégration dans le noyau standard a parait-il permis de la stabiliser, et simplifiera grandement l'intégration des pilotes récents (nombreux sont ceux qui l'utilisait déjà auparavant, bien qu'elle n'était pas incluse dans le noyau), comme iwlwifi (Intel 4965AGN), les pilotes ralink rt2x00, le nouveau pilote pour le chipset Marvel Libertas, le Broadcom bcm43xx, et bien d'autres. L'ancienne couche Wi-Fi (qui s'appelle ieee80211) est conservée dans le noyau (de nombreux « vieux » pilotes l'utilisent). La perspective d'une telle cohabitation - et du travail de maintenance qui s'en trouve doublé - fut la cause de nombreux débats sur les listes de diffusion. Remarquez aussi que l'API de configuration WEXT du ieee80211 est rendue obsolète par le nouveau mécanisme nommé cfg80211, basé sur netlink (API nl80211). Une couche de compatibilité est toutefois maintenue (avec l'aide, si je me souviens bien, d'une bibliothèque en espace utilisateur).
* La nouvelle couche FireWire (<- ça s'écrit ainsi) est certes plus dense (moins de lignes de codes) mais n'est pas tout à fait complète encore. Par exemple l'eth1394 (émulation ethernet sur FireWire) n'est pas encore porté, si vous utilisez cette fonctionnalité, attendez encore un peu.
# Droits/licence des données du site ?
Posté par herodiade . En réponse au journal notations sur http://hardware4linux.info/. Évalué à 10.
Une question me chiffonne depuis le début de ce projet : la seule indication de licence sur le contenu, c'est "Copyright © 2007 Frederic Lepied. All Rights Reserved. ", en bas des pages.
Ainsi, pour le moment, toutes nos contributions t'appartiennent, et le contenu n'est pas libre.
# Commentaire de Matt Dillon
Posté par herodiade . En réponse au journal l'Intel Core 2 Duo considéré dangereux par Theo de Raadt. Évalué à 7.
Il a livré un rapide commentaire sur les principaux bugs dévoilés dans les récentes erratas d'Intel :
- Ici, celles dont parle spécifiquement Theo (AI65, AI79, AI43, AI39, AI90 et AI99) :
http://hardware.slashdot.org/comments.pl?sid=242663&cid=(...)
- Ici celles concernant les Core 2, dont ne parle pas vraiment le message de TdR (en dépit du titre de son email) :
http://hardware.slashdot.org/comments.pl?sid=242663&cid=(...)
(et qui font dire à Dillon, au sujet des core/core2 duo : « So, in summary, AE3 scares the hell out of me, and for the others AE5, AE8, AE21, and AE30 look serious. »).
Notez que les descriptions des problèmes dans l'errata d'Intel semblent souvent très vagues (d'où des incertitudes dans l'appréciation des conséquences possibles, selon les développeurs).
Concernant la possibilité de corriger ces problèmes par upgrade du microcode, donnez vous la peine de regarder le pdf d'Intel : la plupart de ces bugs sont marqués : "Plan : No Fix".
À ce sujet, voici l'errata d'Intel au sujet des Core 2 :
http://download.intel.com/design/processor/specupdt/31327914(...)
Et celle au sujet des Core Duo et Core Solo :
http://download.intel.com/design/mobile/SPECUPDT/30922211.pd(...)
[^] # Re: ...
Posté par herodiade . En réponse au journal l'Intel Core 2 Duo considéré dangereux par Theo de Raadt. Évalué à 3.
À condition que tout ces problèmes soit corrigeables par mise à jour du microcode.
Lorsqu'on parle de la nécessité de mettre à jour le BIOS, dans notre cas, il peut s'agir seulement de ça (le BIOS contenant aussi le microcode, et donc là pas de problème on sait aussi le mettre à jour depuis l'OS), ou bien d'un changement ou d'un workaround pour contourner le bug très différent (le BIOS, ce n'est pas que le microcode hein).
[^] # Re: Linus a dit : « c'est totalement insignifiant »
Posté par herodiade . En réponse au journal l'Intel Core 2 Duo considéré dangereux par Theo de Raadt. Évalué à 5.
Ce n'est généralement pas comme ça qu'on procède dans le domaine de la sécu informatique : on parle des bugs connus (« n'utilisez pas le produit x version y pour faire telle chose, il présente des déficiences notable sur le plan sécurité »). Ne serait-ce que pour encourager ceux qui maintiennent le produit à corriger leur failles prompto (et à tacher d'éviter d'en faire d'autres du même genre la prochaine fois), ou permettre à ceux qui utilisent le produit de ne pas tomber dans le cas d'utilisation qui expose le problème. Le boulot des journalistes et des professionnels de la sécurité informatique est de nous avertir pour faire bouger les choses : Cyrix, qui produisait des procs sensiblement buggués en sait quelque chose : ils l'ont senti passer, et heureusement qu'on n'a pas gardé le silence.
Deuxièmement, on parle ici d'un type de bugs un peu particulier, surtout pour le monde du matériel : ce sont des bugs ayant un potentiel fort d'impact sur la sécurité.
Concernant les hypothétiques mais probables bugs « dont on ne sait rien », on peut bien sûr se perdre en conjectures... mais est-ce bien utile ? ça ne l'est surement pas s'il s'agit de dédouaner ceux dont les bugs sont connus !
Tout les cores aussi complexe que les x86 ont forcement des bugs
Et ? faut-il s'abstenir de faire état des problèmes dont on apprend l'existence ? Tu imagine si nous réagissions comme ça pour le logiciel « (n'en parlons pas | ne jetons pas la pierre ) parce que tout logiciel de plus de 1000 lignes contient forcément des bugs » ?
Certains fournisseurs ne publient pas les bugs
Souhaitons que quelques bonnes vieilles full disclosure vienne leur boter le train. Encore une fois, le précédent de Cyrix devrait les inciter à la prudence (je pense à ce sujet qu'AMD est méchamment sur le déclin, et depuis leur rachat d'ATI ils sont sur ma liste noire de constructeurs travaillant comme des cochons, ne filant ni specs ni code libre pour leurs chipsets).
[^] # Re: Mwais...
Posté par herodiade . En réponse à la dépêche GNU Affero General Public License : la GPL des applications web. Évalué à 2.
> ah, oui effectivement, ça peut être gênant avec la licence PHP c'est ce à quoi tu penses ?
J'ai pensé à ça immédiatement aussi, et aux licences de PEAR et à celle de python, ... mais surtout à la GPLv2. Avec autant de restrictions, ça va être difficile d'utiliser AGPL.
Je ne comprend pas ton argument plus haut, où tu me répond que restreindre la compatibilité à la "v3 ou plus" seulement (au lieu de v2 ou plus) simplifie les choses.
Si des développeurs choisissent la GPLv2 plutôt que la GPLv3, c'est peut être pas par « misunderstandings », comme dirait Eben Moglen, mais peut-être parce que le code était là avant la v3, ou par choix personnel en toute conscience. Tenter de leur forcer la main en créant une incompatibilité arbitraire et articifielle... c'est vraiment les prendre pour des cons.
[^] # Re: Mwais...
Posté par herodiade . En réponse à la dépêche GNU Affero General Public License : la GPL des applications web. Évalué à 2.
Personnellement je pense qu'adopter une lecture critique - sans refreiner son enthousiasme lorsqu'on a pesé les arguments - est salutaire. Une lecture critique, ce n'est pas une contestation, ce n'est pas diminuer la grandeur de nos leaders (la FSF, Linus, ...), c'est simplement se réserver le droit de penser par soi même. La FSF mérite mieux que des gens qui accepterai tout sans réfléchir.
> - ils partagent le même idéal, mais ne sont pas d'accord avec la méthode utilisée.
C'est tout à fait ce que je voulais dire, entre linuxfriens nous partageons généralement les mêmes idéaux, mais il n'y a pas de raisons que nous ne discutions pas de la méthode adaptée pour y parvenir.
> (l'exemple de Bush était peut-être un peu trop fort), mais d'opinions et d'idéaux.
Dans ce très récent et très intéressant thread :
http://kerneltrap.org/node/8382
Linus Torvalds utilise aussi l'administration Bush pour une métaphore :
And then the FSF has the gall to call themselves the "protector of
freedoms", and claim that everybody else is evil. What a crock.
[...]
I don't know if you've followed US politics very much over the last six
years, but there's been a lot of "protecting our freedoms" going on. And
it's been ugly. Maybe you could realize that sometimes "protecting your
freedom" is *anything*but*!
Linus