roptat a écrit 45 commentaires

Le premier livre, LFS, se termine en un week-end avec l'expérience, voire une grosse journée. Pour la première fois, compter plutôt une semaine et un échec :)

Il sort une nouvelle version tous les 6 mois.

Le but du projet est de créer un système Linux à partir de zéro, et donc dans les premiers chapitres, il est demandé de faire de la place pour créer une partition dédiée au projet. Les premières étapes nécessitent d'utiliser une distribution hôte pour avoir les outils nécessaires à compiler le nouveau système. Une fois le système créé, il n'y a plus de distribution hôte : on peut simplement redémarrer sur le système LFS (ou redémarrer sur la distribution hôte, au choix).

Pour l'interface graphique, c'est expliqué dans le livre suivant, BLFS. En fait une fois terminé le premier livre, le système est… minimaliste. Il démarre en mode console avec tout juste bash et un compilateur C. BLFS est nécessaire pour ajouter tous les programmes dont tu auras besoin.

Tu peux télécharger le livre à partir d'ici : https://fr.linuxfromscratch.org/lfs/telecharger/

ah bien vu merci ! Le problème était dans le bout de script qui gère le passage aux URL vers le site francophone. C'est corrigé :)

Pour nous, Pootle marchait assez bien, mais il n'est plus maintenu et en Python 2. Surtout il manquait une fonctionnalité assez évidente que propose Weblate, c'est d'afficher le diff sur une chaine proche. Ça permet de gagner énormément de temps quand la différence c'est une coquille corrigée en anglais qui n'affecte pas la traduction, ou un nombre qui change entre deux versions du logiciel. Ça arrive assez souvant, et Pootle obligeait à regarder le paragraphe entier pour s'assurer que rien d'autre n'avait changé. Par contre, Weblate a l'air un peu plus lent que Pootle et c'est un peu plus difficile de naviguer dans les documents avec. Le fait que ce soit un logiciel libre a été un choix déterminant aussi.

Le titre n'est pas forcément bien mis en avant et présenté en gros, mais dans la chaine que tu prends en exemple, on voit en haut la structure XML du livre, donc on peut savoir si c'est un titre, un paragraphe, etc. Pootle gérait très bien les balises, mais Weblate a l'air d'avoir plus de mal. C'est bien géré sur certaines chaines, mais pas sur d'autres. Soit un bogue, soit un problème de configuration… Par exemple https://translate.linuxfromscratch.org/translate/linux-from-scratch-11-3/chapter02_hostreqs/fr/?checksum=614400c2704b3f93&sort_by=-priority,position affiche bien les balises. En cliquant dessus dans la version originale, on peut les copier dans la version traduite.

En anglais, la dénomination officielle du projet c'est « Guix » et « Guix System ». J'aurais éventuellement pu traduire le deuxième avec une majuscule. C'est vrai que c'est pas forcément très clair, mais la raison invoquée, c'est qu'en dehors d'une commande, guix system reconfigure, tout fonctionne de la même manière dans les deux cas.

Avant, la distribution basée sur Guix s'appelait GuixSD (pour System Distribution) et évidemment on nous demandait si ça fonctionnait que sur un raspberry pi…

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 ?

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 ^'

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.

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.

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.

Entre le moment où j'ai soumis la dépêche à la modération, et le moment où elle a été acceptée, je me suis ouvert une chaîne twitch pour rigoler, histoire d'envoyer en direct la construction d'une LFS. Je ne suis pas sur que ce soit très drôle à regarder, mais n'hésitez pas à passer si le sujet vous intéresse : https://twitch.tv/roptwitch.

Pour ceux qui sont allergiques au JS, youtube-dl fait l'affaire sur ces liens (attention, ils n e sont disponibles que pour 14 jours après leur diffusion) :

• https://www.twitch.tv/videos/732440399 (30 minutes)
• https://www.twitch.tv/videos/733331000 (1h30)

une fois la série terminée, j'essayerai de condenser le tout en une vidéo ou deux et de balancer ça sur un peertube, histoire d'égaliser mon karma ^. Ça risque de prendre un peu de temps cependant, parce que je peux vraiment streamer que le week-end.

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

Côté guix, il y a https://hpc.guix.info/browse qui n'est pas sur le site officiel, mais qui est à jour aussi

Pas encore, mais à part pour Mac OS, il n'y a pas de raison que ça ne puisse pas fonctionner, ça demande "juste" beaucoup d'efforts. Actuellement il semblerait que certains développeurs soient motivés par le Hurd, donc on aura peut-être ça bientôt :)

En fait si, si tu utilises Guix sur une distribution externe, tu peux suivre la procédure d'installation officielle. Les architectures actuellement prises en charge sont i686, x86_64, armv7 et aarch64 (armv8). Le raspi a des problèmes liés aux pilotes graphiques (et au chargeur d'amorçage si je comprends bien) qui ne sont pas libres, ce qui en fait une très mauvaise cible pour le système Guix. Installer guix à côté d'une distribution existante serait plus sage. Ou alors, tu peux utiliser le dépôt non officiel nonguix pour avoir les pilotes non libres, mais ça nécessite la compilation du noyau (guix le fait tout seul, c'est juste très long).

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.

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

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.

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

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

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

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

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.

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

Je voudrais mettre un +10 d'un coup tellement ce retour est incroyable ! Merci d'avoir pris le temps de l'écrire :)

J'ai aussi une expérience similaire, à partir du moment où j'ai découvert Linux, je n'ai pas arrêté de changer et tout casser, jusqu'à me stabiliser un moment sur LFS, ou plutôt mon propre système que j'ai construit grâce à tout ce que j'ai appris avec LFS. Par contre, ça demandait beaucoup de temps et d'énergie de maintenir une distribution à moi tout seul (même en considérant que j'ai automatisé pas mal de choses). Presque 2 ans, c'était un record, mais j'ai fini par me mettre à une autre distro à laquelle je contribue depuis, même si je continue de suivre et de traduire LFS régulièrement :)

C'est évidement le seul choix, par ce qu'inverser la logique vers désactivé par défaut et stocker l'opt-in signe la mort du business, seule une évolution de réglementation pourrait forcer à en arriver là.

Il me semblait que c'était justement ce que demandait le RGPD, non ?

L'auto-destruction des cookies te permet donc d'espérer d'avoir un nouvel identifiant à chaque visite (raté s’il y a une couche de fingerprint) mais tu ne pourras jamais tirer parti des sites respectant la réglementation et te permettant que tes données ne soient pas collectées du tout.

C'est pour ça que ces outils permettent de gérer une liste d'exceptions. Sur les sites qui respectent ma vie privée et pour lesquels je ne veux pas perdre les cookies, je peux les mettre en exception et ne pas virer leurs cookies. Ça c'est de l'opt-in :D

C'est un bogue qui a déjà été rapporté ici : http://lists.gnu.org/archive/html/help-guix/2019-06/msg00024.html

En plus, le nom de ton paramètre de régionalisation devrait terminer par « .UTF-8 » et pas « .utf8 »