Linux France

S'abonner à flux Linux France
Mis à jour : il y a 12 min 6 sec

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

Jeudi du libre le 3 avril à Lyon : Firefox OS

Dimanche 30 Mars

De nos jours, la plupart des gens se promènent avec un smartphone dans la poche (NdM : a priori il est question de la France ici ; voir des chiffres de vente et de marché du smartphone en France par exemple). Bien plus qu'un téléphone, cet appareil nous permet d'accéder à internet, d'écouter de la musique, lire nos courriels, consulter nos comptes et bien d'autres choses encore !

Ce compagnon étant devenu pratiquement indispensable, la question du système d'exploitation doit nécessairement être posée. À l'heure actuelle, Android semble être le seul système libre disponible sur le marché (bien que son côté libre fasse souvent débat). Pourtant d'autres systèmes libres apparaissent, comme Ubuntu Phone et Firefox OS.

Ce jeudi du libre de l'ALDIL vise à présenter Firefox OS, système développé par la fondation Mozilla (le programme est en seconde partie).

Comme d'habitude, cela se passe à la Maison Pour Tous - salle des Rancy le jeudi 3 avril à 19h30, au 249 rue Vendôme - 69003 LYON (Métro Saxe Gambetta).

Le programme

L'intervenant aura l'occasion de répondre à de multiples questions telles que :

  • Pourquoi choisir un appareil sous Firefox OS ?
  • Quelles sont les valeurs défendues par la fondation à l'origine de ce système ?
  • Comment Firefox OS fonctionne ?
  • Quelles sont les différences par rapport aux autres systèmes, notamment Android ?
  • Comment en profiter ?
  • Où trouver des périphériques le proposant et à quel prix ?
Le conférencier

Fabien Bourgeois est membre de plusieurs associations du libre dont l'ALDIL. Dans sa vie professionnelle, il est concepteur d'applications Web. Il a décidé d'utiliser au quotidien un téléphone sous Firefox OS dès que les premiers modèles ont été disponibles en Europe. Ce n'est pas un spécialiste de Firefox OS mais un utilisateur classique, qui souhaite simplement partager son expérience.

Lieu

La conférence a lieu à la Maison Pour Tous / Salle des Rancy à partir de 19h30.

Maison pour Tous — Salle des Rancy
249 rue Vendôme
69003 Lyon
(Métro Saxe Gambetta)

Télécharger ce contenu au format Epub

Lire les commentaires

1flow — plateforme libre pour l'information

Vendredi 28 Mars

1flow est un outil de veille libre, pour rester informé et convertir l'information en action. C'est une application web responsive qui assure l'agrégation (flux RSS et bientôt sociaux), la lecture (récupération des contenus complets et conversion plein-texte à la volée) et l'import / stockage de contenus numériques (PDF, vidéos, images…). À destination d'un public averti mais non-informaticien, son interface est épurée (regardez la vidéo d'introduction de 2 min).

Nous cherchons à monter une équipe d'utilisateurs contributeurs (développeurs ou non) pour tester et renforcer le projet. Plus de détails en seconde partie.

Après un an de développements en interne à l'issue duquel nous devions fonder une société avec un modèle type freemium, nous avons pivoté pour des raisons hors-sujet de cette dépêche, et libéré le code source sous licence GNU AGPLv3, puis ouvert la gestion du projet pour faire de 1flow un bien commun (qui s'inscrit dans http://unisson.co/).

Je (Olivier, développeur à l'origine du projet, impliqué dans le libre depuis 1996) continue les développements et souhaite financer 1flow par un modèle participatif et durable de l'économie du don (pourquoi (en anglais) ?). Matthieu (co-fondateur) contribue au projet avec des contenus (vidéos, dessins, textes) et une promotion hors-pair dans le milieu grand-public non sensibilisé au logiciel libre.

Nous cherchons à monter une équipe d'utilisateurs contributeurs (développeurs ou non) pour renforcer le projet. Les utilisateurs non-contributeurs sont aussi les bienvenus mais comme la plateforme est hébergée sur nos fonds propres, les inscriptions sur http://1flow.io/ sont limitées pour l'instant à ceux qui souhaitent s'impliquer.

Cependant, 1flow est aussi installable chez soi, car un des objectifs à long terme est de construire une toile de confiance pour le stockage distribué de l'information. La première étape est de stresser la procédure d'installation et la valider sur différents environnements, et pour cela nous avons besoin de votre aide.

Concrètement, bien qu'il reste beaucoup de travail pour arriver à l'outil complet tel que nous l'avons imaginé (de la lecture à l'écriture en passant par le partage), 1flow est largement utilisable et très stable, donc il y a déjà un réel intérêt à l'installer chez soi. La plateforme est mise à jour continuellement avec de nouvelles fonctionnalités ou des corrections.

En espérant vous accueillir nombreux, je vous souhaite une très bonne journée !

Télécharger ce contenu au format Epub

Lire les commentaires

Leslie Lamport, prix Turing 2013

Vendredi 28 Mars

Le prix Turing récompense des chercheurs en informatique qui posent des bases sur lesquelles s’appuient non seulement leurs successeurs, mais aussi chacun d’entre nous. Cette année, c’est Leslie qui Lamport (© Shuba) pour ses contributions fondamentales à la théorie et la pratique des systèmes répartis et concurrents, notamment l’invention de concepts tels que la causalité et les horloges logiques, la sûreté et la vivacité, les machines à états réparties, et la cohérence séquentielle.

La suite en seconde partie.

Sommaire À la baguette

Utilisez-vous un système qui exploite plusieurs programmes¹ ? Lorsque plusieurs processus s’exécutent simultanément, ils peuvent avoir besoin d’accéder à un même emplacement de mémoire. Tant qu’ils ne font que lire son contenu, il n’y a pas de problème, mais s’ils veulent le modifier, on ne peut pas les laisser le faire n’importe comment sous peine de voir arriver dans cette zone de mémoire une valeur imprévue. C’est pour résoudre ce problème, appelé exclusion mutuelle, que Lamport a publié l’algorithme de la boulangerie, première solution ne nécessitant pas d’assistance de la part du matériel. De nombreuses solutions à ce problème existent de nos jours, chacune adaptée à un contexte bien particulier.

Coucou !

Prenons maintenant un peu de recul et considérons plusieurs programmes sur des machines différentes reliées en réseau. Nous avons maintenant un nouveau problème, car le temps de communication entre les machines, ajouté à l’inévitable décalage entre leurs horloges internes, rend difficile de dire dans quel ordre leurs opérations se sont produites. De Kevin ou de Jean-Édouard, qui a tiré le premier dans leur partie de Half-Halo² ? L’insertion de la valeur 42 dans la liste d’entiers partagée est-elle arrivée avant ou après l’instruction demandant de supprimer toutes les valeurs paires ? Avec une horloge logique, ce genre de questions prend un nouveau sens. Introduite par Lamport pour donner une fondation au concept de temps dans un système réparti, elle ne fait aucune référence au temps réel (celui de la pendule) et permet de raisonner en termes de causalité. Dans ce modèle, un évènement peut arriver avant un autre (par exemple, si A est l’émission d’un message et B sa réception, A est arrivé avant B) ou deux évènements peuvent être indépendants. Différents types d’horloges logiques existent aujourd’hui, qui donnent plus ou moins d’information sur la relation de causalité dans le système réparti (plus l’information est complète, plus le mécanisme de mise à jour des horloges logiques nécessite d’échanger des messages volumineux).

Le petit oiseau va sortir

Il est clair, à ce stade, qu’un système réparti est un sac de nœuds dans lequel il est difficile de mettre de l’ordre. Par exemple, savoir dans quel état se trouve le système à un moment donné est évidemment impossible. Ou pas. Plus précisément, si on ne peut pas obtenir l’état du système à un instant t (à la pendule), il est tout de même possible d’en obtenir une représentation cohérente (par exemple, dans cette représentation, si B a reçu le message M de A, alors A a envoyé le message M à B). L’algorithme du cliché distribué de Chandy et Lamport fournit une solution à ce problème essentiel puisque sans cela, on ne pourrait pas savoir si le système a atteint un état satisfaisant les conditions attendues (autrement dit, si le système a bien calculé ce qu’on voulait lui faire calculer).

Et pourtant il faut vivre…

Plus largement, on aimerait bien pouvoir raisonner sur les systèmes répartis avec des outils logiques similaires à ceux que l’on utilise sur les algorithmes classiques afin de prouver leur correction. Ceci nécessite un nouvel outil : la logique temporelle, sur laquelle Lamport a beaucoup travaillé. Elle est basée sur deux types de propriétés la combinaison de propriétés de sûreté (A est toujours vrai) et de vivacité (B deviendra vrai dans le futur, on ne sait pas quand). En d’autres termes, une propriété de sûreté indique qu’une mauvaise chose n’arrivera jamais et une propriété de vivacité indique qu’une bonne chose finira par arriver. Toute propriété d’un système réparti peut être exprimée comme une combinaison de propriétés de sûreté et de vivacité. On doit à Lamport la logique TLA (Temporal Logic of Actions), le langage de spécification TLA+ et le langage algorithmique PlusCal, basés sur ces concepts et accompagnés d’outils open source (licence MIT).

Au commencement fut Chaos

Jouons un peu avec nos processus. Ils ont chacun un programme, auquel on ne touche pas, et une mémoire contenant des variables. Écrivons maintenant n’importe quoi dans ces variables. Que se passe-t-il ? Sans doute rien de bon. Sauf peut-être si l’auteur du programme s’appelle Dijkstra, qui a introduit l’autostabilisation en informatique. Son article de 1974 donne quelques programmes capables, après une période de convergence, de fonctionner malgré ces conditions radicales : essentiellement, ils sont capables de récupérer après n’importe quelle défaillance, au prix d’un manque de sûreté (on parle alors plutôt de sûreté inéluctable : on aura des propriétés de sûreté, mais on ne sait pas quand).

Ce résultat avait amusé quelques chercheurs à l’époque, puis était retombé dans l’oubli jusqu’à une présentation de Lamport, dix ans plus tard. Intitulée Solved Problems, Unsolved Problems and NonProblems in Concurrency, elle fait le point sur l’état de l’art dans ce domaine et, entre autres, déterre l’article de Dijkstra, suscitant l’intérêt d’autres chercheurs, ce que Lamport considère comme une de ses plus importantes contributions à l’informatique.

Les généraux byzantins

Constantinople, IXe siècle. Les 101 généraux dalmatiens de l’armée byzantine doivent repousser l’envahisseur. Mais leurs troupes de Macédoine risquent de mal se mélanger, et donc d’attaquer sans se concerter. Les généraux doivent pourtant se mettre d’accord pour attaquer ou non. Cependant, certains d’entre eux sont des traîtres qui n’hésiteront pas, par exemple, à s’allier de façon à faire croire à un autre général que l’attaque est décidée pour la seule raison de l’envoyer tout seul au casse-pipe.

Ce problème se retrouve en informatique dans un système comportant plusieurs processeurs dont certains fonctionnent mal, un type de défaillance plus pervers que l’arrêt définitif car beaucoup plus difficile à détecter. Un mauvais fonctionnement peut être dû à un défaut de fabrication, mais aussi à de mauvaises conditions (chaleur, rayons cosmiques…). Le problème des généraux byzantins est donc un bloc de construction fondamental pour la mise au point de tout système dans lequel une défaillance peut avoir des conséquences graves. Lamport, Pease et Shostak en ont apporté les premiers éléments théoriques : la preuve que le problème n’est résoluble que si le nombre de traîtres est strictement inférieur au tiers de l’effectif, ou à la moitié si des signatures numériques sont utilisées, et les algorithmes correspondants.

Le parlement à temps partiel³

Reprenons le consensus, cette fois en présence de défaillances par arrêt définitif et dans un système asynchrone, c’est-à-dire qu’aucune condition n’est imposée sur le temps de transmission des messages. Un petit détail technique chagrine les chercheurs dans ce domaine : ce problème est insoluble (théorème de Fischer, Lynch et Paterson 1985). Comme la recherche ne s’arrête pas pour si peu, de nombreux algorithmes existent pour résoudre le consensus dans des conditions proches de l’asynchronisme. On doit à Lamport l’algorithme (ou, si on préfère, le concept duquel on peut tirer des algorithmes) de Paxos, dans lequel le système reste toujours cohérent et qui garantit la progression vers le consensus dès lors qu’une majorité des processus fonctionnent correctement. Cet algorithme est également connu pour la mise en scène de son auteur sur le thème d’une cité grecque fictive, avec des présentations en costume d’archéologue, et par son utilisation par Google dans Chubby, dont dépendent notamment le Google File System et BigTable. Plusieurs versions étendues ont été proposées, dont une qui résout le consensus byzantin.

Fenêtres sur cours

Lamport est employé par Microsoft Research, ce qui ne signifie pas qu’il travaille sur la prochaine version de Windows. Ce francophone est membre du laboratoire INRIA-Microsoft de Palaiseau, dans l’Essonne, et collabore régulièrement avec des chercheurs français qui participent à la formation des futures générations d’informaticiens qui sauront, grâce à Lamport, qu’un système réparti est un système dans lequel la défaillance d’un ordinateur dont vous ne saviez même pas qu’il existait peut rendre le vôtre inutilisable.

¹Et sinon, comment êtes-vous arrivé sur linuxfr ?
²D’accord, mauvais exemple : on sait que c’est Han Solo qui a tiré le premier.
³Ceci n’est pas un appeau à trolls politiques.

Télécharger ce contenu au format Epub

Lire les commentaires

Java 8 et NetBeans 8 sont disponibles

Vendredi 28 Mars

Oracle a annoncé la mise à disposition de la nouvelle version standard de Java, la 8. Deux ans et sept mois après Java 7, la publication de cette nouvelle version a été retardée afin d'améliorer la sécurité.

Et pour permettre d'exploiter au mieux ce nouveau JDK, une nouvelle version de l'environnement de développement NetBeans est également disponible et porte le même numéro. Côté Eclipse, un patch est proposé et concernant IntelliJ, Java 8 est pris en charge dans la version 13.1 sortie la semaine dernière.

Ces deux sorties marquent la volonté d'Oracle de convaincre les développeurs.

Sommaire Nouveautés Java 8 Les lambdas

C'est une technique pour écrire des fonctions qui ne sont pas nommées et directement définies là où elles sont appelées. Cela permet une écriture plus simple pour les fonctions qui ne sont appelées qu'à un seul endroit du code. L'exemple classique est pour définir une fonction de tri :

public class Users { public String username; public int karma; /** * Sort users by karma */ public static void sortUser(Users[] users) { Arrays.sort(users, (Users u1, Users u2) -> { return u1.karma - u2.karma; }); } }

Avant l'introduction des lambdas, dans cet exemple il fallait définir une implémentation pour Comparator, ce qui était un peu plus verbeux :

public class Users { public String username; public int karma; /** * Sort users by karma */ public static void sortUser(Users[] users) { Arrays.sort(users, new Comparator<Users>() { @Override public int compare(Users u1, Users u2) { return u1.karma - u2.karma; } }); } } Interfaces fonctionnelles (FunctionalInterface)

Pour implémenter les lambdas le langage s'appuie sur les interfaces fonctionnelles, c'est-à-dire des interfaces possédant une seule méthode abstraite. Toutes les interfaces respectant cette condition sont de fait des interfaces fonctionnelles. Toutefois, il est possible d'utiliser l'annotation @FunctionalInterface pour qu'une erreur soit levée si une interface ne respecte plus cette condition.

API Stream

L'API Stream a été ajoutée, permettant de représenter des données sous forme de flux et de les manipuler de manière efficace. Cette API s'appuie largement sur les lambdas expressions décrites plus haut.

Les habitués des pipes du shell (il y en a par ici ? :), des langages fonctionnels et de certains autres comme Perl ne devraient pas être trop dépaysés par cette manière de programmer.

Voici un exemple sorti de la documentation officielle :

int sum = widgets.stream() .filter(b -> b.getColor() == RED) .mapToInt(b -> b.getWeight()) .sum();

Ici widgets est une Collection<Widget>, mais cette API peut être utilisée avec toute sorte de flux de données comme des fichiers ou des sockets. Il est aussi possible de créer ses propres types de stream.

Enfin, il est possible de paralléliser les traitements sur ces flux de manière simple (plus simple que gérer des Threads).

Nashorn, JavaScript dans Java

Java inclut désormais un nouveau moteur JavaScript qui remplace le vieillissant Rhino. Il permet donc d'invoquer du code JavaScript directement dans le code Java. Il est évidemment possible d'interagir avec le code Java en appelant du code Java en JavaScript ou même en étendant des classes Java.

Il est aussi possible de l'utiliser directement en ligne de commande comme un script classique et d'éviter d'écrire un wrapper Java. La commande s'appelle jjs.

Implémentation par défaut dans les interfaces (Defender Methods)

Jusqu'à la version précédente, les interfaces Java ne pouvaient contenir de code, uniquement des déclarations de méthode. À partir de cette version, les implémentations de méthode statique et les implémentations par défaut de méthode sont possibles. Ces dernières sont des implémentations des méthodes qui seront utilisées si la méthode n'est pas redéfinie dans une autre implémentation qui étend celle-ci ou une classe qui implémente l'interface sans implémentation pour la méthode.

Cela fait resurgir le problème de l'héritage en diamant qui était évité par l'absence d'héritage multiple de classe et que les interfaces permettaient d'éviter par rapport aux classes abstraites. Que faire lorsqu'une méthode est définie dans plusieurs interfaces implémentées dans une classe ? Prenons l'exemple suivant :

interface A { void m() default {} } interface B extends A {} interface C extends A {} class D implements B, C {}

Ce cas est assez simple, D héritera de l'implémentation dans A. Si B ou C implémente la méthode, ce sera cette implémentation qui sera utilisée (implémentation la plus spécifique est utilisée). Si B et C implémentent la méthode, il faudrait spécifier explicitement quelle méthode sera utilisée.

Méthodes statiques dans les interfaces

En plus des méthodes par défaut, il est possible de définir des méthodes statiques dans les interfaces. Il n'y a pas de différence avec les méthodes statiques dans une classe.

API Date

Beaucoup de monde attendait une évolution (une révolution ?) de l'API Date et utilisait JodaTime à la place de l'API standard.

Java 8 apporte une nouvelle API pour gérer les dates qui est divisée en 2 :

  • le temps humain, principalement porté par LocalDate et LocalTime gère une date prenant en compte le fuseau horaire et possédant distinctement différents champs (pour l'heure, le jour, etc)
  • le temps machine qui est un timestamp et qui s'appuie sur les classes Instant et Duration.

Grande nouvelle : cette nouvelle API est thread-safe ! Je vous laisse découvrir plus en détail cette API au travers du tutoriel de Yohan Beschi
Tutoriel sur les nouveautés du langage 8 : la nouvelle API Date et Time.

Disparition du Permgen

C'est une évolution spécifique à l'implémentation de référence mais ça fera plaisir à beaucoup de monde en évitant des erreurs du type java.lang.OutOfMemoryError: PermGen space. Le permgen stockait les définitions de classes définies dans le programme en cours et sa taille pouvait poser un problème pour les grosses applications utilisant beaucoup de classes ou les générant en cours de fonctionnement. C'est donc un point en moins à surveiller pour les mises en production.

Télécharger ce contenu au format Epub

Lire les commentaires

100 développeurs : la part belle à l’Open Source

Vendredi 28 Mars

La french touch du code, c’est le projet fou mené à bien par Tariq Krim de recenser 100 développeurs français (ou francophones) qui ont marqué le paysage mondial, dans le cadre d’une mission confiée par le ministère de l’Économie Numérique. Un projet fou, car quoi qu’il advienne, cette liste sera forcément incomplète et subjective.

La première chose qui marque dans cette liste, c’est la prédominance du monde du libre. Les développeurs de l’hexagone rayonnent partout dans le monde, et ça se manifeste particulièrement à travers le libre.

Si l’on peut aisément critiquer la liste (incomplète, beaucoup de connaissances de l’auteur, très centré startup et business, publication web du rapport sur une plateforme US), l’initiative n’en est pas moins louable, car l’objectif est de remettre sous les projecteurs des compétences qui sont bien souvent sous-estimées ou négligées par les entreprises et autorités françaises. C’est d’ailleurs assez impressionnant, et le rapport en parle, beaucoup de ces développeurs ont choisi de rejoindre les géants de l’informatique étrangers. Peut-être que cette reconnaissance peut amener les entreprises à mieux valoriser les compétences en tenant tête aux géants américains.

En seconde partie de dépêche, un extrait des développeurs sélectionnés qui ont contribué au libre.

Les développeurs du monde Open Source

Romain Guy, le développeur du système graphique d’Android est le premier cité.

Paul Rouget, ensuite, un contributeur à Firefox de la première heure.

Samuel Tardieu est cité également, pour ses nombreux projets libres et son travaille sur Urbi, un OS robotique, aux côtés d’Akim Demaille.

Sam Hocevar, l’auteur fou de libcaca et le casseur de captcha, codeur sur VLC y est cité, aux côtés d’autres développeurs Debian comme Julien Danjou et Lucas Nussbaum, l’actuel DPL.

L’inénarrable Fabrice Bellard, le recordman en 1997 et 2009 du calcul du nombre de décimales de Pi, auteur de QEMU et de FFmpeg.

Thierry Carez, membre PSF et contributeur OpenStack avec Nicolas Barcet.

Plusieurs développeurs kernel sont cités, comme Rémy Card, l’auteur originel des systèmes de fichiers ext et ext2 ; Frédéric Weisbecker qui parle à l’oreille du scheduler, ou Éric Dumazet qui parle à l’oreille du réseau.

Travaillant sur KOffice et le standard OpenDocument, David Faure fait partie de la liste.

Dans les différents langages académiques (ou pas) Xavier Leroy l’inventeur de OCaml, Bertrand Meyer l’auteur d’Eiffel, ou Alain Colmerauer qui a créé Prolog.

Pierre-Yves Ritschard et Marc Espie de la sphère OpenBSD sont cités pour leurs travaux très variés.

On découvre également dans la liste Paparazzi un système de drones libre auquel Pascal Brisset, Antoine Drouin, Michel Gorraz, Pierre-Selim Huard et Jeremy Tyler ont participés.

Loïc Dachary, le fondateur de la FSF France et de Savannah.

Christophe Massiot, Jean-Baptiste Kempf des projet VLC et upipe.

Les créateurs du projet qui monte, docker, Salomon Hykes, Sébastien Pahl, Samuel Alba et Jérôme Petazzoni.

Sébastien Bourdeauducq, fondateur de Milkymist (M-Labs), des designs hardwares open source (CPU, SoC, etc.)

Fabien Potencier, créateur de Symfony, un des framework PHP les plus utilisés au monde.

Ludovic Dubost, le fondateur de XWiki, un wiki open source.

Daniel Glazman, contributeur Mozilla, auteur de BlueGriffon et co-chairman du groupe de travail CSS au W3C.

Mickaël Rémond, committer ejabberd et membre de la fondation XMPP.

Sébastien Tricaud, contributeur Wengo Phone et NuFW.

Stéphane Bortzmeyer, notre trolleur des réseaux, et expert DNS.

Une liste incomplète

Notre champion des kernels stables, et du premier load balancer au monde HAProxy, Willy Tarreau est absent. Pas de mention non plus du précédent DPL, Stefano Zacchiroli. Ou de Julia Lawall, l’auteur de coccinelle qui a énormément contribué à la qualité du code Linux.

On va avoir une pensée toute spéciale - bien évidemment sur LinuxFr.org - à Fabien Penso, Pascal Terjan, et Bruno Michel, qui ont écrit ou ré-écrit LinuxFr.org.

Peut-être pourrons-nous rajouter ceux-ci ?

  • Gaël Duval, créateur de Mandrake/Mandriva
  • Pierre Ficheux, auteur de livres sur Linux embarque
  • Jean_Baptiste Queru, développeur AOSP (Android)
  • Cédric Temple, lead développeur de Centreon
  • Jean Gabès, lead développeur de Shinken
  • Yann Leboulanger, lead développeur de Gajim
  • Stéphane Fermigier, lead développeur de Nuxeo

Quels sont les développeurs qui vous ont marqué ? Quels autres oublis flagrants y a-t-il dans ce rapport selon vous ?

Télécharger ce contenu au format Epub

Lire les commentaires

Libre en fête le 12 avril à Villars-Colmars

Jeudi 27 Mars

Pour l'édition 2014 du Libre en Fête, l'association Linux-Alpes répond à l'invitation de la Communauté de communes du Haut Verdon-Val d'Allos. Une journée complète d'échanges, de démonstrations et d'installations de logiciels libres se déroulera donc samedi 12 avril à La Rotonde de Villars-Colmars.

Au programme des ateliers découvertes :

  • Openstreetmap
  • Ubuntu dans les écoles
  • le logiciel libre pour les professionnels
  • les services en ligne libres
  • install party !

La journée se terminera par une soirée pizza!

Participation libre et gratuite ouverte à tous

Au programme

Le matin de 10h à 12h, ateliers découvertes

  • OpenStreetMap : découvrez un logiciel de cartographie grand public aux multiples talents.
  • Ubuntu dans les écoles : un ordinateur sans virus, avec des jeux éducatifs, des logiciels destinés aux instituteurs, aux parents, aux enfants et bien plus encore ! – Présentation par un maître d'école.
  • Le logiciel libre pour les professionnels : quelles applications, quels outils pour mon entreprise ? Questions / Réponses.

11h30 : le verre de l'amitié offert par la municipalité de Villars-Colmars

De 14h à 18h, ateliers découvertes

  • Libre balade : rendez-vous à la Rotonde à 14H pour une promenade avec GPS à travers le village de Villars, accompagné par Pierre Bonnet, passionné par l'histoire de son village. Ensuite, c'est à vous de jouer pour créer la carte interactive de votre parcours grâce à Openstreetmap.
  • Connaissez vous vraiment Facebook et Google ? Sur votre ordinateur, sur votre smartphone, quelle protection pour votre vie privée ? Quelles alternatives libres ? Un atelier conférence pour tout savoir sur les services en ligne libres animé par l'association Outils-Conviviaux.

Toute la journée :

  • Install Party : découvrez Ubuntu, libre et gratuit… Nous vous proposons de vous installer bénévolement ce système sur votre ordinateur. Attention, vous devez avoir au préalable sauvegardé vos données (documents, photos, vidéos, mails…). Information détaillée sur nos dépliants ou sur cette page
 Et le soir à partir de 20h, libres blablas autour de pizzas à Thorame Basse, au Café de la Vallée

Télécharger ce contenu au format Epub

Lire les commentaires

Meilleurs contributeurs LinuxFr.org : les gagnants de février 2014

Jeudi 27 Mars

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

Abonnement d'un an à Linux Magazine France

Livres des éditions Eyrolles et ENI

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

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

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

Les livres sélectionnés par les gagnants :

                        Télécharger ce contenu au format Epub

Lire les commentaires

Silverpeas 5.14 est sortie

Jeudi 27 Mars

Après plusieurs mois de développement et de débogages intensifs, Silverpeas 5.14, le portail collaboratif et social clé en main, est sorti officiellement la semaine dernière.

Silverpeas est un portail collaboratif et social libre (AGPLv3) écrit en Java/JEE. Son objectif est de faciliter la mise en relation des utilisateurs, leur collaboration, le partage des connaissances et des bonnes pratiques. Pour ce faire, il offre une ergonomie intuitive et de nombreuses applications prêtes à emploi (environ une trentaine) : gestion documentaire (GED), archivage de courriels, import de documents numérisés, workflow documentaire, réservation de salles, organisation de réunions, liens de téléchargement temporaires, blogs, formulaires en ligne, petites annonces, newsletter, flux RSS, etc.

Vous découvrirez plus en détails cette version en deuxième partie de dépêche.

La version 5.14 offre un tout nouveau skin à la plate-forme, apportant un aspect plus moderne et une meilleure lisibilité. Les espaces bénéficient d'une nouvelle page d'accueil. Plus éditoriale et avec une mise en place immédiate, elle remplace l'actuelle page d'accueil basée sur les portlets. L'éditeur WYSIWYG a été mis à jour et offre également un aspect plus moderne.

Les formulaires continuent à s'enrichir avec une nouvelle interface de gestion plus ergonomique et avec deux nouveaux champs : adresse/cartographie et adresse e-mail. Côté administration pure, il est maintenant possible d'affecter un quota d'espace disque sur chaque espace. Enfin, la gestion documentaire offre deux nouvelles fonctions liées aux fichiers : le blocage du téléchargement pour les lecteurs et la limitation des types de fichiers autorisés.

L'installateur graphique, basé sur izPack, vous permet d'installer rapidement Silverpeas en vue de l'essayer. Les paquets pour RedHat/CentOS et pour Debian/Ubuntu vous permettent d'installer Silverpeas sur votre distribution (cf. la page explicative). Seul le template de VM pour la version 5.14 n'est pas encore généré sur le marketplace d'UShareSoft, mais ne saurait tarder.

Télécharger ce contenu au format Epub

Lire les commentaires

Soirée Intéropérabilité des frameworks

Mercredi 26 Mars

L’antenne AFUP (Association Française des Utilisateurs de PHP) Paris donne rendez-vous à tous les développeurs et développeuses le 2 avril 2014 autour du thème de l’intéropérabilité des frameworks à Paris (salle Spark).

L'antenne invite 2 conférenciers pour parler PSR avec FIG et les injections de dépendances. La soirée sera découpée de la manière suivante :

  • ouverture des portes à 18h30 ;
  • 1ère présentation : les containers d’injection par David Négrier de The Coding Machine ;
  • 2ème présentation : les efforts de FIG par Frédéric Marand de Osinet ;
  • 3ème présentation : présentation surprise ;
  • pot de l’amitié.

Comme toujours le rendez-vous est gratuit et ouvert à tous, n’hésitez donc pas en parler autour de vous, et comme toujours… le nombre de places est limité. Alors n'hésitez pas à vous inscrire à partir de la page de l'événement!

Télécharger ce contenu au format Epub

Lire les commentaires

Atelier serveur Samba

Mercredi 26 Mars

Dans le cadre de ses formations bi-mensuelles, le GULL StarinuX vous invite à participer à l'atelier Serveur Samba.

Une journée d'apprentissage intensive et passionnante ! Le programme est en seconde partie.

Objectif :

À la suite de cet atelier vous serez capable d'installer, configurer votre serveur Samba, d'échanger des fichiers entre postes Linux et / ou Windows avec la sécurité, créer un serveur d'impression tout-terrain depuis Linux ou Windows, se connecter en mode client/serveur entre postes GNU/Linux, Windows et Apple.

Programme :

  1. Présentation et origine de Samba (SMB = System Message Block),
  2. Installer Samba et le configurer (smb.conf), rôle de portmap, domaine ou groupe de travail,
  3. Étude des commandes consoles Samba (smb_xxx_), paramétrage, (en mode console et mode graphique)
  4. Échanges de fichiers inter-plates-formes,
  5. Imprimer tous azimuts quel que soit le serveur ou la plate-forme dans le domaine ou groupe,
  6. Connexions Client/Serveur inter-plates-formes,
  7. L'avenir : présentation de Samba version 4.
Télécharger ce contenu au format Epub

Lire les commentaires

Atelier informatique à Grenoble le 1er mercredi de chaque mois

Mercredi 26 Mars

Un atelier informatique se tiendra désormais à Grenoble le 1er mercredi de chaque mois au centre social autogéré la BAF, 2 chemin des alpins. Il sera ouvert de 20h à minuit et son entrée sera libre toute la soirée, sans inscription.

Et voici le texte de présentation complet:

Atelier Informatique
tous les 1er mercredi du mois, de 20h à MINUIT ! entrée libre
à la BAF: 2, chemin des alpins à Grenoble

Partage des connaissances, petits dépannages, initiation aux logiciels libres. Bienvenue, c’est sans inscription:

Une fois par mois aura lieu à la BAF à Grenoble un atelier d’informatique ouvert au public, sans programme pré-établi et sans heure d’arrivée obligatoire, un rendez-vous où chacun-e peut venir avec son ordinateur, ses questions, ses problèmes, et si tout se passe bien, repartir avec des solutions.

Ce sera aussi l’occasion d’avoir un moment et un lieu d’initiation aux logiciels libres sur des postes en libre service, et à la cryptographie (notamment asymétrique, pour chiffrer les emails avec une clé publique), une pratique in-dis-pen-sable dont beaucoup de gens ont entendu parler mais qui est encore trop peu utilisée. On trouvera en plus pendant cet atelier des ressources et des conseils pratiques pour protéger la confidentialité de ses données numériques en général et en particulier.

Ce rendez-vous pourra être également l’occasion de diagnostiquer un ordinateur, récupérer des données effacées, apprendre à se servir de logiciels libres pour faire du montage vidéo ou du son, installer (GNU)Linux sur un ordinateur, installer openwrt sur un routeur wifi et encore d’autres choses que vous pourrez proposer…

Télécharger ce contenu au format Epub

Lire les commentaires

Séminaire LinID le jeudi 3 avril 2014

Mercredi 26 Mars

La société Linagora organise le jeudi 3 avril, dans ses locaux, 74/80 rue Roque de Fillol, 92400 Puteaux (métro : Esplanade de la Défense), un séminaire sur la suite logicielle libre LinID.

LinID est édité sous licence AGPLv3 et a pour objectif de fournir un ensemble de briques libres pour mettre en place de la gestion des identités et des accès, et de la fédération des identités.

Le programme du séminaire est le suivant :

  • 9h00-9h15 - accueil ;
  • 9h15-9h30 - introduction ;
  • 9h30-10h00 - présentation des composants de LinID.org : annuaire LDAP, Directory Manager pour la gestion facile des utilisateurs, OpenLDAP Manager pour la configuration technique, WebSSO et sécurité avec LemonLDAP ::NG  ;
  • 10h00-10h30 - intégration du serveur Active Directory avec LinID (synchronisation avec LS Connecteur, authentification, …) ;
  • 10h30-10h45 - pause ;
  • 10h45-11h30 - mise en place de la fédération des identités avec le protocole SAML ;
  • 11h30-12h00 - retour d’expérience par Olivier Guillard, AFNIC.

Le séminaire est gratuit mais une inscription est nécessaire pour participer.

Télécharger ce contenu au format Epub

Lire les commentaires

Foire du Libre 2014

Mardi 25 Mars

Louvain-li-Nux, une organisation étudiante affiliée à l'Université Catholique de Louvain-la-Neuve, organise la troisième édition de ce que nous appelons la Foire du Libre. Cet événement prendra place sur le campus de la ville universitaire de Louvain-la-Neuve le mardi 1er avril.

Nous y inviterons des représentants de logiciels libres en Belgique pour une soirée de conférences accessibles à tous. Les buts de cet événement sont de faire découvrir les logiciels libres et la philosophie qui a permis leur succès, d’expliquer en quoi les logiciels libres peuvent représenter un avantage pour les entreprises et être intégrés dans un nouveau type de business model et finalement de montrer à notre public que ce milieu n’est pas si éloigné d’eux en présentant des acteurs locaux dans le monde du logiciel libre.

Cela aura lieu à l'auditoire SUD 08 de l'Université Catholique de Louvain (UCL). Ces conférences ne sont pas techniques et ne requièrent pas de connaissances techniques : elles sont ouvertes à tous et gratuites.

Il est devenu très important de faire comprendre les intérêts et les implications que représentent l'utilisation et le développement des logiciels libres aujourd'hui. C’est afin d’expliciter ces implications, d’informer et de renseigner sur les logiciels libres que nous organisons cet événement.

Le Louvain-li-Nux est un kot-à-projet qui se charge de la promotion de l’informatique libre et des différents systèmes d'exploitation "GNU/Linux". Notre activité ne vise pas uniquement les étudiants, mais également tout particulier. C'est pourquoi nous avons besoin d’une visibilité plus large que le public universitaire. Vous trouverez sur notre site web une description plus détaillée de notre action sur le campus de Louvain-la-Neuve. Si vous êtes intéressé par l’idée de communiquer sur cet événement de quelque façon que ce soit, n'hésitez pas à nous en faire part par voie électronique ou venir nous rencontrer lors de notre conférence Latex ou directement au kot à projet, Rue Constantin Meunier, 12 à Louvain-la-Neuve (code postal : 1348).

Télécharger ce contenu au format Epub

Lire les commentaires

Pages