Andréas Livet a écrit 254 commentaires

Je trouve ça bizarre aussi de mettre juste un petit encart concernant la méthode conseillée et de détaillé longuement ce que fait le script sans que l'utilisateur doivent lui même le faire… Il faudrait selon moi une documentation à part pour cela.

sur Arch Linux les paquets sont à jour

Arch est en effet très à jour donc l'apport de Guix sera totalement négligeable de ce côté là. Nix bénéficie quant à lui de beaucoup plus de paquets et souvent bien à jour.

Quel serait l'intérêt d'utiliser Guix sur Arch Linux ?

L'intérêt peut se trouver dans l'utilisation des environnements virtuels si tu fais du dev par exemple. Je pense écrire un article sur ce sujet prochainement.

Après, sans vouloir rentrer dans un débat stérile, j'aime beaucoup l'idée de distribution à intégration continue (et oui je me sers des traductions du wiki que je ne connaissais pas, merci barmic) et c'est ce qui me plaisait dans Arch.

Mais, j'ai vu plusieurs fois un de mes collègues passer parfois des heures entières à tenter de réparer des configs de sa machine qui ne fonctionnait plus après une mise à jour. Et pourtant, c'était un vétéran de Linux !

Pour moi, Nix (puis par la suite Guix) à proposer un concept vraiment novateur et rend possible le fait d'avoir une distribution à intégration continue fiable ou facile à gérer en cas de pépins.

Théoriquement, je trouve donc ces 2 distributions supérieures à Arch. Dans la pratique Arch a sans doute une plus grosse communauté, donc plus facile de trouver des ressources de l'aide, etc.

Après, c'est aussi la curiosité de découvrir un fonctionnement de distribution tout autre.

Merci pour le partage, je vais lire ça de suite !

Le code assembleur lisible avec quoi est-ce qu'on le lit ?

Bah tu le lis sur une autre distribution. Je pense qu'on peut quand même faire confiance dans le fait qu'un éditeur de texte, même compilé sur une distribution non amorçable, reste fiable dans sa manière de retranscrire du texte à l'écran :).

Après, ce n'était peut-être pas le sens de ta remarque ?

Sinon amorçable c'est bien

Merci, je l'avais sur le bout de la langue des doigts !

Pour l'instant il n'y a pas de version officielle de Guix pour ARM.

Après, certains s'amusent à porter la distribution sur ARM mais cela nécessite un gros effort et faut donc avoir beaucoup de temps (et des petites compétences en Scheme) je pense. En ces temps de confinement c'est jouable sans enfant :D !

Réponse courte : Non.

Réponse longue : A part le fait que Guix soit un projet Gnu (et donc a priori pas trop enclin à utiliser LLVM), les développeur de Guix sont en train de réaliser la prouesse - qui a ma connaissance n'a encore jamais été faite pour une distribution, de pouvoir compliler Guix uniquement à partir de source.

Un article du blog explique cette démarche et une vidéo du FOSDEM.

C'est vraiment passionnant ! En gros, ils ont codé un petit compilateur en assembleur qui est capable de compiler Gnu Mes qui est un mini compilateur C et interpréteur Scheme permettant ensuite de compiler une ancienne version de GCC et lire les scripts Scheme, qui permet ensuite de compiler d'autres versions de GCC et ainsi démarrer (bootstraper en franglais) la compilation de la distro.

Il y a donc une grosse dépendance à tout l'outillage GCC et je ne pense pas que cet effort soit reproduit pour LLVM…

Le projet demande à vérifier la signature gpg du fichier que tu as téléchargé. C'est le truc dont on parle.

Je crois qu'il y a confusion entre ce que fait le script d'installation (en effet, il vérifie la signature gpg du binaire) et les instructions pour lancer ce script.

Cette page d'installation ne précise pas comment télécharger ou vérifier le script d'installation, juste de le lancer en root.

Oui c'est vrai avec un hash a taille fixe c'est la même en fait…

Ici en l'occurrence le projet upstream propose quelque chose qui a l'air propre c'est dommage de l'outrepasser.

Je ne comprends pas cette phrase, à quoi faites vous référence ? Comme je l'ai dis dans un commentaire précédent, le projet conseille justement une installation en root via le script mentionné dans l'article, donc en quoi est-ce plus propre ?

J'avoue avoir un peu succombé à cette "mode" car je trouve pratique le fait de pouvoir installer un logiciel en une ligne et sans forcément avoir le fichier d'installation sur son disque après.

Avant, je faisais exactement comme tu l'as montré mais comme je ne faisais pas plus de vérifications de ça, j'ai trouvé que ça revenait au même de passer par des pipes.

Perso, je préfère engager du temps sur des projets comme apt/nix (guix, je découvre donc j'ai pas encore d'avis) plutôt que perdre mon temps avec snap/flatpak/appimage.

Je suis de ton avis, j'ai vraiment du mal à comprendre cet engouement autour de snap et flatpak, ce que je vois c'est que les projets galèrent à créer des paquets sur ce genre de technologies. Je mettrai peut-être AppImage à part vu qu'il s'agit d'un format qui embarque tous les dépendances et donc plutôt axé portabilité et diffusion "rapide", contrairement aux deux autres qui se placent comme des gestionnaires de paquets universels et sécurisés.
Pour moi, Guix (ou Nix) sont bien plus universels et sécurisés que snap ou flatpak, mais bon je ne suis pas du tout spécialiste.

Le nom Guix est sans doute mieux choisi que Nix car y'a pas d'embrouille pour les moteurs de recherche : point pour Guix.

C'est pas faux, par contre il y a très peu de ressources sur Guix…

Le logo de Nix est une pure merveille d'ingéniosité : des lambdas qui forment un flocon de neige alors que Guix, je cherche toujours (une tête de gnou probablement) : point pour Nix

Les goûts et les couleurs… perso je vois pas trop en quoi le logo de Nix est si génial, je le trouve plutôt banal, mais je n'avais pas compris que c'était des lambdas :). Je trouve celui de Guix assez rafraîchissant pour un logo Gnu.

les moteurs de recherche web des paquets : point pour Nix même si lent (la requète ajax qui rappatri un gros json avec tous les paquets est juste horrible)

Non mais c'est clair que c'est assez honteux, même l'outil de gestion de projet (savannah) est assez "archaïque" pour les personnes habituées à la méthode GitHub/GitLab…

Merci pour le commentaire.

Même constat que pour Nix : pourquoi diable avoir mis les hash avant les noms…

J'ai vu sur une vidéo, un des dev Guix a sans doute une modif dans son bash.rc ou autre qui supprime les hash avant les noms, beaucoup plus lisible !

C'est vrai que c'est pas très commode pour le tri alphabétique et pour la lecture des noms de paquets… la raison est sans doute pragmatique : le hash fait toujours la même taille, le logiciel récupère les premiers caractères du dossier et sait ainsi à quel paquet il a affaire. Dans l'autre sens c'est plus difficile de récupérer le hash.

Je pense que le dossier store est plus lourd que les dépendances gérées par apt du fait de la non mutualisation de certaines dépendances.

Chez moi, mon répertoire /gnu/store fait 10.7Go avec quelques "gros" logiciels installés comme scribus et libreoffice entre autre.

Citation de la page d'installation officielle :

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.

Ce que fais ma commande télécharge ce script et l'exécute en tant que super utilisateur, c'est ce qui est conseillé non ?

Si par hasard, je me suis trompé ou que vous voyez une méthode plus sécurisée pour faire cela (je ne suis vraiment pas un pro de la sécurité), je veux bien que vous postiez la bonne méthode et on demandera une correction de la dépêche.

Merci

Maintenant, on n'est pas à un concours de l'article le plus long ou le plus commenté; le but est plutôt de partager des infos donc tous les articles qui vont dans ce sens sont intéressants.

C'est sûr, mais j'ai été interpellé par le peu de réactions sur un article traitant d'un sujet similaire.

Petite question concernant le déploiement de machine virtuelle, tu écris :

À l’issue du déploiement, une adresse IP est fournie et permet d’accèder à notre serveur sur la machine virtuelle.

Si je comprends bien, la commande nixops create créer un fichier de machine virtuel compatible virtual box et nixops deploy la déploie automatiquement ?
La VM est donc automatiquement rajoutée aux machines gérées par Virtual Box ou c'est une étape qui n'est pas montrée ?

Pour l'adresse IP, n'y a-t-il pas moyen de la préciser ?

Désolé si mes questions sont simples ou si la réponse est dans la doc, pas pris le temps de regarder.

Merci

Merci pour cette dépêche complète et limpide !

Je salue tout le travail accompli pour illustrer ton propos, c'est rare de voir autant d'efforts déployés pour introduire une technologie.

Par ailleurs, je suis assez étonné de voir que mon article sur Guix plutôt "minable" en termes de contenu ait créé autant d’engouement (de beaux débats de fond et parfois du troll) alors que le tien n’a aucun commentaire…

Quoiqu'il en soit, ça me donne encore plus envie de tester Nix et NixOS, les concepts sont les mêmes qu'avec Guix et la communauté à l'air bien plus grande (plus de paquets notamment). De plus, la possibilité d'installer un noyau linux avec drivers non libres semble plus évidente qu'avec Guix System, ce qui d'un point de vue de Gnu est mal, mais d'un point de vue pragmatique est plutôt une bonne chose.

Encore bravo pour tout ce travail !

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.

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.

Merci pour ce retour, carrément partant pour écrire la suite à plusieurs !

Je vais poster ce que j'ai déjà dans l'espace de rédaction.

Je vois que le sujet intéresse du monde et cela me dépasse un peu :).

J'avais commencé la rédaction de ces articles justement pour apprendre Guix, mais je suis loin d'être un spécialiste !

Bref, ça va être chouette de pouvoir profiter de l'expertise d'autre membres de linuxfr.

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

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.

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 !

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 !

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