Ian Eure <[email protected]> writes: > There are two issues: > > - Should Guix allow contributions including LLM output?
no. they should be explicitly forbidden with strong language about the many, many harms of llms. i know that's not this conversation, but i want to make my position clear: i think llms are currently a fractal of social ills. it astounds me how i can just keep scratching at them and find more things they're hurting. i am lumping the tech in with the corporations that train it and are its primary purveyors, as they're currently inseparable. the few things of positive social value that come out of them, and there are precious few, come attached, concomitantly, with the outrageous harms of the technology, and thus even these uses are much graver ills than benefits and should be avoided. i wish this technology would go away, almost as much as i wish the atom bomb would go away. that isn't going to happen without a fight, and i think we should fight it at every possible avenue that might be reasonably constructive to the cause. i hope i've made my position clear, because, with that all said: > - Should Guix label software it packages as containing LLM output? i don't think it should. i, and i'm sure many others, would get a benefit out of knowing which software was llm produced and by how much, such that we can take appropriate steps. however, the burden of providing that information just seems to me to be to great. when it comes to licenses, it's fairly easy to track that down almost all of the time, and we can mandate that the field is provided. it's far, far more difficult to know whether or not a project has used llms in some capacity, and, imho, beyond the scope of guix (there are other projects that are attempting to do this, with limited success, which would be better served through tracking this down). i think that's an undue burden on patch submitters. then there's the issue of tainting. the unfortunate fact is that, unlike a license, which can easily be understood and quarantined (at least legally), the concerns i have with llms aren't legal in nature, but ethical and, more pragmatically, about the quality of llm code. ethics and quality can't be contained so easily. bad dependencies leak into good downstream projects. so, from my perspective, an llm flag without tainting isn't particularly useful. that means there's stuff in guix proper we have to code up, and deal with sequela: linux is tainted, we need linux, now we need an opt-in/out mechanism. i'm sure there are even more concerns that spiral out of here that i just haven't thought of yet. that seems like an undue burden on guix maintainers for marginal benefit. so, while i wish this were an avenue to practically fight down to make some progress against the vastly-numbered-heads of the llm hydra, i don't think it is and that energy would be better spent elsewhere on fighting it. it might be better to include a tool akin to ‘guix lint’ that can cross-check a package and its dependencies against slopware lists (default and user-configurable)? thought i strongly suspect we don't have enough volunteers to make this a reality, i would even potentially support a guix-hosted slopware list, as long as it was kept isolated from package definitions themselves. -bjc
