zimoun a écrit 70 commentaires

b/ l'impossibilité de jongler entre les différentes versions des logiciels (allez y, installez firefox 27 et firefox 49 sur un meme linux), là ou windows permet de choisir, et de mettre en cohabitation deux versions sur le meme ordi..
c/ l'abominable dépendance aux.. dépendances.. chaque version de distro est liée à une version des deps, ce qui complique la tache pour changer la version d'un logiciel sans changer le reste.. presque insupportable..

Ceci n'est plus vrai avec GNU Guix ou Nix.

et toujours pas la moindre distro linux from scratch développée par les français, pour des raisons de souveraineté

C'est une vision très pessimiste de la situation. Par exemple GendBuntu ou CLIP OS. Et dans une moindre mesure, GNU Guix (resp. Nix) est partiellement supporté (développé) par des académiques francais (resp. une boîte francaise, à ma connaissance)

à quand un linux ou bsd purement hexagonal?

Ceci ne serait-il pas en contradiction avec votre message d'unification ?

Quelqu'un qui aurait utilisé Guix (distribution) et NixOs, peut nous donner des infos sur l'interet de l'un ou sur l'autre ?

L'intérêt de l'un ou l'autre ? c'est une gestion dans un paradigme fonctionnel et déclaratif. Par exemple, sur ce présent site, il y a cette référence et les commentaires qui vont avec. :-) Sinon, sur ce même site, aussi cela avec les commentaires. Parmi d'autres.

J'ai l'impression que Guix (gestionnaire de paquet) n'apporte finalement rien de particulier par rapport à Nix.

Troll ? :-)

Guix et Nix sont fondés sur les mêmes principes (disons, gestion de paquets dans un paradigme fonctionnel et déclaratif). L'implémentation est différente. Vu de très loin, je dirais que la différence dans l'implémentation est pour Guix une continuité grâce à Scheme (lisp, code is data en quelque sorte), alors que du côté de Nix il y a le langage Nix pour décrire les "dérivations" qui tournent avec du C++ (je crois?).

Guix peut être vu comme une bibliothèque (Scheme) avec laquelle on peut faire la gestion de paquets, décrire un OS dans un DSL Scheme, mais aussi construire dessus, par exemple un moteur expérimental de traitements de flot (/workflow/).

Oui, clairement les principes derrières Nix ou Guix sont vraiment à regarder. Le côté déclaratif et sans état, ca facilite la vie dans l'administration des parcs. Enfin, de mon point de vue. :-) Et même conceptuellement, une même machine peut avoir différentes branches (stable, testing, experimental, etc.) qui coexistent.

Merci pour la mise à jour. Très intéressant.

compiler un langage en utilisant un compilateur écrit dans ce même langage.

Cette approche implique une vision forward et jamais backward.

Et cela ne rendra pas la vie facile aux historiens du futur (s'il y a). Si le compilateur (binaire) est perdu, le compilateur (source) ne pourra plus être compilé. Et si jamais, un programme a besoin de cette version spécifique du compilateur, ce programme ne pourra donc plus être compilé non plus. En imaginant que le matériel est conservé dans un musée, comme « Computer History Museum » par exemple.

Aujourd'hui, la technologie informatique commence à avoir assez d'années derrière elle pour voir de telles situations. Sans chercher bien loin : essayez avec Haskell des années mi-90.

Même si c'est élégant et utiliser ses propres outils permet de les améliorer. :-)

Donc si la sécurité de Redox OS repose sur Rust et l'architecture micro-noyau, cela ne signifie absolument pas qu'il soit plus sécurisé à utiliser que le noyau Linux en l'état actuel.

Tout à fait d'accord. Surtout que Rust n'est pas bien loti pour toutes les attaques type Trusting Trust : le compilo est difficile à bootstrapper, avec une taille de graine non-négligeable et il n'y a pas beaucoup d'implémentations pour faire du Diverse Double Compilation. Entre autres.

En revanche, avoir plusieurs noyaux sur lesquels on pourrait compiler le noyau linux permettrait d'appliquer les principes de DDC sur linux lui-même et donc renforcer sa sécurité. ;-)

C'est bien beau Guix mais moi je vais attendre que ça tourne dans une interface graphique du style Discover ou Pamac pour tester la bête.

Auriez-vous des liens ? Pour voir à quoi ca ressemble. Mon moteur de recherche me renvoie trop de faux-positifs.

Une GUI pour gérer ses paquets et autres, il y a des expérimentations mais encore rien à vraiment recommander.

Et pour les utilisateurs Emacs, il y le front-end Emacs-Guix disponible via guix install emacs-guix. Cependant, il manque un peu d'amour et quelques fonctionnalités sont cassées. Aide bienvenue. :-)

Je me rappelle quelque chose que vous aviez fait ici sur Nix et une petit appli web. Puis j'avais donné en commentaire quelques éléments pour refaire avec Guix. Mais ce n'était pas fini.

Peut-être que ca vaudrait le coup de le faire en tandem avec références croisées dans la doc de Guix et celle de Nix. Concernant Guix, j'imagine où ca pourrait aller. Concernant Nix, je ne connais pas les us et coutumes. :-)

Oui, et c'est valable pour n'importe quel langage. J'ai exactement la même expérience au sujet de R et Python.

(N'importe quel langage c'est un peu excessif. :-) Javascript et Node sont très mal représentés par exemple.)

Chouette ! Merci pour le retour. N'hésitez pas demander. :-)

Très orienté GNU

N'est-ce pas pour un projet GNU? ;-)

C'est pour générer qq stats, un peu de mise en page et implémenter le "cron job".

Ah cool! J'avais un truc pour avoir le nombre de paquets venant de source tar vs Git vs Hg vs SVN vs CVS. Tiens je vais ajouter aussi les hosts. :-)

Merci pour le retour d'utilisation que vous avez fait, ca aide. :-)

Cela arrive-t-il souvent ?

En ce moment, oui cela arrive parce que la ferme de construction patine certaines heures de certains jours. La fréquence est difficile à dire.

Est-ce que le message d'erreur est explicite en ce cas ?

Hélàs, non! C'est un des problèmes de Guix. Les messages d'erreur sont souvent incompréhensibles pour ne pas dire cryptés.

Le mieux est de prendre 5min, de copier/coller dans un email le message, le commit (guix describe) et d'envoyer à help-guix@gnu.org. Je concois que ce que cela implique.

Merci pour le lien. Juste pour info, dans sa présentation, Eelco Dolstra mentionne ces problèmes pour introduire la solution qu'il a implémentée.

Oui, j'ai aussi regardé la vidéo. Et d'ailleurs, les citations que j'ai pointées sont issues de discussions dans la communauté Guix pour savoir justement comment améliorer ou appliquer certaines idées, etc.

Désolé mais je pense que je vais arrêter de commenter. Le concept derrière Guix/Nix est vraiment cool et mérite à être mieux connu. Mais là ça commence à tourner au projet qui aura la plus grosse et j'ai pas envie de participer à ça.

Je suis désolé. Ce n'est pas le but. On demande quelle est la différence avec Nix. Et la principale, c'est le langage. Sachant que c'est mon opinion mais je pense que c'est aussi le point faible de Nix.

Maintenant, si on veut mettre en avant les points faibles de Guix, j'ai aussi une opinion : documentation Scheme éparse, courbe d'apprentissage un peu raide, des lourdeurs dûes à GNU, etc.

Moi aussi je pense que le paradigme fonctionnel pour la gestion des paquets (ou services) mérite d'être mieux connu et diffusé. Peu importe l'outil. :-)

Ma réponse est plus haut. :-)

Désolé si c'est pris comme attaque, ca ne l'était pas du tout.

Peut-être que je me trompe, de ce que je sais, c'est qu'il y a beaucoup plus de paquets dans Nix et la qualité de l'empaquettement est parfois variable. N'étant pas un utilisateur de Nix, non je n'ai pas de stats sur le sujet. Bref, si mes propos froissent certains, je les retire et je présente mes excuses. Oulà, je ne pensais pas autant marcher sur oeufs.

En revanche, je traque les paquets cassés dans Guix donc je peux affirmer que oui c'est très rare, même si ca arrive.

Que la partie core du projet soit un mélange de C, Rust, Python et de Bash ne me pose pas de soucis outre mesure du moment que pour l'empaqueteur final n'a qu'à gérer un fichier nix

Je pense que c'est là qu'il y a une grande différence de philosophie. Guix est en fait une bibliothèque Scheme avec une API. Donc tu peux facilement étendre, modifier, adapter en Scheme. Il y a une continuité entre la partie core et les scripts que tu peux écrire pour transformer tes paquets, utiliser des services externes, etc.

Par exemple dans cette tentative, j'interroge un service externe des fermes de calculs Guix pour lister les paquets non-reproductibles par type de constructeurs (build system, genre CMake, OCaml, Haskell, etc.).

Quelque part, c'est un peu la même philosphie qu'Emacs : c'est le même langage utilisé par le core qui permet aussi de configurer. Cela donne l'extensibilité. Après, certes on adhére ou non car c'est du Lisp. :-)

salut lewo, je ne savais pas que tu moulais ici. :-)

Pour la petite histoire, lewo a fait la partie Nix et j'ai fait la partie Guix. Et on a échangé sur la question.

Merci pour les précisions. Si tu enlèves le "reste du Python et Bash", le fichier sources.json sera produit, mais alors à quoi cela sert-il ?

Personnellement, je pense aussi que le changement de paradigme que Nix a apporté est vraiment novateur. D'ailleurs le paquet Guix vient tout juste d'entrer dans Debian experimental, bientôt apt install guix.

Et je recommande cette présentation à DebConf18 pour les Anglophones. Et aussi Seeing debian through a functional lens par Joey Hess à DebConf14 (je ne trouve plus les archives mais je crois que c'est disponible sur Youtube).

Concernant Nix, j'attends de voir ce que Nix 2.0 va être. ;-)

Au niveau instabilité de GUIX c'est que rapidement dans son utilisation au jour le jour je suis confronté à un échec d'installer un paquet, faire une maj d'un paquet, voir même d'installation de GUIX etc !
Exemple typique : j'ai essayé de faire un 'guix pull' suite à l'annonce de la nouvelle version et ça a cassé au bout de qqs minutes. Si j'essaie demain, cela va peut-être marcher. Et après demain peut-être plus. C'est cela les pbs d'instabilité que j'ai rencontré. Pour moi c'est rédhibitoire, j'ai pas pu passer à GUIX et pourtant j'aurai trop aimé. J'espère que ça évoluera avec le temps.

En tant que contributeur à Guix et en particulier sur la partie release v1.2 (sachant que Guix est une rolling-release), je suis fortement intéressé par vos retours.

Installation de Guix signifiant "Guix distro" via l'installeur, est-ce cela ?
Ou est-ce "Guix on foreign distro" via le script d'installation ?

À quel commit êtiez-vous lorsque vous avez fait guix pull lors de la sortie de la v1.2 ? Je suis vraiment curieux parce que je n'ai pas réussi à casser lors de mes tests.

Par ailleurs, depuis la sortie de la v1.0 (mi-2019), le mécanisme de guix pull est stable et c'est très rare qu'il casse. J'utilise Guix tous les jours pour le travail et le gestionnaire de paquets est en production sur au moins 3 clusters de calculs francais donc je pense que l'on peut dire que Guix est stable. Vraiment je suis très curieux de vos mauvaises expériences, pour résoudre soit des bogues, soit une mauvaise config de votre côté.

En revanche, ce qui est vrai, ce que le temps d'exécution de guix pull et la consommation de ressources (CPU) sont difficiles à prévoir. Un jour ca va et un autre la machine calcule beaucoup plus. Personnellement, j'espère des améliorations pour v1.3 ou v1.4.

Concernant les paquets cassés, c'est très rare. Ca arrive mais beaucoup moins que pour Nix par exemple. En revanche, Guix est victime de son succès (relatif! ;-)) ; la CI passe mal à l'échelle et ne construit pas assez vite les changements. La mesure du problème en terme d'usabilité (tout compiler from scratch n'étant pas possible) est pris en compte et aujourd'hui il y a du travail de fond qui est fait pour résoudre le problème. (Voir Fixing the CI.)

Que reproches-tu à bash à part d'être "d'un autre âge" (au passage bash est moins vieux que scheme).

Pour fixer les idées sur les problèmes, ce projet de Recherche me semble pertinent:

https://www.irif.fr/~treinen/colis/

Et donc tous les bogues qu'ils ont rapportés :

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=colis-shparser;users=treinen@debian.org

Juste sur ces 2 points, je crois que Nix n'est pas un DSL mais un vrai langage turing-complet et que Nixpkgs apporte, en plus d'une logithèque pour Nix, des fonctions de plus haut-niveau pour construire des paquets Python/Haskell/etc, des images Docker, etc.

Voir le commentaire.

Aujourd'hui, le langage Nix a ses propres problèmes, que le langage Guix n'a pas. Voir Nixcon 2020 pour lesdits problèmes : ca et ca, entre autres.

Commentaires biaisés à ces sujets :

I think some of the criticism that applies to Nix does not apply to
Guix: we have ‘guix search’ and ‘guix system search’, we have package
transformation options (which achieve some of what people want to do
with Nixpkgs overlays), source code location shows up in search results,
etc.

https://yhetil.org/guix-devel/86d00evkmr.fsf@gmail.com

Et contrairement à Nix, il y a plus d'abstraction dans le langage Guix:

  For instance, there’s a first-class notion of “package” in Guix (and
 “operating system”, etc.), whereas everything is a “derivation” in Nix.
  Thus Guix can provide a clean UI: you can type “hello@2.10” to refer to
  version 2.10 of Hello (in Nix one usually has to refer to attribute
  sets), there’s a ‘guix search’ command, and so on.
  That’s also what allows for search path handling
  (~/.guix-profile/etc/profile etc.), for grafts (important if you are to
  deliver security updates quickly!), and for “package transformations”:
   https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html

https://yhetil.org/guix-devel/87ft607e1t.fsf@gnu.org

Le workflow est basé sur le emails. Avec ses avantages et ses inconvenients (voir tous les articles LWN sur le sujet).

Le projet Guix a écrit un front-end pour l'antique Debbugs.

Le projet Guix a sa propre CI nommé Cuirass avec des optimisations pour l'infrastructure sur laquelle ca tourne (voir Fixing the CI).

Il y a du bon et mauvais dans cette approche. Quelque part, c'est surtout une histoire de philosophie, plus ou moins tirée de la culture hackeur. M'enfin. :-)

Le fait d'avoir un DSL plutôt qu'un langage complet me parait justement plus approprié : on ne s'étale pas, on va a l'essentiel et y'a pas 36 façon de faire la même chose donc sans doute plus simple en terme de review.

G-Expressions

En effet, dans l'absolu c'est mieux. Dans les faits ça reste minimes à mon sens.

Je vais fournier un contre-exemple peut-être. :-)

Nix et Guix travaillent de concert pour archiver automatiquement dans Software Heritage (SWH). Ca se fait via la génération d'un fichier nommé sources.json qui est ingéré par SWH. Grosso modo, côté Guix c'est en construisant le site web guix.gnu.org que ce fichier est généré et tout le code est là :

website/apps/packages/builder.scm#n96

Rien de plus. Maintenant, comparons avec ce que Nix doit faire :

https://github.com/nix-community/nixpkgs-swh

donc des Nix expressions qui générent des fichiers qui sont ensuite parsés par du Python et le tout recollé avec du Shell.

Donc je ne suis pas du tout convaincu par « y'a pas 36 façon de faire la même chose donc sans doute plus simple en terme de review » et surtout je ne sais pas si on peut dire que c'est minime…

Ça, pour moi, c'est rédhibitoire. Qu'on cloisonne les choses comme dans Debian, ok mais ne rien supporter de non libre, c'est forcément se positionner sur un marché de niche.

Voir mon commentaire là.

C'est là que j'ai un désaccord: je soutiens le fait de distinguer clairement libre et non-libre (comme Debian, où tout ce qui est non-libre est proprement séparé dans non-free), mais avoir un kernel qui refuse de charger les modules non-libres ou une distro qui ne permette pas d'utiliser un repository de softs non-libres me pose clairement un souci : ma liberté c'est aussi celle d'utiliser des logiciels non-libres, par exemple juste pour faire fonctionner mon matériel… (bon après je n'ai jamais utilisé Guix et ses concepts et son approche me semblent extrêmement intéressants. Je base ce commentaire sur ce que j'ai vu de Triquel/gNewSense vs Debian => si je me trombe sur ma compréhension des FSDG n'hésitez pas à répondre)

Dans le vieux débat Debian vs FSF (rms pour être exact), vous êtes un côté de Debian. Très bien, soit! Je ne connais pas l'origine de la brouille qui exclut Debian de la liste des distributions dites libres mais ca sent la brouille personnelle entre Stallman (rms) et un project leader Debian de l'époque. Bref!

(Pour info, je suis contributeur Guix et personnellement je préfère l'organisation pragmatique main, contrib et non-free que le tout ou rien. Très bien aussi, soit!)

Cependant, les FSDG ne définissent pas "votre" liberté mais définissent ce qu'un logiciel doit respecter pour être considérer comme libre (selon lesdits FSDG). La liberté dans votre phrase « ma liberté c'est aussi celle d'utiliser des logiciels non-libres » n'a rien à voir avec les FSDG mais uniquement avec le cadre légal du pays dans lequel vous vivez.

Les projets GNU ne transigent pas. Est-ce un bien ou un mal ? Vaste question philosophique et politique. Question qui se cristallise dans le débat Debian vs FSF.

Maintenant, concernant Guix, rien ne vous empêche techniquement d'utiliser le noyau que vous voulez. Par défaut, le distribution Guix vient avec un noyau linux-libre. Si vous voulez autre chose, oui il faudra mouiller un peu la chemise. Par ailleurs, il existe des canaux (channels, qui sont des dépôts de logiciels) non-libres selon les FSDG, comme Nonguix.

Pour finir, Guix fonctionne au dessus de n'importe quelle distribution. Donc vous pouvez utiliser Debian pour faire fonctionner votre matériel et utiliser Guix pour tout le reste. (C'est ce que je fais principalement.)

Ai-je bon si je pense qu'il y a des similarités avec NixOS?
Lesquelles ?
Quelles sont les différences entre les deux approches ?

En plus des explications de roptat.

Ludo qui a initié le projet Guix était un contributeur de Nix. D'ailleurs Guix = Guile + Nix. Donc la philosophie des 2 projets est celle de la thèse de Eelco Dolstra : appliquer les paradigmes de la programmation fonctionnelle à la gestion de paquets.

Pour faire simple, disons que GNU Guix commence initialement en 2012 par utiliser Scheme à la place des Nix expressions pour générer des dérivations. Le guix-daemon qui est l'élément qui digère ces dérivations est donc repris du nix-daemon.

Depuis 2012, les démons ont évolués. À ma connaissance, aucun des développements du démon côté Nix ont été portés dans le démon de Guix. Et celui de Guix a aussi évolué.

Un marronnier est d'ailleurs la réécriture de ce démon en Scheme. ;-)

Les autres commentaires discutent l'intérêt de Scheme par rapport au "langage Nix+Bash".