raphj a écrit 1623 commentaires

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.

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 ?