mercredi 28 juillet

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Logiciel

[70] Firefox 3.6 en breton
[14] Nouvelle version de Self Service Password (projet LDAP Tool Box)
[2] Sortie de Maarch Entreprise 1.0 et actualité des autres projets Maarch
[32] Sortie de Gnumeric 1.10
[56] Cairo-Dock 2.1.3-3 est sorti
[18] Un p'tit Cappuccino ?
[100] OpenOffice.org 3.2 est disponible
[18] OpenDNSSEC v 1.0.0 (stable)
[6] Sortie de Luciole 0.8.2 !
[38] KDE SC 4.4 est sorti

Liens connexes

Les nouveautés du noyau 2.6.33 (2187 clics)
Le bilan des ajouts partie 1 (348 clics)
Le bilan des ajouts partie 2 (244 clics)
Les articles de H-Online (194 clics)
Les prévisions pour l'avenir de Linux (798 clics)

Dépêche modérée par

baud123

Dépêche éditée par

Logiciel : Nouvelle version 2.6.33 du noyau Linux

Posté par patrick_g (page perso, ). Modéré le 25 février 2010.

120

La sortie de la version stable 2.6.33 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 (qui est sous licence libre CC BY-SA).

PS : Je tiens à remercier tout particulièrement Frédéric Weisbecker, premier contributeur en terme de patchs sur le noyau 2.6.33, qui a accepté de donner un peu de son temps pour répondre à mes questions. Vous trouverez un entretien en fin de dépêche.

PS 2 : Merci aussi aux relecteurs/correcteurs de cette (longue) dépêche.

Les nouveautés du noyau 2.6.33 (2187 clics)
Le bilan des ajouts partie 1 (348 clics)
Le bilan des ajouts partie 2 (244 clics)
Les articles de H-Online (194 clics)
Les prévisions pour l'avenir de Linux (798 clics)

> Lire la suite (213 commentaires, moyenne: 3,2). [dépêche : 100085 caractères]

Le sommaire...

La phase de test
- RC-1
- RC-3
- RC-4
- RC-5
- RC-6
- RC-7
- RC-8
Les nouveautés
En bref
Le bilan en chiffres
Questions/Réponses avec Frédéric Weisbecker
Pour la suite

La phase de test (↑)

RC-1

La version RC-1 a été annoncée par Linus le 17 décembre dernier :

« Bon la période de merge est fermée et la RC-1 est maintenant disponible.
En parlant de période de merge, il y a eu un _paquet_ de branches qui n'ont envoyé leur demande de merge que très tard. Je suis habitué à avoir un dernier jour de la période vraiment très chargé, mais cette fois, ça a duré deux jours. Bien pire que d'habitude.
La période d'ouverture de deux semaines n'est pas supposée être "une demande de merge après un silence de treize jours". En fait, je pense que la prochaine fois, je vais réduire la phase à onze ou douze jours. Ainsi, les gens qui auront essayé de jouer au plus fin en envoyant leur demande au dernier moment auront une sale surprise. Ils seront obligés d'attendre le 2.6.35.
En dehors de ce grognement cela a été une phase assez classique, je pense. Les changements se répartissent en :
1/3 dans la branche staging

1/3 "le reste des pilotes"

1/3 "tout le reste"
avec environ la moitié de ce "tout le reste" final qui concerne les diverses architectures et l'autre moitié les autres trucs (micrologiciels, systèmes de fichiers, réseau, etc.).
Les ajouts notables ? Personnellement, j'aime la façon dont j'ai enfin réussi à merger le code de Nouveau par exemple.
Merci de tester à fond cette RC-1, comme ça nous commencerons à avoir une idée au sujet des inévitables régressions ».

RC-2

C'est pile le jour de Noël que Linus a mis a disposition la version RC-2 :

« Joyeux Noël… ou quoi que vous célébriez aujourd'hui/demain.
Et, si vous ne célébrez rien du tout et que vous crevez d'ennui assis dans votre cave sombre, alors vous pouvez au moins essayer la dernière RC. C'est toujours mieux que de se morfondre sans rien faire.
Et si vous fêtez un truc, mais que vous avez une indigestion de jambon (ou que vous en avez marre de perdre tous vos vêtements dans des parties de strip et d'être la risée de tout le monde) alors faites une pause, compilez un noyau et essayez-le.
Parce que, si votre pantalon ne vous va peut-être plus pendant un mois, le nouveau noyau, lui, sera peut-être bien adapté à votre ordinateur.

J'aurais apprécié une RC-2 plus petite mais j'ai vu pire, donc je ne vais pas me plaindre.
Et maintenant je suis off, car je vais aller peler des patates. Et les manger ensuite.
Amusez-vous. ».

RC-3

Après cette interruption culinaire et digestive, il a fallu attendre le 5 janvier pour la RC-3 :

« Tout a été tranquille du fait des vacances et la RC-3 est raisonnablement petite en dépit de son retard de quelques jours. La plupart des changements sont triviaux, mais il y a eu des problèmes sur ext4 et ReiserFS dans la RC-2, avec un peu de chance tout est corrigé maintenant.
Le changement qui est peut-être le plus notable n'est pas une modification de code, mais le fait de recommander maintenant officiellement la "nouvelle" pile firewire par rapport à l'ancienne.
Espérons que l'une des raisons pour expliquer ce calme est que tout est réellement stable. Essayez-le ! ».

RC-4

Une semaine plus tard, c'est la version RC-4 qui a été annoncée :

« Hmm. Une version bizarre. Il y a environ 40% des patchs qui concernent DRM (surtout nouveau et radeon, qui sont en staging, donc c'est un peu moins effrayant qu'il ne semble. Mais il y a aussi des trucs sur i915). C'est assez inhabituel pour autant que je sache. ».

RC-5

La version RC-5 a été annoncée le 21 janvier :

« Je ne pense pas qu'il y ait quoi que ce soit de renversant là-dedans, mais la modification du pilote KMS i915 est assez importante. Notamment, si vous avez un port eDP ("embedded DisplayPort" - Je pense que c'est une fonction que vous retrouvez dans un nouvel iMac), eh bien maintenant il fonctionne. Mais aussi, si vous aviez des problèmes de tremblement d'image du fait de la réduction de fréquence LVDS (ça économise du courant, mais c'est maintenant désactivé par défaut jusqu'à ce que ce problème soit résolu).
À part ça, c'est un bon paquet de petites corrections. ».

RC-6

C'est le 29 janvier que Linus a annoncé la disponibilité de la version de test RC-6 :

« Hmm. À peu près 50% des patchs sont sur les diverses architectures et 40% sur les pilotes. Le reste concerne principalement les systèmes de fichiers et le réseau.
Nous arrivons dans cette étape du cycle ou tout devrait plus ou moins "juste marcher" et où les gens qui découvrent des régressions devraient commencer à beugler très fort pour que ce soit corrigé ».

RC-7

Lors de la mise à disposition de la version RC-7 le 6 février, Linus a indiqué qu'il restait encore du travail à faire :

« Je dois admettre que j'aurais souhaité avoir moins de régressions à cette étape du processus. J'incite les développeurs à aller regarder sur la liste juste pour voir s'ils reconnaissent des régressions qui leur semblent familières. Prendre quelques minutes pour regarder cette liste et se dire "Hmm, peut-être que je connais celle-là" est une bonne idée.
Mais nous avons certainement corrigé un certain nombre de choses, et ça fait une semaine donc voilà la RC-7. J'aimerais pouvoir dire que c'est la dernière RC, mais j'en doute fortement et il y en aura presque certainement au moins une autre ».

RC-8

Enfin, le 13 février, Linus a annoncé la dernière version candidate avant la sortie du noyau officiel :
« Je pense que ce sera la dernière RC de ce cycle, donc s'il vous plaît testez-là bien. Un certain nombre de régressions devraient être corrigées et - même si la liste des régressions ne me rend pas _content_ - au moins nous n'avons pas ces sales trucs qui m'inquiétaient avant la RC-7 ».

Les nouveautés (↑)

Stockage distribué DRBD

Le système de stockage distribué DRBD (Distributed Replicated Block Device) fait maintenant partie du noyau Linux depuis cette version 2.6.33.
Écrit à l'origine par Philipp Reisner dans le cadre de son master d'informatique de l'Université technique de Vienne ce système de stockage est développé par la société LINBIT qu'il a fondée en 2001.
DRBD peut être compris comme un équivalent réseau du système de réplication RAID 1 (disques durs en miroir) et cela permet de construire des serveurs répartis de haute disponibilité avec des systèmes de fichiers distribués de type GFS ou OCFS2.
Les périphériques de stockages utilisent en interne des blocs de données. Ce sont ces blocs de bas niveau qui sont répliqués par DRBD sur plusieurs machines de façon automatique. Cette réplication peut se faire de façon synchrone (un bloc est considéré comme répliqué uniquement quand il a été écrit en local, envoyé vers le disque du nœud distant et que ce nœud distant a confirmé qu'il était correctement écrit) ou bien de façon asynchrone (un bloc est considéré comme répliqué quand il a été écrit en local et qu'il a juste été envoyé vers le nœud distant, sans confirmation en retour). On voit bien que la méthode synchrone est plus robuste mais qu'elle dépend de la vitesse du réseau. La méthode asynchrone peut impliquer des pertes de données (sans perte de cohérence toutefois) mais elle est utile pour des nœuds séparés par de longues distances avec une latence importante. Pour avoir une idée des performances ce test indique que la version synchrone (c'est le "protocole C" en langage DRBD) tombe à 163,8 Mo/s par rapport aux 239,8 Mo/s de la version asynchrone.

Actuellement DRBD ne supporte que deux nœuds mais cette limitation sera supprimée par la suite. Il y a plusieurs avantages de cette technique de réplication au niveau du bloc de données par rapport à une classique grappe de serveurs (cluster).
Tout d'abord les opérations de lecture de données, qui sont prépondérantes, s'effectuent purement en local puisque les données sont répliquées sur tous les nœuds. Plus besoin de passer par le goulet d'étranglement que constitue le réseau.
Ensuite et surtout la réplication de données est naturellement plus robuste que le simple partage qui est souvent utilisé dans les grappes de serveurs. La perte du réseau entre deux nœuds ne risque pas de provoquer de situation de conflit ou d'accaparement des ressources par les nœuds qui croient chacun que l'autre n'est plus actif.
Pour ceux qui désirent se plonger dans les entrailles techniques du système un fichier PDF explicatif est disponible ainsi qu'un guide d'utilisation détaillé.

Le patch externe implémentant DRBD a été soumis initialement sur la liste de diffusion du noyau en juillet 2007 mais il a été en butte à de nombreuses critiques et ses développeurs ont du le modifier profondément avant que Jens Axboe, mainteneur de la couche bloc, n'accepte finalement le patch.
Comme plusieurs distributions incluaient déjà ce patch dans leur noyau, cette entrée dans la branche principale est bienvenue et va permettre de réduire leur charge de maintenance des patchs externes.
Les utilisateurs de Linux pourront eux profiter de ce système fort utile pour réduire le coût des systèmes de haute disponibilité. Avec DRBD il devient possible de se passer des coûteuses machines spécialisées SAN et d'utiliser de simples serveurs Linux reliés entre eux par l'intermédiaire de ce système de stockage distribué.

Transaction TCP par cookie

La pile réseau du noyau 2.6.33 accueille les patchs initiaux du mécanisme de "transaction TCP par cookie" qui va permettre, quand l'implémentation sera complète, de résoudre deux problèmes réseau d'un seul coup.

En premier lieu la technique de "transaction TCP par cookie" (TCPCT pour "TCP cookie transactions protocol" en anglais) est une amélioration du mécanisme classique SYN cookies qui est en place depuis plusieurs années et qui permet d'éviter les attaques par flots de SYN (SYN flood attacks).
En gros l'attaque se déroule comme ceci : Le client envoie un message SYN au serveur (un message de SYNchronisation pour ouvrir une connexion) et le serveur répond par un SYN-ACK (la SYNchronisation plus l'accusé de réception ACKnowledgement). L'ennui c'est qu'après ça le client malicieux se garde bien de finir la troisième phase de la poignée de main en trois temps (Three-way handshake) et que le serveur reste le bec dans l'eau avec sa connexion ouverte jusqu'à la fin de sa durée d'activité (timeout). Si le client envoie un grand nombre de demandes de connexions qui restent incomplètes alors le serveur finit par être la victime d'un déni de service puisque toutes ses connexions sont ouvertes et attendent des réponses qui ne viendront jamais.
Daniel J. Bernstein a inventé le mécanisme "SYN cookies" pour contrer ce genre d'attaques. En résumé, après le SYN initial du client le serveur va lui renvoyer un SYN-ACK modifié et contenant un numéro de séquence haché par une clé secrète, un "cookie", et il va tout de suite fermer la connexion. Le serveur économise ainsi ses ressources et n'est plus susceptible d'être victime du déni de service. Quand le client répond par le ACK final, la troisième phase de la poignée de main, le serveur est capable de reconnaitre le client car il se base sur le numéro de séquence.
SYN cookies est une solution "bricolée" (un hack) mais ça fonctionne assez bien pour bloquer les attaques par flots de SYN. L'inconvénient de cette technique est qu'il devient impossible d'utiliser certaines options bien utiles du protocole TCP. De plus la sécurité du cookie est relativement faible et des techniques astucieuses permettent de leurrer le serveur.
La solution qui est apportée par la nouvelle technique de "transaction TCP par cookie" est simple. Le client va envoyer lui aussi, et ce dès l'étape initiale du SYN, un cookie signé cryptographiquement en direction du serveur. Le serveur se sert de ce cookie-client pour générer un cookie-serveur et le renvoyer au client avec son SYN-ACK. Il coupe ensuite la connexion et n'attends pas de réponse en dépensant des ressources pour rien. Le client renvoie alors le ACK final avec le cookie-serveur qui contient toutes les informations permettant au serveur de connecter le client comme si une poignée de main en trois temps normale avait eu lieu.
Cette solution élégante est bien plus sécurisée que SYN cookies et elle reste compatible avec les options du protocole TCP.

Le second avantage de cette nouvelle fonction de "transaction TCP par cookie" est qu'elle permet d'améliorer la mise en œuvre de DNSSEC (Domain Name System Security Extensions). Ce mécanisme de sécurisation du protocole DNS (qui fait la correspondance entre une adresse IP et un nom de domaine) a été conçu pour protéger de bout en bout les données échangées par DNS. L'ennui c'est que DNSSEC, outre sa grande complexité, impose de renvoyer des gros paquets. Ces paquets sont trop gros pour le protocole de transmission UDP qui est normalement utilisé par DNS. La taille d'un paquet UDP est de 512 octets alors qu'en moyenne DNSSEC exige 1749 octets. On peut bien entendu fragmenter les échanges en multiples paquets UDP mais cela pose de nombreux problèmes avec les pare-feu et les NAT. On peut alors basculer vers la solution de secours qui consiste à utiliser TCP à la place d'UDP… mais la charge de la machine augmente énormément puisqu'on répète sous TCP une requête qui n'a pas abouti sous UDP et qui a généré un timeout.
Comment faire ? La réponse est simple puisque le mécanisme "transaction TCP par cookie" permet d'encoder des informations dans les cookies-client et cookies-serveur ! Le mécanisme de "transaction TCP par cookie" se sert de cet espace pour permettre au client d'envoyer une requête DNS dans la première partie de la poignée de main et pour permettre au serveur de renvoyer la réponse. Plus besoin de fragmenter des paquets UDP ou d'attendre les interminables timeouts de bascule vers TCP puisque tout se fait directement dans TCP par l'intermédiaire des cookies.

L'article "improving TCP security with robust cookies" (au format PDF) permet d'approfondir le sujet et de mieux comprendre les avantages et les inconvénients de cette solution.
Et oui comme dans toute solution technique il y a des inconvénients. Le principal problème est que SYN cookies (la solution de Bernstein) ne nécessitait qu'une adaptation côté serveur alors que TCPCT impose aussi une mise à jour de tous les clients. Si on ajoute le temps que va prendre l'implémentation complète du protocole dans Linux (le 2.6.33 n'accueille que les patchs initiaux), le temps de déploiement dans toutes les distributions de ces noyaux complètement compatibles et enfin le temps de mise à jour des clients eux-mêmes, on peut penser que le déploiement généralisé est encore assez loin.

Compactage mémoire ramzswap

Une fonction de compactage de la mémoire nommée ramzswap (anciennement compcache) est entrée dans la partie -staging du noyau 2.6.33.
L'idée derrière compcache/ramzswap est de permettre aux LiveCD ou aux petites configurations (netbooks, vieux ordinateurs, clients légers, systèmes embarqués) d'avoir une capacité mémoire artificiellement augmentée grâce à la compression d'une partie des pages mémoires.
Pour cela un périphérique virtuel en mode bloc est créé à l'amorçage et ce périphérique va jouer le rôle d'une zone de swap dans laquelle les pages mémoire non utilisées depuis un certain temps vont être compressées et stockées.
Techniquement ramzswap utilise l'algorithme de compression LZO (par l'intermédiaire des modules noyaux lzo_compress et lzo_decompress) ainsi qu'un allocateur mémoire spécifique (xvmalloc). Cet allocateur est nécessaire car les développeurs ont découvert que ceux qui sont déjà disponibles dans le noyau Linux ne remplissaient pas leur cahier des charges très spécial. SLOB a une complexité linéaire, soit O(n), alors que xvmalloc n'a qu'une complexité constante en O(1). SLUB de son côté a une tendance à la fragmentation mémoire que xvmalloc permet d'éviter.

Pour utiliser cette fonction de compression de la RAM il suffit (outre les modprobe de chargement des modules) d'une initialisation avec un rzscontrol /dev/ramzswap0 --init suivie d'une activation avec swapon /dev/ramzswap0. Par défaut 15% de la mémoire sera utilisée pour stocker les pages mémoire compressées mais on peut changer ça avec l'option memlimit_kb.
Pour des raisons de performances et de montée en charge il est préconisé de créer autant de ramswap qu'il y a de cœurs de calcul sur la machine.
Ainsi si je veux un ramzswap de 256 Mo sur mon laptop bi-cœur je vais faire dans l'ordre :
modprobe ramzswap num_devices=2
puis
rzscontrol /dev/ramzswap0 --init --disksize_kb=131072
rzscontrol /dev/ramzswap1 --init --disksize_kb=131072
et enfin
swapon /dev/ramzswap0
swapon /dev/ramzswap1

Bien entendu toutes ces actions seront la plupart du temps exécutés par des scripts sur nos distributions/LiveCD et l'utilisateur de ramzswap n'aura vraisemblablement pas à se plonger souvent dans la page du manuel.

D'après les test de performances la fonction ramzswap est très efficace et elle permet vraiment d'être "à l'aise" dans des tailles mémoires non démesurées. Par exemple page dédiée du site de compcache donne les résultats de plusieurs expérimentations et le niveau de performance auquel on peut s'attendre lors de l'utilisation (L'expérience a montré que le taux moyen de compression était de 4 pour 1). Un client léger sous LTSP et ayant peu de mémoire peut ainsi utiliser kpdf pour ouvrir simultanément 11 fichiers PDF au lieu de 2 et peut utiliser Firefox pour ouvrir 15 pages webs au lieu de 6.

L'implémentation de ramzswap qui se trouve dans le noyau 2.6.33 est considérée pour l'instant comme préliminaire. Tout d'abord elle se trouve dans la partie -staging qui accueille le code non finalisé et surtout les développeurs projettent d'ajouter plusieurs fonctions avant de considérer que l'outil est vraiment complet. On peut donc à brève échéance s'attendre à voir apparaître un meilleur algorithme de défragmentation de la mémoire, une compression des pages de cache et une possibilité de redimensionnement adaptatif du swap de la mémoire.

Contrôleur IO-Block

Le noyau 2.6.33 accueille dans cette version un contrôleur des entrées/sorties en mode bloc.
Depuis un certain temps plusieurs groupes concurrents avaient commencé à travailler sur ce contrôleur dont le rôle est de faire un arbitrage entre les divers groupes de processus pour accéder aux précieuses ressources d'entrées/sorties. Grâce à ce contrôleur plus de risque qu'un groupe de processus ne monopolise le disque dur et n'affame ses petits camarades.
L'ennui c'est que les équipes de développeurs concurrents n'arrivaient pas à se mettre d'accord sur l'architecture globale qu'il fallait utiliser dans Linux. Comme l'explique très bien cet article LWN, il y avait trois concurrents pour entrer dans la branche principale : dm-ioband, io-throttle et io-controller.
Le premier, comme son nom le laisse supposer, s'appuie sur le mécanisme du device mapper (une couche d'indirection entre les périphériques blocs qui permet par exemple de faire du RAID logiciel ou du chiffrement de disques). Le second est un mécanisme qui s'implante à plus haut niveau que le device mapper mais qui est aussi plus invasif. Enfin le dernier candidat, io-controller, a choisi de s'interfacer directement dans l'ordonnanceur des entrées/sorties.
Après plusieurs mois de chamailleries sans issue entre les trois groupes il fallait bien désigner un vainqueur… mais comment faire ?
Andrew Morton a dit avec humour qu'il songeait à enfermer les développeurs de ces trois solutions dans une chambre verrouillée et à revenir 15 minutes plus tard pour voir qui est le gagnant.
C'est une solution moins coercitive qui a finalement été choisie puisqu'à l'issue du Linux Storage and Filesystem Workshop d'avril dernier les divers développeurs sont enfin tombés d'accord sur une stratégie de couplage avec l'ordonnanceur des entrées/sorties (io-controller remporte donc la mise) et lors du dernier mini-sommet d'octobre à Tokyo une stratégie globale en deux temps a été décidée.
Comme l'écrit Vivek Goyal :
« Le contrôle des entrées/sorties est un problème complexe et si nous essayons de tout résoudre d'un seul coup en un patch cela devient ingérable et rien n'est accepté dans le noyau. Donc lors du dernier mini-sommet nous nous sommes mis d'accord pour y aller par étape et une fois que le premier bout de code sera dans le noyau et bien stabilisé nous nous occuperons des étapes suivantes »

La première étape, celle qui concerne le noyau 2.6.33, voit donc l'inclusion d'un mécanisme de contrôle des entrées/sorties sur les groupes de processus à l'intérieur même de CFQ (l'ordonnanceur I/O par défaut de Linux). Ce nouveau mécanisme utilise bien entendu l'infrastructure cgroup qui a été introduite dans le noyau 2.6.24. Le nouveau cgroup se nomme "blkio" et il permet d'attribuer un poids au différents groupe de processus (avec une valeur comprise entre 100 et 1000).
La documentation indique comment se servir facilement de cette fonction.
On commence par créer deux groupes : mkdir -p /cgroup/test1/ /cgroup/test2

Et ensuite on fixe les poids respectifs :
echo 1000 > /cgroup/test1/blkio.weight
echo 500 > /cgroup/test2/blkio.weight

Le groupe test1 aura alors deux fois plus de ressources d'entrées/sorties que le groupe test2.

La seconde étape, concernant le contrôleur des entrées/sorties en mode bloc, sera implémentée dans les versions suivantes du noyau Linux. Afin de prendre des décisions d'allocation ayant une visibilité complète de la hiérarchie de stockage (Topology-aware scheduling) il est nécessaire d'inclure des composants à un plus haut niveau que celui de l'ordonnanceur CFS.
De même, les entrées/sorties asynchrones (buffered writes) ne sont pas gérées par le mécanisme actuel du noyau 2.6.33 et les développeurs s'en occuperont par la suite:
« Les entrées/sorties asynchrones c'est un gros bordel et cela réclame des changements dans plein d'endroits pour résoudre le problème. Comme le patch devient trop gros nous ne supportons que le contrôle des I/O synchrones pour le moment ».

Même si la solution de contrôle n'est pas encore complète et s'il reste du travail à faire, on peut constater que le noyau Linux avance dans la bonne direction. Les sommets divers qui sont organisés chaque année permettent vraiment aux développeurs de se parler et d'élaborer des compromis afin de développer des solutions techniques aux problèmes. Quant aux administrateurs, ils ont maintenant la possibilité de gérer finement les allocations de ressources entrées/sorties entre les différents groupes de processus.

Les pilotes Android retirés du noyau

Comme évoqué dans ce journal les pilotes Android ont été retirés par Greg Kroah-Hartman de la branche -staging du noyau 2.6.33. De nombreux commentaires intéressants à ce sujet peuvent être lus sur cet article du site Linux Weekly News. On a ainsi Chris DiBona, Engineering Manager Open Source à Google, qui affirme: « la réalité c'est que la branche principale ne veut pas notre code donc un fork est la réponse normale à cet état de fait ». Greg KH a immédiatement répliqué : « Ce n'est pas vrai. Nous ne voulons pas du code tel qu'il est mais c'est juste parce qu'il nécessite un gros travail. Ce n'est pas différent pour toutes les autres contributions au noyau ».

La discussion a été quelque peu acrimonieuse mais elle a également permis de lire plusieurs avis techniques. Apparemment c'est l'ajout de "wakelock" qui est apparu aux yeux de beaucoup de kernel hackers comme le point le plus problématique du code d'Android.
Wakelock est une fonction spécifique du noyau utilisé dans Android et qui permet d'empêcher le système d'entrer en phase économie d'énergie. Cela semble contre-intuitif de procéder ainsi mais la philosophie des ingénieurs de Google est que par défaut le système devrait toujours être dans cet état d'économie d'énergie. Si une application a besoin d'utiliser des cycles du processeur alors elle doit poser explicitement un verrou wakelock interdisant la mise en veille pour que le travail soit effectué. Sinon le système restera endormi par défaut.
En envoyant la commande WAKE_LOCK_SUSPEND le système ne pourra plus entrer en veille tandis que WAKE_LOCK_IDLE empêche le processeur d'entrer dans un mode à faible consommation. Tout ce mécanisme interne au noyau patché d'Android est accessible aux applications qui peuvent placer leurs verrous et les enlever par l'intermédiaire de /sys/power/wake_lock et /sys/power/wake_unlock.
Les développeurs du noyau Linux considèrent cependant que wakelock est un très vilain hack pour plusieurs raisons. Tout d'abord ce mécanisme est en grande partie redondant avec l'API pm_qos (Power Management Quality of Service) qui existe déjà dans le noyau. Si Android a besoin de choses très spécifiques alors le travail aurait du consister en l'ajout de fonctions à pm_qos et pas au développement d'une solution différente.
Autre problème : La gestion de l'énergie traditionnelle sous Linux qui se base sur des écritures de commandes dans /sys/power/state est désactivée par le patch wakelock d'Android car la compatibilité n'est pas prévue.
Les développeurs de Linux relèvent également que le code de wakelock est inutilement compliqué avec plusieurs possibilités différentes alors qu'en réalité tout cela pourrait en définitive se ramener à un simple indicateur pour empêcher la mise en veille.
Enfin si une application utilisateur se crashe au mauvais moment alors qu'elle détient un wakelock... dommage pour vous mais le système ne passera plus en veille !

Il faudra donc que Google réponde à toutes ces critiques techniques et arrive à convaincre les développeurs de la pertinence de sa solution si le géant américain désire vraiment intégrer son code dans la branche principale. Selon Chris DiBona il faut que les développeurs de Linux acceptent le code tel qu'il est car les besoins d'un système pour smartphone sont très différents des autres et nécessitent des solutions particulières : « Android n'est pas la même chose qu'un serveur relié à Internet et penser que Linux sur un mobile est la même chose que Linux sur un serveur explique pourquoi, avant qu'Android n'arrive, Linux sur les mobiles ne rencontrait presque aucun succès ».

Il lui a été immédiatement répondu que, même si le monde des systèmes d'exploitation pour téléphones est sans doute particulier avec des besoins spécifiques, on ne peut que constater que jusqu'à présent le noyau Linux a réussi à répondre aux besoins d'une très large gamme de machines (du gigantesque supercalculateur au minuscule ordinateur embarqué). La synergie permise par un développement unifié autour d'un seul noyau modulaire est une force redoutable et Google, avec son fork, refuse de jouer le jeu de ce développement unifié et choisit la fragmentation. Il est vrai que pour participer à ce jeu la barre est assez haute puisqu'il faut écouter les avis d'autres développeurs hautement expérimentés et accepter de modifier plusieurs fois son code afin de répondre à leurs critiques.
L'ennui c'est que ce retour de la communauté Linux n'a pu être pris en compte par Google qui a choisi de créer Android en secret. Les patchs concernant wakelock ont été postés sur la LKML seulement en février 2009 alors qu'Android était en développement depuis au moins l'année 2005 et le kit de développement des applications disponible depuis novembre 2007.
Google a vraiment jeté son paquet de code "par dessus le mur" comme disent les anglo-saxons (dumping code over the wall) sans aucune volonté de l'adapter aux exigences des mainteneurs de Linux.

Matthew Garrett a répliqué à Chris DiBona que le code d'Android pouvait être accepté si Google voulait bien faire l'effort d'écouter les remarques des développeurs du noyau : « Si le monde entier vous suggère de faire un truc de façon différente et que vous refusez alors cela ne constitue pas un effort honnête de travail en commun. Nokia a réussi à obtenir le même niveau d'économie d'énergie sans tous ces changements invasifs donc toute affirmation selon laquelle wakelock serait absolument nécessaire pour qu'Android atteigne ses objectifs est sans fondement ».
L'attitude des développeurs de Google ayant consisté à développer ce code secrètement et à refuser d'écouter les critiques techniques des autres développeurs a été jugé arrogante par plusieurs personnes. Le message résumant le mieux ce sentiment est celui de rahvin : « Je suis content que les développeurs Google aient participé à cette discussion. Ils m'ont appris quelque chose que je ne savais pas : Que Google et ses développeurs croient qu'ils ont raison quoi que pensent les autres. C'est peut-être un problème de culture d'entreprise. Ils croient vraiment qu'ils ont raison et que tous les autres ont tort.
Je pense que n'importe qui serait d'accord pour dire que parfois c'est mieux d'être en dehors de la branche principale mais c'est l'exception et pas la règle. Pour entrer dans la branche principale, il faut écouter les autres développeurs quand ils vous disent que votre code est une saleté, que votre solution est mauvaise et qu'il en existe une meilleure. C'est d'autant plus vrai quand ce sont tous les développeurs travaillant dans le même domaine (ici l'embarqué) qui vous disent que votre approche est mauvaise.
Pour moi c'est une révélation de constater à quel point les développeurs de Google sont arrogants au sujet de leur code ».

Cet avis est sans doute exagérément critique puisqu'il semble y avoir de la bonne volonté du côté des développeurs de Google pour collaborer plus avant avec la branche principale. Brian Swetland, ingénieur à Google, a ainsi expliqué: « J'aimerai bien discuter de tout ça dans un forum où le but est de résoudre des problèmes communs plutôt que de blâmer les gens. Nous savons que pas mal de gens auraient été plus contents si nous avions résolu tout ça avant que nous ne sortions notre version 1.0... mais ça ne s'est pas passé comme ça et argumenter à ce sujet n'apporte rien à personne. Comprendre comment collaborer afin que les problèmes futurs puissent être résolus plus tôt me semble en revanche bien plus productif.
Donc quand et où pouvons-nous nous rencontrer avec les autres développeurs qui s'occupent de la gestion de l'énergie sous Linux afin de parler de tout ça ? ».

On voit donc qu'il y a une chance que Google fasse l'effort d'adapter son code et le prochain rendez-vous est planifié pour le sommet "Power Management" du mois d'août à Boston.
La morale de l'histoire - comme toujours - est qu'il faut poster son code "tôt et souvent" afin d'obtenir un retour de la communauté, qu'il faut penser à intégrer la branche principale dès le début, avant même de sortir son produit, pour éviter d'être bloqué par la suite en cas de changement du code. Enfin, et comme le rappelle Jonathan Corbet, « les développeurs du noyau doivent travailler pour tout le monde alors que les développeurs de l'embarqué résolvent des problèmes spécifiques sous une forte contrainte de délai. Souvent ils ne pensent pas à étendre un mécanisme pré-existant qui pourrait répondre à leur besoin. Au lieu de ça ils bricolent en vitesse un truc bancal qui n'est pas soumis à un passage en revue par les développeurs de la branche principale. On pourrait penser que Google a le temps, les ressources et la connaissance du développement noyau qui lui permettraient d'éviter tous ces problèmes et faire les choses proprement. Au lieu de ça nous avons là un exemple classique de la façon dont les choses peuvent mal tourner ».

Intégration de Nouveau

Au début de la période de merge du 2.6.33 quand Dave Airlie, responsable de la partie graphique du noyau (Direct Rendering Manager), a proposé à Linus de fusionner sa branche de développement il ne s'attendait certainement pas au message cinglant qu'il allait recevoir en retour.
Pourtant sa demande de récupération du code ("pull" dans le langage du gestionnaire de versions git) était tout à fait banale. Durant les quinze jours de la "fenêtre de tir" chaque gardien d'une sous-partie du noyau indique ainsi à Linus quelles sont les nouveautés qui sont incluses dans la branche et lui demande de faire un pull de sa branche... mais là Linus a eu le sentiment d'être volé sur la marchandise puisque le pilote libre Nouveau, destiné à faire fonctionner les cartes graphiques NVidia, n'était pas dans le paquet cadeau !
Selon le message de commit de Dave Airlie le plus gros manque de sa branche était la gestion de l'énergie du pilote Radeon ce qui lui a valu cette réplique immédiate:
« Non, le plus gros manque c'est que Fedora continue d'inclure Nouveau et que je ne vois toujours pas les gens de Red Hat essayer de l'inclure dans la branche principale. Bordel, qu'est-ce qu'il se passe ? ».
Certains développeurs ont essayé d'expliquer que le pilote n'était pas encore vraiment mûr... mais Linus sait être brutalement franc dans ses échanges :
«J'ai déjà entendu toutes ces excuses. Si ce n'est pas encore prêt alors ils ne devraient pas le proposer à des millions de personnes. Et si c'est prêt alors ils devraient travailler pour l'inclure. Pas d'excuse ».
Suivi de:
« Quand j'ai soulevé ce point lors du dernier sommet du noyau j'ai entendu plein d'excuses différentes. L'une d'elle était que cela ne faisait pas partie d'une version officielle de Fedora (ce qui n'est certainement pas vrai au moins pour Fedora 12).
J'ai aussi entendu l'excuse "Oh mais c'est difficile à inclure" mais je sais que c'est de la connerie parce que je regarde la branche git de Fedora et je vois ça merge sans aucun conflit.
L'excuse la plus commune est "Oh mais le code va encore changer". Pour commencer ce n'est même pas une bonne excuse mais de toute façon la branche -staging est justement là pour ça.
Quelqu'un a même fait un commentaire grotesque disant que "Fedora n'est pas une vraie distribution, donc elle n'est pas obligée de suivre les règles que tout le monde a accepté de suivre il y a des années, c'est-à-dire d'inclure les trucs dans la branche principale".
Je pense que cette dernière excuse est une blague. Mais c'est vraiment difficile d'être affirmatif, car les autres excuses sont tout autant débiles. Les gens semblent vraiment sortir n'importe quelle excuse merdeuse pour justifier un truc que tout le monde sait être complètement faux ».

Devant ce tir de barrage les développeurs du pilote Nouveau ont dû céder et Dave Airlie a promptement annoncé que la branche "Le poney Nouveau pour Noël" était disponible pour merge dans le 2.6.33. Le "poney" du titre de cette branche vient de l'expression anglo-saxonne "Can I have a pony too?" qu'on utilise traditionnellement pour réclamer humoristiquement une chose extraordinaire en plus de tout ce qu'on vient déjà d'avoir. C'est un peu l'équivalent de "Je peux avoir aussi cent balles et un mars ?".
Bien entendu Linus a été content d'avoir obtenu ce qu'il voulait ("PONEYS ! Super ! J'adoooore les poneys !") et les utilisateurs du noyau 2.6.33 pourront profiter d'un pilote libre pour leurs cartes NVidia qui sera de meilleure qualité que le très limité et incompréhensible pilote nv (rendu sciemment illisible par les développeurs de NVidia qui utilisent la technique de l'obfuscation).
Le blob binaire qui est nécessaire pour faire fonctionner Nouveau (le micrologiciel ctxprogs) a même été réécrit par ingéniérie inverse et une version libre, compatible avec les cartes GeForce 6 et 7, a été rendue disponible.
Le support de double écran est possible via RandR et Nouveau propose aussi l'accélération par l'intermédiaire de Xvideo. Bien entendu le support de la 3D n'est pas encore vraiment au top car c'est une tâche très complexe mais nul doute doute que le support va s'améliorer. Une matrice de compatibilité est disponible sur le site du projet.
Nouveau, fondé par le français Stéphane Marchesin, continue d'avancer à bon rythme et comme c'était prévu le code bouge beaucoup. Ainsi la partie en espace utilisateur de Nouveau a rompu la compatibilité avec le pilote DRM (Direct Rendering Manager) intégrée dans le noyau. De plus, juste après l'intégration dans la branche -staging, tout le code a été nettoyé, plus de 15000 lignes ont été supprimées, car il a été décidé que le pilote dépendrait désormais exclusivement de KMS (Kernel Mode Setting). Si votre noyau n'inclut pas KMS et que vous voulez profiter de Nouveau il va falloir songer à mettre à jour !

En bref (↑)

Avec le pilote Nouveau qui entre dans la branche -staging on peut noter que le pilote Radeon, lui, quitte cette antichambre. Il est maintenant considéré comme suffisamment stable et avancé pour rejoindre la partie "normale" du noyau. Dans cette version 2.6.33 on trouve le support du DisplayPort et de l'Embedded DisplayPort, la gestion des interruptions pour les cartes de type r6xx/r7xx ainsi qu'un support basique de la norme HDMI pour les R600. Même si le pilote Radeon est encore en retard sur les toutes dernières générations de cartes on peut considérer que la sortie de la branche -staging est le signe de la maturité. Comme l'écrit Dave Airlie : « Les distributions peuvent maintenant songer à l'activer ».

La couche du device-mapper, qui est une interface virtuelle servant à faire communiquer entre eux des périphériques blocs, vient de gagner dans cette version du noyau la capacité de restaurer des instantanés du système de fichiers (snapshots). La fonction de prise de snapshot existait depuis déjà quelque temps mais elle n'autorisait pas une restauration dans le même périphérique que celui à l'origine de snapshot.
Cette nouvelle fonction de restauration va permettre des choses fort utiles pour les systèmes qui utilisent le device-mapper, c'est-à-dire essentiellement les gens qui utilisent le gestionnaire de volumes logiques LVM. On pourra ainsi prendre un snapshot juste avant une mise à jour du système (via Aptitude ou Yum ou tout autre moyen) et faire un retour arrière en cas de problème... et ce quel que soit le système de fichiers utilisé puisque c'est la couche device-mapper qui s'occupe de tout !

Les processus générant des entrées/sorties sous forme de petits batchs périodiques vont voir leurs performances s'améliorer. En effet le noyau 2.6.33, grâce au travail de Nathan Roberts et de Jeff Moyer, va maintenant accumuler intelligemment ces entrées/sorties asynchrones avant de les envoyer en une seule fois à la couche en mode bloc. Selon le message de commit les performances d'un processus qui fait des batchs de 16 lectures séquentielles de 4 Ko de données sont améliorées de 30%.

Les quatre ordonnanceurs des entrées/sorties du noyau Linux ne sont plus que trois dans cette version 2.6.33. L'ordonnanceur "Anticipatory" a été retiré du code car il n'apporte aucun avantage particulier par rapport à CFQ ("Completely Fair Queuing" Scheduler) et qu'il est toujours bon de nettoyer du code qui ne sert plus. C'est donc la fin du chemin pour "Anticipatory" qui avait été introduit dans le noyau 2.5.59-mm5 et qui a été l'ordonnanceur par défaut entre le 2.6.0 et le 2.6.18 avant d'être remplacé dans ce rôle par CFQ. Sic transit gloria mundi.
Face à CFQ il ne reste donc plus que l'ordonnanceur "NOOP" (NO OPeration) qui comme son nom l'indique ne fait rien par lui même et s'en remet aux couches supérieures et l'ordonnanceur "Deadline" qui est spécialement recommandé pour les bases de données.
Jens Axboe indique dans son message de commit que le travail d'élimination de code sera sans doute poursuivi dans le futur : « Il faut espérer qu'à un moment nous pourrons revenir à un seul ordonnanceur des entrées/sorties. Au moins ça (l'élimination d'Anticipatory) nous rapproche de ce but d'avoir un seul ordonnanceur intelligent ».

Le système de fichiers Reiserfs est maintenant officiellement déclaré libéré de l'infâme verrou global du noyau (BKL).
Le français Frédéric Weisbecker a réussi à éradiquer toutes les occurrences du BKL du code de Reiserfs ce qui représente un bel exploit étant donné que ce système de fichiers en faisait un usage prononcé et peu académique (voir son message explicatif sur LinuxFr à ce sujet). Du côté des performances les choses sont restées plus ou moins égales (on perd d'un côté, on gagne de l'autre) avec le passage aux mutex réentrant à la place du verrou géant.

Le code de l'appel système sysctl, permettant de lire ou d'écrire les paramètres système de la machine, a été retiré du noyau 2.6.33. C'est le résultat du travail d'Eric Biederman qui a toujours soutenu que l'interface de configuration basée sur la hiérarchie /proc/sys est bien plus facile à utiliser et à scripter. Son patch enlève donc plus de 2000 lignes de code et implémente une couche (un wrapper) qui permet aux anciennes applications basées sur sysctl de continuer à fonctionner puisque ces petites naïves ne s'apercevront pas que maintenant c'est en réalité /proc/sys qu'elles utilisent.

Les infrastructures de traçage ftrace (qui a fait son entrée dans le noyau 2.6.27) et de profilage perf events (ayant fait son apparition dans le 2.6.31 sous le nom de perf counters) ont été grandement améliorées dans cette nouvelle version du noyau.
On peut maintenant, grâce au travail de Masami Hiramatsu, insérer des points de marquages dynamiques. La nouvelle fonction de traçage dynamique se base sur kprobe et pour ajouter ces points il suffit d'écrire une ligne dans /sys/kernel/debug/tracing/kprobe_events.
Il est aussi possible d'employer des expressions régulières pour filtrer les résultats de traçage et un outil de "diff" permet de visualiser facilement les changements de performances entre deux tests successifs.
Perf events est maintenant compatible avec les architectures ARM, ia64 et Alpha. On trouve aussi maintenant une commande pour enregistrer toutes les allocations mémoires du noyau, pour tracer un processeur particulier parmi les autres, etc. A noter également que l'infrastructure Hardware-breakpoint (qui utilise les registres spéciaux des processeurs pour faciliter le déboguage) a été réimplémentée par dessus perf events comme on peut le voir dans le joli schéma du commit.

L'appel système recvmsg permet de recevoir un message sur un socket réseau. Comme tous les syscall le fait de franchir la séparation entre espace utilisateur et espace noyau signifie qu'il s'agit d'une opération coûteuse. Arnaldo Carvalho de Melo a eu l'idée de créer un nouvel appel système qui permettrait de recevoir plusieurs messages d'un seul coup au lieu d'un seul. Astucieusement nommé recvmmsg (le "mm" c'est pour multiple messages) ce syscall est une excellente idée et il permettra de réduire la surcharge (overhead) dans les échanges réseaux à haut débit. Évidemment il faut maintenant que les applications utilisent ce nouvel appel système pour profiter de ses bienfaits.

Les modules de sécurité basés sur le chemin (par opposition à SELinux qui fonctionne avec des labels attachés aux objets) vont voir leur travail facilité dans le noyau 2.6.33. De nouveaux hooks (crochets logiciels) ont été ajoutés afin de pouvoir contrôler les commandes chmod (permet de changer les permissions), chown (permet de changer le propriétaire) et chroot (changer le répertoire racine d'un processus). Le module de sécurité basé sur le chemin TOMOYO, qui est entré dans le noyau 2.6.30, pourra maintenant contrôler plus finement ces trois commandes.

Vous êtes des fondus de l'optimisation ultime ? Vous ne jurez que par Gentoo et vous ne compilez dans votre noyau que les modules strictement indispensables afin de gagner quelques Ko ? Soyez contents car Ted Ts'o a pensé à vous. Maintenant il est possible de choisir l'option de configuration CONFIG_EXT4_USE_FOR_EXT23 afin de pouvoir utiliser directement le code du système Ext4 pour monter vos systèmes Ext2 et Ext3. Ext4 n'est en effet qu'une profonde modernisation de la série des Ext(x) et son code préserve la compatibilité permettant de monter ses respectables ancêtres.
L'option CONFIG_EXT4_USE_FOR_EXT23 permet donc de ne plus compiler du tout dans son noyau les anciens systèmes de fichiers Ext2 et Ext3. Comme le dit Ted c'est une option rêvée pour les "minimalist kernel fanatics".

Le protocole de réseau B.A.T.M.A.N (Better Approach To Mobile Adhoc Networking) est un nouveau type de réseau ad hoc qui est en cours de développement. Le routage pour ces réseaux dont l'infrastructure n'est pas définie et organisée strictement est un problème difficile à résoudre. Jusqu'à présent c'est surtout le protocole OLSR qui était utilisé mais les hackers allemands de la communauté Freifunk ont décidé de proposer une meilleure solution. Conceptuellement l'idée derrière B.A.T.M.A.N peut se comparer à un chemin emprunté par des fourmis laissant des phéromones. Plus il y a de fourmis qui passent et plus la piste odorante en attire d'autres. Ici des paquets OGM (Originator Message) de 52 bits sont envoyés en permanence avec un numéro de séquence. Ces paquets jouent le rôle des phéromones et plus il y a de données qui arrivent d'un lien plus ce lien se voit accordé de "confiance" pour transmettre les nouveaux paquets. C'est ce phénomène d'auto-renforcement et d'auto-organisation qui est au cœur de B.A.T.M.A.N.
Le noyau Linux 2.6.33 accueille dans sa branche -staging la version 2 du protocole B.A.T.M.A.N dont le principe, très intéressant, est exposé sur cette page.

Le processeur Loongson 2F, basé sur l'architecture MIPS est une puce conçue par l'Institute of Computing Technology de l'Académie des sciences chinoise. Le but recherché par les autorités chinoises avec toutes ces versions successives de la famille Loongson est de parvenir à une certaine indépendance par rapport aux processeurs d'origine américaine. Le noyau 2.6.33 propose donc la gestion de la dernière version 2F, le code permettant la variation automatique de fréquence ainsi que la mise en veille/hibernation. A noter que si, comme Richard Stallman, vous ne voulez utiliser que des logiciels libres (y compris les micrologiciels et le BIOS) alors ce portable Lemote basé sur un Loongson 2F est vraisemblablement ce qu'il vous faut. En tout cas RMS ne jure que par lui.

Du côté de l'architecture PowerPC il y a aussi du neuf. Tout d'abord le noyau 2.6.33 ajoute le support dans la branche principale des consoles de jeu Nintendo Gamecube et Nintendo Wii (avec les patchs associés pour le processeur Broadway, la carte graphique Hollywood, etc.). A l'autre extrémité du spectre de puissance on trouve les patchs améliorant le support des partitions logiques dynamiques (DLPAR pour Dynamic Logical Partitioning) sur les gros serveurs PowerPC d'IBM. On peut ainsi plus facilement ajouter ou enlever "à chaud" des ressources comme des cartes processeurs, des barrettes mémoire ou divers périphériques.

La technique du Read-Copy update est utilisée dans Linux afin de synchroniser de multiples threads pour leur permettre de lire simultanément une donnée sans poser dessus un verrou coûteux. C'est un mécanisme très efficace dont le grand spécialiste est Paul McKenney. Dans le noyau 2.6.29 la fonction RCU est devenue "hiérarchique" pour faciliter encore plus la montée en charge sur les machines massivement multi-processeurs.
Lors de la précédente conférence linux.conf.au un sondage informel a été organisé par Paul McKenney qui a demandé à ses pairs si un code spécialement adapté à l'embarqué serait utile. Comme la réponse a été positive le nouveau noyau 2.6.33 introduit un petit cousin du RCU hiérarchique à destination des machines n'ayant qu'un seul processeur (pas compatible SMP donc). Ce "Tiny RCU" permet, sur architecture x86, de gagner environ 2,7 Ko sur le module quand on passe de l'option CONFIG_TREE_RCU à CONFIG_TINY_RCU (3526 octets pour "tree" contre seulement 858 octets pour "tiny").
Comme il en a pris l'habitude depuis plusieurs mois, Paul McKenney a décrit en détail ses travaux dans un article du site LWN (avec des quizzs à la fin pour voir si vous avez suivi ou si, comme moi, vous faites juste semblant de comprendre).

Le système de fichiers NILFS (New Implementation of a Log-structured File System) basé sur la technique d'écriture des données "en flux" sous forme de log et qui a fait son entrée dans le noyau 2.6.30, a été largement optimisé dans la version 2.6.33. Ryusuke Konishi annonce ainsi que l'allocation des blocs bénéficie d'un meilleur temps de latence, que la reprise après un unmount "sauvage" est plus rapide (plus de 60% de réduction pour le temps de remontage du fichier du fait de l'utilisation de readahead) et enfin que la suppression de fichiers de grande taille est accélérée (18% de mieux).

Le système de fichiers XFS, créé à l'origine par la société SGI et réimplémenté dans Linux, avait jusqu'à présent une infrastructure de tracing bien à lui. Dans le noyau 2.6.33 ce code baroque et redondant a été retiré et XFS utilise maintenant l'infrastructure commune de tracing du noyau. L'activation du tracing de XFS se fait avec un simple "echo 1 > /sys/kernel/debug/tracing/events/xfs/enable" et les résultats devraient être de bien meilleure qualité puisque de nombreux nouveaux points de traçage ont été ajoutés pour voir plus finement ce qui se passe lors du fonctionnement du système de fichier. Comme le signale Christoph Hellwig, et en dépit des ajouts de nouveaux points de traçage, « Le truc vraiment cool dans ce patch c'est qu'en fait il enlève plein de lignes de code tout en ajoutant des fonctions ».

La machine virtuelle KVM (Kernel-based Virtual Machine) a été améliorée dans cette version 2.6.33 du noyau Linux.
Par exemple KVM utilise depuis toujours les registres spécifiques (MSR pour Model-specific Registers) des processeurs pour fonctionner. Cette utilisation est maintenant rendue bien plus rapide car, au lieu de charger/décharger en permanence ces registres à chaque changement de contexte, le noyau 2.6.33 autorise maintenant un partage des données dans certains cas. Le gain annoncé est très important puisqu'il peut atteindre environ 2 000 cycles de processeur. Dans son message récapitulatif des patchs incorporés dans cette version, Avi Kivity (qui est développeur principal de KVM) indique également que la machine virtuelle cohabite mieux avec l'infrastructure de changement automatique de fréquence cpufreq et qu'il n'est plus nécessaire de décharger d'abord le module KVM avant d'utiliser d'autres solutions de virtualisation.

Le pilote Microsoft hyper-v, destiné à faire fonctionner un système Linux en tant qu'invité (guest) sur un système Windows, avait été en septembre dernier sous la menace d'une éjection pure et simple de la branche -staging pour cause d'abandon. Depuis les développeurs Microsoft sont réapparus et le noyau 2.6.33 contient donc toujours ce fameux pilote. En décembre Greg KH a fait le point sur l'état de la branche -staging et on peut lire la phrase suivante : « Pilote Hyper V Microsoft. Les développeurs semblent avoir disparus une fois de plus, cela commence à être fatiguant. Marqué pour retrait dans le 2.6.35 ».
Pourtant le 20 janvier un message de Hank Janssen, développeur chez Microsoft, est apparu sur la liste de diffusion du Linux Driver Project et à sa lecture on comprend mieux pourquoi, à Redmond, le travail sur ce pilote avance avec le rythme majestueux d'un glacier plutonien :
« Le monde bouge lentement ici du côté sombre, mais des progrès sont en cours. J'ai finalement tiré les bons leviers en interne pour commencer à travailler sur la TODO list.
Oui c'est bien ça le grand trouble que vous avez senti dans la Force.
Encore une fois toutes mes excuses mais la taille des montagne qu'il faut bouger en interne pour nous permettre de travailler en vue d'une intégration dans la branche principale est proprement tectonique. Sans compter que ça a raccourci mon espérance de vie de plusieurs années :)
J'apprécie vraiment votre patience à tous. Nous sommes en train de changer, mais très lentement ! ».

Le bilan en chiffres (↑)

Côté statistiques, l'article récapitulatif pour le 2.6.33 du site LWN est disponible et on pourra également se reporter au site dédié aux statistiques du noyau Linux. Un autre article récent du site LWN (accessible dès maintenant pour les abonnés et visible par tous à partir du jeudi 25 février) s'est également penché sur les statistiques cumulées depuis l'introduction du gestionnaire de version git, c'est-à-dire en avril 2005 avec la version 2.6.12-rc2.

Pour le noyau 2.6.33, le nombre de patchs était de 10 784 au 21 février (10 944 pour le 2.6.32). Il semble bien que l'équipe de développement de Linux se soit plus ou moins calée sur un rythme de développement qui représente un peu plus de dix mille patchs tous les trois mois, écrits par un peu plus de 1000 développeurs (1188 cette fois-ci).
En terme de lignes de codes, nous avons près d'un million et demi de changements (ajout de 900 000 lignes et suppression de 520 000 lignes).
Dans l'article récapitulant l'évolution entre le 2.6.12-rc2 et le 2.6.33 ("How old is our kernel?"), on apprend notamment qu'en cinq ans le code du noyau Linux dans son ensemble a beaucoup changé puisqu'il ne reste plus que 31% des lignes de code du noyau actuel qui n'ont pas été modifiées depuis avril 2005. Les parties ayant le moins changé sont les sous-répertoires documentation (41% de code identique) et sound (45% de code identique). Le cœur du noyau quant à lui (kernel) ne contient plus que 13% de code datant du 2.6.12-rc2.
Une autre statistique intéressante à considérer est celle des primo-contributeurs (ceux qui ont fait un patch dans le noyau pour la toute première fois lors d'un cycle donné). Si on utilise les pages "First commit" du site Linux Kernel Patch Statistic on trouve les résultats suivants :
Noyau 2.6.27 : 216 primo-contributeurs
Noyau 2.6.28 : 252 primo-contributeurs
Noyau 2.6.29 : 279 primo-contributeurs
Noyau 2.6.30 : 256 primo-contributeurs
Noyau 2.6.31 : 275 primo-contributeurs
Noyau 2.6.32 : 294 primo-contributeurs
Noyau 2.6.33 : 272 primo-contributeurs

On voit que chaque noyau enregistre la participation de plus de 250 nouvelles têtes à chaque fois, ce qui est rassurant pour la pérennité du modèle de développement utilisé.

Enfin, si on regarde les statistiques en terme de nombre de patchs nous pouvons pousser un franc cocorico, puisque c'est le français Frédéric Weisbecker (fweisbec sur LinuxFr) qui est médaille d'or dans cette version 2.6.33 avec un total impressionnant de 146 patchs ! On y retrouve le travail évoqué plus haut sur le traçage/profilage, la suppression du BKL dans reiserfs, ainsi que la réimplémentation de Hardware-breakpoint par dessus perf events.
Comme ces travaux me semblent particulièrement difficiles à comprendre et à expliquer (oui, ça s'est vu dans la dépêche que je patauge sur le tracing), j'ai pensé que Frédéric serait mieux à même d'en parler directement aux lecteurs de LinuxFr et que cela nous permettrait par la même occasion de mieux faire sa connaissance.
Je lui ai donc soumis une petite liste de questions auxquelles il a eu la gentillesse de répondre.

Questions/Réponses avec Frédéric Weisbecker (↑)

Patrick_g : Pourquoi avoir choisi de contribuer à Linux ? La GPL c'est important dans ton choix ou pas ?

Frédéric Weisbecker : Pourquoi Linux ? D'abord parce que les noyaux sont ce qui me fascine le plus dans l'informatique. J'ai toujours voulu savoir comment mes logiciels contrôlaient mon matériel. Quand j'ai commencé à chercher des informations sur le sujet, c'étaient toujours des bribes disséminées un peu partout sur le web.
Je crois que c'est le côté cryptique de la chose qui est attirant, un peu pour la même raison que j'aime bien le reverse engineering :)
Partant de là, j'ai exploré le développement noyau sous Windows et Linux. Mais comme le noyau Windows est complètement obfusqué et que je n'y trouvais que des informations très schématiques, je ne m'y suis pas beaucoup attardé.
Linux étant open source, ça a été déterminant bien sûr, même s'il a fallu que je relise Linux Device Drivers ed.3 de nombreuses fois et que - même après - je ne comprenais toujours rien au code :)

Mais sa licence et surtout son développement ouvert (oui, oui, il y a des logiciels GPL/BSD/etc. qui ont un processus de développement tout à fait fermé) ont été très importants pour moi. C'est un processus très démocratique, qui fait qu'un inconnu lambda - comme je l'ai été en arrivant - peut participer lui aussi, pas besoin d'être employé par Red Hat ou Intel pour ça.
Bien sûr ce n'est pas une démocratie pure et parfaite, elle implique aussi une chaîne de confiance complexe avec des nœuds divers ayant plus ou moins de poids qui varie selon les sous-systèmes, mais tout de même, le plus gros poids reste dans le patch, je pense.

Ensuite, le côté logiciel libre et développement ouvert permet de vous faire un nom, visible rapidement sur le Web et qui reflète ce que vous avez fait. Si vous êtes étudiant en informatique et que vous voulez bosser dans un domaine particulier, prenez un logiciel libre dans ce domaine, et participez. La liste des bénéfices à en tirer est innombrable.

Autre chose : ça émousse aussi un peu le Complexe de la Momie. Si vous vouez votre vie au logiciel propriétaire, est-ce-que les gens pourront réutiliser votre travail ? À quel point ? Pendant combien de temps ?
Participer au logiciel libre implique le principe de "se hisser sur les épaules des géants", votre travail aura plus de chances d'être réutilisé, vous aurez agrandi le géant à votre tour et les briques laissées derrière votre passage auront plus de pérennité.

C'est aussi la raison pour laquelle je préfère les licences de type GPL aux licences BSD. Ça force plus le travail en commun. Plutôt que chacun réinvente le même moulin, des entreprises concurrentes qui bossent sur des produits éphémères se rejoignent tout de même sur un point commun, un travail à long terme, un truc particulier.
La GPL amène ça par la coercition, une œuvre qui fait réellement progresser les choses. Je pense que la BSD amène ça aussi, mais avec beaucoup moins d'efficacité.

Patrick_g : Es-tu payé pour ton travail sur Linux ou travailles-tu sur ton temps libre ?

Frédéric Weisbecker : Non, que du temps libre.

Patrick_g : Si tu es bénévole as-tu reçu/t'attends-tu à recevoir des propositions de job à la suite de tes contributions ?

Frédéric Weisbecker : Je n'ai pas reçu de propositions de job. Et je suis étudiant, alors jusque là je n'ai pas vraiment cherché. Mais je suis en fin de cursus, avec beaucoup de temps libre, donc si quelqu'un veut d'un développeur noyau (upstream de préférence) à mi-temps je suis preneur :)

Patrick_g : La LKML a-t-elle été accueillante pour tes patchs ou y a-t-il eu des oppositions virulentes ?

Frédéric Weisbecker : Selon les patchs, l'un ou l'autre. Et c'est le cas pour tous les développeurs du noyau, ce sera toujours comme ça et heureusement. Même les plus expérimentés se font refuser des patchs. Même les mainteneurs d'un sous-système peuvent se voir refuser des patchs dans le domaine qu'ils maintiennent.
En fait, il y a plusieurs niveaux de passage en revue d'un patch, par ordre de priorité :

1) Le changement répond-il à un vrai besoin ? Est-ce-qu'il résout un vrai problème, est-ce-que ce changement est utile?

2) Le changement répond-il d'une bonne manière à ce besoin ? Est-ce une bonne solution ? Devrait-on le faire autrement ?

3) L'architecture du nouveau code est-elle propre ?

4) Y a-t-il des fautes de code, des bugs, des problèmes de verrous, etc.

5) Le changement respecte-il les standards de style de Linux ? (espaces blancs, indentations, accolades mal placées, etc.)

Bien souvent, si le niveau n ne passe pas, le niveau n+1 ne sera même pas examiné.
Ceci étant, lorsque l'on devient familier avec un sous système particulier, on devient très à l'écoute de son cycle de vie, on a une meilleure vision globale de son code, des problèmes qui sont en suspens. On passe aussi en revue les patchs des autres et on découvre les problèmes qu'ils ont vu, ce qui en déterre d'autres, on découvre également les besoins des autres. À partir de là, l'étape 1 ne pose plus beaucoup de problèmes.

Reste l'étape 2. Si votre changement implique beaucoup de boulot (plus qu'une journée), surtout parlez-en d'abord sur LKML, voyez l'opinion générale sur l'architecture qui conviendrait le mieux avant de vous lancer, ou vous risquez de vous casser les dents après des jours, voire des mois de boulot. Lorsqu'on agit seul, même si l'on est familier avec le code en question, on a souvent une vision erratique et incomplète du problème ou de la solution à adopter.
Il faut entamer une discussion, et/ou proposer des maquettes très brouillonnes, à peine testées (patchs RFC), juste pour tâter l'opinion avant de se lancer pour de bon.
Souvent on passe l'étape 3 par la même occasion à force de proposer des patch RFC et de corriger à partir des commentaires donnés par les relecteurs sur LKML.
Le reste de l'étape 3, puis la 4 et 5 se résolvent à force d'adresser les commentaires des autres, après quelques versions du patch.
Ça peut aller jusqu'à prendre parfois une dizaine d'itérations, ça arrive...
Il est rare qu'un changement significatif soit accepté dès la première version.

Patrick_g : Vas-tu continuer ton travail d'élimination du BKL dans d'autres coins du noyau que reiserfs ?

Frédéric Weisbecker : Peut-être, oui. J'ai déjà enlevé quelques traces de bkl ailleurs que dans reiserfs.
Les restes de Bkl sont dans des vieux pilotes, donc difficiles à tester, mais aussi encore un peu dans le cœur du noyau : VFS, Block, TTY... Ce qui reste à supprimer dans le cœur est délicat, on ne sait pas toujours ce qu'il protège.
Ça donne lieu à beaucoup de "Pushdown". C'est-à-dire que lorsque l'on a :

lock_kernel();
func1();
unlock_kernel();

Si func1() est une callback(), on va descendre l'appel de la BKL dans toutes les instances de func1() (toutes les fonctions susceptibles d'être pointées par func1).
Ce sera plus facile de la supprimer après ça, car on finira au fur et à mesure par arriver à passer en revue chacune de ces fonctions, voir laquelle a besoin d'un verrou et remplacer par un verrou traditionnel si c'est le cas, sinon supprimer la bkl à cet endroit. Ce travail peut passer par un pushdown de plus en plus profond, jusqu'à ce qu'on aie une vision nette et chirugicale de ce qu'elle protège (lorsqu'elle protège quelque chose).
Si func1 est une fonction en dur, c'est le même principe, on pushdown sur les function que func1() appelle.
D'ailleurs ce travail donne l'illusion que la suppression du bkl n'avance pas. Si tu fais un grep sur lock_kernel dans les sources du noyau, tu trouveras peut être plus d'appels que dans une version précédente, mais en réalité il est pris moins souvent et plus sélectivement.

Patrick_g : Ton patch "bkl ftrace events" peut-il permettre de faciliter le travail ?

Frédéric Weisbecker : Non. Il permet de tracer l'activité de la bkl pendant que le système tourne. Ça permet de déterminer la fréquence de son usage dynamiquement, le temps durant lequel il est acquis, où et quand.
Si un grep lock_kernel est inefficace pour voir la progression de la suppression du bkl, en revanche les événements donnés par ces points de traçage par ftrace offrent une meilleure vue à ce niveau (pour une configuration de noyau donnée).
Ça peut aussi être utile pour quelqu'un qui a des pré-requis en termes de latence, vérifier le taux d'utilisation du bkl avec une configuration noyau donnée ou un matériel spécifique (dans le cas où un pilote utilise le bkl). Et également ça permet de voir à quel endroit on l'utilise le plus à l'exécution.

Patrick_g : Pourquoi les gens de FreeBSD ont-ils réussi a enlever le BKL de TTY dans leur version 8.0 alors que Linux se traîne encore un code antique ?

Frédéric Weisbecker : Héhé, bonne question. Je ne connais pas bien le code de FreeBSD.
Ceci dit, TTY est un sous-système maudit sous Linux. Je crois que peu de gens osent s'y aventurer, peut être parce que c'est le bordel, je ne sais pas trop. Je dois avouer que chaque fois que j'y vais, ça pique les yeux :)
Mais Alan Cox y a consacré beaucoup de temps. C'est l'un des seuls à bien connaître ce code, et il a, parait-il, assaini considérablement le code de tty et a supprimé beaucoup d'empreintes de Bkl dedans. Il en reste peu d'ailleurs. Il est surtout présent dans les évènements "hangups" de tty.
Malheureusement, Alan Cox a rendu son tablier de mainteneur de Tty, il y a quelques temps. Il devait en avoir marre. Ceci étant, il envoie encore des patchs pour TTY, notamment des pushdown de bkl dans les chemins de hangup :)

Patrick_g : T'arrive-t-il de regarder le code des systèmes BSD pour comparer avec Linux ou bien est-ce terra incognita pour toi ?

Frédéric Weisbecker : Terra incognita :)

Patrick_g : Où en est la situation générale du tracing sous Linux à l'heure actuelle ? Le noyau est-il en retard sur DTrace ?

Frédéric Weisbecker : Euh... je me sens un peu honteux. Mais je ne connais pas bien le tracing en dehors de ce qu'il y a sur la branche principale du noyau Linux. Mais bon je vais essayer de décrire un peu ce que je sais (ou ce que je crois savoir).

Premièrement, je ne sais strictement rien sur DTrace.

Le noyau Linux n'avait pas de sous-système de tracing avant 2.6.27. Mais il y avait beaucoup de mouvement dans des branches de développement avant cela, avec des orientations et des buts tout à fait différents :

- LTTng
Il y avait LTT, "Linux Tracing Toolkit", un patch out of tree avec des outils utilisateurs qui permettait de tracer l'utilisation du processeur. Je ne connais pas les détails, il s'agissait peut être de hooks sur l'ordonnanceur de tâches, entre autres.
Puis l'Ecole Polytechnique de Montréal a repris ce projet pour en faire LTTng (Linux Tracing Toolkit next generation) dont le développeur et mainteneur principal est Mathieu Desnoyers avec de multiples contributions par diverses compagnies comme Fujitsu, Sony, etc.
L'orientation principale de LTTng est de fournir un tracing qui tient bien le passage à l'échelle (utilisable même avec la multiplication de multi-cœurs, etc.), et un tracing fortement optimisé pour être même utilisable lorsque les services tournent, sans trop d'impact sur les performances. Ainsi on peut utiliser LTTng sans besoin d'interruption de service. Un utilisateur peut tracer son noyau sans impact sur le service qu'il offre à ses clients.

LTTng est basé sur les tracepoints (mergés d'ailleurs dans le noyau principal) et les markers, ainsi qu'un tampon circulaire qui centralise les données et enfin un jeu d'outils utilisateurs pour exploiter les événements tracés. Les tracepoints sont des points de traçage statiques dans le noyau. LTTng en a placés sur de multiples points clés du cœur du noyau (ordonnanceur, irqs, appels systèmes, timers, etc.) pour offrir une vue assez complète de ce qui se passe. Les outils utilisateurs synthétisent tout ça.

Mathieu a fait un très bon boulot. Il avait essayé à l'époque de bosser sur la branche principale plutôt qu'out-of-tree, mais je crois que ça s'est soldé par un échec. À cette époque, les développeurs du noyau ne considéraient peut-être pas encore l'importance des tracepoints statiques. Et avoir des points de traçage statiques un peu partout dans le noyau n'enchantait pas grand monde dans la branche principale.
Je ne sais pas exactement pourquoi. Peut être parce que l'importance du tracing était encore trop peu considérée à l'époque, à moins que ce ne soit parce que ces tracepoints étaient sortis de leur contexte et ne semblaient pas encore avoir d'application directe. Je ne sais pas.

Je ne sais pas non plus où Mathieu en est avec ses projets de "mainlining" de LTTng. Je pense que l'une des difficultés est peut être d'adapter LTTng en cohérence avec l'existant en amont : Ftrace.

- SystemTap
L'orientation de SystemTap est fortement basée sur le scripting et les tracepoints dynamiques.
Un utilisateur peut écrire un script (dans un langage dédié) pour extraire des évènements du noyau divers et variés, sortir des statistiques, etc. le tout sans besoin de tracepoints statiques.
Les tracepoints sont insérés dynamiquement par le biais d'un hot-patching (modification du code en mémoire).
Pour ça, Systemtap utilise kprobes (permet de créer/gérer des tracepoints dynamiques dans le noyau), et uprobes (même chose mais en espace utilisateur). Kprobes est mergé dans la branche principale, mais pas uprobes.
Il y a également, si je ne me trompe pas, un compilateur script -> bytecode et un interpréteur bytecode dans un module noyau (out of tree).

SystemTap est également basé sur utrace, un outil pour faciliter l'implantation de code pour gérer le traçage des processus, etc.

SystemTap n'est pas dans la branche principale car je crois qu'il y a eu des désaccords fondamentaux sur son architecture entre les développeurs de la branche principale et ceux de systemtap.

- Ftrace
Le patch Preempt-rt, la branche out of tree dédiée au développement de Linux pour en faire un noyau utilisable pour faire du temps réel soft, avait besoin de faire beaucoup de tracing afin de repérer les zones responsables de latences non voulues.
Quelques traceurs sont nés : un traceur de fonctions (responsable du nom ftrace), un traceur de zones non-préemptibles, un traceur d'événements de l'ordonnanceur, etc. écrits par Steven Rostedt, Ingo Molnar et d'autres.
Ces traceurs ont fini par former un sous-système à part entière, avec possibilité d'écrire de nouveaux traceurs sous forme de greffons. Le tout a été mis au propre et mergé dans la branche principale dans 2.6.27.

Ftrace est devenu plus qu'ftrace, et est maintenant le sous système de tracing de la branche principale. D'autres greffons ont été développés ou adaptés pour ftrace : traceur d'allocateur de mémoire, traceur d'évènements blocks, mmiotrace, un traceur de graphe de fonctions, etc. Le tout, tournant autour d'un tampon circulaire qui agglomère le tout et d'une interface debugfs.

- Aujourd'hui
Maintenant où en sommes nous? Justement les choses ont beaucoup évolué, le tracing est devenu un sujet très actif dans la branche principale.

Les tracepoints statiques ont pris beaucoup d'importance depuis qu'ils ont une nouvelle surcouche : les ftrace events. Ceux-ci permettent d'exploiter les tracepoints depuis debugfs. On peut les activer en utilisant des pseudo-fichiers et récupérer leurs traces facilement.
Donc l'insertion de tracepoints statiques dans le noyau se fait beaucoup plus allègrement. On a maintenant des tracepoints pour la plupart des points clés du cœur du noyau. Certains de ces efforts viennent d'ailleurs des développeurs de LTTng qui ont adapté certains de leurs tracepoints pour la branche principale.

Les tracepoints dynamiques ont également gagné en importance. Kprobes, qui jusque là n'avait pas d'utilisateur dans la branche principale, a gagné son interface utilisateur par le biais des ftrace events (permettant de créer des tracepoints statiques qui sont en fait virtuels : ce sont des tracepoints dynamiques).

2.6.31 a également vu arriver un nouveau sous-système de profiling : perf events (autrefois perf counters). Les tracepoints, qu'ils soient dynamiques ou statiques, peuvent maintenant être utilisés pour faire du profiling, voire pour coupler du tracing et du profiling, un outil très puissant. Et justement, on voit aujourd'hui arriver des changements permettant de scripter l'exploitation de ces évènements de tracing par le biais de scripts python ou perl.
L'utilisation de filtres dans les événements de ftrace, couplés avec ce genre de scripting, nous rapproche finalement des buts de SystemTap, mais avec des langages connus, bien que les choses ne se fassent finalement pas au même niveau d'action.

Parallèlement, les développeurs de SystemTap ont fait des tentatives pour merger utrace, sans trop de succès étant donné le manque de couche d'utilisation existante de utrace dans la branche principale, ainsi que des divergences d'opinions sur son architecture et son rôle.
Utrace génère des doutes et est décrié par les développeurs de la branche principale qui le taxent de "machine à tout faire sans rôle clairement défini" (traduction grossière de ce qu'en dit Linus).

Voyant la puissance offerte par l'utilisation de kprobes en utilisant perf events et ftrace, on commence à vouloir explorer les tracepoints dynamiques sur les processus utilisateurs. Exactement ce que fait uprobes. Uprobes a donc été proposé récemment pour la branche principale.
Beaucoup de controverses ont été levées : la dépendance à utrace par uprobes, son interface ftrace à renouveler pour pouvoir l'exploiter avec perf events, l'architecture du hot patching : divergences d'opinions sur la manière de rebondir sur l'application utilisateur après déclenchement d'un hook. Mais il y a fort à parier que uprobes fera son chemin un jour dans la branche principale, étant donnée la puissance de ce genre d'outil.

Il y a également encore beaucoup de choses en prévisions, ex. : utilisation du traceur de fonctions pour faire du profiling par fonction avec perf events, par exemple (compter les cache-hit, cache-miss au sein d'une fonction, entre autres possibilités).

Patrick_g : Entre les patchs sur l'élimination du BKL, ton travail sur les hw-breakpoints et celui sur le profilage et le tracing tu as touché des parties compliquées et diverses du noyau. Es-tu surhumain ?

Frédéric Weisbecker : Héhé :) Non. En fait j'ai eu la chance de bosser sur des sous-systèmes jeunes, voire naissants.
Essayez de travailler sur l'ordonnanceur de tâches, par exemple. Je pense que c'est difficile parce que CFS (l'ordonnanceur actuel) a été mergé il y a quelques cycles déjà. C'est un gros morceau qui a eu le temps de se stabiliser et de mûrir. Il y a certainement des choses à faire encore, mais pour un nouveau venu ça prendra un peu de temps de se familiariser avec ses milliers de lignes de code qui ont déjà de la bouteille. C'est tout à fait possible, ça demandera juste du temps.

Or, si vous arrivez sur le développement d'un nouveau sous-système, ou d'une grosse refonte d'un sous-système, c'est du code encore frais, plein de bugs, plein de choses à améliorer, à augmenter, à repenser. Il suffit de compiler, tester et les bugs viennent tout seuls, plus qu'à envoyer les patchs pour corriger les problèmes.
Quand on commence cet engrenage, on se familiarise très vite avec le code en question, et des idées d'améliorations plus larges viennent avec le temps étant donnée la meilleure compréhension du sous-système que l'on gagne, et les relations/suggestions/plaintes des autres développeurs ou utilisateurs.
C'est ce qui m'est arrivé avec ftrace qui venait d'être mergé quand je suis arrivé. Pareil avec perf events (d'autant qu'il y avait besoin de créer un pont avec ftrace, que je connaissais déjà bien).
Idem avec les hardware breakpoints, une nouvelle API générique proposée par K. Prasad que nous avons rediscutée, puis améliorée à partir de sa version.
Pour reiserfs, c'est plus du hasard. Je pensais que ça prendrait juste un après-midi pour transformer le BKL en un mutex.
Plus je corrigeais les bugs dûs à la conversion, plus je me disais "nan mais après ce patch là ce sera bon, ça marchera, c'est le dernier".
Finalement, ça m'a pris plusieurs mois, j'ai vraiment mal anticipé la tâche :)

Patrick_g : Merci encore Frédéric d'avoir pris le temps de répondre à mes questions.

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 et surtout vers cet article du site Linux Weekly News qui désigne deux candidats évidents.

Ceph

Ceph est un système de fichiers distribué qui à l'ambition de pouvoir évoluer et monter en charge sans aucun problème. Cette capacité à absorber la charge (en terme d'utilisateurs simultanés) et à évoluer en taille (en terme de disques connectés) représente les deux points forts de Ceph qui est issu de la thèse de doctorat de son concepteur Sage Weil.
Pour atteindre ses objectifs Ceph migre automatiquement les données sur les différents disques afin d'avoir une bonne répartition des accès sans "point chaud". Il n'y a pas de disque de secours spécifique et, en cas de nécessité, la récupération des données se fait à partir de dizaines de disques simultanément et à destination de dizaines d'autres disques (N-way replication).
Une particularité de Ceph est qu'il existe des serveurs de méta-données (MDS pour MetaData Server) qui sont séparés des serveurs de données (OSD pour Object Storage Devices). Ils servent à répartir intelligemment les données, journalisent les modifications et permettent de s'adapter dynamiquement à la charge (dynamic scaling).
Ce fonctionnement ressemble un peu à celui du système de fichiers Lustre et Ceph, avec le slogan "scale from gigabytes to petabytes and beyond", vise clairement à devenir un concurrent plus facile à administrer.
L'opportunité d'intégrer la branche principale du noyau a été manquée lors de la "fenêtre de tir" du 2.6.33 pour diverses raisons dont la plus visible est le refus de Linus de se laisser impressionner par la liste des fonctions. Son message détaillé est très intéressant à lire car il explique ce qui motive son choix d'inclure ou pas une nouvelle fonction dans le noyau : « Quand il s'agit d'ajouter tout un nouveau morceau de code ma réponse par défaut est toujours "non". Il faut d'abord m'expliquer pourquoi je _dois_ inclure ce truc ».

AlacrityVM

S'il est probable que Ceph sera ajouté rapidement au noyau, la situation est beaucoup moins rose pour AlacrityVM et la bataille fait rage entre les développeurs. AlacrityVM est une nouvelle proposition (encore une !) dans le domaine de la virtualisation puisqu'il s'agit d'un dérivé de KVM qui se concentre sur les performances dans le domaine des entrées/sorties. Le but de Novell, qui est derrière le projet, est d'arriver à un débit équivalent aux spécifications maximales du matériel et d'obtenir une virtualisation sans aucun impact négatif en terme de performances. Le code se base sur une utilisation directe des pilotes d'entrées/sorties au lieu de passer par des pilotes émulés. Ces deux schémas successifs (avant - après) aident à comprendre la logique du développement d'AlacrityVM.
L'ennui c'est que les développeurs de KVM ne sont pas très contents de cette solution qui constitue essentiellement un "fork" de leur code. Ils réclament un travail en commun plutôt que l'écriture d'une nouvelle solution complètement séparée. Ingo Molnar semble leur donner raison puisqu'il signale que : « Ces patchs ont reçus de multiples objections par les gens de KVM, pour des raisons techniques, car cela consiste basiquement à forker tous les pilotes KVM sans qu'aucune raison convaincante n'ait été apportée dans une discussion s'étendant sur plus de cent messages. Le résultat serait à mon humble avis un désagrément pour les utilisateurs car nous aurions deux infrastructures, des incompatibilités d'outils, etc. ».
Ce message d'Ingo a relancé la bataille et une magnifique flame war s'est développée sur la LKML.
Comme c'est toujours Linus qui prend la décision finale, il a choisi de ne pas inclure AlacrityVM dans le noyau 2.6.33 et d'attendre que la poussière retombe un peu avant de choisir.
Son message explique bien, avec son ton inimitable, quelle est sa position :
« Les gens de la virtualisation discutent toujours à propos des 36 000 façons différentes qu'il y a de faire les choses. Au lieu de se concentrer sur les vrais pilotes, là où s'exerce vraiment la contrainte due au matériel, ils semblent se complaire à créer de nouvelles interfaces à un rythme hebdomadaire.
Quand je vois une nouvelle interface de virtualisation, je voudrais que les spécialistes se disputent à son sujet _entre eux_. Du fait que, personnellement, je ne me soucie absolument pas le moins du monde de la virtualisation, je peux prendre un peu de recul et admirer le feu d'artifice. Cela ne veut pas dire que ça ne m'amuse pas, j'aime bien une flame war à l'occasion, mais pour être vraiment impliqué dans une flame war, il faut que j'y attache assez d'importance pour m'enflammer à ce sujet.
Donc je ne veux pas que cette bataille se déroule dans mon dépôt et je préférerais vraiment que les combats s'achèvent _avant_ que je ne merge.
Vous êtes tous des malades les gars. ».

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

CFS/CFQ

Posté par fweisbec () le 25/02/2010 à 06:57. (lien). Évalué à 7.

Dans la partie "Contrôleur IO-Block", tu fais référence à CFS comme l'ordonnanceur IO par défaut. Je pense que tu voulais parler de CFQ. CFS c'est l'ordonnanceur de tâches. CFQ est un des ordonnanceurs IO.

Enfin bon je cherche des poux hein? Je suis bien evidemment complètement fan de cette dépêche :p

[^]Re: CFS/CFQ

Posté par patrick_g (page perso, ) le 25/02/2010 à 07:05. (lien). Évalué à 4.
>>> Je pense que tu voulais parler de CFQ.

Argh tu a raison. Coquille corrigé, merci.

>>> Enfin bon je cherche des poux hein?

Pas du tout, c'est bien d'avoir des retours sur les erreurs et typos de la news...me si ça fait mal au coeur d'avoir laissé passé des bêtises en dépit de x relectures.
- [^]Re: CFS/CFQ
  
  Posté par patrick_g (page perso, ) le 25/02/2010 à 07:07. (lien). Évalué à 3.
  Tiens en voilà une illustration...
  
  s/me/même
  - [^]Re: CFS/CFQ
    
    Posté par Christophe Chailloleau-Leclerc (Jabber id, page perso, ) le 25/02/2010 à 08:21. (lien). Évalué à 3.
    Bon, dans ce cas : "ont peut penser que le déploiement".
    
    Sinon, comme d'habitude, excellente dépêche, toujours aussi étonnamment accessible pour des sujets d'une grande complexité, et avec une rédaction de qualité très agréable à lire !
    - [^]Re: CFS/CFQ
      
      Posté par patrick_g (page perso, ) le 25/02/2010 à 08:35. (lien). Évalué à 2.
      >>> Bon, dans ce cas : "ont peut penser que le déploiement"
      
      Ouch elle était vilaine celle là :-\
      Merci.
      - [^]Re: CFS/CFQ
        
        Posté par Yves Bourguignon () le 25/02/2010 à 13:51. (lien). Évalué à 1.
        Une ou deux autres :
        Dans le paragraphe sur le protocole de réseau B.A.T.M.A.N :
        Le routage pour de ces réseaux
        Ici des des paquets OGM
        
        Puis-je ajouter cette ligne sur mon CV :
        « Correcteur (syntaxique) occasionnel des dépêches de patrick_g sur linuxfr »... :)
        
        [^]Re: CFS/CFQ
        
        Posté par patrick_g (page perso, ) le 25/02/2010 à 13:57. (lien). Évalué à 2.
        Merci beaucoup, c'est corrigé.
        
        [^]Re: CFS/CFQ
        
        Posté par Nic0 (page perso, ) le 25/02/2010 à 14:34. (lien). Évalué à 1.
        Un régal à lire (en plusieurs fois)
        
        Et la petite coquille de passage,
        1er paragraphe de TCPCT:
        « alors le serveur finit par être est la victime d'un déni de service »
        
        Merci pour la dépêche.
        
        [^]Re: CFS/CFQ
        
        Posté par patrick_g (page perso, ) le 25/02/2010 à 14:48. (lien). Évalué à 2.
        Tel Sisyphe je roule mon rocher. C'est corrigé, merci.
        
        [^]Re: Autres coquilles
        
        Posté par Zarmakuizz (page perso, ) le 25/02/2010 à 16:39. (lien). Évalué à 1.
        Compactage mémoire ramzswap
        
        Une fonction de compactage de la mémoire nommée ramzswap (anciennement compcache) est entrée dans la partie -staging du noyau 2.6.33.
        L'idée derrière compcache/ramzswap est de permettre aux LiveCD ou aux petites configurations (netbooks, vieux ordinateurs, clients légers, systèmes embarqués) d'avoir une capacité mémoire artificiellement augmenté
        augmentée
        
        Le système de fichiers Reiserfs est maintenant officiellement déclaré libéré de l'infâme verrou global du noyau (BKL).
        Le français Frédéric Weisbecker a réussi a éradiquer
        à éradiquer
        
        [^]Re: Autres coquilles
        
        Posté par patrick_g (page perso, ) le 25/02/2010 à 16:59. (lien). Évalué à 7.
        Groumf. Merci.
        C'est quand même effarant cette perversité de l'Univers qui introduit ainsi des myriades des fautes dans mes dépêches innocentes.
        
        [^]Re: Autres coquilles
        
        Posté par nen () le 26/02/2010 à 05:16. (lien). Évalué à 1.
        'ce portable Lenote'
        
        Selon le lien, ça semble être 'Lemote'.
        
        [^]Re: Autres coquilles
        
        Posté par patrick_g (page perso, ) le 26/02/2010 à 07:29. (lien). Évalué à 2.
        Corrigé merci.
        
        [^]Re: Autres coquilles
        
        Posté par Dreamkey () le 26/02/2010 à 18:59. (lien). Évalué à 2.
        4 autres coquilles :
        - partie ramzswap : "On peut donc à brève échéance s'attendre à voir apparaître"
        - partie Contrôleur IO-Block : "songeait à enfermer" et "Quant aux administrateurs ils ont maintenant"
        - partie Ceph : "principale du noyau a été manquée"
        
        Maintenant je vais poser mes questions ;-)
        
        [^]Re: Autres coquilles
        
        Posté par patrick_g (page perso, ) le 27/02/2010 à 08:46. (lien). Évalué à 1.
        Hmm...sur le quant/quand je ne suis pas certain qu'il soit nécessaire de corriger : http://atilf.atilf.fr/dendien/scripts/tlfiv5/visusel.exe?11;(...)
        Pareil pour les a/à (mais je suis une quiche en grammaire donc je peux me gourer).
        
        [^]Re: Autres coquilles
        
        Posté par guppy () le 27/02/2010 à 09:21. (lien). Évalué à 3.
        Pour moi il a raison.
        
        Pour décider entre à et a, met la phrase à l'imparfait :
        "principale du noyau avait été manquée" => ça a un sens : c'est donc "a"
        "songeait avait enfermer" => pas de sens : c'est donc un "à"
        
        Pour Quand / Quant, tenter de remplacer par "En ce qui concerne"
        "Quant aux administrateurs" => En ce qui concerne les administrateurs => quant avec un t
        "Quand il va manger" => En ce qui concerne il va manger => pas de sens => quand
        
        C'est pas vraiment carré, mais ça donne de bons résultats. En tout cas, c'est comme ça que je fais. ;)
        
        [^]Re: Autres coquilles
        
        Posté par baud123 (Jabber id, page perso, ) le 27/02/2010 à 12:48. (lien). Évalué à 2.
        oui, j'avais déjà pris en compte les corrections :-)

RCU

Posté par Brice Goglin () le 25/02/2010 à 07:55. (lien). Évalué à 3.

> La technique du Read-Copy update est utilisée dans Linux afin de synchroniser
> de multiples threads pour leur permettre de lire simultanément une donnée
> sans poser dessus un verrou coûteux.

Mouaif... Tant qu'on ne fait que lire une donnée, y a jamais besoin de verrou, c'est quand quelqu'un la modifie qu'on est embetté.

L'intérêt de RCU, c'est que ces multiples tâches peuvent lire une donnée alors que d'autres sont en train de la modifier. La modification est faite de manière à ce que les lecteurs aient toujours une vue cohérente de la donnée (typiquement une liste doublement chaînée) et qu'on ne libère pas la mémoire alors qu'ils y accèdent.

Obtenir un boulot via LKML

Posté par Brice Goglin () le 25/02/2010 à 08:09. (lien). Évalué à 4.

Que Frédéric Weisbecker se rassure, on recoit assez facilement des offres d'emploi quand a une activité régulière sur LKML et en terme de patchs. Y a au moins Google et VMWare qui s'intéressent à ce genre de contributeurs...

L'ordonnanceur stabilisé et mur ?

Posté par Brice Goglin () le 25/02/2010 à 08:17. (lien). Évalué à 9.

> Essayez de travailler sur l'ordonnanceur de tâches, par exemple. Je pense que c'est
> difficile parce que CFS (l'ordonnanceur actuel) a été mergé il y a quelques cycles déjà.
> C'est un gros morceau qui a eu le temps de se stabiliser et de mûrir.

Ahah la bonne blague ! L'ordonnanceur change en profondeur toutes les 3 ou 4 releases. C'est le parfait exemple du sous-système qui aurait dû être stable (on pouvait l'espérer après tout le flan qu'on a fait autour du O(1)-scheduler quand 2.6.0 est sorti), et pourtant non, il continue à être complètement changé régulièrement, bien avant d'être stable ou mûr.

Un vrai exemple de sous-système stable et mûr, c'est la pile réseau (au moins la partie basse qui touche aux drivers Ethernet, je sais pas pour les protocoles au dessus). Les drivers Ethernet ont eu très peu de modifications majeures depuis des lustres (je sais de quoi je parle...).

[^]Re: L'ordonnanceur stabilisé et mur ?

Posté par Brice Goglin () le 25/02/2010 à 08:24. (lien). Évalué à 3.
Je vois que Frédéric n'a commencé à contribuer que dans 2.6.28, il n'a peut-être pas assez de recul sur tout ça...
- [^]Re: L'ordonnanceur stabilisé et mur ?
  
  Posté par fweisbec () le 25/02/2010 à 08:47. (lien). Évalué à 4.
  il n'a peut-être pas assez de recul sur tout ça...
  
  Pas faux...

[^]Re: L'ordonnanceur stabilisé et mur ?

Posté par fweisbec () le 25/02/2010 à 08:39. (lien). Évalué à 9.
C'est vrai, l'ordonnanceur est peut être pas le meilleur exemple pour ça. Je l'évoque juste parce que CFS a déjà eu le temps de murir et de se stabiliser un peu. Certes c'est encore loin d'être du code mammouth. Mais c'est pas non plus comme s'il venait à peine d'arriver, avec des bugs béants et de la viande fraiche :-)

Super article

Posté par Edouard (page perso, ) le 25/02/2010 à 08:48. (lien). Évalué à 3.

Super article, à la fois technique et accessible. Merci

--
(pub): baggle, le boggle libre sur internet

[^]Re: Super article

Posté par tankey () le 25/02/2010 à 12:59. (lien). Évalué à 3.
C'est un classique, le remerciement pour la dépêche noyau.
Classiquement, donc, merci Patrick de publier cela sur linuxfr, en fait, merci à toute l'équipe de linuxfr, plus précisement. Remarquable travail de suivi, de vérification, et d'écriture qui demande à n'en pas douter une belle somme de temps. Celle ci apporte un éclairage essentiel sur de nombreux points. Elles rendent passionnante la vie du noyau même aux non-initiés, et ceci n'est pas un compliment mal placé, mais sincèrement, j'aimerai beaucoup lire ces articles dans Science&Vie, pour de multiples raisons. Et d'une manière plus générale, j'aimerai beaucoup avoir plus d'articles de cette qualité (de cette construction (technique-humains-projet) pour de nombreux autres sujets.

ps : à quant le quizz d'après dépêche noyau ?! :p
- [^]Re: Super article
  
  Posté par ianux (Jabber id, page perso, ) le 27/02/2010 à 02:55. (lien). Évalué à 4.
  j'aimerai beaucoup lire ces articles dans Science&Vie
  Passe à Pour La Science, ça sera un poil plus velu...
  
  --
  radio ianux
  - [^]Re: Super article
    
    Posté par tankey () le 27/02/2010 à 12:05. (lien). Évalué à 4.
    Je connais et n'aime pas trop, ça me laisse une impression de "souvent des publications non validées" (les pages "en bref" de Science&Vie ou souvent ou peux deviner des annonces grandiloquantes pour appel financement, dans "Pour la Science, ils font tout un dossier), même si effectivement les articles sont plus velus et plus complets, lla vulgarisation y est de moins bonne qualité. Or n'étant pas non plus "Science", la vulgarisation reste un élément censé être essentiel dans "Pour La Science", et est délaissée au profit d'une fausse impression de "velu". Je suis un peu dur lol, mais vraiment je trouve Science&Vie supérieur Mais ouhai, je matte systématiquement les deux à la librairie, mais n'emporte "Pour La Science" que lorsqu'il y a des articles sur "l'astronomie" lol et le quantique relol.
    
    Une revue a conseillé aux djeuns (et moins puisque je la lis également parfois) c'est la nouvelle revue "Tangeante" (moins de 2 ans il me semble). Souvent mélange de philosophie, mathématique et informatique. J'ai entre autre en tête un super numéro avec plein d'exemple en Python :) Bref, "tangeante", un joli brin d'une guirlande éternelle.
    
    ps : Alors, cet élément dont on nomme temps la mesure de sa différence (de son interaction) avec la gravitation, ils vont le trouver ou pas ? Celui après le boson scalaire, là ... okok je ->
    - [^]Re: Super article
      
      Posté par baud123 (Jabber id, page perso, ) le 27/02/2010 à 13:00. (lien). Évalué à 4.
      La revue tangente a plus de 20 ans : cf. http://tangente.poleditions.com/
      http://tangente.poleditions.com/numeros/thumb_84_TG118.jpg
      
      idem pour http://www.quadrature-journal.org/ cf. Quadrature_(revue).
      
      Et je confirme, science et vie a perdu toute crédibilité, pour moi, depuis l'affaire Benveniste avec la mémoire de l'eau puis ensuite Fleischmann-Pons avec la fusion froide, un traitement trop politique plutôt que factuel... Sciences et Avenir est largement au-dessus en terme de vulgarisation (et plus diversifiée àmha, touchant à la paléontologie, l'archéologie et pas mal de sciences molles) et Pour la Science est sympathique pour de longs articles dans les sciences dures. Pour l'astronomie, Ciel et Espace vaut le coup (et le coût) même si je ne l'achète qu'épisodiquement. Sinon, il reste La Recherche (dont le niveau a pas mal baissé depuis le sièce dernier àmha), même si leur attrait apparent pour la biologie ou les sciences du cerveau me passionnent moins...
      - [^]Re: Super article
        
        Posté par tankey () le 27/02/2010 à 13:29. (lien). Évalué à 3.
        Arf j'ai confondu "Pour La Science" avec "La Recherche" je crois bien.
        Tangeante à eu une re-numérotation ? j'étais persuadé avoir des niméros pas plus que xx, mais bon j'en ai que deux ou trois.
        Merci de la correcftion.
        
        pour revenir à Linux, voici une couverture d'un magazine qui n'a pas 20 ans...forrcément : http://lh3.ggpht.com/_kacbVFEVtH8/S4kOwilvJxI/AAAAAAAAAyE/5z(...) ;-)
      - [^]Re: Super article
        
        Posté par Albert_ () le 02/03/2010 à 10:54. (lien). Évalué à 2.
        Et je confirme, science et vie a perdu toute crédibilité, pour moi, depuis l'affaire Benveniste avec la mémoire de l'eau puis ensuite Fleischmann-Pons avec la fusion froide
        
        Donc tu consideres que Nature est un journal non credible? Parceque c'est deux "decouverte" on fait la une de ce journal aussi. Je ne dis pas que c'est normal que cela soit publie et encore moins envoye a une revue mais bon la on va entrer dans un autre debat.
        
        [^]Re: Super article
        
        Posté par lasher () le 02/03/2010 à 20:07. (lien). Évalué à 2.
        Tu as tout à fait raison, à une petite différence près: « Nature » avait écrit une sorte d'avertissement qui précédait l'article pour dire que c'était une recherche très controversée, et que tout le monde dans la rédaction n'était pas convaincue de la véracité de celle-ci.
        
        [^]Re: Super article
        
        Posté par Albert_ () le 02/03/2010 à 20:58. (lien). Évalué à 3.
        Je te conseil la lecture des PHD comics sur le sujet ou Science se moque de Nature et de leur gaffe (generalement en couverture qui plus est).
        
        Par contre j'ai pas dis mais je suis assez d'accord avec Science et vie qui est le Voici de la science.
        
        [^]Re: Super article
        
        Posté par baud123 (Jabber id, page perso, ) le 06/03/2010 à 01:22. (lien). Évalué à 2.
        Albert_< je te redonne la fin de la citation que tu as omise : un traitement trop politique plutôt que factuel
        
        [^]Re: Super article
        
        Posté par Albert_ () le 06/03/2010 à 06:56. (lien). Évalué à 2.
        Si ces deux decouvertes n'avaient pas ete en couverture de Nature tu penses vraiment que Science et Vie en aurait parle?
        
        [^]Re: Super article
        
        Posté par baud123 (Jabber id, page perso, ) le 06/03/2010 à 07:23. (lien). Évalué à 2.
        quelles découvertes ? tu serais pas le premier benveniste venu toi ? vala, c'est de ça dont je parle, sans rapport avec ta question ;-)
        
        [^]Re: Super article
        
        Posté par Albert_ () le 08/03/2010 à 09:36. (lien). Évalué à 2.
        j'ai oublie les guillemets cette fois ci :)

Questions aux lecteurs

Posté par patrick_g (page perso, ) le 25/02/2010 à 09:00. (lien). Évalué à 10.

Lors de la phase de relecture il y a eu des discussions sur la mailing-list modéros en raison de la longueur inhabituelle de cette news. La question qui se posait c'était de savoir si une borne n'avait pas été franchie.
Comme l'a écrit un des participants à la discussion en découvrant la taille de la dépêche: "Le problème est que ça coupe tout simplement l'envie de lire".

Si je regarde la longueur des dépêches noyau j'obtiens ceci (en me basant sur ce qu'indique la ligne Linuxfr juste en dessous des liens de la news) :

2.6.24 => 33 614 caractères
2.6.25 => 34 938 caractères
2.6.26 => 27 383 caractères
2.6.27 => 45 996 caractères
2.6.28 => 36 479 caractères
2.6.29 => 37 616 caractères
2.6.30 => 54 211 caractères
2.6.31 => 68 189 caractères
2.6.32 => 73 197 caractères
2.6.33 => 100 088 caractères

On constate donc que jusqu'au 2.6.29 ça oscille gentiment entre 35k et 45k caractères. L'inflation réelle commence avec le 2.6.30 et n'a fait qu'augmenter depuis (même si la taille vraiment inhabituelle de la news 2.6.33 s'explique aussi par l'inclusion de l'interview de Frédéric).
Donc des questions se posent auxquelles j'aimerais, gentil lecteur, que tu répondes:

1) Est-ce que c'est trop long à lire ou pas ?
2) Si oui qu'est-ce qu'il faut enlever ?
3) Z'avez d'autres suggestions ?

[^]Re: Questions aux lecteurs

Posté par pasBill pasGates () le 25/02/2010 à 09:10. (lien). Évalué à 3.
1) Oui quand meme un peu
2) A mon avis la partie sur les RC est inutile, et tu pourrais raccourcir un peu la prose sur chaque feature en gardant a peu pres le meme contenu, au total ca raccourcirait pas mal
3) Non
- [+] [^]Re: Questions aux lecteurs
  
  Posté par Brice Goglin () le 25/02/2010 à 09:13. (lien). Évalué à -1.
  Oui c'est trop long. Il faut virer la partie sur les RC et juste eventuellement garder quelques phrases importantes s'il y en a.
  
  Pour le reste, essayer de résumer un peu sans aller trop dans les détails, quitte à mettre plus de liens pour les gens qui veulent des détails techniques.
  - [+] [^]Re: Questions aux lecteurs
    
    Posté par Brice Goglin () le 25/02/2010 à 09:28. (lien). Évalué à -1.
    Pour préciser un peu pourquoi les RC servent à rien: Les annonces des RC contiennent essentiellement des features importantes (que Patrick va de toute façon détailler plus bas), et des stats sur où sont les changement dans cette RC (si ces stats sont vraiment pertinentes, autant les synthétiser sur le release cycle complet comme LWN le fait, pas besoin de stats pour chaque RC). Bref, il reste quelques broutilles, pas besoin de 200 lignes :)
  - [^]Re: Questions aux lecteurs
    
    Posté par guillaume Dorchies () le 25/02/2010 à 11:45. (lien). Évalué à 10.
    Ha non pas les RC ; j'adore la traduction des messages de linus cela met en jambes pour lire la suite
    - [^]Re: Questions aux lecteurs
      
      Posté par phoenix (Jabber id, page perso, ) le 25/02/2010 à 12:59. (lien). Évalué à 10.
      Pareil c'est l'une des parties que je préfère.
      
      --
      Ulrich
      Java pas bien, Java l'dire à ma mère.
      - [^]AOMTP
        
        Posté par Nicolas (page perso, ) le 26/02/2010 à 12:14. (lien). Évalué à 0.
        an other me too post
        aka +1
        
        [^]Re: AOMTP
        
        Posté par skippy () le 26/02/2010 à 13:56. (lien). Évalué à 6.
        Oui, cette partie est amusante à lire. Et notamment pour les personnes n'ayant aucune compétence technique en la matière, et cherchant simplement à avoir une idée stratosphérique de comment est structuré le développement de ce qui marche dans leurs machines.
        
        Seul point : Oui l'interview aurait pu faire l'objet d'une dépêche séparée, mais sinon, il est urgent de ne surtout rien changer !!!
        
        Signé:Un non-développeur curieux

[^]Re: Questions aux lecteurs

Posté par Frédéric Heulin () le 25/02/2010 à 09:14. (lien). Évalué à 3.
Il y a un menu, c'est fait pour c,a, on va lire ce qui nous inte'resse.
Trois de'pe`ches en une aussi puisqu'on a les nouveaute's, l'entretien et l'apre`s.
La seule chose que c,a semble un peu ralentir, ce sont les commentaires enflamme's
car apre`s une bonne et saine lecture, une petite sieste … euh un retour au travail, s'impose !
Donc a` part pour les commentaires, oǜ la se'paration en 2/3 de'pe`ches lie'es les unes
aux autres permettraient peut-e^tre d'avoir plus de retours/questions,
c,a ne semble pas ge^nant.
- [^]Re: Questions aux lecteurs
  
  Posté par Frédéric Heulin () le 25/02/2010 à 09:17. (lien). Évalué à 7.
  Il y a un menu, c'est fait pour ça, on va lire ce qui nous intéresse.
  Trois dépêches en une aussi puisqu'on a les nouveautés, l'entretien et l'après.
  La seule chose que ça semble un peu ralentir, ce sont les commentaires enflammés
  car après une bonne et saine lecture, une petite sieste … euh un retour au travail, s'impose !
  Donc à part pour les commentaires, oǜ la séparation en 2/3 dépêches liées les unes
  aux autres permettraient peut-être d'avoir plus de retours/questions,
  ça ne semble pas gênant.
  
  -- ras le bol du résultat différent de la prévisualisation … pas moyen de poster depuis w3m ! grrr…
  - [^]Re: Questions aux lecteurs
    
    Posté par alexmic () le 25/02/2010 à 10:31. (lien). Évalué à 5.
    oǜ la séparation en 2/3 dépêches liées les unes
    
    ǜ ??
    
    La vache ! C'est quelle disposition clavier qui permet d'acceder à ce caractère ?
    
    ... à moinsse que ce ne soit un combo de touches mortes
    - [^]Re: Questions aux lecteurs
      
      Posté par Olivier () le 25/02/2010 à 11:07. (lien). Évalué à 2.
      « ǜ ??
      La vache ! C'est quelle disposition clavier qui permet d'acceder à ce caractère ? »
      
      Heu… en bépo, entre autre…
      
      --
      Message tapé sur un clavier bépo : http://www.clavier-dvorak.org
      - [^]Re: Questions aux lecteurs
        
        Posté par campagnard () le 25/02/2010 à 15:29. (lien). Évalué à 2.
        une autre question : y'a-t-il réellement une langue qui utilise ce caractère ?
        
        [^]Re: Questions aux lecteurs
        
        Posté par jm trivial (page perso, ) le 25/02/2010 à 15:34. (lien). Évalué à 2.
        Il semble que ce soit utilisé dans les retranscriptions de mandarin :
        http://www.fileformat.info/info/unicode/char/01dc/index.htm
        Pinyin fourth tone
        http://fr.wikipedia.org/wiki/Hanyu_pinyin
        
        [^]Re: Questions aux lecteurs
        
        Posté par Ummon () le 25/02/2010 à 15:45. (lien). Évalué à 10.
        F͖͖͓ͪͣ̑͛̿ͮ̚r̋̇͞͏̡̦̮ą̥̖̬̩͕̅ͣͥ͗̐͗ͬ̉n͕̫͉̭̔͑͋ͫͭͨͥc̷̈́̔̊̀ͣͣ҉͙̼͜h̴̻͖̭̺͔̦̓̓̎ͧ̂e̴͉̘͔͕̥͈̳̞̐̾͑̓̀͟m̨͖̤̗ͥ̈́͆́͞e͓̗͍̠̥ͪ͒ͨͫ̊̎ͯͩ̀n̡̞̳ͭͬ̋̏̾̏̍͜͢t̶̘͉̮̬͉̼̹ͫ̓̀ͯ̐ͨ̀,̶͇̺ͤͬ̾̊ ̥͋ͥ̅͊̀j̠̟͈̝̪͍̳ͧ͂́̑͟'̵͉͈̳͊̃ͤ̇ͯ̕ȅ̳̞̬̠̪̠͕ͫͥ̃ͣ͋̇͘͜͠ņ͉̣̭̎̀̋ͧ̅̄̔͟͠ ̪̩̈̔̊́̀s̡͈͔̅ͯ̒̆ͧͩ̏́̚͜a̸̴̗̯̝̗͚̙̭͊̌ͣͅi̥͍͓̜̰̗̺̒͂͌̂͑ͅs̶̡̫̟͔͉̣̖͈̠̭ͤ̍͌̑͋̅̈ͩ ͍͓͇̘̌͌r̡̖̰̯̣̗̉̈́̾̓ͤ̾̇̈͞i̓̔͒̑ͣ͏̛̫̹̫͖̟̞̯ͅe͕̜̣̩̳͖͙͐̒̌͗ͨ͘͡ͅn̢̯̭ͣ̃̿͗̂͌ͧ̾͞ ̠͎͔̖̜̙̭̙ͪ͜d͖̻̐͋̐̂ư̍ͦͦ̀ͫ̂҉̗͔̼͍̞͖͉͉ͅ ̧͉͚̭͇̮͚̒ͫͨ͗̾̍̋ͅt̨͚̼ͩ̋̇̆̂̂́́ǫ̪̲͈̜ͥ̓͗ͮ̄́ͫ̀̚ų̶̘͙ͨͧ̓ͮͬ̕t̨͖̗̙̫͉̩̩͊͆̍.̟̙̱͎͉̖̙̹̯͐ͧͨ̓ͭ
        
        [^]Re: Questions aux lecteurs
        
        Posté par Troy McClure (page perso, ) le 25/02/2010 à 17:44. (lien). Évalué à 10.
        un jour les membres du consortium unicode devront répondre de leurs actes et expliquer pourquoi ils ont jugé important d'introduire des milliards de caractères à la con
        
        [^]Re: Questions aux lecteurs
        
        Posté par tiot (Jabber id, page perso, ) le 25/02/2010 à 18:21. (lien). Évalué à 3.
        Dans l'exemple au dessus ce sont juste des caractères latins avec des diacritiques (´`^¨¸ sont utilisés en Français, mais il y a aussi °~ˇ¯˙˝˙̛̣ ˛…).
        
        [^]Re: Questions aux lecteurs
        
        Posté par zerchauve () le 25/02/2010 à 18:35. (lien). Évalué à 2.
        des caractères avec PLUSIEURS diacritiques ????
        
        --
        -- Le voilà qui s'en va, un des prototypes personnels de Dieu... Trop bizarre pour vivre, trop unique pour mourir
        
        [^]Re: Questions aux lecteurs
        
        Posté par Tanguy Ortolo (Jabber id, page perso, ) le 25/02/2010 à 19:58. (lien). Évalué à 4.
        Il y a en Unicode des caractères spéciaux qui sont des modificateurs pour le caractère suivant.
        
        --
        Tanguy Ortolo
        Connard amer d'or 2008, décerné par J-A Ad'A, connard amer des origines
        
        [^]Re: Questions aux lecteurs
        
        Posté par zerchauve () le 26/02/2010 à 22:08. (lien). Évalué à 1.
        merci pour cette réponse, je comprends un peu mieux :)
        
        --
        -- Le voilà qui s'en va, un des prototypes personnels de Dieu... Trop bizarre pour vivre, trop unique pour mourir
        
        [^]Re: Questions aux lecteurs
        
        Posté par tiot (Jabber id, page perso, ) le 26/02/2010 à 23:36. (lien). Évalué à 4.
        Dans la vraie vie il y a des caractères latins avec plusieurs diacritiques. Comme par exemple le vietamien : Quốc ngữ. Il y en a aussi pas mal dans l'écriture phonétique.
        
        [^]Re: Questions aux lecteurs
        
        Posté par windu.2b (Jabber id, page perso, ) le 01/03/2010 à 10:33. (lien). Évalué à 2.
        Toi, t'as jamais lu du hongrois...
    - [^]Re: Questions aux lecteurs
      
      Posté par Zarmakuizz (page perso, ) le 25/02/2010 à 16:46. (lien). Évalué à 1.
      Presque : sur un clavier France Autre, latin 9, il suffit de faire tréma mort + ù, c'est-à-dire Maj ^ mort + ù.

[^]Re: Questions aux lecteurs

Posté par FantastIX () le 25/02/2010 à 09:18. (lien). Évalué à 10.
Celui à qui la longueur de la dépêche coupe l'envie de lire n'est peut-être tout simplement pas le lecteur qu'il faut, sans vouloir être brutal. Une telle énergie mise dans une dépêche comme celle-ci mérite qu'on y passe du temps, ne fût-ce que pour apprécier celui que les auteurs ont passé à l'écrire. Et puis, quelle que soit la longueur d'un ouvrage littéraire, il y aura toujours des lecteurs pour apprécier.

Enlever? Rien!
Suggestion(s)? Continuer comme ça, la littérature technique compréhensible est ce que l'on peut rêver de mieux pour des profanes du noyau comme moi.

Maintenant, je vais commencer à la lire à fond. :D
- [+] [^]Re: Questions aux lecteurs
  
  Posté par Brice Goglin () le 25/02/2010 à 09:38. (lien). Évalué à -1.
  > Une telle énergie mise dans une dépêche comme celle-ci mérite qu'on y passe du
  > temps, ne fût-ce que pour apprécier celui que les auteurs ont passé à l'écrire.
  
  Je vois pas en quoi ça empêche Patrick de changer ce qu'il mettra dans sa prochaine dépêche s'il juge qu'il y a du temps de traduction qui est peu utile.
  
  > Et puis, quelle que soit la longueur d'un ouvrage littéraire, il y aura toujours
  > des lecteurs pour apprécier.
  
  Avec des raisonnements comme ça, tu vas finir par demander à Patrick de
  traduire le git log complet à chaque release (194k lignes dans 2.6.33).
  - [^]Re: Questions aux lecteurs
    
    Posté par FantastIX () le 25/02/2010 à 10:31. (lien). Évalué à 10.
    Avec des raisonnements comme ça, tu vas finir par demander à Patrick de
    traduire le git log complet à chaque release (194k lignes dans 2.6.33).
    
    Avec un raisonnement comme ça, je signale simplement à Patrick qu'il n'a aucun souci à se faire concernant la longueur de sa dépêche, qu'il y aura toujours des lecteurs pour apprécier son contenu, quelle que soit la longueur qu'il aura lui-même déterminée.
    
    Donc, plutôt que de demander à Patrick qu'il change quoi que ce soit, j'ai subtilement exprimé le souhait qu'il continue comme il l'a toujours fait: comme il le sent. En d'autres termes: je fais entièrement confiance en son jugement (sans oublier celui des modérateurs) pour écrire des dépêches de qualité.
    
    Je ne lui demande rien, en fait. J'admire juste son travail. Je m'étonne que tu ne l'aies pas perçu ainsi.
    - [+] [^]Re: Questions aux lecteurs
      
      Posté par Brice Goglin () le 25/02/2010 à 10:37. (lien). Évalué à -1.
      > Je ne lui demande rien, en fait. J'admire juste son travail.
      > Je m'étonne que tu ne l'aies pas perçu ainsi.
      
      Bah fallait dire ça au lieu de faire des envolées lyrique sur l'existence d'un lecteur quelle que soit la longueur d'un ouvrage...
      - [^]Re: Questions aux lecteurs
        
        Posté par FantastIX () le 25/02/2010 à 11:15. (lien). Évalué à 8.
        Mon style, c'est ça, désolé :D .
    - [^]Re: Questions aux lecteurs
      
      Posté par guillaume Dorchies () le 25/02/2010 à 11:48. (lien). Évalué à 10.
      Entièrement d'accord
      
      Le sujet est complexe, il ne pas être résumé en deux trois lignes. L'effort d'analyse et de rédaction mérite l'effort de lecture

[^]Re: Questions aux lecteurs

Posté par Mimoza () le 25/02/2010 à 09:22. (lien). Évalué à 3.
1) Oui surtout quand on est au taff et que le boss est pas loin
2) L'interview aurai pu être dans une dépèche à part
3) Pourquoi pas un découpage de la dépèche en plusieurs, cela permettrait de lire sans être découragé par la longueur ...
- [^]Re: Questions aux lecteurs
  
  Posté par Nicolas Boulay () le 25/02/2010 à 10:30. (lien). Évalué à 10.
  Enlever de l'info:surtout pas.
  
  Mais je pense aussi que L'interview pourrait être dans une news séparé. Le sujet n'est pas exactement le même.
  
  --
  "Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
- [^]Re: Questions aux lecteurs
  
  Posté par novexz () le 25/02/2010 à 10:46. (lien). Évalué à 5.
  1) Non ce n'est pas trop long et la partie sur les RC est intéressante et donne un côté plus vivant à l'article.
  2) Par contre c'est vrai que l'interview aurai pu être dans une dépêche à part
  3) Je suis d'accord avec Mimoza sur l'idée de peut-être découper la dépêche, si elle parait trop longue.
- [^]Re: Questions aux lecteurs
  
  Posté par jon207 (Jabber id, ) le 28/02/2010 à 02:54. (lien). Évalué à 5.
  1) Oui surtout quand on est au taff et que le boss est pas loin
  C'est de la veille technologique.
  
  --
  "La liberté ne peut être que toute la liberté ; un morceau de liberté n’est pas la liberté." -- Max Stirner

[^]Re: Questions aux lecteurs

Posté par Vivien MOREAU (Jabber id, ) le 25/02/2010 à 09:30. (lien). Évalué à 4.
Non, je ne trouve pas ça trop long. C'est même très bien.

Par contre, sauf si j'ai raté le lien-qui-va-bien, c'est ensuite la galère quand on revient plus tard lire les nouveaux commentaires : on ne peut pas y accéder directement, il faut d'abord sauter toute la dépêche. Mais c'est un éventuel problème du site, pas du tout de tes textes.
- [^]Re: Questions aux lecteurs
  
  Posté par patrick_g (page perso, ) le 25/02/2010 à 09:42. (lien). Évalué à 4.
  >>> Par contre, sauf si j'ai raté le lien-qui-va-bien, c'est ensuite la galère quand on revient plus tard lire les nouveaux commentaires : on ne peut pas y accéder directement, il faut d'abord sauter toute la dépêche. Mais c'est un éventuel problème du site, pas du tout de tes textes.
  
  Si j'ai bien compris ce que tu veux dire il te suffit d'activer la barre d'outils du site (tu cliques d'abord sur ton lien "Modifier vos préférences" et ensuite tu coches la barre d'outil).
  Ensuite tu pourra cliquer sur les petites flèches en bas à droite de l'écran pour naviguer dans les nouveaux commentaires.
  Regarde cette copie d'écran : http://www.flickr.com/photos/11384633@N00/4387089214/sizes/o(...)
  - [^]Re: Questions aux lecteurs
    
    Posté par Vivien MOREAU (Jabber id, ) le 25/02/2010 à 10:59. (lien). Évalué à 2.
    Merci, je savais bien que je devais avoir raté quelque chose ! :-)
    
    Je l'avais désactivée à une époque pour une raison qui m'échappe...
    
    PS: c'est quand même dingue les gens qui moinssent pour des raisons si étranges.
    - [^]Re: Questions aux lecteurs
      
      Posté par Xavier Claude () le 25/02/2010 à 19:17. (lien). Évalué à 6.
      Je l'avais désactivée à une époque pour une raison qui m'échappe...
      
      Il y avait un bug avec firefox et les thèmes qui cachent automatiquement la barre: le défilement était très consommateur de ressource.
      
      --
      Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. (R. Devos)
  - [^]Re: Questions aux lecteurs
    
    Posté par efournie () le 25/02/2010 à 11:14. (lien). Évalué à 6.
    Ensuite tu pourra cliquer sur les petites flèches en bas à droite de l'écran pour naviguer dans les nouveaux commentaires.
    
    Voire utiliser directement les touches '<' et '>' pour naviguer au clavier parmi les nouveaux commentaires.

[^]Re: Questions aux lecteurs

Posté par snt () le 25/02/2010 à 09:46. (lien). Évalué à 10.
>"Le problème est que ça coupe tout simplement l'envie de lire"

Pas du tout ! Ceux qui n'aiment pas les détails peuvent retourner sur twitter.
Les dépêches détaillées, ca me convient très bien. Si j'ai pas le temps de tout lire, j'y reviendrai plus tard : je ne me lasse pas lire des trucs intéressants comme ça.
Merci encore.

[^]Re: Questions aux lecteurs

Posté par neologix (page perso, ) le 25/02/2010 à 09:48. (lien). Évalué à 3.
Tu as regardé si les longueurs de tes dépêches sont proportionnelles aux nombres de commits ? ;-)
- [^]Re: Questions aux lecteurs
  
  Posté par cosmocat () le 25/02/2010 à 10:19. (lien). Évalué à 6.
  Effectivemment, les articles de patrick_g sont une preuve flagrante de la taille du noyau (embonpoint diront certains surtout dans l'embarqué.)
  
  Pour amener ma pierre à l'édifice, je ne trouve pas que ce soit trop long.
  Apparement certains reprochent que la partie sur les RCs devraient être enlevées. Je pense que non car on peut facilement passer à la suite (1 ou 2 coups de page bas...)
  
  En gros, change rien sauf si c'est trop de boulot pour toi!

[^]Re: Questions aux lecteurs

Posté par pingoomax () le 25/02/2010 à 09:50. (lien). Évalué à 2.
1) Est-ce que c'est trop long à lire ou pas ?
- oui c'est long. Mais ce sont à chaque fois des articles passionnants. Bilan, je les lis en plusieurs fois. Du coup j'apprécie les différentes sections qui permettre de s'arrêter facilement dans la lecture de la news.

2) Si oui qu'est-ce qu'il faut enlever ?
- je suis assez d'accord pour dire que la partie RC n'est pas forcement très utile (à mon sens). Si la chronologie a vraiment de l'importance, par ex montrer la difficulté d'intégration d'un projet, ca peut être décrite dans la section relative à ce sujet.

3) Z'avez d'autres suggestions ?
- Si l'idée de découper la news en plusieurs news vous venait à l'esprit, je pense que c'est une mauvaise idée.
- [^]Re: Questions aux lecteurs
  
  Posté par grid () le 25/02/2010 à 18:26. (lien). Évalué à 3.
  la partie RC, c'est ce que je préfères. Ca donne de la vie à ce qui ne serait qu'un bête changelog.
  
  Maintenant, l'interview, ca aurait dû être à part. Ca enlève facile 20 000 caractères.

[^]Re: Questions aux lecteurs

Posté par Macsim (Jabber id, page perso, ) le 25/02/2010 à 10:02. (lien). Évalué à 10.
Déjà merci pour le temps que tu passes (ainsi que les correcteurs) pour nous syntètiser toutes ces informations.

1) Est-ce que c'est trop long à lire ou pas ?

Quand c'est du Posté par patrick_g c'est jamais assez long, quand tes billets tombent dans mes flux j'ai pas toujours le temps de lire exactement ce que tu as écris je me garde ça pour le soir, donc non ce n'est a mon avis pas trop long, il faut juste prendre le temps de le lire.

2) Si oui qu'est-ce qu'il faut enlever ?

Surtout ne change rien.

3) Z'avez d'autres suggestions ?

Non.

[^]Re: Questions aux lecteurs

Posté par JulienRF () le 25/02/2010 à 10:04. (lien). Évalué à 4.
1) Non ce n’est pas trop long, j’apprécie vraiment la façon dont tu arrives à parler de toutes ces technologies en introduisant juste le nécessaire pour qu’on comprenne de quoi il s’agit, et avec des liens vers Wikipedia ou autre si on veut plus de détails.

2) Peut-être qu’effectivement les détails sur les RC pourraient être omis… Ils ne sont pas très intéressants techniquement mais ils sont marrants.

3) Là en l’occurrence l’interview aurait pu faire l’objet d’un article séparé.

[^]Re: Questions aux lecteurs

Posté par fyxx () le 25/02/2010 à 10:13. (lien). Évalué à 7.
1) oui. Mais vu que le kernel est quand meme assez important dans un systeme, je prefere du long qui me documente bien, que du court qui m'avancera pas. D'autre part, y'a pas une release tous les jours. Donc long, mais logiquement long. Faut garder cette longueur (presque, cf 2)

2) L'interview devrait etre dans une autre depeche, et la depeche d'interview devrait etre mentioné dans les note de pieds de pages de la depeche noyau.

3)oui, surtout ne vous arretez pas de faire cette depeche, elle est interessante et suffisament vulgarisée pour qu'un admin systeme la comprenne alors qu'il est pas developpeur.

--
Blop

[^]Re: Questions aux lecteurs

Posté par Erus_Iluvatar () le 25/02/2010 à 10:21. (lien). Évalué à 7.
1) Si on a une demi-heure (voire une heure) devant soi, c'est parfait
2) Tout est nickel dans la news, mais séparer l'interview l'eût peut-être rendu plus digeste
3) Continue comme ça, je me régale.
- [^]Re: Questions aux lecteurs
  
  Posté par nknico (Jabber id, ) le 25/02/2010 à 10:47. (lien). Évalué à 3.
  Moi non plus, je ne trouve pas ça long du tout.
  
  Lire ça en buvant un (ou deux cette fois, à cause de l'interview) café reste tout à fait plaisant.
  - [^]Re: Questions aux lecteurs
    
    Posté par Erus_Iluvatar () le 25/02/2010 à 11:31. (lien). Évalué à 8.
    Je rajoute que le passage sur les RC est croustillant, et ce serait dommage de l'ôter.

[^]Re: Questions aux lecteurs

Posté par shal () le 25/02/2010 à 10:47. (lien). Évalué à 7.
Pour information, j'ai mis une grosse heure à lire l'intégralité.

1) c'est certes long à lire mais le ratio temps_passé/chose_apprises est très bon . Donc tant que ce ratio reste bon, qu'importe la longueur.

2) l'interview est intéressant mais pas directement lié au 2.6.33 donc aurait du être mis a part.

Contrairement à d'autres, j'aime particulièrement le passage sur les RC. On apprends plus sur comment fonctionne les développeurs entre eux et l'écosystème associé. Le reste est consacré a comment marche le noyau.

3) non

Merci pour ton travail.

[+] [^]Re: Questions aux lecteurs

Posté par phocean (page perso, ) le 25/02/2010 à 10:54. (lien). Évalué à -4.
Oui je pense que bien des passages sont trop longs, il suffirait de mettre des liens pertinents pour ceux qui veulent approfondir.
Là perso je viens de passer presque toute la matinée à lire l'article, je ne pourrais pas me permettre tout ce temps à chaque fois.

--
JC

[^]Re: Questions aux lecteurs

Posté par Olivier () le 25/02/2010 à 11:13. (lien). Évalué à 8.
1) oui, c’est long, mais comme déjà dit, il y a un menu pour naviguer, pas de problème.
2) comme je ne connais pour ainsi dire rien au dev… mais que je lis tout pour la poésie et parce que j’ai quand-même l’impression de comprendre tant c’est bien expliqué, je ne vois rien à enlever. Et surtout pas les frasques de L. Torvald du cycle de RC. Ça rend l’image du développement du noyau vivante et « humaine ». Ne rien changer, surtout.
3) Je trouverais dommage de séparer les choses en plusieurs dépêches. Qui n’aurait pas le temps de tout lire en une fois peut y revenir. Et l’entrevue est très intéressante, je la trouve très bien là. Elle serait un peu « perdue » hors contexte.

--
Message tapé sur un clavier bépo : http://www.clavier-dvorak.org

[^]Re: Questions aux lecteurs

Posté par tuXico () le 25/02/2010 à 11:26. (lien). Évalué à 3.
1) Ou pas. J'estime la longueur de la page et soit je lis quand j'ai le temps soit je pioche des morceaux et je finis plus tard, voire même je me fais tout d'un trait comme ça la journée est finie, je peux retourner au pieu :-D
Plus sérieusement, la longueur ne me gêne pas
3) Nan, juste de ne pas séparer l'interview, ça dynamise un peu le style (par la discussion) :)

--
La République (C) garantit que, pour le lièvre comme pour la tortue, la ligne de départ est la même.

[^]Re: Questions aux lecteurs

Posté par moi1392 () le 25/02/2010 à 11:38. (lien). Évalué à 3.
personnellement, je lis plus attentivement les parties qui m'intéressent plus et je survole le reste. en gros je dirais que j'ai lu les 2/3 de l'article et que j'en ai survolé 1/3 (hors interview)
La longueur en elle même ne me dérange pas, surtout que pour d'autres lecteurs, les parties intéressantes ne sont pas les mêmes, donc je pense que tout l'article à sa place ici.

Ensuite, pour l'interview, je l'ai lu et appréciée, mais je pense qu'elle aurait plus eu sa place dans une autre dépêche.

voilà, c'était mes retours et suggestions à deux balles ;)

[^]Re: Questions aux lecteurs

Posté par Benoît Bâlon (Jabber id, page perso, ) le 25/02/2010 à 11:40. (lien). Évalué à 3.

1) Est-ce que c'est trop long à lire ou pas ?
2) Si oui qu'est-ce qu'il faut enlever ?
3) Z'avez d'autres suggestions ?

Oui c'est long à lire, en particulier quand on ne comprend pas tout instantanément... De là à trouver l'article trop long, alors que tes contributions sur DLFP ont depuis longtemps trouvé un lectorat passionné et reconnaissant, personnellement je ne partage pas cet avis. En outre, je pense qu'il faut relativiser la longueur particulière de cet article-ci, puisqu'il intègre un interview finalement assez conséquent (plus de 20 000 caractères). Cet interview aurait éventuellement pu faire l'objet d'un second article, pour ne pas alourdir celui-ci, voilà mon seul constat.

[^]Re: Questions aux lecteurs

Posté par jyes (Jabber id, page perso, ) le 25/02/2010 à 11:51. (lien). Évalué à 6.
Je me joins aux nombreuses autres réponses.

1) Non, ce n'est pas trop long. C'est trop long pour une dépêche à cause de l'interview (que je n'ai pas encore lue) mais la quantité d'information présente justifie vraiment la longueur de la partie dépêche. De plus, comme d'autres ici, j'apprécie particulièrement la partie sur les RC et je trouverais dommage de s'en passer. Elle permet de bien situer le contexte avant d'attaquer la partie technique parfois difficile à comprendre pour un béotien comme moi.

2) Rien à enlever, mais probablement faire de l'interview une dépêche à part.

3) Pas de d'autre suggestion, seulement des félicitations. Je me disais juste que peut-être que faire des dépêches plus courtes t'économiserais un peu de travail, mais tant que tu es prêt à fournir cet effort, peu importe la longueur pour le lecteur. Je lisais les dépêches noyau de patrick_g bien avant de créer mon compte sur linuxfr et jusqu'à maintenant aucune ne m'a paru trop longue.

[^]Re: Questions aux lecteurs

Posté par guillaume Dorchies () le 25/02/2010 à 11:54. (lien). Évalué à 7.
1) NON
2) Rien du tout
3) Oui mettre un message d'alerte en entête 'Vous n'êtes plus sur TF1' et 'la dépêche ne va pas s'autodétruire' (à l'attention de tous les pressés....)

En tout cas félicitation

[^]Re: Questions aux lecteurs

Posté par WhiteCat () le 25/02/2010 à 12:07. (lien). Évalué à 5.
1) Étant donné qu'il y a avait l'interview c'était plus long, mais pas beaucoup plus que d'habitude. La dépêche est bien organisée, on est pas obligé de tout lire non plus.
D'ailleurs je n'ai pas tout lu cette fois-ci, mais c'est uniquement car certaines nouveautés ne m'intéressaient pas vraiment dans le 2.6.33 contrairement à d'habitude.

2) Rien ! Les traductions des RC c'est cool, c'est le moment rigolo de la dépêche, il faut les garder !

3) Non

[^]Re: Questions aux lecteurs

Posté par Maxime GARCIA (page perso, ) le 25/02/2010 à 12:21. (lien). Évalué à 3.
Non, ne raccourcis rien, c'est très bien. Quand je vois une dépêche noyau by patrick_g, je la mets de côté et je la lis quand j'ai une demi-heure à y consacrer entièrement.

Ça donne une bonne vue du développement et de l'avancement de la chose. Je pense que même les phases RC sont importantes à expliciter comme tu le fais.

Quand on suit le dév noyau qu'à partir de ces dépêches, ça donne l'impression d'avoir bien suivi la chose.

Il faudrait peut-être penser à la mise en place d'un outils de correction de coquille collaboratif pour soulager le travail des relecteurs. Après 100 lectures, ça devrait amener à quelque chose de bien.
Il y a des pistes à explorer :
- commentaires coquilles par paragraphe ;
- un système de replace (genre on copie colle une phrase à corriger dans un form, sa correction, et s'il est validé, ça fait le replace) ;

J'aime bien la deuxième qui serait facile à mettre en place sans nécessiter de gros changement.

--
Un clavier azerty en vaut deux.

[^]Re: Questions aux lecteurs

Posté par Victor STINNER (Jabber id, page perso, ) le 25/02/2010 à 12:31. (lien). Évalué à 5.
La question est mal posée. Le problème n'est pas la taille mais l'aspect pratique, comment est-ce qu'on va lire l'article. L'article une très longue page HTML. Si l'écran est large, les lignes font une cinquantaine de mots ou plus (mesure au pifomètre de compétition). Les magazines et journaux utilisent plusieurs colonnes pour qu'on puisse plus facilement voir sur quelle ligne on est (limiter le nombre de mots par ligne). C'est une limitation de la technologie web. J'avais lu que CSS3 permettrait ça mais j'ai l'impression que ce n'est pas implémenté ou que personne ne l'utilise :-/ Dans mon cas, c'est aussi plus fatiguant de lire sur un écran plutôt que sur du papier. Tous ces défauts mis ensemble font que c'est difficile de lire tes longs articles. Je veux dire que le même article correctement mis en forme sur papier ne me poserait aucun problème. D'ailleurs, la mise en forme sur papier impose un découpage par pages, alors qu'une page web a juste une longue barre de défilement pas toujours pratique (ah merde j'en étais où ?).

C'est pourquoi je pense qu'il serait plus pratique pour moi que tes articles soient découpés en plusieurs parties. Il faudrait arriver à trouver un découpage logique. Pour la dépêche 2.6.33, je pense par exemple que l'interview de Frédéric serait une très bonne dépêche à part entière. Pour le reste c'est plus délicat. Un découpage possible serait :
* toutes les nouveautés
* pour en savoir plus : historique du développements (les phases RC) et les développements futurs

Je pense que comme ça, chacun y trouvera son compte. Ceux qui s'intéressent au noyau Linux mais sans plus ne liront que les nouveautés. Ceux qui veulent tout lire, liront... tout, mais pourrons reposer les yeux et leur cerveau (ça bouillone vite avec tes articles !) entre deux dépêches. Je pense également que les commentaires pourront être plus ciblés et donc pertinents.
- [^]Re: Questions aux lecteurs
  
  Posté par Maxime GARCIA (page perso, ) le 25/02/2010 à 13:16. (lien). Évalué à 2.
  Sur un écran large, comme le site "scale", ça devient effectivement embêtant à lire. Petite astuce donc :
  
  Addon Stylish pour FF : https://addons.mozilla.org/fr/firefox/addon/2108
  
  et une règle à mettre pour dlfp :
  div.main {
  width: 1200px;
  margin-left: auto !important;
  margin-right: auto !important;
  }
  
  Remplacer : 1200px par la largeur désirée.
  
  Rmq: on peut le faire de manière temporaire avec firebug, si on l'a, en éditant le style.
  
  --
  Un clavier azerty en vaut deux.
- [^]Re: Questions aux lecteurs
  
  Posté par patrick_g (page perso, ) le 25/02/2010 à 13:20. (lien). Évalué à 2.
  >>> C'est une limitation de la technologie web. J'avais lu que CSS3 permettrait ça mais j'ai l'impression que ce n'est pas implémenté ou que personne ne l'utilise :-/
  
  Ah ! Mais alors là, hop, je sors l'extension Firefox Readability que m'a fait découvrir nilux_ ici : https://linuxfr.org/comments/1107415.html#1107415
  
  C'est vraiment excellent ce truc car tu peux changer la taille des marges (ainsi que le style général et la taille de la police).
  Regarde par exemple ce screenshot avec une grande taille de marge : http://www.flickr.com/photos/11384633@N00/4386576125/sizes/l(...)
  Pas mal non pour éviter d'avoir des lignes trop longues ? Et encore je suis en "wide" comme marges et pas en "extra wide".
  
  >>> je pense par exemple que l'interview de Frédéric serait une très bonne dépêche à part entière.
  
  Bon sur ce point là il semble que la majorité des lecteurs sont d'accord avec toi. Je crois que c'est l'effet d'allongement de la news qui provoque cette réaction et pas intrinsèquement le fait d'inclure une interview. Par exemple dans la future dépêche GCC 4.5 il y a aussi une interview incluse mais comme la news est bien plus courte que celle sur le noyau cela l'enrichit et ne la dessert pas amha.
  - [^]Re: Questions aux lecteurs
    
    Posté par Victor STINNER (Jabber id, page perso, ) le 25/02/2010 à 15:57. (lien). Évalué à 1.
    je sors l'extension Firefox Readability
    
    Elle ne gère pas le « multi colonnage » malheureusement, mais ça semble pas mal ouais.
- [^]Re: Questions aux lecteurs
  
  Posté par PiT (Jabber id, page perso, ) le 03/03/2010 à 09:57. (lien). Évalué à 1.
  (...) le même article correctement mis en forme sur papier ne me poserait aucun problème (...)
  
  Donc un petit bouton "obtenir l'article en PDF" ferait ton plus grand bonheur.
  
  Si j'imprime l'article dans un fichier (ça prend plusieurs secondes) et j'obtiens un PDF de 114 pages [1]. Les pages "gênantes" étant celles des commentaires, ça prend de la place.
  
  Il faudrait revoir la feuille de style destinée à l'impression et peut-être permettre d'obtenir un PDF des articles ... mais c'est évidement du boulot.
  
  [1] http://namok.be/tmp/linuxfr/lfr-newskernel.pdf

[^]Re: Questions aux lecteurs

Posté par Dup (page perso, ) le 25/02/2010 à 13:09. (lien). Évalué à 3.
1/ Oui c'est long mais plaisant donc ça ne l'est pas trop pour ma part
2/ Rien à enlever le menu permet à chacun de lire ce qui l'intéresse, personnellement je lis tout de bout en bout
3/ Ne pas enlever les RCs, cela permet de voir un peu comment Linus gère ses releases

Sinon bravo, si il y a quelque chose à faire je dirais que cela tiens plus du site afin de mieux gérer les longues dépêches (par exemple garder le sommaire flottant lors du défilement).

[^]Re: Questions aux lecteurs

Posté par Jokernathan () le 25/02/2010 à 13:39. (lien). Évalué à 2.
1) Non car c'est bien écrit et accessible
2) Éventuellement l'interview aurait pu être dans une autre news
3) Linux grossi, Linus grossi, les dépêches sur le noyau aussi, logique rien à redire.

--
Mess with the best
Die like the rest

[^]Re: Questions aux lecteurs

Posté par goom (Jabber id, page perso, ) le 25/02/2010 à 13:42. (lien). Évalué à 6.
Tout d'abord merci pour ces dépêches qui me donnent toujours l'étrange sensation d'une part d'en apprendre beaucoup sur le noyau Linux et d'autre part me rappeler mon ignorance crasse sur le sujet (normal comme je ne suis pas informaticien !!)

1) Est-ce que c'est trop long à lire ou pas ?

Non, non et non. Ce qui rend cette dépêche plus longue c'est l'interview qui aurait pu être proposé en tant que dépêche à part.
Autrement, j'apprécie énormément la manière dont tu rédiges ces dépêches :
Balayage des RC ce qui replace le développement du noyau en perspective (une nouvelle version n'arrive pas juste comme ça), avec les interventions de Linus souvent truculentes !
Les nouveautés sont bien détaillées, c'est important quand on ne connait pas grand chose au noyau
Et les en bref complète le triptyque

3) Z'avez d'autres suggestions ?
Continue comme ça, je prends un vrai plaisir à lire ces dépêches qui allient information et humour

--
Ce n'est pas parce que les choses sont difficiles que nous n'osons pas, c'est parce que nous n'osons pas que les choses sont difficiles - Sénèque

[^]Re: Questions aux lecteurs

Posté par Barret Michel (Jabber id, page perso, ) le 25/02/2010 à 13:47. (lien). Évalué à 5.
1) Les dépêches sont longues mais ce n'est pas tout les jours qu'une nouvelle version du noyau arrive (entre 3 et 5 fois par an si je ne m'abuse, non ?). Tes dépêches sont d'une grande qualité et c'est avec grand plaisir que je les lis (il semble que je ne soit pas seul). Je suis très lent à lire d'une manière générale et encore plus lent quand c'est quelque chose de technique (car je prend des pauses pour réfléchir à ce que je lis (si si c'est vrai)).

Ce qui serait un plus c'est de pouvoir l'imprimer pour le lire dans les transport en commun par exemple. Je vais me pencher sur les CSS qui ont était faites dans ce sens et que j'avais zappé.

Donc non tout va très bien, ce n'est pas trop long.

2) Pourquoi est ce que l'interview n'est pas dans la section « Entretiens » du site ? C'est une section très (trop ?) peut utilisée.

3) Avoir une version PDF ? Mais là c'est une fonctionnalité qui manque au site, je trouve. Pouvoir télécharger une dépêche au format PDF (je suis pas bloqué sur le PDF, ça pourrais être dvi, ps ou djvu).

En tout cas merci beaucoup pour cette dépêche.

--
Debian Squeeze

[^]Re: Questions aux lecteurs

Posté par Alek_Lyon () le 25/02/2010 à 15:03. (lien). Évalué à 5.
1/ Ce n'est pas du tout trop long à lire, puisque c'est concis ! Il n'y a ni phrases inutiles ni circonvolutions abusives et tout est très intéressant (et si jamais quelque chose ne l'est pas pour quelqu'un, c'est suffisamment structuré pour sauter un passage).

Après que ce soit long dans l'absolu ne me gène pas du tout au contraire même c'est extrêmement plaisant ; le web regorge de courts articles très intéressants mais au final frustrants, pas la peine d'en rajouter. ;-)

2/ Rien à mon avis. La partie sur les RC permet de se mettre dans le bain sans attaquer tout de suite les détails techniques. Je ne verrais pas d'inconvénient à ce que l'interview fasse l'objet d'une autre dépêche, mais je n'en ressens pas le besoin.

Merci encore pour ce super travail...

[^]Re: Questions aux lecteurs

Posté par Médéric RIBREUX (page perso, ) le 25/02/2010 à 15:10. (lien). Évalué à 5.
Hello,

d'une manière générale, il sera toujours difficile de contenter tout le monde. Certains trouvent que c'est trop long, d'autres que tel ou tel truc ne les intéressent pas, etc...

Mais avec quelques mécanismes qui sont présents dans ces dépêches, on arrive à contenter beaucoup de personnes.

Pour ma part, j'ai mis 15 minutes pour "tout" lire de mon point de vue: je ne suis pas un spécialiste du noyau mais certaines informations m'intéressent, je n'ai pas 30 minutes pour tout lire en détail.

Donc, je ne lis pas le menu (inutile pour moi) mais je reste en mode "scrutation": si un sujet attire mon regard, je lis le paragraphe concerné.
Les RC, à la base je m'en fiche mais le côté social des expressions de Linus et des autres hackers que tu sais bien mettre en avant me les font lire avec pas mal d'attention. Ce que j'en retiens, c'est plutôt le côté "comment le développement du kernel est organisé, comment ça se passe en pratique ?". C'est plus attirant que de lire des mailings-list.

Pour la suite, je me fie aux titres: si celui-ci m'inspire quelquechose (c'est un élément que je connais, c'est un truc très nouveau). Par exemple, j'ai déjà utilisé DRBD en production il y a 5 ans donc cette partie était très instructive pour moi et j'ai tout lu. Même un néophyte peut s'y intéresser: l'intro du sujet est bonne, elle donne des liens de référence; le reste fait rapidement le tour du sujet avant de ramener au noyau. C'est très bien de procéder comme ça: le newbie peut apprendre; le spécialiste ne lira que la partie finale sur DRBD dans le noyau; celui qui a un niveau intermédiaire peut parfaire ses connaissances.

Pour les trucs en bref, même technique: je zappe et lorsqu'un titre m'interpelle, je lit ce qui suit. Enfin, il n'y a pas de titre ce qui est bien pour la visibilité, aussi je me rattrape sur les premiers mots qui donnent tout de suite le sujet concerné. Là encore, il n'y a pas besoin de tout lire pour simplement identifier le sujet. C'est bien rédigé pour ça.

La partie interview est très importante (j'aimais bien aussi celle sur Harald Welte): ça permet de donner un côté plus humain aux kernel hackers, de s'identifier plus facilement à eux, de donner des conseils pour se mettre dans le bain,etc... bref, de profiter de leur expérience. A mon avis, c'est un vrai plus ! Même si ça prend du temps, ça serait excellent d'en avoir une à chaque release.

Pour résumer:
- c'est bien écrit: tout le monde aime ce que tu fais et comment tu le fais (bande de fanboyz/girlz).
- on peut tout lire ou adapter sa lecture à son propre niveau de connaissance et à son temps disponible.
- il y du très technique mais qui est rédigé pour être abordable même par un novice

En conclusion:
1) ça n'est jamais trop long à lire du moment qu'on peut sélectionner ce qu'on va lire.
2) du coup, il ne faut rien enlever.
3) C'est quand la 2.6.34 ?

[^]Re: Questions aux lecteurs

Posté par Zorro (page perso, ) le 25/02/2010 à 16:19. (lien). Évalué à 3.
C’est long, mais bien écrit et bien mis en page, avec beaucoup de passages compréhensibles même pour le débutant amateur, alors bon… Continue comme ça !

Juste : t’aurais pas une version .epub, pour qu’on puisse le lire tranquillou dans les transports ?

--
Aide instantanée sur Mandriva : retrouvez-nous sur http://chat.jabberfr.org/muckl_int/?room=mandriva

[^]Re: Questions aux lecteurs

Posté par Barret Michel (Jabber id, page perso, ) le 25/02/2010 à 17:45. (lien). Évalué à 4.
Pourquoi ne pas proposer un sondage ?

--
Debian Squeeze

[^]Re: Questions aux lecteurs

Posté par eggman (Jabber id, ) le 25/02/2010 à 18:04. (lien). Évalué à 4.
1) Est-ce que c'est trop long à lire ou pas ?

Franchement, non, ce n'est pas trop long vu le sujet et le style.
Je n'ai jamais rien lu concernant les développements du noyau jusqu'à ce que je tombe sur une de tes dépêches.
Non seulement j'ai l'impression d'être moins ignare après la lecture, mais en plus, celle-ci est plaisante, voire drôle avec, notamment, les citations de Linus.

2) Si oui qu'est-ce qu'il faut enlever ?

Dans la mesure où j'ai répondu non, je ne me vois pas réclamer de raccourcir les dépêches.^^
Tout au plus pourrait-on demander un petit résumé pour que les pisse-vinaigre aient une lecture assez courte...

3) Z'avez d'autres suggestions ?

Continue comme ça, ça rend le développement du noyau et la compréhension de celui-ci plus accessible aux « non-initiés » dont je fais partie.

Deux choses encore :
Excellente, l'idée du menu ! Ça améliore grandement l'accès au contenu.
Et finalement, MERCI pour la lecture ainsi que le temps passé à rédiger.

[^]Re: Questions aux lecteurs

Posté par Axone () le 25/02/2010 à 21:11. (lien). Évalué à 1.
1) Non ce n'est pas trop long. J'adore toutes les parties.
2) bah on n'enlève rien, on garde tout.
3) Je te suggère de continuer encore longtemps, tu fais un travail remarquable et c'est très agréable et intéressant à lire.

[^]Re: Questions aux lecteurs

Posté par vladislav askiparek () le 25/02/2010 à 21:45. (lien). Évalué à 4.
3) pour le retour des dépêches cinéma

--
Troll is te veel

[^]Re: Questions aux lecteurs

Posté par Okki (page perso, ) le 25/02/2010 à 23:36. (lien). Évalué à 2.
Tout comme nous ne sommes pas obligés de lire un roman en une seule fois, ça ne m'a absolument pas dérangé de lire une partie de la dépêche ce matin, puis le reste ce soir. Personnellement j'ai trouvé ça passionnant, ça se lit tout seul, et c'était vraiment une bonne idée d'offrir une interview bonus avec ce nouveau numéro :)

Encore merci Patrick, Frédéric et tous ceux qui ont contribué de près ou de loin à cette dépêche.

[^]Re: Questions aux lecteurs

Posté par VoixOff () le 25/02/2010 à 23:44. (lien). Évalué à 1.
Bien que j'aie « pertinenté » les remarques auxquelles j'adhérais, j'en remets une couche :-)

1) Des articles bien écrits, riches en détails et en liens, c'est rare. Et puis plus c'est long, moins je lis de conneries ailleurs.

2) Nada. Pour les commentaires de RC, je plussoie car ça me rappelle Kernel Traffic que je dévorais.

3) Tu concoures pour l'édition française de Linux Weekly News ?

Continue :-)

[^]Re: Questions aux lecteurs

Posté par __o () le 26/02/2010 à 00:14. (lien). Évalué à 1.
1) Est-ce que c'est trop long à lire ou pas ?
2) Si oui qu'est-ce qu'il faut enlever ?
3) Z'avez d'autres suggestions ?

Ça serait bien de faire des articles plus petits, mais plus souvent (façon « release often »). On a rien pendant des mois, puis un article géant d'un coup :-)

Je pense qu'il serait profitable de publier certaines parties séparément, à des moments différents, entre deux releases (puis de les lier dans la news après).

« Stockage distribué DRBD », « Transaction TCP par cookie », et toutes les autres parties de « Nouveautés » auraient fait des news ou journaux à part entière. L'interview aussi. Etc.
- [^]Re: Questions aux lecteurs
  
  Posté par Zenitram (page perso, ) le 26/02/2010 à 12:21. (lien). Évalué à 1.
  On a rien pendant des mois, puis un article géant d'un coup :-)
  
  Tu n'es pas obligé de tout lire en une fois...
  Si c'est segmenté, on aura du mal à retrouver nos "petits" quand on voudra voir les nouveauté du noyaux.
  
  A la limite, l'interview aurait pu être mise de côté (dans une autre dépêche), car ne concerne pas directement le noyau (ses nouveautés), mais la façon de faire, mais pour le reste... Vaut mieux rester en une fois, et on a le sommaire pour s'organiser!
  - [^]Re: Questions aux lecteurs
    
    Posté par __o () le 26/02/2010 à 19:37. (lien). Évalué à 1.
    > Tu n'es pas obligé de tout lire en une fois...
    
    C'est sûr. Mais entre la rc1 ou la rc2 et la release il y aurait déjà matière à faire de bons articles sur les trucs importants :)
    
    > Si c'est segmenté, on aura du mal à retrouver nos "petits" quand on voudra voir les nouveauté du noyaux.
    
    Je verrais bien une news comme ça :
    
    <article>
    Les nouveautés :
    * nouveauté 1 : lien vers l'article
    * nouveauté 2 : lien vers l'article
    * etc.
    En bref:
    ...
    </article>

[^]Re: Questions aux lecteurs

Posté par Thomas DEBESSE () le 26/02/2010 à 16:35. (lien). Évalué à 3.
1) très long de lire tout, mais comme tout ne m'intéresse pas, je ne lis pas tout, cela ne me pose pas de problème. La mise en page/découpage très bien faite me permet de ne pas etre dérangé par ce qui ne concerne pas.
2) surtout pas les RC, cela permet de faire toucher du doigt l'aspect humain du développement du noyau, et puis c'est passionnant à suivre comme un feuilleton, avec les rebondissements et tout. Et puis c'est le "vous aussi suivez la LKML, édition résumée de poche".
Certains aimeront le cours magistral, d'autres le feuilleton.
3) sans enlever quoique ce soit, l'idée de découper la dépeche est une bonne idée (comme cela s'est produit finalement pour OsmocomBB).

--
† In te confirmátus sum ex útero : de ventre matris meæ tu es protéctor meus.

[^]Re: Questions aux lecteurs

Posté par Olivier (page perso, ) le 26/02/2010 à 17:44. (lien). Évalué à 4.
1) Est-ce que c'est trop long à lire ou pas ?
C'est certes plus long à lire que certains journaux "bookmarks". Mais les news sur le kernel, il n'y a en pas tant que cela par an, et c'est toujours un régal de lire ta prose

2) Si oui qu'est-ce qu'il faut enlever ?
Rien à enlever. Pour les râleurs qui trouvent que les RC sont trop longs, il y a les menus qu'ils peuvent utiliser.
Et puis, toutes les petites anecdotes sur LKML, ou les réponses de Linus, apportent un coté très humain à, ce qui est vu depuis l'extérieur, comme un travail très techniques

3) Z'avez d'autres suggestions ?
Non, continue comme cela, c'est tout simplement excellent !!!

[^]Re: Questions aux lecteurs

Posté par Zarmakuizz (page perso, ) le 27/02/2010 à 00:46. (lien). Évalué à 2.
Je continue la chaine :
1) Le plus long (aussi bien temps que temps de lecture) pour moi est de camper jusqu'à avoir lu assez de commentaires dans ces news-là. Car ça fait aussi partie du charme. :)
2) Il faudrait enlever l'envie d'enlever des choses à cette news : plus la news est courte et moins les gens réagissent en moyenne !
3) À l'avenir poser plus de questions dans les interviews de contributeurs français honorables, ou trouver des questions plus longues, je sais pas...

Tiens, personne n'a remarqué que Linus a indiqué ne jamais être d'accord pour intégrer quelque chose dans le noyau si on ne le convainc pas, par contre il était vraiment convaincu contrairement aux autres développeurs au sujet de Nouveau pour insister autant sur son intégration dans le noyau.
Grosso modo :
_Pourquoi vous voulez pas que Nouveau soit en marche ?
_Ça sert à rien.
_Fedora l'utilise.
_Ouais mais Fedora c'est des hyppies.
_Ouais mais tu racontes de la merde, allez hop accepté.

Il me semble que Linus utilise un Fedora au boulot ? Auquel cas ceci explique cela... à coup sûr il a une nvidia chez lui ou au boulot ou les deux.

Y a-t-il une raison pour laquelle Nouveau soit caché ainsi ?
Même si la tournure du texte laissait supposer que Red Hat seul soit censé gérer l'intégration des pilotes, peut-être sont-ils excessivement prudents par rapport aux alternatives de pilotes déjà présents ?
- [^]Re: Questions aux lecteurs
  
  Posté par KiKouN (Jabber id, ) le 27/02/2010 à 11:08. (lien). Évalué à 2.
  > Tiens, personne n'a remarqué que Linus a indiqué ne jamais être d'accord pour intégrer quelque chose dans le noyau si on ne le convainc pas, par contre il était vraiment convaincu contrairement aux autres développeurs au sujet de Nouveau pour insister autant sur son intégration dans le noyau.
  
  Il faut rappeler que le blob de nvidia est une longue histoire, la première du style ayant fait basser beaucoup de bits dans nos petits tuyaux. Il est peut-être simplement content et/ou pressé de voir une solution libre à ce blob.
  
  --
  KiKouN, Bucheron-Geek
  Aidez des enfants à organiser un jeu de type famille en or.
  A la question Citez quelque chose qui se plante., priez de ne pas répondre Windows. Merci.
  - [^]Re: Questions aux lecteurs
    
    Posté par patrick_g (page perso, ) le 27/02/2010 à 11:23. (lien). Évalué à 2.
    Et puis il faut le convaincre pour intégrer quelque chose dans le noyau si il n'y a pas d'utilisateurs qui le réclament (cf le mail complet de Linus).
    Dans le cas de Nouveau il est évident qu'il y avait beaucoup d'utilisateurs.
- [^]Re: Questions aux lecteurs
  
  Posté par IsNotGood () le 28/02/2010 à 18:50. (lien). Évalué à 2.
  Y a-t-il une raison pour laquelle Nouveau soit caché ainsi ?
  
  Nouveau n'est absolument pas "caché" (et pourquoi le serait-il ?).
  Il est dans Fedora depuis la F8 !
  Je crois qu'ici il faut seulement voir un saut d'humeur de Linus.
  GFS (développé depuis des années par Red Hat) a mis des plombes pour arriver upstream alors que Red Hat le demandait et GFS est utilisé en production.
  Les efforts autour de Nouveau sont remarquables. Mais c'est loin d'être complet (la 3D débute à peine), c'est du reverse engineering, aucun support du constructeur, etc.
  
  Il est très surprenant de voir Linus réclamer Nouveau dans le noyau. À part un contexte difficile (Nouveau, reverse engineering, intégration upstream au pas de charge, etc), Red Hat doit être bien content de cet "amour" de Linus pour Nouveau.
  - [^]Re: Questions aux lecteurs
    
    Posté par Albert_ () le 02/03/2010 à 10:57. (lien). Évalué à 2.
    Les efforts autour de Nouveau sont remarquables. Mais c'est loin d'être complet (la 3D débute à peine)
    
    Que je sache le driver nv n'a pas plus de 3D et personne ne le maintient sauf nvidia et uniquement quand ils veulent.
    - [^]Re: Questions aux lecteurs
      
      Posté par Nicolas Boulay () le 04/03/2010 à 17:39. (lien). Évalué à 3.
      Et surtout Nouveau est bien meilleur que Nv !
      
      --
      "Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."

[^]Re: Questions aux lecteurs

Posté par wismerhill (page perso, ) le 27/02/2010 à 00:51. (lien). Évalué à 2.
C'est très long à lire (je viens d'y passer une bonne partie de ma soirée), mais pas trop car c'est très intéressant.

C'est toujours un plaisir de voir arriver une de tes dépêches car les sujets sont bien traités avec plein de liens extérieurs pour approfondir.

[^]Re: Questions aux lecteurs

Posté par ianux (Jabber id, page perso, ) le 27/02/2010 à 03:51. (lien). Évalué à 2.
1) Quand je vois le titre de la dépêche arriver sur mon lecteur RSS je me dis
« chouette, encore un article de patrick_g sur le dernier noyau linux ».
Quand j'arrive sur la page DLFP je me dis
« merde, encore un article de patrick_g sur le dernier noyau linux ».
Blague à part, mécaniquement, plus y'a de signes, plus c'est long à lire (ce n'est pas une critique, j'ose même pas imaginer le temps qu'il a fallu pour rédiger tout ça). Pour le coup, j'ai gardé l'article sous le coude pendant 3 jours avant de me sentir dispo pour m'y coller (si on veut suivre un peu les liens proposés on arrive vite à quelques heures de lecture). Mais si on veut être exhaustif - et c'est le but de la dépêche - c'est le prix à payer.
2) Je rejoins la plupart des gens pour dire que la partie RC avec les tirades de Linus ajoute un côté rock'n'roll rafraîchissant, à garder absolument ! certains trucs ne m'intéressent pas forcément, mais comme dit précédemment, la dépêche se doit d'être complète, donc elle grossit avec le noyau.
3) Peut-être séparer le côté utilisateur (les changements qu'on voit facilement à l'écran ou à l'usage) et le côté développeur. Et passer l'article plusieurs fois à la moulinette d'un correcteur orthographique, voire d'un turc mécanique pour les fautes qui ne relèvent pas de l'orthographe pure (à l'heure ou j'écris il reste quelques coquilles).

--
radio ianux

[^]Re: Questions aux lecteurs

Posté par Mildred (Jabber id, page perso, ) le 27/02/2010 à 10:14. (lien). Évalué à 3.
1) oui, c'est long, mais ce n'est pas un problème (je viens de finir la lecture juste maintenant)
2) ne rien enlever
3) si c'est trop long, peut être couper en plusieurs articles, et les commentaires pourraient ce centrer que ce qui a été dit en particulier dans un article.

En passant, j'aime bien le texte que tu mets sur les RC, ça donne un coté vivant que j'aime bien, ce serait domage de l'enlever.

--
La Roue du Temps

[^]Re: Questions aux lecteurs

Posté par tankey () le 27/02/2010 à 12:15. (lien). Évalué à 2.
"Le problème est que ça coupe tout simplement l'envie de lire".
enlever l'envie de lire, mais à qui ??

3) Z'avez d'autres suggestions ?
Avec ces articles là, il serait peut être sage de prévoir une page spéciale. La dépêche restante complète comme celle ci (tant que possible!), et renvoyant aux paragraphes encore plus détaillés sur une page spéciale (si possible aussi lol)

En tout cas, prévoir un archivage (ou un accès) spécifique pour les dépêches noyaux. Je trouverai ça intéressant et sympa. Sympa parceque cela permettrai de faire des sauts rapides entre versions proches de noyaux. Et d'une manière plus globale et à plus long terme, avoir une belle historisastion.
- [^]Re: Questions aux lecteurs
  
  Posté par Nic0 (page perso, ) le 27/02/2010 à 13:36. (lien). Évalué à 2.
  » En tout cas, prévoir un archivage (ou un accès) spécifique pour les dépêches noyaux.
  
  Pour retrouver les dépêches noyaux rapidement, c'est facile :
  https://linuxfr.org/news/index,1,note.html
  
  Suffit de trier les dépêches par notes, tu retrouves 7 dépêches noyaux dans le top 10.
  - [^]Re: Questions aux lecteurs
    
    Posté par baud123 (Jabber id, page perso, ) le 27/02/2010 à 14:56. (lien). Évalué à 3.
    ou tout simplement utiliser le système de sections/thèmes de DLFP (à défaut d'avoir des tags)
    https://linuxfr.org/topics/Kernel
    
    Pour la liste complète, voir sur le côté ou tout simplement
    https://linuxfr.org/moderateurs/moderation.html#themes

[^]Re: Questions aux lecteurs

Posté par Boa Treize (page perso, ) le 27/02/2010 à 13:03. (lien). Évalué à 1.
1) Est-ce que c'est trop long à lire ou pas ?

Ce n'est pas trop long. Par contre c'est un des rares cas où je ne lis pas une dépêche tout de suite, mais la met de côté pour la lire ensuite tranquillement le week-end.

2) Si oui qu'est-ce qu'il faut enlever ?

L'interview aurait clairement dû faire l'objet d'une dépêche séparée.

3) Z'avez d'autres suggestions ?

Non. :-)

[^]Re: Questions aux lecteurs

Posté par Phylyppe () le 27/02/2010 à 23:51. (lien). Évalué à 1.
1) Est-ce que c'est trop long à lire ou pas ?
C'est passionnant. Ca ne peut pas être trop long.

2) Si oui qu'est-ce qu'il faut enlever ?
Rien.

3) Z'avez d'autres suggestions ?
Continuer !

[^]Re: Questions aux lecteurs

Posté par PiT (Jabber id, page perso, ) le 03/03/2010 à 09:44. (lien). Évalué à 2.
Pas mal de réponses déjà à ta question mais j'y répond quand même.

D'abord je maudis le copain qui ma filé le lien ce matin car le temps -qui est compté- passe et je le bénis car c'est intéressant.

C'est effectivement (très) long à lire mais c'est le cas de tout article qui se veut un peu complet. Ce n'est donc pas trop long car -comme l'on dit d'autres- on peut lire uniquement les points qui nous intéressent et le lectorat LinuxFR est supposé intéressé ;-)

Les parties sur les différentes releases m'intéressent moins mais elles intéressent peut-être d'autres lecteurs.

Pas d'autres suggestions que de demander de continuer, ça fait quelques années déjà que LinuxFR est ma principale source d'infos (même si je suis de plus en plus taiseux - gestion du temps oblige).

Merci à toi.

[^]Re: Questions aux lecteurs

Posté par Xavier Teyssier (Jabber id, page perso, ) le 03/03/2010 à 12:41. (lien). Évalué à 5.
Une réponse de plus.

* Trop long ?
C'est long à lire, oui, mais certainement pas trop long.
En plus, la nature m'a doté d'un truc assez génial qui s'appelle un cerveau. Avec lui, en plus de savoir lire, je suis capable de m'arrêter quand je dois faire autre chose, et de reprendre là où je m'étais précédemment arrêté quand j'ai de nouveau du temps. C'est assez génial comme fonctionnalité.

* Quoi enlever ?
Rien. La partie sur les RC ajoute du "fun" à la news, et permet de se préparer à attaquer la partie plus technique.
En plus, avec mon cerveau, j'arrive même à sauter les paragraphes qui ne m'intéresse pas. C'est plutôt cool comme liberté !

* Autres suggestions :
- Ne surtout pas couper ces dépêches en plusieurs news. Cela me paraitrait tout aussi agaçant que les liens qui forcent l'ouverture d'une nouvelle fenêtre. L'article forme un tout, le tronçonner briserait son unité.
- Pourquoi pas un bouton pour transformer la news (sans les commentaires) en PDF. Pour LinuxfrOnRails ?

Le cerveau, c'est un truc tellement génial que tout le monde en a un. Malheureusement, beaucoup n'ont pas pris la peine d'en lire le manuel...

[+] Très bon

Posté par Carl Chenet (page perso, ) le 25/02/2010 à 10:56. (lien). Évalué à -2.

Super l'article, merci bien !

--
identi.ca : http://identi.ca/carlchenet
blog : http://carlchenet.wordpress.com

Stockage distribué DRBD

Posté par Olivier Bernard () le 25/02/2010 à 10:58. (lien). Évalué à 4.

Merci pour la dépêche, très intéressante comme à son habitude.

Petite question concernant DRDB.
En lisant sa description :

<<
Ce sont ces blocs de bas niveau qui sont répliqués par DRBD sur plusieurs machines de façon automatique. Cette réplication peut se faire de façon synchrone (un bloc est considéré comme répliqué uniquement quand il a été écrit en local, envoyé vers le disque du nœud distant et que ce nœud distant a confirmé qu'il était correctement écrit) ou bien de façon asynchrone (un bloc est considéré comme répliqué quand il a été écrit en local et qu'il a juste été envoyé vers le nœud distant, sans confirmation en retour).
>>

J'aurai cru justement que ce type de mécanisme permettait [b]d'éviter[\b] d'avoir à utiliser des systèmes de fichiers distribués (possédant souvent des limitations), le mirroring se faisant justement au niveau réseau.
Y a-t-il quelque chose qui m'échappe ?

Beamo

[^]Re: Stockage distribué DRBD

Posté par patrick_g (page perso, ) le 25/02/2010 à 11:19. (lien). Évalué à 3.
En fait, d'après ce que j'ai compris, les noeuds peuvent être configurés de deux façons différentes.
Soit ils sont de type "noeud primaire" (et alors ils ont le droit de modifier les données), soit ils sont de type "noeud secondaire" (et alors ils ont un rôle purement passif).
Après si tu veux monter une configuration avec un primaire et un secondaire il n'y a pas de problème à utiliser un système de fichiers local (Ext3 par exemple).
En revanche si tu veux une config avec deux noeuds primaires (dual-primary) alors il te faut un système de fichiers distribué à la GFS.

Voir ici :
http://www.drbd.org/users-guide/ch-features.html#s-single-pr(...)
http://www.drbd.org/users-guide/s-dual-primary-mode.html
- [^]Re: Stockage distribué DRBD
  
  Posté par Olivier Bernard () le 25/02/2010 à 11:28. (lien). Évalué à 1.
  Ok !
  
  Je n'avais pas pensé au cas d'un cluster actif/actif.
  Tout s'explique, merci :)
  - [^]Re: Stockage distribué DRBD
    
    Posté par denisb () le 25/02/2010 à 14:30. (lien). Évalué à 3.
    On peut aussi utiliser lvm en mode cluster, ce qui permet de monter des lv avec des systèmes de fichiers normaux indifféremment sur les deux noeuds. C'est d'ailleurs la solution pour pouvoir faire des migrations à chaud Xen ou KVM.
    
    Sinon au niveau perfs c'est vraiment bon, j'ai une config en prod ( serveur samba en xen sur une cluser deux noeuds actif/actif ), et la pénalité est très faible.
    http://wwdeb.crdp.ac-caen.fr/mediase3/index.php/Cluster_Xen
    - [^]Re: Stockage distribué DRBD
      
      Posté par Dreamkey () le 26/02/2010 à 19:11. (lien). Évalué à 1.
      Bonjour,
      il y a quelque chose que je n'ai pas compris à propos de DRBD : "La méthode asynchrone peut impliquer des pertes de données (sans perte de cohérence toutefois)". J'ai regardé sur le wiki ce qu'étais la Cohérence_(données) ; cependant s'il la perte de donnée, comment être sûr qu'il n'y a pas de perte cohérence ? Car la demande de réplication transite assez par le réseau, donc elle est aussi susceptible qu'une donnée, non ?
      - [^]Re: Stockage distribué DRBD
        
        Posté par patrick_g (page perso, ) le 27/02/2010 à 08:25. (lien). Évalué à 2.
        J'ai simplifié en parlant juste de protocoles synchrones et asynchrones.
        En fait il y a trois protocoles différents concernant la réplication des données (A, B et C).
        Tu peux lire une explication des différences ici : http://www.drbd.org/users-guide-emb/s-replication-protocols.(...)
      - [^]Re: Stockage distribué DRBD
        
        Posté par pfrenard () le 02/03/2010 à 22:20. (lien). Évalué à 3.
        Il y a juste 2 notions différentes:
        - la cohérence de ton FS/base de données ....
        - la cohérence de tes données.
        
        Pour que tes données soient cohérentes il faut que le mécanisme de réplication assure que les IOs sont réalisées dans le même ordre (In Order Delivery) c'est à dire que si tu fais une IO1 puis une IO2 sur un système tu trouves bien la même chose sur le système distant et dans le même ordre. (Analogie à faire avec le mode barrière des disques récemment traité dans le kernel)
        Par contre ton système de réplication n'est pas en charge de la bonne cohérence de ton FS. Le FSCK est peut-être toujours nécessaire.
        
        Tu peux avoir pert de de données en cas de FSCK ou en cas de non réplication (souvent lié à un sinistre - crash OS/ crash hardware/ crash de datacenter ... )
        
        J'espère avoir été clair :)
        
        @++
        
        [^]Re: Stockage distribué DRBD
        
        Posté par Dreamkey () le 05/03/2010 à 01:24. (lien). Évalué à 1.
        En effet c'est plus clair, merci !

Remerciements

Posté par Laifen () le 25/02/2010 à 11:14. (lien). Évalué à 2.

Merci pour toutes ces descriptions, c'est chaque fois une joie de pouvoir être si bien mis au courant pour chaque release.

Bonne continuation ;)

Juste une question

Posté par campagnard () le 25/02/2010 à 14:37. (lien). Évalué à 6.

Je n'ai pas fini de lire la dépeche, mais je pose cette question tout de suite car sinon je risque d'oublier et apparement elle n'a pas été posée en commentaire. C'est peut etre une question basique mais pas pour moi. (Et si ca m'interesse ca interessera quelqu'un d'autre)

"Techniquement ramzswap utilise l'algorithme de compression LZO (...) ainsi qu'un allocateur mémoire spécifique (xvmalloc). Cet allocateur est nécessaire car les développeurs ont découvert que ceux qui sont déjà disponibles dans le noyau Linux ne remplissaient pas leur cahier des charges très spécial. (..). SLUB de son côté a une tendance à la fragmentation mémoire que xvmalloc permet d'éviter."

Quel est le problème de la fragmentation mémoire pour de la mémoire RAM ? Je comprends le problème de la fragmentation pour des périphériques avec un temps d'accès lent, typiquement les disques durs avec leur parties mécaniques qui doivent donc se déplacer de fragment en fragment. Mais lors d'accès en RAM, ce problème ne se pose pas. Quel est donc le problème ?

Je retourne lire la suite de l'article, et je reviens si j'ai d'autres questions ^^

PS : j'ai failli oublier : félicitations patrick_g pour cette excellente depeche, comme toujours ! Atteindre la perfection est une chose, s'y maintenir en est une autre !

[^]Re: Juste une question

Posté par patrick_g (page perso, ) le 25/02/2010 à 14:59. (lien). Évalué à 8.
>>> Je comprends le problème de la fragmentation pour des périphériques avec un temps d'accès lent, typiquement les disques durs avec leur parties mécaniques qui doivent donc se déplacer de fragment en fragment. Mais lors d'accès en RAM, ce problème ne se pose pas. Quel est donc le problème ?

Moi aussi ce truc m'a toujours plus ou moins intrigué. Cela s'explique parce qu'il y a des cas ou il est absolument nécessaire d'allouer une quantité de mémoire contigüe....et évidemment c'est difficile de satisfaire cette condition si toute la mémoire est fragmentée en petits bouts entre les processus.
On trouve pas mal de détails ici : http://lwn.net/Articles/211505/
Notamment ce paragraphe (à la fin rigolote) :
"Since Linux is a virtual memory system, fragmentation normally is not a problem; physically scattered memory can be made virtually contiguous by way of the page tables.
But there are a few situations where physically-contiguous memory is absolutely required. These include large kernel data structures (except those created with vmalloc()) and any memory which must appear contiguous to peripheral devices. DMA buffers for low-end devices (those which cannot do scatter/gather I/O) are a classic example. If a large ("high order") block of memory is not available when needed, something will fail and yet another user will start to consider switching to BSD".
- [^]Re: Juste une question
  
  Posté par campagnard () le 25/02/2010 à 15:48. (lien). Évalué à 1.
  Tu m'épate encore : non seulement tu fais des dépeches qui consitituent pour moi (et apparement pour beaucoup d'autres) le top de la qualité redactionnelle, mais en plus tu réponds vite et de facon pertinente à mes questions. Bravo et merci !
  
  J'ai maintenant fini de lire la dépeche, aucune autre question ne m'est venue à l'esprit.
  
  Il ne me reste plus qu'a remercier moi aussi Frédéric Weisbecker, j'ai trouvé son interview très interessante. Elle peut donner envie de se plonger dans la programmation noyau, et plus important, oter les peurs de ceux qui n'osent pas s'y lancer.
  - [^]Re: Juste une question
    
    Posté par patrick_g (page perso, ) le 25/02/2010 à 15:50. (lien). Évalué à 4.
    >>> tu réponds vite
    
    Je suis en congé aujourd'hui et demain donc je glandouille devant mon ordi ;-)
    - [+] [^]Re: Juste une question
      
      Posté par Toufou (page perso, ) le 25/02/2010 à 17:02. (lien). Évalué à -1.
      Peut-être mais tu es notre dieu quand même :)
      
      Je reste sidéré par la qualité de tes productions et je n'imagine pas les efforts fournis pour atteindre ce niveau.
      
      Bref : merci za toi
      
      Toufou : membre du Patrick_g fan club
- [^]Re: Juste une question
  
  Posté par ymorin () le 25/02/2010 à 15:58. (lien). Évalué à 3.
  Une autre explication : si tu as 128KiB de memoire (virtuelle!), et que tu alloues 4 blocks de 32KiB, tu as la place, et la memoire est repartie ainsi :
  Block 0 : 32KiB : indisponible
  Block 1 : 32KiB : indisponible
  Block 2 : 32KiB : indisponible
  Block 3 : 32KiB : indisponible
  
  Maintenant, tu liberes les blocks 1 et 3, donc tu as 64KiB de memoire libre, repartis ainsi :
  Block 0 : 32KiB : indisponible
  Block 1 : 32KiB : libre
  Block 2 : 32KiB : indisponible
  Block 3 : 32KiB : libre
  
  Enfin, tu veux allouer un block de 64KiB. He bien ce n'est pas possible, car le plus gros block dispo n'est que de 32KiB. Donc meme si tu as 64KiB de memoire disponible, tu n'as pas 64KiB _contigus_ de disponible, et donc ta memoire est fragmentee!
  
  Voila...
  - [^]Re: Juste une question
    
    Posté par campagnard () le 25/02/2010 à 16:33. (lien). Évalué à 3.
    Je pensais que, dans la situation que tu décris, lors de la demande d'allocation de 64KiB, le système etait capable d'accepter la demande, en allouant les 64 KiB de manière fractionnée et en gérant la fragmentation (lorsque tu essaie de lire ou d'ecrire cette mémoire, le système lit ou écrit les dans les bons fragments). Si c'est le cas, ce que tu me décrit là explique comment on arrive à la situation d'une mémoire fragmentée, mais ca n'explique pas en quoi c'est problématique.
    - [^]Re: Juste une question
      
      Posté par ymorin () le 25/02/2010 à 17:26. (lien). Évalué à 1.
      Lorsque tu alloues de la memoire, tu obtiens un pointeur sur de la memoire _virtuelle_. Si le system re-ordonne les blocks _vituels_ pout obtenir des block contigus, alors tes pointeurs deviennent faux! Et tu n'as aucun moyen de le savoir!
      
      Par contre, le re-ordonnancement des blocks physiques est possible (sauf certains cas) puisque la MMU est la pour ca : translation adresse virtuelle -> adresse physique. Et ca, ca peut changer sans probleme. D'ailleurs, ca arrive tout le temps!
      
      Exemple :
      - ton appli alloue un bloc de memoire : elle obtient de la memoire virtuelle, et une correspondance avec de la memoire physique est etablie a travers la MMU (grosso modo, hein!)
      - ton appli est preemptee par une autre appli, qui a besoin de memoire
      - le block precedent est mis en 'swap'
      - ton appli est a nouveau schedullee et a besoin de son block
      - le systeme reprend le block ; son adresse virtuelle n'a pas change, mais rien ne garantit qu'il soit au meme endroit en memoire physique
      
      Hop, voila.
      - [^]Re: Juste une question
        
        Posté par ymorin () le 25/02/2010 à 17:37. (lien). Évalué à 3.
        Au fait, mon explication est valable pour les applications, pas pour le noyau. Le noyau peut effectivement travailler avec de la memoire physique, lui.
        
        Et pour la memoire physique c'est effectivement plus complique...
        
        Exemple :
        - de la memoire est allouee et desalloue par le kernel, en plusieurs fois, de maniere 'aleatoire' ; tout va bien, il y a assez, mais la memoire est pleine de petits trous...
        - un driver est charge (par exemple, par chargement de module) et a besoin d'une grosse quantite de memoire contigue (ex. pour mapper avec du materiel). Meme s'il y a assez, mais en plein de tout petits bouts, alors l'allocation va echouer. Il est en effet impossible de remapper les petits bouts, car d'autres parties du kernel ont des pointeurs dessus, et il faut surtout pas les contrarier, ces petites betes la!
        
        Re-hop, re-voila! ;-)
        
        [^]Re: Juste une question
        
        Posté par campagnard () le 26/02/2010 à 09:22. (lien). Évalué à 2.
        Merci (à toi et aux autres) pour ces explications supplémentaires. Je comprends mieux le problème maintenant.
  - [^]Re: Juste une question
    
    Posté par neologix (page perso, ) le 25/02/2010 à 16:39. (lien). Évalué à 4.
    Et on peut voir çà dans /proc/buddyinfo:
    Node 0, zone DMA 5 6 2 2 3 1 1 1 1 1 2
    Node 0, zone Normal 298 237 32 3 7 3 0 0 0 1 1
    Node 0, zone HighMem 0 716 6466 3866 1196 188 76 17 26 54 469
    
    On voit le nombre de pages libres, par ordre (puissance de 2), dans les différentes zones de mémoire: DMA (<16M), NORMAL (<4G), HIGHMEM (>4G).
- [^]Re: Juste une question
  
  Posté par lasher () le 26/02/2010 à 02:06. (lien). Évalué à 7.
  Dans certaines applications intensives en calcul aussi, ça peut faire la différence. Du point de vue performances, s'il est possible de modifier les algos de calcul (analyse numérique en général, traitement d'image ou de signal, etc.) de façon à ce que des blocs de données soient utilisés le plus longtemps possible dans les caches, on va gagner en perf (vu que la mémoire cache est plus rapide que la RAM). Mais si à cause d'une trop grande fragmentation mémoire je me retrouve avec de la mémoire non-contiguë, ça finit par faire désordre [1].
  
  Théoriquement, l'utilisation des « superpages » (ou « huge pages ») permet justement d'éviter des défauts de TLB, d'améliorer la façon dont les données sont mappées dans les sets des caches, etc., mais sous Linux, et particulièrement avec du x86 en tout cas, leur utilisation est plutôt difficile : sous x86 et x86-64 par exemple, les huge pages font 2 ou 4 Mio, ce qui est trop pour beaucoup d'applications. Mais si ce n'était que ça encore, ça irait. Le problème vient aussi du fait que pour utiliser ces grosses pages, il faut en gros les allouer au boot de la machine, juste au moment de l'init de Linux, qui va réserver ces pages au démarrage. La mémoire ainsi réservée est perdue pour les autres programmes. Et si j'avais besoin d'une grosse page de plus, ben tant pis (si je me souviens bien, la HugePageTLB des archis x86 est de 4 entrées, de toute manière ...).
  
  Pour le coup, il y a un problème inhérent à l'archi actuelle des x86/x86_64, car une page physique fait obligatoirement 4kio. Sur d'autres architectures (Alpha, Itanium par ex), il existe plusieurs tailles possibles pour les pages mémoire, ce qui permet de limiter la fragmentation de la mémoire en fonction de l'utilisation faite de la machine [2].
  
  [1] Ne pas me demander pourquoi, je suis encore en train d'essayer de piger. Pour simplifier, si je lance une appli de calcul intensif au boot d'une machine je vais avoir un certain temps d'exécution. Si je la relance après plusieurs heures, où entre temps j'ai joué avec Eclipse, Firefox, que sais-je (n'importe quoi qui fragmente bien la mémoire), si ensuite je lance mon appli de calcul qui fait un bon gros malloc/mmap au début, la mémoire réellement allouée va être fragmentée tout partout, et il y a un impact direct sur la performance.
  
  [2] Bon OK, en pratique ça veut juste dire qu'on a des blocs de mémoire contiguë plus gros (par exemple sur Itanium 2, je crois que les distribs Red Hat ont mis 64kio par défaut pour une page normale, et 256 Mio pour une huge page). En même temps, quand on a dans les 1 à 4Gio de RAM comme c'est de plus en plus fréquent, on peut se permettre d'avoir des tailles de pages plus grosses ! Surtout si une grande partie de celle-ci sert de cache disque : ça n'enlèvera a priori rien aux perfs. Au contraire.

[^]Re: Juste une question

Posté par neologix (page perso, ) le 25/02/2010 à 17:04. (lien). Évalué à 3.
Comme le dit patrick_g, il y a des fois où on _doit_ avoir des pages contiguës en mémoire physique, par exemple lorsque tu communiques avec des périphériques/DMA (qui eux n'ont pas ce système de MMU/mémoire virtuelle ils attaquent directement le bus).
Ensuite, si tu regardes les sources du noyau, tu verras qu'on demande bien plus souvent des pages contiguës en mémoire physique qu'en mémoire virtuelle (kmalloc() vs kvmalloc()).
La raison est la même que pour le disque : contrairement à ce que tu pourrais croire, les accès mémoire ne sont pas gratuits, et il vaut mieux avoir des pages contiguës pour éviter des modifications de la table des pages et aussi pour profiter au mieux des caches offerts par le processeur (TLB). C'est toujours pareil, un accès séquentiel est toujours plus rapide qu'un acccès "aléatoire".
Voilà pourquoi on a besoin, et on préfère, des pages contiguës en mémoire (physique). C'est aussi pour cela qu'on préfère des allocations d'ordre pas trop gros, et que par exemple des stacks de 4K en kernel mode seraient sympa, car bien plus rapides et faciles à trouver (parce que pour le coup il faut qu'elles soient contiguës).

[^]Re: Juste une question

Posté par tiot (Jabber id, page perso, ) le 25/02/2010 à 18:37. (lien). Évalué à 7.
D'ailleurs j'aimerai rajouter quelques petits trucs sur compcache (ou ramzswap).

L'idée de départ est toute simple. Le temps d'accès au disque dur est plus long que la compression et la décompression de la RAM. D'où l'algorithme de compression LZO qui n'est pas le plus performant au niveau du taux de compression mais qui est vraiment rapide et demande peu de mémoire.

Dans l'exemple donné sur le site http://code.google.com/p/compcache/wiki/Performance/SwapDisk(...)
On se retrouve à 168 ms pour lire sur le swap de disque dur et 12 µs pour de la RAM compressée. Soit un facteur 14 000. Pour l'écriture c'est 355 ms contre 7 µs : un facteur 50 000 !

Personnellement avec mes 512 Mo de RAM, mon disque dur à 5400 tours/minute je voyais réellement la différence. Plus de réactivité et la possibilité d'ouvrir plus de programmes.

[^]Re: Juste une question

Posté par fleny68 () le 25/02/2010 à 23:30. (lien). Évalué à 2.
La perfection n'est pas tout à fait atteinte: on ne dit pas PS2 mais PPS. PS2 n'a pas de sens alors que post-post-scriptum en a un.

Si on tient à mettre un 2 P²S s'impose.

Comme d'habitude super dépêche. Comme d'habitude on ne se lasse pas d'écrire super dépêche.

Peut-on imaginer un ramzswap dynamique dont la taille diminue automatiquement pour libérer de la mémoire directe si le swap se vide, et réciproquement, ou est-ce que c'est obligatoirement une taille fixe?

--
Si cette signature est vraie, le commentaire ci-dessus est sans intérêt.
- [^]Re: Juste une question
  
  Posté par Ph Husson (Jabber id, page perso, ) le 26/02/2010 à 21:04. (lien). Évalué à 1.
  C'est déjà le cas, ramzswap n'utilise que la mémoire réellement utilisée.
  Sinon ramzswap n'aurait aucun interêt par rapport à un ramdisk + cloop lzo + swapon dessus.
  
  --
  Ce messages est crypté par le système 42-rot13 pour plus de sécurité.

Support hyperV

Posté par xavier Granveaux () le 25/02/2010 à 17:48. (lien). Évalué à 3.

Salut,

Un petit point pour lequel il me faudrait une précision.
Je ne suis pas au fait de tous les détails des différentes phases de développement du noyau.
Mais concrètement, pour la partie hyperV (oui, je suis un peu intéressé), ça veut dire que tot ou tard les linuxIC de Microsoft seront intégrés nativement dans le noyau (sous réserve d'activer l'option qui va bien) ?
Ou ca va rester sous forme de patch comme aujourd'hui ?
J'avoue qu'entre ça, le petit patch fourni par Microsoft, et le petit complément au patch fourni par Citrix, je ne sais pas trop quoi en penser.

Est-ce que je peux nourir le rêve qu'un jour ce soit directement intégré dans le noyau de ma distribution préférée ?

[^]Re: Support hyperV

Posté par briaeros007 () le 25/02/2010 à 22:16. (lien). Évalué à 3.
mode court : t'avais qu'a prendre kvm/xen plutôt qu'hyper v , non mais oh.

mode un poil plus long : si ms décide de bosser correctement, et sur la durée, tu pourras en profiter de base.
Sinon, ben non.

--
Subete ga wakatta toki…watashi ga anta wo korosu.

GNU/Linux Magazine France

Posté par Raphaël SurcouF (Jabber id, page perso, ) le 25/02/2010 à 18:30. (lien). Évalué à 3.

Patrick ! Il ne va plus rien rester au Kernel Corner de GLMF avec tes dépêches ! ;-)

[^]Re: GNU/Linux Magazine France

Posté par baud123 (Jabber id, page perso, ) le 25/02/2010 à 20:35. (lien). Évalué à 7.
Patrick ! Il ne va plus rien rester au Kernel Corner de GLMF avec tes dépêches ! ;-)

le userland :p et un partenariat est en cours pour le patrick_g/Linux Magazine France et sera annoncé à Solutions Linux, où certains des admodérelecteurs/trices seront présent(e)s ;-)
- [^]Re: GNU/Linux Magazine France
  
  Posté par Phylyppe () le 27/02/2010 à 23:44. (lien). Évalué à 2.
  C'est bien, je me disais il va y avoir concurrence.
  - [^]Re: GNU/Linux Magazine France
    
    Posté par baud123 (Jabber id, page perso, ) le 28/02/2010 à 13:43. (lien). Évalué à 2.
    euh, c'est une boutade hein ;-) (d'où le smiley à la fin, je précise, certains esprits semblant prêts à s'échauffer ces derniers temps :D)

plus de net

Posté par n3os () le 25/02/2010 à 20:05. (lien). Évalué à 1.

Hello,

tiens plus de net avec RTL-8169 Gigabit Ethernet et son module r8169 en dur

sinon superbe description, sacré taf.

[^]Re: plus de net

Posté par benoar (Jabber id, ) le 26/02/2010 à 02:35. (lien). Évalué à 3.
Je ne sais pas de quel kernel tu viens, mais le firmware de cette carte a été enlevé du kernel pour le 2.6.32. Maintenant, il faut le charger de "l'extérieur".

[^]Re: plus de net

Posté par Grunt () le 26/02/2010 à 10:52. (lien). Évalué à 2.
Te plains pas, je suis bloqué en 2.6.30 à cause du RTL-8168

petite erreur sur UDP

Posté par gato () le 25/02/2010 à 20:55. (lien). Évalué à 2.

Une petite erreur s'est glissée dans le paragraphe parlant de la taille des datagrammes UDP : la taille utile (le MTU) est de 1500 octets pas 512.

[^]Re: petite erreur sur UDP

Posté par briaeros007 () le 25/02/2010 à 22:25. (lien). Évalué à 3.
oui et non.
1500 est la taille la plus couramment rencontré , au niveau réseau : c'est du 10/100 mbps classique (802.11 et tout le tremblement).
Avec une jumbo frame je peut monter, si j'ai des vlans je peux diminuer, si j'utilise des technos différentes je peux encore changer.

Mais la taille _minimale_ d'un datagramme udp est bien de 512 octet ( de tête).
Cad que si tu utilise UDP tu sais que si ton message fait 512 octets (alors avec ou sans les entêtes ? faut voir), il passera quelque soit le(s) réseau(x) en dessous
Ensuite, suivant les MTU que tu as sur ton réseau, tu prend la taille la plus faible pour que ca passe sans fragmentation* (flag DF dans le protocole IP, de base on ne fragmente pas en ipv6).

* le flag DF est obligatoirement mis pour le protocole TCP, il n'est pas forcément mis pour le protocole UDP.

--
Subete ga wakatta toki…watashi ga anta wo korosu.
- [^]Re: petite erreur sur UDP
  
  Posté par gato () le 26/02/2010 à 11:00. (lien). Évalué à 1.
  Le RFC1191 décrit le PMTU, y-a-t'il un rfc + récent ?
- [+] [^]Re: petite erreur sur UDP
  
  Posté par pasBill pasGates () le 26/02/2010 à 19:20. (lien). Évalué à -1.
  La taille minimal d'un paquet UDP c'est le header du L1 + header du L2 + header UDP et c'est tout il ny 'a pas de taille minimale a 512 octets. Tu peux avoir un paquet UDP qui fait de moins de 70 octets(sans payload), et ca peut monter jusqu'a 65535 bytes de payload (valeur maximale possible dans le champ 'length' du header) + les headers L1, L2 et UDP
  - [^]Re: petite erreur sur UDP
    
    Posté par briaeros007 () le 27/02/2010 à 09:59. (lien). Évalué à 1.
    je parlais de la taille minimale acceptée.
    Je me doute un poil (et je pense tout le monde ici) qu'on va pas faire du padding pour atteindre 512 octets lorsqu'on envoie un ack tcp ou autre.
    Dixit la rfc 791
    All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). [...] The number 576 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information. For example, this size allows a data block of 512 octets plus 64 header octets to fit in a datagram. The maximal internet header is 60 octets, and a typical internet header is 20 octets, allowing a margin for headers of higher level protocols.
    Avec 20 octets d'header IP et 8 octets d'header udp, on a suffisament d'espace pour mettre 512 octets de données.
    
    Par contre j'étais persuadé qu'il ne fragmentait pas à 576 octets. "caramba encore raté".
    
    --
    Subete ga wakatta toki…watashi ga anta wo korosu.

au sujet DNSSEC

Posté par steph1978 () le 25/02/2010 à 22:13. (lien). Évalué à 1.

> La taille d'un paquet UDP est de 512 octets

Pourquoi parle-t-on d'une taille de 512 octets alors que la longueur est codée sur 16bits permettant d'aller jusqu'à 65536 ?

[^]Re: au sujet DNSSEC

Posté par baud123 (Jabber id, page perso, ) le 25/02/2010 à 22:27. (lien). Évalué à 3.
on en avait parlé sur http://linuxfr.org/2010/02/12/26468.html effectivement, c'est peut-être mal formulé : il aurait fallu préciser que c'est les paquets pour DNS qui étaient limités à 512 octets :-)

.

Posté par Matthieu C () le 26/02/2010 à 00:30. (lien). Évalué à 3.

Merci pour ta super dépêche.

SystemTap ne risque pas de ce faire concurrencer par le système perf qui gère de plus en plus de chose (hw-breakpoint, kprobe, syscall trace, ...) ?

noyau 2.6.33 pourront profiter d'un pilote libre pour leurs cartes NVidia qui sera de meilleure qualité que le très limité et incompréhensible pilote nv
Perso nouveau est plus lent chez moi dans certain cas utilisation (fonte bitmap, firefox). Certaines lenteurs sont du au passage XAA vers EXA.
J'ai commencé à investiguer, mais j'ai pas eu le temps de trop creuser (par exemple un changement de tabulation dans firefox engendre un nombre impressionnant de memcpy pour lire des données du GPU dans le CPU).

Si votre noyau n'inclut pas KMS et que vous voulez profiter de Nouveau il va falloir songer à mettre à jour !
KMS c'est super violent, il faut mettre une grosse partie du driver X dans le kernel. Et aujourd'hui ce n'est pas fait pour l'overlay [1], du coup le rendu video n'est pas toujours au top.

[1] sauf pour les cartes intels (et encore avec des limitations) http://git.kernel.org/linus/02e792fbaadb75dec8e476a05b610e49(...)

[^]Re: .

Posté par Krunch (Jabber id, page perso, ) le 26/02/2010 à 22:41. (lien). Évalué à 3.
> SystemTap ne risque pas de ce faire concurrencer par le système
> perf qui gère de plus en plus de chose (hw-breakpoint, kprobe, syscall trace, ...) ?

Je sais pas trop pour les hw-breakpoint mais pour kprobe voir plus bas et pour autant que je sache, le traçage de syscalls se base pour le moment sur ptrace qui est plus limité que utrace.

Dans la dépêche on peut lire :
> SystemTap n'est pas dans la branche principale car je crois qu'il y a eu des
> désaccords fondamentaux sur son architecture entre les développeurs de la
> branche principale et ceux de systemtap.

Pour autant que je sache, SystemTap lui même est en userland, n'a donc aucune raison de faire partie de la branche principale du noyau et ses développeurs n'ont jamais tenté de l'intégrer. Par contre il s'appuie sur kprobe, utrace et uprobe. Comme indiqué, kprobe est dans la branche principale et SystemTap est donc parfaitement utilisable avec la branche principale pour tracer le noyau lui même.

Au final, si utrace et uprobe ne sont pas intégré mais qu'une alternative permettant de tracer le code userland est ajoutée au noyau, SystemTap sera sans doute modifié pour utiliser cela à la place.

Voir http://thread.gmane.org/gmane.linux.kernel.utrace/3258/

--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

Et un autre driver intéressant inclus dans ce 2.6.33

Posté par benoar (Jabber id, ) le 26/02/2010 à 02:44. (lien). Évalué à 2.

Pour tous les possesseurs de Mac PPC, sachez que Benjamin Herrenschmidt a inclus dans cette release son driver macio qui est le portage vers la "nouvelle" pile ATA (libata) de l'ensemble des drivers ATA (IDE) utilisés sur les PowerPC newworld (au moins ; je ne sais pas pour les autres).

Vu que l'ancienne pile va sûrement jarter un jour, c'est une bonne nouvelle pour cette archi qui se voit ainsi encore un peu considérée. Par contre, même si c'est un "simple" portage, testez !

Le vendredi, c'est permis \o/

Posté par Axioplase ıɥs∀ (page perso, ) le 26/02/2010 à 08:31. (lien). Évalué à 9.

>> Le système de fichiers Reiserfs est maintenant officiellement déclaré libéré de l'infâme verrou global du noyau (BKL).

Et l'infâme Reiser, lui, n'est pas encore libéré de derrière les verrous.

--
Je ne suis pas toujours de mon avis.

TRIM ?

Posté par Jokernathan () le 26/02/2010 à 09:08. (lien). Évalué à 1.

D'après l'article de silicon.fr le noyau 2.6.33 supporterait également la commande TRIM.
Si c'est vrai c'est une excellente nouvelle pour les possesseurs de disques SSD mais je suis surpris qu'on en parle si peu d'où mon léger scepticisme.

--
Mess with the best
Die like the rest

[^]Re: TRIM ?

Posté par patrick_g (page perso, ) le 26/02/2010 à 09:57. (lien). Évalué à 3.
J'en avait parlé un tout petit peu lors de la news du noyau 2.6.30 ou on voyait apparaître les premiers patchs. C'est vrai que le 2.6.33 ajoute le TRIM dans libata mais bon ça reste encore désactivé par défaut...et puis on ne peut pas parler de tout ;-)
- [^]Re: TRIM ?
  
  Posté par ElectronLibre () le 27/02/2010 à 14:09. (lien). Évalué à 1.
  Hello,
  
  Dis-moi, patrick_g, on a pas une idée approximative de quand TRIM sera mature/activé_par_défaut ?
  
  +
  - [^]Re: TRIM ?
    
    Posté par patrick_g (page perso, ) le 27/02/2010 à 15:27. (lien). Évalué à 2.
    Désolé, aucune idée.

DNSSEC et UDP

Posté par Yohann Lepage (Jabber id, page perso, ) le 26/02/2010 à 09:30. (lien). Évalué à 3.

Tout d'abord, merci pour cette news !

Il y a une petite erreur au niveau du paragraphe sur la transaction TCP par cookie : les paquets sont trop gros pour le protocole de transmission UDP qui est normalement utilisé par DNS. La taille d'un paquet UDP est de 512 octets alors qu'en moyenne DNSSEC exige 1749 octets.

A l'origine, l'UDP[0] était en effet limité à 512 octets. Cependant, cette limite a été augmenté depuis 12 ans avec l'EDNS0 ( Extension Mechanisms for DNS) [1] à 4096 octets. Le DNSSEC peut fonctionner uniquement avec UDP.

D'autre part, d'où sort cette moyenne de 1749 octets ? Ne confonds-tu pas avec ce thread : [dnsext] root DNSKEY response is 1749 bytes ?

0 :http://www.ietf.org/rfc/rfc1035.txt
1 :http://www.ietf.org/rfc/rfc2671.txt

[^]Re: DNSSEC et UDP

Posté par patrick_g (page perso, ) le 26/02/2010 à 09:49. (lien). Évalué à 2.
Dans le pdf indiqué en lien ("improving TCP security with robust cookies") on trouve ceci :

"Common DNSSEC-signed responses are as long as 1749 bytes. During key rollover, the response could be more than twice that size, much larger than the default UDP data size of 512 bytes".
- [^]Re: DNSSEC et UDP
  
  Posté par pasBill pasGates () le 26/02/2010 à 19:24. (lien). Évalué à 2.
  C'est pas la meme chose, c'est probablement une histoire de perf ce dont il parle :
  
  a) Un paquet UDP peut avoir jusqu'a 65'535 bytes de payload
  b) Cependant, dans la plupart des scenarios, UDP c'est des petits paquets, resultat j'imagine que l'allocation par defaut dans le kernel pour le buffer est de 512 bytes, et si le kernel doit refaire une passe car c'est un paquet plus gros que d'habitude, ca touche les perfs
  - [^]Re: DNSSEC et UDP
    
    Posté par briaeros007 () le 27/02/2010 à 10:04. (lien). Évalué à 3.
    a) Un paquet UDP peut avoir jusqu'a 65'535 bytes de payload
    Mais IP ne permet pas que udp ait autant de payload, vu que la taille minimal est de 65535, donc udp/ip c'est max 65515 octets.
    
    Cependant, dans la plupart des scenarios, UDP c'est des petits paquets,
    nfs, des petits paquets ?
    
    resultat j'imagine que l'allocation par defaut dans le kernel pour le buffer est de 512 bytes, et si le kernel doit refaire une passe car c'est un paquet plus gros que d'habitude, ca touche les perfs
    Je pense que les gens de dnssec en ont un poil rien a foutre du tuning de noyau, surtout si c'est pour les empecher de faire quelque-chose
    Comme précisé avant, les 512 octets sont définis dans une rfc et indique la taille minimale qu'un host est obligé d'accepté
    
    --
    Subete ga wakatta toki…watashi ga anta wo korosu.
    - [+] [^]Re: DNSSEC et UDP
      
      Posté par pasBill pasGates () le 27/02/2010 à 20:22. (lien). Évalué à -2.
      Mais IP ne permet pas que udp ait autant de payload, vu que la taille minimal est de 65535, donc udp/ip c'est max 65515 octets.
      
      Ben si, Ipv6 te permet un paquet de 4Gb avec l'option jumbo.
      
      nfs, des petits paquets ?
      
      En partie oui, ca et le fait qu'UDP soit principalement utilise pour du streaming et autres
      
      Je pense que les gens de dnssec en ont un poil rien a foutre du tuning de noyau, surtout si c'est pour les empecher de faire quelque-chose
      Comme précisé avant, les 512 octets sont définis dans une rfc et indique la taille minimale qu'un host est obligé d'accepté
      
      512 c'est la taille minimale de MTU qu'un poste doit accepter, mais le MTU c'est pas UDP qui le definit, c'est IP en fragmentant pour rentrer dedans. Bref, ca n'a aucun impact sur UDP.
      - [^]Re: DNSSEC et UDP
        
        Posté par briaeros007 () le 28/02/2010 à 23:58. (lien). Évalué à 2.
        En partie oui, ca et le fait qu'UDP soit principalement utilise pour du streaming et autres
        Je vois pas le lien avec nfs.
        Et les paquets lié a du rtp je peux t'assurer qu'ils sont tous sauf petit. J'en ai assé bouffé pour savoir q'une nal contenant des données c'est pas 200 octet.
        
        512 c'est la taille minimale de MTU qu'un poste doit accepter,
        Non, le MTU c'est du L2, Le 576 c'est du normatif L3 (IP).
        
        mais le MTU c'est pas UDP qui le definit, c'est IP en fragmentant pour rentrer dedans.
        Le MTU c'est la couche 2 qui le définis. IP ne fait que s'adapter aux liens qu'il a.
        Un routeur ne vas jamais fragmenté si il peut faire passer le paquet sans problème....
        Enfin peut etre que vos serveurs ISA le font, mais un vrai routeur ne le fera pas.
        Bref, ca n'a aucun impact sur UDP.
        Vu que la taille maximal* accepté par TOUS les postes est de 576 octets pour un paquet ip (fragmenté ou pas). ca veut dire que le payload maximal accepté par TOUS les postes est de 576-8-[20,64] bits.
        Ainsi cette taille a forcément un impact sur udp.
        
        Mais je présume que si il n'y a aucune raison que ca influe udp, alors que les serveurs dns ne devraient jamais envoyer des requets en disant "y'a pas toutes les infos, se connecter en tcp pour tout avoir" ?
        
        *: on est sur que si on envoie un paquet IP <= à 576 octet, alors il sera accepté. Au dessus, on n'est pas sur (en tout cas suivant la norme rfc 791).
        
        --
        Subete ga wakatta toki…watashi ga anta wo korosu.

[^]Re: DNSSEC et UDP

Posté par herodiade () le 27/02/2010 à 10:12. (lien). Évalué à 2.
A ce sujet, la dépêche omet de préciser que les problèmes de "perte" de certaines options TCP (MSS dans certains cas, SACK, ...) causée par les syncookies est (en gros) réglée depuis le noyau 2.6.26, grâce à un astucieux patch de Florian Westphal exploitant le tcp_timestamp pour stocker les quelques bits pertinents.

cf. http://lwn.net/Articles/277146/ et le commit 4dfc2817025965a2fc78a18c50f540736a6b5c24 , d'avril 2008.

L'inconvénient de cette méthode, c'est qu'elle ne suffira plus le jour où le besoin de stocker une nouvelle option tcp pertinente se fera sentir, qu'elle affecte le timestamp tcp initial, et qu'elle est un détail d'implémentation "linux only", pas une solution généralisable.

L'alternative TCPCT est bien entendu plus propre et permet en outre de ne pas avoir à conserver un état en mémoire pour distinguer les paquets out of band après fermeture d'une connexion (période TIME_WAIT). Mais elle ne sera une protection effective et généralisable contre les floods qu'à partir du moment où on pourra considérer que tout les clients la supportent (et ou on pourra légitimement rejeter tout paquet SYN non transactionnel).

Bref, activer les syncookies sur un noyau linux moderne est sans danger, et même plutôt prudent.

Ca decolle

Posté par Kévin FERRARE (page perso, ) le 26/02/2010 à 11:46. (lien). Évalué à 4.

Ces graphiques montrent quelque chose d'interessant je trouve
http://www.remword.com/kps_result/evolvement.php
Du 2.6.12 (mi 2005) au 2.6.33, donc en 4 ans 1/2, le nombre de contributeurs a triple et le nombre de lignes changees par release a ete multiplie par 10.
Ici, on vois que 75% des contributions proviennent d'entreprises.
http://lwn.net/Articles/373405/
Si le nombre d'entreprises et la quantite de leurs contributions a augmente si rapidement, c'est que linux est vraiment entrain de gagner du marche et d'interesser plus de monde, avec une progression importante.
Ca serait interessant d'avoir des donnes de ce genre pour les environnements de bureau.

Pas de news de fanotify ?

Posté par Hardy Damien () le 26/02/2010 à 12:02. (lien). Évalué à 1.

Hello,

Sur le dernier noyaux 2.6.32 E. Paris de chez redhat avait échoué à faire rentrer l'outil fanotify s'appuyant sur l'API fsnotify qu'il avait introduite dans le 2.6.31 (en récrivant inotify et dnotify à iso fonctionnalités sur cette API) qui permet de tracer les évènements d'un file system. (aujourd'hui impossible avec inotify/dnotify qui ne peuvent pas surveiller une hiérarchie de répertoire autrement qu'en ouvrant un file descriptor sur chaque répertoires de celle-ci)

A t'on des nouvelles de ce projet ? qui m'intéresse assez dans le cadre de la sauvegarde de gros file system et de la gestion de split-brain sur drbd master/master (qui entre donc dans le noyaux \o/ ce qui est une excellente nouvelle).

Merci pour cette news.

[^]Re: Pas de news de fanotify ?

Posté par patrick_g (page perso, ) le 26/02/2010 à 12:47. (lien). Évalué à 3.
Il a fait une tentative pour le 2.6.33 mais sa branche n'a pas été incluse : http://thread.gmane.org/gmane.linux.kernel/929510

On peut être certain qu'il va retenter sa chance pour le 2.6.34.

À propos du tracing

Posté par Dreamkey () le 26/02/2010 à 19:38. (lien). Évalué à 1.

Alors que quelques personnes se plaignent que la news est trop longue, je trouve que ça permet à des curieux comme moi de se tenir au courant des avancées du kernel de son OS préféré.
Par contre je n'ai pas compris l'utilité du tracing : c'est juste à des fins de monitoring ou c'est plus poussé (ce dont je suppose, mais je ne vois pas en quoi).
De plus il y a point de traçage statique et dynamique, quel sont les avantages/inconvénients de chacun ? Frédéric dit qu'"avoir des points de traçage statiques un peu partout dans le noyau n'enchantait pas grand monde dans la branche principale", mais pourquoi est-ce que maintenant ça ne les dérangent plus ?

Sinon autre chose, à propos des "régressions" : est-ce que c'est une manière élégante de dire "bugs" ? Dans la RC-8 il est traduit à propos de Linus qu'"un certain nombre de régressions devraient être corrigées et - même si la liste des régressions ne me rend pas _content_".
Cela veut dire que même s'il reste des bugs, le kernel est déclaré comme stable, car Linus ne veut pas avoir plus de 8 RC pour une nouvelle version d'un kernel, et qu'en extrapolant les version 2.6.33.X ne sont que des versions 2.6.33 RC(8+X) ?

[^]Re: À propos du tracing

Posté par Krunch (Jabber id, page perso, ) le 26/02/2010 à 22:18. (lien). Évalué à 2.
> Par contre je n'ai pas compris l'utilité du tracing : c'est juste à des fins de
> monitoring ou c'est plus poussé (ce dont je suppose, mais je ne vois pas en quoi).

Ça peut être utilisé pour du monitoring mais je vois plutôt ça comme un outil de debugging et d'aide au réglage de performances.

> De plus il y a point de traçage statique et dynamique, quel sont les
> avantages/inconvénients de chacun ?

Les points de traçage statiques sont définis par le développeur du code. Il va instrumenter explicitement ce qu'il pense pouvoir être intéressant. Les points de traçages dynamiques sont définis par l'utilisateur du code. Cela permet donc d'oberver des choses auxquelles on n'a pas pensé a priori mais ça nécessite une meilleure compréhension du système à observer.

D'un point de vu non développeur, en gros, pour utiliser les points de traçage dynamiques, tu fais des echo 1 > /proc/sys/whatever/debug alors que pour le dynamiques, il faut dire explicitement ce que tu veux observer au niveau du code.

> Sinon autre chose, à propos des "régressions" : est-ce que c'est une
> manière élégante de dire "bugs" ?

Une régression est un bug qui n'existait pas dans la version précédente (en admettant que la fonctionnalité concernée était déjà dans la version précédente). Quand l'utilisateur rencontre une régression, la nouvelle version marche moins bien que l'ancienne pour lui.

> Cela veut dire que même s'il reste des bugs, le kernel est déclaré comme
> stable, car Linus ne veut pas avoir plus de 8 RC pour une nouvelle version
> d'un kernel, et qu'en extrapolant les version 2.6.33.X ne sont que des versions
> 2.6.33 RC(8+X) ?

Je sais pas si c'est limité strictement à 8 rc pour Linux mais sortir une version sans bug connu n'est pas vraiment un but viable si tu veux espérer pouvoir ajouter des fonctionnalités.

--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

[^]Re: À propos du tracing

Posté par fweisbec () le 27/02/2010 à 10:36. (lien). Évalué à 6.
Concernant l'utilité du tracing, c'est effectivement très varié. Chaque famille de tracepoint prend son sens dans un contexte différent. C'est aux developpeurs de leur donner du sens en écrivant les outils adaptés.

Prends par exemple les tracepoints de l'ordonnaceur de tâche. On a les suivants:
- context switch (tache A dort, tâche B prend la main)
- wakeup (tache A est mise en état "runnable")
- migrate (tache A est migrée du CPU x à CPU y)

Avec ça on peut analyser énormément de choses. On a un outil dans perf events qui s'appele "perf sched". Avec ça on peut tracer la latence de l'ordonnanceur: le temps maximum/moyen pour qu'une tâche, prête à être executée, est finalement executée. On pourrait aussi analyser l'efficacité des décisions de migration. Imagine que sur le CPU 0 on ait quatre tâches qui se battent en duel, et sur le CPU 1 une seule. Si cet état dure trop longtemps, ça signifie qu'il y a un soucis. Les tracepoints permettent d'analyser ce genre de comportement.

Mais le tracing peut aussi être utilisé pour du débuggage. Imagine que tu as un bug en ouvrant un fichier et que tu as besoin de voir quel chemin a été pris par le code.
Tu peux utiliser le function graph tracer pour determiner ce qui se passe à chaque appel de open:

# cd /debug/tracing/
# echo sys_open > set_graph_function
# echo function_graph > current_tracer
# less trace

0) | sys_open() {
0) | do_sys_open() {
0) | getname() {
0) 1.028 us | kmem_cache_alloc();
0) 0.924 us | strncpy_from_user();
0) 5.309 us | }
0) | alloc_fd() {
0) 1.028 us | _raw_spin_lock();
0) 0.991 us | expand_files();
0) 0.886 us | _raw_spin_unlock();
0) 6.931 us | }
0) | do_filp_open() {
0) | get_empty_filp() {
0) 1.622 us | kmem_cache_alloc();
0) | security_file_alloc() {
0) 0.804 us | cap_file_alloc_security();
0) 2.598 us | }
0) 9.536 us | }
0) | do_path_lookup() {
0) | path_init() {
0) 0.901 us | _raw_read_lock();
0) 0.991 us | _raw_read_unlock();
0) 4.994 us | }

Et là tu vois exactement ce qui se passe.

De plus il y a point de traçage statique et dynamique, quel sont les avantages/inconvénients de chacun ?

Les tracepoints statiques sont placés sur des endroits très stratégiques, pertinents pour le sous système en question. Ils permettent de couvrir la majorité des besoins de tracing.
Si quelqu'un veut observer un point moins stratégique, aller plus en profondeur, il peut définir un tracepoint dynamique.

Les statiques sont aussi plus "puissants" dans les données qu'ils peuvent remonter. On peut leur demander de déréférencer des pointeurs, observer des données à l'intérieur d'une structure...on peut leur demander de remonter tout ce qu'on veut en fait.

Les dynamiques n'ont pas encore cette puissance. On peut leur demander d'afficher quelques variables, pourvu qu'il s'agisse de simples entiers ou adresses. Mais déréférencer des pointeurs, on y est pas encore.

Donc les statiques sont plus puissants et précis dans les données qu'ils peuvent remonter, tandis que les dynamiques sont plus puissants dans le fait qu'ils peuvent être placés un peu n'importe où.

frédéric dit qu'"avoir des points de traçage statiques un peu partout dans le noyau n'enchantait pas grand monde dans la branche principale", mais pourquoi est-ce que maintenant ça ne les dérangent plus ?

Parce qu'avant, placer un tracepoint ne faisait que placer un tracepoint :-) C'est à dire que du code noyau pouvait demander à observer ce tracepoint etc...mais il n'y avait pas encore de code qui faisait ça.

Aujourd'hui, quand tu ajoutes un tracepoint, il est directement utilisable par le biais des outils de perf events, ou par debugfs. Tu peux l'activer/désactiver en passant par un fichier. Récupérer ses données formatées en ascii ou directement en binaire. Tu peux filter en utilisant des expressions conditionelles. Générer des scripts python/perl automatiquement pour les analyser, modifier ces scripts, etc....

Donc aujourd'hui, ils sont considérés comme utiles directement.

Sinon autre chose, à propos des "régressions" : est-ce que c'est une manière élégante de dire "bugs" ?

Quand quelque chose fonctionnait, et que soudain du nouveau code casse ce qui fonctionnait, ça s'appelle une regression. C'est le type de bug le plus redouté (avec les trous de sécurité)
- [^]Re: À propos du tracing
  
  Posté par Krunch (Jabber id, page perso, ) le 27/02/2010 à 11:35. (lien). Évalué à 3.
  > Les dynamiques n'ont pas encore cette puissance. On peut leur demander d'afficher
  > quelques variables, pourvu qu'il s'agisse de simples entiers ou adresses.
  > Mais déréférencer des pointeurs, on y est pas encore.
  
  stap -g peut déréférencer des pointeurs et faire ce que tu veux en C dynamiquement sans que le développeur initial ait eu à placer un tracepoint statique.
  
  http://sourceware.org/systemtap/langref/Components_SystemTap(...)
  
  Cela est possible dès à présent avec le noyau de la branche principale (mais uniquement pour instrumenter le noyau lui même, pour observer l'userland il faut utrace/uprobe).
  
  > Donc les statiques sont plus puissants et précis dans les données qu'ils peuvent
  > remonter, tandis que les dynamiques sont plus puissants dans le fait qu'ils peuvent
  > être placés un peu n'importe où.
  
  Non, les statiques sont moins puissants parce qu'ils sont limités à ce que le développeur initial a prévu. Les dynamiques sont plus puissants parce qu'ils permettent d'observer tout et n'importe quoi mais ils sont potentiellement plus compliqués à utiliser puisqu'il faut se familiariser avec le code à tracer.
  
  --
  Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
  pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
  - [^]Re: À propos du tracing
    
    Posté par fweisbec () le 27/02/2010 à 12:09. (lien). Évalué à 2.
    stap -g peut déréférencer des pointeurs et faire ce que tu veux en C dynamiquement sans que le développeur initial ait eu à placer un tracepoint statique.
    
    System tap en fait peut être une exploitation plus poussée oui. Mais dans la branche principale, c'est pas encore le cas.
    
    Non, les statiques sont moins puissants parce qu'ils sont limités à ce que le développeur initial a prévu. Les dynamiques sont plus puissants parce qu'ils permettent d'observer tout et n'importe quoi mais ils sont potentiellement plus compliqués à utiliser puisqu'il faut se familiariser avec le code à tracer.
    
    De ce côté là oui, les statiques sont moins puissants, je n'ai pas dit le contraire.
    Mais les dynamique n'atteindront jamais la puissance des statiques en ce qui concerne les données à sortir.
    
    Par exemple on a un tracepoint statique pour les évenements où un inode devient "dirty".
    Pour retrouver le nom de l'inode, on a besoin de le vérrouiller, d'appeler une fonction pour chercher le dentry correspondant, de faire des copies, de déverrouiller et enfin de décrémenter son compteur de référence.
    
    Impossible avec un tracepoint dynamique.
    Il n'ont pas le même usage ni le même rôle, tout simplement.
    - [^]Re: À propos du tracing
      
      Posté par Krunch (Jabber id, page perso, ) le 27/02/2010 à 12:40. (lien). Évalué à 2.
      >> stap -g peut déréférencer des pointeurs et faire ce que tu veux en
      >> C dynamiquement sans que le développeur initial ait eu à placer un tracepoint statique.
      > System tap en fait peut être une exploitation plus poussée oui.
      > Mais dans la branche principale, c'est pas encore le cas.
      
      Pour autant que je sache, stap -g fonctionne avec la branche principale sans soucis tant que tu ne veux instrumenter que du code noyau.
      
      > Pour retrouver le nom de l'inode, on a besoin de le vérrouiller, d'appeler une fonction
      > pour chercher le dentry correspondant, de faire des copies, de déverrouiller et enfin
      > de décrémenter son compteur de référence.
      >
      > Impossible avec un tracepoint dynamique.
      
      C'est tout à fait possible mais ça devient effectivement assez compliqué et si un tracepoint statique existe pour cela, c'est bien évidemment préférable.
      
      > Il n'ont pas le même usage ni le même rôle, tout simplement.
      
      On est d'accord.
      
      --
      Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
      pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
      - [^]Re: À propos du tracing
        
        Posté par fweisbec () le 27/02/2010 à 13:03. (lien). Évalué à 1.
        > Pour autant que je sache, stap -g fonctionne avec la branche principale sans soucis tant que > tu ne veux instrumenter que du code noy
        
        Oui, mais SystemTap n'est pas intégré dans la branche principale.
        Et il semble être encore loin de l'être!
        
        >> Pour retrouver le nom de l'inode, on a besoin de le vérrouiller, d'appeler une fonction
        >> pour chercher le dentry correspondant, de faire des copies, de déverrouiller et enfin
        >> de décrémenter son compteur de référence.
        >>
        >> Impossible avec un tracepoint dynamique.
        >
        > C'est tout à fait possible mais ça devient effectivement assez compliqué et si un tracepoint
        > statique existe pour cela, c'est bien évidemment préférable.
        
        Ben je vois pas du tout comment ça peut être possible. Il faudrait passer par un script du genre systemtap, mais Systemtap ne va pas jusqu'à pouvoir verrouiller des spinlocks aléatoires ou autres trucs du style. Et puis heureusement d'ailleurs, ça dépasserait vraiment le cadre des tracepoints dynamiques.
        
        [^]Re: À propos du tracing
        
        Posté par Krunch (Jabber id, page perso, ) le 27/02/2010 à 20:06. (lien). Évalué à 2.
        > Oui, mais SystemTap n'est pas intégré dans la branche principale.
        > Et il semble être encore loin de l'être!
        
        SystemTap n'a aucune raison d'être intégré à Linux. C'est que de l'userland. Par contre SystemTap utilise kprobe, utrace et uprobe. S'il n'y a que kprobe, il ne sait que tracer le kernel, ce qui est déjà pas mal.
        
        Voir https://linuxfr.org/comments/1108519.html#1108519 et http://thread.gmane.org/gmane.linux.kernel.utrace/3258/
        
        > Systemtap ne va pas jusqu'à pouvoir verrouiller des spinlocks aléatoires ou
        > autres trucs du style.
        
        stap -g permet d'injecter du code C arbitraire. Donc tu fais *vraiment* ce que tu veux (y compris n'importe quoi).
        
        > Et puis heureusement d'ailleurs, ça dépasserait vraiment le cadre des tracepoints dynamiques.
        
        On est d'accord que le cas que tu cites est plus adapté à un tracepoint statique. Mais si ce tracepoint n'existe pas et que tu ne peux pas te permettre de recompiler le noyau, stap -g permettrait de le faire aussi. Évidemment c'est pas forcément une bonne idée mais c'est faisable.
        
        --
        Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
        pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
        
        [^]Re: À propos du tracing
        
        Posté par fweisbec () le 28/02/2010 à 20:42. (lien). Évalué à 2.
        > SystemTap n'a aucune raison d'être intégré à Linux. C'est que de l'userland. Par contre
        > SystemTap utilise kprobe, utrace et uprobe. S'il n'y a que kprobe, il ne sait que tracer le
        > kernel, ce qui est déjà pas mal.
        
        Systemtap veut être intégré dans Linux (j'entends par là utrace et uprobe) car maintenir des patchs kernel out-of-tree ça demande beaucoup de temps de maintenance, de gestion des versions, etc...
        
        Aussi, il y a du code userland dans Linux, comme le repertoire tools/ qui heberge les outils clients pour perf events. Ca permet d'avoir un developpement très synchronisé avec les évolutions de Linux. Là encore Systemtap aurait probablement interêt à avoir un repertoire tools/stap.
        
        > stap -g permet d'injecter du code C arbitraire. Donc tu fais *vraiment* ce que tu veux (y
        > compris n'importe quoi).
        
        Ah, ok je savais pas.
        
        > On est d'accord que le cas que tu cites est plus adapté à un tracepoint statique. Mais si ce
        > tracepoint n'existe pas et que tu ne peux pas te permettre de recompiler le noyau, stap -g
        > permettrait de le faire aussi. Évidemment c'est pas forcément une bonne idée mais c'est
        > faisable.
        
        Wep.
        
        [^]Re: À propos du tracing
        
        Posté par Krunch (Jabber id, page perso, ) le 28/02/2010 à 21:33. (lien). Évalué à 2.
        > Systemtap veut être intégré dans Linux (j'entends par là utrace et uprobe) car
        > maintenir des patchs kernel out-of-tree ça demande beaucoup de temps de
        > maintenance, de gestion des versions, etc...
        
        Effectivement, utrace et uprobe sont des candidats à l'intégration et ils sont loin d'être acceptés. Ce qui semble probable, c'est qu'à terme il y aura de quoi tracer l'userland dans la branche principale. Si un autre système que uprobe/utrace est intégré pour cela (possiblement une amélioration de ptrace), SystemTap sera sans aucun doute modifié pour utiliser ce mécanisme.
        
        > Aussi, il y a du code userland dans Linux, comme le repertoire tools/ qui heberge les
        > outils clients pour perf events. Ca permet d'avoir un developpement très synchronisé
        > avec les évolutions de Linux. Là encore Systemtap aurait probablement interêt à avoir
        > un repertoire tools/stap.
        
        Je pense pas que ça soit un des buts du projet SystemTap pour le moment mais je peux me tromper (et dans ce cas, je suis intéressé par les threads correspondants). Si tu lis le thread que j'ai donné plus haut [0], il est dit que les changements requis dans SystemTap pour s'adapter au noyau sont de l'ordre de quelques uns par an. Je suis conscient que maintenir du code noyau hors de la branche principale est normalement un gros travail mais dans le cas de l'userland SystemTap, ça ne s'applique pas vraiment (mais pour uprobe/utrace bien).
        
        [0] http://article.gmane.org/gmane.linux.kernel/942001
        
        --
        Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
        pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

device-mapper : snapshot

Posté par ElectronLibre () le 26/02/2010 à 20:13. (lien). Évalué à 0.

Hi guys,

J'ai vraiment envie de faire joujou avec des FS chiffrés en LVM2 RAID5, mais je ne trouve pas de HOWTO sur comment faire des snapshots avec device-mapper.

Est-ce que c'est encore "trop nouveau" pour qu'il y ait de la littérature ?

Autre petite question, je ne me souviens plus comment compiloner avec plusieurs thread (--enable-threads). Je ne trouve pas comment demander à Make de le dire dans le Makefile. Et je n'ai pas l'impression, en regardant le System Monitor, que mes 8 threads soient exploités.

+

[^]Re: device-mapper : snapshot

Posté par baud123 (Jabber id, page perso, ) le 26/02/2010 à 20:30. (lien). Évalué à 2.
je ne me souviens plus comment compiler avec plusieurs threads

make -j 16
- [^]Re: device-mapper : snapshot
  
  Posté par ElectronLibre () le 27/02/2010 à 07:08. (lien). Évalué à 0.
  Merci,
  
  --jobs=16, ça change tout !
  
  Si quelqu'un connait un site qui parle du snapshot device-mapper je suis preneur. Je vais me tapper la doc du noyal, mais un site qui en parle d'un point de vue utilisateur est toujours le bienvenu.
  
  +

Félicitation

Posté par dedesite () le 27/02/2010 à 11:29. (lien). Évalué à 3.

Un GRAND merci à toi patrick_g pour cette merveilleuse dépêche. C'est toujours extrêment intéressant de lire tout se qui se trame lors du développement/merge d'un projet aussi important (en terme de nombre de participants et d'utilisateurs/utilisation) que Linux.
J'ai beaucoup apprécié cette nouvelle partie "interview" et j'espère qu'il y en aura d'autre dans le futur. Le fait d'avoir un regard "interne" sur les problèmes apporte une meilleure compréhension je trouve.

Je ne suis pas forcément fan de tout ce qui est bas niveau, mais étant moi même développeur (dans le jeu vidéo), j'aime tout de même comprendre un minimum ce qui se passe au niveau noyau. Je considère tes dépèche comme des petits cours et j'ai beaucoup sur le fonctionnement d'un noyau grâce à elles. Continue comme ça!!

Andréas

erreur au linkage ?

Posté par Guillaume Revaillot (page perso, ) le 01/03/2010 à 12:39. (lien). Évalué à 3.

Petite erreur dans l'interview de Frédéric Weisbecker : on parle de LTTng, qui serait maintenu par un étudiant de Polytech Montréal, alors que le lien pointe vers le site de l'ETS, une autre école Montréalaise. Le lien correct est http://www.polymtl.ca/ .

[^]Re: erreur au linkage ?

Posté par patrick_g (page perso, ) le 01/03/2010 à 13:56. (lien). Évalué à 2.
Corrigé merci.

Erratum

Posté par murphy2712 () le 02/03/2010 à 17:59. (lien). Évalué à 1.

"Son message explique bien, avec son ton inimitable, qu'elle est sa position"
=> "quelle est sa position"

[^]Re: Erratum

Posté par patrick_g (page perso, ) le 02/03/2010 à 20:06. (lien). Évalué à 2.
Raaahhh...mais ça n'en finira jamais ;-)
Corrigé. Merci de la remarque.

module ath5k

Posté par Jllc () le 03/03/2010 à 21:37. (lien). Évalué à 1.

Est-ce qu'il y en a ici qui utilise le module ath5k pour leur carte wifi Atheros ?

Ça fait plusieurs versions que je n'arrive plus à la faire fonctionner (et encore, sur le 2.6.27.x que j'utilise, c'est avec un débit catastrophique). J'ai vu dans le Changelog de ce 2.6.33 que ce module avait subis pas mal d'évolutions, mais après recompilation et reboot, ça ne marche pas mieux. J'arrive bien à voir les réseaux wifi du coin, mais impossible de me connecter à ma box.

Revenir en haut de page

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : Nouvelle version 2.6.33 du noyau Linux

Le sommaire...

La phase de test (↑)

RC-1

RC-2

RC-3

RC-4

RC-5

RC-6

RC-7

RC-8

Les nouveautés (↑)

Stockage distribué DRBD

Transaction TCP par cookie

Compactage mémoire ramzswap

Contrôleur IO-Block

Les pilotes Android retirés du noyau

Intégration de Nouveau

En bref (↑)

Le bilan en chiffres (↑)

Questions/Réponses avec Frédéric Weisbecker (↑)

Pour la suite (↑)

Ceph

AlacrityVM

CFS/CFQ

[^]Re: CFS/CFQ

[^]Re: CFS/CFQ

[^]Re: CFS/CFQ

[^]Re: CFS/CFQ

[^]Re: CFS/CFQ

[^]Re: CFS/CFQ

[^]Re: CFS/CFQ

[^]Re: CFS/CFQ

[^]Re: Autres coquilles

[^]Re: Autres coquilles

[^]Re: Autres coquilles

[^]Re: Autres coquilles

[^]Re: Autres coquilles

[^]Re: Autres coquilles

[^]Re: Autres coquilles

[^]Re: Autres coquilles

RCU

Obtenir un boulot via LKML

L'ordonnanceur stabilisé et mur ?

[^]Re: L'ordonnanceur stabilisé et mur ?

[^]Re: L'ordonnanceur stabilisé et mur ?

[^]Re: L'ordonnanceur stabilisé et mur ?

Super article

[^]Re: Super article

[^]Re: Super article

[^]Re: Super article

[^]Re: Super article

[^]Re: Super article

[^]Re: Super article

[^]Re: Super article

[^]Re: Super article

[^]Re: Super article

[^]Re: Super article

[^]Re: Super article

[^]Re: Super article

Questions aux lecteurs

[^]Re: Questions aux lecteurs

[+] [^]Re: Questions aux lecteurs

[+] [^]Re: Questions aux lecteurs

[^]Re: Questions aux lecteurs

[^]Re: Questions aux lecteurs

[^]AOMTP

[^]Re: AOMTP

[^]Re: Questions aux lecteurs

[^]Re: Questions aux lecteurs

[^]Re: Questions aux lecteurs

[^]Re: Questions aux lecteurs

[^]Re: Questions aux lecteurs

[^]Re: Questions aux lecteurs

[^]Re: Questions aux lecteurs

[^]Re: Questions aux lecteurs