Un paquet Nix qui démarre dans un onglet

Ce qui se passe

trynix.dev propose de choisir un paquet, n'importe lequel de l'histoire de nixpkgs, et d'obtenir en quelques secondes un shell où ce paquet est dans le PATH. Rien n'est installé sur la machine hôte. L'index couvre 310 083 versions de paquets, jusqu'à un Python 3.6.2 de 2017.

L'auteur, Farid Zakaria, présente le projet comme l'aboutissement de travaux antérieurs : nixpkgs-multiverse, qui indexe toutes les versions jamais livrées par nixpkgs, et son mode rapide, qui saute l'évaluation pour donner directement le chemin de store qu'Hydra a construit.

Comment les pièces s'emboîtent

Le point à voir dans ce schéma est ce qui n'y figure pas : il n'y a aucun serveur applicatif. La page est un fichier statique, tout le reste sont des caches publics.

La condition unique côté cache est de servir l'en-tête access-control-allow-origin: *. cache.nixos.org le fait — l'auteur note au passage qu'il l'avait lui-même demandé cinq ans plus tôt, pour un tout autre usage. Cachix aussi. Et GitHub Pages, gratuitement, puisque c'est un simple serveur de fichiers statiques. Conséquence directe : vous pouvez publier un chemin de store que vous avez construit vous-même et le faire démarrer chez quelqu'un d'autre, même s'il n'existe sur aucun cache public.

Comme il s'agit de Nix, deux versions du même paquet cohabitent sans conflit dans la même machine : chaque binaire nomme ses dépendances par chemin absolu via son RUNPATH, jusqu'au chargeur et à la libc. On peut aussi ajouter des chemins au store d'une VM déjà démarrée, sans redémarrage.

Ce qu'il en coûte

Démarrer un noyau sous émulation est lent, et le projet ne le nie pas : il le contourne. La VM ne démarre jamais à froid. Une machine est amorcée une fois à l'avance, sur un QEMU natif, et mise en pause juste avant de monter le store ; c'est cet instantané, préchargé en arrière-plan avec le moteur, qui est repris.

Les limites restantes sont franches. L'exécution reste émulée : la première exécution d'un binaire le traduit de x86-64 vers WebAssembly, ce qui coûte du temps avant d'être mis en cache. Toute la clôture doit tenir dans la mémoire de l'onglet, plafonnée autour de 1,5 Gio, WebAssembly ne dépassant de toute façon pas 4 Gio d'espace d'adressage 32 bits. Et c'est une console série : aucun programme graphique.

Ce que ça peut changer

L'auteur ouvre plusieurs pistes, dont deux tiennent debout dès aujourd'hui pour un projet qui pousse déjà vers un cache : une pull request relue en cliquant sur les artefacts que la CI a réellement produits, sans cloner ni reconstruire ; et un rapport de bug qui transporte son environnement plutôt que de décrire « ça marche chez moi ». S'y ajoutent la documentation exécutable — un tutoriel qui épingle la version exacte de l'outil qu'il enseigne — et l'archéologie logicielle.

À retenir

Le code est sur github.com/fzakaria/trynix. La démonstration impressionne, mais l'enseignement est ailleurs : un cache Nix correctement configuré en CORS faisait déjà du navigateur un client Nix légitime. Il ne manquait qu'un endroit où exécuter les binaires.

Source : fzakaria