Nouvelle version 2.6.31 du noyau Linux

Posté par patrick_g (site web personnel) le 10 septembre 2009 à 12:09. Modéré par Pascal Terjan.

Étiquettes :

107

sept.

2009

La sortie de la version stable 2.6.31 du noyau Linux vient d'être annoncée par Linus Torvalds. Le nouveau noyau est, comme d'habitude, téléchargeable sur les serveurs du site kernel.org.

Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche. Le sommaire...

La phase de test
Les nouveautés :
En bref :
Le bilan en chiffres
Pour la suite

La phase de test... (↑)

Après avoir pris de bonnes résolutions durant la période de merge des diverses branches de développement (This release, I'm only going to pull trees that don't do crazy shit), la version RC-1 a été annoncée le 24 juin par Linus :
"Nous avons eu l'habituelle période de deux semaines (et un jour) de fusion des patchs et maintenant la RC-1 est disponible et la fenêtre de merge est fermée.
Il y a beaucoup de trucs là-dedans mais, avant toute chose, laissez-moi vous dire que j'ai rarement été aussi content pendant une période de merge. J'espère vraiment que ce n'est pas juste un hasard extraordinaire mais les gens ont gardé leurs branches git propres. Il n'y a eu que deux ou trois cas où j'ai dit "non, je ne vais pas fusionner ce truc" mais dans l'ensemble cela a vraiment été indolore pour moi.
Je ne dis pas qu'il y a nécessairement moins de bugs que d'habitude, je dis juste que globalement les gens m'ont envoyé des demandes ayant un sens, ont expliqué ce qu'ils avaient fait et, quand j'ai mergé, j'ai vu un travail de développement clair. Cela rend juste le truc bien plus facile pour moi.
Donc merci à tous.
J'espère vraiment que nous allons garder ce cap et que ce n'était pas juste un cas unique de "par hasard le bidule a bien marché cette fois".
En ce qui concerne les changements, la majorité se trouve dans les pilotes (70% des diffs) avec la branche staging qui en représente la majorité (environ 60% des diffs de pilotes — 40% du total). mais, merveille des merveilles, je pense que la branche staging a _diminué_ cette fois-ci du fait des nettoyages. Croyez-le si vous le pouvez.
Sur le front des systèmes de fichiers nous avons du btrfs, de l'ext3 et du xfs en développement actif (Pourquoi xfs ? Du diable si je le sais mais c'est ce qu'indiquent les stats) et il y a un sacré morceau sur tout le travail d'unification de fsnotify.
Pour les architectures : ARM, powerpc, mips, sh, x86 sont concernés. Pour ARM le principal est l'inclusion de nouvelles plate-formes (u300, freescale stmp, ce que vous voulez). Il semble ne pas y avoir de fin à l'apparition de ces nouvelles plate-formes délirantes.
Pour x86 (et dans une moindre mesure pour powerpc) une part notable des diffs concerne le nouveau sous-système perfcounter en plus de plein d'autres choses.
En résumé ? Des tonnes de trucs. Alors commençons à tester et à stabiliser".
Le 4 juillet c'est la version candidate RC-2 qui est apparue sur les serveurs :
"C'est dispo. Plus gros que ce que j'espérais mais la majorité des changements vient de mises à jour tardives d'architectures (MIPS et documentation de powerpc).
Il y a aussi quelques mises à jour un peu effrayantes sur le pilote i915 mais c'est surtout l'ajout du support displayport et cela ne devrait pas provoquer de régressions.
Je vais être un peu plus strict maintenant au sujet des demandes de merge. Je veux vraiment que la RC-3 (et les suivantes) soit plus petite que ce que nous avons là.
Donc s'il vous plaît testez cette RC et signalez les régressions, qu'elles soient nouvelles ou anciennes. OK ?".
Après une version RC-3 sans histoire, c'est à l'issue d'une semaine un peu plus sportive que la RC-4 a été annoncée par Linus le 22 juillet :
"OK, ça a été une semaine fun. Nous avons eu un bug dans binutils, un bug ccache et un bug de compilateur. Et là c'était simplement les bugs qui se trouvaient en dehors du noyau mais qui provoquaient des dysfonctionnements des builds.
Mais c'était vraiment inhabituel et le reste est vraiment classique. Beaucoup de petites corrections de partout".
La RC-5 du 31 juillet a apporté pas mal de changements listés par Linus :
"Bon j'ai encore des trucs en attente, mais je publie quand même cette RC-5 car elle apporte beaucoup de corrections, et puis je ne suis pas trop sûr au sujet de certains des trucs en attente.
À part les diverses corrections de régressions le diff montre quelques nouveaux pilotes (at_hdmac, uc2322, gspca/sn9c20x, ds2782) et des gros changements concernant le Kernel Mode Setting des cartes Radeon (le code source Radeon KMS est physiquement dans drivers/gpu mais il est seulement activé lors du choix de l'option CONFIG_STAGING et il est considéré comme non stable).
Oh et il y a aussi des mises à jour concernant USB-3 xhci".
Après un délai assez inhabituel de deux semaines la RC-6 a été annoncée le 13 août par Linus :
"Hmm. Beaucoup de petites corrections réparties un peu partout (50% pilotes, et grossièrement 10% pour arch, fs, kernel, tools/perf, "le reste"). Les choses semblent se calmer parce que, en dehors des patchs displayport du pilote i915 et de quelques patchs perfcounter, tous les autres sont vraiment très petits.
Il n'y a pas grand chose de prodigieusement intéressant là-dedans même si je suis personnellement satisfait d'avoir quelques commits à mon nom de plus que d'habitude. Même s'ils sont petits cela me fait me sentir utile ;)
Il y a aussi la correction pour le déréférencement du pointeur NULL qui a déjà été évoqué sur Slashdot, mais franchement, si on suppose le fait que tous les problèmes du type "Vous ne pouvez pas mapper des trucs à zéro" ont été corrigés lors de la dernière alerte, ce bug là ne sera pas aussi mauvais que ce qu'il aurait pu être".
La RC-7 est apparue le 21 août et Linus, comme souvent, a utilisé la fonction dirstat de Git pour montrer comment se répartissent les changements dans l'arbre des sources du noyau. Bien entendu à ce stade les corrections sont de petites tailles (souvent à peine une ligne) mais on peut noter l'inclusion de 3 patchs par Eric Paris qui sont destinés à corriger les insuffisances de SELinux (voir le paragraphe spécifique dans la partie "Les nouveautés...").
Celle qui devait être dernière version candidate, la RC-8, a été annoncée par Linus le 27 août :
"Il y a 131 patchs là-dedans et tout est assez trivial. (..) Je ne serai pas disponible la semaine prochaine mais tout devrait être calme. Harcelez les suspects habituels (aussi connus sous le nom de "mainteneurs") à propos de tous les bugs que vous détecteriez. Ils les corrigeront pendant que je serai en train de faire de la plongée".
Malheureusement une fois de retour Linus a constaté qu'il restait encore quelques régressions à traiter et il a choisi de jouer la sécurité en sortant une dernière version candidate :
"Je sais que j'avais dit que je sortirai le 2.6.31 lors de mon retour de plongée mais il y a eu trop de corrections pendant que j'étais parti pour que je sois rassuré. Donc je fais une RC-9 qu'on va laisser mijoter pendant deux jours afin d'avoir des tests de dernière minute avant de faire la release finale".

Les nouveautés… (↑)

Deux nouveaux outils de détection de problèmes concernant les allocations mémoire kmemleak et kmemcheck ont été intégrés dans le noyau 2.6.31.
Tout le monde sait, ou devrait savoir, que le noyau Linux est écrit en langage C. Une des charmantes particularités de ce langage est qu'il faut gérer manuellement la mémoire en écrivant explicitement dans son code source les opérations d'allocation et de désallocation. En gros, cela consiste — avant de pouvoir faire quoi que ce soit — à utiliser la fonction malloc() pour réserver de la mémoire et, une fois l'opération terminée, utiliser la fonction free() pour libérer cette mémoire.
Si l'étape du free() est oubliée ou mal codée, alors on a affaire à ce qu'on appelle une fuite mémoire. Les conséquences sont assez graves puisque le programme va occuper de plus en plus de mémoire physique puis d'espace sur le swap de la machine jusqu'à atteindre la limite au delà de laquelle Linux va tuer ce programme glouton en utilisant le mécanisme "OOM killer".
Bien entendu OOM killer est la solution de la dernière chance et il serait bien mieux pour tout le monde si le programme en question ne provoquait pas de fuite mémoire. C'est là qu'intervient kmemleak qui va — comme Valgrind pour les programmes en espace utilisateur — tenter de détecter ces fuites mémoire.
kmemleak, écrit par Catalin Marinas, fonctionne en modifiant l'allocateur mémoire de façon à ce que ce dernier stocke dans un arbre de recherche toutes les allocations et déstocke de l'arbre toutes les libérations mémoire (un peu comme le fait un ramasse-miettes). Quand l'utilisateur veut savoir si une fuite a eu lieu, il lui suffit de lire le contenu de /sys/kernel/debug/memleak et le contenu de l'arbre de recherche est alors injecté dans une liste qui contient toutes les fuites potentielles. Cette liste sert à scanner la mémoire pour vérifier les divers pointeurs mémoires, les blocs, les piles de données, etc. À la fin de ce processus complexe de vérification, les éventuelles fuites sont présentées à l'utilisateur. Ce message de Catalin explique la procédure qu'il utilise afin d'être certain de ne pas être confronté à un faux positif et une documentation complète est disponible.

En ce qui concerne kmemcheck, l'autre outil qui entre dans le noyau Linux 2.6.31, son fonctionnement est plus simple, mais aussi plus pénalisant pour l'utilisation normale de la machine, ce qui le réserve aux développeurs lors des périodes de traque de bugs.
Kmemcheck sert à détecter les accès à des zones mémoires non initialisées, de la même façon que la fonction memcheck de Valgrind. Quand le code fait un appel à la fonction malloc(), il faut écrire quelque chose sur cette zone, par exemple avec la fonction memset(), avant de pouvoir lire cette zone mémoire. Si la mémoire n'est pas initialisée alors toute tentative de lecture provoquera un crash.
Afin de détecter les occurrences de cette erreur, kmemchek utilise une stratégie assez brutale mais simple à comprendre :
- Lors d'une allocation mémoire, kmemchek intercepte la demande et crée une allocation parallèle (fantôme) qui va lui servir de référence.
- Kmemchek renvoie ensuite l'information sur l'emplacement de la zone mémoire au demandeur mais en ayant pris soin de mettre un indicateur qui va déclencher une erreur de page (page fault) lors de tout accès ultérieur.
- Plus tard, quand un processus veut accéder à cette zone mémoire, l'erreur de page est donc déclenchée et kmemchek détermine si c'est un accès en écriture (donc un accès normal pour remplir la zone non initialisée) et il met alors à jour la page fantôme avec un code spécial. Si en revanche kemcheck détermine qu'il s'agit d'un accès en lecture, alors il va aller voir la page fantôme pour savoir si le code spécial est présent. Si oui, pas de problème, la zone avait bien été initialisée auparavant, mais si non, alors bingo, c'est un bug de non initialisation de la mémoire qui a été détecté et qui est remonté a l'utilisateur.
En dépit de son utilité cette technique est évidemment très coûteuse puisque l'empreinte mémoire double — du fait des pages fantômes — et que le fonctionnement est grandement ralenti — du fait des erreurs de pages systématiques lors des accès mémoire. Une documentation complète est disponible pour les développeurs voulant utiliser cette nouvelle fonction de débogage.
L'utilisation de kmemleak et de kmemchek a déjà permis de trouver diverses fuites mémoires et autres problèmes dans le code concernant l'ACPI, SELinux, les architectures i386 et ARM. C'est bien la preuve de leur utilité et leur entrée officielle dans le noyau est donc une bonne nouvelle puisqu'elle va améliorer la fiabilité de Linux.
La nouvelle infrastructure de notification des événements touchant les systèmes de fichiers, fsnotify, fait maintenant partie du noyau Linux 2.6.31.
Tout commence en novembre 2007, quand un développeur de la société d'anti-virus et d'anti-malwares Sophos envoie un message sur la liste de diffusion du noyau en demandant à ce que l'interface LSM (Linux Security Modules) ne soit pas retirée du noyau (il y avait en effet à cette époque des discussions à ce sujet entre les développeurs Linux). Ce développeur explique que Sophos a écrit un module noyau GPL, nommé TALPA, qui permet aux logiciels propriétaires de Sophos qui tournent en espace utilisateur de scanner les fichiers d'un système GNU/Linux afin de détecter des malwares ou des virus (y compris ceux concernant Windows). TALPA se loge dans le noyau et intercepte les appels systèmes de lecture et d'écriture afin de permettre le scan de ces opérations avant qu'elles n'aient effectivement lieu.

Les développeurs du noyau Linux n'ont, c'est peu de le dire, pas été impressionnés par cette solution technique jugée peu élégante et peu protectrice. LSM a fini par gagner sa légitimité en tant qu'infrastructure de sécurité du noyau en accueillant d'autres modules que SELinux mais TALPA, lui, n'a jamais eu la moindre chance d'entrer dans la branche principale.
Pourtant la pression des grosses sociétés commercialisant des anti-virus et anti-malwares n'a pas disparu. Avec la percée commerciale de Linux ces sociétés voient s'ouvrir un nouveau marché constituée par toutes les entreprises traditionnellement friandes de ces scanneurs qui sont très utilisés sous Windows. L'offensive a donc repris et cette fois-ci elle était menée par Eric Paris, un développeur Red Hat qui, le 4 août 2008, a posté un message détaillé sur la liste de diffusion pour proposer à nouveau l'inclusion de TALPA.
Une caractéristique du mode de développement de Linux est que les développeurs se fichent éperdument des arguments commerciaux et marketing. Pour les convaincre, il faut une solution technique solide et Eric Paris s'est efforcé de rester sur ce terrain. On lui a fait brutalement remarquer que scanner des fichiers n'était pas très efficace comme solution de sécurité et que le modèle de menace (threat model) auquel faisait face TALPA était mal défini.
Il a été très honnête dans sa réponse :
"Je veux souligner que beaucoup d'entreprises vont faire tourner ces logiciels sur leurs machines qu'on le veuille ou non. Point à la ligne. Fin de l'histoire. Moi je préfère maintenir une interface propre avec ces scanneurs plutôt que de devoir faire face aux bugs que les clients vont rencontrer quand leurs systèmes modifiés sauvagement auront des problèmes.
Donc que font ces sociétés anti-malwares ? Elles scannent des fichiers. C'est tout (…). Les seules attaques qui sont concernées par cette interface TALPA sont celles qui peuvent êtres détectées en scannant des fichiers. Il peut y avoir toutes sortes de bla-bla marketing ou de croyances vagues mais la réalité est que la seule aide que ces sociétés procurent est une aide contre les menaces détectables par scan. C'est aussi simple que ça. Certains diront que ce n'est pas de la "bonne" sécurité et je ne vais prétendre le contraire, mais si vous exigez vraiment que je définisse un modèle de menace, alors je ne peux pas faire mieux que de dire "Nous tentons de localiser les fichiers qui peuvent être dangereux et nous tentons d'empêcher l'accès à ces fichiers".

Eric Paris a bien senti que son argumentaire n'avait que peu de chance de déchaîner l'enthousiasme des développeurs du noyau, alors il a eu une idée originale. Pour mieux faire passer la pilule TALPA, pourquoi ne pas la coupler avec une vraie amélioration de Linux ?
Les notifications envoyées par les systèmes de fichiers aux applications utilisent deux systèmes différents. L'ancien système, dnotify, est présent depuis la série des noyaux 2.4.x et inotify, le nouveau système, a été ajouté au noyau officiel à partir de la version 2.6.13. Les indexeurs de fichiers comme Tracker ou Beagle, utilisent intensivement inotify pour être prévenu de chaque modification de fichier et pouvoir réindexer ce qui a changé. Bien entendu c'est pénible de devoir maintenir deux systèmes différents mais la compatibilité est à ce prix.
L'idée d'Eric Paris a été de créer un nouveau mécanisme de notifications, propre et générique, et de réimplémenter par dessus les vieux systèmes inotify et dnotify. Ainsi l'interface pour les applications ne change pas mais, à partir du noyau 2.6.31, le mécanisme sous-jacent est complètement rénové.
L'astuce, c'est que ce nouveau mécanisme générique, fsnotify, va dans un futur proche, servir de soubassement technique à un module de scan de fichiers qui se nommera non pas TALPA mais fanotify et qui sera beaucoup plus propre que l'ancien module écrit par Sophos.
Les utilisateurs de Linux gagnent donc un tout nouveau système de notification optimisé qui incorpore beaucoup de conseils de la part des développeurs de systèmes de fichiers : il est plus facilement maintenable, son impact sur le VFS (Virtual File System) est réduit, il unifie les deux systèmes précédents et il réduit la taille de la structure des inodes ce qui constitue une optimisation importante.
Eric Paris, on peut le comprendre, laisse percer un peu de jubilation dans son annonce car, après tout ce harcèlement et ce scepticisme sur l'utilité réelle de TALPA, il a réussi a relever un challenge difficile :
"Tout ceci est fait en préparation de fanotify et afin d'utiliser fanotify en tant que scanneur de fichiers. Donc maintenant vous êtes prévenus. Et pourquoi est-ce utile ? Parce que cela réduit la structure des inodes. Et oui, mon code est plus petit et plus rapide. Mangez-vous ça dans les dents !".
La fonction de KMS (kernel-based mode-setting) qui était entrée dans le noyau 2.6.29 pour les pilotes graphiques Intel est maintenant aussi utilisable par les cartes Radeon.
KMS permet de gérer directement dans le noyau tout ce qui concerne les modes d'affichages graphiques et cette inclusion dans le noyau a de nombreux avantages.
Tout d'abord, la gestion des modes est centralisée, ce qui évite une grande duplication du code et permet de simplifier les divers pilotes de cartes graphiques. Ensuite KMS autorise la fonction de changement rapide d'utilisateur (fast user switching) en évitant de devoir basculer entre les terminaux virtuels. Les phases de mise en veille et de réveil de la machine sont plus simples et plus fiables. Enfin, l'amorçage de la machine est visuellement plus attractif (nul besoin de basculer les modes d'affichage).
On voit que les avantages de KMS sont très intéressants et il n'est pas étonnant que les divers pilotes graphiques se convertissent progressivement à cette technique.

Néanmoins, une difficulté particulière existait concernant la gestion de la mémoire des cartes graphiques. En effet, Intel avait réussi à inclure dans le noyau 2.6.28 le gestionnaire GEM (Graphics Execution Manager) qui semblait parfait pour les cartes à mémoire partagée (Intel) mais moins efficace pour les cartes à mémoire dédiée (Radeon, NVidia).
La solution GEM avait pris le pas sur son concurrent TTM qui semblait, quoique complexe, plus efficace pour gérer les cartes à mémoire dédiée. Après une brève période d'incertitude, l'inclusion de KMS et de GEM pour les pilotes Intel a montré la voie et a mis fin aux querelles techniques. Les développeurs Radeon ont pu se consacrer à l'adaptation de leur code et le développeur Dave Airlie a réussi à combiner le meilleur des deux mondes en recodant une interface de type GEM par dessus un soubassement technique de type TTM. Le patch ajoutant TTM (5800 lignes) fait donc partie lui aussi du code qui entre dans le nouveau noyau 2.6.31.
Le code noyau des cartes Radeon gère la mémoire de façon plus complexe que GEM en allouant des "buffer objects" et en les mappant sur la mémoire. Des verrous à grains fins protègent les buffer objects pour garder la cohérence des mémoires caches ce qui permet d'éviter un verrou global pénalisant.
Certes, le code de TTM est plus compliqué que celui de GEM, mais cette complexité est inévitable si on veut bénéficier pleinement des très puissantes cartes graphiques modernes. Le nouveau code fonctionne avec les cartes Radeon de type R1XX, R2XX, R3XX, R4XX, R5XX (jusqu'à la carte X1950) et le travail continue pour étendre ce support aux cartes plus récentes.
À noter que ces fonctions KMS/TTM pour les pilotes Radeon font partie de la branche staging (activable avec le choix de l'option CONFIG_STAGING) et ne sont pas encore considérées d'une stabilité optimale. Tout devrait rentrer dans l'ordre dès le noyau suivant et on espère également l'intégration rapide de KMS/TTM pour le pilote nouveau des cartes NVidia.
Le moniteur de performances perfcounters a été ajouté au noyau Linux 2.6.31 pour les architectures de type x86 et PowerPC, ce qui met fin à la longue absence d'un tel outil dans la branche principale.
Les développeurs sont toujours à la recherche d'outils leur permettant de mieux comprendre ce qui se passe réellement quand un programme fonctionne. Ces outils, qu'on les nomme profileurs, comme par exemple oprofile, ou moniteurs de performances, comme perfmon, servent à savoir exactement où le programme est en train de tourner, le nombre de mauvaises prédictions du processeur, les accès à la mémoire cache, etc. Ces informations de bas niveau sur les zones critiques du code servent à détecter les problèmes de performances et à implémenter des améliorations potentielles.
Les profileurs utilisent les compteurs spéciaux présents dans les processeurs, afin de ne pas induire de pénalité en temps de calcul ce qui risquerait de fausser les résultats. Ils constituent donc une excellente solution d'analyse et l'entrée dans la branche principale du noyau était très attendue... mais cela n'a pas été sans une petite controverse !

En effet, le candidat le plus probable, perfmon, qui est développé par Stéphane Eranian depuis plusieurs années et dont la toute dernière version 3 avait été proposée pour inclusion en novembre 2008 a été grillé sur le poteau par perfcounters qui est développé par Ingo Molnar et Thomas Gleixner.
L'annonce de perfcounters en décembre a pris tout le monde par surprise et n'est pas sans faire penser à l'annonce surprise de l'ordonnanceur CFS par le même Ingo Molnar qui a permis l'entrée de CFS dans le noyau 2.6.23 au détriment de son concurrent développé par Con Kolivas. Cette concurrence entre les deux moniteurs de performances a été bien entendue évaluée sur des critères techniques.
Perfmon nécessite l'introduction de plusieurs nouveaux appels système (douze à l'origine puis seulement cinq par la suite afin d'augmenter ses chances d'intégration).
Il utilise aussi l'appel ptrace() pour stopper l'exécution d'un autre processus afin d'interroger les compteurs du processeur. Cette technique consistant à stopper l'application pour la relancer ensuite a le défaut de perturber les mesures. En outre, le fait de devoir donner le privilège d'utiliser ptrace() à perfmon est assez ennuyeux.
Perfcounters est beaucoup plus simple, puisqu'il n'a besoin que d'un seul appel système et qu'il n'utilise pas ptrace(). La gestion des compteurs des processeurs est plus flexible (possibilité de partager ces compteurs entre divers processus) et le code noyau est plus propre. Un outil, nommé KernelTop, permet de visualiser facilement et en continu les valeurs des compteurs des processeurs.
Un point technique controversé a été l'emplacement de la bibliothèque de programmation des compteurs de processeurs. Perfmon a choisi de faire une bibliothèque externe (en espace utilisateur) alors que perfcounters a préféré tout mettre dans le noyau ce qui a été stigmatisé comme "bloat" par certains développeurs alors que certains autres ont pensé que c'était la meilleure solution à long terme. Les échanges d'arguments techniques entre Ingo et Stéphane ont été nombreux et très directs et, si on veut résumer sommairement le bilan, on peut dire que le choix devait se faire entre le code simple mais manquant un peu de fonctions d'Ingo et le code complexe mais offrant beaucoup de choses de Stéphane.

C'est là qu'est intervenu ce qui fait la grande force d'Ingo Molnar et qui avait déjà décidé de la victoire dans la controverse sur l'ordonnanceur CFS : Ingo écoute les critiques et il corrige très rapidement son code pour en tenir compte.
Jugez-en : l'annonce initiale de perfcounters est intervenue le 4 décembre. Le 8 décembre c'était la version 2 avec l'intégration de KernelTop et diverses d'optimisations. Dès le 11 décembre est annoncée la version 3 avec, outre les corrections et les optimisations, l'introduction des groupes de compteurs et des compteurs virtuels. La version 4 arrive le 14 décembre avec encore des corrections diverses. Elle permet surtout de gérer l'héritage des compteurs afin de pouvoir surveiller les processus fils de façon automatique. On peut ainsi visualiser les événements de toute une hiérarchie de tâches grâce à l'outil timec. La cinquième version est disponible le 23 décembre et elle apporte la possibilité de gérer les compteurs fixes des processeurs (PERF_COUNT_INSTRUCTIONS, PERF_COUNT_CPU_CYCLES et PERF_COUNT_BUS_CYCLES) de façon à éviter de devoir utiliser des compteurs génériques.

À ce stade les critiques soulevées lors de la discussion initiale sont rendues caduques par l'introduction à grande vitesse de corrections et de nouvelles fonctionnalités. Des développeurs qui avaient critiqué perfcounters, comme Paul Mackerras, participent maintenant à perfcounters et écrivent des patchs qui se retrouvent dans la version 6 du 21 janvier.
La version 7 du 21 mars et la version 8 du 6 juin consacrent définitivement perfcounters comme le moniteur de performances devant entrer dans la branche principale. Les performances sont encore améliorées, les fonctions couvrent les besoins des développeurs et les utilitaires disparates des versions précédentes (KernelTop, timec, etc) disparaissent au profit d'une interface unifiée perf qui permet d'enregistrer les évènements (perf stat) et de faire des rapports (perf report). Cet outil perf réutilise des bibliothèques internes de l'outil de gestion de versions Git afin d'avoir un air familier auprès des développeurs de noyau et de tous les autres utilisateurs de Git.

Ce qui est étonnant, c'est que l'outil perf a été intégré directement dans les sources du noyau (dans le nouveau répertoire tools/) au lieu d'être relégué en espace utilisateur. Linus a justifié ce choix en soulignant :
"Nous avons eu des tonnes de cas ou nous avons essayé de "séparer", au nom de la "beauté" ou de je ne sais pas quoi, le code noyau du code utilisateur. C'est presque toujours un désastre.
Regardez oprofile. P*tain quelle horrible saleté. Cela a pris littéralement des mois pour que les outils utilisateurs se mettent à niveau par rapport aux nouvelles fonctions et, après ça, il a fallu encore plus longtemps pour que ces outils fassent partie d'une version qui soit utilisée par les distributions.
Donc je préfère avoir ces outils dans le noyau que de devoir dépendre d'une entité extérieure qui n'en a rien à foutre".

Stéphane Eranian a tenté le 16 juin un dernier baroud d'honneur dans un message fleuve où il détaille toutes ses critiques à l'encontre de perfcounters et tous les points qui restent en suspens. Ingo y a répondu le 22 avec un message de synthèse et des réponses très détaillées lisibles dans ce fil.
Finalement, les développeurs de Linux ont été convaincus par les performances de perfcounters et par ses avantages techniques par rapport à perfmon et ont choisi de l'intégrer dans la branche principale. En définitive Ingo a, une fois de plus, réussi son coup et le noyau Linux y gagne un nouvel outil très utile.
Martin Petersen, de la société Oracle, a écrit un patch nommé I/O Topology qui permet au noyau de mieux comprendre l'arrangement physique des blocs sur les périphériques qui lui sont rattachés.
Depuis des temps immémoriaux la taille physique des blocs sur les disques était de 512 octets, mais depuis quelques temps les fabricants effectuent une transition vers une taille de bloc de 4 kilo octets et cette transition sera complète en 2011. Les industriels du stockage de données ont même mis en place un consortium pour faciliter cette transition et divers documents techniques sont disponibles sur leur site.
L'avantage d'un disque ayant des blocs de 4 Ko est très simple à comprendre : Sur le disque, les données sont précédées par des informations diverses (adresse, synchronisation, etc) et sont suivies par une somme de contrôle afin de de corriger les erreurs (ECC).
On a donc quelque chose qui ressemble à ça :

[Divers][512 octets de données][ECC].

Donc si on veut enregistrer 4 kilo octets des données sur le disque on doit en fait enregistrer ceci :

[Divers][512 octets de données][ECC][Divers][512 octets de données][ECC]
[Divers][512 octets de données][ECC][Divers][512 octets de données][ECC]
[Divers][512 octets de données][ECC][Divers][512 octets de données][ECC]
[Divers][512 octets de données][ECC][Divers][512 octets de données][ECC]

Avec la nouvelle taille de bloc à 4 kilo octets on peut se contenter d'enregistrer ça :

[Divers][----------4096 octets de données----------][ECC]

On voit bien que la place perdue par les informations de contrôle et de corrections est moindre dans le second cas ce qui entraîne un gain de place (cet article du site LWN explique qu'on passe d'une efficacité de stockage 87% à 96%). On économise aussi sur le temps processeur, puisqu'il y a moins d'informations à traiter.
Cependant un changement tel que celui-ci doit se faire prudemment du fait de l'impact qu'il peut avoir sur les systèmes non compatibles (BIOS, systèmes d'exploitations, LVM, RAID, gestionnaires de partitions, etc). Les fabricants ont donc choisi de passer aux blocs 4 Ko en interne (blocs physiques) mais de continuer à présenter au système d'exploitation une interface basée sur des blocs de 512 octets (blocs logiques). Cette émulation masque la "cuisine interne" du disque, mais elle a aussi le désavantage de ne pas permettre au système d'exploitation d'optimiser l'alignement des blocs puisqu'il ignore le placement réel des blocs physiques sur le disque. Du fait de ce non-alignement des blocs, on a des chevauchements et les plateaux du disque doivent effectuer des tours en plus : le premier secteur partiel doit être lu et stocké dans un tampon puis le second secteur partiel lui est ajouté et, à la rotation suivante, l'information complète est écrite.
Ainsi, par exemple, Windows et Linux utilisent traditionnellement une table de partition de type DOS avec la première partition commençant au bloc 63... qui n'est donc pas du tout aligné sur le début d'un bloc 4 Ko !

C'est ici qu'intervient enfin le patch I/O topology de Martin Petersen. Il permet d'extraire du disque les informations réelles (physiques) sur les blocs et il met à la disposition du noyau ces informations, afin de mapper les blocs du disque et les blocs logiques du système pour obtenir des performances d'alignement optimales.
Par exemple l'information sur le décalage entre la partition et l'alignement physique "naturel" du disque se trouve dans /sys/block/nom_du_disque/alignment_offset.
La documentation détaille toutes ces nouvelles informations rendues disponibles par ce patch et qui vont permettre au noyau Linux d'utiliser ces nouveaux disques à leur plein potentiel.
Pour prendre la suite d'ext4 dans le futur c'est le système de fichiers btrfs qui est envisagé (voir cet excellent article de Valerie Aurora sur l'historique de btrfs et ses avantages par rapport à ZFS). Le travail continue à plein régime sur btrfs et le noyau 2.6.31 propose beaucoup de changements.
La fonction de recherche des extents libres en RAM, qui pouvait utiliser de grandes quantités de mémoires, a été réécrite et mise à la diète (après une semaine de tests intensifs on pouvait dépasser les 1 Go alors que, maintenant, c'est de l'ordre de 10 Mo).
Le code qui s'occupe de la mise en cache des groupes de blocs a été rendu asynchrone afin de ne plus bloquer l'exécution et de permettre des allocations anticipées. Selon la méthodologie de test décrite par Josef Bacik dans son message explicatif on passe de 16 secondes à seulement 6 pour terminer le test.

L'arrivée massive des lecteurs solides (SSD) à mémoire Flash est anticipée par les développeurs de btrfs qui travaillent pour apporter les meilleures performances possibles sur ces nouveaux types de disques. L'auto-détection du lecteur solide est maintenant incorporée (par l'intermédiaire de la vérification de l'indicateur "nonrot") et elle permet de mettre en œuvre des optimisations particulières. Par exemple, le montage de ces lecteurs sous btrfs utilise maintenant moins de cycles processeur et l'allocation des blocs est plus intelligente.

Enfin, le code gérant l'utilisation des "back references" (c'est-à-dire savoir, à partir d'un bloc de données, vers quelles méta-données le bloc pointe) est largement modifié de façon a réduire les temps de latence et améliorer la montée en charge. Il est à noter que ce changement remanie le format de btrfs sur le disque et que les noyaux précédents ne peuvent pas monter une partition btrfs qui incorpore ce changement.
Linus lui-même s'est fait avoir comme un bleu par cette modification (même s'il reconnaît que le noyau l'avait averti au moment de la conversion du format) et il a été obligé de réparer son système en bootant sur une clé USB. Cela a valu à Chris Mason, le responsable de btrfs, un message indigné et le qualificatif de "double-plus-ungood" pour ce changement tardif de format de disque.
Dans le noyau 2.6.31 la sécurité du module SELinux a été renforcée à la suite des exploits successifs de Brad Spengler qui reposaient en partie sur une configuration fautive de ce module de sécurité.
Le fichier mmap_min_addr se trouve dans le répertoire /proc/sys/vm/ et il sert à indiquer au système quelle est l'adresse minimum à partir de laquelle les programmes peuvent allouer de la mémoire. Ce mécanisme a été introduit à partir du noyau 2.6.23 car les développeurs se sont rendu compte qu'il était dangereux de laisser des programmes utiliser les toutes premières pages de la mémoire (celles qui se trouvent à partir de l'adresse 0). Si un bug exploitable existe dans un tel programme alors le système lui-même est en grand danger d'être complètement compromis.
Pour éviter cela, il suffit de mettre une valeur non nulle dans mmap_min_addr et ainsi les programmes ne sont plus autorisés à mapper une zone mémoire à partir de l'adresse de départ. Bien entendu, quand le contenu du fichier mmap_min_addr est à zéro, cela signifie qu'il n'y a pas de protection.
Pour savoir si vous pouvez dormir (relativement) tranquille, il vous suffit donc d'aller voir quelle est la valeur paramétrée dans le fichier qui se trouve sur votre machine :
patrick@laptop:~$ cat /proc/sys/vm/mmap_min_addr
65536

Cette sécurité n'est pas parfaite (aucune ne l'est complètement) mais elle est tout de même fort efficace. Julien Tinnes, le développeur ayant trouvé les bugs de sécurité qui ont mis Brad Spengler sur la piste de son exploit, souligne sur son blog que mmap_min_addr est une bonne fonction de sécurité : "En pratique cette fonction a été suffisament utile pour rendre plus difficile ou même impossible la création d'exploits à partir de beaucoup de vulnérabilités".

L'ennui, c'est que le module de sécurité SELinux est venu mettre son grain de sel dans cette fonction de sécurité et les choses sont devenues plus complexes.
La plupart des programmes tournant sur une distribution Red Hat/Fedora le font avec une configuration de SELinux qui se nomme unconfined_t et qui — comme son nom l'indique — n'impose pas de restrictions. Seuls les programmes "sensibles" sont protégés par SELinux et les autres, pour éviter de gêner l'utilisateur, ne le sont pas.
La faille de sécurité, c'est que le mode unconfined_t ne tient pas compte de la valeur qui se trouve dans mmap_min_addr. Même si cette valeur est non nulle, les programmes sont quand même autorisés par le mode unconfined_t de SELinux à mapper une zone mémoire à partir de l'adresse de départ. Comme le souligne Brad Spengler : "Avoir SELinux signifie *AFFAIBLIR* la sécurité du système pour ce genre d'exploits".
Les développeurs de Red Hat/Fedora sont bien ennuyés par cette situation car ils veulent garder la compatibilité avec les rares applications qui exigent absolument de pouvoir mapper la mémoire à partir de l'adresse de départ (Wine ou Dosemu par exemple) et ils veulent également boucher la faille de sécurité.

Pour remédier à ce grave problème et garder en même temps de la flexibilité pour répondre aux multiples usages des utilisateurs les solutions suivantes ont été adoptées :
Tout d'abord la fonction mmap_min_addr ne pourra plus être contournée par le module de sécurité SELinux. Si un programme a quand même besoin de mapper de la mémoire en dessous de la limite fixée, alors il devra obligatoirement avoir la capacité CAP_SYS_RAWIO (les capacités, capabilities en anglais, sont un système permettant de décomposer finement les droits administrateurs afin d'autoriser certaines actions et pas d'autres).
Ensuite, si la valeur de mmap_min_addr est à zéro (pas de protection du tout), alors SELinux pourra quand même restreindre l'accès à l'adresse mémoire de départ, en autorisant juste certains programmes (au hasard Wine) et pas d'autres.
Ainsi on voit que SELinux retrouve son rôle de gardien vigilant du système, puisqu'il ne peut que renforcer la protection et jamais l'affaiblir.

En bref... (↑)

Le pare-feu Netfilter a été amélioré puisqu'il dispose maintenant d'une fonction de prise d'empreinte passive. Avec ce module, il est possible — comme le fait OpenBSD depuis longtemps — de reconnaître passivement le système d'exploitation qui demande une connexion et d'appliquer des règles spécifiques à ce système d'exploitation. Le module incorporé se base sur osf qui a été développé depuis six ans par Evgeniy Polyakov. Un fichier de reconnaissance, d'origine OpenBSD, mais compatible avec osf, est disponible.
Linus Torvalds a écrit pour le noyau 2.6.31 un patch qui améliore les performances du système de fichiers ext3. Avant le patch de Linus, si le système de fichier prenait en charge les listes de contrôle d'accès (ACL), alors chaque accès à un fichier non possédé par l'utilisateur déclenchait une vérification des droits ACL en posant un verrou (et ce, même si des droits ACL n'avaient même pas été positionnés). Linus réussit à éviter de poser le verrou dans la plupart des cas et ses tests montrent une amélioration d'environ 3% des temps de latence.
Le patch d'optimisation de Linus a été porté également pour ext4 par Ted Ts'o.
Justement le système de fichiers ext4, considéré comme stable depuis le noyau 2.6.28, continue lui aussi d'être amélioré et de gagner des nouvelles fonctions. Cette fois c'est la défragmentation à chaud qui fait son apparition. Pour piloter cette défragmentation l'outil e4defrag utilise le nouveau contrôle ioctl nommé EXT4_IOC_MOVE_EXT. Theodore Ts'o, le mainteneur d'ext4, tient toutefois à avertir que cette fonction de défragmentation à chaud est encore primitive et que des améliorations seront présentes dans les noyaux suivants.
Comme annoncé par Linus dans le message de la RC-1, le noyau 2.6.31 apporte la prise en charge de nombreuses nouvelles variétés de plate-formes ARM. On peut citer l'entrée dans la branche principale de l'Openmoko GTA02/Freerunner, des diverses variantes du ST-Ericsson U300, du Palm Treo 680 ou encore de la très puissante plate-forme OMAP4 (dual core Cortex-A9).
Le sous-système rfkill a été complètement réécrit dans le nouveau noyau. Rfkill est une interface générique qui permet d'éteindre complètement tous les périphériques qui émettent des ondes radios (Wi-Fi, Bluetooth, etc) souvent par l'intermédiaire des touches sur un ordinateur portable ou par la fermeture de l'écran. Johannes Berg détaille dans son message de commit tous les défauts de l'ancienne interface qui ont été corrigés grâce à la réécriture (factorisation du code de tous les pilotes rfkill, suppressions des verrous inutiles, simplification du code, etc).
Si vous vous sentiez un peu à l'étroit avec les 16 téraoctets de mémoire vive de votre machine x86-64, vous serez heureux d'apprendre que les développeurs du noyau 2.6.31 ont pensé à vous. À partir de cette version la limite de de gestion mémoire de l'architecture x86-64 a été portée à 64 téraoctets (64 x 10^12 octets). Comme on l'a déjà (imprudemment) avancé dans le passé "cela devrait être suffisant pour tout le monde".
La nouvelle pile Firewire/IEEE 1394 qui a été introduite dans le noyau 2.6.22 et connue sous le surnom de "juju", n'est désormais plus considérée comme expérimentale. La plus grande partie des pilotes sont désormais convertis pour utiliser cette nouvelle pile, qui gagne au passage la fonction "IPv4 over IEEE 1394", et ils peuvent donc bénéficier de ses multiples avantages : une meilleure sécurité, un code plus simple, une compatibilité renforcée et des performances en hausse. Attention toutefois car, dans le domaine spécifique de l'audio, c'est l'ancienne pile "Linux1394" qui est recommandée car la nouvelle n'est pas encore compatible avec les périphériques qui utilisent les pilotes FFADO (Free FireWire Audio Drivers).
Une interface de programmation conforme à la RFC-2783 a été incorporée au noyau Linux afin de permettre le support des périphériques PPS (Pulse Per Second). Avec l'ajout par Rodolfo Giometti de cette interface et de sa documentation il est maintenant possible de se servir du signal de haute précision des périphériques externes PPS (souvent des récepteurs GPS) pour ajuster l'heure système de votre machine avec bien moins d'une milliseconde de déviation par rapport à l'heure UTC.
Le protocole USB 3.0 fait son entrée dans le noyau 2.6.31 par l'intermédiaire des patchs de la développeuse Sarah Sharp qui travaille chez Intel (lire son entretien ici).
Linux est ainsi le tout premier système d'exploitation a être compatible avec cette norme permettant de connecter des périphériques à chaud avec un très haut débit (rappelons que le débit maximum prévu par la version 3.0 du protocole USB est de 4,8 Gbit/s soit 10 fois le débit d'USB 2.0). La transition vers USB 3.0 devrait se faire rapidement, car la nouvelle norme garde une compatibilité ascendante et les usines tournent déjà à plein régime pour produire les contrôleurs de bus compatibles.
Pour simplifier la vie des administrateurs paranoïaques (ou consciencieux ?), il est maintenant possible de bloquer très simplement le chargement des modules dans le noyau. Ainsi, après le boot initial et son chargement des modules indispensables, il suffit d'un petit "echo 1 > /proc/sys/kernel/modules_disabled" pour interdire irréversiblement tout chargement ultérieur de modules.
Mel Gorman a proposé plusieurs patchs afin de nettoyer et d'optimiser la très critique fonction d'allocation mémoire se trouvant dans le noyau Linux. Dans son message de description des patchs, Mel signale qu'il a remplacé des embranchements dans le code par une table afin de gagner en vitesse, il a séparé les chemins critiques pour les performances des autres parties, il a évité de répéter de multiples fois le même test, etc. Tout ce travail de bénédictin (plus de 20 patchs en tout) a payé puisque le code est maintenant plus simple et plus efficace. Selon les benchmarks effectués et dont le compte-rendu est disponible ici, on gagne en moyenne 3% sur les performances (les extrêmes vont de 0 à 30%).
La gestion de l'outil de profilage de code gcov entre dans le noyau 2.6.31. Gcov est un projet lié au compilateur GCC qui permet d'obtenir des informations sur les performances du code. Pour profiter de ses services, il faut passer l'option "CONFIG_GCOV_KERNEL=y" et suivre la documentation. On peut ainsi savoir si une ligne de code particulière est exécutée et combien de fois, comment écrire des tests pour couvrir une section particulière de code, quel fraction de temps processeur utilise telle portion de code, etc.
Attention toutefois car un noyau tournant avec gcov activé sera significativement plus gros et plus lent qu'un noyau normal.
Le protocole de communication 802.15.4 est à la base des réseaux Zigbee (la même chose que Bluetooth mais en drastiquement plus simple et moins cher). Le noyau 2.6.31 propose une implémentation initiale du protocole 802.15.4 ainsi qu'une documentation succinte sur cette implémentation et un exemple de pilote. Ces ajouts vont permettre de bâtir des réseaux personnels sans fils (Wireless Personal Area Networks) à bas coût et à très faible consommation.
L'interface interne de programmation (API) des pilotes réseau avait été modifiée dans les noyaux antérieurs au 2.6.31. Le nettoyage, initié par Stephen Hemminger, a consisté à séparer les parties qui gèrent la gestion du pilote de celles qui concernent les données. Dans le nouveau noyau l'ancienne interface, utilisable avec COMPAT_NET_DEV_OPS, a été complètement enlevée des sources et tous les pilotes réseau (plus de 300) sont modifiés. Une démonstration éclatante de la qualité du modèle Linux qui permet, par l'intégration directe des pilotes libres dans les sources du noyau, de procéder à des grandes modifications et optimisations sans craindre les problèmes de compatibilité.
Grâce à Tejun Heo de la société Novell, les périphériques en mode caractère peuvent maintenant avoir des pilotes en espace utilisateur. Ceci est possible grâce à CUSE (Character devices in user space) qui fonctionne en tant que surcouche à FUSE (File systems in user space). Cela permettra d'enlever du noyau les vieux pilotes en mode caractère et de proposer plus proprement une compatibilité avec les vilaines applications qui continuent d'utiliser OSS au lieu de passer à ALSA.
Enfin, si vous avez besoin de mettre en veille ou en hibernation votre mainframe IBM ZSeries comme si c'était un vulgaire ordinateur portable, c'est maintenant possible. La mise en veille est implémentée par ce patch tandis que l'hibernation l'est par celui-ci. Maintenant il vous suffira d'un petit "echo disk > /sys/power/state" pour réduire drastiquement votre facture d'électricité !

Le bilan en chiffres... (↑)

Côté statistiques, l'habituel article récapitulatif du site LWN est disponible et on pourra également se reporter au site dédié aux statistiques du noyau Linux.
Pour le noyau 2.6.31, le nombre de patchs était de 10814 au 03 septembre (11984 pour le 2.6.30) ce qui en fait un cycle de développement normal puisque l'habitude a été prise, aux alentours du 2.6.24, d'avoir plus de 10000 patchs dans un cycle.
Le nombre de développeurs ayant contribué au nouveau noyau s'établit à 1151 (là encore c'est stable par rapport aux 1145 du noyau 2.6.30). Le nombre de lignes de codes ajoutées est d'environ 903000 et le nombre de lignes supprimées d'environ 494000 (croissance de 409000 lignes donc pour ceux qui savent compter sur leurs doigts).
Sans surprise, c'est Ingo Molnar qui est en tête de liste des plus gros contributeurs, c'est le reflet de l'inclusion des patchs de perfcounters, avec 277 patchs (2,6% du total).

Côté entreprises les statistiques, toujours difficiles à établir exactement dans ce domaine, oscillent entre 187 et 194 employeurs différents.
Les développeurs travaillant sur leur temps libre restent en tête (16% des patchs), mais ils sont suivis de très près par Red Hat qui approche les 15%.
Une autre mesure très importante est celle des tags "signoffs" qui n'émanent pas des auteurs du patch. C'est en fait un moyen de voir qui autorise ou pas l'entrée du code dans la branche principale. On retrouve dans cette liste tous les responsables des divers sous-systèmes du noyau Linux (les cinq premiers de la liste sont David S. Miller, Ingo Molnar, Greg Kroah-Hartman, John W. Linville et Andrew Morton).
Il est frappant de constater, en dépit de la très longue traîne, que les développeurs d'un tout petit nombre d'entreprises ont ce rôle de "gardiens du noyau". Rien qu'avec Red Hat on a déjà 38,7% des signoffs n'émanant pas de l'auteur. Si on ajoute Novell, on monte a 49,8%.
En prenant les 5 principales entreprises de ces "gardiens du noyau" (Red Hat, Novell, Intel, Google, IBM) on arrive au total à 68,5% des autorisations d'intégration de patchs.
Au bilan global nous avons donc une version 2.6.31 assez "typique" et une confirmation de la robustesse du mode de développement actuel.

Pour la suite... (↑)

En ce qui concerne les futures nouveautés des prochaines versions du noyau on peut se tourner vers la page spécifique de la Fondation Linux

Il est prévu que le noyau 2.6.32 accueille le résultat du travail de Rafael Wysocki sur le "Runtime power management". Ces patchs implémentent une infrastructure centralisée de gestion de l'énergie qui permettra de mettre en veille et de rallumer à la volée les divers périphériques d'une machine afin de gagner en consommation d'énergie. Ce travail de fond (plus de 17 révisions depuis la proposition initiale) est décrit en détail dans la documentation technique.
Le système de fichiers en réseau NFS a connu de nombreux ajouts lors des dernières versions du noyau Linux. Ce travail prépare progressivement l'entrée de la version 4.1 et permettra de proposer un accès bien plus rapide aux données à travers le réseau. C'est le mécanisme Parallel NFS (pNFS) qui permet cela en envoyant les données à partir de plusieurs disques en parallèle (technique de striping). Le noyau 2.6.31 a accueilli le code qui gère le client NFS 4.1 et il est prévu que le futur noyau 2.6.32 intègre la gestion serveur.

Aller plus loin

Les nouveautés du noyau 2.6.31 (kernelnewbies) (67 clics)
Le bilan des ajouts partie 1 (LWN) (6 clics)
Le bilan des ajouts partie 2 (LWN) (4 clics)
"2.6.31 Tracking" sur le site de H-online (6 clics)
Les prévisions pour l'avenir de Linux (8 clics)

# pfff…

Posté par Zorro (site web personnel) le 10 septembre 2009 à 12:38. Évalué à 10.

Y en a marre, vraiment marre, des dépêches bookmark. Mince, tu pourrais développer un peu, quand même !
- [^] # Re: pfff…
  
  Posté par patrick_g (site web personnel) le 10 septembre 2009 à 12:47. Évalué à 10.
  
  ;-)
  
  En tout cas merci aux relecteurs/correcteurs de la dépêche (baud123, Xate, rootix, plic) et un merci très spécial à Victor Stinner qui s'est tapé tout le boulot de création du magnifique sommaire détaillé.
  - [^] # Re: pfff…
    
    Posté par Ellendhel (site web personnel) le 10 septembre 2009 à 13:08. Évalué à 10.
    
    Je m'insurge : comment trouver le temps de lire tout ça au bureau ?
    
    Non mais, ça ruine notre productivité un article de cette qualité.
    - [^] # Re: pfff…
      
      Posté par mornik le 10 septembre 2009 à 16:28. Évalué à 7.
      
      Je suis sur que Linus attend que la dépêche de patrick_g soit rédigée, et préparée par l'équipe de linuxfr pour annoncer la nouvelle version du noyau. En plus je le suspecte fortement de s'en servir pour faire sa synthèse d'annonce.
      
      Merci pour cette lecture.
- [^] # Re: pfff…
  
  Posté par scullder le 10 septembre 2009 à 13:07. Évalué à 7.
  
  Surtout que c'est encore une dépêche qui parle de cinéma, c'est honteux, dénonçons !
  - [^] # Re: pfff…
    
    Posté par Dup (site web personnel) le 10 septembre 2009 à 16:10. Évalué à 4.
    
    J'avoue j'ai pris le temps de lire cette dépêche au boulot, bon je me garde les liens pour ce soir ;)
# ZSeries

Posté par Geoffrey Gouez (site web personnel) le 10 septembre 2009 à 12:48. Évalué à 9.

« Mise en veille ou en hibernation de mainframe IBM ZSeries »

j'aime bien ce concept :) Je ne pense pas que je me risquerais a faire le test, mais celui qui a fait ca devait avoir une sacrée raison...
- [^] # Re: ZSeries
  
  Posté par Sphax le 10 septembre 2009 à 12:50. Évalué à 4.
  
  Ce point m'a aussi fait sourire :)
  Je me demande bien l'intérêt.
  - [^] # Re: ZSeries
    
    Posté par Nÿco (site web personnel) le 10 septembre 2009 à 12:54. Évalué à 10.
    
    C'est pour les mainframes mobiles... hum...
  - [^] # Re: ZSeries
    
    Posté par Mr Kapouik (site web personnel) le 10 septembre 2009 à 13:04. Évalué à 6.
    
    C'est pour mettre en veille le soir son mainframe sous ubuntu !
    Ralala vous ne comprenez pas Madame Michou * ...
    
    * : Se référer aux livres de référence à savoir "Madame Michou devient DSI" et "Martine administre des serveurs". En plus c'est plein de beau dessins en couleur.
  - [^] # Re: ZSeries
    
    Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 10 septembre 2009 à 15:07. Évalué à 10.
    
    Si vous prévoyez une coupure d'électricité (3 heures par exemples) pour votre centre de calcul, plutôt que de prévenir les utilisateurs de ne plus lancer de jobs, d'arrêter les queues longue durée longtemps à l'avance, de tuer tous les jobs en cours quelques heures avant la coupure ... vous mettez vos machines en hibernation et sitôt le courant revenue, la production redémarre. Et selon le point de vue vous avez économisé quelques MWh en les rendant productifs, ou limité drastiquement les perturbations pour les utilisateurs.
    
    Supposons que tout cela soit encore de la science-fiction car les librairies de parallélisation ne supportent peut-être pas ce genre de coupure. En tous cas, c'est un premier pas dans une bonne direction. Voici l'œuf, la poule viendra en son temps. Plus qu'à mettre le truc dans l'étuve.
    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
- [^] # Re: ZSeries
  
  Posté par Brioche4012 (site web personnel) le 10 septembre 2009 à 13:16. Évalué à 2.
  
  Peut etre que les mainframes ne sont pas utilisés la nuit dans certains cas, donc faire une tache cron pour le mettre en veille le soir permet de grosses economies d'énergie. (Aussi, IBM a beaucoup a gagner a faire valoir que son informatique est verte.)
  - [^] # Re: ZSeries
    
    Posté par Boa Treize (site web personnel) le 10 septembre 2009 à 18:59. Évalué à 3.
    
    Dans certains cas très rares alors, parce que chez la plupart des utilisateurs, les mainframes profitent de la nuit pour faire tourner une tonne de traitements batch vitaux pour leurs propriétaires (genre, exécuter les ordres de virement des clients, mettre à jour la compta, transmettre la liste des modifications à un partenaire externe, etc.).
    
    La bonne réponse est beaucoup plus probablement (ce n'est pas mon domaine d'expertise) que les zSeries sont des machines extrêmement virtualisées, où il est normal de faire tourner plein d'instances d'OS en parallèle (genre 60). Dans ce cas, il peut être très intéressant de mettre un des OS en veille, pour des problèmes de charge par exemple.
    - [^] # Re: ZSeries
      
      Posté par steph1978 le 11 septembre 2009 à 00:52. Évalué à 2.
      
      si c'est virtualisé, il suffit de suspendre la machine virtuelle, non ?
      pas besoin d'hibernation, si ?
    - [^] # Re: ZSeries
      
      Posté par Jllc le 29 septembre 2009 à 22:35. Évalué à 2.
      
      Peut être que pour des serveurs de développement et de test, qui ne servent donc qu'aux heures de bureaux, cela peut être intéressant. Là où je bosse, vu le nombre de serveurs (Unix) qui ne servent qu'en dév et recettes, y'aurait sûrement de quoi faire des économies d'énergie. Sans compter la clim' des salles serveurs (ça chauffe ces machins).
- [^] # Re: ZSeries
  
  Posté par ʭ ☯ le 10 septembre 2009 à 13:18. Évalué à 6.
  
  Il doit pédaler pour que ça reste allumé, avec ce patch il a pu aller dormir!
  ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Un vrai bonheur

Posté par oelson le 10 septembre 2009 à 13:10. Évalué à 3.

Comme d'habitude, 3/4d'heure de lecture enrichissante. Même si je ne comprend que la moitié de l'article.

Continue !
- [^] # Re: Un vrai bonheur
  
  Posté par Olivier (site web personnel) le 10 septembre 2009 à 14:31. Évalué à 0.
  
  Oui pareil ! Je lis toujours tout même si il y a plein de chose qui me dépassent totalement. En parallèle des nouveautés de Snow truc, c’est assez rigolo (et pas du tout comparable, oui, je sais, m’en fou).
  - [^] # Re: Un vrai bonheur
    
    Posté par Zorro (site web personnel) le 10 septembre 2009 à 17:41. Évalué à 5.
    
    C’est pas comparable, la plupart des nouveautés de Snow Truc dont on parle, c’est des machins grand public. Mais si les développement de Darwin étaient aussi ouverts ET si on se penchait sur les nouveautés des noyaux Darwin avec le même niveau de complexité et d’exigeance que cette actu de patrick_g, nul doute que ce sera au moins aussi intéressant.
    Même chose pour Windows, d’ailleurs.
    Ha oui, mince, c’est vrai, tu l’as dit toi-même que c’était pas comparable ! :-)
    - [^] # Re: Un vrai bonheur
      
      Posté par Boa Treize (site web personnel) le 10 septembre 2009 à 19:03. Évalué à 4.
      
      Oh il y a eu des articles techniques de bas niveau sur Snow Truc (il me semble même qu'en apparence peu a changé, alors que techniquement il y a eu beaucoup de consolidation et de nettoyage).
      
      Notamment un article sur les optimisations apportées au chargeur d'applications écrites en Objective C, qui a réduit la consommation mémoire globale de l'OS et a amélioré significativement les temps de démarrage des applications. (Significativement en termes de pourcentages. Pour l'utilisateur, c'est quelques dixièmes de seconde. Mais pour chaque programme lancé.)
# kmemcheck

Posté par Gof (site web personnel) le 10 septembre 2009 à 13:51. Évalué à 9.

« Quand le code fait un appel à la fonction malloc(), il faut écrire quelque chose sur cette zone, par exemple avec la fonction memset(), avant de pouvoir lire cette zone mémoire. Si la mémoire n'est pas initialisée alors toute tentative de lecture provoquera un crash. »

Toute tentative de lecture ne provoquera pas de crash. La lecture fonctionne très bien mais puisque rien n'est initialisé, c'est les données qui était à cet emplacement mémoire avant qui sont lues.
Et c'est souvent la cause de bugs difficile à trouver puisque ces données sont plus ou moins aléatoires.

D'ailleurs, si ça provoquais un crash, on aurais pas besoin de kmemcheck pour les détecter. (car un crash ça se voit)
- [^] # Re: kmemcheck
  
  Posté par patrick_g (site web personnel) le 10 septembre 2009 à 14:32. Évalué à 3.
  
  C'est quand on a de la chance qu'il y a un crash.
  La vraie merde ce sont effectivement comme tu le dis les bugs qui ne causent pas de crash et qui corrompent juste les données.
  - [^] # Re: kmemcheck
    
    Posté par Pierre Carrier le 10 septembre 2009 à 15:32. Évalué à 4.
    
    Non, c'est le but de kmemcheck... Grâce à lui ça déclenche un crash. Au lieu de faire n'importe quoi en toute impunité. C'est grâce à cette techno que bientôt on aura tous des failles à la Debian SSL :)
  - [^] # Re: kmemcheck
    
    Posté par Brice Goglin le 10 septembre 2009 à 22:00. Évalué à 2.
    
    Ca sent la confusion entre mémoire user et noyau là. kmemcheck c'est pour la mémoire noyau. Il n'y a jamais de demand-paging pour la mémoire du noyau Linux, tout est faulté dès l'allocation, que ce soit kmalloc ou vmalloc. Donc (sans kmemcheck), il n'y a jamais de "crash", qu'on ait de la chance ou pas. Pour le cas avec kmemcheck, Geoffroy a bien expliqué ci-dessus.
    - [^] # Re: kmemcheck
      
      Posté par patrick_g (site web personnel) le 11 septembre 2009 à 00:00. Évalué à 1.
      
      >>> Donc (sans kmemcheck), il n'y a jamais de "crash", qu'on ait de la chance ou pas.
      
      Ce n'est pas ce qu'écrit Jon Corbet dans un article ou il évoque kmemcheck ici : http://lwn.net/Articles/260068/
      
      Using uninitialized memory can lead to some seriously annoying bugs. If you are lucky, the kernel will crash (...) Other times, though, something more subtly wrong happens, forcing a long hunt for the stupid mistake.
      - [^] # Re: kmemcheck
        
        Posté par Cédric Chevalier (site web personnel) le 11 septembre 2009 à 01:01. Évalué à 5.
        
        Pour répéter légèrement différemment les explications de Brice et Geoffroy :
        le crash potentiel sans kmemcheck est dû aux conséquences de la lecture de la zone mémoire non initialisée mais ce n'est jamais la lecture elle-même qui génère le crash.
- [^] # Re: kmemcheck
  
  Posté par peck (site web personnel) le 10 septembre 2009 à 16:21. Évalué à 3.
  
  Malloc ne fait pas que définir un emplacement, il faut aussi appel à brk qui prévient le noyau qu'il va utiliser telle quantité de mémoire. Il se peut que la lecture pose aussi problème si elle se fait en dehors de ce brk.
- [^] # Re: kmemcheck
  
  Posté par let antibarbie = xp <- xp - 1 le 12 septembre 2009 à 11:57. Évalué à 0.
  
  Ben si visiblement, kmemcheck se sert d'un pagefault en écriture pour initialiser la page, sinon la lecture dans cette page "non initialisée" provoque un crash.
  - [^] # Re: kmemcheck
    
    Posté par Gof (site web personnel) le 13 septembre 2009 à 14:11. Évalué à 4.
    
    Une erreur_de_page est un processus tout à fait normal et absolument pas une erreur (comme son nom ne l'indique pas)
    
    Il n'y a pas de crash dans l'histoire. kmemcheck log les accès en lecture à de la mémoire non initialisée.
    
    La lecture de mémoire non initialisée est souvent la cause d'un bug. Mais peut aussi être parfaitement légitime. (pour des raison de performance)
# Juste...

Posté par skeespin (site web personnel) le 10 septembre 2009 à 13:54. Évalué à 1.

A quand une version imprimable ?
- [^] # Re: Juste...
  
  Posté par Carl Chenet (site web personnel) le 10 septembre 2009 à 13:59. Évalué à 1.
  
  Très bonne idée.
  - [^] # Re: Juste...
    
    Posté par Victor STINNER (site web personnel) le 10 septembre 2009 à 15:01. Évalué à 2.
    
    Linux Magazine contient des articles similaires sur les dernières nouveautés du noyau. Mais je ne crois pas que les articles soient écrits par patrick_g.
    
    @patrick_g : LinuxMag paie (bien ses auteurs), à toi de voir ;-)
    
    Par contre, j'ai beau cliquer sur mon LinuxMag, Firefox ne réagit pas. C'est un peu nul le papier.
    - [^] # Re: Juste...
      
      Posté par patrick_g (site web personnel) le 10 septembre 2009 à 15:24. Évalué à 10.
      
      >>> @patrick_g : LinuxMag paie (bien ses auteurs), à toi de voir ;-)
      
      Les articles de LinuxMag sont très bien foutus et bien plus techniques et détaillés que les miens. Je serai bien incapable de les écrire.
      Je pense aussi que le public n'est, en partie, pas le même.
      
      C'est assez dur de trouver un niveau de détail qui puisse intéresser la majorité des lecteurs LinuxFR sans (trop) rebuter les grands débutants et sans (trop) ennuyer les vieux routiers. C'est pour ça que j'essaye autant que possible de raconter l'histoire autour du code (comme ici pour fsnotify ou perfcounters) afin que ça ne soit pas trop aride.
      - [^] # Re: Juste...
        
        Posté par Olivier (site web personnel) le 10 septembre 2009 à 16:10. Évalué à 7.
        
        Bravo pour cet article, et ce choix éditorial : Pour ceux qui ne touchent que de loin au kernel, cela permet de découvrir des éléments, et donne de bonne bases pour faire des recherches.
        
        Par exemple, je n'étais pas au courant des capacités de défragmentation de ext4 (personnellement, j'ai 3 disques en production fragmentés à plus de 30%...), et cela donne envie d'utiliser ce FS (même si pour l'instant, la défragmentation reste encore un peu "expérimentale".
        
        [^] # Re: Juste...
        
        Posté par Dafatfab le 10 septembre 2009 à 18:52. Évalué à 0.
        
        personnellement, j'ai 3 disques en production fragmentés à plus de 30%...
        
        Ah, d'accord, t'es sous windows, c'est ça ?
        
        arf, pas pû m'en empêcher... :-) ---> []
        
        [^] # Re: Juste...
        
        Posté par ckyl le 10 septembre 2009 à 19:37. Évalué à 1.
        
        Ah, d'accord, t'es sous windows, c'est ça ?
        
        Tu as une poutre dans l'œil ou quoi ? Aujourd'hui j'ai été obligé de faire un mv /home/moi /backup && mv /backup/moi /home pour essayer de retrouver des perfs raisonnables sur ma station au taff.
        
        Si ext3 ne fragmente pas trop dans certains cas, y'en a plein d'autres ou c'est une catastrophe. Réfléchi à l'utilisation classique d'un /home, l'évolution de son taux de remplissage et au fonctionnement d'ext3. C'est pas difficile de trouver ce qui cloche de ne pas pouvoir faire une défragmentation...
        
        [^] # Re: Juste...
        
        Posté par CrEv (site web personnel) le 10 septembre 2009 à 20:08. Évalué à 2.
        
        (juste comme ça, comment connaitre le taux de fragmentation ? j'dis ça car mon home de taff doit être avec une occupation de plus de 70% depuis au moins 1 an et pourant je bouge bcp bcp de fichiers, surtout des petits, dessus)
        
        [^] # Re: Juste...
        
        Posté par patrick_g (site web personnel) le 10 septembre 2009 à 20:21. Évalué à 3.
        
        >>> juste comme ça, comment connaitre le taux de fragmentation ?
        
        Il me semble qu'après un run de fsck il te dit le pourcentage de fragmentation non ?
        
        [^] # Re: Juste...
        
        Posté par ckyl le 10 septembre 2009 à 20:51. Évalué à 8.
        
        e2fsck -n -E fragcheck /dev/XXX
        
        Ca te donne le nombre de fichiers avec des blocs non contigus par rapport au nombre de fichier total. Et aussi le nombre de blocs non contigus par rapport au nombre de bloc total.
        
        si tu veux des stats sur un fichier il faut jouer avec l'ioctl(2) FIBMAP (cf ioctl_list(2)). T'as un exemple de code là: http://www2.lut.fi/~ilonen/ext3_fragmentation.html
        
        Ne pas avoir de défragmentation online est une bêtise qui s'explique très facilement:
        1- Un système de fichier fragmente *toujours* (fichiers qui grossissent, taux de remplissage important etc.)
        2- Un fichier qui est fragmenté reste fragmenté pour l'éternité. La lutte contre la fragmentation s'effectue lors de l'écriture du fichier. Sauf suppression de fichier, la fragmentation ne peut qu'augmenter.
        
        Les mecs qui disent que ça ne sert à rien sont juste des guignols. La seule différence entre FAT et ext3 c'est que FAT est une bouse pour lutter contre la fragmentation à l'écriture. Ext3 ne retarde que l'échéance.
        
        À terme, on peut aussi imaginer des techniques plus avancées pour placer les fichiers de manière intelligente pour éviter des seeks et gagner du temps lors du lancement d'application etc.
        
        [^] # Re: Juste...
        
        Posté par Victor STINNER (site web personnel) le 11 septembre 2009 à 02:55. Évalué à 7.
        
        Perso j'ai passé des heures à regarder defrag.exe. Mais je préférai son ancêtre sous MS-Dos, l'outil Norton dont j'ai oublié le nom, qui utilisait des couleurs plus jolies et il n'était pas nécessaire de scroller pour voir les animations :-) En plus, y'avait la douce musique du disque dur qui grattait. Ah quand je vais raconter ça à mes enfants qui auront des disques SSD avec défragmentation en ligne...
        
        [^] # Re: Juste...
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 11 septembre 2009 à 09:47. Évalué à 4.
        
        Sur périphériques SSD (pas les disques, ce ne sont pas des disques, justement !), fragmenté ou non, je ne vois pas ce que ça peut changer. Ça peut fragmenter à mort, ça ne devrait pas aller moins vite.
        
        [^] # Re: Juste...
        
        Posté par pasBill pasGates le 13 septembre 2009 à 10:39. Évalué à 2.
        
        En fait ca a un impact, defragmenter un SSD reduit ses perfs.
        
        [^] # Re: Juste...
        
        Posté par mscestdelamerde le 13 septembre 2009 à 19:22. Évalué à 2.
        
        surtout sa duree de vie.
        
        [^] # Re: Juste...
        
        Posté par thedude le 15 septembre 2009 à 00:19. Évalué à 2.
        
        par curiosite, pourquoi donc?
        
        [^] # Re: Juste...
        
        Posté par Maurice Rosenfelder (site web personnel) le 17 septembre 2009 à 02:47. Évalué à 1.
        
        Le nombre de réécritures sur chaque élément du disque est limité.
        
        Même si c'est 100 000 fois, il y a une limite.
        
        Une bonne partie de la cuisine interne du disques est consacrée à ce problème. Il s'agit de répartir uniformément les écritures de telle façon que ce ne soit pas toujours les mêmes éléments qui soient réécrits.
        
        [^] # Re: Juste...
        
        Posté par thedude le 17 septembre 2009 à 03:37. Évalué à 1.
        
        Ca je sais bien, mais le message de pb pg parlait de perf.
        
        Apres, on peut tout a fait considerer la duree de vie comme etant une perf, mais j'avais compris son message dans le sens "performance de lecture/ecriture" pas dans le sens duree de vie.
        
        Et la pour le coup je vois pas trop pourquoi a priori, d'ou ma demande de precision.
        
        [^] # Re: Juste...
        
        Posté par mscestdelamerde le 17 septembre 2009 à 10:12. Évalué à -8.
        
        vu qu'il t'a pas repondu cela sent le gourrage a plein nez.
        
        [^] # Re: Juste...
        
        Posté par pasBill pasGates le 17 septembre 2009 à 10:59. Évalué à 8.
        
        Non, je parlais de perfs.
        
        Les SSDs ont des algos charges de repartir les blocs ecrits (wear-leveling) pour eviter d'ecrire trop de fois les memes cellules, faire cela demande d'avoir un mapping entre les blocs "reels" presentes au FS et les blocs internes.
        
        Lorsque tu defragmentes, en gros tu t'amuses a tout reecrire une fois de plus, en plus de bouffer les cycles d'ecriture, tu risques de rendre cette table encore plus complexe(selon l'odre des effacements/ecritures, ...), ce qui rend les operations futures plus lentes parce qu'il faut se taper cette table bien grosse et complexe apres.
        
        cf. l'Intel X-25 qui avait un cas extreme de cela et pour lequel Intel a du creer un patch du firmware pour limiter la casse.
        
        [^] # Re: Juste...
        
        Posté par Boa Treize (site web personnel) le 11 septembre 2009 à 09:51. Évalué à 2.
        
        Y'a pas besoin de defragmenter les SSD.
        
        De toute façon ils gèrent les blocs à leur sauce, dans le dos de l'OS, auquel ils ne présentent qu'une vue virtuelle des numéros de blocs.
        
        [^] # Re: Juste...
        
        Posté par zebra3 le 11 septembre 2009 à 12:24. Évalué à 3.
        
        Je crois que l'outil Norton s'appelait Speed Disk. Et je me souviens maintenant qu'à une époque, Norton produisait d'excellent outils sur DOS, les fameux Norton Utilities.
        Mais depuis que Symantec a pris la main, ce n'est plus ça...
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Juste...
        
        Posté par gpe le 11 septembre 2009 à 13:05. Évalué à 1.
        
        Ne serait-ce pas le grandiose PCTOOLS ?
        
        [^] # Re: Juste...
        
        Posté par Sylvain Sauvage le 11 septembre 2009 à 18:46. Évalué à 3.
        
        Nan, PC Tools était le principal concurrent de Norton Utilities et ils ont tous les deux été rachetés par Symantec (d’abord NU puis PCT).
        
        [^] # Re: Juste...
        
        Posté par Olivier (site web personnel) le 11 septembre 2009 à 14:31. Évalué à 2.
        
        Bien sûr, je parle de machines Linux...
        
        La cause de cette fragmentation excessive est que sur les machines en question, plusieurs softs lancés en parallèle créent de gros volumes de fichiers. Et comme ils ne pré-allouent pas ces fichiers, ils fragmentent comme des fous.
        
        Tu as le même problème avec les fichiers du /var/log/*
        
        Sur une machine "bureautique", il est très facile de reproduire un comportement similaire, avec des softs faisant par exemple du bittorent ou du emule. Quoi que certains de ces softs commencent par créer un fichier vide occupant la taille totale du fichier final, puis ils le remplisse.
        
        [^] # Re: Juste...
        
        Posté par Kaoru le 10 septembre 2009 à 21:35. Évalué à 7.
        
        ... pour info, il existe un petit outil ma foi fort sympathique et qui, dans mon cas (Debian vieille de quelques années, gnome, usage personnel), obtient d'assez bons résultats quand l'utilisation devient poussive :
        
        http://vleu.net/shake/
        
        Je vous laisse juger par vous-même
      - [^] # Re: Juste...
        
        Posté par Pierre Jarillon (site web personnel) le 10 septembre 2009 à 16:26. Évalué à 10.
        
        Les articles de LinuxMag sont très bien foutus et bien plus techniques et détaillés que les miens. Je serai bien incapable de les écrire.
        
        Alors là, pour la première fois, je ne te crois pas ! Tes articles sur le noyau sont à chaque fois un vrai régal et se lisent comme un roman d'aventures. Car ce développement est une vraie aventure qui marquera notre époque et même notre civilisation.
        
        Tu fais un travail d'historien qui servira aux élèves de CM1 de 2080 quand ils apprendront l'histoire de l'informatique.
        
        [^] # Re: Juste...
        
        Posté par patrick_g (site web personnel) le 10 septembre 2009 à 16:33. Évalué à 2.
        
        >>> Tu fais un travail d'historien qui servira aux élèves de CM1 de 2080 quand ils apprendront l'histoire de l'informatique.
        
        Hem...point trop n'en faut sinon ça va se voir que je stipendie des louangeurs ;-)
        
        [^] # Re: Juste...
        
        Posté par Zorro (site web personnel) le 10 septembre 2009 à 17:44. Évalué à 3.
        
        Des « flagorneurs », encore mieux ! :-)
        
        [^] # Re: Juste...
        
        Posté par riri le breton (site web personnel) le 11 septembre 2009 à 00:04. Évalué à 5.
        
        Et en plus tu nous incites à consulter le dictionnaire. Mais quel talent !
        
        Non sincèrement, comme il a été dit à plusieurs reprises, tes articles sont un régal pour tous ceux qui aimeraient s'intéresser au noyau, du moins à ses évolutions, mais n'ont pas le temps nécessaire à sa compréhension.
        
        Merci et bravo.
      - [^] # Re: Juste...
        
        Posté par CrEv (site web personnel) le 10 septembre 2009 à 16:58. Évalué à 10.
        
        > C'est pour ça que j'essaye autant que possible de raconter l'histoire autour du code
        
        En fait, pour ma part c'est même cette partie là qui m'intéresse le plus.
        Donc merci bien pour cette partie, et surtout continue, c'est un régal.
      - [^] # Re: Juste...
        
        Posté par Spack le 11 septembre 2009 à 02:45. Évalué à 6.
        
        Je lis assez souvent les « Kernel Corner » et il est vrai que c'est très technique donc je suis le plus souvent perdu... Les dépêches ici sont plus vulgarisés et j'arrive à comprendre à peu près tout d'autant que j'aime bien aussi voir comment on en est arrivé là...
        
        C'est un peu le « Loft Story » du développement du noyau et c'est plus intéressant que l'émission originale :).
# Une coquille, une question

Posté par Sylvain Blandel le 10 septembre 2009 à 14:16. Évalué à 2.

La dépêche semble contenir une coquille, située dans le paragraphe consacré à kmemcheck :
Lors d'une allocation mémoire, kmemchek intercepte la demande est crée une allocation parallèle (fantôme) qui va lui servir de référence.

Une question : quel est l'état d'avancement du projet « kill-the-BKL » qui vise à se débarrasser totalement du verrou global ?
Voir cette dépêche qui date de mai 2008 : http://www.linuxfr.org/2008/05/18/24099.html
- [^] # Re: Une coquille, une question
  
  Posté par 🚲 Tanguy Ortolo (site web personnel) le 10 septembre 2009 à 14:25. Évalué à 2.
  
  Une autre coquille, de traduction : il y a un « assume » au lieu de « suppose ».
  - [^] # Re: Une coquille, une question
    
    Posté par patrick_g (site web personnel) le 10 septembre 2009 à 14:38. Évalué à 2.
    
    Corrigé. Merci de la remarque.
- [^] # Re: Une coquille, une question
  
  Posté par patrick_g (site web personnel) le 10 septembre 2009 à 14:35. Évalué à 2.
  
  Merci. Faute corrigée.
  Sur le kernel lock je ne sais pas trop te répondre. J'ai vu passer quelques mails qui concernent ce sujet et c'est donc la preuve que le travail continue doucement...mais je suppose qu'au fur et à mesure que le BKL ne concerne plus que des coins obscurs et très peu utilisés du noyau, l'incitation à le traquer se fait de moins en moins forte.
  - [^] # Re: Une coquille, une question
    
    Posté par Victor STINNER (site web personnel) le 10 septembre 2009 à 15:22. Évalué à 8.
    
    Quelques articles
    * The Big Kernel Lock lives on (May 26, 2004) : Article de corbet
    * tty: BKL pushdown (8 Feb 2008) : email (patch) de d'Alan Cox
    * The big kernel lock strikes again (May 13, 2008) : Article de Jonathan Corbet
    * "kill the Big Kernel Lock (BKL)" tree (14 May 2008) : email d'Ingo
    * Removing the Big Kernel Lock (May 15, 2008) : Article par Jeremy (Kerneltrap)
    * Kill BKL Vol. 2 (May 21, 2008) : Article de Jonathan Corbet
    
    Ingo maintient une branche git (enfin, il me semble que ça soit une branche) qui vise à supprimer le BKL, c'est-à-dire utiliser plusieurs petits verrous pour chaque sous-système :
    http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.(...)
    
    La suppressin du BKL dans ReiserFS a montré un gain significatif de performances.
    http://www.linux-magazine.com/Online/News/Reiserfs-Experienc(...)
    
    Pendant ce temps, FreeBSD supprime progression son BKL avec le travail du groupe SMPng, dont le travail a débuté en 2003.
    http://www.freebsd.org/smp/#status
    « While limited sections of the FreeBSD kernel still require Giant, especially more obscure device drivers and file systems, most parts of the kernel now neither require nor run with the Giant lock »
    
    À priori, FreeBSD est plus en avance que Linux au sujet du BKL.
    - [^] # Re: Une coquille, une question
      
      Posté par Victor STINNER (site web personnel) le 10 septembre 2009 à 15:26. Évalué à 6.
      
      Rah mince, la syntaxe (a href=...) ne fonctionne pas dans un commentaire ?
      
      * The Big Kernel Lock lives on: http://lwn.net/Articles/86859/
      * tty: BKL pushdown: http://lwn.net/Articles/268721/
      * The big kernel lock strikes again: http://lwn.net/Articles/281938/
      * "kill the Big Kernel Lock (BKL)" tree: http://lwn.net/Articles/282319/
      * Removing the Big Kernel Lock: http://kerneltrap.org/Linux/Removing_the_Big_Kernel_Lock
      * Kill BKL Vol. 2: http://lwn.net/Articles/283066/
      
      Raah, je lis sans arrêt "Kill Bill".
    - [^] # Re: Une coquille, une question
      
      Posté par patrick_g (site web personnel) le 10 septembre 2009 à 15:27. Évalué à 5.
      
      Je pense que la phrase "most parts of the kernel now neither require nor run with the Giant lock" s'applique aussi parfaitement à Linux donc je ne sais pas si FreeBSD est en avance ou pas.
    - [^] # Re: Une coquille, une question
      
      Posté par fweisbec le 12 septembre 2009 à 02:34. Évalué à 10.
      
      La branche kill-the-bkl d'Ingo est un peu à l'abandon en fait.
      Parce que le soucis c'est que dans cette branche, le BKL est transformé en mutex.
      
      Ca permet de voir ce que ça donne lorsque le bkl est converti en verrou traditionnel.
      Donc avec cette branche le noyau crash assez vite, dû au fait qu'on verrouille le gros
      mutex recursivement et donc ça crée un interblocage.
      
      Cette branche est (était?) un excellent outil parce que justement ça permettait de savoir où
      ça crashait, et aussi de voir les problèmes d'inversion de dépendance (grace à lockdep) qui
      ne peuvent pas être vérifiés avec le BKL normal.
      
      En bref c'est un excellent outil pour débusquer la bête, par contre si cette branche venait
      à être appliquée dans le noyau principal, ce serait un désastre pour sa stabilité :-)
      
      Pour ce qui est de la branche reiserfs/kill-the-bkl http://git.kernel.org/?p=linux/kernel/git/frederic/random-tr(...) (dont je suis l'heureux papa :-), les performances sont bien meilleures lorsqu'il s'agit d'écritures parallèles sur différentes partitions, par contre sur une seule partition c'est pas encore ça.
      
      Le soucis c'est que j'avais fait quelques optimisations qui ont fini par rattraper les performances de la version bkl, voire même de les dépasser dans la plupart des cas. Mais on a découvert plus tard que cette optimisation avait créé une inversion de dépendance de vérrou.
      Il va donc falloir que je fasse quelques pas en arrière et trouver d'autres optimisations.
      J'espère pouvoir en arriver à bout pour 2.6.33, normalement ça devrait aller.
      
      Sinon les efforts concernant le balayage du bkl se sont egrainés, il ya eu quelques contributions par ci par là qui devraient faire leur chemin pour le noyau 2.6.32
      
      En fait c'est vrai que le bkl a été dégagé de la plupart des coins du noyau, mais il reste encore beaucoup utilisé mine de rien, sporadiquement dans des coins lugubres du noyau (tty, block...). Et c'est un gros soucis pour les developpeurs du patch temps réels. En particulier parce qu'ils sont en train de faire plein d'efforts pour intégrer les patchs temps réels dans la branche principale. Ca va assez vite d'ailleurs, mais leur plus gros soucis c'est le bkl qui crée d'enormes latences. Dans la branche temps-réel, ils ont un patch pour ça qui rend le bkl préemptible. Mais Linus ne veut pas de ce patch parce que les gens ne trouverons plus de bonne raisons à se consacrer au balayage du bkl s'il l'applique, alors les développeurs temps réels n'ont rien d'autres à faire que de le dégager.
      
      Tiens par exemple Thomas Gleixner a ouvert une page là-dessus avec l'état d'avancement:
      http://rt.wiki.kernel.org/index.php/Big_Kernel_Lock
      - [^] # Re: Une coquille, une question
        
        Posté par patrick_g (site web personnel) le 12 septembre 2009 à 10:19. Évalué à 2.
        
        Merci pour toutes ces infos et bravo pour ton boulot d'éradication ;-)
        Par curiosité pourquoi avoir choisi de bosser sur reiserfs qui n'est pas, c'est le moins qu'on puisse dire, le fs le plus utilisé sous Linux et qui le sera de moins en moins ?
        
        [^] # Re: Une coquille, une question
        
        Posté par fweisbec le 12 septembre 2009 à 22:58. Évalué à 10.
        
        Par naïveté ;-)
        
        En fait je bossais sur cette branche d'Ingo qui convertissait le BKL en mutex.
        Et puis comme ma machine se figeait complètement dès qu'elle touchait à mes partitions reiserfs, je me suis dit que je commencerais bien par là. D'autant que j'avais déjà bossé un chouilla sur reiserfs (un parseur pour le Hachoir de Victor Stinner).
        
        C'est là que la naiveté commence. Je pensais que construire un simple lock basé sur un mutex pouvant être verrouillé recursivement (donc juste avec un compteur de référence de vérrouillage en plus) suffirait pour l'affaire.
        
        Mais non. Le bkl a d'autres propriétés lamentables que le fait de pouvoir être verrouillé recursivement: il est implicitement relaché lorsqu'une tâche dort, et réattribué lorsqu'elle se réveille. Ce qui n'est pas le cas d'un mutex.
        
        Ce qui fait qu'il y a plein de parties dans reiserfs qui comptent sur le fait qu'en dormant à tel endroit, le vérrou du systeme de fichier est relaché laissant place à un autre utilisateur.
        
        Un cas clinique: une partie du code tombe sur des données qui ont besoin d'être flushées (= écrites sur le disque) avant de continuer, alors il dort, le vérrou se relâche implictement, laissant la place à un thread spécifique qui va flusher justement. Car ce flusher a lui aussi besoin du vérrou pour accéder aux données à écrire.
        Mais voilà, avec un mutex il faut relâcher le vérrou explicitement.
        Et reiserfs est bourré d'endroits comme ça.
        
        Mais bon la majeure partie de ce boulot est terminé.
        L'autre problème c'est que le bkl est un spinlock, donc plus rapide qu'un mutex car le spinlock boucle et prend le vérrou dés qu'il peut, alors qu'un mutex va faire dormir le processus en attendant. D'un autre côté le mutex va permettre à un autre processus de s'executer, ce qui est bien en cas de vérrou vérouillé longtemps. Mais s'il n'est pas vérrouillé longtemps, on perd du temps à switcher d'un processus à un autre.
        Bref, le mutex est un poil moins efficace (même si les mutex peuvent boucler depuis 2.6.30 dans certaines situations).
        
        Donc le reste du boulot c'est rattrapper les pertes de performances induites par la conversion du bkl. Heureusement maintenant il y a perfcounters. Couplé avec ftrace, c'est un outil magique pour trouver les points faibles dans un code :-)
        
        Un autre truc avec reiserfs: c'est l'un des derniers gros utilisateurs du bkl, donc sa dératisation est plutôt désirée. Même s'il n'est plus dans les systèmes de fichiers les plus utilisés, il reste encore beaucoup utilisé (la migration de système de fichiers sur plein de serveurs, ça peut coûter cher).
  - [^] # Re: Une coquille, une question
    
    Posté par Sylvain Blandel le 10 septembre 2009 à 19:39. Évalué à 0.
    
    Merci à Victor STINNER pour sa réponse.
    Et grand bravo à Patrick_g pour sa dépêche.
# kilo

Posté par Gof (site web personnel) le 10 septembre 2009 à 16:30. Évalué à 1.

« Avec la nouvelle taille de bloc à 4 kilo octets on peut se contenter d'enregistrer ça : [Divers][----------4096 octets de données----------][ECC] »

Et encore une erreur dans la dépêche de patrick_g :-)

kilo veux dire 1000
Or ici, c'est bien 4 * 1024 soit 4 kibi octets.
- [^] # Re: kilo
  
  Posté par Strash le 10 septembre 2009 à 16:40. Évalué à 9.
  
  Non, on est pas dans une année bissextile, donc Kilo correspond bien à 1024 voir la définition du standard : http://xkcd.com/394/
  - [^] # Re: kilo
    
    Posté par Pierre Jarillon (site web personnel) le 12 septembre 2009 à 02:44. Évalué à 3.
    
    Je préfère donner ce lien plus officiel : Prefixes for binary multiples, International Electrotechnical Commission (IEC) http://physics.nist.gov/cuu/Units/binary.html
- [^] # Re: kilo
  
  Posté par CrEv (site web personnel) le 10 septembre 2009 à 16:56. Évalué à 9.
  
  > kibi octets
  
  ha mais parce que quelqu'un utilise _vraiment_ ces unités ?
  - [^] # Re: kilo
    
    Posté par Zorro (site web personnel) le 10 septembre 2009 à 17:46. Évalué à 2.
    
    J’ai vu passer, dans certains textes et écrans de Mandriva, à une époque, les termes Kib, ou des trucs comme ça. Ça fait bizarre… Soit ça prend, soit ça prend pas et alors on arrive à une sorte de distorsion de réalité.
  - [^] # Re: kilo
    
    Posté par Nicolas Boulay (site web personnel) le 10 septembre 2009 à 17:51. Évalué à 7.
    
    Les outils Linux respectent ça. Au moins quand on voit écrit MiB on sait de quoi on parle.
    "La première sécurité est la liberté"
    - [^] # Re: kilo
      
      Posté par CrEv (site web personnel) le 10 septembre 2009 à 18:12. Évalué à 1.
      
      c'est quoi "Les outils Linux" ?
      
      parce que faut croire qu'on a soit pas les mêmes outils, soit pas le même linux ;)
      [~] df ... /dev/sda7 15G 14G 682M 96% /home ...
      
      En fait j'ai même ni i, ni o, ni B et je sais très bien de quoi ça parle justement...
      - [^] # Re: kilo
        
        Posté par Benoît Sibaud (site web personnel) le 10 septembre 2009 à 18:28. Évalué à 6.
        
        $ df -H /dev/hda2
        Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
        /dev/hda2 343M 238M 87M 74% /
        $ df -h /dev/hda2
        Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
        /dev/hda2 327M 227M 83M 74% /
        
        $ du -h /boot/vmlinuz-2.6.29-1-686
        1,7M /boot/vmlinuz-2.6.29-1-686
        $ du --si /boot/vmlinuz-2.6.29-1-686
        1,8M /boot/vmlinuz-2.6.29-1-686
        
        ...
        
        [^] # Re: kilo
        
        Posté par CrEv (site web personnel) le 10 septembre 2009 à 20:07. Évalué à 2.
        
        merki, je connaissais pas ces options (faut dire que ma distrib les alias toutes pour que ce soit humain à lire, donc je ne les change pas en général)
      - [^] # Re: kilo
        
        Posté par huitopy le 10 septembre 2009 à 23:31. Évalué à 1.
        
        Y'a au moins Gparted et le moniteur système de gnome qui utilisent les notations en kio Mio Gio et je crois l'avoir vu ailleurs aussi, mais c'est pas le genre de choses que je note ;-)
        
        [^] # Re: kilo
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 10 septembre 2009 à 23:33. Évalué à 6.
        
        Tout GNOME, en fait.
        
        [^] # Re: kilo
        
        Posté par gnumdk (site web personnel) le 10 septembre 2009 à 23:50. Évalué à 3.
        
        Kde4 aussi
    - [^] # Re: kilo
      
      Posté par Victor STINNER (site web personnel) le 10 septembre 2009 à 18:29. Évalué à 5.
      
      MiB : yep, d'extraterrestres, de flashouilleurs et de Will Smith.
      
      Nan je déconne, MiB c'est Mailinblack !
      - [^] # Re: kilo
        
        Posté par Larry Cow le 11 septembre 2009 à 12:25. Évalué à 2.
        
        Nan je déconne, MiB c'est Mailinblack !
        
        Toutes mes condoléances...
  - [^] # Re: kilo
    
    Posté par Pierre Tramo (site web personnel) le 10 septembre 2009 à 18:14. Évalué à 5.
    
    Ca doit être les mêmes qui utilisent cédérom, dévédérom, courriel...
  - [^] # Re: kilo
    
    Posté par Brice Goglin le 10 septembre 2009 à 22:08. Évalué à 3.
    
    Oui, dans les publis parlant de débit des réseaux haute performance par exemple. Les gens du marketing ont tellement triché sur les débits en mélangeant 1Go et 1Gio (7% de différence) que les gens honnêtes se mettent à utiliser explicitement Gio/s pour qu'on sache de quoi ils parlent.
    - [^] # Re: kilo
      
      Posté par liberforce (site web personnel) le 16 septembre 2009 à 18:41. Évalué à 7.
      
      Y a des gens qui parlent de Gio/s en réseau ? Je croyais qu'on parlait qu'en bits (Gb/s), ce qui évite de facto ce problème ?
  - [^] # Re: kilo
    
    Posté par Zenitram (site web personnel) le 11 septembre 2009 à 00:34. Évalué à 4.
    
    ha mais parce que quelqu'un utilise _vraiment_ ces unités ?
    
    Oui, moi tout le temps, cf ma page perso, pour réussir à expliquer que non, 1 MB n'est pas 1000000 d'octets quand "MB" est affiché par certains à la place de MiB. C'est encore plus dur à expliquer quand un MP3 à 128 Kbps veut bien dire, lui, 128000 bps...
    
    La différenciation devient de plus en plus importante, surtout quand les débits sont eux comptés (musique, vidéo, réseau...) avec 1 K = 1000, et les tailles de fichiers avec 1 K(i) = 1024. Et l'importance croit avec l'augmentation des volumes ( 1 To = 0.93 Tio, soit 7% de moins quand même... Notez que les disques dur sont vendus avec 1K = 1000 de nos jours)
    - [^] # Re: kilo
      
      Posté par thedude le 11 septembre 2009 à 01:33. Évalué à 2.
      
      Notez que les disques dur sont vendus avec 1K = 1000 de nos jours
      
      ils l'ont toujours ete non?
      Aussi loin que je me rappelle en tout cas.
      
      On les comprends aisement cela dit, ca gonfle leurs chiffres...
      - [^] # Re: kilo
        
        Posté par Zenitram (site web personnel) le 11 septembre 2009 à 01:48. Évalué à 2.
        
        ils l'ont toujours ete non?
        
        Non.
        Je ne me rappelle plus exactement à quel moment ni quelle capacité, je taperai très grosso modo dans le début des années 2000 vers les capacités de 1 Go. Et après quelle marque a commencé ce jeu, mes souvenirs me font défauts, les salauds...
        
        Aussi loin que je me rappelle en tout cas.
        
        Voila, tu sais maintenant que je suis plus vieux que toi (dans l'informatique en tous cas)
        
        [^] # Re: kilo
        
        Posté par thedude le 11 septembre 2009 à 04:12. Évalué à 2.
        
        Voila, tu sais maintenant que je suis plus vieux que toi (dans l'informatique en tous cas)
        
        Ou pas.
        Je peux etre bien plus vieux et avoir une memoire en compote
        :-P
        
        Bref, merci de la precision (et au passage, rien a voir, mais merci pour mediainfo, il m'a pas mal servi le we dernier).
        
        [^] # Re: kilo
        
        Posté par Maxime G (site web personnel) le 11 septembre 2009 à 17:19. Évalué à 4.
        
        1.44*1000*1000/1024/1024=1.37
        Ça ne vous rappelle rien ?
        
        Ah cet époque, quelle déception quant on en été réduit à compter les Ko après zippage pour faire rentrer ça sur une disquette et qu'on se disait :
        "1.43M, ça passe !!!"
        et ben non !
        
        Maudis marketers !
        
        [^] # Disquette "1.44 MB"
        
        Posté par Zenitram (site web personnel) le 11 septembre 2009 à 17:33. Évalué à 10.
        
        1.43 MiB ne passaient effectivement pas, mais 1.40 passait... Et non, 1.37 MiB n'est pas la limite d'une disquette 1.44 MB!
        
        C'était encore plus vicieux.
        * Un disquette de "720 KB" faisait bien 720 KiB en réalité (2 faces * 80 pistes * 9 secteurs * 512 octets), soit 737 280 octets.
        * Une disquette de "1.44 MB": on double la densité (2 faces * 80 pistes * 18 secteurs * 512 octets), donc ça fait 1440 KiB, tout le monde suit? Et la, le drame, les marketeurs divisent pas 1000 pour donner 1.44 MB. Ce MB signifie donc 1000*1024, encore plus bâtard!
        
        Une disquette de 1.44 MB fait en réalité 1.44*1000*1024 = 1.40625 MiB.
        
        Bref, une jolie merde qui mixe 1K = 1024 et 1M = 1000, c'est-il pas joli comme tambouille?
        
        Tout ça ne nous rajeunit pas...
        
        [^] # Re: Disquette "1.44 MB"
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 11 septembre 2009 à 23:00. Évalué à 2.
        
        Bah, de toute façon la vraie capacité d'une disquette, c'est 1720 kio. Ou 1790, je ne sais plus. Mais bien plus que 1440 kio, en tout cas.
        
        Sans compter les japonais qui avaient des disquettes quadruple densité, eux.
    - [^] # Re: kilo
      
      Posté par benoar le 17 septembre 2009 à 00:52. Évalué à 3.
      
      À propos de ta remarque sur le MP3, j'ai une pseudo-règle qui marche assez bien : quand on parle de bits, et pas d'octets, c'est souvent des multiples de 1000. C'est valable en son, en réseau, etc.
      - [^] # Re: kilo
        
        Posté par boq le 17 septembre 2009 à 06:24. Évalué à 4.
        
        En fait c'est hyper simple. Quand on parle de débit (réseau, son ...) c'est des multiples de 1000.
        Sinon c'est 1024.
        
        Enfin c'était comme ça à la base, maintenant si les marketeux se mettent à tout mélanger pour nous entuberappâter, effectivement le i n'est plus de trop.
        
        [^] # Re: kilo
        
        Posté par benoar le 17 septembre 2009 à 06:44. Évalué à 3.
        
        Ha ok, merci, maintenant ça me paraît évident, c'est vrai que les débits se font souvent en kilo/mega_bit_ par second, et les capacités en kibi/mebi_byte_.
    - [^] # Re: kilo
      
      Posté par François B. le 30 septembre 2009 à 13:37. Évalué à 4.
      
      Non, 1 K = 1 Kelvin
      Le multiplicateur 1000 sur les unités est un k minuscule pour ne pas confondre avec l'unité de température.
  - [^] # Re: kilo
    
    Posté par Maxime (site web personnel) le 13 septembre 2009 à 16:26. Évalué à 8.
    
    C'est pour moi indispensable dès qu'on veut être précis et qu'on fait des calculs dans des domaines qui sortent un peu de l'informatique.
    
    Il suffit par exemple de commencer sur des calculs de physique, d'électronique, etc ou tu fait des calculs de bande passante où tu as des données de calcul en MHz et des informations sur l'échantillonnage etc. Tu peux pas mélanger d'un coté des Mega et de l'autre des "Mega" au sens informatique (2^20), ça fini en des erreurs à la fin...
    Alors faut arrêter avec cet abus de notation, utilisons les Mebi, Kibi &co ! Avec une seule lettre, on retire *enfin* une ambiguïté ! C'est une norme assez récente (1999 ?) ce qui explique sa faible utilisation.
    - [^] # Re: kilo
      
      Posté par Boa Treize (site web personnel) le 14 septembre 2009 à 14:25. Évalué à 3.
      
      C'est surtout le fait que les noms sont merdiques qui explique sa faible utilisation. S'ils ne sonnaient pas aussi ridicule, je les utiliserais depuis longtemps. Là, je fais de la résistance depuis longtemps.
      - [^] # Re: kilo
        
        Posté par Thomas Douillard le 14 septembre 2009 à 15:43. Évalué à 4.
        
        C'est, comment dire ... adulte ? Tu leur reproche quoi exactement ?
      - [^] # Re: kilo
        
        Posté par Maxime (site web personnel) le 14 septembre 2009 à 18:47. Évalué à 3.
        
        Tu préfères l'incertitude avec des noms qui claques à de la rigueur mais avec des noms moyens ?
        C'est vrai que je n'avais pas pris en compte la "beauté" des noms... Je pensais pas que ça pouvais vraiment avoir tant d'importance...
- [^] # Re: kilo
  
  Posté par teoB le 10 septembre 2009 à 21:04. Évalué à 1.
  
  Dans le même genre, pour la RAM c'est vraiment 64*10^12 octets ? car la RAM est plutôt organisée en puissance de 2. Ça devrait plutôt être 64*2^40 soit 2^46 octets (64 Tio), non ?
# radeon KMS

Posté par med le 10 septembre 2009 à 16:42. Évalué à 10.

Pour les propriétaires de r6xx/r7xx, KMS devrait être intégré dans le noyau 2.6.32, plus que 3 mois à attendre donc. Et comme une bonne nouvelle ne vient jamais seule, la 3D devrait normalement être fonctionnelle elle aussi. http://airlied.livejournal.com/68097.html pour plus de détails.
- [^] # Re: radeon KMS
  
  Posté par Ririsoft le 10 septembre 2009 à 17:46. Évalué à 4.
  
  Je vois que je ne suis pas le seul à suivre l'actualité ATI pour les chipset R6xx !
  Merci pour l'info en tout cas, j'étais désespéré de voir que KMS n'arrivait que pour les vieux chipsets d'ATI ...
  
  Il semblerait même que les heureux utilisateurs de Fedora pourront en bénéficier dès F12 (avant la sortie officielle du noyau 2.6.32). D'après la source que tu cites les patchs sont dans la branche de développement.
  
  A moins que je n'ai pas tout compris ?
  - [^] # Re: radeon KMS
    
    Posté par med le 10 septembre 2009 à 19:00. Évalué à 4.
    
    Vu que j'ai une radeon HD 4850 je suis ça d'assez près. KMS est un grand pas en avant. Maintenant j'attends avec une grande impatience l'arrivée des pilotes Gallium 3D. La refonte engagée il y a quelques années finit enfin par porter ses fruits. Maintenant la progression au niveau de la 3D devrait être beaucoup plus facile.
    - [^] # Re: radeon KMS
      
      Posté par glisse le 11 septembre 2009 à 00:34. Évalué à 5.
      
      Encore bcp de boulot bas niveau, mais je pense que d'ici 1 ans on fera beaucoup plus de progres en userspace qui seront plus visible pour l'utilisateur final.
      - [^] # Re: radeon KMS
        
        Posté par Davy Defaud le 11 septembre 2009 à 03:30. Évalué à 3.
        
        Jérôme, je profite de ta présence avisée, pour te poser une petite question parallèle au sujet KMS :
        
        Que manque-t-il encore pour que l'on puisse utiliser officiellement DRI2 et le Redirected Direct Rendering sur les matériels ATI/AMD (le mien est un "vieux" R580) dont ce nouveau noyau implémente déjà (quoique en déclaré non stable) ledit KMS(+TMM) ?
        
        - la sortie officielle de Mesa 7.6 (récemment gelé) contenant radeon-rewrite ?
        - le serveur Xorg 1.7 (récemment gelé également), contenant le dernier pilote DDX pour ATI ?
        - d'autres bidules (libdrm...) ?...
        
        Et puisque l'occasion m'est donnée, j'en profite également pour te remercier de ton immense contribution. Je vais peut-être très bientôt pouvoir utiliser convenablement ma carte graphique avec mon SE préféré et ce sera en partie grâce à toi.
        Cela devenait d'autant plus urgent qu'ATI a définitivement abandonné le support des GPU < R600 dans ses pilotes FGLRX. Pilotes qui n'ont jamais tenu leurs promesses par ailleurs, toute nouvelle fonction étant implémentée 2 ans après NVidia (GLX_EXT_texture_from_pixmap permettant le support de Compiz, Redirected Direct Rendering...) !
        
        [^] # Re: radeon KMS
        
        Posté par glisse le 11 septembre 2009 à 12:22. Évalué à 5.
        
        Tant qu'on est en staging l'userspace ne sera pas officiellement supporté. Il incombe (tout comme il en décombe à forciori ! ;)) au distribution de l'activer ou non. Fedora 12 aura bien le DRI2 et tout le trala pour les autres je sais pas trop.
        
        [^] # Re: radeon KMS
        
        Posté par Davy Defaud le 11 septembre 2009 à 13:59. Évalué à 2.
        
        Ok, mais est-ce que les pré-requis sont bien ceux que j'ai cités (serveur X.org 1.7, mesa 7.6, libdrm...) ? En ai-je oublié ?...
        
        Pascal Terjan devrait être en mesure de nous dire s'il est prévu de l'activer sur le noyau desktop final de la Mandriva 2010.0 ? Il y a le noyau tmb au pire, mais ça restera plus confidentiel.
        Par ailleurs, Pascal, est-il déjà trop tard, comme je le crains, pour envisager l'inclusion des autres éléments nécessaires (serveur X.org 1.7, mesa 7.6...). Est-il envisagé ou envisageable de fournir tout cela en cooker/testing pour les plus aventureux ?
        
        [^] # Re: radeon KMS
        
        Posté par moi1392 le 11 septembre 2009 à 18:28. Évalué à 1.
        
        le serveur, c'est "xserver" et il là prochaine version est bien la 1.7 (qui devrait sortie à la fin du mois... normalement...)
        Xorg, c'est xserver plus tout un tas d'outils et de libs qui vont avec et qui font que tu as sur une machine un serveur graphique fonctionnel et des clients qui peuvent s'y connecter.
        La prochaine version de Xorg est la 7.5, car depuis la modularisation avec Xorg 7.0, xserver et les autres modules peuvent avoir des sorties désynchronisées (il y en a eu 2 pour xserver par exemple, la 1.3 et la 1.6)
        
        [^] # Re: radeon KMS
        
        Posté par Davy Defaud le 12 septembre 2009 à 02:23. Évalué à 3.
        
        Oui je suis au courant, je suis un lecteur assidu des articles de Phoronix qui sont une bonne source d'information sur le sujet.
        Je m'étais mal exprimé et il fallait bien évidemment comprendre xserver 1.7, mais vu le n° de version - 1.7 -, je pense que tout le monde avait compris que je parlais du serveur X...
        
        Pour info, un serveur X 1.7-RC1 pour les Mandriviens est dispo depuis ce soir en i586 et d'ici 2 jours pour les x86_64 (http://lists.mandriva.com/cooker/2009-09/msg00300.php).
        
        De plus, le premier noyau 2.6.31 final de chez Mandriva est dispo... avec KMS pour ATI (< R600) activé !
        
        Voilà qui répond à deux de mes interrogations précédentes.
        
        Il manque encore une mise à jour de mesa et de libdrm (compilés en expérimental d'après ce que me dit Jérôme ci-après).
        
        On y est presque !!!
        
        [^] # Re: radeon KMS
        
        Posté par liberforce (site web personnel) le 16 septembre 2009 à 18:50. Évalué à 3.
        
        De plus, le premier noyau 2.6.31 final de chez Mandriva est dispo... avec KMS pour ATI (< R600) activé !
        
        Damned, et la RC1 qui est censée sortir demain ! Possesseurs de cartes ATI (R350 pour moi), à vos machines !
        
        [^] # Re: radeon KMS
        
        Posté par Davy Defaud le 18 septembre 2009 à 02:10. Évalué à 3.
        
        C'est pas encore gagné, le KMS a été désactivé dans le deuxième noyau (2.6.31-2mnb) :
        
        «
        * mar. sept. 15 2009 Herton Ronaldo Krzesinski <herton@mandriva.com.br> 2.6.31-2mnb
        o Thomas Backlund <tmb@mandriva.org>
        - disable radeon kernel modesetting again as it breaks too many systems
        »
        
        [^] # Re: radeon KMS
        
        Posté par glisse le 11 septembre 2009 à 21:33. Évalué à 1.
        
        Oui, le seul truc c'est que la libdrm doit etre compile avec un flags experimental pour activer le kms et le ddx ati et mesa doivent etre compiles contre la libdrm avec le flag experimental.
- [^] # Re: radeon KMS
  
  Posté par FantastIX le 11 septembre 2009 à 17:30. Évalué à 4.
  
  Pour les propriétaires de r6xx/r7xx, KMS devrait être intégré dans le noyau 2.6.32
  
  J'en suis un. Et j'ose dire que je brûle d'impatience (c'est un euphémisme) de voir arriver KMS et Mesa 7.6. Un article publié en août sur le site de Phoronix [http://www.phoronix.com/scan.php?page=news_item&px=NzQyN(...)] a déclaré que glxgears fonctionnait sur les modèles R6xx et R7xxx. Le code est fonctionnel (Yessssssss!) et n'attend plus qu'à être publié, déployé et testé.
  - [^] # Re: radeon KMS
    
    Posté par glisse le 11 septembre 2009 à 21:31. Évalué à 2.
    
    Enfin faut pas trop s'exciter non plus :), je crois qu'on a plus de 400bugs d'ouvert alors tout marchera pas super pour tout le monde.
    - [^] # Re: radeon KMS
      
      Posté par FantastIX le 12 septembre 2009 à 03:22. Évalué à 1.
      
      Enfin faut pas trop s'exciter non plus :), je crois qu'on a plus de 400bugs d'ouvert alors tout marchera pas super pour tout le monde.
      
      Possible. Mais en attendant, ça a au moins le mérite d'exister!
# deplacement de nouvelles?

Posté par mscestdelamerde le 10 septembre 2009 à 18:47. Évalué à -2.

Je pense que c'est dommage qu'une nouvelle telle que celle la se retrouve a peine quelques heures apres sa publication en 3eme position sur la page du site. Enfin ceci n'engage que moi mais tout de meme je pense que mettre les nouvelles sur le noyau linux et qui plus d'une telle qualite de facon bien visible serait plus normale pour linuxfr.
- [^] # Re: deplacement de nouvelles?
  
  Posté par Sarcastic le 10 septembre 2009 à 19:06. Évalué à 3.
  
  C'est quelque chose qui existe déjà avec la fonction de tri par « intérêt » qui est un mix du tri par note et du tri chronologique.
- [^] # Re: deplacement de nouvelles?
  
  Posté par steph1978 le 11 septembre 2009 à 00:57. Évalué à 2.
  
  "Enfin ceci n'engage que moi" => en effet.
  
  le site est ainsi fait que les dépèches sont par ordre chronologique, ce qui permet de le lire régulièrement sans en louper. d'autres part, toutes les dépèches ont leur légitimité.
  celles sur le noyau se repèrent facilement grâce à l'icone.
  je doute que tu sois tombé dessus pas hazard, ça n'a pas mon cas.
# A propos de la faille de sécurité..

Posté par Romain Be. le 10 septembre 2009 à 21:31. Évalué à 1.

Tout d'abord, très bonne depèche, bravo !

A propos de la faille de sécurité SELinux et compagnie. Ce que le lis là:
http://lwn.net/Articles/347006/
C'est qu'en fait la vraie faille concernait l'utilisation de certaines opérations sur les socket pour lesquelles les pointeurs définissant les opérations applicables sur la socket étaient non initialisés.

Ainsi, pour pouvoir exploiter la faille, il fallait alors faire remplir l'adressage mémoire initial, zero, avec la fonction à executer, et on se retrouve avec la possibilité d'exécuter n'importe quoi avec les droit root.

Ainsi, le paramètre qui permet de choisir un adressage mémoire minimal plus grand que zero est une façon d'empecher l'exploitation de la faille et non la faille elle-même.
- [^] # Re: A propos de la faille de sécurité..
  
  Posté par Victor STINNER (site web personnel) le 11 septembre 2009 à 03:01. Évalué à 5.
  
  L'auteur de grsecurity (suites de patchs pour le noyau visant à en reforcer la sécurité), Brad Spengler, a pris un malin plaisir à démontrer que SELinux (le concurrent de grsecurity) était faillible (contient une faille qui permettait de contourner les protections). Il a fait de même pour les autres systèmes de sécurité (LSM et audit en général). Voir les articles suivants pour les détails :
  http://linuxfr.org/2009/07/18/25744.html
  http://linuxfr.org/2009/07/24/25761.html
  http://linuxfr.org/~patrick_g/28661.html
  
  C'est grâce à au travail de Brad que la sécurité de SELinux a été renforcée dans Linux 2.6.31.
  
  Au sujet de mmap_min_addr, je pense que cet article explique bien l'histoire.
  - [^] # Re: A propos de la faille de sécurité..
    
    Posté par Romain Be. le 11 septembre 2009 à 05:03. Évalué à 1.
    
    Justement, Brad Spengler étant un personnage qui aime bien la polémique (voir son interview, le deuxième lien), et développant un concurrent direct de SELinux, je pense qu'il serait quand plus honnête de développer les problèmes et d'utiliser une terminologie moins partisane
    
    Il y a d'un coté une faille du noyau linux portant sur l'execution de code mappé à l'adresse mémoire zero, c'est la faille.
    
    De l'autre, il y a un mécanisme de protection générique, mmap_min_addr qui permet en théorie d'empecher l'exploitation de la faille.
    
    Enfin il y a SELinux qui, du fait d'un mauvais design, permet de contourner le mécanisme de protection générique mmap_min_addr.
    
    Du point de vue de SELinux, c'est plus un problème de « defect by design » qu'à proprement parler une « faille ». Le fonctionnement utilisé est celui prévu (maladroitement) par les developpeurs.
    
    La simple façon de s'en rendre compte, c'est que sans la faille noyau, il n'y aurait rien à exploiter, SELinux ou pas...
    
    Romain
    - [^] # Re: A propos de la faille de sécurité..
      
      Posté par zebra3 le 11 septembre 2009 à 12:36. Évalué à -2.
      
      Du point de vue de SELinux, c'est plus un problème de « defect by design » qu'à proprement parler une « faille ». Le fonctionnement utilisé est celui prévu (maladroitement) par les developpeurs.
      
      J'avoue que qualifier le fonctionnement de SELinux de « maladroit » me laisse dubitatif, sachant que ce dernier a été conçu par la NSA, la plus grande concentration de mathématiciens au monde et dont le budget est supérieur à celui de la CIA.
      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
      - [^] # Re: A propos de la faille de sécurité..
        
        Posté par patrick_g (site web personnel) le 11 septembre 2009 à 12:51. Évalué à 4.
        
        Je pense que ce qui est qualifié de "maladroit" c'est la configuration construite par RedHat (la unconfined_t) et qui a une faille concernant le setting mmap_min_addr.
        Ce n'est pas SELinux en soi qui a une faille.
        
        [^] # Re: A propos de la faille de sécurité..
        
        Posté par Romain Be. le 12 septembre 2009 à 00:46. Évalué à 1.
        
        En fait, si j'ai bien compris, la directive SELinux de red hat autorise explicitement le mapping à l'adresse 0. C'est un premier problème.
        
        Ce qui est maladroit c'est qu'il y a conflit entre deux directives. D'un coté un directive hors SELinux interdit de mapper à l'adresse zero, de l'autre une directive SELinux l'autorise.
        
        Au final, en matière de sécurité, on voudrait toujours avoir comme combinaisons de plusieurs restrictions la restriction maximale. Ce n'est pas la cas ici, puisque SELinux permet alors d'affaiblir la sécurité du système en donnant la possibilité de contourner une autre directive de sécurité plus stricte.
      - [^] # Re: A propos de la faille de sécurité..
        
        Posté par briaeros007 le 11 septembre 2009 à 18:25. Évalué à 4.
        
        J'avoue que qualifier le fonctionnement de SELinux de « maladroit » me laisse dubitatif, sachant que ce dernier a été conçu par la NSA, la plus grande concentration de mathématiciens au monde et dont le budget est supérieur à celui de la CIA.
        Ils travaillent tous sur SELinux ?
        Amha selinux c'est encore moins q'un projet "auxiliaire" pour eux (et en main d'oeuvre, et en budget).
        
        [^] # Re: A propos de la faille de sécurité..
        
        Posté par Sytoka Modon (site web personnel) le 11 septembre 2009 à 21:48. Évalué à 10.
        
        Et puis, c'est pas parce qu'il y a beaucoup de mec très bon ensemble qu'ils ne peuvent pas faire de conneries !
        
        [^] # Re: A propos de la faille de sécurité..
        
        Posté par zebra3 le 12 septembre 2009 à 18:41. Évalué à 3.
        
        Quand bien même comme dit plus haut ça ne soit pas un projet prioritaire, Linux reste le seul système d'exploitation sur lequel elle se soit penchée assez sérieusement pour lui ajouter des modules de sécurité.
        
        Vu l'importance des systèmes d'informations de nos jours, elle n'a certainement pas dû mener ce projet en dilettante.
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: A propos de la faille de sécurité..
        
        Posté par briaeros007 le 12 septembre 2009 à 22:21. Évalué à 5.
        
        Linux reste le seul système d'exploitation sur lequel elle se soit penchée assez sérieusement pour lui ajouter des modules de sécurité.
        Non.
        Linux reste le seul système d'exploitation open source, sur lequel elle se soit penchée ET a distribué les modules implémenté.
        
        Bref, on sait qu'ils ont travaillé/travaille sur linux, on ne sait rien des autres.
        
        (par contre on sait que la nsa a déjà collaboré étroitement avec microsoft par ex).
      - [^] # Re: A propos de la faille de sécurité..
        
        Posté par Gniarf le 12 septembre 2009 à 14:45. Évalué à 5.
        
        > J'avoue que qualifier le fonctionnement de SELinux de « maladroit » me laisse dubitatif, sachant que ce dernier a été conçu par la NSA, la plus grande concentration de mathématiciens au monde et dont le budget est supérieur à celui de la CIA.
        
        tu veux qu'on parle du budget et des talents de Microsoft quand on constate Windows Vista ou Windows ME ?
        
        [^] # Re: A propos de la faille de sécurité..
        
        Posté par zebra3 le 12 septembre 2009 à 18:40. Évalué à 6.
        
        Disons que la différence entre Microsoft et la NSA, c'est que le premier a pour but de vendre ses produits, ce qui le conduit à faire des compromis.
        
        La NSA a pour contraintes un maximum de sécurité et de fiabilité, sans contrepartie de résultats commerciaux ni même de calendrier (en tout les cas, bien moins qu'une entreprise). Elle peut donc mettre les moyens sur ce qu'elle estime important.
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
      - [^] # Re: A propos de la faille de sécurité..
        
        Posté par neologix le 13 septembre 2009 à 11:52. Évalué à 2.
        
        J'avoue que qualifier le fonctionnement de SELinux de « maladroit » me laisse dubitatif, sachant que ce dernier a été conçu par la NSA, la plus grande concentration de mathématiciens au monde et dont le budget est supérieur à celui de la CIA.
        
        Le problème de SELinux, c'est justement qu'il faudrait bosser à la NSA pour arriver à pondre une configuration correcte. Pour le commun des mortels, c'est impossible à gérer.
        
        Ensuite, pour ce qui est du budget et de la concentration de génies à la CIA et à la NSA, il suffit de se renseigner sur les événements précédant 9/11 pour se rendre compte de leur incompétence...
# Systèmes de fichiers à la pelle

Posté par NickNolte le 11 septembre 2009 à 02:11. Évalué à 3.

Mais y en a pas un qui offre une possibilité de réduction de taille de FS propre et sûre.

Est-ce que c'est réalisable facilement avec EXT4?
- [^] # Re: Systèmes de fichiers à la pelle
  
  Posté par Sphax le 11 septembre 2009 à 11:54. Évalué à 3.
  
  J'ai redimensionné facilement mon /home il y a quelques temps avec resize2fs. Après, je ne sais pas ce que tu entends par "propre et sûre" mais je n'ai pas eu de soucis de mon côté.
- [^] # Re: Systèmes de fichiers à la pelle
  
  Posté par zebra3 le 11 septembre 2009 à 12:40. Évalué à 4.
  
  Bah, j'ai déjà réduit pas mal de volumes ext3, je n'ai jamais eu aucun problème, pour ext4 j'imagine que c'est pareil.
  
  Tu as eu des soucis ?
  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
  - [^] # Re: Systèmes de fichiers à la pelle
    
    Posté par Victor le 11 septembre 2009 à 13:12. Évalué à 2.
    
    Oui, il existe même des outils pour faire ça facilement comme gparted par exemple (qui propose même un livecd/usb qui marche très bien).
# Abandon des anciens drivers IDE ?

Posté par fred le 11 septembre 2009 à 15:32. Évalué à 2.

J'avais cru comprendre que les anciens drivers IDE (PATA) allaient être abandonnés à la faveur des nouveaux de la libata, par exemple le module ata_piix remplaçant piix, etc. : est-ce avéré ? Il me semble avoir également lu que ce module effectuait désormais ses inits en parallèle pour un boot plus rapide…
- [^] # Re: Abandon des anciens drivers IDE ?
  
  Posté par benoar le 17 septembre 2009 à 00:46. Évalué à 2.
  
  Peut-être quelques-uns, mais pas tous en tous cas car certains n'ont pas encore été portés (ou sont encore "en cours", je pense au macio de benh qui gère une grosse partie des Mac PPC). Ça ferait gueuler pas mal de monde.
# cooker

Posté par Maurice Rosenfelder (site web personnel) le 11 septembre 2009 à 17:45. Évalué à 2.

Je suis allé aux nouvelles en le voyant dans la liste des télechargements. C'était dejà le cas pour les diverses RC.

C'est pendant que j'attends ça que j'écris cet article :

Vous devriez relancer système pour kernel-desktop-2.6.31-1mnb
writing /var/lib/rpm/installed-through-deps.list

The following packages:
kernel-desktop-2.6.31-0.rc8.1mnb-1-1mnb2.i586
kernel-desktop-devel-2.6.31-0.rc8.1mnb-1-1mnb2.i586
kernel-desktop-devel-2.6.31-0.rc9.1mnb-1-1mnb2.i586
libltdl-devel-2.2.6-6mdv2009.1.i586
libmediadevicelib1-2.1.1-3mdv2010.0.i586
libtool-2.2.6-6mdv2009.1.i586
libtool-base-2.2.6-6mdv2009.1.i586
are now orphaned, if you wish to remove them, you can use "urpme --auto-orphans"

Il on une ligne directe avec linus, chez mandriva ?
# Support des cartes son Creative X-Fi

Posté par Laurent Léonard (site web personnel) le 12 septembre 2009 à 15:48. Évalué à 3.

À noter aussi que le travail de Takashi Iwai sur la prise en charge des cartes son à base de Creative X-Fi (composant utilisé dans beaucoup de cartes haut de gamme) a été intégré dans cette version.
- [^] # Re: Support des cartes son Creative X-Fi
  
  Posté par turanga leela le 12 septembre 2009 à 16:58. Évalué à 4.
  
  Alors ça c'est une bonne nouvelle, mon frère n'a plus d'excuse pour ne pas passer à linux.
  A quand la prise en charge native des lecteurs d'empreintes digitales??
# Merci...

Posté par Hugues (site web personnel) le 12 septembre 2009 à 16:17. Évalué à 2.

C'est tellement bien écrit qu'on dirait du patrick_g ;-)
# Merci patrick :-)

Posté par 2PetitsVerres le 12 septembre 2009 à 17:40. Évalué à 3.

Comme toujours, intéressant à lire, et en plus en suivant les liens j'ai trouvé lcov [http://ltp.sourceforge.net/coverage/lcov.php] dont je vais pouvoir me servir au boulot (ce sera plus sympa que grep -C 5 ^##### pour voir où la campagne de simulation ne sera pas passée \o/
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
- [^] # Re: Merci patrick :-)
  
  Posté par zebra3 le 12 septembre 2009 à 18:42. Évalué à 3.
  
  Merci Patrick !
  
  (sur un refrain bien connu, pas du tout à la mode bien qu'étant pourtant d'actualité...)
  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# 1er commentaire sur +linux

Posté par super67momo le 13 septembre 2009 à 21:05. Évalué à -10.

bonsoir! je viens de lire, l'article sur le prochain noyau linux. g mal à la tete, mais 1 texte trés riche .ma 1ere questionest: pourquoi, le noyau n'est-il pas ecrit en C++.la lourdeur du C est legendaire.la 2nde question est: ce noyau sera-t-il celui, du prochain ubuntu.la3e est : pourquoi? il y a si peu de developpeurs pour linux, comparer à windows.cela à terme, ne bridera-t-il pas son developpement? enfin quand-est- il de la gestion des coeurs multiples et des nouvelles interfaces creees par intel et amd. je voudrais m'evader de la prison windows xp 32. ci.
- [^] # Re: 1er commentaire sur +linux
  
  Posté par windu.2b le 13 septembre 2009 à 21:14. Évalué à 2.
  
  "enfin quand-est- il de la gestion des coeurs multiples et des nouvelles interfaces creees par intel et amd"
  JAMAIS !!!
  Sinon, si tu veux écrire correctement, tu as le droit de demander : "qu'en est-il [...] ?"
  
  PS : ce n'est pas la seule faute, mais c'est la plus agressive...
- [^] # Re: 1er commentaire sur +linux
  
  Posté par Pinaraf le 13 septembre 2009 à 21:34. Évalué à 4.
  
  C'est une blague ??
- [^] # Re: 1er commentaire sur +linux
  
  Posté par Meku (site web personnel) le 14 septembre 2009 à 00:44. Évalué à 6.
  
  Tant de préjugés stéréotypés... Moi aussi j'ai un peu mal à la tête après avoir décodé ton message mal orthographié et très mal ponctué.
  
  1) C'est quoi la lourdeur du C ? (en particulier, pour écrire un noyau).
  2) Oui, Ubuntu Karmic Kokakola embarquera le 2.6.31.
  3) T'as des chiffres ? Un millier de développeurs en moyenne sur le noyau, c'est pas beaucoup ? Chez Microsoft ils ont mis 10 000 personnes peut-être ?
  4) Quelles interfaces en particulier ? Linux gère les systèmes multi-processeurs. Après les API, c'est peut-être pas au noyau de les implémenter mais à une couche supérieure... Ta question manque de précision.
  
  Qu'est ce qui t'empêche de quitter Windows XP ? Et quel est le lien plus précisément entre tes questions et le fait de t'évader de Windows ? Tu compte coder sur le noyau mais t'aimes pas le C ? Tu possèdes déjà une machine supportant l'USB 3 et des périphériques USB 3 que t'as besoin du 2.6.31 dans la prochaine Ubuntu ? (enfin non, ça sera pas ce point qui te retiendra sous Windows). Explique-nous. C'est très mystérieux tout ça.
  
  J'ai une dernière question. Il y a un passage que je n'ai pas réussi à décoder dans le titre de ton message: « 1er commentaire sur +linux ». Que signifie le « +linux » ? (c'est le « + » qui m'intrigue).
  - [^] # Re: 1er commentaire sur +linux
    
    Posté par Nicolas Boulay (site web personnel) le 14 septembre 2009 à 12:09. Évalué à 6.
    
    "Un millier de développeurs en moyenne sur le noyau, "
    
    Un millier en moyenne _par release_, mais ce n'est pas forcément les même ! Ce qui fait encore plus de personne impliqués.
    "La première sécurité est la liberté"
    - [^] # Re: 1er commentaire sur +linux
      
      Posté par NeoX le 16 septembre 2009 à 01:38. Évalué à 8.
      
      je dirais meme plus
      
      le millier de developpeur c'est UNIQUEMENT pour noyau
      
      apres il y a le millier de developpeur pour KDE/GNOME, la centaine de developpeur pour certains logiciels, le developpeur unique pour d'autres :p
- [^] # Re: 1er commentaire sur +linux
  
  Posté par Spyhawk le 14 septembre 2009 à 03:36. Évalué à 10.
  
  Ah ! Ubuntu Kikolol Karmic user inside :]
# Des pilotes audio en espace utilisateur ?

Posté par psychoslave__ (site web personnel) le 14 septembre 2009 à 15:35. Évalué à 2.

#Grâce à Tejun Heo de la société Novell, les périphériques en mode caractère peuvent maintenant avoir des pilotes en espace utilisateur. Ceci est possible grâce à CUSE (Character devices in user space) qui fonctionne en tant que surcouche à FUSE (File systems in user space). Cela permettra d'enlever du noyau les vieux pilotes en mode caractère et de proposer plus proprement une compatibilité avec les vilaines applications qui continuent d'utiliser OSS au lieu de passer à ALSA.

Mais un pilote son en espace utilisateur, c'est une mauvaise idée si on fait du temps réel, il y aura de grosses latences, non ? :\
- [^] # Re: Des pilotes audio en espace utilisateur ?
  
  Posté par patrick_g (site web personnel) le 14 septembre 2009 à 16:00. Évalué à 2.
  
  D'un autre coté c'est juste pour supporter les applications legacy qui n'ont pas fait la transition vers ALSA.
  - [^] # Re: Des pilotes audio en espace utilisateur ?
    
    Posté par psychoslave__ (site web personnel) le 14 septembre 2009 à 19:45. Évalué à 5.
    
    Ou les applications qui essaient d'être portable avec OSS qui lui fonctionne aussi sous *BSD par exemple ? :)
    - [^] # Re: Des pilotes audio en espace utilisateur ?
      
      Posté par Pierre Bourdon le 18 septembre 2009 à 22:11. Évalué à 1.
      
      Et qui fonctionne mieux qu'ALSA sous Linux aussi :) .
      
      (oui, on est vendredi, toussa)
# gestion des coeurs multiples.

Posté par super67momo le 16 septembre 2009 à 17:55. Évalué à -10.

bonsoir ! J'ai desinstallé du disque dur, ma distribution de linux( mandriva et ubuntu).J 'ai trouvé que la gestion de mon athlon 64 x2, etait tres moyenne. ma question est , y'a-t-il 1 site sur le sujet en francais.Je n'ai jamais reussi, a installé le pilote version linux de ma carte graphique ati radeon hd. J 'ai du utilisé celui de ubuntu, mais il manquait beaucoup de parametres de reglage.l'importation de video de ma partiton windows , etait tres mauvaise.L'autre question est quand est-il de l'interoperabilite des 2 systemes. merci!
- [^] # Re: gestion des coeurs multiples.
  
  Posté par benoar le 17 septembre 2009 à 00:51. Évalué à 3.
  
  Pour Ubuntu : http://ubuntu-fr.org/
  Sinon, essaye d'apprendre (c'est valable pour la syntaxe et l'orthographe aussi) avant de porter certains jugements, ça t'évitera de finir dans les abîmes du moinssage.
- [^] # Re: gestion des coeurs multiples.
  
  Posté par Meku (site web personnel) le 17 septembre 2009 à 01:41. Évalué à 4.
  
  - En quoi tu as trouvé la gestion de ton athlon 64 x2 très moyenne ?
  - Ça veut dire quoi que l'importation de vidéo(s ?) de ta partition windows était très mauvaise ?
  - Peux-tu préciser ta dernière question sur l'interopérabilité ? car c'est super vaste...
  
  As-tu lu les remarques que l'on t'a adressé plus haut ? Je ne constate pas de progrès dans la rédaction et tes questions et affirmations sont toujours très superficielles : on a du mal à comprendre ce qu'il s'est mal passé, ou ce que tu voudrais savoir exactement.
  - [^] # Re: gestion des coeurs multiples.
    
    Posté par Nicolas Boulay (site web personnel) le 21 septembre 2009 à 12:54. Évalué à 3.
    
    C'est beau de résister au plonkage de newbies. C'est vrai aussi que l'on est tous passé par là.
    "La première sécurité est la liberté"
    - [^] # Re: gestion des coeurs multiples.
      
      Posté par grid le 21 septembre 2009 à 23:56. Évalué à 5.
      
      hum non. on peut être jeune sans être abruti

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.