Andréas Livet a écrit 222 commentaires

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

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

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

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

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

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

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

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

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

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

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

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

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

Merci pour le commentaire.

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

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

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

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

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

Citation de la page d'installation officielle :

Note: We recommend the use of this shell installer script. The script automates the download, installation, and initial configuration steps described below. It should be run as the root user.

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

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

Merci

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

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

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

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

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

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

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

Merci

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

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

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

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

Encore bravo pour tout ce travail !

Le fait d'utiliser un langage turing complet t'empêche d'établir un certain nombre de propriétés sur le code. Il devient très complexe de faire des validations et va probablement demander à faire de l'analyse statistique qui peut montrer ses limites.

C'est un point pertinent auquel je n'avais pas réfléchis.

D'autres parts je connais des DSL qui ne sont pas limitatifs. C'est par eexemple le cas de gradle ou des pipelines jenkins qui permettent d'utiliser tous groovy.

Je n'ai jamais pratiqué jenkins mais si son DSL te permet d'utiliser toutes les fonctionnalité d'un langage générique, alors ça me paraît une très bonne option.

La notion de niveau d'abstraction dont tu parles qui serait en plus infini ne me paraît pas très clair ou pas très intéressante. L'abstraction n'est pas une fin en soit. En multiplier les couches est un anti patern. Il faut juste que tu puisses exprimer ce dont tu as besoin et je ne suis pas sûr que gérer des paquets demande à ce que chaque empaqueteur pose son propre design.

C'était un peu le sens de ma remarque sur l'intérêt de donner autant de possibilités à l'utilisateur. En effet, cela peut vite devenir un fouillis pas possible sans vérification de la communauté et sans respect de certaines règles, qui sont obligatoires dans un DSL.
Il y a donc un risque d'arriver à ce que certaines plateformes "à plugin", comme par exemple WordPress, subissent, à savoir une multiplication des plugins de très piètre qualité.
Disons que cela hausse le degré de compétence requis pour quiconque souhaite développer des fonctionnalités avancées.
Ce que je trouve intéressant c'est d'avoir justement cette possibilité.

Concernant les niveaux d'abstractions, en soit je suis d'accord. Ce que je voulais dire par là c'est que l'on peut par exemple configurer sa machine avec une api unifiée.
Cette api va derrière modifier tout un environnement hétérogènes (fichiers de conf) et il a fallu un certain niveau d'abstraction pour en arriver là. Le fait de pouvoir choisir ce niveau d'abstraction sans avoir à rajouter des éléments au DSL me paraît important.

Pour reprendre l'exemple de la configuration de la machine, on peut imaginer avoir une API qui permette de configurer chaque moindre logiciel ou service avec une granularité fine, puis des API beaucoup plus haut niveau genre createLampServer, createMailServer qui vous configure quasi automatiquement toute une machine avec les logiciels qui vont bien.

D'accord avec toi sur le fait que Guile n'est pas un langage très commun et qu'il nécessite un apprentissage, tout comme les API.

Ça n'enlève rien au fait qu'un langage de programmation généraliste (aussi "obscure" soit-il) permette d'avoir une flexibilité et des niveaux d'abstractions infinis. C'est le principe même d'un langage de programmation non ?

Pour dire autrement, un DSL te contraint dans un usage parfois déclaratif (simple fichier de conf) ou impératif mais limité (seul quelques structures de contrôles par exemple) et rend difficile la réutilisation de code, la création de nouveaux concepts ou de nouvelles API.

Je pourrai donner l'exemple des langage de templating (DSL) comme Jinja qui implémente beaucoup de logique et d'expressions et qui se rapproche pas mal de Python, mais en moins générique. Bah personnellement, j'ai senti les limites de Jinja dans un gros projet même si c'est un langage de templating très complet. Dans la même veine, je trouve ça plus intéressant d'utiliser des langages génériques comme le Go ou le Php comme langage de templating que d'avoir un DSL limité.

Je pourrai trouver d'autres exemples dans d'autres domaine mais tu vois ce que je veux dire.

Après, tout le débat va porter sur doit-on ou non aller au delà d'un DSL ? Pour moi, dès qu'une limite est atteinte et qu'elle pose problème pour la personne c'est potentiellement dommage. Idéalement, faudrait donc refaire proprement le code, avec un autre langage, d'autres outils, une autre API etc. Dans la pratique, on finit souvent par faire des hacks pour contourner ces limitations.

Le fait d'utiliser un langage de programmation générique assure que ces limites ne seront pas atteintes au niveau du langage. Elles pourront être atteintes au niveau de l'API par contre.

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

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

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

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

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

Le lien que tu pointes porte sur la sortie de la version 3.0 de Guile qui est le langage de programmation utilisé par Guix, mais pas seulement.
Ce sont bien deux projets distincts bien que maintenu par des personnes en commun notamment Ludovic Courtès qui est un des mainteneur principal des deux projets.

Je tâche de me mettre à Guile (et par la même occasion à la programmation fonctionnelle), mais il faut du temps pour changer les bonnes vielles habitudes procédurales/objet. Ce qui est marrant c'est que ça arrive au moment où j'ai décidé d'arrêter de programmer professionnellement :).

Arf, j'imagine que c'est voulu ?! Un peu dommage quand on est comme moi pas très bon en orthographe et dans une volonté d'améliorer l'existant. C'est pareil pour les dépêches ?
C'est mes débuts de rédaction sur linuxfr donc désolé si je pose des questions évidentes.

Oui ce sont aussi les différences que j'avais noté avec aussi la volonté d'avoir une distribution uniquement compilable à partir de source notamment avec le projet Mes.

Les différents commentaires m'ont incités à jeter un œil à Nix et je dois avouer que je suis impressionné ! Je ne pensais pas que le projet était aussi abouti et aussi populaire.

Je vais tâcher d'en apprendre d'avantage sur Nix et Guix afin d'écrire des articles pertinent au sujet de Guix. Ça ne fait pas si longtemps que cela que je m'intéresse à Guix et je ne dispose pas non plus de beaucoup de temps pour bidouiller avec.

Et peut-être qu'au final, je choisirai Nix dans mon usage quotidien ?

En tout cas, je redécouvre tes dépêches sur le sujet et je les trouve passionnantes, merci pour tes efforts !

Merci, j'aimerai pouvoir corriger, mais malheureusement je ne vois pas comment éditer mon journal… je ne trouve pas de bouton "éditer", je dois être bigleux !

C'est une impression que j'ai aussi. Nix semble en effet plus utilisé et Guix a vraiment une très faible communauté et peu de documentation en dehors du manuel officiel (pas de documentation communautaire type wiki).

Comme je le dis dans l'article, j'ai découvert Nix par le biais de Guix et donc suit resté sur mon premier amour si on veut.

Du coup, j'ai de la peine à comprendre l'intérêt autours de Guix (à part pour les barbus RMSiste) et déplore encore de la fragmentation qui ça engendre.

C'est sûr que c'est un truc de barbus RMSiste ! De plus, les outils de développement utilisés (site projet, bug trackers, etc.) sont ceux de gnu et à part pour ceux qui font tout avec emacs, c'est pas ce qu'il y a de plus évident à utiliser.
Perso, je suis bien plus habitué à un workflow ala Github/Gitlab que je trouve beaucoup plus clair et ouvert, mais c'est sans doute une question de goût.

C'est en effet déplorable d'avoir une fragmentation sur un créneau de niche… Maintenant Guix semble apporter une énergie différente avec une orientation propre à lui comme l'accent mis sur les build reproductibles, sur la distribution bootstrapable (désolé pour ces anglicismes) et l'utilisation d'un langage de programmation générique.

Donc, sur le papier Guix me paraît supérieur, peut-être plus pur, mais bon, l'histoire de l'informatique est remplie de projets mieux pensés qui n'ont jamais percés face à un déjà là fonctionnel et massivement utilisé… Est-ce que ça sera le destin de Guix ?

Pour l'instant Guix m'a l'air très académique et se concentrer sur des problèmes de recherche. Il est toutefois fonctionnel et passionnant alors je continue à creuser :).

C'est en effet une fonctionnalité intéressante dont je parlerai dans le prochain article qui porte sur l'usage du gestionnaire de paquet.

Après, je n'avais pas mis cet élément trop en avant, si tu me le permet, je reprendrai une partie de ton commentaire dans mon prochain article.

Merci.

Merci pour ton commentaire, j'avoue avoir découvert Nix avec Guix, donc j'ai une mauvaise connaissance de ce projet et des différences entre les deux.

Sinon, c'est du détail mais je crois que "GuixSD" s'appelle maintenant "Guix System".

Je n'avais pas vu, j'aimerai éditer mon journal mais je ne sais pas comment faire… c'est le premier journal que j'écris sur linuxfr.

Oui, pour l'instant ce sont uniquement 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 installeur "graphique" (en ligne de commande) pour la distribution mais je ne l'ai pas encore utilisé.

Donc ça reste des outils réservés à des utilisateurs avancés, voir très avancés pour certains.

Pour ce qui est du simple gestionnaire de paquet, si vous savez faire un apt install, vous saurez faire un guix install :).

Content d'avoir éveillé ta curiosité :).
Certains articles sont quasiment finis, d'autres en cours de rédaction et d'autres pas encore commencés.
Je ne sais pas si j'aurai l'énergie d'aller jusqu'au bout de ma démarche, à savoir de décrire toutes les applications potentielles de Guix avec un exemple concret à chaque fois.
Ça risque de prendre pas mal de temps, mais qui sait ? :)

Vraiment sympa l'idée, en plus le code est assez court

Oui, je me demande pourquoi d'autres l'ont pas eu avant !

En tout cas c'est torrent-stream qui fait quasi tout le boulot. C'est ce qui est utilisé dans Popcorn Time (Butter) et ça fonctionne étonnamment bien. Par contre, il me semble que c'est pas accepté par tous les trackers.

Ce projet m'a l'air bien intéressant et je me dis que ça pourrait être un parfait candidat pour intégré un projet que j'avais commencé, mais vite arrêté à cause des limitations des navigateurs et du manque de temps.

En fait, je cherchais à convertir les liens torrents ou magnet comme de simple url http avec derrière un petit serveur web qui tourne et torrent-stream (bon je sais cay mal de streamer les torrent mais je trouvais l'idée vraiment sympa).

De cette manière tu pouvais cliquer sur un lien torrent ou magnet et ça le téléchargeait avec le gestionnaire de téléchargement natif du navigateur. Pareil pour les vidéos, je pouvais les voir dans une balise classique (si le format était compatible). Les torrents contenants plusieurs fichiers étaient affichés avec une interface html générée à la volée.

Le problème c'est qu'il fallait lancer le serveur web à côté et que Firefox ne permet plus d'intégrer des binaires à ses plugins.

Voilà un POC vraiment fait à l'arrache du projet : https://github.com/dedesite/firefox-torrent

Bref, en tout cas Next à l'air vraiment sympa, bravo à toute l'équipe !

Bravo pour cette initiative !

C'est vraiment chouette de voir toutes ces aventures industrielles qui essayent d'avoir une démarche favorisant une utilisation plus conviviale (au sens d'Ivan Illich) de nos outils. Certes, ça reste limité à l'assemblage/réparation mais c'est déjà ça :).

Je rejoins les remarques concernant le fait que le système d’éjection n'est pas forcément le plus pertinent étant donné la grande simplicité des connecteurs actuels (SATA, RAM etc.).
Par contre, ça le devient beaucoup plus les pour les différentes nappes (écran, clavier, touchpad, caméra) car elles sont très fragile et pas toujours faciles à manipuler.

Pareil pour les connecteurs d'alimentation ou autres prises éthernet qui quand ça casse ne sont pas très marrants à réparer…

L'autre gros problème déjà soulevé est la durée de vie des sockets et autres connectiques et ça c'est hors du scope de votre projet vue que vous ne faites qu'acheter des pièces produites par d'autres. Mais, à terme, il faudrait que les industrielles soient capable de s'engager sur des standards à long terme pour permettre à des projets comme le votre d'exister.

Sinon on parlait d'autres retours d'aventures industrielle, je pense que vous connaissez tous le projet EOMA86 ? Si c'est pas le cas, la lecture des comptes rendu de la campagne de financement participatif et un régal :
https://www.crowdsupply.com/eoma68/micro-desktop/updates

Ils ont eu tellement de galère sur ce projet… et pourtant l'initiateur du projet n'est pas né de la dernière pluie.

Au plaisir de suivre l'avancée du projet.