Le système qu'il faut à des développeurs :
un Unix libre !

Edlira Nano, Laurent Bloch, Alain Louge,
Hugo Raguet, Stéfane Fermigier, Bernard Lang,
Olivier Mehani, Franck Routier, Patrick Sinz,
Bastien Guerry, Pierre Jarillon, Jean-Pierre Archambault
 

   Une discussion riche et passionnée a dernièrement animé la liste de diffusion de l'AFUL [1], sur la question de savoir s'il était raisonnable d'acheter, avec la dotation budgétaire d'un laboratoire de recherche public (bio-informatique), des Macintosh pour une équipe de développeurs bio-informaticiens.

   Les participants à la discussion sont tombés d'accord sur le fait que pour créer une équipe de développement, le choix des outils revenait de droit au leader de l'équipe, puisque c'est elle qui aurait à assumer les conséquences de ces choix. De nombreux arguments ont été produits et discutés, avec un convergence assez nette pour souligner les avantages des outils libres.

   En préambule de cette discussion, on peut mentionner les arguments de Roberto Di Cosmo relatifs plus particulièrement à l'usage de logiciels libres pour les activités de recherche scientifique. En effet, pour être valide, un résultat scientifique doit être :

• répétable : l'auteur doit pouvoir répéter plusieurs fois la même expérience dans le même contexte et obtenir le même résultat ;

• réplicable : un autre chercheur, muni des mêmes artefacts et du même environnement que l'auteur, doit pouvoir réitérer la même expérience et obtenir le même résultat ;

• reproductible : un autre chercheur, qui ne connaît que le résultat obtenu mais ni les artefacts utilisés ni l'environnement de l'expérience initiale, doit pouvoir effectuer une expérience sur la base des mêmes hypothèses et obtenir le même résultat.

   Les conditions 1 et 2 ne peuvent être satisfaites que si le système d'exploitation et les logiciels utilisés sont libres.

Quels ordinateurs et systèmes pour les développeurs d'un laboratoire de recherche ?

   Le débat a été lancé par Edlira Nano, ingénieur dans un laboratoire Inserm à Marseille, et je lui laisse la plume (les initiales de chaque intervenant serviront à identifier leurs contributions) :

EN :
« Bon je vais essayer d'être brève et de contenir ma colère : depuis mon retour dans le travail en labo de recherche publique en tant que développeuse informatique il y a un an après une pause de 2 ans, je remarque une prolifération de Mac Os X avec des "Windows c'est trop nul, moi je suis sous Mac", "Mac Os X c'est Unix" (sous-entendu que c'est bien du coup) et aussi "C'est Unix en dessous de toute façon, pourquoi passer à Linux".

   Bon, tout ça c'est pas bien nouveau, et puis les gens ont le droit de dire n'importe quoi et d'y croire très fort, sauf quand votre cheffe vous dit : "nous allons acheter des Macs pour l'équipe de bio-informaticiens que tu vas encadrer en développement, car c'est solide, c'est Unix de toute façon et voilà". Bon à part démissionner ou calculer le temps qu'il te reste avant de terminer ton projet en cours et de partir ailleurs (moi je suis forte en ça, je l'ai déjà fait quand on m'a imposé Windows sans tenir compte de mon avis), et devenir rouge de colère, donc à part ça, une fois qu'on a repris ses esprits, qu'on tourne la tête autour de nous et qu'on voit que dans les labos de recherche même les matheux sont maintenant plus nombreux à être sous Mac que sous Linux ou Windows, les physiciens et les biologistes j'en parle même pas, que des services IT des labos de recherche payés par l'état ose dire "je ne gère que les Mac, les Linuxiens ils se débrouillent sans moi", donc une fois qu'on regarde tout ça en face, comme moi en ce moment, qu'est-ce qu'on dit à des gens qui n'en ont rien à faire du libre (donc les arguments libristes, éthiques et politiques c'est même pas la peine) pour leur faire comprendre que programmer sous Mac Os X n'est pas raisonnable ?

   Je ne connais pas mon nouvel ennemi. Depuis que j'ai un ordi perso je suis sous Linux et je regarde rarement le reste, je suis une libriste de cœur et d'esprit et que même si je ne faisais pas de l'info je le serais libriste et ça me parait évident et je pourrais en parler pendant des heures que c'est mieux de tout point de vue. Mais bon voilà, j'ai besoin d'arguments rationnels autres qu'éthiques destinés à des gens qui s'en fichent complètement du libre et qui veulent dépenser deux fois plus pour être sous un système propriétaire fermé etc. qui est macOs X. Il s'agit d'arguments pour le développement info, donc pas pour une utilisation bureautique de l'ordi.

   Le meilleur argument que j'ai trouvé à dire hier c'est "si ton argument c'est que c'est Unix derrière et que c'est ce qui fait que c'est aussi solide qu'un truc proprio peut l'être, pourquoi ne pas être directement sous Linux, le mieux qu'on ait fait en Unix solide et libre et code dispo" ? Je ne voulais pas ressortir mes arguments libristes et militants car je vois qu'ils n'ont aucun effet et que pire, ils me prennent pour un hippie. Je voulais donc rester neutre et raisonnable. Peut-être il y en a parmi vous qui connaissent les défauts qu'on peut sortir sous Mac Os X en utilisation dev info ? Je me souviens que le dernier stagiaire que j'ai encadré, au passage de son code fait sous Mac sur mon ordi sous Linux avait eu des problèmes d'extensions de fichiers non écrits spécifiquement dans le code (oui les jeunes) et que sous Mac il avait rien vu car le système devait deviner les extensions de fichiers pour lui, bon le truc classique comme à la Windows. Mais à part ça c'était du dev web donc je n'ai rien vu d'autre.

   Vous en savez peut-être plus que moi ?

   Eda (toujours rouge de colère et déçue de ma naïveté à ne pas avoir vu venir ça plus tôt, car ce n'est pas la première fois que ça m'arrive). »

   Voici le débat lancé : les réponses affluèrent, pour donner des arguments contre macOS et les Macintosh, puis des arguments positifs pour Linux, valables aussi pour des Unix BSD d'ailleurs.

Discussion sur le matériel et les prix

   Je crois avoir été le premier à répondre :

LB :
« L'argument contre le Mac : le prix ! Pour avoir un Mac, il faut se le faire payer par :

• son employeur ;
• ses actifs financiers aux îles Cayman ;
• ses grands-parents.

   Autrement, techniquement, il faut entrer dans des détails inaccessibles aux non-professionnels : par exemple, le développement est un enfer parce que l'arborescence des bibliothèques Unix habituelles n'est pas conforme aux pratiques courantes, et que de surcroît cela change à chaque version de l'OS.

   L'addiction est souvent déclenchée par l'iPhone. »

   Suivi par Hugo Raguet HR : « Au risque d'apparaître redondant, je souhaiterais insister sur cet argument évident avancé notamment par Laurent Bloch. Si j'ai bien compris la question, il s'agit ici de recherche publique, contexte dans lequel je n'entends parler que de réduction de budget et autres difficultés de financement. L'argument du prix, que personne ne saurait décemment contester, me semble donc largement suffisant. »

Stéfane Fermigier SF :
« AMHA

• Difficile de trouver des arguments généralistes contre Mac OS en tant qu'OS desktop grand public ou pour développeurs. Selon le contexte, il y en a sûrement (par exemple, comme c'est pas Linux, ça ne supporte pas Docker de façon native...) mais globalement il y a aussi des points positifs. Donc ça dépend vraiment du contexte.

• On peut bien sûr attaquer Apple sur un certain nombre de points :
     - Sa politique d'optimisation fiscale ;
     - L'absence de serviçabilité de son matériel (cf. https://www.wired.com/2012/06/opinion-apple-retina-displa/ – à vérifier car ça date d'il y a 5 ans mais je ne pense pas que cela se soit arrangé) ;
     - L'absence de touche "escape" sur les modèles récents (super important pour vi).

• Le plus simple et AMHA plus efficace est quand même de proposer une alternative en fonction de l'usage précis que tu as en tête – quelles machines ? quel OS ? – et de mettre en avant les avantages de cette proposition. »

LB :
« Acheter des ordinateurs, cela fut mon métier pendant une quarantaine d'années : le "haut de gamme" en ce qui concerne les portables, c'est l'ordinateur considéré comme objet de luxe destiné à rehausser le prestige de son utilisateur, comme un bijou ou un nœud papillon. Inutile de dire que ce sont des considération qui n'ont rien à faire dans les choix d'équipement d'un laboratoire financé par l'argent public. »

SF :
« [À propos du "haut de gamme",] il y a plusieurs sujets.

   Le premier, bien sûr, est que "haut de gamme" n'est pas une simple considération de prestige, comme tu [LB] sembles l'impliquer. Cela implique, en général :

• des considérations de performance (CPU, RAM, disque...)
• des considérations de confort utilisateur (légèreté, qualité de l'écran, du clavier...)
• des considérations de robustesse et de durabilité (à performances égale) : qualité du boîtier (aluminium ou fibres synthétiques vs. simple plastique peint donc la peinture s'en va après quelques semaines, résistance aux chocs, etc.)

   Les deux premiers points ont un impact sur la productivité des développeurs.

   Le dernier sur la durée de vie de la machine.

   J'ai acheté pas mal de machines "no name" à très bas prix, et en terme de durabilité j'avais ce à quoi j'aurais du m'attendre : entre 12 et 18 mois de durée de vie effective des machines. Avec des machines plus haut de gamme, j'ai facilement le double.

   À une époque, ou la vitesse des CPU doublait tous les 18 mois et le prix de la RAM était divisé par deux sur la même période, c'était pas forcément grave de renouveler son parc disons tous les deux ans. A présent que ça évolue moins vite, on a d'autant plus un intérêt économique à prendre du matériel durable et le garder quelques années de plus.

1. Je n'ai pas pris en compte ci-dessus un autre aspect important, la serviçabilité. Il y a quelques années, c'était pas insensé de prendre un portable avec une certaine config en terme de RAM et de disque dur, et d'ajouter de la RAM et de changer le disque au milieu de sa vie, en tenant compte de la baisse des prix. Avec les portables modernes, notamment Apple, qui ne sont ni upgradable (tout est soudé sur la carte mère), ni "serviçables" facilement, c'est une autre paire de manches. Très mauvais point pour Apple, tout le monde en convient.

2. Tu [LB] écartes d'un revers de manche la notion d'image auprès des utilisateurs. C'est un raisonnement de pure ingénierie (et encore, comme je l'ai indiqué ci-dessus je ne pense pas ton raisonnement correct sur ce plan) qui ne tient pas compte de la psychologie des utilisateurs. Un bon artisan s'achète des bons outils – probablement d'un autre artisan réputé dans son milieu ; un bon musicien s'achète des bons instruments, etc., – à la fois pour leur qualité intrinsèque mais aussi parce que ça l'inspire.

   Il y a, heureusement, des bonnes et belles machines ailleurs que chez Apple. Elles sont forcément plus onéreuses que des machines d'entrée de gamme, qui se dégradent (dans leur apparence) au bout de quelques mois, et qui tombent en panne au bout de 18 mois en moyenne... »

Pierre Tarif : PT :
« Stéfane Fermigier nous informait il y a quelques jours de ce que depuis le dernier classement du "TOP500", 100 % des 500 supercalculateurs les plus puissants au monde sont sous Linux (autrement dit 500 sur 500 !). https://www.top500.org/statistics/details/osfam/1 et il rajoute :
en 1998 (année de fondation de l'AFUL), on était à 0.2 % (1 sur 500).

   C'est à peu près à ce moment-là que Stevie s'est dit que de faire du fric en partant d'une base d'OS gratuit bien solide [2], c'était une super-idée (la preuve a bien été faite) : il a abandonné son OS cracra et a pris BSD (vu que Berkeley, ce n'est pas loin de Palo Alto)

   Alors voilà l'argument : si on a une ambition scientifique sérieuse, alors on veut pouvoir disposer du max de la puissance possible, aujourd'hui, et surtout... demain !

   100 % des 500 machines les plus puissantes de la planète sont sur Linux et c'est passé de 0,2 % à 100 % en 20 ans donc un directeur de labo qui a un tant soit peu d'égo et de l'ambition eh bien, il ne peut pas faire autrement que de développer en natif sur l'environnement le plus puissante de la planète Terre. »

   Stéfane Fermigier SF : « en 1998 :

• Linux avait 0.1 % du marché des supercalcultateurs (cf. supra)
• Linux 0 % du marché des smartphones (qui n'existait pas...) ou même 0 % du marché des téléphones portables.
• Linux avait 0.1 ou 0.2 % du marché des desktops.

   En 2017 :

• Linux a 100 % du marché des supercalculateurs
• Linux a 80 ou 90 % des téléphones portables (c.f Android)
• Linux a 2 ou 3 % du marché des desktops (en augmentation sensible depuis 2 ans, mais on reste quand même dans les "pouillèmes").

   Quelle est l'intrus dans ces chiffres ?

   Je pense qu'il y a un vrai débat à avoir sur cette question, et peut-être des solutions à trouver. »

Arguments sur le système et les logiciels

HR :
« Quels sont les autres aspects à prendre en compte ? Si toutes les machines en question doivent être mises sur pied et maintenues par des techniciens IT qui ne jurent que par Mac, alors c'est un peu plus compliqué (et le système est alors effectivement bien vérolé). Il faudra au minimum que tu proposes un support IT alternatif. Si c'est toi qui dois "encadrer l'équipe en développement", la décision technique devrait purement et simplement t'appartenir : tu feras mieux ton travail avec les outils que tu connais le mieux. S'il faut vraiment enfoncer le clou, et pour éviter de rentrer dans les détails scabreux de l'organisation des bibliothèques logicielles, je propose la méthode (un peu fumeuse) suivante :

   Nombre de résultats Google (oui, je sais, il faut promouvoir les moteurs de recherche alternatifs, mais il reste la référence pour ce genre de statistiques bidons) pour la recherche "compilation problem <OS>" :

• linux : 1 170 000 résultats
• mac : 39 100 000 résultats
• windows : 86 400 000 résultats

   Même s'il faudrait débiaiser par le nombre d'utilisateurs (et encore, il faudrait prendre seulement en compte ceux qui se donnent la peine de compiler eux-mêmes des choses, ce qui est largement en faveur de Linux), le résultat est sans appel.

   Bon courage dans ta lutte. »

Franck Routier FR :
« Je pense que si tu exclus les arguments éthiques, de coût et idéologiques, il n'y a pas de raison particulière d'exclure macOS, qui est effectivement construit sur une base BSD... Sur les arguments techniques, d'autres ici pourront peut-être t'aider, mais tu en trouveras aussi dans l'autre sens de toute façon...

   Il me semble que le coût, le côté fermé de l'Apple Store, multinationale américaine pratiquant l'évasion fiscale, l'absence de maîtrise réelle du système (et donc de compréhension intime) et de ses évolutions sont des arguments suffisants, surtout dans le public. Mais sinon, c'est un environnement cohérent, plutôt agréable à utiliser, qui te classe du côté des "libéraux" (au sens américain ) friqués, que du bon.

   Bref, il me semble que le terrain purement technique est voué à l'échec (sauf peut-être sur des cas d'usage bien particuliers ). Si tu abandonnes les arguments éthiques et d'autonomie à long terme, ça devient une question de préférence, et là le marketing d'Apple joue contre toi... »

Olivier Mehani OM :
« Même problème ici : je suis dans un boîte 100 % OS X. Il y a du bien et du moins bien.

   C'est un Unix, donc nettement plus pratique que Windows. L'argument des outils bureautiques est, certes, vrai, mais je constate aussi que de plus en plus de sites visent d'abord OS X avant de viser Linux, ce qui fait que les choses type WebRTC ou autre marchent parfois mieux (par exemple, partage d'écran ou de fenêtres sur certains sites).

   Par contre, il faut tout un tas d'apps non libres et non gratuites pour que ton UI fonctionne comme tu le veux (raccourci, comportement des fenêtres, comportement de la souris...).

   Ensuite, la gestion des paquets est nulle. Principalement parce qu'il n'y en a pas. Tu dois tout installer à la main et mettre à jour au cas par cas. Homebrew simplifie un peu les chose pour l'install outils Unix classiques, et Cask pour les Apps OS X, mais la mise à jour laisse toujours à désirer.

   Enfin, eh bien... la faille du système d'authentification pour macOS High Sierra
https://www.wired.com/story/macos-high-sierra-hack-root/.

   Ceci dit, tu peux aussi installer un vrai Unix sur ton Mac ! »

EN :
« Moi je serai sous PC/Linux, faut pas pousser non plus, c'est les gens dont je dois surveiller et aider au développement (des bio-informaticiens plutôt novices en dév info) qui seraient (car c'est pas encore fait) sous Mac. Mais au final ce sera toujours moi qui serai embêtée car c'est moi qui vais les aider à déboguer, bien coder etc. Mais c'est pas mal ton lien : "cette nuit quelqu'un a passé tous les Mac du bureau sous Linux, c'est bizarre...".

   Enfin bon, que de temps et d'argent perdu pour rien quand même... »

Bastien Guerry BG :
« D'abord, je compatis.

   Ensuite, pourquoi ne pas inverser la charge de la preuve ?

   Ce n'est pas aux GNU/Linuxiens de montrer que leur environnement de développement est plus adapté mais aux MacOSXiens !

   Pourquoi ne pas piquer les chercheurs dans ce qu'ils ont de plus précieux, leur orgueil scientifique ?

   Ont-ils mis en place une méthode scientifique pour choisir les outils qui leur serviront à produire du code ?

   À défaut de l'éthique tout court, au moins l'éthique scientifique devrait pouvoir jouer dans cet environnement.

   Deux centimes, peut-être 1,98. »

Patrick Sinz PS :
« En fait le principal problème de macOS c'est que ca marche "presque" et après c'est l'enfer, ta librairie a été packagée pour le kit de compatibilité 1 mais la librairie b ne marche qu'avec...

   Et la gestion utf8 est juste assez bizarre pour que... etc. »

HR :
« Il s'agit ici de choisir des machines et un système d'exploitation pour une équipe de développeurs. Malheureusement aujourd'hui on n'en est pas encore à convaincre les dirigeants de ne pas s'acheter (pour eux-mêmes) des Macs juste par coquetterie. Le combat actuel est de les convaincre d'acheter les outils qui conviennent aux équipes techniques, donc pas là pour faire joli en réunion. »

SF :
« En effet, et du coup tout dépend du type de logiciels à développer (pour quel type de plate-forme ?), avec quels outils (langages, IDE...).

   Dans certains cas (le mien), le mieux c'est d'avoir une équipe hétérogène : chacun développe sur sa plate-forme préférée (Mac, Linux, Windows), avec ses petites habitudes (éditeur ou IDE, navigateur...). Si on a des développeurs suffisamment autonomes avec leurs outils on a les avantages suivants :

1) Même s'il s'agit d'un logiciel serveur (typiquement destiné à Linux) mais si il est open source, en ayant une équipe diverse elle sera aussi nécessairement plus accueillante pour des contributeurs divers.

2) Si on doit développer pour plusieurs plates-formes, alors l'avantage est encore plus évident.

   Si on a des développeurs peu autonomes (sur la configuration et la maintenance de leurs outils), c'est plus embêtant, il vaut mieux leur fournir un environnement cadré qu'on est capable de supporter.

   Dans tous les cas, il faut quand même avoir sélectionnés des outils de développement (langage, linters, packagers...) qui sont suffisamment multi-plates-formes.

   Quand on a la chance de faire et d'utiliser des outils open source, on peut se réjouir de la diversité actuelle des développeurs open source et du fait qu'on trouve de bonnes solutions pour développer dans tous les environnements courants :

• L'immense majorité des outils de développements supportent les 3 plates-formes et leurs variantes.

• Il est relativement facile d'installer la plupart des ces outils en utilisant soit un gestionnaire de paquets natifs (apt / yum / ...), soit un gestionnaire de paquets tiers (Homebrew marche super bien sous MacOS, Cygwin mais aussi Nuget et Chocolateyr sous Windows...), ou encore un gestionnaire de paquets spécifique à un environnement de développement (maven, pip, npm...).

   Enfin, n'oublions pas que la tendance actuelle est au cloud. Cela fait déjà plus de 5 ans (ex : https://www.silicon.fr/conference-javascript-s'attaque-aux-applications-d'entreprise-43712.html?inf_by=5a22b16f671db8a6768b4af5 où on avait parlé de Cloud9) que l'on a des IDE "full web", et le mouvement s'accélère (cf. l'annonce d'Amazon cette semaine : https://aws.amazon.com/cloud9/) mais aussi le fait que de plus en plus d'application "Desktop" (en plus de mobiles) sont développées en utilisant des technologies "Web" (notamment Electron : https://electronjs.org/). On peut bien sûr (et on doit) s'interroger sur ces deux tendances, qui poussent à l'extrême la citation de Marc Andreesen en 1995 et visent à reléguer les OS « traditionnels » (i.e. non cloud) à a poorly debugged set of device drivers (en d'autre terme, à commoditiser l'OS et mettre toute la valeur dans le Cloud).

   Linux étant, d'une certaine façon, l'OS du Cloud, on pourra dire qu'on aura « gagné », mais si les valeurs de ce cloud ne sont pas celles (liberté, pérennité, interopérabilité...) que l'on défend, on aura perdu.

=> Le débat sur le cloud ouvert est primordial (oui je détourne le thread). »

HR :
« En reprenant à la suite de l'explication de Laurent Bloch [(cf. ci-dessous, en fait)] sur ce qu'est la bio-informatique, les algorithmes qui répondent effectivement aux questions des biologistes sont encore à inventer. On parle donc bel et bien de recherche. Les équipes en question vont évidemment et dans un premier temps utiliser des logiciels de calcul numériques dits "haut niveau", dans ce contexte ça veut dire "interprétés", à savoir R, Octave (ou MATLAB, si vraiment le labo tient à dépenser des sous pour rien), Python, etc. Edlira nous dira ce qu'elle préfère. Par la suite, quand ça commence à marcher et que les données s'accumulent, on passe à un langage plus proche de la machine dans un soucis de performance. Du C ou à la rigueur du FORTRAN, et bien souvent dans les disciplines déjà bien établies comme l'est certainement la bio-informatique, à l'aide de bibliothèques développées dans ce but spécifique, et donc dans le meilleur des cas, libres, pour que tous les chercheurs puissent contribuer.

   C'est peut-être pas exactement ce qu'Edlira a en tête, mais je parle d'expérience après un doctorat et quelques recherches post-doctorales en maths appliquées au traitement du signal et à l'apprentissage statistique (donc même schéma : on développe un modèle, on l'implémente en haut niveau, on l'implémente en bas niveau). Je connais exactement les besoins pour ce genre d'activités, et je peux concrètement dire que :

• pour le développement "haut niveau" (langage interprété), Mac et Linux sont tous deux aussi pratiques (Windows est déjà loin derrière, mais il est écarté dès le début de la discussion) ;

• pour le développement "bas niveau", où il faut avoir un meilleur contrôle des librairies et du système en général, Mac commence à poser problème ;

• les besoins sont cantonnés au calcul numérique, donc les quelques avantages matériels que peuvent procurer Mac, en terme de meilleure fiabilité des périphériques typiquement (quand ils sont estampillés Apple, bien évidemment), ne sont pas intéressants ici. J'insiste, quand on connaît son besoin et qu'on s'y cantonne, ce qui importe ce sont les composants dans la machine (nombre et type de processeurs, nombre et type de barrettes mémoire, éventuellement GPU), et à composants égaux, Mac est de mon expérience (récente, mais pour un achat personnel) 50 % plus cher.

   Il y a un dernier point, moins évident mais tout aussi important, que je souhaiterais argumenter : si les développeurs en question sont jeunes (genre étudiants en master, thèses, ou jeunes ingénieurs). Si on leur met GNU/Linux dans les mains aujourd'hui, ils auront plus de chances de s'habituer à un élément important de la culture du libre : tout est transformable et adaptable à ses besoins (il suffit de lire le manuel et de modifier le fichier .conf qui va bien). D'expérience, ceux qui restent sous Mac ou Windows prennent l'habitude de s'adapter à l'outil qui est disponible. Les gens habitués au libre chercheront plus à adapter l'outil à leurs besoins. Le gain n'apparaît bien sûr que sur le long terme, mais dans un domaine comme la recherche, il est significatif et on sait reconnaître tout de suite ceux qui ont appris à le faire.

   C'est sans appel. Edlira, tu ne peux pas abandonner ce combat ; si on perd ici, on n'a plus qu'à tous se convertir à la coquetterie. »

BL :
« Je dois dire que je suis impressionné par la qualité de la discussion, compétence et ouverture.

   Je me demande si cela est transféré ou transférable aux décideurs.

   Un point (évident) qui ressort : les machines de développement ne sont pas nécessairement les futures machines d'exploitation... qui pour des applications demandant une forte puissance seront vraisemblablement des machines Linux. Mais je suppose que la machine de développement est généralement celle sur laquelle le code est testé, ce qui devrait avoir des conséquences. Je le souligne car cela m'a semblé plus implicite qu'explicite dans les interventions. »

SF :
« As-tu pensé a regarder du côté de Cython, qui est la progression logique quand on veut optimiser du code numérique Python ?

   (Pour ceux qui ne connaissent pas, Cython est une variante de Python avec des annotations de type supplémentaire, qui compile vers du C/C++, et dont l'interopérabilité avec Python est grandement facilité. C'est ce qui est souvent utilisé par scikit-learn, entre autres projets intensifs en calcul.)

   Il y a même un article de recherche sur le sujet : http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.834.9167&rep=rep1&type=pdf).

   Sinon :

• Go est relativement simple à apprendre, mais pas évident à intégrer avec Python du fait qu'il a son propre runtime (GC...)
• Rust a un modèle qui le rend plus simple à intégrer à Python, et il y a des gens qui le font, mais à ce stade ça demande encore pas mal d'efforts.

Cf. https://blog.sentry.io/2017/11/14/evolving-our-rust-with-milksnake et http://lucumr.pocoo.org/2015/5/27/rust-for-pythonistas/ pour une introduction. »

EN :
« Oui je connais un peu, j'ai vu des utilisations et en ai deboggué une implémentation une fois. Je n'ai pas trouvé ça hyper sympa à utiliser, et c'est probablement psychologique, mais je trouve ça un peu cra cra un code python avec Cython compilé C++ et je n'ai pas eu l'occasion d'en profiler, mais bon quand il faut il faut :) Par contre il y a pas longtemps j'ai vu en séminaire une implémentation qui passait du Go au C, presque sans avoir rien à faire (pas d'annotation de types par exemple comme en Cython) et cela semblait trop simple pour être vrai. Mais je n'ai pas creusé la chose.

   Le truc c'est qu'il faudrait se demander surtout en amont du projet, quel est le meilleur langage que je choisis pour faire telle chose. Et c'est une question assez difficile je trouve, personnellement je mets beaucoup de temps à décider ce genre de choses. Et comme on le sait, même en recherche, la mode est à la rapidité, à la performance et à l'efficacité. J'entends très souvent des gens dire "on va choisir snakemake, voyons, c'est évident, c'est trop cool", "on va prendre des Macs voyons, c'est Unix c'est solide" :) "on va tout faire sur Docker voyons, un script = un Docker pour pouvoir le relancer" bon et j'en passe. Et c'est peut être que je suis un peu lente, mais je trouve pas ça si évident, je n'ai toujours pas compris pourquoi snakemake est trop cool pour les scripts d'analyses de données, pourquoi Docker c'est mieux qu'un travail rigoureux et documenté avec dépendances bien gérées à la paquet debian, pourquoi les MACs sont mieux etc. Dans le privé, où j'ai travaillé pendant 8 mois (bon je sais c'est pas bcp) ils avaient pleins de défauts, mais au moins ils me laissaient faire mes tests, évaluer etc, prendre un certain temps avant de prendre des décisions techniques. Mais bon encore une fois ça doit dépendre des labos. »

HR :
« Edlira, un grand merci pour ta réponse détaillée, et positive qui plus est. Ça donne envie de venir travailler avec vous !

   Pour l'amour de la connaissance, prends ton temps ! Comme ça on sera deux, et en plus de gagner en pertinence, on gagnera peut-être en crédibilité (parce qu'au train où ça va, en recherche on peut plus être crédible sans un CV pollué par une liste interminable d'articles bidon publiés dans des conférences obscures).

   Et puisqu'on en est à parler de choix concrets de logiciels, je me dois de faire part de mon émerveillement devant `Rcpp`, la bibliothèque R qui permet d'interfacer du code C/C++ directement et sans effort : Tu #include <Rcpp.h> , tu écris ta fonction C (avec des types qui conviennent, genre NumericMatrix), tu rajoute // [[Rcpp : :export]] devant (et aussi // [[Rcpp : :plugins(openmp)]] si tu as eu la bonne idée de paralléliser quelques tâches avec OpenMP), et hop ! quand tu interprètes le code avec `sourceCpp("code.cpp")`, ça compile le C++ à la volée et te crée une fonction que tu peux appeler directement dans R. C'est absurdement simple, et ça permet une chose en plus : faire explicitement des passages par référence dans un code interprété. Je n'ai aucune expérience avec Cython, mais avant je faisais du Mex pour Octave/Matlab, et je peux te dire que c'est sans commune mesure. En plus, le développeur (Dirk Eddelbuettel) est facilement accessible (R mailing list de préférence, éventuellement Stack Overflow). À mon sens, seule la documentation pèche un peu parce que l'outil est trop riche, avec par exemple toute une collection de simplificateur syntaxique du code C lui-même, superflue à mon sens, et donc ça a l'air compliqué de prime abord. »

Arguments sur l'organisation du travail et la formation

LB :
« Oui, j'appuie Bastien et Hugo : si tu dois encadrer l'équipe de développement, il va de soi que c'est toi qui choisis les outils. Et pour développer il faut toutes sortes de logiciels dont la version macOS est soit inexistante, soit difficile à mettre en œuvre, alors que Linux a été conçu dès le départ pour du développement, ce qui du coup le rend moins disponible pour iTunes, Kindle Reader et autres colifichets qui n'ont pas lieu d'exister dans ton travail. »

Bernard Lang BL :
« Intéressante discussion

   Peut-être que l'on avancerait un peu si on savait ce que c'est qu'un bioinformaticien qui fait du développement.

   Par exemple un écono-informaticien qui fait du développement, c'est souvent le titre technique d'un comptable qui fait des tableaux de chiffres.

   C'est quoi, le genre de programmes qu'ils écrivent, les outils qu'ils utilisent ou devraient utiliser, les compétences informatiques mises en œuvre, etc.

   Il y a peut-être d'autres questions de ce genre qui permettraient de mieux cerner le problème, car je ne suis pas sûr que tout le monde parle de la même chose. »

LB :
« Alors je crois pouvoir en parler, puisque j'ai dirigé le service d'informatique scientifique de l'Institut Pasteur pendant dix ans et que nous y avions créé un cours d'informatique pour biologistes de 400 heures (deux langages de programmation, réseau, système, modélisation moléculaire, alignement de séquences, etc.), j'ai mis cela sur mon site :

Enseigner l'informatique aux biologistes
https://laurentbloch.net/MySpip3/Enseigner-l-informatique-aux-biologistes

Rapport d'activité de l'informatique scientifique à Pasteur
https://laurentbloch.net/Data/RapportPasteur/Html/index.html

   Je suis un peu attristé que le cours Pasteur ait disparu au profit de formations aux "usages", et que la grande équipe de bio-informatique https://research.pasteur.fr/fr/center/c3bi/ créée récemment à Pasteur ne compte pratiquement pas de vrais informaticiens : où sont-ils ?

   Dans un contexte de recherche, la bio-informatique ne peut pas se limiter à utiliser les logiciels existants, mais doit se donner les moyens d'en créer, et au minimum de bien comprendre comment ils fonctionnent. R pour le traitement de données et les statistiques, BLAST, FastDNAml et ClustalW pour les séquences c'est très bien, mais en rester là c'est insuffisant, et le biologiste lui-même doit s'approprier l'informatique, ne serait-ce que pour comprendre ce qu'il fait.

   Je poursuis une partie de cet enseignement aujourd'hui au Cnam.

   Certes, les choses évoluent, mais envisager les bio-informaticiens comme des techniciens auxquels des biologistes ignorants de l'informatique diraient "fais moi ci, fais moi ça" me semble voué à l'échec, justement parce que les choses évoluent, plus que pour la comptabilité. »

BL :
« Il me semble que le principal critère pour un développeur payé par l'argent public est de s'assurer que les logiciels développés ne sont pas dépendants d'une plate-forme particulière. C'est d'ailleurs le pendant naturel de l'élaboration d'un enseignement qui ne soit pas dépendant de fournisseurs spécifiques. »

LB :
« Allez, c'est l'heure à laquelle chacun y va de son langage préféré, j'y vais aussi : Scheme bien sûr, Node.js est à la mode, mais pour améliorer l'acceptabilité de la chose je regarderais Scala.

   Oui, je précise : c'est mon expérience des bioinformaticiens, je les ai vus ramer avec malloc, sizeof, typedef et autres struct, alors un langage avec GC me semble s'imposer. »

BL :
« Voilà une question qui me titille. Quelles sont les raisons invoquées pour utiliser des langages sans GC, en dehors de C (qui d'ailleurs peut avoir un GC conservatif) ?

   Bon... je sais qu'il y a des applications spécifiques qui ne font pas d'allocation mémoire significative). »

LB :
« Langages sans GC, typiquement C : pour écrire l'OS, les pilotes, le scheduler, etc. Sinon il n'y a aucune raison sérieuse de s'exposer aux erreurs liées à l'absence de GC, et au surcroît de difficulté de la programmation. »

SF :
« On rentre dans des débats d'experts, mais bien sûr Python et Cython gèrent la mémoire tous seuls comme des grands.

   Quant à Rust, il n'a pas de GC, mais c'est le système de types qui permet de fournir des garanties fortes à la compilation sur la sûreté de l'utilisation de la mémoire.

Détails par exemple ici : http://zee-nix.blogspot.fr/2017/05/rust-memory-management.html  »

Alain Louge AL :
« 1) Je comprends mal, même si c'est dans l'air du temps, comment on peut appeler « informaticien » quelqu'un qui rame avec malloc()... Je sais bien que l'époque est à l'esbroufe, mais à ce point ! Un informaticien, quel que soit le préfixe, bio- ou autre, c'est, selon ma conception des choses, quelqu'un qui a étudié l'informatique jusqu'à bac+5, avec les bases culturelles nécessaires pour comprendre ; bref, tronc commun math et sciences au moins à bac+2.

2) Je comprends mal, même si c'est dans l'air du temps, pourquoi on laisse des chercheurs en Biologie, en Mécanique, en n'importe quoi, programmer eux-mêmes. Sauf exception, ils n'en ont pas la compétence, et écrivent en général du code exécrable, voire pire, et, qu'ils l'aient ou non, y dilapident leur temps (donc l'argent du contribuable) au lieu de pratiquer leur recherche. Et il ne viendrait à l'idée de personne de demander aux informaticiens, les vrais, de faire la Biologie ou la Mécanique à leur place.

3) Vu le nombre d'écoles d'informatique, et la qualité de la formation dispensée par certaines d'entre elles, je ne comprends toujours pas comment les laboratoires de recherche ne prennent pas au moins des étudiants en stage, ou le cas échéant, n'embauchent pas des informaticiens dignes de ce nom pour écrire à la demande des chercheurs et selon leurs indications du code de qualité. J'ai vu cette pratique salutaire mise en œuvre à quelques endroits, et ignorée activement ailleurs.

4) Tant qu'on y est, et autour du sujet précis en discussion, je ne comprends pas non plus comment on peut écrire, au hasard, des codes de dynamique moléculaire sans même se poser la question de la validité mathématique de la méthode. Dès MathSup, j'ai été averti des pièges de l'Analyse numérique, par exemple avec le phénomène de Gibbs ou l'instabilité de l'intégration d'Euler explicite. J'ai eu affaire à pas mal de chercheurs de spécialités variées pratiquant ce genre de simulation, et tous ignoraient l'existence de l'Analyse numérique et des difficultés qu'elle traite, et l'idée que leur petite méthode intuitive puisse ne pas converger vers une solution valide semblait hors de leur univers mental.

5) Bref, et pour conclure en revenant au sujet d'origine, j'ai quand même l'impression que si l'on fait, légitimement, appel à de vrais informaticiens pour écrire du code, la question du choix entre Linux et MacOS est un peu simplifiée...

   J'ai nécessairement résumé à outrance ma position ; j'ajouterai donc que les chercheurs doivent avoir un peu de culture, y compris en informatique, pour être capables de dialoguer avec les informaticiens, et ces derniers doivent, c'était ma proposition initiale, avoir assez de culture générale mathématique et scientifique pour faire l'autre moitié du chemin. Mais une fois que chacun a compris les besoins de l'autre, que chacun fasse son travail dans son domaine. J'ai tellement vu des matheux, ou pire, des physiciens, recommencer à partir de zéro un nouveau programme (en FORTRAN VAX...) chaque fois que le problème à traiter était un peu différent... »

Pierre Jarillon PJ :
Réponse au point 2) d'Alain Louge : « C'est ce raisonnement qui conduit à des échecs cuisants qui se comptent parfois en centaines de millions d'euros.

   J'ai connu l'époque où on avait des analystes et des programmeurs. Ces derniers étaient qualifiés de "pisseurs de code". Ils voyaient parfois des erreurs mais ce n'était pas à eux d'intervenir. Cette époque est maintenant heureusement révolue car l'analyste peut faire le code dans le temps où il le spécifiait.

   Nous avons eu ensuite la grande époque où on fait un cahier des charges, il est confié à un sous-traitant qui va rédiger des spécifications techniques et on va le confier à un autre sous-traitant qui va produire le logiciel avec le fameux cycle en V ou en W. C'est l'époque des plus grands fiascos informatiques. Encore une histoire de séparation des fonctions.

   Les raisons de ces échecs retentissants sont :

• on est capable de vérifier que le logiciel est conforme aux spécifications mais on n'est pas capable de vérifier que les spécifications sont conformes au besoin.
• informatiser une fonction change les conditions dans laquelle elle s'effectue, rendant faux le cahier des charges et les spécifications. C'est tout le contraire de la méthode agile.
• le demandeur peut exiger des choses qu'il croit simples alors qu'elles ne le sont pas du tout (voire impossibles) pour l'informaticien.
• l'informaticien pourrait proposer des choses simples pour lui et d'une grande utilité pour le demandeur mais ce n'est pas son rôle et ne connaissant pas bien le métier, il n'ose pas le faire.
• affecter tous les membres d'une équipe à de nouveaux projets sous prétexte que la tâche est terminée conduit à faire intervenir ensuite des mercenaires qui vont, faute de temps, massacrer le code et y introduire verrues sur verrues. Le code devient peu à peu non maintenable.

   L'idéal serait que la personne du métier et l'informaticien soient une seule et même personne. C'est un cas rare et même de plus en plus rare. Il ne faut plus trop y compter. Alors que conseiller à Edira ?

Je pense qu'elle l'a trouvé toute seule et je ne peux que lui conseiller de persévérer dans cette voie. Il faut associer un biologiste avec un informaticien en favorisant à chacun une très bonne compréhension du métier de l'autre. Ainsi, le biologiste et l'informaticien pourront dialoguer efficacement, trouver les meilleurs algorithmes et les meilleurs logiciels correspondant aux besoins.

   Cette connaissance mutuelle du métier de l'autre est la clé de la réussite. Il est peu envisageable d'être expert dans deux domaines. C'est dans la zone de compétences communes que peut s'effectuer le meilleur dialogue. »

LB :
« Point 3) d'Alain Louge : "vu le nombre d'écoles d'informatique, et la qualité de la formation dispensée par certaines d'entre elles, je ne comprends toujours pas comment les laboratoires de recherche ne prennent pas au moins des étudiants en stage, ou le cas échéant, n'embauchent pas des informaticiens dignes de ce nom pour écrire à la demande des chercheurs et selon leurs indications du code de qualité."

   Toute l'aporie est dans la locution "à la demande des chercheurs et selon leurs indications" : hors recherche cela marche déjà assez mal, alors en recherche ce ne sera souvent qu'en essayant de programmer eux-mêmes leurs problèmes qu'ils les comprendront vraiment, ou du moins mieux, au fur et à mesure de leurs approximations successives.

   Alors c'est ainsi : les bio-informaticiens sont en général des gens qui ont effectué un cursus de biologie ou de biochimie, et qui ensuite apprennent à programmer, de ce fait ils n'ont pas forcément toute la culture ni la vision du monde d'un informaticien pur sucre.

   Cette situation n'est pas parfaitement satisfaisante, mais elle est bien moins mauvaise que celle, que j'ai eu l'occasion d'essayer, où des chercheurs qui ignorent tout de l'informatique donnent de soit-disant spécifications à des informaticiens considérés comme de simples exécutants.

   C'est pourquoi la situation décrite par Edlira, avec des bio-informaticiens à la formation incomplète mais supervisés par une vraie informaticienne qui pourra les conseiller et les guider, est sans doute la moins mauvaise solution.

   Au risque de me répéter, j'ai un peu écrit cela ici ou là :
https://laurentbloch.net/MySpip3/Enseigner-l-informatique-aux-biologistes
https://laurentbloch.net/MySpip3/Pourquoi-Scheme-48

Et puis on n'a jamais fini d'apprendre à programmer... »

Paru le 9 décembre 2017 sur le site de Laurent Bloch.
https://laurentbloch.net/MySpip3/Le-systeme-qu-il-faut-a-des-developpeurs-un-Unix-libre

Dimension irrationnelle des comportements d'achat

[EN] : « Comme l'expliquait le dernier prix Nobel d'économie [Richard Thaler] dans [ces] émissions :
• https://www.franceculture.fr/le-prix-nobel-2017-souligne-comment-l-economie-depend-de-l-humain
• https://www.franceculture.fr/emissions/les-nouvelles-de-leco/les-nouvelles-de-leco-lundi-9-octobre-2017
l'économie et la finance reposent pour une partie non négligeable et non quantifiable sur une dimension "irrationnelle" qu'il essayait lui d'analyser.

Ça s'appelle de l'économie comportementale. Et depuis que j'ai entendu parler de ça j'y pense souvent à des occasions variées. Et notamment j'y ai beaucoup pensé dans cette histoire de comparaison et de débats Mac/pas Mac avec ma cheffe. J'ai essayé de quantifier et de rationaliser le débat au maximum, mais au final cela compte peu... C'est nos comportements et notre volonté à mettre en question et changer ces comportements qui ont finalement compté.

Par exemple, en discutant avec ma cheffe sur les prix des Mac et la comparaison que j'ai faite, je me disais que ça ne servait pas à grand chose en effet cette comparaison en pratique, si ce n'est pour qu'elle ose moins me dire que la différence de prix entre Mac et non Mac n'est pas significative. Donc maintenant elle ne pourra plus me dire ça. Mais par contre cela ne changera pas nos comportements respectifs. Car, par exemple le fait que je ne puisse pas dans un Mac changer un composant matériel en cas de panne sans passer par Apple de par les limitations logicielle et matérielles qu'il impose, mais que je puisse faire ça plus facilement sur un PC hautement configurable, pour moi cela n'a pas de prix quantifiable, car c'est en gros le prix de la liberté pour moi. Mais pour elle, c'est le prix à payer pour avoir un bel ordinateur qu'elle croit dur comme fer stable et professionnel et facile d'utilisation et abouti comme personne d'autre qu'Apple ne serait capable de faire. Donc ça c'est pas quantifiable.

Bon au final résultat de nos discussions sur toute cette histoire : dans notre labo il y a aura deux achats : un serveur de production Linux (pour mettre les logiciels développés en utilisation) et un serveur de développement sous Linux. Donc les gens seront, pendant leur développement, en ssh , sur ce serveur et n'aurant pas le droit de développer ailleurs ou sur leur ordi de bureau.

Sur leur bureau ils seront sous "ce qu'ils choisiront" en sachant (d'après l'ancien thésard de ma cheffe avec qui j'ai travaillé une semaine) que ce sera interdit d'écrire une thèse en LaTeX ou autre document scientifique, car la cheffe veut pouvoir facilement et comme elle le veut modifier et aider à l'écriture (il y a eu débat animé sur Illustrator, Inkscape, retouchage de graphes svg, la mocheté des thèses et articles de bio qui sont pas sous LaTeX mais sous des Office trucs). Donc je ne vois pas du coup comment ils peuvent choisir d'être sous Linux s'il faut retoucher les graphes en Illustrator et rédiger en doc.

En bref, il y aura deux serveurs sous Linux, un ordi sous Linux le mien, ma cheffe sous Mac et trois personnes à influencer/demander sur quel système ils vont choisir pour leur ordi de bureau.

C'est mieux que "nous serons un labo basé sous Mac, oh yeah", mais c'est pas le top non plus. J'ai fait ce que j'ai pu :)

Merci en tout cas pour vos échanges, ça m'a beaucoup aidé et j'ai encore des trucs à regarder dessus. »

Cet article est sous licence Creative Commons (selon la juridiction française = Paternité - Pas de Modification). http://creativecommons.org/licenses/by-nd/2.0/fr/

NOTES

[1] Association Francophone des Utilisateurs de Logiciels Libres.

[2] [LB] Rectification historique : Steve Jobs s'est tourné vers BSD et Mach lorsqu'il a créé NeXT Computer en 1985, racheté par Apple lorsqu'il y est revenu en 1996.