[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
01/03: doc: Add article for "1024" (French).
|
From: |
Ludovic Court�s |
|
Subject: |
01/03: doc: Add article for "1024" (French). |
|
Date: |
Fri, 26 Nov 2021 04:39:44 -0500 (EST) |
civodul pushed a commit to branch master
in repository maintenance.
commit 223759e1732bb8be5a676db4d868a21f61985b3d
Author: Ludovic Courtès <ludo@gnu.org>
AuthorDate: Mon Jul 26 11:51:38 2021 +0200
doc: Add article for "1024" (French).
* doc/sif-2021/article-1024.org: New file.
---
.gitignore | 4 +
doc/sif-2021/article-1024.org | 594 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 598 insertions(+)
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: