roptat a écrit 45 commentaires

oui exactement. Je voulais simplement dire qu'on aurait peut-être pu diviser un peu plus certains paquets pour réduire cette taille. Mais en effet, par défaut tu utilises la sortie "out" de glib, et pas "doc".

Le problème que tu as, c'est que tu télécharges le paquet entier, alors que tu n'as besoin que d'une petite partie (les bibliothèques). Sur la plupart des distributions, c'est le cas : tu as libpng, libpng-dev ou pour postgresql, tu vas avoir libpostgresql et postgresql-server par exemple.

Dans le cas de Guix, ça complique un peu les choses de séparer les paquets, même si c'est possible. Un paquet peut avoir plusieurs sorties (par exemple le paquet bind a la sortie out par défaut et utils, on peut le voir avec guix package --show=bind).

La plupart du temps, c'est un peu compliqué de faire ça, parce qu'il faut alors spécifier la sortie qu'on veut utiliser comme dépendance d'un paquet si ce n'est pas la sortie par défaut. Il peut aussi y avoir parfois des problèmes de références circulaires entre les sorties. Ça fait que la séparation en différentes sorties est limitée. Maintenant ça serait sans doute intéressant d'étudier l'impact de la séparation de quelques paquets clefs sur la taille totale du téléchargement d'applications courantes.

Tu peux aussi regarder avec guix graph la raison pour laquelle tu as besoin de postgresql et wayland pour le paquet que tu installes. guix size te donneras la taille totale du paquet, en prenant en compte les dépendances récursivement (mais sans prendre en compte le fait que ces dépendances sont partagées avec d'autres applications).

Dans Guix, les paquets sont déclarés avec leurs recettes, et en général il n'y a à un seul instant une seule version de tel ou tel paquet. Chaque paquet déclaré est associé à une variable qu'on utilise ensuite. Donc par exemple, la variable libpng contient une déclaration du paquet libpng. En utilisant cette variable dans la liste des dépendances, on utilise précisément le paquet construit quant on « évalue » la variable. Le fait qu'il n'y ait qu'une seule variable qui s'appelle libpng signifie que tous les paquets d'une version de guix qui utilisent libpng utiliseront le même paquet.

Entre deux versions de Guix, la version de libpng peut changer mais ce n'est pas grave : une fois installé dans le dépôt un paquet continue de faire référence à la même libpng. On peut aussi utiliser des inférieurs pour utiliser la version de telle révision de Guix (une révision passée ou future). On peut déclarer un nouveau paquet, qu'on pourrait lier à une variable libpng-1.5 pour utiliser une autre version. Comme chaque paquet est installé dans un répertoire à lui qui contient un hash des entrées et de sa recette, cette dernière solution crée un paquet différent du paquet libpng (en version 1.5) d'un inférieur où libpng était dans cette version. Il n'y a pas de conflit.

Guix va télécharger toutes les dépendances. Scribus a sans doute des dépendances à des trucs qui peuvent utiliser mesa, ou wayland, ou postgresql, en tant que bibliothèques, mais il ne lancera jamais de service sur une distribution externe. Ces paquets n'ont pas été séparés en bibliothèques / binaires / etc, mais ils pourraient l'être.

Le noyau lui-même n'est effectivement pas pris en compte dans le modèle, mais il y a assez peu de problèmes de compatibilité entre versions. L'ensemble des services qui tournent sur la machines peuvent aussi être problématiques, mais encore une fois, leur compatibilité casse assez peu souvent.

Pour le reste, c'est un peu plus compliqué. Tous les paquets sont installés dans le dépôt, une arborescence de fichier en ajout-seul (sauf pour le ramasse-miettes, qui a le droit de supprimer ce qui n'est utilisé par aucune génération des profils sur le système). Quand je construis un paquet, je vais en fait l'ajouter au dépôt dans un chemin de la forme /gnu/store/<hash>-<nom>/. Par exemple, pour le paquet hello, j'ai actuellement /gnu/store/md2plii4g5sk66wg9cgwc964l3xwhrm9-hello-2.10.

L'une des dépendances de hello, c'est la bibliothèque C (glibc), et on peut s'en rendre compte en regardant les détails du fichier binaire:

$ file /gnu/store/md2plii4g5sk66wg9cgwc964l3xwhrm9-hello-2.10/bin/hello 
/gnu/store/md2plii4g5sk66wg9cgwc964l3xwhrm9-hello-2.10/bin/hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped

Comme on peut le voir, le fichier fait directement référence à ld-linux-x86-64.so.2 dans le dépôt, et non à un fichier installé de manière globale sur le système, comme pourrait l'être /lib/ld-linux-x86-64.so.2 par exemple. Ça veut dire que, quoi qu'il arrive autour de ce paquet, il fera toujours référence à la même bibliothèque standard C. Il en va de même pour toutes ses dépendances.

Ce chemin vers la bibliothèque standard C ne vient pas de nul part : le paquet est compilé à partir d'une recette qui vient d'une version précise de Guix. Le chemin est question est celui qui provient de la recette de glibc dans la même révision de Guix. Si une future révision de Guix met à jour la recette de glibc (par exemple en la mettant à jour), cela modifie l'entrée correspondante pour le paquet hello. Le paquet hello qui serait construit à partir de cette nouvelle version ferait alors référence directement à la glibc de cette nouvelle révision de Guix.

Quand on met à jour son système, on met à jour la révision de Guix et on reconstruit tous les paquets dont les entrées ont changés (récursivement). À chaque mise à jour les nouvelles variantes des paquets font bien référence aux nouvelles variantes de leurs dépendances (ou les anciennes si elles n'ont pas changé), ce qui garanti que tout est bien mis à jour. Les anciens paquets qui ne sont plus nécessaires peuvent être récoltés par le ramasse-miettes.

Mais c'est aussi pour cela que l'article dit qu'un paquet construit une fois ne peut pas casser : tant qu'il est dans le dépôt, il fait référence aux paquets qui l'ont construit, et pas des versions différentes. On a donc l'avantage des deux mondes : du partage autant que possible pour les paquets d'une même révision de Guix, mais les dépendances sont préservées à leur version d'origine pour les paquets qui ne peuvent pas être mis à jour.

J'ai dit « facultatives ». Sur une distribution externe, ce n'est pas activé par défaut, mais il suffit d'une commande pour le faire (et c'est recommandé par le manuel, et proposé par le script d'installation). Le fait que ça ne soit pas activé par défaut est simplement dû à la procédure d'installation dans ce cas, plus qu'à un choix réfléchi. Sur le système Guix, c'est activé par défaut.

Pour flatpak, je vois par exemple que gimp est basé sur "org.gnome.Platform", ce qui a l'air assez vague et sans doute plus gros que nécessaire. C'est défini quelque part ? Qui construit ces images ? Le paquet gimp a l'air de redéfinir tout ce dont il a besoin : gtk2, ibus-gtk2, etc… Donc si j'ai deux flatpak qui utilisent les mêmes dépendances, j'ai deux fois les mêmes dépendances ? Je les construit deux fois ? Ou alors ces dépendances ne sont utilisées qu'à la construction et l'exécution se fait avec org.gnome.Platform ? Mais dans ce cas comment garantir l'adéquation entre le paquet construit et son environnement d'exécution ?

Dans Guix, chaque paquet est défini séparément et peut réutiliser les mêmes définitions. À la fin, les dépendances à l'exécution sont un sous-ensemble des dépendances à la compilation, ce qui garanti que ce soient les mêmes dans les deux cas.

Merci pour ce commentaire enthousiaste :D

pour donner quelques précisions, le seul autre projet qui ressemble à Guix, c'est Nix. Nix (comme NixOS) est basé sur les recherches et la thèse d'Eelco Dolstra. Pour créer Nix, Eelco a inventé le langage d'expression Nix de toutes pièces et construit la distribution à partir de zéro. Guix est plus récent et s'inspire beaucoup de Nix (d'ailleurs on partage le même démon) mais utilise le langage Guile, qui existait déjà, et a aussi reconstruit son système de zéro.

Les deux projets sont vraiment très similaires et pourront sans doute tous les deux t'intéresser. Je préfère Guix pour son utilisation plus homogène d'un seul langage (pas besoin de connaître Nix et Shell, Guile suffit à tous les niveaux) et pour la structure des données qui rend beaucoup plus lisibles le code et les déclarations de paquets, de systèmes, etc, mais aussi pour son gros travail sur la reproductibilité et la bootstrappabilité.

Dans l'ensemble tu as bien raison, Guix est LA distribution du futur :)

Oui, tout est configurable depuis cet unique fichier de conf. En fait, il est fortement déconseillé de toucher à quoi que ce soit d'autre du système : guix gère le système, ce n'est pas à nous de le faire.

Certains services proposent cependant d'utiliser un fichier de configuration externe, dans /etc si tu en as déjà un, mais la plupart du temps, il y a une interface un peu plus homogène et programmable pour ces services. Évidemment, il n'y a pas de code pour tous les services possibles et imaginables, mais ça grandit :)

Tu peux regarder le sommaire de ce chapitre pour avoir une idée de ce qui est configurable, et par exemple pour les services, regarder celui-ci.

Pour tes exemples, la configuration réseau se fait via le service dhcp-service, static-networking-service, connman-service ou network-manager-service. La gestion des serveurs et de leur configuration se fait via divers services et les clefs connues des machines sont configurées avec openssh-service.

S'il manque un service qui t'est nécessaire, tes contributions sont les bienvenues :D

Certains répondront sans doute mieux que moi : je ne connais pas bien le cas du HPC. Pour ce qui est du déploiement de configurations, il n'y a rien dans Guix lui-même hormis la configuration de la machine elle-même. On peut cependant construire une configuration sur une machine et l'envoyer sur une autre, ou décharger la compilation sur une autre machine. Pour ce que j'en sais, les utilisateurs HPC utilisent Guix sur une distribution externe, donc en pratique ça ne change rien. Il y a eu des discussions sur guix deploy et une proposition de projet pour Google Summer of Code.

Pour des exemples de configuration de plusieurs machines via le même dépôt, tu peux jeter un œil à la configuration des fermes de construction de Guix et la configuration de mes propres machines. Peut-être que d'autres pourront compléter.

1)

flatpak et snap sont des solutions pour créer des snapshot pour faire tourner un logiciel. Je ne me suis jamais trop intéressé à ces technos, mais ce que j'en comprends, c'est qu'il est très difficile de reproduire le même environnement ou d'en modifier des bouts. Guix n'est pas exactement un concurrent dans ce sens (ou peut créer des conteneurs docker ou singularity, et rien n'interdit d'ajouter la prise en charge de flatpak ou snap dans le futur), mais une approche radicalement différente pour créer ces conteneurs.

Dans docker (que je connais mieux) on utilise un dockerfile (dans le meilleur des cas) pour spécifier des commandes à lancer. C'est une manière très impérative de faire, et qui dépend beaucoup de l'état extérieur au conteneur ou à docker. Je crois que c'est aussi le cas pour les autres technos. Avec Guix, tu peux déclarer de manière fonctionnelle et sans état (autre que guix lui-même). C'est pour ça qu'on parle de gestion des paquets fonctionnelles : la même entrée (guix et un manifeste) donnera toujours la même sortie (le même conteneur, environnement, VM, …). À l'inverse, les outils par défaut de flatpak et autres ne permettent pas de faire ça. Si on considère que la plupart des dockerfiles commencent par apt-get update, on comprendra facilement qu'un dockerfile qui marche une fois ne fonctionnera peut-être plus la prochaine fois.

Le dépôt de Guix de référence est son code source, sur savannah. Par défaut, seuls les paquets de ce dépôt sont présents. Ils sont mis à jour par guix pull qui récupère la dernière version de ce code, et donc des paquets. Il y a aussi deux fermes de constructions qui fournissent des binaires, mais elles sont facultatives : avec la transparence binaire, on peut aussi bien compiler soit-même que télécharger des « substituts ». D'ailleurs guix va compiler les paquets lui-même s'il n'arrive pas à contacter de ferme de construction ou qu'il ne trouve aucun substitut pour certains paquets. Il y a un mécanisme de canaux qui permet d'étendre la collection de paquets de Guix. Pour cela, il y a juste besoin de déclarer les canaux à utiliser dans ~/.config/guix/channels.scm. C'est expliqué dans le manuel, et voici quelques exemples de canaux. Ces canaux ne sont pas officiels.

Je crois qu'il y a un paquet dans les dépôts non officiels de fedora (copper ou un truc comme ça), mais le mieux reste d'effectuer une installation avec le script d'installation officiel.

2)

guix environment gimp crée un environnement similaire à celui utilisé pour compiler réellement gimp. Il y a toutes les dépendances à la compilation déclarées dans la recette de gimp (dont make, gcc, et toutes les bibliothèques et outils nécessaires). C'est tout. Gimp lui-même n'est pas disponible dans cet environnement. Si on veut ajouter des programmes à l'environnement (par exemple gimp lui-même), il y a une option --ad-hoc qui fait ça. guix environment gimp --ad-hoc gimp crée donc un environnement pour construire gimp, dans lequel toutes les dépendances à la compilation de gimp sont disponibles, en plus de gimp lui-même.

Ça dépend du logiciel. Souvent en effet j'utilise guix refresh pour être informé des mises à jour, mais tous les paquets ne sont pas pris en charge. Parfois ça se fait via les collègues, parfois je vais sur le site de temps en temps et pour le reste je suis abonné à une liste de diffusion nom-du-projet-announces.

Tu ne dois pas être le seul projet sur tuxfamily, donc je vais voir si je peux écrire un petit gestionnaire de mise à jour.

Hop, merci pour ce jeu aussi facile à empaqueter, il est maintenant dans guix dont on parlait il y a peu :)

Tu sais s'il y a moyen d'être prévenu lors de la publication de nouvelles versions, pour que je puisse faire la mise à jour dans guix au moment de leur sortie ?

Ça serait pas mieux d'utiliser un truc existant que de réinventer ton format de données ? En cherchant un peu rapidement je trouve ça qui propose d'utiliser go-i18n qui a l'air pas trop mal.

Pour guix, il n'y a pas de notion de paquet recommandé. J'imagine que ça pourrait être ajouté assez facilement dans les métadonnées du paquet, mais pour l'instant nous ne gérons pas ça. On reste ouvert aux propositions cependant, et tu peux tester par toi-même en installant le gestionnaire de paquets sur ton système debian pour comparer et voir ce qui pourrait manquer d'autre.

Je ne suis pas sûr de comprendre la notion de paquet orphelin. Un paquet installé pour une dépendance mais pas installé explicitement par l'utilisateur ? Dans ce cas je viens de te répondre dans un autre commentaire : comme le profil ne contient que les paquets explicitement demandés par l'utilisateur, il n'y a pas d'orphelin. C'est aussi le cas pour Nix. Si ce n'est pas la bonne définition, tu pourrais préciser ?

À titre d'exemple, voici ce qui se passe quand je demande la liste des paquets installés dans mon profil utilisateur :

$ guix package -I
neovim  0.3.4   out /gnu/store/8ha2x36s49321bvjhwq83gvh2f8lq8fz-neovim-0.3.4
python-neovim   0.3.2   out /gnu/store/iqsl6cr825d2cpm4qs6fy3x2pjmvmbrs-python-neovim-0.3.2
...

$ guix package -I | wc -l
58

Par contre, qu'en est-il des patchs downstream? De la signature du packageur?
Si je prend par exemple Debian, le format des paquets binaire en lui-même est vraiment simple.

L'ensemble des paquets de la distributions sont présents dans un dépôt git. Chaque commit doit être signé par la personne qui le pousse et nous avons des lignes directrices assez strictes quant à la qualité des recettes et des logiciels inclus dans la distribution. Il n'y a pas de paquets binaires à proprement dit : seulement des recettes. Le projet a deux fermes de construction qui publient les paquets qu'elles construisent et les signent avec leur propre clef. L'utilisateur est libre d'accorder sa confiance à une ferme de construction ou non.

On parle de transparence binaire : comme les paquets sont reproductibles, à partir de la même recette (et du même commit de guix), il est impossible de distinguer un paquet construit localement d'un paquet construit à distance. On peut donc soit construire le paquet localement, soit utiliser un « substitut binaire », qui remplace la construction du paquet. Grâce à ça, on peut aussi vérifier que les fermes de constructions ne sont pas corrompues en construisant un paquet localement et en défiant les fermes de construction, de cette manière :

guix challenge python-oauthlib python-polib python-tornado --substitute-urls="https://mirror.hydra.gnu.org https://ci.guix.gnu.org"
mise à jour des substituts depuis « https://mirror.hydra.gnu.org »... 100.0 %
mise à jour des substituts depuis « https://ci.guix.gnu.org »... 100.0 %

3 éléments du dépôt ont été analysés :
  - 3 (100.0 %) étaient identiques
  - 0 (0.0 %) étaient différents
  - 0 (0.0 %) étaient impossibles à évaluer

Ça permet de se rassurer et d'ajouter un peu plus de confiance dans les fermes de construction. Chaque utilisateur peut aussi publier les paquets binaires qu'il a construit localement ou substitués, en les signant avec sa propre clef, que d'autres utilisateurs peuvent autoriser.

Par contre, faire un paquet Debian qui respecte les exigences de qualité Debian est plus chiant, ne serait-ce que la customisation des règles (fichier debian/rules) qui doit être en accord avec le fichier de conrôle (debian/control) ça rend les choses assez pénibles pour que, personnellement, au taf et pour ma pomme, je compile via cmake/autotools/scons/whatever et empaquette les binaires directement (coucou, libsdl2!).
L'une des raisons de la pénibilité des paquets source de Debian, selon moi, c'est la gestion des patchs, qui sont je pense nécessaires à une distro de type cyclique (pour une rolling, ce serait probablement trop pénible à gérer).

Impossible d'empaqueter des paquets binaires avec guix : tout doit utiliser des recettes, l'équivalent de debian/rules. Le but de ce gestionnaire de paquets est avant tout la transparence, et un paquet binaire n'est pas transparent du tout. D'ailleurs c'est plus généralement le but du projet reproducible-builds.

Pour les correctifs, effectivement on en a assez peu puisqu'on a un modèle de type cyclique. On peut cependant en ajouter dans l'enregistrement origin que je montrais plus haut, par exemple :

(source (origin
          (method url-fetch)
          (uri (string-append "ftp://xmlsoft.org/libxslt/libxslt-"
                              version ".tar.gz"))
          (sha256
           (base32
            "0q2l6m56iv3ysxgm2walhg4c9wp7q183jb328687i9zlp85csvjj"))
          (patches (search-patches "libxslt-generated-ids.patch"))))

et le fichier se trouve à un endroit bien précis dans l'arborescence des sources de guix ou du canal qui possède ce paquet.

Une autre est la gestion des transitions, mais il me semble que Guix règle le problème avec des hash mis au bout des dossiers dépaquetés? Ou alors est-ce juste Nix? Toujours est-il que la gestion des transitions dans Debian est, je pense, remarquable, et aussi complexe à implémenter pour les daemons, tout en permettant un système très propre (un paquet ne restera pas installé en doublon ou sans raison sans demande explicite de l'admin). Que fait Guix de ce côté?

Sous guix (comme nix), les paquets sont présents dans le dépôt (/gnu/store ou /nix/store). Il peut y avoir dans le dépôt plus de paquets que nécessaire, mais j'y viens. En tant qu'utilisateur j'ai un profil de paquets (et même, je pourrais en créer plusieurs) dans lequel ne sont présents que les paquets que j'ai explicitement demandé, mais pas leurs dépendances, car les paquets se réfèrent à leurs dépendances directement avec leur chemin dans le dépôt. Chaque modification du profil crée une nouvelle génération, et on peut instantanément revenir à une génération antérieure ou postérieure. On peut aussi, quand on n'en a plus besoin, supprimer d'anciennes générations pour faire de la place.

Donc, avec guix remove qui « supprime » un paquet, je ne retire pas un paquet de mon profil, je crée une nouvelle génération qui contient les mêmes paquets qu'avant, sauf ceux que j'ai supprimés : rien n'est supprimé du dépôt. En supprimant des générations, je retire simplement la possibilité de revenir à elles, mais rien n'est supprimé du dépôt non plus. Pour supprimer des éléments du dépôt et faire de la place, on peut lancer guix gc qui va automatiquement déterminer les éléments du dépôt qui ne sont plus accessible depuis au moins une génération d'un profil et les supprimer, un peu comme le ferait autoclean avec le cache de debian. À noter que comme seuls les paquets explicitement demandés par l'utilisateur sont installés, il n'y a pas besoin d'équivalent à autoremove.

Ça serait étonnant : quelle serait alors la différence entre Triskel et le système Guix ? On peut néanmoins toujours installer Guix en tant que gestionnaire de paquet secondaire sur n'importe quelle autre distribution (même Android !), sans que cela n'impacte le gestionnaire de paquets du système. Les deux étant complètement indépendants l'un de l'autre. On dit alors que Guix est installé sur une distribution externe (foreign distro).

Je crois que je peux répondre à la première de ces questions, étant contributeur :)

Sur la simplicité ou non de créer des paquets sur Guix, ça dépend du paquet en question. Certains sont vraiment très chiants, mais la difficulté est plutôt imputable au paquet : il sera aussi chiant à packager sur d'autres gestionnaires. La plupart du temps cependant, les paquets sont assez simples. Contrairement à nix qui construit un script bash avec son propre langage, les paquets dans Guix ont une forme plus déclarative et utilisent le concept de « système de construction ». Par exemple, pour un paquet python, on utilisera le python-build-system, pour un paquet cmake, on a le cmake-build-system, pour dune (outil de construction pour des paquets OCaml), on a le dune-build-system, pour un paquet qui utilise les autotools et suit la convention « configure, make, make install », on a le gnu-build-system, etc. En plus de ça, on a un outil d'import qui permet d'automatiser la création de recettes. Par exemple, si je veux importer le paquet OCaml qcheck, je lance guix import opam qcheck et j'obtiens :

(package
  (name "ocaml-qcheck")
  (version "0.9")
  (source
    (origin
      (method url-fetch)
      (uri "https://github.com/c-cube/qcheck/archive/0.9.tar.gz")
      (sha256
        (base32
          "1gczijq2vghb8aqn84w3c3h5lpxa7d0qnlmvzac48jqfly7d2cna"))))
  (build-system dune-build-system)
  (inputs
    `(("ocaml-base-bytes" ,ocaml-base-bytes)
      ("ocaml-base-unix" ,ocaml-base-unix)
      ("ocaml-qcheck-core" ,ocaml-qcheck-core)
      ("ocaml-qcheck-ounit" ,ocaml-qcheck-ounit)
      ("ocaml-odoc" ,ocaml-odoc)))
  (home-page "https://github.com/c-cube/qcheck/")
  (synopsis
    "QuickCheck inspired property-based testing for OCaml.")
  (description
    "This module allows to check invariants (properties of some types) over
randomly generated instances of the type. It provides combinators for
generating instances and printing them.")
  (license #f))

qui est vraiment très facile à lire. le seul truc un peu bizarre, ce sont les parenthèses (en fait c'est une expression Guile, une implémentation de Scheme) et le contenu de « inputs » avec ses apostrophes et ses virgules, mais dans l'ensemble on peut simplement se dire que ce sont des éléments de syntaxe un peu étranges et si on ne connait pas le langage, pas besoin de l'apprendre. Avec cette recette, on peut construire le paquet en question, il faut juste nettoyer un peu (par exemple retirer les pseudo-paquets ocaml-base-bytes et ocaml-base-unix et choisir une licence appropriée). Ce paquet et ses dépendances sont déjà dans Guix, mais la plupart du temps, l'option -r permet aussi d'importer récursivement les dépendances qui ne sont pas encore dans la distribution.

Il y a aussi des importateurs pour d'autres sources, comme pypi, cpan, hackage, elpa, gem, cran, et d'autres.

Pour les autres questions, je ne peux pas répondre avec précision, mais je sais au moins que les deux co-mainteneurs, Ludo et Ricardo maintiennent une infrastructure qui utilise Guix dans le contexte du calcul haute-performance. Peut-être que la lecture de la page du projet guix-hpc permettra de répondre à tes questions ?

Je peux aussi te dire que lorsque j'entends parler de recherche reproductible de mon côté, j'entends surtout parler de docker et de technologies similaires : il s'agit de faire un snapshot pour le redistribuer aux collègues. Dans tous les cas, je préfère guix qui permet de reconstruire le snapshot de manière transparente, et de facilement jouer avec (par exemple, reconstruire exactement le même snapshot, mais avec une version de tel logiciel différent, ou en mettant tous les paquets à jour).

Pour ce qui est de la dépendance au noyau effectivement, Nix comme Guix supposent que l'interface du noyau ne change pas de comportement et ignore totalement sa version.

En effet, je ne crois pas que ALFS soit vraiment adapté pour créer une distribution. Le but de ce script est double : pour les utilisateurs qui ont déjà suivi le livre plusieurs fois et qui n'ont plus rien à y apprendre, et pour les développeurs qui peuvent alors vérifier rapidement si les instructions du livre fonctionnent.

Si on veut faire sa propre distribution, je trouve qu'il vaut mieux utiliser un gestionnaire de paquets pour gérer les logiciels (dont la base de la distribution : la chaîne de compilation et tout). Si je dis ça, c'est qu'un bon gestionnaire de paquet propose des outils pour que les utilisateurs installent des paquets pré-compilés (ou les compiler soi-même, peu importe) mais aussi des outils pour les développeurs de la distribution, pour qu'ils puissent tester ou compiler les paquets qu'ils proposent à leurs utilisateurs. Il reste utile d'extraire les commandes depuis le livre vers des recettes séparées. La chaîne de bootstrap du début (le chapitre 5 en fait) est aussi une très bonne source d'inspiration pour démarrer sa distribution sur des bases saines. Mais ALFS fournit à la fin un système complet, en un seul gros morceau. C'est pas très propre je trouve.

Contrairement à une distribution, LFS place ses utilisateurs dans le rôle de mainteneur de distribution. Chacun est libre de faire ses choix, de modifier sa « distribution » comme il l'entend. La simplicité (toute relative) de LFS par rapport à des solutions plus avancées (dpkg, ebuild, rpm, …), fait aussi sa force : on peut voir vraiment les rouages essentiels d'une distribution. En revanche, je déconseille d'utiliser au quotidien un système LFS sans y apporter quelques modifications : il y a une raison pour laquelle on a inventé les gestionnaires de paquets et pour laquelle on automatise la construction des paquets.

Pour ce qui est de la construction du système, c'est le but. C'est avant tout pédagogique. À la fin, on peut évidemment configurer son système aux petits oignons (noyau avec les modules qui nous font plaisir, configuration des services, …) mais on peut faire cela sur n'importe quelle autre distribution. Le livre suivant, BLFS, propose un peu plus d'options avec des notions de dépendances facultatives : on peut ajouter telle ou telle fonctionnalité à tel ou tel paquet.

Le système LFS brut est assez minimal, il y a assez peu de différence sur ces quelques paquets entre distributions de toute façon, en dehors de la version ou des différences entre les variantes de LFS. BLFS propose un choix beaucoup plus large et on peut créer son système avec les fonctionnalités que l'on souhaite, beaucoup plus finement que sur une distribution même comme Gentoo.

J'ai un peu de mal à comprendre le commentaire, mais j'espère pouvoir donner des précisions utiles.

Je trouve la frontière assez floue entre « système LFS » et « nouvelle distribution inspirée par LFS ». En fait, si on se contente de suivre le guide, on arrive à un système assez difficile à maintenir, pas forcément très personnalisé et finalement, on trouve mieux ailleurs. Mais le véritable intérêt et la force de LFS, c'est justement de ne pas suivre le livre, mais de s'en éloigner pour voir ce que ça donne.

Une petite anecdote : je voulais mieux comprendre comment fonctionnait le système d'initialisation, et pour rigoler, j'ai écrit un Makefile qui lancerait tout le système (vu que make sait gérer les dépendances et fait du parallélisme, ça ferait une version un peu améliorée de sysVinit). Du coup j'ai suivi le guide, mais au lieu d'installer sysVinit, j'ai installé mon Makefile (que j'ai astucieusement appelé /sbin/init, avec un shebang du style #!/bin/make -j5 -f) et hop. En redémarrant, ça a fonctionné.

On peut aussi expérimenter avec d'autres aspects, comme la gestion des paquets, la chaîne de construction et d'autres trucs. En définitive, même si terminer un système LFS en suivant le livre à la lettre est gratifiant et très instructif, quand on l'a déjà fait une ou deux fois et qu'on est à l'aise avec les principes du livre, il est encore plus intéressant de se lancer sans filet et de voir ce que ça donne :). Ça permet aussi d'être très à l'aise avec les concepts manipulés par les distributions, et de contribuer directement. Sans LFS, je ne sais pas si j'aurais eu le courage de contribuer sur la distribution que j'utilise maintenant.

Une autre différence majeure entre distribution et LFS, c'est l'absence de gestionnaire de paquets. Il faut vraiment beaucoup s'éloigner du livre pour arriver à un point où il devient facile de « partager » des paquets entre machines : construire sur une machine et obtenir la même chose sur l'autre (soit en partageant le binaire, soit en partageant la recette). Donc à mon avis, une distribution inspirée par LFS n'est pas un système LFS, mais comme je le disais, la frontière est très floue.

Pour bien prendre le temps de lire le livre et de le comprendre, il te faudra sans doute une semaine (ça inclut le temps de compilation du système, en supposant que tu ne t'éloignes pas du livre). Si tu as déjà lu le livre plusieurs fois et avec une bonne machine, ça peut se réduire à une journée (sur la mienne, plutôt deux à cause des temps de compilation).

Le mieux pour se lancer est d'utiliser une machine virtuelle (par exemple avec virtualbox), parce qu'elle permet de prendre des snapshots et de revenir en arrière facilement en cas de pépin. Ça permet aussi de pouvoir arrêter le processus et reprendre plus tard aisément. Ça fait gagner pas mal de temps.