raphj a écrit 1753 commentaires

pas sympa mais efficace et compétent fin connaisseurs.

Ouais, enfin, le mec alpha incapable socialement qui joue les cowboys ou les loups solitaires et impose sa vision, non merci. Je préfère avoir affaire à des expert·e·s qui savent convaincre par une bonne communication.

C'est plus agréable pour tout le monde, et à long terme, c'est la seule manière d'avoir des projets de qualité qui restent pertinents. Pourquoi ?

• Parce que comme tout le monde, le cowboy vieillit, et comme beaucoup de gens, peut être sujet à la résistance aux changements, rester sur des idées de plus en plus dépassées, surtout s'il n'écoute personne
• Parce qu'il fait fuir des gens de bonne volonté qui peuvent aussi ramener leur expertise, et permettre une expertise variée, remise en cause, qui évolue, donc :
  • pas de sang neuf pourtant potentiellement utile à la bonne santé d'un projet
  • un bus factor très bas

Ne pas savoir communiquer correctement, c'est de l'incompétence aussi.

Indépendamment des bienfaits pratico-pratiques de bien se comporter, j'ai beaucoup de mal à excuser ou justifier des comportements détestables, qu'ils viennent de quelqu'un qui s'y connaît ou non.

Il y avait une "sélection naturelle" impitoyable…

Il semblerait que la « "sélection naturelle" impitoyable » dont tu sembles être nostalgique ait sélectionné systemd…

mais avec l'arrivée de la professionnalisation et de la montée en puissance des GAFAM sont apparus des informaticiens compétent mais un peu trop scolaires poussé par ces entreprises

On rappellera que l'idée de systemd vient à l'origine de deux types qui bossaient à l'époque pour Red Hat (et qui ont construit sur un existant encore plus vieux) et que ça s'est imposé avant que l'un d'eux ne parte chez MS donc rien avoir avec les GAFAM.

Tu en es totalement à l’origine.

Non

Tu as juste projeté sur moi une pensée sociale et politique très pauvre.

Bah oui, à défaut d'avoir une explication demandée à répétition de ce que tu sous-entendais par :

Et le prosélytisme ainsi que l'agressivité du projet pour intégrer des besoins indépendants devrait interroger sur sa finalité (ne pas oublier que Microsoft est à la manœuvre). C'est très politique tout ça.

---

Insidueusement il fait passer le message de l’homme providentiel qui a sauvé l’écosystème Linux courant à la catastrophe. On aime ça en France les hommes providentiels.

Okay, ça ça pue vraiment du cul comme remarque.

Perso, je n'ai pas de passion pour systemd, si c'était une autre accusation que tu souhaitais exprimer. Mais j'avoue, j'ai du mal avec les argumentations pétées.

En fait, je me demande qui est le plus passionné ici.

Cet échange est mort, je m'arrête là.

Où est la vision manichéenne ? J'ai demandé d'étayer des accusations sous-entendues dont *je ne suis pas l'origine. J'ai développé cette demande pour montrer les contradictions sur lesquelles on tombe rapidement avec ces accusations.

Accusations que systemd poursuit une finalité questionable, juste après un rappel sur le fait que systemd a un lien avec Microsoft, sans d'ailleurs expliquer lequel. En partant de la supposition que Microsoft c'est le mal, j'imagine.

C'est moi qui suis manichéen ? Si mon raisonnement parait grotesque, il fallait être plus explicite en premier lieu.

Je suis sûr que systemd a des défauts, mais malheureusement, les critiques constructives, factuelles et informées se font rares dans les commentaires de cette page, à la place on a le droit à des tartines de frustrations profondes essentiellement causées par une méconnaissance du sujet, et maintenant, du fud. Super. En vrai, les gens semblent détester systemd de manière complètement irrationnelle. Rien de nouveau depuis 15 ans finalement.

Tant pis, j'irai lire des comparatifs informés avec les alternatives ailleurs à l'occasion pour satisfaire ma curiosité.

Ah oui, en effet, mes confuses, une petite lecture de /lib/systemd/system/systemd-nspawn@.service m'aurait permis d'éviter de dire des âneries. Comme quoi on en apprend tous les jours, y compris au plus profond d'un troll systemd xD

Y'a un tor.service et un tor@default.service. Encore une syntaxe à apprendre (mais pourquoi le arobase?? quel est le sens de tout ceci?), il y a surement une bonne explication à ce truc qui me paraît initialement incompréhensible.

Merci pour l'exemple concret :-)

Okay, j'ai été voir par curiosité. Je n'ai jamais mis tor en place. Ça a l'air d'être un choix de conception de Tor expliqué ici : Tor a décidé que ça devait être un système multi-instance, dont une par défaut (le default), et que lancer Tor sans préciser d'instance n'a pas de sens.

Ils auraient pu décider de ne pas fournir de tor.service, ou de le faire échouer avec un message d'erreur spécifique, en tout cas systemd ne les empêchaient pas de le faire. Pourquoi ils ne l'ont pas fait, je ne sais pas, en tout cas ça n'a pas l'air d'être la faute de systemd.

Quant au @, c'est une convention que d'autres services utilisent. Par exemple systemd-nspawn. Si tu veux gérer un conteneur tartampion avec un service, tu vas avoir un service nommé systemd-nspawn@tartampion.service. Tor a réutilisé cette convention pour son système multi-instance. Je note qu'il n'y a d'ailleurs pas de systemd-nspawn.service, Tor pourrait certainement calquer ça pour éviter les surprises. Moi, je trouve ce @ élégant, mais question de goût. Ça aurait pu être un autre caractère. C'est bien que ça ne soit pas alphanumérique, ni un tiret, ni un point, bref, pas un caractère que tu peux utiliser dans une le nom d'une variable C. Ça aurait pu être dans un sous-dossier mais je suppose que ne pas gérer une arborescence simplifie les choses.

Donc quand tu utilises tor@default.service, tu gères l'instance default de tor. Il semble important de comprendre cet élément central de l'architecture de tor.

Pour moi on est effectivement dans une situation où il y a une bonne explication à un truc initialement incompréhensible, et ça montre aussi que c'est facile de rejeter la faute sur le mauvais acteur si on ne s'est pas assez renseigné, entrainant potentiellement des échanges un peu stériles parce que les critiques sont incompréhensibles ou tombent à côté de la réalité, et du coup c'est impossible d'échanger sur une base commune compréhensible.

Oui, mais on est pas forcément d'accord avec ces justifications.

Oui, évidemment, mais du coup ce n'est plus juste "fuck you" :-)

quel génie Lennart est

il ne s'agit pas de ça, et par ailleurs, j'aimerais aussi avoir des trains à l'heure avec une tarification qui a du sens, le train étant un de mes modes de transports principaux.

j'ai faim

bon app'

Ah bah ui, c'est évident. Bien sûr. C'est clairement indiqué. Parfaitement lumineux

Ça m'a clairement surpris les premières fois. active (exited) est surprenant. Ça, je suis d'accord.

Bon, la sortie est certainement perfectible, mais une fois qu'on a compris la logique, ça va, non ?

Le système permet de gérer des units qui exécutent un programme qui retourne immédiatement pour mettre en place un truc, et c'est pas mal d'avoir un statut qui indique que ça a bien été lancé et que ça s'est bien passé.

Tu n'as même pas besoin de savoir beaucoup de choses pour utiliser systemd

je voulais dire journalctl ici.

Et vous remarquerez que Docker (et ses concurrents) sont des projets indépendant du noyau Linux.

Je ne vois pas trop le rapport avec Docker, mais la majorité de ce qui fait fonctionner Docker et ses copains aujourd'hui, c'est des fonctionnalités du noyau Linux et c'est dans le noyau Linux que les développements se sont passés. Notamment tout ce qui concerne l'isolation des différents namespaces. Ces systèmes sont des couches très légères sur des fonctionnalités puissantes du noyau (plus, éventuellement, tout un système de format et de distribution de conteneurs, et un système de virtualization sur les systèmes qui ne sont pas basés sur Linux, peut-être en faisant appel à des briques de toute façon existantes comme Qemu ou Hyper-V, à vérifier).

ne pas oublier que Microsoft est à la manœuvre

Le fait que Lennart bosse pour Microsoft est assez récent dans l'histoire de systemd.

devrait interroger sur sa finalité

Tu as des hypothèses ? J'en vois deux :

1. L'équipe derrière systemd est honnête sur son objectif de proposer une solution pour le démarrage des systèmes Linux
2. RedHat précédemment, et maintenant Microsoft, ont malicieusement poussé systemd partout (contre le gré des distributions qui n'ont pas du tout adopté systemd volontairement parce qu'en vrai, ce n'est pas une bonne solution technique qui résout des vrais problèmes que les distributions avaient sans systemd - surtout Debian qui n'a absolument pas un fonctionnement bénévole et démocratique et qui s'y est mis immédiatement et sans délai) pour conquérir le monde libre. Microsoft n'a en fait pas embauché Lennart pour son expertise en OS Linux au moment où ils ont un énorme cloud qui repose sur cette techno, et au moment où il veulent proposer du WSL pour récupérer des dev.
   

La deuxième hypothèse, en plus de sentir un peu la théorie du complot (qu'il faut donc bien étayer), n'explique pas l'absence totale de changement de situation entre le passage de Lennart de Red Hat à Microsoft, qui pourtant ne sont pas trop partenaires (Red Hat n'est d'ailleurs pas dans le store de Microsoft comme distribution installable pour WSL). Il faut aussi bien voir que l'hypothèse 2 ne serait pas une bonne nouvelle sur la gestion d'aucune distribution majeur, et en particulier Debian. En vrai, c'est même une accusation assez grave sur leur fonctionnement, donc ce n'est pas léger.

Alors, il me reste l'hypothèse 1, qui correspond également à mon ressenti personnel (je trouve les système linux incroyablement plus simple à utiliser et à administrer depuis systemd.

Je suis ouvert à d'autres hypothèses ou à des preuves pour étayer l'hypothèse 2 bien sûr.

Bah non, tout faut, zefklop.service c'est un lien sur /bin/true (pourquoi? parceque fuck you, that's why!!) et qu'il fallait utiliser systemctl start zefklop@default t'avais qu'a lire la doc! (wut?)

Je n'ai jamais observé ça. C'est quoi zefklop ? Un exemple concret, pas inventé, permettrait d'évaluer la situation correctement et objectivement.

parceque fuck you, that's why!!

Bon, rarement quand-même, il y a souvent une bonne explication à un truc qui nous parait initialement incompréhensible. C'est sûr que si tu prends les dev pour des adversaires, la vie va être triste.

Faisons juste un ps ax | grep zefklop. oula non

Bah pourquoi pas ? Ça fonctionne toujours et je ne m'en prive pas.

On critique justement systemd parce que ça fonctionne plus pareil et que ça veut remplacer les outils unix de base, mais quand ça marche, un grand plat de pâte géant nous interdit de les utiliser ? C'est un pattern que je vois pas mal dans les commentaires ici. "On nous dit de". On nous dit rien du tout, juste appelle ton grep et ton tail sur journalctl et appelle ps aux | grep pour trouver ton service, je ne vois pas où est le problème, personne ne va te manger si tu fais ça.

c'est quoi déjà le -x de journalctl? ou c'est -u, ou

Que suggères-tu comme solution ? Parce que tes outils unix historiques, ils sont tous comme ça. Il n'y a pas plus unix que des paramètres au nom plus ou moins arbitraire et plus ou moins logique à apprendre à utiliser. Regarde justement ps ax. C'est cryptique au possible. Perso j'écris ps aux, ou ps -ef si le précédent ne marche pas avec la version de ps que j'ai en main, sans savoir ce que ça veut dire parce que je sais que ça fait le taf, mais c'est pas très intelligent. Mais bon c'est pas grave, si un jour je suis curieux, il y a la doc. Pour ps comme pour journalctl, également de la même manière avec man ou -h.

Bref, critiquons systemd pour ses particularités, par pour les caractéristiques qu'il partage avec son écosystème, surtout quand on voudrait qu'il soit un peu plus dans la philosophie de cet écosystème.

Tu n'as même pas besoin de savoir beaucoup de choses pour utiliser systemd. Voilà tout ce que j'utilise de lui, et je n'en sais pas plus (notamment, l'option -x, je ne sais pas ce qu'elle fait et je n'en ai pas encore eu besoin - ou peut-être je passe à côté de quelque chose mais je suis encore vivant) :

• l'option -u (pour unit, unité) pour cibler le service dont tu veux les logs. À omettre si tu veux tous les logs.
• l'option -r (pour reverse, inverser) pour lire les logs du plus récent en bas. Franchement, ça aurait pu être par défaut, mais bon, les outils historiques ont le même sens de lecture que le sens par défaut
• l'option -f (pour follow, suivre) pour suivre les logs en temps réel.

Propose aussi simple avec les outils Unix traditionnels.

Maintenant qu'on vient d'établir que journalctl est aussi simple d'utilisation que possible, et suite aux échanges dans ces commentaires, je vais avoir besoin d'être convaincu que l'affirmation suivante est fausse : les attentes sur systemd de la part de ses détracteurs sont irréalistes, et ce qu'ils proposent est moins utilisable, moins fonctionnel, ou n'existe pas. Bon, pour être tout à fait honnête, c'était déjà mon avis avant ces échanges.

Autre affirmations à casser :

1. Les systèmes d'init alternatifs obligent à écrire des scripts shell pour définir des services et/ou de hardcoder le processus entier de boot (ce qui est à la fois un calvaire pour la distribution et pour l'utilisateur ou l'utilisatrice), au lieu d'utiliser un format déclaratif dans lequel on peut lister les dépendances et d'avoir un moteur d'exécution qui résout ses dépendances proprement.
2. Ils ne proposent pas non plus un système d'activation lazy par l'accès à un socket, ce qui fait que tout ce dont on pourrait potentiellement avoir besoin doit être démarré en avance, et tout doit tourner sur la machine en permanence.
   

La seule chose qui m'a convaincue pour le moment, c'est le retour d’AncalagonTotof sur le fait que c'est difficile de retrouver ses petits après un changement, mais ce n'est pas vraiment spécifique à systemd, c'est commun à toute évolution.

Ah oui, en effet. Dans ce cas, j'imagine que la faute est partagée :

• les distributions devraient modulariser la distribution de systemd
• il n'y a pas, de la part du projet systemd, une volonté de pousser les distributions à modulariser, notamment en donnant des guidelines pour l'empaquetage

Peut-être que ça viendra si une alternative un minimum suivie réutilise certaines briques de systemd et pas d'autres.

À propos de ton dernier paragraphe : j'ai espoir que je ferai partie de la seconde catégorie de gens mais je comprends parfaitement les difficultés liées à réapprendre des choses qu'on sait déjà faire efficacement avec un système qui est remplacé. C'est assez frustrant.

Je ne l'ai pas trop vécu avec la transition vers systemd (et la transition vers upstart avant ça), mais on ne peut pas dire que j'avais une utilisation avancée. Je redémarrais les services (d'ailleurs la commande pour ça, service xxx restart, fonctionne toujours, même si elle est découragée et qu'elle va certainement disparaître et qu'elle n'est même pas partout) et consultais les logs, sans plus.

Rien à été conçu dans SystemD pour decoupler les choses.

Au contraire, je crois que c'est l'inverse. Tu as un exemple de deux choses qui pourraient et devraient être découplées (parce que ce serait utile, avec un exemple de pourquoi ce serait utile) mais qui ne le sont pas ? Et qui le sont dans un projet équivalent ?

Très bizarres tes commentaires ici. Tu affirmes partout que systemd est mal conçu, que c'est indébogable… Sans jamais rentrer dans les détails.

Moi je dis : il va falloir étayer tout ça, parce qu'il ne suffit pas de l'affirmer pour que ce soit vrai, et je suis loin d'être convaincu. En particulier quand justement aucune alternative crédible n'a réussi à percer malgré les efforts.

Ici tu affirmes que Lennart n'est pas au niveau. Bon déjà il ne travaille pas seul sur systemd, donc tu vises une équipe entière. Et… ça parait grotesque. On peut ne pas aimer son travail, mais son niveau… On parle quand même d'une personne qui a transformé le desktop linux dans plein d'aspects souvent fondamentaux. On n'y arrive pas si on est incompétent. Va falloir étayer aussi, et bon courage.

Concernant Rust, il a argumenté et c'était très raisonnable. Rust actuellement n'est pas adapté au cas d'usage de systemd et ses remarques étaient une invitation à améliorer Rust pour qu'il soit adapté à son cas d'usage. La démarche me parait bonne, mais bon, oui, tu peux continuer à te boucher les oreilles quand des experts mondiaux travaillant sur des parties critiques de ton OS font des retours constructifs sur pourquoi ils ne peuvent pas utiliser telle ou telle techno en l'état et décréter que c'est parce qu'ils sont nuls.

Ça doit demander un sacré égo, ça me laisse admiratif…

tout les soft doivent être redéveloppé quasiment pour SystemD

Tu peux en dire plus ? Si ton soft est intimement lié au boot, ça paraît normal, mais sinon, que faut-il adapter ?

C'est précisément ça que je repproche à systemd

Mais systemd n'est pas un bloc monolithique, c'est un ensemble de petits outils qui se concentrent sur une chose et qui fonctionnent bien ensemble. Du coup, de ce point de vue, ça respecte la philosophie unix. Je ne commente pas l'aspect "bien" de "faire une seule chose bien", on peut subjectivement trouver qu'ils ne font pas bien le taf.

Le pid 1 de systemd est peut-être plus complexe que le reste, peut-être qu'on peut discuter cet aspect, en vérifiant que les alternatives ne sont pas aussi complexes de toute façon, à fonctionnalités comparables.

On peut regretter que journald ne soit pas optionnel (pid 1 l'est probablement, je suppose qu'on peut utiliser la plupart des outils systemd sans, à vérifier), donc la modularité a ses limites, mais pareil, est-ce plus modulaire ailleurs ? Vrai question, je ne suis pas trop familier avec les alternatives.

Enfin, on peut regretter que journald stocke les journaux en binaire. Question de goût, je suppose que c'est pour des questions de robustesse et d'efficacité. Je comprends qu'on n'aime pas trop, en même temps ça ne m'est jamais arrivé de m'en rendre compte parce que je trouve journalctl très agréable à utiliser pour manipuler les logs.

En résumé, qu'est-ce qui n'est pas unix pour toi dans systemd, et quels inconvénients cela apporte en ptatique ? (Après avoir lu les contre-arguments aux critiques usuelles là : http://0pointer.de/blog/projects/the-biggest-myths.html_ en particulier les points 1 et 10)

Je note l'inaccessibilité des logs sans utiliser un binaire systemd, j'entends, avec les réserves que j'ai émises dans l'autre commentaire.

Sinon j'entends aussi l'argument de n'être pas familier avec la solution, en vrai c'est une vraie bonne raison.

Concernant ta question sur la modularité et si quelqu'un a essayé en pratique, je n'ai pas trop essayé à part utiliser ou non systemd-networkd, nspawn et leur solution pour remplacer cron (?). Je dirais que c'est à la critique de montrer que ce n'est pas modulaire.

Mais en vrai, la philosophie unix, je m'en fiche un peu, ce qui m'importe c'est que ce soit efficace, clair et si possible élégant. Un argument plus fort pour moi serait la présentation d'une alternative dont la fonctionnalité principale n'est pas "n'est pas systemd", mais des arguments convaincants sur pourquoi c'est mieux. Sachant que pour moi, l'arrivée de systemd a été une grosse amélioration. Écrire un service par exemple, largement plus simple et plus compréhensible qu'un script shell parce que c'est en mode déclaratif et c'est très conscis. C'était déjà le cas avec upstart, qui était pas mal, mais pour moi systemd est juste un meilleur upstart, avec si j'ai bien compris un peu d'inspiration du côté de launchd avec l'activation par socket (qui semble être une excellente idée, pour avoir accès à des fonctionnalité sans tout devoir lancer en avance).

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.