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: 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]