mirror of
git://git.savannah.gnu.org/guix/maintenance.git
synced 2023-12-14 03:33:04 +01:00
doc: Add article for "1024" (French).
* doc/sif-2021/article-1024.org: New file.
This commit is contained in:
parent
d3eaabdc6a
commit
223759e173
2 changed files with 598 additions and 0 deletions
4
.gitignore
vendored
4
.gitignore
vendored
|
@ -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
|
||||
|
|
594
doc/sif-2021/article-1024.org
Normal file
594
doc/sif-2021/article-1024.org
Normal 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 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:
|
Loading…
Reference in a new issue