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

71–80 of 228 posts

Re: LLM Usage in Debian: Three Proposals

#71

Post by mappu »

prologic wrote: post #20

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.

Linus Torvalds said last week that LLMs were just a tool. Lorenzo Stoakes had the impeccable rebuttal that "it's a tool in the same way a nuclear bomb is just a tool" - of course it's useful but there is clearly more to it than that.

I'm happy for Debian to at least consider the other aspects of social impact, ethics, copyright, and maintainability.

Re: LLM Usage in Debian: Three Proposals

#72

Post by preg_match »

Meneth wrote: post #36

Gentoo chose to ban LLMs two years ago. They seem to be doing well.

Yes for gentoo and their users it makes sense. Debian is much, much larger and is used pretty extensively in enterprises.

The biggest question, I think, is: does a complete LLM ban interfere with, or slow down, security patches? I think it could, as LLMs are used a lot for vulnerability discovery.

Re: LLM Usage in Debian: Three Proposals

#73

Post by tulio_ribeiro »

The whole anti-LLM crusade feels like developers trying to gatekeep their own relevance. They know the tool can automate parts if not all of what gave them status, so instead of adapting, they want to declare its use illegitimate and keep themselves as mandatory middlemen. Which is already ironic enough. If Proposal A passes and is somehow enforceable, every distro that embraces AI while Debian moralizes about it will lap them within a few years. You do not stop technological displacement by banning the tools everyone else is using. You just volunteer to be displaced first.

Elementary, Redox and Gentoo already banned it. Nix and Fedora allow it with disclosure. Now Debian and Arch are debating whether to adapt or seal their fate alongside Gentoo. Nix and Fedora got it right. Debian and Arch are deciding whether they want to remain relevant or fade into irrelevance.

Re: LLM Usage in Debian: Three Proposals

#74

Post by goodmythical »

sigmoid10 wrote: post #68
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…

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% hand built by humans

Though, of course, this highlights that the market will fragment itself given that there are in fact many humans who will outright refuse machine driven cars despite mounting evidence that they are vastly safer and more efficient in a growing number of situations.

We'll likely see both "individual who won't use AI assisted software gets hacked" and "individual who won't get in a robo-taxi kills jay-walker in broad daylight"

Re: LLM Usage in Debian: Three Proposals

#75

Post by runarberg »

tulio_ribeiro wrote: post #64
runarberg wrote: post #58

Earlier quoted context omitted.

I assume RL stands for reinforcement learning, which just means that the weights are adjusted by evaluating some loss function. If the loss function uses the training data (i.e. supervised learning) then the original assumption still holds. So I fail to see how this is a misconception.

Supervised learning and reinforcement learning are mathematically distinct. Supervised pre-training as you said maximizes the likelihood of a token sequence. RL optimizes a policy against an external reward signal or execution environment. For example, RL evaluates code against runtime execution/unit tests/proof checkers (e.g lean). Models learn new strategies and are able to produce novel code if trained in an RL en…

I don‘t understand what you mean. Supervised learning is reinforcement learning, while not all reinforcement learning is supervised learning (e.g unsupervised learning is also reinforcement learning; i.e. reinforcement learning with unlabelled data).

Like you said, you can have reinforcement learning which doesn’t use training data. But that is not what my parent said. What they said is: since RL is used heavily in the training. And since reinforcement learning is a broad category which includes supervised learning, nothing in their logic disproves the strawman they created from an AI skeptic.

Re: LLM Usage in Debian: Three Proposals

#76

Post by preg_match »

aabhay wrote: post #24
TZubiri wrote: post #5

Interesting that this makes no distinction from using LLM output and using LLM assistance. An overly strict policy is better than no policy, but I wonder if using llm for conversation and analysis, but not code/config generation, was discussed.

I’m curious what makes you believe that this distinction is precise or meaningful. What exactly is the difference?

The difference is LLMs are extremely good at analyzing code under the careful hand of an engineer. This is how most vulnerabilities are found now.

Prohibiting that might mean that security falls off.

And, if the concern is code quality, then everything before the code writing shouldn’t matter. A good engineer using an LLM for analysis and then writing a patch by-hand might create a better patch.

Re: LLM Usage in Debian: Three Proposals

#77

Post by runarberg »

prologic wrote: post #62
sanxiyn wrote: post #23

Earlier quoted context omitted.

It's more like: food processing tool A is known to be defective. We ask employees of this restaurant and supply chains to avoid food processing tool A. This seems eminently reasonable. The question is whether the tool is in fact defective.

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.

The tool makes the food taste bad in ... say ... 20% of the cases, and in 5% of the cases it contaminates the food with salmonella.

Yes you can have the chefs taste the food before serving, and test it for salmonella. But it would be completely reasonable for a regulator to ban such a tool, and even more reasonable for restaurants to have a strict policy against using this tool.

Re: LLM Usage in Debian: Three Proposals

#78

Post by prologic »

runarberg wrote: post #77
prologic wrote: post #62

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

The tool makes the food taste bad in ... say ... 20% of the cases, and in 5% of the cases it contaminates the food with salmonella. Yes you can have the chefs taste the food before serving, and test it for salmonella. But it would be completely reasonable for a regulator to ban such a tool, and even more reasonable for restaurants to have a strict policy against using this tool.

You may as well ban every technological advancement in society then. There are risks to everything we do, build and support. Ban 'em all! Let's go back to the dark ages where everything is safe!

Re: LLM Usage in Debian: Three Proposals

#79

Post by runarberg »

atherton94027 wrote: post #61
runarberg wrote: post #58

Earlier quoted context omitted.

I assume RL stands for reinforcement learning, which just means that the weights are adjusted by evaluating some loss function. If the loss function uses the training data (i.e. supervised learning) then the original assumption still holds. So I fail to see how this is a misconception.

I think OP might be referring to synthetic data, which is now used to provide more data for training?

That would makes sense. This is how AlphaGo became better then the training data, and was the basis for Alpha Zero which used no human data and became even better.

However the loss function (or the success criteria more broadly) for the game of go is extremely simple. We do not know whether such a success criteria even exists for a generic task like coding, and it is a mistake to assume that the AI labs have found one.

Re: LLM Usage in Debian: Three Proposals

#80

Post by mmwelt »

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…

There is also proposal D right at the bottom, which is "Accept AI contributions for Debian specific work".
Post reply on HN