Linuxfr

Syndiquer le contenu
Mis à jour : il y a 30 min 57 sec

[ZOL] - ZFS On Linux 0.6.3 released

sam, 14/06/2014 - 12:55

La version 0.6.3 de ZOL (ZFS On Linux) vient fraîchement d'être mise à disposition. Bien que n'ayant que peu communiqué (sur la liste de discussion en tout cas), depuis la dernière version sortie en août 2013, les développeurs du projet n'ont pas chômé puisqu'il y a eu près de 200 corrections de bugs et de nombreuses fonctionnalités ajoutées au projet avec notamment : la compatibilité pour les noyaux Linux <= 3.14, la comptabilité avec les ACL POSIX et un nouvel outil de supervision dédié le ZED daemon.

Fonctionnalités clés :

  • Compatible avec les noyaux Linux jusqu'à la version 3.14.
  • Meilleure gestion du ralentissement en écriture pour maintenir les performances lors d'un forte charge.
  • Cache plus intelligent pour améliorer le taux d'accès à certains niveaux de charges.
  • Gestion des ACL type Posix.
  • Gestion des attributs immutable : les ajouts seuls sur les fichiers.
  • Possibilité de monter les systèmes de fichiers avec mise à jour à chaud.
  • Intégration SELinux à travers quatre nouveaux ensembles de propriétés.
  • Support de systemd.
  • Apparition du ZFS Event Daemon (ZED) pour gérer et surveiller.
  • Gestion des architectures arch64 et sparc64.
  • Beaucoup d'amélioration de performances.
  • Plus de 200 bug corrigés.
Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Conférence Transformer et enrichir vos données avec OpenRefine (Mons, BE)

sam, 14/06/2014 - 09:04

Ce jeudi 19 juin 2014 à 19h se déroulera la 30ème séance montoise des Jeudis du Libre de Belgique.

Le sujet de cette séance : Transformer et enrichir vos données avec OpenRefine

Thématique : Traitement des données
Public visé : chefs de projet | entreprises | développeurs | étudiants
Animateur conférencier : Max De Wilde (ULB)

Description : Quel que soit le domaine d’application (scientifique, culturel, financier, biopharma, etc.), manipuler de gros volumes de données implique inévitablement une déperdition de leur qualité, surtout quand ces données ont été encodées par de nombreuses personnes, dans plusieurs langues et/ou sur un long laps de temps.

OpenRefine est un outil interactif de transformation qui permet de diagnostiquer les problèmes de qualité dans un jeu de données et de les corriger dans la foulée, ainsi que d’enrichir les données sémantiquement.

Cette présentation abordera successivement les points suivants :

  • Big Data vs Data Quality ou comment concilier quantité et qualité ?
  • De Google Refine à OpenRefine : historique d’un projet cédé à la communauté
  • Raffinement des données : du minerai brut au diamant pur
  • Vers un web de données : liaison avec le Linked Data Cloud
  • La représentation des connaissances, un enjeu économique et politique

Les différentes fonctionnalités du logiciel seront illustrées à l’aide d’une collection de données ouvertes issues du domaine muséal, mais suivant une méthodologie applicable à n’importe quel autre domaine. Les retombées opérationnelles de l’utilisation d’OpenRefine seront illustrées à travers le projet Free Your Metadata (freeyourmetadata.org).

Lieu de cette séance : HEPH Condorcet, Chemin du Champ de Mars, 15 – 7000 Mons – Auditorium 2 situé au rez de chaussée (cf. ce plan sur le site d’OpenStreetMap; ATTENTION, l’entrée est peu visible de la voie principale, elle se trouve dans l’angle formé par un très grand parking).

La participation sera gratuite et ne nécessitera que votre inscription nominative, de préférence préalable, ou à l’entrée de la séance. Merci d’indiquer votre intention en vous inscrivant via la page http://jeudisdulibre.fikket.com/

Cette séance sera suivie d’un verre de l’amitié, offert par la Catégorie Économique de la Haute École Condorcet.

Si vous êtes intéressé(e) par ce cycle mensuel, n’hésitez pas à consulter l’agenda et à vous inscrire sur la liste de diffusion afin de recevoir systématiquement les annonces.

Pour rappel, les Jeudis du Libre se veulent des rencontres autour de thématiques des Logiciels Libres. Les rencontres montoises se déroulent chaque troisième jeudi du mois, et sont organisées dans des locaux et en collaboration avec des Hautes Écoles et Facultés Universitaires du Pôle Hainuyer d’enseignement supérieur impliquées dans les formations d’informaticiens (UMONS, HEH et Condorcet), et avec le concours de l’A.S.B.L. LoLiGrUB, active dans la promotion des logiciels libres.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Faites une bonne action : contactez vos élus territoriaux

sam, 14/06/2014 - 09:02

Contrairement à l'Etat et ses ministères qui passent tranquillement aux logiciels libres, au moins pour la bureautique, les collectivités territoriales ont un gros retard à ce sujet-là, et c'est là qu'on observe le plus de résistance au changement.

C'est pourtant le moment de contacter vos élus territoriaux sur ce thème (maires, adjoints et conseillers municipaux, conseillers généraux et régionaux, élus des communautés de communes). En effet, après les élections, ils ont tous reçu la bonne nouvelle de la baisse des « Dotations de l'État ». Qu'est-ce donc ? Il s'agit de sommes versées par l'État aux collectivités territoriales pour leur fonctionnement. Le problème est que les baisses sont importantes d'année en année (et dans les 5% cette année). Pour résumer, beaucoup sont ou seront financièrement en difficulté.

C'est donc le moment de les interpeller au sujet des logiciels libres, sources d'économies mais pas seulement (insister sur le « pas seulement »).

Les économies sont de quel ordre de grandeur ? C'est là que le cas de Munich peut vous aider. Un premier article de Zdnet a estimé le potentiel d'économies à 9€ par habitant, Munich comptant 1.3 million d'habitants. Un deuxième article annoncerait quant à lui un total 4 M€/an d'économies.

Or ces économies sont récurrentes, puisqu'à chaque renouvellement de poste (tous les 6 ans environ en logiciels propriétaires), il faut prévoir le renouvellement du Windows et de la plupart des logiciels propriétaires qui ne sont plus compatibles avec la nouvelle version de Windows installée.

Mais attention, l'argument économique n'est pas suffisant, il faut convaincre les élus et le personnel de la pertinence de la démarche : ce n'est pas gagné.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Mise aux poings sur systemd

ven, 13/06/2014 - 11:26

systemd est un gestionnaire du système et de services (aussi appelé « PID 1 », car c’est le premier processus à être lancé) pour Linux, compatible avec SysV et les scripts d’init LSB. systemd a des capacités de parallélisation énergiques. Il utilise les sockets et l’activation par D-Bus pour démarrer les services, permettant le démarrage à la demande des démons. Il surveille et commande les processus avec les groupes de contrôle (cgroups) Linux. Il prend en charge la construction d’instantanés et la restauration de l’état du système. Il maintient les points de montage et d’auto-montage, et implémente une logique de contrôle transactionnelle élaborée fondée sur les dépendances entre services.

systemd ne fait pas partie du projet freedesktop.org, bien qu’hébergé sur le site. Il est codé en langage C et publié sous licence GNU GPL 2.1+. Il a été lancé par Lennart Poettering, auteur de PulseAudio et d'Avahi entre autres, et est maintenant activement développé par plusieurs dizaines de développeurs.

La dernière dépêche concernant systemd a suscité de nombreuses réactions et certaines d'entre elles montraient une méconnaissance de ce logiciel : la dépêche se contentait, pour la majeure partie il est vrai, de traduire les notes de versions.

Je vais donc faire un point sur systemd, histoire d’en finir une bonne fois pour toutes avec les discussions sans fin sur systemd (l’espoir fait vivre).

Sommaire

Ce qui suit est en grande partie une traduction d’un article Les 30 plus grands mythes à propos de systemd paru en janvier 2013 sur le site de Lennart Poettering.

Donc à partir de maintenant et jusqu’à la fin, c’est Lennart Poettering qui (indirectement) parle !

Depuis la première proposition d’inclusion de systemd au sein des distributions, on en a fréquemment parlé sur de nombreux forums, listes de diffusion et conférences. Dans ces discussions, on peut souvent entendre certains mythes à propos de systemd, qui sont répétés encore et encore, sans que cette répétition ne les rende vrais pour autant. Prenons le temps d’en briser quelques-uns :

systemd est monolithique

systemd est constitué de plus de 70 binaires (NdT : 72 sur ma machine !) clairement séparés. D’une part, systemd a été conçu pour être sécurisé : chaque binaire effectue une tâche très spécifique avec des privilèges minimaux — en utilisant les capacités (capabilities) du noyau par exemple — pour réduire la surface d’attaque et l’impact de failles de sécurité. Cela rend également systemd plus robuste et plus facile à faire évoluer et à déboguer. D’autre part, cette séparation est essentielle pour que systemd puisse lancer ces binaires en parallèle. Beaucoup d'entre eux sont même si bien séparés qu’ils peuvent aussi être utiles en dehors de systemd (systemd-detect-virt, systemd-tmpfiles ou systemd-udevd, par exemple).

Un ensemble de plusieurs dizaines de binaires peut difficilement être qualifié de monolithique. À la différence de ce qui se pratiquait auparavant, les composants sont dans une seule archive, et ils sont tous maintenus en amont dans un seul dépôt avec un cycle de publication unifié — ce qui est sans doute bénéfique au bon fonctionnement de l’ensemble.

systemd a été conçu pour la vitesse

Oui, systemd est rapide (on peut obtenir un espace utilisateur presque complet en à peu près 900 ms !), mais c’est principalement un effet secondaire d’avoir fait les choses correctement. En fait, nous n’avons jamais essayé d’optimiser chaque parcelle de systemd ; au contraire, nous avons fréquemment choisi en toute connaissance de cause un code légèrement plus lent en faveur de la lisibilité du code. Cela ne veut pas dire que la vitesse ne nous intéresse pas, mais réduire systemd à sa vitesse est une idée fausse, car ce n’est pas du tout dans nos priorités.

La vitesse de systemd ne sert à rien pour les serveurs !

C’est complètement faux. Beaucoup d’administrateurs désirent réduire les temps d’arrêt des fenêtres de maintenance. Pour les configurations à haute disponibilité, c’est sympathique d’avoir une machine indisponible qui redevient très vite disponible (le besoin utilisateur étant « toujours disponible », même s’ils oublient les interventions techniques (montée de version de logiciel, d’OS…), vu qu’ils ont une approche « nos utilisateurs » pour lesquels une nouvelle version ne correspond qu’à des ajouts, pas des régressions…). Pour les configurations dans les nuages avec un nombre important de machines virtuelles ou de conteneurs, le cout d’un démarrage lent est multiplié par le nombre d’instances. Passer plusieurs minutes de temps CPU et d’entrées/sorties sur des démarrages très lents de milliers de machines virtuelles ou de conteneurs réduit la densité de votre système de façon importante, cela vous coute même plus d’énergie. Un démarrage lent peut vous couter beaucoup d’argent, alors qu’un démarrage rapide permet d’implémenter une logique d’activation de conteneurs par socket pour augmenter la densité de votre système dans les nuages.

Bien entendu, pour la plupart des configurations de serveur, le temps de démarrage n’est pas intéressant, mais systemd est censé couvrir le plus de cas possibles. Et oui, je suis au courant que c’est souvent le micrologiciel du serveur qui prend le plus de temps au démarrage, et que le système d’exploitation démarre vite en comparaison, mais tous les serveurs n’ont pas un aussi mauvais micrologiciel, et certainement pas les machines virtuelles ni les conteneurs, qui sont un type de machine virtuelle également.

Note : nous essayons de faire notre petite part pour rendre les micrologiciels meilleurs. En mettant les performances de démarrage du micrologiciel en évidence dans la sortie de systemd, nous espérons que la honte poussera les auteurs de micrologiciels à nettoyer leur travail.

systemd est incompatible avec les scripts shell

C’est complètement bidon. Nous ne les utilisons pas pour le processus de démarrage parce que nous pensons qu’ils ne sont pas le meilleur outil pour cette tâche spécifique, mais cela ne signifie pas que systemd n’est pas compatible avec eux. Vous pouvez facilement lancer des scripts shell en tant que service systemd, systemd n’a strictement rien à faire de ce qui est à l’intérieur de votre exécutable. De plus, nous utilisons énormément les scripts shell pour installer, construire et tester systemd. Et vous pouvez continuer à utiliser vos propres scripts très tôt dans le démarrage, les utiliser comme des services normaux, les lancer à l’extinction de la machine, il n’y a quasiment aucune limite.

systemd est compliqué

C’est aussi un non-sens total. Une plateforme systemd est en réalité beaucoup plus simple que les Linux traditionnels, car elle unifie le système d’objets et leurs dépendances en unités systemd. Le langage des fichiers de configuration est très simple et on se débarrasse des fichiers de configuration redondants. Nous fournissons des outils uniformes pour la plupart des tâches de configuration du système. Le système est beaucoup moins aggloméré que les Linux traditionnels. Nous avons également une documentation plutôt complète (tout est présent sur la page d’accueil) sur à peu près tous les détails de systemd, et cela ne couvre pas seulement les interfaces pour utilisateur et administrateur, mais également les API pour les développeurs.

systemd nécessite bien sûr un apprentissage. Comme toute chose. Cependant, nous aimons croire que c’est vraiment plus simple de comprendre systemd qu’un démarrage fondé sur des scripts shell pour la plupart des gens. Surpris de ces paroles ? Eh bien, il s’avère que le shell n’est pas un langage sympathique à apprendre, sa syntaxe est obscure et complexe. Les fichiers unités de systemd sont beaucoup plus simples à comprendre, ils ne nous exposent pas à un langage de programmation, mais sont simples et déclaratifs par nature. Cela dit, si vous avez de l’expérience en shell, en effet, adopter systemd vous demandera un petit peu d’apprentissage.

Afin de rendre l’apprentissage facile, nous avons fait notre maximum pour fournir une compatibilité avec les solutions précédentes. De plus, sur de nombreuses distributions, vous remarquerez que certains des outils traditionnels vous diront — en faisant ce que vous leur aviez demandé — comment vous pourriez le faire avec les nouveaux outils à la place, possiblement d’une façon plus agréable.

Bref, systemd ne peut probablement pas être plus simple qu’il ne l’est déjà pour la tâche qu’il remplit, et nous avons travaillé dur pour qu’il soit simple à apprendre. Alors oui, si vous connaissez sysvinit alors adopter systemd va vous demander un peu d’apprentissage ; mais franchement, si vous maitrisez sysvinit, alors systemd devrait être facile pour vous.

systemd n’est pas modulaire

Tout faux. À la compilation, il y a beaucoup d’options de configuration pour choisir ce que vous voulez compiler ou non. Et nous documentons comment sélectionner encore plus en détail ce dont vous avez besoin, en allant plus loin que les options de configuration.

Cette modularité n’est pas totalement différente de celle du noyau Linux, où vous pouvez sélectionner beaucoup de fonctionnalités individuellement à la compilation. Si le noyau est assez modulaire pour vous, alors systemd l’est probablement.

systemd est seulement pour les ordinateurs de bureau

Ce n’est certainement pas vrai. Avec systemd, nous essayons à peu près de couvrir la même portée que Linux. Alors, que nous tenons compte des usages bureautiques, nous tenons aussi compte des usages serveur, ainsi que des usages embarqués. Vous pouvez parier que Red Hat ne voudrait pas en faire une pièce centrale de RHEL 7 si ce n’était pas la meilleure option pour gérer les services des serveurs.

Des personnes de différentes entreprises travaillent sur systemd. Les fabricants de voitures l’intègrent dans leurs voitures, Red Hat l’utilise pour ses systèmes d’exploitation pour serveurs, et GNOME utilise nombre de ses interfaces afin d’améliorer le bureau. Vous le trouvez dans les jouets, les télescopes et dans les éoliennes.

La plupart des fonctionnalités sur lesquelles j’ai travaillé récemment, relèvent du domaine des serveurs, comme le support des conteneurs, le management des ressources ou des fonctionnalités de sécurité. Nous couvrons plutôt bien les systèmes bureautiques pour le moment, et il y a de nombreuses entreprises faisant du développement sur systemd pour l’embarqué, certaines offrent même des services de consultance pour lui.

systemd est un résultat du syndrome NIH (NdT : Not Invented Here, « Pas inventé ici »)

Ce n’est pas vrai. Avant que nous commencions à travailler sur systemd, nous poussions l’adoption à grande échelle d’Upstart (et Fedora/RHEL l’utilisent également depuis un moment). Cependant, nous sommes finalement arrivés à la conclusion que le cœur de sa conception présentait des défauts (au moins à nos yeux : plus fondamentalement, il laisse la gestion des dépendances à l’administrateur/au développeur, au lieu de résoudre ce problème difficile dans le code) et, si quelque chose ne va pas dans le cœur, il vaut mieux le remplacer que de le corriger. Ça n’est pas la seule raison cependant, d’autres choses ont joué, comme le bordel autour du CLA. NIH n’était cependant pas une des raisons…

Note : et puis, devinez quel projet inclut une bibliothèque « libnih » — Upstart ou systemd ? (indice : ça n’est pas systemd !)

systemd est un projet freedesktop.org

Ma foi, c’est vrai que systemd est hébergé sur fdo, mais freedesktop.org n’offre pas grand-chose de plus qu’un dépôt pour le code et la documentation. À peu près tous les développeurs peuvent demander de l’espace et déposer leurs affaires ici (à condition d’avoir un vague rapport avec l’infrastructure des systèmes libres). Il n’y a pas de cabale, pas de processus de standardisation, pas de vérification de projet, rien. C’est juste un hébergement sympa, gratuit et solide pour mettre un dépôt. De ce point de vue, c’est un peu comme sourceforge, github, kernel.org, mais de nature non commerciale et sans demandes excessives et donc, un bon endroit où mettre notre projet.

Donc oui, nous avons choisi fdo pour l’hébergement, mais l’hypothèse implicite de ce mythe, qu’il existe un groupe de gens qui se rencontrent et qui décident du futur des systèmes libres, est entièrement fausse.

systemd n’est pas UNIX

Il y a certainement du vrai en cela. Les sources de systemd ne contiennent pas une seule ligne de code héritée de l’UNIX originel. En revanche, notre inspiration nous vient d’UNIX et c’est pourquoi il y a beaucoup d’UNIX en systemd. Par exemple, l’idée d’UNIX du « tout est fichier » trouve son jumeau dans systemd où tous les services sont exposés au lancement dans un système de fichiers du noyau, le cgroupfs. Ensuite, une des fonctionnalités originelles d’UNIX était celle des multi-terminaux (multi-seat), basée sur la prise en charge des consoles (terminaux d'ordinateurs). Les consoles en mode texte ne sont pas vraiment la manière dont vous interagissez avec votre ordinateur de nos jours. Avec systemd, nous avons apporté le retour de la gestion des multi-terminaux, mais cette fois avec la gestion complète des composants modernes, des cartes graphiques aux souris, systèmes audio, webcams et bien plus, et tout cela complètement automatique, branchements à chaud et sans configuration. En effet, le design de systemd en tant que suite d’outils intégrés dont chacun a ses buts propres, voilà la philosophie du cœur d’UNIX. Ensuite, la façon dont notre projet est géré (c'est-à-dire maintenir la majeure partie du cœur de l’OS dans un unique dépôt git) est plus proche du modèle BSD (qui est un vrai UNIX, pas comme Linux) dans la façon de faire (où la plus grande partie du cœur de l’OS est conservé dans un seul répertoire CVS/SVN) que de la façon de faire de Linux.

Enfin, UNIX est quelque chose de différent pour chacun. Pour nous, les mainteneurs de systemd, c’est quelque chose dont nous nous inspirons. Pour d’autres, c’est une religion, et tout comme les autres religions du monde, il y a différentes façons de lire ou d’interpréter. Certains définissent UNIX comme un héritage de certains bouts de codes spécifiques, d’autres le voient juste comme un ensemble d’idées, d’autres comme un ensemble de commandes, et d’autres encore comme une définition de comportements. Bien sûr, il est impossible de faire en sorte que toutes ces personnes soient heureuses.

Finalement, la question de savoir si quelque chose est UNIX ou non importe vraiment peu. Être techniquement excellent n’est pas exclusif à UNIX. Pour nous, UNIX est une influence majeure (zut, la plus grosse), mais nous avons aussi d’autres influences. Ainsi, dans certains domaines systemd sera vraiment UNIX et dans d’autres un peu moins.

systemd est complexe

Il y a un fond de vérité à cela. Les ordinateurs modernes sont des choses complexes et le système qui tourne dessus doit donc être complexe aussi. Toutefois, systemd n’est pas plus complexe que les implémentations précédentes des mêmes composants. Au contraire, il est plus simple et réduit les redondances (voir plus haut). De plus, construire un système simple basé sur systemd impliquera moins de paquets qu’un système Linux traditionnel. Avoir moins de paquets facilite la construction du système et permet de se débarrasser des interdépendances et des comportements divergents de chaque composant impliqué.

systemd est une usine à gaz

Hé bien, il y a probablement plusieurs définitions de « usine à gaz ». Mais dans la plupart des définitions, systemd est probablement l’opposé d’une usine à gaz. Vu que les composants systemd partagent une base de code commune, ils ont tendance à partager plus de code pour les fonctions générales. Voici un exemple : dans une configuration Linux traditionnelle, sysvinit, start-stop-daemon, inetd, cron, dbus implémentent tous une façon de lancer des processus avec des options de configuration variées dans un environnement que l’on espère propre. Dans systemd, les fonctions pour tout ceci, que ce soit le parsing (NdT : analyse syntaxique si vous y tenez vraiment) de la configuration ou le lancement lui-même, sont partagées. Cela se traduit par moins de code, moins de place pour faire des erreurs, moins de mémoire occupée et moins de pression sur le cache, et donc c’est une très bonne chose. Et en plus, vous gagnez une tonne de nouvelles fonctionnalités grâce à ça.

Comme mentionné plus haut, systemd est aussi plutôt modulaire. Vous pouvez choisir à la compilation les composants dont vous avez besoin et ceux dont vous pouvez vous passer. De sorte que les gens peuvent choisir à quel point systemd est une « usine à gaz ».

Quand vous compilez systemd, il ne demande que 3 dépendances : glibc, libcap et dbus. C’est tout. Il peut utiliser beaucoup plus de dépendances, mais elles sont toutes entièrement optionnelles.

Donc oui, sous tous les angles, ce n’est vraiment pas une usine à gaz.

systemd seulement pour Linux, pas sympa pour les BSD

Complètement faux. Les gens de chez BSD ne sont pas vraiment intéressés par systemd. Si systemd était portable, cela n’aurait rien changé, ils ne voudraient pas l’adopter quand même. Et la même chose est vraie pour les autres Unix dans le monde. Solaris a SMF, BSD a son propre système rc, et ils l’ont toujours maintenu séparément de Linux. Le système d’initialisation est très proche du cœur du système d’exploitation. Et ces autres systèmes d’exploitation se définissent eux-mêmes, entre autres choses, par le cœur de leur espace utilisateur. L’hypothèse qu’ils aient adopté notre cœur d’espace utilisateur si nous l’avions juste rendu portable est sans aucun fondement.

systemd seulement pour Linux empêche son adoption comme système d’initialisation par défaut sur Debian

NdT : Debian est déjà passée à systemd, mais on traduit aussi cette partie pour le plaisir. :p

Debian prend en charge des noyaux non-Linux dans leur distribution. systemd ne fonctionnera pas sur ceux-ci. Est-ce que c’est cependant un problème, et cela doit-il gêner l’adoption de systemd par défaut ? Pas vraiment. Les gens qui ont porté Debian sur ces noyaux sont prêts à investir du temps dans un portage qui demande beaucoup de travail, ils ont mis en place des systèmes de tests et de compilation, patché et compilé de nombreux paquets pour atteindre ce but. La maintenance à la fois d’une unité systemd et d’un script d’initialisation classique pour les services empaquetés est une charge de travail négligeable comparé à cela, en particulier parce que le plus souvent ces scripts existent déjà.

systemd pourrait être porté sur d’autres noyaux si ces mainteneurs le voulaient

C’est tout simplement faux. Faire un portage de systemd sur d’autres noyaux n’est pas faisable. Nous utilisons trop d’interfaces spécifiques à Linux. Pour certaines, on peut trouver des remplacements sur les autres noyaux, pour d’autres nous pourrions les désactiver, mais pour la plupart, ce n’est vraiment pas possible. Voici une petite liste non exhaustive: cgroups, fanotify, umount2(), /proc/self/mountinfo (incluant les notifications), /dev/swaps (de même), udev, netlink, la structure de /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capacités, espaces de nommages en tout genre, divers prctl()s, de nombreux ioctls, l’appel système mount() et sa sémantique, SELinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, et ainsi de suite.

Si vous regardez cette liste et prenez les quelques éléments auxquels vous pouvez trouver un équivalent évident dans d’autres noyaux, alors réfléchissez à nouveau, et regardez ceux que vous n’avez pas considérés et la complexité nécessaire pour les remplacer.

systemd n’a pas de raison de ne pas être portable

Ça n’a aucun sens ! Nous utilisons des fonctions spécifiques à Linux parce que nous en avons besoin pour implémenter ce que nous voulons. Linux a beaucoup de fonctionnalités qu’UNIX/POSIX n’a pas, et nous voulons que les utilisateurs puissent en tirer parti. Ces fonctions sont incroyablement utiles, mais seulement si elles sont offertes de manière conviviale à l’utilisateur et c’est ce que nous voulons faire avec systemd.

systemd utilise des fichiers de configuration binaire

Je n’ai aucune idée d’où est sorti ce mythe fou, mais ça n’est absolument pas vrai. systemd est configuré quasi exclusivement par de simples fichiers textes. Vous pouvez également modifier quelques options avec la ligne de commande du noyau ou par des variables d’environnement. Il n’y a rien de binaire dans sa configuration (même pas de XML). Seulement des fichiers en texte brut, simples, et faciles à lire.

systemd est un cauchemar de fonctionnalités

Eh bien, systemd couvre certainement plus de terrain que par le passé. Ce n’est plus uniquement un système d’initialisation, mais le bloc de base de l’espace utilisateur à partir duquel construire un système d’exploitation ; mais nous faisons attention de garder optionnelles la plupart des fonctionnalités. Vous pouvez en désactiver beaucoup lors de la compilation, et encore plus lors de l’exécution. Ainsi pouvez-vous choisir librement combien de fonctionnalités injecter.

systemd vous force à faire quelque chose

systemd n’est pas la mafia. C’est un logiciel libre, vous pouvez en faire ce que vous voulez, ce qui inclut ne pas l’utiliser. C’est plutôt l’opposé de « forcer ».

systemd rend impossible l’utilisation de syslog

C’est faux, nous avons fait attention lors de l’introduction du journal à ce que les informations soient transmises au serveur syslog. En fait, s’il y a bien une chose qui a changé, c’est surtout le fait que syslog reçoit maintenant plus d’informations, car nous nous occupons du début du démarrage système ainsi que des flux STDOUT/STDERR de tous les services du système.

systemd est incompatible

Nous faisons de notre mieux pour garantir la meilleure compatibilité possible avec sysvinit. En fait, la grande majorité des scripts d’initialisation fonctionne telle quelle sous systemd, sans modifications. Toutefois, il y a effectivement quelques incompatibilités, mais nous essayons de les documenter et d’expliquer comment y réagir. En fin de compte, tout système qui n’est pas systemd aura une certaine dose d’incompatibilité avec lui vu qu’il n’aura pas exactement la même structure d’exécution.

Notre but est que les différences entre les multiples distributions restent à un niveau minimum. Cela implique que les fichiers unité fonctionnent généralement bien sur une distribution différente de celle où ils ont été conçus, ce qui est un énorme progrès sur les scripts classiques d’initialisation qui sont très difficiles à écrire d’une façon portable à d’autres distributions Linux, compte tenu des nombreuses incompatibilités entre elles.

systemd n’est pas scriptable, à cause de son utilisation de D-Bus

Ce n’est pas vrai. Presque chaque interface D-BUS que fournit systemd est aussi accessible via un outil en ligne de commande, par exemple dans systemctl, loginctl, timedatectl, hostnamectl, localectl et autres. Vous pouvez aisément appeler ces outils depuis des scripts shell, ils donnent accès à pratiquement toute l’API depuis la ligne de commande avec des commandes faciles d’emploi.

Cela dit, D-Bus a aussi une interface (NdT : bindings) pour presque tous les langages de script de ce monde. Même depuis le shell on peut invoquer des méthodes D-Bus quelconques avec dbus-send ou gdbus. Finalement, cela facilite son utilisation dans des scripts grâce à la bonne gestion de D-Bus par les différents langages de script.

systemd requiert l’utilisation d’obscurs outils de configuration au lieu d’éditer des fichiers textes directement

Ce n’est pas vrai du tout. Nous proposons des outils de configuration, et leur utilisation vous fournit quelques fonctionnalités complémentaires (par exemple, la complétion en ligne de commande de tous les paramètres !), mais ils ne sont en rien nécessaires. On peut toujours modifier les fichiers en question directement si on le souhaite, et c’est totalement accepté. Bien sûr que quelquefois on a besoin de recharger explicitement la configuration d’un démon après l’avoir modifiée, mais ceci est vrai de la plupart des services UNIX.

systemd est instable et bogué

Selon nos données, certainement pas. Nous analysons minutieusement le système de suivi de bogues (NdT : bugtracker) de Fedora (et d’autres) depuis longtemps. Le nombre de bogues est très faible pour un tel composant central du système d’exploitation, surtout si on en retranche les nombreuses propositions d’améliorations (NdT : RFE) que nous enregistrons dans ce projet. Nous sommes plutôt bons pour maintenir systemd hors de la liste des bugs bloquant la distribution. Notre cycle de développement est plutôt rapide avec principalement des modifications incrémentales pour conserver un haut niveau de qualité et de stabilité.

systemd n’est pas déboguable

Faux. Certains sous-entendent que le shell était un bon débogueur. Hé bien pas vraiment. Dans systemd nous vous fournissons de véritables capacités de débogage. Par exemple, le débogage interactif, une traçabilité détaillée, la possibilité de masquer n’importe quel composant pendant le démarrage et plus encore. Nous fournissons aussi la documentation associée.

Il est sans aucun doute parfaitement débogable, nous en avons nous-mêmes besoin pour notre propre développement. Cependant nous reconnaissons une chose : il utilise des outils de débogage différents, dont nous pensons qu'ils sont plus appropriés à l’objectif.

systemd fait des changements pour le plaisir de changer

Largement mensonger. Nous avons à peu près uniquement des raisons techniques aux différents changements apportés, et nous les expliquons dans les multiples documentations, pages de wiki, articles de blogues et annonces dans les listes de diffusion. Nous faisons un réel effort pour éviter les changements incompatibles, et si nous y sommes contraints, nous essayons d’en documenter en détail la cause et la modalité. Et s’il vous reste des questions, n’hésitez pas à nous les poser !

systemd est un projet uniquement dirigé par Red Hat, une propriété privée de quelques développeurs je-sais-tout, qui l’utilisent pour servir leur vision du monde

C’est faux. Actuellement (NdT : 2013-01-16), il y a 16 développeurs avec le droit de commit sur le dépôt git. Dans ces 16 développeurs, seulement 6 sont employés par Red Hat (NdT : le compte a changé depuis). Les 10 autres sont des gens d’ArchLinux, de Debian, de Mageia, d’Intel, de Pantheon et même de Canonical, ainsi qu’un certain nombre de gens de la communauté. Et ils font souvent de grosses modifications et des changements majeurs. Ensuite, il y a aussi les 374 particuliers avec des patchs dans notre dépôt. Ils viennent aussi d’horizons et d’entreprises variés et plusieurs ont bien plus qu’un seul patch dans le dépôt. Les discussions sur le futur de systemd sont faites de façon ouverte sur notre canal IRC (#systemd sur freenode, vous êtes les bienvenus), sur notre liste de discussion et lors de nos hackfests publiques (comme la prochaine qui aura lieu à Brno, où vous êtes cordialement invité). Nous assistons régulièrement à diverses conférences pour avoir des retours, pour expliquer ce que nous faisons et pour quelle raison, à un degré que peu de projets font. Nous gardons à jour les blogs, nous engageons la discussion sur les réseaux sociaux (nous avons du contenu assez intéressant sur Google+, et notre communauté Google+ est relativement vivante aussi), et nous tentons ardemment d’expliquer pourquoi et comment on fait les choses et on écoute les retours, afin de trouver où sont les soucis (par exemple, avec ces retours, nous avons écrit cette liste de mythes courants sur systemd…).

La plupart des contributeurs à systemd partagent probablement une idée grossière de ce à quoi un bon système d’exploitation devrait ressembler, ainsi que le désir de la voir se concrétiser. Cependant, par la nature Open Source même du projet et son implantation dans la communauté, systemd est simplement ce que les gens veulent qu’il soit et si ça n’est pas ce qu’ils veulent, ils peuvent influencer la direction du projet avec des patchs et du code, et si ça n’est pas possible, il y a alors de nombreuses autres options à épuiser. systemd n’est jamais fermé.

Un but de systemd est d’unifier un peu le paysage dispersé de Linux. Nous essayons de nous débarrasser de beaucoup des différences inutiles entre distributions dans différents domaines du cœur de l’OS. Dans ce cadre, nous adoptons parfois une méthode spécifique à une distribution et l’utilisons par défaut pour systemd dans le but de pousser gentiment tout le monde vers le même ensemble de configurations de base. Ce n’est cependant pas une obligation, les distributions peuvent continuer de le faire à leur manière. Cependant, si elles finissent par adopter le standard, leur travail devient plus simple et elles peuvent gagner une fonctionnalité ou deux. Actuellement, la plupart des standards que nous avons adoptés venaient de Debian plutôt que de Fedora/RHEL. Par exemple, les systèmes qui utilisent systemd stockent généralement leur nom d’hôte dans /etc/hostname, ce qui était auparavant spécifique à Debian et maintenant utilisé sur plusieurs distributions.

Une chose que je vous accorde cependant est que nous pouvons certaines fois avoir l’air de monsieur-je-sais-tout. Nous essayons d’être préparés à chaque fois que nous ouvrons notre bouche, dans le but de soutenir nos affirmations. Cela peut nous faire passer pour des monsieur-je-sais-tout.

De façon générale, effectivement, quelques-uns des plus influents contributeurs de systemd travaillent pour Red Hat. Cependant ils sont une minorité et systemd est une communauté saine et ouverte avec différents intérêts, différentes expériences, simplement unifiée par quelques idées grossières de la direction à prendre, une communauté où le code et sa conception comptent, mais certainement pas l’affiliation à une entreprise.

systemd ne gère pas l’utilisation d’un /usr séparé du répertoire racine

Absurde. Depuis ses débuts systemd gère l’option --with-rootprefix= pour son script configure, ce qui vous permet de dire à systemd de bien séparer les choses nécessaires au début du démarrage de celles nécessaires plus tard. Toute cette logique est complètement présente et nous la gardons à jour dans le système de compilation de systemd.

Bien sûr, nous ne pensons toujours pas qu’amorcer sans /usr disponible est une bonne idée, mais nous le prenons parfaitement en charge dans notre système de compilation. Cela ne corrigera pas les problèmes inhérents du procédé que vous rencontrerez partout, mais vous ne pouvez pas accuser de cela systemd, car dans systemd nous le gérons très bien.

systemd ne permet pas de remplacer ses composants

Faux, vous pouvez désactiver et remplacer à peu près n’importe quel bout de systemd, à de très rares exceptions près. Et ces exceptions (comme journald) en général vous permettent d’utiliser une alternative côte à côte tout en coopérant avec elle.

L’utilisation de D-Bus dans systemd au lieu de sockets le rend opaque

Cette affirmation est déjà contradictoire en elle-même : D-Bus utilise les sockets comme transport. Donc, chaque fois que D-Bus est utilisé pour envoyer quelque chose, une socket est utilisée. D-Bus est pour majeure partie une sérialisation standardisée de message à envoyer à travers ces sockets. Cela le rend plus transparent, car ce format de sérialisation est bien documenté, compris, et il y a de nombreux outils de traçage et des liaisons de langage (language bindings). C’est complètement à l’opposé des habituels protocoles maison que les divers démons Unix classiques utilisent pour communiquer localement.

Hum, ai-je écrit que je voulais briser juste « quelques » mythes ? Peut-être qu’il y en avait plus que quelques-uns… Quoi qu’il en soit, j’espère que j’ai réussi à éliminer certaines idées fausses. Merci de votre temps.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

eZ Server Monitor : un tableau de bord simple et léger en deux versions

ven, 13/06/2014 - 10:17

eZ Server Monitor (eSM) permet d’afficher plusieurs informations de votre machine Unix afin de la superviser. Il se décline en deux versions : Web (eSM`Web) et Bash (eSM`sh) (tous deux sous licence GPL).

eSM`Web

Dans sa version Web, eSM est un script PHP qui regroupe sur une seule page diverses informations séparées en blocs :

  • system : nom de la machine, OS, version du noyau, uptime, date du dernier démarrage, nombre d’utilisateur(s) connecté(s), date de la machine ;
  • load average : graphiques indiquant la charge CPU avec le pourcentage (1 minute, 5 minutes et 15 minutes) ;
  • network usage : affichage de l’adresse IP de chaque interface réseau avec les données transmises et reçues ;
  • CPU : modèle, fréquence, nombre de coeurs, cache L2, bogomips ;
  • disk usage : tableau représentant chaque point de montage avec l’espace disponible, utilisé et total ;
  • memory : tableau contenant la quantité disponible, utilisée et totale de la mémoire vive ;
  • swap : tableau contenant la quantité disponible, utilisée et totale du Swap ;
  • last login : affichage des 5 dernières connexions utilisateur ;
  • ping : effectue un ping sur les sites définis dans le fichier de configuration ;
  • services : affiche l’état (disponible ou non) des services définis dans le fichier de configuration.

Chaque bloc peut être actualisé manuellement.

Vous pouvez télécharger la dernière version en cliquant ici. Les pré-requis sont simples : une machine fonctionnant sur un environnement Unix, un serveur Web (Apache, Nginx…) et PHP.

eSM`sh

Quant à la version Bash (eSM`sh), elle vous permet également de retrouver ces informations sur votre terminal Unix.

Chaque bloc peut être affiché de manière indépendante grâce aux différentes options proposées :

  • -h, -u, --help or --usage : affiche l’aide ;
  • -v or --version : affiche la version du script ;
  • -C or --clear : efface le terminal (doit être inséré avant tout autre argument) ;
  • -a or --all : affiche tous les blocs ;
  • -s or --system : informations du système (OS et distribution, kernel, nom de la machine, uptime, nombre d’utilisateurs connectés, date du dernier démarrage, date de la machine) ;
  • -e or --services : vérifie la disponibilité d’un service (peut être configuré) ;
  • -n or --network : informations réseau (IP LAN ; IP WAN) ;
  • -p or --ping : ping sur quelques sites (peut être configuré) ;
  • -c or --cpu : informations du CPU (modèle, fréquence, cache L2, bogomips) ;
  • -m or --memory : informations mémoire vive (disponible et totale) ;
  • -l or --load : charge du CPU et nombre de processus ;
  • -t or --temperatures : affiche la température du CPU, système et des disques durs (facultatif et nécessite hddtemp et/ou lm-sensors d’installés ; peut être configuré) ;
  • -d or --disk : espace disque (top 5).

Ainsi, pour afficher l’ensemble des blocs, il suffit de lancer la commande suivante :

./eZServerMonitor.sh -Ca

La documentation détaille l’ensemble des possibilités du script.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Makilab : Création d’un Fab Lab en Belgique francophone (Louvain-La-Neuve)

ven, 13/06/2014 - 07:26

Un nouveau laboratoire de création numérique a vu le jour à Louvain-La-Neuve (Belgique, Brabant Wallon, à 20 min de Bruxelles).

Son nom : Makilab !

Pour rappel, les Fab Labs (FABrication LABoratory) sont des lieux dédiés à la fabrication numérique où tout le monde peut venir s’essayer à prototyper des projets, créer ou simplement personnaliser un objet. Et bien souvent, l'approche libre ou open hardware/source adoptée par les projets existants ou en devenir rendent ces lieux particulièrement intéressants.

L’ASBL (l'équivalent d'une association de Loi 1901 en France) en est à ses débuts, mais rencontre déjà un certain écho dans le monde académique, étudiant (Louvain-La-Neuve est une ville universitaire), citoyen et entrepreneurial. Le fait que l’initiative soit une première dans la province n’y est certainement pas étranger. Dans cette dynamique, nous avons lancé une campagne de financement participatif.

Au niveau technique, nous sommes actuellement équipés d'une découpe vinyle et d'une imprimante 3D, bientôt rejoints par une découpe laser et un scanner 3D. Bref, que vous soyez passionné, curieux ou simple bricoleur, n’hésitez pas à nous visiter.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Inauguration du fablab de Montpellier le 14 juin 2014

jeu, 12/06/2014 - 18:19

Dans le cadre du Festival French Tech, venez découvrir tout au long de la journée du samedi 14 juin le fablab LABSUD.

À 11h00, le Fablab sera inauguré en présence de Max Levita, Vice-Président de l’Agglomération de Montpellier.

À partir de 12h00 et tout au long de la journée, de nombreuses démos seront organisées afin de montrer les technologies utilisables à LABSUD:

  • scan 3D, avec démonstrations de numérisation puis impressions 3D de modèles humains ;
  • impression 3D ;
  • usinage à commande numérique ;
  • découpe Laser ;
  • etc.

Le LABSud est situé à l'Hôtel d'entreprise du Millénaire, 120 allée John Napier, à Montpellier.

LABSUD est une association loi 1901 créée en septembre 2012 sur les valeurs de la collaboration, les échanges et le partage de connaissances et de savoir-faire.

Exemple: tous les ateliers autour de la fabrication et la maîtrise des imprimantes 3D se font autour d'open hardware (+30 imprimantes 3D sont ainsi sorties du labo depuis 18mois).

L'installation dans ses nouveaux locaux (270m2 équipés) donne l'occasion d'une journée portes ouvertes pour permettre à toutes et à tous de découvrir et partager les valeurs et les activités de LABSUD. On y trouvera un espace "électronique", une salle pour les conférences et formations, le coin scanner et imprimantes 3D, un espace détente, et bien sûr une salle dédiée aux machines outils: CNC, tour, découpe laser, imprimante grand format, etc…

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Inauguration du fablab de Montpellier le 14 juin

jeu, 12/06/2014 - 18:19

Dans le cadre du Festival French Tech, venez découvrir tout au long de la journée du samedi 14 juin le fablab LABSUD.

À 11h00, le Fablab sera inauguré en présence de Max Levita, Vice-Président de l’Agglomération de Montpellier.

À partir de 12h00 et tout au long de la journée, de nombreuses démos seront organisées afin de montrer les technologies utilisables à LABSUD:

  • scan 3D, avec démonstrations de numérisation puis impressions 3D de modèles humains ;
  • impression 3D ;
  • usinage à commande numérique ;
  • découpe Laser ;
  • etc.

Le LABSud est situé à l'Hôtel d'entreprise du Millénaire, 120 allée John Napier, à Montpellier.

LABSUD est une association loi 1901 créée en septembre 2012 sur les valeurs de la collaboration, les échanges et le partage de connaissances et de savoir-faire.

Exemple: tous les ateliers autour de la fabrication et la maîtrise des imprimantes 3D se font autour d'open hardware (+30 imprimantes 3D sont ainsi sorties du labo depuis 18mois).

L'installation dans ses nouveaux locaux (270m2 équipés) donne l'occasion d'une journée portes ouvertes pour permettre à toutes et à tous de découvrir et partager les valeurs et les activités de LABSUD. On y trouvera un espace "électronique", une salle pour les conférences et formations, le coin scanner et imprimantes 3D, un espace détente, et bien sûr une salle dédiée aux machines outils: CNC, tour, découpe laser, imprimante grand format, etc…

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Présentation et installation Emmabuntüs et Logiciels Libres dans l'Hérault, samedi 14 juin 2014

jeu, 12/06/2014 - 13:33

L’équipe de Montpel’libre vous donne rendez-vous chez Emmaüs le samedi 14 juin 2014 pour une journée d’information et de sensibilisation à l’utilisation des Logiciels Libres. Nous vous présenterons Ubuntu et bien sûr l’une de ses dérivées Emmabuntüs.

La prochaine occurrence de cette rencontre mensuelle aura donc lieu ce samedi 14 juin 2014 de 14h00 à 17h30 à la communauté Emmaüs Montpellier-Saint-Aunès, sise à La Vieille Cadoule 34130 Saint-Aunès (Coordonnées GPS : 43.649363,3.991591)

  • Vous désirez un ordinateur à votre service ?
  • Vous désirez un ordinateur qui va vite ?
  • Vous désirez un ordinateur qui ne communique aucune données à des inconnus ?
  • Vous désirez un ordinateur qui n’a pas besoin d’antivirus ?

Vous rencontrerez des personnes qui sont là pour vous parler de Logiciels Libres.
Vous pourrez aussi acheter des ordinateurs déjà installés prêt à être utilisés.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Sortie du noyau Linux 3.15

jeu, 12/06/2014 - 07:35

La sortie de la version stable 3.15 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.

Sommaire En bref
  • Pilotes graphiques libres :
    • DRM : interface unifiée pour la gestion des plans graphiques ;
    • Radeon : gestion de l’encodage vidéo matériel et d’une nouvelle puce unifiée avec processeur graphique intégré (APU) ;
    • Nouveau : gestion initiale de la famille Kepler et meilleure gestion des ventilateurs.
  • Réseau :
    • amélioration forte des performances ;
    • affectation de règles iptables à un cgroup.
  • Systèmes de fichiers :
    • réduction du temps de réveil après une mise en veille en mémoire vive ;
    • nouvel appel système pour échanger les noms entre deux fichiers de façon atomique ;
    • verrous POSIX par fichier ;
    • ajout de la gestion de l’algorithme de compression LZ4 pour zram.
La phase de test RC-1

La version RC-1 est sortie le 13 avril 2014.

Ça fait deux semaines que la 3.14 a été livrée et la 3.15-rc1 est maintenant étiquetée et publiée ; les correctifs et les archives tar » sont — au moment où j’écris ces lignes — en train de passer dans les compresseurs de kernel.org. Ce qui veut dire que la fenêtre de fusion est fermée et que les gens doivent m’envoyer uniquement des corrections de bogues.

Et franchement, il était temps. Cette version ne contient pas vraiment de choses bizarres, mais elle est grosse. Bien sûr, nous avons déjà eu des versions avec plus de lignes et de fichiers modifiés (3.7-rc1 et 3.11-rc1, notamment), mais celles-ci ont tendance à avoir quelque chose de particulier dedans (3.7-rc1 a vu la désintégration largement automatisée du fichier d’en-tête UAPI et la 3.11 a vu la fusion de la correction des bogues de Lustre).

En comparaison de ces grosses versions, 3.15-rc1 est seulement grosse. Pas de gros changement unitaire, mais seulement énormément de correctifs. Effectivement, il y a eu quelques intégrations de nouveaux pilotes (rtl8723au, notamment). Mais, même s’ils étaient gros, ils ne représentent pas la majorité des changements. Il y a seulement énormément de changements.

En fait, nous avons le plus grand nombre de correctifs dans l’histoire récente (peut-être depuis toujours), à un peu plus de 12 000 correctifs hors fusions (et environ 800 fusions).

Et il y en a vraiment un peu partout. L’essentiel concerne les modifications de pilotes, ce qui représente environ trois quarts des modifications. Le staging se démarque, mais c’est vraiment sur tout ​​le périmètre des pilotes, avec le réseau, le son, les médias, les pilotes graphiques, les pilotes de blocs…

Mais il y a aussi des tonnes de trucs qui ne concernent pas les pilotes. En dehors du sous-répertoire des pilotes, les mises à jour d’architecture comptent environ pour la moitié des changements (avec en tête ARM, principalement dû aux « device-tree descriptors ». Mais il y a aussi IPS, x86, PowerPC, s390, Blackfin…). Et le reste est aussi assez varié, avec le cœur du réseau, la documentation, le noyau, mm, les outils, etc.

Ainsi, alors que les modifications de pilotes et d’architecture représentent l’essentiel, nous avons aussi beaucoup de changement du cœur.

Quoi qu’il en soit, encore plus que d’habitude, la RC-1 est beaucoup trop grande pour inclure un résumé du rapport de toutes les publications. Mais le résumé du rapport des fusions que j’ai fait peut donner à minima une vue d’ensemble de tous les changements. Comme d’habitude, les personnes citées dans le rapport de fusion sont les mainteneurs depuis que j’ai récupéré les changements, et non les développeurs qui ont écrit le code. Vous pouvez voir ça dans les journaux complets de git.

Quoi qu’il en soit, comme la RC-1 est déjà sacrément grosse, je ne veux pas entendre de « désolé j’ai raté la fenêtre, puis-je encore me faufiler ? ». Corrections uniquement.

La seule exception concerne deux choses en cours qui sont arrivées pendant la fenêtre de fusion, mais qui ont été explicitement retardées. Nous avons donc en attente un mouvement de fichier fbdev (je ferai le mouvement du fichier après la RC-1, simplement pour que les choses soient plus simples à voir dans l’historique et ne pas mélanger les mouvements avec les développements). Et il y avait une demande de fusion sur les espaces de noms et montages que je n’ai pas intégrée, mais que je ferai probablement après quelques améliorations ou commentaires supplémentaires. Ça retardera probablement la 3.16, mais nous verrons de combien de lignes de code ce truc a besoin…

Linus

RC-2

La version RC-2 est sortie le 20 avril 2014.

« Et le septième jour la RC est ressuscitée, conformément aux Écritures du Kernel summit de l’année 2004. »

Cela fait une semaine, donc voici une nouvelle RC. Et alors que la RC-1 était de mémoire une des plus grosses RC, la RC-2 a l’air tout à fait normale. Nous avons eu quelques erreurs tenaces corrigées, mais ce n’était pas réellement quelque chose de pire que d’habitude. C’est peut‐être un peu plus gros que la plupart des RC-2, mais attendons de voir après la RC-3 quelles choses sont vraiment plus actives que d’habitude. La RC-2 est régulièrement plus calme que la RC-3, car il faut plus d’une semaine pour que certaines anomalies surviennent.

Quant à ce qu’il s’est passé au cours de la semaine dernière, le gros du correctif RC-2 est, en fait, la suppression du pilote RTL8187SE de staging, car il y en a maintenant un bon en dehors de staging. C’est vraiment un peu plus de la moitié du correctif en lui‐même. Mais, même si vous ignorez tout simplement cette sortie, les autres changements de pilotes représentent environ les deux tiers du reste (pilote graphiques, réseau, renommage des fichiers fbdev, IPMI, InfiniBand, pin control… Nommez votre pilote préféré). La partie concernant le DRM est probablement la plus remarquable.

En dehors des pilotes, nous avons les mises à jour habituelles d’architectures (principalement x86 et s390, un peu de PA-RISC) et quelques mises à jour de documentation. Quelques corrections pour le réseau et des mises à jour de système de fichiers (CIFS, sysfs, XFS). Et quelques trucs d’outillage.

Testez, s’il vous plaît,

Linus

RC-3

La version RC-3 est sortie le 27 avril 2014.

Nouvelle semaine, nouvelle RC. Jusqu’à présent, pas de grosses craintes et la RC-3 est adéquatement plus petite que la RC-2 ne l’était, nous sommes donc sur la bonne voie.

Les statistiques semblent relativement normales, avec une moitié de pilotes (pilote d’entrées, USB, pilotes graphiques, ACPI, régulateur…) et un tiers de mises à jour d’architectures (la majorité portant sur les fichiers DTS pour ARM, mais aussi d’autres mises à jour sur ARM et user-mode). Le reste est varié, mais principalement concentré sur les mises à jour des systèmes de fichiers (Btrfs et ext4).

Linus

RC-4

La version RC-4 est sortie le 4 mai 2014.

Rien de particulièrement exceptionnel en cours. 45 % de pilotes (DRM, son, [md](http://en.wikipedia.org/wiki/Mdadm "multiple device), pin-control, ACPI, etc.), 40 % d’architecture (principalement powerpc/powernv, mais aussi x86 et ARM), 15 % de divers (outillage de performance, mises à jour documentaires et code du noyau). Le rapport simplifié ci‐joint donne un bon aperçu des détails sans être trop gros.

Il y a encore quelques trucs en cours (par exemple, une correction en attente pour une intéressante corruption de la liste des « entrées de répertoires » (dentry) — même si une utilisation normale aura peu de risque d’être affectée). Mais, dans l’ensemble, c’est relativement calme et il n’y a rien d’horriblement effrayant. Nous sommes au milieu de la période d’apaisement, donc c’est comme je l’aime.

Mais, plus nous avons de tests, mieux c’est ; donc, s’il vous plaît, essayez-la.

Linus

RC-5

La version RC-5 est sortie le 9 mai 2014.

Oui, je suis conscient que c’est en avance de deux jours. Le programme normal était pour moi de faire des versions dominicales, mais, cette fois j’ai une combinaison de voyage (ce qui aurait avancé la version à samedi matin depuis l’aéroport comme c’est souvent mon habitude quand je voyage) et il se trouve que la RC-5 avait déjà suffisamment grossi pour être plus grosse que les RC-3 et RC-4 ne l’étaient.

Donc, au lieu de publier ça à la dernière minute avant que j’embarque dans un avion et que je sois hors ligne pour une semaine, j’ai décidé qu’il n’y a absolument aucune raison pour ce genre de livraison sur le fil. Je préfère faire une livraison tranquillement un vendredi après‐midi, plutôt qu’une précipitée un lendemain matin avant de disparaître pendant une semaine.

Peu importe, assez d’explications. La RC-5 est sortie et, bien que j’eusse été plus joyeux si ça avait été aussi petit que la RC-4, ça semble n’être que des corrections solides (fameux derniers mots). L’intéressante corruption de la liste dcache, que j’avais mentionnée comme reliquat de la RC-4, est dedans ; et ce serait adorable si vous aviez un test de charge pour la couche VFS qui interagit avec la consommation de mémoire. Mais, le jeu en valait la chandelle, la correction nettoie pas mal de choses et retire plus de lignes qu’elle n’en ajoute, donc je la sens bien.

Exceptée cette intéressante modification véritable du cœur (où « véritable du cœur » est défini comme « un domaine auquel je tiens particulièrement », et ne signifie rien de plus ;), tout semble ennuyeusement familier : 55 % de pilotes, 20 % de mises à jour d’architectures et 25 % de divers (systèmes de fichiers, cœur du réseau, machines virtuelles, etc.).

Et, bien que cette RC-5 soit peut‐être plus grosse que les RC-3 et 4 ne l’étaient, ce n’est pas comme si c’était inquiétant. Cette période de fusion était plus grosse que la moyenne, et le fait que la RC-5 est donc un peu plus grosse que la moyenne n’est pas quelque chose qui m’inquiète plus que ça. Et comme la RC-4 était plus petite que d’habitude, tout s’égalise.

Mais je serai réellement entièrement non joignable toute la semaine prochaine, donc faites vos tests, parce que l’arborescence git sera très calme.

Linus

RC-6

La version RC-6 est sortie le 22 mai 2014.

À cause des voyages et du manque d’accès à Internet, des publications de RC n’ont pas suivi le cycle normal de publication dominicale, et, comme j’ai pris connaissance de ce qu’il s’est passé pendant que j’étais hors ligne, plutôt que d’attendre jusqu’à dimanche prochain pour revenir à un cycle normal, je publie en conséquence la RC-6 en milieu de semaine depuis Tokyo.

Avec la RC-5 qui était en avance de quelques jours et la RC-6 qui est en retard, nous avons presque deux semaines entre elles. La taille du résultat n’est pas deux fois plus grosse cependant. En partie parce qu’heureusement on a avancé dans la série des RC et que les choses sont censées se calmer, mais aussi parce que certains sous‐mainteneurs n’ont pas envoyé leurs demandes d’intégration car ils savaient que j’étais hors ligne. Quelle que soit la raison, c’est pas mal.

La distribution du correctif à l’air normale aussi. Principalement des pilotes (ACPI, son, média, pilote graphique i915, horloge clk, PCI…), avec le gros du reste qui correspond à diverses mises à jour d’architectures (notamment MIPS, mais aussi ARM et PA-RISC). Et une poignée de trucs divers dans les systèmes de fichiers et le code du cœur du noyau.

De toute façon, en fonction de ce qui est en cours, je rallongerai un peu la RC-7 pour revenir à une planification dominicale et, en fonction de comment les choses se passent d’ici là, ça pourrait être ne pas être la dernière RC.

Mais, s’il vous plaît, testez ça,

Linus

RC-7

La version RC-7 est sortie le 25 mai 2014.

… cette sortie dominicale se recale sur le calendrier habituel.

La RC-6 a seulement quelques jours, mais, comme prévu, du travail m’attendait à la maison. Cette version est donc normale, la RC-6 ayant juste été décalée par mon voyage.

Le contenu est en grande partie composé de changements concernant le réseau (principalement les pilotes), puisque les autres branches avaient été mises à jour pour la RC-6. Il y a aussi d’autres petits changements (DRM, ordonnanceur, perf, NFS, AFS, etc.).

Linus

RC-8

La version RC-8 est sortie le 1er juin 2014.

J’ai vraiment espéré que la RC-7 serait la dernière RC, mais la réalité a encore conspiré contre mes super plans bien établis, et me force donc à faire une RC-8. Ce n’est pas comme s’il y avait beaucoup de changement, mais une correction de dernière minute de dcache me fait penser que cela ne serait pas complètement sain de sortir la version définitive sans une semaine de test supplémentaire.

De tout de façon, normalement, une RC-8 n’est pas vraiment un énorme changement — la 3.15 est une des plus grosses (si ce n’est la plus grosse) version depuis bien longtemps, et nous faisons des RC-8 assez régulièrement. Ça pourrait ne pas être le cas de toutes les versions, mais je pense que nous avons 50 % de chances de faire une RC-8 à chaque version. Aussi je ne suis pas très fâché, et sûrement pas surpris.

Non, la véritable raison pour laquelle j’avais espéré que nous n’aurions pas besoin de faire une RC-8 pour la 3.15, c’est que c’est la fin des classes dans deux semaines et nous devons prendre nos vacances en famille juste après. Je déteste avoir encore un « Linus voyage pendant la fenêtre des fusions ». Normalement, je suis plus chanceux que ça durant dans mes voyages.

Certes, j’aurai Internet, et je pourrais faire la fenêtre des fusions pendant mes vacances en famille. Je préférerais juste ne pas à avoir le faire.

Aussi, essayons de voir comment cela va marcher — les dernières semaines de versions consistent généralement à regarder et être sûr que rien de grave ne se passe, par conséquent, le développement devrait fonctionner. Peut‐être que si cela fonctionne bien, nous finirons par continuer comme cela, même s’il n’y pas de conflit de calendrier qui me fait vouloir démarrer la fenêtre des fusions avant que je sois 100 % satisfait de la version précédente.

Ce n’est pas comme si je pensais que la RC-8 était cassée de quelque façon que ce soit. Je ne me sentais simplement pas faire une version 3.15 sans un petit peu plus de temps pour que les gens testent le correctif pour le dentry.

Quoi qu’il en soit, en dehors du changement dcache, il y a plein de petites choses éparpillées. Un changement d’une ligne est particulièrement intéressant : Minchan Kim avait trouvé un cas de figure qui remplissait entièrement la pile du noyau sur l’architecture x86-64 ; et, bien que cela soit quelque chose que je repoussais depuis longtemps, ce changement étend la pile à 16 Kio. Je pense que toutes les autres architectures 64 bits avaient cela depuis longtemps, aussi cela n’est pas très choquant, mais c’est, quelque part, assez fondamental sur une des architectures principales pour être mentionné.

Linus

Version finale

La version finale est sortie le 8 juin 2014.

Je me suis donc résigné à faire une RC-8, parce que j’étais un peu inquiet des corrections de dernière minute sur dcache, mais il s’est avéré que personne ne semble avoir remarqué quoi que ce soit. Malgré tout, nous avons eu d’autres problèmes pendant la semaine, aussi cela n’était pas plus mal. Les corrections de verrous futex et les nettoyages se démarquent, mais comme d’habitude il y a diverses autres corrections un peu partout réalisées depuis la RC-8, principalement les pilotes (DRM, réseau, son, USB, etc.), le réseau, l’ordonnanceur et les outils de mesure de performance.

Mais cela a été dans l’ensemble raisonnablement petit et calme, ce qui doit être, bien entendu, dû au fait que la semaine dernière était également la première semaine de la période de fusion pour la 3.16. Cela a pu distraire certains développeurs. Je ne suis pas complètement convaincu d’avoir apprécié le chevauchement, mais il semblerait que cela ait fonctionné correctement. Et, à moins que les gens crient très fort (« S’il te plaît ne refais plus jamais cela ! ») et qu’ils donnent de bonnes raisons pour cela, je pourrais refaire un chevauchement des fenêtres de fusion dans le futur, si cela peut aider pour certains problèmes de délai.

Ceci dit, je ne pense pas que cela ait été une expérience grandiose au point que je refasse un chevauchement à chaque fois, sans une bonne raison spécifique pour cela. C’était assez agréable d’être productif la dernière semaine de la RC (qui est généralement plutôt ennuyeuse et morte), mais je pense que cela pourrait représenter une distraction quand les gens devraient s’inquiéter de la stabilité de la RC.

Bien sûr, il se pourrait que le chevauchement aboutisse à moins de bruit pendant la dernière semaine de stabilisation, et que cela aide réellement. Cela pourrait aussi produire l’inverse. Je serais intéressé d’entendre l’avis des autres personnes, mais je soupçonne que la plupart n’ont aucune opinion particulière sur le sujet.

Quoiqu’il en soit, avec la version 3.15 publiée, ma branche « master » a déjà été fusionnée avec ma branche « next » sur ma machine locale, et je vais démonter la branche « next » une fois que j’aurai dégagé tout ça. Après cela, les futures fenêtre de fusion se feront sur la branche « master » et nous reviendrons au modèle normal de branche unique pour mon arbre.

Linus

Les nouveautés Architecture Gestion du mode mixte EFI

Certaines machines ont un micrologiciel EFI 32 bits, les noyaux 64 bits ne pouvaient du coup pas démarrer simplement dessus. Le mode mixte EFI (EFI mixed mode) ajouté à cette version 3.15, permet maintenant d’y remédier. Un exemple concret est la possibilité pour l’ASUS Transformer Book T100TA de démarrer sur un tel micrologiciel.

Le mode mixte EFI est un mode qui permet aux micrologiciels EFI 32 bits de démarrer sur des noyaux 64 bits, à condition que le chargeur de démarrage gère le protocole EFI handover. La plupart des chargeurs de démarrage populaires comme GRUB, SYSLINUX ou EFILINUX le gèrent, il sera donc possible de disposer de cette fonctionnalité très simplement à condition d’activer l’option CONFIG_EFI_MIXED depuis les options de configuration du noyau Linux.

AVX-512

Les premiers processeurs proposant le jeu d’instructions AVX-512 ne seront commercialisés qu’en 2015, avec la génération Knights Landing des processeurs Intel. Toutefois, leur prise en charge est déjà disponible dans cette version 3.15.

AVX-512 (Advanced Vector Extensions), extension directe de AVX-256, est un jeu d’instructions SIMD (Single Instruction Multiple Data). Il s’agit d’un jeu d’instructions qui permet d’appliquer une même opération arithmétique sur plusieurs données en parallèle. Par opposition aux instructions habituelles de type SISD, pour Single Instruction Single Data, SIMD permet d’appliquer une même opération d’addition, de multiplication sur plusieurs éléments d’une structure très régulière, comme c’est par exemple le cas sur des tableaux ou des matrices. AVX-512 permet, entre autres, d’agrandir la taille des registres AVX à 512 bits, ou encore va donner la possibilité aux compilateurs de vectoriser plus de boucles efficacement, grâce aux instructions Conflict Detection Instructions (CDI) qui, comme leur nom l’indique, permettent la détection des conflits.

Améliorations de l’ordonnanceur

L’ordonnanceur subit un travail de préparation qui vise à permettre une meilleure intégration avec le choix des états de veille du processeur, pour économiser l’énergie. Cela ne sera disponible que dans de futures versions du noyau [commit de fusion].

Il y a aussi eu plusieurs améliorations liées à l’usage des cgroups, notamment lors du changement de contexte entre deux processus d’un même cgroup [1, 2, 3].

Abandon des anciennes plates-formes x86

Je vais faire pleurer ceux d’entre vous qui ont des enfants qui jouaient à Jill, Linux 3.15 ne gère plus ces systèmes excitants introuvables que sont les SGI Visual Workstations, Sequent Computer Systems NUMAQ, IBM Summit/EXA et autres Unisys ES7000.

Instruction RDSEED

À partir du noyau 3.15, /dev/random utilisera les nouvelles instructions RDSEED des futures générations Broadwell de chez Intel [demande d’intégration].

À partir de cette génération, les processeurs Intel proposent une nouvelle instruction RDSEED. Il s’agit d’une instruction de génération de bits aléatoires. Comparée à son homologue RDRAND, qui fut introduite avec la génération Ivy bridge, elle est destinée à être utilisée par les logiciels qui disposent déjà d’un générateur de nombres pseudo-aléatoires (PRNG), en tant que « graine » (seed), c’est-à-dire une source d’entropie de nombres aléatoires. RDRAND, quant à elle, est une instruction de génération de nombres pseudo-aléatoires.

Systèmes mono-puces ARM

La plate-forme ARM est toujours très active, au point que les développeurs songent à mettre l’arborescence des périphériques dans un arbre Git dédié.

Parmi les nouveautés, on peut noter :

  • l’ajout de la carte de développement A10-OLinuXino-LIME ;
  • l’ajout du Freescale l’i.MX35 ;
  • l’ajout des dérivés Freescale i.MX51 , i.MX25 et i.MX35 de chez Eukréa ;
  • un ensemble d’améliorations au niveau des systèmes mono-puces i.MX de chez Freescale ;
  • pas mal d’améliorations au niveau des systèmes mono-puces de chez ATMEL.
ACPI

Avant Linux 3.15, l’événement envoyé lors de l’appui sur une touche « augmenter la luminosité » ou « baisser la luminosité » pouvait signifier deux choses pour un environnement de bureau :

  1. notification comme quoi la luminosité a été modifiée ;
  2. touche de modification de luminosité pressée, « débrouille-toi ».

La plupart des environnements de bureau interprètent cet événement comme le cas numéro 2, ce qui causait des problèmes : changement de luminosité effectué deux fois — une fois par le noyau, une fois par l’environnement de bureau — ou changement de luminosité non détecté, et donc notification non affichée, etc. En effet, le scénario numéro 1 est très difficile à détecter en espace utilisateur.

Désormais, la grosse majorité des ordinateurs portables seront dans le cas numéro deux, ce qui rend la gestion de la luminosité plus simple et plus cohérente et résout les cas cités ci-dessus [commit].

Changement de la taille de la pile du noyau

La pile du noyau pour l’architecture x86_64 voit sa taille passer de 8 Kio à 16 Kio. Ce changement a été effectué par Minchan Kim [commit].

Pilotes graphiques libres DRM (Direct Rendering Manager)

Le code commun aux pilotes graphiques libres (DRM) a reçu plus d’attention que d’habitude pour cette nouvelle version, notamment afin de préparer la venue de nouvelles fonctionnalités dans les versions futures. Il n’y a donc rien de visible pour le moment pour l’utilisateur final.

Le premier gros changement est la gestion universelle des plans d’affichage (display planes). Jusqu’à présent, le DRM n’exposait que les plans de type sprites et superposition (overlay) vidéo. Les plans pour curseurs étaient, eux, exposés via des appels ioctl() dédiés, alors que les plans primaires n’ont jamais été exposés. Désormais, tout client exposant la capacité DRM_CLIENT_CAP_UNIVERSAL_PLANES pourra accéder à l’interface de plans universelle (universal plane) et à la liste complète des plans proposés par le matériel. Ce client pourra dès maintenant changer des paramètres tels que la mise à l’échelle (scaling) ou désactiver l’affichage, sans avoir à effectuer de changement de mode graphique au niveau du contrôleur vidéo (CRTC). Cependant, l’intérêt de cette nouvelle interface ne sera clair que lorsque le travail de changement atomique du mode graphique et du commutation de pages (page flip) du noyau sera terminé. En attendant, si vous voulez plus d’information, vous pouvez consulter ce message ou l’article récapitulatif de la gestion du mode graphique de Pekka Paalanen (développeur Wayland).

Le deuxième changement important est la mise en commun du code gérant le canal auxiliaire de communication du DisplayPort (DP). Cela va permettre la gestion du Multi-Stream Transport (MST) proposé par le DisplayPort, qui permet de multiplexer plusieurs liaisons vidéo à travers le même câble DP. Voici la demande d’intégration de cette nouvelle infrastructure. La gestion du MST devrait, quant à elle, arriver dans Linux 3.16 ou 3.17.

La gestion des nœuds maîtres, mineurs et de contrôles a été revue dans cette version, notamment sur la gestion des verrous. En parlant de verrous, les symboles DRM vérifient maintenant activement que les bons verrous ont été pris avant l’appel, au lieu de simplement le marquer dans la documentation. Mais le changement le plus important vient mettre fin à une bidouille pour l’allocation d’un espace d’adressage pour le périphérique. En effet, il est impossible d’allouer un espace d’adressage sans avoir de nœud d’index (inode) disponible. Du coup, DRM attendait que le premier client ouvre un nœud vers un processeur graphique avant d’allouer l’espace d’adressage. Cette technique était clairement une bidouille, et Al Viro (mainteneur VFS) a conseillé d’utiliser une autre méthode qui a été appliquée.

Pour finir, la documentation DRM a été corrigée et nettoyée.

Adreno (pilote msm)

Dans cette nouvelle version, le pilote msm gagne la possibilité de diffuser du son via la prise HDMI [correctif] et devient plus économe en énergie en activant le clock gating après 66 ms d’inactivité [correctif].

Après un article de LWN sur comment gérer proprement des drapeaux inconnus dans les ioctl() ou les appels systèmes, Rob Clark a vérifié à nouveau son code et trouvé quelques problèmes qu’il a corrigés [correctif]. Ces modifications cassent la compatibilité binaire, mais Rob se justifie en disant qu’il n’y a presque aucun pilote en espace utilisateur et que, si une application venait à être cassée par ce changement, il reviendrait partiellement sur son correctif.

Le pilote msm utilise maintenant les plans d’affichage universels qui viennent juste d’être introduits, au lieu de l’ancienne interface de programmation [correctif].

Pour finir, une option noyau a été ajoutée afin d’afficher l’état des registres lorsque le processeur graphique se bloque [correctif]. Cela devrait aider pour l’écriture de rapports de bogues.

Pour information, le pilote freedreno (accélération 3D pour Adreno) utilisant le pilote msm vient de recevoir la prise en charge d’OpenGL 2.1. Celui-ci prenait en charge OpenGLES 2.0 depuis quelque temps, mais ne gérait pas quelques extensions nécessaires pour la version « bureau » d’OpenGL. Ce code devrait être disponible dans Mesa 3D 10.3 qui sortira en août.

AMD/ATI (pilote radeon)

La principale nouveauté concernant le pilote radeon est la prise en charge de l’encodeur vidéo matériel VCE afin d’accélérer la conversion de vidéos au format H.264. Ce noyau permet l’utilisation de cet encodeur à travers le standard OpenMAX, du groupe Khronos. Ce n’est pour l’instant possible qu’avec la version VCE 2.0 du matériel, la prochaine version de Mesa 3D (10.3) [correctif] et le greffon GStreamer gst-omx.

Cette nouvelle version apporte également la prise en charge complète d’un petit dernier dans la famille des processeurs APU Kaveri, le Mullins, qui est sorti le 29 avril 2014.

Pour finir, radeon a laissé tomber sa gestion spécifique du canal de communication auxiliaire du DisplayPort, afin d’utiliser la nouvelle version proposée par DRM [correctif]. Beaucoup d’autres bogues ont également été corrigés, notamment dans la gestion des horloges.

Samsung (pilote exynos)

Un gros travail de réorganisation du code a été mené sur le pilote exynos, avec notamment le déplacement du pilote DisplayPort depuis video/ vers drm/, afin de gérer correctement le branchement à chaud et le changement de mode graphique [correctif]. Il est également à noter l’ajout de la gestion des ponts LVDS, ainsi que des écrans à interface parallèle (remplacée par l’interface DSI).

Pour plus d’informations, vous pouvez consulter la demande d’intégration exynos.

Intel (pilote i915)

Aucune nouvelle fonctionnalité activée par défaut pour le pilote i915 dans cette version, mais un énorme travail de fond a été effectué.

La gestion des Per-Process Graphics Translation Tables (PPGTT, tables de traduction graphique par processus) fait son apparition, mais est désactivée par défaut à cause de quelques bogues trouvés à la dernière minute. PPGTT est une fonctionnalité des processeurs graphiques inclus dans les processeurs Intel Ivy Bridge, Haswell, et Broadwell qui permet l’isolation des tâches du processeur graphique, ce qui améliore la sécurité en fournissant un contexte et un espace d’adressage par descripteur de fichier et client de ressources graphiques. Pour en savoir plus sur GTT et GEM, un cours d’introduction a été écrit par Ben Widawsky, un ingénieur de chez Intel.

Par le passé, la gestion du power gating et du clock gating par le matériel Intel a surtout été gérée automatiquement. Désormais, les nouvelles architectures requièrent l’intervention du pilote afin, notamment, de sauvegarder et restaurer le contexte. Donc, il est nécessaire de préparer une infrastructure permettant de représenter les domaines énergétiques, de suivre leur état et de gérer les changements d’état. Comme les domaines énergétiques sont très dépendants de l’architecture et sont amenés à évoluer dans le futur, une couche d’abstraction est proposée par l’infrastructure. Cette infrastructure devrait commencer à être utilisée dans Linux 3.16.

Du côté de l’affichage, la gestion expérimentale du démarrage rapide et sans clignotement a été améliorée afin de pouvoir hériter du mode graphique qui a été mis en place au démarrage par le micrologiciel EFI. Encore un peu de travail est nécessaire pour rendre sa gestion parfaitement fiable, ce qui explique pourquoi l’option n’est pas activée par défaut bien que toute l’infrastructure soit maintenant en place. Si vous voulez l’essayer malgré tout, vous pouvez ajouter l’option i915.fastboot=1 à votre ligne de commande noyau.

Concernant l’affichage, la prise en charge des liens DisplayPort à 5,4 GHz, nécessaire pour piloter des écrans à ultra haute définition (4K), est disponible. Malheureusement, les écrans 4K actuels exposent généralement deux écrans, via le Multi-Stream Transport (MST), afin de proposer la 4K. En parlant de MST, le pilote i915 utilise maintenant la gestion du canal auxiliaire du DisplayPort proposée par DRM, ceci afin de pouvoir plus tard gérer les écrans accessibles via MST. Enfin, la gestion des grands curseurs a été ajoutée afin de mieux gérer les curseurs sur les écrans à haute densité de pixels.

La prise en charge des processeurs Broadwell a reçu beaucoup de modifications, mais elle reste encore incomplète. D’autres devraient suivre dans Linux 3.16.

Pour plus d’informations, vous pouvez consulter le billet de blogue de Daniel Vetter dédié à Linux 3.15.

NVIDIA (pilote nouveau)

La nouveauté principale côté du pilote nouveau est la gestion expérimentale de la nouvelle famille de cartes NVIDIA Maxwell, sortie le 18 février 2014. Cette gestion se limite actuellement au mode graphique [correctif] et à l’accélération 3D [correctif] en utilisant le microcode de NVIDIA. Ce microcode sera remplacé dans le futur par une version entièrement libre, quand les fonctionnalités basiques s’exécuteront en espace utilisateur. En effet, cette nouvelle famille de cartes a introduit un nouveau jeu d’instructions qu’il a fallu étudier et intégrer à Mesa 3D [correctif]. Il manque cependant les modifications nécessaires au pilote X.Org xf86-video-nouveau pour pouvoir utiliser l’accélération 2D et 3D sur processeur graphique Maxwell avec un serveur X.

Une première version d’un système de reprise sur panne a également été intégrée pour Kepler, afin de ne pas bloquer tout le système lorsque l’unité de gestion mémoire ne connaît pas la correspondance entre une adresse virtuelle et une adresse physique. Le pilote nouveau devrait également mieux gérer les cas où le microcode de changement contexte se bloque.

La gestion automatique de la ventilation s’améliore avec la correction de multiples bogues, et, surtout, l’ajout de la gestion de deux nouveaux types de ventilateurs couramment trouvés dans la famille Kepler. Si vous avez encore des problèmes de ventilateur dans cette version, vous êtes invités à écrire un rapport de bogue. De multiples bogues concernant la lecture du BIOS vidéo ont également été corrigés, en partie grâce à l’aide de NVIDIA.

Parmi les modifications apportées dans Linux 3.15, l’une d’elles se distingue particulièrement, pour deux raisons :

  • elle prépare nouveau afin de pouvoir gérer le processeur graphique ARM Tegra K1, qui n’est pas accessible via un bus PCI, AGP ou PCIe ;
  • elle est écrite par un nouvel employé de NVIDIA, Alexandre Courbot.

Ce n’est pas la première fois que NVIDIA contribue à nouveau puisque Aaron Plattner l’avait déjà fait en février 2013, mais c’est cependant la première fois que la gestion d’un nouveau jeu de composants est écrite par un employé de NVIDIA, français, qui plus est. Alexandre Courbot est, en effet, actif sur l’IRC et les listes de diffusion de nouveau et ajoute la gestion du Tegra K1 (nom de code GK20A) au noyau, tel que nous le rapportions sur LinuxFr.org en février. La majorité des contributions sont encore à venir, notamment dans Linux 3.16. La gestion de l’accélération 3D en espace utilisateur n’a pour l’instant nécessité que -8 / +21 changements ! Plus d’information dans un futur proche, mais, en attendant, voici une petite démonstration de l’avancement.

Poulsbo (pilote gma500)

Le pilote gma500 du tristement célèbre processeur graphique à basse consommation Poulsbo évolue doucement, avec la prise en charge d’un nouveau type d’unité de gestion mémoire et de gestionnaire d’interruptions (SGX).

Tegra (pilotes host1x et tegra)

Les choses ont bien bougé du côté de host1x qui reçoit une infrastructure pour l’allocation de contextes, la synchronisation des moteurs d’exécution et la gestion du moteur de rendu 2D. La gestion de la 3D est en cours d’écriture. Bien que ce travail ait été testé durant plusieurs semaines par de multiples contributeurs, les contrôles d’entrées-sorties introduits pour tegra sont actuellement considérés comme staging (branche git dédié à la mise en œuvre) de façon à permettre un changement plus tard, si l’interface venait à ne pas être adaptée. La gestion de la 2D et de la 3D a été testée avec le pilote grate. Pour rappel, host1x est la partie des processeurs Tegra qui gère les transferts DMA, ainsi que l’affichage et l’envoi asynchrone de commandes au processeur graphique et autres systèmes multimédias. Le processeur graphique Tegra est, lui, séparé, à la fois dans la puce et dans le code, et se charge de l’accélération 2D et 3D.

Pour plus d’informations, vous pouvez consulter la demande d’intégration tegra/host1x.

VMware (pilote vmwgfx)

Le pilote vmwgfx, pour l’accélération graphique dans les machines virtuelles VMware tournant sous Linux, a revu sa politique de sécurité afin de pouvoir gérer les nœuds de rendu (render nodes).

Réseau À la recherche des performances

La recherche de gain en performance est une tâche courante dans le noyau Linux, et la partie réseau n’est pas en reste pour cette nouvelle version. Petit tour de ces nouveautés.

Une horloge plus fine

Dans les arcanes du très populaire TCP, l’estimation du RTT est importante pour certains algorithmes de gestion de la congestion. L’unité de cette estimation était la milliseconde, avec une bidouille immonde pour les cas inférieurs à cette valeur. Concrètement, cette bidouille dépendait de la fréquence de réveil de votre noyau (déterminée à la compilation). Cette fréquence étant à 1 000 Hz par défaut sur les architectures x86, l’estimation la plus fine utilisait des pas de 125 µs.

Sur des réseaux modernes très performants, ces 125 µs sont beaucoup trop imprécises. Le nouveau noyau compte donc désormais en microsecondes, mais reste compatible avec les anciens outils de l’espace utilisateur en exportant toujours les données en millisecondes. Une mise à jour de la commande ip sera nécessaire pour voir les changements.

Réécriture de l’interpréteur interne BPF

Que ne serait pas un nouveau noyau sans travail du côté du filtrage de paquets ? Le cœur de l’interpréteur a été réécrit dans cette version, avec pour objectif une amélioration des performances. Le correctif est accompagné de tests de performance prometteurs, et d’une promesse de faire encore mieux bientôt en adaptant le compilateur à la volée (Just In Time) de BPF.

Mettre à jour la somme de contrôle tout simplement

Pour limiter l’utilisation du processeur sur des réseaux à très forte capacité, un mécanisme courant est de déléguer une grande partie du travail à la carte réseau. L’idée est de faire « comme si » on envoyait et recevait des très gros paquets du côté noyau, pendant que la carte réseau se charge de découper/rassembler les paquets réels, bien plus petits. Pour en savoir plus, vous pouvez consulter un très bon article sur LWN.

C’est en utilisant ce mécanisme qu’un développeur de Google a détecté une forte utilisation du processeur pour le calcul de la somme de contrôle de ses paquets, avec près d’un pour cent du processeur dédié à cette simple tâche. Cette somme de contrôle a de bonnes propriétés mathématiques, elle est notamment incrémentale : quand on modifie un champ d’un paquet, on n’est pas obligé de tout recalculer, il suffit de calculer la différence induite par la partie réécrite.

L’analyse détaillée a donc conduit à identifier le coupable : la fonction csum_replace2(). Cette fonction prend une somme de contrôle, deux mots de 16 bits (l’ancien champ et le nouveau champ réécrit du paquet), et retourne la nouvelle somme de contrôle.

Cette fonction ne faisait pas réellement le travail, en délégant la tâche à la fonction csum_replace4(), prenant comme arguments des mots de 32 bits. Qui peut le plus peut le moins, mais le fait moins vite. csum_replace4() appelle, elle-même, une fonction générique encore plus complexe.

Cette mise à jour de la somme de contrôle est pourtant une tâche simple pour des mots de 16 bits, bien documentée depuis longtemps dans la RFC 1624. Davil Miller a signalé cette référence, et Éric Dumazet de chez Google a donc modifié la fonction pour utiliser cette méthode simple et rapide. Comme cette fonction est utilisée à d’autres endroits de la partie réseau, d’autres cas d’utilisation devraient profiter de ce gain.

Protection contre les dénis de service

Les dénis de service, consistant à surcharger un serveur par un nombre impressionnant de connexions, sont très courants sur Internet. Parmi ceux-ci, un grand classique est le bon vieux SYN flood. Sur un pare-feu à états, chaque paquet ajoutera une connexion à suivre, et il faut être capable de les gérer.

Chez Linux, ce suivi est effectué par la table conntrack. Cette table était protégée par un verrou central pour les insertions et les suppressions. Et ce verrou devenait avec le temps un énorme frein (un peu comme le Big Kernel Lock, à échelle très réduite).

Le nouveau noyau introduit donc un verrouillage plus fin, avec 1 024 verrous et une table de hachage pour savoir quel verrou utiliser. L’amélioration de performance est spectaculaire, si vous avez le matériel qui va avec. Avec un bon processeur et un réseau à 10 Gbit/s, le testeur est passé d’une gestion de 810 405 connexions par seconde à 2 233 876, soit une amélioration d’un facteur de presque trois.

Sécurité réseau cgroups et réseau

C’est une modification triviale, mais il est désormais possible d’attacher une règle iptables à un cgroup pour du trafic entrant. Cela permet notamment de compter le trafic entrant d’une application.

Toujours du côté des cgroups, une refonte assez importante a supprimé la possibilité de compiler le contrôleur cgroup net_prio en tant que module. C’était le seul qui utilisait cette possibilité.

IPsec

Dans un paquet IPsec, il est possible d’ajouter un compteur de paquets pour se protéger des attaques par rejeu (en refusant des paquets dont le compteur est inférieur aux valeurs déjà reçues). Ce compteur est historiquement de 32 bits, ce qui permet d’envoyer un certain nombre de paquets.

Ce nombre est cependant insuffisant pour les réseaux modernes, et une extension existe dans le standard depuis 2005 pour utiliser un compteur à 64 bits. Linux permettait de le faire pour le protocole ESP d’IPsec (intégrité et authentification) et, à partir de cette version, l’autorise également pour le protocole AH (intégrité et confidentialité).

Depuis sa version 3.6, le noyau permet de gérer le routage à travers un tunnel, avec les vti (Virtual Tunnel Interface, nom venant de Cisco), pour gérer plus facilement et plus dynamiquement le routage à travers un tunnel IPsec. Ces VTI sont uniquement une abstraction des règles IPsec existantes dans le noyau. Pour ces VTI, ce noyau ajoute la possibilité de configurer un espace de noms et de faire passer de l’IPv6 dans un tunnel IPv4.

Bluetooth

Ce noyau introduit la gestion du niveau 4 (le plus élevé) de la sécurité en Bluetooth. Concrètement, ce mode de sécurité force l’utilisation de clefs de chiffrement plus fortes, mais ne sera compatible qu’avec les équipements utilisant la norme Bluetooth 4.1. Il n’y a pas de compatibilité pour ce mode avec le matériel plus ancien.

Commentons avec nftables

Avec le pare-feu de nouvelle génération nftables, on peut désormais ajouter des commentaires arbitraires associés à une règle. Cela permettra à l’administrateur pressé de répondre à la question « Mais, pourquoi ai-je bien pu ouvrir le port 22 ? ».

Sécurité Audit

La valeur de proc/<pid>/cmdline (nommée proctitle) fait maintenant partie des informations remontées par le sous-système d’audit [correctif]. Cette chaîne de caractères peut être changée par le processus avec la fonction setproctitle(), et ne peut donc pas être considérée comme « de confiance » d’un point de vue sécurité.

En revanche, elle sera particulièrement utile pour le débogage sur Android notamment, car les applications ne sont pas lancées à l’aide d’un classique fork() + exec(). En effet, pour accélérer le lancement, les applications Java utilisent une instance (processus) préparée à l’avance par la machine virtuelle Java Dalvik et la spécialisent en chargeant les classes de l’application. Ceci évite notamment d’avoir à charger systématiquement les classes des paquets de base pour chaque nouvelle application lancée, et permet donc de profiter de la propriété de copie sur écriture (Copy-On-Write) de l’appel système fork(). Lorsque la machine virtuelle Java (JVM) lance une application, elle change la valeur de proctitle pour la faire correspondre à son nom et cela apparaîtra désormais dans les journaux d’audit.

La prise en charge de l’audit des appels système a aussi été étendue pour gérer les appels 32 bits sur une architecture 64 bits [correctif].

Gestion de l’Intel Trusted Execution Environment

Une série de correctifs [1, 2, 3, 4 et 5] ajoute la gestion du périphérique Intel Trusted Execution Environment à l’Intel Management Engine Interface (IMEI). L’IMEI est une interface IPMI faisant partie de l’Intel Active Management Technology qui est présente dans les processeurs avec la technologie Intel vPro. Elle permet de gérer un système en discutant directement avec une puce dédiée, sans passer par le système d’exploitation (out‐of‐band management).

LSM

Diverses corrections de bogues et améliorations mineures sont listées dans le message de demande d’intégration des correctifs.

SELinux

La mise en correspondance de zones mémoire proches de l’adresse 0 peut poser des problèmes de sécurité (cela simplifie principalement l’écriture d’exploitations de failles du noyau). Ainsi, une limitation arbitraire avait été ajoutée (vm.mmap_min_addr, configurable à l’aide de sysctl) pour réduire ce risque. Les processus souhaitant mettre en correspondance une zone mémoire inférieure à mmap_min_addr doivent disposer de la « capacité » (capability) CAP_SYS_RAWIO.

Pour le noyau 2.6.30, Eric Paris avait choisi de placer la vérification effectuée par SELinux (MAC) avant la vérification classique de « capacité » (DAC) [correctif]. Ce comportement était un cas exceptionnel, car les vérifications effectuées au niveau des appels système suivent toutes l’ordre DAC puis MAC (cf. un exemple complet pour le contrôle d’accès à un fichier).

Cette inversion a eu pour principale conséquence la mise en avant d’un cas d’erreur courant et géré sans aucun problème par les programmes (notamment Wine et QEMU) dans la majeure partie des cas. En effet, lorsque qu’un programme essayait d’effectuer un mmap() au‐dessous de mmap_min_addr, il se voyait refuser l’accès par SELinux en premier, ce qui générait un AVC qui était affiché à l’utilisateur (par setroobleshoot) avec un message du type :

SELinux is preventing /usr/bin/wine-preloader from 'mmap_zero' accesses on the memprotect.

L’utilisateur croyait alors à tort qu’il y avait un problème de sécurité. Si l’application échouait, ce n’était pas non plus nécessairement la faute de SELinux. Et, si c’était effectivement le cas, il fallait non seulement autoriser ce programme dans la politique SELinux, mais également lui donner la capacité CAP_SYS_RAWIO pour qu’il puisse fonctionner.

Ayant causé plus de soucis que de bénéfices potentiels (détection de programmes malveillants), cette inversion MAC/DAC a été corrigée (cf. l’article de Daniel Walsh sur le sujet) [correctif].

Un autre bogue a été corrigé : des nœuds d’index (inodes) dans /proc pouvaient être laissés avec une étiquette de sécurité (label) attribuée par défaut au lieu de celle indiquée dans la politique de sécurité. Cela se produisait si un programme y accédait avant que la politique ne soit chargée [correctif].

Systèmes de fichiers Code commun VFS

L’appel système renameat2 a été ajouté afin de permettre d’échanger les noms de deux fichiers de façon atomique. Avec cet appel système, il devient donc possible de remplacer un dossier par un lien symbolique sans risque qu’une opération arrive durant l’opération et ne réussisse pas ! Vous pouvez consulter l’article de LWN sur le sujet, ainsi que la page de manuel de l’appel système, afin d’obtenir plus d’informations.

Une autre modification importante est l’ajout de nouveaux verrous équivalents aux verrous POSIX, mais associés aux fichiers et non plus aux processus. La différence semble être peu importante, mais elle permet de rendre ces verrous utiles pour la synchronisation de plusieurs fils d’exécution à l’intérieur d’un même processus.

Avec les verrous POSIX classiques (qui n’ont pas été remplacés), si deux fils d’exécution (threads) d’un même processus ouvraient le même fichier, un verrou posé en écriture par un fil serait remplacé par un autre verrou en écriture posé par l’autre fil. De plus, si le fichier est ouvert plusieurs fois (utile pour paralléliser la lecture de données dans plusieurs fils) les verrous posés par un fil sur un fichier sont enlevés lorsqu’un autre fil ferme son descripteur de fichier. Il est très difficile de se prémunir contre ça sans rajouter beaucoup de verrous internes à l’application et s’assurer que les chemins des fichiers sont uniques (pas de lien dur ou symbolique).

Cependant, si les verrous sur un fichier ne sont plus associés à l’identifiant du processus (PID) mais sont associés aux descripteurs de fichier, le noyau ne fera plus de distinction entre deux tentatives de verrouillage venant de deux fils d’exécution d’un même processus ou de deux processus séparés ! Pour plus d’information, vous pouvez lire l’article dédié sur LWN.

SATA

La vitesse de sortie de veille a été augmentée en autorisant le contrôleur de disque SATA à se réinitialiser en tâche de fond pendant que le reste du noyau se réveille puis rend la main à l’espace utilisateur. Ce n’est pas un problème, car même si une application utilisateur ou le noyau essaient de relire un fichier pendant que le contrôleur SATA se réveille, le processus ou le module sera bloqué et la requête mise en file d’attente en attendant que le contrôleur ait fini son travail. Le résultat est un temps de réveil de 7 à 12 fois plus rapide sur les machines de son développeur et une faible complexité du code (1 et 2). Plus d’informations sont disponibles sur LWN.

Ext3/4

Le système de fichiers par défaut de nombreuses distributions se stabilise encore et toujours, mais peu de nouveautés à se mettre sous la dent.

XFS

Idem du côté de XFS, la période est relativement calme. À noter que le sous‐système XFS n’est plus maintenu par SGI mais désormais par Dave Chinner (Red Hat). Celui‐ci remercie au passage grandement SGI pour le boulot réalisé depuis les débuts de XFS. Les modifications les plus significatives concernent la gestion de O_TMPFILE, ainsi que l’option de l’appel système fallocate (COLLAPSE_RANGE et ZERO_RANGE).

Btrfs

Suite à l’embauche de Chris Mason chez Facebook, puis au déploiement sur une ferme de serveurs de test de Btrfs, ce système de fichiers a le vent en poupe. Btrfs se voit amélioré considérablement, avec une bonne salve de corrections et d’améliorations de performance qui ne semblent cependant pas visibles dans les tests de Phoronix.

Le temps semble être à la stabilisation de Btrfs.

F2FS

Ce système de fichiers qui s’entend bien avec les mémoires Flash (Flash‐Friendly File System) se voit doté d’une amélioration des performances sous certaines charges de serveur, ainsi que d’une gestion des dossiers de taille importante.

kernfs

Le pseudo‐système de fichiers kernfs a été tout juste introduit dans la version 3.14. Il reprend la logique de sysfs pour la rendre plus utile aux différents sous‐systèmes ayant besoin d’un système de fichiers virtuel. Il continue d’être amélioré, en particulier par Tejun Heo, auteur de la majorité des correctifs.

ZRAM

Ajout de la gestion de l’algorithme de compression LZ4 pour zram. zram est un système de d’échange de mémoire (swap) compressé tournant en mémoire vive, afin d’améliorer les performances des machines qui en manquent.

En vrac

Par manque de temps, tous les changements n’ont pu être résumés. Voici quelques informations complémentaires :

Virtualisation KVM

Les nouveautés tirées de la demande d'intégration :

  • pour les architectures ARM, il y a quelques corrections pour les caches ;
  • du côté du PowerPC, les invités peuvent profiter de la mémoire transactionnelle (disponible avec le POWER8) ;
  • MIPS profite de quelques corrections de bogue, mais d’autres devraient arriver avec la prochaine version, car QEMU va avoir droit à KVM avec MIPS ;
  • pour les x86 :
    • des optimisations dans les registres de débogage utilisés par certains jeux pour Windows,
    • de manière générale, les invités Windows profitent de plusieurs corrections de bogues,
    • pour tous les invités, les instructions des processeurs Intel Broadwell sont maintenant exposées, ainsi que les instructions MPX développées par Intel pour protéger les accès mémoire,
    • pour les invités OS X, il y a un contournement avec le minuteur de préemption pour la virtualisation imbriquée, et quelques modifications de l’horloge présentée par KVM ;
  • pour l’architecture s390 (les ordinateurs centraux d’IBM), les erreurs de page asynchrones sont implémentées, et des améliorations des interruptions font que les périphériques virtio sont plus rapides.
Xen

Aucune nouveauté du côté de Xen pour cette version.

Le bilan en chiffres

Une fois n’est pas coutume, LWN n’a pas encore publié son article sur les statistiques des contributions à cette nouvelle version de Linux.

Nous avons profité de ce délai de leur part pour améliorer la qualité de cette dépêche, mais nous ne pouvons pas la retarder infiniment. Nous rajouterons cette partie dans un commentaire quand l’article de LWN sera disponible.

Appel aux volontaires

Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :

Mainteneur Contributeur(s) La phase de test aucun Julien Pecqueur, Albert_ Architecture Romain Perier Sébastien Chauvel Pilotes graphiques libres Martin Peres Réseau Florent F. Systèmes de fichiers Jiehong Martin Peres Sécurité Timothée Ravier Virtualisation Xavier Claude Édition générale aucun Martin Peres, Davy Defaud, rogo

Un peu de vocabulaire :

  • Le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie. Il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer.
  • Un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche. Il n’y a aucune forme d’engagement pour le futur.

Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps. Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les correctifs intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Sortie de Linux 3.15

jeu, 12/06/2014 - 07:35

La sortie de la version stable 3.15 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.

Sommaire En bref
  • Pilotes graphiques libres :
    • DRM : interface unifiée pour la gestion des plans graphiques ;
    • Radeon : gestion de l’encodage vidéo matériel et d’une nouvelle puce unifiée avec processeur graphique intégré (APU) ;
    • Nouveau : gestion initiale de la famille Kepler et meilleure gestion des ventilateurs.
  • Réseau :
    • amélioration forte des performances ;
    • affectation de règles iptables à un cgroup.
  • Systèmes de fichiers :
    • réduction du temps de réveil après une mise en veille en mémoire vive ;
    • nouvel appel système pour échanger les noms entre deux fichiers de façon atomique ;
    • verrous POSIX par fichier ;
    • ajout de la gestion de l’algorithme de compression LZ4 pour zram.
La phase de test RC-1

La version RC-1 est sortie le 13 avril 2014.

Ça fait deux semaines que la 3.14 a été livrée et la 3.15-rc1 est maintenant étiquetée et publiée ; les correctifs et les archives tar » sont — au moment où j’écris ces lignes — en train de passer dans les compresseurs de kernel.org. Ce qui veut dire que la fenêtre de fusion est fermée et que les gens doivent m’envoyer uniquement des corrections de bogues.

Et franchement, il était temps. Cette version ne contient pas vraiment de choses bizarres, mais elle est grosse. Bien sûr, nous avons déjà eu des versions avec plus de lignes et de fichiers modifiés (3.7-rc1 et 3.11-rc1, notamment), mais celles-ci ont tendance à avoir quelque chose de particulier dedans (3.7-rc1 a vu la désintégration largement automatisée du fichier d’en-tête UAPI et la 3.11 a vu la fusion de la correction des bogues de Lustre).

En comparaison de ces grosses versions, 3.15-rc1 est seulement grosse. Pas de gros changement unitaire, mais seulement énormément de correctifs. Effectivement, il y a eu quelques intégrations de nouveaux pilotes (rtl8723au, notamment). Mais, même s’ils étaient gros, ils ne représentent pas la majorité des changements. Il y a seulement énormément de changements.

En fait, nous avons le plus grand nombre de correctifs dans l’histoire récente (peut-être depuis toujours), à un peu plus de 12 000 correctifs hors fusions (et environ 800 fusions).

Et il y en a vraiment un peu partout. L’essentiel concerne les modifications de pilotes, ce qui représente environ trois quarts des modifications. Le staging se démarque, mais c’est vraiment sur tout ​​le périmètre des pilotes, avec le réseau, le son, les médias, les pilotes graphiques, les pilotes de blocs…

Mais il y a aussi des tonnes de trucs qui ne concernent pas les pilotes. En dehors du sous-répertoire des pilotes, les mises à jour d’architecture comptent environ pour la moitié des changements (avec en tête ARM, principalement dû aux « device-tree descriptors ». Mais il y a aussi IPS, x86, PowerPC, s390, Blackfin…). Et le reste est aussi assez varié, avec le cœur du réseau, la documentation, le noyau, mm, les outils, etc.

Ainsi, alors que les modifications de pilotes et d’architecture représentent l’essentiel, nous avons aussi beaucoup de changement du cœur.

Quoi qu’il en soit, encore plus que d’habitude, la RC-1 est beaucoup trop grande pour inclure un résumé du rapport de toutes les publications. Mais le résumé du rapport des fusions que j’ai fait peut donner à minima une vue d’ensemble de tous les changements. Comme d’habitude, les personnes citées dans le rapport de fusion sont les mainteneurs depuis que j’ai récupéré les changements, et non les développeurs qui ont écrit le code. Vous pouvez voir ça dans les journaux complets de git.

Quoi qu’il en soit, comme la RC-1 est déjà sacrément grosse, je ne veux pas entendre de « désolé j’ai raté la fenêtre, puis-je encore me faufiler ? ». Corrections uniquement.

La seule exception concerne deux choses en cours qui sont arrivées pendant la fenêtre de fusion, mais qui ont été explicitement retardées. Nous avons donc en attente un mouvement de fichier fbdev (je ferai le mouvement du fichier après la RC-1, simplement pour que les choses soient plus simples à voir dans l’historique et ne pas mélanger les mouvements avec les développements). Et il y avait une demande de fusion sur les espaces de noms et montages que je n’ai pas intégrée, mais que je ferai probablement après quelques améliorations ou commentaires supplémentaires. Ça retardera probablement la 3.16, mais nous verrons de combien de lignes de code ce truc a besoin…

Linus

RC-2

La version RC-2 est sortie le 20 avril 2014.

« Et le septième jour la RC est ressuscitée, conformément aux Écritures du Kernel summit de l’année 2004. »

Cela fait une semaine, donc voici une nouvelle RC. Et alors que la RC-1 était de mémoire une des plus grosses RC, la RC-2 a l’air tout à fait normale. Nous avons eu quelques erreurs tenaces corrigées, mais ce n’était pas réellement quelque chose de pire que d’habitude. C’est peut‐être un peu plus gros que la plupart des RC-2, mais attendons de voir après la RC-3 quelles choses sont vraiment plus actives que d’habitude. La RC-2 est régulièrement plus calme que la RC-3, car il faut plus d’une semaine pour que certaines anomalies surviennent.

Quant à ce qu’il s’est passé au cours de la semaine dernière, le gros du correctif RC-2 est, en fait, la suppression du pilote RTL8187SE de staging, car il y en a maintenant un bon en dehors de staging. C’est vraiment un peu plus de la moitié du correctif en lui‐même. Mais, même si vous ignorez tout simplement cette sortie, les autres changements de pilotes représentent environ les deux tiers du reste (pilote graphiques, réseau, renommage des fichiers fbdev, IPMI, InfiniBand, pin control… Nommez votre pilote préféré). La partie concernant le DRM est probablement la plus remarquable.

En dehors des pilotes, nous avons les mises à jour habituelles d’architectures (principalement x86 et s390, un peu de PA-RISC) et quelques mises à jour de documentation. Quelques corrections pour le réseau et des mises à jour de système de fichiers (CIFS, sysfs, XFS). Et quelques trucs d’outillage.

Testez, s’il vous plaît,

Linus

RC-3

La version RC-3 est sortie le 27 avril 2014.

Nouvelle semaine, nouvelle RC. Jusqu’à présent, pas de grosses craintes et la RC-3 est adéquatement plus petite que la RC-2 ne l’était, nous sommes donc sur la bonne voie.

Les statistiques semblent relativement normales, avec une moitié de pilotes (pilote d’entrées, USB, pilotes graphiques, ACPI, régulateur…) et un tiers de mises à jour d’architectures (la majorité portant sur les fichiers DTS pour ARM, mais aussi d’autres mises à jour sur ARM et user-mode). Le reste est varié, mais principalement concentré sur les mises à jour des systèmes de fichiers (Btrfs et ext4).

Linus

RC-4

La version RC-4 est sortie le 4 mai 2014.

Rien de particulièrement exceptionnel en cours. 45 % de pilotes (DRM, son, [md](http://en.wikipedia.org/wiki/Mdadm "multiple device), pin-control, ACPI, etc.), 40 % d’architecture (principalement powerpc/powernv, mais aussi x86 et ARM), 15 % de divers (outillage de performance, mises à jour documentaires et code du noyau). Le rapport simplifié ci‐joint donne un bon aperçu des détails sans être trop gros.

Il y a encore quelques trucs en cours (par exemple, une correction en attente pour une intéressante corruption de la liste des « entrées de répertoires » (dentry) — même si une utilisation normale aura peu de risque d’être affectée). Mais, dans l’ensemble, c’est relativement calme et il n’y a rien d’horriblement effrayant. Nous sommes au milieu de la période d’apaisement, donc c’est comme je l’aime.

Mais, plus nous avons de tests, mieux c’est ; donc, s’il vous plaît, essayez-la.

Linus

RC-5

La version RC-5 est sortie le 9 mai 2014.

Oui, je suis conscient que c’est en avance de deux jours. Le programme normal était pour moi de faire des versions dominicales, mais, cette fois j’ai une combinaison de voyage (ce qui aurait avancé la version à samedi matin depuis l’aéroport comme c’est souvent mon habitude quand je voyage) et il se trouve que la RC-5 avait déjà suffisamment grossi pour être plus grosse que les RC-3 et RC-4 ne l’étaient.

Donc, au lieu de publier ça à la dernière minute avant que j’embarque dans un avion et que je sois hors ligne pour une semaine, j’ai décidé qu’il n’y a absolument aucune raison pour ce genre de livraison sur le fil. Je préfère faire une livraison tranquillement un vendredi après‐midi, plutôt qu’une précipitée un lendemain matin avant de disparaître pendant une semaine.

Peu importe, assez d’explications. La RC-5 est sortie et, bien que j’eusse été plus joyeux si ça avait été aussi petit que la RC-4, ça semble n’être que des corrections solides (fameux derniers mots). L’intéressante corruption de la liste dcache, que j’avais mentionnée comme reliquat de la RC-4, est dedans ; et ce serait adorable si vous aviez un test de charge pour la couche VFS qui interagit avec la consommation de mémoire. Mais, le jeu en valait la chandelle, la correction nettoie pas mal de choses et retire plus de lignes qu’elle n’en ajoute, donc je la sens bien.

Exceptée cette intéressante modification véritable du cœur (où « véritable du cœur » est défini comme « un domaine auquel je tiens particulièrement », et ne signifie rien de plus ;), tout semble ennuyeusement familier : 55 % de pilotes, 20 % de mises à jour d’architectures et 25 % de divers (systèmes de fichiers, cœur du réseau, machines virtuelles, etc.).

Et, bien que cette RC-5 soit peut‐être plus grosse que les RC-3 et 4 ne l’étaient, ce n’est pas comme si c’était inquiétant. Cette période de fusion était plus grosse que la moyenne, et le fait que la RC-5 est donc un peu plus grosse que la moyenne n’est pas quelque chose qui m’inquiète plus que ça. Et comme la RC-4 était plus petite que d’habitude, tout s’égalise.

Mais je serai réellement entièrement non joignable toute la semaine prochaine, donc faites vos tests, parce que l’arborescence git sera très calme.

Linus

RC-6

La version RC-6 est sortie le 22 mai 2014.

À cause des voyages et du manque d’accès à Internet, des publications de RC n’ont pas suivi le cycle normal de publication dominicale, et, comme j’ai pris connaissance de ce qu’il s’est passé pendant que j’étais hors ligne, plutôt que d’attendre jusqu’à dimanche prochain pour revenir à un cycle normal, je publie en conséquence la RC-6 en milieu de semaine depuis Tokyo.

Avec la RC-5 qui était en avance de quelques jours et la RC-6 qui est en retard, nous avons presque deux semaines entre elles. La taille du résultat n’est pas deux fois plus grosse cependant. En partie parce qu’heureusement on a avancé dans la série des RC et que les choses sont censées se calmer, mais aussi parce que certains sous‐mainteneurs n’ont pas envoyé leurs demandes d’intégration car ils savaient que j’étais hors ligne. Quelle que soit la raison, c’est pas mal.

La distribution du correctif à l’air normale aussi. Principalement des pilotes (ACPI, son, média, pilote graphique i915, horloge clk, PCI…), avec le gros du reste qui correspond à diverses mises à jour d’architectures (notamment MIPS, mais aussi ARM et PA-RISC). Et une poignée de trucs divers dans les systèmes de fichiers et le code du cœur du noyau.

De toute façon, en fonction de ce qui est en cours, je rallongerai un peu la RC-7 pour revenir à une planification dominicale et, en fonction de comment les choses se passent d’ici là, ça pourrait être ne pas être la dernière RC.

Mais, s’il vous plaît, testez ça,

Linus

RC-7

La version RC-7 est sortie le 25 mai 2014.

… cette sortie dominicale se recale sur le calendrier habituel.

La RC-6 a seulement quelques jours, mais, comme prévu, du travail m’attendait à la maison. Cette version est donc normale, la RC-6 ayant juste été décalée par mon voyage.

Le contenu est en grande partie composé de changements concernant le réseau (principalement les pilotes), puisque les autres branches avaient été mises à jour pour la RC-6. Il y a aussi d’autres petits changements (DRM, ordonnanceur, perf, NFS, AFS, etc.).

Linus

RC-8

La version RC-8 est sortie le 1er juin 2014.

J’ai vraiment espéré que la RC-7 serait la dernière RC, mais la réalité a encore conspiré contre mes super plans bien établis, et me force donc à faire une RC-8. Ce n’est pas comme s’il y avait beaucoup de changement, mais une correction de dernière minute de dcache me fait penser que cela ne serait pas complètement sain de sortir la version définitive sans une semaine de test supplémentaire.

De tout de façon, normalement, une RC-8 n’est pas vraiment un énorme changement — la 3.15 est une des plus grosses (si ce n’est la plus grosse) version depuis bien longtemps, et nous faisons des RC-8 assez régulièrement. Ça pourrait ne pas être le cas de toutes les versions, mais je pense que nous avons 50 % de chances de faire une RC-8 à chaque version. Aussi je ne suis pas très fâché, et sûrement pas surpris.

Non, la véritable raison pour laquelle j’avais espéré que nous n’aurions pas besoin de faire une RC-8 pour la 3.15, c’est que c’est la fin des classes dans deux semaines et nous devons prendre nos vacances en famille juste après. Je déteste avoir encore un « Linus voyage pendant la fenêtre des fusions ». Normalement, je suis plus chanceux que ça durant dans mes voyages.

Certes, j’aurai Internet, et je pourrais faire la fenêtre des fusions pendant mes vacances en famille. Je préférerais juste ne pas à avoir le faire.

Aussi, essayons de voir comment cela va marcher — les dernières semaines de versions consistent généralement à regarder et être sûr que rien de grave ne se passe, par conséquent, le développement devrait fonctionner. Peut‐être que si cela fonctionne bien, nous finirons par continuer comme cela, même s’il n’y pas de conflit de calendrier qui me fait vouloir démarrer la fenêtre des fusions avant que je sois 100 % satisfait de la version précédente.

Ce n’est pas comme si je pensais que la RC-8 était cassée de quelque façon que ce soit. Je ne me sentais simplement pas faire une version 3.15 sans un petit peu plus de temps pour que les gens testent le correctif pour le dentry.

Quoi qu’il en soit, en dehors du changement dcache, il y a plein de petites choses éparpillées. Un changement d’une ligne est particulièrement intéressant : Minchan Kim avait trouvé un cas de figure qui remplissait entièrement la pile du noyau sur l’architecture x86-64 ; et, bien que cela soit quelque chose que je repoussais depuis longtemps, ce changement étend la pile à 16 Kio. Je pense que toutes les autres architectures 64 bits avaient cela depuis longtemps, aussi cela n’est pas très choquant, mais c’est, quelque part, assez fondamental sur une des architectures principales pour être mentionné.

Linus

Version finale

La version finale est sortie le 8 juin 2014.

Je me suis donc résigné à faire une RC-8, parce que j’étais un peu inquiet des corrections de dernière minute sur dcache, mais il s’est avéré que personne ne semble avoir remarqué quoi que ce soit. Malgré tout, nous avons eu d’autres problèmes pendant la semaine, aussi cela n’était pas plus mal. Les corrections de verrous futex et les nettoyages se démarquent, mais comme d’habitude il y a diverses autres corrections un peu partout réalisées depuis la RC-8, principalement les pilotes (DRM, réseau, son, USB, etc.), le réseau, l’ordonnanceur et les outils de mesure de performance.

Mais cela a été dans l’ensemble raisonnablement petit et calme, ce qui doit être, bien entendu, dû au fait que la semaine dernière était également la première semaine de la période de fusion pour la 3.16. Cela a pu distraire certains développeurs. Je ne suis pas complètement convaincu d’avoir apprécié le chevauchement, mais il semblerait que cela ait fonctionné correctement. Et, à moins que les gens crient très fort (« S’il te plaît ne refais plus jamais cela ! ») et qu’ils donnent de bonnes raisons pour cela, je pourrais refaire un chevauchement des fenêtres de fusion dans le futur, si cela peut aider pour certains problèmes de délai.

Ceci dit, je ne pense pas que cela ait été une expérience grandiose au point que je refasse un chevauchement à chaque fois, sans une bonne raison spécifique pour cela. C’était assez agréable d’être productif la dernière semaine de la RC (qui est généralement plutôt ennuyeuse et morte), mais je pense que cela pourrait représenter une distraction quand les gens devraient s’inquiéter de la stabilité de la RC.

Bien sûr, il se pourrait que le chevauchement aboutisse à moins de bruit pendant la dernière semaine de stabilisation, et que cela aide réellement. Cela pourrait aussi produire l’inverse. Je serais intéressé d’entendre l’avis des autres personnes, mais je soupçonne que la plupart n’ont aucune opinion particulière sur le sujet.

Quoiqu’il en soit, avec la version 3.15 publiée, ma branche « master » a déjà été fusionnée avec ma branche « next » sur ma machine locale, et je vais démonter la branche « next » une fois que j’aurai dégagé tout ça. Après cela, les futures fenêtre de fusion se feront sur la branche « master » et nous reviendrons au modèle normal de branche unique pour mon arbre.

Linus

Les nouveautés Architecture Gestion du mode mixte EFI

Certaines machines ont un micrologiciel EFI 32 bits, les noyaux 64 bits ne pouvaient du coup pas démarrer simplement dessus. Le mode mixte EFI (EFI mixed mode) ajouté à cette version 3.15, permet maintenant d’y remédier. Un exemple concret est la possibilité pour l’ASUS Transformer Book T100TA de démarrer sur un tel micrologiciel.

Le mode mixte EFI est un mode qui permet aux micrologiciels EFI 32 bits de démarrer sur des noyaux 64 bits, à condition que le chargeur de démarrage gère le protocole EFI handover. La plupart des chargeurs de démarrage populaires comme GRUB, SYSLINUX ou EFILINUX le gèrent, il sera donc possible de disposer de cette fonctionnalité très simplement à condition d’activer l’option CONFIG_EFI_MIXED depuis les options de configuration du noyau Linux.

AVX-512

Les premiers processeurs proposant le jeu d’instructions AVX-512 ne seront commercialisés qu’en 2015, avec la génération Knights Landing des processeurs Intel. Toutefois, leur prise en charge est déjà disponible dans cette version 3.15.

AVX-512 (Advanced Vector Extensions), extension directe de AVX-256, est un jeu d’instructions SIMD (Single Instruction Multiple Data). Il s’agit d’un jeu d’instructions qui permet d’appliquer une même opération arithmétique sur plusieurs données en parallèle. Par opposition aux instructions habituelles de type SISD, pour Single Instruction Single Data, SIMD permet d’appliquer une même opération d’addition, de multiplication sur plusieurs éléments d’une structure très régulière, comme c’est par exemple le cas sur des tableaux ou des matrices. AVX-512 permet, entre autres, d’agrandir la taille des registres AVX à 512 bits, ou encore va donner la possibilité aux compilateurs de vectoriser plus de boucles efficacement, grâce aux instructions Conflict Detection Instructions (CDI) qui, comme leur nom l’indique, permettent la détection des conflits.

Améliorations de l’ordonnanceur

L’ordonnanceur subit un travail de préparation qui vise à permettre une meilleure intégration avec le choix des états de veille du processeur, pour économiser l’énergie. Cela ne sera disponible que dans de futures versions du noyau [commit de fusion].

Il y a aussi eu plusieurs améliorations liées à l’usage des cgroups, notamment lors du changement de contexte entre deux processus d’un même cgroup [1, 2, 3].

Abandon des anciennes plates-formes x86

Je vais faire pleurer ceux d’entre vous qui ont des enfants qui jouaient à Jill, Linux 3.15 ne gère plus ces systèmes excitants introuvables que sont les SGI Visual Workstations, Sequent Computer Systems NUMAQ, IBM Summit/EXA et autres Unisys ES7000.

Instruction RDSEED

À partir du noyau 3.15, /dev/random utilisera les nouvelles instructions RDSEED des futures générations Broadwell de chez Intel [demande d’intégration].

À partir de cette génération, les processeurs Intel proposent une nouvelle instruction RDSEED. Il s’agit d’une instruction de génération de bits aléatoires. Comparée à son homologue RDRAND, qui fut introduite avec la génération Ivy bridge, elle est destinée à être utilisée par les logiciels qui disposent déjà d’un générateur de nombres pseudo-aléatoires (PRNG), en tant que « graine » (seed), c’est-à-dire une source d’entropie de nombres aléatoires. RDRAND, quant à elle, est une instruction de génération de nombres pseudo-aléatoires.

Systèmes mono-puces ARM

La plate-forme ARM est toujours très active, au point que les développeurs songent à mettre l’arborescence des périphériques dans un arbre Git dédié.

Parmi les nouveautés, on peut noter :

  • l’ajout de la carte de développement A10-OLinuXino-LIME ;
  • l’ajout du Freescale l’i.MX35 ;
  • l’ajout des dérivés Freescale i.MX51 , i.MX25 et i.MX35 de chez Eukréa ;
  • un ensemble d’améliorations au niveau des systèmes mono-puces i.MX de chez Freescale ;
  • pas mal d’améliorations au niveau des systèmes mono-puces de chez ATMEL.
ACPI

Avant Linux 3.15, l’événement envoyé lors de l’appui sur une touche « augmenter la luminosité » ou « baisser la luminosité » pouvait signifier deux choses pour un environnement de bureau :

  1. notification comme quoi la luminosité a été modifiée ;
  2. touche de modification de luminosité pressée, « débrouille-toi ».

La plupart des environnements de bureau interprètent cet événement comme le cas numéro 2, ce qui causait des problèmes : changement de luminosité effectué deux fois — une fois par le noyau, une fois par l’environnement de bureau — ou changement de luminosité non détecté, et donc notification non affichée, etc. En effet, le scénario numéro 1 est très difficile à détecter en espace utilisateur.

Désormais, la grosse majorité des ordinateurs portables seront dans le cas numéro deux, ce qui rend la gestion de la luminosité plus simple et plus cohérente et résout les cas cités ci-dessus [commit].

Changement de la taille de la pile du noyau

La pile du noyau pour l’architecture x86_64 voit sa taille passer de 8 Kio à 16 Kio. Ce changement a été effectué par Minchan Kim [commit].

Pilotes graphiques libres DRM (Direct Rendering Manager)

Le code commun aux pilotes graphiques libres (DRM) a reçu plus d’attention que d’habitude pour cette nouvelle version, notamment afin de préparer la venue de nouvelles fonctionnalités dans les versions futures. Il n’y a donc rien de visible pour le moment pour l’utilisateur final.

Le premier gros changement est la gestion universelle des plans d’affichage (display planes). Jusqu’à présent, le DRM n’exposait que les plans de type sprites et superposition (overlay) vidéo. Les plans pour curseurs étaient, eux, exposés via des appels ioctl() dédiés, alors que les plans primaires n’ont jamais été exposés. Désormais, tout client exposant la capacité DRM_CLIENT_CAP_UNIVERSAL_PLANES pourra accéder à l’interface de plans universelle (universal plane) et à la liste complète des plans proposés par le matériel. Ce client pourra dès maintenant changer des paramètres tels que la mise à l’échelle (scaling) ou désactiver l’affichage, sans avoir à effectuer de changement de mode graphique au niveau du contrôleur vidéo (CRTC). Cependant, l’intérêt de cette nouvelle interface ne sera clair que lorsque le travail de changement atomique du mode graphique et du commutation de pages (page flip) du noyau sera terminé. En attendant, si vous voulez plus d’information, vous pouvez consulter ce message ou l’article récapitulatif de la gestion du mode graphique de Pekka Paalanen (développeur Wayland).

Le deuxième changement important est la mise en commun du code gérant le canal auxiliaire de communication du DisplayPort (DP). Cela va permettre la gestion du Multi-Stream Transport (MST) proposé par le DisplayPort, qui permet de multiplexer plusieurs liaisons vidéo à travers le même câble DP. Voici la demande d’intégration de cette nouvelle infrastructure. La gestion du MST devrait, quant à elle, arriver dans Linux 3.16 ou 3.17.

La gestion des nœuds maîtres, mineurs et de contrôles a été revue dans cette version, notamment sur la gestion des verrous. En parlant de verrous, les symboles DRM vérifient maintenant activement que les bons verrous ont été pris avant l’appel, au lieu de simplement le marquer dans la documentation. Mais le changement le plus important vient mettre fin à une bidouille pour l’allocation d’un espace d’adressage pour le périphérique. En effet, il est impossible d’allouer un espace d’adressage sans avoir de nœud d’index (inode) disponible. Du coup, DRM attendait que le premier client ouvre un nœud vers un processeur graphique avant d’allouer l’espace d’adressage. Cette technique était clairement une bidouille, et Al Viro (mainteneur VFS) a conseillé d’utiliser une autre méthode qui a été appliquée.

Pour finir, la documentation DRM a été corrigée et nettoyée.

Adreno (pilote msm)

Dans cette nouvelle version, le pilote msm gagne la possibilité de diffuser du son via la prise HDMI [correctif] et devient plus économe en énergie en activant le clock gating après 66 ms d’inactivité [correctif].

Après un article de LWN sur comment gérer proprement des drapeaux inconnus dans les ioctl() ou les appels systèmes, Rob Clark a vérifié à nouveau son code et trouvé quelques problèmes qu’il a corrigés [correctif]. Ces modifications cassent la compatibilité binaire, mais Rob se justifie en disant qu’il n’y a presque aucun pilote en espace utilisateur et que, si une application venait à être cassée par ce changement, il reviendrait partiellement sur son correctif.

Le pilote msm utilise maintenant les plans d’affichage universels qui viennent juste d’être introduits, au lieu de l’ancienne interface de programmation [correctif].

Pour finir, une option noyau a été ajoutée afin d’afficher l’état des registres lorsque le processeur graphique se bloque [correctif]. Cela devrait aider pour l’écriture de rapports de bogues.

Pour information, le pilote freedreno (accélération 3D pour Adreno) utilisant le pilote msm vient de recevoir la prise en charge d’OpenGL 2.1. Celui-ci prenait en charge OpenGLES 2.0 depuis quelque temps, mais ne gérait pas quelques extensions nécessaires pour la version « bureau » d’OpenGL. Ce code devrait être disponible dans Mesa 3D 10.3 qui sortira en août.

AMD/ATI (pilote radeon)

La principale nouveauté concernant le pilote radeon est la prise en charge de l’encodeur vidéo matériel VCE afin d’accélérer la conversion de vidéos au format H.264. Ce noyau permet l’utilisation de cet encodeur à travers le standard OpenMAX, du groupe Khronos. Ce n’est pour l’instant possible qu’avec la version VCE 2.0 du matériel, la prochaine version de Mesa 3D (10.3) [correctif] et le greffon GStreamer gst-omx.

Cette nouvelle version apporte également la prise en charge complète d’un petit dernier dans la famille des processeurs APU Kaveri, le Mullins, qui est sorti le 29 avril 2014.

Pour finir, radeon a laissé tomber sa gestion spécifique du canal de communication auxiliaire du DisplayPort, afin d’utiliser la nouvelle version proposée par DRM [correctif]. Beaucoup d’autres bogues ont également été corrigés, notamment dans la gestion des horloges.

Samsung (pilote exynos)

Un gros travail de réorganisation du code a été mené sur le pilote exynos, avec notamment le déplacement du pilote DisplayPort depuis video/ vers drm/, afin de gérer correctement le branchement à chaud et le changement de mode graphique [correctif]. Il est également à noter l’ajout de la gestion des ponts LVDS, ainsi que des écrans à interface parallèle (remplacée par l’interface DSI).

Pour plus d’informations, vous pouvez consulter la demande d’intégration exynos.

Intel (pilote i915)

Aucune nouvelle fonctionnalité activée par défaut pour le pilote i915 dans cette version, mais un énorme travail de fond a été effectué.

La gestion des Per-Process Graphics Translation Tables (PPGTT, tables de traduction graphique par processus) fait son apparition, mais est désactivée par défaut à cause de quelques bogues trouvés à la dernière minute. PPGTT est une fonctionnalité des processeurs graphiques inclus dans les processeurs Intel Ivy Bridge, Haswell, et Broadwell qui permet l’isolation des tâches du processeur graphique, ce qui améliore la sécurité en fournissant un contexte et un espace d’adressage par descripteur de fichier et client de ressources graphiques. Pour en savoir plus sur GTT et GEM, un cours d’introduction a été écrit par Ben Widawsky, un ingénieur de chez Intel.

Par le passé, la gestion du power gating et du clock gating par le matériel Intel a surtout été gérée automatiquement. Désormais, les nouvelles architectures requièrent l’intervention du pilote afin, notamment, de sauvegarder et restaurer le contexte. Donc, il est nécessaire de préparer une infrastructure permettant de représenter les domaines énergétiques, de suivre leur état et de gérer les changements d’état. Comme les domaines énergétiques sont très dépendants de l’architecture et sont amenés à évoluer dans le futur, une couche d’abstraction est proposée par l’infrastructure. Cette infrastructure devrait commencer à être utilisée dans Linux 3.16.

Du côté de l’affichage, la gestion expérimentale du démarrage rapide et sans clignotement a été améliorée afin de pouvoir hériter du mode graphique qui a été mis en place au démarrage par le micrologiciel EFI. Encore un peu de travail est nécessaire pour rendre sa gestion parfaitement fiable, ce qui explique pourquoi l’option n’est pas activée par défaut bien que toute l’infrastructure soit maintenant en place. Si vous voulez l’essayer malgré tout, vous pouvez ajouter l’option i915.fastboot=1 à votre ligne de commande noyau.

Concernant l’affichage, la prise en charge des liens DisplayPort à 5,4 GHz, nécessaire pour piloter des écrans à ultra haute définition (4K), est disponible. Malheureusement, les écrans 4K actuels exposent généralement deux écrans, via le Multi-Stream Transport (MST), afin de proposer la 4K. En parlant de MST, le pilote i915 utilise maintenant la gestion du canal auxiliaire du DisplayPort proposée par DRM, ceci afin de pouvoir plus tard gérer les écrans accessibles via MST. Enfin, la gestion des grands curseurs a été ajoutée afin de mieux gérer les curseurs sur les écrans à haute densité de pixels.

La prise en charge des processeurs Broadwell a reçu beaucoup de modifications, mais elle reste encore incomplète. D’autres devraient suivre dans Linux 3.16.

Pour plus d’informations, vous pouvez consulter le billet de blogue de Daniel Vetter dédié à Linux 3.15.

NVIDIA (pilote nouveau)

La nouveauté principale côté du pilote nouveau est la gestion expérimentale de la nouvelle famille de cartes NVIDIA Maxwell, sortie le 18 février 2014. Cette gestion se limite actuellement au mode graphique [correctif] et à l’accélération 3D [correctif] en utilisant le microcode de NVIDIA. Ce microcode sera remplacé dans le futur par une version entièrement libre, quand les fonctionnalités basiques s’exécuteront en espace utilisateur. En effet, cette nouvelle famille de cartes a introduit un nouveau jeu d’instructions qu’il a fallu étudier et intégrer à Mesa 3D [correctif]. Il manque cependant les modifications nécessaires au pilote X.Org xf86-video-nouveau pour pouvoir utiliser l’accélération 2D et 3D sur processeur graphique Maxwell avec un serveur X.

Une première version d’un système de reprise sur panne a également été intégrée pour Kepler, afin de ne pas bloquer tout le système lorsque l’unité de gestion mémoire ne connaît pas la correspondance entre une adresse virtuelle et une adresse physique. Le pilote nouveau devrait également mieux gérer les cas où le microcode de changement contexte se bloque.

La gestion automatique de la ventilation s’améliore avec la correction de multiples bogues, et, surtout, l’ajout de la gestion de deux nouveaux types de ventilateurs couramment trouvés dans la famille Kepler. Si vous avez encore des problèmes de ventilateur dans cette version, vous êtes invités à écrire un rapport de bogue. De multiples bogues concernant la lecture du BIOS vidéo ont également été corrigés, en partie grâce à l’aide de NVIDIA.

Parmi les modifications apportées dans Linux 3.15, l’une d’elles se distingue particulièrement, pour deux raisons :

  • elle prépare nouveau afin de pouvoir gérer le processeur graphique ARM Tegra K1, qui n’est pas accessible via un bus PCI, AGP ou PCIe ;
  • elle est écrite par un nouvel employé de NVIDIA, Alexandre Courbot.

Ce n’est pas la première fois que NVIDIA contribue à nouveau puisque Aaron Plattner l’avait déjà fait en février 2013, mais c’est cependant la première fois que la gestion d’un nouveau jeu de composants est écrite par un employé de NVIDIA, français, qui plus est. Alexandre Courbot est, en effet, actif sur l’IRC et les listes de diffusion de nouveau et ajoute la gestion du Tegra K1 (nom de code GK20A) au noyau, tel que nous le rapportions sur LinuxFr.org en février. La majorité des contributions sont encore à venir, notamment dans Linux 3.16. La gestion de l’accélération 3D en espace utilisateur n’a pour l’instant nécessité que -8 / +21 changements ! Plus d’information dans un futur proche, mais, en attendant, voici une petite démonstration de l’avancement.

Poulsbo (pilote gma500)

Le pilote gma500 du tristement célèbre processeur graphique à basse consommation Poulsbo évolue doucement, avec la prise en charge d’un nouveau type d’unité de gestion mémoire et de gestionnaire d’interruptions (SGX).

Tegra (pilotes host1x et tegra)

Les choses ont bien bougé du côté de host1x qui reçoit une infrastructure pour l’allocation de contextes, la synchronisation des moteurs d’exécution et la gestion du moteur de rendu 2D. La gestion de la 3D est en cours d’écriture. Bien que ce travail ait été testé durant plusieurs semaines par de multiples contributeurs, les contrôles d’entrées-sorties introduits pour tegra sont actuellement considérés comme staging (branche git dédié à la mise en œuvre) de façon à permettre un changement plus tard, si l’interface venait à ne pas être adaptée. La gestion de la 2D et de la 3D a été testée avec le pilote grate. Pour rappel, host1x est la partie des processeurs Tegra qui gère les transferts DMA, ainsi que l’affichage et l’envoi asynchrone de commandes au processeur graphique et autres systèmes multimédias. Le processeur graphique Tegra est, lui, séparé, à la fois dans la puce et dans le code, et se charge de l’accélération 2D et 3D.

Pour plus d’informations, vous pouvez consulter la demande d’intégration tegra/host1x.

VMware (pilote vmwgfx)

Le pilote vmwgfx, pour l’accélération graphique dans les machines virtuelles VMware tournant sous Linux, a revu sa politique de sécurité afin de pouvoir gérer les nœuds de rendu (render nodes).

Réseau À la recherche des performances

La recherche de gain en performance est une tâche courante dans le noyau Linux, et la partie réseau n’est pas en reste pour cette nouvelle version. Petit tour de ces nouveautés.

Une horloge plus fine

Dans les arcanes du très populaire TCP, l’estimation du RTT est importante pour certains algorithmes de gestion de la congestion. L’unité de cette estimation était la milliseconde, avec une bidouille immonde pour les cas inférieurs à cette valeur. Concrètement, cette bidouille dépendait de la fréquence de réveil de votre noyau (déterminée à la compilation). Cette fréquence étant à 1 000 Hz par défaut sur les architectures x86, l’estimation la plus fine utilisait des pas de 125 µs.

Sur des réseaux modernes très performants, ces 125 µs sont beaucoup trop imprécises. Le nouveau noyau compte donc désormais en microsecondes, mais reste compatible avec les anciens outils de l’espace utilisateur en exportant toujours les données en millisecondes. Une mise à jour de la commande ip sera nécessaire pour voir les changements.

Réécriture de l’interpréteur interne BPF

Que ne serait pas un nouveau noyau sans travail du côté du filtrage de paquets ? Le cœur de l’interpréteur a été réécrit dans cette version, avec pour objectif une amélioration des performances. Le correctif est accompagné de tests de performance prometteurs, et d’une promesse de faire encore mieux bientôt en adaptant le compilateur à la volée (Just In Time) de BPF.

Mettre à jour la somme de contrôle tout simplement

Pour limiter l’utilisation du processeur sur des réseaux à très forte capacité, un mécanisme courant est de déléguer une grande partie du travail à la carte réseau. L’idée est de faire « comme si » on envoyait et recevait des très gros paquets du côté noyau, pendant que la carte réseau se charge de découper/rassembler les paquets réels, bien plus petits. Pour en savoir plus, vous pouvez consulter un très bon article sur LWN.

C’est en utilisant ce mécanisme qu’un développeur de Google a détecté une forte utilisation du processeur pour le calcul de la somme de contrôle de ses paquets, avec près d’un pour cent du processeur dédié à cette simple tâche. Cette somme de contrôle a de bonnes propriétés mathématiques, elle est notamment incrémentale : quand on modifie un champ d’un paquet, on n’est pas obligé de tout recalculer, il suffit de calculer la différence induite par la partie réécrite.

L’analyse détaillée a donc conduit à identifier le coupable : la fonction csum_replace2(). Cette fonction prend une somme de contrôle, deux mots de 16 bits (l’ancien champ et le nouveau champ réécrit du paquet), et retourne la nouvelle somme de contrôle.

Cette fonction ne faisait pas réellement le travail, en délégant la tâche à la fonction csum_replace4(), prenant comme arguments des mots de 32 bits. Qui peut le plus peut le moins, mais le fait moins vite. csum_replace4() appelle, elle-même, une fonction générique encore plus complexe.

Cette mise à jour de la somme de contrôle est pourtant une tâche simple pour des mots de 16 bits, bien documentée depuis longtemps dans la RFC 1624. Davil Miller a signalé cette référence, et Éric Dumazet de chez Google a donc modifié la fonction pour utiliser cette méthode simple et rapide. Comme cette fonction est utilisée à d’autres endroits de la partie réseau, d’autres cas d’utilisation devraient profiter de ce gain.

Protection contre les dénis de service

Les dénis de service, consistant à surcharger un serveur par un nombre impressionnant de connexions, sont très courants sur Internet. Parmi ceux-ci, un grand classique est le bon vieux SYN flood. Sur un pare-feu à états, chaque paquet ajoutera une connexion à suivre, et il faut être capable de les gérer.

Chez Linux, ce suivi est effectué par la table conntrack. Cette table était protégée par un verrou central pour les insertions et les suppressions. Et ce verrou devenait avec le temps un énorme frein (un peu comme le Big Kernel Lock, à échelle très réduite).

Le nouveau noyau introduit donc un verrouillage plus fin, avec 1 024 verrous et une table de hachage pour savoir quel verrou utiliser. L’amélioration de performance est spectaculaire, si vous avez le matériel qui va avec. Avec un bon processeur et un réseau à 10 Gbit/s, le testeur est passé d’une gestion de 810 405 connexions par seconde à 2 233 876, soit une amélioration d’un facteur de presque trois.

Sécurité réseau cgroups et réseau

C’est une modification triviale, mais il est désormais possible d’attacher une règle iptables à un cgroup pour du trafic entrant. Cela permet notamment de compter le trafic entrant d’une application.

Toujours du côté des cgroups, une refonte assez importante a supprimé la possibilité de compiler le contrôleur cgroup net_prio en tant que module. C’était le seul qui utilisait cette possibilité.

IPsec

Dans un paquet IPsec, il est possible d’ajouter un compteur de paquets pour se protéger des attaques par rejeu (en refusant des paquets dont le compteur est inférieur aux valeurs déjà reçues). Ce compteur est historiquement de 32 bits, ce qui permet d’envoyer un certain nombre de paquets.

Ce nombre est cependant insuffisant pour les réseaux modernes, et une extension existe dans le standard depuis 2005 pour utiliser un compteur à 64 bits. Linux permettait de le faire pour le mode ESP d’IPsec (mode tunnel) et, à partir de cette version, l’autorise également pour le mode AH (mode transport).

Depuis sa version 3.6, le noyau permet de gérer le routage à travers un tunnel, avec les vti (Virtual Tunnel Interface, nom venant de Cisco), pour gérer plus facilement et plus dynamiquement le routage à travers un tunnel IPsec. Ces VTI sont uniquement une abstraction des règles IPsec existantes dans le noyau. Pour ces VTI, ce noyau ajoute la possibilité de configurer un espace de noms et de faire passer de l’IPv6 dans un tunnel IPv4.

Bluetooth

Ce noyau introduit la gestion du niveau 4 (le plus élevé) de la sécurité en Bluetooth. Concrètement, ce mode de sécurité force l’utilisation de clefs de chiffrement plus fortes, mais ne sera compatible qu’avec les équipements utilisant la norme Bluetooth 4.1. Il n’y a pas de compatibilité pour ce mode avec le matériel plus ancien.

Commentons avec nftables

Avec le pare-feu de nouvelle génération nftables, on peut désormais ajouter des commentaires arbitraires associés à une règle. Cela permettra à l’administrateur pressé de répondre à la question « Mais, pourquoi ai-je bien pu ouvrir le port 22 ? ».

Sécurité Audit

La valeur de proc/<pid>/cmdline (nommée proctitle) fait maintenant partie des informations remontées par le sous-système d’audit [correctif]. Cette chaîne de caractères peut être changée par le processus avec la fonction setproctitle(), et ne peut donc pas être considérée comme « de confiance » d’un point de vue sécurité.

En revanche, elle sera particulièrement utile pour le débogage sur Android notamment, car les applications ne sont pas lancées à l’aide d’un classique fork() + exec(). En effet, pour accélérer le lancement, les applications Java utilisent une instance (processus) préparée à l’avance par la machine virtuelle Java Dalvik et la spécialisent en chargeant les classes de l’application. Ceci évite notamment d’avoir à charger systématiquement les classes des paquets de base pour chaque nouvelle application lancée, et permet donc de profiter de la propriété de copie sur écriture (Copy-On-Write) de l’appel système fork(). Lorsque la machine virtuelle Java (JVM) lance une application, elle change la valeur de proctitle pour la faire correspondre à son nom et cela apparaîtra désormais dans les journaux d’audit.

La prise en charge de l’audit des appels système a aussi été étendue pour gérer les appels 32 bits sur une architecture 64 bits [correctif].

Gestion de l’Intel Trusted Execution Environment

Une série de correctifs [1, 2, 3, 4 et 5] ajoute la gestion du périphérique Intel Trusted Execution Environment à l’Intel Management Engine Interface (IMEI). L’IMEI est une interface IPMI faisant partie de l’Intel Active Management Technology qui est présente dans les processeurs avec la technologie Intel vPro. Elle permet de gérer un système en discutant directement avec une puce dédiée, sans passer par le système d’exploitation (out‐of‐band management).

LSM

Diverses corrections de bogues et améliorations mineures sont listées dans le message de demande d’intégration des correctifs.

SELinux

La mise en correspondance de zones mémoire proches de l’adresse 0 peut poser des problèmes de sécurité (cela simplifie principalement l’écriture d’exploitations de failles du noyau). Ainsi, une limitation arbitraire avait été ajoutée (vm.mmap_min_addr, configurable à l’aide de sysctl) pour réduire ce risque. Les processus souhaitant mettre en correspondance une zone mémoire inférieure à mmap_min_addr doivent disposer de la « capacité » (capability) CAP_SYS_RAWIO.

Pour le noyau 2.6.30, Eric Paris avait choisi de placer la vérification effectuée par SELinux (MAC) avant la vérification classique de « capacité » (DAC) [correctif]. Ce comportement était un cas exceptionnel, car les vérifications effectuées au niveau des appels système suivent toutes l’ordre DAC puis MAC (cf. un exemple complet pour le contrôle d’accès à un fichier).

Cette inversion a eu pour principale conséquence la mise en avant d’un cas d’erreur courant et géré sans aucun problème par les programmes (notamment Wine et QEMU) dans la majeure partie des cas. En effet, lorsque qu’un programme essayait d’effectuer un mmap() au‐dessous de mmap_min_addr, il se voyait refuser l’accès par SELinux en premier, ce qui générait un AVC qui était affiché à l’utilisateur (par setroobleshoot) avec un message du type :

SELinux is preventing /usr/bin/wine-preloader from 'mmap_zero' accesses on the memprotect.

L’utilisateur croyait alors à tort qu’il y avait un problème de sécurité. Si l’application échouait, ce n’était pas non plus nécessairement la faute de SELinux. Et, si c’était effectivement le cas, il fallait non seulement autoriser ce programme dans la politique SELinux, mais également lui donner la capacité CAP_SYS_RAWIO pour qu’il puisse fonctionner.

Ayant causé plus de soucis que de bénéfices potentiels (détection de programmes malveillants), cette inversion MAC/DAC a été corrigée (cf. l’article de Daniel Walsh sur le sujet) [correctif].

Un autre bogue a été corrigé : des nœuds d’index (inodes) dans /proc pouvaient être laissés avec une étiquette de sécurité (label) attribuée par défaut au lieu de celle indiquée dans la politique de sécurité. Cela se produisait si un programme y accédait avant que la politique ne soit chargée [correctif].

Systèmes de fichiers Code commun VFS

L’appel système renameat2 a été ajouté afin de permettre d’échanger les noms de deux fichiers de façon atomique. Avec cet appel système, il devient donc possible de remplacer un dossier par un lien symbolique sans risque qu’une opération arrive durant l’opération et ne réussisse pas ! Vous pouvez consulter l’article de LWN sur le sujet, ainsi que la page de manuel de l’appel système, afin d’obtenir plus d’informations.

Une autre modification importante est l’ajout de nouveaux verrous équivalents aux verrous POSIX, mais associés aux fichiers et non plus aux processus. La différence semble être peu importante, mais elle permet de rendre ces verrous utiles pour la synchronisation de plusieurs fils d’exécution à l’intérieur d’un même processus.

Avec les verrous POSIX classiques (qui n’ont pas été remplacés), si deux fils d’exécution (threads) d’un même processus ouvraient le même fichier, un verrou posé en écriture par un fil serait remplacé par un autre verrou en écriture posé par l’autre fil. De plus, si le fichier est ouvert plusieurs fois (utile pour paralléliser la lecture de données dans plusieurs fils) les verrous posés par un fil sur un fichier sont enlevés lorsqu’un autre fil ferme son descripteur de fichier. Il est très difficile de se prémunir contre ça sans rajouter beaucoup de verrous internes à l’application et s’assurer que les chemins des fichiers sont uniques (pas de lien dur ou symbolique).

Cependant, si les verrous sur un fichier ne sont plus associés à l’identifiant du processus (PID) mais sont associés aux descripteurs de fichier, le noyau ne fera plus de distinction entre deux tentatives de verrouillage venant de deux fils d’exécution d’un même processus ou de deux processus séparés ! Pour plus d’information, vous pouvez lire l’article dédié sur LWN.

SATA

La vitesse de sortie de veille a été augmentée en autorisant le contrôleur de disque SATA à se réinitialiser en tâche de fond pendant que le reste du noyau se réveille puis rend la main à l’espace utilisateur. Ce n’est pas un problème, car même si une application utilisateur ou le noyau essaient de relire un fichier pendant que le contrôleur SATA se réveille, le processus ou le module sera bloqué et la requête mise en file d’attente en attendant que le contrôleur ait fini son travail. Le résultat est un temps de réveil de 7 à 12 fois plus rapide sur les machines de son développeur et une faible complexité du code (1 et 2). Plus d’informations sont disponibles sur LWN.

Ext3/4

Le système de fichiers par défaut de nombreuses distributions se stabilise encore et toujours, mais peu de nouveautés à se mettre sous la dent.

XFS

Idem du côté de XFS, la période est relativement calme. À noter que le sous‐système XFS n’est plus maintenu par SGI mais désormais par Dave Chinner (Red Hat). Celui‐ci remercie au passage grandement SGI pour le boulot réalisé depuis les débuts de XFS. Les modifications les plus significatives concernent la gestion de O_TMPFILE, ainsi que l’option de l’appel système fallocate (COLLAPSE_RANGE et ZERO_RANGE).

Btrfs

Suite à l’embauche de Chris Mason chez Facebook, puis au déploiement sur une ferme de serveurs de test de Btrfs, ce système de fichiers a le vent en poupe. Btrfs se voit amélioré considérablement, avec une bonne salve de corrections et d’améliorations de performance qui ne semblent cependant pas visibles dans les tests de Phoronix.

Le temps semble être à la stabilisation de Btrfs.

F2FS

Ce système de fichiers qui s’entend bien avec les mémoires Flash (Flash‐Friendly File System) se voit doté d’une amélioration des performances sous certaines charges de serveur, ainsi que d’une gestion des dossiers de taille importante.

kernfs

Le pseudo‐système de fichiers kernfs a été tout juste introduit dans la version 3.14. Il reprend la logique de sysfs pour la rendre plus utile aux différents sous‐systèmes ayant besoin d’un système de fichiers virtuel. Il continue d’être amélioré, en particulier par Tejun Heo, auteur de la majorité des correctifs.

ZRAM

Ajout de la gestion de l’algorithme de compression LZ4 pour zram. zram est un système de d’échange de mémoire (swap) compressé tournant en mémoire vive, afin d’améliorer les performances des machines qui en manquent.

En vrac

Par manque de temps, tous les changements n’ont pu être résumés. Voici quelques informations complémentaires :

Virtualisation KVM

Les nouveautés tirées de la demande d'intégration :

  • pour les architectures ARM, il y a quelques corrections pour les caches ;
  • du côté du PowerPC, les invités peuvent profiter de la mémoire transactionnelle (disponible avec le POWER8) ;
  • MIPS profite de quelques corrections de bogue, mais d’autres devraient arriver avec la prochaine version, car QEMU va avoir droit à KVM avec MIPS ;
  • pour les x86 :
    • des optimisations dans les registres de débogage utilisés par certains jeux pour Windows,
    • de manière générale, les invités Windows profitent de plusieurs corrections de bogues,
    • pour tous les invités, les instructions des processeurs Intel Broadwell sont maintenant exposées, ainsi que les instructions MPX développées par Intel pour protéger les accès mémoire,
    • pour les invités OS X, il y a un contournement avec le minuteur de préemption pour la virtualisation imbriquée, et quelques modifications de l’horloge présentée par KVM ;
  • pour l’architecture s390 (les ordinateurs centraux d’IBM), les erreurs de page asynchrones sont implémentées, et des améliorations des interruptions font que les périphériques virtio sont plus rapides.
Xen

Aucune nouveauté du côté de Xen pour cette version.

Le bilan en chiffres

Une fois n’est pas coutume, LWN n’a pas encore publié son article sur les statistiques des contributions à cette nouvelle version de Linux.

Nous avons profité de ce délai de leur part pour améliorer la qualité de cette dépêche, mais nous ne pouvons pas la retarder infiniment. Nous rajouterons cette partie dans un commentaire quand l’article de LWN sera disponible.

Appel aux volontaires

Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :

Mainteneur Contributeur(s) La phase de test aucun Julien Pecqueur, Albert_ Architecture Romain Perier Sébastien Chauvel Pilotes graphiques libres Martin Peres Réseau Florent F. Systèmes de fichiers Jiehong Martin Peres Sécurité Timothée Ravier Virtualisation Xavier Claude Édition générale aucun Martin Peres, Davy Defaud, rogo

Un peu de vocabulaire :

  • Le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie. Il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer.
  • Un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche. Il n’y a aucune forme d’engagement pour le futur.

Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps. Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les correctifs intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Firefox 30 glorieuses

mer, 11/06/2014 - 23:27

Firefox 30 est sorti !

Après une version 29 riche en changements, la version 30 est plus calme pour la version bureau. La version mobile (Android) voit ses fonctionnalités d'accueil améliorées.

Bureau

Firefox pour GNU/Linux passe à GStreamer 1.0 ! Pour rappel, GSstreamer est une bibliothèque qui permet la lecture de musiques et de vidéos. GStreamer 1.0 est sorti fin 2012, mais la version précédente (0.10) continue encore d'être maintenue. Ce changement ne devrait pas impacter l'utilisateur final, bien que certaines améliorations de performances puissent êtres visibles. Et il est toujours rassurant de voir son navigateur se débarrasser d'une dépendance à une vieille bibliothèque.

Dans cette version, Firefox désactive le chargement automatique des greffons pour passer au click-to-play (à l'exception de ceux inscrits dans la Whitelist). Ceci devrait améliorer les performances et la stabilité du navigateur.

Parmi les autres changements notables, sur Mac OS X, le raccourci command-E lance une recherche sur le texte sélectionné. Sur toutes les plateformes, le bouton de la sidebar donne un meilleur accès au social, aux marque-pages et à l'historique.

Mobile

Sur mobile, ou plutôt sur Android, on a des changements peut-être un peu moins notables :

  • Ajout du bouton Quickshare au menu contextuel ;
  • langues ajoutées : Biélorusse [be], Argentin [es-AR], Mexicain [es-MX], Indonésien [id], Letton [lv], Malais [ms] ;
  • amélioration de la page d'accueil de l'application mobile, permettant ainsi de rajouter une page par défaut.
Coup d'œil technique

Les constructeurs WebIDL, un langage utilisé pour spécifier des interfaces (notamment utilisé pour définir celles du W3C), sont désactivés pour le web.

Coup d'œil de développeur web

En commun, sur bureau et mobile :

  • amélioration de box-shadow et d'autres problèmes graphiques (voir bug 480888) ;
  • Les contrôles "silence" et "volume" sont disponibles par onglet (quand WebAudio est utilisé) ;
  • background-blend-mode activé par défaut ;
  • utilisation de line-height permise pour <input type="reset|button|submit"> ;
  • les array et generator comprehensions de ES6 ont été implémentés (lire les docs pour plus de details) ;
  • la pile d'erreur contient maintenant le numéro de colonne où l'erreur a été générée, cela permet aux développeurs de retrouver plus facilement la fonction problématique ;
  • gestion de l'option alpha dans les options de contexte du canvas.

Spécifiquement sur le bureau :

  • à l’exception de ceux qui sont inclus dans une extension ou qui sont sur liste blanche, les greffons (plugins) ne seront plus activés par défaut (voir ce billet).
Coup d’œil sur la suite

L'implémentation du mode lecture pour la version bureau comme de la neutralisation de l'écran de veille pendant la lecture de vidéo semblent en bonne voie.

Coup d’œil sur le côté

Opera va intégrer PDF.js, le lecteur de PDF que Mozilla a développé en JavaScript/HTML5 pour Firefox.

Quelques statistiques
  • 493 développeurs ont contribué à cette version, 62 d'entre eux sont de nouveaux contributeurs ;
  • 6339 modifications ont été acceptées pour cette version, 1 558 800 lignes ont été ajoutées et 1 178 208 supprimées (soit un delta de 380 592) ;
Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Red Hat Enterprise Linux 7

mer, 11/06/2014 - 11:48

C'est après une version bêta et une release candidate que Red Hat a annoncé ce 10 juin la disponibilité publique de Red Hat Enterprise Linux (RHEL) 7, distribution commerciale destinée aux professionnels et aux entreprises. Il s'agit d'une version majeure, apportant un lot conséquent de nouveautés. Red Hat Enterprise Linux 7 est disponible pour les architectures AMD64/Intel64 et IBM (POWER7, POWER8 et System Z). Les versions bêta et Release Candidate ont été rendues publiques les 11 décembre et 15 avril derniers. Le nom de code de cette version est Maipo.

Sommaire Versions logicielles

Dans les grandes lignes, RHEL 7 c'est :

  • noyau Linux 3.10 ;
  • Glibc 2.17 ;
  • GNOME 3.8 ;
  • KDE 4.10 ;
  • Python 2.7.5 ;
  • Firefox 24.4 ;
  • LibreOffice 4.1 ;
  • Bash 4.2 ;
  • OpenSSH 6.4p1 ;
  • Apache HTTPD 2.4.6 ;
  • PHP 5.4.16 ;
  • Bind 9.9 ;
  • DHCP 4.2 ;
  • PostgreSQL 9.2 ;
  • Postfix 2.10 ;
  • Sendmail 8.14.7 ;
  • MariaDB 5.5.35 ;
  • Perl 5.16.3 ;
  • GCC 4.8.2 ;
  • GDB 7.6.1 ;
  • SystemTap 2.4 ;
  • Samba 4.1.1 ;
  • Systemd 208 ;
  • Xorg-server 1.15.0.

Globalement, en terme de versions logicielles, RHEL 7 se rapproche de Fedora 19.

Nouveautés importantes
  • MariaDB remplace MySQL ;
  • Systemd remplace Upstart comme système d'init ;
  • inclusion de Docker et de LXC, montrant l'ambition de Red Hat à faire de RHEL la plateforme cloud de référence ;
  • XFS comme système de fichiers par défaut, en remplacement d'Ext4.

Cette dépêche est fortement inspirée de la technical overview officielle et des notes de version.

Systemd

Systemd est utilisé comme init (système d'initialisation, démarrage) par défaut. Il s'occupe donc de gérer les services, le système (watchdogs, ACPI…) et aussi partiellement les machines virtuelles et les conteneurs (en coopération avec libvirtd). En effet, la version présente est la 208, qui inclut notamment les changements introduits dans la version 205 : la "prise de possession de l'arbre des cgroups". Systemd est le seul responsable de l'arborescence des cgroups et se charge donc d'y placer tous les processus. Cette nouvelle interface est décrite sur le wiki de systemd. La différence ici sera donc marquée même par rapport à un système avec un systemd ancien (Debian par exemple) : le cas pour libvirt.

Installation

C'est sans doute la première chose qui va sauter aux yeux lorsque vous installerez RHEL 7 : Anaconda. Si vous n'avez pas utilisé une Fedora depuis la version 18, la surprise sera totale et vous aurez du mal à reconnaître l'interface d'installation, dont les menus sont accessibles en deux étapes principales. Parmi les nouveautés d'Anaconda, on trouvera :

  • une meilleure internationalisation ;
  • une gestion de cette internationalisation en fonction de la géolocalisation : la langue et l'heure de la machine peuvent être automatiquement définies grâce à cette donnée ;
  • la possibilité de configurer un système de fichier tmpfs ;
  • une configuration réseau plus complète, avec par exemple l’agrégation de cartes réseau.

Autre nouveauté non négligeable, la mise à jour : il devient possible de mettre à jour une RHEL 6.5 (ou ultérieure dans la branche 6) vers RHEL 7 ! C'est une avancée majeure pour Red Hat, qui prend en charge officiellement cette possibilité.

Une autre chose importante à noter : l'installeur n'est plus accessible pour les machines x86 à processeur 32 bits. Si pour certains cela peut être décevant, il convient de rappeler que depuis plusieurs années, les principaux fabricants de serveurs x86 ne proposent que des machines x86_64, les seules machines 32 bits récentes étant dotées de processeurs de faible puissance et de faible consommation (comme par exemple la gamme Soekris net6501), qui ne sont clairement pas la cible commerciale de Red Hat. Malgré tout, de nombreux paquets compilés pour i686 sont disponibles, ce qui laisse encore du temps si vous avez des développements spécifiques à cette architecture.

Matériel Pilotes et périphériques

Le retrait de l'architecture 32 bits x86 des plateformes prises en charge permet à Red Hat de faire le ménage. Un certain nombre de pilotes et de modules quittent RHEL, dont par exemple b43-fwcutter, b43-openfwwf, forcedeth, ipw2100, ipw2200 et via-rhine. La liste complète des modules non reconduits dans RHEL 7 est disponible dans la section 4.4.1 du guide de migration.

Préconisations matérielles

Pour faire fonctionner RHEL 7, Red Hat recommande de disposer d'au moins 1 Go de mémoire vive (c'était déjà le cas avec RHEL 6). Dans les faits, il est possible de démarrer avec seulement 256 Mo de mémoire vive, mais il vaudra mieux en avoir 512 Mo pour ouvrir une session graphique (et il ne faudra pas être pressé). Du côté de l'installeur, celui-ci refusera de démarrer en dessous de 512 Mo de mémoire.

Pour ce qui est de la limite haute, Red Hat a augmenté le nombre de processeurs logiques que peut utiliser RHEL. Là où RHEL 6 en est actuellement à 4096 coeurs (en x86_64), la 7 monte jusqu'à 5120 ! Pour la mémoire vive, le maximum annoncé est de 64 To.

Gestion des performances Performance Co-Pilot

Performance Co-Pilot est un outil de mesure, de surveillance et d'analyse des performances d'un système qui s'intègre avec les outils classiques (syslog…). Des détails sont disponibles aux liens suivants :

Tuned et profils Tuned

Tuned est un démon qui change la configuration du système (principalement le noyau) pour s'adapter à l'utilisation du système. Il permet de facilement configurer un système pour l'orienter performance ou économie d'énergie. Des profils par défaut sont fournis pour chaque variante de RHEL.

Affinité NUMA

La version du noyau incluse dans RHEL 7 améliore les performances pour les systèmes de type NUMA. Sur ces systèmes, les temps d'accès à la mémoire ne sont pas uniformes et dépendent de la proximité physique des barrettes de RAM. Il faut donc gérer la répartition de la mémoire judicieusement en fonction des cœurs sur lesquels les processus s'exécutent. C'est le noyau qui est chargé de cette optimisation pour réduire les communications inter-nœuds.

Mécanisme de remontée des événements matériels (HERM)

Diverses améliorations dans le noyau et un démon en espace utilisateur (rasdaemon) permettent d'obtenir des informations plus cohérentes sur les rapports d'événement matériel.

Stockage et systèmes de fichiers XFS

Le système de fichiers utilisé par défaut lors de l'installation est maintenant XFS, qui succède à Ext4. Btrfs est disponible lors de l'installation, mais n'est pas recommandé par défaut (aperçu technologique, non pris en charge pour la production).
Tant XFS que BtrFS (quand il sera pleinement pris en charge) voient leur capacités prises en charge poussée à 500 Tio par système de fichier.

/tmp en tmpfs par défaut

Avec systemd vient le passage du répertoire /tmp au système de fichiers intégralement en mémoire tmpfs par défaut. Cela ne semble affecter que les machines physiques (les machines virtuelles ont un /tmp sur disque par défaut apparemment puisqu'il semble que systemd détecte qu'il n'est pas sur une machine physique). Cette fonction peut se désactiver très facilement (appliqué au prochain redémarrage) :

$ systemctl mask tmp.mount

Ext4

Le système de fichiers Ext4 prend désormais en charge des fichiers de 50 Tio contre 16 Tio auparavant.

Cache de périphérique blocs sur disque SSD

Un autre aperçu technologique de RHEL 7 est la possibilité d'utiliser un disque SSD PCIe comme cache intermédiaire pour des disques rotationnels plus lents, via lvm(8).

Virtualisation Conteneurs Linux (LXC) et Docker

Les conteneurs permettent d'isoler des processus ou des environnements plus facilement et de façon moins lourde que les machines virtuelles sur un système. Ils sont particulièrement utiles lorsque l'on veut lancer plusieurs instances d'une application et qu'elles partagent des ressources (les binaires, les bibliothèques…). Les conteneurs sur RHEL 7 utiliseront quatre technologies introduites en partie dans les noyaux récents :

  • les espaces de noms (namespace), qui sont de plusieurs types, et permettent principalement de mieux isoler les processus entre eux ;
  • les Cgroups, qui facilitent la gestion dynamique et contrôlent l'accès aux ressources ;
  • SELinux, chargé de la sécurité, de l'isolation et du contrôle d'accès pour les conteneurs ; il faut noter que le contrôle d'accès SELinux vise principalement à isoler les conteneurs entre eux et vis-à-vis du système, sans ajout de contrôle supplémentaire à l'intérieur du conteneur, lequel ayant d'ailleurs l'impression que SELinux est désactivé ;
  • libvirt, qui permet d'administrer les conteneurs.

Pour pouvoir dupliquer rapidement des conteneurs, Docker utilisait le système de fichiers AUFS qui permet de faire des copies liées de systèmes de fichiers de façon très peu coûteuse en temps. Malheureusement, le système de fichiers AUFS n'est inclus ni dans le noyau upstream ni dans les noyaux des distributions autres qu'Ubuntu. Depuis la version 0.7, Docker peut utiliser d'autres méthodes de stockage (fichiers et dossier simples ou Device Mapper et LVM). C'était la raison principale qui retardait l'apparition de Docker dans RHEL, Fedora et les autres distributions. Attention cependant, Docker n'est pas disponible dans l'image ISO de base ou dans le canal de base, il faudra activer les dépôts "extras" et "optional", comme indiqué dans la documentation.

VMware

La machine virtuelle RHEL 7 dispose d'une meilleure intégration avec l'hyperviseur VMware vSphere, grâce notamment à l'ajout des Open VM Tools, fruit de l'ouverture partielle du code source des VMware Tools. La société VMware garde cependant certaines parties de ces outils en licence propriétaire. À noter aussi la prise en charge de l'accélération 3D matérielle dans les machines virtuelles (rendu OpenGL et X11), ainsi qu'un mécanisme de communication plus rapide entre celles-ci et le système hôte VMware ESX. Ces ajouts permettent l'exécution encore plus performante d'une machine virtuelle Red Hat Enterprise Linux fonctionnant sous VMware. Pour plus d'informations, VMware dispose d'une page dédiée à RHEL 7 sur son site.

Xen

Sans plus de détails, Red Hat indique que RHEL 7 fonctionne en tant que domU HVM sous Xen.

Hyper-V

RHEL 7 est utilisable comme machine virtuelle de génération 2 avec un hôte Microsoft Hyper-V Server 2012 R2. Cette deuxième génération permet entre autres d'avoir accès à Secure Boot, un UEFI ou de démarrer depuis un disque virtuel SCSI.

KVM

La solution privilégiée par Red Hat pour la virtualisation n'est pas en reste avec cette nouvelle version majeure de RHEL : il est possible de migrer une machine virtuelle d'un hyperviseur RHEL 6.5 vers un hypverviseur RHEL 7.0 en direct, sans arrêt. De plus, un nouveau périphérique, virtio-rng, pourra être accessible aux machines virtuelles pour qu'elles disposent de plus d'entropie, en provenance de l'hôte. Par défaut, l'hôte utilisera /dev/random, mais un générateur matériel de nombres aléatoires pourra être utilisé.

Côté invités, Red Hat annonce la possibilité d'utiliser les derniers systèmes de Microsoft, Windows 8 et Windows Server 2012.

Haute-disponibilité et grappes de calcul

Dans ce domaine, le changement est flagrant : au revoir rgmanager, bonjour Pacemaker ! Du coup, le système de configuration, nommé pcs, remplace ccs, ricci et luci. Pacemaker apporte beaucoup, comme une synchronisation automatique de la configuration des ressources, des options de configuration de ressources basées sur l'heure, le fait d'avoir un outil de configuration en ligne de commande. Cela se fait malheureusement au prix de l’interopérabilité entre des nœuds RHEL 6 et 7 dans un cluster. Il sera sans doute préférable de créer un nouveau cluster RHEL 7 plutôt que de migrer progressivement un cluster existant sous RHEL 6.

Réseau

Dans les précédentes RHEL, pour agréger plusieurs cartes réseau, on utilisait le bonding. Red Hat a inclus dans RHEL 7 le teaming et recommande son utilisation. Si vous avez haï NetworkManager dans RHEL 6 au point de le désactiver dès que possible, du fait de son inadéquation à l'utilisation sur un serveur, sachez que vous avez peut-être été entendu. Non, NetworkManager n'a pas été sorti de RHEL, mais il a été amélioré sur ce point et vous disposez maintenant d'un outil nommé nmcli. Comme NetworkManager ne passe plus son temps à surveiller des modifications dans la configuration réseau, vous pouvez éditer celle-ci manuellement (ou déployer un nouveau fichier avec par exemple Puppet, Salt, Chef ou Satellite) et faire prendre en compte les modifications avec la commande nmcli connection reload.

Une autre nouveauté qui risque de surprendre se situe dans le pare-feu de RHEL, avec l'inclusion du pare-feu dynamique : firewalld. Celui-ci se base sur le concept de zones pour associer un niveau de confiance à un réseau. Son comportement peut s'adapter avec une configuration permanente et une temporaire. Il prend bien entendu en charge IPv4, IPv6, mais aussi les ponts Ethernet !

Développement

La nouvelle version de GCC (4.8) présente dans RHEL 7 ainsi que la nouvelle glibc permettent maintenant d'utiliser C++11, OpenMP v3.1, de nouvelles fonctionnalités pour Fortran et apportent de meilleurs avertissements et diagnostics. Bien entendu, une version plus récente de GDB accompagne tout cela, mais dispose en plus d'un nouveau paquet : gdb-doc. Comme son nom l'indique, il s'agit de la documentation, disponible dans les formats info, HTML et PDF.

Java est aussi de la partie, avec OpenJDK7 comme environnement par défaut. Vous pouvez toutefois installer les machines virtuelles d'IBM et d'Oracle en parallèle, comme pour les différentes versions du noyau Linux.

Dans les autres environnements notables, Python est maintenant disponible en version 2.7.5 (une version 3 sera accessible via les Software Collections) et Ruby arrive en version 2.0.0.

Authentification Relations d'approbations entre domaines Identity Management et Active Directory

Un utilisateur possédant un compte sur un domaine Active Directory (Microsoft AD) pourra accéder aux ressources mises à disposition sur des serveurs RHEL sans avoir à effectuer une nouvelle authentification. Cela généralise le "single sign on" même s'il existe deux royaumes distincts pour Windows et Linux. C'est le serveur Red Hat Identity Management (projet FreeIPA, à base de Kerberos & LDAP) sous Linux qui établira une relation d'approbation avec le domaine AD. Il n'est pas nécessaire de synchroniser les bases d'utilisateurs.

Realmd

Pour faciliter la configuration pour le point précédent, le démon realmd se chargera de la découverte des royaumes Kerberos Linux et des domaines AD.

Sécurité

Les grands changements sont résumés dans la présentation de Dan Walsh au Red Hat Summit de cette année.

OpenSSH

La principale nouveauté vient avec la nouvelle version d'OpenSSH, qui apporte l'option ChrootDirectory. Cette option permet d'emprisonner l'utilisateur au niveau d'OpenSSH en plus de la possibilité déjà existante au niveau de SELinux.

Autre nouveauté en provenance d'OpenSSH, l'authentification multiple obligatoire. Il est déjà possible d'utiliser une authentification à deux facteurs, mais on peut augmenter la sécurité de son système en imposant celle-ci : cette possibilité se paramètre au niveau de l'option AuthenticationMethods.

Fonctionnalités liées à systemd journald

RHEL 7 utilise toujours un démon de type syslog par défaut pour stocker les logs du système dans divers fichiers. En revanche, les logs sont d'abord collectés par journald qui les retransmet ensuite au démon syslog.

Il était auparavant difficile de vérifier qu'un message de log avait bien été émis par le démon indiqué dans les logs car syslog ne gardait que très peu d'informations liées à l'identité du processus émetteur de logs. Par exemple, si le démon ntpd venait à être compromis par un attaquant, celui-ci pouvait émettre des logs ressemblant à ceux produit par sshd et ainsi influencer le comportements d'outils tels que fail2ban se basant sur les logs de sshd.

Ce comportement est toujours possible, mais il est désormais très facile de le détecter car journald conserve des informations supplémentaires :

... SYSLOG_IDENTIFIER=sshd SYSLOG_PID=2302 MESSAGE=Faux message provenant de sshd... _PID=2302 _UID=0 _GID=0 _COMM=ntpd _EXE=/usr/sbin/ntpd _CMDLINE=/usr/sbin/ntpd -n -u ntp:ntp -g _SYSTEMD_CGROUP=/system/ntpd.service _SYSTEMD_UNIT=ntpd.service _SELINUX_CONTEXT=system_u:system_r:ntpd_t:s0 _SOURCE_REALTIME_TIMESTAMP=1330527027590337 _BOOT_ID=4c3d0faf6b774fb7930972c1a4a5f870 _MACHINE_ID=432d8198a8fc421caf2dca48ccde1cf2\ _HOSTNAME=www.example.com ...

Plus de détails sur le blog de Red Hat lié à la sécurité.

Démarrage des démons avec systemd

L'ensemble des démons est maintenant démarré et géré par systemd. Les administrateurs ne doivent ainsi plus se charger de redémarrer les démons directement, c'est systemd qui s'en charge. Il peut ainsi :

  • s'assurer que l'environnement est bien contrôlé (entre autres que les variables d'environnement n'ont pas été modifiées) ;
  • s'assurer que le démon a accès au dossier courant lors de son exécution ;
  • rediriger les entrées/sorties du terminal vers journald, par exemple pour récupérer tous les logs d'erreurs qui auraient été perdus autrement ;
  • ouvrir des sockets auxquelles le démon n'aura pas nécessairement accès, si il est exécuté avec moins de privilèges ;
  • changer la gestion des signaux par défaut ;

Enfin, cela simplifie les règles de changement de contexte SELinux et améliore ainsi la sécurité.

Plus de détails sur le blog de Red Hat lié à la sécurité.

Répertoire /tmp privé

Le répertoire /tmp était couramment utilisé par les démons d'un système pour stocker des fichiers temporaires, sockets ou des FIFO. Or ce dossier est accessible à tous les utilisateurs ce qui a causé de nombreux problèmes de sécurité (par exemple CVE-2011-2722) lorsque la manipulation des fichiers n'était pas faite de façon très précautionneuse par rapport à la sécurité.

La plupart des démons utilisent maintenant des sous-dossiers de /run avec des permissions restreintes pour stocker leurs données temporaires. Mais certains projets sont récalcitrants et certains programmes ne peuvent aussi pas être changés (logiciels propriétaires, notamment). Pour ceux-ci, l'option PrivateTmp des fichiers d'unit systemd permet de créer un dossier à accès restreint, dont l'usage sera transparent pour l'application.

Ainsi, avant de démarrer un service, systemd :

  • crée un dossier tmp avec un nom imprédictible en utilisant la fonction mkdtemp ;
  • crée un nouvel espace de nom de système de fichiers (file system namespace) pour que les changements n'impactent pas tout le système, mais uniquement le démon et ses fils ;
  • monte avec l'option bind le dossier créé par-dessus le dossier /tmp ;
  • démarre le service.

Plus de détails sur le blog de Red Hat lié à la sécurité.

SELinux Association de label SELinux automatique en fonction du nom de fichier

Le contrôle d'accès effectué par SELinux est basé sur des labels que l'on va attacher aux divers éléments d'un système (fichiers, sockets, processus…). Pour qu'un système fonctionne correctement, il faut que ces labels correspondent aux règles définies dans la politique SELinux. Un problème fréquent se produisait lorsqu'un administrateur ou un utilisateur créait des dossiers ou fichiers et que les labels utilisés par défaut ne correspondaient pas à ce qui était attendu dans la politique SELinux.

Les deux exemples récurrents sont :

  • la création du dossier .ssh dans le répertoire /root : le dossier recevait alors le label admin_home_t par défaut alors que la politique est conçue pour que ce dossier soit labellisé ssh_home_t, Le démon sshd (utilisant le label sshd_t) ne pouvait alors pas accéder au contenu de /root/.ssh et refusait les connexions à l'aide de clé publique par exemple ;
  • la création du dossier public_html dans le répertoire personnel d'un utilisateur : le dossier recevait alors le label user_home_t mais la politique par défaut utilise le label http_user_content_t, L'accès à ces dossiers était donc refusé à Apache (avec le label httpd_t).

Dans les deux cas, l'utilisateur devait corriger manuellement le label de ces dossiers et fichiers avec la commande :

$ restorecon -Rv /home/user/public_html

Une première amélioration avait été apportée par l'ajout dans la politique de règles de changement automatique de labels pour les fichiers (file transition rule). Ces règles permettaient d'indiquer par exemple que les fichiers créés par les processus labellisés NetworkManager_t dans le dossier labellisé etc_t (/etc) seraient automatiquement de type net_conf_t. Exemple :

filetrans_pattern(NetworkManager_t, etc_t, file, net_conf_t)

Cette règle n'est cependant pas optimale car elle autorise NetworkManager à créer n'importe quel fichier qui n'existerai pas déjà dans un dossier labellisé etc_t (/etc/) et à lui donner le contexte net_conf_t. Elle ne permets pas non plus de contrôler le label du dossier .ssh lors de sa création par un utilisateur. Une règle du type :

filetrans_pattern(unconfined_t, user_home_t, file, ssh_home_t)

forcerait tous les fichiers du répertoire d'un utilisateur a être labellisé ssh_home_t, ce qui n'est pas vraiment le but recherché.

Eric Paris a ainsi travaillé sur la gestion (dans la politique et dans le noyau) d'un quatrième argument pour cette règle : le nom du fichier créé (sans le chemin d'accès). Cette règle permet d'exprimer ainsi facilement les deux cas de figure cités au-dessus :

  • si un processus unconfined_t crée un dossier .ssh dans un dossier admin_home_t, alors il sera créé avec le label ssh_home_t :
filetrans_pattern(unconfined_t, admin_home_t, directory, ssh_home_t)
  • si un administrateur (staff_t) crée un dossier public_html dans un dossier labellisé user_home_t, il sera labellisé http_user_content_t :
filetrans_pattern(staff_t, user_home_t, directory, http_user_content_t)

D'autres règles ont aussi été ajoutées pour s'assurer que les fichiers créés dans /dev soient automatiquement labellisés avec les bons contextes sans avoir à attendre qu'udev fixe le contexte.

Cette règle permet aussi de restreindre NetworkManager à la création du seul fichier resolv.conf dans un dossier etc_t.

Plus de détails sur le blog de Red Hat lié à la sécurité.

Aide à la rédaction de politiques

Un nouveau document d'introduction à l'écriture de politiques SELinux a été rédigé entre autres par Dan Walsh. Il est disponible à cette adresse sur le blog orienté développeur Red Hat de Dan Walsh.

Il détaille le processus de création de politique en utilisant les outils sepolicy generate et audit2allow. L'outil sepolicy generate :

  • génère la base d'une politique à partir des réponses à des questions de type « Mon programme est-il un démon ? » ;
  • prépare un fichier .spec pour construire un paquet RPM pour distribuer facilement la politique sur un ensemble de machines ;
  • crée une page de man expliquant la politique venant d'être écrite.
Chiffrement

Les récentes versions de RHEL 6 avaient apporté la prise en charge des courbes elliptiques dans le chiffrement pour un certain nombre de paquets. Dans RHEL 7, nss a été mis à jour et apporte de nouvelles suites de chiffrement et fait disparaître MD2, MD4 et MD5 dans le cas des CRL.

Durée de vie

Enfin, et pour conclure sur cette nouvelle version, il convient de rappeler que RHEL 7 disposera d'une durée de vie de 10 ans (13 avec le support étendu, tout comme RHEL 5 et 6).

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Recrutement Licence Pro CoLibre : devenir un(e) professionnel(le) de la com rien qu'avec du libre

mer, 11/06/2014 - 08:07

Les dépôts de candidature pour la licence pro "CoLibre" promo 2014-2015 se clôturent le 20 juin.

CoLibre est une licence professionnelle "Activités et techniques de communication" proposée par l’Université Lumière Lyon2. Elle est ouverte aux titulaires d'un diplôme bac+2 (ou aux personnes ayant un parcours professionnel de plusieurs années pouvant ouvrir à une validation d'acquis pour suivre la formation). Cette formation n'est pas limitée aux personnes ayant un parcours en communication ou en informatique. La formation recrute dans toutes les disciplines et diplômes.

Cette licence prépare aux métiers de la communication impliquant une connaissance des outils de création numérique, de communication électronique et une maîtrise des techniques et concepts (chargé de communication, chef de projet, web rédacteur, web développeur, community manager, concepteur audio-visuel, infographiste…).

Au cours de l'année, les étudiants découvriront les logiciels libres qui leur permettront de réaliser l'ensemble de leurs tâches y compris (voir surtout) dans un environnement gnu/linux.

Ils auront en plus des cours de pratiques logicielles, des cours de communication des organisations, communication interpersonnelle, droit, économie, veille…

En outre, les étudiants effectuent un stage professionnalisant de 16 semaines au sein d'une entreprise, d'une organisation humanitaire ou une collectivité.

Pour les personnes qui ne rentreraient pas dans ce dispositif mais souhaiteraient suivre une partie des enseignements sur mesure : contactez le responsable de la formation.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Les RMLL à Montpellier

mar, 10/06/2014 - 22:25

Vous rêviez d'une rencontre internationale de geeks autour d'une bonne bière pour parler code et logiciel ?

Et bien les Rencontres Mondiales du Logiciel Libre c'est un peu cela, mais c'est surtout plus de 300 conférences et ateliers autour de la thématique du logiciel libre. Que vous soyez professionnel ou simple curieux, nous serons ravis de vous accueillir du 5 au 11 juillet dans notre belle ville de Montpellier.

Cette 15e édition s'annonce sous les meilleurs auspices avec deux jours grand public sur l'Esplanade Charles De Gaulle, en plein centre de Montpellier, puis cinq jours sur le campus Triolet de l'Université Montpellier 2.

Entre deux baignades… heu conférences… vous pourrez vous désaltérer grâce à notre bière du libre, discuter avec les membres du village associatif, assister aux concerts prévus en soirée et partager avec nous le fameux repas du libre le jeudi soir. De plus des chambres sont encore disponibles au tarif de 21€ par nuit, dépêchez-vous de réserver sur notre site de réservation !

Et bien entendu, comme l'entrée est libre et gratuite, vous pourrez faire le plein de formations sur tous les sujets qui vous intéressent, du graphisme à la sécurité, en passant par la musique, vous pouvez consulter notre programme.

Ok, pour le moment tout cela est trop parfait, vous cherchez le piège : il n'y en a pas. Mais pour que tout cela soit possible il ne faut pas oublier le travail de notre sympathique équipe de bénévoles ! Vous pouvez d'ailleurs nous rejoindre si vous voulez voir l'envers du décor, nous vous accueillerons avec plaisir.

Et si vous êtes loin, n'avez pas de temps ou autres, nous acceptons bien évidement vos dons dans notre boutique, où est d'ailleurs disponible en exclusivité notre tee-shirt officiel. Vous pouvez aussi faire les deux, oui on sait, on rêve un peu mais après tout pour quoi pas !

À tout bientôt et n'oubliez pas de nous suivre sur Twitter @RMLL2014 et de visiter régulièrement notre site pour être toujours au courant des dernières nouveautés !

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Meilleurs contributeurs LinuxFr.org : les gagnants de mai 2014

mar, 10/06/2014 - 12:14

On continue sur notre lancée de récompenser ceux qui chaque mois contribuent positivement au site LinuxFr.org (dépêches, commentaires, logo, journaux, patchs, etc.). Vous n'êtes pas sans risquer de gagner un abonnement à GNU/Linux Magazine France ou encore un livre des éditions Eyrolles ou ENI. Voici les gagnants du mois de mai 2014 :

Abonnement d'un an à Linux Magazine France

Livres des éditions Eyrolles et ENI

Les livres qu'ils ont sélectionnés sont en seconde partie de la dépêche.

Certains gagnants n'ont pas pu être joints ou n'ont pas répondu. N'oubliez pas de mettre une adresse de courriel valable dans votre compte ou lors de la proposition d'une dépêche. En effet, c'est notre seul moyen de vous contacter, que ce soit pour les lots ou des questions sur votre dépêche lors de sa modération. Tous nos remerciements aux contributeurs du site ainsi qu'à GNU/Linux Magazine France, aux éditions Eyrolles et ENI.

N'oubliez pas de contribuer, LinuxFr.org vit pour vous et par vous !

Les livres sélectionnés par les gagnants :

                        Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Revue de presse de l'April pour la semaine 23 de l'année 2014

mar, 10/06/2014 - 07:48

La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

Sommaire

[Numerama] Une campagne pour "réinitialiser le net"

Par Julien L., le jeudi 5 juin 2014. Extrait:

Un an après les premières publications dans la presse relatives aux activités de la NSA, une opération a été lancée aux États-Unis. Celle-ci appelle à "réinitialiser le net" en invitant les internautes à ne plus demander leur droit à la vie privée, mais à le reprendre directement.

Lien vers l'article original: http://www.numerama.com/magazine/29592-une-campagne-pour-reinitialiser-le-net.html

Et aussi:

Voir aussi:

[Le Monde.fr] L'étrange disparition du logiciel de chiffrement TrueCrypt

Par Yves Eudes, le mercredi 4 juin 2014. Extrait:

Ce logiciel, recommandé par des ONG et utilisé par Edward Snowden et des journalistes ou militants anti-censure, a subitement été retiré du Web par ses créateurs. Sans explications.

Lien vers l'article original: http://www.lemonde.fr/pixels/article/2014/06/04/l-etrange-disparition-du-logiciel-truecrypt_4431134_4408996.html

Et aussi:

[Next INpact] Hadopi-CSA: le report à 2015 du projet de loi Création se précise

Par Xavier Berne, le mercredi 4 juin 2014. Extrait:

Le projet de loi «Création», préparé par Aurélie Filippetti afin notamment de transférer les compétences de la Hadopi au CSA, est décidément en bien mauvaise posture. Le texte, qui a notamment souffert du dernier remaniement ministériel et de la pause des municipales, pourrait en effet n’être discuté devant le Parlement que l’année prochaine. Et encore, s’il arrive à sortir de derrière les murs de la Rue de Valois…

Lien vers l'article original: http://www.nextinpact.com/news/87929-hadopi-csa-report-a-2015-projet-loi-creation-se-precise.htm

[Blogs LeMonde.fr] L’Assemblée se dote d’une commission sur le numérique

Par Hélène Bekmezian, le mercredi 4 juin 2014. Extrait:

Droit à l'oubli, cybercriminalité, économie numérique, ouverture des données publiques… Progressivement, de façon disparate mais certaine, Internet s'installe dans la législation et, récemment, le sujet a été abordé dans des textes aussi divers que la loi de programmation militaire, la proposition de loi de lutte contre la prostitution ou encore le projet de loi sur la géolocalisation.

Lien vers l'article original: http://parlement.blog.lemonde.fr/2014/06/04/lassemblee-se-dote-dune-commission-sur-le-numerique

Et aussi:

[Direction Informatique] Comment choisir une société de services en logiciel libre?

Par Laurent Bounin, le mercredi 4 juin 2014. Extrait:

Alors que mon billet précédent présentait plusieurs critères pour vous aider dans la sélection d’un logiciel libre, voici certaines pistes de réflexion en ce qui a trait au choix de la société qui vous accompagnera tout au long de votre projet.

Lien vers l'article original: http://www.directioninformatique.com/blogue/comment-choisir-une-societe-de-services-en-logiciel-libre/27767

[Medium] Plus rien ne marche, qu'est-ce qu'on fait?

Par Quinn Norton (traduction Framalang), le lundi 2 juin 2014. Extrait:

Un beau jour un de mes amis a pris par hasard le contrôle de plusieurs milliers d’ordinateurs. Il avait trouvé une faille dans un bout de code et s’était mis à jouer avec. Ce faisant, il a trouvé comment obtenir les droits d’administration sur un réseau. Il a écrit un script, et l’a fait tourner pour voir ce que ça donnerait. Il est allé se coucher et il a dormi environ quatre heures. Le matin suivant, en allant au boulot, il a jeté un coup d’œil et s’est aperçu qu’il contrôlait désormais près de 50 000 ordinateurs.

Lien vers l'article original: http://www.framablog.org/index.php/post/plus-rien-ne-marche-que-faire

Et aussi:

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

REUNIC 2014 à Marseille - l’OpenData avec mon public, j’en fais quoi ?

lun, 09/06/2014 - 17:53

RevCamp sur le thème Révolutions Numériques - R[é]volutions Citoyennes avec Jean-Christophe Becquet, directeur d’APITUX : L’OpenData avec mon public, j’en fais quoi ? vendredi 13 juin 2014 de 11h15 à 12h45, La friche Belle de mai 41 rue Jobin à Marseille.

Cet atelier d'échange sur les usages du numérique et leur futur s'inscrit dans le cadre des Rencontres des Usages Numériques de l'Internet Citoyen (REUNIC 2014) organisées par l'association Arsenic Paca à La Friche de la Belle de Mai, située au 41 rue Jobin à Marseille.

« L’OpenData doit changer le monde. C’est du moins ce qui nous est dit depuis quelques années maintenant. Mais concrètement, avec mon public sénior, mes demandeurs d’emploi ou dans mon atelier ado, comment j’intègre l’OpenData ? Des pistes, des idées, des exemples lors de ce RevCamp. »

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Nouveau livre sur Inkscape

lun, 09/06/2014 - 15:07

FlossManuals Francophone vient de mettre à disposition un nouveau livre sur Inkscape. D'une centaine de pages, il décrit les fonctionnalités principales dans le but d'aider les personnes à mieux rentrer dans l'outil et d'aider à la prise en main. Il est destiné à y remplacer un manuel plus ancien qui était à l'époque le manuel officiel d'Inkscape, mais qui a été peu mis à jour en français depuis.

Ce nouvel ouvrage a été rendu possible grâce au travail d'Elisa de Castro Guerra qui a déjà deux livres sur Inkscape à son actif. Après la disparition progressive des livres chez les éditeurs classiques, cela va peut-être relancer ce logiciel dont une nouvelle sortie est prévue prochainement.

En tout cas, Flossmanuals francophone dispose maintenant d'une série complète dédiée au graphisme et à l'impression incluant :

Ils peuvent être complétés par quelques autres comme celui sur Darktable, par exemple. On me dit dans l'oreillette qu'il y a pas mal de choses en préparation sur Blender pour faire suite au manuel sur Blender et l'impression 3D. Rappelons que les livres sont libres et qu'il suffit d'un compte utilisateur pour les éditer, corriger les coquilles ou contribuer au contenu.

Bonne lecture.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Joignez-vous à nous pour la HackFest 2014 de Tails ! 5 et 6 juillet 2014 -- Paris, France

lun, 09/06/2014 - 06:54

Joignez-vous à nous pour la HackFest 2014 de Tails les 5 et 6 juillet 2014 à Paris !

Description et objectifs

Rejoignez-nous pour rendre accessible à quiconque l'anonymat en ligne et la confidentialité dans le monde numérique. Que votre spécialité soit la documentation technique, le développement logiciel, le design, l'administration système… ou si vous êtes tout simplement intéressés : venez en apprendre plus sur les challenges auxquels Tails fait face, et comment vous pouvez faire partie de la solution.

La HackFest Tails rassemblera quiconque s'intéresse à rendre Tails plus utilisable et plus sûr. Cet événement ouvert sera un joyeux mélange d'apprentissage, de dessin, de programmation, de partage et de fête.

Logistique Qu'est-ce que Tails ?

Tails est un système d'exploitation live, qui peut être démarré, sur quasiment n'importe quel ordinateur, depuis un DVD, une clé USB, ou une carte SD. C'est un Logiciel Libre, basé sur Debian GNU/Linux.

Son but est de préserver la vie privée et l'anonymat. Il aide à :

  • utiliser Internet de manière anonyme et contourner la censure ; toutes les connexions sortantes vers Internet sont obligées de passer par le réseau Tor ;
  • ne pas laisser de traces sur l'ordinateur utilisé, sauf si l'utilisateur le demande explicitement ;
  • utiliser des outils de cryptographie reconnus pour chiffrer vos fichiers, courriels et la messagerie instantanée.

Tails est conçu pour être utilisable : chaque fonctionnalité et chaque logiciel sont prêts à être utilisés, documentés en détail, et traduits dans de nombreuses langues.

Tails coopère : tout ce que Tails produit est publié comme Logiciel Libre, et partagé avec d'autres projets, autant que possible.

Des gens utilisent Tails pour écrire des livres et monter des films.
Des gens utilisent Tails pour discuter à l'abri des oreilles indiscrètes, pour naviguer sur le web anonymement, et pour partager des documents sensibles.
De nombreuses personnes dépendent de Tails pour effectuer leurs tâches quotidiennes, quand ce n'est pas, tout bonnement, pour rester en vie.

Au plaisir de vous rencontrer les 5 et 6 juillet ! Sans nul doute, vous trouverez une chouette façon de contribuer à Tails, quel que soit votre spécialité !

Hôte et sponsors

Nous remercions vivement Debian, l'IRILL, Mozilla et le projet Tor pour leur soutien à cet événement !

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre