diff --git a/.gitignore b/.gitignore index 5b4c628..eb2ee0c 100644 --- a/.gitignore +++ b/.gitignore @@ -219,3 +219,7 @@ talk.vrb /talks/packaging-con-2021/grail/images/bootstrap-graph-reduced.pdf /talks/packaging-con-2021/grail/images/bootstrap-graph.pdf /talks/packaging-con-2021/grail/images/pytorch-graph.pdf +/doc/sif-2021/article-1024.bbl +/doc/sif-2021/article-1024.bib +/doc/sif-2021/article-1024.pdf +/doc/sif-2021/article-1024.tex diff --git a/doc/sif-2021/article-1024.org b/doc/sif-2021/article-1024.org new file mode 100644 index 0000000..2410fb1 --- /dev/null +++ b/doc/sif-2021/article-1024.org @@ -0,0 +1,594 @@ +#+TITLE: Reproduire les environnements logiciels : un maillon incontournable de la recherche reproductible +#+AUTHOR: Ludovic Courtès +#+ORGANIZATION: Inria +#+DATE: 26 juillet 2021 +#+STARTUP: content hidestars +#+LANGUAGE: fr +#+LATEX_CLASS: article +#+LATEX_CLASS_OPTIONS: [a4paper] +#+LATEX_HEADER: \usepackage{xcolor} +#+LATEX_HEADER: \usepackage[T1]{fontenc} +#+LATEX_HEADER: \usepackage[french]{babel} +#+LATEX_HEADER: \definecolor{darkblue}{rgb}{0.0, 0.0, 0.55} +#+LATEX_HEADER: \definecolor{cobalt}{rgb}{0.0, 0.28, 0.67} +#+LATEX_HEADER: \definecolor{coolblack}{rgb}{0.0, 0.18, 0.39} +#+LATEX_HEADER: \PassOptionsToPackage{hyphens}{url}\usepackage[colorlinks=true, linkcolor=coolblack, urlcolor=cobalt, citecolor=coolblack]{hyperref} +#+LATEX_HEADER: \RequirePackage[hyphens]{url} +#+LATEX_HEADER: \usepackage{libertine} +#+LATEX_HEADER: \usepackage{inconsolata} +#+OPTIONS: toc:nil num:nil + +* COMMENT What’s this? + + This is an article for “[[https://www.societe-informatique-de-france.fr/bulletin/][1024]]”, the bulletin of the Société + Informatique de France (French computer science society). + +* Introduction + + Un constat est largement partagé : puisque les logiciels font + dorénavant partie intégrante du processus scientifique, une démarche + de recherche reproductible — un pléonasme ! — doit intégrer le + logiciel. Mais de quelle manière au juste ? + + Le Deuxième Plan national pour la science ouverte + [[cite:mesri2021planscienceouverte]], publié en juillet 2021, « soutient » + la diffusion du code source des logiciels de recherche sous licence + libre permettant la diffusion sans restriction, mais aussi la + modification et la diffusion de versions modifiées. C’est une + transcription naturelle du processus scientifique : le travail de + critique ne peut se faire correctement que si les pairs peuvent + étudier le code source et faire leurs propres expériences. Le Plan + insiste aussi sur la conservation des codes sources grâce à Software + Heritage sans laquelle ce travail devient vite impossible. + + Que le code source soit disponible est une condition nécessaire mais + pas suffisante. Les sociétés savantes ont mis en place un système de + badges pour évaluer le niveau de reproductibilité des résultats + décrits dans leurs publications. Celui de l'/Association for Computer + Machinery/ (ACM) dispose de trois niveaux selon que le code soit + disponible (premier niveau), utilisable (deuxième niveau), ou que les + résultats aient été reproduits indépendamment en faisant tourner le + code[fn:2]. La reproduction des environnements logiciels — le fait de + pouvoir déployer précisément l’ensemble logiciel qui a servi à une + production scientifique — est un aspect qu’on relègue volontiers au + rang de détail technique mais qui est pourtant incontournable pour + parvenir à cet objectif de reproductibilité. Quels outils, quelles + méthodes existent pour y parvenir ? + + +* Entre « gestion » et « gel » des environnements logiciels + + Beaucoup de logiciels de recherche sont développés pour GNU/Linux et + tirent parti des outils de déploiement logiciel qu’on y trouve. Les + « distributions » GNU/Linux telles que Debian et Ubuntu se basent sur + des outils de /gestion de paquets/ comme =apt= qui permettent + d’installer, de mettre à jour ou de retirer les logiciels. Ces outils + ont une vision du /graphe de dépendance/ des logiciels et permettent + de savoir quels logiciels sont présents sur la machine. + + Malheureusement, ces outils ont deux limitations : ils requièrent les + droits d’administration système, et ils ne permettent de déployer + qu’un seul environnement logiciel à la fois. Pour cette raison, en + particulier dans le domaine du calcul intensif (ou HPC, pour + /high-performance computing/), on a développé d’autres outils de + gestions de paquets destinés à être utilisés /par dessus/ celui du + système, avec l’avantage d’être utilisable sans les droits + d’administration, par chaque utilisateur·ice, qui peut ainsi déployer + son ou ses environnements logiciels. Les outils populaires dans cette + catégorie incluent CONDA, Spack et EasyBuild, ainsi que des outils + propres à un langage de programmation (pour Python, Julia, R, etc.). + + L’expérience a rapidement montré que cet empilement d’outils de + déploiement devient vite préjudiciable à la reproductibilité, car + chaque outil ignore celui « du dessous », bien qu’il dépende de ce que + celui-ci a installé. Autrement dit, chaque outil ne voit qu’une + partie du graphe de dépendance de l’ensemble. À cela s’ajoute le fait + que, même pris individuellement, ces outils ne permettent pas ou + difficilement de reproduire un environnement logiciel à l’identique. + C’est notamment pour cette raison qu’une deuxième approche du + déploiement logiciel s’est popularisée : celle qui consiste à /geler + l’environnement logiciel/, plutôt que d’essayer de le décrire. + + L’idée peut se résumer ainsi : puisqu’il est difficile voire + impossible de redéployer un environnement logiciel à l’identique en + utilisant ces outils de gestion de paquets, créons l’environnement une + fois pour toutes puis sauvegardons les octets qui le composent — les + fichiers de chaque logiciel installé. On obtient ainsi une /image/ + binaire, qui permet, sur n’importe quelle machine et à n’importe quel + moment, de relancer les logiciels scientifiques d’intérêt. Le plus + souvent, on utilise les outils à base de « conteneurs » Linux, tels + que Docker ou Singularity, mais une machine virtuelle peut aussi + remplir cette fonction. + + L’approche est séduisante : puisqu’on a tous les octets des logiciels, + la reproductibilité est totale ; on a la garantie de pouvoir relancer + les logiciels, et donc, de reproduire l’expérience scientifique. Mais + l’inconvénient est de taille : puisque l’on a /que/ les octets des + logiciels, comment savoir si ces octets correspondent vraiment au code + source que l’on croit exécuter ? Comment expérimenter avec cet + environnement logiciel, dans le cadre d’une démarche scientifique, + pour établir l’impact d’un choix de version, d’une option de + compilation ou du code d’une fonction ? L’approche est pratique, + c’est indéniable, mais ces deux faiblesses fragilisent l’édifice + scientifique qui se bâtirait sur ces fondations. + +* Le déploiement logiciel vu comme une fonction pure + + GNU Guix[fn:3] est un outil de déploiement logiciel qui cherche à + obtenir le meilleur des deux mondes : la reproductibilité parfaite des + environnements « gelés » dans des conteneurs, et la transparence et la + flexibilité des outils de gestion de paquets. Il est issu de travaux + à la croisée de l’ingénierie logicielle et des langages, d’abord en + bâtissant sur le modèle de /déploiement purement fonctionnel/ de Nix + [[cite:dolstra2004nix]] et en étendant Scheme, un langage de programmation + fonctionnelle de la famille Lisp, avec des abstractions permettant + d’en tirer partie. En termes pratiques, Guix hérite de Nix les + fondations permettant la reproductibilité d’environnements logiciels + et fournit les outils pour exploiter ces capacités sans expertise + préalable [[cite:courtes2015reproducible]]. + + Le principe du déploiement fonctionnel est de traiter le processus de + compilation d’un logiciel comme une /fonction pure/, au sens + mathématique : les entrées de la fonction sont le code source, un + compilateur et des bibliothèques, et son résultat est le logiciel + compilé. Les mêmes entrées mènent au même résultat ; Guix s’assure + que c’est effectivement le cas en vérifiant que les compilations sont + reproductibles /au bit près/, ainsi que le font d’autres projets + participant à l’effort /Reproducible Builds/[fn:1]. Cette approche + fonctionnelle capture ainsi l’essence de la variabilité du déploiement + logiciel. Car non : une série de noms et de numéros de version de + logiciels /ne suffit pas/ à rendre compte des variations qui peuvent + être introduites lors du déploiement de chaque logiciel. + + Chaque déploiement logiciel est vu comme une fonction pure, la + définition est donc récursive. Mais puisqu’elle est récursive, qu’y + a-t-il « au tout début » ? Quel compilateur compile le premier + compilateur ? On arrive là à une question fondamentale, presque + philosophique, mais qui a un impact très concret sur la transparence + des systèmes logiciels comme l’a expliqué Ken Thompson dans son + allocution pour la remise du prix Alan Turing + [[cite:thompson1984trusting]] : tant que subsistent dans le graphe de + dépendance des binaires opaques dont la provenance ne peut pas être + vérifiée, il est impossible d’établir avec certitude l’authenticité + des binaires qui en découlent. + + Guix s’attaque à ce problème en basant le graphe de dépendance de ses + paquets sur un ensemble de binaires pré-compilés bien identifié et le + plus petit possible — actuellement quelques dizaines de méga-octets —, + avec pour objectif de le réduire à un seul binaire suffisamment petit + pour pouvoir être analysé par un humain [[cite:janneke2020bootstrap]]. + C’est là un sujet d’ingénierie et de recherche à part entière. + +* Déclarer et reproduire un environnement logiciel + + Guix peut s’utiliser comme une distribution à part entière, Guix + System, ou alors comme un outil de déploiement par dessus une + distribution existante et donnant accès à plus de 18 000 logiciels + libres. Il fournit une interface en ligne de commande similaire à + celle des outils de gestion de paquets : la commande =guix install + python=, par exemple, installe l’interprète Python, la commande =guix + pull= met à jour la liste des logiciels disponibles et =guix upgrade= + met à jour les logiciels précédemment installés. Chaque opération + s’effectue sans les droits d’administration système. Plusieurs + supercalculateurs en France et à l’étranger proposent Guix et le + projet Guix-HPC, qui implique plusieurs institutions dont Inria, vise + à élargir le mouvement[fn:4]. + + Voyons maintenant comment on peut concrètement, en tant que + scientifique, utiliser cet outil pour que ses expériences + calculatoires soient reproductibles. On peut commencer par lister + dans un /manifeste/ les logiciels à déployer ; ce fichier peut être + partagé avec ses pairs et stocké en gestion de version. L’exemple + ci-dessous nous montre un manifeste pour les logiciels Python, SciPy + et NumPy : + + #+begin_src scheme + (specifications->manifest + '("python" "python-scipy" "python-numpy")) + #+end_src + + Il s’agit de code Scheme. Une utilisation avancée serait par exemple + d’inclure dans le manifeste des définitions de paquets ou de variantes + de paquets ; Guix permet notamment de réécrire facilement le graphe de + dépendance d’un paquet pour le personnaliser, ce qui est une pratique + courante en HPC [[cite:courtes2015reproducible]]. + + Supposons que l’on ait ainsi créé le fichier ~manifeste.scm~, on peut + déployer les logiciels qui y sont listés — et uniquement ceux-là — + avec, par exemple, la commande suivante : + + #+begin_src sh + guix package -m manifeste.scm + #+end_src + + Ce manifeste, toutefois, ne contient que des noms de paquets + symboliques, et pas de numéros de version, options de compilation, + etc. Comment dans ces conditions reproduire exactement le même + environnement logiciel ? + + Pour cela, il nous faut une information supplémentaire : l’identifiant + de révision de Guix. Puisque Guix et toutes les définitions de + paquets qu’il fournit sont stockées dans un dépôt de gestion de + version Git, l’identifiant de révision désigne de manière non ambiguë + /l’ensemble du graphe de dépendance des logiciels/ — aussi bien la + version de Python, que ses options des compilations, ses dépendances, + et ce récursivement jusqu’au compilateur du compilateur. C’est la + commande ~guix describe~ qui donne la révision actuellement utilisée : + + #+begin_src sh + $ guix describe + Génération 107 20 juil. 2021 13:23:35 (actuelle) + guix 7b9c441 + URL du dépôt : https://git.savannah.gnu.org/git/guix.git + branche : master + commit : 7b9c4417d54009efd9140860ce07dec97120676f + #+end_src + + En conservant cette information adossée au manifeste, on a de quoi + reproduire /au bit près/ cet environnement logiciel, sur des machines + différentes, mais aussi à des moments différents. Le plus pratique + est de stocker cette information dans un fichier, au format que Guix + utilise pour représenter les /canaux/ utilisés[fn:5] : + + #+begin_src sh + guix describe -f channels > canaux.scm + #+end_src + + Une personne souhaitant reproduire l’environnement logiciel pourra le + faire avec la commande suivante : + + #+begin_src sh + guix time-machine -C canaux.scm -- \ + package -m manifeste.scm + #+end_src + + Cette commande va d’abord obtenir et déployer la révision de Guix + spécifiée dans ~canaux.scm~, à la manière d’une « machine à voyager + dans le temps ». C’est ensuite la commande ~guix package~ de cette + révision là qui est lancée pour déployer les logiciels conformément à + ~manifeste.scm~. En quoi est-ce différent d’autres outils ? + + D’abord, une version ultérieure de Guix peut reproduire une ancienne + version de Guix et de là, déployer les logiciels décrits dans le + manifeste. Contrairement à des outils comme CONDA ou ~apt~, Guix ne + repose pas sur la mise à disposition de binaires pré-compilés sur les + serveurs du projet ; il peut utiliser des binaires pré-compilés — et + ça rend les installations plus rapides — mais ses définitions de + paquets contiennent toutes les instructions nécessaires pour compiler + chaque logiciel, avec un résultat déterministe au bit près. + + Une des deux différences majeures par rapport à l’approche qui + consiste à geler un environnement dans une image Docker ou similaire + est le /suivi de provenance/ : au lieu de binaires inertes, on a là + accès au graphe de dépendance complet lié au code source des + logiciels. Chacun·e peut /vérifier/ que le binaire correspond bien au + code source — puisque les compilations sont déterministes — plutôt que + de faire confiance à la personne qui fournit les binaires. C’est le + principe même de la démarche scientifique expérimentale qui est + appliquée au logiciel. + + La deuxième différence est que, ayant accès à toutes les instructions + pour compiler les logiciels, Guix fournit aux usagers les moyens + d'/expérimenter/ avec cet ensemble logiciel : on peut, y compris + depuis la ligne de commande, faire varier certains aspects, tel que + les versions ou variantes utilisées. L’expérimentation reste + possible. + + Et si le code source de ces logiciels venait à disparaître ? On peut + compter sur Software Heritage (abrégé SWH), qui a pour mission rien de + moins que d’archiver tout le code source public disponible[fn:6]. + Depuis quelques années, Guix est intégré à SWH de deux manières : + d’une part Guix va automatiquement chercher le code source sur SWH + lorsqu’il est devenu indisponible à l’adresse initiale + [[cite:courtes2019connecting]], et d’autre part Guix alimente la liste des + codes sources archivés par SWH. Le lien avec l’archivage de code en + amont est assuré. + +* Vers des articles reproductibles + + On a vu le lien en amont avec l’archivage de code source, mais le lien + en aval avec la production scientifique est également crucial. C’est + un travail en cours, mais on peut déjà citer quelques initiatives pour + construire au-dessus de Guix des outils et méthodes pour aider les + scientifiques dans la production et dans la critique scientifique. + + Alors que les annexes pour la reproductibilité logicielle des + conférences scientifiques sont bien souvent informelles, écrites en + langage naturel, et laissent le soin aux lecteurs et lectrices de + reproduire tant bien que mal l’environnement logiciel, un saut + qualitatif consiste à fournir les fichiers ~canaux.scm~ et + ~manifeste.scm~ qui constituent en quelque sorte une description + exécutable de l’environnement logiciel. Cette approche a montré ses + bénéfices notamment pour des travaux en génomique dont les résultats + demandent de nombreux traitements logiciels. + + La revue en ligne ReScience C organisait en 2020 le /Ten Years + Reproducibility Challenge/, un défi invitant les scientifiques a + reproduire les résultats d’articles vieux de dix ans ou plus[fn:7]. + C’est dans ce cadre que nous avons montré comment Guix peut être + utilisé pour décrire l’ensemble d’une chaîne de traitement + scientifique, incluant le code source du logiciel dont traite + l’article, les expériences effectuées avec ce logiciel, les courbes + produites dans ce cadre, pour enfin arriver au PDF de l’article + incluant la prose et ces courbes [[cite:courtes2020:storage]]. Toute + cette chaîne est décrite, automatisée, et reproductible, de bout en + bout. Cette approche pourrait être généralisée aux domaines + scientifiques ne requérant pas de ressources de calcul spécialisées ; + nous comptons fournir des outils pour la rendre plus accessible. + + La question du déploiement logiciel se retrouve également dans + d’autres contextes. Guix-Jupyter[fn:8], par exemple, permet d’ajouter + à des bloc-notes Jupyter des annotations décrivant l’environnement + logiciel dans lequel doit s’exécuter le bloc-notes. L’environnement + décrit est automatiquement déployé /via/ Guix, ce qui garantit que les + cellules du bloc-notes s’exécutent avec les « bons » logiciels. Dans + le domaine du calcul intensif et du traitement de données + volumineuses, le /Guix Workflow Language/ (GWL) permet de décrire des + chaînes de traitement pouvant s’exécuter sur des grappes de calcul + tout en bénéficiant de déploiement reproductible /via/ Guix[fn:9]. + +* Adapter les pratiques scientifiques + + La place croissante prise par le logiciel dans les travaux + scientifiques avait, paradoxalement, probablement été une des causes + de la « crise » de la reproductibilité en sciences expérimentales que + beaucoup ont observée — par la perte de bonnes pratiques anciennes + telles que les cahiers de laboratoire. Notre souhait est qu’elle + puisse maintenant, au contraire, permettre une /meilleure/ + reproductibilité des résultats expérimentaux, en refusant de mettre de + côté la rigueur scientifique quand on arrive dans le terrain logiciel. + + De même que les outils de gestion de version sont progressivement + entrés dans la boîte à outils des scientifiques comme un moyen + incontournable de suivre les évolutions d’un logiciel, les outils de + déploiement logiciel reproductible tels que Guix mériteraient faire + partie des bonnes pratiques communément admises. Il en va de la + crédibilité de la démarche scientifique moderne. + + +#+BIBLIOGRAPHY: article-1024 plain + +* COMMENT Bibliographie + + +** Deuxième Plan national pour la science ouverte + :PROPERTIES: + :TITLE: Deuxième {Plan} national pour la science ouverte — {Généraliser} la science ouverte en {France}, 2021–2024 + :BTYPE: misc + :AUTHOR: {Ministère de l’enseignement supérieur, de la recherche et de l’innovation} + :YEAR: 2021 + :MONTH: July + :CUSTOM_ID: mesri2021planscienceouverte + :NOTE: \url{https://www.ouvrirlascience.fr/deuxieme-plan-national-pour-la-science-ouverte/} + :END: + +** Reflections on Trusting Trust + :PROPERTIES: + :TITLE: Reflections on Trusting Trust + :BTYPE: article + :AUTHOR: Ken Thompson + :JOURNAL: Communications of the {ACM} + :YEAR: 1984 + :MONTH: August + :PAGES: 761--763 + :CUSTOM_ID: thompson1984trusting + :END: + +** Connecting Reproducible Deployment to a Long-Term Source Code Archive + :PROPERTIES: + :TITLE: Connecting Reproducible Deployment to a Long-Term Source Code Archive + :BTYPE: misc + :AUTHOR: Ludovic Courtès + :CUSTOM_ID: courtes2019connecting + :NOTE: \url{https://guix.gnu.org/en/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive/} + :YEAR: 2019 + :MONTH: March + :END: + +** {Guix} Further Reduces Bootstrap Seed to 25% + :PROPERTIES: + :TITLE: {Guix} Further Reduces Bootstrap Seed to 25\% + :BTYPE: misc + :NOTE: \url{https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/} + :YEAR: 2020 + :MONTH: June + :AUTHOR: Jan Nieuwenhuizen + :CUSTOM_ID: janneke2020bootstrap + :END: + +** Reproducible and User-Controlled Software Environments in HPC with Guix + :PROPERTIES: + :TITLE: Reproducible and User-Controlled Software Environments in {HPC} with {Guix} + :BTYPE: inproceedings + :AUTHOR: Ludovic Courtès and Ricardo Wurmus + :BOOKTITLE: Euro-Par 2015: Parallel Processing Workshops + :YEAR: 2015 + :PAGES: 579--591 + :MONTH: August + :SERIES: Lecture Notes in Computer Science + :URL: https://hal.inria.fr/hal-01161771/en + :CUSTOM_ID: courtes2015reproducible + :END: + +** Code Staging in GNU Guix + :PROPERTIES: + :TITLE: Code Staging in {GNU Guix} + :BTYPE: inproceedings + :AUTHOR: Ludovic Courtès + :BOOKTITLE: 16th {ACM SIGPLAN} International Conference on Generative Programming: Concepts and Experiences ({GPCE}'17) + :YEAR: 2017 + :MONTH: October + :VOLUME: 52 + :NUMBER: 12 + :PAGES: 41--48 + :NOTE: \url{https://hal.inria.fr/hal-01580582} + :CUSTOM_ID: courtes2017staging + :END: + +** Nix: A Safe and Policy-Free System for Software Deployment + :PROPERTIES: + :TITLE: {Nix}: A Safe and Policy-Free System for Software Deployment + :BTYPE: inproceedings + :AUTHOR: Eelco Dolstra and Merijn de Jonge and Eelco Visser + :BOOKTITLE: Proceedings of the 18th Large Installation System Administration Conference (LISA '04) + :PAGES: 79--92 + :PUBLISHER: USENIX + :YEAR: 2004 + :MONTH: November + :CUSTOM_ID: dolstra2004nix + :END: + +** CODECHECK: an Open Science initiative for the independent execution of computations underlying research articles during peer review to improve reproducibility + :PROPERTIES: + :TITLE: {CODECHECK}: an {Open Science} initiative for the independent execution of computations underlying research articles during peer review to improve reproducibility [version 1; peer review: 1 approved, 1 approved with reservation] + :BTYPE: article + :AUTHOR: Nüst, Daniel and Eglen, Stephen J. + :JOURNAL: F1000Research + :NOTE: \url{https://doi.org/10.12688/f1000research.51738.1} + :VOLUME: 10 + :NUMBER: 253 + :YEAR: 2021 + :CUSTOM_ID: nust2021:codecheck + :END: + +** {[Re]} Storage Tradeoffs in a Collaborative Backup Service for Mobile Devices + :PROPERTIES: + :TITLE: {[Re]} {Storage} Tradeoffs in a Collaborative Backup Service for Mobile Devices + :BTYPE: article + :AUTHOR: Ludovic Courtès + :JOURNAL: ReScience C + :VOLUME: 6 + :NUMBER: 1 + :YEAR: 2020 + :MONTH: June + :DOI: {10.5281/zenodo.3886739} + :NOTE: \url{https://doi.org/10.5281/zenodo.3886739} + :CUSTOM_ID: courtes2020:storage + :END: + +** Guix-HPC Activity Report 2020 + :PROPERTIES: + :TITLE: {Guix-HPC Activity Report 2020} + :BTYPE: techreport + :YEAR: 2020 + :AUTHOR: Braun, Lars-Dominik and Courtès, Ludovic and Prins, Pjotr and Tournier, Simon and Wurmus, Ricardo + :NOTE: \url{https://hpc.guix.info/blog/2021/02/guix-hpc-activity-report-2020/} + :CUSTOM_ID: braun2021:guixhpc + :END: + +** Guix-HPC Activity Report 2019 + :PROPERTIES: + :TITLE: {Guix-HPC} Activity Report 2019 + :BTYPE: techreport + :YEAR: 2020 + :AUTHOR: Courtès, Ludovic and Garlick, Paul and Hinsen, Konrad and Prins, Pjotr and Wurmus, Ricardo + :NOTE: \url{https://hpc.guix.info/blog/2020/02/guix-hpc-activity-report-2019/} + :CUSTOM_ID: courtes2020:guixhpc + :END: + +** Maneage + :PROPERTIES: + :AUTHOR: Mohammad Akhlaghi + :TITLE: {Maneage}: Managing Data Lineage + :BTYPE: misc + :HOWPUBLISHED: {\url{http://maneage.org/}} + :YEAR: 2020 + :NOTE: {Accessed 2020/05/29} + :CUSTOM_ID: akhlaghi20:maneage + :END: + +** Software Heritage + :PROPERTIES: + :AUTHOR: Roberto Di Cosmo + :TITLE: {Software Heritage} and {GNU Guix} join forces to enable long term reproducibility + :BTYPE: misc + :HOWPUBLISHED: {\url{https://www.softwareheritage.org/2019/04/18/software-heritage-and-gnu-guix-join-forces-to-enable-long-term-reproducibility/}} + :YEAR: 2019 + :NOTE: {Accessed 2020/06/05} + :CUSTOM_ID: swh2019:guix + :END: + +** Manuel de référence de GNU Guix + :PROPERTIES: + :AUTHOR: {Projet GNU Guix} + :TITLE: Manuel de référence de {GNU Guix} + :BTYPE: manual + :NOTE: \url{https://guix.gnu.org/manual/fr/html_node/} + :YEAR: 2020 + :NOTE: {Accessed 2020/06/05} + :CUSTOM_ID: guix2020:manual + :END: + +** Challenge to Scientists + :PROPERTIES: + :TITLE: Challenge to Scientists: Does Your Ten-Year-Old Code Still Run? + :BTYPE: article + :AUTHOR: Jeffrey M. Perkel + :JOURNAL: Nature + :NOTE: \url{https://www.nature.com/articles/d41586-020-02462-7} + :YEAR: 2020 + :MONTH: August + :CUSTOM_ID: perkel2020:challenge + :END: + +** Staged Computation + :PROPERTIES: + :TITLE: Staged Computation: The Technique You Didn’t Know You Were Using + :BTYPE: article + :AUTHOR: Konrad Hinsen + :JOURNAL: Computing in Science and Engineering, Institute of Electrical and Electronics Engineers (CiSE) + :VOLUME: 22 + :NUMBER: 4 + :PAGES: 99--103 + :YEAR: 2020 + :MONTH: June + :NOTE: \url{https://dx.doi.org/10.1109/MCSE.2020.2985508} + :CUSTOM_ID: hinsen2020:staged + :END: + + +* Copier cet article + :PROPERTIES: + :COPYING: t + :END: + + Copyright © 2021 Ludovic Courtès + + #+BEGIN_QUOTE + Cet article est mis à disposition suivant les termes de la licence + Creative Commons Attribution – Partage dans les Mêmes Conditions 4.0 + International ([[https://creativecommons.org/licenses/by-sa/4.0/deed.fr][CC BY-SA 4.0]]). + #+END_QUOTE + +* Footnotes +[fn:1] /Reproducible Builds/, https://reproducible-builds.org + +[fn:9] Guix Workflow Language, https://workflows.guix.info + +[fn:8] Guix-Jupyter, https://gitlab.inria.fr/guix-hpc/guix-kernel + +[fn:7] ReScience, /Ten Years Reproducibility Challenge/, +https://rescience.github.io/ten-years/ + +[fn:6] Software Heritage, https://www.softwareheritage.org + +[fn:5] Un /canal/ Guix est une collection de définitions de paquets +stockée dans un dépôt Git. + +[fn:4] Projet Guix-HPC, https://hpc.guix.info + +[fn:3] GNU Guix, https://guix.gnu.org + +[fn:2] [[https://www.acm.org/publications/policies/artifact-review-badging][Artifact Review and Badging – Version 1.0]], Association for +Computer Machinery, August 2020 + +* COMMENT Emacs + +Local Variables: +ispell-local-dictionary: "francais" +eval: (require 'ox-bibtex) +eval: (setq-local org-bibtex-export-arbitrary-fields t) +eval: (setq-local org-bibtex-prefix "") +eval: (setq-local org-latex-default-packages-alist '()) +eval: (setq-local org-latex-pdf-process '("rubber --pdf %f")) +End: