Given how Debian went for a both-sides approach when it came to systemd, which is now a de facto hard requirement even if Debian technically supports other init systems, one doesn't need a crystal ball to know how this vote will play out.
@pndc I also assume the ban will happen. But I give that ban one year. Then it will be released again. Because the ban will not solve the quality problems.
The true problem is that tests have no real Meaning anymore, if LLMs can modify them. Tests coild to be separate repositories, which cannot be touched vy everyone. Or we could invent tools which check the grade of code modifications?
@pndc A tool like a linter which detects LLM code smells could be introduced. Which checks if SOLID and DRY was violated badly. This can never be perfect. But why can’t we find a way to automatically scan code upfront with abstract constraints.
Even humans can write really ugly code. Gosh, how often have I seen ugly code of beginners.
There must be a scientific way of maintaining the quality. Instead of „politics“ and „feelings“.
I am asking myself what happens to the past LLM contribs. And cintribs which indirectly contain LLM code.
I personally find this debate hysteric. Because people will silently use offline LLMs for this and that and lie about the usage.
From my point of view the new situation is asking on how to do quality management in future. It’s asking about us needing new tools for admins. Better classifiers. Code Quality Scores.
How do you want guarantee a ban? This is just theory.
One day we will wake up and NOTHING will work anymore.
NOTHING.
but all the poor countries - the 'shithole' countries? - yeah, they will just continue to bring and sell and buy food at the local market, and ride their bikes back to their casa, and cook on their woodstove, after getting water from the well.
What I hate about this movement is: no one explains how you detect it? What about false positives?
I once contributed to OSS. My pull request was rejected. Because it had the „feeling“ of LLM. That feeling was me summarizing all changes of mine and a file listing. I wanted to safe the maintainers time. And exactly this „service“ was treated as „feeling“ like LLM made.
This is ridiculous. You work for days. And then people fuck you because they have a „feeling“.
Who said you have to detect it? Did anyone propose automatic detection, because I did not see that.
You set a rule, and if you find someone did not follow the rule, you ban them forever. It is quite simple. There is no need for detection: nobody wants liars.
@jackpearse You are focusing on an implementation detail and not the purpose of the rule.
If it's fake, a fake person or some fake code, it will reveal itself. You don't need to test for it.
"So, John Smith, how does this patch work?"
(10 pages of markdown formatted wibble follows which doesn't answer the question.)
Or there's a bot config file. Or a credit line. Or it's a 200 line diff that changes 1 operator.
Bosh. Bot slop. Goodbye, "Mr Smith."
It's like the joke: "how do you spot a vegan?"
Answer: you don't. There's no need. They'll tell you.
In this case they will angrily complain, giving themselves away. Then they will stomp off and prompt the bot to create an entire distro, which they will never maintain because they don't know how.
It doesn't matter. You don't need to be able to test for it. Either they bitch about it (result, ban) or they cheat (ban) or they tell you (ban) or the bot tells you (ban).
But it is already like this. For me this ban is hysterical.
The OSS Community is popular for being very gate keeping. Never explaing stuff when people ask. Behaving elitarian to people who are new to i.e. linux.
From my perspektive of more than 30 years of IT experience, AI is just an amplifier of processes which already started with „python“ and „full stack development“.
And the „ban“ tells a story. It amplifies „gate keeping“.
I already addressed the points. Which you call „anger“.
This „ban“ is just tagging. And it sees a Problem like LLM. My point is: Not LLM is the issue but the culture. AI amplified it. And this ban makes it worse.
If you need to trust your team. Then you need to know your team. If you know your team, bans are obsolete.
If you don’t know the team, you need tools to detect bad members.
But everything is said now. Open Source is split into two camps now. And that is sad.
We habe the same stupid procedures in the demoscene. You now have to sign „I have not used AI“ before uploading the contribution to the compo. How stupid is that? They added a layer of bureaucracy. WHY?
Instead of simply uploading shit without singning stuff. Since 1995 I am building software. And I have seen a lot of shit since the 1990ies. But never ever have I seen that IT became like politics.
From my personal perspective, the problem isn't the code. It's this debate.
The real problem is „bullshit“ code. And instead of banning a particular Algorithm, I would go and search for ways to maintain code quality. At work I have seen truly ugly code, made by people. This is also a problem. The more coders participate the more helper functions appear. Also people produce Slop.
This could be a once in a lifetime chance to really advance IT quality management by improving code quality tools.
I am proposing automatic detection instead of a written „ban“. Just adding „this is banned“ will change nothing.
This is like trying to change climate change by apllying the rule where the caps on plastic bottles can no longer be removed.
The real problem isn‘t LLM. Microsoft owns github and is the bigest stakeholder of AI corporations. AI is indirectly the biggest OSS sponsor. (Like PostreSQL). The largest FOSS sponsors are AI-Corporations. Copilot is default in github.
@jackpearse The problem isn't with the movement but the tech, LLMs cut everyone regardless of their contact with it so your aggrievement is with the LLMs making your work suspect.
@ferrix @joe Apart from Alpine, Arch, Chimera Linux, Mageia, OpenMandriva, Slackware, PCLinuxOS, and dozens of others not based on Debian, plus the SUSE and Red Hat families, you mean?
Learn how Red Hat is using AI to address concerns in open source communities and improve development lives. Discover principles for AI adoption and real-world examples.
@Arthfach @ferrix @joe Genuinely wish Gentoo would fork the Linux kernel (though I'm fully aware they don't have anywhere near enough resources to even consider it)
@Cal @arthfach @ferrix you can install Debian on a FreeBSD kernel using its Linux emulation and the debootstrap port. Depending on how much Linuxisms gentoo needs to bootstrap, might be possible to do something similar
FreeBSD can already run Docker containers. It's run Linux binaries for years. It only needs a little more wiring up of the bits that are already there to make it a single-click operation to just run one of the containerised Linux app formats (AppImage, Snap, Flatpak or something).
@joe @Arthfach @ferrix What's the modern gaming experience like on FreeBSD in practice? I'm on mobile data right now but if it plays current games eg via Wine/Proton reasonably well on capable hardware, I may jump ship.
No idea. I don't play video games. I suspect it's probably awful. It's barely usable as a GUI desktop OS with a ton of manual work, and it is poor at dual-booting.
@Cal @arthfach @ferrix my experience aligns with Liam’s that convincing FreeBSD to do desktop stuff is a very manual process still. that said, it uses the exact same drm drivers for Intel and AMD GPUs as Linux (albeit a few versions back), and ports contains a launcher for steam, so it’s possible. Depends on how aggressively proton and friends use cutting edge Linux kernel features that FreeBSD’s compatibility layer doesn’t emulate
debian has a ban on contributions in general, I have a few cool little command line utilities and programs I wanted to contribute and found out it would take a 3 year certification process where I had to travel around the world exchanging usb keys to be allowed to and would only succeed if , after it all, one of them was willing to 'bless' me.
I honestly have no idea how ANY of the packages in debian got there, but I can TOTALLY understand when projects host there own packages.
@RueNahcMohr Well, some of us (being a Debian Developer myself) managed... It requires commitment, but outcome is really worth it: a worldwide group of very committed Free Software enthusiasts.
@RueNahcMohr The trouble with LLM code in a project like debian is simple, deep, and obvious.
If someone is using an LLM instead of learning, providing official feedback to the LLM instead of growing, and providing the LLM's reply to the feedback instead of engaging...
You're not training the next generation of developers. You're training a model.
@Longplay_Games @RueNahcMohr you are missing the fact, that when learning yourself, tradcoding, expanding understanding, you also contribute to llms, even more i would say: your output is a compost for them and it makes them stronger. no license or ban will prevent it. until it's acked, there can't be an effective solution. and solution will be much more radical than Stallman was in the 80ties, i predict.
in case somebody is reading this and wondering, the process to start contributing packaging work to Debian is more or less:
* at first you need to do some work, submit it to mentors (a platform and a mailing list) and get a Debian developer to vet it: this can be quite easy or quite hard, depending on how niche what you're working on is: finding a volunteer that feels confident working on a python module with common applications is much easier than finding one for something written in a niche language that is only relevant for a few people. There may be a bit of back and forth requiring changes to the package: Debian covers a number of non-obvious usecases, and providing packages for that requires more nuances than building a package that just works on one computer.
* continue working on it in time: maintaining a package is a long term commitment, not something that works well with hit and run contributions. While doing so you're likely to establish a working relationship with one or more DDs.
* this is where being able to travel (or living in Germany :D ) helps: then you need to connect your contributions to a GPG (not USB) key and long-term identity: the easiest way is to meet one or more Debian developers in person, chat a bit, and exchange cryptographic signatures on that key, but since 2020-ish (for obvious reasons) there is at least one alternate procedure where meeting is optional. Having the same name on the GPG key and a government issued ID makes the process easier, but is not mandatory either.
* once you have both an history of contributions and a signature you may be given permission to upload a small number of packages without supervision (Debian Maintainer)
* and after some time as a Debian Maintainer you may, after a bit of exam, become Debian Developer and get permission to upload anything, voting rights, and everything.
Honestly 3 years between the first contribution and becoming DDs sounds even a short time, unless somebody has a *lot* of time to contribute, but it's not like your contributions aren't getting into Debian during that time, they only need an extra step or a few because they have to be supervised.
(Also, if your contributions aren't packaging related the process is different, and depends on what they contributions are related to. And there is a way for people to get voting (but not uplading) rights without ever having to learn how to package, if they are contributing in different areas.)
@valhalla I'm not socially popular, rolled really low on charisma, so my whole train abruptly ends at 'mentors' and doesn't even get to platforms or mailing lists (haha)
@RueNahcMohr I have contributed several things to Debian without becoming a Debian Maintainer or Developer. It really doesn't require any of the things mentioned.
in case somebody is reading this and wondering, the process to start contributing packaging work to Debian is more or less:
* at first you need to do some work, submit it to mentors (a platform and a mailing list) and get a Debian developer to vet it: this can be quite easy or quite hard, depending on how niche what you're working on is: finding a volunteer that feels confident working on a python module with common applications is much easier than finding one for something written in a niche language that is only relevant for a few people. There may be a bit of back and forth requiring changes to the package: Debian covers a number of non-obvious usecases, and providing packages for that requires more nuances than building a package that just works on one computer.
* continue working on it in time: maintaining a package is a long term commitment, not something that works well with hit and run contributions. While doing so you're likely to establish a working relationship with one or more DDs.
* this is where being able to travel (or living in Germany :D ) helps: then you need to connect your contributions to a GPG (not USB) key and long-term identity: the easiest way is to meet one or more Debian developers in person, chat a bit, and exchange cryptographic signatures on that key, but since 2020-ish (for obvious reasons) there is at least one alternate procedure where meeting is optional. Having the same name on the GPG key and a government issued ID makes the process easier, but is not mandatory either.
* once you have both an history of contributions and a signature you may be given permission to upload a small number of packages without supervision (Debian Maintainer)
* and after some time as a Debian Maintainer you may, after a bit of exam, become Debian Developer and get permission to upload anything, voting rights, and everything.
Honestly 3 years between the first contribution and becoming DDs sounds even a short time, unless somebody has a *lot* of time to contribute, but it's not like your contributions aren't getting into Debian during that time, they only need an extra step or a few because they have to be supervised.
(Also, if your contributions aren't packaging related the process is different, and depends on what they contributions are related to. And there is a way for people to get voting (but not uplading) rights without ever having to learn how to package, if they are contributing in different areas.)
@dos no no, I was just told that was all gibberish folklore. and I dont think people socially hype-up a package and create a ruccas about it on *mailing lists* to get it inducted into debian.
Questo sito utilizza cookie per riconosce gli utenti loggati e quelli che tornano a visitare. Proseguendo la navigazione su questo sito, accetti l'utilizzo di questi cookie.
@pndc
in reply to Liam Proven • • •JackPearse
in reply to @pndc • • •@pndc
I also assume the ban will happen. But I give that ban one year. Then it will be released again. Because the ban will not solve the quality problems.
The true problem is that tests have no real
Meaning anymore, if LLMs can modify them. Tests coild to be separate repositories, which cannot be touched vy everyone. Or we could invent tools which check the grade of code modifications?
Resuna
in reply to @pndc • • •The Poeterring Window.
JackPearse
in reply to @pndc • • •@pndc
A tool like a linter which detects LLM code smells could be introduced. Which checks if SOLID and DRY was violated badly. This can never be perfect. But why can’t we find a way to automatically scan code upfront with abstract constraints.
Even humans can write really ugly code. Gosh, how often have I seen ugly code of beginners.
There must be a scientific way of maintaining the quality. Instead of „politics“ and „feelings“.
muddle 🥣
in reply to JackPearse • • •YourShadowDani
in reply to Liam Proven • • •JackPearse
in reply to Liam Proven • • •I am asking myself what happens to the past LLM contribs. And cintribs which indirectly contain LLM code.
I personally find this debate hysteric. Because people will silently use offline LLMs for this and that and lie about the usage.
From my point of view the new situation is asking on how to do quality management in future. It’s asking about us needing new tools for admins. Better classifiers. Code Quality Scores.
How do you want guarantee a ban? This is just theory.
Peachy Fae
in reply to JackPearse • • •JackPearse
in reply to Liam Proven • • •This ballot taks about a ban of LLM code if detected.
So my question is: how is it detected?
For me this is the most important question of all.
@pndc
in reply to JackPearse • • •JackPearse
in reply to Liam Proven • • •So please guy‘s, just answer this question to me:
I provide a pull request. And I guarantee it was hand made.
How do you approve it was not LLM made. Please. How?
brainwashed by lentils
in reply to JackPearse • • •@jackpearse trust.
it's the same in many situations, like when you ask whether food or drink is vegan.
of course some asshole can lie — »yes« — and use a cow's breast milk instead of oat in the coffee.
then, if you find out they're lying, you out them and eject them.
letting people know that a harmful behaviour is not welcome goes a long way.
Sassinake! ᑐ ∪ ∩ ⊂
in reply to Liam Proven • • •One day we will wake up and NOTHING will work anymore.
NOTHING.
but all the poor countries - the 'shithole' countries? - yeah, they will just continue to bring and sell and buy food at the local market, and ride their bikes back to their casa, and cook on their woodstove, after getting water from the well.
but we will all die within a week.
JackPearse
in reply to Liam Proven • • •What I hate about this movement is: no one explains how you detect it? What about false positives?
I once contributed to OSS. My pull request was rejected. Because it had the „feeling“ of LLM. That feeling was me summarizing all changes of mine and a file listing. I wanted to safe the maintainers time. And exactly this „service“ was treated as „feeling“ like LLM made.
This is ridiculous. You work for days. And then people fuck you because they have a „feeling“.
Liam Proven
in reply to JackPearse • • •@jackpearse
Who said you have to detect it? Did anyone propose automatic detection, because I did not see that.
You set a rule, and if you find someone did not follow the rule, you ban them forever. It is quite simple. There is no need for detection: nobody wants liars.
JackPearse
in reply to Liam Proven • • •But THAT is the issue. „You find someone did nor follow the rule“
HOW?
I have seen excellent LLM code. And I have seen ugly humand made code. And the ither way around.
How can you speak out a ban without telling how to control it?
This is what I am talking about. Anyways. I think this „so called“ ban will nit last for long. It’s missing a lot of issues in reality.
Liam Proven
in reply to JackPearse • • •@jackpearse You are focusing on an implementation detail and not the purpose of the rule.
If it's fake, a fake person or some fake code, it will reveal itself. You don't need to test for it.
"So, John Smith, how does this patch work?"
(10 pages of markdown formatted wibble follows which doesn't answer the question.)
Or there's a bot config file. Or a credit line. Or it's a 200 line diff that changes 1 operator.
Bosh. Bot slop. Goodbye, "Mr Smith."
It's like the joke: "how do you spot a vegan?"
Answer: you don't. There's no need. They'll tell you.
In this case they will angrily complain, giving themselves away. Then they will stomp off and prompt the bot to create an entire distro, which they will never maintain because they don't know how.
It doesn't matter. You don't need to be able to test for it. Either they bitch about it (result, ban) or they cheat (ban) or they tell you (ban) or the bot tells you (ban).
JackPearse
in reply to Liam Proven • • •But it is already like this.
For me this ban is hysterical.
The OSS Community is popular for being very gate keeping. Never explaing stuff when people ask. Behaving elitarian to people who are new to i.e. linux.
From my perspektive of more than 30 years of IT experience, AI is just an amplifier of processes which already started with „python“ and „full stack development“.
And the „ban“ tells a story. It amplifies „gate keeping“.
This ban will make OSS fall back.
Liam Proven
in reply to JackPearse • • •JackPearse
in reply to Liam Proven • • •I already addressed the points. Which you call „anger“.
This „ban“ is just tagging. And it sees a Problem like LLM. My point is: Not LLM is the issue but the culture. AI amplified it. And this ban makes it worse.
If you need to trust your team. Then you need to know your team. If you know your team, bans are obsolete.
If you don’t know the team, you need tools to detect bad members.
But everything is said now. Open Source is split into two camps now. And that is sad.
JackPearse
in reply to Liam Proven • • •We habe the same stupid procedures in the demoscene. You now have to sign „I have not used AI“ before uploading the contribution to the compo. How stupid is that? They added a layer of bureaucracy. WHY?
Instead of simply uploading shit without singning stuff. Since 1995 I am building software. And I have seen a lot of shit since the 1990ies. But never ever have I seen that IT became like politics.
From my personal perspective, the problem isn't the code. It's this debate.
JackPearse
in reply to Liam Proven • • •The real problem is „bullshit“ code. And instead of banning a particular Algorithm, I would go and search for ways to maintain code quality. At work I have seen truly ugly code, made by people. This is also a problem. The more coders participate the more helper functions appear. Also people produce Slop.
This could be a once in a lifetime chance to really advance IT quality management by improving code quality tools.
Instead we are closing borders.
JackPearse
in reply to Liam Proven • • •I am proposing automatic detection instead of a written „ban“. Just adding „this is banned“ will change nothing.
This is like trying to change climate change by apllying the rule where the caps on plastic bottles can no longer be removed.
The real problem isn‘t LLM. Microsoft owns github and is the bigest stakeholder of AI corporations. AI is indirectly the biggest OSS sponsor. (Like PostreSQL). The largest FOSS sponsors are AI-Corporations. Copilot is default in github.
Liam Proven
in reply to JackPearse • • •@jackpearse As far as I can see, no, you aren't. You are saying it won't work.
But nobody proposed it.
I see no need for it, as I've already explained. You have not answered my points at all.
Nini
in reply to JackPearse • • •Angela Scholder
in reply to Liam Proven • • •Greg Bell
in reply to Liam Proven • • •Liam Proven
in reply to Greg Bell • • •Longplay Games
in reply to Liam Proven • • •redhat.com/en/about/press-rele…
redhat.com/en/blog/acceleratin…
"Red Hat believes that AI offers tremendous opportunities for open source projects and contributors. "
Accelerating open source development with AI
Chris Wright (Red Hat)Liam Proven
in reply to Longplay Games • • •@Longplay_Games @ferrix @joe
I'm aware. I wrote an article about it:
theregister.com/software/2026/…
Memo: Red Hat Global Engineering plans to lean in to AI
Liam Proven (theregister)Arthfach 🐻
in reply to Greg Bell • • •Gentoo!
It's very much not as scary as people claim, and you get the added bonus of telling systemd to eat shit! ❤️
Cal Q Alaera
in reply to Arthfach 🐻 • • •Joe Groff
in reply to Cal Q Alaera • • •Liam Proven
in reply to Joe Groff • • •@joe @Cal @arthfach @ferrix
Life is *way* too short.
FreeBSD can already run Docker containers. It's run Linux binaries for years. It only needs a little more wiring up of the bits that are already there to make it a single-click operation to just run one of the containerised Linux app formats (AppImage, Snap, Flatpak or something).
Cal Q Alaera
in reply to Liam Proven • • •What's the modern gaming experience like on FreeBSD in practice? I'm on mobile data right now but if it plays current games eg via Wine/Proton reasonably well on capable hardware, I may jump ship.
Liam Proven
in reply to Cal Q Alaera • • •@Cal @joe @arthfach @ferrix
No idea. I don't play video games. I suspect it's probably awful. It's barely usable as a GUI desktop OS with a ton of manual work, and it is poor at dual-booting.
If you want to game, use a console, TBH.
Joe Groff
in reply to Liam Proven • • •JackPearse
in reply to Liam Proven • • •Thorvald says LLM is allowed to be used for the kernel. Then LLM use is banned by Debian.
Is the Kernel then banned?
In biology and medicine they use AI to detect cancer cells. Is this also banned then? Or are these type of programs allowed then?
What is with Computer Scientists developing free LLM tools. Also banned?
This kind of approach isn‘t realistic.
The overall issue is a quality problem. And needs tools to maintain quality. A ban is simply symbolic politics.
Hilko Bengen
in reply to JackPearse • • •Cainmark Does Not Comply 🚲
in reply to Liam Proven • • •Jared White (ResistanceNet ✊)
in reply to Liam Proven • • •teledyn 𓂀
in reply to Liam Proven • • •@lproven
Rue Mohr
in reply to Liam Proven • • •debian has a ban on contributions in general, I have a few cool little command line utilities and programs I wanted to contribute and found out it would take a 3 year certification process where I had to travel around the world exchanging usb keys to be allowed to and would only succeed if , after it all, one of them was willing to 'bless' me.
I honestly have no idea how ANY of the packages in debian got there, but I can TOTALLY understand when projects host there own packages.
sunweaver
in reply to Rue Mohr • • •Longplay Games
in reply to Rue Mohr • • •@RueNahcMohr The trouble with LLM code in a project like debian is simple, deep, and obvious.
If someone is using an LLM instead of learning, providing official feedback to the LLM instead of growing, and providing the LLM's reply to the feedback instead of engaging...
You're not training the next generation of developers. You're training a model.
Filip M. Nowak
in reply to Longplay Games • • •Liam Proven
in reply to Filip M. Nowak • • •@fmn @Longplay_Games @RueNahcMohr
> solution will be much more radical than Stallman was in the 80ties, i predict.
Key insight right there, I reckon.
Elena ``of Valhalla''
in reply to Rue Mohr • •@Rue Mohr @Liam Proven
in case somebody is reading this and wondering, the process to start contributing packaging work to Debian is more or less:
* at first you need to do some work, submit it to mentors (a platform and a mailing list) and get a Debian developer to vet it: this can be quite easy or quite hard, depending on how niche what you're working on is: finding a volunteer that feels confident working on a python module with common applications is much easier than finding one for something written in a niche language that is only relevant for a few people. There may be a bit of back and forth requiring changes to the package: Debian covers a number of non-obvious usecases, and providing packages for that requires more nuances than building a package that just works on one computer.
* continue working on it in time: maintaining a package is a long term commitment, not something that works well with hit and run contributions. While doing so you're likely to establish a working relationship with one or more DDs.
* this is where being able to travel (or living in Germany :D ) helps: then you need to connect your contributions to a GPG (not USB) key and long-term identity: the easiest way is to meet one or more Debian developers in person, chat a bit, and exchange cryptographic signatures on that key, but since 2020-ish (for obvious reasons) there is at least one alternate procedure where meeting is optional. Having the same name on the GPG key and a government issued ID makes the process easier, but is not mandatory either.
* once you have both an history of contributions and a signature you may be given permission to upload a small number of packages without supervision (Debian Maintainer)
* and after some time as a Debian Maintainer you may, after a bit of exam, become Debian Developer and get permission to upload anything, voting rights, and everything.
Honestly 3 years between the first contribution and becoming DDs sounds even a short time, unless somebody has a *lot* of time to contribute, but it's not like your contributions aren't getting into Debian during that time, they only need an extra step or a few because they have to be supervised.
(Also, if your contributions aren't packaging related the process is different, and depends on what they contributions are related to. And there is a way for people to get voting (but not uplading) rights without ever having to learn how to package, if they are contributing in different areas.)
like this
Liam Proven, PurpleGengar e Rue Mohr like this.
reshared this
Liam Proven e Esther Payne reshared this.
Rue Mohr
in reply to Elena ``of Valhalla'' • • •I'm not socially popular, rolled really low on charisma, so my whole train abruptly ends at 'mentors' and doesn't even get to platforms or mailing lists (haha)
Sebastian Krzyszkowiak
in reply to Rue Mohr • • •Rue Mohr
in reply to Sebastian Krzyszkowiak • • •..... so.... what the truth about it then?
Liam Proven
in reply to Rue Mohr • • •@RueNahcMohr @dos
You were told earlier today, in this thread.
social.gl-como.it/display/3e3c…
What more do you want?
Elena ``of Valhalla''
2026-08-16 19:29:32
Rue Mohr
in reply to Liam Proven • • •Liam Proven
in reply to Rue Mohr • • •