❌

Vue lecture

Debian, IA, vibe coding & rsync : la croisée des chemins ?

rsync est un logiciel libre de synchronisation distante de fichiers (remote synchronisation), très utilisé et fréquemment évoqué sur LinuxFr.org. Ce logiciel a connu une polémique récente sur l’utilisation de LLM pour son développement et maintenant les versions concernées sont arrivées dans Debian, non seulement les versions futures de la distribution mais également la version courante. Et la suite de la dépêche de s’interroger sur les conséquences ou non de ce (peut-être) notable événement. Et plus largement sur le clivage autour de l’intelligence artificielle générative.

    Le 20 mai 2026, la version 3.4.3 a été publiée, amenant des correctifs sécurité et des corrections de bugs. Et très vite les critiques sont arrivées (par exemple le 29 mai le bug Debian Consider reverting to pre-LLM version (considérer un retour à une version pré-LLM) ou le 30 mai un ticket GitHub Please Do Not Vibe Fuck Up This Software (quelque chose comme merci de ne pas sIAloper ce logiciel) attribuant les problèmes à l’intelligence artificielle ; ceci a entraîné une réponse du mainteneur Andrew Tridgell rsync and outrage expliquant s’être aidé de LLM pour réécrire sa suite de tests (du shell au Python). Et les régressions constatées n’étaient pas liées à l’IA au final.

    Dès le 20 mai, la première version post-polémique atteignait les dépôts Debian de développement ([2026-05-20] Accepted rsync 3.4.3+ds1-2 (source) into unstable). Et en août la version 3.5 y est entrée ([2026-08-17] Accepted rsync 3.5.0+ds1-1 (source) into unstable).

    En juillet et août 2026 a eu lieu un scrutin pour les personnes développant la distribution Debian sur l’usage des LLM (voir les annonces, discussions, résultats et conséquences 1, 2, 3). Le choix s’est porté sur un « usage responsable de l’IA générative ».

    Le 15 septembre, le mainteneur Debian du paquet rsync a annoncé que « pour corriger 33 CVE, [il a] décidé de passer à la version 3.5.0 plutôt que de rétroporter toutes les corrections individuellement » (ce qui entraîne des changements de comportement, est annoncé à la mise à jour du paquet et a amorcé la réflexion qui a donné lieu à cette dépêche).

    Verra-t-on un basculement majeur vers autre chose que rsync des réfractaires à l’IA ? Est-ce un non-événement ? Est-ce le premier de nombreux cas où des paquets embarquant des modifications faites par un LLM (sont arrivées et) arriveront dans Debian ?

    D’une part, la fracture sur le sujet est palpable : ainsi le sondage StackOverflow 2025 rapportait 20% de défavorables à l’IA, 60% de favorables et 20% d’incertains/indifférents, mais avec 33% de confiance dans l’IA et 46% de défiance, et 32% d’utilisateurs de l’IA et 38% de réfractaires à l’idée. Le sondage State of Devs 2026 donne un 50/50 sur les avis positifs ou négatifs sur l’IA, sur l’effet sur l’état mental de l’IA, et classe en premier comme risques l’impact environnement, la perte d’emploi, la montée de l’IA slop, les effets cognitifs et l’usage militaire. Même le sondage State of IA 2026 est révélateur : les utilisateurs d’IA amplifient leur usage, avec de plus en plus d’agentique, tout en reconnaissant une addiction, une capacité à se faire traire financièrement (pour le dire grossièrement) et une montée des risques. Dit autrement tout en se traitant parfois qui de mormons passéistes rétrogrades qui de moutons suivistes antéchristiques (termes non contractuels), tout le monde reconnaît la complexité et la multiplicité des risques.

    D’autre part, la capacité à faire autrement est assez réduite : forker une Debian en Devuan pour se passer de Systemd est « relativement » facile, on remplace un seul logiciel et les alternatives pré-existaient. Vouloir éviter d’être teinté par une GPL comme certains projets BSD reste faisable (il suffit d’une alternative à chaque logiciel GPL, et visiblement c’est plus ou moins le cas). Mais vouloir éviter tout logiciel libre ayant eu une contribution LLM est-il encore possible ? Est-on seulement capable de lister les logiciels concernés ? Et existe-t-il encore une alternative non-teintée à chacun d’entre eux ? Ne serait-ce pas aussi dur que par exemple vouloir faire du logiciel propriétaire sans jamais utiliser un seul logiciel libre quand ceux-ci sont omniprésents, en particulier dans le développement logiciel ?

    Bref, est-on à une croisée des chemins ? Ou déjà bien engagé sur une route (et laquelle) ? La réponse est laissée en exercice au lectorat (moi à la base je voulais juste mettre à jour des Debian).

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    •  

    CERN Transitioning From RHEL To Debian

    Longtime Slashdot reader Microsplat: CERN plans to have all 2,200+ industrial computers and embedded systems in its accelerator-control infrastructure running Debian 13 by the end of 2026. These are systems used for accelerator control, laboratory equipment and other operational functions ... They also generate and interact with a hefty amount of data, although this Linux.com article refers more broadly to CERN's computing infrastructure. It's unclear whether the Debian migration covers all server infrastructure or what scientific-research-based systems are included. Our shops have done much the same in recent years, mostly due to CentOS and CFEngine getting the can. Phoronix adds some additional context in its article: CERN was a longtime RHEL/CentOS shop, previously co-maintained the Scientific Linux RHEL derivative, moved to CentOS in 2015, and later considered CentOS Stream. CERN says Red Hat's adoption of the "-march=x86-64-v2" compiler flag by default, which it viewed as "forced obsolescence" of older hardware, was the "straw that broke the camel's back."

    Read more of this story at Slashdot.

    •  

    Debian Decides: Contributors Can Use Generative AI 'Responsibly'

    This week Debian voted on whether to ban AI-assisted contributions. The winning proposal? "Debian neither endorses nor prohibits the use of generative AI tools" in its projects, documentation, and packaging... Generative AI "is neither exempt from nor subject to special rules beyond the standards already expected of Debian contributors." "The responsibility for every contribution rests with the contributor who submits it, who remains accountable for its technical quality, legal acceptability, and suitability for inclusion in Debian." "We recognize that such tools can substantially improve the productivity of contributors when used responsibly, allowing volunteers to spend more of their limited time on work that requires technical expertise, judgment, review, and collaboration. The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance. The use of a generative AI tool does not diminish the contributor's responsibility for the work they submit. Contributors are expected to understand, review, test, and, where appropriate, modify AI-assisted output before incorporating it into Debian. Blindly accepting or uploading AI-generated material without appropriate human review is inconsistent with Debian's established development practices. We enourage our contributors to disclose whether a contribution was made with AI assitance, but do not require them to do so. Debian acknowledges that the legal status of material produced by generative AI systems remains the subject of ongoing discussion in many jurisdictions, including questions relating to copyright... The Project does not seek to resolve these unsettled legal questions through this General Resolution, nor does it adopt a position on whether AI-generated output is, in whole or in part, copyrightable or derived from copyrighted works. Instead, Debian continues to rely on the judgment and responsibility of its individual contributors. Project members are expected to exercise appropriate care when using generative AI tools, to consider the provenance and licensing implications of material they contribute, and to avoid introducing content whose legal status they cannot reasonably justify. Existing Debian policies governing licensing, copyright, software freedom, and the acceptance of contributions continue to apply irrespective of the tools used to produce those contributions. It also cautions contributors to keep keys, credentials, and embargoed security reports from leaking to third-party AI services. But discussion continues on Debian's mailing list. "I regret the loss of contributors," wrote the author of the winning proposition (while acknowledging it would have happened with either option winning). "It is just too early to take a final decision on the matter. Let's revisit this in two years or so, and let this mess of a GR be a warning for our future selves." Other comments from the mailing list: "On a very personal note, I regret that the winning option does not acknowledge all the legitimate concerns around AI: environmental impact, copyright and licensing uncertainty, the health of Free Software communities, and the strain of aggressive scraping on the open web... [W]e have a lot of work ahead of us to act as a community and understand how we can continue to accommodate the very large minority that would have preferred to ban or discourage AI. "I also think that our next discussion should distinguish between locally running LLMs and cloud LLMs. The way things are going, locally running LLMs will be an alternative, and then you can much better control what was the training data and the Freeness of the thing." Thanks to long-time Slashdot reader Robbat2 for sharing the news.

    Read more of this story at Slashdot.

    •  

    Debian is Voting on Whether to Allow AI-Assisted Contributions

    Debian developers are voting on whether to ban AI-assisted contributions, reports the blog Linuxiac, with a ballot listing eight proposals and a "None of the above" option. The first one is still the original proposal to ban LLM-assisted contributions by changing the Debian Social Contract. This would stop generative AI from being used for direct Debian work like packaging, software, documentation, translations, websites, and project communication. However, upstream projects made with AI help would not be affected. The proposal gives several reasons for the ban, such as unclear copyright and licensing, doubts about the reliability of AI-generated work, extra review work for maintainers, aggressive scraping of Free Software resources, and the high resource use of large AI systems... The second option would clearly allow contributions that are partly or fully made by an LLM, as long as contributors check their technical quality, security, licensing, and usefulness, fully understand the changes, and disclose major AI help. It would also ban sending private or sensitive Debian information to untrusted external AI services. A similar fourth option recognizes worries about generative AI but says banning it would be hard to enforce and not helpful. This proposal would accept AI-assisted Debian work if it follows the Debian Free Software Guidelines, is properly reviewed and understood by the contributor, and is marked as AI-assisted when needed. The fifth proposal is even more open. It says Debian should not support or ban generative AI tools, but should apply the same standards for quality, correctness, maintainability, and legality to all contributions, no matter how they were made... One unique proposal is called "Debian is created by humans." Instead of banning AI tools for contributors, it focuses on what actually gets included in Debian. With this approach, contributors could use generative AI for research, analysis, exploration, or critique, but could not submit AI-generated output directly as Debian packaging, patches, documentation, bug reports, project communications, or other Debian work. As the proposal says: humans create Debian. Another, much stricter proposal asks Debian contributors to avoid LLM use as much as possible. It would require all Debian communication, like bug reports, mailing-list messages, Salsa discussions, and Planet Debian posts, to be written only by humans. Any AI use in Debian work would have to be disclosed, and violations could be handled under the project's Code of Conduct. The CEO/founder of AI-native compliance management platform company Strike Graph believes a Debian AI ban is "the wrong fix for the actual problem" at hand, reports The New Stack: "Debian's ban isn't really about banning AI," [CEO Justin] Beals says. "It's an admission that nobody has built a reliable way to verify what an AI agent actually produced before it lands in a codebase this many systems depend on, including infrastructure running in orbit. That's a legitimate thing to be worried about...." He thinks that any policy statement that says AI isn't allowed simply won't hold up, as the tooling keeps getting harder to detect... Looking across the complete set of tabled propositions, proposal A (no LLM contributions to Debian via social contract) needs a 3:1 majority to pass; the other seven proposals (B to H) need a simple majority.

    Read more of this story at Slashdot.

    •  

    EmmaDE6 1.02 améliore encore l’accessibilité aux déficients visuels

    Ce 27 juillet 2026, le collectif Emmabuntüs vient d’annoncer la sortie de sa nouvelle version Emmabuntüs Debian Édition 6 1.02, basée sur la Debian 13.6 Trixie et supportant les deux environnements de bureau XFCE et LXQt.

    Première séance de formation au Centre  Polyvalent Saint-Augustin de Lomé, du 9 au 10 juillet 2026

    Rappelons que cette distribution est née au sein du Mouvement Emmaüs, pour faciliter le reconditionnement des ordinateurs donnés aux associations, notamment humanitaires, mais aussi pour favoriser la découverte de GNU/Linux par les débutants, tout en prolongeant la durée de vie du matériel informatique, ce qui réduit le gaspillage lié à la surconsommation de matière première.

    La nouvelle évolution de cette distribution concerne essentiellement des améliorations en matière d’accessibilité avec notamment un retour à la version stable d'Orca 48.1.1 ainsi qu’une meilleure prise en charge de la synthèse vocale Piper, ce qui améliore notablement le confort d’écoute du système.
    Cette distribution a été utilisée lors de la première séance de formation dispensée au Centre Polyvalent Saint-Augustin de Lomé, à l'intention des futurs référents représentant les 10 structures spécialisées pour les personnes déficientes visuelles du Togo.

    Pour mémoire ces actions se font en collaboration étroite avec l’A.S.I. YOVOTOGO qui prévoit aussi l’installation d’une première salle informatique au Cameroun, marquant une nouvelle étape dans l’expansion géographique de ses actions dans cette région d’Afrique.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    •  
    ❌