mahikeulbody a écrit 1671 commentaires

Je pirate Lightroom (car il n'a pas d'équivalent sous Linux), mais pour mes besoins Gimp me suffit, donc je ne pirate pas Photoshop…

Il aurait été plus juste de dire :

Je pirate Lightroom car les équivalents Linux existent mais ne me conviennent pas autant que Lightroom, alors que je ne pirate pas Photoshop car Gimp me suffit.

NB. Il ne s'agit pas ici de lancer une discussion sur les mérites comparés des différents logiciels impliqués, il s'agit juste de rectifier une contre-vérité : il y a des équivalents* à Lightroom sous Linux (Darktable, Rawtherapy, Digikam principalement).

* au sens "on peut faire les mêmes choses", sans préjuger de la façon plus ou moins facile de les faire selon le logiciel.

Par ailleurs, au delà du fait que pirater c'est pas bien, pirater un logiciel dont certaines sorties sont propriétaires est assez risqué. En effet, si les tags IPTC ou XMP créés avec Lightroom sont portables d'un logiciel à un autre, les historiques de développement raw eux ne le sont pas => ils seront complètement perdus si un jour on ne peut plus pirater le logiciel. Or un photographe qui développe ses raw accepte rarement de bon cœur de les perdre (et si c'est un pro, c'est difficilement envisageable).

Tu pourrais peut-être essayer de configurer un compte google juste pour voir si ça te permet de désactiver le service sans que Settings plante. Puis une fois le service arrêté, tu n'aurais plus qu'à désinstaller le compte.

L'idée sous-jacente est qu'il s'agit peut-être d'un bug provoqué par l'absence de compte google au moment de désactiver un service google.

Mais même si c'est ça, ça n'expliquerait pas comment le service s'est retrouvé activé s'il n'y a jamais eu de compte google configuré sur ce smartphone…

Si j'ai bien compris ce n'est pas l'app elle-même qui est en cause (si ça se trouve, il ne l'a pas non plus). En fait il veut désactiver le service qui écoute les requêtes extérieures demandant la localisation du smartphone (requêtes faite via une page web ou via un FDM installé sur un autre device Android).

Cette désactivation est un paramétrage (voir son post plus haut sur comment l'effectuer) sauf que chez lui ça plante l'appli 'Paramétrages'. Du coup, il cherche à carrément désinstaller le service.

Ce plantage ressemble à un vrai bug car je ne l'ai pas rencontré dans aucun de mes smartphones Android jusqu'à présent (ce qui serait le cas si c'était un truc exprès pour ne pas pouvoir désactiver le service).

plus de garantie non plus…

(moi, j'attends toujours la fin de la garantie avant d'installer une AOSP, ce qui colle en général avec le moment où le fabricant ne met plus ce modèle à jour)

ça me dit, me montre, le nom ubuntu 18, alors que c'est impossible que j'ai ubuntu 18 installé, vu que l’architecture de mon processeur est de 32bits, donc j'ai installé linux mint.

Mint étant basé sur Ubuntu, il n'est pas impossible qu'il y ait quelques scories qui traînent.

Je viens d'essayer sur le mien, ça désactive bien la fonction, sans crash.
Je suis sous Android 7.

La pub pour FMD se trouve dans tes options puis "Google" => "Security" => "Find My Device".

Ok, j'ai ça aussi mais comme tu dis, ça reste une pub pour une application qu'on a de toutes façons peu de raisons d'installer puisqu'en général si on perd son smartphone on va passer par le web sur un PC pour le localiser (à moins d'avoir plusieurs devices android).

Indépendamment de cette "pub", il y aussi un switch d'activation de la fonction à cet endroit.

Pour voir les [comptes] administrateurs sur l'appareil c'est dans options => "écran de verrouillage et Sécurité" => "Administrateurs de l'appareil".

Moi, j'ai ça dans Sécurité et localisation/Applis d'administration d'appareil où j'ai aussi un switch permettant d'activer ou pas la fonction.

Du coup, si tu désactives la fonction dans le ou les endroits où on en parle, ça ne suffit pas ?

Sur mon smartphone, les choses sont un peu différentes : je ne vois pas de FMD et dans la partie 'administration' je peux cocher/décocher la fonction "localiser mon appareil" (j'aurais préféré un truc plus précis comme "autorisation de localiser mon appareil à ma demande").

Google n'a pas besoin d'un compte google pour t'espionner.

Tu donnes de l'eau à mon moulin !

Puisque c'est Google qui développe FMD et qu'il n'en a pas besoin pour te localiser (entre autres choses), pourquoi veux-tu désinstaller FMD ?

Enfaite c'est peut-être un gros bug (franchement sérieux niveau sécurité…) d'android.

Ah, lequel ?

(tu as lu mon autre commentaire ?)

Supprimer cette application ne sert à rien (sauf pour gagner de la place en mémoire) car elle n'est pas en charge de communiquer la localisation du smartphone où elle est installée, elle est en charge de trouver celle d'un autre device Android dont on possède le login-password du compte Google installé (s'il y en a un).

Ce n'est pas un daemon, c'est un client.

Pour localiser le smartphone concerné, il n'y a pas besoin que Find My Device soit installé, il suffit d'utiliser un navigateur web sur n'importe quel PC et de chercher Find My Device dans Google, puis d'entrer les identifiants du compte Google associé à ton smartphone. En fait l'appli Android n'a de sens que si tu as d'autres devices Android dont tu possèdes les identifiants Google.

Pour résumer :
- une personne lambda ne peut pas localiser ton smartphone si elle n'a pas les identifiants de ton compte Google, que Find My Device soit installé ou pas
- une personne lambda peut localiser ton smartphone si elle a les identifiants de ton compte Google, que Find My Device soit installé ou pas
- Google pourra te suivre à la trace si tu as un compte Google, que Find My Device soit installé ou pas
- il n'y a pas lieu de se méfier de Find My Device car… elle est développée par Google qui n'en a pas besoin pour te localiser (voir alinéa précédent)
- cette application n'est utile que si tu as un autre device Android ("utile" mais pas nécessaire puisqu'on peut aussi utiliser un navigateur web, y compris sur ton smartphone)

J'imagine qu'il faut prendre en compte l'historique du logiciel et des toolkits multi-plateforme disponibles au début du projet. Peut-être qu'en démarrant aujourd'hui ils auraient choisi un toolkit existant multi-plateforme, Qt5 par exemple, au lieu de développer une solution interne.

Ceci dit, vu qu'ils ont aussi créé Rust alors qu'il y avait très probablement d'autres langages qui auraient pu convenir, c'est peut-être l'effet du syndrome "not invented here" (même si au final, ça donne un très bon langage utilisable par la communauté).

Dans ma vision naïve des choses, Wayland n'impactait que les toolkits graphiques utilisés par les applications.
Qu'est-ce que je n'ai pas compris ?

> elle n'est plus vendu comme rolling ? ok, j'ai vécu sous un pont.

Je pense même que tu es né sous le pont vu que sauf erreur grossière de ma part Fedora n'a jamais été une rolling release (ou alors à une époque dont le commun des mortels n'a pas souvenir).

Je n'ai rien compris !

Et que vient faire le rolling release dans cette diatribe contre une distribution qui ne l'est pas ?

Désolé, c'est grub-btrfs (et non l'inverse). Je l'ai trouvé dans les dépôts officiels de ma manjaro.

A moins que j'ai raté quelque chose, Timeshift ne garantit pas de pouvoir revenir en arrière.
En effet, on fait un snapshot de @/ avant une mise à jour. Puis on fait la mise à jour. Un éventuel problème peut être visible de suite, auquel cas on demande à Timeshift de restaurer les snapshot que l'on vient de faire et on reboote (la restauration implique un reboot pour être effective). Tout va bien.

Mais le problème peut aussi ne se révéler que lorsqu'on reboote le système après une mise à jour et que ça plante avant d'arriver sur le bureau => impossible de demander une restauration à Timeshift. Il faut se débrouiller avec les moyens habituels (pas forcément à la portée de Mr Michu).

C'est là qu'intervient btrfs-grub : il créé automatiquement une entrée dans grub pour chaque nouveau snapshot de @/. Du coup, si ça plante au redémarrage après la mise à jour, il suffit de choisir un des snapshots existants via une des entrées de grub.

Du coup, je n'utilise Timeshift que comme une UI pour créer un snapshot, les lister ou en supprimer, jamais pour en restaurer un.

Pour ce qui est de btrfs, je m'y suis mis moi aussi, y compris pour les données (en raid 1) et pour le moment j'en suis satisfait.

Je comprends bien qu'en réalité, tu as voulu dire "il faudrait que les applications XMPP existantes soient aussi simples à utiliser que Whatsapp" mais c'est de nature à induire en erreur Mamie Janine si elle venait à s'égarer par ici.

Par ailleurs, le titre laisse aussi entendre que l'interface de Whatsapp est mieux puisque plus facile à utiliser. En réalité, c'est au prix d'un gros bémol pas forcément acceptable par tous (la transmission automatique des contacts) que ce mieux est possible.

Un titre plus exact aurait pu être : "Acceptons de perdre un peu de notre privacité - et celles de nos amis qui n'ont rien demandé - afin d'avoir des messageries xmpp aussi faciles à utiliser que Whatsapp.

Après, l'article lui-même ne pose pas de problème, il explicite tout comme il faut.

Pour ce qui est de se servir des contacts pour établir automatiquement la liste des contacts tout en restant éthique j'ai la solution : il faut juste une déclaration sur l'honneur : "Si moi, sous-signé Whatsapp (par exemple), détecte qu'un contact de la liste est déjà dans ma base d'utilisateurs alors je l'utilise sinon je le jette, je l'oublie, c'est comme si ne l'avais jamais vu promis juré".

Simple, non ?
Mais juste pas crédible.

Il faut un disque dans chaque maison. Donc la solution avec deux maisons est plus chère.

Tu as raison, je vais m'en tenir à une seule maison, j'ai pas le budget pour deux disques.

Avec restic (j'imagine que c'est pareil pour les autres) je lance régulièrement restic check

Oui, il y a aussi un borg check (mais si on veut qu'il contrôle tous les blocs d'un repo de 500 Go ça peut être très long, surtout s'ils sont chiffrés).

J'utilise une autre solution : btrfs en raid 1 pour les données source et le dépôt des archives (j'aurais bien choisi plutôt zfs mais ce n'est pas out of the box sur linux et je n'ai pas voulu me compliquer la vie). Le raid 1, ce n'est pas pour la disponibilité mais pour la correction automatique des éventuelles erreurs (capacité de btrfs et zfs, chose qu'un raid 1 logiciel classique ne peut pas faire).

Dans le même genre il y a borg, restic ou bup (qui lui a des front-end, kup par exemple).

La déduplication est souvent vue comme le moyen de se passer de sauvegardes incrémentales (chaque sauvegarde est vue comme complète) mais ce n'est pas là qu'elle se distingue le plus. En effet, une sauvegarde type BackinTime avec des hard links fait la même chose (à la maille fichier). Pour moi, l'apport qui distingue la dé-duplication type restic/borg/bup est qu'elle s'effectue à la maille bloc de données dans les fichiers =>

1) Tagger une photo n'induit pas de doubler l'espace pris par deux versions de la photo alors que seuls quelques ko ont été modifiés (assez efficace avec borg ou bup, beaucoup moins avec restic qui ne permet pas de paramétrer la taille des blocs).

2) Déplacer, renommer des arborescences ou des fichiers (même par milliers) n'a aucun impact sur la taille totale des sauvegardes (quel confort !).

NB. Comme toute sauvegarde de type déduplication à la maille fichier (basée sur rsync et des hardlinks)) ou de type déduplication "bloc", il faut impérativement un double ailleurs (dans le cloud par exemple) car un même bloc de données peut être partagé entre toutes les versions d'un fichier ou plusieurs fichiers). Si le secteur supportant ce bloc devient corrompu on a perdu le fichier.

Je n'utilise pas Mint mais je l'ai déjà installé "pour voir". btrfs n'y est pas proposé par défaut et encore moins "imposé".

Si néanmoins on veut quand même btrfs (il y a plein de raisons valables pour ça), on peut alors utiliser Timeshift en mode btrfs pour avoir la gestion de points de restauration système (/, pas /home) via des snapshots et la maj de grub en conséquence. C'est quand même plus simple et autrement plus rapide que passer par la restauration d'une sauvegarde du système ou sa réinstallation.

Pour les sauvegardes elles-mêmes, Timeshift me paraît assez limité (même si sa fondation est solide : rsync) mais je ne vois pas en quoi il te verrouille sur Mint. Ensuite, libre à toi de mettre en avant déja-dup (un peu lourdement quand même) mais il y a plein d'autres solutions, parfois plus performantes. Ce n'est juste pas le sujet ici.

J'ai dit que ce n'était pas un outil de sauvegarde en mode btrfs.

"ce" est le sujet de ce fil : Timeshift. Or Timeshift ne propose pas d'envoi/réception de snapshot. Timeshift en mode btrfs est clairement un outil pour restaurer le système à un état antérieur. Il propose accessoirement (et pas par défaut) d'embarquer @/home dans le snapshot.

J'utilise Backintime (également basé sur rsync) sur le PC de ma compagne. Il s'active toutes les heures et c'est transparent. Mais comme la performance à la base est celle de rsync lui-même je vois deux raisons possibles à tes mauvaises perfs :

• le fait que tes sauvegardes s'effectuent sur le même disque (qui doit donc faire à la fois des lectures et des écritures)
• un paramétrage "maladroit" de rsync par Timeshift (par exemple l'option -c qui peut être pénalisante en cpu)

Ceci dit, une sauvegarde sur le même disque c'est pas une sauvegarde, c'est juste la possibilité de revenir en arrière dans le temps. Une sauvegarde c'est aussi la possibilité de remédier à un problème disque (inéluctable tôt ou tard).

Il y a deux fonctions assez différentes dans Timeshift :
- un outil basé sur rsync
- un outil basé sur btrfs

Dans le premier cas (rsync), c'est un outil de sauvegarde type "hardlink" tel que Back-in-Time (il faut bien sûr choisir un autre disque que la source). J'ignore ce qu'il vaut dans ce rôle mais il est basé sur rsync donc ça devrait être efficace.

Dans le deuxième cas (btrfs), ce n'est pas un outil de sauvegarde. C'est un outil de retour en arrière, un peu comme les points de restauration de Windows. En effet, la photo (i.e. snapshot) ne peut s'effectuer que sur la partition source. Par défaut, Timeshift exclut le sous-volume @/home ; il ne prend que @/. De plus, il met à jour le grub quand on veut restaurer une ancienne photo de @/.

Pour moi, mettre ces deux fonctions dans le même logiciel n'a pas de sens.