Merci pour ces remarques. Je précise que je ne suis pas expert en Manjaro, que j'ai fait comme j'ai pu et avec les infos que j'ai trouvées et que je ne pense pas que ma démarche soit complètement incohérente étant donnée que Manjaro se veut être un OS accessible à tous.
Ton /boot est une partition ext4 qui ne permet pas de snapshot.
…
Oui, j'ai fait pas mal de tests à ce sujet. Le plus simple aurait été de faire une table msdos avec juste une partition en btrfs mais l'installeur de Manjaro conseille fortement de faire du GPT. Concernant les noyaux, j'ai testé d'en installer plusieurs et dans ce cas au grub on peut choisir le snapshot puis le noyau, en s'arrangeant pour que ce soit compatible. Maintenant, est-ce-que les maj noyaux sont destructives et qu'un noyau casse facilement, je ne sais pas mais si c'est le cas alors oui ce partitionnement n'est pas idéal.
Seulement 200M pour le /boot de Manjaro, ça me semble vraiment juste…
Je me suis inspiré des docs et du wiki archlinux : "A suggested size for /boot is 200 MiB unless you are using EFI system partition as /boot, in which case at least 260 MiB is recommended. " https://wiki.archlinux.org/index.php/partitioning#/boot
ne pas faire un partition dédié pour /boot, mais de le laisser sur /
C'est ce que j'ai testé en premier mais avec une table GPT, si j'enlève la partition /boot, l'installation échoue, avec un vilain message d'erreur.
le mettre dans un sous-volume btrfs. Grub sait booter sur du btrfs du quelques temps déjà
Je n'ai aucune idée de comment faire ça avec l'installeur. Par contre, j'ai testé de mettre la partition /boot en btrfs mais idem : message d'erreur.
Oui j'ai vu mais comme cette dépêche n'a pas eu d'activité concrète en 10 jours (hormis le message que j'y ai mis) je me suis permis de faire un journal de mon côté.
Maintenant, il y a certainement des choses à améliorer dans ce que je présente ici donc si quelqu'un veut faire une dépêche propre et complète sur le sujet, foncez.
Oui, je comprends mais là l'idée c'est juste de montrer comment un utilisateur de l'un peut tester l'autre.
Sur un test aussi simple, je n'ai pas vu de grosse différence. Guix était plus lent sur les maj mais c'est parce que, par défaut, il est en rolling release alors que NixOS est fixé sur une version. Si j'avais mis le même réglage des deux côtés, j'aurais certainement moins eu cette différence.
Je ferai peut-être une comparaison plus tard mais il me faudrait plus d'expérience sur Guix. Ces 3 dernières années, j'ai dû l'utiliser 3 semaines au cumulé alors que j'ai utilisé Nix tous les jours, donc je ne peux pas vraiment comparer.
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.
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.
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.
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 :
…
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.
Concernant les paquets cassés, c'est très rare. Ca arrive mais beaucoup moins que pour Nix par exemple.
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) ?
These scripts play a central role in the initial installation of UNIX and Linux machines, as well as in recurrent configuration, installation, and software maintenance tasks.
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.
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).
Avec Nix, il est nécessaire d'apprendre un nouveau DSL (le langage d'expression Nix),
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, …)
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.
J'admire ta patience mais à mon avis tu perds ton temps. Le gars n'arrête pas de nous chier une pendule parce que j'ai mis 2 traits d'humour dans mon introduction. Quand on utilise Nix on doit accepter de se faire traiter de hacker/geek/nolife/whatever mais quand tu fais remarquer que la super feature qui secure la distrib ou filesystem à la mode, on l'a gratos depuis 15 ans avec Nix on se fait incendier… Bref, va plutôt parler chaussures à un cul-de-jatte, tu auras plus de chance de te faire comprendre…
Ok, toutes mes excuses. C'est vrai que mon article se résume à critiquer ta solution. D'ailleurs tous mes articles sont du prosélystisme pour NixOS sur lequel je me fais des millions, tout ça en occultant toutes les autres solutions ou en les tournant en dérision… Bien le bonsoir.
Là, on est en train de me dire qu'il y a mieux que ce que j'utilise, or je ne peux que constater que pas du tout de mon point de vue, et très probablement aussi du point de vue de beaucoup d'utilisateurs à mon humble avis.
Pour la petite histoire, c'est exactement l'impression que j'ai eu quand j'ai lu le commentaire du journal/dépêche sur Manjaro : "Pour se prémunir d'éventuels problèmes […] Avant chaque mise à jour, faire un snapshot de "/" avec Timeshift […] Comme ça, plus de stress et on peut profiter sans souci des avantages d'une rolling release […]" (https://linuxfr.org/nodes/122116/comments/1830785). Et là je n'ai pu que constater, que oui, ce que j'avais par défaut sur NixOS était bien mieux.
modifier les fichiers dans /etc : ??? je n'ai jamais besoin de toucher à ça
Pour Manjaro non, pour Arch il me semble que c'est la procédure.
lire la page de news avant toutes maj : je le fais, mais en toute rigueur pas nécessaire pour l'usage "monsieur tout le monde" que je fais de mon PC du fait des snapshots
Honnêtement, je ne suis pas sûr qu'une rolling release + snapshot soit une bonne idée pour un "monsieur tout le monde". Mais ce n'est que mon avis et ça dépend vraiment du "monsieur tout le monde".
deviner d'où viennent les éventuels problèmes : pas besoin, je reviens au snapshot précédent en attendant qu'ils soient corrigés
Oui, je pensais à Arch où on va plutôt éditer directement les fichiers de conf et donc corriger nous-mêmes.
apprendre conda/venv/chef/whatever : ??? je n'ai jamais besoin de toucher à ça
écrire des Dockerfile : ??? je n'ai jamais besoin de toucher à ça
Oui voila, chacun son usage. Perso, c'est mon usage au quotidien.
Honnêtement, pour un utilisateur avec un usage "monsieur tout le monde", tu trouve que c'est plus compliqué que Nix ?
Je suis complètement d'accord.
Perso, je trouve plus simple d'éditer configuration.nix, d'écrire un default.nix de temps en temps et de connaitre trois commandes nix, tout ça pour gérer mon système avec des vérifs et rollbacks automatiques, packager mes projets, des environnements python, des images docker, etc.
Je trouve plus compliqué de modifier les fichiers dans /etc, lire la page de news avant toute maj, faire un snapshot, deviner d'où viennent les éventuels problèmes, apprendre conda/venv/chef/whatever, écrire des Dockerfile, etc, mais je comprends très bien qu'on puisse avoir une vision différente.
Ce que je veux dire c'est que ta présentation est bien mais l'argument mis en avant dès l'introduction me paraît au mieux inutile, au pire malvenu.
Merci. C'est pour cela que c'est un journal/blog et non une dépêche ni un article wikipedia. Je pense avoir le droit à un peu d'humour, d'autant plus que personnellement je ne critique pas le moindre blog ou commentaire vantant, par exemple, la simplicité et la stabilité de Arch alors que mes quelques années d'expérience personnelle sur ce système me mettraient plutôt en désaccord.
Alors NUR pas vraiment et c'est assez logique, c'est juste une conf de nix et pas une installation de logiciel
Oui mais non. NUR demande effectivement une étape de configuration mais après tu fais bien des installations hors nixpkgs (ou du moins sur un nixpkgs augmenté), par exemple :
$ nix-shell -p nur.repos.mic92.hello-nur
Et pour en revenir au "cas nominal" de Nix, je pense que justement c'est plus de gérer nos propres environnements de développement que d'installer un logiciel de nixpkgs. D'ailleurs, la page de doc du site aborde très souvent les "developer environments" (https://nixos.org/learn.html).
Nix est peu connu donc on ne risque pas de voir, par exemple, vscode fournir un script Nix. Mais dans la communauté Nix, il est assez courant de proposer des scripts/paquets en dehors de nixpkgs : home-manager, cachix, nixGL, nur…
nix, guix et pkgsrc permet surtout d'installer des logiciels sans impact sur le reste du système. Cela apporte des choses en plus et nixos pousse ça à tous l'ensemble du système. Mais on est sur un modèle à dépôt. Tu fais inclure ton logiciel dans le dépôt et il est dispo (tu peux fournir un script nix pour faire l'installation, mais c'est pas l'usage nominal).
D'ailleurs, nixpkgs n'est pas uniquement une logithèque mais avant tout un ensemble de fonctions pour construire des logiciels. Par exemple, en lançant automatiquement des commandes autotools, cmake, python/pip, etc.
Normalement, on peut utiliser Nix sur n'importe quelle distribution mais il y a un réglage de libGL à faire pour les applis graphiques. Je ne connais pas bien ce cas d'usage mais ça doit se résumer à :
# Erratum
Posté par nokomprendo (site web personnel) . En réponse au journal Les rollbacks avec Manjaro, Btrs et Timeshift. Évalué à 6.
Pour l'histoire du /boot : c'est effectivement mieux de faire juste un / pour snapshoter aussi les noyaux. Par contre, ce partitionnement ne semble pas fonctionner via l'installeur graphique donc il faut le faire avec gparted avant de lancer l'installeur. J'ai mis à jour ma page de blog (et ajouté une vidéo d'erratum) : https://nokomprendo.gitlab.io/posts/tuto_fonctionnel_49/2020-12-04-fr-README.html#installer-manjaro-sur-une-partition-btrfs
[^] # Re: Les mots ont un sens
Posté par nokomprendo (site web personnel) . En réponse au journal Les rollbacks avec Manjaro, Btrs et Timeshift. Évalué à 4.
Je ne suis pas sûr de bien comprendre. Manjaro ne suit pas un modèle "rolling release" ?
[^] # Re: /boot
Posté par nokomprendo (site web personnel) . En réponse au journal Les rollbacks avec Manjaro, Btrs et Timeshift. Évalué à 3.
Merci pour ces remarques. Je précise que je ne suis pas expert en Manjaro, que j'ai fait comme j'ai pu et avec les infos que j'ai trouvées et que je ne pense pas que ma démarche soit complètement incohérente étant donnée que Manjaro se veut être un OS accessible à tous.
Oui, j'ai fait pas mal de tests à ce sujet. Le plus simple aurait été de faire une table msdos avec juste une partition en btrfs mais l'installeur de Manjaro conseille fortement de faire du GPT. Concernant les noyaux, j'ai testé d'en installer plusieurs et dans ce cas au grub on peut choisir le snapshot puis le noyau, en s'arrangeant pour que ce soit compatible. Maintenant, est-ce-que les maj noyaux sont destructives et qu'un noyau casse facilement, je ne sais pas mais si c'est le cas alors oui ce partitionnement n'est pas idéal.
Je me suis inspiré des docs et du wiki archlinux : "A suggested size for /boot is 200 MiB unless you are using EFI system partition as /boot, in which case at least 260 MiB is recommended. " https://wiki.archlinux.org/index.php/partitioning#/boot
C'est ce que j'ai testé en premier mais avec une table GPT, si j'enlève la partition /boot, l'installation échoue, avec un vilain message d'erreur.
Je n'ai aucune idée de comment faire ça avec l'installeur. Par contre, j'ai testé de mettre la partition /boot en btrfs mais idem : message d'erreur.
[^] # Re: Dépêche
Posté par nokomprendo (site web personnel) . En réponse au journal Les rollbacks avec Manjaro, Btrs et Timeshift. Évalué à 5.
Oui j'ai vu mais comme cette dépêche n'a pas eu d'activité concrète en 10 jours (hormis le message que j'y ai mis) je me suis permis de faire un journal de mon côté.
Maintenant, il y a certainement des choses à améliorer dans ce que je présente ici donc si quelqu'un veut faire une dépêche propre et complète sur le sujet, foncez.
[^] # Re: Pro - Cons
Posté par nokomprendo (site web personnel) . En réponse au journal NixOS vs Guix System, premiers pas. Évalué à 7.
Oui, je comprends mais là l'idée c'est juste de montrer comment un utilisateur de l'un peut tester l'autre.
Sur un test aussi simple, je n'ai pas vu de grosse différence. Guix était plus lent sur les maj mais c'est parce que, par défaut, il est en rolling release alors que NixOS est fixé sur une version. Si j'avais mis le même réglage des deux côtés, j'aurais certainement moins eu cette différence.
Je ferai peut-être une comparaison plus tard mais il me faudrait plus d'expérience sur Guix. Ces 3 dernières années, j'ai dû l'utiliser 3 semaines au cumulé alors que j'ai utilisé Nix tous les jours, donc je ne peux pas vraiment comparer.
[^] # Re: Une doc sur les commandes Guix - Nix ?
Posté par nokomprendo (site web personnel) . En réponse à la dépêche GNU Guix 1.2.0 est publié. É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.
[^] # Re: Une doc sur les commandes Guix - Nix ?
Posté par nokomprendo (site web personnel) . En réponse à la dépêche GNU Guix 1.2.0 est publié. É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.
# Une doc sur les commandes Guix - Nix ?
Posté par nokomprendo (site web personnel) . En réponse à la dépêche GNU Guix 1.2.0 est publié. É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: Similaire à NixOS
Posté par nokomprendo (site web personnel) . En réponse à la dépêche GNU Guix 1.2.0 est publié. É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 nokomprendo (site web personnel) . En réponse à la dépêche GNU Guix 1.2.0 est publié. É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 nokomprendo (site web personnel) . En réponse à la dépêche GNU Guix 1.2.0 est publié. É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 nokomprendo (site web personnel) . En réponse à la dépêche GNU Guix 1.2.0 est publié. É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 nokomprendo (site web personnel) . En réponse à la dépêche GNU Guix 1.2.0 est publié. É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 nokomprendo (site web personnel) . En réponse à la dépêche GNU Guix 1.2.0 est publié. É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: à chacun sa vision de la simplicité
Posté par nokomprendo (site web personnel) . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. Évalué à 1.
J'admire ta patience mais à mon avis tu perds ton temps. Le gars n'arrête pas de nous chier une pendule parce que j'ai mis 2 traits d'humour dans mon introduction. Quand on utilise Nix on doit accepter de se faire traiter de hacker/geek/nolife/whatever mais quand tu fais remarquer que la super feature qui secure la distrib ou filesystem à la mode, on l'a gratos depuis 15 ans avec Nix on se fait incendier… Bref, va plutôt parler chaussures à un cul-de-jatte, tu auras plus de chance de te faire comprendre…
[^] # Re: à chacun sa vision de la simplicité
Posté par nokomprendo (site web personnel) . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. Évalué à 2.
Ok, toutes mes excuses. C'est vrai que mon article se résume à critiquer ta solution. D'ailleurs tous mes articles sont du prosélystisme pour NixOS sur lequel je me fais des millions, tout ça en occultant toutes les autres solutions ou en les tournant en dérision… Bien le bonsoir.
[^] # Re: à chacun sa vision de la simplicité
Posté par nokomprendo (site web personnel) . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. Évalué à 2.
Je dis juste que si X vante son vélo, Y a aussi le droit de vanter le sien ensuite sans se le faire reprocher lourdement par X…
[^] # Re: à chacun sa vision de la simplicité
Posté par nokomprendo (site web personnel) . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. Évalué à 3.
Pour la petite histoire, c'est exactement l'impression que j'ai eu quand j'ai lu le commentaire du journal/dépêche sur Manjaro : "Pour se prémunir d'éventuels problèmes […] Avant chaque mise à jour, faire un snapshot de "/" avec Timeshift […] Comme ça, plus de stress et on peut profiter sans souci des avantages d'une rolling release […]" (https://linuxfr.org/nodes/122116/comments/1830785). Et là je n'ai pu que constater, que oui, ce que j'avais par défaut sur NixOS était bien mieux.
[^] # Re: à chacun sa vision de la simplicité
Posté par nokomprendo (site web personnel) . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. Évalué à 3. Dernière modification le 24 novembre 2020 à 16:46.
Pour Manjaro non, pour Arch il me semble que c'est la procédure.
Honnêtement, je ne suis pas sûr qu'une rolling release + snapshot soit une bonne idée pour un "monsieur tout le monde". Mais ce n'est que mon avis et ça dépend vraiment du "monsieur tout le monde".
Oui, je pensais à Arch où on va plutôt éditer directement les fichiers de conf et donc corriger nous-mêmes.
Oui voila, chacun son usage. Perso, c'est mon usage au quotidien.
Non non, je suis d'accord que Nix n'est pas adapté, et c'est exactement ce que je dis dans mon post précédent dont le lien est ici : https://linuxfr.org/users/nokomprendo-3/liens/nixos-20-09-presentation-installation-configuration-utilisation
Bah non, c'est ton ressenti et je suis content que tu l'aies partagé.
[^] # Re: à chacun sa vision de la simplicité
Posté par nokomprendo (site web personnel) . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. Évalué à 6.
Je suis complètement d'accord.
Perso, je trouve plus simple d'éditer configuration.nix, d'écrire un default.nix de temps en temps et de connaitre trois commandes nix, tout ça pour gérer mon système avec des vérifs et rollbacks automatiques, packager mes projets, des environnements python, des images docker, etc.
Je trouve plus compliqué de modifier les fichiers dans /etc, lire la page de news avant toute maj, faire un snapshot, deviner d'où viennent les éventuels problèmes, apprendre conda/venv/chef/whatever, écrire des Dockerfile, etc, mais je comprends très bien qu'on puisse avoir une vision différente.
Merci. C'est pour cela que c'est un journal/blog et non une dépêche ni un article wikipedia. Je pense avoir le droit à un peu d'humour, d'autant plus que personnellement je ne critique pas le moindre blog ou commentaire vantant, par exemple, la simplicité et la stabilité de Arch alors que mes quelques années d'expérience personnelle sur ce système me mettraient plutôt en désaccord.
[^] # Re: Debian
Posté par nokomprendo (site web personnel) . En réponse au journal Installer Chromium sur Ubuntu via Nix. Évalué à 3.
La discussion originale est ici : https://linuxfr.org/users/chrisk/journaux/ubuntu-snap-les-performances-de-chromium-se-degradent
N'hésitez pas à aller y proposer vos solutions.
[^] # Re: quid de Nix ?
Posté par nokomprendo (site web personnel) . En réponse au journal Ubuntu, Snap, les performances de chromium se dégradent. Évalué à 2.
Oui mais non. NUR demande effectivement une étape de configuration mais après tu fais bien des installations hors nixpkgs (ou du moins sur un nixpkgs augmenté), par exemple :
Et pour en revenir au "cas nominal" de Nix, je pense que justement c'est plus de gérer nos propres environnements de développement que d'installer un logiciel de nixpkgs. D'ailleurs, la page de doc du site aborde très souvent les "developer environments" (https://nixos.org/learn.html).
[^] # Re: quid de Nix ?
Posté par nokomprendo (site web personnel) . En réponse au journal Ubuntu, Snap, les performances de chromium se dégradent. Évalué à 2.
Nix est peu connu donc on ne risque pas de voir, par exemple, vscode fournir un script Nix. Mais dans la communauté Nix, il est assez courant de proposer des scripts/paquets en dehors de nixpkgs : home-manager, cachix, nixGL, nur…
https://github.com/nix-community/home-manager#home-manager-using-nix
https://github.com/cachix/cachix#installation
https://github.com/guibou/nixGL#installation
https://github.com/nix-community/NUR#installation
[^] # Re: quid de Nix ?
Posté par nokomprendo (site web personnel) . En réponse au journal Ubuntu, Snap, les performances de chromium se dégradent. Évalué à 2.
Que veux-tu dire par "Tu fais inclure ton logiciel dans le dépôt" ?
Pour moi, Nix est, justement, très pratique pour packager soi-même des projets : https://linuxfr.org/news/gestion-de-paquets-et-devops-avec-nix-tour-d-horizon-sur-un-cas-concret#toc-construire-et-installer-le-paquet-duprojet
D'ailleurs, nixpkgs n'est pas uniquement une logithèque mais avant tout un ensemble de fonctions pour construire des logiciels. Par exemple, en lançant automatiquement des commandes autotools, cmake, python/pip, etc.
[^] # Re: quid de Nix ?
Posté par nokomprendo (site web personnel) . En réponse au journal Ubuntu, Snap, les performances de chromium se dégradent. Évalué à 2.
Normalement, on peut utiliser Nix sur n'importe quelle distribution mais il y a un réglage de libGL à faire pour les applis graphiques. Je ne connais pas bien ce cas d'usage mais ça doit se résumer à :
nix-env -iA nixpkgs.chromium)