Ç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).
Pour ma part j'ai mis le fichier keepass dans une Dropbox (compte gratuit qui ne sert qu'à ça). Quand je veux ouvrir un fichier keepass sur un device (PC, smartphone, tablette, …) je sélectionne le fichier directement dans le drive Dropbox (Dropbox a un cache local dans le device, ce qui fait que le fichier reste accessible même sans connexion internet). De cette façon, mon fichier keepass est automatiquement synchronisé. Keepass détecte s'il y a eu des modifications concurrentes et proposera de les fusionner si elles sont compatibles.
Certains disent que le mécanisme de gestion des éventuels conflits n'est pas suffisamment robuste en cas de multi-utilisateurs. Je n'ai jamais eu de problème mais chez moi le multi-utilisateurs, c'est seulement deux personnes qui ne créent pas de mots de passe toutes les 5'. En tous cas, pour un usage personnel, la synchronisation entre plusieurs clients par cette méthode est automatique.
NB. C'est bien de faire un backup de temps en temps du fichier dans Dropbox car si on supprime le fichier par mégarde dans un device il va disparaître de tous les devices, Dropbox version gratuite n'offre pas de sécurité à ce sujet. Mais ce n'est pas une problématique propre à Keepass.
NB2. On peut remplacer Dropbox par un autre cloud gratuit. J'ai choisi Dropbox par rapport à Google Drive car il y a un client Linux natif.
Il suffit d'avoir un serveur Git pour faire les synchros (par SSH pour la sécurité), sachant que les fichiers dessus sont crypter GPG, et que la clé (protégé par mot de passe) ne sort pas du client… bref, simple, pratique, sécurisé…
"serveur Git" … "simple"
C'est une solution simple pour toi, absolument pas pour l'usager lambda (surtout si en plus le serveur doit être accessible depuis l'extérieur de chez toi).
J'utilise également keepassxc, qui est plus pratique au quotidien que l'interface (un peu lourde) de nextcloud. Par contre, il plante très souvent, ça vous le fait aussi ?
Absolument aucun plantage avec keepassxc (sous Manjaro/KDE) que j'utilise pourtant plusieurs fois par jour.
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.
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.
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.
Il y a un gros malentendu : je ne compare rien du tout. Je me contente de répondre à cette partie du journal
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…
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.
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".
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.
Si mon instantané peut être fait automatiquement, c'est mieux.
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).
J'avoue que si tu règles ces 2 points […]
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).
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.
[^] # 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.
Ç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: Ou si
Posté par mahikeulbody . En réponse à la dépêche KeePass, ou apprendre à gérer correctement ses mots de passe. Évalué à 4. Dernière modification le 27 novembre 2020 à 13:16.
Pour ma part j'ai mis le fichier keepass dans une Dropbox (compte gratuit qui ne sert qu'à ça). Quand je veux ouvrir un fichier keepass sur un device (PC, smartphone, tablette, …) je sélectionne le fichier directement dans le drive Dropbox (Dropbox a un cache local dans le device, ce qui fait que le fichier reste accessible même sans connexion internet). De cette façon, mon fichier keepass est automatiquement synchronisé. Keepass détecte s'il y a eu des modifications concurrentes et proposera de les fusionner si elles sont compatibles.
Certains disent que le mécanisme de gestion des éventuels conflits n'est pas suffisamment robuste en cas de multi-utilisateurs. Je n'ai jamais eu de problème mais chez moi le multi-utilisateurs, c'est seulement deux personnes qui ne créent pas de mots de passe toutes les 5'. En tous cas, pour un usage personnel, la synchronisation entre plusieurs clients par cette méthode est automatique.
NB. C'est bien de faire un backup de temps en temps du fichier dans Dropbox car si on supprime le fichier par mégarde dans un device il va disparaître de tous les devices, Dropbox version gratuite n'offre pas de sécurité à ce sujet. Mais ce n'est pas une problématique propre à Keepass.
NB2. On peut remplacer Dropbox par un autre cloud gratuit. J'ai choisi Dropbox par rapport à Google Drive car il y a un client Linux natif.
[^] # Re: Autre alternative plus "geek"
Posté par mahikeulbody . En réponse à la dépêche KeePass, ou apprendre à gérer correctement ses mots de passe. Évalué à 3.
Je fais amende honorable, le titre m'avait effectivement échappé !
[^] # Re: Autre alternative plus "geek"
Posté par mahikeulbody . En réponse à la dépêche KeePass, ou apprendre à gérer correctement ses mots de passe. Évalué à 1.
"serveur Git" … "simple"
C'est une solution simple pour toi, absolument pas pour l'usager lambda (surtout si en plus le serveur doit être accessible depuis l'extérieur de chez toi).
[^] # Re: keeweb et keepassxc
Posté par mahikeulbody . En réponse à la dépêche KeePass, ou apprendre à gérer correctement ses mots de passe. Évalué à 4.
Absolument aucun plantage avec keepassxc (sous Manjaro/KDE) que j'utilise pourtant plusieurs fois par jour.
[^] # 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é à 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 mahikeulbody . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. É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 mahikeulbody . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. É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 mahikeulbody . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. É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 mahikeulbody . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. É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 mahikeulbody . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. É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 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).