Linux France

S'abonner à flux Linux France
Mis à jour : il y a 11 min 30 sec

Appel à partenariat pour créer d'autres petits hackers

Lundi 7 Avril

Un appel à projet sur l’éducation populaire et la jeunesse autour du numérique vient d’être lancé. Et nous, à la Maison du libre (mld29.net), dans la dynamique des Fabriques du ponant (consortium fondé entre Les petits débrouillards Bretagne, La Maison du Libre et Telecom Bretagne), nous avons créé un club d’informatique et d’électronique pour les jeunes qui a maintenant 4 ans d’existence (détails dans la seconde partie de la dépêche).

Nous (c’est pas encore défini si c’est la Maison du libre, les Fabriques du ponant et /ou le Patronage laïque Guérin) avons avec cet appel à projet l’envie d’étendre ce travail sur d’autres territoires bretons. Cela sera aussi pour nous l’occasion d’approfondir notre « club » avec des ouvertures le mercredi, et pendant les vacances scolaires.

Donc pour pouvoir étendre ce travail auprès des jeunes, nous recherchons des partenaires en Bretagne.

Quatre ans d'activité du club d’informatique et d’électronique pour les jeunes

C’est un refuge pour tous les jeunes geeks qui peuvent être un peu en décalage du fait de leur passion, avec leur cercle social, mais c’est aussi un moyen d’expliquer ce qu’est le libre dans son ensemble. Le type d’activité que nous avons développé c’est installation GNU/linux, découverte du bash et des scripts, apprentissage de vi, initiation à l’électronique, création de robot, développement d’un jeu vidéo sur téléphone portable, TCP/IP, serveur apache, blender, etc. Bref que du libre.

Avec ces jeunes nous avons aussi organisé un stage de découverte électro-multimedia dans une structure de quartier (le patronage laïque). Nos petits hackers ont animé pendant une semaine des initiations autour de l’Arduino, Blender, screencast (pour pouvoir créer sa chaine YouTube) et GIMP (retouche photo).

Toujours avec le patronage laïque Guérin, nous avons organisé un camp geek où les jeunes de la structure ont pu vivre leur passion de SF, fantastique, jeux vidéo et un peu d’électronique. Et enfin, le patronage laïque a aussi lancé une activité autour de Minecraft où le patron se sert de ce jeu vidéo de création de monde virtuel pour travailler sur le vivre ensemble.

Télécharger ce contenu au format Epub

Lire les commentaires

AFUP Lyon - 10 avril : conférence sur MySQL

Lundi 7 Avril

L'antenne lyonnaise de l'AFUP (Association Française des Utilisateurs de PHP) organise le 10 avril prochain une conférence sur le SGBD MySQL. Celle-ci sera animée par Olivier Zemrag, consultant MySQL chez Oracle.

La présentation abordera donc différentes thématiques, dont :

  • comment retrouver des infos rapidement en cas d’erreur ;
  • la configuration de MySQL ;
  • des conseils au niveau de l’indexation ;
  • des exemples d’utilisation de la base performance_schema.

La conférence aura lieu dans le grand amphithéâtre d’Epitech Lyon, au 86 boulevard Marius Vivier-Merle 69003 Lyon, à 18h30 le 10 avril 2014.

Les inscriptions à cette conférence gratuite se font sur cette page.

Télécharger ce contenu au format Epub

Lire les commentaires

Création de l'association Open Food Facts et assemblée constitutive au NUMA à Paris le 11 avril 2014

Lundi 7 Avril

Open Food Facts a débuté il y a maintenant 2 ans, le temps passe vite ! Jusqu'à présent tous les efforts ont porté sur le fond plutôt que sur la forme : le projet se développe bien, la base de produits grandit et s'internationalise, mais il n'existe pas encore de structure juridique dédiée à Open Food Facts (le projet est pour l'instant "abrité" par l'entreprise unipersonnelle du fondateur dont l'activité principale est l'édition du site Recettes de Cuisine).

Le projet Open Food Facts est collaboratif et à but non lucratif, créer une association 1901 pour le porter est donc tout indiqué.

Pourquoi une association ?

Cette association permettra de ré-affirmer le caractère non-lucratif du projet, de permettre à plus de personnes de s'impliquer dans plus d'aspects du projet, et de rendre possible l'obtention de ressources pour développer plus d'activités.

Préparation de la création de l'association et assemblée constitutive

La création de l'association est en cours de préparation sur le wiki d'Open Food Facts. L'association sera effectivement créée à la suite de l'assemblée constitutive qui aura lieu au NUMA le soir du vendredi 11 avril 2014. Beaucoup de contributeurs et de participants au projet n'étant pas parisiens, il sera possible d'utiliser Internet pour s'inscrire sur la liste des membres, se présenter au conseil d'administration, et voter pour l'élection du conseil d'administration.

Statuts de l'association

Un projet de statuts est en ligne sur le wiki, que vous pouvez commenter sur la page de discussion associée.

Inscription sur la liste des membres

Si vous avez envie de rejoindre l'association (ce n'est pas obligatoire pour contribuer au projet, mais tous les participants sont encouragés à adhérer, en particulier si elles et ils souhaitent s'impliquer au delà du simple ajout de produits), vous pouvez vous inscrire sur la liste des membres.

Candidatures pour le conseil d'administration

Si vous souhaitez vous impliquer dans la gestion quotidienne de l'association, vous pouvez présenter votre candidature au conseil d'administration. Les candidatures sont ouvertes jusqu'au 30 mars 2014.

À voir également : le calendrier et les modalités de l'élection du conseil d'administration.

Nous espérons que vous serez nombreuses et nombreux à rejoindre l'association, et que nous aurons le plaisir d'échanger avec celles et ceux d'entre vous qui habitent en région parisienne lors de l'assemblée constitutive au NUMA. Cette soirée sera également l'occasion de vous présenter les projets en cours et à venir, et à vous inviter à y participer et à en lancer d'autres.

Télécharger ce contenu au format Epub

Lire les commentaires

Thème cloud computing / infonuagique

Dimanche 6 Avril

Cette année le thème Cloud Libre du salon Solutions Linux, Libres et Open Source (20 & 21 mai 2014 - CNIT - Paris La Défense) va s'orienter vers les déploiements effectifs de projets de l'IaaS au PaaS en passant par l'orchestration. Retours d'expériences, solutions émergentes, quelles sont les différentes technologies pour monter et industrialiser ses déploiements et la gestion de son infrastructure ?

Le thème comprend une table ronde du IaaS au PaaS : un écosystème de solutions libres ! et sept conférences spécifiques (mots-clés cloud ouvert, Prism, ownCloud, dpdk.org, Solum, OpenStack, Shinken, Hadoop) détaillées en seconde partie de dépêche.

Sommaire

13h00-14h00 : table ronde du IaaS au PaaS : un écosystème de solutions libres !

Lors de cette table ronde nous ferons un tour d'horizon des différents projets qui permettent de passer du IaaS au PaaS. Nous nous interrogerons notamment sur l’interopérabilité entre les outils, le rôle l’existence de standards et la possibilité de piloter des projets multi-environnements.

Intervenants :
  • Christophe SAUTHIER, CEO, Objectif Libre
  • Hervé LERCLERC, Directeur Technique, Alter Way
  • Michel-Marie MAUDET, Directeur Général, Linagora
  • Frédéric AATZ, Responsable de Stratégie Interopérabilité et Open Source et Marc GARDETTE, Senior Business Dev Manager, Microsoft

Animateur : Jonathan LE LOUS, meneur de pratique Cloud conputing, Savoir-faire Linux

Conférences spécifiques
  • 14h10-14h40 : Pourquoi et comment un Cloud Ouvert, par Jean-Pierre LAISNE, CEO, CompatibleOne
  • 14h45-15h25 : Living in a Cloudy Post-Prism World – the User Data Manifesto, par Frank KARLITSCHEK, ownCloud project Creator & owncloud.com, CEO, ownCloud
  • 15h30-16h10 : Indicateurs de haut niveau et supervision niveau métier : nouveaux défis de la supervision à l’ère du cloud, par Rodrigue CHAKODE, Ingénieur R&D, SysFera et RealOpInsight Labs
  • 16h15-16h55 : dpdk.org- le cœur de la performance réseau sur les systèmes virtualisés, par Vincent JARDIN, CTO 6WIND
  • 17h00-17h40 : Solum : le PaaS arrive dans OpenStack, par Julien VEY, DevOps, Numergy
  • 17h45-18h25 : La supervision dans les nuages avec OpenStack et Shinken, par Thibault COHEN, Leader de pratique supervision, Savoir-faire Linux
  • 18h30-19h00: Hadoop as Service, OpenStack + Hadoop, par Charly CLAIRMONT, CTO, ALTIC

Résumé des interventions :

  • 14h10-14h40 : Pourquoi et comment un Cloud Ouvert, par Jean-Pierre LAISNE, CEO, CompatibleOne
    Clouds hybrides, fédérations de cloud, places de marché, bourse de services cloud, tous ces termes se recouvrent une même réalité. Dans les faits ils décrivent les différentes formes plus ou moins complexes d'évolution possible des architectures cloud. Lors de cette présentation, nous nous proposons d'exposer les points communs et les relations qui peuvent être établies entre ces différentes architectures. Grâce à des cas d'usage et des retours d'expérience, nous étudierons en particulier les standards ouverts et les logiciels libres permettant de gérer la complexité de ces nouvelles architectures massivement distribuées.

  • 14h45-15h25 : Living in a Cloudy Post-Prism World – the User Data Manifesto, par Frank KARLITSCHEK, ownCloud project Creator & owncloud.com, CEO, ownCloud
    In this session Frank Karlitschek, founder of the ownCloud project and creator of the User Data Manifesto, will discuss steps individuals and businesses can take to protect their own data – as well as the responsibility we share to assure our own privacy and data protection.
    People have become increasingly worried about the privacy of their information, revelations have surfaced that the NSA – and other state-controlled agencies (and businesses and black hatters?) – are spying on businesses and individuals. Karlitschek founded the ownCloud project and more recently created and began publicly discussing the User Data Manifesto, defining basic rights for people to control their own data in the internet age.

  • 15h30-16h10 : Indicateurs de haut niveau et supervision niveau métier : nouveaux défis de la supervision à l’ère du cloud, par Rodrigue CHAKODE, Ingénieur R&D, SysFera et RealOpInsight Labs
    Le but de cet exposé sera de présenter les enjeux et les nouvelles problématiques de la supervision des environnements IT actuels. Notamment dans un contexte où la vision cloud, de plus en plus présente, impose aux responsables de supervision de passer outre les indicateurs de bas niveau pour s’intéresser davantage à la qualité de service fournie aux utilisateurs finaux ainsi qu’aux applications tierces.

  • 16h15-16h55 : dpdk.org- le cœur de la performance réseau sur les systèmes virtualisés, par Vincent JARDIN, CTO 6WIND
    La communauté dpdk.org a été lancée l'année dernière par 6WIND afin de soutenir les projets nécessitant du traitement de paquet à très haut débit (200Mpps, 200Gbps) en environnement cloud pour les solutions NFV.
    Cette communauté est devenue très active en quelques mois.
    Plusieurs projets open source (Openvswitch, rump) et sociétés spécialisées dans les télécoms (Cisco, vmware, NEC, etc.) utilisent maintenant les librte de dpdk.org afin de booster leurs performances. Elles contribuent sur dpdk.org.

  • 17h00-17h40 : Solum : le PaaS arrive dans OpenStack, par Julien VEY, DevOps, Numergy
    Solum, L’un des projets d'Openstack en phase de prototypage dite “StackForge”, peut se décrire ainsi: “Transformer le code en une application managée tournant sur OpenStack en un clic de bouton”. Il s’agit bel et bien d’une solution de PaaS (Platform-as-a-Service). Solum tire partie des dernières solutions technologiques en matière de PaaS, avec notamment le projet Docker, utilisé au coeur de la plateforme. Partant d’une nouvelle base de code, sans historique à gérer, comme cela peut être le cas pour des solutions concurrentes telles que OpenShift ou CloundFoundry, Solum avance vite, poussé par des acteurs tels que RedHat ou Rackspace et l’essor de la communauté OpenStack.
    Dans cette présentation, nous détaillerons les aspects techniques du projet Solum, les composants OpenStack dont il tire partie, l’intégration de Docker… Nous présenterons également les différentes roadmaps du projet, quels langages vont être supportés, quel est l’horizon de sortie…

  • 17h45-18h25 : La supervision dans les nuages avec OpenStack et Shinken, par Thibault COHEN, Leader de pratique supervision, Savoir-faire Linux
    Nous commencerons cette conférence par une courte présentation d'OpenStack et de Shinken. Ensuite nous montrerons les possibilités d'ingrégration de ces deux solutions. Pour finir, nous exposerons quelques exemples de supervision de différentes couches de la solution OpenStack: que ce soit au niveau du service final, des applications de gestion de la plateforme OpenStack, des systèmes d'exploitation, ou du matériel.

  • 18h30-19h00: Hadoop as Service, OpenStack + Hadoop, par Charly CLAIRMONT, CTO, ALTIC
    Il existe de nombreuse questions sur le caractère prête à l'emploi du Big Data. Beaucoup d'interrogation quant à la manière de monter des architectures, ou à la souplesse d'étendre son cluster à mesure de ses besoins.
    Un projet open source c'est proposé de résoudre cette problématique d'"Hadoop élastique". Il s'agit du projet Savana, qui s'incrit comme un plugin pour OpenStack et qui permet aux organisation de bénéficier tant de la puissance de calcul d'Hadoop que de la flexibilité que peut délivrer OpenStack.
    Dans cette présentation, il s'agit de montrer à tous à quel point il est simple grâce à Savana d'avoir du "Hadoop à la demande". Après une brêve introduction et avoir détaillé les principaux composants du projet, une légère démonstration pour conclure.

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie d’IPython en version 2.0

Dimanche 6 Avril

IPython est une console alternative principalement tournée vers l'exploration interactive des données. Comme tous les 6 mois maintenant (avec 3 mois de retard), la nouvelle version est publiée. Je vous inviterai à aller lire les dépêches précédentes si vous ne connaissez pas IPython.

Au-delà d'une simple console Python, elle est aussi agnostique au niveau du langage en offrant une console Qt, un notebook web (interface web riche) et l'architecture pour y écrire dans son dialecte préféré.

Pour rappel, IPython 2.0 est la seconde des quatre versions qui seront publiées sur les fonds donnés par la fondation Sloan sur une durée de deux ans. Je vais ici vous présenter quelques nouveautés qui ont été développées lors des 9 derniers mois et vous donner un avant-goût de ce qui est prévu pour le mois à venir.

Merci aux participants qui m'ont aidé à rédiger cette dépêche, corrigeant les fautes d'orthographe et les anglicismes.

Sommaire

Une fois n'est pas coutume, les notes de version sont disponibles sur le site web d’IPython, mais cette fois-ci la documentation officielle s'étoffe et utilise IPython Notebook viewer pour afficher les répertoires d'exemples. Ces notes sont plus complètes que la présente dépêche, mais on notera tout de même (cf. plus loin) que les Notebooks exportés en HTML avec nbconvert ou Nbviewer n'affichent pas les widgets et nécessitent d'être exécutés en local avec la nouvelle version.

En deux mots

Cette version de IPython a perdu son statut de rc le 2 avril (pour éviter un poisson), après plus de 8 mois de travail. On notera l'obligation d'utiliser Python 2.7 ou ≥ 3.3 (on s'excuse pour les gens encore sous 2.6 et 3.2), mais cela a permis l'unification du code source qui fonctionne indifféremment sur les deux versions majeures de l'interpréteur, sans avoir recours à des outils tels que 2to3.

Les grandes nouveautés sont toutes pour le Notebook :

  • Widget interactif javascript ;
  • navigation du disque dur ;
  • URL persistante ;
  • Interface modale ;
  • augmentation de la sécurité.

En chiffres, ou plutôt en nombres (arrondis à chaque fois) :

  • 8 mois de travail ;
  • 650 demandes d'intégrations pour 4000 modifications ;
  • 400 bogues fermés ;
  • 100 contributeurs (merci à eux !).
Ce que vous devez savoir Interface modale

Les raccourcis clavier de l'interface du Notebook ont complètement changé. Les premières interactions avec le Notebook risqueront d'être bien difficiles (comparez à la première fois où vous avez utilisé Vim). Du fait des limitations des navigateurs web, ce changement était nécessaire, et implique quelques heures d'ajustement pour les utilisateurs déjà habitués aux raccourcis clavier. Allez faire un tour dans le menu d'aide si vous êtes perdu.

Tout comme beaucoup d'éditeurs modaux, vous pouvez vous trouver entre deux états, soit vous éditez une cellule et le clavier se comporte comme dans n'importe quel éditeur de texte classique (edit mode, utilisez Enter pour y accéder), ou en mode commande (Esc) les touches du clavier sont alors assignées à des actions, comme x pour couper, j pour sélectionner la cellule suivante… une introduction est bien sûr disponible pour les anglophones, lecture vivement conseillée, et sauvegarde préalable de vos .ipynb aussi.

Sécurité

Au sein de l'équipe de développement d’IPython, le Notebook tel que présent dans la 1.0 est comparé au bouton qui déclenche une bombe atomique enveloppée dans un joli bonbon qu'on tendrait à un nourrisson. Les capacités de destruction et de mauvaise utilisation sont particulièrement importantes. C'est pourquoi un modèle de sécurité a été adopté. À partir de maintenant, chaque Notebook est signé numériquement avec une clé privée générée au premier lancement, et tout chargement d'un Notebook dont la signature n'est pas valide désactive un grand nombre de fonctionnalités. En pratique, cela signifie que si M. ou Mme Michu™ vous envoient un Notebook, au chargement de celui-ci, vous ne pourrez voir que les jolis HTML et JavaScript qui affichent des chiots animés. Vous devrez ré-exécuter le Notebook dans son intégralité, ou explicitement lui faire confiance.

Cela ne signifie bien sûr pas que la sécurité est infaillible, on appréciera aussi tout retour d'expérience de personnes plus compétentes au niveau cryptographie. On notera que le système est à priori extensible, donc oui, utilisateur motivé de LinuxFr.org, tu devrais pouvoir écrire une extension qui utilise GPG.

Le Beau et Brillant Navigation du disque dur

Le schéma URL est maintenant REST, et persistant ! Vous n'avez plus besoin que de lancer un seul notebook server pour parcourir tout votre disque dur ! Même si on évite de servir des fichiers qui sont dans ~/.ssh, ne lancez pas le serveur n'importe où dans votre arborescence !

Vous pouvez aussi maintenant utiliser la fonction marque-page de votre butineur pour retrouver rapidement tous vos Notebooks.

Les widgets javascript

C'est beau, ça bouge, ça se manipule à la souris et c'est simple à utiliser, mais ça reste encore à peaufiner. Il vous suffit d'un simple décorateur sur une fonction pour que les paramètres de celle-ci soient accessibles avec de jolis éléments de GUI et au moindre changement le résultat se met à jour. Un peu comme ce bel exemple de Jake Van Der Plas.

Sous le capot c'est un protocole qui décrit une synchronisation, et ne suppose pas l'utilisation de JavaScript. Sachant qu’un greffon pour Emacs permet déjà de se connecter au Notebook, rien ne vous empêche de réaliser les widgets pour Emacs en utilisant lisp. Ceci devrait aussi permettre aux autres langages de réutiliser les mêmes widgets. Pour les impatients, vous trouverez une vidéo de B. Granger lors de PyData 2014, avec une démonstration des widgets (la vidéo démarre à la 34 ème minute).

Avec l'implémentation actuelle, la création de widget et leur affichage nécessite un noyau actif. De ce fait, l'export de Notebook en HTML ne conserve pas les widgets. Nbviewer utilisant l'export en HTML, vous ne verrez donc pas de widgets à moins de télécharger le Notebook qui vous intéresse et de l'exécuter en local (on travaille dessus).

La suite Multi-language

Pour ceux qui n'auraient pas suivi, ou qui liraient en diagonal, IPython permet d'écrire en utilisant un autre langage que Python, vous pouvez probablement écrire en quelques lignes un noyau Evenja, en plus des nombreux noyaux déjà existants, l'un des soucis étant qu'il faut démarrer autant de serveurs que de langages demandés. La version 3.0 devrait commencer à remédier à ce problème en proposant de choisir parmi les noyaux installés lors de l'ouverture d'un Notebook.

Multi-utilisateur

On ne parle pas encore de collaboration en direct, mais de la possibilité de démarrer un seul serveur pour de multiples utilisateurs dans un premier temps. Le but initial ne sera pas de permettre un déploiement pour des centaines d'utilisateurs simultanés, mais plus de l'ordre de grandeur d'un petit laboratoire de recherche, ou dans le cadre d'un enseignant utilisant le Notebook pour ses élèves. Cette fonction ne sera probablement pas complète pour la version 3.0 (été 2014), mais devrait, on l'espère, être utilisable pour 4.0 (hiver 2014).

Le reste Les réunions

Tous les jeudis, en direct sur youtube/Google Hangout vers 19h, réunion technique sur l'avancement du projet et le futur. Si vous voulez parler avec nous de votre projet d'amélioration, demandez une invitation.

Un mardi par mois, à 19h aussi, venez poser vos questions, on fera de notre mieux pour vous aider à faire ce que vous voulez avec IPython (en anglais, of course).

Nbviewer

Nbviewer a été déplacé de Heroku à Rackspace qui nous offre une réduction sur le prix des serveurs non négligeable, et Kyle Kelley s'occupe du déploiement ; si vous le croisez, lui ou Jesse Noller, remerciez-les !

Télécharger ce contenu au format Epub

Lire les commentaires

Blender annonce le projet Gooseberry de campagne de dons pour film libre

Vendredi 4 Avril

La Fondation Blender nous avait promis quelque chose de gros lorsqu'elle avait annoncé en 2011 son prochain projet de film libre, le projet Gooseberry. Aujourd'hui les ambitions se concrétisent et la fondation a mis en place une campagne de dons pour financer le projet.

Rétrospective

Depuis 2005, la Fondation Blender, organisation néerlandaise à but non lucratif développant le logiciel de modélisation 3D Blender, réalise et publie des films d'animation libres. Ces films ont pour but de faire connaître le logiciel Blender, de montrer ses possibilités, et d'aider à l'améliorer en ciblant plus précisément les attentes des infographistes.

Aujourd'hui, tous ces films partagent les caractéristiques suivantes :

  • ce sont des courts métrages, d'environ 10 à 15 minutes
  • ils sont sous licence libre CC BY
  • ils ont été réalisés avec Blender
  • ils ont été réalisés principalement avec des logiciels libres (ou uniquement avec des logiciels libres, si on exclut la partie audio)
  • les sources sont disponibles, sous licence libre si on exclut la partie audio
  • le nom de code du projet est toujours un nom de fruit, dont on voit une ou plusieurs représentations dans le film

Jusqu'à maintenant, quatre Open Movie Projects ont été réalisés :

  • Elephants Dream, ou projet Orange , annoncé en septembre 2005, publié en mars 2006 sous CC BY 2.5. Il dure 10min54 et a nécessité un budget de 120 000€.
  • Big Buck Bunny, ou projet Peach , annoncé en septembre 2007, publié en avril 2008 sous CC BY 3.0. Il dure 9min56 et a nécessité un budget de 150 000€.
  • Sintel, ou projet Durian , annoncé en mai 2009, publié en septembre 2010 sous CC BY 3.0. Il dure 14min48 et a nécessité un budget de 400 000€.
  • Tears of Steel, ou projet Mango , annoncé en octobre 2011, publié en septembre 2012 sous CC BY 3.0. Il dure 12min14 et a nécessité un budget de 300 000€.

À noter qu’un autre court-métrage libre a été publié en 2013 par la Fondation Blender, Gran dillama. Plus confidentiel, il est la suite du court-métrage LLama drama réalisé par ailleurs et qui n’est pas un Open Movie Project officiel.

Le projet Gooseberry

Le 10 janvier 2011, le cinquième Open Movie Project, le projet Gooseberry, a été annoncé. Il s'agira d'un long métrage qui devrait sortir en novembre 2015 sous licence CC BY 4.0.

La Blender Foundation place désormais la barre très haut : le film devrait durer aux alentours de 90 minutes, et sa réalisation nécessitera le travail à temps plein de 60 à 80 personnes, impliquera 12 studios de différents pays, et aura un budget minimal de 3,5 millions d'euros ! Cerise sur le gâteau, Ton Roosendaal, président de la Blender Foundation, compte pousser l'utilisation d'outils libres pour la réalisation de la partie audio du film, ce qui pourrait faire de ce film le premier Open Movie réalisé entièrement avec des logiciels libres !

Un scénario est déjà prêt : le film devrait être une comédie narrant les mésaventures de Michel le mouton.

Campagne de dons

Pour mener à bout ce projet ambitieux, la Fondation Blender fait appel à l'aide financière de la communauté. Le 9 mars 2014, une campagne de dons a été lancée, avec pour objectif de récolter 500 000 € et 10 000 souscriptions de « supporters » (personnes prêtes à donner 10 € par mois pendant les 18 mois de réalisation du film).

Les dons vont de 20 € à 2500 € et chaque option donne droit à un « cadeau » différent : une réduction de 20 € sur l'achat d'une copie physique du film, une mention plus ou moins voyante au générique de fin, et un accès au « Blender Cloud », plateforme mise en place par la Blender Foundation spécialement pour l'occasion. Le supporter du projet Gooseberry y trouvera une archive de tutoriels, de cours, de vidéos, d'artworks, de modèles 3D, enrichie au fur et à mesure de l'avancement du projet. Ces ressources seront d'abord disponibles sous CC BY-NC-SA 4.0, puis libérées sous CC BY 4.0 lors de la sortie du film.

La communauté pourra aussi avoir un aperçu de l'avancée du travail sur les blogs des équipes du projet, qui seront publiés sous CC BY et mis à jour régulièrement (le blog officiel du projet Gooseberry est déjà très actif).

Les 500 000 € récoltés via la campagne de don s'ajouteront aux fonds de la fondation Blender et à l'argent des sponsors pour permettre la réalisation du film. 70 % de l'argent sera consacré à la partie purement artistique du projet, 10 % servira à couvrir les frais divers et 20 % iront dans le développement logiciel.

Il est possible que la communauté soit invitée à participer un peu sur la partie artistique, comme ce fut le cas pour Sintel.

Et pour ceux qui ne savent pas ce qu'est une gooseberry c'est ça :

Télécharger ce contenu au format Epub

Lire les commentaires

Apéro Python à Lyon le mercredi 23 avril

Vendredi 4 Avril

Un apéro Python aura lieu à Lyon le mercredi 23 avril à partir de 20h à l'Antre Autre (11 rue Terme, Lyon 1er). Un AFPyro est un moment convivial où les Pythonistes peuvent échanger librement autour d’un verre ou d’une assiette.

Une présentation sur WTForms sera faite. WTForms est une bibliothèque permettant de faciliter la gestion des formulaires dans une application web.

Télécharger ce contenu au format Epub

Lire les commentaires

FusionDirectory 1.0.7.3 est sorti

Vendredi 4 Avril

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.

Correctif importants
  • Nettoyage de la fonctionnalité snapshot pour les rendre plus efficaces.
  • L'état de l'installation d'un machine avec FAI est à nouveau écrit correctement
  • Les fenêtres d'erreurs LDAP sont plus claire et on un style propre.
Correctifs mineurs
  • Déplacement de la vérification du 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'un cronjob pour le miroir Debian
Télécharger ce contenu au format Epub

Lire les commentaires

Repas du Libre à Toulouse le 10 avril 2014

Vendredi 4 Avril

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

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

Vendredi 4 Avril

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'import,
  • 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 bugs 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

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

Jeudi 3 Avril

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

OpenJDK 8, JEP 142 & False Sharing

Mercredi 2 Avril

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, la 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'infra 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 CPU é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 du CPU. Le pari étant qu'une fois l'accès couteux à la mémoire centrale effectué cette valeur va être réutilisée et on ira alors la chercher dans ce cache et donc gagner beaucoup beaucoup 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 CPU 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 CPU ou un coeur fait une modification elle sera visible par les autres. Chaque architecture à 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 "memory model". Charge au compilateur de traduire celui du langage vers celui de la plate-forme.

Si l'on met ces deux choses ensembles, on arrive au false sharing : deux variables théoriquement indépendantes se retrouvent sur la même ligne de cache. Chacune est accédée ou modifiée par un CPU distinct, cependant les CPU doivent passer leur temps à se synchroniser ce qui écroule les performances.

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

Exemple

Commençons avec un benchmark très simple: Une classe avec un seul membre ainsi que de 4 threads. Le premier lit en permanence la valeur de ce membre, les trois autres ne font rien. Le benchmark 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) { }

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 benchmark. Nous ajoutons un deuxième membre qui va être accéder par les trois threads qui
ne faisaient rien. Le premier thread 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 prendre un facteur 10.

Nous pouvons vérifier la disposition mémoire de notre objet StateBaseline avec jol pour voir que nos deux variables ont bien été collé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'ils 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 parait simple mais avant OpenJDK 8 cela demande de très sérieusement connaitre/lutter contre la VM.

Fort du principe de localité, le comportement logique de la VM est d'essayer d'entasser autant que possible les différents membres comme bon lui semble. Le layout d'un objet peut changer selon beaucoup de critères et l'utilisation d'un GC n'aide pas puisqu'il peut décider de déplacer un peu tout et n’importe quoi (notamment les tableaux utilisés pour padder). Bref trouver une stratégie qui marche, est une source d'amusement inépuisable. Aleksey Shipilёv en a documenté quelques-unes dans un benchmark 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 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 JVM. L'annotation se trouve dans un package privé d'Oracle et l'annotation n'est disponible que pour les classes du JDK par défaut (comme beaucoup de chose que le JDK se réserve précieusement). Si 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 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 leur outil ou avec perf mais ça reste assez empirique.

Si on garde le principe du false sharing en tête, cela permet de surveiller les mauvais patterns dans les bouts d'infrastructure qui peuvent être affectés. En général il faut que ça commence à aller sérieusement vite, donc structure de données dédiée, 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 threads différents. Ça arrive par exemple qu'en 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érerait être chacune être dans sa 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 fait travailler plusieurs threads en parallèle.

Le dernier cas est du calcul de type matriciel avec plusieurs threads. 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 fourni un tel exemple.

J’ai essayé de fournir quelques exemples dans le benchmark.

Conclusion

@Contended ne devrait pas changer la vie de grand monde hormis pour celle des gens qui pondent l’infra de service à haute performance. Mais elle ouvre la porte à une revendication de longue date : marier les bénéfices de la JVM 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 requises.

Cette annotation ne répond absolument pas au besoin de pouvoir contrôler le layout d’un objet ou de choisir quels membres d’un objet doivent être regroupés ensemble. Il 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’application qui passe en off-the-heap ou en mmap lorsque nécessaire.

Enfin le false sharing n'est pas le seul problème liés aux caches. Un autre exemple.
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

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

Mercredi 2 Avril

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

ADSILLH : Licence professionnelle administrateur et développeur

Mercredi 2 Avril

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édit 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'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éseaux 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

Sortie de Linux 3.14

Mardi 1 Avril

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 CPP (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 CPP 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 leur 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 addresse virtuelle à une addresse 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'a 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 après que le pilote Radeon ait 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

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

Mardi 1 Avril

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

Sortie de Clojure 1.6

Mardi 1 Avril

Le 25 mars, Clojure est sorti en version 1.6, l'occasion de se pencher un peu sur ce langage.

Clojure est un langage de programmation fonctionnel dérivé de Lisp tournant au-dessus de la Machine Virtuelle Java, des ports existant également pour Javascript et pour le Common Language Runtime de .NET.

Sommaire Présentation du langage

Conçu par Rich Hickey, et présenté pour la première fois en 2007, Clojure est un langage dont l'objectif est d'être une variante moderne de Lisp. S'il garde certaines des spécificités de cette famille de langages (considérer le code comme des données, ce qui permet notamment un usage sophistiqué de macros), il a comme particularité d'avoir une approche plus orientée vers la programmation fonctionnelle (décourageant l'utilisation de variables muables) et vers la concurrence. Par ailleurs, Clojure est conçu pour être en « symbiose » avec son hôte (dans la plupart des cas, la machine virtuelle Java) et permet d'utiliser facilement le code existant et de mêler au sein d'un même projet du code écrit en Java et en Clojure.

Installation

La manière la plus simple d'utiliser Clojure est d'utiliser Leiningen. Cet outil (en ligne de commande) permettra entre autres choses de récupérer les dépendances nécessaires (dont Clojure lui-même, qui prend la forme d'une bibliothèque Java), de créer l'arborescence pour un nouveau projet et de compiler ce projet.

Cet outil permet également (via lein repl) de lancer un REPL (Read-Eval-Print-Loop) qui permet de manipuler interactivement du code. Cf. le tutorial Clojurer des regexps avec Java, en Lisp :) qui présente un peu plus cet aspect-là.

Pour tester Clojure sans avoir à installer quoi que ce soit sur sa machine, il est également possible d'utiliser le site Try Clojure, qui fournit un REPL accessible par le web.

Un peu de syntaxe

La syntaxe de Clojure ne dépayesera pas les habitués de Lisp, ou de ses variantes.

(println "Hello, world !") ;; affiche "Hello, world !" (+ 2 2) ;; renvoie 4 (* 3 2) ;; renvoie 6

Clojure est dynamiquement typé : c'est au moment de l'exécution qu'on vérifie qu'une valeur est bien du type attendu. Comme le langage tourne sur la machine virtuelle Java, un certain nombre de types de base, comme les entiers ou les chaînes de caractères, viennent directement de Java, comme on peut le constater avec la fonction type :

(type 2) ;; renvoie java.lang.Long (type "Hello, world !") ;; renvoie java.lang.String

Un petit mot sur la syntaxe, directement héritée de Lisp. Dans tous les exemples ci-dessus, on construit, grâce aux parenthèses, une liste contenant un certain nombre d'éléments. Cette liste est ensuite évaluée, et le premier élément est interprété comme la fonction à appeler : dans le premier cas, println, dans les suivants + et * (qui ne sont pas considérés comme des caractères spéciaux). Les autres éléments de la liste correspondent aux arguments donnés à cette fonction.

Pour créer une liste, il suffit de demander à ce qu'elle ne soit pas évaluée, via quote, ou le caractère spécial ' :

(quote (1 2 3 4 5)) ;; renvoie (1 2 3 4 5) '(1 2 3 4 5) ;; identique

C'est le principe fondateur de Lisp (le nom Lisp vient de LISt Processing) : le code est constitué de données, c'est à dire que tout le code qu'on écrit est en réalité constitué de listes qui vont être évaluées. Il s'agit d'une structure assez simple, celle de liste simplement chaînée, sur laquelle on peut effectuer un certain nombre d'opérations basiques :

  • (cons x une-liste) ajoute l'élément x au début de la liste une-liste ;
  • (first une-liste) retourne le premier élément d'une-liste (correspond à car dans Lisp) ;
  • (rest une-liste) retourne une liste comprenant tous les éléments d'une-liste, sauf le premier (correspond à cdr dans Lisp).

Quelques exemples :

(def une-liste '(1 2 3 4 5)) ;; définit une variable, une-liste, contenant (1 2 3 4 5) (first une-liste) ;; renvoie 1 (rest une-liste) ;; renvoie (2 3 4 5) (cons 0 une-liste) ;; renvoie (0 1 2 3 4 5) Particularités de Clojure Structures de données

En Lisp, la liste est donc la structure hégémonique que l'on retrouve partout et qui est l'élément de syntaxe principal du langage (les fameuses parenthèses). Clojure garde le même principe, mais avec quelques nuances. Ainsi, pour déclarer une fonction :

(defn doubler [x] (* 2 x)) (doubler 2) ;; renvoie 4

Les crochets autour des paramètres de la fonction (en l'occurrence, x) ont une signification bien particulière : ils indiquent qu'il ne s'agit pas d'une liste ordinaire, mais d'un vecteur. Clojure se différencie en effet de son aîné en proposant « en dur » d'autres structures de données, comme les vecteurs : 

[1 2 3 4]

À première vue, un vecteur peut ne pas sembler très différent d'une liste, mais accéder à un élément ou en ajouter un n'ont pas les mêmes impacts en termes de performances :

  • avec une liste, il est possible d'accéder au premier élément ou d'ajouter un élément en début de liste en temps constant, mais pour accéder au n-ième élément il faudra parcourir la liste depuis le début ;
  • à l'inverse, avec un vecteur, il est possible d'accéder à n'importe quel élément avec un temps constant ; avec l'implémentation de Clojure, il en est de même pour ajouter un élément à la fin du vecteur.

Clojure fournit également une syntaxe pour les ensembles :

#{"bleu" "rouge" "vert"}

ainsi que pour les dictionnaires :

{1 "bleu" 2 "rouge" 3 "vert"} Un accent sur l'immuabilité

À première vue, ces ajouts peuvent être vus comme du simple sucre syntaxique, puisque ces structures de données peuvent également être créées par l'appel à des fonctions, repectivement :

(vector 1 2 3 4) ;; crée un vecteur (set '("bleu" "rouge" "vert")) ;; crée un ensemble (array-map 1 "bleu" 2 "rouge" 3 "vert") ;; crée un dictionnaire

Cependant, l'intérêt de ces structures n'est pas uniquement d'avoir du code comportant un peu moins de parenthèses et plus de caractères différents. Leur particularité est qu'à l'instar des listes, ces structures de données sont persistantes. Clojure met en effet un fort accent sur l'immuabilité. Par exemple, pour ajouter une valeur à un vecteur, plutôt que de modifier le vecteur lui-même, on va créer un nouveau vecteur, via la fonction conj :

(def mon-vecteur [1 2 3 4]) (conj mon-vecteur 5) ;; renvoie [1 2 3 4 5] mon-vecteur ;; contient toujours [1 2 3 4]

Si garantir cette immuabilité pour toutes les structures de données du langage a un coût (en termes de performances), cela présente un certain nombre d'avantages, notamment en programmation concurrente : en n'utilisant que des variables immuables, on n'a pas à se soucier de ce qui peut arriver si un autre thread modifie les données sur lesquelles on est en train de travailler.

Bien entendu, il est parfois indispensable qu'une variable puisse être modifiée. Clojure fait le choix de proposer plusieurs solutions pour ce cas, en fonction des besoins (en terme de concurrence et de parallélisme). Ainsi, si modifier une variable par le biais du mot-clé def n'entraînera un changement qui ne sera visible qu'à l'intérieur du même thread, il existe également atom, agent et ref qui permettent de partager des données entre plusieurs threads, avec des mécanismes un peu différents :

  • atom s'assure simplement, comme son nom l'indique, d'une modification atomique de la variable, garantissant qu'elle soit toujours dans un état cohérent. C'est notamment utile lorsqu'une modification de cette variable n'a pas à être coordonnée avec la modification d'autres variables ;
  • ref permet une modification coordonnée de plusieurs variables, de manière synchrone ;
  • agent permet une modification coordonnée de plusieurs variables, de manière asynchrone.
Du sucre syntaxique

Clojure fournit également du sucre syntaxique pour permettre une utilisation plus facile de ces structures de données. Ainsi, vecteurs comme dictionnaires peuvent être utilisés comme des fonctions, renvoyant la valeur correspondant au paramètre qui leur est passé :

(def v [1 2 3 4]) (def d {1 "bleu" 2 "rouge" 3 "vert"}) (v 2) ;; renvoie 3 (d 1) ;; renvoie "bleu"

En ce qui concerne les dictionnaires, leurs clés correspondent souvent à des mots-clés, des identifiants commençant par le caractère :. Il est également possible d'utiliser ces mots-clés en guise de fonction, afin d'obtenir la valeur correspondante dans le dictionnaire passé en argument :

(def point {:x 3 :y 4}) (:x point) ;; renvoie 3

Un autre élément de syntaxe intéressant pour accéder au contenu d'une structure de données est la déstructuration, qui permet de lier des variables à un élément d'une structure plutôt qu'à son ensemble. Par exemple, si l'on désire créer une fonction affiche-point qui prend en paramètre un vecteur contenant l'abscisse et l'ordonnée, plutôt que d'accéder manuellement au premier et au second élément du vecteur, on peut écrire le code suivant :

(defn affiche-point [[x y]] (println "Coordonnées :" x ";" y)) (affiche-point [4 2]) ;; affiche "Coordonnées : 4 , 2"

Cette déstructuration fonctionne pour les listes et les vecteur, mais également pour les dictionnaires.

Interopérabilité avec Java

Un atout de Clojure est son interopérabilité avec Java, qui lui permet d'utiliser les multiples bibliothèques existantes. Cela se fait très simplement : (classe. parametres) crée une nouvelle instance de la classe, tandis qu'on accède à une méthode ou à un attribut public en faisant (.methode objet). Un exemple concret, pour afficher une fenêtre via la biblièthèque Swing :

(import '(javax.swing JFrame JLabel)) ;; importe JFrame et JLabel (def frame (JFrame. "Hello !")) ;; JFrame frame = new JFrame ("Hello !"); (def label (JLabel. "Hello, world !")) ;; JLabel label = new JLabel ("Hello, world !"); (.add (.getContentPane frame) label) ;; frame.getContentPane().add(label) (.pack frame) ;; frame.pack () (.setVisible frame true) ;; frame.setVisible (true)

La macro proxy permet également de créer des objets étendant des classes ou implémentant des interfaces. Pour rester dans l'interface graphique, si l'on veut que le programme affiche "Plop !" lorsqu'on clique sur un bouton :

(def button (javax.swing.JButton. "Plop")) ;; crée le bouton (.addActionListener button (proxy [java.awt.event.ActionListener] [] (actionPerformed [e] (println "Plop !")))) ;; on implémente la méthode actionPerformed de l'interface ActionListener Pas (vraiment) de modèle objet

Hormis les mécanismes d'interopérabilité évoqués ci-dessus, Clojure ne met pas en avant de mécanisme pour faire de la programmation objet au sens strict du terme. Cependant, il existe un certain nombre d'outils permettant d'obtenir sensiblement le même type de fonctionnalités, notamment en terme de polymorphisme.

L'un de ces outils est la notion de protocoles, similaires aux interfaces en programmation objet. Un protocole va en effet définir un certain nombre de fonctions s'appliquant aux éléments d'un type donné. Par exemple, pour définir un protocole contenant une seule fonction, doubler :

(defprotocol Doubler (doubler [this]))

Il est ensuite possible d'implémenter ce protocole, soit pour de nouveaux types (voir ci-dessous), soit pour des types existants. Par exemple, si on veut implémenter ce protocole pour les nombres et les chaînes de caractères :

(extend-protocol Doubler java.lang.Number (doubler [x] (* 2 x)) java.lang.String (doubler [x] (str x x))) (doubler 21) ;; renvoie 42 (doubler "coin") ;; renvoie "coincoin"

En complément des protocoles, Clojure fournit également un outil pour créer de nouveaux types : defrecord (il existe également deftype, un peu plus bas niveau). Cela crée concrètement une classe Java contenant les attributs passés en paramètres, tout en permettant une utilisation similaire à celle des dictionnaires :

(defrecord Surface [longueur largeur]) (def s (Surface. 2 2)) ;; On crée un nouvel objet de la classe Surface (.longueur s) ;; On peut accéder aux attributs en utilisant les méthodes d'interopérabilité Java... (:largeur 2) ;; ... ou comme s'il s'agissait de clés pour un dictionnaire

Il est possible, lors de la création d'un nouveau record, d'implémenter directement certaines interfaces :

(defrecord Surface [longueur largeur]) Doubler (doubler [this] (Surface. (* 1.41 longueur) (* 1.41 largeur)))) (def s (Surface. 2 2)) (:longueur (doubler s)) ;; -> renvoie 2.82

Les protocoles permettent donc une forme de polymorphisme assez similaire aux interfaces ou à l'héritage dans la programmation orientée objet. Le choix de la méthode à appeler en fonction du type de l'objet (single dispatch) n'est pas toujours optimal, et il est parfois utile d'avoir un choix de la méthode à appeler qui puisse être arbitraire (multiple dispatch). Pour cela, Clojure fournit également un mécanisme, les multiméthodes.

Changements apportés par la version 1.6

La version 1.6 de Clojure apporte peu de réelles nouveautés, le langage ayant maintenant acquis une certaine maturité. Un certain nombre de fonctionnalités qui étaient auparavant considérées comme alpha ont été « promues » et sont donc maintenant considérées comme stables, notamment :

  • la création de types via defrecord ou deftype ;
  • les transients (permettant de considérer une variable immuable comme muable tant que c'est au sein de la même fonction) ;
  • les watches, permettant d'appeler automatiquement une fonction lorsqu'une variable est modifiée ;
  • les promises, qui permettent de ne pas bloquer le thread à la création de la variable, mais uniquement lorsqu'elle est lue.

Au rang des nouveautés, cette version fournit des interfaces minimales pour permettre l'accès à Clojure depuis d'autres langages tournant sur la machine virtuelle Java. Elle propose également quelques fonctions supplémentaires (some?, if-some et when-some) destinées à simplifier l'écriture d'expressions conditionnelles courantes. Sinon, la majorité des changements concerne des améliorations de mécanismes existants (comme la déstructuration, ou les mécanismes de hachage utilisés par un certain nombre de structures de données), sans compter de nombreuses corrections de bugs.

On notera également que Clojure requiert dorénavant Java 6 (ou supérieur), tandis que la version précédente (mais pas toutes les bibliothèques) pouvait encore tourner sur la version 5 de Java.

Un certain nombre de développements intéressants concernant Clojure ont lieu en dehors du cœur même de Clojure. Il existe notamment un certain nombre de projets pour compiler du code Clojure vers d'autres plate-formes. Parmi ceux-ci, ClojureScript, le compilateur Clojure pour le langage javascript, a acquis une certaine stabilité et une relative popularité. Dans un autre registre, le projet Typed Clojure vise à ajouter un typage statique optionnel, à l'instar de ce qui se fait pour d'autres langages typés dynamiquement.

Télécharger ce contenu au format Epub

Lire les commentaires

Atelier préparation aux LPIC

Lundi 31 Mars

Dans le cadre de ses formations bi-mensuelles, l'association StarinuX vous convie à l'atelier « Préparation aux certifications du Linux Professional Institute » le samedi 26 avril 2014. L'atelier est animé par Marc Baudoin, professeur à l'ENSTA, membre-enseignant agréé LPIC en France et reconnu comme excellent pédagogue.

Tous les détails en seconde partie!

Préparation aux certifications du Linux Professional Institute (LPIC)

Les LPIC comportent six examens :

  • 101-102 : maîtriser Linux, les commandes Gnu et Unix, installer les paquetages, configurer le système ;
  • 201-202 : compiler le noyau, personnaliser le système en réseau et serveur ;
  • 301-302 : en cours…

Chaque examen coûte environ 150 €, il faut donc bien s'y préparer pour ne pas le rater. Si vous avez déjà un niveau GNU/Linux correct, multipliez vos chances de réussir les LPIC qui démontreront immédiatement votre compétence sous GNU/Linux aux entreprises !

Objectif
  • Constater votre niveau et celui requis pour passer les LPIC ;
  • acquérir les bons réflexes pour aborder les examens dans de bonnes conditions ;
  • obtenir les informations techniques et "les ficelles" pour réussir l'examen.
Programme
  • Présentation du LPI ;
  • cours sous forme de nombreux tests ;
  • passage des tests 101-102 ;
  • évaluation des auditeurs sur leur niveau : s'inscrire directement à l'examen, suivre encore un cours ou attendre…
Les infos pratiques
  • Lieu : 74 rue Roque de Fillol 92800 Puteaux (RER la Défense ou métro ou Esplanade de la Défense ou Pont de Neuilly ligne 1) ;
  • Date : samedi 26 avril 2014 de 9h00 à 18h00 ;
  • Restauration : boissons, micro-ondes sur place, restaurants / alimentation à côté.
  • S'informer et s'inscrire : www.starinux.org/ateliers-sx.php

Une participation de 15 € (7,5 € pour les demandeurs d'emploi) est demandée, permettant de suivre plus de 12 autres ateliers pendant un an.

Télécharger ce contenu au format Epub

Lire les commentaires

Apéro du libre XXL à Rennes le jeudi 3 avril

Lundi 31 Mars

L'association Actux vous invite à un nouvel Apéro du Libre, jeudi 3 avril 2014 à partir de 19h au Papier Timbré, au 39 rue de Dinan à Rennes.

L'apéro du libre est une rencontre conviviale autour d'un verre, pour discuter et faire connaissance entre utilisateurs de Logiciels Libres, débutants ou confirmés. Pour fêter le printemps cet apéro s'inscrit dans le cadre de Libre en Fête et sera un apéro XXL avec quelques animations qui ponctueront la soirée.

Pour rappel, cet évènement a lieu habituellement tous les premiers jeudis du mois, même heure, même endroit, et est ouvert à tous !

Télécharger ce contenu au format Epub

Lire les commentaires

Docker : Tutoriel pour manipuler les conteneurs

Dimanche 30 Mars

Docker (présenté ici-même la semaine dernière) est un logiciel à mi-chemin entre la virtualisation applicative et l'automatisation.
Il a l'avantage de ne virtualiser que la partie application et pas du tout la partie système ni le noyau.
Il étend le principe des conteneurs Linux (LXC).

Dotcloud qui développe Docker, propose aussi un système minimaliste (CoreOS) pour héberger et hyperviser les conteneurs.

Installation (Debian/Ubuntu)

Créer le fichier /etc/apt/sources.list.d/docker.list et écrire ça dedans :

deb http://get.docker.io/ubuntu docker main

Télécharger la clé GPG et installer le package :

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9 apt-get update apt-get install lxc-docker Manipulation d'images

Prendre une Debian sur le dépôt officiel de Docker et se connecter dessus

docker pull debian docker run -i -t debian /bin/bash Faire tout ce qu'on veut sur la nouvelle image root@xxxxxx# ... Et sauvegarder les changements root@xxxxxx# exit docker commit xxxxxx le_nom_de_l_image Supprimer les images : docker rmi id_ou_nom_de_l_image Création d'images par Dockerfile

Les principales directives des fichiers Dockerfiles :

MAINTAINER : nom et courriel de mainteneur du conteneur
FROM : image de base (ubuntu, debian)
VOLUME : point de montage
RUN : commande à exécuter pour installer le conteneur.
ENTRYPOINT : commande qui s'exécute au démarrage du conteneur (une seule sera exécutée).
CMD : commande qui s'exécute au démarrage du conteneur.
ADD : copier un fichier du répertoire courant dans le système de fichiers du conteneur.
USER : utilisateur qui exécute les commandes dans le conteneur.
EXPOSE : port(s) à exposer à l'extérieur.

Manipuler un conteneur JOB1=$(docker run -d conteneur) docker logs $JOB1 docker stop $JOB1 Voir les conteneurs qui tournent : docker ps

ou

docker ps -a Supprimer un conteneur / supprimer tous les conteneurs : docker rm $JOB1 docker rm id_du_conteneur docker rm `docker ps -a -q` Construire un conteneur

Créer un fichier nommé Dockerfile avec les directives Docker puis :

docker build -t nom_du_conteneur . Exemple de Dockerfile : LAMP - MariaDB Dockerfile # lamp (d'un M qui veut dire Maria) # Pour Debian Wheezy # # VERSION 0.0.1 # FROM debian:wheezy MAINTAINER Nico Dewaele "nico@adminrezo.fr" ENV DEBIAN_FRONTEND noninteractive # Depots, mises a jour et installs de Apache/PHP5 RUN echo "deb http://ftp.fr.debian.org/debian/ wheezy main non-free contrib" > /etc/apt/sources.list RUN (apt-get update && apt-get upgrade -y -q && apt-get dist-upgrade -y -q && apt-get -y -q autoclean && apt-get -y -q autoremove) RUN apt-get install -y -q vim ssh supervisor python-software-properties apache2 libapache2-mod-php5 php5-cli php5-mysql # Installation et configuration de MariaDB RUN apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db RUN add-apt-repository 'deb http://mirrors.linsrv.net/mariadb/repo/5.5/debian wheezy main' RUN apt-get update && apt-get install -y mariadb-server RUN service mysql start RUN mysql -v -uroot -e'UPDATE user SET host = "%" WHERE user = "root" LIMIT 1; DELETE FROM user WHERE user = "root" AND host != "%"' mysql RUN service mysql stop # Config de Apache ADD foreground.sh /etc/apache2/foreground.sh ENV APACHE_RUN_USER www-data ENV APACHE_RUN_GROUP www-data ENV APACHE_LOG_DIR /var/log/apache2 # Verification de PHP ADD index.php /var/www/index.php #RUN rm /var/www/index.html # Demarrage des services RUN mkdir -p /var/log/supervisor ADD supervisord.conf /etc/supervisor/conf.d/supervisord.conf ADD start.sh /start.sh EXPOSE 80 22 # Si MariaDB doit être exposée à l'extérieur # EXPOSE 3306 CMD ["/bin/bash", "-e", "/start.sh"] foreground.sh #!/bin/bash read pid cmd state ppid pgrp session tty_nr tpgid rest < /proc/self/stat trap "kill -TERM -$pgrp; exit" EXIT TERM KILL SIGKILL SIGTERM SIGQUIT source /etc/apache2/envvars apache2 -D FOREGROUND start.sh #!/bin/bash supervisord supervisord.conf [supervisord] nodaemon=true [program:sshd] command=/usr/sbin/sshd -D stdout_logfile=/var/log/supervisor/%(program_name)s.log stderr_logfile=/var/log/supervisor/%(program_name)s.log autorestart=true [program:httpd] command=/usr/sbin/apache2ctl start stopsignal=6 [program:mariadb] command=/usr/sbin/mysqld stdout_logfile=/tmp/%(program_name)s.stdout stderr_logfile=/tmp/%(program_name)s.stderr stopsignal=6Télécharger ce contenu au format Epub

Lire les commentaires

Pages