Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLM Usage in Debian: Three Proposals

debian.org

Post reply on HN
Print view View original

161–170 of 228 posts

Re: LLM Usage in Debian: Three Proposals

#161

Post by mrtx01 »

goodmythical wrote: post #74
sigmoid10 wrote: post #68

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…

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%…

"maintainer said no AI pulls, so we forked it"

They should call it:

debAIn

Re: LLM Usage in Debian: Three Proposals

#162

Post by inigyou »

rcxdude wrote: post #137
aabhay wrote: post #17

Earlier quoted context omitted.

I think the questionable term is not “syntactically likely” but “merely”. Syntactical likeness is a vast solution space that encompasses the work of a terrible developer and a genius developer. In fact this solution space is a gap wide enough to encompass all coding knowledge and expertise.

"Combinations of the training data" is also hiding a pretty common and serious misconception about modern generative AI: this seems to come from a mental model that LLMs and image generators are merely producing a collage of sorts, especially that this is some way linked to specific parts of the training data as opposed to a generalized result of building up an understanding of how to produce a sentence, piece of cod…

That is how they feel when using them for code. It feels like they generate templates filled in with the details of a specific case.

Re: LLM Usage in Debian: Three Proposals

#163

Post by tomtomtom777 »

rlpb wrote: post #151
clcaev wrote: post #27

Earlier quoted context omitted.

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…

> Notable are the endorsements, which are balanced over all three options... I don't think this is notable. The process requires five seconders, so you're just seeing the set of people who seconded asynchronously before there were obviously enough that others didn't bother. The culture is to avoid unnecessary noise and leave it for the vote.

A bit of topic, but does the word "seconded" still work when five are required? Isn't there a more generic term?

Re: LLM Usage in Debian: Three Proposals

#165

Post by ptx »

mmooss wrote: post #118

From Proposal A: > LLM output has very unclear legal status: it may be possible to copyright on its own merits, or not; it may be affected by all of the licenses and copyrights in the training data, or not. Debian Policy and the DFSG require absolute clarity for licensing and copyright[1][2]. Software and other contributions written conventionally by humans with unclear copyright or license status are not allowed in…

Exactly. This is like proposing to solve memory safety by asking programmers to simply not make any mistakes. Simply specify that "the contributor should verify" that the code has no use after free, no out of bounds access, no undefined behavior, etc., for which they "assume full responsibility".

Re: LLM Usage in Debian: Three Proposals

#166

Post by fl0ki »

simonw wrote: 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…

Mr President, a 4th proposal has hit the General Resolution.

Re: LLM Usage in Debian: Three Proposals

#167

Post by [deleted] »

AlexeyBrin wrote: post #81
sigmoid10 wrote: post #68

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.

[deleted]

Re: LLM Usage in Debian: Three Proposals

#168

Post by Orphis »

mmooss wrote: post #118

From Proposal A: > LLM output has very unclear legal status: it may be possible to copyright on its own merits, or not; it may be affected by all of the licenses and copyrights in the training data, or not. Debian Policy and the DFSG require absolute clarity for licensing and copyright[1][2]. Software and other contributions written conventionally by humans with unclear copyright or license status are not allowed in…

At the same time, how can a human know if they accidentally rewrote exactly some code they read in the past from a codebase with an incompatible license?

Accidental copies happen all the time in code, music and art. Not all of it is necessarily super original, but that's beside the point and it happens.

So while we think we can hold AI tools to higher standards than humans, they are still modeled after human thinking and will make the same mistakes. Is this really the right thing to do and is it entirely practical?

Post reply on HN