LLM Usage in Debian: Three Proposals
181–190 of 228 posts
Re: LLM Usage in Debian: Three Proposals
#182Earlier quoted context omitted.
There are a few of these "maintainer said no AI pulls, so we forked it" in the wild already and I am really interested to see how it all pans out. Like, okay, sure, maintainer says AI bug monitoring is cumbersome. One fork stops reading the AI bug monitoring, the other leans in. Isn't the latter more likely to find/fix critical/performance/security issues? >Similar to how noone would want to drive a car that was 100%…
I think the viability of the fork primarily depends on whether it has enough people motivated to maintain it long term. A turtle can win a distracted hare.
Re: LLM Usage in Debian: Three Proposals
#183Earlier quoted context omitted.
That's just it though. The tool(s) aren't necessarily defective. Just because you can chop off your own hand with an chainsaw or do a botch job of sawing a plank of wood because you weren't watching what you were doing with the electric saw, does not by itself make the tools (Chainsaw, Electric Saw) defective.
Or does it? https://youtu.be/gOReKxH5NlA?t=154 I agree "not by itself" was said, mostly your comment just made me think of this newer tech for table saws. And, made me think "when is a design inadequacy a defect"?
Interestingly there was a discussion here about exactly that a couple of years ago: https://news.ycombinator.com/item?id=39977058
Re: LLM Usage in Debian: Three Proposals
#184Earlier quoted context omitted.
Even if they wanted to forbid that, how would they even detect it?
Some people want to uphold the rule even if they can't be caught.
If Debian wants to make the LLM thing good, sue the providers for a billion or two for copyright violation, and join a class action to do some ASCAP style thing routing their money back to copyright holders. Separately, lobby to regulate data center build outs to include the solar and battery they need, and not be built in water stressed areas or near people who object. And understand the trillions thing is quite likely a dotcom style over investment and will vaporize in the next few years when all these pools of capital are either regulated or more likely off to ruin some other sector with too much money.
Re: LLM Usage in Debian: Three Proposals
#185Re: LLM Usage in Debian: Three Proposals
#186Earlier quoted context omitted.
No, but they are going to tell you what's acceptable if you want to contribute to their project, and kick you out if they find you broke the rules. Projects have always had their rules you had to follow if you wanted to participate.
I simply don't accept that this type of project rule has any validity. It's like telling me what editor I can use, or that I can't use Google to search for programming tips, or that I can only use an electric car to drive to the office.
Re: LLM Usage in Debian: Three Proposals
#187How can they even tell code was written by AI instead of a human?
> Other projects exploring similar decisions have elicited a common reply: "How will you enforce a ban on LLM contributions?" While enforcement could be a challenge, this is a statement of intent by the Debian community, and we trust this community to adhere to it in good faith.
Re: LLM Usage in Debian: Three Proposals
#188Re: LLM Usage in Debian: Three Proposals
#189I think that's an unfortunate framing & I think A would be the best option for the opposite reasons. If they go with Proposal A, people will absolutely use AI tooling to contribute to Debian. This might be in bad faith (unlikely but possible), but it will also be done in good faith through a number of avenues:
1. people having a saturation of LLM tooling integrated into their development environment to such an extent that it can't help touching everything they code - an infrequent Debian contributor is unlikely to change their entire dev setup, stripping out, turning off & limiting various ai tooling configs, just to comply with one project's social contract.
2. some people will mislead themselves by reframing the social contract's stated intent to suit their own world view. Maybe they'll subconsciously ignore the "or other generative AI tools" & just avoid direct chatbots, categorising some other LLM assistive tooling as out of the scope of the ban. Or perhaps they'll reframe it in terms of generation: using LLM agents to investigate, understand & guide them in their work while they actively type out each line of code committed (occasionally copypasting from an LLM response but never granting it repo write access): "This doesn't count, right?".
3. Some contributors might simply not read the social contract carefully enough, miss this line, & innocently forget to mention their LLM usage when pushing patches.
And ultimately, that's all ok. That's the reality of the world we live in: the social contract is ultimately "social", it's not intended to be strictly enforcable, it's a statement of intent aimed at a community who are assumed to be (& generally are) acting in good faith.
LLM tools are great - they open up amazing new horizons of what individual devs can achieve, which is positive for open source in particular. But they also come with an incredible upscaling of open source review burdens & I think anything "less" than Proposal A actively invites a tsunami of slop.
Re: LLM Usage in Debian: Three Proposals
#190> A LLM (...) merely produces syntactically likely combinations of the training data While doesn't matter much in the rest of the policy, this is a common misconception among AI skeptics. It is not the case for a long time (since RL is used heavily in the training) and a LLM may go beyond its training data.
Doesn't the LLM still output the next most probable token (modulus heat/desired variation) according to its model? Training shifts the probability - but doesn't change the fact that the output is a sampling based on input and the model?