Sommaire
- Les canaux de NixOS
- Les générations systèmes
- Nettoyer les générations systèmes
- Les vérifications automatiques
- Conclusion
Voir aussi : video youtube - video peertube - article de blog
Une distribution Linux "rolling release" permet de faire évoluer progressivement son système. Ceci permet d'avoir des logiciels plus à jour et surtout d'éviter les montées de version majeure.
Cependant, le rolling release augmente le risque de "mise-à-jour qui casse tout". Une solution classique à ce risque est de lire les news de mise-à-jour, faire un snapshot avec Timeshift, lancer la mise-à-jour après avoir tirer une carte chance et faire un rollback vers la case départ sans toucher vingt milles francs en cas de problème. Ou sinon, utiliser NixOS…
Les canaux de NixOS
NixOS utilise un système de canaux de paquets. Ceci permet de choisir entre une approche rolling release (canal nixos-unstable) ou une approche par version (nixos-20.09, nixos-20.03…). Il est même possible de changer de canal, d'utiliser plusieurs canaux en même temps, de spécifier des canaux par utilisateur, de personnaliser des canaux…
On peut lister les canaux systèmes avec la commande suivante :
# nix-channel --list
nixos https://nixos.org/channels/nixos-unstable
On peut également mettre à jour le système, avec les dernières versions de paquets disponibles sur le canal :
# nixos-rebuild switch --upgrade
[...]
Il peut arriver que des paquets soient cassés, que des incompatibilités apparaissent, ou tout simplement qu'on n'ait fait une erreur dans le fichier de configuration. NixOS propose différents outils pour gérer les mises-à-jour et résoudre les éventuels problèmes.
Les générations systèmes
Lors d'une mise-à-jour système (nixos-rebuild), NixOS crée une nouvelle "génération" de la configuration et ajoute une entrée dans l'historique des générations systèmes.
Par exemple, on peut afficher l'historique des générations :
# nix-env -p /nix/var/nix/profiles/system --list-generations
11 2020-11-22 22:27:47 (current)
Puis modifier la configuration et mettre à jour le système :
# nixos-rebuild edit
[...]
# nixos-rebuild switch
building Nix...
building the system configuration...
these derivations will be built:
[...]
L'historique indiquera alors une nouvelle génération :
# nix-env -p /nix/var/nix/profiles/system --list-generations
11 2020-11-22 22:27:47
12 2020-11-22 23:34:26 (current)
Il est alors possible de faire un nixos-rebuild switch --rollback pour revenir sur la configuration précédente.
En fait, les générations sont également accessibles depuis le bootloader. On peut donc rebooter la machine et sélectionner la génération à utiliser, depuis l'amorceur.
Nettoyer les générations systèmes
Avec NixOS, tout paquet ou configuration est stocké sous forme de dossier dans /nix/store/. L'environnement courant est simplement un ensemble de liens symboliques vers des éléments du store. Lorsqu'on "désinstalle" un paquet Nix, seuls les liens symboliques sont supprimés; les éléments du store sont conservés.
Ainsi, pour nettoyer complètement les générations inutilisées, il faut nettoyer le store, supprimer les générations et mettre à jour les entrées du bootloader :
# nix-collect-garbage -d
# nix-env -p /nix/var/nix/profiles/system --delete-generations
# nixos-rebuild switch
Les vérifications automatiques
Si NixOS permet de revenir facilement à des configurations précédentes, il effectue même des vérifications pour éviter de générer des configurations invalides.
Par exemple, soit la configuration suivante du serveur graphique :
services = {
xserver = {
enable = true;
layout = "fr";
displayManager.lightdm.enable = true;
...Nix vérifie que les options spécifiées existent bien. Par exemple, si on remplace layout par layoute,
layoute = "fr";alors on obtient l'erreur suivante :
# nixos-rebuild switch
building the system configuration...
error: The option `services.xserver.layoute' does not exist. Definition values:
- In `/etc/nixos/configuration.nix': "fr"
(use '--show-trace' to show detailed location information)
Nix vérifie également les valeurs de certaines options. Par exemple, si on remplace le layout fr par fre,
layout = "fre";on obtient l'erreur :
# nixos-rebuild switch
building Nix...
building the system configuration...
[...]
The value `fre' for keyboard layout is invalid.
Please check the definition in `services.xserver.layout'.
Detailed XKB compiler errors:
[...]
Enfin, Nix vérifie certaines assertions, notamment des dépendances entre options. Par exemple, si on désactive le serveur graphique (tout en laissant activer le gestionnaire de connection lightdm).
enable = false;on obtient l'erreur :
# nixos-rebuild switch
building Nix...
building the system configuration...
error:
Failed assertions:
- LightDM requires services.xserver.enable to be true
(use '--show-trace' to show detailed location information)
Conclusion
NixOS est basé sur un système d'environnements immuables, reproductibles et composables, ce qui permet, assez naturellement, de naviguer dans l'historique des mises-à-jour. De plus, comme ce système est déclaratif, Nix peut effectuer certaines vérifications et donc éviter de générer des configurations invalides.
Tout ceci permet de simplifier les mises-à-jour du système, sans avoir à utiliser un système de snapshots supplémentaire ni de prendre des précautions particulières avant de lancer la commande de mise-à-jour. Cependant, le système de mise-à-jour de NixOS ne se substitue pas non plus à un système de sauvegarde de fichiers.
# à chacun sa vision de la simplicité
Posté par mahikeulbody . Évalué à 3. Dernière modification le 24 novembre 2020 à 08:41.
A chacun sa vision de la simplicité. Faire un snapshot avec Timeshift prend exactement 5" (lancement de Timeshift inclus). Voilà, c'est fini : pas de précautions particulières supplémentaires, pas de commandes Nix à apprendre, pas de carte chance à tirer en croisant les doigts.
Nix est sans doute conceptuellement plus satisfaisant que faire un snapshot mais je doute que cela corresponde le mieux à l'usage le plus courant d'une distribution. 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.
[^] # Re: à chacun sa vision de la simplicité
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Tout à fait, Nix n'est pas prévu pour ce qu'on entend par usage courant parce-que dans ton usage : tu n'as pas besoin d'avoir plusieurs versions (avec des dépendances conflictuelles éventuellement) ; chose pour laquelle Timeshift ne sera pas utile quand les bibliothèques se marcheront dessus… (enfin tes cinq minutes vont se transformer en heures/jours)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: à chacun sa vision de la simplicité
Posté par nokomprendo (site web personnel) . É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: à chacun sa vision de la simplicité
Posté par mahikeulbody . Évalué à 3.
Je résume : je suis un utilisateur lambda d'une distribution (Manjaro) qui me fournit son système de mise à jour (pacman) ; j'ai un "/" en BTRFS sur lequel je fais un snapshot avec Timeshift avant chaque mise à jour (toutes les trois semaines environ sous Manjaro) : 5" pour le faire ; puis je fais la mise à jour elle-même => Manjaro ajoute automatiquement pour moi une entrée dans grub pour mon snapshot.
Honnêtement, pour un utilisateur avec un usage "monsieur tout le monde", tu trouve que c'est plus compliqué que Nix ?
Peut-être n'ai-je pas perçu l'humour. Quoiqu'il en soit, je regrette cette partie de mon commentaire, tout à fait inutile.
[^] # Re: à chacun sa vision de la simplicité
Posté par nokomprendo (site web personnel) . É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 mahikeulbody . Évalué à 2.
J'ai dit : pour un utilisateur avec un usage "monsieur tout le monde" (ou, si tu préfères, avec un usage classique de PC : internet, bureautique, photos, …), ce n'est pas tout à fait pareil.
C'est gentil mais je regrette quand même :-)
[^] # Re: à chacun sa vision de la simplicité
Posté par deuzene (site web personnel) . Évalué à 2.
Tu sais bien, sinon je te le rappelle, qu'il n'y a pas d'usage classique d'un PC :
Et puisque j'ai parlé de ma maman (78 ans), quand elle ne regarde pas ses photos, elle joue comme une ado sur sa tablette !
« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
[^] # Re: à chacun sa vision de la simplicité
Posté par mahikeulbody . Évalué à 3.
Tous les usages que tu as listé rentrent dans ce que j'appelle un usage classique (mais j'admets volontiers que ce n'est sans doute pas le meilleur terme). Pour le dire autrement, les arguments qui ont été exposés en faveur de Nix sont des arguments pour les développeurs, administrateurs, bidouilleurs, puristes. Mais pour la grande majorité des autres usagers, utiliser Nix en sus (ou à la place) du système de mise à jour de leur distribution est à mon avis plus compliqué
que la solution snapshot/btrfs.
[^] # Re: à chacun sa vision de la simplicité
Posté par deuzene (site web personnel) . Évalué à 2.
Je suis tout à fait d'accord avec toi quand tu dis que Nix (OS) s'adresses plutôt à des, hum, hackers et des nerds. On pourrait même rajouter que la fameuse famille Michu ne sais pas ce qu'est un OS et encore moins un FS, n'en a en fait rien à faire pourvu que ses membres puisse utiliser leurs ordis à leur convenance : et ils ont raison. Ils ne voient d'ailleurs pas pourquoi il est important de faire des sauvegardes.
Toutes ces killer features dont on peut parler ici si elles ne sont ni intégrées au système ni silencieuses, ne seront jamais comprises et utilisée par le quidam. On peut le remarquer avec les mises à jour qui, si une appliquette n'annonce pas qu'il y en a ne seront pas faites. Et encore, la popup risque d'être simplement fermée sans être lue !
Mon cmmentaire était juste à propos de ce que l'on peut penser des usages de ce que font les autres à partir d'une généralité rèvée ou phantasmée de ce que l'on peut s'imaginer de ce qu'est un autre. Je n'étais pas contradictoire.
« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
[^] # Re: à chacun sa vision de la simplicité
Posté par mothsART . Évalué à 3.
Le problème de Timeshift est qu'il n'est pas synchronisé avec le gestionnaire de paquets.
Du coup, si tu pars sur un instantané, tu perds par exemple 1 journée de diff alors que c'est seulement 5 minutes que tu souhaiterais rollback.
Ça peut être vraiment contre-intuitif et rageant car tu ne sais pas exactement ce qu'il manque et certaines opérations que tu pensais finis sont à refaire.
Il manque sans doute une GUI a Nix pour proposer la gestion des snapshots :
Si c'était le cas, réviserais-tu ton discours ?
Je n'utilise pas Timeshift mais si tu casses au hasard X11 ou Wayland, c'est toujours facile ? (pour le coup, avec les snapshots au bootloader, ça me parait une avancé notable, non ?)
Là ou je trouve que son journal est également intéressant c'est qu'on c'est tous fait avoir par la permissivité de certains fichiers de conf : on se trompe dans l'édition et on se rend compte à l’exécution qu'on a tout cassé.
Avec Nix, on limite la casse en opérant des contrôles en amont.
Point curiosité : j'aimerais bien savoir ce qu'un comparatif d'espace disque consommé sur les 2 technos avec une échelle de temps et gamme de logiciels proche d'un usage courant donnerait.
[^] # Re: à chacun sa vision de la simplicité
Posté par mahikeulbody . Évalué à 3.
Je ne comprends pas le problème : je fais un instantané avant chaque mise à jour de paquets (soit une fois toutes les trois semaines en moyenne sur Manjaro ou, plus rarement quand j'installe un nouveau logiciel).
Manjaro créé automatiquement une entrée dans grub pour chaque snapshot du sous-volume BTRFS "/" existant. Donc oui, même si une mise à jour casse X11 ou Wayland, c'est facile.
Les snapshots BTRFS (tout comme ceux de ZFS j'imagine) reposent sur la caractéristique cow du système de fichier : ils n'induisent pas de copie en double et sont instantanés.
[^] # Re: à chacun sa vision de la simplicité
Posté par mothsART . Évalué à 1.
ah, oui : c'est pas vraiment comme ça que j'envisage l'informatique. Si mon instantané peut être fait automatiquement, c'est mieux.
Bon j'imagine que c'est possible de faire un alias bash ou zsh qui lance ton instantané avant de mettre à jour mais bon on rentre dans la bidouille.
Quand tu me parles de Timeshift, je pensais plus à rsync (usage le plus courant) que à BTRFS.
J'avoue que si tu règles ces 2 points, on obtient un léger avantage pour ta technique vu que les snapshots de BTRFS doivent être bien moins gourmand.
[^] # Re: à chacun sa vision de la simplicité
Posté par mahikeulbody . Évalué à 2. Dernière modification le 24 novembre 2020 à 22:45.
Je crois qu'il y a une distribution qui fait ça automatiquement, ça doit donc être faisable. Personnellement je n'en éprouve pas le besoin sachant que j'installe rarement un nouveau logiciel (je n'ai donc que les mises à jour périodiques de la distribution). De plus, si jamais j'oublie de faire un instantané avant une mise à jour et qu'en plus cette mise à jour a un gros problème, il me suffit de repartir du dernier instantané disponible (j'en garde toujours trois).
Je ne vois qu'un point. Pour moi Timeshift ne m'intéresse que pour faire des instantanés BTRFS. Pour la sauvegarde j'utilise autre chose (borg).
[^] # Re: à chacun sa vision de la simplicité
Posté par barmic 🦦 . Évalué à 3.
Pas mal de gestionnaire de paquets ont des hooks, donc c'est pas de la bidouille. Ça fonctionne juste comme il faut.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: à chacun sa vision de la simplicité
Posté par mothsART . Évalué à 1.
@mahikeulbody : Les 2 points, je parlais de l'install auto et de BTRFS bien sur.
@barmic : j'avais pas pensé aux hooks, bonne idée.
[^] # Re: à chacun sa vision de la simplicité
Posté par mahikeulbody . Évalué à 2.
Tu me demandais de régler les deux points. Je ne vois pas bien ce que tu veux que je règle avec BTRFS. Si tu ne veux pas l'utiliser, la solution perd de son efficacité mais c'est comme si je te disais "j'aime bien ce que fait Nix mais trouve une solution pour que ça marche pareil sans Nix".
[^] # Re: à chacun sa vision de la simplicité
Posté par jyes . Évalué à 3.
Bah, utilise snapper alors, le paquet Debian vient avec un hook pour apt. Sur Fedora aussi il est couplé au gestionnaire de paquets (il me semble, ça fait longtemps que je n’ai testé avec Fedora).
[^] # Re: à chacun sa vision de la simplicité
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
suis plutôt équipe EtcKeeper
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: à chacun sa vision de la simplicité
Posté par Guillaum (site web personnel) . Évalué à 7. Dernière modification le 25 novembre 2020 à 14:43.
Je n'ai aucun souci avec le fait que timeshift te convient, c'est parfait. Mais je suis plus embêté par le fait que tu dise implicitement que NixOS est moins simple et moins "courant". Autant pour le simple, c'est discutable. Autant pour le moins courant, je ne vois pas en quoi c'est un argument.
Pour le simple, je ne sais pas trop. Installer timeshift va sans doute te demander un peu de travail, tout du moins de configuration pour obtenir le snapshot qui correspond à tes besoins (afin de ne pas snapshoter de trucs inutiles qui prennent beaucoup de place, comme tes containers / images docker).
La première installation de NixOS n'est pas forcement trivial, mais ce n'est pas non plus une horreur, tu boot sur un live cd, tu partitionnes des disques et tu edit un fichier de configuration. Cela manque d'un installer graphique qui configure un système "gnome" ou "kde" de base. Ce n'est pas forcement pire qu'une ubuntu fraiche ou tu passes une heure dans les menus pour installer / configurer tes applications et services et c'est bien mieux que tout autre distribution "un peu hard core" ou tu dois faire de nombreuses étapes pour réaliser l'installation.
Pour les "snapshot" à la mode NixOS, t'as une commande à connaitre, celle qui met à jour le système, et cela marche tout seul. Et tu y gagnes d'autres avantages liés à NixOS.
Mais au final, tu compares un outil de description de système et un outil de snapshot. Les deux traitent des problèmes différents et sont complémentaires.
L'outil de snapshot n'explique pas comment tu es arrivé à cette configuration là. L'outil de snapshot ne permet pas te partager ton installation entre plusieurs machines (avec des variantes). L'outil de snapshot ne te protège pas des dérives progressives de ta distribution qui mise à jour après mises à jour vas devenir différent d'un installation fraîche.
Par contre NixOS ne te protège pas de la perte de donnée accidentelle ou par erreur, et il faut faire des snapshot et des backups. Par contre NixOS peut te permettre de configurer ton outil de snapshot / backup.
Note que je ne backup / snapshot plus du tout mon système depuis que j'utilise NixOS, car je peux réinstaller mon système à l'identique à partir de ma configuration NixOS. Par contre, je continue à faire des snapshot et des backups de mes documents. Au final cela génère beaucoup moins d'activité sur mon système de backup. A titre d'information, mon système fait actuellement 27 Giga octet. C'est 27 Giga octet qui ne pollue pas mes backups chaque fois que je fais une mise à jour système qui remplace ceux-ci à neuf. Par contre, les fichiers importants de mon home font une dizaine de Giga octets, mais l'évolution est plus incrementale (i.e. je ne change pas tout d'un coup, donc on parle de quelques Mo de backup par jour).
L'outil de snapshot / backup ne te permet pas à ma connaissance de restaurer une configuration à l'identique sur une nouvelle machine en quelques minutes.
L'outil de snapshot / backup est plus lourd quand tu veux réaliser une bissection dans ton système. Cela ne m'a jamais servis sur une machine perso, mais sur un problème professionnel, on a cherché une régression de performance sur une de nos machine de production, il a suffit de "git bisect" la configuration nixos de la machine. En premier lieu on a pu le faire dans une VM et en second lieu, on aurait jamais pu le faire avec un outil de snapshot car on aurait pas gardé tous les snapshot sur la durée de vie de cette machine. Et puis, quand tu trouves le snapshot qui introduit la regression, après il faut chercher dedans ce qui est different. Avec NixOS, t'as directement le diff de ton fichier de configuration.
Tu peux aussi tester des configurations complètement différentes sans augmenter le poids de ton backup / snapshot. Par exemple, installer tout KDE, et finalement décider que tu veux tout GNOME, puis décider que finalement tu veux juste un système minimaliste. Autant ces changements apparaîtront dans le snapshot / backup de ta configuration, mais pas les gigabytes nécessaires au snapshot / backup des applications.
Bref, NixOS a d'autres avantages que juste faire des rollback d'install et même là, je trouve que NixOS est meilleure pour faire des rollback d'install que de nombreuses autre solutions.
[^] # Re: à chacun sa vision de la simplicité
Posté par mahikeulbody . Évalué à 3.
Il y a un gros malentendu : je ne compare rien du tout. Je me contente de répondre à cette partie du journal
L'auteur aurait écrit "Une solution classique à ce risque est de faire un snapshot avec Timeshift, lancer la mise-à-jour et revenir au snapshot précédent en cas de problème. Ou sinon, utiliser NixOS…" je n'aurais absolument pas réagi. 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.
Ça ne change rien au fait que NixOS puisse être conceptuellement plus élégant, résoudre des problèmes de dépendances que d'autres systèmes auront peut-être plus de mal à résoudre, etc… là n'était pas mon propos.
[^] # Re: à chacun sa vision de la simplicité
Posté par nokomprendo (site web personnel) . É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 barmic 🦦 . Évalué à 3.
Si je suis que j'adore mon vélo, il va falloir que tu le compare au tiens pour venir me dire que le tiens est meilleur ?
Il décrit une solution, je ne vois pas ce qui présume que c'est la seule ou la meilleure ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: à chacun sa vision de la simplicité
Posté par nokomprendo (site web personnel) . É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 mahikeulbody . Évalué à 2. Dernière modification le 25 novembre 2020 à 21:21.
J'ai expliqué plus haut le pourquoi de mon commentaire initial. Affirmer que ta solution est mieux en tournant en dérision la mienne m'a incité à te répondre. Je me rends compte que c'était une perte de temps. Je vais donc en rester là. Contrairement à toi je n'ai rien à promouvoir. Tu es heureux avec NixOS, moi avec Manjaro et mes snapshots, tout va bien.
[^] # Re: à chacun sa vision de la simplicité
Posté par nokomprendo (site web personnel) . É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 Guillaum (site web personnel) . Évalué à 2.
Tu te fais des millions avec nix? Tu embauches? (Je gagne bien ma vie, en partie avec nix, mais pas "des millions" ;)
[^] # Re: à chacun sa vision de la simplicité
Posté par mothsART . Évalué à 4.
Allez, on se calme, cet espace est justement la pour échanger (troller) et on commence à avoir l'habitude que ça tourne au conflit d'intérêt. C'est une des grandes traditions sur linuxfr !
Perso, j'ai apprécié ton article (et d'ailleurs tout ceux que tu réalises autours de Nix) : c'est toujours enrichissant de voir des problématiques être traités différemment.
Au final, peut importe celle qui est la mieux, ce que je trouve toujours édifiant autours du libre c'est la grande richesse de possibilités et le fait que dans tout choix technique, il y ai des avantages et des inconvénients et donc un arbitrage à faire, soit individuel soit collectif.
Perso, les rollbacks Nix sont vraiment une des fonctionnalités qui m'intéresse le moins dans la techno. L'installation en user, le fait de pouvoir l'utiliser sur une distrib hors NixOS, le côté "fonctionnel" et la simplicité de créer ses propres paquets m’enthousiasme d'avantage mais c'est toujours bien d'avoir une vision plus large que celle de ses propres besoins.
Après, à l'avenir, si tu construisais ton article avec :
"Voici comment la plupart font et voici comment je fais" plutôt que "j'ai une meilleur solution" tuerais sans doute un vent de protestation dans l’œuf.
[^] # Re: à chacun sa vision de la simplicité
Posté par Guillaum (site web personnel) . Évalué à 2.
En effet, erreur de compréhension de ma part ;)
[^] # Re: à chacun sa vision de la simplicité
Posté par barmic 🦦 . Évalué à 2.
C'est cocasse un défendeur de nix qui explique qu'autre chose que nix prend de la place disque :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: à chacun sa vision de la simplicité
Posté par Guillaum (site web personnel) . Évalué à 3.
Meme si je vois ce que tu veux dire (mon /nix/store fait à l'heure actuelle 230 Giga Octets), je trouve que c'est un peu se moquer de nix pour rien, car c'est principalement du cache. Sur ces 230 Giga, j'en ai 11 qui représentent le système installé (avec applications et configuration.). Ça je ne peux pas le purger. J'en ai 15 qui représentent des projets, perso ou pro. Cela peut se purger, j'aurais à le télécharger de nouveau quand je m’intéresserais de nouveau à ce projet.
Le reste, c'est du cache. D'ancienne configuration du système, ou même de build. Je me sers de nix comme build système chez certains client, donc j'ai des gigas d'artifacts intermediaires de build (type fichier
.ode compilation C++). Je peux tout purger maintenant et récupérer environ 200 Giga d'espace disque. Tant que mon disque n'est pas plein, je m'en fous un peu. Je pourrais aussi purger basé sur l’ancienneté, mais pareil, je n'en vois pas l’intérêt. Ce cache me servira peut-être ou peut-être pas dans le futur (e.g. bisect sur l’environnent d'un projet). Bref, tant qu'il ne m’embête pas, je le garde.Mais mon argument dans ce discours c'est que quoi qu'il arrive, ces données ne vont pas dans mon système de snapshot ni de backup. Ces données n'ont aucune valeur à être sauvegardés. Alors qu'avec un outil de snapshot système, chaque mise à jour augmente la taille de ton snapshot de plusieurs gigas octets, avec très peu de partage. Si tu fais un snapshot avant chaque commande sur ton gestionnaire de paquet, je veux bien parier une bière que rapidement ton système de snapshot va te prendre un disque entier et que tu vas devoir accepter de supprimer des snapshots. Pareil pour les backups, si tu fais une mise à jour système, c'est autant qui vont finir dans ton backup.
[^] # Re: à chacun sa vision de la simplicité
Posté par mahikeulbody . Évalué à 4. Dernière modification le 26 novembre 2020 à 12:28.
Je ne comprends pas ce mélange entre backup et snapshot. Je backup "/home" et je snapshote "/". Le backup, c'est pour retrouver mes données perdues, le snapshot, c'est pour pouvoir revenir en arrière si une mise à jour se passe mal. Je ne garde que les trois derniers snapshots (je ne vois pas l'intérêt dans mon cas d'en garder plus, ça représente, sur Manjaro, au moins deux mois), alors il n'y a aucun risque que je sature mon FS (d'autant moins qu'avec btrfs, seuls les blocs différents sont dupliqués).
A aucun moment, je n'ai prétendu que c'est une solution alternative à Nix. Je n'ai fait que répondre à une présentation de Nix où l'introduction mettait essentiellement l'accent sur "oh combien c'est plus facile de s'en sortir avec Nix qu'avec la solution snapshot si la dernière mise à jour de ta rolling release casse le système" ce qui est factuellement faux, bien au contraire. Je ne me sens pas concerné par une discussion sur les mérites comparés de Nix et de la solution snaphot, cette comparaison n'ayant à mon avis pas de sens sauf si on la restreint au cas d'utilisation abordé dans l'introduction.
[^] # Re: à chacun sa vision de la simplicité
Posté par Guillaum (site web personnel) . Évalué à 3.
En effet, l'usage que tu as ne risque pas de beaucoup saturer le système avec des updates espacés et pas de "backup" du système.
J'imaginais (à tort) que tu réalisais un snapshot avant chaque interaction avec le système (changement de configuration, (de)-installation d'un paquet), ce qui arrive sans doute plus souvent et qui stresserait un peu plus le système de snapshot / backup.
[^] # Re: à chacun sa vision de la simplicité
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 26 novembre 2020 à 16:47.
Je ne vois pas de quel "stress" tu parles dans un concept de COW. Sur un système utilisant zfs. btrfs ou hammerfs tu peux scripter une création de snapshot toutes les heures, jours, semaines et avoir une rotation automatique sans surcoût particulier. Ça fait juste plus de bruit si par exemple tu veux pouvoir tous les amorcer depuis ton grub mais pour le reste non.
[^] # Re: à chacun sa vision de la simplicité
Posté par Guillaum (site web personnel) . Évalué à 2.
Le stress dont je parle c'est que lors de ta mise à jour, tu vas "remplacer" plusieurs programmes. Généralement c'est plusieurs mega (voir giga) d'archives à récupérer et à décompresser.
Ton snapshot il va "stocker" la différence avant la mise à jour et après. Lors du mise à jour, il y a très peu de copy on write, parce qu'il y a beaucoup de choses qui changent. Donc tu as plusieurs giga de difference à stocker. La déduplication n'est pas non plus très performante car bien qu'il y ai des chances pour que les fichiers soient sensiblement les mêmes, il y aura plein de petites differences subtiles qui ne permettront pas un énorme partage. Si tu conserves plusieurs snapshot, c'est plusieurs fois plusieurs giga que tu as besoin de stocker. Ce n'est pas la fin du monde hein, mais cela prend vite de la place.
Et si tu fais des backups de cela, c'est la même chose, et tu payes en plus le temps de transfert vers le backup.
Après, si ta politique c'est de ne garder que deux snapshots locaux et qu'un nombre limité de snapshots dans ton backup, et de ne pas inclure le système dans le backup il n'y a pas de problème du tout.
Ton répertoire "home", contrairement au système, aura beaucoup plus tendance à évoluer "lentement". Généralement tu ne remplaces pas tout d'un coup, c'est bien plus incrémentale, moins "stressant" pour le système comparé à l'exemple précédant.
Maintenant j'admet (et j'ai admis) que je n'avais pas imaginé que mon interlocuteur faisait "peu" de snapshot. (En gros, il admet en faire un avant chaque grosse mise à jour, et en garder 2 ou 3, et ne pas faire de backup de son système, seulement son home). Bref, dans son cas, il n'y a pas trop de problème. On ne fait juste pas la même chose.
[^] # Re: à chacun sa vision de la simplicité
Posté par Psychofox (Mastodon) . Évalué à 2.
Quand tu fais une mise à jour de packages, notemment sur du rolling release, on parle rarement de GB mais de MB de différences. Il n'y a que sur une dist-upgrade que tu peux compter ça en gigas.
Du reste quand tu as plusieurs snapshots tu n'as que la différence incrémentale entre les snapshots à stocker, pas à chaque fois la différence totale avec l'état actuel.
[^] # Re: à chacun sa vision de la simplicité
Posté par nokomprendo (site web personnel) . É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 barmic 🦦 . Évalué à 3.
Je présume que tu parle de snapshot pre-zfs/hammerfs/btrfs. Avec la technique du CoW, c'est instantané et ça ne coûte que la place réellement nécessaire. Donc non tu ne peux pas avoir une rétention infinie, mais si tu te donne la liberté de consommer 230Gio alors tu as de quoi faire pour un paquet de temps. De plus la gestion est plus légère, il est parfaitement inutile de garder plus d'un certains nombre de snapshots (à choisir) et supprimer un snapshot ne coûte rien. Ça ne ralenti pas ton build suivant, ça prend le même temps quelque soit la taille de ton fs ou des données contrairement à une suppression de 200Gio sur disque. Définir une rétention est simple tu n'a qu'à supprimer la plus vielle snapshot, tu n'a pas à aller voir chaque fichiers pour ne supprimer que les plus vieux.
(Je sais pas pourquoi tu parle de backup quand il est question de snapshot)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: à chacun sa vision de la simplicité
Posté par Guillaum (site web personnel) . Évalué à 2.
Avant de discuter je voulais juste repréciser un truc. Je suis rentré dans le débat parce que je vois pleins d'avantages à nix versus le snapshot avant upgrade. J'ai aussi fais des suppositions sur comment était fait ces snapshot. Je pensais que l'utilisateur faisait un snapshot avant toute intervention sur son système (i.e. installation de paquet, changement de config, …) et concevrait ses snapshot pendant une longue période, parce que c'est ce que j'aurais fais. J'ai aussi imaginé que l'utilisateur intégrait ces snapshot dans sa procédure de backup.
Bref, j'ai mal compris, donc pas mal des points de mon argumentation ne sont pas valable dans ce contexte. Je veux bien admettre que nous ne sommes pas d'accord sur la stratégie de mise à jour.
Maintenant, tu soulèves certains points sur btrfs qui m’intéressent fortement et que j'aimerais discuter.
En gros, je ne suis pas d'accord avec toi ;) Mais ma connaissance de btrfs est limité, donc si je dis une connerie, arrête moi immédiatement.
Non, je parlais bien de snapshot btrfs.
La place réellement nécessaire lors d'une mise à jour importante c'est généralement égale à tout ce que tu as changé pendant cette mise à jour. Ce qui peut être beaucoup et le CoW ne va pas faire grand chose ici à mon avis.
Si tu met à jour un paquet de la version X à la version Y, ta distribution va commencer par supprimer les fichiers du paquet, puis installer les nouveaux, ainsi:
Donc je suis d'accord avec l'argument du snapshot instantané et qui ne prend que la place nécessaire, mais je pense que cette place nécessaire peut être très importante.
Ici je ne suis pas d'accord. Supprimer un snapshot va au moins lancer une cascade d'opération pour mettre à jour les meta données de ton file système. Toutes les données devenues orphelines après cette suppression vont devoir etre "collectée" et cela peut representer un gros travail.
La suppression des 200Gio par nix va faire sensiblement la même chose.
La grosse difference entre les deux? La suppression d'un snapshot se fera en un appel système et le reste c'est le file système qui fait. La suppression des 200 Gio risque de générer de nombreux appels pour chaque fichiers à supprimer.
Cependant, je vois un peu cela comme une analyse amortie. Dans le modèle snapshot + update, tu va supprimer et créer de nouveaux fichiers puis plus tard tu vas supprimer le snapshot. Dans le modèle "nix", tu vas seulement créer de nouveaux fichiers (donc pas d'appel système pour les suppressions) et plus tard, lors de la "purge", tu vas supprimer tes fichiers inutiles. Les deux sembles équivalents, mais pas au même instant.
Je me sers de snapshot dans ma stratégie de backup du système, d'ou ma confusion.
[^] # Re: à chacun sa vision de la simplicité
Posté par barmic 🦦 . Évalué à 2.
Effectivement c'est la déduplication qui peut aider (si elle est activée). Après je crois que fedora a un système qui permet de mettre à jour par application de diff. Ça doit simplifier les choses.
Il n'y a pas de miracle. Cet espace très important c'est la différence entre les 2 états de ton système. On peut envisager des compressions, des déduplication plus ou moins fine, c'est un curseur à positionner.
Non, il ne touche pas aux fichiers. Il modifie ces propres métadonnées pour supprimer la référence du snapshot. L'espace occupé ne sera réutilisé au fur et à mesure que tu en a besoin. C'est sans commune mesure avec un parcourt arborescent du système de fichiers.
Je ne sais pas pourquoi là tu parle de cascade d'opérations et en dessous tu parle d'un seul.
C'est exactement mon point.
Tu remplace la suppression par des créations de liens ce qui a le même coût.
En fait, nix fait la même chose que les snapshot sauf qu'avec la connaissance interne du système de fichier c'est bien plus rapide à manipuler, mais ça demande nécéssite un redémarrage pour faire le changement. Après nix a d'autres intérêts.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: à chacun sa vision de la simplicité
Posté par Guillaum (site web personnel) . Évalué à 2. Dernière modification le 27 novembre 2020 à 22:19.
Je crois que cela fonctionne à base de comptage de référence. En gros, tu as un arbre qui représente ton filesystem à un instant T, et un autre arbre à un instant T', qui partage le plus possible avec le premier arbre. Chaque sous arbre partagé ayant un compteur de référence supérieur à 1.
Bref, supprimer une référence, c'est faire -1 sur le compteur. Si celui-ci est à 0, alors on "supprime" et cette opération peut être récursive et donc prendre du temps.
Oui, mais dans un cas tu supprimes + crée, alors que dans l'autre cas tu crée seulement (et tu supprimera plus tard).
Je pense que les coûts sont assez similaires. J'ai envie de Benchmark cela.
[^] # Re: à chacun sa vision de la simplicité
Posté par mahikeulbody . Évalué à 2.
Ça ne vaut pas un benchmark mais je peux dire que même en cas de mise à jour de plusieurs Go, c'est quasiment instantané, tant pour créer un snapshot que pour en supprimer un.
NB. Je précise que mon "/" est sur un SSD (mais limité par un connecteur SATA 2).
[^] # Re: à chacun sa vision de la simplicité
Posté par barmic 🦦 . Évalué à 2.
Tu as tout à fais raison, pour le fonctionnement, je me suis trompé par contre.
Suivre une série de pointeurs dans un arbre balancé et faire une série d'appels systèmes pour lister le contenu des répertoires puis supprimer chaque fichier n'a sans doute pas le même coût.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.