Les développeurs de Google sont toujours à la recherche de solutions permettant d'améliorer la sécurité du navigateur web Google Chrome (ou son implémentation libre Chromium), ou de leur projet ChromeOS. Dans la dépêche à ce sujet, je vous avais raconté leur participation au projet Capsicum, qui apporte une gestion très fine des privilèges d'un processus, maintenant intégré dans FreeBSD.

Bien que les techniques mises en place par Capsicum soient pensées pour tous les systèmes inspirés d'UNIX, il n'y a pas grand espoir aujourd'hui qu'un port Linux soit accepté par les développeurs noyau ; Capsicum est un projet externe qu'il faudrait d'abord intégrer, ré-exprimer en terme des fonctionnalités existantes dans le noyau ; et les mainteneurs sont notoirement mécontents de la multiplication des solutions de sécurité (les Linux Security Modules en particulier) et ne verraient pas d'un bon œil l'apparition d'un nouveau candidat. Les développeurs Chromium utilisent sous Linux le primitif système de sandboxing seccomp, bien qu'il soit beaucoup moins flexible que Capsicum et donc nettement plus pénible et difficile à utiliser.

Depuis 2009, les développeurs Chrome essaient d'étendre les capacités de seccomp pour mieux répondre à leurs besoins. Les changements se sont révélés beaucoup plus difficiles à faire accepter que prévu : la situation a semblé bloquée à de nombreuses reprises et n'a pas évolué pendant de nombreux mois. Après plusieurs tentatives infructueuses, Will Drewry vient de proposer une nouvelle approche qui pourrait obtenir l'approbation des développeurs noyau ; mais rien n'est encore gagné…

Wolfgang Draxinger a lancé le projet KLANG. Il ambitionne d'écrire un nouveau gestionnaire audio pour les noyaux Linux et FreeBSD avec un rendu professionnel :

• sans hachure,
• avec un minimum de latence
• et avec une gestion intelligente de l'énergie.

Alors que l'information est en train de se répandre sur la toile, l'auteur met en garde : bien qu'un site décrivant les ambitions du projet existe, le code n'est pas encore dans un état acceptable pour une première version publique.

La sortie de la version stable 2.6.37 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 CC BY-SA).

PS : Outre mes camarades relecteurs/modérateurs je tiens particulièrement à remercier davy78 qui a bien voulu accepter de relire longuement la dépêche pour traquer les fautes et me permettre de les corriger.

La sortie de la version stable 3.16 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org. Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.

Le titre est accrocheur, mais les faits sont encore plus incroyables. Juste avant le FOSDEM 2014, Alexandre Courbot, un développeur de chez NVIDIA, a envoyé une suite de 16 correctifs pour ajouter la gestion des Tegra K1 dans Nouveau, le pilote libre communautaire pour les cartes graphiques NVIDIA.

NdM : Pour la bonne compréhension du ton enthousiaste de cette dépêche, précisons que son auteur est un des principaux développeurs de Nouveau.

Linus Torvalds, dictateur bienveillant et grand protecteur du noyau Linux, envisage de mettre à disposition le noyau 2.6.40 sous la dénomination 2.8.0, voire 3.0, comme suggéré par Ingo Molnar.

Depuis la sortie du noyau 2.6.0 en décembre 2003, nous avons pu assister à l’évolution de notre noyau spheniscidé tout au long de ses 40 versions successives. Toute cette évolution s’est faite en suivant un protocole bien rodé, comprenant des cycles de développement de 8 à 12 semaines.

Le cycle de développement commence avec la mise à disposition d’un noyau stable numéroté 2.6.x, suivi d’une fenêtre d’intégration de deux semaines. Cette fenêtre est l’occasion pour les développeurs de proposer tous les patches introduisant de nouvelles fonctionnalités aux différents mainteneurs du noyau.

Ensuite commence la longue route de la stabilisation. Au gré des messages attendus et parfois redoutés de ce pragmatique néo‐Américain qu’est Linus Torvalds, nous voyons apparaître environ 8 versions candidate (RC). À ce stade du développement, n’essayez pas d’introduire la moindre petite fonctionnalité ou le moindre petit pilote, ou il vous en cuira, et chacun pourra suivre sur la liste de diffusion du noyau Linux (LKML) votre admonestation par le sieur Torvalds.

Enfin, lorsque la RC semble suffisamment stable, Linus Torvalds lâche le noyau 2.6.(x + 1) dans la nature, et un nouveau cycle peut recommencer.

Mais cette fois, quelque chose de différent risque d’arriver : le nouveau noyau passera à la version 2.8 ou 3.0 ! Concrètement, quelle est la raison de ce changement de numérotation ? Quelles nouvelles fonctionnalités révolutionnaires, quel changement d’API et quelle grande réécriture du code entraîne ce passage à une version 2.8 ? Rien. Linus nous fait juste savoir dans un post scriptum, que des voix dans sa tête lui ont dit que 40, c’est grand, et donc qu’il faut passer à une version supérieure.

Néanmoins, il ne faut pas s’y tromper. Le mode de développement du noyau, qui se fait de manière progressive, pas après pas, a engendré des changements énormes depuis la 2.6.0. Donc, même si ce noyau s’inscrira dans la continuité du 2.6.39, ça permettra sans doute aussi de satisfaire notre besoin de discriminer de grandes étapes du développement linuxien, et de pouvoir s’asseoir devant son PC d’ici quelques mois en se disant « Ouah, j’utilise la nouvelle génération de noyaux Linux ! ». Et rien que ça ravira les geeks du monde entier au plus profond de leur cerveau reptilien.

À chaque fois que je lis les dépêches LinuxFr.org sur le nouveau noyau ou bien les nouvelles de Phoronix, je m’empresse de regarder les avancées des pilotes graphique libres. Et souvent, je vais sur la page Mesa traçant les évolutions de l’implémentation d’OpenGL. Mais je trouve difficile de suivre où en est réellement la progression de cette adaptation dans Mesa et de ses différents pilotes graphiques qui en dépendent. C’est pourquoi j’ai décidé de faire un script qui parcourt ce fichier et l’affiche de manière plus intelligible.

 http://mesamatrix.net/

Si vous adorez suivre la course qui se tient entre Mesa et OpenGL, et que vous allez souvent voir quelles sont les nouvelles extensions OpenGL qui ont été implémentées et pour quels pilotes, ça pourrait vous intéresser ! Plus d’explications dans la suite de la dépêche.

Greg Kroah-Hartman est le mainteneur de la branche -stable du noyau Linux. Dans son annonce du 2.6.32.58, il a indiqué qu'il passait la main à Willy Tarreau pour veiller sur cette branche 2.6.32 et il vient de publier une rétrospective très intéressante à propos de ce noyau.

NdM : merci à patrick_g pour son journal.

Depuis sa version 2.6.38, le noyau Linux est atteint d’une régression sur la consommation d’énergie. Sur certaines configurations matérielles, la consommation pouvait augmenter jusqu’à 25 %.

Suite à différents tests, notamment de la part de Michael Larabel de Phoronix (il s’en est d’ailleurs largement entretenu dans beaucoup d’articles), il a été identifié que c’était à la suite d’un correctif du noyau que la régression était apparue. La norme PCI Express a introduit l’ASPM (Active State Power Management), un moyen pour diminuer la consommation des périphériques, mais qui n’est pas toujours pris en charge.

C’est le BIOS qui est censé exposer au noyau la configuration, seulement ce n’est pas toujours fait, car les fabricants passent outre avec leur pilote Windows et ne s’en tracassent pas le moins du monde. Avant le noyau 2.6.38, l’option était activée sur toutes les configurations, mais comme cela peut poser de sérieux problèmes, la vérification du BIOS a été introduite… Et là, c’est le drame !

Un patch a été créé en se basant sur des explications de Microsoft concernant l’implémentation de l’ASPM dans Windows Vista, afin de détecter si réellement le système peut activer cette option sans risque. Et ça a l’air de fonctionner. Comme la fenêtre d’intégration pour le noyau 3.2 a été fermée, il faudra attendre le 3.3 avant de voir ce patch arriver.

Depuis l'arrivée de l'ordonnanceur de processus CFS dans le noyau Linux (2.6.23) et la généralisation des processeurs multi-coeurs, plusieurs projets cherchent à améliorer la réactivité du noyau Linux, notamment pour un environnement bureau. En septembre 2009, Con Kolivas a écrit un nouvel ordonnanceur appelé BFS (Brain Fuck Scheduler). En le comparant à CFS, des bugs ont été isolés puis corrigés dans CFS. Par exemple, un test avec le codec x264 a montré que BFS était 80% plus rapide : le bug a été isolé puis corrigé par Mike Galbraith (lire Open source collaboration done right). Depuis, Con Kolivas continue d'écrire des patchs pour améliorer la réactivité.

Plus récemment, ce même Mike Galbraith a proposé un patch sur la LKML le 19 octobre 2010 pour regrouper automatiquement les tâches par terminal (TTY). Suite aux critiques d'autres développeurs, il a écrit une deuxième, puis une troisième version de son patch. Linus en personne s'est réjoui qu'un si petit patch, non intrusif, soit capable d'améliorer autant l'interactivité. Le lendemain, un article paru sur Phoronix montre en vidéo le gain notable en utilisant un cas de test similaire à celui de Linus : lancer une compilation du noyau avec make -j64 (lance 64 tâches de compilation en parallèle) dans un terminal, tout en utilisant un bureau : navigateur web et lecture de vidéo en HD.

Le patch améliore l'interactivité en distribuant le temps de processeur plus équitablement du point de vue de l'utilisateur. Il utilise les cgroups (groupe de tâches) introduits dans le noyau 2.6.24 (janvier 2008) pour l'ordonnanceur CFS. CFS permet de définir le pourcentage de temps assigné à un cgroup. Cette fonctionnalité révolutionnaire a été un peu oubliée car la création des cgroup était manuelle. Le patch de Mike propose de créer automatiquement un cgroup par TTY, et permet donc de mettre en application simplement le travail sur CFS et les cgroups. Con Kolivas a néanmoins critiqué le patch sur son blog en expliquant qu'il introduit des régressions dans les cas d'utilisation « normaux ».

Proposé après la fenêtre de tir du noyau 2.6.37, l'avenir nous dira si ce patch va être intégré ou non dans le noyau 2.6.38. Plus généralement, ces différents projets devraient à terme améliorer la réactivité de nos environnements de bureaux sous Linux.

NdM : Merci à Poloh d'avoir proposé une dépêche sur le même sujet et insert_coincoin pour son journal en lien ci-dessous.