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 .o de 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 Guillaum (site web personnel) . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. É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.