Debian and the sirens
45 points by danlamanna
45 points by danlamanna
If they succeeed, Debian will become dependent on proprietary software for development
There is nothing I see in the resolution about proprietary software? For most of the tasks I expect to be relevant in Debian (packaging, tooling) local free models have been plenty good for quite some time, for example
local free models
Open-weight models are not at all free according to Debian’s definition.
I've been thinking back and forth about this question, and about the GPL definition of source code as the "preferred form of the work for making modifications to it."
And I'm pretty sure that when and if I modify an open weight LLM that I don't actually have the ability to use the raw data used as input to pre-training. It's getting somewhere close to 40-400TB these days even for smaller models. But more importantly, no end user has access to the millions or tens of millions of dollars of compute required to do anything with the raw pre-training data. If I'm going to modify a model, I'm going to start in one of two places:
So, no, I don't really think open weights technically meet the DFSG. But weights aren't software, any more than microprocessors are software. Models are some other kind of thing that are going to need their own definitions and rules. The term "open weights" seems to accurately communicate the idea that I can download them, fine tune them, remove political censorship from them, etc. We will presumably want some more terms for open training data, open base models, etc.
Interestingly, it is feasible to train from scratch a GPT 2.0-like chat model these days for around $50-100 worth of compute time, including some rudimentary chat training. See the Nanochat project for details.
In the case of PNG files created from SVG, debian asks for the SVG source (and converter). Models don't seem very different.
I'm trying hard not to think of the results today as having lost a child, though I spent 18 years helping Debian grow up.
ok, no. if you really wanna go with the child analogy, you got divorced and moved out as soon as the last child turned 18 because you got tired of not being able to control them. years later, after not really being a part of their life, you heard they made some life choice you disagree with (coming out as queer, marrying someone you don’t like, whatever) and have decided to feel like they are dead despite the fact they’re very much alive.
That quote is missing some preceding context:
I lost a parent yesterday, and I'm trying hard not to think of the results today as having lost a child…
In general, I don't recommend getting one's identity wrapped up in things or people, nor do I care for over-dramatization. But considering his dad just died, I can understand why he would reach for a death analogy.
What LLMs in Debian development will do, I fear, is eliminate any incentive to scrap boilerplate or reform policies that require a lot of other senseless human effort. If I had had access to LLMs 30 years ago, I might have just had them generate the rules files, replate with complexity. So they will make Debian even more firmly what it is, and ever less likely to explore what it could become.
What a weirdly pessimistic take. LLMs make boilerplate less painful, so Debian is less likely to take steps to remove boilerplate.
Alternative possibility: LLMs make identifying and building tools to remove boilerplate easier, so Debian is more likely to take those steps in the future.
A realistic take because what's preventing boilerplate elimination in Debian isn't technical. Reducing the labor to generate incidental complexity will only entrench political resistance to change to improve the conditions. Even in a weirdly LLM-maximalist take, how on earth are LLMs supposed to solve this? Pointing out how LLMs can cause problems doesn't make the take pessimistic. Or weird.
A realistic take because what's preventing boilerplate elimination in Debian isn't technical.
I recall this post (from 2019!) looking at the different Debian build helpers, and it notes:
Now of course, that remaining 15% of debhelper/cdbs (or just 7% of cdbs, depending on how pedantic you are) will be the hard part to transition. Notice how the 1% of "other" packages hasn't really moved in the last four years: that's because some packages in Debian are old, abandoned, ignored, complicated, or all of the above. So it will be difficult to convert the remaining packages and finalize this great unification Joey (unknowingly) started ten years ago, as the remaining packages are probably the hard, messy, old ones no want wants to fix because, well, "they're not broken so don't fix it".
This is the sort of thing LLMs can do well: small scope; large corpus of good examples; complete information.
dh
dh changes. Dive into awkward perl/Makefiles.Fan-out to many packages.
I mostly use cheap models like DeepSeek v4 Flash, but even that can do this style of work.
Seems just very literal and plain-spokenly true to me, if uncomfortable. All the evidence I've seen backs it up.
As usual, I'm biased by the LLM-users take on IDEs. Where I see the possibility to massively slash the complexity of an IDE by eliminating layers and layers of historical debt, they just want to build layers and layers on top of historical debt.
Not weird at all, people often follow a path of least resistance especially under time constraints. I literally saw when instead of solving the problem once and for all, the "skill" was introduced to "solve" it for 50 cents or so every time.
Joey created debhelper which is new the most used packaging tool for debian and removed a lot of boilerplate in debian scripts. He has already done the technical side and also a lot on the social side.
For the rest, ~pmbauer already mentioned that the rest isn't technical (see everythibg around tag2upload).