Guix : un outil pour les remplacer tous

Posté par Andréas Livet le 19 janvier 2020 à 17:38. Édité par palm123, Benoît Sibaud et Davy Defaud. Modéré par Ysabeau 🧶. Licence CC By‑SA.

Étiquettes :

jan.

2020

« GNU Guix est un gestionnaire de paquets pour GNU. Il est inspiré par le gestionnaire de paquets Nix, son principal apport est l’Interface de programmation GNU Guile et sa spécialisation dans la fourniture de logiciels libres. Au mardi 31 décembre 2019, GNU Guix permet d’installer 11 174 logiciels. » (Wikipédia)

Dans le journal dont est tirée cette dépêche, Andréas Livet nous raconte sa découverte de Guix.

Sommaire

Introduction
Pourquoi Guix est si génial ?
- Un gestionnaire de paquets révolutionnaire
- Une distribution hackable
Domaines d’application
Compléments tirés des commentaires du journal

Introduction

Je (Andréas Livet auteur du journal à l’origine de cette dépêche) suis tombé très récemment sur une dépêche LinuxFr.org « GNU Guix version Un‑Point‑Zéro » annonçant la sortie de la version 1.0 du gestionnaire de paquets 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 (sept ans, de mémoire), mais c’est passé à travers les mailles de mon filet de veille technologique 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 administrateurs système, devops, développeurs ou simples 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 ou des approches sont venus 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 certain nombre de problèmes pour lesquels un nombre impressionnant de solutions de contournement ont été mises 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 divergence de Nix tellement ils sont proches.

Un gestionnaire de paquets révolutionnaire

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

Eh oui, tous les linuxiens savent qu’il est difficile de mettre à jour un logiciel qui dépend d’une bibliothèque dans une version différente de celle de sa distribution. (Cette dépêche LinuxFr.org résume pas mal la situation actuelle).

En effet, il est alors nécessaire de mettre à jour la dépendance pour tous les logiciels installés sur votre distribution, et vous 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. Les exemples de ce genre ne manquent pas…

Les solutions proposées jusque‑là étaient 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 Arch Linux ;
un entre deux : c’est le choix par exemple d’Ubuntu avec les PPA (Personal Package Archives) ; 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 cela oblige les mainteneurs de PPA à créer des paquets pour chaque version d’Ubuntu et donc a une certaine limite ;
avoir un système de « virtualisation de paquets » de 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 à jour et le partage optimum des dépendances communes. Tout cela en te garantissant que si quelque chose ne fonctionne plus, on pourra 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, la version la plus récente installée sur le système est utilisée 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 paquets 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 a 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 la stabilité 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 fonctionnelle 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 Guix et le bidouiller.

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

Eh oui, là où 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’abstraction infinis propres à la programmation.

De plus, grâce à des liaisons (bindings) avec 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 de haut niveau, tout en étant théoriquement plus puissants et flexibles 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ésout de manière élégante les problématiques à l’origine de la création de tels outils !
les technologies de conteneurisation telles 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 tels qu’Ansible ;
les outils de création de distributions tels que Yocto ;
et, bien entendu, GuixSD peut remplacer votre distribution GNU/Linux actuelle !

Bien évidemment, 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.

Compléments tirés des commentaires du journal

Andréas Livet : Guix regroupe 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 installateur « graphique » (en ligne de commande) pour la distribution, mais je ne l’ai pas encore utilisé. Il s’agit donc encore d’outils réservés à des utilisateurs avancés, voire très avancés pour certains. Pour ce qui est du simple gestionnaire de paquets, si vous savez faire un apt install, vous saurez faire un guix install :).

Guillawme rajoute qu’un autre point important 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 versions 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 tout 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. »

nokomprendo ajoute : « 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 deux outils. »

La comparaison porte aussi sur les communautés respectives de chaque solution et leurs choix techniques.

nokomprendo précise : « Perso, je trouve bien qu’il y ait deux projets sur cette approche de la gestion de paquets. 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 l’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’initialisation GNU Shepherd et non systemd. Donc, apparemment, il y a quand même de quoi occuper deux projets distincts. »

nokomprendo annonce des présentations sur Guix et Nix au FOSDEM 2020 : voir Meet Guix at FOSDEM et FOSDEM 2020 in Bruxelles.

Aller plus loin

Journal à l’origine de la dépêche (251 clics)

# Mal connaître sa distribution

Posté par ʭ ☯ le 19 janvier 2020 à 18:13. Évalué à 10. Dernière modification le 19 janvier 2020 à 18:15.
C'est fou ce que l'on connaît mal nos distributions. Toutes les distributions permettent déjà d'avoir plusieurs versions des librairies. Exemple pour la librairie PNG dans ma machine :
- lib64png16_16-1.6.37-1.mga7
- lib64png12_0-1.2.59-1.mga7
Mais les empaqueteurs essayent toujours d'utiliser la dernière version, car cela apporte les dernières fonctionnalités, et améliore la sécurité en n'exposant pas des vieilles versions avec des tous de sécurité connus.

Le vrai problème est que ce travail est exponentiel : si je propose 2 versions d'un logiciel, avec 2 versions de librairies, je dois faire deux fois plus de travail lors de la découverte d'un trou de sécurité. Et si les développeurs du logiciel disent "on ne propose de patch que pour la dernière version" je me retrouve à faire du rétroportage de code, ce qui n'est plus un simple empaquetage.

Donc s'il n'y a pas 3 versions d'un logiciel dans votre distribution, c'est parce qu'on manque de petites mains pour maintenir les rétroportages, et qu'on privilégie la sécurité à la diversité.

⚓ À g'Auch TOUTE! http://afdgauch.online.fr
- [^] # Re: Mal connaître sa distribution
  
  Posté par barmic 🦦 le 19 janvier 2020 à 19:24. Évalué à 4. Dernière modification le 19 janvier 2020 à 19:24.
  
  Donc s'il n'y a pas 3 versions d'un logiciel dans votre distribution, c'est parce qu'on manque de petites mains pour maintenir les rétroportages, et qu'on privilégie la sécurité à la diversité.
  
  Il y a une autre raison. Une distribution c'est le choix d'un ensemble d'éléments qui se veulent cohérents. Il y a une sélection, une organisation et des choix qui sont effectués. Cela permet entre autre de gérer la maintenance de la distribution. Une distribution peut par exemple choisir de n'avoir que libressl plutôt qu'openssl et c'est important car elle sait qu'elle n'a pas à se tenir à jour sur 5 ou 6 bibliothèques tls. L'objectif n'est pas de prendre et d'exécuter tout le code du monde. Ce n'est pas en principe le boulot d'une distribution qui se doit de faire des choix.
  
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
- [^] # Re: Mal connaître sa distribution
  
  Posté par roptat le 19 janvier 2020 à 19:44. Évalué à 6.
  
  Je crois qu'il y a un malentendu. Guix en général ne propose qu'une version de chaque logiciel qu'il propose (sauf par exemple gcc, python et d'autres outils du même genre). En revanche, Guix te permet de créer tes propres paquets (tu me diras, comme n'importe quelle distro, et tu auras raison). Je ne connais pas ta distribution, mais en général, les paquets sont installés dans des répertoires globaux (/usr, /lib, /bin, etc) ce qui fait que tu ne peux pas avoir un libpng.so qui soit en version 1.2 et un autre libpng.so en version 1.6 (tu auras libpng.so et libpng12.so par exemple). Comme guix installe chaque paquet séparément, tu peux avoir plusieurs variantes de libpng.so qui cohabitent.
  
  Pour éviter qu'un logiciel compilé avec libpng 1.6 ne trouve libpng 1.2 (et plante), Guix s'assure que ce logiciel ne pourra trouver que la version 1.6 en lui passant le chemin direct vers la bibliothèque (et pas juste son nom) via le mécanisme de RPath pour les fichiers exécutables ELF par exemple. De cette manière, je peux installer une visionneuse avec libpng 1.6 et un autre logiciel avec libpng 1.2. Les deux vivent ensemble sans problème. Je pourrais aussi avoir un libpng 1.6 avec la prise en charge du format apng, et un autre libpng 1.6 sans cette prise en charge par exemple, utilisés par des logiciels différents (bon là c'est tiré par les cheveux).
  
  Un autre exemple, c'est la mise à jour : si j'ai deux logiciels qui dépendent d'une bibliothèque et qu'il y a un changement d'API dans la nouvelle version de cette bibliothèque. La nouvelle version du premier premier prend ça en compte et n'est plus compatible avec l'ancienne bibliothèque, alors que le deuxième n'a pas sortie de version compatible. Sur une distribution classique, tu as un problème : soit tu ne mets rien à jour (et alors tu ne peux pas profiter des dernière nouveautés du premier logiciel) soit tu mets à jour en cassant le deuxième logiciel. Comme les logiciels pointent vers les bibliothèques exactes avec lesquelles ils ont été compilés, dans Guix tu peux mettre à jour le premier logiciel, et il utilisera la nouvelle version de la bibliothèque, alors que le deuxième logiciel continuera d'utiliser l'ancienne.
  
  C'est ce que j'essaye d'expliquer dans la première partie de cette présentation : https://replay.jres.org/videos/watch/c77b3a44-b75f-4c10-9f39-8fb55ae096d7 (et hop, de l'auto-promotion :p). Je suis pas forcément très doué pour ça, mais avec des images, ça devrait aider un peu à la compréhension :)
  - [^] # Re: Mal connaître sa distribution
    
    Posté par ʭ ☯ le 19 janvier 2020 à 22:46. Évalué à 9.
    
    Je crois qu'il y a un malentendu. […] ce qui fait que tu ne peux pas avoir un libpng.so qui soit en version 1.2 et un autre libpng.so en version 1.6 (tu auras libpng.so et libpng12.so par exemple.
    
    Pas de malentendu, mais encore une méconnaissance : les logiciels compilés ne cherchent jamais une librairie sans son numéro de version. Donc le mécanisme que tu décris est dans toutes les distributions…
    ldd /usr/bin/gwenview | grep png libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f7217555000)
    Ce sont les bibliothèques de développement qui fournissent le fichier non versionné :
    urpmf libpng.so lib64png-devel:/usr/lib64/libpng.so
    
    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
    - [^] # Re: Mal connaître sa distribution
      
      Posté par nokomprendo (site web personnel) le 19 janvier 2020 à 23:49. Évalué à 4.
      
      Il y a effectivement un malentendu. Dans ton exemple, gwenview est linké sur /lib64/libpng16.so.16, qui semble correspondre à la version 1.6.37. Du coup, tu auras un soucis si tu as également besoin de la version 1.6.36 ou même d'une version 1.6.37 compilée avec d'autres options.
      - [^] # Re: Mal connaître sa distribution
        
        Posté par gnumdk (site web personnel) le 20 janvier 2020 à 09:05. Évalué à 7.
        
        Sauf que ça n'a aucun intérêt car la 1.6.36 et la 1.6.37 sont compatibles au niveau ABI.
        
        Perso, le journal sur GUIX m'a fait joué avec l'original (NixOS) ce week end. Sur le papier ça semble bien, j'aime bien l'idée de la recette de cuisine à la puppet (même si très voir trop basique en comparaison de Puppet/Ansible & co).
        
        Mais par contre, c'est d'une lenteur pour installer des paquets! Le passage de stable vers unstable a mis trois plombe et mon sentiment général que que NixOS, c'est l'inverse d'ArchLinux, ne gardons rien de simple!
        
        Bref, c'est surement une bonne distrib mais beaucoup trop complexe à mon gout.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par nokomprendo (site web personnel) le 20 janvier 2020 à 11:04. Évalué à 5.
        
        Sauf que ça n'a aucun intérêt car la 1.6.36 et la 1.6.37 sont compatibles au niveau ABI.
        
        Aucun intérêt pour qui ? Perso, j'utilise régulièrement la lib OpenCV et il y a tellement d'options de compilation qu'il est très classique d'avoir à recompiler sa propre version, ou même ses versions, selon les besoins des différents projets. Il y a quelques années, la version d'OpenCV packagée dans Debian était compilée avec un BLAS générique; résultat un code C++ utilisant ce paquet était plus lent qu'un script python utilisant la version Pypi d'OpenCV (qui, elle, était compilée avec un BLAS optimisé). Donc oui, il y a bien un intérêt.
        
        Le passage de stable vers unstable a mis trois plombe
        
        Passer du canal stable au canal unstable, ça correspond à un dist-upgrade sous Debian. Ca fait longtemps que je n'ai pas fait de dist-upgrade mais je ne crois pas que ça se fasse en 5 min. Ceci dit le changement de canal sous Nixos prend essentiellement du temps de téléchargement et essentiellement la première fois qu'on utilise un canal. Switcher entre les canaux déjà installés est ensuite beaucoup plus rapide.
        
        NixOS, c'est l'inverse d'ArchLinux, ne gardons rien de simple
        
        Je suis d'accord que NixOS est assez compliqué à apprendre. Par contre, je ne suis pas du tout d'accord sur la comparaison avec ArchLinux, du moins pour du dev, où chaque update risque de casser les projets. Avec NixOS, tu peux fixer complètement l'environnement de chaque projet, les modifier, les rollbacker, les partager, etc et ça juste marche.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par ʭ ☯ le 20 janvier 2020 à 11:40. Évalué à 1.
        
        la version d'OpenCV packagée dans Debian était compilée avec un BLAS générique; résultat un code C++ utilisant ce paquet était plus lent qu'un script python utilisant la version Pypi d'OpenCV (qui, elle, était compilée avec un BLAS optimisé). Donc oui, il y a bien un intérêt.
        
        Il y a un intérêt à changer les choix de Debian pour tout ton système, pas d'intérêt d'avoir 3 fois la même version d'une librairie. D'ailleurs, je pense que NixOS ne permet pas directement ce que tu indiques : 3 compilations différentes d'une même version de libraire pour 3 logiciels consommateurs différents.
        
        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 20 janvier 2020 à 13:10. Évalué à 4. Dernière modification le 20 janvier 2020 à 13:11.
        
        Je ne connais pas NixOS, uniquement un petit peu Guix.
        
        La première chose est que Guix signifie :
        
        une gestionnaire de paquets
        
        une distribution utilisant ce gestionnaire de paquets
        
        Vous pouvez utiliser le gestionnaire de paquets sur n'importe quelle distribution GNU/Linux et il n'y aura aucun conflit. Et pour le déinstaller, il suffit de faire guix package --list-profiles pour faire le ménage dans les liens symboliques, quelques autres petites choses dans le cache e.g., ~/.cache/guix puis simplement rm -fr /gnu/ /var/guix.
        
        La deuxième chose est que Guix (originellement Nix) est un changement de paradigme. Un gestionnaire de paquets comme APT peut être vu comme "impératif" tandis que Guix comme "fonctionnel". Tout ca avec des très gros guillemets ! :-) Alors il y a choses que se font facilement avec l'un et difficilement avec l'autre, et vice-versa.
        
        Concrètement, que signifie 3 fois la même version ? Est-ce que la version libfoo-1.2.3 compilé par GCC 7 ou GCC 8 ou autre signifie la même version pour vous ?
        
        Pour finir, que signifie pour vous 3 compilations différentes d'une même version pour 3 logiciels consommateurs différents ?
        
        Par exemple, Guix a la notion de "transformations" de paquet qui permet dans une certaine mesure de ré-écrire le graphe des dépendances. Cette entrée pourrait vous intéresser :
        https://hpc.guix.info/blog/2018/01/pre-built-binaries-vs-performance/
        
        Par ailleurs, Guix a aussi la notion d'héritage (inherit) pour un paquet. Donc vous pouvez prendre la bibliothèque libfoo-1.2.3 avec ses options de compilations et les changer, et uniquement elles.
        
        En revanche, il n'est pas possible aujourd'hui de "propager" ces options de compilations, un peu comme le fait Gentoo avec USER flag. Mais il y a des discussions récentes pour savoir qu'est-ce qu'il serait souhaitable. Voir tout le thread là :
        https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00026.html
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par freem le 20 janvier 2020 à 22:46. Évalué à 2.
        
        La deuxième chose est que Guix (originellement Nix) est un changement de paradigme. Un gestionnaire de paquets comme APT peut être vu comme "impératif" tandis que Guix comme "fonctionnel". Tout ca avec des très gros guillemets ! :-)
        
        À ce stade la, on est loin des guillemets…
        
        DPKG (nope, APT n'est pas un gestionnaire de paquets, il se contente de télécharger un paquet et ses dépendances) est majoritairement "déclaratif" c'est à dire basé sur un simple fichier de configuration.
        
        Pour rappel, un .deb, c'est une archive cpio qui contiens 3 fichiers: 1 fichier texte qui décris la version, 1 tarball avec les méta-données qui sont toutes, à ma connaissance, sous forme de texte déclaratif (ini-style) à l'exception des scripts pré/post rm/inst, et une tarball contenant les données.
        Je sais que la compression est supportée, mais je ne sais exactement comment.
        
        Quelques paquets utilisent en effet des scripts pré/post rm/inst, mais à mes yeux et rapport a ce que j'ai subi, c'est soit une erreur politique (gérer automatiquement les services plutôt que les faire gérer par l'install/suppression de paquets qui seraient en conflits) soit un workaround pour ces foutus sgbdr qui sont incapables de fournir des données binaires (faut reconstruire a partir d'un dump sql… long, lourd et pénible).
        À noter qu'au taf, j'ai opté pour la création de paquets qui activent les services qu'on écrit, et qui sont parfois en conflit. Ben, c'est vachement plus simple qu'écrire les scripts pré/post inst/rm, et s'il nous venais l'envie d'utiliser systemd plutôt que runit, il n'y aurait pas besoin de refaire (et donc réinstaller) les paquets contenant les binaires: les paquets de services sont, en effet, à part.
        
        Concrètement, que signifie 3 fois la même version ? Est-ce que la version libfoo-1.2.3 compilé par GCC 7 ou GCC 8 ou autre signifie la même version pour vous ?
        
        Tout dépend de si GCC 7 et GCC 8 ont la même ABI. Si c'est pas le cas, c'est en effet le job de distro de gérer.
        Mais bon, hé, vraiment, mauvais exemple ici (a moins que tu aies un bug causé par une incompat entre ces compilos?), tu aurais dû parler de GCC vs Clang, ou de la glibc vs musl. La réponse aurait été que, majoritairement, la différence de libc se sens, la différence de compilo C, non. Ah, je précise bien, de compilo C, pour les autres langages, c'est plus compliqué, d'où le modèle «hour-glass» pour construire des libs portables en C++, notamment.
        
        Pour info, sache que, il y a 8 ans (quand j'étais sous win), on étais capables d'avoir des ABI compatibles sous windows entre GCC et VisualC++. Et ça fait longtemps que j'ai pas eu de problèmes parce que j'utilise un compilo différent de celui du système (pas sûr d'en avoir déjà eu)? Dans une certaine mesure, même utiliser une libc différente m'est pas mal transparent.
        
        Par ailleurs, Guix a aussi la notion d'héritage (inherit) pour un paquet.
        
        L'équivalent d'un méta-paquet qui dépend au choix d'un ou plusieurs paquets, ou l'équivalent d'un paquet qui fournit un paquet virtuel? Non, parce que bon, Debian implémente ça depuis que je m'en sers, soit au moins 10 ans.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par nokomprendo (site web personnel) le 20 janvier 2020 à 23:07. Évalué à 4.
        
        Le paradigme fonctionnel ne se résume pas à adopter un style déclaratif, il permet également de faire de la composition. Avec Guix/Nix, une description de paquet est en fait une fonction qui ajoute à l'environnement courant le soft correspondant. Cette fonction peut prendre des paramètres, par exemple les descriptions de paquet du compilateur ou des dépendances, des options de compilations à activer ou non, etc. Il est donc très facile de régler un paquet et de répercuter les modifications sur tout l'environnement logiciel, si besoin. Ou encore de prendre une description et d'en calculer un environnement/conteneur/vm minimal pour la faire tourner.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par barmic 🦦 le 21 janvier 2020 à 00:26. Évalué à 2.
        
        C'est ce que permet apt-build. La composition n'est pas un concept uniquement fonctionnel tu l'a aussi pour en orienté objet et du effectivement fait par des méta paquets.
        
        Guix/nix font probablement toutes ces choses mieux (l'inverse serais dommage), ils ne les ont pas forcément inventé et les gens n'ont pas attendu nix pour proposer des solutions
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 21 janvier 2020 à 00:51. Évalué à 2.
        
        Guix/nix font probablement toutes ces choses mieux (l'inverse serais dommage), ils ne les ont pas forcément inventé et les gens n'ont pas attendu nix pour proposer des solutions
        
        Oui tout à fait. D'ailleurs, les principes de Nix ont été posés dans une thèse et on sait tous qu'une thèse c'est beaucoup d'existant et un soupcon de nouveauté/originalité. ;-)
        
        https://nixos.org/~eelco/pubs/phd-thesis.pdf
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par nokomprendo (site web personnel) le 21 janvier 2020 à 11:38. Évalué à 1.
        
        C'est ce que permet apt-build.
        
        Avec Guix/Nix, je peux écrire un simple fichier dans un projet perso pour définir complètement ses dépendances, sa construction, comment l'intégrer dans la logithèque, modifier n'importe quelle option au plus profond de la logithèque et en recalculant automatiquement et uniquement les paquets impactés, etc. puis l'installer comme un programme classique, en construire un environnement virtuel, une image docker, une vm… Je ne connais pas apt-build, ça permet vraiment de faire tout ça ?
        
        Guix/nix font probablement toutes ces choses mieux (l'inverse serais dommage), ils ne les ont pas forcément inventé et les gens n'ont pas attendu nix pour proposer des solutions
        
        On n'est pas à un concours pour le prix Nobel mais pour le coup, il me semble que oui : appliquer les principes de programmation fonctionnelle à la gestion de paquets n'avait jamais été fait avant les débuts de Nix en 2003. Mais je peux me tromper, si tu as des références à ce sujet, ça m'intéresse.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 21 janvier 2020 à 12:58. Évalué à 3.
        
        Guix/nix font probablement toutes ces choses mieux (l'inverse serais dommage), ils ne les ont pas forcément inventé et les gens n'ont pas attendu nix pour proposer des solutions
        
        On n'est pas à un concours pour le prix Nobel mais pour le coup, il me semble que oui : appliquer les principes de programmation fonctionnelle à la gestion de paquets n'avait jamais été fait avant les débuts de Nix en 2003. Mais je peux me tromper, si tu as des références à ce sujet, ça m'intéresse.
        
        Concernant Debian, il y a eu cette présentation à DebConf14.
        
        http://debconf14-video.debian.net/video/311/seeing-debian-through-a-functional-lens
        
        Toujours est-il que Nix—et Guix=Guile+Nix ;-)—est à mon avis un changement de paradigme dans la gestion des paquets. Comme tout paradigme différent, tout n'est pas orthogonal. :-)
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par nokomprendo (site web personnel) le 21 janvier 2020 à 14:45. Évalué à 3.
        
        Merci, je vais regarder. Ca a l'air intéressant et en plus il y a un gars en kilt trop classe qui pose une question à la fin.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 21 janvier 2020 à 00:26. Évalué à 4.
        
        DPKG (nope, APT n'est pas un gestionnaire de paquets, il se contente de télécharger un paquet et ses dépendances) est majoritairement "déclaratif" c'est à dire basé sur un simple fichier de configuration.
        
        Peut-être que je comprends mal ce qu'est APT. J'avais cru comprendre que c'était Advanced Packaging Tools donc une suite d'outils pour manipuler les paquets Debian. D'après ma compréhension, dpkg est un outil qui gére à proprement parler le .deb mais il ne gère pas la résolution de conflit qui est faite par apt ou aptitude, non ?
        
        C'était des gros guillemets parce que l'analogie ne vaut qu'une analogie. :-)
        
        Debian se comporte de manière procédurale (état séquentiel) et mutable. Par exemple, tu n'as aucune garantie que la séquence apt update, apt install foo, apt remove bar donne le même état final que apt update, apt remove bar, apt install foo.
        
        Dans Guix, le résultat sera le même. Enfin normalement. ;-)
        
        Pour le dire autrement, dans Debian, il y a des effets de bord qui sont contrôlés dans un style impératif. Dans Guix, les effets de bord sont contrôlés dans un style fonctionnel.
        
        https://guix.gnu.org/manual/en/html_node/The-Store-Monad.html#The-Store-Monad
        
        À noter qu'au taf, j'ai opté pour la création de paquets qui activent les services qu'on écrit,
        
        Concernant les services, c'est presque la même histoire que pour les paquets. ;-)
        
        Concrètement, que signifie 3 fois la même version ? Est-ce que la version libfoo-1.2.3 compilé par GCC 7 ou GCC 8 ou autre signifie la même version pour vous ?
        
        Tout dépend de si GCC 7 et GCC 8 ont la même ABI. Si c'est pas le cas, c'est en effet le job de distro de gérer.
        Mais bon, hé, vraiment, mauvais exemple ici (a moins que tu aies un bug causé par une incompat entre ces compilos?),
        
        Considérons ceci :
        
        #include <stdio.h> int main() { printf("Bonjour\n"); return 1; }
        
        Et compilons avec GCC 6 et GCC 7 :
        
        gcc-6 hello.c -o hello-6 gcc-7 hello.c -o hello-7
        
        Evidemment ./hello-6 et ./hello-7 produisent la même sortie. Mais ce ne sont pas les mêmes binaires :
        
        md5sum hello-{6,7} e1c353671a5c2737e819cf586503865c hello-6 608d3e055a4f7eb124ebc43747152fd7 hello-7
        
        Doit-on considérer que le même code source compilé par 2 compilateurs est la même version ou non ? Qu'est-ce qu'une même version ? Code source identique ? Binaire identique ? Résultat identique ?
        
        Et là commence les ennuis. ;-) Parce que GCC 6 est lui même un binaire donc produit par un autre binaire.
        
        C'est le problème du yahourt. Pour produire un yahourt (binaire), il faut un yahourt (compilateur) et du lait (source). Et donc quel est le yahourt initial ? Et si ce yahourt initial change, va-t-on produire le même yahourt final ?
        
        Ce n'est pas un problème d'ABI. C'est un problème de qu'est-ce qui définit la version d'un logiciel ? Une fois définie, on peut parler de même version ou version différente.
        
        Par ailleurs, Guix a aussi la notion d'héritage (inherit) pour un paquet.
        
        L'équivalent d'un méta-paquet qui dépend au choix d'un ou plusieurs paquets, ou l'équivalent d'un paquet qui fournit un paquet virtuel? Non, parce que bon, Debian implémente ça depuis que je m'en sers, soit au moins 10 ans.
        
        Ce n'est pas un méta-paquet. Du moins de ce que je comprends.
        
        Un méta-paquet permet de résoudre un problème de nommage ou il permet d'installer une collection de paquets.
        
        Un paquet utilisant inherit utilise la recette du paquet qu'il hérite et la modifie.
        
        Par exemple
        
        la définition longue de GnuPG (v2.2.19)
        
        https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnupg.scm#n247
        
        GnuPG v2.0.30 l'utilise et change des choses
        
        https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnupg.scm#n320
        
        et GnuPG v1 l'utilise aussi
        
        https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnupg.scm#n366
        
        Les 3 paquets sont fonctionnels en soi. Il n'y a pas de "coquilles vides". C'est juste que la définition du paquet gnupg-2 hérite de la définition du paquet gnupg.
        
        J'ai peut-être mal compris ce qu'était un méta-paquet.
        
        Toujours est-il que Guix utilise plein de choses existantes ailleurs. Une partie de l'originalité est de les rassembler de manière cohérente.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par freem le 22 janvier 2020 à 10:03. Évalué à 3.
        
        J'avais cru comprendre que c'était Advanced Packaging Tools donc une suite d'outils pour manipuler les paquets Debian.
        
        Dans la pratique, je dirais que ça manipule surtout le repo. En gros, ça regarde dans une BDD texte les dépendances d'un paquet, ça les Dl, et ensuite ça invoque un gros "dpkg -i $pkgs". Ça peut aussi potentiellement faire de la collecte de déchets, aussi.
        
        Mais le vrai boulot, in fine, c'est à dire dépaqueter le cadeau, exécuter les scripts pré/post rm/inst dans le bon ordre, déplacer les fichiers, mettre à jour (ou pas) les fichiers de conf… tout ça, c'est dpkg. Donc pour moi, c'est bien dpkg le gestionnaire, apt, apt-*, aptitude, synaptics (j'ai toujours un doute sur son nom à lui)… eux, c'est juste des frontaux.
        
        Concernant les services, c'est presque la même histoire que pour les paquets. ;-)
        
        Je me doute, mais sur ce point, ce que je voulais dire, c'est que j'ai opté pour une politique différente que celle que debian opte. Autrement dit: installer un paquet contenant un daemon ne l'active pas automatiquement. D'un autre côté, je me base sur runit, donc c'est trivial, alors que Debian s'est longtemps basée sur rc.d, j'imagine que ça joue.
        Je reconnaît que ce point était hors sujet pour le coup :)
        
        Doit-on considérer que le même code source compilé par 2 compilateurs est la même version ou non ? Qu'est-ce qu'une même version ? Code source identique ? Binaire identique ? Résultat identique ?
        
        Je ne vois pas vraiment l'intérêt pour un utilisateur d'avoir, au niveau système, plusieurs build d'un programme avec plusieurs compilos… pour un développeur, ok, mais un programmeur fera de toute façon ses tests dans un dossier local.
        
        Le seul moment ou je vois un problème potentiellement posé par la compilation d'un même source avec les mêmes options de build par un compilateur différent, c'est pour une bibliothèque dont l'ABI peut changer. Et ce problème est habituellement contourné par les bibliothèques elles-mêmes quand elles sont bien foutues (par exemple en utilisant pimpl).
        
        Les 3 paquets sont fonctionnels en soi. Il n'y a pas de "coquilles vides". C'est juste que la définition du paquet gnupg-2 hérite de la définition du paquet gnupg.
        
        J'ai peut-être mal compris ce qu'était un méta-paquet.
        
        Je pense plutôt que c'est moi qui ne comprend pas à quoi sert ton héritage ni (hum… c'est chiant en vrai de faire un ou inclusif en langage parlé…) comment ça marche.
        Pour le coup, ça me ferait plutôt penser aux «recommends» du format deb: tu peux installer un paquet parce qu'il améliorera le paquet courant, mais c'est pas obligatoire.
        Sauf que du coup, c'est pas de l'héritage tel qu'entendu en POO, vu que dans ce cas ça serait une dépendance forte, donc un «depends».
        
        Par contre, effectivement un meta-paquet c'est un paquet vide, qui se compose juste d'une série de dépendances d'un type ou d'un autre (debian utilise surtout des dépendances fortes, mais rien n'empêcherais un méta-paquet qui bannit).
        
        Toujours est-il que Guix utilise plein de choses existantes ailleurs. Une partie de l'originalité est de les rassembler de manière cohérente.
        
        Je trouve honnêtement le concept intéressant, mais pour moi sa plus grosse et principale force, c'est le fait qu'il semblerait invalider complètement une suite d'actions si une installation échoue, et ça, dpkg ne sait pas le faire, ses frontaux non plus.
        Par contre, je me demande si la raison est vraiment le fait que nix/guix soient fonctionnels, justement.
        En soit, le format des paquets deb devrais largement permettre sans trop de hacks un gestionnaire de paquet bien plus puissant (parallélisé, avec rollbacks, install en mode user), mais l'histoire est là.
        
        Enfin, l'histoire ainsi que le fait que le noyau linux (ou sont-ce extX les coupables?) ne permette pas, à ma connaissance, de réellement verrouiller un fichier: flock() places advisory locks only; given suitable permissions on a file, a process is free to ignore the use of flock() and perform I/O on the file. me font me demander d'à quel point nix/guix peuvent réellement garantir quoique ce soit.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 22 janvier 2020 à 16:09. Évalué à 2.
        
        Doit-on considérer que le même code source compilé par 2 compilateurs est la même version ou non ? Qu'est-ce qu'une même version ? Code source identique ? Binaire identique ? Résultat identique ?
        
        Je ne vois pas vraiment l'intérêt pour un utilisateur d'avoir, au niveau système, plusieurs build d'un programme avec plusieurs compilos… pour un développeur, ok, mais un programmeur fera de toute façon ses tests dans un dossier local.
        
        L'intérêt est double:
        
        sécurité
        
        science computationnelle reproductible.
        
        Le seul moment ou je vois un problème potentiellement posé par la compilation d'un même source avec les mêmes options de build par un compilateur différent, c'est pour une bibliothèque dont l'ABI peut changer. Et ce problème est habituellement contourné par les bibliothèques elles-mêmes quand elles sont bien foutues (par exemple en utilisant pimpl).
        
        De ce que je comprends, vous définissez même par: code source identique et résultat identique.
        
        C'est le cas d'usage le plus courant. Mais il faut garder en tête :
        
        Que vous n'avez aucune garantie que le compilateur n'a pas introduit de code frauduleux. C'est ce que l'on appelle la Trusting Trust attaque et le problème du bootstrapp.
        
        Le papier par Ken Thompson himself :
        https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
        
        Et une vidéo en anglais très didactique—il faut faire abstraction de l'application (bitcoin) car cela s'applique à n'importe quel programme compilé :
        https://www.youtube.com/watch?v=I2iShmUTEl8
        
        En calcul scientifique, si on dit que l'on fait de la Science, cela signifie que l'on doit contrôler au maximum son environnement d'exécution pour trouver l'origine des différences et donc contrôler les erreurs—ou disons plutôt fournir une preuve de confiance.
        
        Une vidéo expliquant les enjeux se trouve là :
        https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible
        
        Je pense plutôt que c'est moi qui ne comprend pas à quoi sert ton héritage ni (hum… c'est chiant en vrai de faire un ou inclusif en langage parlé…) comment ça marche.
        
        Cela permet de ré-écrire partiellement la recette d'une paquet.
        
        Je trouve honnêtement le concept intéressant, mais pour moi sa plus grosse et principale force, c'est le fait qu'il semblerait invalider complètement une suite d'actions si une installation échoue, et ça, dpkg ne sait pas le faire, ses frontaux non plus.
        
        Je crois que RPM est capable de faire du transactionnel.
        
        Par contre, je me demande si la raison est vraiment le fait que nix/guix soient fonctionnels, justement.
        
        Le fait d'être "fonctionnel" rend les transactions faciles à implémenter. Ou disons plus facile que dans les approches "classiques" de gestion de paquets.
        
        Enfin, l'histoire ainsi que le fait que le noyau linux (ou sont-ce extX les coupables?) ne permette pas, à ma connaissance, de réellement verrouiller un fichier
        
        Oui, c'est légitime comme question. Et à ma connaissance il n'y a pas encore vraiment de réponse par manque d'observation.
        
        Guix fait l'hypothèse (forte) qu'il y a suffisamment de stabilité dans le noyau, le système de fichiers, etc. pour ne pas influencer sur la transparence binaire. Mais oui il y a une question pertinente sur l'effet du hardware.
        
        Cependant, qui peut le plus peut le moins. ;-)
        
        Merci de poser toutes ces questions. C'est intéressant d'avoir un retour. :-)
        
        Je me permets de faire un petit résumé.
        
        Guix est un gestionnaire de paquets transactionnel et inclut nativement la coexistence de plusieurs versions (les modulefiles et consort en beaucoup mieux), il permet de faire du roll-back et de voyager dans le temps, il inclut nativement la génération de conteneur (Docker, Singularity, tarball relocatable), il permet de travailler nativement dans un conteneur, il prend au sérieux les problèmes de bootstrap, et j'en passe d'autres; comme le fallback vers Software Heritage si les sources upstream ont disparues, etc..
        
        Alors oui chaque fonctionnalité prise individuellement existe ici ou là. Mais il n'y a aucun outil qui les intégrè aussi bien—sauf la grande tante Nix :-).
        
        Et oui il y a encore des questions ouvertes, en particulier sur la transparence binaire.
        
        Mais aujourd'hui, le vrai problème de Guix est une base d'utilisateurs assez petite donc des retours d'expériences assez peu nombreux. N'hésitez pas à essayer, il n'y a rien à faire avec le script d'installation et cela sera totalement transparent pour votre distribution. Puis venez râler en francais ou en anglais que cela ne convient pas sur help-guix@gnu.org. :-) Tous les retours sont bons à prendre. ;-)
        
        En passant, Vagrant est en train de l'empaqueter pour Debian. ;-)
        https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850644#56
        Donc n'hésitez pas du côté Debian non plus.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par freem le 24 janvier 2020 à 23:27. Évalué à 4.
        
        En Pré-Scriptum: j'ai pas suivi les liens, je vais le faire, ça semble super intéressant. Je ne fais que réagir à tes arguments ici, qui sont intéressants.
        
        L'intérêt est double:
        
        sécurité
        
        pardon, on m'a appris a considérer le mot sécurité comme un buzzword, quand il est tout seul.
        
        Ça protège de quoi, et dans quelles limitations?
        
        science computationnelle reproductible
        
        Arf… pardonnes donc le pauvre auto-didacte que je suis du manque de connaissances théorique…. mais je renifle ici quand même… euh, pour être poli, 3 mots mis ensembles pour impressionner la galerie. Désolé si c'est crû. En fait, non, pas tant désolé que ça, ce coin du web reste un coin ou je peux m'exprimer et apprendre sans faussetés.
        
        C'est le cas d'usage le plus courant. Mais il faut garder en tête :
        
        Que vous n'avez aucune garantie que le compilateur n'a pas introduit de code frauduleux. C'est ce que l'on appelle la Trusting Trust attaque et le problème du bootstrapp.
        
        Je le sais, je suis un nerd comme les autres. Enfin, p'tet moins doué, certes.
        
        Mais, oui, on sait, tu peux être espionné dès lors que tu confies ton hard a un autre. On sait, même le CPU peut leak… ça fait que 2 ans qu'on a des preuves, certes.
        Mais, y'a un moment, soit on fait abstinence, soit on reste un minimum optimiste, non? A noter que, j'ai lu 1984.
        
        Cela permet de ré-écrire partiellement la recette d'une paquet.
        
        Tu parles de science. Je te parle d'ingénierie. C'est p'tet la qu'on se comprend pas, je suis pas assez intelligent pour la science, mais je reste captivé par l'idée de supprimer toute contrainte inutile a l'humain. Il parait aussi que je suis pas idiot, mais, je connais pas de scientifique.
        Bref, à quoi ça sert?
        
        Je crois que RPM est capable de faire du transactionnel.
        
        Atta… tu compares RPM, un format de fichier, avec APT, un exécutable et… nix, une distro?
        Justement, parlons simples, parlons binaires, ça ressemble a quoi le format de nix?
        
        Le fait d'être "fonctionnel" rend les transactions faciles à implémenter. Ou disons plus facile que dans les approches "classiques" de gestion de paquets.
        
        Ah… le paradigme «silver bullet»… Java a essayé. Java a bien marché, mais n'a pas conquis le monde. Je vous souhaite le même succès.
        Désolé, tu n'as pas fournis un seul fait réel, donc je me permets de faire de même, et, en bon dev c++, de troller le java :) (y'a des traditions que j'aime, c'est un peu le folklore de l'info).
        
        Oui, c'est légitime comme question. Et à ma connaissance il n'y a pas encore vraiment de réponse par manque d'observation.
        
        Bien. Ici, pas moyen de troller, on cause tech.
        
        Par contre, j'ai un doute sur le "manque d'observation". Tu entends quoi? Si Nix est si robuste, faites donc du fuzzing. Il faut un stress root constant pour estimer le niveau de fragilité. Et même si vous avez des failles, hé, vous, au moins, vous permettez un certain parallélisme, et ça c'est un argument de vente pour moi. Parce que c'est fort, la vitesse.
        Ou alors vous jouez la sécurité, le tout séquentiel, et alors votre paradigme, bah, il sers pas a grand chose.
        
        Guix fait l'hypothèse (forte) qu'il y a suffisamment de stabilité dans le noyau, le système de fichiers, etc. pour ne pas influencer sur la transparence binaire. Mais oui il y a une question pertinente sur l'effet du hardware.
        
        Tu vois, c'est justement par l'intermédiaire de Nix que j'ai appris cette faiblesse. Et de mon job. Je suis tellement curieux… j'ai cherché, j'ai voulu reproduire cette fiabilité supposée, et… j'ai trouvé que c'était de la poudre aux yeux.
        Parce que le soft (le kernel est un soft) sous linux ne permets pas cette hypothèse. Et Nix/Guix l'affirment a chaque fois comme forte.
        J'aime pas ça, c''est pas honnête.
        
        Cependant, qui peut le plus peut le moins. ;-)
        
        Pitié, non… Un dev sys ne seras jamais un bon dev web, un architecte ne sera jamais un bon maçon, et vice versa. Cette expression je la prend comme une forme de mépris. C'est désagréable, même si je sais que je l'ai moi aussi commise, cette erreur.
        On peut avoir les notions des métiers adjacents, mais jamais on ne les fait aussi bien que des pros.
        
        Je me permets de faire un petit résumé.
        
        Merci pour ça
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 25 janvier 2020 à 16:31. Évalué à 3.
        
        En Pré-Scriptum: j'ai pas suivi les liens, je vais le faire, ça semble super intéressant. Je ne fais que réagir à tes arguments ici, qui sont intéressants.
        
        Peut-être commencez par cela. ;-)
        
        pardon, on m'a appris a considérer le mot sécurité comme un buzzword, quand il est tout seul.
        Ça protège de quoi, et dans quelles limitations?
        
        Attaque Trusting Trust par exemple.
        
        Arf… pardonnes donc le pauvre auto-didacte que je suis du manque de connaissances théorique…. mais je renifle ici quand même… euh, pour être poli, 3 mots mis ensembles pour impressionner la galerie. Désolé si c'est crû. En fait, non, pas tant désolé que ça, ce coin du web reste un coin ou je peux m'exprimer et apprendre sans faussetés.
        
        Au temps pour moi. Désolé.
        
        Il faut entendre tout processus de traitement numérique utilisé en Science. Cela va de la simulation numérique (météo, méca, etc.) à l'étude génétique des cancers par exemple.
        
        Aujourd'hui, tous les champs de la Science utilisent à un moment ou un autre un logiciel (ou plusieurs) et souvent le résultat (scientifique) est plus "dû" au traitement numérique qu'à l'observation elle-même.
        
        Or la méthode scientifique n'est pas appliquée à la gestion desdits logiciels. Donc finalement, est-ce encore de la Science ? (question ouverte qui n'appelle pas de réponse :-))
        
        (Méthode scientifique est pompeux et ne réfère à pas grand chose de bien définie : voir toute la philosophie des sciences ;-))
        
        Mais, oui, on sait, tu peux être espionné dès lors que tu confies ton hard a un autre. On sait, même le CPU peut leak… ça fait que 2 ans qu'on a des preuves, certes.
        Mais, y'a un moment, soit on fait abstinence, soit on reste un minimum optimiste, non? A noter que, j'ai lu 1984.
        
        On ne parle pas du hard qui est une question en soi. Déjà uniquement avec le soft, ca suffit.
        
        Pour être explicite, le compilateur peut introduire une backdoor à la compilation. Et comme un compilateur est lui même le résultat d'une compilation, ladite backdoor peut être ainsi propagée. D'où la question du bootstrap.
        
        Au quotidien, oui clairement on s'en fiche un peu. Enfin moi cela ne me dérange pas d'utiliser GHC parce qu'Haskell c'est chouette ;-) alors que le compilateur GHC n'est pas encore bootstrappable (à ma connaissance) donc potentiellement une source de fragilité en terme de sécurité.
        
        Et sinon, oui le hardware est une question. Il y a des projets qui essaie justement d'avoir du hard bootstrappable. Mais je ne suis pas sûr de suffisamment bien comprendre pour l'expliquer. :-)
        
        Tu parles de science. Je te parle d'ingénierie. C'est p'tet la qu'on se comprend pas, je suis pas assez intelligent pour la science, mais je reste captivé par l'idée de supprimer toute contrainte inutile a l'humain. Il parait aussi que je suis pas idiot, mais, je connais pas de scientifique.
        Bref, à quoi ça sert?
        
        Traduction libre d'une réponse Alan Cox :-)
        L'ingénierie ne requiert pas de science. La science aide beaucoup mais les gens construisait des mûrs en brique parfaitement bien bien avant qu'ils sachent pourquoi le ciment fonctionne.
        https://lkml.org/lkml/2001/12/1/110
        
        Donc on peut construire des choses incroyables sans science. :-)
        
        Cependant la science (en tant que méthode) se repose de plus en plus sur l'ingénierie (en tant que technique) et tout devient un peu mélangé.
        
        Bref, la question que vous posez sort du cadre de Guix et de LinuxFr et prendrait un peu plus qu'un commentaire pour y répondre. Êtes-vous dispo pour une bière ? ;-)
        
        Je crois que RPM est capable de faire du transactionnel.
        
        Atta… tu compares RPM, un format de fichier, avec APT, un exécutable et… nix, une distro?
        Justement, parlons simples, parlons binaires, ça ressemble a quoi le format de nix?
        
        Pour moi RPM c'est Red hat Package Manager et APT c'est Advanced Package Tools. Donc mes excuses si c'est un raccourci mais je voulais dire RPM pour toute l'infrastructure RedHat (et consort), un peu comme je pourrais aussi dire APT pour tout l'écosystème Debian. Abus de langage.
        
        Remarquez que dans tous les commentaires, j'ai parlé de Guix en tant que gestionnaire de paquets et jamais vraiment en tant que distribution. C'est une autre histoire.
        
        Personnellement, j'utilise Guix (gestionnaire de paquets) avec une distribution Debian stable. Debian me fournit principalement le noyau linux et le système de fichiers, plus quelques autres trucs comme des pilotes etc.. Bref!
        
        Tout ca pour dire que je crois que le gestionnaire de paquets RedHat (et/ou consort) permet de faire du transactionnel.
        
        Ca ressemble à quoi le format des paquets Guix ? La recette source ressemble à ca :
        https://guix.gnu.org/blog/2018/a-packaging-tutorial-for-guix
        Et le binaire c'est un format qui s'appelle nar. C'est repris de chez Nix qui l'a défini, voir par exemple une spec là:
        https://gist.github.com/jbeda/5c79d2b1434f0018d693
        Mais on ne manipule jamais un fichier .nar manuellement.
        
        Guix fait l'hypothèse (forte) qu'il y a suffisamment de stabilité dans le noyau, le système de fichiers, etc. pour ne pas influencer sur la transparence binaire. Mais oui il y a une question pertinente sur l'effet du hardware.
        
        Tu vois, c'est justement par l'intermédiaire de Nix que j'ai appris cette faiblesse. Et de mon job. Je suis tellement curieux… j'ai cherché, j'ai voulu reproduire cette fiabilité supposée, et… j'ai trouvé que c'était de la poudre aux yeux.
        Parce que le soft (le kernel est un soft) sous linux ne permets pas cette hypothèse. Et Nix/Guix l'affirment a chaque fois comme forte.
        J'aime pas ça, c''est pas honnête.
        
        Qu'est-ce qui n'est pas honnête ?
        
        Et juste pour comprendre. Vous avez pris 2 hardwares différents et mis dessus 2 versions différentes du noyau linux avec 2 versions différents du système de fichiers. Ensuite, vous avez mis dans ces 2 environnements différents exactement la même chaîne de compilation, bit à bit identique, du compilateur au linker en passant la Glibc. Puis vous avez compilé le même code source dans ces 2 environnements et vous n'obtenez pas le même binaire identique bit à bit, est-ce cela ?
        
        Si oui, je suis intéressé par connaitre le matériel en question, les versions des noyaux en questions, des systèmes de fichiers, de la chaîne de compilation et de ce que vous avez compilé. Du coup, je serais intéressé que vous me contactiez en privée. :-)
        
        Parce que oui c'est possible mais c'est rare. :-)
        Et je n'ai pas encore vu de mes propres yeux de tel cas.
        
        Cependant, qui peut le plus peut le moins. ;-)
        
        Pitié, non… Un dev sys ne seras jamais un bon dev web, un architecte ne sera jamais un bon maçon, et vice versa. Cette expression je la prend comme une forme de mépris. C'est désagréable, même si je sais que je l'ai moi aussi commise, cette erreur.
        On peut avoir les notions des métiers adjacents, mais jamais on ne les fait aussi bien que des pros.
        
        Le qui se réfèrait à "gestionnaire de paquets". :-)
        
        Merci pour vos commentaires.
        
        J'espère que vous prendrez le temps de tester Guix parce que notre discussion là est beaucoup plus large de ce qu'apporte le gestionnaire de paquets Guix comparé à ce qui existe (avec Debian par exemple). Et je ne voudrais pas qu'avec cette déviation, certes intéressante, vous ayez une fausse impression de ce que Guix fait/est.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par freem le 04 février 2020 à 21:52. Évalué à 4.
        
        Je sais qu'il est tard, mais bon…
        
        Donc finalement, est-ce encore de la Science ? (question ouverte qui n'appelle pas de réponse :-))
        
        (Méthode scientifique est pompeux et ne réfère à pas grand chose de bien définie : voir toute la philosophie des sciences ;-))
        
        Pour le coup, ce que j'imagine être la méthode scientifique c'est, en gros, observer un certain nombre de cause et de résultats, essayer de déduire la règle, puis prouver qu'elle est relativement juste avec un jeu d'expériences, preuve qui doit être validée par d'autres.
        Mes propos restent vagues, c'est normal, c'est pas mon domaine. Par contre, je trouve pas ça si pompeux que ça.
        
        Pour être explicite, le compilateur peut introduire une backdoor à la compilation.
        
        Mais il faut bien partir d'un binaire exécutable, parce que sinon, on doit se fier a un humain au niveau de l'intention et de la qualité (faut bien le construire, le 1er compilo). Dans le cas des compilateurs, c'est déjà le cas, mais on peut tester avec un certain nombre d'implémentations les résultats, plus ou moins, via fuzzing.
        C'est pas idéal, mais ça me semble la seule solution avec un vrai potentiel de confiance. Et sur ce point, l'absence de standardisation de l'ABI du C et du C++ seraient, ironiquement, une force, alors que ça cause tant de problèmes de portabilité…
        
        Enfin moi cela ne me dérange pas d'utiliser GHC parce qu'Haskell c'est chouette
        
        Voila, la, je te rejoins :)
        Bon, pas sur l'haskell parce que je connaît pas, mais je rejoins le fait qu'on doive faire l'équilibre entre la confiance et le sympa. Perso, un de mes arguments pour le C ou le C++, c'est que, justement, on a plusieurs implémentations, et je pense que pouvoir tester un code sur toutes ces implémentations est une force dont peu de langages «sûrs» peuvent se targuer (hein, rust?).
        Je joue le conservatisme sur ce point.
        
        Traduction libre d'une réponse Alan Cox :-)
        L'ingénierie ne requiert pas de science. La science aide beaucoup mais les gens construisait des mûrs en brique parfaitement bien bien avant qu'ils sachent pourquoi le ciment fonctionne.
        
        Magnifique. Merci, même si, pour moi, l'ingénierie est un peu une science de la pratique: on a observé que telle combinaison marche dans certaines situations, mais une autre est meilleure. On sait pas pourquoi, certes. Du coup, un mélange de science, d'expérience et d'intuition?
        
        Bref, la question que vous posez sort du cadre de Guix et de LinuxFr et prendrait un peu plus qu'un commentaire pour y répondre. Êtes-vous dispo pour une bière ? ;-)
        
        Ça m'amuserais énormément d'améliorer mes opinions lors d'une rencontre physique.
        
        Pour moi RPM c'est Red hat Package Manager et APT c'est Advanced Package Tools. Donc mes excuses si c'est un raccourci mais je voulais dire RPM pour toute l'infrastructure RedHat (et consort), un peu comme je pourrais aussi dire APT pour tout l'écosystème Debian.
        
        Justement, je pense que les étiquettes officielles sont foireuses, quand on ouvres un peu les boîtes. Par exemple, Debian dispose de plusieurs outils pour gérer packages et dépôts: apt, apt-get, aptitude, dselect, synaptics… leur point commun? L'outil qui installe le paquet dans le système. Et cet outil, c'est dpkg. Pour moi, c'est lui, le vrai gestionnaire de paquets, mais j'aime le low level, j'aime avoir la maîtrise de mes systèmes, je suis probablement pas dans la norme.
        
        Abus de langage.
        
        Qui est commun et difficile a ne pas faire, je pense. Ou peut-être que je n'ai pas la même définition, c'est un problème récurrent…
        
        Mais on ne manipule jamais un fichier .nar manuellement.
        
        C'est aussi ce qu'on dit d'un fichier .deb, mais moi, dans la pratique, tant a titre perso que professionnel, ça m'arrive chaque semaine.
        La raison principale, c'est que l'environnement officiel de debian est trop complexe. Par contre le format est bien documenté, et facile a implémenter de façon très automatique en shell, si on se contente d'un jeu de fonctionnalités (en gros: ne pas utiliser pré/post rm/inst, dont le résultat final est trop complexe pour mon esprit simple).
        Ah, quand j'évalue un logiciel, je tends a… lire le code et les formats. Pour que, si un jour un problème surviens, je puisse le patcher. Parce que c'est bien beau d'avoir le droit, encore faut-il avoir les compétences pour. Hors, un deb, je pourrais l'ouvrir avec un éditeur hexa, si besoin est. C'est une qualité non négligeable pour moi.
        
        Parce que le soft (le kernel est un soft) sous linux ne permets pas cette hypothèse. Et Nix/Guix l'affirment a chaque fois comme forte.
        J'aime pas ça, c''est pas honnête.
        
        Qu'est-ce qui n'est pas honnête ?
        
        Le fait de garantir un truc que même les manpages disent que ce n'est pas garantit. À savoir, que sur les FS de linux, il semble être impossible de garantir qu'un autre process n'écrit pas en même temps sur le même fichier, parce que les verrous sont juste informatifs, si un process ne veux pas les respecter, il peut ne pas le faire.
        
        J'espère que vous prendrez le temps de tester Guix parce que notre discussion là est beaucoup plus large de ce qu'apporte le gestionnaire de paquets Guix comparé à ce qui existe (avec Debian par exemple). Et je ne voudrais pas qu'avec cette déviation, certes intéressante, vous ayez une fausse impression de ce que Guix fait/est.
        
        Pas de soucis, j'ai bien conscience de ce que peux ou non un gestionnaire de paquet. Je pense depuis longtemps que l'approche de Nix/Guix est intéressante, sinon je n'aurais pas pris la peine de répondre.
        
        Hélas, les TODOlist des geeks ont tendance a s'allonger plus vite qu'autre chose, mais, honnêtement, il me suffirais de pas grand chose, genre, un outil qui permets de naviguer et manipuler les paquets installés (idéalement en ncurses), pour que j'adopte. Parce que pour moi, les forces de Debian, c'est 1) sa stabilité, et 2) aptitude.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par yabb85 le 30 janvier 2020 à 19:10. Évalué à 0.
        
        RPM est aussi un outil on peut installer un paquet en faisant
        
        rpm -i toto.rpm
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par barmic 🦦 le 22 janvier 2020 à 10:39. Évalué à 3.
        
        Un paquet utilisant inherit utilise la recette du paquet qu'il hérite et la modifie.
        
        Si on veut continuer de filer la métaphore, c'est une mauvaise pratique d'utiliser l'héritage pour ça. Ça rend très difficile la maintenance (faire évoluer l'ancêtre tout en restant pertinent pour tous les descendants). Ça pète le principe open/close des concepts SOLID
        
        Pour partager du code le mieux ça reste de faire de la composition
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 22 janvier 2020 à 16:14. Évalué à 1.
        
        Pour partager du code le mieux ça reste de faire de la composition
        
        C'est difficile de tout expliquer dans des commentaires ici et là. ;-)
        
        A l'essentiel: Guix compose. :-)
        
        Cette histoire d'inherit est un artefact dans la grande histoire de Guix. :-)
        C'est une astuce pour réécrire partiellement une recette de construction. Je ne vois pas en quoi cela casse la composition. En revanche oui, cela peut rendre plus fragile certains paquets.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par freem le 24 janvier 2020 à 22:43. Évalué à -1.
        
        J'me permets, parce que c'est facile…
        
        Pour partager du code le mieux ça reste de faire de la composition
        
        C'est difficile de tout expliquer dans des commentaires ici et là. ;-)
        
        A l'essentiel: Guix compose. :-)
        
        On m'a dis la même de la PO (Programmation Object). Mais je suis resté à la POO (Programmation Orientée Objet). Parce que forcer une façon de penser, c'est brider.
        
        Même les devs de systemd ont supporté le fait d'avoir des shells scripts, pour dire! (et pourtant, j'aime pas systemd).
        
        Cette histoire d'inherit est un artefact dans la grande histoire de Guix. :-)
        
        J'espère que tu espères pas convaincre des devs expérimentés en leur présentant un système nouveau qui a déjà des artefacts mis en avant? Parce que, bon, les artefacts, on (enfin, je) les accepte que quand ils sont obligatoire, hein.
        Au point que, pour mes collègues j'ai écrit un script pour générer des .deb à partir d'un fichier ini-style. Certes, des debs castrés, mais ça marche et c'est simple.
        
        C'est une astuce pour réécrire partiellement une recette de construction. Je ne vois pas en quoi cela casse la composition. En revanche oui, cela peut rendre plus fragile certains paquets.
        
        Désolé, tu viens de contre-vendre le projet.
        Moi, ce que je veux, c'est une distro qui concurrence la solidité et la simplicité réelle de debian. Et par simplicité réelle, j'entends… comment dire… ouvres donc un ficher .deb, tu verras.
        
        Ce format "binaire", est tellement simple, que c'est tout sauf stupide, et certainement pas du conservatisme (oui, je crache sur KISS ici).
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 25 janvier 2020 à 15:10. Évalué à 2. Dernière modification le 25 janvier 2020 à 15:10.
        
        On m'a dis la même de la PO (Programmation Object). Mais je suis resté à la POO (Programmation Orientée Objet). Parce que forcer une façon de penser, c'est brider.
        
        Sauf erreur de ma part personne n'a pas parlé de POO en présentant de Guix. C'est vous en lisant inherit et héritage qui extrapolez.
        
        J'ai l'impression que l'on s'amuse plus à une joute rhétorique que vraiment chercher à comprendre ce que fait l'outil et comment il fonctionne. Mais bon, c'est le jeu sur LinuxFr. ;-)
        
        J'espère que tu espères pas convaincre des devs expérimentés en leur présentant un système nouveau qui a déjà des artefacts mis en avant? Parce que, bon, les artefacts, on (enfin, je) les accepte que quand ils sont obligatoire, hein.
        Au point que, pour mes collègues j'ai écrit un script pour générer des .deb à partir d'un fichier ini-style. Certes, des debs castrés, mais ça marche et c'est simple.
        
        Idem ici. Vous découpez le cheveux en 4 alors que je vous ai donné un exemple concret avec GnuPG de ce que c'était. De quelle était l'idée derrière.
        
        Donc au lieu de juger et comparer l'idée (technique) avec par exemple Debian, vous faites de la rhétorique sur un mot en réponse à un autre commentaire en essayant de trouver une "faille" dans la présentation (mots) de ladite idée. Pourquoi pas mais je ne suis pas convaincu de là où cela mène. :-)
        
        C'est une astuce pour réécrire partiellement une recette de construction. Je ne vois pas en quoi cela casse la composition. En revanche oui, cela peut rendre plus fragile certains paquets.
        
        Désolé, tu viens de contre-vendre le projet.
        Moi, ce que je veux, c'est une distro qui concurrence la solidité et la simplicité réelle de debian. Et par simplicité réelle, j'entends… comment dire… ouvres donc un ficher .deb, tu verras.
        
        Je suis désolé pour vous parce que vous passez à côté d'un changement de paradigme en terme de gestion de paquets à cause de simples arguments de rhétorique.
        
        Et si l'on cherche la petite bête, les méta-paquets de chez Debian présentent exactement le même type de fragilité mais cela ne semble pas vous poser de problème. Mais je dis ca, je dis rien. ;-)
        
        Bref, j'ai essayé de répondre au mieux aux commentaires en présentant les concepts et en mettant des liens pointant vers la documentation.
        
        Honnêtement, si vous n'avez pas envie d'aller voir par vous même, je ne vois pas trop ce que moi je peux faire de plus ; à part troller. :-)
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par barmic 🦦 le 25 janvier 2020 à 18:16. Évalué à 3.
        
        Je suis désolé pour vous parce que vous passez à côté d'un changement de paradigme en terme de gestion de paquets à cause de simples arguments de rhétorique.
        
        Rien que ça ? Faudrait se calmer un peu, non ? Tu as vu la lumière et tout ce que les gens peuvent dire qui ne seraient pas dans ton sens ne sont que rhétorique ?
        
        Quand on en fait autant de caisse pour un outil qui fait pour beaucoup la même chose que ce qui existe déjà mais en mieux intégré avec quelques fonctionnalités (pas forcément utile pour grand monde) en plus, ça peut avoir évidement tendance à rendre septique.
        
        D'autant que personnellement un outils qui intègre mieux que ce qui existe déjà un ensemble de fonctionnalités, je n'appelle pas ça un changement de paradigme. Mais alors pas du tout.
        
        Le changement important est dans le fait de découpler ce qui est installé de ce qui est accessible. On installe dans un store et par des jeux de liens symboliques, on rend accessible ou pas dans le système ce qui est installé. C'est là dessus que tout nix/guix se base. L'aspect fonctionnel me paraît plus être un jouet de description de paquets.
        
        Très franchement personnellement cette indirection et ce changement de sémantique ne m'intéressent pas. Ça ajoute une complexité à mon système sans m'apporter la moindre fonctionnalité dont j'ai pu ressentir le besoin.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 25 janvier 2020 à 19:47. Évalué à -3.
        
        Rien que ça ? Faudrait se calmer un peu, non ? Tu as vu la lumière et tout ce que les gens peuvent dire qui ne seraient pas dans ton sens ne sont que rhétorique ?
        
        Ahaha j'adore… <3
        
        Pour le reste, vu que cela ne vous intéresse apparemment pas, pas la peine que je prenne du temps pour répondre.
        
        Comme le disait une certaine émission, à une certaine époque: c'est fini et vous pouvez reprendre une activité normale. :-)
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par nokomprendo (site web personnel) le 20 janvier 2020 à 14:00. Évalué à 5.
        
        Il y a un intérêt à changer les choix de Debian pour tout ton système, pas d'intérêt d'avoir 3 fois la même version d'une librairie.
        
        Peut-être que pour toi ça n'a pas d'intérêt mais perso j'utilise cette fonctionnalité tous les jours. Dans le domaine du HPC, c'est même indispensable et il y a différentes alternatives pour faire ça (environment modules, spack, guix/nix…)
        
        D'ailleurs, je pense que NixOS ne permet pas directement ce que tu indiques : 3 compilations différentes d'une même version de libraire pour 3 logiciels consommateurs différents.
        
        C'est expliqué ici pour nix : https://nokomprendo.gitlab.io/posts/tuto_fonctionnel_20/2018-04-28-README.html . Tu peux compiler autant de versions que tu veux, choisir les dépendances, le compilateur, les options de cmake, etc.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 20 janvier 2020 à 14:39. Évalué à 3.
        
        Il y a un intérêt à changer les choix de Debian pour tout ton système, pas d'intérêt d'avoir 3 fois la même version d'une librairie.
        
        Peut-être que pour toi ça n'a pas d'intérêt mais perso j'utilise cette fonctionnalité tous les jours.
        
        Toute la question est la définition de même version. Comme je demandais, est-ce que, considérant toutes les autres options exactement les mêmes,libfoo-1.2.3 compilée avec GCC 7 est-elle la même version que celle compilée avec GCC 8 ?
        
        D'ailleurs, je pense que NixOS ne permet pas directement ce que tu indiques : 3 compilations différentes d'une même version de libraire pour 3 logiciels consommateurs différents.
        
        C'est expliqué ici pour nix : https://nokomprendo.gitlab.io/posts/tuto_fonctionnel_20/2018-04-28-README.html . Tu peux compiler autant de versions que tu veux, choisir les dépendances, le compilateur, les options de cmake, etc.
        
        Ceci est vrai dans une certaine mesure. Je ne connais pas Nix mais Guix définit différents inputs et il est facile de changer les explicit inputs, en utilisant les transformations de build.
        
        En revanche, dans Guix il n'est pas facile de ré-écrire les implicit inputs.
        
        Disons pour schématiser, libfoo-1.2.3 dépend de bax (explicit) et bar (explicit) puis bar dépend de baz (implicit) puis baz dépend de baf (implicit) qui dépend de bax (implicit).
        
        Il est facile de changer comment libfoo-1.2.3 est compilée.
        
        Il est facile de changer la version ou même la bibliothèque bar elle-même, par exemple guix build foo --with-inputs=bar=café.
        
        Mais, guix build foo --with-inputs=bax=pax ne changera pas comme baf a été compilé et n'utilisera pas pax à la place de bax dans la compilation de baf. Il faut ré-écrire "manuellement" un nouveau paquet de baf disons giffle avec la dépendance à pax, ré-écrire un nouveau paquet baz disons taz et aussi un nouveau bar disons troquet.
        
        Bref, tout est possible et tout dépend de ce que l'on appelle même et différent. Le gros avantage, c'est que Guix donne les outils pour manipuler le graphe des dépendances et surtout détecter que l'on fait bien les choses que l'on veut faire. :-)
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par freem le 20 janvier 2020 à 22:50. Évalué à 2.
        
        Toute la question est la définition de même version. Comme je demandais, est-ce que, considérant toutes les autres options exactement les mêmes,libfoo-1.2.3 compilée avec GCC 7 est-elle la même version que celle compilée avec GCC 8 ?
        
        J'avais regardé un peu comment marchent ces 2 systèmes de paquet (guix/nix). En gros, les versions des paquets sont en fait un hash, pas la version réelle.
        Un journal précédent posait d'ailleurs il me semble la question du nettoyage automatique, qui était inefficace, contrairement aux mécanismes plus classiques. Certes, ça n'impacte que les machines avec un espace disque restreint, mais bon, sur ma machine a moi, j'ai moins de 300Gio de disque (c'est un ssd pas tout neuf, certes), et ça me ferait chier que chaque distro dessus ait besoin de plus de 30Gio d'espace disque pour /.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 21 janvier 2020 à 00:36. Évalué à 3.
        
        Un journal précédent posait d'ailleurs il me semble la question du nettoyage automatique, qui était inefficace, contrairement aux mécanismes plus classiques. Certes, ça n'impacte que les machines avec un espace disque restreint, mais bon, sur ma machine a moi, j'ai moins de 300Gio de disque (c'est un ssd pas tout neuf, certes), et ça me ferait chier que chaque distro dessus ait besoin de plus de 30Gio d'espace disque pour /.
        
        Si par nettoyage automatique on parle de guix gc, je ne sais pas si on peut dire inefficace. Même si oui il y a des choses à améliorer.
        
        https://guix.gnu.org/manual/en/html_node/Invoking-guix-gc.html#Invoking-guix-gc
        
        En fait, on peut conserver qu'un certain nombre de générations (disons 3) ce qui permet de faire au plus 3 roll-backs.
        
        En espace limité, il y a les manifests qui permettent de ne stocker que des fichiers textes pour restaurer ultérieurement un état précis. Mais sans garanti que les binaires seront encore disponibles donc peut-être la CPU sera un peu mangé par quelques compilations. :-)
        
        Quelque part, c'est "no free lunch". ;-)
        
        Toujours est-il que ce serait intéressant de regarder l'espace disque occupé par une distro classique versus la taille de /gnu/store ne conservant que 2 ou 3 générations.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par gnumdk (site web personnel) le 20 janvier 2020 à 12:52. Évalué à 1.
        
        Passer du canal stable au canal unstable, ça correspond à un dist-upgrade sous Debian. Ca fait
        longtemps que je n'ai pas fait de dist-upgrade mais je ne crois pas que ça se fasse en 5 min.
        
        Quand tu le fais sur l'installation minimal, si, une debian, ça prend deux minutes.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 20 janvier 2020 à 19:32. Évalué à 1.
        
        Passer du canal stable au canal unstable, ça correspond à un dist-upgrade sous Debian. Ca fait
        longtemps que je n'ai pas fait de dist-upgrade mais je ne crois pas que ça se fasse en 5 min.
        
        Quand tu le fais sur l'installation minimal, si, une debian, ça prend deux minutes.
        
        Non, concernant Debian, d'un point de vue théorique cela dépend de la divergence entre la branche stable de la branche unstable.
        
        D'un point de vue pragmatique, cela peut déjà prendre 2 minutes pour mettre à jour avec apt update. Et ensuite le temps de apt upgrade dépendra fortement de votre réseau et du réseau d'où les binaires sont tirés.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par freem le 20 janvier 2020 à 22:53. Évalué à 4. Dernière modification le 20 janvier 2020 à 22:53.
        
        Est-ce vraiment pertinent de prendre en compte le réseau? Pour moi, l'impact du gestionnaire de paquets, c'est sur l'overhead du calcul des dépendances et de l'install proprement dite qu'il faut le faire, pas sur le DL.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par barmic 🦦 le 21 janvier 2020 à 00:18. Évalué à 4.
        
        Ça doit faire au moins 10 ans que je n'ai pas eu à lancer aptitude pour avoir un vrai résolveur 3-SAT pour mes dépendances (et t'avais vraiment fait n'importe quoi). Non pour moi c'est le téléchargement qui prend presque la totalité du au quotidien et le depaquetage et la configuration aussi sur les grosses installations ou mise à jour
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par Maxzor le 20 janvier 2020 à 13:14. Évalué à -3.
        
        Molière au secours!
        It just works je suis un peu près convinced que ça se traduit pas comme ça :)
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 20 janvier 2020 à 19:20. Évalué à 2.
        
        Je ne connais pas Nix et uniquement un peu Guix.
        
        Perso, le journal sur GUIX m'a fait joué avec l'original (NixOS) ce week end. Sur le papier ça semble bien, j'aime bien l'idée de la recette de cuisine à la puppet (même si très voir trop basique en comparaison de Puppet/Ansible & co).
        
        Je n'ai jamais utilisé Puppet/Ansible & co..
        
        Dans Guix, il y a guix deploy qui fait pas mal de boulot. Alors j'aimerais bien savoir ce qui est trop basique, i.e., ce que fait Pupper/Ansible & co. que ne ferait pas guix deploy.
        
        https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-deploy.html
        
        Mais par contre, c'est d'une lenteur pour installer des paquets! Le passage de stable vers unstable a mis trois plombe
        
        Dans Guix, il n'y a pas de notion de stable vs instable. Donc je ne comprends pas cette phrase.
        
        Une fois le gestionnaire de paquet installé, il faut faire un premier guix pull qui est l'équivalent d'un apt update. Est-ce cette étape qui vous a paru longue ?
        
        Ensuite pour installer un paquet (avant ou après guix pull peu importe), est-ce la commande guix install foo qui vous a paru longue ? Si oui, quel était le paquet foo en question ?
        
        et mon sentiment général que que NixOS, c'est l'inverse d'ArchLinux, ne gardons rien de simple!
        
        Hum? c'est étrange comme remarque… Sans troller, aujourd'hui les utilisateurs de Guix System sont souvent principalement des anciens utilisateurs de ArchLinux, Gentoo ou Debian, même si je n'ai pas vraiment de chiffres pour affirmer cela. :-)
        
        Toujours est-il que le gros avantage de Guix (gestionnaire de paquets), c'est que cela peut s'installer sur n'importe quelle distro. Donc on peut allier le meilleur des mondes. ;-)
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par roptat le 21 janvier 2020 à 01:28. Évalué à 3.
        
        J'ai beau apprécier Guix, guix deploy n'est pas vraiment comparable à Ansible & co : d'une part ce n'est pas la même cible : Ansible & co déploient n'importe quelle distro, alors que guix deploy est spécifique à Guix. Ensuite, à cause de la quantité de scripts Ansible disponibles, comparé au nombre de services minimaux de Guix.
        
        Par contre, je suis convaincu que guix deploy utilise le bon modèle de déploiement (sans état) contrairement à Ansible & Co.
        
        Dans Guix, il n'y a pas de notion de stable vs instable. Donc je ne comprends pas cette phrase.
        
        Ça concernait NixOS, qui a plusieurs canaux de base (stable, unstable) alors qu'on n'a que le canal par défaut dans Guix (donc l'équivalent de unstable). Et oui c'est long à mettre à jour ou installer des paquets, parce qu'il n'y a pas toujours des substituts, et que les paquets sont pas forcément très bien découpés, ce qui fait augmenter le nombre de dépendances inutiles.
        
        et mon sentiment général que que NixOS, c'est l'inverse d'ArchLinux, ne gardons rien de simple!
        
        Je viens de Arch, (et LFS) mais c'était plutôt la rolling-release qui m'intéressait. Je comprends assez bien la remarque, côté développement et maintient de la distro. Je dirais qu'on perd la simplicité pour gagner une certaine rigueur mathématique dans la gestion des paquets. Par contre côté utilisateur, je ne comprends pas bien la remarque : entre guix install foo et pacman -S foo j'ai du mal à comprendre lequel serait plus simple. Mais j'ai jamais vraiment compris la « simplicité » de Arch :D
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 21 janvier 2020 à 10:44. Évalué à 1.
        
        Par contre, je suis convaincu que guix deploy utilise le bon modèle de déploiement (sans état) contrairement à Ansible & Co.
        
        Connais-tu propellor ?
        
        http://propellor.branchable.com/
        
        Dans Guix, il n'y a pas de notion de stable vs instable. Donc je ne comprends pas cette phrase.
        
        Ça concernait NixOS, qui a plusieurs canaux de base (stable, unstable) alors qu'on n'a que le canal par défaut dans Guix (donc l'équivalent de unstable). Et oui c'est long à mettre à jour ou installer des paquets, parce qu'il n'y a pas toujours des substituts, et que les paquets sont pas forcément très bien découpés, ce qui fait augmenter le nombre de dépendances inutiles.
        
        Cela correspond à changer de branche / canal avec guix pull, non ?
        
        Et donc le calcul de la dérivation est long, c'est ca ? Je ne vois pas pourquoi il devrait être "plus long".
        
        Concernant la disponibilité de substituts, c'est comparer des pommes et des oranges. ;-)
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par roptat le 23 janvier 2020 à 05:28. Évalué à 1.
        
        tient non, je ne connaissais pas :)
        
        Par contre, en regardant rapidement ça a l'air d'être toujours le même modèle de déploiement qu'Ansible par exemple (notamment ça parle d'idempotence). C'est bien, mais pour moi ce n'est pas suffisant : le résultat dépend de l'état de la machine. Une même configuration ne t'assure pas d'avoir le même résultat sur plusieurs machines différentes, si leur état initial est différent.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 24 janvier 2020 à 12:26. Évalué à 1.
        
        Finalement, si je comprends bien, c'est la même conclusion concernant la reproductibilité que pour n'importe quel outil utilisant le schéma d'une distribution classique : il y a toujours un hic quelque part car les distributions classiques sont doomed en fait. :-)
        
        Plus de propagande là : ;-)
        https://archive.fosdem.org/2019/schedule/event/gnu_guix_new_approach_to_software_distribution/
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par freem le 24 janvier 2020 à 22:47. Évalué à 2.
        
        Il suffit de dire qu'on doit accepter et prendre conscience de ça, le fait que l'on doit faire confiance a un organe initial?
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par zimoun le 25 janvier 2020 à 14:32. Évalué à 1.
        
        Ou il y a une autre option paraphrasant vos mots :
        
        Il suffit de dire qu'on doit essayer de changer ça parce qu'on en a pris conscience, le fait que de pouvoir collectivement vérifier "l'organe initial" pour lui faire confiance.
        
        [^] # Re: Mal connaître sa distribution
        
        Posté par freem le 24 janvier 2020 à 22:45. Évalué à 2.
        
        et cfengine? Je pose la question en toute innocence, mais je crois que c'est l'ancêtre, son but étant d'arriver a un état stable en tout temps? pas réussi à l'utiliser, mais pas eu le temps d'étudier non plus…
    - [^] # Re: Mal connaître sa distribution
      
      Posté par roptat le 20 janvier 2020 à 04:29. Évalué à 8.
      ok j'ai pas gwenview dans guix, mais voyons avec feh, une visionneuse d'images :
      
      ldd `which feh` | grep libpng libpng16.so.16 => /gnu/store/3snpwk7jl8i125bhiilvk9scqc4mnsx7-libpng-1.6.37/lib/libpng16.so.16 (0x00007f5d066f9000)
      
      effectivement, libpng n'est pas un très bon exemple puisque le nom de la bibliothèque contient le numéro de version :). En revanche, ma libpng16.so est dans un dossier à part, ce qui me permet d'avoir une version 1.6.36 (là je doute que tu puisses le faire :p). Mais cette 1.6.36 n'est pas maintenue par Guix : c'est simplement une version qui a existé dans la distribution à un moment donné.
      
      Contrairement aux autres distros (sauf nix) guix ne remplace jamais rien : il ajoute les nouveautés dans le dépôt, dans de nouveaux chemins (c'est à ça que sert le hash : il identifie sources + dépendances + recette) et en retire les vieilleries quand elles ne servent plus à personne. Si je mets à jour feh, guix installera une nouvelle version qui fera référence à une nouvelle version de libpng (en imaginant qu'il y a eu une mise à jour) et remplacera feh dans la nouvelle génération de mon profil.
      
      Si je me rends compte qu'il y a un problème avec cette nouvelle version, je fais un coup de guix roll-back et je suis revenu à la version précédent de feh, qui fonctionne (c'est pour ça qu'on ne supprime rien : ça peut toujours servir). Si ça fonctionne, je peux supprimer cette ancienne génération (guix package --delete-generation) et lancer le ramasse-miette (guix gc). Je peux aussi utiliser ça pour :
      
      Avoir plusieurs profils, par exemple un par projet de développement (comme pypi le fait pour python, mais avec un outil unique pour tous les langages et capable d'installer des profils polyglottes). Chaque profil peut évoluer à son rythme, par exemple si je n'ai pas le temps de corriger un projet pour la nouvelle version de tel logiciel, je peux attendre un peu.
      
      Faire une mise à jour partielle : dans mon exemple avec feh, je peux mettre à jour uniquement feh pour profiter de ses nouveautés, sans toucher à dunst qui se trouve aussi dans mon profil. Là feh utiliserait l'hypothétique 1.6.38, alors que dunst continuerait de fonctionner comme avant, avec la 1.6.37.
      
      Ne pas remplacer, ça donne la garanti que le logiciel se comportera toujours de la même manière, quoi qu'on fasse.
# Quelques "killer features"

Posté par zimoun le 20 janvier 2020 à 11:26. Évalué à 7.
En terme de gestion de paquets, le paradigme de Guix vient avec :
- coexistence de différents outils incompatibles entre eux : profile et environment
- générations / transactions : roll-back
- configuration déclarative : fichier manifest
- voyage dans le temps : time-machine
Autant les 3 premiers points peuvent être obtenus avec des gestionnaires de paquets "classiques" modulo un peu de d'habitude quand même, autant le voyage dans le temps est impossible—à ma connaissance. Aujourd'hui, il est impossible de restaurer (recompiler) une version de l'archive (par exemple Debian, je ne connais pas assez Arch ou autres) telle qu'elle était exactement disons le 14 juillet 2017.

Et donc Guix peut générer des conteneurs (Docker, Singularity, tarball) de manière reproductible (en s'affranchissant du paramètre : quand l'image a-t-elle été générée ?) en ne conservant qu'un simple fichier texte (manifest).

Quelques pointeurs à cliquer :

https://guix.gnu.org/blog/2019/guix-profiles-in-practice/
https://guix.gnu.org/manual/en/html_node/Features.html#Features
https://guix.gnu.org/manual/en/html_node/Invoking-guix-pull.html#Invoking-guix-pull
https://guix.gnu.org/manual/en/html_node/Invoking-guix-time_002dmachine.html#Invoking-guix-time_002dmachine
https://guix.gnu.org/blog/2020/reproducible-computations-with-guix/
- [^] # Re: Quelques "killer features"
  
  Posté par vpinon le 20 janvier 2020 à 21:56. Évalué à 3.
  
  restaurer (recompiler) une version de l'archive (par exemple Debian, je ne connais pas assez Arch ou autres) telle qu'elle était exactement disons le 14 juillet 2017.
  
  http://snapshot.debian.org/
  - [^] # Re: Quelques "killer features"
    
    Posté par zimoun le 20 janvier 2020 à 23:01. Évalué à 2.
    http://snapshot.debian.org/
    
    Merci. Même si je connaissais, c'est mieux d'être précis. :-)
    
    Il faut les droits administrateurs—ceci est un détail mais peu vite devenir fastidieux suivant l'environnement dans lequel on travaille (cluster partagé).
    
    Ensuite, il faut donc modifier le fichier sources.list pour ajouter les dépôts à tirer, faire apt update et ensuite apt install foo installera la version que l'on souhaite. Version qui peut être en conflit avec une version de foo déjà installée, ou pire avec une des dépendances de foo, ou des dépendances de dépendances. Et cela peut vite devenir l'enfer. (Sauf à recourir à un outil externe à Debian comme Docker. ;-))
    
    L'équivalent de cette procédure avec Guix serait : guix pull --commit=12345abcdef puis guix install foo --profile=good-old-foo et il n'y a pas de question sur de possibles conflits.
    
    La commande time-machine permet de faire beaucoup mieux car dans Guix il y a un concept qui permet d'avoir plusieurs versions de Guix (index des paquets) sans conflits : inferior.
    
    https://guix.gnu.org/manual/en/html_node/Inferiors.html#Inferiors
    
    Chose à ma connaissance difficile avec Debian et APT.
    
    Donc par exemple, je peux vouloir utiliser foo une seule fois dans sa vielle version. Dans ce cas :
```
$ guix time-machine --commit=12345abcdef     \
    -- environment  --container --ad-hoc foo \
    -- foo
```
    récupéra la bonne version de l'index des paquets, puis construira ce qu'il manque et lancera foo dans un conteneur (pour éviter une faille de sécurité par exemple).
    
    Pour finir, la dernière chose qui n'a pas été évoqué est la bootstrappabilité. Pour le dire clairement, comment est construit / compilé le compilateur utilisé pour compiler la version de foo du 14 juillet 2017 ?
    
    Dans la machinerie des snapshots, je ne sais pas si les choses sont aussi transparentes, binairement parlant. Et donc à ma connaissance, les binaires sont conservés car ils sont difficiles—si ce n'est impossible—à reproduire bit-à-bit.
- [^] # Re: Quelques "killer features"
  
  Posté par freem le 20 janvier 2020 à 23:00. Évalué à 2.
  
  En terme de gestion de paquets, le paradigme de Guix vient avec :
  
  coexistence de différents outils incompatibles entre eux : profile et environment
  générations / transactions : roll-back
  configuration déclarative : fichier manifest
  voyage dans le temps : time-machine
  Autant les 3 premiers points peuvent être obtenus avec des gestionnaires de paquets "classiques" modulo un peu de d'habitude quand même, autant le voyage dans le temps est impossible—à ma connaissance.
  
  Marrant, moi j'aurais dis que c'est le roll-back qui est chiant avec Debian. Le repro-build, c'est en cours pour Debian, et de ce que j'en sais (pas grand chose, outre mes compétences de développeur non-debian) je dirais que la cause est plutôt les recettes de compilations, notamment celles à base de CMake.
  
  Du coup, je suis curieux, tu fais comment pour rollback une install d'un .deb qui foire?
  - [^] # Re: Quelques "killer features"
    
    Posté par zimoun le 20 janvier 2020 à 23:21. Évalué à 1.
    Du coup, je suis curieux, tu fais comment pour rollback une install d'un .deb qui foire?
    
    Debian n'est pas transactionnel à ma connaissance (très limitée). Donc si ca foire au milieu, c'est un peu le début de la galère. Enfin cela dépend ce qui a foiré etc.
    
    Pour du roll-back, toujours à ma connaissance très partielle, la solution c'est le snapshot. Soit tu snapshotes niveau système de fichiers, soit tu utilises snapshot.debian.org en connaissant les dates etc.
    
    Dans tous les cas, c'est ce que j'appelle "un peu de d'habitude quand même". ;-)
    
    Le repro-build, c'est en cours pour Debian
    
    Oui le repro-build est bien avancé dans Debian. Cependant, toujours à ma connaissance, le paquet peut être reproductible, mais tu n'as aucune garantie que le binaire que tu tires a bien été compilé en utilisant la recette de construction qui a été testée. Tu peux juste avoir la garantie que le binaire a été poussé par une personne de confiance (via les signatures etc.).
    
    Je ne connais pas les outils Debian mais dans Guix, tu peux faire:
```
guix build foo                        #1
guix build foo --check --no-grafts -K #2
```
    L'étape #1 va mettre ce qu'il faut dans /gnu/store/ en utilisant les substituts s'ils sont disponibles, donc cela va télécharger un tas de binaires.
    
    L'étape #2 va reconstruire le paquet en local et dire si le résultat (hash) est le même que cela qui a été téléchargé. Si ce hash n'est pas le même, cela signifie que le paquet n'est pas reproductible. Soit le substitut a été corrompu, soit il y a une cause de non-reproducibilité dans le code et là il faut sortir diffoscope (initier par Debian à ma connaissance) et chercher la cause.
    - [^] # Re: Quelques "killer features"
      
      Posté par barmic 🦦 le 21 janvier 2020 à 00:14. Évalué à 1.
      
      apt-build permet de reconstruire un paquet très facilement et le comparer avec l'existant n'est pas très compliqué
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
      - [^] # Re: Quelques "killer features"
        
        Posté par zimoun le 21 janvier 2020 à 00:43. Évalué à 1.
        
        apt-build permet de reconstruire un paquet très facilement et le comparer avec l'existant n'est pas très compliqué
        
        Merci pour l'information.
        
        Comment est contrôlé la chaine de compilation ?
        
        [^] # Re: Quelques "killer features"
        
        Posté par barmic 🦦 le 21 janvier 2020 à 07:16. Évalué à 1.
        
        C'est une information qui fait partie du paquet, donc tu peux l'installer et tu peux la vérifier de la même manière. Évidemment il peut y avoir un problème au bootstrap, mais je présume qu'ily een a un aussi aussi avec ta solution.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Quelques "killer features"
        
        Posté par zimoun le 21 janvier 2020 à 10:32. Évalué à 1.
        
        C'est une information qui fait partie du paquet, donc tu peux l'installer et tu peux la vérifier de la même manière. Évidemment il peut y avoir un problème au bootstrap, mais je présume qu'ily een a un aussi aussi avec ta solution.
        
        Pour faire simple, la graine utilisée pour bootstrapper est donnée par le commit de Guix.
        
        $ guix describe Generation 10 Sep 03 2018 17:32:44 (current) guix e0fa68c repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: e0fa68c7718fffd33d81af415279d6ddb518f727
        
        https://guix.gnu.org/manual/en/html_node/Invoking-guix-describe.html#Invoking-guix-describe
        
        Imaginons que l'on ait la définition du paquet foo là chemin/du/paquet—et ce paquet n'est pas dans l'arbre officiel.
        
        Connaissant le commit, je peux à n'importe quel moment réutiliser la même graine et donc construire le paquet.
        
        guix time-machine --commit=e0fa68c -- build -L chemin/du/paquet foo
        
        Et le résultat sera toujours le même. Enfin devrait. ;-)
        
        En revanche, le résultat de guix build -L chemin/du/paquet foo dépendra de l'état (commit) dans lequel je me trouve au moment où je lance ladite commande.
        
        La machinerie (côté Guix) est là mais tout n'est pas résolu non plus (côté dev. des langages).
        
        Pour ce qui concerne le C, GNU Mes a fait un gros boulot et la graine commence à être raisonnable. :-)
        
        Mais pour d'autres langages, c'est encore assez compliqué. Voir ce qui est fait pour Rust.
        
        Ne parlons pas d'Haskell. ;-)
        
        etc.
        
        https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/
        https://guix.gnu.org/blog/2018/bootstrapping-rust/
        https://www.joachim-breitner.de/blog/748-Thoughts_on_bootstrapping_GHC
        
        [^] # Re: Quelques "killer features"
        
        Posté par barmic 🦦 le 21 janvier 2020 à 10:50. Évalué à 3.
        
        Connaissant le commit, je peux à n'importe quel moment réutiliser la même graine et donc construire le paquet.
        
        Tu le construis avec quels outils ?
        
        Pour ce qui concerne le C, GNU Mes a fait un gros boulot et la graine commence à être raisonnable. :-)
        
        Je veux bien mais tu va devoir faire confiance au binaire de ce compilateur si j'ai bien compris.
        
        Se passer d'une étape de compilation est extrêmement complexe, c'est pas une question de guis, nix ou apt. Si tu veux remettre en cause les dépôts de ton outils, il y a soit un compilateur à qui tu es contrains de faire confiance soit tu prends des étapes hyper relous de construction d'un compilateur from scratch (tu fais confiance à quel éditeur hexa décimal ? ;)
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: Quelques "killer features"
        
        Posté par zimoun le 21 janvier 2020 à 12:29. Évalué à 1.
        
        Tu le construis avec quels outils ?
        
        Avec 2 outils: un peu de magie et beaucoup d'amour. ;-)
        
        Le terme "le" se réferre à paquet, n'est-ce pas?
        
        C'est toute la machinerie du boostrapp. Au lieu de faire une longue explication ici, le mieux me semble-t-il est d'aller voir la documentation officielle. :-)
        
        https://guix.gnu.org/manual/en/html_node/Bootstrapping.html#Bootstrapping
        
        En particulier, cette section
        
        https://guix.gnu.org/manual/en/html_node/Preparing-to-Use-the-Bootstrap-Binaries.html#Building-the-Build-Tools
        
        Pour ce qui concerne le C, GNU Mes a fait un gros boulot et la graine commence à être raisonnable. :-)
        
        Je veux bien mais tu va devoir faire confiance au binaire de ce compilateur si j'ai bien compris.
        
        GNU Mes est une histoire en soi. :-)
        
        Le but est de réduire la taille des binaires auxquels on fait confiance. Ceci pour réduire la surface d'une attaque Trusting Trust.
        
        Discuter et analyser la taille de ces binaires est déjà un pas en avant. Je ne sais pas où en est Debian, je suis un peu perdu avec le "stage0" de Gentoo et je ne sais pas du tout comment Arch fait.
        
        Se passer d'une étape de compilation est extrêmement complexe, c'est pas une question de guix, nix ou apt. Si tu veux remettre en cause les dépôts de ton outils, il y a soit un compilateur à qui tu es contrains de faire confiance soit tu prends des étapes hyper relous de construction d'un compilateur from scratch (tu fais confiance à quel éditeur hexa décimal ? ;)
        
        Oui c'est un problème compliqué. :-)
        Et oui cela dépasse le cadre de Guix et autres.
        Cependant, ce n'est pas pour cela qu'il n'y a pas de question. ;-)
        
        Et une des choses que Guix fait—entre autres—est de fournir des outils pour avoir une vision plus claire sur cette chaine de production source->binaire. Pour le dire clairement, il y a une plus grande transparence binaire, à mon humble avis.
        
        Ces étapes "hyper relous" sont déjà avancées.
        
        https://gitlab.com/janneke/stage0
        https://bootstrapping.miraheze.org/wiki/Stage0
# Ouïe fonctionnel...

Posté par Maxzor le 20 janvier 2020 à 16:29. Évalué à 1.

Quand on a jamais fait de fonctionnel, qu'on traîne dans les marécages de l'impératif, entendre Scheme ça fait peur.
Comment on s'y met?
- [^] # Re: Ouïe fonctionnel...
  
  Posté par zimoun le 20 janvier 2020 à 17:58. Évalué à 5.
  - La connaissance de Scheme n'est pas nécessaire dans un premier temps.
  - (La (connaissance (des (parenthèses)))) est nécessaire dans un deuxième temps.
  - Pour bricoler en expert, il faudra apprendre un peu de Scheme.
  La première chose est d'installer Guix sur ta distribution actuelle. Il n'y aura pas de conflit et cela permet de tester et comprendre un peu les concepts. Juste avec la gestion de paquets. (Avant d'aller plus loin avec les services, une autre histoire ;-))
  
  Il faut commencer par les profiles, le côté rolling release et pull en particulier les channels et describe, aussi les environments.
  
  Ensuite, il faut passer par les manifests pour déclarer ses profils. C'est là qu'il faut commencer à taper des parenthèses. Mais pas vraiment du Scheme. Juste un DSL avec des parenthèses.
  
  Ensuite, une étape passe par créer ses paquets. Un peu plus Scheme mais pas vraiment non plus. Il faut voir cela comme un DSL avec des parenthèses.
  
  Jusque là, tout se fait avec la CLI. Et cette CLI a une interface Emacs.
  
  https://emacs-guix.gitlab.io/website/
  
  On peut s'arrêter là, même pour une utilisation avancée dans la gestion des paquets.
  
  L'étape suivante serait de jouer avec guix repl qui lance un Read-Eval-Parse-Loop. Cela permet de manipuler les paquets avec du code, écrire des petites fonctions etc. Et c'est à cette étape là qu'il faut commencer à écrire du Scheme. Mais bon, la plupart des choses usuelles se font en ligne de commande ; comme pour les autres gestionnaires de paquets.
  
  A titre d'analogie, ce n'est pas parce que l'on ne sait pas écrire des scripts fu que l'on ne peut pas utiliser Gimp. Ou du Lisp et AutoCAD. Ben là, c'est un peu pareil. Guix vient avec le concept de hackabilité ; pour les experts en quelque sorte. Mais ce n'est pas nécessaire pour une utilisation quotidienne et même avancée.
  
  Pour le dire autrement, il ne faut pas connaître les subtilités du dossier debian/, ni le C++ pour utiliser Debian et faire apt install ou apt update. De la même manière, il ne faut pas connaître Scheme pour utiliser Guix.
# impatient pour la suite

Posté par roptat le 20 janvier 2020 à 18:38. Évalué à 3.

J'attends la suite avec impatience. Ça me fait toujours plaisir qu'on parle de Guix. Si ça t'intéresse, on peut essayer de se coordonner pour écrire la suite. Je suis sûr que Zimoun serait très intéressé aussi si tu lui proposais. Tiens-nous au courant :)
- [^] # Re: impatient pour la suite
  
  Posté par zimoun le 20 janvier 2020 à 19:03. Évalué à 3.
  
  salut roptat :-)
  
  Oui tout à fait ! On peut se coordonner pour écrire la suite. :-)
  
  J'en profite pour aussi dire qu'il y a un manuel en francais
  
  https://guix.gnu.org/manual/fr/html_node/
  
  et qu'un bon moyen de se mettre le pied à l'étrier est de rapporter les erreurs/coquilles et/ou traduire ce qu'il manque. ;-)
  - [^] # Re: impatient pour la suite
    
    Posté par roptat le 20 janvier 2020 à 22:45. Évalué à 2.
    
    autant dire que je suis nul en aurtogrâf :p. Ce serait très utile d'avoir une relecture (normalement la version que tu proposes est traduite à 100%). Par contre, je suis convaincu qu'on peut trouver mieux que « récupère le .po, modifie-le et envoie-moi le diff ». J'avais pensé à une interface web, mais pootle n'est plus maintenu et weblate demande un accès au dépôt, c'est pas top. Si d'autres ici ont des idées, je suis preneur.
    - [^] # Re: impatient pour la suite
      
      Posté par zimoun le 21 janvier 2020 à 10:48. Évalué à 1.
      
      normalement la version que tu proposes est traduite à 100%.
      
      Il y a encore des choses à faire… :-)
      
      https://guix.gnu.org/manual/fr/html_node/Invoking-guix-time_002dmachine.html#Invoking-guix-time_002dmachine
      
      Par contre, je suis convaincu qu'on peut trouver mieux que « récupère le .po, modifie-le et envoie-moi le diff ».
      
      +1 :-)
      
      Mais je n'ai aucune idée :-(
- [^] # Re: impatient pour la suite
  
  Posté par Andréas Livet le 20 janvier 2020 à 22:08. Évalué à 2.
  
  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.
# Vim Emacs

Posté par reynum (site web personnel) le 30 janvier 2020 à 16:21. Évalué à 3.

J’avoue ne pas être un fan d’Emacs (ni de Vim)

Pour l'un c'est normal mais pour l'autre c'est presque une hérésie 😃

kentoc'h mervel eget bezan saotred
- [^] # Re: Vim Emacs
  
  Posté par barmic 🦦 le 31 janvier 2020 à 10:41. Évalué à 2.
  
  Quoi ?! Mais tu peux pas dire ça !
  
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: Vim Emacs
    
    Posté par reynum (site web personnel) le 31 janvier 2020 à 15:51. Évalué à 3.
    
    SI !
    
    kentoc'h mervel eget bezan saotred

Suivre le flux des commentaires

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