GNU Guix est le gestionnaire de paquets transactionnel et une distribution perfectionnée du système GNU qui respecte la liberté de ses utilisateurs. Guix peut s’utiliser en tant que gestionnaire de paquets sur n’importe quel système utilisant le noyau Linux ou Hurd, et peut s’utiliser comme distribution à part entière sur les machines i686, x86-64, ARMv7 et AArch64.
En plus des fonctionnalités habituelles des gestionnaires de paquets, Guix permet des mises à jour et des retours en arrière transactionnels, de gérer ses paquets sans privilèges, d’utiliser plusieurs profils par utilisateur, et d’empaqueter une collection de paquets via une archive TAR repositionnable ou une image Docker. Et tout ceci pour n’importe quel point dans le temps via guix time-machine.
Lorsque Guix est utilisé comme distribution GNU/Linux à part entière, il permet aussi de gérer son système d’exploitation avec une approche déclarative et sans état. Guix est extrêmement personnalisable et bidouillable grâce à ses interfaces Guile (un dialecte du langage Scheme).
La publication fournit des images d’installation ISO 9660, une image pour machine virtuelle et un script d’installation pour installer le gestionnaire de paquets sur votre distribution GNU/Linux sans interférer avec celle‑ci. Les utilisateurs de Guix peuvent mettre à jour comme d’habitude en lançant guix pull.
La suite de la dépêche est une traduction de l’annonce officielle. Le « nous » utilisé dans la dépêche renvoie à l’équipe Guix, pas aux traducteurs.
Sommaire
- Bonus musical
- Sécurité
- Expérience utilisateur
- Lots, GNU/Hurd, images disques, services…
- Essayer, c’est l’adopter !
- Crédits
Nous sommes heureux d’annoncer la sortie de GNU Guix en version 1.2.0, juste à temps pour célébrer le huitième anniversaire de Guix !
La publication fournit des images d’installation ISO 9660, une image pour machine virtuelle et des archives pour pour installer le gestionnaire de paquets sur votre distribution GNU/Linux, soit à partir des sources, soit à partir des binaires. Les utilisateurs de Guix peuvent mettre à jour comme d’habitude en lançant guix pull.
Cela fait presque sept mois depuis la dernière version, pendant lesquels deux cents personnes ont contribué au code et aux paquets, et de nombreuses autres personnes ont contribué à d’autres tâches importantes : la revue de code, l’administration système, les traductions, la mise à jour du site Web, le mentorat à travers Outreachy, et bien d’autres !
Il y a eu plus de 10 200 commits durant cette période et c’est toujours un défi de résumer toute cette activité dans les notes de version.
Bonus musical
Avant d’aller plus loin, asseyez‑vous confortablement et lancez la lecture de cette chanson de publication très spéciale, Ode to One Two Oh (paroles) proposée par la sympathique équipe de Guix — voir les crédits plus bas !
Sécurité
Une avancée majeure dans cette version est la possibilité d’authentifier les canaux, ce qui fait sans doute aujourd’hui de Guix l’une des manières les plus sécurisées pour fournir un système d’exploitation. C’était le lien manquant dans notre « chaîne logistique logicielle » et nous sommes ravis qu’il soit désormais corrigé. Le résultat, c’est que guix pull et les commandes associées authentifient maintenant le code des canaux qu’elles récupèrent de manière cryptographique. Vous ne pouvez plus par exemple récupérer des commits non autorisés dans le dépôt officiel de Guix. Nous avons détaillé la conception et le code de cette fonctionnalité en juillet. Le manuel explique ce que vous devez savoir en tant qu’utilisateur et en tant qu’auteur d’un canal. Il y a aussi une nouvelle commande guix git authenticate pour pouvoir utiliser ce mécanisme dans des dépôts Git arbitraires !
En plus de cela, guix pull et guix system reconfigure détectent maintenant de potentiels retours en arrière du système ou de Guix et renvoie une erreur. Cela permet de s’assurer qu’on ne puisse pas vous tromper et faire revenir les logiciels de votre système à des versions antérieures, ce qui pourrait éventuellement réintroduire des vulnérabilités exploitables dans les logiciels que vous utilisez.
Avec ces nouvelles sécurités, nous avons ajouté un service de mise à jour non surveillées qui, en substance, lance guix pull && guix system reconfigure régulièrement. Des mises à jour non surveillées en toute quiétude.
Un autre changement important en termes de sécurité dont nous sommes très fiers est la réduction de l’ensemble d’amorçage à 60 Mio sur les systèmes x86-64 et x686, grâce à un travail acharné sur GNU Mes, Gash et d’autres logiciels associés.
Toujours sur le thème de la sécurité, le démon de construction et l’interface de programmation origin acceptent maintenant de nouvelles fonctions de hachage cryptographiques (en particulier SHA‑3 et BLAKE2s) pour les « dérivations à sortie fixe ». Jusqu’ici nous utilisions toujours des hachages SHA256 pour le code source.
Expérience utilisateur
Nous souhaitons que Guix soit accessible et utile pour une large audience, et ça a de nouveau été l’une des lignes directrices dans cette version. L’installateur graphique du système et le script pour installer Guix sur une autre distribution ont tous deux reçu des corrections de bogues et des améliorations en termes d’utilisabilité. Les nouveaux utilisateurs apprécieront le fait que guix help fournisse maintenant un aperçu clair des commandes disponibles, que les commandes guix soient moins verbeuses par défaut (elles n’affichent plus les longues listes de ce qu’elles vont télécharger), et que guix pull affiche une barre de progression lorsqu’il met à jour son dépôt Git. guix search, guix system search et les commandes similaires invoquent maintenant automatiquement un outil de mise en forme (less par défaut), ce qui règle un désagrément souvent perçu.
La nouvelle version propose des améliorations de performance à plusieurs endroits. L’utilisation du nouveau « compilateur de référence » qui est arrivé avec Guile 3.0.4 permet de réduire les temps de construction de Guix lui‑même, ce qui signifie aussi que guix pull est moins gourmand en ressources. Les performances se sont améliorées à plusieurs autres endroits et il y a encore du travail à venir.
Nous proposons encore plus de flexibilité à la ligne de commande, avec l’ajout de trois options de transformation de paquets --with-debug-info (pour toujours déboguer dans de bonnes conditions !), --with-c-toolchain et --without-tests. Les transformations sont maintenant sauvegardées dans le profil et rejouées avec guix upgrade. En outre, ces options opèrent maintenant sur tout le graphe de dépendance, ce qui inclut des entrées « implicites » et donc permet d’effectuer des transformations précédemment impossibles, comme :
guix install --with-input=python=python2 python-itsdangerous
Enfin, le nouveau module (guix transformations) founit une interface pour les options de transformation disponibles sur la ligne de commande, ce qui est pratique si vous voulez utiliser une telle transformation dans un manifeste.
Le manuel de référence a été étendu : il y a une nouvelle section « Pour démarrer », la section « Interface de programmation » contient plus d’informations pour celles et ceux qui écrivent des paquets. Nous avons ajouté des exemples de code à de nombreux endroits. Sur la copie en ligne du manuel, les identifiants dans ces bouts de code sont cliquables et renvoient au bon endroit dans le manuel de Guix ou de Guile.
Finalement, le manuel est entièrement traduit en français, en allemand et en espagnol, avec des traductions partielles en russe et en chinois. Guix lui‑même est entièrement traduit dans ces trois langues et partiellement traduit en onze autres langues.
Lots, GNU/Hurd, images disques, services…
Attendez, il y en a encore plus ! Si ce qui vous intéresse, c’est d’apporter des applications de Guix à des machines qui n’ont pas Guix, guix pack -RR prend maintenant en charge un nouveau moteur d’exécution « fakechroot » pour les lots repositionnables, avec la possibilité de choisir entre différents moteurs à l’exécution avec la variable GUIX_EXECUTION_ENGINE. Le moteur fakechroot améliore les performances par rapport au moteur proot, pour les hôtes qui ne prennent pas en charge les espaces de noms d’utilisateurs non privilégiés.
La prise en charge de la compilation croisée d’un système entier — comme dans guix system build --target=arm-linux-gnueabihf config.scm — a été améliorée. Avec tout un travail de portage à la fois pour les paquets et la machinerie de Guix System. Cela permet d’apporter le service hurd-vm — un système Guix sur GNU/Hurd compilé de manière croisée lancé dans une machine virtuelle sous GNU/Linux. À son tour, ce service nous a permis de travailler sur la prise en charge native de GNU/Hurd.
En parlant de cela, le nouveau module (gnu image) implémente une interface flexible aux images de systèmes d’exploitation. Depuis la ligne de commande, elle est accessible via guix system disk-image --image-type=TYPE. Plusieurs types d’images sont pris en charge : le format ISO 9660 compressé, le format qcow2 contenant des partitions ext4, ext2 avec les options de Hurd, etc. Cela est actuellement implémenté avec genimage.
En plus des services système déjà mentionnés, une douzaine de nouveaux services sont disponibles, dont un service pour Ganeti, un service pour LXQt, un service R Shiny, un service Gemini, et un service pour le Guix Build Coordinator.
Deux mille paquets ont été ajoutés, pour un total de plus de quinze mille paquets ; 3 652 ont été mis à jour. La distribution embarque GNU libc 2.31, GCC 10.2, GNOME 3.34, Xfce 4.14.2, Linux-libre 5.9.3 et LibreOffice 6.4.6.2 pour n’en citer que quelques‑uns. Il y a aussi un nouveau système de construction de paquets pour Maven (l’amorçage de Maven dans Guix a été le sujet d’une présentation lors des Guix Days la semaine dernière)
Le fichier NEWS liste des changements supplémentaires importants et des corrections de bogues qui pourraient vous intéresser.
Essayer, c’est l’adopter !
Vous pouvez télécharger cette nouvelle version et nous contacter.
D’ailleurs, notre ambassadeur chez Debian nous signale que vous pourrez bientôt lancer apt install guix si vous utilisez Debian ou une distribution dérivée !
Amusez‑vous bien !
Crédits
Merci à Ricardo Wurmus (grand stick, synthétiseur, percussions, voix et paroles), Luis Felipe (illustration), Vagrant Cascadian (paquet Debian, paroles) et Festival (voix de fond).
Aller plus loin
- Annonce officielle (76 clics)
- Manuel en français (88 clics)
- La chanson, « ode to one two oh » (Ogg Vorbis) (20 clics)
# Similaire à NixOS
Posté par tisaac (Mastodon) . Évalué à 9.
Au risque d'étaler mon incompréhension totale, quand je lis transactionnel et déclaratif, cela me fait penser à NixOS.
Ai-je bon si je pense qu'il y a des similarités avec NixOS?
Lesquelles ?
Quelles sont les différences entre les deux approches ?
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Similaire à NixOS
Posté par barmic 🦦 . Évalué à 3.
Il me semble que les 2 principales différence que c'est que guix est GNU compliant et qu'il utilise scheme.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Similaire à NixOS
Posté par roptat . Évalué à 10.
Alors, ça risque d'être un peu long (et biaisé : je contribue à Guix :)) donc oui, les deux distributions sont assez similaires. Guix est plus récente que Nixos (2012 contre 2002 si je me souviens bien) et est basée sur les mêmes principes, la thèse d'Eelco Dolstra. D'ailleurs Guix contient un tout petit composant de Nixos: le démon Nix. Tout le reste est complètement différent.
Avec Nix, il est nécessaire d'apprendre un nouveau DSL (le langage d'expression Nix), pour l'utiliser, le paramétrer, créer des paquets, … Guix demande d'apprendre un langage assez ancien, Scheme (plus précisément l'implémentation Guile de GNU). L'avantage de Guile, c'est son homoiconicité : les données et les programmes ont la même représentation. On s'en sert pour créer ce qu'on appelle des G-Expressions. En gros, au lieu d'utiliser le langage Nix pour concaténer des chaînes de caractères qui représentent des scripts shells (ou bien d'autres langages) à passer au démon Nix, on utilise Scheme pour créer des programmes Scheme à passer au démon Nix, ce qui de mon point de vue est bien plus propre.
De la même manière, on s'intègre un peu mieux avec le reste du système, notamment parce que le PID 1 est le Shepherd, écrit et configuré en Scheme. Pareil pour le démon de taches récurrentes mcron, écrit et configuré en Scheme.
Aillant eu plus de temps pour maturer, Guix propose aussi des interfaces de programmation de plus haut niveau. Si Nixos manipule directement des dérivations (des fonctions écrites en Nix), Guix propose d'utiliser des notions de plus haut niveau (paquets, origines, simili-fichiers, système d'exploitation, service, …) qui permettent entre autre l'héritage et ont une structure de base bien plus stricte (et donc compréhensible) qu'une simple fonction. Ces objets sont ensuite traduits en dérivation pour que le démon puisse faire son œuvre.
Guix prend aussi position idéologiquement et techniquement sur certains aspects : elle respecte les FSDG (Free Software Distributions Guidelines) et ne propose donc pas de logiciel non-libre. Elle insiste aussi beaucoup sur la reproductibilité (comme Nix) et la possibilité d'amorcer les logiciels. C'est une différence qui me tient beaucoup à cœur, même si ça veut dire qu'il y a moins de paquets qui arrivent à passer les standards de qualité de Guix. On peut toujours créer un canal pour les paquets qui n'ont pas encore atteint la maturité suffisante pour passer ces critères.
[^] # Re: Similaire à NixOS
Posté par karteum59 . Évalué à 6. Dernière modification le 29 novembre 2020 à 14:21.
C'est là que j'ai un désaccord: je soutiens le fait de distinguer clairement libre et non-libre (comme Debian, où tout ce qui est non-libre est proprement séparé dans non-free), mais avoir un kernel qui refuse de charger les modules non-libres ou une distro qui ne permette pas d'utiliser un repository de softs non-libres me pose clairement un souci : ma liberté c'est aussi celle d'utiliser des logiciels non-libres, par exemple juste pour faire fonctionner mon matériel… (bon après je n'ai jamais utilisé Guix et ses concepts et son approche me semblent extrêmement intéressants. Je base ce commentaire sur ce que j'ai vu de Triquel/gNewSense vs Debian => si je me trombe sur ma compréhension des FSDG n'hésitez pas à répondre)
[^] # Re: Similaire à NixOS
Posté par roptat . Évalué à 4.
Effectivement le noyau n'arrive pas à charger de modules non libres, mais ce n'est pas pour une raison idéologique, mais un problème dans la manière de générer le noyau sans blobs que personne n'a encore corrigé. Les FSDG n'interdisent pas aux utilisateurs d'installer des logiciels non libres s'ils le souhaitent, mais interdisent de proposer ces choses-là dans la distribution.
Dans le cas de Trisquel, tu peux quand même installer des paquets venant de Debian, ou récupérer un .deb ou une archive d'un logiciel privateur depuis son site officiel. Guix a un système de canaux, qui permettent aussi de proposer des logiciels non libres, même s'il n'y a pas de publicité officielle.
[^] # Re: Similaire à NixOS
Posté par karteum59 . Évalué à 2.
Je n'ai pas compris ce que ça voulait dire (notamment "que personne n'a encore corrigé)…
Le noyau Linux est parfaitement capable de charger des modules non-libres (avec ou sans blobs à côté). J'ai par contre compris que le noyau Linux-libre (nécessaire pour FSDG) faisait précisément le choix (pour raison idéologique) d'être plus restrictif là dessus.
[^] # Re: Similaire à NixOS
Posté par roptat . Évalué à 5.
Ce que j'ai compris, c'est que linux-libre retire tous les blobs binaires et modules non libres du noyau, donc par défaut tu as un noyau complètement libre (d'où le nom). Ça, ça relève de l'idéologie. Par contre, t'empêcher de construire ton propre module qui contient un composant non libre et le charger, ça relève d'un bogue dans la manière dont le noyau linux-libre est obtenu, pas de l'idéologie.
[^] # Re: Similaire à NixOS
Posté par karteum59 . Évalué à 5.
Je lis ici
[^] # Re: Similaire à NixOS
Posté par anaseto . Évalué à 6.
Perso, ce que j'ai jamais compris, c'est pourquoi ils ne font pas, comme sur OpenBSD, la différence entre les blobs au sens microcode qui est chargé sur un composant hardware particulier, et les drivers non libres (les seuls que les gens appellent blobs dans le monde BSD). Les seconds s'exécutent dans le noyau et sont vraiment problématiques pour plein de raisons, mais les premiers s'exécutent dans du matériel spécifique et n'apportent pas vraiment de problèmes qui n'existent pas déjà : que le microcode soit reçu après le démarrage ou déjà présent dans le matériel, ça ne change pas grand chose au final, à moins d'avoir du matériel libre à la base.
[^] # Re: Similaire à NixOS
Posté par karteum59 . Évalué à 2.
Hmmm… la frontière est parfois floue (e.g. la partie modem des SoCs Qualcomm/Mediatek qui peuvent accéder à la RAM du application processor. C'est une des motivations de Librem et Pine64 pour avoir un modem séparé du CPU)
(Cela dit : c'est là une question d'architecture hardware/firmware, et ce genre de SoC ne fonctionnera de toute façon jamais avec linux-libre).
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 5.
Dans le vieux débat Debian vs FSF (rms pour être exact), vous êtes un côté de Debian. Très bien, soit! Je ne connais pas l'origine de la brouille qui exclut Debian de la liste des distributions dites libres mais ca sent la brouille personnelle entre Stallman (rms) et un project leader Debian de l'époque. Bref!
(Pour info, je suis contributeur Guix et personnellement je préfère l'organisation pragmatique main, contrib et non-free que le tout ou rien. Très bien aussi, soit!)
Cependant, les FSDG ne définissent pas "votre" liberté mais définissent ce qu'un logiciel doit respecter pour être considérer comme libre (selon lesdits FSDG). La liberté dans votre phrase « ma liberté c'est aussi celle d'utiliser des logiciels non-libres » n'a rien à voir avec les FSDG mais uniquement avec le cadre légal du pays dans lequel vous vivez.
Les projets GNU ne transigent pas. Est-ce un bien ou un mal ? Vaste question philosophique et politique. Question qui se cristallise dans le débat Debian vs FSF.
Maintenant, concernant Guix, rien ne vous empêche techniquement d'utiliser le noyau que vous voulez. Par défaut, le distribution Guix vient avec un noyau linux-libre. Si vous voulez autre chose, oui il faudra mouiller un peu la chemise. Par ailleurs, il existe des canaux (channels, qui sont des dépôts de logiciels) non-libres selon les FSDG, comme Nonguix.
Pour finir, Guix fonctionne au dessus de n'importe quelle distribution. Donc vous pouvez utiliser Debian pour faire fonctionner votre matériel et utiliser Guix pour tout le reste. (C'est ce que je fais principalement.)
[^] # Re: Similaire à NixOS
Posté par mothsART . Évalué à 2.
Je pense que je ferais le pas Guix un de ses 4 un peu pour le fun au début et peut-être en complément de Debian/Nix.
En dehors du fait que je sois sceptique sur certains points, je trouve ce projet bien plus novateurs que pas mal d'autres. Sans doute un des seuls vrais candidats (avec Nix) pour remplacer "apt", "pacman" ou autre gestionnaires vieillissants mais également fournir de meilleurs solutions que Snap , Flatpack et cie.
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 4.
Personnellement, je pense aussi que le changement de paradigme que Nix a apporté est vraiment novateur. D'ailleurs le paquet Guix vient tout juste d'entrer dans Debian experimental, bientôt
apt install guix.Et je recommande cette présentation à DebConf18 pour les Anglophones. Et aussi Seeing debian through a functional lens par Joey Hess à DebConf14 (je ne trouve plus les archives mais je crois que c'est disponible sur Youtube).
Concernant Nix, j'attends de voir ce que Nix 2.0 va être. ;-)
[^] # Re: Similaire à NixOS
Posté par mothsART . Évalué à 7.
Déjà merci pour cette dépèche très rafraîchissante sur une distrib peu connu !
Connaissant un peu mieux Nix, je ne serais sans doute pas très objectif non plus.
Là ou tu vois une faiblesse, je vois une qualité.
De toute façon, tu trouveras peu de développeur Scheme (qui ne connaisse ou ne participe pas déjà à Guix) et du coup, ça demande de toute façon d'apprendre un langage pour l'occasion.
Le fait d'avoir un DSL plutôt qu'un langage complet me parait justement plus approprié : on ne s'étale pas, on va a l'essentiel et y'a pas 36 façon de faire la même chose donc sans doute plus simple en terme de review.
En effet, dans l'absolu c'est mieux. Dans les faits ça reste minimes à mon sens.
Ça, pour moi, c'est rédhibitoire. Qu'on cloisonne les choses comme dans Debian, ok mais ne rien supporter de non libre, c'est forcément se positionner sur un marché de niche.
Faut savoir être pragmatique ! Je préfère avoir un système à 95% libre mais "utilisable" parce que mon GPU est supporté, que je peux utiliser ponctuellement tel logiciel etc.
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 5.
Je vais fournier un contre-exemple peut-être. :-)
Nix et Guix travaillent de concert pour archiver automatiquement dans Software Heritage (SWH). Ca se fait via la génération d'un fichier nommé
sources.jsonqui est ingéré par SWH. Grosso modo, côté Guix c'est en construisant le site web guix.gnu.org que ce fichier est généré et tout le code est là :website/apps/packages/builder.scm#n96
Rien de plus. Maintenant, comparons avec ce que Nix doit faire :
https://github.com/nix-community/nixpkgs-swh
donc des Nix expressions qui générent des fichiers qui sont ensuite parsés par du Python et le tout recollé avec du Shell.
Donc je ne suis pas du tout convaincu par « y'a pas 36 façon de faire la même chose donc sans doute plus simple en terme de review » et surtout je ne sais pas si on peut dire que c'est minime…
Voir mon commentaire là.
[^] # Re: Similaire à NixOS
Posté par mothsART . Évalué à 2.
Excuse moi si je me trompe mais ce process d'archivage n'a rien à voir avec le langage Nix utilisé pour du packaging.
C'est effectivement ultra critique mais c'est touché (et revue) par très peu de personnes, à la diff d'un fichier Nix qui va décrire l'empaquetage (en somme, tout ce qui est dans https://github.com/NixOS/nixpkgs/tree/master/pkgs) d'un logiciel en particulier.
Le python/shell (voir même peut-être la partie Nix) pourrait très bien être remplacé par du OOCaml, du Rust ou autre langage un peu plus rigoureux et l'affaire serait close.
Justement, Nix ne fait pas le parsing car il ne sait pas faire et comme déjà dit : tant mieux, car c'est un DSL (même si cette notion est vague).
Que la partie core du projet soit un mélange de C, Rust, Python et de Bash ne me pose pas de soucis outre mesure du moment que pour l'empaqueteur final n'a qu'à gérer un fichier nix réduit à peau de chagrin.(du genre https://github.com/NixOS/nixpkgs/blob/13a3e5023192b62d6c5662c37549d8bb9e5e6a28/pkgs/applications/editors/geany/default.nix)
Alors, tout n'est pas parfait, j'en conçoit. Ce genre de choses devraient être évité/remplacé dans la mesure du possible : https://github.com/NixOS/nixpkgs/blob/e66ba6bd4619068541dd0446e2c69f2a7cba08a2/pkgs/applications/graphics/ImageMagick/default.nix#L83
mais ça reste suffisamment cloisonné pour rester "acceptable".
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 2.
Je pense que c'est là qu'il y a une grande différence de philosophie. Guix est en fait une bibliothèque Scheme avec une API. Donc tu peux facilement étendre, modifier, adapter en Scheme. Il y a une continuité entre la partie core et les scripts que tu peux écrire pour transformer tes paquets, utiliser des services externes, etc.
Par exemple dans cette tentative, j'interroge un service externe des fermes de calculs Guix pour lister les paquets non-reproductibles par type de constructeurs (build system, genre CMake, OCaml, Haskell, etc.).
Quelque part, c'est un peu la même philosphie qu'Emacs : c'est le même langage utilisé par le core qui permet aussi de configurer. Cela donne l'extensibilité. Après, certes on adhére ou non car c'est du Lisp. :-)
[^] # Re: Similaire à NixOS
Posté par lewo . Évalué à 3.
Je peux confirmer qu'un langage généraliste aurait été plus pratique que Nix pour réaliser ce genre de tâche!
Cependant, il est "presque" possible de générer ce fichier avec Nix uniquement: un bout de Python est utilisé pour palier à une petite
builtinactuellement manquante (hashToSRI). Le reste du Python et Bash n'étant, en fait, pas utilisé pour générer le fichiersources.json.[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 3. Dernière modification le 30 novembre 2020 à 16:45.
salut lewo, je ne savais pas que tu moulais ici. :-)
Pour la petite histoire, lewo a fait la partie Nix et j'ai fait la partie Guix. Et on a échangé sur la question.
Merci pour les précisions. Si tu enlèves le "reste du Python et Bash", le fichier
sources.jsonsera produit, mais alors à quoi cela sert-il ?[^] # Re: Similaire à NixOS
Posté par lewo . Évalué à 3.
Héhé, uniquement pour lire les articles sur Guix;)
Oui, et c'est super qu'on puisse faire avancer le schmilblick ensemble!
C'est pour générer qq stats, un peu de mise en page et implémenter le "cron job".
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 2.
Ah cool! J'avais un truc pour avoir le nombre de paquets venant de source tar vs Git vs Hg vs SVN vs CVS. Tiens je vais ajouter aussi les hosts. :-)
[^] # Re: Similaire à NixOS
Posté par mothsART . Évalué à 1.
Héhé, tout s'éclaire. Intéressant !
[^] # Re: Similaire à NixOS
Posté par mothsART . Évalué à 2.
Autre point qui me chiffonne : pas de gitlab/github/bitbucket mais savannah. Je sais que ça va encore un peu à l'encontre du "Libre" mais bon, derrière on se prive d'une tonne d'outils modernes (issues, git-flow, ci etc.) et de visibilité.
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 2.
Le workflow est basé sur le emails. Avec ses avantages et ses inconvenients (voir tous les articles LWN sur le sujet).
Le projet Guix a écrit un front-end pour l'antique Debbugs.
Le projet Guix a sa propre CI nommé Cuirass avec des optimisations pour l'infrastructure sur laquelle ca tourne (voir Fixing the CI).
Il y a du bon et mauvais dans cette approche. Quelque part, c'est surtout une histoire de philosophie, plus ou moins tirée de la culture hackeur. M'enfin. :-)
[^] # Re: Similaire à NixOS
Posté par mothsART . Évalué à 2.
Très orienté GNU : on fait tout nous même.
C'est un parti pris.
Dans l'absolu c'est une bonne idée, dans les faits : ça occasionne des projets qui avancent au ralenti et qui n'attire pas vraiment les jeunes générations de devs.
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 2.
N'est-ce pas pour un projet GNU? ;-)
[^] # Re: Similaire à NixOS
Posté par nokomprendo (site web personnel) . Évalué à 6.
Salut,
Juste sur ces 2 points, je crois que Nix n'est pas un DSL mais un vrai langage turing-complet et que Nixpkgs apporte, en plus d'une logithèque pour Nix, des fonctions de plus haut-niveau pour construire des paquets Python/Haskell/etc, des images Docker, etc.
Sinon, merci pour la dépêche et le travail sur Guix, qui est effectivement bien plus que juste un Nix en Scheme et en 100% libre.
[^] # Re: Similaire à NixOS
Posté par lpgl . Évalué à 3.
Scheme est un excellent langage. je trouve cela pas aberrant du tout de choisir un language de haut niveau pour construire une distribution GNU/Linux. Il faut voir les complications que cela a engendré d'avoir des distribs construites autour d'un shell primitif, même si bash a évolué ! Au fond c'est quand même d'un autre âge…
Par contre le problème que j'ai rencontré en cherchant à utiliser GUIX (distrib ou gestionnaire de pacquets) est son instabilité. Donc à chaque fois j'ai fait machine arrière car la stabilité est une qualité première nécessaire pour ce genre de fonctionalité.
[^] # Re: Similaire à NixOS
Posté par nokomprendo (site web personnel) . Évalué à 2.
Si la qualité d'un langage était objective, on n'en aurait pas autant. Nix et bash sont prévus pour des usages bien particuliers et s'en sortent pas si mal dans leur domaine respectif. Que reproches-tu à bash à part d'être "d'un autre âge" (au passage bash est moins vieux que scheme).
Quels genres d'instabilités ? J'ai juste un peu bidouillé avec Guix dans une VM mais je n'ai pas observé cela (pourtant ça m'arrive de péter des distributions conseillées aux débutants).
[^] # Re: Similaire à NixOS
Posté par lpgl . Évalué à 3.
Scheme est simple et puissant et a une des particularités - comme tous les languages de la famille LISP - que n'ont pas encore les autres langages modernes : l'abstraction syntaxique (qui est pourtant un atout énorme voire indispensable.)
C'est plutôt de construire une distrib autour d'un langage type shell que je trouve d'un autre âge : ces langages n'ont pas de structures de données assez évoluées pour permettre de faire des choses complexes (du moins sans que cela ne deviennent extrêmement lourd).
As-tu déjà essayé de faire un programme un peu gros en shell ? C'est trop lourd et abscons. À éviter.
Sinon bash en lui même c'est un bon shell.
Au niveau instabilité de GUIX c'est que rapidement dans son utilisation au jour le jour je suis confronté à un échec d'installer un paquet, faire une maj d'un paquet, voir même d'installation de GUIX etc !
Exemple typique : j'ai essayé de faire un 'guix pull' suite à l'annonce de la nouvelle version et ça a cassé au bout de qqs minutes. Si j'essaie demain, cela va peut-être marcher. Et après demain peut-être plus. C'est cela les pbs d'instabilité que j'ai rencontré. Pour moi c'est rédhibitoire, j'ai pas pu passer à GUIX et pourtant j'aurai trop aimé. J'espère que ça évoluera avec le temps.
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 3.
En tant que contributeur à Guix et en particulier sur la partie release v1.2 (sachant que Guix est une rolling-release), je suis fortement intéressé par vos retours.
Installation de Guix signifiant "Guix distro" via l'installeur, est-ce cela ?
Ou est-ce "Guix on foreign distro" via le script d'installation ?
À quel commit êtiez-vous lorsque vous avez fait
guix pulllors de la sortie de la v1.2 ? Je suis vraiment curieux parce que je n'ai pas réussi à casser lors de mes tests.Par ailleurs, depuis la sortie de la
v1.0(mi-2019), le mécanisme deguix pullest stable et c'est très rare qu'il casse. J'utilise Guix tous les jours pour le travail et le gestionnaire de paquets est en production sur au moins 3 clusters de calculs francais donc je pense que l'on peut dire que Guix est stable. Vraiment je suis très curieux de vos mauvaises expériences, pour résoudre soit des bogues, soit une mauvaise config de votre côté.En revanche, ce qui est vrai, ce que le temps d'exécution de
guix pullet la consommation de ressources (CPU) sont difficiles à prévoir. Un jour ca va et un autre la machine calcule beaucoup plus. Personnellement, j'espère des améliorations pour v1.3 ou v1.4.Concernant les paquets cassés, c'est très rare. Ca arrive mais beaucoup moins que pour Nix par exemple. En revanche, Guix est victime de son succès (relatif! ;-)) ; la CI passe mal à l'échelle et ne construit pas assez vite les changements. La mesure du problème en terme d'usabilité (tout compiler from scratch n'étant pas possible) est pris en compte et aujourd'hui il y a du travail de fond qui est fait pour résoudre le problème. (Voir Fixing the CI.)
[^] # Re: Similaire à NixOS
Posté par nokomprendo (site web personnel) . Évalué à 4.
C'est quoi l'intérêt de ce genre d'attaques gratuites ? Et il y a des stats sérieuses à ce sujet (et qui tiennent compte que Nix a beaucoup plus de paquets) ?
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 2.
Désolé si c'est pris comme attaque, ca ne l'était pas du tout.
Peut-être que je me trompe, de ce que je sais, c'est qu'il y a beaucoup plus de paquets dans Nix et la qualité de l'empaquettement est parfois variable. N'étant pas un utilisateur de Nix, non je n'ai pas de stats sur le sujet. Bref, si mes propos froissent certains, je les retire et je présente mes excuses. Oulà, je ne pensais pas autant marcher sur oeufs.
En revanche, je traque les paquets cassés dans Guix donc je peux affirmer que oui c'est très rare, même si ca arrive.
[^] # Re: Similaire à NixOS
Posté par mothsART . Évalué à 1. Dernière modification le 30 novembre 2020 à 18:01.
Il m'en faut plus pour être "froissé" et là n'est pas la question.
Je considère juste qu'il faut tendre vers l'impartialité.
Il faut toujours garder en tête que rien n'est "parfait".
A titre d'exemple, j'ai porté quelques softs sous Nix qui étaient déjà empaqueté sous debian.
En le faisant de manière brut (juste édition d'un fichier nix), le soft se lançait mais certaines choses ne fonctionnaient pas bien : mon applicatif appelait des fichiers avec des chemin absolu selon les conventions d'arborescence Unix au lieu de passer par des chemins relatifs.
J'ai donc adapté mon code.
Si le paquet avait été validé tel quel dans la distrib sans que je m'en aperçoive, est-ce que ça aurait été un soucis de Nix ou de l'applicatif ?
Je présume que le soucis aurait été identique sous Guix.
Après, il faut se rendre à l'évidence : même si la partie packaging est purement fonctionnel (pas de bash ni aucun truc avec effet de bord) si l'applicatif derrière est très permissive et pas réfléchit pour… ça pourra pas être parfait !
Mais d'un point de vue utilisateur, l'amalgame est vite fait : à tord ou a raison.
[^] # Re: Similaire à NixOS
Posté par lpgl . Évalué à 1.
Merci c'est gentil !
Mon expérience (désolé pour l'imprécision de mémoire!) :
- j'utilise depuis x années GENTOO come distribution GNU/Linux. Ce qui m'a bloqué à répétition pour GUIX c'est le critère : je veux une distribution GNU/Linux qui ne me bloque pas mon travail de façon impromptue (perdre du temps sans l'avoir prévu à réparer la distrib alors que j'ai qq chose d'urgent à faire)
- je crois que j'ai déjà installé GUIX distrib et cela a cassé peu de temps après donc abandon.
- j'ai essayé l'installation de GUIX comme gestionnaire de paquet sur GENTOO et UBUNTU -> abandon : j'ai essayé via le script d'installation mais cela a cassé (je crois que c'était pour UBUNTU). Du coup j'ai essayé une installation via les sources et le manuel GUIX.
Actuellement sur GENTOO j'étais au commit e85d7ed60905f059686650c3ab21b42500f09351 quand j'ai fais le "guix pull" suite à l'annonce de sortie v1.2, et que cela n'a pas abouti.
[^] # Re: Similaire à NixOS
Posté par roptat . Évalué à 3.
Je sais par exemple que guix pull est assez sensible aux problèmes réseau, ce qui fait que de temps en temps, si le serveur de substitut de répond pas, ou que le réseau a un petit couac, ça va planter, en affichant un vilain message d'erreur. En général, il suffit de retenter derrière et ça passe. Est-ce que c'est ce qui aurait pu arriver ?
En cas de problème avec Guix, il n'y a pas de problème ;). Si une mise à jour ne s'effectue pas, pas de souci : c'est comme si on n'avait rien fait, on ne se retrouve pas dans un état intermédiaire cassé. Si une mise à jour fonctionne mais que le résultat n'est pas stable, il suffit de retourner en arrière :
guix package --roll-back. Franchement la seule fois où j'ai pété une installation de Guix System, c'est le disque qui est mort '[^] # Re: Similaire à NixOS
Posté par lpgl . Évalué à 1.
Cela arrive-t-il souvent ?
Est-ce que le message d'erreur est explicite en ce cas ?
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 2.
Merci pour le retour d'utilisation que vous avez fait, ca aide. :-)
En ce moment, oui cela arrive parce que la ferme de construction patine certaines heures de certains jours. La fréquence est difficile à dire.
Hélàs, non! C'est un des problèmes de Guix. Les messages d'erreur sont souvent incompréhensibles pour ne pas dire cryptés.
Le mieux est de prendre 5min, de copier/coller dans un email le message, le commit (guix describe) et d'envoyer à help-guix@gnu.org. Je concois que ce que cela implique.
[^] # Re: Similaire à NixOS
Posté par lpgl . Évalué à 2. Dernière modification le 30 novembre 2020 à 21:39.
OK, donc c'est cela qui m'a bloqué je pense : me retrouver à répétition complètement le bec dans l'eau avec qq chose qui plante.
Avec GENTOO j'ai l'habitude que la distrib se plaigne (c'est même devenu assez pittoresque avec python qui occupe une place proéminente dans le volume de soft total et les pbs ahurissant de retro-compatibilité qu'il y a entre python version x.y et python version u.z). Mais au moins avec les messages d'erreur on s'en sort assez bien et suffisamment vite.
Il faut absolument améliorer cet aspect de GUIX et/ou fournir un bon tuto pour débutant avec les erreurs GUIX…
Je vais essayer dans le futur d'étudier sérieusement GUIX (source et manuel) avant de tenter à nouveau de l'utiliser à la place de GENTOO.
[^] # Re: Similaire à NixOS
Posté par mothsART . Évalué à 1.
C'est déjà bien de le reconnaître.
Le fait d'avoir réfléchit à un outil graphique compense (ça manque cruellement dans Nix).
[^] # Re: Similaire à NixOS
Posté par mothsART . Évalué à 2. Dernière modification le 30 novembre 2020 à 14:12.
Oups, bavure ?
On peux rester courtois et ouvert d'esprit plutôt que de partir sur des facilités ?
Sinon, mes paquets Nix vont très bien, merci.
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 2.
Ma réponse est plus haut. :-)
[^] # Re: Similaire à NixOS
Posté par lockidor . Évalué à 9.
Euh… franchement ? Tout ?
(Lire la suite en remplaçant
,par backtick et€par dollar)La syntaxe hyper-pointilleuse, les types inexistants, les bidouilles à base de «
[est en fait une commande », les espaces significatifs partout, quand mettre des ; ou des \, les € pour la lecture mais pas l'assignation, les subtilités entre,,et€(), les subtiles différences entre[et[[, pas d'arguments nommés pour les fonctions, seulement€1,€2, … (bon courage pour relire la fonction trois ans après),function f { ... }vs.f() { ... },for i in {1..10}mais pasfor i in {1.. €i}parce que lol l'ordre d'évaluation (qui est une merveille à lui tout seul),€pipovs.€{pipo}vs."€{pipo}", et ça continue encore et toujours.[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 2.
Pour fixer les idées sur les problèmes, ce projet de Recherche me semble pertinent:
https://www.irif.fr/~treinen/colis/
Et donc tous les bogues qu'ils ont rapportés :
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=colis-shparser;users=treinen@debian.org
[^] # Re: Similaire à NixOS
Posté par nokomprendo (site web personnel) . Évalué à 2.
D'après le descriptif du projet :
Il me semble que c'est justement là où NixOS utilise le langage Nix et non bash.
Après, je suis assez d'accord que bash n'est pas adapté pour des gros programmes, mais pour des petits scripts simples, c'est bien pratique.
[^] # Re: Similaire à NixOS
Posté par Guillaum (site web personnel) . Évalué à 4.
Un DSL peut être un langage turing-complet, c'est juste un langage crée pour un besoin spécifique. Contrairement à un langage générique qui ne fait pas de supposition sur le besoin d'application.
Et c'est hyper flou (au moins autant que la difference entre POO et fonctionel, ou langage de script versus vrai programme). Les templates C++ sont un DSL (c'est fait pour faire de la manipulation de type) et sont pourtant considérés turing-complet (https://rtraba.files.wordpress.com/2015/05/cppturing.pdf). Est-ce que les C est un langage génerique, ou un DSL adapté à la programmation système bas niveau ? Est-ce que Haskell est un langage générique, ou un DSL adapté à la création de compilateur ?
Et parlons des EDSL, des DSL "embarqués" dans un langage. Quel est la différence entre un EDSL et une librairie avec une API bien pensée ?
Bref, pour moi c'est encore un de ces concept peu défini en informatique que tout le monde utilise sans que personne ne soit vraiment d'accord sur la définition.
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 1.
Voir le commentaire.
Aujourd'hui, le langage Nix a ses propres problèmes, que le langage Guix n'a pas. Voir Nixcon 2020 pour lesdits problèmes : ca et ca, entre autres.
Commentaires biaisés à ces sujets :
https://yhetil.org/guix-devel/86d00evkmr.fsf@gmail.com
Et contrairement à Nix, il y a plus d'abstraction dans le langage Guix:
https://yhetil.org/guix-devel/87ft607e1t.fsf@gnu.org
[^] # Re: Similaire à NixOS
Posté par nokomprendo (site web personnel) . Évalué à 2.
Merci pour le lien. Juste pour info, dans sa présentation, Eelco Dolstra mentionne ces problèmes pour introduire la solution qu'il a implémentée.
Désolé mais je pense que je vais arrêter de commenter. Le concept derrière Guix/Nix est vraiment cool et mérite à être mieux connu. Mais là ça commence à tourner au projet qui aura la plus grosse et j'ai pas envie de participer à ça.
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 2.
Oui, j'ai aussi regardé la vidéo. Et d'ailleurs, les citations que j'ai pointées sont issues de discussions dans la communauté Guix pour savoir justement comment améliorer ou appliquer certaines idées, etc.
Je suis désolé. Ce n'est pas le but. On demande quelle est la différence avec Nix. Et la principale, c'est le langage. Sachant que c'est mon opinion mais je pense que c'est aussi le point faible de Nix.
Maintenant, si on veut mettre en avant les points faibles de Guix, j'ai aussi une opinion : documentation Scheme éparse, courbe d'apprentissage un peu raide, des lourdeurs dûes à GNU, etc.
Moi aussi je pense que le paradigme fonctionnel pour la gestion des paquets (ou services) mérite d'être mieux connu et diffusé. Peu importe l'outil. :-)
[^] # Re: Similaire à NixOS
Posté par nokomprendo (site web personnel) . Évalué à 2. Dernière modification le 30 novembre 2020 à 18:38.
Pas de soucis. C'est juste que je ne supporte pas qu'on extrait une partie d'une source qui justement essaie de brosser plus large. Mais j'avoue que je suis limite psycho-rigide là dessus, désolé.
Pour en revenir à Guix 1.2.0, je l'ai installé dans une VM et l'installeur semi-graphique est vraiment cool. Je vais essayer de me remettre dans le langage et dans le système de paquets, à l'occasion.
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 1.
Chouette ! Merci pour le retour. N'hésitez pas demander. :-)
[^] # Re: Similaire à NixOS
Posté par zimoun . Évalué à 1.
En plus des explications de roptat.
Ludo qui a initié le projet Guix était un contributeur de Nix. D'ailleurs Guix = Guile + Nix. Donc la philosophie des 2 projets est celle de la thèse de Eelco Dolstra : appliquer les paradigmes de la programmation fonctionnelle à la gestion de paquets.
Pour faire simple, disons que GNU Guix commence initialement en 2012 par utiliser Scheme à la place des Nix expressions pour générer des dérivations. Le
guix-daemonqui est l'élément qui digère ces dérivations est donc repris dunix-daemon.Depuis 2012, les démons ont évolués. À ma connaissance, aucun des développements du démon côté Nix ont été portés dans le démon de Guix. Et celui de Guix a aussi évolué.
Un marronnier est d'ailleurs la réécriture de ce démon en Scheme. ;-)
Les autres commentaires discutent l'intérêt de Scheme par rapport au "langage Nix+Bash".
# Couteau suisse pour développeur
Posté par Rednosehacker . Évalué à 4.
Je me suis lancé très récemment dans le développement d'une application web avec le langage de programmation Guile.
Guix est vraiment un élément central dans cette optique :
- gestion des dépendances de mon application
- création d'environnements virtuels pour développer
- assistante à la chaîne de construction (configure, make et compagnie).
- création de VM et conteneurs pour mes tests
- déploiement sur machine distante (avec reconfiguration des services, mise à jour de l'app…)
Et tout ça avec une seule techno. Pas besoin d'apprendre à utiliser une multitude d'outils. Une fois qu'on s'est familiarisé avec, la productivité est au rendez-vous !
[^] # Re: Couteau suisse pour développeur
Posté par fabrices . Évalué à -5.
Faut dire que Guile c'est à l'informatique ce que la burqua est à … en plus ça automatise https://www.poudreverte.org dans le cloud 4.0
-> Je retourne lire les articles sur PHP et Raku …
[^] # Re: Couteau suisse pour développeur
Posté par zimoun . Évalué à 2.
Oui, et c'est valable pour n'importe quel langage. J'ai exactement la même expérience au sujet de R et Python.
(N'importe quel langage c'est un peu excessif. :-) Javascript et Node sont très mal représentés par exemple.)
# Une doc sur les commandes Guix - Nix ?
Posté par nokomprendo (site web personnel) . Évalué à 3.
Est-ce-qu'il existe une doc expliquant à un utilisateur de Nix quelques commandes équivalentes pour Guix, et réciproquement (dans le genre de https://wiki.archlinux.org/index.php/Pacman/Rosetta#Basic_operations) ?
[^] # Re: Une doc sur les commandes Guix - Nix ?
Posté par roptat . Évalué à 1.
Pas à ma connaissance, mais ça serait super chouette. Il faudrait voir comment faire ça, parce qu'à mon avis ça a autant sa place dans la documentation de Guix que dans celle de Nix. Du coup, comment synchroniser les deux et s'assurer que l'une ne reste pas derrière l'autre ?
[^] # Re: Une doc sur les commandes Guix - Nix ?
Posté par nokomprendo (site web personnel) . Évalué à 5.
Effectivement, ce serait bien d'avoir une doc "officielle" et synchronisée des 2 côtés mais ça doit être difficile à faire en pratique.
Sinon ça pourrait être dans une page "Nix/Guix for Guix/Nix users" des docs respectives, ou dans un wiki (par exemple, https://nixos.wiki/), ou même juste un endroit indépendant dans un premier temps (une dépêche linuxfr par exemple ?).
Perso, je pensais faire un journal sur un petit cas d'utilisation, en montrant à la fois avec Nix et avec Guix. Ca peut peut-être servir de première base pour quelque chose de plus intéressant ensuite.
[^] # Re: Une doc sur les commandes Guix - Nix ?
Posté par zimoun . Évalué à 1.
Je me rappelle quelque chose que vous aviez fait ici sur Nix et une petit appli web. Puis j'avais donné en commentaire quelques éléments pour refaire avec Guix. Mais ce n'était pas fini.
Peut-être que ca vaudrait le coup de le faire en tandem avec références croisées dans la doc de Guix et celle de Nix. Concernant Guix, j'imagine où ca pourrait aller. Concernant Nix, je ne connais pas les us et coutumes. :-)
[^] # Re: Une doc sur les commandes Guix - Nix ?
Posté par nokomprendo (site web personnel) . Évalué à 2.
Ah oui exact, j'avais complètement oublié cet article (https://linuxfr.org/news/gestion-de-paquets-et-devops-avec-nix-tour-d-horizon-sur-un-cas-concret) mais ce serait effectivement intéressant de terminer la version Guix, ou de faire quelque chose de similaire sur un exemple plus simple.
Pour une doc en tandem, je ne suis pas très impliqué dans le projet NixOS donc peut-être qu'ils seraient intéressés, mais ça me parait difficile à première vue.
Mais s'il y a moyen de faire facilement une page du côté de Guix et qu'un utilisateur de Nix peut proposer facilement des modifs, ce serait déjà super.
# Interface graphique
Posté par geekborg . Évalué à -2.
C'est bien beau Guix mais moi je vais attendre que ça tourne dans une interface graphique du style Discover ou Pamac pour tester la bête.
[^] # Re: Interface graphique
Posté par zimoun . Évalué à 1.
Auriez-vous des liens ? Pour voir à quoi ca ressemble. Mon moteur de recherche me renvoie trop de faux-positifs.
Une GUI pour gérer ses paquets et autres, il y a des expérimentations mais encore rien à vraiment recommander.
Et pour les utilisateurs Emacs, il y le front-end Emacs-Guix disponible via
guix install emacs-guix. Cependant, il manque un peu d'amour et quelques fonctionnalités sont cassées. Aide bienvenue. :-)# Illustration trop lourde
Posté par Stéphane Ascoët (site web personnel) . Évalué à 1.
Bien que ne voyant pas le rapport de celui-ci avec le sujet, j'aime bien le dessin d'illustration qui fait "BD de science-fiction". Mais celui-ci est bien trop gros: il alourdit terriblement la page d'accueil DLFP
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.