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".
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.
Bah non, c'est ton ressenti et je suis content que tu l'aies partagé.
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.
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).
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 ?)
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.
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.
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.
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.
modifier les fichiers dans /etc : ??? je n'ai jamais besoin de toucher à ça
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
deviner d'où viennent les éventuels problèmes : pas besoin, je reviens au snapshot précédent en attendant qu'ils soient corrigés
apprendre conda/venv/chef/whatever : ??? je n'ai jamais besoin de toucher à ça
écrire des Dockerfile : ??? je n'ai jamais besoin de toucher à ça
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 ?
Je pense avoir le droit à un peu d'humour, d'autant plus que personnellement je ne critique pas le moindre blog ou commentaire […]
Peut-être n'ai-je pas perçu l'humour. Quoiqu'il en soit, je regrette cette partie de mon commentaire, tout à fait inutile.
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.
Si on veut minimiser le nombre de coups en moyenne (i.e. sur un grand nombre de parties) sans compter sur le hasard, il me semble qu'il ne faut pas exclure de jouer des coups incompatibles mais qui apportent plus d'information. J'ai programmé ce jeu il y a quelques décennies (avec un algorithme de parcours d'arbre classique et min-max) et il me semble bien que le programme sortait aussi des coups incompatibles avec la connaissance disponible au tour concerné.
En fait, les deux modes proposés (BTRFS et RSYNC) correspondent à des fonctionnalités différentes* : la gestion de snapshot btrfs et une fonctionnalité plus classique de sauvegarde basée sur rsync. Quand Timeshift est en mode BTRFS, il montre les différents sous-volumes btrfs existants et permet de choisir celui pour lequel on veut faire un snapshot. Quand il est en mode RSYNC, il propose comme tout logiciel de sauvegarde le choix des dossiers à sauvegarder. Pour ma part, je ne l'utilise qu'en mode BTRFS pour faire des snapshots du sous-volume btrfs "/" et j'utilise un autre logiciel (borg) pour la sauvegarde de mes données.
* Un snapshot n'est pas vraiment une sauvegarde. Certes il fige une image du passé mais sur le même disque…
L'explication "serait" que certains environnements graphiques (Gnome, notamment) sont plus sujets à avoir des problèmes si la mise à jour est effectuée en mode graphique.
Il est même conseillé de faire pacman -Syu dans un terminal hors environnement graphique (i.e. accessible via ctrl-alt F3 par exemple).
Pour moi, cette phrase est mal formulée ou bien est un non-sens. Elle laisse entendre qu'avant d'utiliser Manjaro il faudrait utiliser Arch. D'abord "utiliser" n'est pas le bon terme car ce qui différencie les deux, c'est surtout l'installation. Si on a été au bout de celle de Arch (configuration comprise), je ne vois plus trop l'intérêt de passer à Manjaro.
[…] le fait qu'elle [Manjaro] utilise ses propres dépôts m'a rapidement fait fuir. On perd tout l'intérêt de la rolling release et c'est pas aussi à jour que sous Arch.
Ce sont ses propres dépôts mais ils s'agit pour l'essentiel des mêmes paquets que sous Arch mais décalés de 2 à 4 semaines. Par ailleurs, l'intérêt d'une rolling release n'est pas uniquement d'avoir des mises à jour immédiates mais d'éviter les changements de version à la Ubuntu et consorts. En ce qui me concerne, attendre 2 à 4 semaines la dernière version du noyau ou de LO ne me traumatise pas plus que ça et en 2 ans je n'ai eu qu'une seule fois un souci de mise à jour (facilement réglé en revenant au snapshot précédent).
Mettre les mains dans le cambouis d'une distribution Linux c'est très formateur mais c'est comme la mécanique auto, ça n'intéresse pas tout le monde.
Il y a je crois un utilitaire btrfs pour ça. Après il faudra vérifier si le fait de créer une entrée dans grup pour les snapshots existants de "/" est mis en place à l'installation du système ou bien si le FS de "/" est re-testé à chaque mise à jour (à moins que ce ne soit Timeshift lui-même qui mette à jour les entrées dans grub ?). J'avoue ne pas avoir creusé car j'ai installé Manjaro directement avec btrfs.
btrfs donne aussi une solution pour le dimensionnement de "/" : il suffit de choisir aussi btrfs pour "/home". Dans ce cas (et sous réserve que les deux points de montage soient sur le même disque), l'installation va créer deux sous-volumes qui se comportent comme deux partitions mais sans dimensionnement prédéfini entre les deux.
Pour se prémunir d'éventuels problèmes lors d'une mise à jour, il est, comme indiqué dans le journal, conseillé de consulter le forum (https://forum.manjaro.org/c/announcements/stable-updates/12). Ceci étant dit, j'utilise pour ma part la solution suivante : choisir btrfs comme FS pour "/" à l'installation.
Avant chaque mise à jour, faire un snapshot de "/" avec Timeshift (et supprimer le plus ancien pour ne pas en avoir un trop grand nombre, personnellement je n'en garde que trois). Faire la mise à jour. Dans le cas d'un "/" en btrfs, Manjaro va automatiquement créer une entrée dans le menu de grub (en fait, une entrée par snapshot existant sur "/").
Comme ça, plus de stress et on peut profiter sans souci des avantages d'une rolling release, pour ma part en saveur KDE. Ceci dit, je crois n'avoir eu qu'une fois en deux ans un souci nécessitant d'utiliser un précédent snapshot pour ré-démarrer.
Utiliser les snapshots comme points de restauration de / ne nécessite pas de les exporter, il n'y a donc rien de contradictoire.
btrfs, tout comme zfs, a deux autres avantages par rapport à un FS classique qui sont autant de raisons, pour moi, de vouloir l'utiliser : détection auto (et même correction auto si raid) des corruptions de donnée, raid 1 très souple (différent du raid 1 classique).
Pour revenir sur la sauvegarde, je n'ai pas creusé les possibilités offertes par send snapshot, notamment pour faire de l'incrémental, car j'utilisais déjà borg et j'en suis satisfait. Je ne peux donc pas en parler.
Je n'utilise les snapshots btrfs que sur /. Avant chaque mise à jour du système, je fais un snapshot de / avec Timeshift, celui-ci est automatiquement rajouté au menu de démarrage de grub par Manjaro, ce qui me permet d'être à peu près sûr de redémarrer s'il y a un gros problème sur la mise à jour.
En revanche, je ne les utilise pas pour les sauvegardes de /home et autres partitions de données mais tout est quand même sous btrfs dont l'intérêt ne réside pas que dans la possibilité de faire des snapshots.
Peut-être parce que le sujet du journal est la sauvegarde et qu'un raid, aussi résilient soit-il, ne protège pas contre les pertes de données dues à d'autres causes que les problèmes disque. Seule une sauvegarde avec historisation (et si possible deux destinations, une locale et une externe) peut répondre à ce problème. Si le raid en question assure une détection et une correction des erreurs disque, c'est très bien mais ça ne remplace pas une sauvegarde pour autant.
Le RAID me parait inutile et coûteux. Il répond selon moi à des questions de disponibilité, pas de sauvegarde.
Pas que. Par exemple le RAID 1 sous BTRFS permet la détection et la correction automatique d'une corruption. Je m'en sers pour ça, pas spécialement pour la disponibilité.
Ca permet d'éviter (autant que possible) qu'une corruption ne se propage le long de l'historique jusqu'à ce qu'il n'y ait plus aucune version du fichier non corrompue. De ce point de vue, ça répond à une problématique de la sauvegarde (mais ça ne la remplace absolument pas, on est bien d'accord).
[^] # Re: à chacun sa vision de la simplicité
Posté par mahikeulbody . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. É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 mahikeulbody . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. É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 mahikeulbody . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. É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: ah bon
Posté par mahikeulbody . En réponse au lien Les voitures hybrides rechargeables polluent beaucoup plus qu'annoncé. Évalué à 9.
C'est bien une remarque de citadin …
Plus sérieusement, à mon avis beaucoup de ceux qui utilisent une voiture pour aller au boulot font plus de 30km AR.
# à chacun sa vision de la simplicité
Posté par mahikeulbody . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. É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.
# coups incompatibles
Posté par mahikeulbody . En réponse au journal Yes Master. Évalué à 2.
Si on veut minimiser le nombre de coups en moyenne (i.e. sur un grand nombre de parties) sans compter sur le hasard, il me semble qu'il ne faut pas exclure de jouer des coups incompatibles mais qui apportent plus d'information. J'ai programmé ce jeu il y a quelques décennies (avec un algorithme de parcours d'arbre classique et min-max) et il me semble bien que le programme sortait aussi des coups incompatibles avec la connaissance disponible au tour concerné.
[^] # Re: I use Arch BTW
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 4.
Idem pour Octopi : il faut installer un paquet pour avoir le support de AUR.
[^] # Re: snapshot
Posté par mahikeulbody . En réponse au message Besoin de quelques éclaircissements sur btrfs. Évalué à 4.
En fait, les deux modes proposés (BTRFS et RSYNC) correspondent à des fonctionnalités différentes* : la gestion de snapshot btrfs et une fonctionnalité plus classique de sauvegarde basée sur rsync. Quand Timeshift est en mode BTRFS, il montre les différents sous-volumes btrfs existants et permet de choisir celui pour lequel on veut faire un snapshot. Quand il est en mode RSYNC, il propose comme tout logiciel de sauvegarde le choix des dossiers à sauvegarder. Pour ma part, je ne l'utilise qu'en mode BTRFS pour faire des snapshots du sous-volume btrfs "/" et j'utilise un autre logiciel (borg) pour la sauvegarde de mes données.
* Un snapshot n'est pas vraiment une sauvegarde. Certes il fige une image du passé mais sur le même disque…
[^] # Re: snapshot
Posté par mahikeulbody . En réponse au message Besoin de quelques éclaircissements sur btrfs. Évalué à 3.
Je n'ai pas d'onglet 'Filters'. As-tu bien sélectionné le type BTRFS (et non pas RSYNC) pour tes instantanés ?
[^] # Re: Certains renseignements m'auraient bien servi
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 4. Dernière modification le 21 novembre 2020 à 11:20.
L'explication "serait" que certains environnements graphiques (Gnome, notamment) sont plus sujets à avoir des problèmes si la mise à jour est effectuée en mode graphique.
Il est même conseillé de faire pacman -Syu dans un terminal hors environnement graphique (i.e. accessible via ctrl-alt F3 par exemple).
[^] # Re: pour se prémunir d'éventuels problèmes lors d'une mise à jour
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 4.
Pourquoi pas mais je n'en sais guère plus que ce j'ai dit ici. Je peux néanmoins relire la partie correspondante.
[^] # Re: pour se prémunir d'éventuels problèmes lors d'une mise à jour
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 3.
Je ne connaissais pas, merci.
[^] # Re: Bien débuter avec Manjaro
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 6. Dernière modification le 19 novembre 2020 à 19:05.
Pour moi, cette phrase est mal formulée ou bien est un non-sens. Elle laisse entendre qu'avant d'utiliser Manjaro il faudrait utiliser Arch. D'abord "utiliser" n'est pas le bon terme car ce qui différencie les deux, c'est surtout l'installation. Si on a été au bout de celle de Arch (configuration comprise), je ne vois plus trop l'intérêt de passer à Manjaro.
Ce sont ses propres dépôts mais ils s'agit pour l'essentiel des mêmes paquets que sous Arch mais décalés de 2 à 4 semaines. Par ailleurs, l'intérêt d'une rolling release n'est pas uniquement d'avoir des mises à jour immédiates mais d'éviter les changements de version à la Ubuntu et consorts. En ce qui me concerne, attendre 2 à 4 semaines la dernière version du noyau ou de LO ne me traumatise pas plus que ça et en 2 ans je n'ai eu qu'une seule fois un souci de mise à jour (facilement réglé en revenant au snapshot précédent).
Mettre les mains dans le cambouis d'une distribution Linux c'est très formateur mais c'est comme la mécanique auto, ça n'intéresse pas tout le monde.
Ah mince, je suis tombé en plein dans le troll !
[^] # Re: Certains renseignements m'auraient bien servi
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 3.
Il l'est dans certaines distributions (Fedora, OpenSuse notamment).
[^] # Re: pour se prémunir d'éventuels problèmes lors d'une mise à jour
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 5.
Il y a je crois un utilitaire btrfs pour ça. Après il faudra vérifier si le fait de créer une entrée dans grup pour les snapshots existants de "/" est mis en place à l'installation du système ou bien si le FS de "/" est re-testé à chaque mise à jour (à moins que ce ne soit Timeshift lui-même qui mette à jour les entrées dans grub ?). J'avoue ne pas avoir creusé car j'ai installé Manjaro directement avec btrfs.
[^] # Re: Certains renseignements m'auraient bien servi
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 5.
btrfs donne aussi une solution pour le dimensionnement de "/" : il suffit de choisir aussi btrfs pour "/home". Dans ce cas (et sous réserve que les deux points de montage soient sur le même disque), l'installation va créer deux sous-volumes qui se comportent comme deux partitions mais sans dimensionnement prédéfini entre les deux.
[^] # Re: du materiel ?
Posté par mahikeulbody . En réponse au message Mon pc a des phases rapide et d'autre très lente. Évalué à 6.
et font souvent de l'indexation par défaut.
# pour se prémunir d'éventuels problèmes lors d'une mise à jour
Posté par mahikeulbody . En réponse à la dépêche Bien débuter avec Manjaro Linux. Évalué à 5. Dernière modification le 19 novembre 2020 à 15:56.
Pour se prémunir d'éventuels problèmes lors d'une mise à jour, il est, comme indiqué dans le journal, conseillé de consulter le forum (https://forum.manjaro.org/c/announcements/stable-updates/12). Ceci étant dit, j'utilise pour ma part la solution suivante : choisir btrfs comme FS pour "/" à l'installation.
Avant chaque mise à jour, faire un snapshot de "/" avec Timeshift (et supprimer le plus ancien pour ne pas en avoir un trop grand nombre, personnellement je n'en garde que trois). Faire la mise à jour. Dans le cas d'un "/" en btrfs, Manjaro va automatiquement créer une entrée dans le menu de grub (en fait, une entrée par snapshot existant sur "/").
Comme ça, plus de stress et on peut profiter sans souci des avantages d'une rolling release, pour ma part en saveur KDE. Ceci dit, je crois n'avoir eu qu'une fois en deux ans un souci nécessitant d'utiliser un précédent snapshot pour ré-démarrer.
[^] # Re: snapshot
Posté par mahikeulbody . En réponse au message Besoin de quelques éclaircissements sur btrfs. Évalué à 2.
Utiliser les snapshots comme points de restauration de / ne nécessite pas de les exporter, il n'y a donc rien de contradictoire.
btrfs, tout comme zfs, a deux autres avantages par rapport à un FS classique qui sont autant de raisons, pour moi, de vouloir l'utiliser : détection auto (et même correction auto si raid) des corruptions de donnée, raid 1 très souple (différent du raid 1 classique).
Pour revenir sur la sauvegarde, je n'ai pas creusé les possibilités offertes par send snapshot, notamment pour faire de l'incrémental, car j'utilisais déjà borg et j'en suis satisfait. Je ne peux donc pas en parler.
# snapshot
Posté par mahikeulbody . En réponse au message Besoin de quelques éclaircissements sur btrfs. Évalué à 2. Dernière modification le 18 novembre 2020 à 21:06.
Je n'utilise les snapshots btrfs que sur /. Avant chaque mise à jour du système, je fais un snapshot de / avec Timeshift, celui-ci est automatiquement rajouté au menu de démarrage de grub par Manjaro, ce qui me permet d'être à peu près sûr de redémarrer s'il y a un gros problème sur la mise à jour.
En revanche, je ne les utilise pas pour les sauvegardes de /home et autres partitions de données mais tout est quand même sous btrfs dont l'intérêt ne réside pas que dans la possibilité de faire des snapshots.
[^] # Re: Pourquoi si compliqué ?
Posté par mahikeulbody . En réponse au journal Sauvegarde de données. Évalué à 2.
Faux, borg fait de la compression.
[^] # Re: Snapraid
Posté par mahikeulbody . En réponse au journal Sauvegarde de données. Évalué à 2.
Peut-être parce que le sujet du journal est la sauvegarde et qu'un raid, aussi résilient soit-il, ne protège pas contre les pertes de données dues à d'autres causes que les problèmes disque. Seule une sauvegarde avec historisation (et si possible deux destinations, une locale et une externe) peut répondre à ce problème. Si le raid en question assure une détection et une correction des erreurs disque, c'est très bien mais ça ne remplace pas une sauvegarde pour autant.
[^] # Re: Scénarii ?
Posté par mahikeulbody . En réponse au lien scénarii de propagation du virus sars-2. Évalué à 2. Dernière modification le 10 novembre 2020 à 21:49.
Ok, merci !
[^] # Re: Sauvegarde Paranoïa
Posté par mahikeulbody . En réponse au journal Sauvegarde de données. Évalué à 4.
Pas que. Par exemple le RAID 1 sous BTRFS permet la détection et la correction automatique d'une corruption. Je m'en sers pour ça, pas spécialement pour la disponibilité.
Ca permet d'éviter (autant que possible) qu'une corruption ne se propage le long de l'historique jusqu'à ce qu'il n'y ait plus aucune version du fichier non corrompue. De ce point de vue, ça répond à une problématique de la sauvegarde (mais ça ne la remplace absolument pas, on est bien d'accord).
[^] # Re: Pourquoi si compliqué ?
Posté par mahikeulbody . En réponse au journal Sauvegarde de données. Évalué à 2.
C'est aussi un FS qui évolue donc ce qu'il était il y a quelques années ne reflète pas/plus ce qu'il est aujourd'hui.