Je sais pas si je qualifierais ça de débat, vu que presque personne ne semble participer à part mirabilos (et un gars qui réponds) pour un bug ouvert depuis 10 jours. Et bien que ne participant pas à Debian, j'ai reconnu son nom aussi tôt vu le nombre d'avis claqués au sol qu'il a posté depuis des années.
Donc j'ai tendance à penser qu'il a largement brûlé son capital social dans le projet et que ça va pas faire tant de bruit dans l'état.
Cette partie de la réponse mérite d'être relevée :
however this affects various other code bases as well, for example src:linux[1]:
| as an example, he pointed to a patch credited to him that was merged
| for the 6.15 release. that patch was entirely written by an llm,
| changelog included.
and
| another example is the git-resolve script that was merged for 6.16.
| this script, which came out of a late 2024 discussion on ambiguous
| commit ids, will resolve an ambiguous (or even incorrect) id into a
| full commit. it, too, was generated with an llm. not only does it
| work, but it includes a full set of self tests, something he noted
| (with understatement) is unusual for code found in the kernel's
| scripts directory. llms, he said, ""won't give you a frowny face""
| when asked to generate tests. the script includes documentation
| (also unusual for that directory), and is being used on a daily
| basis in the kernel community.
Le gras est de moi. Du code généré par LLM on interagit tous les jours y compris dans le kernel… L'IA ne s'en ira pas.
L'argumentation de ansgar est d'autant plus fallacieuse pour dire que les LLM sont ok, que dans les commentaires LWN, il est justement relevé que les patchs linux du LLM contenait au moins un bug évitable, ainsi que le manque d'honneteté du contributeur qui a poussé ce code généré par LLM.
As the maintainer that pulled Sasha's patch, I missed the removal of the "__read_mostly" because I thought Sasha had written it
Which I would have caught if I had know this was 100% generated, as I would not have trusted the patch as much as I did thinking Sasha did the work.
The missing "__read_mostly" is a red herring. The real issue is transparency. We should not be submitting AI generated patches without explicitly stating how it was generated. As I mentioned. If I had known it was 100% a script, I may have been a bit more critical over the patch. I shouldn't be finding this out by reading LWN articles.
Le manque d'honnêteté ça y'a pas de doute. Il va falloir créer des tags (comme les TW ou NSFW) ou autre signifiant pour informer que tel truc n'a pas été produit par un humain. Et trouver des limites aussi, parce que ça fait longtemps qu'on utilise des textes produits par des algorithmes donc ça serait contre-productif de signaler chaque ligne de ce style (par exemple quand je traduis quelque chose je fais généralement relire par Deepl, qui utilise le même type d'IA (transformers) que les ChatGPT &co)
Par contre je ne suis pas sûr que ça change la conclusion du commentaire : on interagit déjà avec quantité de code produit par LLM y compris dans le kernel. Et il y a sûrement plein de cas non-détectés parce qu'il n'y avait tout simplement rien à redire sur le patch.
Je n'ai pas bien compris cette discussion. Déjà, je ne vois pas de "mirabilos" dedans (s'agit-il de Thorsten Glaser, Ansgar 🙀 ou Michael Biebl ?). Ensuite, existe t-il une règle qui interdit le code généré par LLM dans Debian (j'imagine que non vu le "wontfix") ? Et surtout, qui dit que tout code généré par LLM est "very likely non-free", à part l'auteur du message ? Est-ce une position répandue ? Celle de la FSF ?
Quand je dit mirabilos, je parle de Thorsten Glaser.
Et je pense qu'il fait référence au procès en cours, en prenant une position maximaliste sur le sujet. Même si je vois le raisonnement, ça n'a pas l'air d'être celle de la justice américaine si j'en crois d'autres cas en cours de jugement.
Et que je sache, la FSF n'a pas publié grand chose. Comme le faisait remarquer Matthew Garrett un jour (je crois), la position maximaliste en question ne serait sans doute pas totalement aligné avec les positions de la FSF qui n'utilise le copyright que comme un outil pour avoir plus de code libre et pas une fin en soi.
Je vais te dire comment on a fait. On a fait sans. Comme on a fait sans la voiture avant qu'elle ne soit là…
Mais il faut dire une chose, la gestion des logs avec l'IA n'est certainement pas son utilisation la plus idiote. Il faudra des garde fous, des solutions plus light. Mais elle peut largement apporter un plus en repérant plus facilement les changements "suspect" pour ne pas simplement dire les changements.
La question n'est pas sur l'IA, mais sur la manière dont elle est intégré à commencé par le manque de débat. On peut faire des trucs génial avec l'IA mais aussi des catastrophes… comme avec la voiture.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Mais est-ce que le jeu en vaut la chandelle ? Si les calculs sont déportés dans un datacenter, est-ce que la dépense énergétique induite vaut vraiment le coup ?
Si c'est du LLM qui tourne en local, éventuellement - mais est-ce que ce sera suffisamment performant/efficace ?
Sachant que ce ne sont que des maths et plus précisément des statistiques, est-ce qu'un algorithme écrit spécifiquement ne serait pas une meilleure solution technique avec un impact énergétique/environnemental plus faible ?
est-ce qu'un algorithme écrit spécifiquement ne serait pas une meilleure solution technique avec un impact énergétique/environnemental plus faible ?
Ce n'est pas la réponse que l'on peut faire sur chaque utilisation de l'IA ? Quand l'algorithme exact ne peut être écrit (n'est pas connu, est trop compliqué, par flemme, par méconnaissance, etc.) on a recours à un algo caché dans une IA dont on ignore ce qu'il fait précisément/exactement mais qui globalement fait le taf. Parce que sinon on peut faire de l'apprentissage sur 1 milliard de cas pour faire une IA pour le tic-tac-toe ou le lancer de deux dés à 6 faces.
Après si le point est "ne choisissons nous pas ici l'IA par flemme/facilité", j'aime à le penser oui, mais le sait-on vraiment a priori ? (Ie. Va-t-on apprendre des banalités genre "si niveau de log CRITICAL ou ERROR c'est qu'il y a un problème" ou des choses utiles comme le log A est suivi du log B et 15min32s après ça donne l'erreur du log C, à chaque fois)
Ce n'est pas la réponse que l'on peut faire sur chaque utilisation de l'IA ?
C'est le sentiment que j'ai aussi.
L'usage de l'IA me semble pertinent pour de la « compréhension » de texte. Et encore, je dis « IA » mais finalement c'est seulement l'apprentissage profond qui est utile dans ce cas et ça existait avant l'arrivée des IA dites « génératives ».
La partie « génération » de texte telle que les chatbots la font peut être à mon avis quelque chose d'intéressant pour produire des réponses et une interaction qui soit plus adaptable que des réponses prédéfinies, mais là encore, je ne suis pas sûr que monter des datacenters et les centrales qui vont avec vaille le coup.
Pour le reste, je reste très dubitatif. Je caricature un peu mais toute cette dépense d'énergie pour résumer des mails de 10 lignes et générer des starter packs, c'est un sacré gâchis. Que ce soit pour synthétiser des documents ou du code, dans tous les retours que j'ai pu lire ci et là, à chaque fois il fau(drai)t que ce soit relu par un humain pour corriger. L'argument qui consiste à dire que ça fait gagner du temps perd de fait de sa pertinence - surtout mis en regard de ce que ça implique pour notre environnement.
Posté par barmic 🦦 .
Évalué à 4 (+2/-0).
Dernière modification le 22 juillet 2025 à 09:55.
[…] à chaque fois il fau(drai)t que ce soit relu par un humain pour corriger. L'argument qui consiste à dire que ça fait gagner du temps perd de fait de sa pertinence […]
Ce n’est pas parce que le temps ne devient pas nul, que l’argument n’est pas pertinent. Pour des tâche de création, tu n’a pas à faire de travail de vérification des sources, tu vérifie juste le résultat par rapport à ce qui est attendu. Pour le gain de temps il faut comparer le temps de prompt + l’évaluation/amélioration au temps que la tâche prend sans (et donc c’est à chacun de faire son avis en fonction de la tâche et de la qualité du résultat).
Ça change aussi le flux de travail, il peut être laborieux de démarrer une tâche (syndrome de la page blanche, procrastination) et bien plus simple de corriger un résultat.
Pour ce qui est des tâches de synthèse, c’est plus compliqué :
des fois tu va de toute manière mécaniquement vérifier l’information (si tu te sert de ça par exemple pour savoir comment lancer awk) dans ces cas là c’est un moteur de recherche sophistiqué ou avec une consolidation de l’information. L’intérêt dépend de la qualité de la doc et de ta capacité à naviguer dedans entre autre.
si c’est pour de la publication par contre là c’est une autre paire de manche effectivement
Posté par woffer 🐧 (site web personnel) .
Évalué à 4 (+2/-0).
Dernière modification le 22 juillet 2025 à 11:10.
J'imagine que les équipes vont intégrer un service MCP (une sorte de connexion "USB" mais pour l'IA) au service rsyslog.
Par ailleurs, j'ai déjà vu pas ce genre d'initiative (genre dans certains débugueurs) pour y connecter agent d'IA (ou autres).
# Décision en cours chez Debian
Posté par Glandos . Évalué à 4 (+2/-0).
Ça se passe sur https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109121
[^] # Re: Décision en cours chez Debian
Posté par Misc (site web personnel) . Évalué à 4 (+1/-0).
Je sais pas si je qualifierais ça de débat, vu que presque personne ne semble participer à part mirabilos (et un gars qui réponds) pour un bug ouvert depuis 10 jours. Et bien que ne participant pas à Debian, j'ai reconnu son nom aussi tôt vu le nombre d'avis claqués au sol qu'il a posté depuis des années.
Donc j'ai tendance à penser qu'il a largement brûlé son capital social dans le projet et que ça va pas faire tant de bruit dans l'état.
[^] # Re: Décision en cours chez Debian
Posté par Faya . Évalué à 6 (+5/-1).
Cette partie de la réponse mérite d'être relevée :
Le gras est de moi. Du code généré par LLM on interagit tous les jours y compris dans le kernel… L'IA ne s'en ira pas.
[^] # Re: Décision en cours chez Debian
Posté par Octabrain . Évalué à 7 (+5/-0).
L'argumentation de ansgar est d'autant plus fallacieuse pour dire que les LLM sont ok, que dans les commentaires LWN, il est justement relevé que les patchs linux du LLM contenait au moins un bug évitable, ainsi que le manque d'honneteté du contributeur qui a poussé ce code généré par LLM.
[^] # Re: Décision en cours chez Debian
Posté par Faya . Évalué à 4 (+2/-0).
Le manque d'honnêteté ça y'a pas de doute. Il va falloir créer des tags (comme les
TWou NSFW) ou autre signifiant pour informer que tel truc n'a pas été produit par un humain. Et trouver des limites aussi, parce que ça fait longtemps qu'on utilise des textes produits par des algorithmes donc ça serait contre-productif de signaler chaque ligne de ce style (par exemple quand je traduis quelque chose je fais généralement relire par Deepl, qui utilise le même type d'IA (transformers) que les ChatGPT &co)Par contre je ne suis pas sûr que ça change la conclusion du commentaire : on interagit déjà avec quantité de code produit par LLM y compris dans le kernel. Et il y a sûrement plein de cas non-détectés parce qu'il n'y avait tout simplement rien à redire sur le patch.
[^] # Re: Décision en cours chez Debian
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Je n'ai pas bien compris cette discussion. Déjà, je ne vois pas de "mirabilos" dedans (s'agit-il de Thorsten Glaser, Ansgar 🙀 ou Michael Biebl ?). Ensuite, existe t-il une règle qui interdit le code généré par LLM dans Debian (j'imagine que non vu le "wontfix") ? Et surtout, qui dit que tout code généré par LLM est "very likely non-free", à part l'auteur du message ? Est-ce une position répandue ? Celle de la FSF ?
[^] # Re: Décision en cours chez Debian
Posté par Misc (site web personnel) . Évalué à 4 (+1/-0).
Quand je dit mirabilos, je parle de Thorsten Glaser.
Et je pense qu'il fait référence au procès en cours, en prenant une position maximaliste sur le sujet. Même si je vois le raisonnement, ça n'a pas l'air d'être celle de la justice américaine si j'en crois d'autres cas en cours de jugement.
Et que je sache, la FSF n'a pas publié grand chose. Comme le faisait remarquer Matthew Garrett un jour (je crois), la position maximaliste en question ne serait sans doute pas totalement aligné avec les positions de la FSF qui n'utilise le copyright que comme un outil pour avoir plus de code libre et pas une fin en soi.
# Ils ont du retard (ou de l'avance) ...
Posté par woffer 🐧 (site web personnel) . Évalué à 5 (+3/-0).
… car si je ne me trompe pas, on n'est pas un 1er avril.
[^] # Re: Ils ont du retard (ou de l'avance) ...
Posté par David Demelier (site web personnel) . Évalué à 5 (+3/-0).
Hélas. Comment avons nous fait pour vivre avec des gestionnaires de logs sans IA pendant plus de 30 ans ?
C'était indispensable, ma vie trouve son sens enfin.
AI is a mental disorder
[^] # Re: Ils ont du retard (ou de l'avance) ...
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3 (+4/-2). Dernière modification le 21 juillet 2025 à 22:34.
Je vais te dire comment on a fait. On a fait sans. Comme on a fait sans la voiture avant qu'elle ne soit là…
Mais il faut dire une chose, la gestion des logs avec l'IA n'est certainement pas son utilisation la plus idiote. Il faudra des garde fous, des solutions plus light. Mais elle peut largement apporter un plus en repérant plus facilement les changements "suspect" pour ne pas simplement dire les changements.
La question n'est pas sur l'IA, mais sur la manière dont elle est intégré à commencé par le manque de débat. On peut faire des trucs génial avec l'IA mais aussi des catastrophes… comme avec la voiture.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Ils ont du retard (ou de l'avance) ...
Posté par madhatter (site web personnel) . Évalué à 4 (+3/-0).
On peut faire des trucs géniaux aussi. ;)
Mais est-ce que le jeu en vaut la chandelle ? Si les calculs sont déportés dans un datacenter, est-ce que la dépense énergétique induite vaut vraiment le coup ?
Si c'est du LLM qui tourne en local, éventuellement - mais est-ce que ce sera suffisamment performant/efficace ?
Sachant que ce ne sont que des maths et plus précisément des statistiques, est-ce qu'un algorithme écrit spécifiquement ne serait pas une meilleure solution technique avec un impact énergétique/environnemental plus faible ?
There is no spoon...
[^] # Re: Ils ont du retard (ou de l'avance) ...
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+3/-0).
Ce n'est pas la réponse que l'on peut faire sur chaque utilisation de l'IA ? Quand l'algorithme exact ne peut être écrit (n'est pas connu, est trop compliqué, par flemme, par méconnaissance, etc.) on a recours à un algo caché dans une IA dont on ignore ce qu'il fait précisément/exactement mais qui globalement fait le taf. Parce que sinon on peut faire de l'apprentissage sur 1 milliard de cas pour faire une IA pour le tic-tac-toe ou le lancer de deux dés à 6 faces.
Après si le point est "ne choisissons nous pas ici l'IA par flemme/facilité", j'aime à le penser oui, mais le sait-on vraiment a priori ? (Ie. Va-t-on apprendre des banalités genre "si niveau de log CRITICAL ou ERROR c'est qu'il y a un problème" ou des choses utiles comme le log A est suivi du log B et 15min32s après ça donne l'erreur du log C, à chaque fois)
[^] # Re: Ils ont du retard (ou de l'avance) ...
Posté par Pol' uX (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 22 juillet 2025 à 07:10.
Personne n'étant disponible pour suivre ces alertes en temps réel, je propose de les consigner dans un journal D.
Adhérer à l'April, ça vous tente ?
[^] # Re: Ils ont du retard (ou de l'avance) ...
Posté par madhatter (site web personnel) . Évalué à 3 (+2/-0).
C'est le sentiment que j'ai aussi.
L'usage de l'IA me semble pertinent pour de la « compréhension » de texte. Et encore, je dis « IA » mais finalement c'est seulement l'apprentissage profond qui est utile dans ce cas et ça existait avant l'arrivée des IA dites « génératives ».
La partie « génération » de texte telle que les chatbots la font peut être à mon avis quelque chose d'intéressant pour produire des réponses et une interaction qui soit plus adaptable que des réponses prédéfinies, mais là encore, je ne suis pas sûr que monter des datacenters et les centrales qui vont avec vaille le coup.
Pour le reste, je reste très dubitatif. Je caricature un peu mais toute cette dépense d'énergie pour résumer des mails de 10 lignes et générer des starter packs, c'est un sacré gâchis. Que ce soit pour synthétiser des documents ou du code, dans tous les retours que j'ai pu lire ci et là, à chaque fois il fau(drai)t que ce soit relu par un humain pour corriger. L'argument qui consiste à dire que ça fait gagner du temps perd de fait de sa pertinence - surtout mis en regard de ce que ça implique pour notre environnement.
There is no spoon...
[^] # Re: Ils ont du retard (ou de l'avance) ...
Posté par barmic 🦦 . Évalué à 4 (+2/-0). Dernière modification le 22 juillet 2025 à 09:55.
Ce n’est pas parce que le temps ne devient pas nul, que l’argument n’est pas pertinent. Pour des tâche de création, tu n’a pas à faire de travail de vérification des sources, tu vérifie juste le résultat par rapport à ce qui est attendu. Pour le gain de temps il faut comparer le temps de prompt + l’évaluation/amélioration au temps que la tâche prend sans (et donc c’est à chacun de faire son avis en fonction de la tâche et de la qualité du résultat).
Ça change aussi le flux de travail, il peut être laborieux de démarrer une tâche (syndrome de la page blanche, procrastination) et bien plus simple de corriger un résultat.
Pour ce qui est des tâches de synthèse, c’est plus compliqué :
Mais oui l’impacte écologique est démesuré
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ils ont du retard (ou de l'avance) ...
Posté par woffer 🐧 (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 22 juillet 2025 à 11:10.
J'imagine que les équipes vont intégrer un service MCP (une sorte de connexion "USB" mais pour l'IA) au service rsyslog.
Par ailleurs, j'ai déjà vu pas ce genre d'initiative (genre dans certains débugueurs) pour y connecter agent d'IA (ou autres).
# Metalog
Posté par Maderios . Évalué à 4 (+2/-0).
Ce n'est peut-être pas un hasard si Arch officiel ne fournit pas de paquet Rsyslog. J'utilise Metalog.
Il existe également syslog-ng
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.