GNU Guix version Un‐Point‐Zéro

46
9
mai
2019
Distribution

Nous sommes très heureux d’annoncer la publication de GNU Guix version 1.0.0 !

GNU Guix est un gestionnaire de paquets transactionnel et une distribution GNU perfectionnée qui respecte la liberté des utilisateurs. Guix peut être utilisé avec n’importe quelle distribution utilisant le noyau Linux, tout comme il peut être utilisé comme système d’exploitation à part entière pour des machines ayant une architecture i686, x86-64, ARMv7 ou AArch64.

En plus des fonctionnalités habituelles pour gérer des paquets, Guix permet des mises à jours et retours en arrière transactionnels, une gestion des paquets qui ne nécessite pas de droits privilégiés, des profils pour chaque utilisateur et une gestion automatique de la mémoire.

Lorsque Guix est utilisé comme une distribution GNU/Linux autonome, il permet la gestion de la configuration du système d’exploitation par une approche déclarative et sans état. Guix est extrêmement personnalisable et bidouillable via Guile qui est une implémentation du langage Scheme avec quelques extensions.

La publication fournit des images d’installation ISO 9660, une image pour machine virtuelle et des archives tar.xz pour installer le gestionnaire de paquets sur votre distribution GNU/Linux à partir des sources ou des binaires. Les utilisateurs de Guix peuvent mettre à jour en lançant guix pull.

La suite de la dépêche est une traduction de l’annonce officielle. Cette traduction n’a pas été faite par l’équipe de Guix, le « nous » utilisé dans la dépêche renvoie à l’équipe Guix, pas aux traducteurs.

Sommaire

Logo Guix 1.0

Guix 1.0 une aventure !

Un‐point‐zéro est toujours une étape importante dans la publication de logiciels libres. Pour Guix, 1.0 est le fruit de sept ans de développement. Deux cent soixante personnes ont produit du code, construit des paquets ou rédigé la documentation. Une douzaine de personnes a réalisé la traduction, l’identité graphique ou encore le développement du site Web… pour ne citer que quelques‐uns des travaux effectués. Au cours de ces années, nous avons publié pas moins de dix‐neuf versions « 0.x ».

Nous avons pris notre temps pour en arriver là, ce qui est assez inhabituel à une époque ou les logiciels libres évoluent rapidement. Pourquoi avons nous mis autant de temps ? Premièrement, construire une communauté autour d’une distribution GNU/Linux prend du temps et une distribution ne peux pas vraiment exister sans elle. Deuxièmement, nous avons le sentiment d’apporter une pièce importante au système d’exploitation GNU, et évidemment cela intimide et rend humble.

Enfin, nous avons construit quelque chose d’inédit. Bien sûr, nous nous tenons sur les épaules de géants, notamment Nix qui a conçu le paradigme de distribution de logiciels dont Guix est une implémentation. Mais le développement de Guix a été, et est encore, une prouesse dans plein de domaines : c’est une prouesse au niveau de la conception d’un langage de programmation, une prouesse au niveau de la conception d’un système d’exploitation, une prouesse au niveau de la sécurité, de la reproductibilité, de l’amorçage, de l’utilisabilité et de bien d’autres choses. Bref, cela a été une longue aventure, mais pleine d’enseignements.

Ce que GNU Guix peut faire pour vous

Nous supposons que nombre de lecteurs découvrent Guix aujourd’hui, voici donc un petit récapitulatif de ce que Guix peut faire pour vous, chers utilisateurs et utilisatrices.

Guix est un ensemble d’outils complet pour distribuer des logiciels, ce qui le distingue de la plupart des outils que vous connaissez.

Guix gère les paquets, les environnements, les conteneurs et les systèmes.

Guix gère les paquets, les environnements, les conteneurs et les systèmes

Le court guide de référence présente les principales commandes. En vous plongeant dans Guix, vous découvrirez bien des aspects du système exposé à l’aide d’interfaces de programmation Guile cohérentes : la définition des paquets, les services système, le système d’initialisation et tout un tas bibliothèques système. Nous pensons que cela rend le système très bidouillable, et nous espérons que vous vous amuserez autant avec que nous.

Tout cela peut paraître un peu abstrait, regardons donc des cas concrets.

Pour les utilisateurs

En tant qu’utilisateur, Guix vous permet d’installer vos logiciels et de les mettre à jour : trouvez des logiciels avec guix search, installez‐les avec guix install et mettez‐les à jour régulièrement en lançant guix pull et guix upgrade. Guix suit un modèle en publication continue (rolling release), ainsi vous pouvez lancer guix pull à tout moment pour obtenir la dernière et la meilleure version des logiciels libres.

Cela peut vous paraître familier, mais ce qui distingue Guix est sa fiabilité : Guix est transactionnel, cela veut dire que vous pouvez à tout instant revenir en arrière (à une « génération » précédente de votre ensemble de paquets) avec guix package --roll-back et examiner les différences avec guix package -l, etc.

Une autre propriété utile est la reproductibilité : Guix vous permet de déployer exactement le même environnement logiciel sur des machines différentes ou à des moments différents. Tout cela grâce à guix describe et guix pull.

Tout cela, en plus des opérations de gestion des paquets ne nécessitant pas de droits de super‐utilisateur root, est très précieux, notamment pour le calcul haute performance (HPC) et la reproductibilité en science, ce sur quoi le projet Guix-HPC a concentré ses efforts de développement.

Guix-HPC est un projet de développement de logiciels auquel participent actuellement trois instituts de recherche : Inria, le Centre de médecine moléculaire Max Delbrück (MDC) et le Centre de bio‐informatique d’Utrecht (UBC).

Pour les développeurs

En tant que développeur, nous espérons que vous apprécierez guix environnement. Il vous permet de créer des environnements logiciels uniques. Supposons que vous êtes un développeur de GIMP : guix environment gimp permet de produire un environnement avec tout ce dont vous avez besoin pour « hacker » GIMP, bien plus rapidement que l’installation manuelle de ses nombreuses dépendances.

Les développeurs ont souvent du mal à diffuser leur travail aux utilisateurs, ce qui leur permettrait d’avoir rapidement des retours d’expérience. guix pack offre un moyen simple de créer des conteneurs utilisables par Docker et compagnie, ou même des archives TAR relocalisables [relocatable] et exécutables par tout le monde, indépendamment de la distribution GNU/Linux utilisée.

Ah, et vous aimerez sûrement aussi les options de transformation de paquet, elles vous permettent de définir des variantes de paquets via la ligne de commande.

Pour les administrateurs système

En tant qu’administrateur système (et actuellement nous sommes tous des espèces d’administrateurs système de nos ordinateurs portables), l’approche déclarative et unifiée de Guix pour gérer les configurations vous sera très utile. C’est sûrement une pratique avec laquelle la plupart des gens sont habitués, mais c’est si rassurant : un fichier de configuration suffit pour spécifier tous les aspects de la configuration du système (services, systèmes de fichiers, options de localisation, comptes des utilisateurs), le tout dans un même langage.

Tout cela rend étonnamment facile le déploiement de services autrement plus complexes, comme des logiciels qui dépendent de services Web. Par exemple, installer CGit ou Zabbix se fait en une ligne, même si, en coulisse, cela implique la configuration de nginx, fcgiwrap, etc. Nous aimerions voir dans quelle mesure cela aide les gens à héberger eux‐mêmes leurs services — un peu comme ce qui est proposé par FreedomBox et YunoHost.

Avec le guix system, vous pouvez instancier une configuration sur votre machine, ou dans une machine virtuelle où la tester, ou dans un conteneur. Vous pouvez aussi provisionner des images ISO, des images de machines virtuelles ou des images de conteneurs avec un système d’exploitation complet depuis la même configuration, grâce à guix system.

Voilà pour l’aperçu !

Les nouveautés depuis la version 0.16.0

Pour ceux qui nous ont suivi jusqu’ici, de nombreuses et importantes choses ont changé depuis les cinq derniers mois, depuis la version 0.16.

En effet, sur cette période, 99 personnes ont contribué via 5 700 commits, dont voici les principaux points :

  • l’image ISO d’installation dispose dorénavant d’un installateur graphique tout mignon (un grand merci à Mathieu Othacehe pour l’avoir développé, et merci à tout ceux qui l’ont testé et amélioré !) qui suit l’esprit de l’installateur Debian ; que vous soyez un hacker GNU/Linux intransigeant ou un utilisateur novice, vous constaterez certainement que cela rend l’installation du système beaucoup moins fastidieuse qu’elle ne l’était ! L’installateur est entièrement traduit en français, allemand et espagnol ;
  • la nouvelle image VM correspond mieux aux attentes des utilisateurs : que vous souhaitiez bricoler avec Guix System et voir à quoi il ressemble, ou que vous souhaitiez l’utiliser comme environnement de développement, cette image de machine virtuelle devrait être plus utile ;
  • plus de 1 100 paquets ont été ajoutés, 2 104 paquets ont été mis à jours et plusieurs services systèmes ont été fournis ; on approche donc des 10 000 paquets ;
  • l’interface utilisateur a été améliorée : maintenant, des alias pour les opérations communes comme guix search et guix install sont disponibles, les diagnostics sont colorés, plus d’opérations affichent une barre de progression, il y a une nouvelle option --verbosity reconnue par toutes les commandes et la plupart des commandes sont « silencieuses » par défaut ;
  • il y a une nouvelle option de transformation de paquet : --with-git-url, qui se combine avec --with-branch et --with-commit ;
  • Guix a maintenant un mécanisme uniforme de première classe pour configurer la disposition du clavier, une fonction attendue depuis longtemps ; dans la continuité, la configuration de X.Org a été adaptée avec le nouvel enregistrement xorg-configuration ;
  • nous avons introduit guix pack -R il y a longtemps : il crée des archives contenant des ensembles d’applications déplaçables qui reposent sur des espaces de noms d’utilisateurs ; à partir de la version 1.0, guix pack -RR (pour « reliably relocatable » ou « relocalisation fiable ») génère des fichiers binaires déplaçables qui reposent sur PRoot sur les systèmes où les espaces de noms d’utilisateurs ne sont pas pris en charge ;
  • le manuel a été entièrement traduit en français et les traductions allemandes et espagnoles sont presque terminées, et une traduction en chinois simplifié vient d’être lancée ; vous pouvez aider à traduire le manuel dans votre langue en intégrant le groupe de traduction.

Cette liste est déjà longue, mais vous trouverez plus de détails dans le fichier NEWS.

Les prochaines étapes

Un‐point‐zéro est une étape majeure, en particulier pour ceux d’entre nous qui participent au projet depuis plusieurs années. Mais avec les nombreuses idées que nous avons collectées, ce n’est certainement pas la fin de l’aventure !

Si vous êtes intéressé par le « devops » et le déploiement distribué, vous serez certainement ravi de nous aider dans ce domaine. Ceux qui sont intéressés par le développement de systèmes d’exploitation voudront peut‐être rendre Shepherd plus flexible et plus rapide.

Les scientifiques intéressés par la reproductibilité à long terme mettront certainement l’approfondissement de l’intégration au projet Software Heritage en première position sur leur liste de choses à améliorer.

Les bricoleurs en langage de programmation voudront peut‐être pousser plus loin les G-expressions, etc.

Guix 1.0 est un outil à la fois utile pour l’utilisation quotidienne d’un ordinateur et un grand terrain de jeu pour les bricoleurs que nous sommes.

Que vous souhaitiez aider au niveau du design, de la programmation, de la maintenance, de l’administration système, de la traduction, des tests, de la charte graphique, des services Web, du financement ou de l’organisation d’install parties, vos contributions sont bienvenues !

Nous sommes humains, n’hésitez pas à nous contacter. Et surtout amusez‐vous bien avec Guix 1.0 !

Aller plus loin

  • # Debian & Yunohost ?

    Posté par (page perso) . Évalué à 3 (+2/-0).

    Est-il envisageable que Debian utilise Guix à la place dpkg ? Idem pour Yunohost, actuellement basé sur Debian ?

    • [^] # Re: Debian & Yunohost ?

      Posté par (page perso) . Évalué à 5 (+4/-0).

      Le gestionnaire de paquets est quand même un élément central du système, ça ne doit pas être facile de migrer (quoique on a bien eu systemd). Je me poserais plutôt la question pour Trisquel qui est soutenue par la FSF.

      Un LUG en Lorraine : https://enunclic-cappel.fr

      • [^] # Re: Debian & Yunohost ?

        Posté par . Évalué à 4 (+3/-0). Dernière modification le 10/05/19 à 15:35.

        Ç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).

        • [^] # Re: Debian & Yunohost ?

          Posté par . Évalué à 5 (+3/-0).

          quelle serait alors la différence entre Triskel et le système Guix ?

          Pour moi la question n'est même pas là: est-ce que Guix règle les problèmes de dpkg tout en gardant la même puissance?
          Parce que bon, dpkg est très puissant, et une de ses fonctionnalités que j'apprécie particulièrement, c'est la notion de recommandations: des paquets optionnels qui améliorent un logiciel. Leur absence est même un de mes principaux reproches à xbps (voidlinux).
          De même, il me semble avoir lu que Nix, l'ancêtre de Guix, peinait à retrouver les paquets orphelins, ce qui n'est pas le cas d'apt, bien qu'il ne soit pas possible avec apt de spécifier la raison d'installation d'un paquet… et donc de le virer si la raison n'est plus valide.

          • [^] # Re: Debian & Yunohost ?

            Posté par . Évalué à 3 (+2/-0).

            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
            
      • [^] # Re: Debian & Yunohost ?

        Posté par (page perso) . Évalué à 2 (+1/-0). Dernière modification le 11/05/19 à 13:27.

        J'ai bien conscience de cette importance et de cette difficulté. Mais, il me semble, que la grande force de Debian c'est principalement sa communauté, ce qui manque actuellement à Guix.

        Guix gagne 1000 paquets tous les 6 mois, à ce rythme il lui faudra encore 5 ans pour atteindre les 20 000 paquets… à comparer aux 51 000 paquets de Debian.

        Guix a donc besoin d'une accélération, la simplification de la gestion des paquets qu'il apporte est un bon argument pour switcher… et pour échapper à la stagnation des distributionsactuelles.

  • # Heu

    Posté par . Évalué à 8 (+7/-0).

    Un gestionnaire de packages sous ACID ? ;)

  • # Nix et autres

    Posté par (page perso) . Évalué à 10 (+9/-0). Dernière modification le 09/05/19 à 20:19.

    On m'a déjà "vendu" Nix une fois que c'était génial et tout et tout… Déjà, nix n'est pas toujours compatible avec lui même selon les versions donc l'environnement stable sur un cluster qui évolue et se renouvelle… Un peu sur-vendu.

    Faire un paquet Nix n'est pas si facile que cela. Qu'en est-il d'un paquet Guix ?

    On a toujours le même environnement… à condition de ne pas dépendre du noyau et de ses modules. Si vous faites du CUDA, Guix ne va pas plus être magique que Nix ou que module je pense.

    On a toujours le même environnement… ce qui permet la reproductibilité. C'est un argument actuel en science. Autant je trouve GÉNIAL le projet Reproductible Build en partie porté par Debian (un même code source donne toujours le même code compilé selon l'algorithme SHA256, donc je suis sur que le code qui tourne n'a pas de porte dérobée rajoutée en cachette), autant je suis sceptique en science pour du code ou ce mot, reproductible, est utilisé pour complètement autre chose. En science, je me fou un peu (je fais exprès de prendre l'argument 100% opposé) de retrouver avec le code du voisin le même résultat que lui à la dixième décimale ! Pour moi, la reproductibilité en science est qu'une autre équipe, avec un environnement quasi-identique (mais non forcément identique) retrouve les mêmes lois de comportement, les mêmes phénomènes. Cela permet d'enrichir et de conforter un modèle. Retrouver N fois le même résultat avec le même code n'a pas un intérêt fou, sauf à vérifier que le chercheur n'a pas triché, et encore… En plus, ce coté reproductible pousse les personnes à faire du code non portable, aux API qui changent et dont le résultat est fortement dépendant des versions des modules de ceci et de cela. Telle et telle version marchent (même s'il y a un bogue et que c'est hyper dépendant des versions), hop je publie -> c'est reproductible par tout lecteur ! Bref, cette notion là éloigne au final assez fortement de la notion de reproductible au sens universel du terme.

    Qu'en est-il du Python ? Car en pratique, c'est souvent les modules Python qui sont "chiants" à packager vu que cela bouge tout le temps (trop souvent) et que les API changent… Avec Nix, mes amis font du conda ou du virtualenv… Bref, c'est pas une super réussite !

    • [^] # Re: Nix et autres

      Posté par . Évalué à 10 (+11/-0). Dernière modification le 10/05/19 à 14:58.

      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.

      • [^] # Re: Nix et autres

        Posté par . Évalué à 4 (+2/-0).

        Donc, la génération de paquets sources est pas mal automatisée, au moins pour le descriptif.

        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.

        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).
        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é?

        • [^] # Re: Nix et autres

          Posté par . Évalué à 4 (+3/-0).

          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.

      • [^] # Re: Nix et autres

        Posté par . Évalué à 4 (+2/-0).

        en fait c'est une expression Guile, une implémentation de Scheme

        Je pourrais chercher mais comme tu utilise ton avis m'intéresse particulièrement : quels sont les avantages de guile face à d'autres langages plus commun ?

        • [^] # Re: Nix et autres

          Posté par . Évalué à 2 (+2/-0).

          Bonjour,
          Je me posais la même question il y a longtemps (20 ans…, premier numéro de LinuxMag il me semble, snif…), concernant le choix de scheme comme langage de script/macro/extension dans GIMP.
          Je crois deviner que l'interpréteur est très léger et robuste, et visiblement semble plutôt facile à lier à une API C/C++ ou embarquer dans une suite logicielle.
          Désormais il est sans doute un peu concurrencé par d'autre micro-interpréteurs comme lua j'imagine.
          Les gurus d'Emacs-Lisp ne seront pas trop dépaysés.
          A noter, il y a une douzaine d'années Scheme était enseigné en première année d'études universitaires scientifiques et techniques dans certaines universités en France.

          • [^] # Re: Nix et autres

            Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 12/05/19 à 11:39.

            La syntaxe pour décrire un objet et pour du code est la même. C'est hyper simple à parser. Bref, c'est un bon langage pour faire des extensions.

            Personnellement, j'aime bien le YAML pour décrire mais quand tu vois certains YAML d'aujourd'hui (Ansible…), on veut en faire un langage de script avec des boucles ! Un peu comme la catastrophe du XSLT pour le XML.

            Le LISP et ses dérivés n'ont pas ce problème là. La mixité donnée / programme s'est toujours bien passée dans cette syntaxe ;-)

            • [^] # Re: Nix et autres

              Posté par . Évalué à 2 (+0/-0).

              J'ai tiqué sur cette remarque:

              Un peu comme la catastrophe du XSLT pour le XML.

              En quoi XSLT est-il une catastrophe?
              C'est très pratique pour transformer un document XML en autre chose, ou pour en extraire des données.

              • [^] # Re: Nix et autres

                Posté par (page perso) . Évalué à 6 (+4/-0).

                C'est puissant et pratique, mais syntaxiquement lourdingue car ça a voulu utiliser de l'XML pour l'expression de la logique. XML est très bien pour l'échange entre programmes de données structurées, il permet éventuellement à un humain de relire/rédiger, mais pour l'expression d'une logique de programmation il est plutôt ch****.

                Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

                • [^] # Re: Nix et autres

                  Posté par . Évalué à 2 (+0/-0).

                  C'est verbeux en effet, mais si le but est de produire un XML structuré différemment (ou du HTML), ce dernier peut être inclus directement mélangé dans les balises XSLT, ce qui est beaucoup plus pratique que dans n'importe quel autre language, avec la garantie de générer un XML syntaxiquement valide.

                  • [^] # Re: Nix et autres

                    Posté par (page perso) . Évalué à 3 (+1/-0).

                    Plus de 90% du temps, tu relies du code d'un autre. Avec le XSLT, tu as la garantie d'avoir un XML valide mais est-ce le bon XML final ? Tu et les autres vont en ch… à maintenir et à faire évoluer ce morceau là du traitement !

                    XML comme YAML sont fondamentalement des langages de description. Vouloir les transformer en langage déclaratif n'est pas une bonne idée. C'est trop clairement écrit dans la structure initiale.

                    Le LISP qui est quasi du XML avant le XML mais basé sur une syntaxe en ( n'a pas ce problème car justement, ces concepteurs ont pris dès le début la ( afin de pouvoir mixer les deux : codes et données. Et encore, le paquet de )))) n'est pas toujours très parlant…

        • [^] # Re: Nix et autres

          Posté par . Évalué à 4 (+4/-0).

          quels sont les avantages de guile face à d'autres langages plus commun ?

          Il est très facile d'écrire un Domain Specific Language (DSL).

          Pour le dire autrement, on peut voir la définition d'un paquet comme simplement une liste de mot-clés (package, name, version, etc.) avec des déclarations. Au lieu de :

          (package
            (name "ocaml-qcheck")
            (version "0.9")
            (source
              (origin
                (method url-fetch)
          [...]

          cela pourrait se lire :

          package :
            name "ocaml-qcheck"
            version "0.9"
            source :
              origin :
                method url-fetch
          [...]

          et ceci est possible avec l'extension Wisp. C'est très déclaratif et il n'y a pas besoin de connaitre Lisp ou Scheme pour définir des paquets. Certes, il y a une petite barrière psychologique avec les parenthèses. :-)

          D'expérience dans les "configurations", on veut pouvoir décrire des choses plus ou moins complexes et très souvent on arrive à vouloir des fonctions, des boucles, des tests, etc. Alors autant utiliser directement un langage qui va bien.

          Pourquoi GNU Guile ? L'histoire dit que c'est un contributeur de Nix et qui était aussi co-mainteneur de GNU Guile. Et voilà Guile+Nix ;-)

          Et comme GNU Guix est basé sur scheme qui permet de créer facilement des DSL, il y a une expérimentation très intéressante pour décrire un workflow d'exécution (comme dans les projets Snakemake, Common Workflow Language, Workflow Definition Language, Nextflow, etc.), c'est le Guix Workflow Language. Par exemple, présentations au FOSDEM 2017 ou 2019.

    • [^] # Re: Nix et autres

      Posté par . Évalué à 4 (+4/-0).

      On m'a déjà "vendu" Nix une fois que c'était génial et tout et tout…

      Si si c'est génial !! Enfin le changement de paradigme (approche déclarative et fonctionnelle) est vraiment très intéressant.

      Déjà, nix n'est pas toujours compatible avec lui même selon les versions donc l'environnement stable sur un cluster qui évolue et se renouvelle

      Je n'ai pas compris ?

      Sinon, un point d'entrée concernant GNU Guix et le HPC est ce papier par les mainteneurs même si des petites choses se sont améliorées depuis.

      On a toujours le même environnement… ce qui permet la reproductibilité. C'est un argument actuel en science. […] autant je suis sceptique en science pour du code ou ce mot, reproductible, est utilisé pour complètement autre chose.

      Effectivement, le terme Reproducible Science est souvent utilisé sans vraiment définir de quoi on parle. N'est-ce pas un peu comme Big Data ou Machine Learning ? ;-)

      Disons pour faire simple et rapide, il faut distinguer :

      • répétable : le même code a tourné (plusieurs fois?) avec les mêmes données sur la même machine et les résultats sont similaires ;
      • reproductible : le même code a tourné avec les mêmes données sur une autre machine et les résultats sont similaires ;
      • réplicable : un autre code a tourné avec les mêmes données sur une autre machine et les résultats sont similaires.

      Bon il faut aussi définir similaire. Quelle précision ? Arithmétique d'intervalle ? etc.

      Disons que la distinction entre les 3 niveaux est admise mais la définition ne l'est pas toujours. Voir par exemple le journal ReScience.

      Retrouver N fois le même résultat avec le même code n'a pas un intérêt fou, sauf à vérifier que le chercheur n'a pas triché, et encore…

      N'est-ce pas essentiel dans le processus de revue par les pairs ?

      En plus, ce coté reproductible pousse les personnes à faire du code non portable, aux API qui changent et dont le résultat est fortement dépendant des versions des modules de ceci et de cela. Telle et telle version marchent (même s'il y a un bogue et que c'est hyper dépendant des versions), hop je publie -> c'est reproductible par tout lecteur !

      Je ne suis pas sûr de saisir la signification.

      Parce que non ! Ce n'est pas reproductible par tout lecteur parce que justement c'est généralement hyper dépendant des versions et que cela fonctionne uniquement avec telle et telle version.

      Il faut peut-être distinguer le champ d'application. Dans un contexte simulation, pour faire simple, on résout une équation (ou plusieurs) et en général c'est un gros code monolithique ; ou alors il y a un nombre de dépendances résonnables, dans le sens où même si c'est fastidieux, toutes les dépendances peuvent être installés à la main.
      Dans d'autres contextes, ce sont des dizaines de "petits" codes qui interagissent entre eux (workflow ou pipeline) et chaque code a lui-même des dépendances et parfois 2 petits codes dépendent d'une même bibliothèque mais dans une version différente. Et parfois il y a des subtilités difficiles à trouver. Qui n'a pas passé des heures à chercher pourquoi cela fonctionne sur telle machine et pas sur telle autre alors que diantre! tout est pourtant identique… :-)

      Il y a une notion peu mise en avant dans la reproductibilité, c'est la pérennité dans le temps. Comment s'assurer que ce que je publie aujourd'hui et que je ne maintiendrai probablement pas parce que le chercheur n'a pas forcément le temps, que mon code puisse être utilisable dans quelques mois ou années alors que tout un tas de bibliothèques aura évolué.

      Disons qu'aujourd'hui, je dispose d'un code publié et open source qui dépend d'une dizaine de bibliothèques elles aussi open source. Disons que ce code a été écrit il y a 2 ans, il est en Python et dépend de bibliothèques en C, Fortran, C++ (de différentes saveurs) etc. qui ont toutes évoluées et dont l'API est devenu incompatible. Comment faire ?

      • Soit j'essaie de mettre à jour le code Python. Mais quel travail, surtout s'il a été écrit par un autre ou un étudiant, s'il n'est pas ou peu documenté, etc.
      • Soit j'arrive à retrouver toutes les versions utilisées des composants et à tout compiler. Mais encore quel travail.

      Et au final, je ne trouve pas le même résultat que celui dans l'article. Est-ce que l'auteur s'est trompé ? a triché ? Ai-je fait une erreur dans la mise à jour ou est-ce vraiment la bonne version de la bibliothèque ? etc.

      La Science est basée sur la vérification et comment vérifier ?

      En clair, pour qu'il y ait reproductibilité, il faut qu'un déploiement soit possible dans le temps.

      Or aujourd'hui, seule une solution pour la partie déploiement est proposée avec les conteneurs. Mais par exemple les Dockerfiles ne permettent pas une pérennité dans le temps. Par exemple avec Debian, est-ce que les binaires qu'apt-get tirent sont boostrappables ? Comment reconstruire aujourd'hui le même binaire présent dans l'archive en mai 2018 ? etc.

      Pour le dire clairement, à mon sens, les solutions comme Docker ne tendent pas vers une démarche scientifique.


      Pour schématiser, GNU Guix est peut-être l'outil le plus avancé pour la reproductibilité computationnelle en science.

      1.
      Il permet totalement de capturer un environnement avec guix describe. Par exemple :

        bimsb d1cba4a
          repository URL: file:///home/simon/work/guix/bimsb
          branch: master
          commit: d1cba4a2cba1eb6c6c33328fea511b75dfcffe39
        guix ccabb66
          repository URL: https://git.savannah.gnu.org/git/guix.git
          branch: master
          commit: ccabb664ed55d44767e037bb73169be2ecf9449d
      

      guix est le dépôt (channel) "officiel" et bimsb est un dépôt local (qui pourrait aussi être sur une forge) qui me sert à tester (par exemple pour empaquetter des choses en R de BioConductor).

      2.
      Il permet de créer des environnements (comme virtualenv) très facilement. Par exemple :

      guix environment --pure --ad-hoc emacs gcc-toolchain python python-numpy
      

      créé un environnement isolé avec Emacs, GCC, Python et Numpy. Prêt pour travailler ! ;-)

      3.
      Il permet le déploiement facilement avec guix pack. Cela crée un fichier .tar.gz avec tous les binaires. Et il y a même une option pour générer une image Docker. Quelques explications sur le blog de GuixHPC.

      4.
      Il permet de restaurer un état antérieur du dépôt, par exemple au 1er mai 2018, avec guix pull --commit=bb6f94c71e. Maintenant, guix package -i emacs installera Emacs et ses dépendances exactement comme je l'aurais fait ce 1er mai 2018.
      A ma connaissance, les channels ne sont pas encore supportés dans ce mécanisme… Un patch à proposer? :-)

      Évidemment, il y a la possibilité d'utiliser des fichiers manifest. Plus d'explications sur guix pull c'est par là.


      Qu'en est-il du Python ? Car en pratique, c'est souvent les modules Python qui sont "chiants" à packager vu que cela bouge tout le temps (trop souvent) et que les API changent… Avec Nix, mes amis font du conda ou du virtualenv… Bref, c'est pas une super réussite !

      Même si guix import pypi fait une bonne partie du boulot, ce n'est pas forcément facile de suivre. Cela n'a pas à voir avec le gestionnaire de paquet mais avec la communauté. Pas assez de bras, pas de chocolat.

      Si le paquet est déjà dans GNU Guix mais pas à la bonne version, en général il suffit de mettre à jour le numéro de version et le hash upstream, et puis guix build pour vérifier et voilà guix package -i. Les channels facilitent vraiment cela.

      Si le paquet n'est pas dans GNU Guix, cela devient un boulot d'empaquetage. Et même si c'est assez facile avec GNU Guix---une fois passé la barrière psychologique des parenthèses ; je trouve que c'est plus facile que de faire un paquet Conda---cela reste un boulot d'empaquetage avec les trucs pénibles (quelque soit le gestionnaire de paquet).

  • # Plusieurs questions

    Posté par (page perso) . Évalué à 4 (+2/-0).

    1) Quels sont les similitudes et différences avec les technos flatpak ou snap? Genre vous parlez d'environnement indépendants, de conteneurs, etc. C'est du sandboxing avec des permissions, etc.?

    En outre y a-t-il un serveur/dépôt Guix de référence? Quand on fait un guix search ou guix install, ça installe depuis un dépôt unique? Quelqu'un peut créer son propre dépôt? Qui crée les paquets?

    J'aurais bien testé un guix install gimp mais guix ne semble pas dispo sur Fedora. ;-(

    2) À croire que ça s'adresse à moi! 😛

    Supposons que vous êtes un développeur de GIMP : guix environment gimp permet de produire un environnement avec tout ce dont vous avez besoin pour « hacker » GIMP, bien plus rapidement que l’installation manuelle de ses nombreuses dépendances.

    Bon perso j'installe les dépendances de GIMP en quelques minutes et j'ai mon propre outil pour me créer mes environnement de développement (crossroad). Je me crée mes builds de GIMP indépendants en quelques secondes. Mais c'est intéressant de voir des alternatives. On aimerait bien en savoir plus sur ce que fait ce guix environment gimp. Notamment ça semble dire que ça installe aussi toutes les dépendances pour pouvoir compiler GIMP (ce que ne fait pas mon outil). Pour le coup, je veux bien plus de détails. On reste un peu sur sa faim!

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Plusieurs questions

      Posté par . Évalué à 5 (+4/-0).

      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.

      • [^] # Re: Plusieurs questions

        Posté par (page perso) . Évalué à 2 (+0/-0).

        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.

        Dans flatpak, on utilise aussi juste un manifest qui dit où trouver le tarball (avec un checksum pour vérifier) ou bien un dépôt (avec un commit). Si c'est un projet qui utilise un des systèmes de compilation classique (autotools, CMake, meson…), on dit quel système c'est et c'est bon. Éventuellement on peut ajouter des options à appliquer à l'étape de compilation.

        Ça me semble plus proche de guix tel que tu le décris que de docker. :-)

        J'ai cherché un peu dans votre dépôt, le manifeste de GIMP me semble être ça, celui pour flatpak est ça.
        C'est assez similaire! :-)

        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

        Ah ok, donc un guix install recompile le paquet par défaut. C'est pas idéal selon moi pour les utilisateurs finaux. Fournir des binaires devrait être la norme pour un système de paquets (avec bien sûr la possibilité de reconstruire le paquet pour comparaison binaire, reproductibilité, etc. C'est très cool, je dis pas que ça devrait pas être possible, je parle juste point de vue de celui qui veut juste installer GIMP). Je dis ça, j'adore Gentoo (je l'ai utilisé quelques années en distrib principale). Mais de nos jours, je veux juste pas me prendre la tête, faire confiance à des gens et ne recompiler moi-même que les logiciels que j'ai besoin de hacker. Ensuite ce n'est que mon avis et mon conseil (qui vaut ce qu'il vaut, c'est à dire pas forcément grand chose) aussi pour que cette technologie prenne sur le grand public. 😛
        À moins bien sûr que guix est destiné aux développeurs seulement, mais je crois comprendre que vous voulez aussi que ce soit considéré comme un système de paquets pour tous.

        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).

        Ok. C'est intéressant.

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: Plusieurs questions

          Posté par . Évalué à 1 (+0/-0).

          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.

          • [^] # Re: Plusieurs questions

            Posté par (page perso) . Évalué à 3 (+1/-0).

            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.

            Ok.

            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 ?

            C'est un runtime GNOME. À ce jour, y a au moins 3 runtime majeurs: Freedesktop (assez simple avec peu de dépendances), KDE et GNOME (tous deux basés sur le runtime Freedesktop auquel ils ajoutent des dépendances assez classiques dans les logiciels KDE ou GNOME). Ils sont bien sûr défini quelque part:

            • Freedesktop runtime
            • GNOME runtime, je crois que c'est ce lien, à vérifier
            • KDE runtime, ça m'a l'air d'être ici bien que ça m'étonne que ce soit sur github (peut-être un mirroir?)

            Ensuite oui dans un runtime, y a très probablement plus que nécessaire. Ça part évidemment du principe qu'un runtime est utilisé par de multiples applications et permet au contraire de partager la charge (construction des dépendances, téléchargements, espace disque, maintenance et mises à jour, etc.). Mais bien entendu si GIMP est le seul flatpak installé, ça aura l'effet inverse (ça fait installer beaucoup inutilement).

            Qui construit ces images ?

            Les mainteneurs de ces runtimes chez GNOME, KDE, etc.

            Le paquet gimp a l'air de redéfinir tout ce dont il a besoin : gtk2, ibus-gtk2, etc…

            C'est un cas particulier car GIMP utilise encore GTK+2. Il y a encore pas si longtemps, GTK+2 était inclus dans le runtime GNOME, et on avait pas besoin de le définir dans le manifest/compiler dans notre flatpak. Ça a changé avec la version 3.30 du runtime, où ils ont décidé de ne plus inclure la version 2. Ça a du sens si on considère que la plupart des logiciels n'utilise plus GTK+2 qui est vraiment en fin de vie, et donc ça sert à rien de l'avoir par défaut.

            Donc si j'ai deux flatpak qui utilisent les mêmes dépendances, j'ai deux fois les mêmes dépendances ?

            Dans le cas cité, oui, retirer GTK+2 du runtime a un prix. Dès que quelqu'un aura au moins 2 applications basés sur GTK+2, alors il y aura duplication. Je pense personnellement que les mainteneurs du runtime ont retiré GTK+2 un chouille trop tôt, car il y a encore plusieurs applications très répandues basées sur GTK+2 (ne serait-ce que GIMP, qui est tout de même le flatpak le plus téléchargé de tout le dépôt flathub).

            Ensuite c'est toujours une décision difficile à évaluer: quand retirer une vieille dépendance pour essayer de pousser les développeurs d'application à se mettre à jour?

            Mais dans le cas d'une dépendance qui est dans le runtime dont un flatpak dépend, il existe en une unique version pour tous les logiciels basés dessus.

            Notre flatpak stable est ainsi un exemple typique d'un logiciel avec une longue histoire et un peu de dette technique. Ainsi on doit se taper en effet l'ajout de GTK+2 mais aussi d'autres technos liées, comme ibus-gtk2 ou webkitgtk (v2!), du Python 2 (et pygtk 2). Notre flatpak de développement est bien plus simple (GTK+3, Webkit récent, etc. dispos dans le runtime GNOME).

            À 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.

            Pareil pour flatpak. Un runtime est constitué d'un ".Platform" et d'un ".Sdk". Le ".Sdk" comprend en addition les dépendances de compilation et n'est pas téléchargé par les gens qui n'ont que besoin d'exécuter.

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Plusieurs questions

      Posté par . Évalué à 4 (+4/-0).

      En outre y a-t-il un serveur/dépôt Guix de référence?

      Le dépôt officiel est : https://git.savannah.gnu.org/git/guix.git.

      Quand on fait un guix search ou guix install, ça installe depuis un dépôt unique?

      Comparé à aptitude, les commandes aptitude update, aptitude search et aptitude install correspondent à guix pull, guix search et guix install. Cependant, il y a une différence majeure : avec aptitude quand le dépôt central (la liste de deb dans le fichier /etc/apt/source.list) est mis à jour par les mainteneurs de Debian, il n'est quasiment plus possible d'installer un paquet dans une version d'avant cette mise à jour. Sauf erreur de ma part.

      Ce n'est pas le cas avec GNU Guix. Le comportement ressemble plus à celui de Git par exemple. Vous avez une copie locale qui se trouve dans un état, et dans le cas de GNU Guix, cet état est donné par guix describe; par exemple sur ma machine:

      Generation 24   May 16 2019 13:12:59    (current)
        guix 6e633a5
          repository URL: https://git.savannah.gnu.org/git/guix.git
          branch: master
          commit: 6e633a510c53ac3130296bfd5ecf98506b499421

      Connaissant ce état (commit), vous pouvez toujours y revenir (guix pull --commit=), quelque soit l'évolution ou autre mise à jour du dépôt officiel. Pour le dire autrement, une fois qu'un paquet est entré dans le dépôt officiel, il pourra toujours être reconstruit et à l'identique (modulo des changements hardware).

      Dans un état donné, quand vous installez un paquet, par exemple guix install gimp, GNU Guix va regarder dans quel état il se trouve localement, puis il va regarder toutes les dépendences dont il a besoin pour installer Gimp. Et ensuite, il va regarder si tous les binaires correspondants se trouvent sur une des 2 fermes (substitute), si tel est le cas, il les téléchargent pour compléter l'installation. Sinon, il va utiliser le champ source de la définition du paquet pour le construire localement, ainsi que toutes les dépendances dont Gimp aurait besoin (spécifiées dans la définition du paquet).

      Place à la transparence binaire ;-)

      Je me permets de pointer la dernière partie de mon commentaire précédent.

      Qui crée les paquets?

      Les contributeurs du projets. ;-)
      Si par paquet on entend le fichier de description dans un DSL scheme.

      Et si par parquet on entend binaire, c'est tout le monde grâce à la transparence binaire. Actuellement, il y a 2 fermes de constructions mais il y a beaucoup de discussion sur la liste pour avoir une solution distribuée (IPFS, etc.)

      Quelqu'un peut créer son propre dépôt?

      Oui, il y a un mécanisme de channel. Par exemple, si je fais guix describe

      Generation 24   May 16 2019 13:12:59    (current)
        bimsb d1cba4a
          repository URL: file:///home/simon/work/guix/bimsb
          branch: master
          commit: d1cba4a2cba1eb6c6c33328fea511b75dfcffe39
        guix 6e633a5
          repository URL: https://git.savannah.gnu.org/git/guix.git
          branch: master
          commit: 6e633a510c53ac3130296bfd5ecf98506b499421
      

      On voit que j'ai un canal supplémentaire en local (file:/// mais cela pourrait être https:/// etc.).

      Il n'y a qu'un dépôt officiel et la compatibilité avec les canaux n'est pas garantie ou pour le dire autrement la compatibilité du canal est la charge du mainteneur du dit canal. Dans ce canal bimsb, il y a des dépendances à LLVM par exemple mais la version de cette dépendence n'est actuellement pas trackée par le canal donc si le dépôt officiel change, le canal risque de casser. Cependant, le problème se résout en trackant des fichiers manifest. Bref, les outils sont là, il manque peut-être un peu d'UI. :-)

      De toute manière, si c'est un logiciel libre autant pousser dans le dépôt officiel. ;-)

      J'aurais bien testé un guix install gimp mais guix ne semble pas dispo sur Fedora. ;-(

      Comme dit roptat: le mieux reste d'effectuer une installation avec le script d'installation officiel (voir manuel).

      Notamment ça semble dire que ça installe aussi toutes les dépendances pour pouvoir compiler GIMP (ce que ne fait pas mon outil). Pour le coup, je veux bien plus de détails.

      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.

      J'ajouterai même l'option --pure, i.e., guix environment gimp --ad-hoc gimp --pure, qui déactive les variables d'environnement existantes. Il y a aussi les options --container ou --network (voir manuel).

      • [^] # Re: Plusieurs questions

        Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 25/05/19 à 13:25.

        Cependant, il y a une différence majeure : avec aptitude quand le dépôt central (la liste de deb dans le fichier /etc/apt/source.list) est mis à jour par les mainteneurs de Debian, il n'est quasiment plus possible d'installer un paquet dans une version d'avant cette mise à jour. Sauf erreur de ma part.

        Avec flatpak aussi c'est possible. :-)

        $ flatpak remote-info flathub org.gimp.GIMP
        
        GNU Image Manipulation Program - Create images and edit photographs
        
                ID: org.gimp.GIMP
               Ref: app/org.gimp.GIMP/x86_64/stable
              Arch: x86_64
            Branch: stable
           Version: 2.10.10
           License: GPL-3.0+ AND LGPL-3.0+
        Collection: org.flathub.Stable
          Download: 108,5 MB
         Installed: 307,0 MB
           Runtime: org.gnome.Platform/x86_64/3.32
        
               Sdk: org.gnome.Sdk/x86_64/3.32
            Commit: 451758521226112dd7d4e2c4ce7fadaa93f69ce58c2f1afb70fb057db81f5e57
            Parent: 5c8a3dc204a12d4695c5bb7e98ea3b3862d78e52c1cf0f9b021c1dae836ecc95
           Subject: Update to GEGL 0.4.16. (1d8cb1dd)
              Date: 2019-05-09 05:02:52 +0000

        Ce résultat de commande indique le commit actuel du flatpak de GIMP (avec le message de commit, ici "Update to GEGL 0.4.16.") ainsi que le commit parent (le dépôt flathub garde une dizaine de versions précédentes de chaque paquet). Il est possible de remonter dans les vieux commits:

        $ flatpak remote-info flathub org.gimp.GIMP --commit=5c8a3dc204a12d4695c5bb7e98ea3b3862d78e52c1cf0f9b021c1dae836ecc95 
        
        GNU Image Manipulation Program - Create images and edit photographs
        
                ID: org.gimp.GIMP
               Ref: app/org.gimp.GIMP/x86_64/stable
              Arch: x86_64
            Branch: stable
           Version: 2.10.10
           License: GPL-3.0+ AND LGPL-3.0+
        Collection: org.flathub.Stable
          Download: 108,5 MB
         Installed: 306,8 MB
           Runtime: org.gnome.Platform/x86_64/3.32
        
               Sdk: org.gnome.Sdk/x86_64/3.32
            Commit: 5c8a3dc204a12d4695c5bb7e98ea3b3862d78e52c1cf0f9b021c1dae836ecc95
            Parent: fdbcfcbb8e5a4a6f484674208c6bbdf96c6e37fe2df21983a444069e5949276f
           Subject: Build GTK+2 with more patches. (d7578706)
              Date: 2019-04-25 16:46:42 +0000

        Et enfin si je veux, je peux installer une vieille version de GIMP: flatpak update --commit=5c8a3dc204a12d4695c5bb7e98ea3b3862d78e52c1cf0f9b021c1dae836ecc95 org.gimp.GIMP

        Pour info, je veux pas avoir l'air de faire mon lourd à toujours vous comparer avec flatpak. C'est simplement que c'est le seul aussi système de paquet/conteneur que je connais bien. Donc j'essaie juste de comprendre les différences entre guix et flatpak parce que je connais pas grand chose d'autre dans cette catégorie. Bien sûr je pourrais aussi juste tester guix mais bon… comme tous, mon temps est limité, et je peux pas prendre trop de temps maintenant pour suivre de longues instructions d'installation (j'ai bien regardé le lien donné, mais quand j'ai vu la longue série de commande pour l'installation dite binaire, je me suis dit "un autre jour"; désolé!), j'espérais plutôt un truc basique (🛌 lazy mode). Alors j'essaie d'avoir déjà une première idée de base juste en discutant. ;-)

        Et pour le coup, d'ailleurs, je suis toujours pas sûr des différences, hormis que guix recompile localement par défaut avec installations binaires optionnelles (avec flatpak, c'est l'inverse; c'est très facile de recompiler un flatpak: ça se fait en une commande à partir du fichier manifest, mais par défaut on privilégie une installation d'un binaire sur un dépôt).

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

  • # Déploiement HPC

    Posté par (page perso) . Évalué à 2 (+0/-0).

    Concrètement est-que ça peut aider à définir une configuration de nœuds, de serveurs (données, accès…) et à les déployer plus facilement que ce qu'on peut faire avec d'autres distributions ?

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Déploiement HPC

      Posté par . Évalué à 2 (+1/-0).

      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.

      • [^] # Re: Déploiement HPC

        Posté par (page perso) . Évalué à 2 (+0/-0).

        C'est déjà un début de réponse qui permet peut-être de mieux formuler la question : Est-ce que, conformément à ce que laisse entendre l'article tout, absolument tout, est paramétrable depuis l'unique fichier de configuration : configuration réseau, serveurs à démarrer, configuration des serveurs, clefs connus des machines… ?

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

        • [^] # Re: Déploiement HPC

          Posté par . Évalué à 4 (+3/-0).

          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

  • # Le système d'exploitation du futur ?

    Posté par . Évalué à 4 (+4/-0).

    Bravo pour cette dépêche et cet ambitieux projet.

    J'avoue ne pas trop être à la pointe de toutes les technos devops et ne pas non plus être super fan d'admin sys (plus de 15 de linux au quotidien donc à force je sais faire quelques trucs mais je suis plus un dev), donc je ne comprend pas tous les tenants et aboutissant de cette dépêche…

    Néanmoins, j'ai vraiment l'impression que vous avez construit quelque chose d'unique qui répond à pas mal de problématiques actuelles.

    Si je comprends bien, vous avez mis au point une distribution "from scratch" dont le système de paquet est vraiment "révolutionnaire" (dans le sens où il n'a pas d'égal en terme de fonctionnalités), permet notamment d'installer les paquets sans privilèges super utilisateur.

    Ce système est aussi configurable via un langage que vous avez inventé et qui j'imagine après retranscrit ça en fichier de conf compatible ngnix, x11, gnome ou je ne sais quoi ? Si c'est le cas, c'est un truc de fou quand même, mais j'ai sans doute mal compris.

    Il est aussi très facile de créer des environnement de dev virtuel, donc cool pour le développeur que je suis.

    En plus, on peut installer l'environnement de bureau de notre choix, comme toute bonne distribution.

    Franchement, vu comme ça (mais je pense que je rate des trucs et en comprends mal d'autres), ça m'a tout l'air d'être LA distribution du future.

    En tout cas, tout m'a l'air très bien pensé, structuré, avec une conception globale (voir systémique), ce qui est super rare dans le monde libre (c'est plutôt plein de modules hétérogène qui "communiquent" entre eux tant bien que mal).

    Je vais définitivement y regarder de plus près et peut-être l'adoptée si ce n'est pas trop difficile.

    Avec hâte d'en apprendre d'avantage,
    Andréas

    • [^] # Re: Le système d'exploitation du futur ?

      Posté par . Évalué à 2 (+1/-0).

      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 :)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.