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

211–220 of 228 posts

Re: LLM Usage in Debian: Three Proposals

#211

Post by bigstrat2003 »

simondotau wrote: post #176

Whatever the decision is today, it's going to become utterly moot within a decade or so. Think about how far we've come over the past three years. Programming with AI in ten years will be utterly unfathomable. It would be like showing Fable 5 to someone a decade ago. It will be unbelievable. In twenty years, programming by hand might be somewhat akin to writing assembly today: a skill that a limited number of program…

> Think about how far we've come over the past three years.

I do, and that's why I am pretty damn certain the future of programming doesn't involve LLMs. We still haven't really improved them, even with three years of pouring resources into doing so. The models of today are still as stupid and unreliable as the models of three years ago. Given we haven't made significant progress on that in three years, I don't expect we will get significant progress in the future either.

Re: LLM Usage in Debian: Three Proposals

#212

Post by bigstrat2003 »

tulio_ribeiro wrote: post #73

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

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

That's an absurd and entirely uncharitable interpretation. What it actually is, is developers recognize that LLMs suck at programming and don't want people using a tool which has proven to be so crappy.

Re: LLM Usage in Debian: Three Proposals

#213

Post by bigstrat2003 »

baggy_trough wrote: post #178
bigstrat2003 wrote: post #109

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

Well, you're wrong. Whether or not you are actually writing the code is well within their right to regulate. Using an LLM is no different than if you hired a guy to write code for you and contributed it under your name; they would probably explicitly ban that too if there were significant numbers of people doing it.

Re: LLM Usage in Debian: Three Proposals

#216

Post by baggy_trough »

bigstrat2003 wrote: post #213
baggy_trough wrote: post #178

Earlier quoted context omitted.

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.

Well, you're wrong. Whether or not you are actually writing the code is well within their right to regulate. Using an LLM is no different than if you hired a guy to write code for you and contributed it under your name; they would probably explicitly ban that too if there were significant numbers of people doing it.

It is quite different indeed. There are many ways to use an LLM. Blunderbuss approaches like this are wrongheaded and ignorant.

Re: LLM Usage in Debian: Three Proposals

#217

Post by josu »

e12e wrote: post #195
josu wrote: post #119

Earlier quoted context omitted.

The combination of the most probable tokens doesn't necessarily have to be in the training set, thus creating something completely novel.

If you shuffle a deck of cards, you likely have a novel sequence of cards. I'm not sure how that is relevant?

I was responding to this "merely produces syntactically likely combinations of the training data".

Re: LLM Usage in Debian: Three Proposals

#218

Post by e12e »

bob001 wrote: post #199
e12e wrote: post #194

Earlier quoted context omitted.

I think there are quite fundamental differences to the LLM model equivalent to an adult human mind and current LLMs (even accepting an LLM can model a human brain, which I don't think is a given - but I also don't think it's impossible). The details matter (training set, full context). I doubt our current LLMs knows what smelling cut grass on a wet morning feels like, or how the stomach flutters on a first kiss - eve…

>The details matter (training set, full context). But you said: >Training shifts the probability - but doesn't change the fact that the output is a sampling based on input and the model? So which is it? >You're essentially suggesting we play Turing's Guessing Game; if your LLM can guess my response to any prompt - then it can be said to have modeled how I would reply to those prompts. Expand the prompts far enough, a…

> I'm merely noting that your argument that "training+input=>output is the problem" applies to humans.

I'm not sure I ever said that it was a problem.

I also never meant to say that sampling across the model (formed by training) based on input couldn't produce novel token sequences.

As for human vs LLM - my argument would be that while trained on a large corpus, the models are poor in experience and "sensory input" - their training so different from growing up - that even if we could model humans as LLMs - the gap between current LLMs and "human" LLMs remain a wide one.

More to the point - I believe the current generation of LLMs are way too sensitive to input (prompt, system prompt, context/RAG) - precisely because they're still too narrowly trained, and also aligned to weigh input heavily.

What we have today are models that work well with language (generate, transform, translate) - not so great on complex tasks - because they're still generating next probable token.

Re: LLM Usage in Debian: Three Proposals

#219

Post by simondotau »

bigstrat2003 wrote: post #211
simondotau wrote: post #176

Whatever the decision is today, it's going to become utterly moot within a decade or so. Think about how far we've come over the past three years. Programming with AI in ten years will be utterly unfathomable. It would be like showing Fable 5 to someone a decade ago. It will be unbelievable. In twenty years, programming by hand might be somewhat akin to writing assembly today: a skill that a limited number of program…

> Think about how far we've come over the past three years. I do, and that's why I am pretty damn certain the future of programming doesn't involve LLMs. We still haven't really improved them, even with three years of pouring resources into doing so. The models of today are still as stupid and unreliable as the models of three years ago. Given we haven't made significant progress on that in three years, I don't expec…

You are saying that LLMs have not meaningfully improved since 2023? If you want me to take that claim seriously, you will need to do more than merely assert it. I am not a mind-reader.

My current working theory for the seemingly irreconcilable differences between programmers' experiences with LLMs is grounded in their ability and willingness to explain what they want in sufficient detail. AI is not a mind-reader.

Re: LLM Usage in Debian: Three Proposals

#220

Post by DaSHacka »

setopt wrote: post #205
goodmythical wrote: post #74

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

> 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. There are also forks that go in the other direction, i.e. forking to avoid AI contributions upstream: https://drewdevault.com/blog/Forking-vim/ And promises to do so if it becomes necessary: https://human-emacs.org/ Will indeed be interesting to see how it all pans out.

It's already been quite interesting to witness the birth of the 'Digital Amish' throughout the past few years.
Post reply on HN