Ricardo Wurmus <[email protected]> writes: > Hugo Buddelmeijer via "Development of GNU Guix and the GNU System > distribution." <[email protected]> writes: > >> Hi all, >> >> On 10/27/26 17:31, Ludovic Courtès wrote: >>> Andreas Enge <[email protected]> skribis: >>> >>>> On Tue, Oct 27, 2026 at 03:51:11PM +0100, Simon Tournier wrote: >>>> I am very hesitant about this splitting idea, at least until I see >>>> a >>>> working proposition. >>> Same here: experience with Guix-Science has shown that this is very >>> tricky. :-) >> There is a big difference when talking about LLM-assisted software: >> It >> will be trivial to fix breakages in a channel that itself allows >> LLM-assisted code. >> >> Maybe that is even a simple way out: people who like to write >> LLM-assisted code might actually prefer to have their package in a >> channel that can be maintained by an agent.
I've been thinking along these lines since I first noticed conflict about LLM assisted, and fully vibe-coded contributions, but didn't want to add to the noise. I'll try to chime in exactly once. Guix's core aim as a "free software project understood by humans" is in conflict with current AI workflows. The full source bootstrapping up to core libraries for a minimal machine must be understandable by people, and LLMs are so often used as a substitute for understanding. At the same time, completely closing off Guix to modern scientific advancements (LLMs) is short sighted. I personally enjoy hand-crafting my parentheses, but I have also seen non-technical users that are able to use their devices in ways we always dreamed of. Also, we have seen the news of blobs and drivers being reverse engineered with the help of LLMs, which the FSF lists as a "High Priority Project"[0]. > This could be our way out, but it also means that Guix needs to make > it even easier to deal with extra channels. So far adding a new > channel has always felt a little heavy. A few commands to manage > channels might lower the threshold. Recently we've got command line > options to fetch a channels file to pull from; working a little more > in that direction might make channels cheap enough to make it more > attractive to keep packages independent of the collection that's part > of Guix. You are thinking about it too much. The point is, development of core Guix should not be hindered by LLM assisted PRs and/or vibe-coded packages that encumber without adding enough value. Make the d*** LLM channel, and let them deal with making it work well. If they do something that is smart and good, humans can hand-craft a similar solution into Guix core, and the LLMs can readjust their approach if/when we do so in a way that conflicts. There are two reasons why Guix should have an official LLM-allowed (guix-contrib? guix-llm?) channel: - Guix has many orthogonal requirements as part of FSDG that are still valuable to users. - LLMs, despite their shortcomings, DO empower users to exert greater control of their devices. -Zacchae PS To be clear, I'm not making light of SaaSS "cloud" (i.e. someone else's computer) LLMs, just making points about the technology. Transitioning to free LLMs is critical[1], but less important than software freedom (in the same way we all use proprietary hardware). [0] https://www.fsf.org/campaigns/priority-projects/hardware-firmware-drivers [1] https://www.fsf.org/news/fsf-is-working-on-freedom-in-machine-learning-applications
