Windows Subsystem for Linux

Avec les dernières mises à jour de Windows 10, il est possible d’ajouter un support de l’API Linux au noyau Windows, le Windows Subsystem for Linux (WSL). Cela rappelera peut-être aux anciens des souvenirs des Windows Services for Unix il y a 20 ans.

WSL permet d’exécuter des applications Linux sous Windows avec des modifications et des coûts en performance très faibles (pas d’émulation matérielle, juste une traduction d’API). Même si l’analogie a ses limites, cette technologie est comparable à Wine, qui permet l’exécution d’applications Windows sous Linux.

Il n’y a pas d’émulation matérielle, donc le système Linux invité (plusieurs distributions Linux sont utilisables) voit les fichiers du système Windows hôte et vice-versa. La traduction d’API peut cependant avoir d’autres coûts, par exemple en termes de performance (émuler un système de fichier Linux a un coût) ou de fonctionnalités (jusqu’à récemment, il n’était même pas possible de lancer une application Linux en tâche de fond).

Malgré ces limites, le Windows Subsystem for Linux est globalement très apprécié par tous les utilisateurs habitués à jongler entre les deux mondes qui l’ont essayé. On a même réussi à y faire tourner Apache Spark !

Spark et LSST

Les utilisateurs LSST sont désormais conscients du problème de passage à l’échelle inhérent à cette expérience, mais ne sont pas encore convaincus que l’outil actuel ne peut pas passer à l’échelle et que si il faut changer d’outil, Spark est la bonne solution.

Un Data Challenge va prochainement être organisé dans LSST.  Il faudra alors démontrer, sur un grand jeu de données  (0.5 milliards de fichier, O(500) TB), que Spark est une alternative viable au pipeline précédemment envisagé.

Actuellement l’injection des données prend 1 semaine, car il faut passer par une conversion en CSV avant injection. Au NERSC, il a été montré qu’on peut traiter 1 To de données en 2 secondes sur 1000 cœurs.

Des jeux d’essais unitaires ont été faits précédemment, à l’époque où la France n’était pas impliquée. Ils permettront de valider que la solution est au moins aussi bonne que l’ancienne et donc rassurer les personnes responsables, mais pour l’instant aucun essai n’a vraiment validé le passage à l’échelle.

Toute personne intéressée souhaitant participer à ce projet est la bienvenue.

Parmi les difficultés attendues, on sait que l’algorithme actuel ne peut être distribué, et que la compression de données n’est pas suffisante pour être utilisable. Un pis-aller actuel est donc de compresser en zip, puis déplacer le fichier vers sa destination.

Julius indique que Grigori a mis en place une compression Hadoop très rapide au niveau 10. Cela pourrait être un argument pour plaider une sortie au format Hadoop.

Evénements

ANF programmation fonctionnelle

La proposition, principalement portée par Antoine, visant à organiser une ANF CNRS en 2019 sur le thème « La programmation fonctionnelle dans notre vie de tout les jours » a été acceptée!

Le programme prévisionnel est de faire 1 ou 2 jours de théorie dans un langage fonctionnel pur (type Haskell/OCaml), et 1 ou 2 jours plus pratiques centrés sur les utilisations du paradigme fonctionnel dans nos environnements et langages de tous les jours (C++, Python…).

La formation inclura notamment des exercices de refactoring de code impératif dans un style plus fonctionnels, ainsi que des études de cas où il est pertinent de le faire.

Prochain café LoOPS

Le café LoOPS du mardi 3 juin sera centré sur la RGPD, une réforme européenne des lois informatique et libertés. Il sera animé par un membre de l’association de libertés civiles La Quadrature du Net.

En parallèle, un webinaire RI3 est organisé la même semaine pour présenter du point de vue institutionnel du CNRS sur cette question.

Formation Git

Hadrien anime ce 30 mai et le 1er juin une formation Git dans le cadre de la formation permanente d’Île de France. Les slides et autres matériaux sont en lignes sur owncloud :
https://owncloud.lal.in2p3.fr/index.php/s/YrK8dADMGEQfaP3

David en a fait un portage « piscine », qui est en ligne sur
https://gitlab.in2p3.fr/MaitresNageurs/GenieLeaugiciel/

A ceux qui se demandaient si ça vaut le coup d’en faire un format plongeon, il a répondu que les TPs « portés » sont déjà presque des « plongeons ».

Piscines aux JIs 2018

L’offre de piscines s’étoffe sur https://gitlab.in2p3.fr/MaitresNageurs/GenieLeaugiciel/ .

Chacun est encouragé à y apporter les contributions qu’il souhaite et à signaler tout sujet manquant.

Ateliers Docker

Les heures Docker se sont bien passées. Les retours des participants sont bons, ils trouvent que David a fait du bon boulot !

Nicolas Leroy a apprécié, et voudrait d’autres formations de ce style sur des sujets informatique.

Une possibilité serait d’organiser une formation Git à partir du matériau produit par Hadrien.

Serge rejoint SVOM

Serge rejoint l’équipe SVOM pour contribuer au segment « au sol » de l’expérience.

Le lancement du satellite est actuellement envisagé courant 2021.

StackOverflow

Présentation

StackOverflow est un site de questions-réponses collaboratif, qui se positionne sur des questions concrètes de développement logiciel. Il se distingue en celà des autres sites de la famille StackExchange, qui sont davantage centrés sur des questions d’ingénérie logicielle, de conception, de qualité… ou bien qui sont plutôt définis par un environnement technologique comme « Android », « Linux », ou « la sécurité informatique » que par la pratique du développement logiciel.

Avantages

Christian trouve que la fréquentation de StackOverflow est un bon complément pratique à l’étude théorique du langage de programmation, car elle est plus adaptée pour répondre aux question que l’on se pose quand on a les mains dans le cambouis. Par exemple « Je veux faire X dans mon code, comment dois-je procéder ? », ou bien « Quelles bibliothèques conseillez-vous dans le langage X pour le domaine métier Y ? ». C’est particulièrement vrai dans un cadre d’autoformation, où on n’a guère l’occasion d’interroger ses enseignants.

Le principal avantage de StackOverflow est sa taille. Il s’agit sans doute de la plus grande communauté de développement logiciel sur internet, et le site a accumulé au fil des années une base de connaissances immenses. Quand on fait une recherche sur un problème de développement logiciel sur internet, il est courant que StackOverflow soit le premier résultat du moteur de recherche, et qu’il contienne effectivement la réponse juste. Et quand la réponse n’est pas encore là, on sait que toute question posée sera vue par une audience gigantesque, au sein de laquelle il y a de fortes chances de tomber sur une personne qui connaît la réponse. Bien entendu, comme dans tout site de questions-réponses, la qualité des réponses dépend aussi beaucoup de celle de la question…

Globalement, les utilisateurs de StackOverflow sont très satisfaits. C’est devenu un outil incontournable dans le monde du développement logiciel, même en tant que « simple lecteur » qui ne pose pas de questions et ne soument pas de réponses. Que l’on tombe dessus par simple recherche web, que l’on contribue directement au site ou que l’on s’abonne à des alertes régulières sur un sujet donné comme Antoine, l’utilisation est facile, le contenu est copieux et de qualité élevé, et le site a globalement tiré chacun d’entre nous de plus d’un mauvais pas.

Inconvénients

Au niveau des défauts, l’utilisation excessive de StackOverflow tend à créer chez le développeur une certaine paresse intellectuelle, où l’on finit par copier-coller du code de réponses que l’on ne comprend pas sans ouvrir la documentation, réfléchir et se demander si il est optimal ou adapté à la situation. La pratique est suffisamment répandue pour avoir gagné le surnom moqueur de « StackOverflow-oriented programming ». Bien entendu, il ne s’agit pas vraiment d’un problème lié au site et que ce dernier pourrait corriger, mais plutôt d’un travers de la société qui s’est construite autour du site.

La grande taille et le long historique de StackOverflow ont aussi quelques inconvénients. Par un système de ludification, le site encourage très fortement les utilisateurs à soumettre des réponses aux questions, mais n’offre qu’un contrôle relativement faible de la qualité des réponses. Quand on combine cela au grand nombre d’utilisateurs, il vient naturellement qu’une question populaire va avoir un grand nombre de réponses, de qualité très variable, et qu’un certain nombre de recherches seront nécessaires pour faire le tri. Et comme le site existe depuis longtemps, et gère mal le vieillissement des réponses, il n’est pas rare de tomber sur des réponses anciennes obsolètes que personne ne s’est chargé de corriger. A ce niveau, l’inertie communautaire liée au système des votes est aussi un problème, car elle s’adapte mal aux changements dans le milieu technologique extérieur.

La gestion des droits utilisateurs et de la modération, basée sur un système de réputation, est très encadrée à un degré qui frise parfois le psychorigide. Les nouveaux utilisateurs ne peuvent faire que peu de choses sur le site, et les habitués ayant accumulé une grande quantité de pouvoir par leur fréquentation régulière du site sont rarement très tendres avec les débutants. On est autant jugé sur la forme que sur le fond, de nombreux sujets de conversation (notamment tout ce qui relève d’un jugement de valeur) sont complètement bannis du site, et la chasse au doublon se fait souvent sans pitié. Globalement, les « experts » historiques ont souvent un comportement peu aimable voire très dominateur, c’est une des principales critiques du site à l’extérieur. Mais bien sûr, il y a des exceptions.

Un mot sur les auteurs

Le site StackOverflow a été cofondé par Jeff Atwood et Joël Spolsky, deux illustres bloggeurs de la première heure dans le monde Microsoft, auteurs respectifs des blogs Coding Horror et Joel on Software. Parmi les autres réalisations de ces développeurs, on peut aussi mentionner:

• FogBugz, une forge logicielle supportant Git, Mercurial et SVN
• Trello, un outil de gestion de projet par tableaux inspiré par la méthodologie Kanban
• Discourse, un système de forums utilisé par exemple par la communauté ROOT

Conférences

Budget missions du SI

Le service informatique du LAL possède un budget pour financer toutes sortes de missions, qu’il s’agisse d’aller à des conférences ou d’accélérer un projet en passant une semaine avec les développeurs principaux.

Ce budget est géré selon l’idée que si on se déplace principalement pour le compte d’une expérience de physique, il est approprié de mettre la mission sur le compte de l’expérience correspondante, mais qu’il existe tout un tas d’activités du SI qui sont soit trop transverses, soit trop « informatique » pour qu’aucune expérience précise ne s’y identifie. Le SI finance volontiers ce type de missions.

Dans cette optique, Michel recense actuellement qui souhaite se rendre à CHEP et aux JI.

CHEP

Nous avons déjà parlé de CHEP dans des éditions précédentes de cette réunion. C’est sans doute la plus grande conférence d’informatique et de logiciel pour la physique des particules, et elle est organisée tous les deux ans et dont le lieu tourne entre l’Europe, les Etats-Unis, et le reste du monde. Cette année, elle est organisée à Sofia, en Bulgarie.

L’inscription à CHEP est chère par rapport aux habitudes du monde de la physique et du milieu académique (500 €), mais ces frais ne sont pas forcément excessifs si on les met en parallèle avec d’autres conférences d’informatique. Pour donner quelques exemples, l’inscription à la conférence GTC du fabricant de processeurs graphiques NVidia coûte près de 2000 $, et même des conférences informatiques organisées par des sociétés savantes comme l’ACM (SIGGRAPH, Supercomputing…) voient leurs frais d’inscription sans réduction monter à plus de 600 $.

JIs

Les JI sont un autre rendez-vous dont l’esprit est très différent. Il s’agit des Journées Informatiques de l’IN2P3 et de l’Irfu, qui rassemblent à l’échelle nationale des personnels informaticiens du CNRS et du CEA travaillant sur des thématiques « univers et particules », via le réseau RI3. L’atmosphère est plutôt détendue, avec un programme mêlant présentations informelles et ateliers pédagogiques, et les frais sont presque tous pris en charge par les tutelles à l’exception du transport. Le cadre est généralement un centre de vacances du CAES en morte saison, le comité de programme parvient à n’avoir que 2-3 sessions en parallèle sans faire une sélection très stricte, et globalement l’idée est plutôt de prendre un moment pour se poser et voir ce que font les collègues de l’autre bout de la France.

Bien sûr, cela ne veut pas dire pour autant qu’il n’y a rien à préparer. En particulier, les animations pédagogiques comme la piscine (dont on a parlé dans les réunions précédentes) nécessitent une bonne dose de matériau et de main d’oeuvre, dont la préparation est généralement lancée quelques mois à l’avance. A ce niveau, David reconnaît que le nom de « Pépé Nageurs », qu’il proposait pour la prochaine édition des piscines, n’est pas forcément idéal (selon la personne qui le lit, il peut être lu comme sexiste, comme un « sale vioque », etc…). On trouvera mieux. Il rappelle aussi que les JI n’excluent pas des formats de formation plus longs que la piscine, qui sont plus adaptés par exemple à l’exploration en profondeur d’un sujet, ou bien à l’utilisation d’une infrastructure qui ne se VM-ise ou containeur-ise pas.

Avenir d’ACAT

Pour terminer sur le sujet des conférences, Julius s’inquiète du devenir de la conférence ACAT.

Pour ceux qui ne seraient pas familier de cette dernière, il s’agit d’une conférence d’informatique en physique des particules, beaucoup plus petite que CHEP et plus centrée sur les questions de logiciel, avec quelques sous-domaines de prédilection comme l’apprentissage automatique (qu’ils traitaient avant que ce soit la mode). Les habitués trouvent ACAT plus agréable que CHEP, car cette conférence a une atmosphère plus « humaine », moins « usine ».

Le coeur du problème est que l’organisation de la conférence a historiquement été fortement portée par Federico Carminati, or ce dernier…

• Approche de la retraite et doit passer la main, avec les risques que cela entraîne.
• Ne serait, selon Julius, actuellement plus en odeur de sainteté dans la communauté des développeurs CERN.

Au coeur du second problème se trouve le projet de simulation HEP parallèle et vectorisée GeantV. Ce dernier se place en concurrence avec le standard actuel de la simulation, Geant4, ce qui fait qu’il n’est naturellement pas vu d’un très bon oeil par les experts de cet outil. Et dans ce contexte tendu, le caractère peu diplomate de Federico ne fait que jeter de l’huile sur le feu.

Ce conflit est devenu particulièrement apparent lors de la revue du projet GeantV par HSF, principalement assurée par des experts Geant4, dont les conclusions n’accordaient de crédit qu’aux seuls aspects du projet qui peuvent être aisément réintégrés à Geant4, et se montraient critiques sur tous les autres aspects. Or, s’il va de soi qu’une telle intégration est extrêmement désirable lorsqu’elle est possible, puisqu’elle permet une validation du code GeantV au sein des simulations des expériences, il est évident que favoriser ces aspects au détriment des innovations de rupture de GeantV est unilatéralement à l’avantage du projet Geant4 dans un contexte de compétition entre ces deux projets.

C’est cette lutte intestine, jusqu’à présent plutôt à l’avantage de Geant4 (qui possède un plus grand soutien des expériences), qui amène Julius à s’interroger sur la capacité de Federico à maintenir une force politique au CERN suffisante pour assurer le devenir d’ACAT. Du côté des éléments plus rassurants, on peut cependant noter que…

• La section simulation Community White Paper de HSF a été rédigée d’une façon qui respecte davantage le point de vue des développeurs de GeantV, et présente une vision plus conciliante de l’avenir des deux projets.
• Il y a déjà eu, avec ROOT, un précédent dans l’histoire du CERN où une innovation de rupture logicielle a été d’abord violemment rejetée, en compagnie de son créateur, mais finalement réintégrée.

Système de classement de tutos

Le groupe Dev@Lal souhaiterait recenser les bons didacticiels disponible en ligne et rendre les siens plus visibles. Le classement hérarchique gère mal les sujets « transverses ». Un système de mots-clés semble plus adapté pour ce cas, et David aimerait bien embaucher un stagiaire en développement web pour se fabriquer un tel « trieur de tutos ».

Le sujet a été lancé à l’IUT. Si des membres connaissent d’autres formations en développement web, David est intéressé par l’information. Pour initialiser cet index, un grand nombre de contenus sont disponibles sur la cellule webcast du CC IN2P3, les sites des JDEV (2017, 2015, 2013 et 2011) et le site LoOPS.

Github possède un système de tri par étiquettes intégré, et l’instance Gitlab du CERN et du CC IN2P3 semble proposer une fonctionnalité similaire ( -> Settings -> General). Mais l’information correspondante semble mal intégrée à l’interface actuellement : ajouter des mots-clés à un projet n’a pas d’effet apparent…

Il y a un équilibre entre faire les choses soi-même et utiliser une solution clé-en-main. On peut faire mieux soi-même en y consacrant suffisamment de temps, mais la main-d’œuvre est une denrée très précieuse. Un stage fournit temporairement de la main-d’œuvre, mais la maintenance et l’évolution future sont incertaines. De plus, un stage est court, or les projets logiciels débutent souvent en 5 minutes pour la première version mais nécessitent 10 ans pour la version finale…

C’était aussi un sujet de discussion au dernier café LoOPS sur le développement de jeu vidéo : utiliser un moteur de jeu tout fait a un coût en termes de flexibilité. A ce sujet, Julien et Serge mentionnent qu’un bon compromis est souvent de partir d’un projet tout fait open-source, et de le modifier pour l’amener à ses besoins.

Nouveaux entrants et valorisation

Julien a participé le 20/03 à la journée des nouveaux entrants du CNRS.

Le début n’était pas passionnant, avec une table ronde qui ne tournait pas rond: les questions/réponses étaient clairement préparées et répétées à l’avance. Une intense phase de lobotimisation du type « regardez c’est génial, on s’aime tous et on travaille tous ensemble ».

La suite s’est révélée plus intéressante, avec entre autre des présentations sur la propriété intellectuelle, les brevets, les licences logicielles, … L’accent a été principalement sur les thèmes scientifiques, les sciences sociales étant un peu ignorées. Antoine mentionne tout de même qu’il existe plusieurs projets informatiques en sciences sociales, tels que la constitution de bases de données (par exemple le TGIR huma-num).

Julien note qu’il existe une volonté d’aider et de financer les projets interdisciplinaires, et en lien avec l’industrie, favorisés par la politique actuelle. Ces ressources sont souvent méconnues des agents. En même temps, Julien doute de cette démarche puisque lui même a passé 3 ans dans une équipe interdisciplinaire (physique, stat, info), où la recherche de financement était une difficulté comme partout ailleurs (sempiternelle réponse: pourquoi des physiciens iraient financer des projets informatiques alors qu’ils n’arrivent même pas à financer des projets de physique, et vice-versa?).

Il existe un « pôle CNRS innovation » : c’est une société privée qui travaille pour le CNRS, en faisant du conseil et de l’accompagnement de création d’entreprises. C’est gratuit pour l’utilisateur, il y a un formulaire d’inscription simple et sans engagement avec post-traitement donnant soit une réponse «Non» (refusé), soit «peut-être mais» (on accompagne et on décidera plus tard) soit «Oui».

On peut créer une structure au sein du CNRS ou bien chercher un partenariat avec le privé. Le pôle CNRS innovation (en lien avec le service valorisation) gère les questions de droit d’auteur et s’occupe de faire des études de marché.

Christian se demande d’où vient l’argent qui paye ces gens ? Mais la réponse n’est pas connue… Il y a 45 personnes dans la structure CNRS innovation, et plusieurs antennes dont une à Saclay (en lien avec les SATT).

Nouvelles bases de données

Du côté ATLAS, il y a eu une discussion autour de l’utilisation éventuelle de Kudu dans l’Event Index. Les avis sont partagés: Dario est enthousiaste, mais Torre (le chef du computing ATLAS) n’est pas motivé. Du côté LAL, Julius trouve que c’est de la complexité inutile.

Kudu est une nouvelle BDD pour Hadoop, column-wise, non-relationnelle mais avec une interface SQL. Ça devient courant, probablement davantage pour des raisons de familiarité et de réutilisation que de réelle adéquation au domaine.

Christian voit aussi ça avec les dataframes, qui utilisent de requêtes SQL pour exploiter les optimiseurs existants. Au-delà de quoi Spark optimise aussi le pipeline entier, le réordonne…

David trouve que c’est une discussion intéressante dans le cadre de nos discussions sur les DSL de calcul. SQL, un DSL qui a réussi, serait-il finalement vu comme moins désirable ? Hadrien pense qu’il y a un continuum entre langage généraliste et langage spécifique à une application très précise, et que SQL vire généraliste.

Antoine mentionne qu’un intérêt de SQL, en combination avec le modèle relationnel, est qu’on peut faire des prédictions sur l’utilisation des données, basées sur des modèles mathématiques précis de l’usage. Une raison pour laquelle les BDD orientées objet comme Objectivity n’ont pas eu trop de succès, c’est que SQL a plusieurs propriétés désirables comme la possibilité de prouver la finitude d’une requête.

Julius trouve qu’il y a aussi un problème de l’évolution de schémas : l’objet est fait pour permettre des changements faciles de l’implémentation derrière une interface stable, mais les BDD n’aiment pas les changements de schémas…

Les « anciens » du service, comme Serge et Jean-Noël, se souviennent encore de BaBar, où l’expérience a fini par assumer elle-même la maintenance de la BDD Objectivity. Aujourd’hui, cette peur revient avec MongoDB, où il n’y a pas de garantie que le modèle soit stable…

Divers

Le groupe SVOM récupère l’ancien stagiaire d’Oleg. Ce dernier est en effet perdu pour la science, il partira faire de la blockchain dans l’industrie dans quelques mois.

Il y a pas  mal de musiciens dans le SI, en fait: Oleg joue de la trompette, Guy Barrand et Christian Helft avaient fait une session guitare il y a quelques années, Christian Arnault chante, David a joué du basson, Hadrien du piano et de la flûte…

Avenir des piscines

Lors des dernières JI (Journées Informatiques de l’IN2P3 et de l’IRFU), en 2016, un nouveau format pédagogique avait été essayé: la « piscine ». C’est un format dont on a entendu parler car il est pratiqué à l’EPITA, qui a inspiré par la suite l’école 42. Il s’agit de proposer des tutoriels sur un format de 20-25 minutes, appelés « plongeons », ayant vocation à être utilisables de manière plus ou moins autonome, chacun travaillant sur sa propre machine. L’idée n’est pas de faire un cours, mais de se familiariser rapidement avec une nouvelle technologie à laquelle on ne souhaite pas accorder un grand budget temps. La limite de temps d’environ 20 minutes est choisie pour coller au temps maximal pendant lequel une personne peut se concentrer en continu : si l’on a davantage de choses à dire que cette limite de temps ne le permet, il faut découper en plusieurs plongeons.

Les prochaines JI ayant été annoncées pour octobre 2018, il est temps de se demander ce que l’on va faire de ces tutoriels, actuellement disponibles sur le dépôt « PiscineJI » du Gitlab du CCIN2P3. Est-ce qu’on se contente d’un nettoyage des tutoriels existants, sans rien changer d’autre ? Est-ce qu’on renomme le dépôt existant en « PiscineJI2016 » et on crée un nouveau dépôt pour les plongeons 2018 ? Est-ce qu’on conserve une organisation basée sur un dépôt unique, ou est-ce qu’on change d’organisation pour l’occasion ?

La première chose à faire semble être de tester les plongeons existants pour voir si ils fonctionnent encore. A priori, on souhaite préserver tous ceux qui sont fonctionnels, ou que l’on peut remettre en service facilement. Par la suite, il serait peut-être pertinent d’avoir plusieurs dépôts de plongeons thématiques à l’avenir, au lieu d’un dépôt unique, car ce dernier est rapidement devenu un grand fatras, tant dans sa hiérarchie de fichiers que dans son historique Git. Dans cette optique, David a déjà lancé deux nouveaux projets GitLab liés au Master-Projet IN2P3 DécaLog :

• Le premier projet est centré sur les conteneurs (ex: Docker, Singularity…). Il s’appelle « EnBarque » car l’idée est que l’on essaie d’aller dans l’eau en se mouillant moins. Ce dépôt de tutoriels est lié par ses thématiques au projet IN2P3 ComputeOps et à l’école d’informatique en cours d’organisation par Cécile Cavet (voir ci-après).
• Le second projet est centré sur les problématiques et technologies liées au calcul numérique (ex: kokkos, xtensor…). Il s’appelle « NatationSynchronisee » et se rapproche, dans ses thématiques, du projet IN2P3 Reprises.

Une autre piste serait de développer de nouveaux plongeons. Par exemple, Julien et Christian sont attendus au tournant pour le développement d’un plongeon Scala/Spark. Pour ceux qui seraient intéressés, les activités liées à la piscine sont regroupées au sein du groupe « MaitreNageurs » sur le GitLab du CCIN2P3, et il suffit de contacter David pour en devenir membre.

Il existe aussi, depuis la création du format piscine, une ambiguïté quand à sa mise en pratique. Veut-on, au-delà de son utilisation présentielle dans une session dédiée des JI, le promouvoir comme un didacticiel en ligne utilisable à tout moment de l’année ? Sur le principe, ça semble être désirable, mais le diable est dans les détails :

• Que veut-on faire des sujets qui ne peuvent pas être enseignés à distance parce qu’ils nécessitent une infrastructure ou un matériel dédié ? (ex: Arduino)
• À partir du moment où l’on prévoit cette utilisation ex-situ, au rythme de l’apprenant, l’utilisation d’un format segmenté par 20 minutes ne devient-elle pas une contrainte arbitraire ? En effet, il a déjà été observé que ce format peut décourager certains enseignants potentiels, car il n’est pas toujours simple de faire tenir un savoir dans un ou plusieurs blocs de 20 minutes…
• Si l’on se dirige vers de l’enseignement à distance, n’existe-t-il pas des technologies plus adaptées que notre combinaison image Docker + dépôt GitLab actuelle (ex : notebooks, plate-formes MOOCs) ? Et à l’inverse, un tutoriel pensé pour un usage autonome est-il optimal en présentiel ? N’est-il pas difficile de préparer un tutoriel qui soit adapté aux deux situations ?
• Si l’auto-formation est jugé préférable, doit-on continuer à préserver un créneau horaire dédié pendant les JI pour les piscines « présentielles » ? Ou bien est-ce que les JI pourraient n’être qu’un point de ralliement pour fixer une date limite à la préparation des plongeons et faire de la pub pour ces derniers ? En d’autres termes, les avantages du format présentiel compensent-ils ses inconvénients ?

Plus généralement, on se rend compte dans cette discussion qu’il y a un important besoin de veille technologique, de formation, et d’assistance autour de l’enseignement en ligne et de l’auto-formation. C’est un sujet complexe, qui part des questions de portabilité du code (machines virtuelles, conteneurs, et leurs limites dans des scénarios nécessitant un contrôle fin sur le matériel et le système), et s’étend jusqu’aux nouvelles technologies pour l’enseignement en ligne comme les notebooks et les MOOCs. Sur ces dernières technologies, il y a aussi des questions d’infrastructures: on ne peut plus se contenter de dire aux gens d’installer Docker ou VirtualBox et de télécharger une image, il faut aussi souvent préparer et maintenir des serveurs équipés de plate-formes logicielles complexes avec la charge supplémentaire que ça implique pour l’exploitation. Un exemple type à ce niveau est celui du notebook en ligne: derrière son apparente simplicité, ce format nécessite l’installation et la maintenance d’un logiciel dédié par langage de programmation supporté (voire un système de notebook à part comme dans le cas de Zeppelin pour Scala + Spark), ainsi qu’une infrastructure de machines virtuelles pour les TPs nécessitant des manipulations shell.

En parlant de machines virtuelles, d’ailleurs, un autre problème que l’on doit régler dans le cadre de nos activités d’enseignement est le trafic réseau occasionné par l’utilisation des VMs et des conteneurs. En effet, l’emploi de ces technologies est à la base guidé par un constat, qui est que les apprenants dans un TP d’informatique n’ont souvent ni l’envie, ni les connaissances techniques, pour mettre en place l’environnement logiciel parfois complexe d’un enseignement sur leurs machines. Mais en répondant à ce besoin par l’utilisation d’une grosse boîte noire contenant la quasi-totalité d’un système d’exploitation moderne, on se retrouve avec des téléchargements de plusieurs gigaoctets que les apprenants n’essaient souvent de récupérer qu’au moment du cours. Par conséquent, le jour J, on fait face à des dizaines de machines qui cherchent simultanément à télécharger d’énormes fichiers depuis internet, via une connection souvent peu performante, ce qui entraîne naturellement une énorme contention réseau et de longs délais avant le démarrage des TPs. Le moins que l’on puisse dire, c’est que ça ne semble pas encore optimal.

On peut envisager différentes stratégies :

• encourager les maîtres-nageurs à partir d’un socle logiciel commun (VM ou image docker de référence bien remplie) afin de mutualiser davantage de données entre les plongeons ;
• encourager les maîtres-nageurs à mettre leurs images à disposition avec une bonne avance, afin qu’un téléchargement préalable soit possible ;
• encourager les apprenants à préparer l’environnement logiciel des plongeons à l’avance, idéalement par simple installation de docker et « docker pull » ;
• reconnaître qu’aucune de ces mesures ne sera un remède à l’inattention et à la paresse des apprenants, et fournir sur place des serveurs de fichiers performant et une bonne bande passante locale pour éviter de trop dépendre de la connexion Internet.

À la fin de cette discussion, l’on s’est aussi interrogé sur la pertinence de créer une zone de piscine dédiée aux langages de programmation. D’un côté, c’est très clairement une thématique populaire et un peu à part par rapport aux autres. Mais de l’autre, il peut être maladroit de trop vouloir séparer les langages de programmation de leurs écosystèmes. En effet, il est très courant qu’une technologie ne soit aisément utilisable que depuis un seul langage de programmation, ainsi l’utilisation de Spark est bien plus naturelle depuis Scala que depuis les autres langages, la majorité des bibliothèques de vectorisation et de parallélisme de la dernière décennie ne sont utilisables que depuis C++, le développement web front-end n’est pas envisageable sans avoir un minimum de notions de HTML/CSS/Javascript, et Python et R détiennent un monopole absolu sur les bibliothèques libres d’informatique scientifique pour non-spécialistes. Peut-être qu’une solution possible serait de faire ce qu’Olivier Girardot a fait dans la formation Spark, et de proposer une formation « langage » et une formation « techno » en expliquant clairement que la première est un préalable nécessaire à la seconde ?

Autres activités de formation

École informatique sur les conteneurs en production

La prochaine école informatique sera sur les conteneurs en production. Elle se déroulera du 4 au 8 juin au Centre de Calcul de l’IN2P3. Elle est piloté par Cécile Cavet, qui a proposé un programme, mais depuis que tout le monde est tombé d’accord, il n’y a plus de nouvelles. Il reste encore à définir le programme, trouver des intervenants, et lancer les inscriptions. Vu le calendrier, le délai est court est la question se pose de relancer Cécile.

Des sujets variés pourraient être abordés, tels que l’orchestration de conteneurs et Singularity. David a proposé de rejouer sa piscine, déjà jouée aux Journées Informatiques de l’IN2P3, mais il risque d’être indisponible, il cherche donc un renfort pour le remplacer en cas d’absence. Toute bonne volonté est aussi bienvenue pour faire évoluer ce plongeon sur https://gitlab.in2p3.fr/MaitresNageurs. Plus globalement, ce peut être l’occasion de réutiliser des piscines des JI précédentes Cela a été proposé à Gérard, intéressé par les sujets Docker et Singularity, mais il est un peu trop occupé.

Liste de formations en ligne

L’intérêt d’une liste de formations disponibles en ligne pourrait être utile, autour du développement. Le format plongeon de 20 minutes peut s’avérer adapté mais tout format est utile. Actuellement, sont disponibles plusieurs types de ressources :

• Formations Atrium
• MiniVOL2016 test logiciel

Cette liste pourrait apparaître dans le wordpress sous forme de page statique recensée dans le site du SI, pour rassembler toutes les informations utiles au même endroit, et faciliter la découverte des outils par les nouveaux arrivants.

Petite formation à Python au LAL

On a noté qu’il existe un besoin de formation python au LAL. Un cas d’utilisation basique serait le début d’un développement python, quand on ne connaît pas la langage. Christien remarque qu’au delà de la syntaxe d’un langage, les outils de l’environnement (maven, SBT, etc.) sont une base importante pour aborder un langage. Le réflexe d’Antoine est de créer un environnement virtuel avec virtualenv avant tout. On pourrait aussi y ajouter l’interface de développement PyCharm.

En résumé, un guide de démarrage qui voit plus large que le langage lui-même serait nécessaire. L’idée serait d’adopter un format court, informel, pour mettre le pied à l’étrier pour des personnes qui n’ont pas le temps et les références. À la fin d’un tel cours, d’autres ressources seraient comme toujours données, pour aller plus loin.

Questionnaires dans le cadre pédagogique

Un séminaire du café pédagogique de Paris-Sud a abordé les quizz dans le cadre de l’enseignement.

• Les questionnaires pré-formation permettent de s’assurer que les pré-requis sont maîtrisés. C’est un effort immense mais cela peut valoir le coup dans certains cas.
• Les questionnaires post-formation se révèlent aussi utiles après une formation : les retours d’expériences montrent qu’une révision quivie d’un questionnaire est plus efficace que deux révisions.

C’est une manière différente de réfléchir au matériel pédagogique, les questionnaires peuvent être vus comme le TD en présentiel. Pour créer de tels questionnaires, les services limesurvey de l’IN2P3 ou du LAL pourraient être utilisés.

Formation à Git

Hadrien prépare une formation Git pour la DR4 du CNRS. Elle se déroulera les 31 mai et 1er juin 2018. La question du format piscine s’est posée, mais semblait ici moins adapté : l’ambition n’est pas seulement de donner une liste de commandes utiles, mais aussi que les participants sortent avec une bonne compréhension du fonctionnement de l’outil.

Le principal prérequis demandé est la connaissance des commandes de gestion de fichier de base d’Unix (cd, mkdir, ls, touch, etc.), puisque les TPs sont sous Linux et utilisent principalement la ligne de commande. Aucun prérequis ne sera demandé en gestion de version, et le contenu pourra peut-être être adapté à l’expérience des participants.

Les deux types de didacticiels (les «tutorials») ont leur utilité, mais il existe déjà de nombreux didaticiels introductifs à Git, ce qui laisse songeur quand à la nécessité d’en créer un de plus. Quelques exemples pour les intéressés:

• https://try.github.io/
• https://git-scm.com/docs/gittutorial
• http://gitimmersion.com/
• https://backlog.com/git-tutorial/

Par ailleurs, la documentation de référence est complémentaire de ces didacticiels, c’est une différence dont il faut être conscient.

Communauté dev@LAL et outils

Idées d’animation

Tout part du constat suivent: nous ne sommes pas nombreux aux réunions développeurs du LAL par rapport au nombre total de développeurs au laboratoire. Il a été proposé plusieurs idées pour palier à ce problème.

• Faire des petites présentations d’outils de 20 min. ? Ou encore des annonces brèves sur des outils récemment découverts ?
• Partager régulièrement des URLs intéressantes collectées durant les deux semaines de travail écoulées ?
• Fournir enfin, après l’avoir souvent évoqué, un annuaire  des listes de diffusion utiles ?

La question du partage d’URL a été plus longuement discutée. Par exemple, un format possible serait que chacun présente deux URLs par réunion. Ces URLs apparaîtraient sur le compte rendu, et pourraient éventuellement être intégrées à un annuaire plus pérenne sous forme de page statique.

Dans ce dernier cas, il faudrait cependant gérer le problème de l’accumulation des actualités et de leur obsolescence. Sans maintenance régulière, une page statique a tôt fait de devenir un fatras.

On pourrait, à la place, préférer partager nos trouvailles au fur et à mesure. Se pose alors la question du moyen de communication. L’e-mail est peut-être un peu sur-utilisé, dans la mesure où il ne passe pas bien à l’échelle : quand on est abonné à des listes de diffusion très actives, les retours de vacances sont difficiles…

A ce niveau, on pourrait préférer des outils davantage basés sur la notion de flux continu d’information qu’on peut aisément ignorer pendant un temps, à la manière de Twitter ou des chats persistants comme Slack et son clone libre Mattermost. Sur ce sujet, il est d’ailleurs intéressant de noter qu’il existe un groupe Slack RI3 et que le CCIN2P3 s’interroge sur la pertinence d’héberger une instance de Mattermost.

Outil: Trello

Un des exemples d’utilisation de l’outil Trello fourni par les développeurs, c’est un tableau dédié à l’accueil des nouveaux entrants. Cela semble être une bonne idée dont nous pourrions nous inspirer.

Les intégrations pour Github, Bitbucket, ou encore des outils de workflow Scrum sont potentiellement intéressantes, mais il peut y avoir besoin de développements custom pour ajouter les intégrations désirées, comme celles avec les services du CC par exemple.

Plus généralement, un problème existant avec les intégrations Trello par défaut, c’est qu’elles concernent principalement des logiciels qui ne sont pas très utilisés dans notre communauté.  Pour en tirer profit, il faut peut-être avoir pensé le projet dès le départ pour un workflow Trello et avoir choisi les outils de gestion de projet en fonction.

Il existe un clone libre de Trello, Kanboard (service gratuit : Framaboard), qui dispose de modules similaires (module bitbucket, module gitlab).

Outil: Framework Python Dash

Dash est un outil qui sert à construire des applications web orientées Data Science. Il est basé sur Plotly, et est lié à PyData.

En le présentant, son auteur citait Guido von Rossum: « Python a été créé comme langage d’enseignement, pour combler le vide entre bash et C ».

Du point de vue de l’auteur de Dash, PyData est la prochaine page de l’histoire du Python numérique, après l’ère SWIG et l’ère Numpy/Matplotlib.

Journal: Software and Computing for Big Science

Software and Computing for Big Science est un nouveau journal, créé en Septembre 2017, pour des publications ayant trait au logiciel scientifique.

Michel, qui fait partie de son Editorial Board, a confié un exemplaire du premier numéro de la revue à Antoine. Ce dernier est désormais disponible dans la salle détente !

Cafés LoOPS

Le prochain café LoOPS parlera de notebooks C++ avec xeus et cling. Mais sur la page de LoOPS, ce n’est pas très clair qui va présenter. On peut juste soupçonner que sera Loïc Gouarin, qui travaille pas mal sur ce genre de sujets.

Le café LoOPS précédent parlait de l’outil d’intégration continue TeamCity de JetBrains. Pour l’instant, ce dernier n’est pas open-source, il offre juste des versions closed-source gratuites et payantes. A ce niveau, la politique de JetBrains n’est pas forcément très claire: certains de leurs projets sont open-source (les « community editions » de IDEA et PyCharm et le plugin Rust), mais la plupart ne le sont pas…

Le café LoOPS du 6 mars sera probablement organisé en collaboration avec le LLR, sur le thème « coder pour le jeu ». On y invitera des développeurs du LLR qui travaillent sur des jeux scientifiques.

Certains se demandaient si on ne devrait pas y inviter nos anciens collaborateurs de l’école Cnam-ENJMIN (Angoulême), avec qui on avait précédemment travaillé sur « Quark Clash », un jeu vidéo qui aurait dû être la version numérique du jeu de cartes « Quark Poker », mais qui a finalement été quelque chose d’assez différent. Un des regrets de cette expérience est en effet qu’on n’ait jamais réussi à en faire un séminaire technique.

Les méthodes de travail des développeurs du jeu étaient intéressantes, car différentes de ce qu’on observe habituellement dans les labos, avec notamment diverses spécialisations inhabituelles (graphisme, son…). Les locaux de l’école eux-même, une ancienne usine papier à cigarette, ont une esthétique assez unique: murs à base de palettes, rails d’éclairage d’usine au plafond…

Les EDIs / IDEs

Il y a eu une longue discussion sur les environnements de développements intégrés (EDIs, plus connus sous l’abbréviation anglaise IDEs), avec des points de vue allant de la révolutions de productivité à l’usine à gaz insupportable.

Un point qui a été mentionné est que les IDEs sont particulièrement utiles quand on ne connaît pas très bien le langage de programmation qu’on utilise ou le projet logiciel sur lequel on travaille, l’avantage sur d’autres environnements étant moins prononcé quand on est déjà un expert des deux.

Un autre point qui a été soulevé par les participants de l’école de fonctionnel et de Spark, c’est que dans des langages utilisant l’inférence de type comme Scala, un bon IDE aide beaucoup à comprendre ce qui se passe dans du code touffu. Et quand dans des codes complexe, il aide à naviguer rapidement d’un module à l’autre, ou à comprendre l’architecture et trouver la documentation.

Antoine mentionne aussi que l’intégration des outils d’analyse statique et des linters dans les IDEs est particulièrement plaisante, puisque ces derniers sont capable de signaler les erreurs détectées directement dans le code, sans indirection. En Python, l’intégration des lints PEP8 est particulièrement plaisante. Une autre fonction classique de IDEs est l’application automatique d’un style de code.

Un inconvénient des IDEs est qu’ils sont souvent, au moins pour partie, spécifiques à un langage. Cela complique la vie des programmeurs qui travaillent dans plusieurs langages, et tend à encourager à l’inverse une certaine hyper-spécialisation. A ce niveau, on peut saluer l’effort de Jetbrains pour fournir des IDEs d’interface relativement uniforme pour de nombreux langages. Ils ont réussi à en cela à détrôner Eclipse, qui avait tenté la stratégie de l’IDE qui fait tout, mais qui s’avérait finalement moyen hors de son domaine d’expertise du Java.

Serge en profite pour mentionner que les développements web du labo se font beaucoup avec Eclipse, et qu’il s’interroge sur la pertinence de passer à PHPStorm, l’IDE PHP de Jetbrains. Cet IDE ayant une version gratuite, il a été proposé qu’on fasse des tests avec et achète quelques licence au LAL si l’essai est concluant.

Comme souvent, il faut de tout pour faire un monde: certaines personnes se sentent beaucoup plus confiantes et plus productives avec un IDE, tandis qu’à l’autre extrême certains développeurs du LAL ont du mal avec la coloration syntaxique. Et bien sûr, il ne faut pas oublier que quoi qu’il arrive, l’outil ne remplace pas la compétence.

Formation Fonctionnel/Spark

La réunion développeurs s’est tenue entre les deux parties de la formation de programmation fonctionnelle et Apache Spark, donc après la partie « programmation fonctionnelle en Scala ».

A ce stade, l’impression était que c’était un très bon début, avec toutefois quelques regrets sur l’équilibrage du troisième jour, où Olivier avait passé un peu trop de temps sur la gestion des erreurs, et trop peu sur la concurrence et le parallélisme.

Un autre sujet peut-être trop développé était la question du lien entre Java et Scala. C’est certes un point important pour comprendre certains points malheureux de la conception de Scala, mais dans notre communauté globalement peu portée sur le Java, ça tournait assez rapidement à la discussion d’expert opaque.

On pourrait sans doute faire mieux sur ce point la prochaine fois en faisant circuler un petit questionnaire lors de l’inscription à la formation pour se faire une meilleure idée du public cible.

Un exemple de point où l’héritage Java a influencé Scala, c’est la taille maximale des tableaux (et des collections), qui est fixée à 2 milliards d’éléments (2³¹ – 1 pour être précis). L’origine de ça, c’est que Java stocke les indices et tailles de tableaux dans des entiers signés 32-bit. A l’époque où le langage a été conçu, sur du matériel nettement moins performant qu’aujourd’hui, et avec une audience beaucoup plus faible, ça avait dû paraître suffisant, mais aujourd’hui on est gêné par cette limitation dans des projets comme LSST où on a bien plus que deux milliarde de données à traiter.

Dans le cas de LSST, Christian a contourné le problème en utilisant des tableaux de tableaux, dont l’organisation interne est cachée au programmeur par l’API de Spark qui n’expose que des pipelines et des itérateurs. C’est une solution globalement satisfaisante, mais qui a quelques inconvénients, notamment quand on manipule des éléments voisins dans le tableau global (qui ne sont pas forcément voisins dans le tableau de tableau qui le simule) ou quand on modifie le tableau.

Le modèle de programmation fonctionnel où les données sont immutables nous sauve cependant ici, car il élimine la question de la modification du tableau, et simplifie la gestion du voisinage par mise en cache des voisins.

Un autre aspect qui est remarquablement facile à aborder en Spark, c’est la non-commutativité de certaines opérations sur les données du point de vue de la performance. Pour donner un exemple, il est généralement préférable de filtrer les données avant de les transformer, pour ne pas effectuer des transformations inutiles. C’est un problème connu des utilisateurs de SQL, où l’ordre des conditions dans une clause WHERE a aussi son importance. Or, avec un modèle de programmation à base d’itérateurs comme celui de Spark, il est nettement plus facile de raisonner sur ce type de considération, car l’ordre des opérations effectuées sur les données apparaît assez naturellement dans la chaîne d’itérateurs.

Autres événements

Une visite de l’IgleX avait préalablement été proposée par Antoine, qui trouve que c’est important de voir l’évolution de l’igloo avant l’installation de ThomX. Le groupe contrôle-commande a donné un accord de principe, il n’y a donc maintenant plus qu’à programmer la chose. La mise en service de ThomX est actuellement prévue pour cet été (mais sera potentiellement retardée par des problèmes avec les électro-aimants), et Antoine propose une visite en février.

C’est aussi le moment pour proposer des sujets de stages pour le Google Summer of Code. PSPA n’y participera pas cette année en raison du refactoring en cours, par contre on a une proposition d’astrophysique par Julien et Christian et deux propositions de tracking pour la physique des particules par Hadrien et David.

Les inscriptions sont ouvertes pour CHEP 2018, la grande « conférence-usine » (8 sessions parallèles avec une présentation intéressante par demi-journée dans chacune…) sur l’informatique pour la physique des particules. Elle se tiendra à Sofia, en Bulgarie, entre le 9 et le 13 juillet. Le conflit avec les stages GSoC est regrettable, mais on s’en tirera probablement par des mails rapides entre deux sessions. HSF organise également un workshop appelé PyHEP sur le Python en physique des particules le week-end d’avant. Hadrien devrait y présenter une étude des caractéristiques de stabilité numérique d’ACTS avec l’outil Verrou.

Pour ce qui concerne la formation Symfony 3 préalablement proposée sur Devlog, Serge et Justine sont malheureusement sans nouvelles. Pour rappel, l’idée serait de discuter des nouveautés de cette version du framework PHP, que l’on utilise beaucoup au LAL pour des applications de gestion du personnel.

Une réunion de fonctionnement du SI se tiendra le 25 janvier à 14h30. L’une des questions auxquelles elle devra répondre est la pertinence de poursuivre cette série de réunions. En effet, elles ont déjà eu un impact positif net (comme la création de la salle relax), mais on va peut-être vouloir passer à un autre format pour la suite.

Développement au LAL

Présentations

La réunion a commencé par quelques présentations, car beaucoup rencontraient Julien, nouvelle recrue du SI, pour la première fois. Julien a été recruté sur des thématiques de calcul scientifique distribué, et va dans un premier temps travailler sur le logiciel de LSST avec Stéphane, Réza, Sylvie et Guillaume.

Serge s’est présenté comme ayant un pied dans le développement logiciel et un autre dans l’exploitation. Il est courant pour les développeurs web de contribuer ainsi à l’exploitation au LAL, mais ce n’est pas nécessairement le cas dans le reste de l’industrie où ces corps de métiers peuvent, de son expérience, être davantage séparés.

Accueil des nouveaux entrants

Julien mentionne qu’il ne reçoit pas les comptes-rendus de réunions. C’est lié au fait qu’on a oublié de l’inscrire sur la liste de diffusion DEV-LAL. Ce qui réveille la vielle question de l’accueil des nouveaux entrants et de l’intégration de ces derniers à l’infrastructure informatique : pour l’instant, cela reste un processus assez fastidieux et manuel, peut-on l’automatiser davantage ou au moins centraliser une liste de ce qu’il faut faire à chaque fois ?

Serge propose aussi la rédaction d’un guide des nouveaux entrants, qui présente à ces derniers les ressources informatiques disponibles, par exemple les mailing-lists importantes. La question de la maintenance d’un tel guide doit être préalablement élucidée, surtout dans un contexte de fusion de laboratoires où il est probable que les règles de fonctionnement informatique vont changer prochainement et de façon importante.

Organisation des réunions

Les développeurs du LAL organisent une réunion toutes les deux semaines, le mercredi matin à 10h30, qui dure une heure. L’un des buts de cette réunion est d’échapper au cloisonnement naturellement créé entre les différentes activités du LAL par le grand nombre de collaborations avec des manips « hors-sol ».

Le format de cette réunion change régulièrement. Actuellement, la formule choisie n’utilise pas d’ordre du jour, préférant une organisation à base de parole libre. Ce format a des avantages et des inconvénients: il donne plus de place aux sujets de conversation imprévisibles (ex: actualités) et aux personnes d’un naturel spontané, mais il convient moins aux personnes qui préfèrent préparer un sujet et au suivi sur la durée de sujets précis (ex: retours des café LoOPS annoncés à une réunion précédente).

Peut-être faudrait-il envisager un format plus hybride, où chaque réunion a une partie cadrée et une partie non-cadrée. A minima, on pourrait envisager de définir une structure guidée par la trame récurrente des réunions libres, Philippe propose par exemple :

• Actualités et futur proche
• Suivi des annonces précédentes (ex: retours des cafés LoOPS)
• Parole libre

Comme première expérience, on pourrait allouer 15 minutes à la partie cadrée et 45 minutes à la partie libre, et voir comment ça se passe.

Pour aller plus loin, on pourrait aussi envisager la rédaction d’un ordre du jour collaboratif avec un outil « léger » de type Etherpad. Le document serait pré-rempli avec la structure ci-dessus, et les gens pourraient librement y ajouter des points de discussion entre deux réunions. La structure ainsi définie pourrait aussi être réutilisée lors de la rédaction de comptes-rendus, et il en résulterait un gain de temps.

Une autre possibilité, préalablement évoquée mais qui n’a pour l’instant pas été mise en pratique, est de tourner entre les différents développeurs au fil d’une année, laissant à chacun l’occasion de présenter son activité à tour de rôle.

Serge mentionne qu’un travers du format actuel est qu’il peut souvent tourner au débat d’expert. Antoine rappelle que de tels débats sont aussi utiles, mais approuve qu’il vaut mieux qu’ils ne monopolisent pas la réunion pour autant…

Autre question: doit-on parler davantage de projets dans les réunions développeurs ? Christian popose pour ça de partir du compte rendu mensuel de la réunion ASPRO que nous envoie Michel, et de mettre nos questions sur ce dernier à l’ordre du jour. Pour rappel, ASPRO est une réunion mensuelle des chefs de projets du LAL, sur un format préparé à l’avance avec éventuellement un tour de table si le temps le permet.

Comptes-rendus

Hadrien sonne l’alarme: le format actuel des comptes-rendus, qu’il a inauguré, structuré et rédigé, est très apprécié mais il lui coûte aussi cher en termes de temps de rédaction. Typiquement, il faut compter entre un et deux jours à temps partiel pour produire un compte rendu, et à fréquence de toutes les deux semaines ça finit par représenter une part non négligeable de son temps de travail.

Plusieurs possibilités sont envisageables:

• On continue avec le format actuel, mais on répartit la charge entre plusieurs personnes. Par exemple, on pourrait alterner entre deux secrétaires de séance d’une réunion à l’autre. Cela aurait aussi pour avantage de fournir une solution évidente pour les réunions où Hadrien n’est pas présent.
• On reste avec un secrétaire de séance unique, mais on sacrifie la qualité du document, par exemple en passant à un format moins rédigé ou moins structuré. C’est moins satisfaisant en termes de résultat final, mais ce sera l’approche la plus facile à adopter si personne ne se manifeste pour aider.
• On essaye d’abandonner complètement le concept de secrétaire de séance unique au profit d’une approche plus collaborative de type Etherpad. Celle-ci reste cependant à définir:
  • Si tout le monde est responsable pour prendre des notes, personne ne l’est, et de l’information sera perdue. De plus, l’activité de prise de notes freine grandement la participation à la réunion, donc on ne veut pas forcer tout le monde à prendre les siennes de façon redondante.
  • Quel outil de prise de notes utiliser ? Mieux vaut éviter une prolifération des ordinateurs en réunions, qui tendent à être distrayants et à freiner la communication entre personnes (au profit de tâches individuelles comme la gestion des e-mails). Mais les notes manuelles doivent être recopiées, ce qui induit aussi une charge de travail conséquente.
  • Comment centraliser les notes à la fin et s’assurer qu’elles soient mutuellement intelligibles ?
  • Qui se charge de la mise en page et de la rédaction finale ?

Cette discussion sera poursuivie prochainement, par exemple en faisant un petit sondage par e-mail sur les avis du groupe de développement à ce sujet.

Distribution de binaires

La question de la distribution de binaires pour le contrôle-commande demeure encore irrésolue. C’est en effet actuellement un peu complexe quand on utilise le Gitlab du CCIN2P3.

Philippe essaye actuellement de distribuer les binaires via l’ownCloud du LAL, mais il y a des erreurs à l’upload avec de gros fichiers (~3 Go) même quand il y a assez de place dans le dépôt. Gérard essaye actuellement d’examiner les quotas du serveur afin de comprendre ce phénomène. Si le problème n’est pas là, une autre possibilité serait que quelqu’un ait encore fait la boulette d’utiliser un entier signé 32-bit pour stocker des tailles de fichier quelque part dans le code source d’ownCloud ou de ses dépendances. Ce serait loin d’être la première fois…

Idéalement, il n’y aurait pas besoin de séparer les binaires du code source versionné, et on pourrait directement gérer ces derniers depuis l’interface Gitlab à la manière des pages « releases » de Github. Une possibilité serait de faire appel à la fonctionnalité Git LFS (Large File Storage), mais cette dernière ne pourra pas être introduite au CC tant que ce dernier n’aura pas effectué la mise à jour à Gitlab 10…

Christian propose d’utiliser Atrium à la place d’ownCloud. Il dit que grâce à l’API de ce dernier, on peut automatiser les transferts de fichiers vers Atrium tout aussi facilement. Philippe s’interroge sur la question de l’authentification: sans certificats de groupe, auxquels la politique d’administration est généralement hostile, comment permettre à tout membre du groupe contrôle-commande de récupérer les binaires depuis un compte utilisateur unique sur une machine partagée ? Une solution possible, si les données ne sont pas secrètes, est d’autoriser un accès public sans authentification.

Il est intéressant de noter que ces problèmes d’authentification reviennent à chaque fois qu’on utilise une machine ou un compte utilisateur partagé, que ce soit pour faire des sauvegardes ou installer des logiciels. Il serait peut-être intéressant d’y trouver une solution de long terme générale au lieu de toujours procéder au cas par cas.

Un avantage à l’utilisation d’Atrium est son contrôle d’accès plus fin, qui permet par exemple de distinguer entre versions de développement privées et versions de production publiques.

On peut envisager d’automatiser l’export de binaires depuis Gitlab vers la solution choisie via les hooks de déploiement de l’intégration continue.

Café LoOPS sur Vue.js

Les deux derniers cafés LoOPS ont été consacrés au framework Javascript Vue.js et à l’outil d’intégration continue TeamCity.

Le style était assez différent: le café sur Vue se rapprochait davantage d’un tutoriel expliquant comment utiliser le framework, celui sur TeamCity tenait plus de la description de l’outil. Il est intéressant de noter que le format préféré dépend des affinités de chacun.

Serge voulait savoir si l’IAS, qui ont de l’expérience d’Angular.js, ont émis des commentaires et déclarations d’intention concernant Vue. Les personnes présentes ne se rappellent de rien de tel.

La personne qui a effectué la présentation de Vue l’utilise de façon intensive dans ses développements. Il l’utilise essentiellement pour des besoins d’interface homme-machine généralistes (administration d’une infrastructure).

Est-ce que Vue pourrait intéresser PSPA ? Ce point sera discuté avec le contracteur quand on le connaîtra. Il est plus probable que PSPA utilise une combinaison de plusieurs technologies, intégrant outils d’interface hommes-machine généralistes et bibliothèques plus spécialisées dans la visualisation de données scientifiques (ex: D3.js).

Projet PSPA

Pour rappel, PSPA (Platform for Simulation of Particle Accelerators) est un projet qui vise à fournir une interface unifiée vers les nombreux logiciels de simulation utilisés lors de la mise au point d’accélérateurs de particules. L’idée est d’en finir avec les interfaces utilisateur incohérentes et les formats de données non documentés et incompatibles, en proposant une IHM et un bus de données unifié pour l’ensemble des outils concernés.

L’outil a été utilisé avec succès dans le cadre du projet PHIL, et le prochain défi auquel on va le consacrer est la source de rayonnement synchrotron compacte ThomX. Dans ce cadre, PSPA a récemment acquis la capacité de modéliser l’injection d’un paquet d’électrons dans un anneau de stockage et son mouvement au sein de ce dernier.

PSPA se présente à l’utilisateur via une interface web. Initialement, cette dernière avait été réalisée via le framework Wt, un générateur de code HTML/CSS dont l’API est similaire à celle de Qt. Mais le développeur qui s’occupait initialement de l’interface de PSPA, Laurent Garnier, a quitté le LAL depuis, et plus personne dans le projet PSPA n’a les connaissances et la volonté requis pour régler les problèmes ergonomiques de l’IHM.

Face au manque de compétences internes du LAL et à la difficulté de trouver des collaborateurs extérieurs, une solution à base de sous-traitance a finalement été choisie. Il a été prévu, dans ce cadre, de collaborer avec le sous-traitant sur la conception de l’interface et de recevoir des formations de ce dernier afin de pouvoir à terme reprendre la maintenance de PSPA en main au LAL.  Le code source du front-end PSPA sera aussi libéré à terme.

Au-delà de cette gestion des compétences IHM, Antoine pense que cette réécriture sera aussi une bonne occasion de revoir l’architecture de PSPA, par exemple pour mieux séparer le front-end du back-end et mieux spécifier les interfaces logicielles entre ces composants.

Meltdown et Spectre

Le sujet des deux failles de sécurité qui ont défrayé la chronique en ce début d’année, Meltdown et Spectre a été brièvement évoqué.

Pour résumer, des défauts de conception dans les CPU modernes permettent à un attaquant qui peut exécuter du code sur une machine d’avoir un accès en lecture seule à des informations qui lui seraient normalement inaccessibles:

• L’attaque Meltdown permet à un processus non privilégié d’avoir accès aux données du noyau d’un système d’exploitation.
• Les attaques Spectre permettent à du code sensé être isolé du reste du système, par exemple qui s’exécute dans l’interpréteur Javascript d’un navigateur web, d’avoir accès aux données privées de son processus hôte, voire d’autres processus.

Ces failles proviennent de couches très basses du matériel (éxécution spéculative), donc la seule manière de les éliminer est de revoir la conception de ce dernier, ce qui prendra très longtems. En attendant, des solutions de contournement logiciel qui évitent d’utiliser la portion vulnérable du matériel ont été proposées.

Comme la spéculation est une optimisation de performance très importante dans les processeurs modernes, ces solutions ont un impact fort sur les chemins de code concernés: les patches pour Meltdown augmentent le coût d’un appel système, avec pour résultat des pertes de performances allant jusqu’à ~30% dans les applications qui font beaucoup d’appels système (ex: bases de données), ceux pour Spectre ont un coût en performance dans tout code qui effectue des branchements (if / else, méthodes virtuelles…), dont l’impact exact n’a pas encore été mesuré précisément.

Tout programme qui stocke des données secrètes et exécute du code potentiellement malveillant est concerné par cette faille. Cela inclut par exemple les noyaux des systèmes d’exploitation, les hyperviseurs (hôtes de machine virtuelles), les navigateurs web, et les interpréteurs de code en général (Python, Java…).

Les administrateurs systèmes du LAL et du CERN sont actuellement très affairés à déployer les correctifs de sécurité pour ces failles dans les services centraux. En parallèle, d’autres administrateurs de systèmes plus spécialisés s’interrogent: l’impact de performances de ces patches se justifie-t-il vraiment sur des systèmes qui ne manipulent pas de données secrètes et n’exécutent que du code de confiance, comme les machines d’acquisition de données des expériences ? Ne devrait-on pas les désactiver au cas par cas sur les systèmes où ils ne sont pas nécessaires ?

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