Présentation LoOPS de Vue.js

On en a déjà parlé à la dernière réunion, LoOPS re-joue sa présentation sur Vue.js le 19 décembre.

Bien que le développeur de Vue, Evan You n’ait aucun lien particulier avec la France (il est d’origine chinoise et vit dans le New Jersey), le site officiel est extrêmement bien traduit en français, ce qui suggère qu’il existe une communauté francophone active.

Serge a entendu parler de Vue dans une réunion INRIA, où les utilisateurs d’Angular et React présents se sont montrés assez sceptiques. Ces utilisateurs de frameworks Javascript étant eux-même minoritaires dans l’assemblée… Il y avait une question muette sous-jacente: avec un écosystème du web qui évolue très rapidement, c’est difficile de savoir sur quel cheval parier quand on bâtit un site ou une application destiné être maintenu pendant de longues années.

Christian se demandait quelles applications web connues sont écrites avec Vue.js. Des éléments de réponse à cette question peuvent être trouvés dans le dépôt Github « Awesome Vue.js », section « Projects using Vue.js ».

Réunion RI3 « Outils collaboratifs »

Il y a eu le 11 décembre une réunion RI3 sur le thème des outils collaboratifs. Cette dernière a été principalement centrée sur les services mutualisés du CCIN2P3, mais il y avait aussi des infos intéressantes pour des développeurs utilisant les services du CC comme Gitlab. Concernant ce dernier:

• Une mise à jour vers une version plus récente de Gitlab 9 surviendra prochainement. La mise à jour vers Gitlab 10 ne peut pas encore être effectuée car il faut d’abord que le CC mette à jour le server de bases de données PostgreSQL sous-jacent.
• Le CCIN2P3 travaille actuellement sur la possibilité de déployer automatiquement les nouvelles versions d’une application lorsque l’intégration continue réussit.
• L’activation de la fonctionnalité « Gitlab Pages » qui permer de gérer un site web statique au sein d’un dépôt Git est aussi prévue prochainement.
• Il est d’ors et déjà possible de mettre des images Docker en ligne au CC, via un « registry » local, et la possibilité de les construire automatiquement dans l’intégration continue est à l’étude.
• La limite du nombre de projets privés sur Gitlab (qui détermine par exemple combien de « forks » un développeur peut posséder) a été montée à 50 pour les nouveaux utilisateurs. Cette modification sera propagée aux anciens utilisateurs ultérieurement.
• Il est maintenant possible d’activer une intégration Mattermost dans Gitlab, ce qui soulève une question: est-ce qu’il y a de la demande pour que l’on monte une instance Mattermost (un chat persistent façon Slack) au CC ?

Jean-René a aussi discuté de l’avenir de l’application web de sondages LimeSurvey. Elle fonctionne bien et connaît une certaine popularité, mais le logiciel est distribué sous un modèle économique freemium où certaines fonctionnalités sont payantes. L’une d’elle est la mise à jour automatique, qui serait un confort appréciable pour les administrateurs du CC. C’est pourquoi le CC envisage d’acheter une licence premium.

Le cahier de manip numérique ELog a aussi été discuté. Il existe au CC une instance de ce logiciel populaire chez les physiciens, peut-être pourrait-on la mutualiser. Ce n’est certes pas l’application web la plus moderne et ergonomique qui existe, mais Serge rappelle qu’il existe toujours pire (ex: OSN, imposé par Nicolas Leroy dans CALVA).

Dans la même famille des applications web que les utilisateurs aiment beaucoup, mais dont ne peut pas s’empêcher d’être un peu insatisfait quand même, il y a aussi TWiki. Sa maintenance au LAL est très difficile, et Serge adorerait arrêter ce service en faveur d’une solution plus moderne, éventuellement mutualisée au CC. Mais la migration du contenu accumulé dessus est un problème encore irrésolu.

La réunion RI3 a aussi abordé la question plus générale des infrastructures sous-jacentes aux applications web, que sont les certificats HTTPS et les noms de domaines. Ce sont deux domaines qui nécessitent un effort conséquent de maintenance manuelle à l’heure actuelle, et où une politique plus unifiée et automatisable serait souhaitable. Pour le HTTPS, le CC propose un usage plus intensif de l’autorité de certification Let’s Encrypt, pensée dès le départ pour l’automatisation. Mais pour les noms de domaines, la réponse reste encore à trouver. Serge pense qu’une première étape serait pour le SI d’apprendre à dire davantage « non » aux utilisateurs, au lieu de toujours accepter de prendre en charge la maintenance à long terme de leurs infrastructures mises en place à la hâte sans concertation préalable avec l’exploitation.

Un autre sujet abordé était la gestion de tickets pour l’exploitation. Il y a quelques temps, le CCIN2P3 avait essayé de proposer une solution mutualisée à ce problème avec OSRF, mais le moment semble venu d’admettre que ce projet n’a pas abouti: seul un laboratoire de Clermont-Ferrand (le LPC?) y reste attaché. L’argument généralement invoqué est la trop grande complexité de la solution au OSRF, qui semble surdimensionné et trop peu ergonomique. Si c’était à refaire, le gagnant de cette bataille technologique serait plutôt GLPI à l’heure actuelle.

Enfin, un dernier point qui a été abordé est la gestion des ressources humaines, et la possibilité de mutualiser les outils web développés pour cet usage. Des collaborations possibles pour Justine, qui est spécialiste de ce type de développements au LAL ?

Autres sujets

François mentionnait la manière dont on peut être perdu face aux questions de la gestion de version distribuée moderne, par exemple « J’ai accidentellement ajouté un commit sur la branche develop, que puis-je faire pour le transformer en branche de développement ? ». Une piste pour organiser des formations futures ?

L’école de programmation fonctionnelle et distribuée avec Spark a suscité un grand intérêt, avec en particulier une forte participation du LAL (10 personnes, soit environ un quart des étudiants). Elle se déroulera en deux parties, une partie plutôt centrée programmation fonctionnelle du 15 au 17 janvier, et une partie plutôt centrée Spark du 29 au 31 janvier.

Philippe mentionne une bonne idée de Microsoft et Canonical dans les versions récentes de Windows 10, le Windows Subsystem for Linux (WSL). Cet outil permet d’exécuter des applications Linux sous Windows en utilisant une émulation des appels systèmes, similaires à ce qu’offre Wine dans l’autre sens. Ce serait potentiellement intéressant pour des applications online, où on utilise beaucoup Windows et on a parfois des difficultés à y construire un environnement de développement confortable dès qu’on sort de l’écosystème Visual Studio. On se retrouve ainsi par exemple souvent avec plusieurs installations de Python qui se battent en duel, chaque projet fournissant son propre gestionnaire de paquet.

En janvier, le LAL organise un séminaire qui discutera de machine learning avec l’ASIC de recuit simulé quantique de D-Wave. Ce sera une bonne occasion d’approfondir ce que cette machine sait faire, et en quoi elle diffère des systèmes basés sur des qubits intriqués que l’on met plus généralement derrière le mot « ordinateur quantique ».

Les joies du déploiement

Antoine travaille sur un conteneur Wt pour PSPA. Ce dernier est basé sur une image Docker qui communique avec l’hôte par le biais d’un port réseau local. Mais récemment, le script qui initialise le conteneur a cassé et il ne comprend pas pourquoi. Toute aide pour débugger ce comportement serait la bienvenue.

Simultanément, l’équipe ThomX se pose la question de la distribution des binaires, qui se fait actuellement par le biais d’images ISO. Existe-t’il une solution plus simple de mise en oeuvre et mieux intégrée à leur gestion de version Git ?

Au niveau simplicité, tout dépend du degré auquel on descend à bas niveau. Docker marche bien pour de l’applicatif, mais ne sera pas forcément adéquat dès lors qu’on doit communiquer directement avec le noyau du système d’exploitation ou un pilote de matériel. A ce niveau, Philippe mentionne que l’un des buts pour ThomX est de déployer des pilotes TANGO.

Guy utilise différents mécanismes suivant la plate-forme cible. Par exemple, l’App Store d’Apple a des contraintes bien à lui. Quand il doit distribuer des programmes directement, il préfère lier statiquement un maximum de dépendances, même sous Linux. Windows et macOS sont mieux adaptés à ce mode de déploiement.

Dans tous les cas, il est important au moment du déploiement de savoir de quelles bibliothèques on dépend. A ce niveau, ldd et son équivalent Windows sont d’une grande aide, même si ils ne sont pas omniscients (par exemple, ils ne détectent pas les chargements dynamiques de bibliothèques à la dlopen()).

Pour ce qui concerne l’intégration avec Git, il y a eu des évolutions intéressantes ces dernières années autour des environnements GitHub et GitLab. Par exemple, on peut facilement automatiser le déploiement d’un binaire ou la mise à jour d’un site web chaque fois que l’intégration continue se passe bien.

Lorsqu’on a besoin de mettre des gros fichiers binaires dans un dépôt Git, il peut être intéressant de regarder ce qui se fait du côté de l’extension Git LFS (Large File Storage), co-développée par GitHub et Atlassian. Celle-ci a été pensée pour des usages où du code qui varie rapidement dépend de gros fichiers binaires qui varient plus lentement, par exemple pour les modèles 3D et textures dans les applications graphiques. Au niveau des inconvénients, l’extension est relativement jeune et en évolution rapide, ainsi Guy avait rencontré des problèmes de dépôt brisé lorsqu’il avait essayé il y a quelques temps.

Antoine mentionne aussi que l’équipement de développement Git s’intéresse actuellement aux idées du projet Evolve de Mercurial, qui vise à rendre les modifications d’historique (rebase, amend et compagnie) un peu moins dangereuses. Espérons que cet effort ne sera pas lui aussi condamné au destin d’éternelle beta…

Projets et communautés

Atrium

Christian nous annonce que l’INSU et l’IN2P3 se sont finalement mis d’accord pour utiliser tous les deux Atrium, ce qui est une première dans les relations politiques tendues entre ces frères ennemis. Ils ont même conjointement décidé de financer un CDD pour assurer sa maintenance.

Globalement, l’outil croît raisonnablement au LAL et à l’IN2P3 en général. Il est notamment bien accepté dans ThomX, mais les membres de PHIL sont plus hésitants.

LoOPS, Xtensor et Vue.js

LoOPS joue le 5 décembre un café sur Xtensor, une bibliothèque pour manipuler des tableaux multidimensionnels avec une interface utilisant des concepts similaires à MATLAB et NumPy. Cette bibliothèque possède une communauté assez active sur le plateau de Saclay.

Guy regrette l’usage du C++14, qui ferme des portes quand on veut rester portable avec des plate-formes dont les compilateurs C++ ne sont pas maintenux à jour par rapport aux évolutions du standard. En un sens, on observe dans la communauté C++ un schisme comparable à celui entre Python 2 et Python 3 (le premier n’est plus maintenu, mais de nombreuses infrastructures n’ont toujours pas sauté le pas).

En cadeau de Noël, LoOPS rejoue aussi le 19/12 sa présentation sur Vue.js, un framework Javascript pour le développement web front-end qui s’oppose à des solutions plus connues comme React et Angular par son approche plus « légère ».  Angular a aussi une réputation de briser davantage la compatibilité.

Hébergement de tutoriels

Hadrien commence à accumuler différents tutoriels et supports de formation autour de la performance logicielle, de différents types (slides, wikis, code…), et se demandait si il y avait un bon endroit dans les communautés académiques auxquelles on a accès (CNRS, RENATER, IN2P3, CERN, etc…) pour héberger tout ça.

En pratique, il s’est avéré que la contrainte la plus stricte sur ce genre était la volonté de donner facilement accès en écriture à d’autres personnes. A ce niveau, l’hébergeur le plus sympathique dans nos communautés académiques semble finalement être le CCIN2P3, qui accepte d’ouvrir des comptes à des extérieurs sur simple demande administrative d’un personnel IN2P3.

Deux solutions y ressortent comme particulièrement intéressantes:

• Atrium, dont on a parlé précédemment, est un système de gestion de documents, plutôt orienté vers du contenu relativement immuable sur lequel on souhaite appliquer des politiques d’accès ou d’édition complexes. Il y a un support préliminaire de l’édition en ligne, mais ce n’est pas la spécialité de l’outil.
• Gitlab, une plate-forme de gestion de code source avec de nombreux à-côtés sympathiques (wikis, sites web statiques), qui semble mieux adapté pour le code et les contenus collaboratifs.

WebAssembly

En ce moment, il y a pas mal d’activité autour de WebAssembly. Il s’agit d’un projet pour standardiser un bytecode universel pour le développement front-end web, afin de faciliter le développement de composants d’applications web dans d’autres langages que Javascript (typiquement pour des raisons de performances).

Le projet est comparable dans son intention au projet PNaCl (Portable Native Client) préalablement proposé par Google, mais contrairement à ce dernier il a réussi à faire l’unanimité auprès des développeurs de navigateurs web (y compris Apple et Microsoft, traditionnellement les plus difficiles à convaincre).

WebAssembly se veut être le successeur spirituel d’asm.js, un sous-ensemble de construction Javascript bas niveau orienté performances vers lequel on transpile parfois du code C/++ pour des besoins comme le développement de jeux vidéo.

Hadrien en a entendu parler via la communauté Rust, qui s’y intéresse beaucoup et en a récemment fait un backend du compilateur officiel.

Community White Paper

La HEP Software Foundation est actuellement en train de finaliser son « Community White Paper », un papier qui recense des idées et plans pour les développements logiciels à venir dans la physique des particules.

Guy s’interroge sur le périmètre du document. Il ne comprend pas pourquoi une fondation qui, dans son titre, se positionne comme focalisée sur les questions de logiciel, concentre une partie significative de son papier sur des questions d’infrastructure système. Antoine répond qu’il existe un lien fort entre les deux: sans un computing solide sous le capot, point de salut pour le logiciel… Mais dans ce cas, pourquoi ne pas l’appeler « Hep Computing Foundation », HCF, en prenant exemple sur le nom de la conférence CHEP ? Et n’existe-t-il pas un risque de dispersion des efforts ?

Une autre question de périmètre se pose au niveau des expériences. Le document conserve actuellement une très forte teinte (HL-)LHC, les autres expériences n’étant que brièvement mentionnées. Or, si l’on ne parvient pas changer cela, prétendre parler au nom de l’ensemble de la communauté de la physique des particules devient pour le moins présomptueux…

Guy est aussi peu satisfait de la partie visualisation, qu’il trouve incomplète et encore une fois biaisée en faveur de l’écosystème LHC. Il a tenté d’y contribuer, notamment en défendant l’importance d’applications locales autonomes, mieux découplées de l’infrastructure d’analyse des expériences. Mais le modèle client-serveur demeure finalement favorisé dans le texte final.

Le rôle réservé à Python pour l’analyse est intéressant: on accepte la popularité grandissante de ce langage, mais ne considère dans le texte que son usage en compagnie de ROOT, via PyROOT.

En vrac

Suite à un vol, Philippe est à la recherche d’un téléphone Samsung Galaxy S3 pour des besoins de développement bas niveau. Il est important que ce soit un S3 car l’écosystème ARM / Android est très pauvre en pilotes de matériel open-source, et peu de terminaux sont correctement supportés par Replicant, le fork open-source d’Android.

Il y a aussi eu une brève discussion sur le langage Go:

• Qui l’utilise ?
• Est-il désirable que ce soit utilisé davantage ?
• Si oui, comment on « vend » un nouveau langage aux expériences ?

La question du cycle de vie de l’expérience a été discutée : il est plus facile pour une expérience d’adopter une nouvelle techno, comme un nouveau langage, quand elle est au début de son cycle de vie. Mais même là, une nouvelle manip peut être liée à des technologies plus anciennes utilisée par une manip précédente.

Christian trouve qu’il est intéressant de faire un parallèle avec la transition de Fortran à C++ de la physique des particules dans les années 90. Beaucoup des arguments qu’on trouve aujourd’hui étaient déjà invoqués à l’époque, et à la fin l’histoire a montré qu’avec une motivation suffisante, une transition de langages est possible.

Arrivée de Julien Peloton

Cette réunion a été l’occasion d’annoncer l’arrivée en janvier 2018 de Julien Peloton, successeur de Christian Arnault sur les projets de calcul distribué avec Spark pour l’astrophysique.

Dans ce concours, 3 bons candidats avaient émergé: Julien, Alexandre du CDS, et Christophe de l’IAS (ancien de ROMEO). Si Julien ne partait pas initialement favori, il a su faire une très bonne impression au jury lors de son oral, ce qui a finalement fait pencher la balance en sa faveur.

Au niveau parcours, Julien a suivi le master NPAC, puis fait une thèse astroparticules au laboratoire APC sur l’analyse des données de l’expérience Polarbear, complétée par un post-doc de 3 ans à l’université de Sussex sur des sujets similaires, obtenu grâce à un prix. Il souhaitait revenir en France pour des raisons personnelles.

Il sera aussi l’un des premiers ingénieurs recrutés par le LAL à ne pas bénéficier de la Prime de Fonctions Informatiques (PFI), supprimée à l’occasion du passage à la RIFSEEP…

Nouvelles de SVOM

Antoine a passé deux jours au CNES pour un événement autour de SVOM, expérience spatiale rejointe par le LAL il y a quelques mois, mais dont l’existence est plus ancienne (quelques années).

SVOM est une expérience d’astrophysique franco-chinois visant à suivre des sursauts gamma par une combinaison d’instruments sur orbite et au sol. L’instrument spatial devrait être lancé de la Chine courant 2020.

Du côté français, on attend notamment des contributions de Florent Robinet et Nicolas Leroy du groupe Virgo, et d’Antoine et Marc du service informatique. Antoine y fait l’interface avec l’entreprise chargée du marché de gestion de la qualité pour l’astrophysique au CNRS, et en particulier au CNES.

Antoine rapporte quelques divergences culturelles intéressantes dans cette collaboration logicielle franco-chinoise. Il est ainsi étonamment difficile de proposer l’utilisation d’outils logiciels d’origine américaine, même open-source, dans un projet chinois.

Nouvelles de PSPA

Redesign de l’interface utilisateur

Après examen des différentes options possibles, PSPA va finalement sous-traiter la refonte de son interface utilisateur à une entreprise privée. Ce dernier sera chargé de l’essentiel du front-end web, le LAL continuant le développement du back-end.

Une entreprise potentielle a été trouvée par Christian Helft. Après quelques discussions, elle a fait une proposition. La décision finale est en attente d’un appel d’offre, qui devrait être lancé en 2018.

Le projet a été présenté au Conseil Scientifique du LAL. Un financement mixte LAL + IN2P3 est envisagé afin d’élargir le cadre du projet PSPA et éviter qu’il ne reste trop centré au LAL.

Grigory a demandé si la sous-traitance d’un tel projet ne nous entraînait pas sur la pente glissante d’une sous-traitance de l’informatique au CNRS. Antoine a répondu que le projet avait longuement cherché l’expertise de conception d’interface utilisateur en interne à l’IN2P3, ainsi qu’en contactant des écoles d’ergonomie et en proposant des projets pour le Google Summer of Code, mais que tout cela n’avait pas été concluant.

Philippe mentionne qu’il existe des personnes ayant ce genre de compétences à l’IN2P3, car ils en ont trouvé pour ThomX, mais que ce n’est effectivement pas ce qu’il y a de plus répandu.

Serge aurait été partant pour une approche où l’on partirait de bibliothèques d’interface web distribuées par des designers professionnels, en les adaptant aux besoins de PSPA quand c’est nécessaire. Il regrette que le projet n’ait pas trouvé d’autres labos à l’IN2P3 avec lesquels collaborer sur cette question.

Il semble y avoir ici un besoin de compétences qui n’est pas satisfait, peut-être devrait-on chercher à le combler à l’occasion de la fusion ?

Dans tous les cas, ce projet de développement du front-end et du back-end permettra de motiver des améliorations importantes de PSPA, telles que la formalisation de l’interface entre ces composants.

Choix d’une licence open-source

Actuellement, le code du projet PSPA n’est distribué sous aucune licence logicielle. Cela signifie qu’il est de facto propriétaire: si il est légal de le lire et d’en faire des copies privées, personne n’a le droit d’en redistribuer une version modifiée, ou un binaire en découlant, ce qui interdit par exemple tout développement basé sur les forks à la GitHub / Gitlab (puisque le propriétaire d’un fork distribue de fait une version modifiée du code).

Une licence open source vise à autoriser un certain nombre de scénarios de redistribution du code source. Il en existe un grand nombre, leur prolifération et les incompatibilités subtiles qui existent entre elles est d’ailleurs un problème. Pour cette raison, il existe depuis quelques années un certain nombre d’initiatives visant à inviter la communauter à se recentrer sur un nombre réduits d’entre elles. Parmi elles, on peut mentionner la liste « Popular Licenses » de l’Open Source Initiative (OSI) et le guide « Choose a License » de GitHub.

Quand on s’en tient à ces licences populaires, le choix se fait principalement autour de ce qu’on veut autoriser les autres à faire avec son code. En effet, les licenses les plus permissives, comme la BSD et la MIT, ont un certain nombre d’effets pervers connus que l’on peut souhaiter décourager:

• Si une entreprise décide de prendre un logiciel gratuit sous licence BSD et d’en vendre une version à peine modifiée, les auteurs originaux ne peuvent réclamer aucune rétribution financière,  ni demander à avoir accès aux versions modifiées du code source. Ce comportement parasite est entièrement autorisé par la licence.
• Dans les pays comme les Etats-Unis où les brevets logiciels sont répandus et utilisés comme instruments de guerre commerciale, une entreprise peut aussi tout à fait tenter de faire une copie d’un logiciel sous licence BSD, breveter son comportement, puis accuser l’auteur original de violation de brevet. Bien sûr, le brevet est alors totalement illégal puisque le parasite n’a pas la paternité du logiciel, mais le prouver à un tribunal demande une lutte juridique longue et des moyens financiers conséquents, et de nombreux « petits » développeurs finiront par préférer abandonner et payer le racketteur faute de moyens…

La licence Apache tente de lutter contre cette utilisation abusive des brevets logiciels en forçant l’auteur du logiciel et son utilisateur à signer un pacte de non-agression. L’auteur confère à l’utilisateur une licence non-révocable pour tous les brevets liés au logiciel sous licence Apache, tandis que l’utilisateur accepte que tout procès de violation de brevet intenté à l’auteur causera un arrêt immédiat de sa licence d’utilisation du logiciel.

Les licences dites « copyleft », comme la GPL, vont plus loin en imposant une redistribution du code source de tout logiciel basé sur le code sous licence copyleft, et en interdisant toute redistribution sous une licence plus restrictive. Cette approche interdit au maximum les comportements parasites, au prix parfois d’interdire aussi des utilisations du logiciel jugées légitimes par l’auteur du logiciel. Par exemple, veut-on qu’une entreprise soit forcée de redistribuer le code source complet de son application simplement parce qu’elle utilise une bibliothèque libre ?

Pour ceux qui souhaitent éviter ce genre d’effet pervers, mais tiennent aux garanties anti-parasites du copyleft, il existe le compromis du « copyleft faible », comme les licenses LGPL et MPL. Destinées à des bibliothèques, ces licences disent grosso modo qu’une version modifiée de la bibliothèque doit être redistribuée en open-source, mais qu’une application basée sur la bibliothèque n’est pas forcée d’utiliser la même licence. Ces licences ne diffèrent que dans leur définition d’une bibliothèque et des utilisations autorisées sans qu’une licence particulière soit imposée à l’application hôte.

Les licences précédentes ont été conçues pour le droit américain, ce qui conduit certains juristes à affirmer que leur transposition au droit français et européen n’est pas évident. Pour ceux qui sont inquiets de cet aspect légal, il existe des variantes « régionales » des licences précédentes, adaptées au droit français (CECILL) ou européen (EUPL). Le prix à payer est une collaboration potentiellement plus difficile avec des projets internationaux, qui feront à ces licences le reproche inverse d’être insuffisamment adaptées au droit américain…

Si l’on a besoin de l’aide d’un juriste sur ces questions légales, cela peut être difficile à trouver au CNRS, le service valorisation de la DR4 n’étant pas très doué sur ces questions. Philippe mentionne l’existence d’un juriste très compétent à l’échelle nationale, la difficulté étant de le contacter en esquivant l’échelon intermédiaire… Grigory mentionne aussi la présence d’un bon juriste à Polytechnique, qu’on peut aussi contacter en cas de problème avec la délégation régionale.

Revues numériques Diamond

Nous avons pu tester pendant un certain temps la version numérique des revues des éditions Diamond (GNU/Linux mag, Hackable, Linux pratique, Misc). La période d’essai arrive maintenant à son terme, et Philippe souhaiterait savoir si ces éditions nous intéressent suffisamment pour que ça vaille le coup d’acquérir un abonnement.

On nous a proposé l’accès en ligne aux versions numériques (base documentaire) pour 607,5€/an, et le papier en plus pour 825,03€/an. Cet abonnement, appelé « L+ », inclut les numéros de l’ensemble des quatre revues, ainsi que leurs hors-séries. Pour les autres devis possibles, un générateur de devis est disponible en ligne.

Au moment de la réunion, le faible nombre de retours (Adrien seulement) suggérait qu’il serait peut-être mieux d’en rester là.

Autres sujets en vrac

Serge mentionne l’organisation possible d’une formation Symfony 3 au CNRS, en cours de discussion sur la liste DevLog.

Le bureau de Christian Helft est maintenant vde, et prêt à être transformé en salle de repos pour le service informatique.

Pour la prochaine réunion sur le fonctionnement du SI (20/11), quelques sujets commencent à émerger:

• Veille technologique
• Évolution du format des réunions développeurs
• Fréquence élevée des réunions exploitation
• Projet de réunion orienté utilisateurs, sur le même principe que le COMUTI mais davantage orienté développement

Voici l’automne, saison où les feuilles tombent mais les conférences et les réunions en tous genres fleurissent.  Cette réunion développeurs a donc principalement eu pour but de centraliser les retours des réunions où ses différents membres s’étaient rendus.

GENCI

Contexte

David s’est rendu à la réunion du GENCI (Grand Équipement National de Calcul Intensif), organisme dont le principal rôle est de centraliser la direction des ressources de calcul intensif pour la recherche publique en France. On peut le voir comme l’antenne française de l’organisation européenne PRACE (PaRtnership for Advanced Computing in Europe).

La réunion se déroulait au grand amphithéâtre du CNRS Michel-Ange.  L’ambiance était bonne, avec beaucoup de tables rondes. Bien que le public d’une réunion GENCI soit à la base plutôt décisionnaire, des utilisateurs étaient présents pour expliquer leurs besoins, et étaient écoutés.

Moyens et évolution de GENCI

Les ressources de calcul de GENCI sont majoritairement concentrées dans 3 grands centres nationaux, chacun ayant une certaine « couleur » administrative bien qu’étant utilisé par tous les acteurs académiques:

• Le CINES (Centre Informatique National de l’Enseignement Supérieur), à Montpellier, est plutôt porté par les universités.
• L’IDRIS (Institut du Développement et des Ressources en Informatique Scientifique), en haut du campus de Paris-Sud, est plutôt porté par le CNRS.
• Le TGCC (Très Grand Centre de calcul du CEA), à Bruyères-le-Châtel, est plutôt porté par le CEA.

Depuis quelques années, GENCI tente également d’intégrer davantage à sa stratégie des centres de calcul régionaux de plus petites tailles, dits « mésocentres », comme par exemple le centre de calcul ROMEO de Champagne-Ardenne. Ils utilisent pour cela une organisation hiérarchique avec une terminologie à base de « Tiers », similaire à celle du monde des grilles.

Une autre évolution est que GENCI tentent de s’adapter davantage aux utilisateurs ayant des besoins en stockage de long terme. Ce n’est historiquement pas une spécialité des supercalculateurs, normalement on crée des comptes utilisateurs le temps d’un projet de court terme, on le détruit à la fin, et toutes les données sont alors jetées. Mais ce changement de stratégie est nécessaire pour intégrer la problématique « big data », ce que le GENCI essaie de faire sous la terminologie de HPDA (High Performance Data Analytics).

Le calcul intensif et les grilles

Historiquement, les communautés du calcul intensif et des grilles de calcul ont régulièrement été en compétition. Une partie de la raison est que leurs besoins et leur organisation sont assez différents, même si ils tendent à se rapprocher depuis quelques années.

Voici quelques points de comparaison entre les deux approches (désolé pour le piètre rendu visuel, j’ai fait ce que j’ai pu côté HTML mais le CSS du blog développeurs semble avoir sa propre idée très précise de l’apparence qu’une table devrait avoir):

Séminaire Verrou

Dans le cadre des séminaires « Demandez le programme » de l’INRIA Saclay, François Févotte, ingénieur de recherche chez EDF, a présenté l’outil Verrou. Cet outil permet d’étudier la stabilité numérique des codes de calcul scientifiques, c’est à dire la sensibilité de leurs résultats aux fluctuations des données d’entrée ou de sortie.

Une telle analyse a plusieurs intérêts:

• Elle permet d’évaluer à quel point le résultat d’un calcul est significatif, et de comprendre et améliorer sa précision.
• Elle peut révéler des bugs ou des problèmes de performance liés à une mauvaise utilisation des nombres à virgule flottante (ex: critère de convergence en-dessous de la précision du calcul)
• Elle peut aussi être utilisée pour guider l’évolution d’un code de calcul vers une précision réduite ou hybride afin d’augmenter ses performances. Souvent, un scientifique utilise en effet la double précision par défaut, par sécurité face à son inexpérience.

La méthode mathématique généralement utilisée pour de telles études de stabilité, appelé CESTAC, consiste à introduire des erreurs d’arrondi aléatoires dans les calculs (correspondant à un bruit sur le dernier bit du nombre calculé) et à évaluer l’impact de ces erreurs sur le résultat du calcul.

Il y a plusieurs manières d’introduire de telles erreurs. La méthode historique, utilisée par l’outil CADNA, est malheureusement très intrusive: on doit remplacer tous les nombres flottants dans le code par un type de données spécialisé. C’est en pratique très laborieux, surtout sur des programmes ayant des dépendances nombreuses. Verrou résout ce problème en utilisant l’émulateur Valgrind pour instrumenter à la volée un binaire non modifié. C’est un gain de temps énorme, pour un prix à payer finalement assez faible:

• Moindre portabilité entre systèmes (Linux x86 seulement)
• Localisation plus grossière des problèmes (le compilateur a éliminé une partie de l’information sur la position des calculs)

L’outil est open-source, EDF l’a mis sur Github. François Touze a mentionné qu’il pourrait intéresser aussi la communauté de la chromodynamique quantique (QCD), qui manipule souvent des matrices presque non inversibles où la moindre erreur dans l’algorithme de calcul peut être fatale pour la qualité du résultat.

ICALEPS et sécurité info

Philippe était à ICALEPS, à Barcelone. C’est essentiellement une conférence de contrôle-commande centrée sur les deux frameworks ennemis TANGO et EPICS, mais cette année, on y trouvait aussi un workshop très intéressant sur la cyber-sécurité.

Un thème récurrent était les nouvelles menaces liées aux nouvelles pratiques de gestion des données des entreprises, où on tend de plus en plus à remplir des disques dur par défaut sans réfléchir aux conséquences légales et techniques de cette accumulation.

En passant, un mot sur l’attaque KRACK. Pour résumer, une faille de sécurité a été trouvée dans le protocole cryptographique d’échange de clé du système de chiffrement WPA2 des réseaux Wi-Fi. La conséquence est qu’un utilisateur ne disposant pas du mot de passe peut lire et écrire le trafic réseau chiffré comme si il avait rejoint le réseau normalement. La faille se situant au niveau du protocole WPA lui-même, toutes les implémentations actuelles sont vulnérables, et le problème ne sera pas facilement soluble par un simple patch. Il faut donc dorénavant considérer que les réseaux WPA2 sont aussi sûrs (confidentiels et intègres) que des réseaux publics non chiffrés pour un attaquant expérimenté. Il ne faut donc pas utiliser sur ces réseaux des protocoles réseau « en clair » ne fournissant pas leur propre mécanisme de chiffrement et d’authentification.

Une autre menace grandissante est celle des périphériques malveillants. A ce sujet, on peut facilement laisser son esprit être emporté par une fascination perverse pour l’élégance technologiques d’attaques sophistiquées, comme celles basées sur des logiciels malveillants ou sur le siphonnage du contenu de la RAM d’un ordinateur par un périphérique (auxquels les Macs ont été sujets avec le Firewire, puis à nouveau avec le Thunderbolt, prouvant que les fabricants de matériel ne savent pas tirer les leçons de l’histoire en termes de sécurité). Mais il faut aussi garder les pieds sur terre et se rappeler que le danger peut aussi provenir d’attaques beaucoup plus « bas niveau ». Ainsi, les sinistres « USB killers » ne sont autres que des batteries de condensateurs qui, à la manière d’un flash d’appareil photo, se chargent avec la petite alimentation 5V d’un port USB pour finalement frire la carte mère de l’ordinateur victime avec une impulsion de plusieurs centaines de volts. Quand on en arrive à ce niveau de bassesse, on en finit par se dire que tout accès physique aux ports d’une machine est une vulnérabilité en soi.

Se pose alors la question la plus importante: quelle alternative pratique et efficace aux clés USB peut-on fournir aux utilisateurs d’installations partagées comme les synchrotrons pour transférer leurs données scientifiques d’un ordinateur à un autre?

Une autre faille courante, au niveau utilisateur, c’est la réutilisation de mots de passe. Pour rappel, le problème avec cette pratique, c’est qu’elle augmente la quantité de dégâts provoqués par une brèche de sécurité. Ainsi, quand la base de données de mots de passe d’un site web fuite, tous les autres sites web pour lesquels on utilise le même mot de passe sont potentiellement aussi vulnérables. Un outil pratique quand on arrive après la bataille est le site « Have I been pwned », qui permet de savoir si un site populaire où l’on possède un compte a fuité des mots de passe récemment. Un autre outil plus ambivalent est le gestionnaire de mots de passe. Ce dernier facilite grandement la tâche d’avoir un mot de passe différent pour chaque service auquel on se connecte, par contre lorsqu’une faille de sécurité est trouvée dans le gestionnaire de mots de passe lui-même, les conséquences sont potentiellement dramatiques.

Comme sources d’informations sur la sécurité informatique, on peut mentionner pour les plus braves les listes de diffusion CERT, qui recensent les failles de sécurité découvertes dans des logiciels couramment utilisés. Mais leur débit conséquent et leur contenu très technique en découragera plus d’un. Comme alternative un peu plus agréable à lire et vulgarisée, le blog Naked Security de l’entreprise Sophos est une source très sympathique. Au niveau formation, on peut mentionner de nouveau que l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) a ouvert cette année un MOOC sur la sécurité de l’information appelé SecNum académie.

Autres sujets en vrac

Nous aurions bien aimé avoir aussi des retours de XLDB et SUCCES, mais malheureusement, aucun des développeurs qui s’y étaient rendus n’était présents ce jour là.

Philippe voulait savoir si des gens dans le service souhaitent encore jeter un oeil à l’abonnement en ligne à LinuxMag dont il nous avait parlé précédemment par mail, ou si ce n’est pas nécessaire de faire attendre l’éditeur plus longtemps et on peut déjà lui répondre.

L’école de programmation fonctionnelle et de Spark organisée par Christian n’est pas passée inaperçue. Ça a été l’occasion pour Hadrien de rappeler que ce style de programmation a d’autres applications que le calcul.  Ainsi, des langages comme Elm proposent un modèle fonctionnel pour la conception d’interfaces Web, tandis que du côté serveur l’API multi-langages ReactiveX fournit une approche très ergonomique et performante de la programmation par flux de données grâce à des mécanismes d’inspiration fonctionnelle.

Pour débuter avec ce modèle, le mieux est sans doute d’apprendre un langage pensé pour la programmation fonctionnelle à la base. On peut ainsi trouver des formations d’OCaml via l’INRIA et sur la plate-forme de MOOCs France Université Numérique, et des formations Scala sur la plate-forme de MOOCs Coursera.

Faut-il un ordre du jour?

La question de l’ordre du jour des réunions développeurs a été soulevée lors de la récente réunion sur le fonctionnement du service informatique. Le sujet laisse peu indifférent, certaines personnes trouvent la perspective motivante et d’autres la trouvent étouffante. Un compromis possible est de distribuer le temps de réunion entre discussion cadrée et parole libre.

L’une des questions que poserait l’introduction d’un ordre du jour, c’est le remplissage de ce dernier. On sait en effet que quand l’organisateur d’une réunion essaye de partir à la pêche aux idées, il y a peu d’écho du côté des participants. Une possibilité serait de récupérer les idées qui n’ont pas été complètement traitées lors d’une réunion pour la réunion suivante.

Pour satisfaire les personnes qui exprimaient, à la réunion sur le fonctionnement du service, une insatisfaction de ne pas savoir ce que font leurs collègues, il a été proposé de faire, au fil des réunions, un tour de table graduel des activités des développeurs, personne par personne. Le format serait très bref, 2-3 slides par exemple.

Il a été remarqué qu’au rythme d’un développeur par séance, comme il y a 12 semaines ouvrées par semestre et la réunion développeurs se produit une semaine sur deux, ce rite de présentations ne concernerait qu’environ 12 personnes par an, et prendrait donc plusieurs années à couvrir l’ensemble des développeurs. Cependant, l’alternative consistant à présenter plusieurs personnes par réunion a aussi été jugée nocive pour la discussion.

Une autre conséquence de ce délai très long est qu’il faudrait bien réfléchir à l’ordre dans lequel on fait passer les gens, par exemple en mettant les personnes qui vont bientôt quitter le LAL en premier. Pour ne pas intimider par une prise de parole forcée, il était proposé de fonctionner sur un mode de volontariat assisté, où Antoine et David partiraient entre deux réunions à la pêche à la bonne personne ou au bon sujet, et les personnes qui ne souhaiteraient pas présenter elles-mêmes leur activité pourraient déléguer la tâche à quelqu’un d’autre.

Formation et milieu universitaire

Développements dans Paris-Saclay

Fabien Cavalier a récemment envoyé un courrier sur les derniers développements en date de l’Université Paris-Saclay. Le premier point qui est clair, c’est que Polytechnique et la plupart des écoles en ont marre, à l’exception notable de l’ENS Cachan.

Par ailleurs, le nouveau document a le mérite d’exprimer plus honnêtement que la raison d’être de Paris-Saclay est l’optimisation du rang au classement de Shanghai.

Dans cette optique, la dernière fantaisie en date du projet est de séparer le plus gros de la formation de licence (le « CUPS ») des filières de Master et de recherche (MàJ du 28-09-2017: ce plan semble aujourd’hui en voie d’enterrement). La tendance est, dans ce cadre, vers un plus grand nombre de PRAGs et de PRCEs. Une autre tendance est de profiter du changement administratif pour essayer d’augmenter les frais d’inscriptions et modifier d’autres statuts.

Formations au développement logiciel

Il y a eu une courte discussion sur l’école 42 lancée par Xavier Niel (Iliad/Free). De l’expérience de développeurs qui ont rencontré leurs anciens élèves, ils tendent à être des hyper-spécialistes qui sont d’une efficacité impressionnante dans leur domaine d’expertise, mais n’ont même pas une vague culture générale des autres facettes de l’informatique. C’est un pari dangereux pour la carrière de quelqu’un.

Une autre particularité de cette école, c’est qu’elle n’exige aucun prérequis en entrée (ce qui n’est pas le cas de formations similaires comme Epita/Epitech), et offre une flexibilité très grande dans le plan de formation qui rend plus difficile la tâche d’évaluer le niveau de sortie des étudiants. Le système encourage assez fortement la spécialisation et l’évaluation des étudiants par leurs pairs.

Dans le périmètre Paris-Saclay, il y a…

• Une licence d’informatique généraliste, qui n’est pas particulièrement fléchée « code ».
• Un IUT qui offre une formation de programmation généraliste, impliquant notamment du C++, du Java et des technologies Web.
• Un DUT plus spécialisé dans la programmation web à Vélizy.
• Joël Falcou, gourou C++ local (anciennement LRI, maintenant plus focalisé sur l’entreprise Numscale), qui organise avec le groupe Calcul des séminaires de niveau avancé sur le C++ moderne.
• Un DUST (Diplôme Universitaire de Sciences et Technologies) que Gérard Marchal a suivi. On ne sait pas si ce diplôme existe encore.
• Polytech Paris-Sud a une filière info.
• Des écoles généralistes comme Centrale qui enseignent notamment de l’informatique.
• Le master de calcul de l’UVSQ, dont David et Hadrien ont plusieurs fois constaté que les étudiants sont fort brillants.

Des éloges ont également été formulés sur la formation de l’UTC (Université de Technologie de Compiègne).

Dénouement du stage de Lucas

Malheureusement, nous n’avons pas réussi à trouver un financement approprié pour la thèse que nous proposions pour Lucas Serrano, visant à permettre le développement de langages spécifiques pour la performance portable et durable en physique des particules.

Nous n’avons pas su remarquer les faiblesses du plan de financement proposé à la base (via les bourses ENS et Télécom Sud Paris), et n’avons pas non plus réussi à rattraper le coup via les financement de Paris Saclay. Le LAL était, quand à lui, prêt à financer la thèse en intégralité si besoin, mais nous avons préféré refuser cette proposition car il était très important pour le bon déroulement de cette thèse et pour la carrière de Lucas par la suite qu’un laboratoire d’informatique soit dans la boucle.

Pourquoi pas la Maison de la Simulation? Parce que cet organisme n’a pas vraiment de financement propre. Ils font financer leurs thèses par l’institut auquel appartiendra le doctorant. Ce qui aurait pu poser quelques problèmes politiques avec les physiciens…

Du côté de Télécom, les gens sont toujours intéressés, et une nouvelle proposition de projet commun est en préparation. Pas mal de développeurs LAL présents étaient aussi intéressés par le rapport de stage de Lucas.

Café LoOPS sur Meson

La veille de la réunion, le mardi 5 septembre, LoOPS a tenu son premier café de 2017-2018. Le sujet était Meson, un système de gestion de configuration et de compilation. Il y avait environ 23 personnes dans la salle.

Meson effectue un travail similaire à celui de CMake et des Autotools. Il se destine principalement à des projets écrits dans des langages compilés (C, C++, Fortran…). Sa fonction est de s’assurer que les dépendances de compilation d’un programme sont présentes sur le système hôte, gérer des différences plus ou moins subtiles entre les configurations système supportées (ex: Linux vs OSX, Clang vs GCC, x86 vs ARM…), et générer en sortie des fichiers de configuration pour IDE (XCode et Visual Studio) ou des scripts de compilation (actuellement au format Ninja) permettant d’orchestrer la compilation proprement dite.

Au niveau des utilisateurs, Meson a rencontré un grand succès dans la communauté GNOME (environnement graphique pour Linux), et il est en cours d’intégration dans d’autres grands projets open-source (Xorg, systemd, Wayland/Weston) en tant qu’option de build secondaire. Pour l’instant, il a surtout du succès comme remplacement des Autotools, mais a plus de difficulté à convaincre les utilisateurs de CMake, outil plus récent et plus proche de Meson au niveau des fonctionnalités.

Voici un résumé des principales différences par rapport à CMake:

• L’outil est beaucoup plus jeune, ce qui a ses avantages (évolution rapide, équipe joignable et à l’écoute) et ses inconvénients (certaines fonctions sont peu matures, comme le support des IDE)
• La gestion de dépendances utilise le standard pkg-config plutôt que des scripts ad-hocs de plusieurs milliers de lignes.
• Si une dépendance n’est pas présente, Meson peut en option aller automatiquement la chercher, la compiler et l’installer.
• Les scripts de configuration sont faits pour être faciles à écrire et lisibles par la suite. Ils sont donc écrits dans un langage déclaratif simple, haut niveau, et volontairement non Turing-complet, avec une syntaxe d’inspiration Python.
• La configuration par défaut est optimisée pour une bonne performance de compilation via l’usage de Ninja, de CCache, des en-têtes précompilés; ainsi que l’interdiction d’utiliser des « wildcards » comme *.cpp qui sont pratiques mais ne passent pas à l’échelle.
• Cette configuration par défaut suit aussi un certain nombre de bonnes pratiques comme l’activation des diagnostics de compilateurs (-Wall) et l’usage d’un dossier de compilation dédié.
• Le support des analyses dynamiques de programmes comme la mesure de couverture de code, les « sanitizers » des compilateurs, ou Valgrind est plus poussé que dans CMake, qui se restreint essentiellement au support des builds de debug et des tests unitaires.

Le langage de script mérite quelques mots de plus, car c’est un des points les plus contentieux de la conception de Meson. Voici les principales choses qu’on peut en dire:

• Il est, dans sa syntaxe, inspiré par Python avec quelques changements mineurs pour adapter aux scénarios de compilation (par exemple, on utilise pour le formatage de texte le caractère @ plutôt que les accolades {}, ce qui réduit la nécessité d’utiliser des séquences d’échappement).
• Bien que Meson soit actuellement implémenté en Python, l’équipe se réserve la possibilité de basculer vers un autre langage si des contraintes comme la performance l’exigent. L’équipe essaie donc de ne pas exposer l’implémentation Python dans l’interface, y compris au niveau des scripts de configuration.
• Pour cette raison, et pour éviter de se retrouver face à des monstres tentaculaires de configuration comme ça peut arriver avec les langages Turing-complet comme le Python de SCons et Waf ou le pseudo-script shell de CMake, Meson essaie de s’en tenir à un langage de configuration minimaliste, qui ne fournit que ce qui est strictement nécessaire. L’import de modules Python arbitraire ou la génération de code de configuration à la volée n’est donc actuellement pas à l’ordre du jour.

Dans un contexte LAL, un autre point de comparaison possible était CMT. Par rapport à ce dernier, Meson met moins l’accent sur la possibilité d’effectuer des requêtes sur la configuration de compilation, et sur son origine. Par exemple, on pouvait dans CMT savoir de quelle dépendance provenait un certain paramètre de compilation, ce qui semble plus difficile voire impossible avec Meson.

Une suite de ce café LoOPS sera probablement proposée sous la forme d’un atelier Meson d’un jour en présence d’un ou deux développeurs de l’outil.

Événements à venir

XLDB

L’édition 2017 de la conférence XLDB, qui discute de grandes bases de données avec un accent sur les problématiques de physique des particules et d’astrophysique, se déroulera à Clermont-Ferrand du 10 au 12 octobre.

Cette conférence se déroule habituellement à San Francisco, mais elle a été organisée en France cette année en reconnaissance des contributions du LPC à l’infrastructure de bases de données de LSST.

Les participants actuellement pressentis sont Grigory, Adrien, Antoine et Christian (ce dernier étant financé par LSST).

Séminaire d’architecture matérielle

Hadrien fera une première présentation d’un séminaire d’architecture matérielle le mercredi 13/09 à 10h30. Le contenu sera principalement orienté vers un public de développeurs, mais peut aussi intéresser une partie du groupe exploitation, car il y a une forte synergie sur certains sujets comme la mesure des performances.

Le principe est de présenter en quoi les ordinateurs modernes s’écartent du modèle de Von Neumann qui est souvent utilisé dans l’enseignement de la programmation, pour quelles raisons, et par là même de dévoiler quelques grands principes pour l’obtention de bonnes performances logicielles sur le matériel moderne.

Si ça a du succès, il y a des évolutions possibles, par exemple une diffusion vers un publique plus large (IPN, webinaire RI3, traduction anglaise pour une utilisation au CERN), ou une évolution vers un format plus « TP » présentant quelques exemples classiques de programmes inefficaces et invitant l’apprenant à les optimiser grâce aux connaissances acquises et à des outils de mesure de performance modernes.

École de programmation fonctionnelle et Apache Spark

Christian est en train de préparer une double formation de programmation fonctionnelle et de traitement de données distribué avec Apache Spark. Cette dernière sera, à terme, gérée comme Action Nationale de Formation (ANF) du CNRS, mais pour la première édition, nous tirerons parti d’un créneau de formation de DevLOG qui a dû être annulé.

La formation se composera de deux parties de trois jours, administrativement indépendantes mais pensées pour former un tout cohérent. La première partie présentera des concepts de programmation fonctionnelle en Python ou Scala (langages préférés pour l’interaction avec Spark), et la seconde partie présentera le traitement de données avec Spark à proprement parler.

La première session devrait se tenir au LAL en janvier 2018. L’intervenant de l’école Apache Spark, très apprécié, sera rappelé, avec un budget temps plus confortable (3 jours au lieu de 2).

MOOC ANSSI sur la sécurité informatique

Philippe rappelle que l’ANSSI a récemment lancé un MOOC sur la sécurité de l’information, appelé « SecNum académie », qui sera en libre accès jusqu’à Avril 2019.

Peut-être de quoi faire un peu de concurrence francophone à l’excellent Introduction to Cyber-Security de FutureLearn, qui est souvent un brin trop britannique dans ses discussions légales!

Organisation des réunions

Antoine a profité de cette réunion pour relancer la question de l’ordre du jour. Par choix, les réunions Dev@LAL n’en ont pas, ce qui a des avantages et des inconvénients.

Un inconvénient qui a été mentionné par le passé est que les gens qui ne viennent pas aux réunions n’ont pas un mot à dire sur le contenu, mais on peut légitimement se demander si ils devraient en avoir un. Un autre travers de la parole spontanée est qu’elle favorise l’expression des individus bavards et à l’aise socialement, ce qu’on pourrait éventuellement contrer en ajoutant des règles de prises de parole, mais au prix d’une perte des avantages de la spontanéité.

La question de la valorisation des compte-rendus a été soulevés. Ces derniers demandent pas mal de travail, et on pourrait avoir envie de les diffuser à un public plus large, à définir. Par exemple à tout le SI, voire au-delà. Antoine avertit cependant qu’une diffusion trop large pourrait amener les personnes à surveiller davantage leurs paroles, et donc à perdre en spontanéité.

Au sein du groupe de développement, certaines personnes sont intimidées par le volume de texte. Pour cette raison, nous souhaiterions un format résumé, ce qui sort de la zone de confort d’Hadrien. Après quelques discussions, la parade a été trouvée: une extension WordPress peut générer automatiquement une table des matières des articles, qui pourra être jointe aux mails annonçant la publication du compte-rendu de la réunion. Serge a mis ça en place (merci!).

Philippe s’interrogeait sur les canaux de diffusion possibles pour des séminaires issues du service informatique, ce qui a soulevé quelques commentaires:

• Les cafés LoOPS ne devraient pas être des séminaires, mais des discussions. David a déjà fait face à des situations où une personne refusait d’organiser un café car elle avait le sentiment de « ne pas connaître le sujet assez pour en parler », et souhaiterait éviter que ce type d’auto-censure ne devienne la norme.
• Serge a rappelé qu’il est possible d’organiser des séminaires internes à l’échelle du LAL.
• Antoine a mentionné qu’en creusant la question du changelog automatique, il a découvert que c’était un sujet assez riche pour mériter un séminaire en soi.
• Christian a rappelé qu’il n’y a pas besoin d’être un grand expert pour présenter un séminaire, juste d’en savoir un peu plus que la moyenne.

Antoine voudrait aussi discuter prochainement de nouveaux outils d’analyse de code statique, comme le Better Code Hub, un outil d’analyse de qualité de code qui se branche sur l’API GitHub et compile différents indicateurs, un peu à la manière de Sonarqube:

• Longueur et complexité des routines
• Absence de duplication
• Simplicité des interfaces publiques
• Modules spécialisés et bien séparés
• Architecture équilibrée (pas de composant-dieu)
• Simplicité générale du code
• Tests automatisés et complets…

Hébergement et noms de domaine

Nous avons récemment reçu un mail de la DSI [1] nous informant que cette dernière propose maintenant un hébergement gratuit des sites web professionnels. Auparavant, ce service était payant.

L’apparition de ce nouvel hébergeur potentiel a lancé une discussion sur l’hébergement du blog sur Apache Spark que Christian Arnault est actuellement en train de monter à l’adresse spark.in2p3.fr.

Christian a considéré deux hébergeurs privés, WordPress.com et Overblog.  Il s’est cependant rapidement heurté aux limitations des fonctionnalités proposées gratuitement par ces derniers. Ainsi, WordPress demandait un paiement pour l’attribution d’un nom de domaine en rapport avec Spark, et Overblog inondait trop les visiteurs de publicités pour un blog professionnel.

Il a aussi pensé à héberger ce blog au LAL. Cependant, ce dernier mettait un trop fort accent sur l’utilisation d’un nom de domaine en .lal.in2p3.fr, dont le périmètre institutionnel restreint déplaisait à Christian du fait de la vocation universaliste de son blog. Serge a clarifié que le problème résidait dans la gestion trop fastidieuse des nombreux noms de domaines extérieurs, qui demandent une maintenance manuelle régulière.

Sur ce sujet des noms de domaines, Christian a mentionné plus tard par mail que le CNRS peut aussi fournir un service de noms de domaine plus général (notamment en .cnrs.fr, et en .fr via RENATER). Michel a cependant rappelé qu’il est nécessaire que les demandes de noms de domaines passent par le groupe exploitation, afin que ce dernier garde une visibilité sur les domaines gérés par le LAL.

Christian s’est ensuite tourné vers le CCIN2P3 [2]. Ce dernier lui a fourni un nom de domaine un peu plus générique en in2p3.fr, mais en revanche ne fournissait pas d’assistance particulière à l’installation et la configuration de sites. Christian a donc dû installer et configurer son installation de WordPress lui-même avec l’aide de Serge et Justine.

Une question qui reste encore à régler est celle des permissions d’édition. Pour l’instant, les gens doivent se créer un compte sur le blog Spark, et demander «manuellement» la permission d’écrire des articles à Christian. Idéalement, Christian souhaiterait que cette permission soit offerte automatiquement à quiconque s’inscrit à la mailing-list Spark, mais cela requiert une intégration entre la gestion de comptes de Sympa [3] et WordPress qui est actuellement perçue comme trop complexe pour en valoir la peine.

ElasticSearch et Kibana

Philippe s’est rendu à l’atelier sur ElasticSearch et Kibana aux JDEV. Il a trouvé ces outils intéressants pour des utilisations de «déboguage des données», par exemple pour chercher des corrélations statistiques ou des anomalies dans ces dernières.

Une application particulière qu’il avait en tête était l’analyse de logs. Il a été remarqué qu’analyser des logs n’est pas une pratique nouvelle, et qu’on l’avait évoqué lors d’une réunion Dev@Lal il y a un an et demi. Il a été aussi remarqué que ce ne sont pas les seuls outils disponibles pour ce travail, par exemple Spark est aussi parfois utilisé pour analyser des logs de serveurs afin de détecter des pannes. Il existe d’ailleurs une passerelle permettant à Spark de manipuler des données via ElasticSearch.

Le sujet de Spark étant invoqué, la discussion a un peu dérivé sur la capacité de MongoDB à gérer des données temporelles comme des logs. En effet, SQL n’est pas très simple à utiliser pour ce type de travail, mais la dimension «temps» est très utile quand on cherche à étudier des anomalies de latence. Christian a expliqué que ce n’est pas une information native en MongoDB non plus, mais qu’on peut éventuellement la gérer au niveau de la couche Spark supérieure.

Dans l’écosystème ElasticSearch, un outil de visualisation qui peut être utilisé pour ce type est Logstash, qui a également été présenté aux JDEV.

Certains des outils liés (X-Pack, lié à ElasticSearch) sont distribués sous un modèle commercial «freemium», avec une version gratuite disposant de fonctionnalités limitées et une version payante donnant accès au jeu complet de fonctionnalités. Quand on utilise ce type d’outil, il est important d’étudier attentivement les limites de la version gratuite et les conditions de licence de la version payante. Il n’est pas rare, par exemple, que la version gratuite soit open source, mais la version payante soit propriétaire.

Christian a mentionné qu’ElasticSearch serait plutôt efficace pour des besoins de recherche multicritère dans des documents texte, et qu’il était utilisé dans ce but par Nuxeo, le moteur d’Atrium. Il est aussi utilisé pour le moteur de recherche Qwant.

Quelqu’un a aussi mentionné que Dominique Mège du CCIN2P3 avait pas mal d’expérience de la mise en place de ce type d’outils d’analyse statistique.

Conteneurs et machines virtuelles

Qu’est-ce qu’un conteneur?

Antoine, David, Hadrien, Michel et Philippe ont suivi l’atelier sur Docker, LXD et Singularity aux JDEV, présenté par Alexandre Dehne Garcia et Martin Souchal. Cela été l’occasion de clarifier un peu la situation de l’écosystème des conteneurs, qui peut être difficile à aborder.

Pour comprendre la notion de conteneur, un bon point de départ est de considérer leurs prédécesseurs spirituels, les machines virtuelles. Pourquoi utilise-t-on généralement des machines virtuelles?

• Pour s’abstraire du matériel et du système d’exploitation «hyperviseur» sous-jacent et exécuter une application basée sur le matériel virtuel et le système d’exploitation de son choix.
• Pour contrôler l’accès de l’application au système d’une façon plus fine que le système d’exploitation sous-jacent ne le permet (par exemple,  dissimuler l’existence de certains matériels).
• Pour exécuter l’application dans une configuration matérielle et système bien contrôlée afin de maximiser les chances qu’elle se comporte comme dans l’environnement où elle a été développée.

Mais a-t-on vraiment besoin de toute la complexité d’une machine virtuelle pour atteindre ces objectifs? Il se trouve que sous Linux, ce n’est pas toujours le cas:

• On a rarement besoin de simuler du matériel qui n’existe pas sur l’hôte (et on souhaite rarement le faire, car c’est très inefficace)
• Il est devenu possible «au niveau système» de dissimuler une partie du système hôte, y compris les processus en cours d’exécution et les périphériques d’entrée-sortie disponibles, avec de nouvelles fonctionnalités du noyau Linux comme les cgroups [4].
• Le noyau Linux évolue assez lentement de nos jours, donc on a rarement des problèmes de compatibilité avec le noyau du système d’exploitation hôte. Les problèmes de compatibilité apparaissent plutôt au niveau de l’environnement applicatif (compilateur, versions des bibliothèques partagées…).
• Par diverses astuces impliquant le système de fichiers virtuel, on peut aisément «greffer» l’environnement applicatif d’un système Linux sur le noyau d’un autre.

L’idée d’un conteneur est donc de dire que lorsqu’on veut exécuter une application Linux sur un hôte Linux, on peut se permettre d’éliminer la complexité d’une émulation/isolation matérielle et d’une duplication du noyau de système d’exploitation hôte, et à la place ne dupliquer que l’environnement applicatif de l’application cible en l’installant par-dessus le noyau du système hôte. C’est ce que fait Docker sous Linux.

Depuis quelques années, Docker est aussi disponible sous Windows et OSX. Mais sous ces systèmes, il ne peut bien entendu fonctionner comme sous Linux, puisqu’il ne dispose pas d’un noyau Linux sous-jacent. Les versions de Docker disponibles sous OSX et Windows ne sont donc en réalité qu’une machine virtuelle Linux sous le capot. Historiquement, cette machine virtuelle était basée sur VirtualBox, mais depuis 2016, Docker peut aussi utiliser les fonctionnalités de virtualisations natives d’OSX et Windows quand on utilise une version de ces systèmes d’exploitation qui propose de telles fonctionnalités.

Docker est par exemple utilisé pour répondre aux besoins de reproductibilité logicielle d’environnements d’intégration continue, ainsi que dans les enseignements du master NPAC. Mais ce logiciel a certaines limitations en termes de sécurité qui freinent son développement dans d’autres domaines, notamment en production sur la grille de calcul ou dans des supercalculateurs…

L’écosystème des conteneurs

Docker a popularisé la notion de conteneur, mais il ne l’a pas inventée et n’en est pas la seule incarnation. Un grand nombre d’alternatives existent, chacune attaquant le problème sous un angle un peu différent.

Ainsi, une critique de Docker qui est souvent formulée par les administrateurs système est que son isolation est très poreuse. Une application s’exécutant au sein d’un conteneur Docker peut très facilement obtenir un accès administrateur au système hôte, et par ce biais avoir accès à des ressources système dont le conteneur est censé l’isoler. Par conséquent, l’isolation fournie par Docker n’est pas suffisante dans des scénarios où on doit exécuter du code auquel on n’accorde pas une confiance totale, comme c’est le cas par exemple lorsque la grille du CERN exécute des programmes d’analyse écrits par des physiciens sans compétence particulière en sécurité informatique. C’est ainsi qu’on se retrouve dans des situations assez absurdes, comme Amazon faisant tourner des conteneurs Docker par-dessus leur infrastructure de machines virtuelles.

Une solution possible à ce problème est Singularity, un système développé pour le milieu des supercalculateurs qui propose une solution de conteneur dans laquelle l’application s’exécute comme processus ordinaire et n’a pas d’accès administrateur au système hôte. Un effort a été fait pour que l’utilisation de Singularity soit similaire à celle de docker (les Dockerfiles étant compatibles), à ceci près bien sûr que l’utilisateur n’a plus le droit d’utiliser des commandes administratives comme «sudo» dans le conteneur. Cette solution semble donc bien adaptée à la conteneurisation d’applications individuelles nécessitant peu de privilèges système et auxquelles on n’accorde qu’une confiance limitée, ce qui devrait bien correspondre aux besoins de l’informatique scientifique.

Pour ceux qui auraient besoin d’exécuter des applications plus complexes nécessitant un accès plus poussé au système, et ne pouvant donc se satisfaire d’un conteneur limité à l’exécution d’applications non privilégiées, un projet peut être plus intéressant est l’extension de l’infrastructure LXC (LinuX Containers), historiquement utilisée par Docker et CoreOS, via une nouvelle surcouche appelée LXD. Contrairement à Docker, cette plate-forme se destine plutôt à la virtualisation de systèmes complets que d’applications isolées. Entre autres choses, elle vise à offrir de meilleures performances quand on lance de grands nombres de conteneurs, proposer une gestion fine des privilèges système accordés aux conteneurs, et permettre de migrer plus facilement des conteneurs d’un système à l’autre. Elle est donc à première vue mieux pensée pour des déploiements de conteneurs complexes, en production et à grande échelle.

Au-delà des conteneurs actuels

Si les technologies de conteneurs disponibles aujourd’hui sont plus légères et éliminent pas mal de complexité quand on les compare à des machines virtuelles, elles sont cependant encore loin d’atteindre l’efficacité du gestionnaire de paquet natif d’une distribution Linux moderne. Le trafic réseau important engendré par la nécessité de recopier l’équivalent de l’environnement applicatif complet d’un système d’exploitation est notamment un problème, qui limite l’application de ces technologies dans des contextes où la bande passante est limitée, par exemple lorsqu’on organise des TPs basés sur des conteneurs dans des locaux dont la connexion réseau n’est pas dernier cri.

En principe, Docker pourrait répondre à ce problème, car il permet d’ajouter des changements incrémentaux à une image existante et de ne transférer que ces changements si le client possède déjà une copie de l’image de base. Mais en pratique, l’absence de standardisation des images «mères» et la jeunesse de la technologie font que cette possibilité est difficile à exploiter en pratique.

En réponse à ce problème, diverses solutions ont été proposées. Une approche particulièrement prometteuse est d’adapter le concept de gestionnaire de paquet pour lui permettre de mieux répondre aux besoins de reproductibilité logicielle, via un contrôle plus fin des dépendances. Cette approche est poursuivie par les gestionnaires de paquets Nix et Spack, le premier se voulant plus généraliste et le second plus orienté vers les besoins du calcul haute performance.

Antoine a précisé par la suite que le tutoriel Nix présenté aux JDEV est en ligne à l’adresse https://gricad.github.io/calcul/nix/tuto/2017/07/04/nix-tutorial.html, et qu’il est possible de le rejouer en environ 3h.

Une autre évolution, matérielle celle-ci, qui a le potentiel de changer beaucoup l’utilisation qu’on a des conteneurs est Intel SGX (Software Guard eXtensions). C’est une technologie qui vise à permettre aux applications de créer des régions mémoires protégées, inaccessibles au système d’exploitation sous-jacent. L’isolation est assurée en ne conservant les données en clair qu’au niveau du CPU, en limitant drastiquement l’accès à ces données au sein du CPU, et en chiffrant toute donnée destinée à être stockée en RAM.

En principe, cela devrait permettre par exemple de sécuriser les applications de type «cloud» où l’on fait tourner du code sur des serveurs sur lesquels on n’a aucun contrôle et qui sont potentiellement sujets à espionner ce qui se passe. Ce propos optimiste doit toutefois être nuancé en mentionnant ce système possède aussi plusieurs caractéristiques nettement plus discutables:

• Pour déployer une application SGX en production (c’est-à-dire supprimer l’accès aux régions mémoires protégées offert à d’autres applications pendant la phase de débogage), il faut obtenir une licence d’Intel, représentée logiciellement par une signature cryptographique dont l’autorité de certification racine est Intel. Selon le brevet américain 8 972 746 d’Intel, c’est une décision de conception volontaire, visant à permettre l’émergence de nouveaux modèles commerciaux («is an enforcement point for a number of new business models»). Le brevet évoque ensuite de façon répétée le potentiel lucratif de la chose pour Intel.
• Comme il est également expliqué dans ce brevet, une application ainsi authentifiée par Intel peut, si Intel lui en donne la permission, aussi avoir accès à des secrets cryptographiques stockés au sein du processeur, tels que la clé «Enhanced Privacy ID» (EPID). Cette clé de chiffrement, écrite en dur dans chaque processeur et donc non révocable, est au coeur de la sécurité de SGX, et une telle application possède donc la capacité de briser la sécurité de SGX (et potentiellement celle d’autres technologies hardware de sécurité des processeurs x86).
• De nombreux aspects de l’implémentation de SGX qui jouent un rôle essentiel pour sa sécurité ne sont pas documentés par Intel. Comme Costan et Devadas l’expliquent dans leur analyse de SGX publiée en 2016, cela empêche une analyse extérieure complète de la sécurité de ce système. C’est problématique, car cela signifie que seuls les ingénieurs d’Intel sont en mesure de dire précisément quelles sont les limites de la sécurité du système SGX, or il n’est pas dans leur intérêt commercial de le faire.
• SGX est, dans sa conception même, vulnérable à de nombreuses attaques de type «side-channel» accessibles à d’autres logiciels tournant sur le même système hôte. Ainsi, une attaque par minutage de cache permettant d’accéder en 5 minutes à 96% des 4096 bits d’une clé cryptographique RSA censée être protégée par SGX a été publiée cette année. Comble de l’ironie, le logiciel attaquant utilisait également SGX pour dissimuler son activité malveillante du système d’exploitation hôte.
• Comme toute extension x86, SGX ne restera pas éternellement spécifique au milieu des gros datacenters, mais finira à terme par atterrir dans des processeurs grand public. Sur ces derniers, il est à craindre que sa principale application ne soit l’implémentation de systèmes de type DRM, visant à donner aux géants du multimédia un contrôle total et centralisé sur les oeuvres qu’ils distribuent. Cette utilisation a été explicitement prévue par Intel, comme ils l’expliquent dans le brevet susmentionné en mentionnant comme cas d’utilisation un lecteur de vidéos. Or, la généralisation de DRMs protégés au niveau matériel a des implications inquiétantes en termes d’interopérabilité des logiciels libres, de censure politique des contenus numériques, et de pérennité des oeuvres artistiques.

Glossaire

1. Direction des Systèmes d’Information du CNRS, qui gère les services informatiques centralisés comme Agate et Janus.
2. Centre de calcul de l’IN2P3.
3. Sympa est un système de gestion de mailing lists très utilisé dans la communauté de l’enseignement supérieur en France.
4. Les cgroups sont une fonctionnalité du noyau Linux permettant de manipuler des groupes de processus en leur imposant des restrictions communes, par exemple un budget total de RAM ou la (non-)visibilité des interfaces réseau.

En l’absence de notre secrétaire de séance, les notes sont succinctes …

Les 3 principaux sujets évoqués et/ou âprement discutés :

1. Existe-t-il des outils pour versionner des documents Excel ?
   Jean-Noël souligne la différence entre gérer l’historique et visualiser les différences entre version.
2.  Nouvelles d’ATLAS à la suite de la Software Week de Valence (España)
   Julius, Justine y ont présenté leur travail.
   Grigory évoque les discussions à propos de l’analyse des logs avec les outils récemment choisis par ATLAS :
   • ElasticSearch, moteur de recherche et d’analyse distribué et performant
   • Kibana, un plugin de visualisation pour ElasticSearch
3. Discussion à propos des fichiers « ChangeLog »
   Pourquoi et comment les générer, quels liens avec les messages de « commit » …

Nous convenons qu’Antoine présentera une intro à la gestion des ChangeLog et aux conventions de message de commit

Le sujet principal de cette réunion développeur était une présentation concernant le contrôle-commande du vide dans l’expérience VIRGO, mais elle a aussi été l’occasion de présenter Nicolas Loizeau, stagiaire L3 fraîchement arrivé dans le service.

Continuer la lecture de Réunion du 14 juin 2017 →