mahikeulbody a écrit 2018 commentaires

Avec les styles par défaut, je viens d'insérer un tableau puis j'ai écris une ligne en dessous : elle est juste en dessous, il n'y a pas de ligne insérée.

Peut-être que chez toi le style "tableau" spécifie un saut de ligne après le tableau. Je crois que c'est dans l'onglet 'enchaînement' quand tu édites le style.

Bon, peut-être que je n'ai pas compris ton problème.

J'ai souvent lu que la technologie AMOLED, de plus en plus courante sur les écrans d'ordiphone, fait qu'un pixel noir ne consomme rien. Du coup, le thème sombre augmenterait l'autonomie (ce qui n'est pas forcément une bonne raison pour s’abîmer la vue, j'en conviens).

facile à dérober.

Mais très difficile à "ouvrir" s'il a été verrouillé. Plus que le PC à la maison (qui lui, en revanche, est moins facile à dérober).

Les gens choisissant un système autre qu'AOSP/android le choisissent pour virer les applis, celles des gafam en tête de liste.

Ça m'étonnerait que ce soit la raison vu que rien ne t'oblige à utiliser les applis GAFAM tout en restant sur Android/AOSP. Quant à virer toutes les applis quelles qu'elles soient, je ne comprends pas vu que tu ne réponds jamais à la question : qu'entends-tu par appli ?
Il y a aussi des applis sur Linux ou postmarketOS, non ? Tout comme il y a des applis libres sur Android/AOSP.

Bon courage pour "forker" une variante sur un AOSP devenu propriétaire, source fermée.

L'idée du fork est de le faire sur la dernière version libre disponible (ou avant). Que AOSP devienne propriétaire, à source fermée, un jour n'est pas le problème, c'est ça que tu ne sembles pas comprendre.

Le problème ce n'est pas AOSP mais le support du matériel. Et c'est la même chose pour n'importe quelle distribution Linux (pocketmarket OS) dans le monde ARM.

comment voulez vous maintenir une variante d'AOSP si celui ci devient propriétaire? À terme (dix ans max) c'est complètement inévitable.

En le forkant à partir d'une version encore libre.

A mon humble avis, le souci n'est pas là, il est d'avoir accès aux pilotes du matériel (ce qui sur ARM semble plus compliqué que sur x86) et c'est le même problème pour une solution non basée sur AOSP (pocketmarket OS, par exemple).

Si un ou plusieurs fabricants donnent accès à leurs pilotes, la question se posera alors de choisir entre partir du fork de AOSP ou bien d'une distribution Linux "classique". Les deux ont leurs avantages et inconvénients.

Quelle certitude a un utilisateur de Linux qu'aucune de ses applis n'a de faille qui donne une porte d'entrée à une entité malveillante ?

Et avec un Linux basé sur flatpak comme certaines distributions récentes ?

Je préfère mille fois quelqu'un qui apprécie le smartphone et qui est en accord avec ses convictions en utilisant un service dispo uniquement sur appli,

Il faudrait que tu définisses ce que tu appelles "applis", visiblement ça ne correspond pas à l'usage courant et ça entraîne des malentendus.

J'ai l'impression que "appli" pour toi, c'est quand il y a service avec un compte qu'on doit créer. Sauf qu'il n'y a pas que ce type d'applis.

Pour moi, Syncthing, Jami, Aegis, Aves, cartes IGN, CoMaps, KeepassDX, Thunderbird, Home Assistant,pour n'en citer que quelque unes, sont aussi des applis et je les utilise sur mon Android.

Est-ce qu'il existe beaucoup de gens en France qui n'ont pas leur adresse, leur nom, leur âge, leur numéro de téléphone, probablement leur RIB et leur numéro de sécu, qui ne se baladent pas déjà quelque part?

Probablement très peu (y compris tkr malgré sa rigueur sur le sujet).

Ça me gonfle que des GAFAM aspirent mes données pour du ciblage publicitaire (publicités que je bloque de toutes façons) ou bien pour alimenter leurs IA, en échange d'un service : à moins de décider si ça en vaut la peine ou le risque. Mais ça me gonfle encore plus que mes données fuitent aux mains de hackers pas bien intentionnés parce les entités qui les détiennent demandent des infos non nécessaires, les conservent plus que de raison et ne font aucun effort sérieux pour en assurer la sécurité.

et de l'autre, "la base de donnée était accessible par tout le monde".

ou bien "la base de données stockait des données non nécessaires au service".

ce sera mort pour les androidisés, mais les trois pelés auront survécu à l'invasion d'android. À méditer.

J'ai médité autant que j'ai pu et le résultat est toujours le même : si ta prophétie se réalise en 2040, les androidisés auront utilisé un système viable pendant une décennie ou plus et se résoudront alors à devenir des pelés si des alternatives libres de Google, éventuellement basées sur un fork de AOSP, ne sont pas apparues d'ici-là. Ils auront survécu tout autant à l'invasion d'Android que les trois pelés, non ?

Pour le dire autrement, je ne vois pas l'avantage qu'il y aurait aujourd'hui à se contraindre à utiliser pocketmarketOS avec tout ce que ça entraîne, en l'état, comme sous-utilisation d'un ordiphone. Que toi tu n'aies pas besoin de ces usages n'implique pas d'en faire une généralité valable pour tout le monde.

En revanche, il y a bien un motif pour utiliser sans attendre 2040 des alternatives fonctionnelles basées sur AOSP : une meilleure préservation de sa vie privée.

Ca dépend peut-être de si tu l'as utilisé quand il était basé sur duplicity ou bien plus récemment sur restic. Sinon, backrest fonctionne correctement avec restic.

Du coup, c'est une alternative à backrest qui est aussi une UI utilisant restic ?

Ah ok, c'est nouveau.

Deja Dup est désormais basé sur restic (les anciennes versions étaient basées sur duplicity).

Sur la page fournie en lien je ne vois aucune mention de restic.

(du coup, moinser le commentaire de Rodier n'est pas très pertinent)

Le second point est crucial. Avec Borg, si je perds le dossier ~/.config/borg/keys, je perds mon backup.

Non, tu as le choix entre deux modes :

• repokey (mode par défaut) : la clé de chiffrement est stockée directement à l'intérieur du dépôt
• keyfile : la clé est stockée uniquement (~/.config/borg/keys)

Basé sur rsync, il y a backintime qui est très bien. Comme tout ce qui est basé sur rsync, ça fait de la déduplication mais à la maille fichier et ça ne sait pas reconnaître un fichier renommé ou déplacé même s'il n'a pas été modifiée depuis la dernière sauvegarde (=> il va le re-sauvegarder ; ça n'est pas un problème en soi mais ça augmente la taille de la sauvegarde).

Pour de la déduplication à la maille bloc (donc sans re-sauvegarde inutile des fichiers renommés ou déplacés mais non modifiés), il y a surtout borg et restic (et aussi kopia mais qui est plus "jeune").

borg et restic sont des outils en ligne de commande. borg dans sa version actuelle ne sait pas gérer des sauvegardes sur des clouds (s3, …), c'est prévu en v2. restic sait gérer aussi des clouds.

borg a une UI : Vorta. restic a une UI : backrest.

La doc parle effectivement de Mariadb comme possible MySQL remote server mais ne précise pas ce qui est utilisé pour le MySQL internal server fournit par Digikam. Il est probable cependant que ce soit Mariadb.

Quoiqu’il en soit, l'interface de Digikam n'affiche que SQLite ou MySQL, pas Mariadb (y compris dans leur outil de migration), ce qui m'a induit en erreur, d'autant que j'utilise seulement SQLite.

On peut difficilement accuser KDE et Digikam d'être une entreprise "commerciale" et pourtant Digikam propose toujours MySQL (ainsi que SQLite pour les collections de moins de 100K photos). J'imagine qu'il y a d'autres raisons : les ressources disponibles dans le projet pour faire un outil de migration, par exemple.

Ma banque me prévient par mail au moins 48h (ou plus ?) avant un prélèvement quand c'est le premier d'un mandat. On a donc en principe le temps de le bloquer avant. Par ailleurs on a plusieurs mois pour demander l'annulation d'un prélèvement déjà fait.

C'est une fuite ennuyeuse, certes, mais pas forcément aussi catastrophique que c'est présenté. Après, je ne sais pas comment ça se passe dans les autres banques.

Grammalecte le dit lui-même : « Après “après que”, le verbe ne devrait pas être au subjonctif mais à l’indicatif. » ;-)

Du coup, il aurait fallu écrire quoi, ici ?

et que si AOSP n'est plus libre (ce qui arrivera forcément), comment sailfish restera installable sur ces appareils..

AOSP restera toujours libre, sous un autre nom s'il y a un fork. Ceci dit, je t'accorde que je suis moi aussi sceptique sur la capacité d'une équipe à reprendre ce code et en faire une distribution Android fonctionnelle.

Téléphoner au service client si tu es à l'étranger et que celui-ci ne t'identifie pas via un n° appelant connu, ça risque d'être coton (sauf peut-être pour bloquer la carte), sans parler des frais téléphoniques.

En ce qui concerne ma banque (qui n'impose pas l'appli), elle impose une contrainte que je trouve agaçante mais qui au final est quand même une sécurité : l'ajout d'un nouveau bénéficiaire de virement prend 48h avant qu'on puisse lui virer quoique ce soit.

Si on veut garder son ordiphone avec soi (comme la plupart des gens qui en ont un), on est obligé de se promener dans les endroits dangereux avec le dispositif complet pour entrer dans sa banque. Alors qu'avec une clé génératrice de numéros aléatoires, on peut le laisser à la maison,

Je ne suis pas sûr d'avoir compris. Tu es en voyage, tu as donc ton ordiphone sur toi, sans l'application bancaire installée et on ne peut pas te forcer à l'installer car tu ne connais pas le mot de passe du compte par cœur. Premier problème, il faut aussi que je désinstalle Keepass de mon téléphone alors, ce qui va m'embêter ; disons que j'ai une version de keepass "voyage" sans l'entrée "ma banque".

Tu veux quand même pouvoir accéder à ton compte pour être en mesure de bloquer ta carte de crédit si elle est volée ou pour relever un plafond. Tu fais comment ?

Un emploi sous rémunéré sans autorisation de vacances

Comme dit plus haut, tu as droit à 35 jours par an de vacances indemnisées.