Journal Guix : un outil pour les remplacer tous

Posté par  . Licence CC By‑SA.
Étiquettes :
42
18
jan.
2020
Ce journal a été promu en dépêche : Guix : un outil pour les remplacer tous.

Sommaire

Introduction

Je suis tombé très récemment sur une dépêche LinuxFR annonçant la sortie de la version 1.0 du gestionnaire de paquet Gnu Guix et dans la foulée de la distribution GuixSD et j'ai littéralement pris une claque !

Comme me l'a fait remarquer quelqu'un dans les commentaires, le projet n'est pas tout jeune (7 ans de mémoire), mais c'est passé à travers les mailles de mon filet de veille techno tout ce temps.

Je compte bien rattraper le retard car cet outil est tout bonnement hallucinant et je vous invite vraiment à creuser les différentes sources que vous trouverez car, que vous soyez admin sys., devops, développeurs ou simple amateurs de distributions libres, Guix est fait pour vous !

Cette suite d'articles est une tentative, sans doute très imparfaite, de montrer l'ensemble des cas où Guix remplace avantageusement d'autres outils.

Vous allez voir, les champs d'applications sont vastes !

Dans l'histoire de l'informatique, des outils/approches, sont venues totalement bouleverser nos manières de voir les choses et de travailler, Guix en fait partie.

Pourquoi Guix est si génial ?

Qu'est ce qui me permet d'avancer que Guix est si important ?

Parce que Guix résout un certains nombres de problèmes pour lesquels un nombre impressionnant de solutions de contournement ont été mise au point.
Et comment les résout-il ? En traitant le problème à la racine et en proposant une solution radicale, rendant les solutions trouvées jusqu'ici obsolètes ou du moins inutiles.

Ce long article en anglais nous en donne une explication détaillée, mais je vais tâcher de vous résumer ça en quelques paragraphes.

Note : il faut tout de même rappeler que Guix a repris les concepts fondamentaux de Nix (et NixOS) tout en utilisant un langage de programmation généraliste (voir plus bas). On pourrait même considérer que Guix est une sorte de fork de Nix tellement qu'ils sont proches.

Un gestionnaire de paquet révolutionnaire

Guix est avant tout un super gestionnaire de paquet qui règle les principaux problèmes des gestionnaires de paquets classiques.

Et oui, tous les linuxiens savent qu'il est difficile de mettre à jour un logiciel qui dépend d'une librairie dans une version différente de celle de sa distribution. (Cette dépêche LinuxFR résume pas mal la situation actuelle).

En effet, vous serez alors obligé de mettre à jour la dépendance pour tous les logiciels installés sur votre distribution et risquez ainsi de casser certains logiciels.

Regardez aussi la difficulté que les distributions ont à gérer plusieurs versions de certains logiciels en même temps en même temps. Les exemples de ce genre ne manquent pas…

Les solutions proposées jusque-là était soit :

  • Le conservatisme : je reste avec mes paquets peu à jour pendant un certain laps de temps entre deux versions de ma distribution (disons entre 6 mois et 3 ans selon les distributions et le degré de stabilité). C'est le choix de la plupart des distributions Linux.
  • La "rolling release" : je mets à jour continuellement les logiciels et les dépendances de mon système tout en courant un risque de casser quelque chose et d'avoir à le réparer. C'est le choix de distributions comme Gentoo ou encore ArchLinux
  • Un entre deux : c'est le choix par exemple d'Ubuntu avec les ppa. Il s'agit donc de rajouter des dépôts spécifiques à un paquet (compatible avec sa distribution actuelle) afin de mettre celui-ci à jour. Dans la pratique cela marche plutôt bien mais ça oblige les mainteneurs de ppa de créer des paquets pour chaque version d'Ubuntu et donc a une certaine limite.
  • Avoir un système de "virtualisation de paquet" type flatpak ou snap qui permet de s'abstraire des dépendances du système en embarquant ses propres dépendances soit directement dans l'application qu'on souhaite mettre à jour, soit dans des dépendances communes (pour faire court).
  • Distribuer les nouvelles versions des logiciels contenant l'ensemble des dépendances. Le meilleur exemple est AppImage. Ça fonctionne bien mais augmente la taille des logiciels et ne permet pas de partager des dépendances donc offre une moins bonne sécurité.

Guix résout élégamment l'ensemble de ces problématiques en permettant d'avoir à la fois des logiciels à jours et le partage optimum des dépendances communes.
Tout ça en te garantissant que si quelque chose ne fonctionne plus, tu pourras faire un retour en arrière sans une goutte de sueur !

Je vais tâcher de vous expliquer rapidement comment :

  • Tous les paquets sont installés dans un dossier gnu et sont préfixés d'un hash. De cette manière, il ne peut pas y avoir de collision entre deux versions d'un même paquet.
  • Si la version d'une dépendance pour un paquet n'est pas précisée, cela prendra la version la plus récente installée sur le système et il est ainsi possible de partager des dépendances entre paquets.
  • Si jamais un paquet a besoin d'une version spécifique d'une dépendance, il est possible de la préciser, guix la téléchargera au moment de l'installation et le paquet pourra fonctionner sans nuire au fonctionnement du reste du système
  • Comme guix est un gestionnaire de paquet transactionnel, le système ne peut pas être corrompu lorsqu'une mise à jour n'arrive pas au bout.

On a ainsi le meilleur des deux mondes :

  • La possibilité de mettre à jour un paquet de manière indépendante si celui-ci à besoin de dépendances différentes de celles installées sur le système.
  • Le partage d'un maximum de dépendances afin de garantir un niveau de sécurité élevé

En d'autres mots : il est possible d'être constamment à jour (mode rolling release) tout en ayant une stabilité à celle d'une distribution "conservative". Le tout sans avoir à gérer des dépôts spécifiques comme les ppa.

Une distribution hackable

En plus d'être ce génialissime gestionnaire de paquets, Guix est aussi une distribution Gnu/Linux (le Gnu prend ici tout son sens car c'est une distribution soutenue par le projet Gnu) hautement modifiable.

La particularité de cette distribution est qu'elle utilise pour ses fichiers de configuration un langage de programmation fonctionnel nommé Guile qui est une implémentation libre de Scheme, un dérivé de Lisp.

C'est donc très orienté culture Gnu/Emacs. J'avoue ne pas être un fan d'emacs (ni de vim) et n'y connaître à peu près rien en programmation fonctionnelle. Mais, nous verrons dans les articles suivants que ce n'est pas un frein pour utiliser et bidouiller avec Guix.

Cela peut paraître un choix anodin d'utiliser un langage de programmation à la place de fichiers de configurations "statiques" pour une distribution (et même un gestionnaire de paquet), mais en réalité ça change tout.

Et oui, là ou avec des langages dédiés à un domaine (DSL en anglais), on est toujours limité dans nos possibilités de configuration et par l'apprentissage nécessaire d'une nouvelle syntaxe. Guile devient une sorte de langage universel, extrêmement flexible et permettant des niveaux d'abstractions infinis propre à la programmation.

De plus, grâce à des bindings pour les différents logiciels, il est possible de configurer sa machine entièrement en Guile, sans passer directement par les fichiers de configuration de tel ou tel service.

En cela, Guix se rapproche d'outils comme Ansible qui permettent de configurer un système d'exploitation avec une api haut niveau, tout en étant théoriquement plus puissant et flexible du fait de l'utilisation d'un langage de programmation généraliste.

Domaines d'application

Quand je dis que Guix peut remplacer tous les outils, ce n'est pas une métaphore et nous verrons dans les prochains articles des cas pratiques où Guix remplace avantageusement :

  • Le gestionnaire de paquets de votre distribution. Guix s'installe très facilement sur les principales distributions et cohabite merveilleusement bien avec les autres gestionnaires de paquets.
  • Le gestionnaire de paquets et de versions de votre langage de programmation. Plus besoin des environnements virtuels pour python, rvm ou bundler pour ruby, npm pour node.js etc. Guix résolve de manière élégante les problématiques à l'origine de la création de tels outils !
  • Les technologies de conteneurisation tel que Docker. Nous verrons qu'il est en effet possible de créer des équivalents de conteneurs avec des commandes Guix.
  • Les gestionnaires de paquets tel que snap ou flatpak, car Guix permet l'installation de plusieurs versions d'un même logiciel et peut aussi limiter les droits d'utilisation d'une application à l'instar de snap ou flatpak.
  • Les outils d'automatisation de configuration de machine tel que Ansible.
  • Les outils de création de distribution tel que Yocto
  • Et bien entendu, GuixSD peut remplacer votre distribution Linux actuelle !

Bien évidement, tous ces projets ont encore de beaux jours devant eux et sont tous plus avancés et spécifiques que Guix ce qui leur donne une légitimité incontestable.

Néanmoins, Guix pourrait théoriquement être utilisé à la place de chacun d'eux, ce que je tâcherai de démontrer dans les articles qui suivront.

  • # Curieux !

    Posté par  . Évalué à 10.

    Alors là du coup on attend avec impatience les autres articles ;-)

    • [^] # Re: Curieux !

      Posté par  . Évalué à 9.

      Content d'avoir éveillé ta curiosité :).
      Certains articles sont quasiment finis, d'autres en cours de rédaction et d'autres pas encore commencés.
      Je ne sais pas si j'aurai l'énergie d'aller jusqu'au bout de ma démarche, à savoir de décrire toutes les applications potentielles de Guix avec un exemple concret à chaque fois.
      Ça risque de prendre pas mal de temps, mais qui sait ? :)

      • [^] # Re: Curieux !

        Posté par  . Évalué à 5.

        Courage en tout cas car effectivement tu as donné envie ;-)

  • # Très intéressant!

    Posté par  . Évalué à 5.

    J'imagine que c'est en ligne de commandes? Un Gui serait trop génial!
    Hâte de lire la suite!
    Merci!

    • [^] # Re: Très intéressant!

      Posté par  . Évalué à 4.

      Oui, pour l'instant ce sont uniquement des outils en ligne de commande et la configuration du système se fait avec un éditeur de texte… Il y a tout de même un installeur "graphique" (en ligne de commande) pour la distribution mais je ne l'ai pas encore utilisé.

      Donc ça reste des outils réservés à des utilisateurs avancés, voir très avancés pour certains.

      Pour ce qui est du simple gestionnaire de paquet, si vous savez faire un apt install, vous saurez faire un guix install :).

      • [^] # Re: Très intéressant!

        Posté par  . Évalué à 2.

        Il existe une interface graphique (avec emacs) ! C'est emacs-guix. J'ai jamais essayé mais j'ai lu que certain la trouve puissante.

        Peut-être que je pourrai faire mon premier journal dessus ;)

  • # La meilleure fonctionnalité du gestionnaire de paquets

    Posté par  (site web personnel, Mastodon) . Évalué à 8.

    Je trouve que la meilleure fonctionnalité du gestionnaire de paquets (que tu comptes peut-être mentionner dans un prochain journal), c’est qu’il autorise l’installation de paquets par tous les utilisateurs et pas seulement root (ou les comptes autorisés à utiliser sudo).

    Pour un système partagé, c’est un avantage énorme qui simplifie grandement la vie de l’administrateur du système. Au lieu de constamment installer des logiciels à la requête des utilisateurs (avec des conflits de version potentiels si deux utilisateurs veulent le même paquet mais dans des versions différentes), il suffit de leur enseigner une ou deux commandes et ils peuvent se débrouiller tous seuls. Guix garantit que chaque paquet n’est installé qu’une seule fois (si un utilisateur installe un paquet déjà présent, Guix ajoute simplement le chemin du paquet déjà installé au profil de cet utilisateur) et que chaque utilisateur peut avoir les versions qu’il veut.
    L’administrateur n’a plus qu’à faire le ménage régulièrement en demandant à Guix (il y a une commande pour ça) de supprimer les paquets qui sont présents sur le système mais qu’aucun profil utilisateur n’utilise.

    • [^] # Re: La meilleure fonctionnalité du gestionnaire de paquets

      Posté par  . Évalué à 5.

      C'est en effet une fonctionnalité intéressante dont je parlerai dans le prochain article qui porte sur l'usage du gestionnaire de paquet.

      Après, je n'avais pas mis cet élément trop en avant, si tu me le permet, je reprendrai une partie de ton commentaire dans mon prochain article.

      Merci.

    • [^] # Re: La meilleure fonctionnalité du gestionnaire de paquets

      Posté par  (site web personnel) . Évalué à 3.

      C'est surprenant ton histoire de partage de paquets entre utilisateurs:
      - Soit les utilisateurs ont des droits root quand il font l'installation, beurk
      - Soit le second pointe sur le paquet du premier utilisateur? beurk aussi?

      Comment ça fonctionne ?

      • [^] # Re: La meilleure fonctionnalité du gestionnaire de paquets

        Posté par  . Évalué à 4. Dernière modification le 19 janvier 2020 à 13:51.

        Chaque utilisateur installe les paquets dans son propre espace dédié et donc peut avoir un environnement complètement différent du voisin ou du système. Il est même possible d'avoir plusieurs environnements par utilisateur et de se déplacer de l'un à l'autre en faisant un simple : 

        source ${GUIX_PROFILE}/etc/profile

        Où GUIX_PROFILE est le dossier de base du profile. Tous les profiles sont gérés automatiquement par Guix et stockés dans /var/guix/profiles.

        • [^] # Re: La meilleure fonctionnalité du gestionnaire de paquets

          Posté par  (site web personnel) . Évalué à 6.

          Pour compléter un peu la réponse, il y a un dossier /gnu/store où tout est installé, via le programme guix. Si un utilisateur installe un soft, guix crée un dossier dans le store et crée des liens symboliques pour l'utilisateur. Si ensuite un deuxième utilisateur installe également le soft, guix a juste à créer des liens sympoliques, pour ce deuxième utilisateur, vers le dossier déjà créé dans le store.

          Le store n'est accessible que par guix ce qui permet d'avoir des paquets à la fois isolés et partagés. Une présentation intéressante à ce sujet : https://www.cbaines.net/projects/guix/fosdem-2018/presentation/

      • [^] # Re: La meilleure fonctionnalité du gestionnaire de paquets

        Posté par  . Évalué à 5.

        • Soit les utilisateurs ont des droits root quand il font l'installation, beurk

        Il y a un service guix-daemon auquel la commande guix envoi les demandes de compilation et d'installation des paquets. Chaque paquet est compilé dans un chroot pour éviter les effets de bord potentiel.

    • [^] # Re: La meilleure fonctionnalité du gestionnaire de paquets

      Posté par  . Évalué à 1.

      Le problème c'est quand tu n'as pas envie qu'un pirate puisse installer des logiciels sur ton serveur qui puisse l'aider (par exemple gdb, gcc, …).

      J'ai pensé à changer les droits de /run/guix-qqch mais j'ai pas encore essayé.

      Si quelqu'un a une solution élégante, je suis preneur !

      • [^] # Re: La meilleure fonctionnalité du gestionnaire de paquets

        Posté par  (site web personnel) . Évalué à 4.

        J'ai toujours trouvé que cet argument était un faux argument. Le pirate pourra toujours installer les packages localement dans son répertoire. C'est sans doute un poil plus de travail que nix-shell -p gcc -p gdb, mais c'est à la portée de tout pirate qui se respecte.

        • [^] # Re: La meilleure fonctionnalité du gestionnaire de paquets

          Posté par  . Évalué à 1.

          Sauf si tu changes les options de tes points de montage (comme /home) en noexec (sauf celui qui contient /gnu/store/), du coup le seul moyen d'avoir un exécutable c'est par le gestionnaire de paquets.

          Par contre les scripts marchent toujours.

          • [^] # Re: La meilleure fonctionnalité du gestionnaire de paquets

            Posté par  (site web personnel) . Évalué à 3.

            Je ne suis pas expert du domaine et c'est avec plaisir que je me ferais contredire. Mais j'ai l'impression que cette solution est vouée à l'échec car tu aura toujours sur la machine un moyen de lancer quelque chose d'une manière ou d'une autre. Est ce que /tmp sera aussi en noexec ?

            J'ai l'impression que si tu veux ce type d'encapsulation c'est un autre outil qu'il te faut. Type docker ou autre.

            Ceci étant dit, tu peux toujours:

            a) interdire à ton utilisateur d'utiliser nix (le démon peut filtrer les requêtes d'installation basé sur le userid.
            b) Le monter dans un file système virtuel qui ne montre que les chemins autorisés. (Cela revient à virtualiser).

            Bref. J'ai l'impression que la sécurité dans ce contexte est plus complexe que juste "interdire d'installer n'importe quoi".

            • [^] # Re: La meilleure fonctionnalité du gestionnaire de paquets

              Posté par  . Évalué à 1.

              Est ce que /tmp sera aussi en noexec ?

              Avoir /tmp sur un montage séparé (ce qui évite les débordements) avec les options noexec,nosuid,nodev est souvent recommandé.

              Mon système tourne ainsi depuis pas mal de temps. Par contre j'ai déjà eu des programmes qui refusaient de se lancer à cause de ça : ils génèrent des fichiers dans /tmp qui doivent pouvoir être exécutés (ou liés à une exécution). J'ai rencontré par exemple avec des libs (.so), du java (.class) ou du electron (nodejs/chromium).

              Par contre ce n'est généralement pas le cas du /var/tmp (qui ainsi propose une alternative au /tmp, surtout en terme d'espace quand le /tmp est en ramfs).

  • # Super initiative

    Posté par  (site web personnel) . Évalué à 8.

    Merci beaucoup pour ce journal. En tant qu'utilisateur de Nix/NixOS, je suis très intéressé par l'approche de Guix mais je manque de temps pour m'y mettre sérieusement, donc j'attends la suite de tes articles avec impatience.

    Il me semble que Nix possède aussi toutes les fonctionnalités que tu présentes ici, hormis peut-être la limitation des droits d'utilisation d'une application. Peux-tu nous en dire plus ou prévois-tu d'en parler dans tes prochains articles ?

    Sinon, c'est du détail mais je crois que "GuixSD" s'appelle maintenant "Guix System".

    • [^] # Re: Super initiative

      Posté par  . Évalué à 3.

      J'allais poser la question. Nokomprendo m'a presque convaincu de tester Nix, et maintenant voila Guix ?

      Damned :p

    • [^] # Re: Super initiative

      Posté par  (site web personnel) . Évalué à 6.

      Sur le coup je pensais que c'était toi qui avais écrit ce journal, mais non tu n'as pas changé de chapelle. Ça serait vraiment intéressant que tu intervienne pour faire la comparaison avec Nix.

      J'attends avec impatience les prochains épisodes.

      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

      • [^] # Re: Super initiative

        Posté par  (site web personnel) . Évalué à 6.

        Guix et Nix ont une approche assez similaire et c'est surtout cette approche qui est intéressante, à mon avis.

        Donc oui, ce serait bien de comparer régulièrement, pour voir quelles fonctionnalités sont disponibles ou non, et comment on peut utiliser une fonctionnalité donnée avec l'un et autre de ces 2 outils.

        Perso, je suis partant pour donner un coup de main via des dépêches collaboratives, discussions préalables ou autres.

        • [^] # Re: Super initiative

          Posté par  . Évalué à 1.

          NixOs a Home-Manager (qui a fait l’objet d'un journal ici par nokomprendo), je suis jaloux.

          • [^] # Re: Super initiative

            Posté par  . Évalué à 2.

            guix aussi, sous forme de canal et très expérimental : https://framagit.org/tyreunom/guix-home-manager

            Je crois que ça marche assez différemment. Le home-manager de guix remplace ton $HOME par un chemin dans le dépôt, donc il est en lecture-seule, ce qui assure que tes paramètres ne sont pas effacés. Mais ça rend pas ça facile à utiliser au quotidien…

    • [^] # Re: Super initiative

      Posté par  (Mastodon) . Évalué à 3.

      il me semble que guix a commencé en forkant nix non?

      • [^] # Re: Super initiative

        Posté par  . Évalué à 1. Dernière modification le 20 janvier 2020 à 15:23.

        Oui plus ou moins. Ça n'est pas un fork complet, mais le démon de guix provient du démon de nix. Le reste du code scheme reprend les mêmes concepts et pas mal de paquets sont très inspirés de ce que fait nix.

    • [^] # Re: Super initiative

      Posté par  . Évalué à 3.

      Merci pour ton commentaire, j'avoue avoir découvert Nix avec Guix, donc j'ai une mauvaise connaissance de ce projet et des différences entre les deux.

      Sinon, c'est du détail mais je crois que "GuixSD" s'appelle maintenant "Guix System".

      Je n'avais pas vu, j'aimerai éditer mon journal mais je ne sais pas comment faire… c'est le premier journal que j'écris sur linuxfr.

  • # Et si vous allez à FOSDEM 2020...

    Posté par  (site web personnel) . Évalué à 10.

    il y aura des présentations sur Guix :
    https://guix.gnu.org/blog/2020/meet-guix-at-fosdem-2020/
    https://discourse.nixos.org/t/fosdem-2020-in-bruxelles/5491

  • # intéresssé mais

    Posté par  . Évalué à 6.

    Guix me parait sympa mais arrive bien après une version stable de Nix qui présente tous les avantages cités + d'avantages de paquets + 1 plus grande communauté.

    Du coup, j'ai de la peine à comprendre l'intérêt autours de Guix (à part pour les barbus RMSiste) et déplore encore de la fragmentation qui ça engendre.

    • [^] # Re: intéresssé mais

      Posté par  . Évalué à 8.

      C'est une impression que j'ai aussi. Nix semble en effet plus utilisé et Guix a vraiment une très faible communauté et peu de documentation en dehors du manuel officiel (pas de documentation communautaire type wiki).

      Comme je le dis dans l'article, j'ai découvert Nix par le biais de Guix et donc suit resté sur mon premier amour si on veut.

      Du coup, j'ai de la peine à comprendre l'intérêt autours de Guix (à part pour les barbus RMSiste) et déplore encore de la fragmentation qui ça engendre.

      C'est sûr que c'est un truc de barbus RMSiste ! De plus, les outils de développement utilisés (site projet, bug trackers, etc.) sont ceux de gnu et à part pour ceux qui font tout avec emacs, c'est pas ce qu'il y a de plus évident à utiliser.
      Perso, je suis bien plus habitué à un workflow ala Github/Gitlab que je trouve beaucoup plus clair et ouvert, mais c'est sans doute une question de goût.

      C'est en effet déplorable d'avoir une fragmentation sur un créneau de niche… Maintenant Guix semble apporter une énergie différente avec une orientation propre à lui comme l'accent mis sur les build reproductibles, sur la distribution bootstrapable (désolé pour ces anglicismes) et l'utilisation d'un langage de programmation générique.

      Donc, sur le papier Guix me paraît supérieur, peut-être plus pur, mais bon, l'histoire de l'informatique est remplie de projets mieux pensés qui n'ont jamais percés face à un déjà là fonctionnel et massivement utilisé… Est-ce que ça sera le destin de Guix ?

      Pour l'instant Guix m'a l'air très académique et se concentrer sur des problèmes de recherche. Il est toutefois fonctionnel et passionnant alors je continue à creuser :).

      • [^] # Re: intéresssé mais

        Posté par  (site web personnel) . Évalué à 7.

        Perso, je trouve bien qu'il y ait 2 projets sur cette approche de la gestion de packages. Ce n'est pas une grosse fragmentation et ça permet d'apporter un peu de dynamique et d'idées différentes.

        Historiquement, la motivation de Guix était d'utiliser un langage plus classique (scheme au lieu du langage nix) et d'avoir un système de base 100% libre (Nix propose des blobs binaires si on active l'option allowUnfree).
        Aujourd'hui Guix semble attacher une grande importance à la reproductibilité, notamment avec Guix HPC et software heritage. De plus, Guix System utilise le système d'init GNU Sheperd et non Systemd.
        Donc apparemment il y a quand même de quoi occuper deux projets distincts.

        • [^] # Re: intéresssé mais

          Posté par  . Évalué à 5.

          Oui ce sont aussi les différences que j'avais noté avec aussi la volonté d'avoir une distribution uniquement compilable à partir de source notamment avec le projet Mes.

          Les différents commentaires m'ont incités à jeter un œil à Nix et je dois avouer que je suis impressionné ! Je ne pensais pas que le projet était aussi abouti et aussi populaire.

          Je vais tâcher d'en apprendre d'avantage sur Nix et Guix afin d'écrire des articles pertinent au sujet de Guix. Ça ne fait pas si longtemps que cela que je m'intéresse à Guix et je ne dispose pas non plus de beaucoup de temps pour bidouiller avec.

          Et peut-être qu'au final, je choisirai Nix dans mon usage quotidien ?

          En tout cas, je redécouvre tes dépêches sur le sujet et je les trouve passionnantes, merci pour tes efforts !

        • [^] # Re: intéresssé mais

          Posté par  . Évalué à 2.

          Concernant l'argumentaire "guix a un language de programmation complet et pas nix" il y a un parallele avec emacs et vim. emacs proposant un derivé du lisp là ou vim se limite au vimscript.

          On peut donc se poser la question de savoir si c´est un avantage de proposer tant de fonctionnalités là où le besoin est de proposer de l´infrastructure as code, et de ne pas déborder. Ansible, chef et co ne sont pas des languages à part entiére et ce n´est pas sans raison.

          J´ajouterais que la (grande?) nuance entre guix et nix est que le dernier hérite de fonctionalités paresseuses (lazy) qui dans le cadre d´un gestionnaire de dépendance et de paquet semble très bienvenu.

        • [^] # Re: intéresssé mais

          Posté par  (site web personnel) . Évalué à 6. Dernière modification le 19 janvier 2020 à 12:57.

          Historiquement, la motivation de Guix était d'utiliser un langage plus classique (scheme
          au lieu du langage nix)

          C'est vrai, les développeurs scheme, ça court les rues :p

  • # typo

    Posté par  . Évalué à 1.

    je vais tâcher de vous résumer ça en quelques paragraphe S

    • [^] # Re: typo

      Posté par  . Évalué à 1.

      Merci, j'aimerai pouvoir corriger, mais malheureusement je ne vois pas comment éditer mon journal… je ne trouve pas de bouton "éditer", je dois être bigleux !

      • [^] # Re: typo

        Posté par  (Mastodon) . Évalué à 2.

        Il n'y en a pas. N'hésite pas à demander de l'aide à l'équipe de modération, elle est là pour ça : elle a accès au bouton "modifier" et corrigera avec plaisir :)

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: typo

          Posté par  . Évalué à 1.

          Arf, j'imagine que c'est voulu ?! Un peu dommage quand on est comme moi pas très bon en orthographe et dans une volonté d'améliorer l'existant. C'est pareil pour les dépêches ?
          C'est mes débuts de rédaction sur linuxfr donc désolé si je pose des questions évidentes.

          • [^] # Re: typo

            Posté par  (site web personnel) . Évalué à 6. Dernière modification le 19 janvier 2020 à 13:51.

            Le système actuel (cf https://linuxfr.org/aide#aide-authentification ):
            - on peut rééditer pendant quelques minutes ses propres commentaires ;
            - on ne peut pas rééditer ses propres contenus (qu'ils soient modérés a priori comme les dépêches et les sondages, ou a posteriori comme les autres contenus du site).

            Dans l'absolu (et pour des raisons de responsabilité juridique notamment), il y aurait moins de sens à permettre de rééditer les contenus modérés a priori (ou alors il faut revérifier toutes les éditions post-publication).

            En dehors de cette question, de façon externe au site, le greffon Grammalecte pour navigateur permet de nettoyer pas mal de fautes d'orthographe/grammaire typiques avant de soumettre.

            • [^] # Re: typo

              Posté par  . Évalué à 1.

              • on ne peut pas rééditer ses propres contenus (qu'ils soient modérés a priori comme les dépêches et les sondages, ou a posteriori comme les autres contenus du site).

              Dans l'absolu (et pour des raisons de responsabilité juridique notamment), il y aurait moins de sens à permettre de rééditer les contenus modérés a priori (ou alors il faut revérifier toutes les éditions post-publication).

              Pour les utilisateurs du site, mon avis est qu'il est beaucoup plus pertinant de pouvoir éditer ses propres contenus.

              La partie juridique (et également aussi polémque) qui peut en découler peut être facilement résolu en permettant d'acceder aux anciennes versions du contenu edité. Et encore mieux, avec possibilité de l'afficher sous forme de diff! J'aime bien ce qu'à fait GitHub à ce niveau là.

              Mais je comprends que cela soit couteux à développer…

              • [^] # Re: typo

                Posté par  (Mastodon) . Évalué à 4.

                Pour les utilisateurs du site, mon avis est qu'il est beaucoup plus pertinant de pouvoir éditer ses propres contenus.

                Je ne suis pas pour. Suites aux commentaires, le contenu pourrait changer et rendrait les commentaires obsolètes, dur à lire plus tard etc. Ce pourrait être un peu la foire quoi.

                Et puis ça force à se relire avant de poster ;)

                Et pour de menues modifications, pas de pb, l'équipe modo est là (d'ailleurs il n'est pas rare de voir un fil de commentaires uniquement porté sur la forme, tout le monde signale, les modos corrigent).

                En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                • [^] # Re: typo

                  Posté par  (site web personnel, Mastodon) . Évalué à 4.

                  Je suis plutôt favorable et favorable aussi à ce qu'on puisse prévenir directement la modération en cas de demande de correction, de spam ou de tout autre signalement de message. Cela serait plus efficace et limiterait le bruit. On a ça sur Ravelry et c'est pratique (bien que très peu utilisé pour autant que je sache).

                  « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

                  • [^] # Re: typo

                    Posté par  . Évalué à 1.

                    Peut être avoir des notifications lors de guerre d'inutilage/pertinage ?

                    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: typo

                  Posté par  . Évalué à 0.

                  Je ne suis pas pour. Suites aux commentaires, le contenu pourrait changer et rendrait les commentaires obsolètes, dur à lire plus tard etc. Ce pourrait être un peu la foire quoi.

                  D'où vient cette hypothèse si négative ?

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: typo

      Posté par  (site web personnel) . Évalué à 3.

      Corrigé, merci.

  • # mieux que LWN!

    Posté par  . Évalué à 1.

    J'avais bien vu passer le point sur LWN, mais cet article est bien plus clair -ce qui incidemment n'est pas rien!
    Merci!!
    Herve5

    • [^] # Re: mieux que LWN!

      Posté par  . Évalué à 3.

      Le lien que tu pointes porte sur la sortie de la version 3.0 de Guile qui est le langage de programmation utilisé par Guix, mais pas seulement.
      Ce sont bien deux projets distincts bien que maintenu par des personnes en commun notamment Ludovic Courtès qui est un des mainteneur principal des deux projets.

      Je tâche de me mettre à Guile (et par la même occasion à la programmation fonctionnelle), mais il faut du temps pour changer les bonnes vielles habitudes procédurales/objet. Ce qui est marrant c'est que ça arrive au moment où j'ai décidé d'arrêter de programmer professionnellement :).

  • # Langage

    Posté par  . Évalué à 3.

    Et oui, là ou avec des langages dédiés à un domaine (DSL en anglais), on est toujours limité dans nos possibilités de configuration et par l'apprentissage nécessaire d'une nouvelle syntaxe. Guile devient une sorte de langage universel, extrêmement flexible et permettant des niveaux d'abstractions infinis propre à la programmation.

    Les DSL, il faut les apprendre après que guile c'est un langage qui a d'autres usages donc ceux qui me connaissent déjà n'ont pas à l'apprendre. Ok mais qui utilise guile ? Comme tous les scheme, il manque beaucoup de popularité et même comme ça il faut en apprendre les api spécifiques.

    Je n'ai rien contre le lisp, mais je ne suis pas vraiment convaincu par ce paragraphe.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Langage

      Posté par  . Évalué à 1. Dernière modification le 22 janvier 2020 à 13:57.

      D'accord avec toi sur le fait que Guile n'est pas un langage très commun et qu'il nécessite un apprentissage, tout comme les API.

      Ça n'enlève rien au fait qu'un langage de programmation généraliste (aussi "obscure" soit-il) permette d'avoir une flexibilité et des niveaux d'abstractions infinis. C'est le principe même d'un langage de programmation non ?

      Pour dire autrement, un DSL te contraint dans un usage parfois déclaratif (simple fichier de conf) ou impératif mais limité (seul quelques structures de contrôles par exemple) et rend difficile la réutilisation de code, la création de nouveaux concepts ou de nouvelles API.

      Je pourrai donner l'exemple des langage de templating (DSL) comme Jinja qui implémente beaucoup de logique et d'expressions et qui se rapproche pas mal de Python, mais en moins générique. Bah personnellement, j'ai senti les limites de Jinja dans un gros projet même si c'est un langage de templating très complet. Dans la même veine, je trouve ça plus intéressant d'utiliser des langages génériques comme le Go ou le Php comme langage de templating que d'avoir un DSL limité.

      Je pourrai trouver d'autres exemples dans d'autres domaine mais tu vois ce que je veux dire.

      Après, tout le débat va porter sur doit-on ou non aller au delà d'un DSL ? Pour moi, dès qu'une limite est atteinte et qu'elle pose problème pour la personne c'est potentiellement dommage. Idéalement, faudrait donc refaire proprement le code, avec un autre langage, d'autres outils, une autre API etc. Dans la pratique, on finit souvent par faire des hacks pour contourner ces limitations.

      Le fait d'utiliser un langage de programmation générique assure que ces limites ne seront pas atteintes au niveau du langage. Elles pourront être atteintes au niveau de l'API par contre.

      • [^] # Re: Langage

        Posté par  . Évalué à 3.

        Le fait d'utiliser un langage turing complet t'empêche d'établir un certain nombre de propriétés sur le code. Il devient très complexe de faire des validations et va probablement demander à faire de l'analyse statistique qui peut montrer ses limites.

        D'autres parts je connais des DSL qui ne sont pas limitatifs. C'est par eexemple le cas de gradle ou des pipelines jenkins qui permettent d'utiliser tous groovy.

        La notion de niveau d'abstraction dont tu parles qui serait en plus infini ne me paraît pas très clair ou pas très intéressante. L'abstraction n'est pas une fin en soit. En multiplier les couches est un anti patern. Il faut juste que tu puisses exprimer ce dont tu as besoin et je ne suis pas sûr que gérer des paquets demande à ce que chaque empaqueteur pose son propre design.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Langage

          Posté par  . Évalué à 1.

          Le fait d'utiliser un langage turing complet t'empêche d'établir un certain nombre de propriétés sur le code. Il devient très complexe de faire des validations et va probablement demander à faire de l'analyse statistique qui peut montrer ses limites.

          C'est un point pertinent auquel je n'avais pas réfléchis.

          D'autres parts je connais des DSL qui ne sont pas limitatifs. C'est par eexemple le cas de gradle ou des pipelines jenkins qui permettent d'utiliser tous groovy.

          Je n'ai jamais pratiqué jenkins mais si son DSL te permet d'utiliser toutes les fonctionnalité d'un langage générique, alors ça me paraît une très bonne option.

          La notion de niveau d'abstraction dont tu parles qui serait en plus infini ne me paraît pas très clair ou pas très intéressante. L'abstraction n'est pas une fin en soit. En multiplier les couches est un anti patern. Il faut juste que tu puisses exprimer ce dont tu as besoin et je ne suis pas sûr que gérer des paquets demande à ce que chaque empaqueteur pose son propre design.

          C'était un peu le sens de ma remarque sur l'intérêt de donner autant de possibilités à l'utilisateur. En effet, cela peut vite devenir un fouillis pas possible sans vérification de la communauté et sans respect de certaines règles, qui sont obligatoires dans un DSL.
          Il y a donc un risque d'arriver à ce que certaines plateformes "à plugin", comme par exemple WordPress, subissent, à savoir une multiplication des plugins de très piètre qualité.
          Disons que cela hausse le degré de compétence requis pour quiconque souhaite développer des fonctionnalités avancées.
          Ce que je trouve intéressant c'est d'avoir justement cette possibilité.

          Concernant les niveaux d'abstractions, en soit je suis d'accord. Ce que je voulais dire par là c'est que l'on peut par exemple configurer sa machine avec une api unifiée.
          Cette api va derrière modifier tout un environnement hétérogènes (fichiers de conf) et il a fallu un certain niveau d'abstraction pour en arriver là. Le fait de pouvoir choisir ce niveau d'abstraction sans avoir à rajouter des éléments au DSL me paraît important.

          Pour reprendre l'exemple de la configuration de la machine, on peut imaginer avoir une API qui permette de configurer chaque moindre logiciel ou service avec une granularité fine, puis des API beaucoup plus haut niveau genre createLampServer, createMailServer qui vous configure quasi automatiquement toute une machine avec les logiciels qui vont bien.

  • # Un bon résumé

    Posté par  . Évalué à 1.

    Super dépêche. Cela me paraît une assez bonne introduction.

    J’utilise GNU Guix System (anciennement GuixSD) depuis près d’un an et demi sur mon ordinateur portable (unique système d’exploitation). J’aime bien.

    Pour ceux qui voudraient avoir un retour d’expérience, j’ai écrit un article sur le sujet.

    Mais si vous voulez en savoir plus sur GNU Guix en lui-même, il y a eu de très bons articles publiés dans GNU/Linux Magazine :
    - Gestion de paquets sûre et flexible avec GNU Guix ;
    - Python : un environnement vraiment isolé avec GNU Guix.

Suivre le flux des commentaires

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