Live data from Hacker News

LLM Usage in Debian: Three Proposals

debian.org

121–130 of 228 posts

Re: LLM Usage in Debian: Three Proposals

#121

Debian should completely avoid AI slop. Let the Salesforces and the Atlassians of the world destroy themselves with poor quality vibecode driven teams. Using LLM to scan for security holes is another issue altogether.

Indeed it is, and it doesn't count as a "contribution" at all; the actual work is in fixing the CVE.

This is nonsense, the vast majority of critical CVEs are trivial to fix once you spot them. It's very rare that you have something like spectre where the solution is non-obvious: most of them are shit like "delete a `free`" or "put the `goto fail` in braces".

Re: LLM Usage in Debian: Three Proposals

#123

> 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.

The natural next argument that I see a lot is "well it's still all probabilistic", which is technically true. However, don't the atoms that make up the cells that make up a human move around and interact based on probabilities?

Saying a LLM is all just based on probabilities is pretty meaningless, even if it is true, since everything else is just based on probabilities too. What matters is the massive amount of machinery that generates those probabilities. Anything from rolling a dice to an accurate model of an entire human, or even a model of the entire universe, is all "just probabilities".

Re: LLM Usage in Debian: Three Proposals

#125
post #27
post #18

Don't misinterpret this link as representing a final decision. It's actually three separate proposals which will be debated and then voted on. Proposal A is "expressly forbid any contributions to Debian written with the use or assistance of large language models (LLMs) or other generative AI tools." Proposal B is "The Debian project allows AI-assisted contributions (partially or fully generated by an LLM), provided t…

Of the 3 proposals, the 2nd/B seems to be more of an “informed consent” model while the other two are seeking a comprehensive exclusion. I hope earnest dialogue and driving to a broad consensus among significant contributors is forthcoming. Notable are the endorsements, which are balanced over all three options, perhaps indicating only 1/3 are supportive of a more permissive position. If this represents core contribu…

[dead]

Re: LLM Usage in Debian: Three Proposals

#126

Earlier quoted context omitted.

I wonder how long software projects will even be able to ban LLM use in an age where exploits are found by LLMs. Like, if you have two forks of Debian and one uses LLMs to fix exploitable bugs and the other one doesn't, the level of security they can offer will be worlds apart. And noone in their right mind would want to use the less secure one. Similar to how noone would want to drive a car that was 100% hand built…

> I wonder how long software projects will even be able to ban LLM use in an age where exploits are found by LLMs. You can use an LLM to scan your human written code for exploits and patch the relevant ones yourself without any LLM code generation. An LLM is a tool, you can chose how you use it.

That's quite naive. We're looking at 50 years of legacy software running Unix/Linux environments. If the attacker with an LLM finds one in minutes it might take you hours to even comprehend the finding. Guess what the attacker with the LLM will do in that time?

Re: LLM Usage in Debian: Three Proposals

#127

Earlier quoted context omitted.

Indeed it is, and it doesn't count as a "contribution" at all; the actual work is in fixing the CVE.

This is nonsense, the vast majority of critical CVEs are trivial to fix once you spot them. It's very rare that you have something like spectre where the solution is non-obvious: most of them are shit like "delete a `free`" or "put the `goto fail` in braces".

It’s still not an LLM contribution in a meaningful sense. The contribution is the fix, no matter how trivial it is.

Re: LLM Usage in Debian: Three Proposals

#128

I suspect the debate shouldn't be LLMs or no LLMs, but rather what level of human accountability is required. We've accepted compilers, static analyzers, and code generators because the maintainer is still responsible for the final result. The interesting question is whether LLMs fundamentally change that responsibility, or just change the kinds of mistakes reviewers need to look for

Some of the reasons to ban LLMs are beyond what they do to code. I.e. environmental degradation, scraping without authorization, reduce human interaction etc. So I think banning them still makes sense.

All of which have been challenged though. As the stake is high, any such reason (for or against LLMs, to be fair) has to be backed with Wikipedia-level evidences at the very least.

Re: LLM Usage in Debian: Three Proposals

#129

This set of proposals, are (sorry) just stupid. It's like saying to someone, you are not allowed to saw wood using an electric saw, you must do it by hand. What are we doing here?! LLM(s) are just a tool. Use it as such. You should own the work anyway.

Yeah, I agree, it's really stupid. It's like discussing whether contributors are allowed to use google search, stackoverflow, an encyclopedia, etc.

Re: LLM Usage in Debian: Three Proposals

#130
post #117

Proposal A is the end of debian for non-english speakers. For those who don't speak english which is most of the world, using an LLM has become vital, because technical information is not available in their language or is extremely basic. Arch Linux is far more lenient with this.

This is a somewhat common talking point for supporting LLMs. What did non-English speakers do before LLMs?

They learned English or gave up.
Post reply on HN