raphj a écrit 1687 commentaires

Qu'est-ce qu'il y avait de mal à avoir un soft qui règle un et un seul problème, par rapport à un systemd tentaculaire qui va finir par devenir un OS à lui tout seul ?

Lennart le redit dans sa présentation : leur objectif est de fournir une solution pour démarrer un OS. Et pour faire ça bien, en fait on touche plein de choses.

Mais en réalité systemd c'est très modulaire. On pourrait se dire qu'on n'a pas besoin de networkd, nspawn, resolved… et c'est vrai, et ça tombe bien, ces composants sont optionnels.

Par exemple pour ton histoire de configuration réseau : aucune obligation d'utiliser NetworkManager si tu n'en veux pas, c'est normalement possible de faire comme avant.

Mais systemd, c'est aussi une standardisation, un ensemble plus cohérent et unifié. Ça change forcément l'existant, mais ça simplifie grandement la vie des gens flemmards comme moi. Tu installes un nouveau service, tu sais direct comment t'en servir, et notamment que tu peux avoir ses logs en lançant journalctl -fu service par exemple. grep, tail, tout ça, tu peux continuer à les utiliser en apprenant une commande : journalctl -u service; c'est pas la mort. En général il y a un flag pour faire ça mieux direct dans l'outil, mais c'est toujours possible.

Cette standardisation, ça demande effectivement un apprentissage initial, mais sur le long terme, c'est moins la pagaille, l'ensemble est plus facile à comprendre et au final c'est moins d'effort.

Après, c'est clair que si tu n'aimes pas la vision, ça va mal se passer pour toi. Je ne crois pas qu'il faut rester sur l'impression laissée par une mauvaise expérience de migration au début, et plutôt analyser ce qu'on a aujourd'hui, sinon c'est sûr que tu resteras bloqué sur ça mais ça ne parait pas méga constructif.

C'était une bonne présentation. C'était aussi cool de voir Lennart en vrai, ça met un visage et un aperçu sur un des personnages dont on entend régulièrement parler.

L'article sur LWN est un bon résumé, reprenant tous les points clés. Il y a aussi eu un passage intéressant sur « Est-ce que systemd respecte la philosophie Unix », qui n'est pas cité dans l'article mais qui vaut le coup. C'est un peu résumé sur le site de systemd (point 10: « Myth: systemd is not UNIX. »). (D'ailleurs, cette page montre à quel point les détracteurs de systemd sont souvent à côté de la plaque dans leurs arguments, il y a une réponse claire à la plupart des critiques qu'on peut lire).

L'impression que ça m'a donné, c'est que l'équipe qui maintient systemd a une vision forte sur comment faire les choses, et que des efforts sont faits pour garder un ensemble propre, cohérent et un bon équilibre entre légèreté, sécurité et fonctionnalités. Par exemple, ils réduisent au maximum le nombre de leur dépendances fortes, et utilisent dlopen pour les fonctionnalités plus optionnelles. C'est plutôt rafraîchissant de voir ce genre de démarche dans un monde où on s'en fout de rajouter 2000 dépendances transitive et où on bundle le tout pour le balancer au navigateur sans se préoccuper de la situation matérielle des destinataires.

J'aime bien aussi leur ambition de standardiser les manières de faire / un certain nombre de choses sur les systèmes GNU/Linux (l'article en parle).

Bref : systemd, j'aime la démarche, et le résultat.

Oui, et avec un peu de chance, le richesse va un peu ruisseler sur nous :-)

S'asseoir sur la Constitution

Malheureusement, une partie des problèmes est que la Constitution contient des backdoors démocratiques et que ces backdoors sont empruntées…

Disons que les deux affirmations ne sont pas mutuellement exclusives :-)

L'actualité sur le site du service public : https://entreprendre.service-public.fr/actualites/A15683

La facture électronique, en soit je trouve ça pas mal. Aujourd'hui j'édite manuellement les quelques rares factures que j'émets en espérant que je respecte bien les obligations. On peut espérer de plus fortes garanties là dessus avec un service dédié. On peut aussi espérer des garanties de conservations, et même peut-être des déclarations directes à l'URSSAF : une étape de moins (bon, ça, je ne pense pas que ça arrivera cela dit).

Par contre, l'obligation de passer par un prestataire privé, c'est quand même un problème :

Les factures électroniques transiteront sur une plateforme utilisée par l'émetteur et le destinataire de la facture. Celle-ci sera nécessairement une plateforme de dématérialisation partenaire (PDP) accréditée par l'administration fiscale. Le portail public de facturation n'étant finalement pas mis en place.

Au lieu de se tuer à mettre en place des processus pour auditer et accréditer des boites privées qui ne devraient avoir rien avoir avec l'activité d'une autre boite, je préférerais que le service public mette en place une plateforme pour ça, avec des API solides si besoin. Libre ensuite à des boites privées pour fournir des services autour, et libre aux entreprises de les utiliser ou non.

Là, on va avoir le droit à une usine à gaz qui coûte plus cher (il n'y a pas de mystère, on va forcément payer le temps de travail nécessaire à mettre en place une plateforme de facturation électronique), impliquant des intermédiaires indésirables.

C'est comme pour les bulletins de salaires électroniques, c'est naze de devoir passer par des "coffres forts" privés. C'est comme France Connect +.

Le service public doit se donner les moyens de fournir les outils nécessaires pour respecter. Mais bon, cette logique libérale n'est pas étonnante. On a, collectivement, voté pour.

Oui, c'est vrai. J'avais un couteau de cuisine en tête, le premier que tu affiches est clairement une arme. Un couteau de cuisine bien aiguisé peut servir d'arme mais n'est pas particulièrement orienté vers cette utilisation. Mais je suis d'accord avec toi, on peut toujours trouver une manière de montrer qu'un outil n'est pas neutre. Je suis même près à penser qu'aucun outil n'est absolument neutre, au moins parce qu'il biaise vers au moins une utilisation en particulier, et cette utilisation peut elle-même être discutable (et c'est vrai pour le couteau de cuisine : s'il est optimisé pour couper de la viande par exemple, on peut déjà trouver à discuter). Disons que sans arriver à la neutralité, une arme ou un LLM me paraissent plus sujets à controverses qu'un couteau de cuisine, qu'on absolument toutes et tous chez soi sans que le principe soit trop remis en question. J'ai plutôt du mal à trouver des problématiques éthiques liées au couteau de cuisine à soulever.

il fallait pas blâmer

Ah non, je n'ai pas cette lecture. La guerre en Ukraine est bien une matérialisation de plus du comportement de la Russie, mais ce n'est pas pour ça qu'elle n'est pas critiquable en tant que telle. Mais si tu veux raisonner sur cette guerre voire te battre contre, fatalement, tu vas devoir te pencher sur le comportement de la Russie. Mais il n'est vraiment pas question de s'interdire de s'émouvoir de la guerre elle-même.

Pareil pour l'IA : il faut être clair dans les idées et voir que des choses se généralisent, mais ça n'empêche pas de voir des aspects de l'IA d'un mauvais œil.

Après tout, c'est bien les manifestations spécifiques des travers du cadre plus large qu'on n'aime pas, sinon il n'y aurait pas vraiment de problème.

Oui, et ces ROM sont dispo pour une variété limitée de téléphone, en tout cas pas pour plus d'appareils que https://lineage.microg.org/ à première vue.

Parce qu'en vrai, quand on a Lineage for microG, c'est relativement simple, il n'y a plus grand chose à faire de mémoire. C'est quand il n'y a pas de build de Lineage for microG que c'est la merde.

Je vois que certaines ROM proposent une installation via WebUSB, j'imagine que ça facilite encore plus, je n'ai jamais essayé. Il y a de grande chance pour que je m'en tienne à l'installation en ligne de commande cela dit, je suis très à l'aise et c'est simple dans ma tête, et ça ne dépend pas de Chromium.

Ah yes, exact, merci pour l'info !

C'est une excellente nouvelle s'il y a le signature spoofing dans Lineage directement maintenant. Lineage s'y opposait si je me souviens bien. Le changement semble dater d'il y a un an, on sait qu'est-ce qui les a fait changer d'avis ? Une petite recherche m'a mené vers les commits en questions dans le système de review, sans plus.

Bon, il se trouve que je n'ai jamais manipulé des versions récentes de Lineage. Du coup, en général, je vise https://lineage.microg.org/, et si je ne trouve pas le build, alors je prends un Lineage et j'utilise https://gitlab.com/Nanolx/NanoDroid

J'ai récemment installé Lineage sur le vieux Fairphone 2 d'une personne curieuse qui n'y connaissait rien (mais qui avait commencé à regardé les instructions d'installation de Lineage), et bah expliquer ce qu'est :

• adb
• fastboot
• une rom
• LineageOS
• microG
• twrp
• Magisk
• NanoDroid (et ses différents modules)

… et pourquoi on a besoin de chacun de ces trucs, ce n'était pas évident. Et c'était encore moins évident de trouver comment faire quand on n'a plus le build Lineage de microG (ce qui est le cas quand Lineage ne prend plus en charge le modèle, ce qui est dommage parce que certaines personnes se disent qu'une mise à jour et/ou se débarrasser de Google après que ça arrivent mais ne veulent malgré tout pas changer de téléphone, au moins pour des raisons écologiques - on se retrouve à ne plus trouver de build de releases de lineage, on trouve un build nightly qu'on espère assez stable sur un serveur d'archives maintenu par une seule personne qui affirme que les builds ont été récupérés à droite à gauche sans trop de vérification, c'est un peu bizarre pour un téléphone si répandu. Je compilerais bien Android et je l'ai déjà fait, mais faut avoir le temps, l'espace disque, la ram, savoir quoi intégrer et comment (dont le signature spoofing et microG), et être un peu sûr que ça va marcher…)

On a l'impression de devoir empiler des briques mal documentées et plus ou moins stables trouvées à droite à gauche parfois par hasard et sur lesquelles on espère pouvoir faire confiance. On sert un peu les fesses pour que ça marche suffisamment bien quand-même et que ça ne soit pas vérolé…

Si déjà on peut, à l'avenir, ne pas avoir besoin de NanoDroid ni de Magisk, et pouvoir installer microG (et f-droid) purement avec des applications standard sur un Lineage standard, ce serait quand-même plus simple et plus rassurant.

Le monde d'Android, c'est quand même spécial.

Le truc qui est peut-être plus compliqué à faire c'est avec les changements climatiques, on va avoir des changements de régimes météo qui feront que les patterns appris par le passé vont être moins important, ou plus importants, et que c'est pas tellement visible dans les données passées parce que c'était rare ou il va y avoir de l'inédit

Oui, j'ai eu cette inquiétude.

Mais finalement là on se retrouve avec le fait que le terme "IA" recouvre tellement de choses que … plus ça va avancer plus il va falloir préciser de quoi on parle.

Exact !

c'est au nom de l'IA et des ruptures promises futures qu'on produit des centrales nucléaires

C'est vrai, et en même temps je pense que ce n'est qu'un symptôme du système tel qu'il est.

Du coup, peut-être qu'on peut dire un truc comme : il ne faut pas oublier de généraliser, et il faut éviter d'attribuer à l'IA les maux qui viennent en fait du cadre plus large, mais ça vaut probablement le coup de (et ça ne veut pas dire qu'on ne devrait pas) s'attarder sur les manifestations spécifiques liées à l'IA, qui peuvent même aider à identifier les problèmes (structurels) du cadre.

Et, allez, une touche de positif tout de même : bien que ça me laisse un peu circonspect, il semblerait que pour certaines applications comme prédire la météo, on puisse faire beaucoup plus efficace énergétiquement avec des meilleurs résultats que ce qu'on a aujourd'hui. Donc il faut aussi prendre en compte ce genre de choses si ça s'avère vrai.

Dans tous les cas, je ne suis pas sûr d'être pour une interdiction formelle (mais pas sûr d'être contre non plus, bref, je ne suis pas fixé). Cela étant dit :

Si on parle d'un contenu entièrement généré par l'IA, plutôt non : c'est chiant à lire et je n'ai pas besoin que LinuxFr agisse comme un proxy entre une IA et moi. Tout comme je ne voudrais pas d'un copier coller d'une page de résultats d'un moteur de recherche. Je pourrais moi-même aller demander un truc à une IA si par le plus grand des hasards j'en avais envie. Mais bon, je n'ai encore jamais interrogé volontairement un LLM. Pour le moment, je ne fait pas confiance aux LLM pour m'apprendre des choses. Si de tels contenus devaient exister, il serait souhaitable de les marquer clairement comme tel, et faciliter le filtrage. Ça pourrait être un tag + une fonctionnalité du site pour cacher des tags.

Si on parle d'un contenu écrit avec l'assistance d'une IA, c'est probablement différent.

• hors question éthiques : si l'auteur ou l'autrice fait gaffe, ça peut rester intéressant à lire.
• avec questions éthiques : aujourd'hui, on ne vérifie pas que les gens qui écrivent le font avec des outils éthiques. Qui nous dit que tartampion n'a pas écrit le brouillon de son journal à la plume trempée dans le sang d'une de ses victimes ? Ou via macOS ou Windows ? N'autoriser que les IA libres ne me semblerait pas cohérent avec les pratiques existantes.

S'il peut-être souhaitable d'encourager les gens à ne pas utiliser des outils qui ont une éthique douteuse, je ne suis pas sûr qu'on devrait interdire quoi que ce soit, d'autant que chacun·e a sa vision personnelle de l'éthique. Ce n'est même pas efficace au niveau sensibilisation, voire c'est contre-productif.

Sur la question des droits d'auteurs : on pourrait décider par principe que les modèles entrainés sur des textes sans l'accord de leurs auteurs et de leurs autrices génèrent nécessairement du plagiat, et qu'on ne veut pas de ça sur LinuxFr, mais je ne suis pas sûr qu'on veuille faire plus de zèle que la loi.

Il y a un peu de ça, mais je ne suis pas entièrement convaincu.

• Ni par ce résumé : j'ai l'impression qu'il perd pas mal le cœur du message.
• Ni par le parallèle :
  • Comment représente-t-on le système politique / économique ? Le cuisinier et l'assassin sont des utilisateurs dont on accepte ou rejette les agissements, mais ça ne représente pas une grosse partie des inquiétudes qui ne sont pas liées aux les bonnes et mauvaises utilisations des IA
  • Si le couteau me parait plutôt neutre comme outil, je ne suis pas sûr qu'on peut dire la même chose des implémentations actuelles de l'IA. Et je ne pense pas que les discussions autour de l'écologie et de l'IA, ni autour des droits d'auteurs, ni des résultats incorrects ou biaisés (entre autres inquiétudes), se transposent bien à la production et l'utilisation du couteau. Je ne sais pas s'il y a des enjeux économiques, politiques, sociaux et environnementaux comparables.

En résumé, les LLM, qui sont des outils, n'ont malgré tout pas grand chose avoir avec de simples couteaux.

On peut installer microG facilement depuis les dépôts

Comment ça marche ? Il n'y a plus besoin de flasher des trucs depuis Magisk ou un de ses copains ? Il suffit d'installer des APK et ça marche ? Est-ce vrai pour les vieilles versions d'Android également ?

Ma réaction initiale au titre a été « Comment ça ? Je ne comprends pas la question, pouvez répéter ? » xD

Pour finir par tomber d'accord avec l'article. Ce que j'en retiens : beaucoup de maux qu'on réserve à l'IA ne sont en fait pas spécifiques à l'IA.

Ça fait bien longtemps qu'on casse plein de choses et on n'a pas attendu l'IA pour ça. J'étais tombé sur cette conclusion dans ce commentaire (2ème point à la toute fin - le commentaire est long), c'est cool de voir que je ne suis pas seul.

C'est parce que l'IA, comme les autres outils, y compris ceux qui l'ont précédée, existent dans un système politique et économique qui fonctionne comme ça. Si on n'aime pas les effet qu'ils ont, ça me parait vain de combattre une de ses manifestations en isolation, il faut à mon avis être plus général et attaquer le problème à la racine.

Après, si la manifestation spécifique mais visible qu'est IA permet à certain·e·s de prendre conscience de certaines choses, ou que ça agit comme la goûte d'eau qui fait déborder le vase, pourquoi pas après tout. Il ne faut juste pas se méprendre, et bien identifier les bonnes cibles.

Et l'IA, c'est large, flou, et ça une définition glissante, autant spécifier. Par exemple, est-ce que toutes les critiques qu'on adresse contre l'IA s'appliquent à GNU Chess, qui est une IA ? Non. Elles s'adressent surtout aux IA génératives, et très souvent aux LLM. En tout cas, en ce moment et depuis peut-être 2-3 ans.

Soyons spécifiques, ou généraux, selon ce qu'on affirme :-)

Je préfère aussi systemd. C'est la forme la plus répandue, celle que préfère les gens du projet concerné. « SystemD » saute aux yeux et donne l'impression d'être une erreur, et que c'est juste écrit par quelqu'un qui ne fait pas trop gaffe à l'orthographe / la typographie (ce qui n'est pas un problème, il y a vraiment des choses plus importante dans la vie).

J'étais loin de m'imaginer que ça pouvait être justement volontaire.

C'est probablement juste une question d'habitude, c'est vrai que je crois me souvenir que ça m'avait un peu titillé au début.

je préfère que la version en ligne soit écrite avec la forme préférée du lectorat de LinuxFr

C'est bien urbain :-)

Je suppose qu'une manière serait de trouver la liste d'IP qu'ils utilisent, espérer que ça ne bouge pas trop ou trouver une manière la maintenir à jour, et coller ça dans le fichier hosts.

Cela dit, bon courage, ils sont vraiment omniprésent.

On pourrait avoir un fichier Markdown, tout comme ce que tu as, mais qui, au lieu d'appeler des binaires, appelle des méthodes et des fonctions et teste leurs résultats. Directement lisible en tant que doc.

Mais pour que ça marche, il faut un moyen d'appeler les tests depuis le système de tests (unitaires) du projet, en fonction du langage utilisé. Faut que le "test runner" trouve les tests dans les fichiers markdown. Pour ça, il faut probablement générer des fichiers de tests habituellement écrits à la main, ou être embarquable en tant que bibliothèque appelée par le "test runner".

Bon après, peut-être que ça a beaucoup de sens d'avoir un système comme celui que tu proposes pour appeler des binaires parce que la documentation est celle à destination des utilisateurs finaux / utilisatrices finales, mais que ça n'a pas tant d'intérêt que ça pour des tests unitaires et de la doc pour les devs, qui peut se permettre d'être plus technique, avec plus facilement du code mis en avant.

D'un autre côté, qui n'a jamais cherché comment on utilise un code pas suffisamment documenté en regardant ses tests unitaires, quand une doc lisible aurait été plus appréciable ? Naïvement, un bbt pour les tests unitaires pourrait sembler intéressant. Ça pourrait permettre d'ajouter une rubrique d'exemples d'utilisation pour chaque fonction à cette page par exemple, avec le résultat attendu. Pour certain projets, l'utilisateur final est un·e dev, par exemple pour les frameworks. Peut-être que ça devrait être un outil complémentaire à part, ça résout probablement un problème plus ou moins différent et demande une manière de faire différente.

En tout cas merci pour tes réponses, bien cool ta doc comparables.md!

La doc exécutable, je trouve ça très malin. Ça peut encourager à écrire de la doc quand on écrit des tests, et vice versa. D'une pierre deux coups, on améliore la qualité et la maintenabilité d'un logiciel. Avec une garantie que la doc est correcte et à jour, voire complète si on vérifie la couverture du code. Et des tests lisibles, compréhensibles et qui ont du sens. Ça me donne envie de m'y mettre.

Ça fait beaucoup penser à l'outil unix expect, qui peut lancer des programmes, écrire dans l'entrée standard, tester la sortie… C'est très complet, et de façon amusante, dans le basique de chez basique, ça ressemble un peu à la grammaire de ton outil : les commandes commencent par un verbe en anglais.

Par contre, ce n'est pas du tout orienté doc ; tu écrits un script expect quoi.

Du coup, en partant de la supposition qu'il y aura fatalement des cas demander une telle complexité, ton outil propose-t-il des fonctionnalités du même genre qu'expect, ou est-ce prévu ?

J'ai l'impression que quelqu'un pourrait implémenter ton idée en faisant un préprocesseur pour expect, qui mange du markdown ou autre en ne gardant que les lignes à destination de l'outil, et qui sort des scripts expect. Est-ce une piste que tu avais envisagé ?

Y a-t-il des plans pour sortir du modèle "appeler un binaire" et permettre l'exécution des tests dans un code de test ? Ça donne envie de pouvoir documenter et tester des appels de fonctions / méthodes comme ça, où les exemples dans la doc seraient en fait des cas de tests. (Pour le coup, j'ai la vague impression qu'une implémentation en mode préprocesseur pour expect serait un poil incompatible) (et je comprends bien que ça sort probablement très largement du scope de ton implémentation et qu'un outil pour faire une chose bien, c'est pas mal aussi)

Je suppose que ça demanderait de fournir une bibliothèque et des bindings dans chaque langage de programmation, où le fonctionnement actuel serait juste l'utilisation du binding pour le shell unix.

En tout cas merci pour l'idée et le partage, et l'outil en libre. Que je me mette à utiliser ton implémentation ou non, c'est inspirant.

Je suis curieux de pourquoi ce n’est transparent que pour moi.

C'est peut-être juste moi aussi, ce n'est pas exclus xD

Mhm, oui. J'ai eu tant de mal à suivre ces deux journaux que j'ai abandonné.

J'ai essayé de comprendre pourquoi sur ce journal, et je pense que :

• ça manque de structure (avec des sections qui ont des titres, un plan)
• ça manque de ligne directrice (d'où on part et vers où on souhaite amener les lecteurs et les lectrices)
• ça manque de définitions avant usage des termes
• le texte a été frappé par la malédiction de la connaissance
• la manière de progresser ne me correspond pas. Un symptôme de cette manière de progresser est la présence de motifs du style "[A]. Pourquoi ? [B]". En réalité, B est arrivé avant A, du coup si on veut partir du début et arriver à la fin, potentiellement B devrait être présenté avant A. De fait, ça peut totalement inverser le sens du texte. Autrement dit, pour saisir qu'il y a un problème à résoudre, on devrait déjà être mis au courant de B, et ensuite A devient une implication présentée après. Évidemment, un texte très bien rédigé pourra transgresser cette règle çà et là pour un peu de dynamisme et ne pas faire mourir les gens d'ennui.

Je note une motivation présentée au début, ça aide bien. Mais je n'ai pas le contexte pour la comprendre : le terme "Séquences" en majuscule est utilisé mais je ne sais pas à quoi ça fait référence.

Ce journal propose par exemple de renommer un concept qui n'est alors pas encore présenté. Donc on sent qu'il y a un problème et qu'on essaie de lui couper l'herbe sur le pied (on n'a pas encore le problème dans le monde francophone), mais on ne comprend pas les tenants et les aboutissants. On comprend que le terme initial n'est pas approprié du point de vue de certaines personne, mais on ne saisit pas pourquoi.

Une manière qui marche bien pour s'adresser à moi avec un long texte :

• présenter clairement un problème qu'il faut résoudre et proposer une solution
  • décrire le problème à l'aide de concepts définis au préalable
  • décrire une solution à l'aide de concepts définis au préalable
• Si on propose un changement, faire un état des lieux bien défini, présenter les problèmes de l'existant, et introduire la proposition.

Et après, ce qu'on voit en philosophie ou en littérature au lycée marche plutôt bien :
- intro
- un poil de contexte, avec une motivation
- présenter le sujet / l'objet / le problème de façon concise
- définir les termes du sujet
- on peut sauter la présentation verbeuse textuel du plan et la remplacer par des liens ficelés entre les parties
- parties et sous partie qu'on titre et qu'on lie entre elles (ouais, contrairement à certaines consignes de ne surtout pas mettre des titres explicites aux sections mais d'en faire des premières phrases de paragraphe, on pourra présenter un plan clair)
- conclusion

D'autres schémas marchent probablement bien, l'important soit qu'en tant qu'ignorant total du sujet, je sache à tout moment d'où on part et où on va, que je comprenne les termes centraux utilisés (et donc qu'ils soient définis avant leur utilisation, ou juste à côté), et pourquoi je devrais continuer à lire. Surtout au début.

Le contexte étant que j'ai une lecture relativement lente et pénible, et une concentration du st… oh un oiseau ! D'ailleurs le précédent journal joue un peu avec ça volontairement xD. Et j'ai une mémoire de travail très courte. Donc je suis vite perdu en lisant un truc. D'ailleurs, pour cette raison, un max de concision est très appréciée.

Le sujet partait avec un avantage : les biais cognitifs, ça m'intéresse, des bons raisonnements, ça m'intéresse, je veux en savoir plus :-)

Un bon exemple de sujet compliqué et un peu long qui est bien passé hier malgré la fatigue complète dans laquelle j'étais à cause de FOSDEM et du boulot intense ces derniers mois : https://www.ralfj.de/blog/2020/12/14/provenance.html

Voilà, j'espère que ce commentaire trouvera son utilité, il est là pour suggérer plus que pour donner des leçons, j'espère d'ailleurs qu'il sera perçu comme tel. Je présente bien mon rapport personnel avec les textes, on sait très bien qu'un même style d'écriture accroche très bien une personne et très mal une autre, et que chacun·e a le sien. Je pense que je suis très scolaire, de ce point de vu.

(bien sûr, je trouvais les règles des dissertations au lycée très pénibles et rigides, mais je vois maintenant très bien pourquoi elles existent)

Ah, belle variante du Darwin Award xD

Trouver le variateur qui contrôle la luminosité du soleil et le baisser d'un petit poil.

Il n'existe pas des alternative libres à Authy? Ça fait plus que juste générer des codes MFA, elle est obligatoire pour certains services ?

(Pour Revolut je suppose que ça va être plus dur…)

Sinon, il y a peut-être des contournement à SafetyNet notamment avec microG ?

pour dire "je n'aime pas les messages vocaux". Je suis plutôt d'accord, mais ça ne vaut pas trop le coup de cliquer, c'est la seul info xD