doc: Add article for "1024" (French).

* doc/sif-2021/article-1024.org: New file.
This commit is contained in:
Ludovic Courtès 2021-07-26 11:51:38 +02:00
parent d3eaabdc6a
commit 223759e173
No known key found for this signature in database
GPG Key ID: 090B11993D9AEBB5
2 changed files with 598 additions and 0 deletions

4
.gitignore vendored
View File

@ -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

View File

@ -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 Whats 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. Cest 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 lensemble logiciel qui a servi à une
production scientifique — est un aspect quon 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 quon y trouve. Les
« distributions » GNU/Linux telles que Debian et Ubuntu se basent sur
des outils de /gestion de paquets/ comme =apt= qui permettent
dinstaller, 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 dadministration système, et ils ne permettent de déployer
quun 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é dautres outils de
gestions de paquets destinés à être utilisés /par dessus/ celui du
système, avec lavantage dêtre utilisable sans les droits
dadministration, 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.).
Lexpérience a rapidement montré que cet empilement doutils de
déploiement devient vite préjudiciable à la reproductibilité, car
chaque outil ignore celui « du dessous », bien quil dépende de ce que
celui-ci a installé. Autrement dit, chaque outil ne voit quune
partie du graphe de dépendance de lensemble. À cela sajoute le fait
que, même pris individuellement, ces outils ne permettent pas ou
difficilement de reproduire un environnement logiciel à lidentique.
Cest notamment pour cette raison quune deuxième approche du
déploiement logiciel sest popularisée : celle qui consiste à /geler
lenvironnement logiciel/, plutôt que dessayer de le décrire.
Lidée peut se résumer ainsi : puisquil est difficile voire
impossible de redéployer un environnement logiciel à lidentique en
utilisant ces outils de gestion de paquets, créons lenvironnement 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 nimporte quelle machine et à nimporte quel
moment, de relancer les logiciels scientifiques dinté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.
Lapproche est séduisante : puisquon a tous les octets des logiciels,
la reproductibilité est totale ; on a la garantie de pouvoir relancer
les logiciels, et donc, de reproduire lexpérience scientifique. Mais
linconvénient est de taille : puisque lon a /que/ les octets des
logiciels, comment savoir si ces octets correspondent vraiment au code
source que lon croit exécuter ? Comment expérimenter avec cet
environnement logiciel, dans le cadre dune démarche scientifique,
pour établir limpact dun choix de version, dune option de
compilation ou du code dune fonction ? Lapproche est pratique,
cest 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 lingénierie logicielle et des langages, dabord 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
den tirer partie. En termes pratiques, Guix hérite de Nix les
fondations permettant la reproductibilité denvironnements 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 dun 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 sassure
que cest effectivement le cas en vérifiant que les compilations sont
reproductibles /au bit près/, ainsi que le font dautres projets
participant à leffort /Reproducible Builds/[fn:1]. Cette approche
fonctionnelle capture ainsi lessence 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 puisquelle est récursive, quy
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 la 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 lauthenticité
des binaires qui en découlent.
Guix sattaque à 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]].
Cest là un sujet dingénierie et de recherche à part entière.
* Déclarer et reproduire un environnement logiciel
Guix peut sutiliser 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 linterprè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
seffectue sans les droits dadministration 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. Lexemple
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 sagit de code Scheme. Une utilisation avancée serait par exemple
dinclure 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 dun paquet pour le personnaliser, ce qui est une pratique
courante en HPC [[cite:courtes2015reproducible]].
Supposons que lon 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 : lidentifiant
de révision de Guix. Puisque Guix et toutes les définitions de
paquets quil fournit sont stockées dans un dépôt de gestion de
version Git, lidentifiant de révision désigne de manière non ambiguë
/lensemble 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 jusquau compilateur du compilateur. Cest 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 lenvironnement 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 dabord obtenir et déployer la révision de Guix
spécifiée dans ~canaux.scm~, à la manière dune « machine à voyager
dans le temps ». Cest 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 dautres outils ?
Dabord, 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 à lapproche 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. Cest 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. Lexpé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 darchiver tout le code source public disponible[fn:6].
Depuis quelques années, Guix est intégré à SWH de deux manières :
dune part Guix va automatiquement chercher le code source sur SWH
lorsquil est devenu indisponible à ladresse initiale
[[cite:courtes2019connecting]], et dautre part Guix alimente la liste des
codes sources archivés par SWH. Le lien avec larchivage de code en
amont est assuré.
* Vers des articles reproductibles
On a vu le lien en amont avec larchivage de code source, mais le lien
en aval avec la production scientifique est également crucial. Cest
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 lenvironnement logiciel, un saut
qualitatif consiste à fournir les fichiers ~canaux.scm~ et
~manifeste.scm~ qui constituent en quelque sorte une description
exécutable de lenvironnement 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 darticles vieux de dix ans ou plus[fn:7].
Cest dans ce cadre que nous avons montré comment Guix peut être
utilisé pour décrire lensemble dune chaîne de traitement
scientifique, incluant le code source du logiciel dont traite
larticle, les expériences effectuées avec ce logiciel, les courbes
produites dans ce cadre, pour enfin arriver au PDF de larticle
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
dautres contextes. Guix-Jupyter[fn:8], par exemple, permet dajouter
à des bloc-notes Jupyter des annotations décrivant lenvironnement
logiciel dans lequel doit sexécuter le bloc-notes. Lenvironnement
décrit est automatiquement déployé /via/ Guix, ce qui garantit que les
cellules du bloc-notes sexé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 sexé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 quelle
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 dun 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}, 20212024
:BTYPE: misc
:AUTHOR: {Ministère de lenseignement supérieur, de la recherche et de linnovation}
: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 Didnt 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: