SoylentNews is people
SoylentNews
Disclosure optional, quality mandatory:
The Debian community has voted to allow members to use generative AI when creating their contributions, with the caveat that developers remain responsible for code quality.
The Linux distro's community recently decided to develop a policy on use of AI-assisted coding tools, and asked participants to vote on one of eight proposals that included an outright ban, cautious use, or just avoiding LLMs because of their impact on Earth's environment.
The rules of the vote saw community members asked to rank each of the eight proposals. Just under 600 people voted, but Debian's election team rejected many for unspecified reasons, leaving almost 450 valid votes to count.
When the tallying was done, proposal E – "Responsible Use of Generative AI" – won the day.
The proposal means "Debian neither endorses nor prohibits the use of generative AI tools in the development, maintenance, or documentation of software, packaging, documentation, and other media published within the Debian Project."
The proposal advocates that approach because "such tools can substantially improve the productivity of contributors when used responsibly, allowing volunteers to spend more of their limited time on work that requires technical expertise, judgment, review, and collaboration."
The proposal also spells out that the Debian community doesn't believe "AI made a mistake" is an excuse for sloppy contributions.
"The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance," the proposal states. "The use of a generative AI tool does not diminish the contributor's responsibility for the work they submit. Contributors are expected to understand, review, test, and, where appropriate, modify AI-assisted output before incorporating it into Debian."
Woe betide the dev who doesn't check their AI-generated code, as the proposal also states, "Blindly accepting or uploading AI-generated material without appropriate human review is inconsistent with Debian's established development practices."
Another element of the proposal tries to make acknowledging the use of AI a norm.
"We encourage our contributors to disclose whether a contribution was made with AI assistance, but do not require them to do so," the text states.
As our FOSS aficionado Liam Proven wrote in his report on the vote, the Gentoo Linux team has banned use of AI, while NetBSD and OpenBSD don't want any clanker-written code contributions.
Linus Torvalds, arguably the most influential figure in the FOSS community, welcomes AI-generated contributions.
In July he declared "Linux is not one of those anti-AI projects" – and recently proved it by using AI to squash a tricky bug. Torvalds has also sometimes complained about AI, such as his May observation that AI-generated bug reports sometimes made the Linux security mailing list "unmanageable."
(Score: 1, Insightful) by Anonymous Coward on Tuesday September 01, @11:19PM (6 children)
> The proposal advocates that approach because "such tools can substantially improve the productivity of contributors when used responsibly,
Actual studies show that there is no "substantial improvement," but rather only "very slight improvement," and those studies had no requirement of using the slop responsibly. The simple fact is evidenced by Faceplant just shutting down their move to "Al". They laid people off, made others work-more, pushed and pushed and bet the whole company on Al, and failed.
Whoever keeps promulgating this BS needs to just leave. If you ever see such remarks, you should ask to see the relevant data. Not "how many lines of slop" are generated, but its usefulness, efficiency, how many lines of slop are taken back out again later, whether production bug-count increases or decreases... and the actual, big attempts all show the same thing. No one has been able to make this into a positive.
(Score: 5, Touché) by JoeMerchant on Wednesday September 02, @01:20AM (5 children)
>Actual studies show
Citation, with dates of study, absolutely required.
I'd probably agree for a study done in early 2025 - marginal improvement if used well.
For a study done in the last 4 months, whole different world - one that was actually pretty predictably coming in 2025.
What's coming in 2027?
Reply hazy, try again
Ask again later
Better not tell you now
Cannot predict now
Concentrate and ask again
🌻🌻🌻🌻✌️ [google.com]
(Score: 3, Touché) by Anonymous Coward on Wednesday September 02, @05:22AM (4 children)
Sooo continually moving goal-posts?
Whenever the statement has made, comes the response, "Yeah, but that was _yesterday_! Have you tried again *today*?!?"
Monday, August 31st:
- https://soylentnews.org/article.pl?sid=26/08/30/2256250 [soylentnews.org]
"AI Agents Meant To Replace Meta Workers Made “Large-Scale, Disruptive Actions”
This Al shit causes more problems than it solves, and is not capable of being used productively.
Cue the replies about how it's a different type, different purpose "Yeah, but--" etc. I guess this is out of date. It was literally yesterday, and the contents was based around back in may -- three whole months ago. So I guess it's just out-of-date all over again. Shrug. Just like the Al lobbyists, "It'll change the world!! We just need MOAR training data! MOAR datacenters! Bigger graphics cards! More processing! More power!"
(Score: 1, Informative) by khallow on Wednesday September 02, @11:41AM
One of the things routinely missed here is that much of that aggressive new data center construction goes towards improving AI. One should expect that what AI was capable of in the past will not be the limit of what it is capable of in the future.
(Score: 2) by JoeMerchant on Wednesday September 02, @12:11PM (2 children)
>Sooo continually moving goal-posts?
Ummm.... yeah. Automobiles 100 years ago were absolutely wretched death traps, beyond unsafe even at walking speeed, the idea of letting them roam city streets and the countryside even at "a gallop" with two for every house and people using them daily, in 1926, would have created obscene amounts of air pollution and a death toll higher than the worst world wars. Automobiles were improved, now they're only the 12th leading cause of death in the US - by comparison, half as many people die per-capita by automobile (and all transportation) accident in Western Europe. Unfortunately they are still the number one cause of death for Americans aged 13 through 25, but somehow that is still acceptable and we fund all kinds of tax supported infrastructure, bailouts for struggling manufacturers and other societal costs because, apparently, we the people value the convenience and yes: fun, of automobiles in our society that much.
>shit causes more problems than it solves, and is not capable of being used productively.
Yeah... see above, and throw in some notes about how the oil industry did its thing on the global environment, in large part aided and abetted by people's love for their cars and their cars' dependance on oil...
Computer, and now AI/LLM, technology is moving faster still. Alvin Toffler wrote "Future Shock" in 1970 about how societal change was accelerating and the children of the 1960s accepted massive changes and rates of change that their parents struggled to deal with, and that was before computers started having massive direct personal impact in daily life, and AI was just a joke about "telling the computer exactly what it can do with a lifetime supply of chocolate" in the Gene Wilder Willy Wonka movie.
🌻🌻🌻🌻✌️ [google.com]
(Score: 0) by Anonymous Coward on Wednesday September 02, @06:14PM (1 child)
LLM technology is fundamentally unimproveable. No increase in the size of training sets can change the problem of stochiastic, incorrect output. Sorry, "confabulations" if you're trying to present this as unintentional. "Hallucinations" if you're intent on anthromorphizing software. Same with increases in the dimensions of correlation.
https://arxiv.org/html/2401.11817v2 [arxiv.org]
https://arxiv.org/pdf/2508.01781 [arxiv.org]
https://fortune.com/2023/08/01/can-ai-chatgpt-hallucinations-be-fixed-experts-doubt-altman-openai/ [fortune.com]
Takeaway quote: “This isn’t fixable...It’s inherent in the mismatch between the technology and the proposed use cases.”
(Score: 3, Insightful) by JoeMerchant on Wednesday September 02, @09:30PM
I don't give 2 shits about your hypothetical theoretical academical analysis of your own understanding.
What I know is: I sez code, it codez. It codez faster than me, better than me, and it findz mor bugz. It also glazes right through misspellings and gives you what you meant, not what you said.
Is it perfect? No. Will it completely replace human coders? Some, not all. Is it the most significant "coding assist tool" to come along in the last 50 years? Again, I'd say yes. Will people misuse it? Absolutely. Does that mean it's inherently flawed? Absolutely not.
IDEs with built in refactoring tools, compilers with warnings, Google search for examples of what you're trying to do, those were all big jumps forward. Not this big.
12 months ago it couldn't handle big projects, but it was doing small stuff so well it was already significant. Beyond maybe 300 lines of specs it started to get a bit lost at times.
Today, I feel like it starts to get annoyingly bogged down around the point that I have about 30K lines of specification documents - at that level you can turn things around and make simple changes faster than it does, if you've managed to keep some sense of how the code it built works. You can also modularize your system and just have it work on one 30K chunk at a time as long as you can fit reasonable interface specs into those 30K lines of specs.
This time next year, will that be 300K lines of specs? I don't know, but even if the LLMs themselves "aren't getting any better" the experience of using the frontier model based agents has dramatically improved.
🌻🌻🌻🌻✌️ [google.com]
(Score: 3, Insightful) by krishnoid on Tuesday September 01, @11:44PM (3 children)
Makes sense, no pointing to the source of the technical failure and conflating it with transfer of responsibility [youtu.be].
(Score: 3, Touché) by JoeMerchant on Wednesday September 02, @01:24AM (2 children)
If I use a chainsaw, haphazardly, to trim the Begonias, is the chainsaw to blame?
Better to look to the trimmed Begonias to decide if they have been trimmed well, or not - nonya damn business if I did it myself with medical scalpels, a katana, or if I paid migrant laborers to do it with left handed school scissors - what matters is the end product.
🌻🌻🌻🌻✌️ [google.com]
(Score: 2) by krishnoid on Wednesday September 02, @01:30AM (1 child)
Sorta, because you still should be able to answer questions about any problems with the work? But you've been actively using AI *way* more than me, so I defer to your experience here.
(Score: 5, Insightful) by JoeMerchant on Wednesday September 02, @02:30AM
>you still should be able to answer questions about any problems with the work?
That is the ideal, and that is the level of professionalism I have attempted to display for 35 years... I have had many paid colleagues over the years who point to things and shrug their shoulders "I dunno why, it just does..."
Then you get into the world of FOSS, and those people are anonymous, from all over the globe - it's a damn miracle that anything sensible happens at all. I was "close" to the ffmpeg project around 2012 when the libav fork happened because a big chunk of the community couldn't stand the immature posturing of the other half... but what makes OSS work is: the tests. The build controllers and the automated test suites that help clearly illustrate if a patch has broken anything, and the metric based tests that demonstrate - objectively - when an improvement has been proffered. IMO, that's what has kept FOSS improving, more or less, for the past 20+ years. Before that, it may have operated more on honor and ethics and technical craft excellence, but those qualities are ill suited to management of the global contributor model.
And those same things that keep FOSS ahead of the chaos are effective tools with LLM agents, separating the slop from the stuff that actually meets requirements.
Then the challenge becomes: how good are your requirements?
>answer questions about any problems with the work?
AI will answer the questions, not reliably, but it will give you some BS that's usually as good or better than your average Stack Exchange denizen - wonder why that is?
What is more important is: can AI successfully iterate until it finds solutions which meet all requirements? A year ago, agents getting stuck in loops while debugging was far more common - they've improved quite a bit in that respect.
I notice, as my projects get bigger, frontier model based LLM agents still bog down, get slower about doing simple things, I assume because there's so much more to consider in the project even before making a change, and it's so much easier to break one of 350 unit tests than it is to break one of 30.
🌻🌻🌻🌻✌️ [google.com]
(Score: 5, Insightful) by RedGreen on Wednesday September 02, @12:18AM
hahahahahahahahaha. Stop it you are killing me. There is no way in hell to ensure legal compliance by using stolen code in the development process. It simply cannot be done, those models do not give you the copyright of the code they stole when training them that was produced for you to use. The Debian project is supposed to be a place where that matters and is the only way a package can/will, now was to be, be accepted into the archive is when it has a clearly stated copyright of that code that is compatible with the DFSG for its inclusion. Say goodbye to that now, pull the other one it has bells on it. So there they go more slop included in the project for even more enshitification of it than they already have done.
"Cervantes definitely was prescient in describing a senile Don fighting against windmills." -- larryjoe on /.
(Score: 4, Insightful) by SomeGuy on Wednesday September 02, @12:33AM (4 children)
Good. I hope that also means responsible for their code, period.
If they want to use a Large Lameness Machine to slop out a "template" for them, great. It's not that different from copying code off of a random web site. It can not change anyones responsibility to make sure code is quality, secure, and maintainable. (I'd also argue licensed, but I guess that ship has sailed).
The trap here is that for simple stuff, what it shats out might not need any changes. So people get lazy and don't want to ever look at it at all. Can't do that.
(Score: 4, Touché) by JoeMerchant on Wednesday September 02, @01:26AM (3 children)
> I hope that also means responsible for their code, period.
As responsible as ever, have a read of the end of the MIT license if you need a refresher:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
🌻🌻🌻🌻✌️ [google.com]
(Score: 1, Interesting) by Anonymous Coward on Wednesday September 02, @05:25AM (2 children)
If you can't copyright machine-generated code, can you still be responsible for it?
Suppose it violates copyright.
Or it causes systems to brick, for anyone who uses it.
You include the disclaimer in the copyright and throw a license file in there, MIT, that disclaims liability. Courts determine that you can't copyright the code, because machine-generated. Your license need-not-apply. Then.. are you now liable? unable to disclaim liability?
(Score: 2) by JoeMerchant on Wednesday September 02, @03:20PM (1 child)
If the copyright is invalid, that would seem to me to lessen liability, not increase it.
But, what do I know? Sony is in the process of arguing that if players could "own" GTA6 then only one player could ever have it, ergo players are merely "licensing" the game for time-limited use. https://www.youtube.com/watch?v=UBxZFadp9Pw [youtube.com]
🌻🌻🌻🌻✌️ [google.com]
(Score: 0) by Anonymous Coward on Thursday September 03, @02:46AM
So if an author sells books, if buyers could own their own books, only one buyer could ever have the book?
🤣
(Score: 0) by Anonymous Coward on Wednesday September 02, @11:39AM (1 child)
in his grave... Oh, wait!
(Score: 4, Informative) by Bentonite on Thursday September 03, @04:02AM
The symbol of freedom is hard to kill (but I guess utter destroying the freedom of the OS he originally got the FSF to fund development of, to be free software, is the most effective kind of attack (but it's not working)).
If only these Debian dis-contributors realized, that if you are going to make an OS more and more proprietary, you may as well just stop wasting your time and just use windows or macos (as the end result will be the same).
If Debian wants to end up any different to windows or macos, they should commit to becoming free software again by taking back out all the proprietary software and committing to never putting any back in (if only so much hadn't been put in, the task would be easy).
Alas, Debian is going in the opposite direction, full steam to 100% proprietary, via proprietary slopware now.
(Score: 3, Touché) by Anonymous Coward on Wednesday September 02, @11:44AM (4 children)
Debian had no choice. AI is everywhere in the kernel and major FOSS projects. Debian is upstream for a lot of distributions but downstream of every corporate entity that writes the Linux kernel.
Just like the systemd thing, Debian can only sit and pretend like they have agency.
Where Red Hat / IBM goes, where Google goes, so too will the Linux desktop follow, which means Debian must follow.
If you don't want AI, go use NetBSD. Or Linux-libre on GNU/Guix.
(Score: 2) by JoeMerchant on Wednesday September 02, @12:28PM (2 children)
>If you don't want AI, go use...
Find whatever level of tech you think is "good enough," fork it, and go live in your Amish inspired communities - eschewing pneumatic tires, buttons, electricity, and whatever other tech offends your sensibilities.
If you're like most Amish, you'll find yourself occasionally cheating - maybe accepting installation of a telephone on a pole outside your home. I watched an elder in the community use that phone to call the fire department (who arrived in diesel powered truck on English air tires) to ensure the safety of their home from a fire in the field that might have gotten out of hand. By the time the fire truck arrived they had used their animal powered mower to cut down enough dry corn to contain the fire before it got to the (tinderbox wooden) family home, cost 'em about 3/4 acre of crop but they actually didn't need the fire truck that day and it just stood by, incase... Then there were my visiting Mennonite cousins who spent all day glued to the TV watching "Price is Right", "Mike Douglas" and similar voraciously while visiting "the secular side" of the family... like kids in a crack-den. As I was told, they allow themselves automobiles - just not flashy chrome plated bumpers and such other frivolous decorations...
By the way, Amish and Mennonites are not poor, far from it, their lifestyle depends on above average wealth just to survive. It's a matter of choice, and I think choosing to not watch 1970s daytime television was a good one.
🌻🌻🌻🌻✌️ [google.com]
(Score: 5, Informative) by canopic jug on Wednesday September 02, @12:55PM (1 child)
I disagree with your false premise that LLMs are a useful development tool. So far what we have seen, they are not. I also disagree with the assertion that LLMs will amount to anything beyond grammar checkers and propaganda at scale. That's what they are good at. That's about all they can be good at.
Furthermore, adding more processing power only makes LLMs that much more expensive, not better, while vastly increasing the fossil carbon emissions which they are responsible for.
Money is not free speech. Elections should not be auctions.
(Score: 3, Insightful) by JoeMerchant on Wednesday September 02, @01:58PM
>So far what we have seen, they are not.
In 2020 I coded up a fancy mp3 player, got it running on a Raspberry Pi 4, implemented a decent feature set and my family has listened to it, off and on, ever since.
It did not become memory efficient enough to run on a Pi Zero 2W. It did not succeed in replacing the AcousticBrainz database with raw analysis algorithms (all the more relevant since AcousticBrainz shut down.) It did not implement multiple UI "skins". It did not succeed in connecting to bluetooth speakers from a Raspberry Pi. It was implemented in C/C++, my language of deepest experience.
In 2026 I resurrected the project during the "Free demo" of Claude Fable, and have continued development under Opus after 2 weeks of Fable access elapsed. For what I would estimate to be less than 1/3 the original effort in C/C++, Claude and I have re-implemented the music player with all of the above features and a couple more. Found a few bugs / misconceptions of features I thought were working in the old system that actually weren't. It's now in Rust and Python as I deem appropriate. It's now starting to implement controlled database synchrozation between multiple player instances, something I never even attempted before.
I call that useful. It's already out-performing the prior project on several fronts and the new hardware capabilities mean I can finally deploy it as an in-car system like I wanted to, but never had enough free time to do the extra work.
On the useless metric side: the old hand written C++ system was 11K LOC in 73 files, maybe 500 lines of documentation. The new Rust system is 32K LOC in 86 files, plus 23K LOC in 102 Python files and 40K lines of documentation / specifications. Before you get too happy about the "inefficiencies" of the LLM generated system, know that the C++ project has 0 automated unit and integration testing, whereas the Rust and Python have 350 automated tests implemented, and that 40K lines of documentation the tests are based on were generated "conversationally" with me just casually describing what I wanted the system to do. There's also the fact that I'd say the new system embodies at least twice the feature count of the old one and has a much more diverse tech base including cross compilation support, importing of crazy old Symphonia algorithms, etc.
And, it's at 6 weeks of spare time development, where the prior system took 6 months of spare time to reach less than 1/2 the feature count. I'd also estimate that by using LLMs I'm 80% or more "less focused" on the development work when I'm "working on it". With "real code" I had to close the door, bark at disturbances and focus, with LLM assistance I can sit down, scan a status report, whip out a quick off the cuff guidance statement and it's off to work for another 5-30 minutes unsupervised. Last night I set it to work on a refactor / modularization hygiene pass and it worked independently for 2-3 hours based on 10 minutes of interactive prompting. Those 2-3 hours would have taken me 10-20 hours to do by hand, and as a result I probably never would have bothered - instead opting to live with the spaghetti I know because "it's more efficient".
Yes, I have my own personal micro-meter of sea level rise contribution due to all the energy "wasted" on a stupid music player via LLM assistance. At least I raged online against Proof Of Work cryptocurrencies back in 2018, for all the good that did. And in a very real sense, my work from home situation of the past 6 years has saved far more energy than all my LLM explorations, and likely continues to save more energy per year than I spend in LLM work.
🌻🌻🌻🌻✌️ [google.com]
(Score: 2) by mrpg on Wednesday September 02, @06:31PM
With options from the systemd vote:
.
Focus on AI. Every commit message must now be co-authored by a chatbot, whether it helped or not.
LLMs but we support exploring alternatives. You may still write code by hand, as a hobby, like calligraphy.
Support portability, without blocking progress. The AI-generated changelog should at least try to compile.
Support non-AI systems, without blocking progress. Human maintainers may keep maintaining, provided they file a Reasons-For-Being-Organic bug report.
Support portability and multiple implementations. GPT, Claude, Llama, and a Markov chain trained on debian-devel flamewars all get equal billing.
Support for human review is Important. Someone should probably glance at the diff before NMU.
Support for human review is Required. Radical proposal: an actual person reads the code once.
Further Discussion. The traditional Debian outcome, now available as a subscription service.
None of the above, ban AI entirely, return to hand-carving packages into stone tablets, as Ian intended.
#nonsponsored #responsibleAI #apt-moo #humanitytowardsAI #FreeAI