lewo a écrit 8 commentaires

d'après les logs, lors des installations je vois que beaucoup de téléchargements sont fait directement depuis github : ce n'est pas très rassurant pour la souveraineté (coucou la DINUM).

NixOS repose effectivement beaucoup (trop) sur GitHub. Après, nous pourrions tout de même relativiser…

Pour vulgariser, lorsque tu installes ou modifies NixOS, nixos-rebuild réalise principalement 3 étapes:

1. Lire ta configuration afin de générer une recette de build. On parle d'évaluation, et cela peut être fait manuellement via la commande nix-instantiate qui génère des "derivations".
2. Éxecuter la recette issue de l'évaluation pour construire le script de déploiement. On parle de build/realization et cela peut être fait manuellement via la commande nix-store --realize derivation.drv. Dans le cas de NixOS, lorsque tu buildes ta configuration, Nix construit un script (nommé switch-to-configuration) qui a pour rôle de modifier ton systeme à chaud (écrire dans /etc, installer le bootloader, …).
3. Executer le script switch-to-configuration pour installer ou mettre à jour ton système.

Seules les étapes 1. et 2. ont besoin d'Internet.

Concernant l'étape 1., Nix a besoin du dépot nixpkgs qui contient les recettes de build des paquets NixOS. Ce dépot est hebergé sur GitHub et par défault, nixos-rebuild va donc récupérer les recettes de GitHub. Cependant, si tu clones ce dépot ailleurs, tu pourrais te passer de GitHub.

Concernant l'étape 2., nixos-rebuild va d'abord chercher des binaires préconstruits (la magie de la transparence source/binary) sur cache.nixos.org. Cela t'évite de builder localement tous les paquets dont tu as besoin. Si le paquet dont tu as besoin n'existe pas dans le cache NixOS, alors il va le construire localement. Si les sources de ce paquet sont sur GitHub, alors Nix va récupérer ces sources depuis GitHub [1].
Ce cache n'est pas hebergé sur GitHub, mais sur le S3 d'AWS :/
Il serait possible de se passer de ce S3 en rebuildant tous les paquets nécessaires localement ou en ayant une CI qui construit ces paquets et les expose comme cache.nixos.org.

En conclusion, par défaut, NixOS est effectivement fortement dépendant de services extra européens mais les outils existent pour s'en passer. Et à l'échelle d'un état, ce n'est pas insurmontable (des entreprises utilisant Nix le font déjà).

[1] une idée pourrait être de fallback sur Softwre Heritage si GitHub n'est pas la, mais il n'y a rien de très concret coté Nix pour l'instant (Guix est plus avancé sur ce sujet).

Cela me semble bizarre de passer d'un système modulaire (chaque paquet a sa configuration) à une base de registre configuration monolithique.

La configuration n'est pas monolithique: il est possible de la splitter dans plusieurs fichiers, mais également de créer des modules qu'il est possible de composer. Ces modules peuvent ne concerner qu'un service, mais également un ensemble cohérent de services (comme une stack mail par exemple).

Et si la configuration n'a pas été "nixifiée", comment on fait?

Bah, NixOS est plutot radical et pour que cela fonctionne, il faut tout nixifier, d'où le prix élevé du ticket d'entrée.
Cela dit, NixOS ne gère pas la configuration utilisateur, uniquement celle du système. Il est donc possible de ne commencer que par nixifier sa configuration système. Ensuite, home-manager est un projet permettant de nixifier sa configuration utilisateur.

je ne savais pas que tu moulais ici. :-)

Héhé, uniquement pour lire les articles sur Guix;)

lewo a fait la partie Nix et j'ai fait la partie Guix. Et on a échangé sur la question.

Oui, et c'est super qu'on puisse faire avancer le schmilblick ensemble!

mais alors à quoi cela sert-il ?

C'est pour générer qq stats, un peu de mise en page et implémenter le "cron job".

Maintenant, comparons avec ce que Nix doit faire :

https://github.com/nix-community/nixpkgs-swh

donc des Nix expressions qui générent des fichiers qui sont ensuite parsés par du Python > et le tout recollé avec du Shell.

Je peux confirmer qu'un langage généraliste aurait été plus pratique que Nix pour réaliser ce genre de tâche!

Cependant, il est "presque" possible de générer ce fichier avec Nix uniquement: un bout de Python est utilisé pour palier à une petite builtin actuellement manquante (hashToSRI). Le reste du Python et Bash n'étant, en fait, pas utilisé pour générer le fichier sources.json.

Le projet Simple NixOS Mailserver permet de déployer une stack mail configurable assez bien fournie, très simplement… pour celles et ceux utilisant déjà NixOS!

Juste pour confirmer que Nix est bien dans Debian unstable, bien qu'il ne soit pas respecte pas le FHS (Filesystem Hierarchy Standard) (cf la dicussion https://lists.debian.org/debian-devel/2019/01/msg00013.html).

Je ne sais pas quelle espace disposent les poules dans ce cas, mais des cahiers des charges de label peuvent être utile pour se faire une idée.
Pour Nature et Progrès, en gros, c'est 10 poule/m² en intérieur et 4m² par poule d'espace extérieur (http://www.natureetprogres.org/servicepro/sp100.pdf page 14).
Ces chiffres existent aussi pour AB, et autres labels.

Pour répondre partiellement, l'image buildée par Nix n'a pas d'image parente. Il est cependant possible d'en ajouter une si besoin.