GNU Guix version Un‐Point‐Zéro

• # Debian & Yunohost ?

  Posté par Apichat (site web personnel) le 09 mai 2019 à 19:12. Évalué à 3.

  

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

  • [^] # Re: Debian & Yunohost ?

    Posté par ted (site web personnel) le 09 mai 2019 à 19:33. Évalué à 5.

    

    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 roptat le 10 mai 2019 à 15:31. Évalué à 4. Dernière modification le 10 mai 2019 à 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 freem le 10 mai 2019 à 21:18. Évalué à 5.

        

        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 roptat le 11 mai 2019 à 12:18. Évalué à 3.

          

          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 Apichat (site web personnel) le 11 mai 2019 à 13:23. Évalué à 2. Dernière modification le 11 mai 2019 à 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 distributions… actuelles.

• # Heu

  Posté par bunam le 09 mai 2019 à 19:23. Évalué à 8.

  

  Un gestionnaire de packages sous ACID ? ;)

• # Nix et autres

  Posté par Sytoka Modon (site web personnel) le 09 mai 2019 à 20:15. Évalué à 10. Dernière modification le 09 mai 2019 à 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 roptat le 10 mai 2019 à 14:58. Évalué à 10. Dernière modification le 10 mai 2019 à 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 freem le 10 mai 2019 à 21:11. Évalué à 4.

      

      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 roptat le 11 mai 2019 à 12:09. Évalué à 4.

        

        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 Andréas Livet le 29 mai 2019 à 09:47. Évalué à 1.

          

          Impossible d'empaqueter des paquets binaires avec guix : tout doit utiliser des recettes

          Je me permet de rebondir sur cette affirmation que je ne comprends pas.
          Cela signifie-t-il qu'un paquet guix doit forcément être compilé ou empaqueté à partir de source ?

          Pourtant, j'ai vu qu'il est possible d'inclure, par exemple, les modules non libres de linux qui contiennent des blobs binaires.

          L'auteur de cet article parle aussi d'empaqueter des jeux propriétaires.

          Est-ce que j'ai loupé quelque chose ?

          Merci,
          Andréas

    • [^] # Re: Nix et autres

      Posté par barmic le 10 mai 2019 à 22:55. Évalué à 4.

      

      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 bistouille le 11 mai 2019 à 10:38. Évalué à 2.

        

        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 Sytoka Modon (site web personnel) le 12 mai 2019 à 11:39. Évalué à 3. Dernière modification le 12 mai 2019 à 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 wismerhill le 12 mai 2019 à 11:51. Évalué à 2.

            

            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 lolop (site web personnel) le 12 mai 2019 à 17:27. Évalué à 6.

              

              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 dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

              • [^] # Re: Nix et autres

                Posté par wismerhill le 12 mai 2019 à 22:29. Évalué à 2.

                

                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 Sytoka Modon (site web personnel) le 13 mai 2019 à 08:14. Évalué à 3.

                  

                  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 nokomprendo (site web personnel) le 13 mai 2019 à 10:30. Évalué à 2.

                    

                    Salut,
                    XSLT est également homoïconique et permet donc également de mixer codes et données (https://en.wikipedia.org/wiki/Homoiconicity#Implementation_methods). Par contre, je ne sais pas si c'est aussi pratique avec XSLT qu'avec les macro LISP.

      • [^] # Re: Nix et autres

        Posté par zimoun le 13 mai 2019 à 21:09. Évalué à 4.

        

        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 zimoun le 13 mai 2019 à 20:42. Évalué à 5.

    

    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
    

    où 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 Jehan (site web personnel, Mastodon) le 21 mai 2019 à 05:49. Évalué à 4.

  

  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 roptat le 21 mai 2019 à 10:38. Évalué à 5.

    

    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 Jehan (site web personnel, Mastodon) le 25 mai 2019 à 13:04. Évalué à 2.

      

      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 roptat le 25 mai 2019 à 19:14. Évalué à 1.

        

        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 Jehan (site web personnel, Mastodon) le 26 mai 2019 à 10:41. Évalué à 3.

          

          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 zimoun le 27 mai 2019 à 18:58. Évalué à 2.

            

            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.

            Je fais les mêmes remarques que roptat formulées un peu différemment. En espérant que cela aide à mieux cerner les différences. Sachant que je ne suis pas un utilisateur de flatpack.

            ---

            Pour faire simple, flatpack construit sur un runtime/SDK et donc quel est le contrôle sur cela ? Quelle est la version du compilateur C ? Comment cela a-t-il été bootstrappé ?

            Liens bootstrap: dans Guix ou généralement pour le C ou l'effort pour Rust.

            Si je comprends bien, avec les lignes 4-6 de org.gimp.GIMP.json un environnement est tiré qui contient un certain nombre de binaires. Est-ce que dans disons 2 ans, si cet environnement n'est plus disponible en ligne, sera-t-on capable de le reconstruire à l'identique (bit-to-bit) ?

            Si on considère un dockerfile (finalement très similaire à flatpack me semble-t-il), ce fichier/recette utilise disons une image Debian stable, et depuis le 22 juillet 2017, il y a eu 9 mises à jour mineures de la version stable, dont 3 "mises à jour" de la glibc, et 1 mise à jour de GCC, python2.7 et python3.5. Sans compter je ne sais combien de paquets supprimés (voir ici). Sauf erreur de ma part, aujourd'hui, on est incapable de reconstruire from scratch l'image Debian telle qu'elle était disons le 5 mars 2019.

            Par ailleurs, disons que Gimp dépende de Python3.5 qui a besoin de GCC pour être construit; ces 2 sont fournit pour le SDK. Gimp est construit avec ce SDK, disons SDK1. Puis imaginons que GCC recoive un patch de sécurité et Python3.5 est donc reconstruit avec cette "nouvelle" version de GCC, ce qui donne un SDK2. Ce changement est l'objet d'un commit dans le Gitlab de Freedesktop-SDK mais les mainteneurs ne changent pas la version du SDK, cela ne le mérite pas vraiment. Avec la même recette (qui ne dépend pas du commit ni runtime ni SDK mais uniquement de la version et oups! les mainteneurs ne l'ont pas changée), Gimp est maintenant construit avec ce SDK2. Et oh surprise, un bug apparait dans le Gimp-SDK2 et pas le Gimp-SDK1. Tout semble identique en apparence. Mais la chaine de dépendance n'est pas exactement la même. flatpack ne semble pas capable de le détecter. Est-ce exact ?

            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

            Certes. Et en plus il faut aussi remarquer si 2 applications partagent une même dépendance (qui n'est pas dans le runtime), son mode de construction sera spécifiée à 2 endroits bien différents. Ceci a l'avantage d'avoir des bundles/application bien séparés; qui peuvent vivre leur vie chacune de leur côté. Et ceci à l'inconvénient de ne pas être mutualisé et donc de refaire du boulot déjà fait par d'autres.

            Dans GNU Guix, on cherche à mutualiser toutes les briques pour pouvoir les composer. Au plus juste si on peut dire. :-)

            ---

            Finalement, mon impression sans jamais avoir utilisé flatpack est que cela correspond à guix pack sans la machinerie de la reproductibilité bit-à-bit.

  • [^] # Re: Plusieurs questions

    Posté par zimoun le 21 mai 2019 à 18:54. Évalué à 4.

    

    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 Jehan (site web personnel, Mastodon) le 25 mai 2019 à 13:25. Évalué à 3. Dernière modification le 25 mai 2019 à 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 ]

      • [^] # Re: Plusieurs questions

        Posté par zimoun le 26 mai 2019 à 19:05. Évalué à 1.

        

        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é!),

        Hum? Il faut bien lire ;-) et surtout ne pas rater la Note cette page:

        Note: We recommend the use of this shell installer script. The script automates the download, installation, and initial configuration steps described below. It should be run as the root user.

        qui pointe vers ce script d'installation et il n'y a vraiment rien à faire! :-)

        Je ne connais pas bien flatpack. Mais oui il est possible que flatpack a des fonctionnalités similaires, en revanche j'aurais plutôt l'impression que flatpack est une sous-ensemble en terme de possibilités. Bref! A voir.

      • [^] # Re: Plusieurs questions

        Posté par zimoun le 27 mai 2019 à 19:06. Évalué à 1.

        

        Et pour le coup, d'ailleurs, je suis toujours pas sûr des différences

        Il y a suffisamment de différence pour que les gens de chez Nix aient empaqueté flatpack ;-)
        Voir cette page.

        Et GNU Guix hérite des concepts de Nix avec une implémentation différente et parfois d'autres choix techniques.

• # Déploiement HPC

  Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 21 mai 2019 à 08:14. Évalué à 2.

  

  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 roptat le 21 mai 2019 à 11:17. Évalué à 2.

    

    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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 21 mai 2019 à 12:00. Évalué à 2.

      

      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 roptat le 21 mai 2019 à 13:30. Évalué à 4.

        

        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

        • [^] # Re: Déploiement HPC

          Posté par zimoun le 21 mai 2019 à 19:01. Évalué à 2.

          

          Un autre point d'entrée serait peut-être cette discussion.

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

  Posté par Andréas Livet le 23 mai 2019 à 14:50. Évalué à 5.

  

  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 roptat le 25 mai 2019 à 10:57. Évalué à 3.

    

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

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

      Posté par Andréas Livet le 27 mai 2019 à 09:28. Évalué à 1.

      

      Merci pour ces précisions :). J'ai vu dans la dépêche qu'il était question de Nix aussi (que je ne connais pas non plus), tout ça m'a l'air vraiment enthousiasmant !

      Comme je le disais, l'admin sys et le devops c'est pas trop mon dada, mais il faut bien reconnaître qu'il n'y a pas eu, à ma connaissance, d'innovation majeure dans le milieu des distributions linux depuis une quinzaine d'années, si ce n'est plus.

      Bien sûr, tout l'écosystème a énormément évolué mais les fondements restent les mêmes. Certes, snap, flatpak et autre apporte tout de même des choses intéressantes, mais personnellement, je trouve que c'est plus contraignant qu'autre chose quand on utilise déjà une distribution basée sur un autre type de paquet.

      Ca fait 2 (voir 3) méthodes d'installation, de configuration à retenir, un système encore plus hétérogène.

      Là, on sent que le truc à vraiment été bien pensé et qu'il y a une grande cohérence entre tous les éléments, c'est ça qui m'attire.

      Bref, je vais creuser tout ça, encore merci pour la dépêche.

      PS : D'ailleurs, c'est drôle mais j'ai trouvé peu d'articles de vulgarisation qui en parle.

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

      Posté par Andréas Livet le 28 mai 2019 à 23:33. Évalué à 1.

      

      Je continue de me documenter sur Guix.
      J'ai trouvé ce merveilleux article qui m'éclaire un peu plus sur l'intérêt de la démarche et compare avec les solutions existantes.
      https://ambrevar.xyz/guix-advance/

      Néanmoins, il y a des choses que je n'arrive pas à comprendre.

      Par exemple, l'auteur dis qu'à partir du moment ou un paquet fonction, il fonctionnera tout le temps.
      Mais que se passe-t-il si par exemple, pour un jeu (vu qu'il cite les jeux en exemple), je met à jour mon kernel et mesa et ça casse la compatibilité binaire, voir juste rajoute des problèmes liés aux drivers ?

      Mon paquet ne fonctionnera plus non ? Car pour une même machine on continue à n'avoir qu'un seul kernel ?

      Le kernel et d'autres paquets comme le serveur d'affichage sont donc des dépendances transverses qui ne peuvent être isolées dans un environnement.

      C'est là où j'ai du mal à comprendre.

      Aussi, on dit toujours que les système comme snap, flatpak (et guix aussi) sont plus sécurisés car ils exécutent l'application dans un bac à sable dans lequel on choisit ce qu'ils ont droit de faire ou non.

      Mais, un des trucs important pour moi dans les systèmes de paquet classiques c'est justement le fait d'avoir des dépendances partagées. De cette manière, s'il y a une faille dans OpenSSL par exemple, bah la correction est faite à un endroit (le paquet lib-openssl par exemple) et tous les paquets qui en dépendent en bénéficient.
      Avec ces systèmes qui incluent leur propre dépendance, ce n'est plus possible, non ? Chaque paquet doit donc mettre à jour ses dépendances etc. Sans parler de la place en plus que ça prend sur le disque.

      Bref, j'ai encore du mal à comprendre l'intérêt de certaines de ces approches, mais ça m'a tout l'air révolutionnaire sur beaucoup de points.

      Merci,
      Andréas

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

        Posté par roptat le 30 mai 2019 à 21:59. Évalué à 3.

        

        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.

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

          Posté par Andréas Livet le 31 mai 2019 à 20:57. Évalué à 2.

          

          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.

          Merci pour cet éclaircissement, je vois maintenant la puissance du système !

          Dernière question : comment précise-t-on dans le paquet qu'on veut être sur la dernière libc à jour ? J'imagine qu'il y a un système comme avec npm pour Node.js où l'on peut préciser que l'on veut une version fixe exemble (4.7.8) ou alors avoir les derniers correctifs seulement (ex 4.5.x) , ou bien carrément être toujours à la dernière version peu importe le numéro de version ? Ou alors c'est plus complexes que ça ?

          Dans ton exemple, si hello se met à jour quand la libc se met à jour, qu'est ce qui me garanti que mon paquet nouvellement compilé va fonctionner ? Bon là c'est la libc dont l'api est pas souvent mis à jour, mais pour une lib plus "mouvante", ça pourrait être problématique non ? Même si le paquet compile, il se peut qu'il soit cassé, non ?

          Bon en fait, j'ai encore plein d'autres questions :).

          Je trouve Guix vraiment passionnant et j'aimerai creuser un peu plus le concept.

          Là je l'ai installé sur ma distrib (Xubuntu 18.04) et par exemple en installant Scribus, il m'a téléchargé des trucs comme Wayland, Mesa, MariaDB ou PostgreSQL, y a-t-il vraiment toutes ces dépendances dans Scribus ?

          Scribus installé avec Guix se lancera-t-il avec sa propre version de mesa et de Wayland (même si je suis sous X) ? Bien que je pense que ce soit impossible, ça m'a interloqué :).

          Allez, je retourne lire la doc et j'arrête de poser des questions !

          Merci pour tout, plus j'en lis dessus plus je me dis que c'est vraiment l'OS du futur !

          Andréas

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

            Posté par nokomprendo (site web personnel) le 31 mai 2019 à 21:26. Évalué à 2.

            

            Salut,

            Pour info, il y a déjà eu pas mal d'articles à propos de Nix/Nixos/Guix, ici même :
            https://linuxfr.org/tags/nix/public
            https://linuxfr.org/tags/nixos/public
            https://linuxfr.org/tags/guix/public

            Du coup, te voir découvrir Nix/Guix comme l'OS du futur est à la fois encourageant et déprimant…

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

              Posté par Andréas Livet le 02 juin 2019 à 15:29. Évalué à 1.

              

              Oui c'est vrai que c'est pas tout jeune… Mais je ne sais pas parfois, je ne porte pas intérêt à certaines choses et puis d'un coup, on prend plus le temps de lire une dépêche qui a priori ne nous intéresse pas trop (j'avoue, avoir un nouveau gestionnaire de paquet, ou une nouvelle distro, si il ne change pas fondamentalement mon usage de l'OS, ça m'importe peu) et PAF on s'en prend plein la gueule !

              C'est ce que ça m'a fait avec Guix et je me rends compte maintenant de la puissance de l'outil et à quel point il est capable de remplacer avantageusement une pléthore d'autres outils. C'est vraiment impressionnant !

              Je crois que j'ai toujours eu en tête de pouvoir faire ce genre de chose dans ma distrib sans avoir une once d'idée de par où commencer et quelle serait la meilleure méthode pour y arriver.

              Avec Guix, le résultat est bluffant de simplicité si l'on compare à l'ensemble des technos que cela peut remplacer et la complexité qui s'empile dans nos "piles" (c'est bien le mot d'ailleurs !) de développement modernes.

              J'ai toujours vu d'un œil un peu suspect les développements autour de snap, flatpack, Docker et autres. Ça m'a toujours paru bizarre aussi d'avoir des outils pour gérer mes version et mes dépendances en ruby, node, python, ou php. Certains, comme npm, étant en plus assez obscures (qui n'a pas déjà entendu : "essai de supprimer le dossier node_modules et recommence pour voir") et peu configurables (ex : le dossier node_modules est codé en dur…).

              Aujourd'hui, nous avons vraisemblablement (pas encore assez pratiqué pour être sûr) une réponse élégante et unique à tous ces problèmes (et bien d'autres) et c'est tant mieux !

              Je prépare un article en mode "Guix pour remplacer x, y ou z" avec des petits exemples à chaque fois.

              Je le mettrai sur linuxfr si ça intéresse.

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

                Posté par nokomprendo (site web personnel) le 02 juin 2019 à 23:11. Évalué à 2.

                

                Ce n'était pas une critique mais juste une observation, désolé si je me suis mal exprimé. Perso, je suis très content de Nixos mais j'essaie de garder un oeil sur Guix. Du coup, ça m'intéresse beaucoup si tu rédiges des articles dessus.

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

                  Posté par Andréas Livet le 03 juin 2019 à 22:38. Évalué à 1.

                  

                  Ces paquets n'ont pas été séparés en bibliothèques / binaires / etc, mais ils pourraient l'être.

                  Je ne l'ai pas mal pris comme une critique :).

                  Pour mes articles, ça va être vraiment de l'introductif, genre comment je peux remplacer mes outils actuels en utilisant guix. Si tu es déjà habitué à Nixos, tu ne devrais pas apprendre grand chose je pense…

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

                    Posté par Apichat (site web personnel) le 04 juin 2019 à 13:06. Évalué à 1.

                    

                    Ton projet d'article a l'air très intéressant ! J'ai hâte de le lire sur LinuxFr :-)

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

                      Posté par Andréas Livet le 04 juin 2019 à 21:29. Évalué à 1.

                      

                      Je fais ça au fil de l'eau en fonction des besoins et des problèmes que je rencontre.

                      D'ailleurs, sous Xubuntu 18.04, j'ai toujours ces messages d'erreur :

                      bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)

                      J'ai trouvé ces notes qui parlent de ce problème, mais les solutions proposées n'ont pas tout résolu.

                      Bref, je ne sais pas quand ça sera fini.

                      Si ça t'intéresse, j'écris ça sur un pad HackMd : https://pad.lamyne.org/s/HJ5J3SWCN#

                      Sens toi libre de participer :)

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

                        Posté par roptat le 05 juin 2019 à 10:13. Évalué à 1.

                        

                        C'est un bogue qui a déjà été rapporté ici : http://lists.gnu.org/archive/html/help-guix/2019-06/msg00024.html

                        En plus, le nom de ton paramètre de régionalisation devrait terminer par « .UTF-8 » et pas « .utf8 »

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

            Posté par roptat le 03 juin 2019 à 10:31. Évalué à 2.

            

            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.

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

              Posté par Andréas Livet le 03 juin 2019 à 22:36. Évalué à 1.

              

              Merci pour toutes ces précisions.

              A force de me documenter sur guix je commence à comprendre bien son fonctionnement et cela me ravie :).

              Ces paquets n'ont pas été séparés en bibliothèques / binaires / etc, mais ils pourraient l'être.

              Qu'entends tu par là ?

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

                Posté par roptat le 04 juin 2019 à 10:35. Évalué à 2.

                

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

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

                  Posté par Andréas Livet le 04 juin 2019 à 21:25. Évalué à 1.

                  

                  Tu peux aussi regarder avec guix graph

                  Wow impressionnant cet outil :) !

                  Encore merci pour toutes ces précisions.

                  Un paquet peut avoir plusieurs sorties

                  Ah oui j'avais oublié ça, mais quand on télécharge le paquet par défaut, justement ça ne prend pas toutes les sorties, donc ça devrait être bon niveau taille non ?

                  Exemple avec le paquet glib qui ne télécharge pas la doc par défaut. Comme précisé dans la doc.

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

                    Posté par roptat le 05 juin 2019 à 10:11. Évalué à 1.

                    

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

Suivre le flux des commentaires

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