Nouvelles du Libre

Christopher Dziekan, d'IBM à Pentaho

Toolinux - ven, 04/04/2014 - 18:04

Le patron de la stratégie Business Analytics d'IBM a cette semaine rejoint Pentaho en tant que Chief Product Officer.

- Services
Catégories: Nouvelles du Libre

Talend Big Data certifié Cloudera pour Cloudera Enterprise 5

Toolinux - ven, 04/04/2014 - 18:02

L'éditeur a annoncé cette semaine que ses solutions Talend Open Studio for Big Data, Talend Enterprise Big Dataet Talend Platform for Big Data, sont désormais certifiées pour Cloudera Enterprise 5.

- Services
Catégories: Nouvelles du Libre

TOOLinux est de retour

Toolinux - ven, 04/04/2014 - 18:00

Ces derniers mois, l'accès au site TOOLinux a été bien souvent perturbé. Nous avons procédé cette semaine à une migration vers un nouveau serveur

- Breves
Catégories: Nouvelles du Libre

Big data : Jaspersoft et Talend étendent leur partenariat

Toolinux - ven, 04/04/2014 - 17:22

Jaspersoft et Talend lancent la version Big Data Extended de Jaspersoft Extract, Transform, and Load (ETL).

- Services
Catégories: Nouvelles du Libre

FusionDirectory 1.0.7.3 est sorti

Linuxfr - ven, 04/04/2014 - 14:55

L’équipe de FusionDirectory est heureuse de vous annoncer la publication de la version 1.0.7.3 de FusionDirectory. Pour ceux qui ne connaissent pas FusionDirectory, il s’agit d’un gestionnaire d’infrastructure. Il est à LDAP ce que Webmin pouvait être à NIS/NIS+ : une interface Web modulaire de gestion complète d’un annuaire LDAP. Sa modularité permet d’offrir aussi la gestion de services qui ne sont pas directement interopérables avec LDAP.

La version 1.0.7.3, qui est une version de maintenance, apporte des correctifs importants ainsi que de petites corrections.

Correctifs importants
  • Nettoyage de la fonctionnalité de prise d’instantané (snapshot) pour la rendre plus efficace
  • L’état de l’installation d’une machine avec FAI est à nouveau écrit correctement
  • Les fenêtres d’erreur LDAP sont plus claires et ont un style propre
Correctifs mineurs
  • Déplacement de la vérification du numéro de groupe (gid) vers la méthode de test globale
  • Suppression de l’entrée pour le chemin TFTP statique dans le service argonaut fuse
  • Correction de l’erreur lors de la création d’une tâche récurrente programmée (cronjob) pour le miroir Debian
Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Repas du Libre à Toulouse le 10 avril 2014

Linuxfr - ven, 04/04/2014 - 14:55

Le groupe d'utilisateurs de Logiciels Libres de Toulouse Toulibre en collaboration avec Tetaneutral.net fournisseur d'accès internet et hébergeur libre proposent aux sympathisants de se retrouver l'un des mardis ou jeudis de chaque mois pour échanger autour des logiciels Libres, des réseaux libres, discuter de nos projets respectifs et lancer des initiatives locales autour du Libre. Ce repas est ouvert à tous, amateurs de l'esprit du Libre, débutants ou techniciens chevronnés.

Ce Qjelt (Quelconque Jour du Libre Toulousain) aura lieu le jeudi 10 avril 2014 à 20 heures, au restaurant Bois et Charbon situé au 64 rue de la Colombette à Toulouse. C'est à proximité de la place Saint Aubin accessible par le métro à la station Jean Jaurès (ligne A et B). Entrée/plat/dessert + 1/4 de vin à 18€. Pour des raisons de logistique, une inscription préalable avant la veille au soir est demandée.

Inscription demandée avant le mercredi soir à l'adresse http://www.toulibre.org/qjelt.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Un an après le premier commit, nouvelle version pour wallabag

Linuxfr - ven, 04/04/2014 - 13:13

Il y a un an démarrait le projet wallabag (qui s’appelait alors poche). C’est une application qui vous permet de mettre de côté un article que vous souhaitez lire plus tard. Ce n’est pas uniquement un gestionnaire de favoris pour sauvegarder un lien, ça sauvegarde également tout le contenu de l’article et uniquement le contenu (c’est‐à‐dire que les éléments superflus — comme la publicité — ne sont pas conservés).

Un nouvelle version vient de sortir ce 3 avril et voici les nouveautés.

Nouvelle version, nouvelles fonctionnalités

La nouvelle version sortie le 3 avril 2014 apporte de nouvelles fonctionnalités attendues :

  • un moteur de recherche ;
  • un nouveau système d’importation ;
  • un raccourci clavier pour sauvegarder rapidement un nouvel article ;
  • la possibilité de sauvegarder un lien présent dans un article déjà sauvegardé.

Énormément de bogues ont été corrigés (dont le très ancien souci qui empêchait de rester connecté).

Visuellement parlant, pas mal de changements également, puisque, depuis quelques semaines déjà, le thème officiel du projet a changé et wallabag se dote maintenant d’un thème de qualité, et toujours responsive (s’adapte à la taille de l’écran). Il est possible de tester wallabag sur le site de démo.

Hey, je n’suis pas geek comme vous, je fais comment ?

Depuis que le projet a changé de nom, wallabag a également rejoint la sphère Framasoft, et vous pouvez créer un compte gratuitement et librement sur Framabag. Seule votre adresse de courriel vous sera demandée.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Mirantis : nouveau programme de partenariat OpenStack

Toolinux - jeu, 03/04/2014 - 23:12

Mirantis lance un nouveau programme de partenariat pour la formation OpenStack. Les cours sont fournis par des entreprises qualifiées.

- Services
Catégories: Nouvelles du Libre

Les journaux LinuxFr.org les mieux notés du mois de mars 2014

Linuxfr - jeu, 03/04/2014 - 08:08

LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l'équipe de modération avant publication. C'est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

Ce que l’on sait moins, c’est que LinuxFr.org vous propose également à tous de tenir vos propres articles directement publiables, sans validation a priori des modérateurs. Ceux-ci s'appellent des journaux. Voici un florilège d'une dizaine de ces journaux parmi les mieux notés par les utilisateurs… qui notent. Lumière sur ceux du mois de mars passé.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

OpenJDK 8, JEP 142 & False Sharing

Linuxfr - mer, 02/04/2014 - 19:48

Java 8 est sorti ce mois‐ci et vous avez même eu droit à une dépêche, ici‐même, qui parle des lambdas, de l’API flux (stream API), etc.

Cependant, derrière ces gros changements qui impactent le monde hétérogène des développeurs Java, il y a des petits changements qui eux servent plutôt aux développeurs qui font des briques de base, de l’infrastructure ou du code qui va vite. Je vous propose donc d’explorer quelques JDK Enhancement Proposals d’OpenJDK.

Pour cette première dépêche, on commence avec la JEP 142 : Reduce Cache Contention on Specified Fields soit l’annotation @Contended qui vise à proposer une solution aux problèmes de false sharing.

NdM : merci à ckyl pour son journal.

Sommaire C’est quoi le false sharing ?

Le false sharing est un problème de performance en environnement parallèle qui est causé par une « leaky abstraction » du matériel. La présentation suivante est extrêmement grossière et ne vise qu’à faire comprendre le problème aux gens ne connaissant pas du tout le domaine.

En tant que développeur, on aime se représenter la mémoire comme un espace d’adressage continu. Plus on travaille dans un langage de haut niveau, plus cela est vrai. Par exemple, les problèmes d’alignement sont une notion totalement inconnue pour beaucoup. Cependant, dans ce monde idéal, la réalité du matériel refait surface périodiquement.

Un processeur étant beaucoup plus rapide que la mémoire vive et le principe de localité ayant été découvert, il dispose de caches mémoire. Ce sont des petits morceaux de mémoire tampon travaillant à une vitesse beaucoup plus proche de celle du processeur. Le pari étant qu’une fois l’accès coûteux à la mémoire centrale effectué, cette valeur va être réutilisée et on ira alors la chercher dans ce cache en gagnant énormément de temps.

Le problème du false sharing vient de deux choses :

  • L’architecture des caches. Un cache est composé d’un certain nombre de lignes de taille fixe (64 octets, par exemple). Lorsqu’une modification est faite, elle affecte la ligne entière.
  • Le processeur doit gérer la cohérence entre ces caches à l’aide d’un protocole de cohérence. Il s’agit de s’assurer que lorsqu’un processeur ou un cœur fait une modification, elle sera visible par les autres. Chaque architecture a son propre modèle de cohérence, le x86 étant, par exemple, particulièrement fort. Ce modèle est exposé dans les langages de bas niveau, mais les langages de haut niveau décrivent souvent leur propre modèle mémoire. Charge au compilateur de traduire celui du langage vers celui de la plate‐forme.

Si l’on met ces deux choses ensemble, on arrive au false sharing : deux variables théoriquement indépendantes se retrouvent sur la même ligne de cache. Chacune est lue ou modifiée par un processeur distinct, cependant les processeurs doivent passer leur temps à se synchroniser, et les performances s’écroulent.

Bref, notre bel espace mémoire uniforme vient d’en prendre un coup. Coller ou espacer deux variables peut faire varier d’un à plusieurs ordres de grandeur la performance de notre structure de données.

Exemple

Commençons avec un banc d’essai très simple : une classe avec un seul membre et quatre fils d’exécution (threads). Le premier lit en permanence la valeur de ce membre, les trois autres ne font rien. Le banc d’essai est écrit avec JMH :

@State(Scope.Benchmark) public static class StateNoFalseSharing { public int readOnly; } @GenerateMicroBenchmark @Group("noFalseSharing") public int reader(StateNoFalseSharing s) { return s.readOnly; } @GenerateMicroBenchmark @Group("noFalseSharing") public void noOp(StateNoFalseSharing s) { }

Ce qui nous donne le résultat suivant :

Benchmark Mode Samples Mean Mean error Units g.c.Benchmarks.noFalseSharing:noOp avgt 18 0.297 0.002 ns/op g.c.Benchmarks.noFalseSharing:reader avgt 18 0.743 0.003 ns/op

Comme on pouvait s’y attendre, c’est très rapide, et on aura du mal à mesurer quelque chose de plus petit.

Maintenant, faisons évoluer notre banc d’essai. Nous ajoutons un deuxième membre qui va être accédé par les trois fils d’exécution qui ne faisaient rien. Le premier fil ne change absolument pas et, si les caches n’étaient pas organisés en ligne, il n’y aurait aucune raison que sa performance soit affectée.

@State(Scope.Group) public static class StateFalseSharing { int readOnly; volatile int writeOnly; } @GenerateMicroBenchmark @Group("falseSharing") public int reader(StateFalseSharing s) { return s.readOnly; } @GenerateMicroBenchmark @Group("falseSharing") public int writer(StateFalseSharing s) { return s.writeOnly++; }

Regardons les résultats :

Benchmark Mode Samples Mean Mean error Units g.c.Benchmarks.falseSharing:reader avgt 18 5.038 0.617 ns/op g.c.Benchmarks.falseSharing:writer avgt 18 78.530 3.598 ns/op

On vient presque de gagner un facteur 10.

Nous pouvons vérifier l’agencement mémoire de notre objet StateBaseline avec jol, pour voir que nos deux variables ont bien été juxtaposées par le compilateur :

gist.contended.Benchmarks.StateFalseSharing object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 12 (object header) N/A 12 4 int StateFalseSharing.readOnly N/A 16 4 int StateFalseSharing.writeOnly N/A 20 4 (loss due to the next object alignment) Instance size: 24 bytes (estimated, the sample instance is not available) Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

Sans rentrer dans les détails, statistiquement, il y a de fortes chances qu’elles se retrouvent dans la même ligne de cache.

@Contended

La solution à notre problème est donc simplement d’espacer ces deux variables, quitte à perdre de l’espace. Ça paraît simple, mais, avant OpenJDK 8, cela demandait de très sérieusement connaître la machine virtuelle Java (ou lutter contre elle).

Fort du principe de localité, le comportement logique de la machine virtuelle Java est d’essayer d’entasser autant que possible les différents membres comme bon lui semble. La disposition (layout) d’un objet peut changer selon beaucoup de critères. Et l’utilisation d’un ramasse‐miettes n’aide pas, puisque ce dernier peut décider de déplacer un peu tout et n’importe quoi (notamment les tableaux utilisés pour les aligner). Bref, trouver une stratégie qui marche, est une source d’amusement inépuisable. Aleksey Shipilёv en a documenté quelques‐unes dans un banc d’essai JMH, de même que Martin Thompson.

La JEP 142 propose d’ajouter une annotation @Contended pour identifier les variables, ou classes, qui doivent se retrouver seules sur une ligne de cache pour éviter le false sharing.

Essayons de l’utiliser :

@State(Scope.Group) public static class StateContended { int readOnly; @Contended volatile int writeOnly; } @GenerateMicroBenchmark @Group("contented") public int reader(StateContended s) { return s.readOnly; } @GenerateMicroBenchmark @Group("contented") public int writer(StateContended s) { return s.writeOnly++; }

Vérifions avec jol puis avec JMH :

gist.contended.Benchmarks.StateContended object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 12 (object header) N/A 12 4 int StateContended.readOnly N/A 16 128 (alignment/padding gap) N/A 144 4 int StateContended.writeOnly N/A 148 4 (loss due to the next object alignment) Instance size: 152 bytes (estimated, the sample instance is not available) Space losses: 128 bytes internal + 4 bytes external = 132 bytes total Benchmark Mode Samples Mean Mean error Units g.c.Benchmarks.contented:reader avgt 18 0.742 0.006 ns/op g.c.Benchmarks.contented:writer avgt 18 70.811 3.572 ns/op

On observe que la variable a bien été décalée, et l’on retrouve les performances initiales.

Limitations

@Contended est une JEP d’OpenJDK, c’est‐à‐dire qu’il ne s’agit pas d’une spécification de Java ou de la machine virtuelle Java (JVM). L’annotation se trouve dans un paquet privé d’Oracle, et elle n’est disponible que pour les classes du kit de développement Java (JDK) par défaut (comme beaucoup de choses que le JDK se réserve précieusement). Si l’on veut l’utiliser, et donc se lier à OpenJDK, il faut passer l’option -XX:-RestrictContended.

Bien entendu, vu l’impact sur la consommation mémoire et la possibilité de réduire l’efficacité du cache, il faut bien savoir ce qu’on fait et l’utiliser avec parcimonie.

Comment détecter un cas de false sharing

Notre exemple était très simple et nous connaissions le problème. Malheureusement, dans la vraie vie, ce n’est pas aussi évident, et il n’existe pas à ma connaissance d’outil simple permettant de détecter le false sharing, quel que soit le langage. On peut suivre les conseils d’Intel et les appliquer avec l’outil qu’ils fournissent ou avec perf, mais ça reste assez empirique.

Si l’on garde le principe du false sharing en tête, cela permet de surveiller les mauvaises pratiques dans les bouts d’infrastructure qui peuvent être affectés. En général, il faut que ça commence à aller sérieusement vite, donc avec des structures de données dédiées, pour que ça commence à devenir un problème.

Cas courants

Identiquement à notre exemple, un même objet possède deux membres qui sont utilisés par deux fils d’exécution différents. Ça arrive, par exemple, quand un objet tient des statistiques. Dans ce cas, on va annoter le membre avec @Contended.

On peut avoir aussi le cas de plusieurs instances d’une même classe qui préféreraient chacune être dans leur propre ligne de cache. Dans ce cas, on va annoter la classe. Cela fonctionne aussi si l’on met les instances dans un tableau ; cas courant, lorsque l’on fait travailler plusieurs fils d’exécution en parallèle.

Le dernier cas est le calcul de type matriciel avec plusieurs fils d’exécution. Dans ce cas, l’annotation ne peut rien et il faut concevoir son algorithme pour en tenir compte (tout comme on itère dans le bon sens). Dr doobs fournit un tel exemple.

J’ai essayé de fournir quelques exemples dans le banc d’essai.

Conclusion

@Contended ne devrait pas changer la vie de grand monde, hormis celle des gens qui pondent l’infrastructure de service à haute performance. Mais, elle ouvre la porte à une revendication de longue date : marier les bénéfices de la machine virtuelle Java avec les besoins des applications haute performance, en ouvrant l’accès au matériel et à des techniques contre l’esprit initial de Java, mais nécessaires.

Cette annotation ne répond absolument pas au besoin de pouvoir contrôler l’agencement d’un objet ou de choisir quels membres d’un objet doivent être regroupés. Elle ne résout pas non plus les problèmes d’indirection dus aux références pour les objets. Mais la pression monte doucement avec le nombre d’applications qui passent en off‐the‐heap ou en mmap lorsque nécessaire.

Enfin, le false sharing n’est pas le seul problème lié aux caches, il y a d’autres exemples.
Et, bien entendu, exploiter les caches correctement a un impact certain sur les performances d’une application.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Les codes sources de Microsoft Word 1.1a et DOS 1.1 et 2.0 publiés

Linuxfr - mer, 02/04/2014 - 19:48

Le 25 mars dernier, le code source de Microsoft Word 1.1a (1990) a été publiquement publié via le Computer History Museum. Ne rêvez pas trop, ce n’est pas libre et tout code dérivé n’est pas autorisé à être diffusé :

You may not distribute or publish the software or Derivative Works. You may not use or test the software to provide a commercial service unless Microsoft permits you to do so under another agreement.

N’espérez donc pas trop avoir ce splendide logiciel ergonomique qu’est Microsoft Word for Windows version 1.1a sous GNU/Linux prochainement (les polémistes habituels vont sans doute prétendre que LibreOffice n’arrive pas à la cheville de cette merveille).

Accessoirement, vous pouvez obtenir également le code de Microsoft DOS v1.1 (1982) & v2.0 (1983).

NdM : merci à fravashyo pour son journal. Sinon, vous pouvez aussi lire du vieux code libre, comme GCC 1.42 de 1990, LaTeX 0.90 de 1983, etc.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Les sources de Microsoft Word 1.1a et Dos 1.1 et 2.0 publiées

Linuxfr - mer, 02/04/2014 - 19:48

Le 25 mars dernier, le code source de Microsoft Word 1.1a (1990) a été publiquement publié via le Computer History Museum. Ne rêvez pas trop, ce n'est pas libre et tout code dérivé n'est pas autorisé à être diffusé :

You may not distribute or publish the software or Derivative Works. You may not use or test the software to provide a commercial service unless Microsoft permits you to do so under another agreement.

N'espérez donc pas trop avoir ce splendide logiciel ergonomique qu'est Microsoft Word for Windows version 1.1a sous Linux prochainement (les polémistes habituels vont sans doute prétendre que LibreOffice n'arrive pas à la cheville de cette merveille).

Accessoirement, vous pouvez obtenir également le code de Microsoft DOS V1.1 (1982) & V2.0 (1983).

NdM : merci à fravashyo pour son journal. Sinon vous pouvez aussi lire du vieux code libre, comme GCC 1.42 de 1990, LaTeX 0.90 de 1983, etc.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

ADSILLH : Licence professionnelle administrateur et développeur

Linuxfr - mer, 02/04/2014 - 07:50

L’Université de Bordeaux vient d’ajouter à son catalogue de formations la licence professionnelle Systèmes informatiques et logiciels spécialité Administrateur et Développeur de Systèmes Informatiques sous Licences Libres et Hybrides (ADSILLH). Deux autres formations analogues existent déjà, l’une à Angers et l’autre à Nancy. La description de cette licence est en deuxième partie.

Il s’agit bien d’une formation professionnelle destinée à trouver un emploi dans un secteur où la demande est forte.

Il est intéressant de remarquer que les étudiants devront s’impliquer dans la communauté des développeurs de logiciels libres autour de projets reconnus. Cette démarche est très intéressante car, ainsi, cette formation bénéficiera non seulement aux étudiants, mais à tous !

Les inscriptions sont d’ores et déjà ouvertes.

La licence professionnelle ADSILLH Carte d’identité de la formation
  • Domaine : sciences, technologies, santé.
  • Mention : systèmes informatiques et logiciels (nouvelle dénomination : administration et sécurité des systèmes).
  • Spécialité : Administrateur et Développeur de Systèmes Informatiques sous Licences Libres et Hybrides (ADSILLH).
  • Discipline : informatique.
  • Public concerné : formation initiale.
  • Niveau de sortie : licence professionnelle.
  • Durée : 1 an.
  • Crédits : 60 crédits ECTS.
  • Collège : sciences et technologies.
  • Composante : UF informatique.
  • Site de formation : Campus de Talence.
  • Responsable de la formation : François Pellegrini (professeur des universités).
Objectifs et compétences

La licence professionnelle ADSILLH (Administrateur et Développeur de Systèmes Informatiques sous Licences Libres et Hybrides) a pour objectif de former des techniciens en informatique de haut niveau en administration des systèmes d’information, polyvalents et aptes à effectuer l’intégration de composants logiciels appartenant à de nombreux domaines fonctionnels : systèmes d’exploitation, bases de données, serveurs Web, téléphonie logicielle, etc.

Ce profil, alliant de solides compétences d’administration à des capacités de développement, en partant des couches les plus basses jusqu’aux plus hautes, est explicitement recherché par les entreprises et fait l’unicité de la formation. Celle‐ci intègre également des aspects organisationnels.

Organisation des enseignements

La licence professionnelle ADSILLH est conforme au système européen. Elle complète une formation de 4 semestres, bac+2, par deux semestres supplémentaires. Elle consiste en 6 UE (Unités d’Enseignement) et permet l’attribution de 60 ECTS (European Credit Transfer System). Cette troisième année comprend environ 360 heures d’enseignement, et autant de travail personnel. Le premier semestre comporte environ 170 heures d’enseignement et inclut un projet tuteuré en petits groupes. Le deuxième semestre comporte environ 190 heures d’enseignement, et se conclut par un stage en entreprise de 16 semaines.

Environ la moitié de l’enseignement est dédié aux techniques de développement logiciel, un tiers à l’administration et un sixième aux compétences transversales : anglais, droit, économie.

Chaque UE fait l’objet d’évaluations notées : sous forme de contrôle continu et d’un examen écrit terminal et, dans certains cas, de rapport écrit et/ou d’exposé oral.

Poursuite des études et débouchés

La licence professionnelle est un diplôme à vocation terminale. Il n’y a pas de poursuite d’études associée.

Les débouchés visés sont les postes de responsable du système d’information et/ou d’administrateur système et réseau au sein des PME, ETI, grandes entreprises et collectivités locales. Les entreprises ciblées n’appartiennent pas nécessairement au secteur de l’informatique. Avec l’informatisation croissante de la société, de plus en plus d’entreprises ont besoin des compétences nécessaires au déploiement, à la maintenance et à l’évolution de leur système d’information.

Professionnalisation / Formation continue

La licence sera ouverte en contrat de professionnalisation et en formation continue.

Recherche

La réalisation du projet tuteuré « logiciel libre » a pour but de mettre en relation les étudiants avec la communauté de développeurs et d’utilisateurs d’un projet libre reconnu. De fait, les étudiants seront amenés à utiliser la langue anglaise dans nombre de leurs échanges, et ceux‐ci impliqueront des personnes de nationalités diverses. Ces prises de contact pourront favoriser la réalisation du stage en entreprise à l’étranger.

Schéma des études
  • UE 1 : Systèmes et réseaux (9 ECTS)
    • Installation et configuration des systèmes et réseaux
    • Programmation système
    • Programmation réseau (J1IN5014, « option obligatoire » sans le projet)
  • UE 2 : Langues, droit et économie (6 ECTS)
    • Anglais (B0TR5W01)
    • Droit et économie des logiciels
  • UE 3 : Projet tuteuré (15 ECTS)
Semestre 6
  • UE 4 : Technologies logicielles (12 ECTS)
    • Bases de données (J1IN6013, « option obligatoire »)
    • Développement Web
    • Logiciels de communication (cours localisé à Mont‐de‐Marsan, partenariat UPPA)
  • UE 5 : Progiciels et entreprise (9 ECTS)
    • Progiciels
    • Sûreté et sécurité 
    • Anglais niveau 6 et OP3 (B1TR6W01)
  • UE 6 : Stage en entreprise (9 ECTS)
Informations complémentaires

Les enseignements de logiciels de communication sont localisés à Mont‐de‐Marsan, et réalisés en partenariat avec l’UPPA.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

kGraft, un correctif en temps réel pour le noyau Linux

Toolinux - mar, 01/04/2014 - 23:50

SUSE propose kGraft, une technologie développée pour appliquer des correctifs au noyau Linux en temps réel. Contrairement à d'autres technologies, kGraft ne nécessite aucun arrêt du noyau, même pendant de courtes périodes.

- Logiciels
Catégories: Nouvelles du Libre

Une version intermédiaire de développement de MySQL 5.7

Toolinux - mar, 01/04/2014 - 23:48

Oracle annonce la disponibilité immédiate d'une démo de MySQL 5.7, ainsi que de nouvelles versions pour plusieurs autres produits MySQL.

- Logiciels
Catégories: Nouvelles du Libre

Gnome 3.12 se présente en vidéo

Toolinux - mar, 01/04/2014 - 23:45

Parce qu'une vidéo vaut mieux qu'une longue description, le projet de bureau graphique GNOME publie sur Youtube un résumé de trois minutes portant sur les nouveautés de la version 3.12, lancée le 26 mars dernier.

- Logiciels
Catégories: Nouvelles du Libre

Jahia 7 veut "redéfinir les standards des CMS open source haut de gamme"

Toolinux - mar, 01/04/2014 - 23:40

Jahia a lancé cette semaine une nouvelle plateforme Jahia 7 : fonctionnalités de développement distribué, "Private App Stores" et intégration d'OSGi.

- Logiciels
Catégories: Nouvelles du Libre

AdminBastion en mode MSSP

Toolinux - mar, 01/04/2014 - 23:20

L'éditeur français Wallix propose d'installer AdminBastion, sa solution de traçabilité et de contrôle des utilisateurs à privilèges, dans leur infrastructure, tout en déléguant l'administration et l'exploitation quotidienne du produit à un tiers de confiance.

- Services
Catégories: Nouvelles du Libre

Sortie de Linux 3.14

Linuxfr - mar, 01/04/2014 - 09:40

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

Bon, ça c'est fait 
mais Linus vous réserve bien d'autres nouveautés :)

Sommaire La phase de test RC-1

La version RC-1 est sortie le 2 février 2014.

Hé, c'était une fenêtre ordinaire de fusion sur quinze jours, qui est maintenant terminée. Autant que je sache, j'ai intégré tout ce qui m'a été demandé (à une exception près, voir plus loin) et j'ai appliqué tous les patches que je devais appliquer. Si vous pensez que j'ai oublié votre travail, cela pourrait être à cause d'un email pris pour un spam (cela est arrivé plusieurs fois récemment, mais je pense que je les ai tous) ou d'une simple incompétence de ma part (cela arrive aussi).

J'ai conscience que le nombre 3,14 semble familier pour certains, et j'ai eu des demandes de nommage en rapport avec cela. Mais ce n'est tout simplement pas comme cela que fonctionne le nommage du noyau. Vous pouvez vous consoler avec le fait que le nom ne s'affiche pas partout, et que personne n'y porte un réel intérêt. Ainsi n'importe quel nom en lien avec Pi que vous pourriez concevoir serait tout aussi pertinent que celui dans le Makefile principal, donc ne soyez pas déprimé.

Par ailleurs, n'importe quel geek qui se respecte connait vingt décimales de Pi depuis qu'il est un jeune con. Donc 3,14 n'est vraiment pas si proche, n'est-ce pas ?

Qu'importe, la demande d'intégration manquante est l'appel système rename2 que je pensais devoir regarder par moi-même, et pour laquelle j'espérais aussi plus de commentaires (je suis en train de te regarder, Al). Bref, j'ai senti que je n'avais pas le débit mental suffisant pour m'en occuper pendant cette fenêtre de fusion, mais je prendrai le temps de regarder ça tranquillement cette semaine. Je pourrais toujours l'intégrer avec la RC-2, mais franchement, c'est plus que probable que ça attende la 3.15.

Autre chose ? Le truc que j'ai vraiment fusionné ? C'était une fenêtre de fusion ordinaire, rien ne sort du lot. Les statistiques font apparaître le très traditionnel deux tiers pour les pilotes, le reste concernant un mélange de mises à jour des architectures (ARM domine, mais il y a du powerpc, X86, mips, s390, et même du ia64 avec de la suppression de code obsolète dans xen) et du tout-venant : cœur du noyau, gm (NDT : gestion de la mémoire), réseaux, outillage etc.

J'ai joint mon journal de fusion, vu que comme d'habitude la version courte du journal est bien trop longue. Et encore une fois, notez que mon journal de fusion ne donne que les noms des mainteneurs, pas les noms de ceux qui ont effectivement codé. Il faut lire les journaux complets de git pour avoir ce niveau de détail.

Linus

RC-2

La version RC-2 est sortie le 9 février 2014.

Ça a été plutôt calme, en fait, ce qui devrait me rendre heureux. Mais je suis de nature méfiante, et je vais attendre de voir si la situation empire, et si les gens sont juste en train de me bercer d'un faux sentiment de sécurité. Parce que je connais les développeurs du noyau, et ils sont sournois. Je soupçonne que Davem (pour prendre quelqu'un, pas au hasard) est en train de rire nerveusement, attendant ce message, planifiant de m'envoyer demain des demandes d'intégration de gros porc.

Parce que les gars, vous êtes de ce genre-là.

Qu'importe, le peu de nouveautés semble normal : à peu près deux tiers de pilotes (carte graphique, pilote en mode bloc, média et divers), avec presque la moitié des patchs restants pour la mise à jour des architectures (x86, s390 et ARM64). Le reste concerne les systèmes de fichiers (vfs, nfs, ocfs, btrfs et quelques corrections de kernfs), quelques trucs sur la gestion de la mémoire et de l'outillage (performance).

La version courte du journal est jointe, ce qui n'arrive pas à chaque RC2.

Linus

RC-3

La version RC-3 est sortie le 16 février 2014.

Quand j'ai annoncé la RC-2, j'ai mentionné combien elle était plaisante et petite. J'ai également noté que je ne vous faisais pas confiance et que je soupçonnais que certains d'entre vous gloussaient dans leur coin en retardant leurs demandes d'intégration, diaboliques petites créatures que vous êtes.

Et je déteste avoir raison. La RC-2 était assez légère, mais la RC-3 la contrebalance. J'ai tranquillement pris toutes les demandes d'intégration parce que cela n'était clairement pas une surprise, mais je vous avertis que je vais commencer à maudire des gens, si cette tendance se maintenait. Vous avez été prévenus.

Quoi qu'il en soit, parce que la version courte du journal est assez lourde, je présente les grandes lignes de mon journal de fusion ici, et je posterai sa version courte séparément en réponse à cet e-mail pour ceux qui veulent plus de détails. L'essentiel des modifications concerne le réseau et divers pilotes (réseau, de la branche staging, USB, pilote en mode bloc, infiniband…), mais il y a quelques mises à jour d'architecture (powerpc, ARM, x86) et quelques mises à jour de la documentation.

Linus

RC-4

La version RC4 est sortie le 23 février 2014.

Bon, tout semble normal, et la RC-4 est plus légère que la RC-3, je suis donc heureux.

Le plus gros changement inclus (représentant environ un sixième de la taille) est seulement dû à la ré-indentation d'un fichier reiserfs effectuée par DaveJ. En ignorant ce nettoyage d'espaces, il ne reste que le lot habituel de mises à jour de pilotes, des couches réseau et de quelques architectures.

Rien d'énorme, ni de particulièrement effrayant.

Alors prenez-la, et testez-la complètement.

Linus

RC-5

La version RC5 est sortie le 2 mars 2014.

Une autre semaine, une autre RC.

Les choses ont été clairement calmes, et clairement normales. Les pilotes représentent un peu moins de 60% des changements (le son est prédominant du fait de deux changements qui sont plus importants mais triviaux, mais il y a divers changements ponctuels partout). Le reste vient pour la plupart des mises à jour d'architectures (principalement PowerPC et xtensa), et puis il y a une poignée de petites choses ailleurs.

Pas beaucoup. C'est exactement ce que j'aime.

Allez vérifier que tout fonctionne pour vous.

Linus

RC-6

La version RC6 est sortie le 10 mars 2014

Nous nous approchons de la fin du cycle de rc et je dois admettre que j'aurais préféré un parcours moins chaotique.

Il n'y a pas eu d'énormes problèmes, mais il y a eu pas mal de petits heurts qui n'auraient jamais dû arriver si tard dans le cycle de sortie. Et la rc6 est également sensiblement plus grosse que ne l'était la rc5.

Donc, j'espère réellement que la semaine à venir sera plus calme, car sinon je devrai faire une rc8 voire rc9…

Cela dit, il n'y a rien de fondamentalement inquiétant jusqu'ici. De petites erreurs idiotes et quelques malheureux retours arrières tardifs de commits, mais le gros reste des corrections triviales. Donc, je reste raisonnablement optimiste.

Linus

RC-7

La version RC7 est sortie le 16 mars 2014

Une semaine peut vraiment faire la différence. En mieux. Il y a une semaine, en récoltant la rc6, j'étais mécontent : il y avait trop de correctifs épars et j’augurais une rc8, voire une rc9 comme une réelle éventualité.

Mais maintenant, une semaine s'est écoulée, et la rc7 semble beaucoup plus satisfaisante. Bon, il y a encore des choses imprévisibles un peu partout (les plus grosses contributions concernent le réseau, à la fois dans le cœur et les pilotes), mais c’est beaucoup plus petit que pour la rc6, et il n’y a rien qui m’incommode. Quasiment tous les changements sont petits, et je pense que le changement qui retire la vieille et inutile option x86 Centaur OOSTORE est probablement le plus gros d’entre eux. Le seul autre changement qui pourrait rivaliser en taille supprime du code lui aussi (« r8152 : désactiver le mode ECM »).

Maintenant, les choses peuvent encore changer, et peut-être que la prochaine semaine se terminera comme une semaine horrible, mais avec un peu de chance cela n’arrivera pas et c’est la dernière rc.

Allez-y et testez. Tout ça a l’air bon.

Linus

RC-8

La version RC8 est sortie le 24 mars.

J'avais pris un délai d'un jour sur mon calendrier habituel, espérant être plus à l'aise pour sortir cette version 3.14, mais cela n'a pas été le cas. Donc voici une rc8 et j'espère faire la dernière version le week-end prochain.

Il n'y avait pas tant de choses effrayantes en cours, mais il y a quelques correctifs vfs en attente et nous avons fini par avoir quelques correctifs intéressants sur le code principal la semaine dernière (pas de nouvelles régressions, mais récemment découvertes par Trinity. Félicitations à Hug Dickins pour les avoir comprises et en avoir corrigé les causes). Il y a aussi quelques correctifs réseau et des correctifs épars (principalement MIPS). Je souhaitais vraiment, par conséquent, une autre semaine avant de tout livrer.

Linus

Version finale

La version finale est sortie le 30 mars.

Bon, nous avons eu quelques changements tardifs dont j’aurais pu me passer, mais la liste des changements depuis la rc8 est assez petite, et je le sens bien tout ça. Si nous avions rencontré quelques problèmes de dernière minute à cause du sursaut de contribution final, ces patchs seraient très spécifiques et je n'ai donc pas vraiment de raison de retarder la publication sans rien avoir de notoire en attente. La majorité de ce sursaut final concerne des régressions marquées comme candidates pour les branches stables ou pour des régressions connues.

Donc la 3.14 est là et la fenêtre d’incorporation pour la 3.15 est ouverte. Veuillez s’il-vous-plait prendre le temps de tester cette 3.14, même si vous êtes pressés de me faire parvenir votre liste d’attente pour la prochaine version.

Linus

Les nouveautés Arch CPU Multi-processeurs Xtensa

Le processeur Xtensa reçoit la gestion multi-processeurs SMP (Symetric Multi-Processors).

Xtensa est le processeur configurable et extensible de Tensilica / Cadence Design Systems, basé sur une architecture 32 bits de type RISC.

Connu pour sa grande personnalisation et sa modularité il permet par exemple de choisir l'endianness, la largeur du bus de données, l'ajout de FPU supplémentaires, etc.

Co-processeurs cryptographiques de AMD

L'AMD CCP (Cryptograph Coprocessor) est maintenant pris en charge dans cette 3.14. Un co-processeur est un circuit intégré couplé au CPU qui permet de lui ajouter un support matériel dédié pour une tâche donnée (il en existe plein, comme par exemple des co-processeurs arithmétiques, vectoriels).

Selon les sources ce CCP pourrait être embarqué dans le ARM cortex-A15 de leur futur SoC Opteron. Il permettrait en outre de gérer les algorithmes de chiffrement AES, AES-CMAC, XTS-AES et les fonctions de hashage SHA directement en matériel.

MIPS interAptiv et proAptiv

L'équipe MIPS nous propose la gestion des derniers processeurs de la marque à savoir le MIPS interAptiv et le proAtiv.

MIPS fabrique principalement leurs puces pour des appareils grand public, comme par exemple des lecteurs Blu-ray de salons ou des télévisions numériques. On les retrouve également dans des terminaux bas de gamme de certains pays émergents.

Le interAptiv est la dernière génération de processeur basse consommation multi-cœurs de MIPS. Il est doté de la technologie MIPS Multi-threading (MT), proche de la technologie hyper-threading de Intel. Le MT est une technologie employée dans les processeurs multi-cœurs ces dernières années afin que la topologie et la réalisation matérielle soit plus adaptées aux programmes disposant de plusieurs fils d'exécution, chose très répandue de nos jours. Cette technologie permet d'obtenir de meilleures performances pour les programmes qui sont correctement prévus à cet effet (ce qui n'est pas toujours le cas et peut entrainer des surprises comme de la contention sur l'utilisation des unités de calcul partagé ou une mauvaise utilisation du cache). Ce processeur dispose également d'un protocole de cohérence de cache censé réduire et limiter les temps d'accès.

Le proAptic est le dernier processeur visant à concurrencer la société ARM sur la téléphonie mobile, les tablettes et peut-être les télévisions connectées. Le constructeur annonce un noyau deux fois plus petit que le ARM Cortex-A15 avec des performances similaires, voire plus élevées, encore faut-il que l'efficience soit au rendez-vous…

ARM64 : gestion de l'allocateur mémoire CMA

Dans les ordinateurs de bureau contemporains les contrôleurs DMA (Direct Memory Access) doivent avoir accès à la mémoire principale afin de pouvoir y copier ou y lire de grosses quantités de données (requête préalablement demandée par le noyau). Ces derniers n'ont pas directement accès à la mémoire physique pour diverses raisons : les périphériques peuvent être bogués et corrompre la totalité de la mémoire du système, ou nécessiter de gros tampons de mémoire contiguë (ce qui n'est pas toujours possible dans la mémoire physique), etc.

Le lien entre la mémoire principale et ces périphériques est réalisé par le biais d'une IOMMU. Il s'agit d'une unité de management de la mémoire comme la MMU qui permet de faire correspondre une adresse virtuelle à une adresse physique, uniquement pour celles qui ont été enregistrées par le noyau.

De nos jours, les cartes embarquées étant de plus en plus petites et pour certaines de moins en moins coûteuses, il est assez rare qu'elles soient munies d'IOMMU. Oui mais, comment gérer l'obtention de tampons contigus dans la mémoire physique ? Doit-on maintenir cette correspondance directement dans nos modules ? C'est la raison pour laquelle le framework CMA (Contiguous Memory Allocator) a été ajouté au noyau il y a quelques années.
Il s'agit d'une boîte à outils qui permet de demander l'allocation de zones mémoire contiguë directement dans la mémoire physique (quand c'est possible) ou de respecter certaines conditions d'alignement, par exemple.

Les processeurs ARM 64 bits ont maintenant la possibilité d'utiliser cet allocateur mémoire.

Intel Merrifield

Le Merrifield, le dernier chipset 64 bits mobile d'intel annoncé à la Mobile World Congress 2014 est maintenant géré dans le noyau.

Comparé à la génération précédente, le Merrifield apporte de meilleures performances graphiques 2D, une fréquence d'horloge un peu plus élevée (6.5%), il gère jusqu'à 4 Go de RAM LPDDR cadencée à 533Mhz et intégrera le GPU Power VR Series 6.

Nouvelles plateformes ARM

De nouvelles plateformes à base de processeurs ARM font leur apparition :

  • HiSilicon intègre la gestion de sa première carte. Il s'agit d'un constructeur chinois crée par Huawei destiné à produire des SoC (System On Chip) ARM.

  • Les plateformes embarquées EFM32 ARMv7m sont gérées. EFM32 est une famille de microcontrôleurs basé des ARM 32 bits et construit par Silicon Labs. Ces microcontrôleurs sont destinés à des solutions à très basses consommations énergétiques. Ces principales caractéristiques sont : des temps de calcul très faibles, un temps de réveil (lors d'interruptions) très rapide et une très faible consommation.

  • Le Marvell Berlin, le chipset à l'interieur de la Google Chromecast, dispose d'une prise en charge officielle.

  • La plateforme industrielle Moxa ARM est gérée dans cette 3.14.

  • La Freescale I.MX50 est gérée officiellement

Allocateurs mémoire et classes d'allocations ARM : protection des classes d'allocations des modules

Les plateformes disposant d'un processeur ARM peuvent configurer le noyau afin que les classes d'allocations des modules disposent de droits différents. Les classes d'allocations sont des zones mémoires disjointes dans lesquelles les données et le code sont disposés par le système au moment du chargement d'un programme ou d'un module. L'idée principale est de séparer les données entre elles, en fonction de l'utilisation dont va en faire l’entité logicielle concernée mais aussi de séparer le code de celle-ci. Ceci est fait à la fois pour respecter une sémantique d'utilisation mais aussi pour des raisons de sécurité. Il serait en effet regrettable de pouvoir exécuter une zone de donnée, comme le tas ou la pile (exploitable en cas de dépassement de tampons par exemple) ou de pouvoir modifier la zone mémoire dans laquelle se trouve le code.

À partir de la version 3.14, les plateformes ARM pourront demander au système que les zones de codes des modules, ou celles censées être en lecture seule, ne soient pas modifiables. Il auront également la possibilité de restreindre l'exécution de certaines classes d'allocations.

Ordonnancement

La classe d'ordonnancement SCHED_DEADLINE est l'une des grandes nouveautés de cette version. Il s'agit d'une politique d'ordonnancement temps réel basé sur l'algorithme Earliest deadline first (EDF).

Les processus doivent fournir trois paramètres à l'ordonnanceur : une limite temporelle au-delà de laquelle il ne faut pas aller pour que la tâche soit accomplie, une période spécifiant la fréquence à laquelle elle doit être exécutée et un temps CPU maximum à ne pas dépasser lors de l'exécution de cette tâche (sa durée maximale). Les processus sont ensuite placés dans une file de priorité, ainsi à chaque fois que l'ordonnancement reprend la main (préemption ou coopération en rendant la main à ce dernier lors d'une action bloquante par exemple) il exécute la tâche dont la limite d'exécution est la plus proche.

Les ordonnanceurs deadline sont très utiles pour les tâches temps réel ou pour les tâches périodiques multimédia.

Développement, déboguage et outils perf

L'une des grandes nouveautés de perf est l'ajout de la prise en charge du compteur de consommation énergétique Intel RAPL.

RAPL (Running Average Power Limit) est une fonctionnalité matérielle, introduite lors de la sortie des processeurs de la famille Sandy bridge, qui permet de surveiller, contrôler et collecter des informations concernant la consommation énergétique des SoC (System On Chip) d'un ordinateur. Les développeurs du noyau pourront donc savoir précisément quels sont les composants matériels les plus sollicités énergétiquement en fonction des modifications qu'ils effectueront. Plus d'informations sur RAPL sont disponibles dans la dépêche de sortie de Linux 3.13

L'utilitaire en espace utilisateur bénéficie également de nombreuses améliorations et nouvelles fonctionalités. Pour plus de détails, veuillez consulter la requête de fusion de Ingo Molnar

Pour mémoire, perf est un outil de profilage dans Linux qui permet de superviser facilement les compteurs de performance. Les compteurs de performance sont des registres spéciaux dans le processeur qui permettent de compter les événements matériels qui ont lieu lorsque vous exécutez du code : le nombre de défauts de cache, le nombre d’instructions exécutées, les prédictions de branchements correctes ou incorrectes, etc.

kexec

kexec est désormais compatible avec les systèmes disposant de EFI. Actuellement, ceci n'était fonctionnel qu'à partir d'un BIOS.

L'architecture m68k bénéficie également d'une prise en charge préliminaire de kexec.

kexec (kernel execution) est une fonctionnalité au sein de Linux qui permet de démarrer à chaud un nouveau noyau en écrasant l'espace d'adressage de l'existant actuellement en cours d'exécution.
Cette procédure permet d'éviter les phases d'initialisation matérielle faite par le micro-logiciel BIOS ou UEFI ainsi que le chargeur de démarrage, réalisées au lancement de votre ordinateur. Ceci permet donc de gagner un temps considérable lorsque vous souhaitez mettre à jour votre noyau ou lorsqu'un développeur réalise des changements dans un composant central du noyau nécessitant un redémarrage.

smp_load_acquire/smp_store_release

Les barrières de synchronisation mémoire smp_load_acquire() et smp_store_release() ont été ajoutées. Voir cet article pour savoir quand elles sont nécessaires et comment les utiliser.

preempt_enable_no_resched

preempt_enable_no_resched() est une fonction qui permet de ré-activer le mode préemptif de l'ordonnanceur du noyau, préalablement désactivé, tout en demandant à ce dernier de ne pas interrompre la tâche courante immédiatement.

Cette fonction n'est plus disponible pour les modules car elle est jugée trop dangereuse et mal utilisée par les développeurs de l'ordonnanceur du noyau qui considèrent que les modules ne devraient pas faire preuve de créativité à ce niveau là. Pour plus d'informations, veuillez consulter ce fil de discussion.

Pilotes graphiques libres DRM (Direct Rendering Manager)

Peu de nouveautés pour DRM si ce n'est une amélioration de la gestion des timestamps et un peu de nettoyage de code.

Voir le pull request.

TTM (Allocateur Mémoire Graphique)

La principale nouveauté de TTM devait être une augmentation des performances CPU lors de l'allocation de pages mémoires partagées grâce à l'utilisation du drapeau VM_PFNMAP au lieu de VM_MIXEDMAP (commit). Cependant, durant le cycle des RC, un problème de performance a été trouvé dans certains cas (utilisation combinée de VM_PFNMAP, x86 PAT et du write-combining). Le patch initial a donc été enlevé en attendant de mieux investiguer le problème (commit).

TTM se voit aussi recevoir une amélioration liée au partage de tampons graphiques entre différentes cartes graphiques (DMA-buf). TTM ne générera plus de faute de page sur les pages importée par DMA-buf (commit).

Voir le pull request.

Adreno (pilote msm)

La principale nouveauté du pilote graphique MSM est la prise en charge des adreno 330. Cette prise en charge a nécessité de retravailler l'architecture du pilote du bloc d'affichage qui est passé de sa version 4 à 5. Comme ces blocs sont similaires, du code a été factorisé.

MSM peut maintenant fonctionner sur des systèmes ne disposant pas d'IOMMU. Dans ces cas là, le pilote réservera dans la mémoire centrale une zone qui sera dédiée aux rendus graphiques grâce au Contiguous Memory Allocator (CMA). La taille de cette zone mémoire est configurable grâce au paramètre noyau msm.vram. Pour des raisons de sécurité, le pilote refuse encore de se charger si aucune MMU n'est disponible afin d'empêcher le GPU d'accéder aux adresses qui ne lui sont pas réservées. Il semblerait que cette restriction puisse être levée dans le futur car le GPU aurait un moyen matériel de limiter les adresses auxquelles les clients graphiques peuvent accéder.

La gestion de COMPILE_TEST fait également son entrée. Cette gestion permet de forcer la compilation du pilote, même quand on n'est pas sur une architecture gérée par msm. Cela permet de tester la compilation depuis une autre plateforme.

Pour finir, les SoC APQ8060A (double coeur + GPU a320) sont désormais pris en charge.

Voir le pull request.

AMD/ATI (pilote radeon)

La prise en charge du DPM (Dynamic Power Management) a été ajoutée pour la famille de carte Sea Islands/CIK ce qui devrait permettre de réduire la consommation énergétique et la température sur ces cartes.

Toujours dans la famille Sea Islands, la prise en charge d'UVD (décodage vidéo matériel) a été de nouveau ajoutée. Il semblerait que sa prise en charge ait été accidentellement supprimée il y a un an, lors de la fusion de la gestion d'UVD dans le noyau (commit).

Dans la famille Volcanic Islands, le chipset Hawaii vient de recevoir des microcodes ce qui devrait permettre d'activer l'accélération 2D, 3D et vidéo.

Une modification tardive sur la partie gérant l'envoi de commandes a permis d'activer le support pour les Geometry Shaders (GS) sur les cartes des r600 et r700. Cela permet donc à radeon d'avoir le support d'OpenGL 3.2 et 3.3 sur ces cartes !

Rashika Kheria, du Outreach Program for Women, a également écrit plusieurs patchs pour résoudre des warnings dans le pilote afin de pouvoir activer un niveau de deboggage plus élevé dans GCC lors de la compilation du noyau (plus d'informations).

Le pilote a également reçu plusieurs corrections de bogues et légères améliorations. Voir le pull request pour plus d'informations.

Intel (pilote i915)

La gestion des GPU Broadwell est maintenant considérée comme stable et ne nécessitera plus d'option de compilation particulière. La gestion des processeurs Baytrail s'est aussi améliorée, notamment sur l'affichage (branchement à chaud du VGA).

La deuxième grande nouveauté est que l'UMS (User-space Mode-Setting) est maintenant déprécié en faveur du KMS (Kernel-based Mode-Setting). Le pilote Intel était le dernier à gérer officiellement l'UMS depuis que le pilote Radeon a décidé de déprécier sa gestion en Janvier 2013. Le support de l'UMS devrait être définitivement retiré dans le noyau 3.16.

Dans la même veine de suppression des vieilles interfaces, il est maintenant possible de compiler le pilote i915 sans prise en charge de fbdev. Ce n'est pas une bonne idée pour la plupart des utilisateurs de bureau car certaines applications telles que l'écran de chargement Plymouth en dépendent. Par contre, cela permet à certaines plateformes embarquées de réduire le volume de code compilé. Dans le futur, nous pouvons penser qu'il sera possible d'utiliser des applications telles que kmscon de façon à rendre totalement obsolète l'interface fbdev.

Côté sécurité, la gestion du PPGTT (Per-Process Graphics Translation Table) s'améliore mais quelques régressions de dernière minute ont empêché l'ajout des dernières parties nécessaires pour sa gestion complète. Espérons que la prochaine version apportera une gestion fonctionnelle et permettra d'isoler chaque processus dans un espace d'adressage différent !

La partie noyau de gestion de l'extension OpenGL GL_ARB_robustness vient également d'être intégrée. Le rôle de cette extension OpenGL est de permettre aux applications de réagir à la perte de leur contexte graphique dans le cas où le matériel aurait planté ou été mis en pause (Optimus).

Le reste des modifications concerne la gestion de l'affichage et sa gestion d'énergie. Pour plus d'informations, vous pouvez consulter l'article de blog de Daniel Vetter, mainteneur i915

NVIDIA (pilote nouveau)

La gestion initiale de l'accélération pour les GPU GK110/GK208 (NVF0/NV108) fait son apparition dans le noyau 3.14 grâce à Ben Skeggs. Cette gestion est incomplète car elle requiert aussi des modifications dans le pilote nvc0 de mesa à cause du changement d'ISA (Architecture_de_processeur). Elle est cependant suffisante pour faire tourner gnome shell. Ilia Mirkin a corrigé une bonne partie des problèmes de génération d'instruction dans Mesa. Ces modifications devraient être disponibles dans la version 10.2.

La gestion de l'affichage des erreurs a également été améliorée par Ilia et Ben afin de mieux pouvoir diagnostiquer les problèmes remontés par la carte.

En parlant d'affichage, la gestion des overlays vidéo pour les cartes nv10-40 vient d'être dévoilée par Ilia grâce à l'interface KMS planes. Il faudra des modifications dans xf86-video-nouveau pour que les applications en espace utilisateur puissent l'exploiter.

Le travail de fond pour la gestion d'énergie continue, mais rien n'a encore été soumis.

Voir le pull request.

OMAP (pilote omap)

Peu de nouveautés du côté du pilote OMAP qui ajoute la gestion du Device Tree pour le bloc TI DMM (Dynamic Memory Manager). Le reste des modifications corrige des bogues au démontage à chaud du pilote omap.

Voir le pull request.

Renesas R-Car DU (pilote rcar-du)

La principale nouveauté du pilote Renesas R-Car DU est l'ajout de la prise en charge du r8a7791 DU qui est une version allégée du r8a7790 DU avec uniquement 2 CRTC (2 écrans maximum) et une unique sortie LVDS (liaison habituelle pour les écrans d'ordinateur portable). Le reste des modifications se limite à l'aspect cosmétique du code et de la correction de bugs matériel avec l'ajout de rustine pour la sélection des voies LVDS.

Voir le pull request.

Tegra (pilotes host1x et tegra)

Cette nouvelle version d'host1x apporte une gestion initiale des SoC basés sur Tegra124.

Le pilote DRM/Tegra se voit aussi recevoir une gestion partielle de prime ce qui va permettre à tegra (le processeur graphique) d'afficher les images calculées à l'écran grâce à host1x sans faire de copie.

Il est également maintenant possible de désactiver la gestion de fbdev à la compilation même si il sera compilé par défaut. Les motivations pour ce travail doivent être les mêmes que pour Intel.

Le reste des changements apportés sont liés à host1x et au contrôleur d'affichage. Plus d'écrans sont gérés, et l'utilisation de l'HDMI est plus économe en énergie.

Voir le pull request

VMware (pilote vmwgfx)

Pas de changement visible pour le pilote vmwgfx dans cette version. Le travail a uniquement consisté en l'écriture de la gestion pour l'allocation de ressources graphiques en utilisant la mémoire de la machine virtuelle. Ces ressources sont les contextes graphiques, les textures et les shaders.

Cette gestion permettra l'implémentation des pilotes pour la version 11 de la carte graphique virtuelle svga2. Maintenant que les modifications sont disponibles dans le noyau, des patchs pour mesa devraient bientôt arriver pour gérer l'allocation locale de mémoire.

Voir le pull request.

Réseau Adresses IPv6 temporaires en espace utilisateur

En IPv6, l'auto-configuration des adresses est la règle par défaut. Cela a conduit à une gestion des adresses en espace noyau : à la réception d'une annonce de routeur, le noyau se charge d'attribuer une adresse globale statique dérivée de l'adresse MAC, et une adresse aléatoire temporaire si la variable sysctl use_tempaddr est au moins à 1.

C'est bien beau et pratique, mais des outils en espace utilisateur ont parfois envie de prendre la main. L'exemple le plus typique et le plus connu est probablement NetworkManager. Ces outils pouvaient déjà bien entendu ajouter ou supprimer des adresses, mais uniquement des adresses permanentes. Impossible d'ajouter une adresse considérée comme temporaire par le noyau. Il serait bien entendu possible de mettre un minuteur pour supprimer l'adresse depuis l'espace utilisateur, mais cela n'aurait pas les mêmes effets (une adresse temporaire est marquée comme obsolète par le noyau et n'est pas supprimée directement après son expiration).

Un nouveau drapeau de configuration des adresses a donc été ajouté, permettant l'ajout d'une adresse temporaire depuis l'espace utilisateur. Cela permettra aux outils en espace utilisateur de prendre totalement la main sur la configuration de l'IPv6, et permettra aussi d'ajouter plus tard les adresses temporaires obtenues par DHCPv6.

Pour l'anecdote, cette fonctionnalité a eu des conséquences sur ifconfig durant le cycle de développement. En effet, ifconfig lit le fichier /proc/net/if_inet6 pour déterminer les adresses assignées à une interface. L'ajout de l'information du drapeau "adresse temporaire" cassait cette lecture, et a donc été retirée (l'information reste lisible par l'interface netlink). C'est un bon rappel pour ceux utilisant encore les vieux outils : ifconfig et les outils associés sont obsolètes, et ne renvoient que des informations incomplètes sur l'état réel de la configuration réseau. La bonne méthode est d'utiliser les outils apportés par iproute (cf cet article).

Bouchon automatique sur TCP

Les développeurs noyaux de Google sont très intéressés par les performances réseaux du noyau Linux, en particulier du protocole TCP (par exemple avec RPS et RFS). Pour cette version, ils ont développé des "bouchons" automatiques sur une socket TCP.

Mais qu'est-ce qu'un bouchon ? Le principe est ancien : une application peut depuis très longtemps mettre l'option TCP_CORK sur une socket, ce qui bloque l'envoi de petits paquets. Les écritures de l'application sur la socket sont alors placées dans une file d'attente, qui peut ensuite se vider dans deux situations :

  • partiellement si elle est suffisante pour envoyer une frame complète ;
  • complètement quand l'application enlève le bouchon en désactivant l'option.

L'intérêt est de gagner en performance : chaque paquet TCP étant coûteux, il est plus simple et potentiellement plus rapide d'envoyer un gros paquet qu'une dizaine de petits.

C'est bien beau, mais cette option demande une coopération fine de l'application. Tout repose sur elle, qui doit mettre le bouchon et l'enlever au bon moment. Eric Dumazet, développeur chez Google, propose donc d'optimiser tout ça automatiquement. À présent, quand le noyau reçoit de nouvelles données à mettre dans une socket TCP, il vérifie deux choses. La première est la taille du paquet. S'il est suffisamment grand, il est ajouté dans la queue à transmettre.

En revanche, si le paquet est trop petit, il se peut qu'il soit pertinent d'attendre un peu avant de le placer dans la queue. Le noyau regarde donc s'il y a des paquets déjà en attente d'envoi. Si c'est le cas, on peut attendre, la carte réseau a déjà du travail, cela ne retarde rien de ne pas mettre le paquet dans la pile immédiatement. Le paquet sera mis à la fin du vidage de la file.

Ce petit délai donne une chance de grouper plusieurs messages de l'application dans le même paquet. Ce qui ressemble à une petite optimisation permet des gains de performance inattendus dans certains cas, à la fois en terme de débit utile et de processeur utilisé.

Pour désactiver cette fonctionnalité, une nouvelle variable sysctl existe : /proc/sys/net/ipv4/tcp_autocorking. On peut aussi s'amuser à compter les paquets bouchonnés avec nstat -a | grep TcpExtTCPAutoCorking. Le bouchon manuel est quant à lui toujours disponible pour les applications capables d'anticiper leurs besoins.

Petites nouvelles de nftables

nftables, ou le nouveau pare-feu sous Linux, a été intégré dans le précédent noyau 3.13. Cette version contient donc logiquement de nombreuses corrections, suite aux retours des nouveaux utilisateurs.

Dans les fonctionnalités on notera l'apparition d'une nouvelle table inet, permettant d'ajouter des règles pour IPv4 et IPv6 simultanément. Pratique pour la cohérence des règles sur les deux protocoles, notamment celles qui concernent des ports à ouvrir pour TCP et UDP. De quoi simplifier la vie des administrateurs, obligés de jongler entre iptables et ip6tables, ou d'utiliser un outil de haut niveau pour générer les règles.

Du debug pour BPF

Le Berkeley Packet Filter est régulièrement cité dans les dépêches noyaux, par exemple pour la version 3.0. Pour rappel, il permet aux applications analysant le réseau de ne pas capturer l'ensemble des paquets, mais seulement une partie, que le noyau se charge de trier en fonction de règles définies par l'application.

Les développeurs de ces applications seront heureux de découvrir un débogueur, permettant de simplement vérifier l'exécution du filtre avant de réellement l'exécuter. Pour utiliser ce débogueur, il existe un programme bpf_dbg tout prêt dans le dossier tools/net des sources du noyau.

Toujours dans ce dossier, le nouvel outil bpf_asm permet de compiler de l'assembleur BPF en espace utilisateur pour l'insérer ensuite dans le noyau directement. Cet usage est normalement réservé à des usages très particuliers, pour des développeurs ne pouvant pas utiliser la bibliothèque libpcap : soit parce qu’elle manque de fonctionnalité, soit parce qu’elle ne peut être intégrée sur le système, soit parce que le développeur veut utiliser le compilateur JIT (décrit dans la dépêche noyau 3.0), etc.

Une fois n'est pas coutume, la série de patch contient aussi une mise à jour de la documentation de BPF.

Systèmes de fichiers Ext4

Rien de bien croustillant pour le système de fichier ext4 cette fois-là. Correction d'une régression dans bigalloc, activation par défaut de la fonction punch hole — toujours pour bigalloc — et aussi quelques autres mises à jours diverses et éparses pour un total de 9 commits. Pour plus de détails sur les changements d'ext4, voir ici.

Btrfs

Bien que les changements apportés à Ext4 et Xfs ne soient pas extraordinaires, le système de fichier Btrfs avance à grand pas.
Chris Mason a écrit dans sa demande d'intégration : « c'est un gros morceau : la plupart de ces changements sont dans Btrfs-next depuis très longtemps ».

Changements majeurs :

  • ajout des propriétés d'inodes (Filipe David Borba Manana) ;
  • export des infos du système de fichiers dans sysfs (Jeff Mahoney) ;
  • énormément d'améliorations de performances.

Adapté d'un article de phoronix.

F2FS

F2fs, Flash-Friendly File System, un système de fichier écrit spécifiquement pour les mémoires flash NAND continue son évolution. Celui-ci est écrit et maintenu par Kim Jaegeuk, employé par Samsung, et vise à fournir une meilleure prise en charge des matériels tels que les cartes SD ou autres disques durs SSD. Dans cette dernière fournée, f2fs se voit ajouter de nouvelles options afin de modifier son comportement durant l'exécution : small_discards, max_victim_search et in-place-update. Les performances en lecture/écriture sont améliorées dans certaines situations, et la gestion des données inline_data (amélioration du stockage des petits fichiers) est commencée. Comme souvent, ce fut aussi l'occasion de réaliser du nettoyage de code et de corriger plusieurs rapports d'erreurs.

Voir le pull request.

kernfs

Kernfs est une version plus générique de sysfs pour que d'autres sous-systèmes puissent l'utiliser pour créer leur propre système de fichier virtuel. Il bénéficieront ainsi facilement des attributs propres à sysfs (gestion de la déconnexion d'un périphérique, création et suppression d'entrées dynamiques…). Sysfs a donc été modifié pour utiliser kernfs (commit), et le système de fichier virtuel utilisé pour représenter les cgroups en espace utilisateur est en cours de conversion (commit). La conversion de debugfs est aussi prévue.

Attention à ne pas confondre avec le kernfs de NetBsd.

Pour rappel, sysfs est un système de fichier virtuel introduit dans le kernel 2.5. Il permet de fournir à l'espace utilisateur des informations sur le matériel et ses pilotes. Plus concrètement parlant, Sysfs permet de fournir une méthode générique de chargement à chaud (hot plug), un arbre de relation materiel->unité logique générique (device tree), mais aussi de simplifier procfs. Cette mise à jour fut fournie par Patrick Mochel, puis patchée par Maneesh Soni.

RBD

En parlant stockage, et bien qu'il ne s'agisse pas d'un système de fichier, un problème de stabilité a été résolu dans le module RBD (le «périphérique de type bloc» des clusters Ceph), qui pouvait provoquer un kernel panic à haut régime.

Sécurité Audit

Le système d'audit change temporairement de code de retour d'erreur dans certains cas. Cela concerne principalement les utilisateurs de conteneurs qui devaient jusqu'à présent désactiver l'audit pour pouvoir se loguer dans un conteneur (commit). Ce commit est un hack temporaire, un correctif propre sera proposé pour inclusion dans le 3.15 (bugzilla) à la suite des changements déjà implémentés dans le 3.13. Ce hack est similaire à celui déjà implémenté dans systemd-nspawn.

D'autres bugs liés à l’interaction d'audit avec les namespaces ont été corrigés (commit).

Chaque changement dans la configuration des éléments audités loguera les informations du processus l'ayant effectué (commit).

La taille du tampon de stockage temporaire des messages d'audit peut être illimitée (seulement limitée par la quantité de RAM : commit).

Les logs générés lors d'un plantage et création d'un core dump contiennent le nom de l'exécutable qui a planté (commit).

Le code a été globalement retravaillé (commit).

Protection de la pile à la compilation par GCC (GCC stack protector)

La version 4.9 de GCC gèrera l'option -fstack-protector-strong, qui se positionne entre -fstack-protector et -fstack-protector-all. Ces options activent la protection de la pile à l'aide de canaris qui consiste à détecter et ainsi prévenir les effets néfastes des dépassements de tampon. Cette nouvelle option choisit plus judicieusement dans quel cas la protection est appliquée à une fonction. Cela évite d'avoir à choisir entre protéger toutes les fonctions (même celles pour lesquelles la protection n'est pas vraiment nécessaire) et ne protéger que très peu de fonctions (seulement 2.81% avec -fstack-protector).

Kees Cook a ajouté la gestion de cette option dans le noyau Linux. Les détails sont sur son blog avec le document de travail pour l'implémentation dans GCC.

Intel Memory Protection Extensions (MPX)

Inclusion des bases de l'infrastructure pour gérer l'extension matérielle MPX, pour l'instant spécifique aux futurs processus Intel. Les fonctionnalités elles-mêmes seront incluses plus tard.

L'extension MPX vise à mieux protéger le système des vulnérabilités de type dépassement de tampon. Pour cela, des registres supplémentaires seront introduits pour stocker les valeurs maximales et minimales que peuvent prendre certains pointeurs. Lorsque l'un de ces pointeurs est déréférencé, l'adresse est comparée aux valeurs précédemment stockées dans les registres. Les accès en dehors de ces limites déclenchent une exception #BR (boundary range exceeded) qui peut ainsi être traitée soit par le noyau, soit par le programme en espace utilisateur.

À terme, la prise en charge devrait fonctionner pour les programmes en espace utilisateur ainsi que pour le noyau (la gestion pour l'hyperviseur KVM est prévue). Ces protections sont contrôlées séparément.

La prise en charge complète de MPX nécessite donc des changements dans les compilateurs. En outre, la protection n'est pas "tout ou rien", car un programme peut fonctionner même si seulement une partie du code est compilé pour MPX et ce même code sera aussi fonctionnel sur les processeurs ne gérant pas l'extension.

kALSR

kASLR (kernel Address Space Layout Randomization : commit) consiste à rendre aléatoire l'adresse physique et l'adresse virtuelle à laquelle est décompressé le noyau Linux lors de la phase de démarrage.

Ceci devrait rendre un peu plus difficile l'exploitation de vulnérabilités dans le noyau puisqu'un attaquant ne pourra plus simplement utiliser une même adresse statique sur tous les systèmes vulnérables (et avec la même version du noyau). Il lui faudra au préalable récupérer une adresse mémoire d'un élément dans le noyau (memory infoleak) pour pouvoir calculer l'adresse de la structure ou fonction à utiliser dans un exploit.

Comme cette étape se déroule très tôt au démarrage du système, les contraintes de placement en mémoire sont fortes et l'entropie disponible est faible. Il n'est donc possible d'utiliser que 9 bits d'entropie pour l'architecture AMD64 et 8 bits pour l'architecture x86.

Les développeurs du patch grsecurity ont vivement critiqué cet ajout car il n'apporte que très peu d'avantages en terme de sécurité. En effet, les vulnérabilités de type fuite d'information sont assez courantes dans le noyau Linux et elles ne sont pas corrigées avec la même rapidité que les failles plus immédiatement critiques. Une explication détaillée est disponible sur le blog de grsecurity.

Note importante : l'hibernation n'est pour l'instant plus possible avec un noyau configuré avec kASLR (option RANDOMIZE_BASE).

Vérification des copies userspace/kernelspace

Une première étape vers plus de vérification sur les copies entre userspace et kernelspace a été ajoutée sous forme de module noyau vérifiant les appels à copy_to/from_user (commit). Les erreurs à ce niveau sont souvent source de bugs ou de fuites d'information justement.

Trousseaux de clés

Plusieurs bugs dans la gestion des trousseaux de clés par le noyau ont été corrigés (1, 2).

LSM SELinux

La politique SELinux stockée dans le noyau stockera les informations nécessaires aux outils en espace utilisateur pour déterminer quelle contrainte a levé une interdiction (commit). Les contraintes SELinux sont un ensemble de règles d'une politique qui ont précédence sur toutes les autres règles. Elles sont vérifiées à l'exécution, d'où l'importance de ce patch dans l'investigation des erreurs de ce type. Les contraintes sont particulièrement utilisées dans la politique MLS.

Les labels de sécurité associés à des paquets IPsec seront vérifiés à la fois pour les paquets entrants (ce qui est fait actuellement) et les paquets sortants (commit). Il est en effet possible de marquer les paquets IPsec avec des labels SELinux pour qu'ils soient interprétés par le destinataire. Le composant netfilter peut alors prendre des décisions de filtrage en fonction de ces labels.

SMACK

Les exécutables ne peuvent plus être labelés avec "*" ou "@" car les fichiers qu'ils créeraient ne disposeraient pas de restrictions suffisantes par défaut ("*" signifie tout le monde peut lire le fichier), ce qui est contraire aux principes du MAC (commit).

Le contrôle de la socket /dev/log était limité par défaut aux processus avec le label "_". Or le système Tizen n'utilise ce label que pour un nombre très limité de processus. Il fallait donc autoriser l'administrateur à définir un label personnalisé chargé de la gestion de cette socket. La nouvelle valeur par défaut est *, ce qui autorise l'accès par n'importe quel label. Pour restreindre à nouveau l'accès, il suffit d'écrire le label désiré dans smakfs/syslog (commit).

Les contrôles SMACK effectués lors du montage de systèmes de fichiers sans droits particuliers (utilisateurs non root) étaient trop laxistes et pouvait permettre à un processus d'effectuer des opérations nécessitant la capacité CAP_MAC_ADMIN en temps normal. Il n'est ainsi plus possible d'indiquer des options SMACK lors d'un montage non privilégié. Cette fonctionnalité sera potentiellement réactivée plus tard si un modèle valide est trouvé pour gérer ce cas (commit).

Un autre petit changement corrigeant potentiellement une vulnérabilité a été ajouté (commit).

Chiffrement

Ajout de versions de l'algorithme AESNI-GCM exploitant les instructions AVX/AVX2 (commit) optimisant les opérations de chiffrement et de déchiffrement pour des blocs de données de grande taille. Les gains sont de 6, 11, et 18% pour des blocs respectivement de taille 1, 2, 8K par rapport aux versions des ces algorithmes exploitant les instructions SSE. Les gains devraient être encore plus importants pour les futurs processeurs Intel.

Virtualisation KVM

Du côté Intel, la virtualisation imbriquée (qui consiste à avoir les machines virtuelles qui exposent les instructions de virtualisation, ce qui permet d'avoir un hyperviseur en machine virtuelle sans problème de performance, très pratique pour tester une solution de virtualisation sur son portable) est corrigée car elle n'était plus disponible depuis le noyau 3.13. Pour les architectures ARM, la supervision du contrôleur d'interruption est désormais possible, ce qui permet la migration à chaud de machines virtuelles. Pour les mainframes IBM (s390), il y a la prise en charge des transactions et de la « Load Program Parameter facility for guests », cette dernière est un prérequis pour avoir un compteur de performance matériel sur ces processeurs. Enfin, toujours chez IBM, l'architecture POWER permet les invités en little endian et la prise en charge des nouveautés des POWER 8.

Il y a eu deux pull requests concernant KVM auxquels vous pouvez vous référer pour plus d'informations, 1 et 2.

Xen

Cette version apporte deux nouveautés majeures dans Xen. Premièrement, l'extensibilité du canal des évènements matériels (IRQ). Au lieu d'avoir une table à deux niveaux par processeur, il y a maintenant une file FIFO avec priorité, ce qui permet d'avoir une meilleure latence, de gérer plus d'évènements et d'être plus extensible.

La deuxième fonctionnalité est le mode PVH ; pour ceux qui ne connaissent pas Xen, il y a plusieurs modes. Le premier est le mode paravirtualisé (PV) qui implique l'utilisation d'un noyau invité prévu pour fonctionner avec Xen mais offre des fonctionnalités intéressantes comme des bonnes performances avec un processeur 32 bits ne prenant pas en charge les instructions de virtualisation ; et le fait de ne pas devoir émuler le matériel. L'autre mode est le mode Hardware Virtual Machine (HVM) qui virtualise classiquement le système et permet de faire tourner n'importe quel système d'exploitation.

Le mode PV pose problème avec les invités 64 bits car les appels systèmes sont lents. Cela est dû au fait que sur 32 bits, Xen utilise la segmentation de mémoire du processeur, mais comme cette fonctionnalité était utilisée par très peu d'applications, AMD l'a supprimé des instructions 64 bits et Xen doit faire plus de travail de vérification pour éviter les failles. Pour résoudre ce problème, l'équipe a décidé d'utiliser l’infrastructure de virtualisation des processeurs pour la paravirualisation : ce mode hybride est le PVH. Il permet d'avoir des invités beaucoup plus réactifs en 64 bits et beaucoup moins de code dans le noyau.

Pour plus d'information sur le PVH, vous pouvez regarder la vidéo (en anglais) de la conférence du Fosdem : « How we ported FreeBSD to PVH » et lire le pull request.

Divers

Pour ceux à qui cette dépêche aurait donné l'envie d'ouvrir le capot et mettre les mains dans le moteur, il n'est pas trop tard pour vous inscrire au Challenge Eudyptula. Le but est, petit à petit, d'amener les participants via des exercices progressifs à apprendre à utiliser les outils nécessaires et comprendre les règles du développement du noyau Linux.

L'Eudyptula Minor est le nom scientifique du manchot pygmée bien connu des Linuxiens.

Le bilan en chiffres

En ce qui concerne les statistiques du cycle de développement du noyau 3.14, le site LWN.net a publié son traditionnel article récapitulatif et on peut également se reporter au site remwod qui compile des statistiques relatives au développement de Linux.

Le nombre final de patchs incorporés dans cette version est de 12 300 soit légèrement au-dessus des 12 122 patchs du noyau 3.13. Ces ajouts sont le résultat du travail d'environ 1 500 développeurs soit là-encore, une hausse notable par rapport aux 1 402 développeurs du noyau précédent.

C'est Intel qui occupe la tête du classement des entreprises, avec une marge assez confortable par rapport à Red Hat. Rappelons toutefois que la hiérarchie s'inverse complètement quand on examine les tags de type "signoffs". Ces tags sont employés par les mainteneurs pour marquer leur approbation d'un changement.
Dans ce rôle de gardien des portes du noyau, les développeurs employés par Red Hat représentent (selon LWN) 20% des tags de type "signoffs" alors que les développeurs Intel ne sont qu'à 11,8% et ceux de la Linux Foundation sont à 13,4% (il s'agit essentiellement de Greg KH).

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 Jarvis, Thomas DEBESSE Arch Romain Perier Pilotes graphiques libres Martin Peres Réseau Florent F. Systèmes de fichiers Jiehong (inactif) Timothée Ravier Sécurité Timothée Ravier Virtualisation Xavier Claude Édition générale Martin Peres, Mali, Patrick_g

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. 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

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

Linuxfr - mar, 01/04/2014 - 05:37

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

[Le Monde.fr] «2048», stop ou encore?

Par Marlène Duretz, le jeudi 27 mars 2014. Extrait:

Ce jeu de réflexion, addictif et chronophage, fait des petits en ligne.

Lien vers l'article original: http://www.lemonde.fr/vous/article/2014/03/27/2048-stop-ou-encore_4390930_3238.html

Et aussi:

[Libération.fr] La querelle des algorithmes scolaires

Par Léa Lejeune, le jeudi 27 mars 2014. Extrait:

Les rudiments de la programmation et du code informatique enseignés dès le primaire? L’idée agite la sphère geek. Lubie ou projet visionnaire?

Lien vers l'article original: http://www.liberation.fr/economie/2014/03/24/la-querelle-des-algorithmes-scolaires_989290

[PC INpact] Les députés brésiliens adoptent une loi en faveur de la neutralité du Net

Par Xavier Berne, le jeudi 27 mars 2014. Extrait:

Discuté depuis de longs mois déjà, le «Marco Civil da Internet» a été adopté mardi soir par la Chambre des députés du Brésil. Ce projet de loi, relancé par l’exécutif suite aux révélations d’Edward Snowden, contient des dispositions visant notamment à garantir la neutralité du Net dans ce pays d'Amérique du Sud. Soutenu au niveau international par WikiLeaks, La Quadrature du Net ou Tim Berners-Lee, le texte est l'objet de nombreuses attentions. Désormais, il doit cependant obtenir l’approbation du Sénat.

Lien vers l'article original: http://www.pcinpact.com/news/86722-les-deputes-bresiliens-adoptent-loi-en-faveur-neutralite-net.htm

[Developpez.com] L'open source, moteur de l'innovation technologique?

Par Hinault Romaric, le jeudi 27 mars 2014. Extrait:

80% de logiciels commerciaux seront basés sur des piles open source. L’open source est devenu un élément clé au sein de l’univers technologique. Au fil des années, la culture du développement open source est devenue un moteur de l’évolution de l’industrie du développement logiciel.

Lien vers l'article original: http://www.developpez.com/actu/69401/L-open-source-moteur-de-l-innovation-technologique-80pourcent-de-logiciels-commerciaux-seront-bases-sur-des-piles-open-source

Et aussi:

[InformatiqueNews.fr] L’open source next-generation au service de la cybersécurité

Par Cyrille Badeau, le jeudi 27 mars 2014. Extrait:

Le concept de logiciel open source est apparu au début des années 80 comme un moyen pour les universitaires spécialisés en informatique et les chercheurs de travailler en collaboration pour élaborer le meilleur logiciel possible et relever de nouveaux défis. Alors que l’adoption des nouvelles technologies a trouvé un nouvel élan dans les années 90, l’intérêt pour une approche «ouverte» a continué de croître et les utilisateurs y ont trouvé un réel intérêt.

Lien vers l'article original: http://www.informatiquenews.fr/lopen-source-next-generation-au-service-de-la-cybersecurite-cyrille-badeau-sourcefire-12143

[ouest-france.fr] «Libre en fête» au lycée de l'Hyrôme samedi

Par la rédaction, le jeudi 27 mars 2014. Extrait:

Pour accompagner l'arrivée du printemps, des événements de découverte des logiciels libres et du «libre» en général sont proposés partout en France.

Lien vers l'article original: http://www.ouest-france.fr/libre-en-fete-au-lycee-de-lhyrome-samedi-2056365

Et aussi:

Voir aussi:

[leParisien.fr] Données personnelles: l'UFC attaque Facebook, Twitter et Google +

Par la rédaction, le mardi 25 mars 2014. Extrait:

Après dix mois de négociations avec les grands réseaux sociaux Facebook, Twitter et Google +, l'association de consommateurs UFC Que-Choisir a décidé de saisir la justice devant le tribunal de grande instance de Paris en demandant à ces géants d'internet de clarifier les conditions d'utilisation des données personnelles.

Lien vers l'article original: http://www.leparisien.fr/high-tech/donnees-personnelles-l-ufc-attaque-facebook-twitter-et-google-25-03-2014-3707289.php

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Syndiquer le contenu