Je travaille depuis quelque temps sur Elpe, un projet qui vise à obtenir les bonnes propriétés de Nix/NixOS (les mises à jour atomiques, la reproductibilité), mais avec des paquets Ubuntu.
Le code : https://nest.pijul.com/pmeunier/elpe
L'idée est de définir des recettes de compilation en OCaml et de les envoyer à un backend Rust, qui se charge de les exécuter dans un conteneur sans réseau, en exposant uniquement le contexte nécessaire à la bonne exécution de la compilation. Les produits du build sont indexés par le contenu de la recette du build, et indexés une deuxième fois par le résultat : c'est ce deuxième hash qui est utilisé dans les dépendants du paquet, ce qui permet de construire un arbre de Merkle du système complet (et non seulement de ses sources), qui rend toute modification ultérieure facilement détectable.
De plus, le système de base provient des dépôts de paquet Debian ou Ubuntu. Cependant, tous les chemins sont hard-codés (comme dans Nix), ce qui permet de garantir la reproductibilité, au détriment toutefois du coût de mise à jour en termes d'espace et opérations disque.
Si le choix de Rust devient relativement consensuel par les temps qui courent, OCaml est plus surprenant. Après divers essais avec plusieurs langages, je l'ai choisi parce que c'est le seul langage avec à la fois :
- Une bonne approximation du système de types dont j'avais besoin: typage nominal et aussi structurel, entre autres.
- Un système de types relativement simple (pas de typeclasses ni de monades comme en Haskell, de borrow checkers comme en Rust ni de types dépendants comme en TypeScript).
- Du late binding, nécessaire pour exprimer des "overrides" et des "hooks", courants quand on veut compiler des choses (autoconf et make ont plein d'options de ce type, par exemple).
- Un compilateur ultra-rapide.
- Un bytecode, pour (dans le futur) contrôler aussi l'isolation du code de build de façon très légère.
La simplicité et l'expressivité d'OCaml sont bien adaptés à ce projet: les fonctions simples à concevoir y sont relativement claires à énoncer.
Pourquoi pas NixOS, me direz-vous ? En tant qu'utilisateur et contributeur depuis environ 10 ans, un certain nombre de problèmes plus ou moins récents m'ont motivé à explorer une alternative:
En termes de gouvernance, la communauté a traversé dans la dernière année plusieurs crises de différentes tailles (Anduril, Devenv…). On pourrait y voir un signe de maturation ou au moins de croissance du projet, mais plusieurs éléments me permettent d'en douter, dont les réactions répétées de la fondation Nix, qui semble avoir beaucoup de mal à comprendre les messages pourtant clairs des contributeurs.
Je vois aussi les choix de design imposés par les fondateurs du projet depuis quelques années comme un bien mauvais signe: les flakes (en 2020) étaient une première incarnation de cette tendance, et plus récemment la "distribution propriétaire" de Nix est clairement une mauvaise idée, alors que la qualité de code de Nix n'est pas au niveau où on l'attendrait et que le gros du projet repose depuis plusieurs années sur le travail pharaonique des contributeurs de Nixpkgs.
On pourrait parler longtemps de la sécurité de Nix, qui me fait de plus en plus peur y compris pour mon usage personnel. Les process de gestion des rapports ne me conviennent pas, de même que l'opacité de certains choix techniques (les flags de compilation désactivés sur certaines plateformes, entre autres), souvent bien cachés dans les entrailles de Nixpkgs.
Enfin, le langage trop complexe à utiliser (principalement par manque de typage statique et de messages d'erreurs pertinents) rend Nix difficile à utiliser au sein d'une organisation d'une taille importante, et encourage les comportements peu inclusifs (éviter d'écrire de la doc, inventer des casse-têtes pour faire des choses simples…). Je suis bien sûr conscient que des entreprises (comme Anduril) et des ONGs (comme Médecins Sans Frontières) l'utilisent, mais je ne pense pas que ce soit généralisable aux situations où j'aimerais voir ce genre de projet utilisé.
# Pourquoi pas Guix
Posté par madhatter (site web personnel) . Évalué à 5 (+4/-0).
Salut,
c'est très intéressant, merci !
Je ne connais pas assez NixOS et pas encore assez Guix, mais de la même manière que tu détailles « pourquoi pas NixOS » et les différences de conception qu'il entretient avec ton projet, pourrais-tu détailler les différences qu'il y a avec Guix et pourquoi tu as choisi de créer quelque chose de nouveau ?
Pour ma part j'ai choisi de m'intéresser à Guix plutôt qu'à Nix notamment à cause au langage utilisé. Le Scheme n'est pas forcément évident à appréhender (loin de là - en tout cas pour moi) mais au moins je pourrai m'en servir dans d'autres contextes contrairement au langage propre à Nix.
There is no spoon...
[^] # Re: Pourquoi pas Guix
Posté par pmeunier . Évalué à 6 (+5/-0).
Je suis fan de Guix aussi, mais je pense qu'il partage plusieurs problèmes avec Nix. Entre autres:
Le problème de gouvernance est le même, même si Ludovic Courtès semble avoir de très bonnes intentions, c'est aussi le cas de Lix, et c'était aussi le cas des gens de Nix il y a encore quelques années. Il ne suffit pas à mon avis de dire "oui mais nous on est les gentils" pour régler le problème.
L'intérêt d'avoir une solution basée sur une source de paquets externe est de pouvoir sous-traiter et financiariser le problème de la confiance dans les paquets.
Lisp ne résout pas tellement le problème du langage Nix. La principale difficulté dans le passage à l'échelle dans une organisation n'est pas dans les détails syntaxiques du langage, mais dans la capacité d'écrire des programmes qui renvoient des messages d'erreurs utiles, malgré le fait que la plupart des ingénieurs sont peu amenés à pratiquer le langage en question (parce qu'on n'installe pas des machines tous les quatre matins, en tout cas Nix prétend qu'on n'aura pas/peu à le faire).
Et sinon, l'objectif d'Elpe est assez différent de Nix et Guix, et surtout de Nixpkgs ou son équivalent Guix: il ne s'agit pas ici de refaire une distribution Linux de zéro, mais plutôt d'apporter les bonnes propriétés de Nix et de Guix à une distribution existante (Ubuntu ou Debian).
[^] # Re: Pourquoi pas Guix
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
Même si ton projet est sans doute meilleur, tu va avoir du mal à le faire émerger. Ce ne sont pas toujours les meilleurs qui gagnent… Même si les pires finissent généralement quand même par être évincés. Tu a comparativement peu d'avantages par rapport à NixOS, je comprends surtout l'argument du langage… mais l'argument de gouvernance peut se trouver dans chaque projet malheureusement. C'est parfois un passage.
La tache est grande pour toi. Bon courage, j'espère que tu trouvera une comunauté pour arriver à grossir.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Pourquoi pas Guix
Posté par zimoun . Évalué à 5 (+4/-0).
Euh, pourriez-vous en dire plus ?
Pour fixer les idées, j'étais jusqu'à ce samedi passé un des deux du Bureau de Guix Foundation. Et je suis un des co-auteurs de la procédure Guix Consensus Document pour prendre les décisions collectives.
Alors, certes il y a des tas d'amélioration à apporter dans le projet Guix concernant la gouvernance mais je serais curieux des problèmes que vous voyiez.
Oui ! Je partage cet avis. :-)
Un des points faibles de tout avoir en Scheme est l'absence d'un système typage (décent). Comme OCaml peut offrir.
Avec Elp, chouette ! Intéressant… à regarder. :-)
En fait, je ne vois pas très bien quelle serait la différence avec
guix shellet les fichiersmanifest.scm(à part le typage OCaml vs Scheme :-)). J'utilise Guix comme gestionnaire de paquets au dessus du système Debian (ou Ubuntu). Donc je faisapt installpuisguix shellpour compléter etc. Ou à l'inverse pour totalement isolé de Debian. :_)La question est : Comment Elp apporte les bonnes pratiques de Nix/Guix à une distribution existante comme Debian ou Ubuntu ? Ou pour le dire autrement, est-ce que Elp utilise la machinerie du répertoire
debian/avec le fichierdebian/controletc. dans sa construction ?Comme Elp définit une recette de construction en OCaml et que cette recette peut utiliser un binaire produit par Ubuntu, il semble y avoir une perte de tracabilité, non? Car comment est-ce que je serais en mesure de reproduire ce même binaire Ubuntu sur une autre machine et/ou à un autre moment (dans 6mois, 1an, 2ans, plus?) ?
Pour finir, je ne sais pas où en est le projet Tvix qui se veut une réimplémentation d'une partie de Nix en Rust. Mais il semble y avoir une intersection, peut-être ?
# Flakes
Posté par saltimbanque (site web personnel) . Évalué à 2 (+0/-0).
J'ai rejoins le bateau un peu récemment pour me prononcer, mais que critiques tu dans les Flake? Je comprends qu'il permettent basiquement de nixifier nimporte quelle source, tout en spécifiant au besoin la release voire le commit, ce qui est assez top sur le papier…
[^] # Re: Flakes
Posté par pmeunier . Évalué à 3 (+2/-0).
Je reproche plusieurs choses aux flakes:
La syntaxe précédente était bien plus simple et moins verbeuse, et il aurait été facile de changer juste la sémantique des "chemins" (la syntaxe
<nixpkgs>) pour gérer tous les cas gérés par les flakes. Par exemple, aujouter un .lock à côté des default.nix.Les flakes ont été imposés sans aucune discussion ni RFC de la communauté.
La vision de "bibliothèques Nix" est à mon avis un gros problème de sécurité, en fragmentant l'écosystème et en le rendant les audits encore plus difficiles.
Le design lui-même a plein de trous: par exemple, le nixpkgs implicite ou encore
nix runqui peut permettre de surcharger les noms entre "apps" et "packages". Le manque de stabilisation encourage l'écriture d'une grande quantité de code Nix reposant sur des bases fragiles.Enfin, à l'échelle d'une organisation, l'articulation entre les différents projets n'est pas particulièrement simplifiée par les flakes, contrairement à ce qu'on entend parfois.
[^] # Re: Flakes
Posté par pmeunier . Évalué à 3 (+2/-0).
(et aussi, "nixifier n'importe quelle source" est ce que fait Nixpkgs pour tous ses paquets, sans aucun flake)
[^] # Re: Flakes
Posté par saltimbanque (site web personnel) . Évalué à 3 (+1/-0).
Merci ce sont des points intéressants. Peut être qu'à ce stade le sujet "communauté" me parle le plus car un point particulier en arrivant dans le
mondechaos de NixOS, ce sont les 2 wikis qui se battent et la difficulté de trouver des docs qui référencent une même manière de faire - il y a systématiquement 50 mille approches…[^] # Re: Flakes
Posté par pmeunier . Évalué à 3 (+2/-0).
J'avoue que je suis un peu gonflé par l'attirance des egos surdimensionnés pour Nix/NixOS. Je pense sincèrement que ça vient de l'intersection "compilation un peu hardcore" et "langage de merde": les deux séparés sont déjà rarement très bons.
Un symptôme c'est qu'il n'y a aucune collaboration entre des projets qui font pourtant la même chose. Par exemple, il y a quelques années j'ai écrit
buildRustCratepour remplacer Cargo par Nix. Depuis, un grand paquet d'autres solutions pour compiler du Rust en Nix sont sorties, sans aucune référence ni discussion sur les compromis. Dommage…[^] # Re: Flakes
Posté par saltimbanque (site web personnel) . Évalué à 2 (+0/-0).
Ah oui quand j'ai voulu compiler mon premier projet Rust j'ai pleuré. Il doit y avoir cinquante solutions alternatives ça donne juste envie de compiler Rust sur un autre ordi! J'ai réussi entre temps mais je testerai buildRustCrate!
# index d'entrée, index de sortie
Posté par fabien . Évalué à 3 (+2/-0).
Hello,
Vraiment intéressé par cette partie (je suis en ce moment dans ce même genre de problème):
J'ai l'impression que classiquement on hash les sources (sources + recette) pour faire une signature d'entrée et on indexe l'artefact produit en utilisant ce hash d'entrée. En passant cet index à l'étape suivante du build on peut réutiliser l'artefact. De proche en proche on identifie les signatures d'entrée de chaque build, et on est capable de trouver les artefacts correspondant à chacune de ces signatures.
Je n'arrive pas à imaginer comment tu utilises le deuxième hash (celui de l'artefact) comme index de dépendance : il faut maintenir une table de correspondance entre signature d'entrée et hash de l'artefact ? Si j'analyse mon arbre de build, je peux connaitre a priori l'ensemble des signatures d'entrée (tout dérive du hash des sources), mais j'ai besoin d'exécuter les build pour avoir le hash de l'artefact, et c'est là ou je ne comprends pas comment l'utiliser comme index de dépendance.
(en fait ce cas m'intéresse parce que pour des recettes légèrement différente on peut produire exactement le même artefact et arriver à identifier ce cas permet de ne pas refaire des builds inutilement).
Sur ce sujet je suis preneur de tout pointeur de documentation, article, présentation … :)
[^] # Re: index d'entrée, index de sortie
Posté par pmeunier . Évalué à 2 (+1/-0).
Bonjour,
La botte secrète est de produire un fichier des hashs des autres fichiers dans chaque paquet qu'on produit, puis de hasher ce nouveau fichier. Ensuite, la table de correspondance peut être élégamment encodée dans le système de fichiers (qui est lui-même une table de correspondance) avec des liens symboliques: le lien s'appelle "hash de la sortie", il pointe vers le résultat, qui s'appelle "hash de l'entrée".
Bien entendu, ça ne marche pas pour des références cycliques, et il y en a quelques unes dans les index de paquets Debian.
[^] # Re: index d'entrée, index de sortie
Posté par fabien . Évalué à 1 (+0/-0).
Merci pour cette réponse.
J'avais en tête une sorte de manifeste du build (liste des fichiers avec leurs hash), mais pas les liens dans le système de fichier. A creuser. Pas de dépendance cyclique dans mon cas, c'est un pur DAG, c'est plus facile.
[^] # Re: index d'entrée, index de sortie
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Ça ne vaudrait pas le coup d’utiliser plutôt une archive type cpio ? Pour capturer de manière plus complète l’input ? Pour inclure les droits et éventuellement les types ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: index d'entrée, index de sortie
Posté par pmeunier . Évalué à 3 (+2/-0).
Dans le cas des paquets Debian/Ubuntu, c'est exactement ce qu'on ne veut pas ! On sait exactement ce qui change et ce qui ne change pas, et le jeu est de l'utiliser pour mettre un maximum en cache.
Par contre, je te rejoins complètement sur les autres paquets. La difficulté que j'anticipe est d'archiver sans dupliquer l'entrée sur le disque, et en limitant les opérations IO au minimum. L'expérience Nix montre que garder l'IO en tête n'est pas inutile.
# Commentaire supprimé
Posté par CarmenMarin . Évalué à 0 (+0/-0). Dernière modification le 21 juin 2025 à 10:07.
Ce commentaire a été supprimé par l’équipe de modération.
# Pourquoi OCaml ?
Posté par Firwen (site web personnel) . Évalué à 4 (+2/-0).
Merci pour cet article et projet ambitieux et très intéressant.
J'ai moi même utiliser Nix à l’échelle pour de gros déploiement de stack en entreprise.
Je partage votre avis sur Nix qui a besoin d'un remplaçant.
Nix a trop de problème pour être sauvé:
Le langage a été baclé et a une montagne de problème (hello no typing). Il est maintenant dans 100k packages et inchangeable. Le système de Hook et le compiler wrapper en bash qui cache la misère en est un autre.
La qualité du code du software lui même est franchement douteuse et le projet est contrôlé par une petite élite qui refuse la plupart des changements (ceci depuis le début du projet).
Les CLIs sont une purge à utiliser, les options n'ont aucun sens et se contredisent entre les trois command line tools principaux. Le nouveau CLI unifié "nix" a les mème problème en plus d'etre marqué en 'experimental' depuis des années.
Les flakes sont un hack et une usine à Gaz illisible. En plus de poser des problèmes de tracabilités, ils posent de sérieux problème de performance.
J'ai à vrai dire moi même longtemps hésiter à forker le projet mais au vu du travail nécessaire et de mon temps libre, j'ai vite oublié l'idée.
L'idée d'une re-implémentation est bonne.
Et pourquoi pas en Rust pour un tool système.
Par contre: pourquoi OCaml pour le scripting ?
La critique récurrente que j'entends sur Guix (qui a un bien meilleur design) est justement l'utilisation de Guile.
Guix a choisi Guile car GNU, ce qui peut se comprendre au vu des ambitions du projets.
Mais essayer de convaincre une communauté de faire du Guile se traduit souvent pas un "No thx. Ce truc est illisible et encore pire que Nix. J'ai (aucune (envie (de (ca))))".
Et c'est une des raisons principales derrière le fait que Guix n'ait qu'une faible nombre de paquets comparé à Nixpkgs.
Il y a fort à parier que la même chose se produise pour OCaml, même si c'est objectivement plus facile à maintenir que du Scheme.
Ca reste un langage fonctionnel de niche qui n'a jamais été désigné pour du scripting.
[^] # Re: Pourquoi OCaml ?
Posté par zimoun . Évalué à 3 (+2/-0).
Hum, et peut-être aussi que Guix est moitié plus jeune (Nix ~22 ans vs Guix ~12 ans). :-)
Je me permets de préciser un point : à part le démon, pour Guix tout est en Guile, de la définition de paquets à la configuration en passant par toutes les parties internes de Guix. Certes, quand on n'aime pas les parenthèses, c'est fâcheux. ;-) Cependant, le point est clé est une continuité entre tous les composants : ma distribution devient une bibliothèque Scheme que je peux manipuler.
Quelque part, Guix pourrait être vu comme une mise en application de The Emacs Thesis décrite par le manuel Guile.
À nouveau, le langage Guile/Scheme a des tas de faiblesses, oulà oui ! :-) Cependant, les propriétés de Lisp (macro, reader, S-exp, etc.) permettent d'implémenter des DSLs pour étendre le langage lui-même. Il est toujours possible de faire ce genre de trucs dans d'autres langages mais il faut dire que le Scheme est vraiment super adapté.
Tout ceci dit, Guile a des tas de faiblesses : 1. pas vraiment de debugger décent ÀMHA et 2. pas assez de typage à la compilation, dur dur la refactorisation, la vérification de la composition, etc.
Ce serait chouette s'il y avait un truc à la sauce Typed Racket avec du gradual typing.
Des exemples comme MirageOS montrent qu'OCaml serait peut-être un bon choix. :-) Mais bon, si on se plaint du nombre de paquets dans Guix après plus de 10 ans avec une communauté certes petite mais active, je serais curieux de voir une "réimplémentation" de toutes ces idées from scratch quelque soit le langage…
# Reproductibilité et résilience
Posté par Sytoka Modon (site web personnel) . Évalué à 4 (+2/-0).
Pour avoir une forme de reproductibilité assez simple à mettre en œuvre là ou il y en a besoin, il y a les container, par exemple AppTainer https://apptainer.org/.
Il n'y a pas moyen de garantir la reproductibilité dans la plupart des cas ! Il suffit de changer de CPU (ou de GPU) et plus rien n'est garanti !
Ce qui est important, c'est soit le résultat, soit une faible dérive avec le résultat précédent. Dans de nombreux cas, une faible dérive suffit. En plus, cela a un avantage de plus travailler sur la résilience du code aux modifications que sur le dernier bit. En science, un résultat doit être reproductible par d'autres équipes pour valider un résultat, mais cela ne signifie nullement relancer le même code dans les mêmes conditions. 1 + 1 = 3 est faux, mais reproductible par un bogue de codage. Le valider n'est pas de la science…
La stabilité des API, la correction des bogues est souvent un sujet plus important que la reproductibilité bit à bit…
Cela dis, le projet « Reproductible Build » qui permet de garantir que le code compilé est bien issu de ces sources là est carrément important. C'est le même type de garantie qu'un hash certifiant qu'un téléchargement s'est passé sans modification lors du transfert. C'est une signature numérique.
Bref, la reproductibilité, c'est bien à bon escient. Parfois, cela se transforme un peu trop en religion…
[^] # Re: Reproductibilité et résilience
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Si je te donne deux binaires, comment tu qualifies une différence de « faible dérive » ?
Adhérer à l'April, ça vous tente ?
[^] # Re: Reproductibilité et résilience
Posté par Sytoka Modon (site web personnel) . Évalué à 3 (+1/-0).
Si c'est un code élément finis, tu as un ensemble de cas test. Une simple dérive, c'est par exemple les mêmes résultats en terme de contrainte et de déformation à 10-7 par exemple.
Ce que je veux dire, c'est qu'il y a de nombreux cas où une petite dérive du calcul n'est pas du tout gênante. Bien sur, si ton code n'a aucun cas test, alors c'est compliqué de qualifier le code…
[^] # Re: Reproductibilité et résilience
Posté par zimoun . Évalué à 3 (+2/-0).
Pour aller au plus court dans mes explications. :-)
Dans votre exemple, il faudrait définir 2 types de reproductibilité : la reproductibilité dans la production du binaire et la reproducibilité à l'exécution (calcul de déformation).
Alors autant oui c'est un vaste sujet que d'avoir une reproductibilité bit-à-bit à l'exécution, c'est à dire avoir l'exact même résultat de déformation au bit près.
Autant il est atteignable d'avoir le même binaire bit-à-bit, celui qui va ensuite calculer.
Et chercher à avoir ce binaire bit-à-bit n'est pas le sujet d'un résultat de déformation bit-à-bit, mais essayer d'avoir ce binaire bit-à-bit, c'est tout simplement essayer de contrôler au plus les sources de variabilité—et n'est-ce pas l'enjeu de la méthode scientifique ? ;-)
En contexte scientifique, toute la question de la reproductibilité n'est pas vraiment d'avoir des calculs de déformation au bit près (enfin ca pourrait l'être quoique l'intérêt me semblerait limité à des cas très précis :-)), mais plutot la question est de réduire l'espace de recherche quand justement l'écart entre deux calculs n'est plus considéré comme une "petite dérive".
Je vous rejoins sur le point : il ne faut pas faire de la reproductibilité une sorte de dogme rigide mais un outil dans la trousse de l'expert·e.
[^] # Re: Reproductibilité et résilience
Posté par Sytoka Modon (site web personnel) . Évalué à 2 (+0/-0).
Je suis entièrement d'accord et d'ailleurs, le projet Debian est à fond dans le Reproductible Build. C'est ce que j'ai dis. Reproductible Build est à mettre au même niveau que la signature de code, on est SUR que le code qui tourne est compilé à partir de ces codes sources là.
La reproductibilité bit à bit à l’exécution est intéressante dans certains cas, mais pas nécessaire dans tous les cas. Et c'est souvent dans les cas de code de calcul, qui sont complexes et font intervenir des quantités d'opérations, que s'accrocher sur cette notion de bit à bit pour les résultats a peu de sens. Mieux vaut avoir un code robuste avec des critères objectifs. Ainsi les algorithmes peuvent être refait dans d'autres langages par d'autres équipes sur d'autres CPU, l'important est le résultat scientifique, à epsilon près ;-)
[^] # Re: Reproductibilité et résilience
Posté par zimoun . Évalué à 2 (+1/-0).
Que les binaires soient bit-à-bit identiques ou non, cela ne change rien. :-)
Deux binaires bit-à-bit peuvent produire deux résultats différents. L'exemple tout bête est afficher l'heure. ;-) Plus sérieusement, dès qu'il va y avoir de la concurrence à l'intérieur du programme, avec du calcul sur floatant, il y a de grande chance pour les résultats soient différents.
Pour le dire autrement, deux binaires bit-à-bit identiques peuvent calculer deux résultats différents. Et deux binaires différents peuvent calculer deux résultats bit-à-bit identiques.
L'enjeu de la reproductibilité ne se joue pas là, ÀMHA.
[^] # Re: Reproductibilité et résilience
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0).
Essayons se reformuler.
La notion de reproductibilité bit à bit des binaires produits consiste à identifier et figer les critères variables (nom de la machine, spécificités du matériel, date/heure, identifiants type IP/MAC/UUID, etc.) du build, pour montrer que l'on peut réobtenir la même chose dans cet environnement contrôlé.
La reproductibilité des sorties de l'exécution dans un environnement non contrôlé de façon exacte semble très improbable (pour les mêmes critères évoqués précédemment, plus d'autres comme l'ordre d'exécution, le parallélisme, les arrondis, les entrées externes, etc.). Déjà reproduire dans un environnement contrôlé paraît difficile, parce que l'environnement de run est plus variable que celui de build. Il faudrait vraiment en avoir le besoin pour vouloir s'y lancer (peut-être dans les domaines classiques nucléaire / aérien / spatial ?) parce que ça va être couteux en temps et ressources.
On notera que l'informatique oscille entre le simple compréhensible déterministe prédictible et l'intriqué incompréhensible non déterministe non prédictible, suivant les besoins et l'état de l'art. Et suivant ce à quoi on s'intéresse (par exemple les binaires pour l'équipe sécu qui se fiche un peu des résultats d'exécution, tandis que les scientifiques se fichent des binaires mais voudraient en gros les mêmes résultats).
[^] # Re: Reproductibilité et résilience
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Tu as lu Reflections on Trusting Trust ou d'autres papiers du domaine ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.