mahikeulbody a écrit 2026 commentaires

Vivement Euro-Office ? (le nom est nul)

Oui, vraiment (je me demandais si j'étais seul à penser ça). En plus, c'est contre-productif si on souhaite que ça soit largement utilisé world wide.

Il y a beaucoup de mauvaise foi dans ton commentaire.

En quoi c'est mieux qu'un format issue de MS Office ?

Peut-être parce qu'il ne fait pas 10000 pages et qu'il n'y a pas des blobs non documentés dedans ?

Avant ODT il n'y avait qu'un format propriétaire qui le serait resté sans ODT (OOXML n'existe que parce que MS y a été, de facto, contraint).

Tu appliques un raisonnement récursif douteux : ODT c'est pas bien parce que presque personne ne l'utilise (ce qui est d'ailleurs faux), donc il ne faut pas l'utiliser. Et puis l'interface de LO est nulle (ce qui se discute) mais n'est pas absolument pas un argument quand l'article dont il est question parle de l'avenir.

Pour finir, le titre de ton commentaire est juste ridicule, j'espère que tu t'en rends compte.

PASSED

Les mettre dans un dépôt git les rends lisibles ? Pas lisible au sens où c'est compréhensible facilement mais au sens où on a le texte complet qui s'applique sans un millier de renvois à d'autres textes et des dizaines de "annule et remplace le chapitre xx de yy".

J'imagine par ailleurs que ça doit faciliter l'analyse de savoir ce qui était applicable à une date donnée dans le passé.

Tout est dans le "presque"…

Je n'ai jamais utilisé Strava mais je ne crois pas que ça ait un rapport avec le sujet. Ici, on a affaire à des gens qui partagent consciemment (même s'ils oublient les conséquences possibles) leurs activités sportives sur Strava. C'est ce partage qui donne tout son sens à Strava : cartes de chaleur, comparaison avec la performance des autres, etc… Rien à voir avec des données leakées et des databrokers qui les revendent.

En revanche si les clients qui refusent le smartphone ne représentent que 0,1% de leur clientèle, ils peuvent aussi choisir de fermer leurs comptes sans avoir à justifier pourquoi plutôt que mettre en place une alternative.

Les premières victimes de cette révolution vont être les ESN. Rappelons leur modèle :
* Le client rédige les spécifications du logiciel.
* Il confie le développement à l'ESN, qui active une cohorte de développeurs.

Bon, durant ma carrière (je suis à la retraite depuis une quinzaine d'années) que j'ai effectué dans une ESN (Sema puis Atos), le modèle des projets sur lesquels j'ai travaillé était plutôt :

• le client rédige (ou fait rédiger) un cahier des charges
• il confie la réalisation à une ESN qui
  • active des gens avec profil informatique ET des connaissances du métier du client
  • active des gens pour concevoir l'architecture informatique nécessaire
  • active des gens pour réaliser le projet

Il y a des étapes que je vois mal remplacées par une IA en l'état actuel mais il est évident que l'IA aurait considérablement réduit l'effectif des projets dont je parle.

Je viens moi-même de faire du vibe coding sur une appli Python à usage personnel que j'ai fait il y a une dizaine d'années afin de la moderniser et la rendre éventuellement "publiable" et je dois dire que je suis extrêmement impressionné : découverte de bugs très subtils, génération de la documentation sur la seule base du code avec une "compréhension" profonde du pourquoi du comment, génération de suite de tests, suggestions pertinentes d'amélioration, … Après, je parle d'une appli d'environ 3500 lignes de Python (hors codes de test), rien à voir avec une vraie appli métier réelle.

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.