Elektrine lite

← Feed

@Crumpled6273@lemmy.ca

2026-10-11 03:30 UTC

Are Anti-AI Linux distributions practical? I have been using Linux for over 8 months now, and my primary distribution of choice was Debian. Debian recently conducted a community vote on allowing AI contributions, and it ended up allowing responsible AI contributions. What is this responsible? How can AI commits be responsible? There are thousands of reasons to not use AI, and the primary reason is AI is a thief. How did you react to Debian’s decision? Did you switch distros? Which one was your option, and why? Also, when the Linux kernel itself allows AI commits, is there any practicality in a Linux distribution strictly limiting or restricting AI commits? I have no serious usability issue with Debian now but am concerned about the use of AI even in my Linux distribution. Should I keep going with Debian or consider any other distribution, as I only have 8+ months of experience as a daily Linux user? I tried almost all Linux distros and am comfortable with everything except Void Linux and highly complex ones like Gentoo.

Replies (26)

  • @cmnybo@discuss.tchncs.de 2026-10-11 03:43

    There will never be an AI free Linux distro again since it’s allowed in the kernel. I would certainly prefer to use a distro that doesn’t allow vibe coded programs though. That junk is unmaintainable and will be abandoned when the creator can no longer afford the tokens.

    Open ##4981458

  • @dusk@piefed.social 2026-10-11 03:50

    “How did you react to Debian’s decision?” I deleted it, debian was thankfully not my main, just a backup/something of interest. The ‘vote’ itself seemed dodgy, every option was going to ai in some form, or another.

    Open ##4981489

  • @Skullgrid@lemmy.world 2026-10-11 03:51

    www.debian.org/vote/2026/vote_002#texte 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 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. Blindly accepting or uploading AI-generated material without appropriate human review is inconsistent with Debian’s established development practices. We enourage [sic] our contributors to disclose whether a contribution was made with AI assitance[sic], but do not require them to do so.

    Open ##4981491

  • @cerement@slrpnk.net 2026-10-11 03:51

    Most of it comes down to personally mitigating the damages: start with ElementaryOS and Pantheon/Gnome, then decide which path you want to follow if you’re hardcore, go for NetBSD or MirBSD or 9front/Plan9 instead of Linux on the Linux side: ElementaryOS, Gentoo, Chimera Linux, AerynOS, and Nura/PostmarketOS all have strong LLM policies along those lines: Gnome and Cosmic haven’t gone soft on AI the way KDE has Starlight Network No-AI List is one jumping off point, but there are several other lists including repo-slopscore and Weird Little Guys

    Open ##4981510

  • @dusk@piefed.social 2026-10-11 03:54

    Some links to anti-ai digital things: https://noai.starlightnet.work/list.html https://codeberg.org/brib/slopfree-software-index https://www.newinlinux.com/ai-free-linux-distros-open-source-operating-systems/ https://noailist.org/

    Open ##4981527

  • @Mordikan@kbin.earth 2026-10-11 05:23

    What is this responsible? How can AI commits be responsible? There are thousands of reasons to not use AI, and the primary reason is AI is a thief. I feel like you aren't actually asking a legitimate question and are just trying to soapbox, but this is covered by Debian here: https://lists.debian.org/debian-devel-announce/2026/08/msg00005.html As far as what the consequences of failing to follow that policy is, it would be covered under the Debian code of conduct: https://www.debian.org/code_of_conduct_interpretation.html

    Open ##4982389

  • @RIotingPacifist@lemmy.world 2026-10-11 05:23

    Sure but why? the primary reason is AI is a thief. That’s the least important reason to not use AI. All property is theft, especially copyright! There is a difference between people using AI to help write/maintain code that they understand, and slopcoding unmaintainable vibe projects.

    Open ##4982394

  • @hendrik@palaver.p3x.de 2026-10-11 06:43

    I’ve been using Debian for a long time and honestly, I’m not going to worry about this too much as of today. We got that decision, yes. But I don’t think I’ve seen any consequences, yet. And I always try to judge people by what they actually do. Less so by what they say. I say that the last word hasn’t been said yet. On this whole AI thing. We still got many Linux people who don’t really appreciate AI. The entire community isn’t really fond of it. We got people who say there isn’t a way to make use of it responsibly. I have a hunch there’s more to this story. But only time will tell. Until then I’m going to continue using Debian, just like I have for the past 10-15 years. I trust the community distributions, they faced other challenges before. And usually they’re not half bad at facing challenges and ultimately doing the right thing. Doesn’t have to be easy. Sometimes we’re headed the wrong direction for a while. But what matters IMO is the result. And I’m positive they’ll find some way to deal with this. I don’t think AI fits Debian’s identity at all.

    Open ##4983282

  • @mildseason@sopuli.xyz 2026-10-11 07:17

    AI is a tool. You already trust the developers to build an operating system with the tools available. From the Debian announcement 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 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. Blindly accepting or uploading AI-generated material without appropriate human review is inconsistent with Debian’s established development practices. It’s quite clear they don’t allow vibe coding. As you say, the kernal itself allows AI contributions in a similar way. If you’re worried about the ethical aspects of AI then you’ll probably have to move to NetBSD. If you’re only worried about quality this is a non issue.

    Open ##4983588

  • @tabular@lemmy.world 2026-10-11 07:43

    AI companies and AI users either do not care or don’t know/understand the value of software freedom. I only used Debian from Mint [Mint being based on Ubuntu, Ubuntu based on Debian] but they used to appear as a champion of software freedom. It was somewhat understandable when they choose to no longer ~seperate proprietary drivers/codec/software but, whoever runs Debian now, I think their true colors are showing with AI. I avoided using Debian as I thought it would be too hard to get up to date drivers! Gentoo has binaries for most of what I need and compiles the rest for me. It may not be as difficult to use as you think, at least for day to day usage. However, trying to install Gentoo would definitely be… an experience 🫣

    Open ##4983850

  • @m532@lemmy.ml 2026-10-11 07:56

    thief If you advocate for further expansion of “copyright” oppression, you deserve microsoft windows.

    Open ##4983957

  • @Mercer@lemmy.zip 2026-10-11 09:41

    AI is an incredibly useful but morally dubious. The word responsible likely means technically responsible not morally. I personally wouldn’t change distro over this but you do you.

    Open ##4984781

  • @mactan@lemmy.ml 2026-10-11 10:49

    the only good to come of it is the destruction of the concept of intellectual property, the tools of capital won’t serve us

    Open ##4985517

  • @mrnngglry@sh.itjust.works 2026-10-11 12:39

    Void isn’t too difficult and is documented well. I strongly dislike AI but am not a purist. Linux is already a no-go for purists and good luck with the alternatives. I think the kernel’s policy on AI use is reasonable. As long as a distro or a package isn’t obvious slop and they have a clear policy, I’m okay using it or continuing to use it. In the meantime, while I mostly use mainstream distros like Fedora and Arch, I’m quite happy that distros like Void exist so that if mainstream Linux ever takes a direction I disagree with, I have alternatives. In the end, keep perspective. A distribution like Debian allowing for responsible AI use is not the same as the vibe-coded slop that is Omarchy.

    Open ##4987115

  • @cypherpunks@lemmy.ml 2026-10-11 14:37

    Are Anti-AI Linux distributions practical? It’s not possible to have a 100% no-LLM-coding-involved Linux distro anymore now that the kernel itself is welcoming LLM-assisted contributions, but it’s still possible to say that everything which the distro produces itself will not use AI. How can AI commits be responsible? What Debian means is: by reading what it produces and not just blindly accepting it but having humans review it carefully. The quality of LLM-assisted software is highly variable. Experienced people like Linux and Debian developers are much less likely to publish very bad slop than inexperienced developers who are newly able to make a thing work well enough to ship it. I am concerned about the extent of Debian’s embrace of LLMs but I still have a lot more confidence in them than most other distros (especially small hardcore-anti-AI distro projects lacking sufficient developer capacity to even keep up with security updates). I expect we’ll be seeing lots more things like this non-upstreamable-because-AI hardware enablement and distros like Nura (formerly postmarketOS) will either either adopt more nuanced LLM policies or be forked. I am doubtful about if there will be any serious distros with hard LLM bans in a few years from now. But also, perhaps the bubble will have burst by then, so hosted inference won’t be so cheap and the use of LLMs will probably be quite different. the primary reason is AI is a thief This is not the primary reason for most people, I don’t think. I think the fact that it increases complexity while reducing human understanding is the biggest problem; it’s possible (easy even) now to produce mountains of good-enough-by-many-metrics source code which the person doing the prompting has very little comprehension of. The fact that it is also a plagiarism machine is far less of a problem than this. (There are a litany of other problems too of course, several others of which I would also rate as worse than the plagiarism aspect.)

    Open ##4988194

  • @Sina@beehaw.org 2026-10-11 14:48

    Also, when the Linux kernel itself allows AI commits, is there any practicality in a Linux distribution strictly limiting or restricting AI commits? Upstream is unrestricted, unless you want to detach from upstream it’s hopeless.

    Open ##4988206

  • @TrollAccount69@lemmy.ml 2026-10-11 20:50

    No. It’s not practical. No matter how you feel about ai or how you think it is wrong, the increased tempo of bug fixes and security patches necessitates either manpower beyond what is feasible for volunteer projects or the use of ai tools. It’s an arms race and you can’t opt out without just missing the patch schedule.

    Open ##4991189

  • @story@lemmy.zip 2026-10-12 03:02

    Sorry to bring this into the Linux discussion but OpenBSD is still here. even if the code were AI-generated it would have to go into the meat grinder that all human code goes through to get into release. Maybe it’s time to consider your switch?

    Open ##4996341

  • @RumRunningDevil@lemmy.zip 2026-10-11 15:06

    OpenBSD. Come learn about computo. Be free with us.

    Open ##4996352

  • @pinball_wizard@lemmy.zip 2026-10-12 04:06

    Some of us learned how to code in the first place, and didn’t write overly complicated spaghetti code full of vulnerabilities for the AI to find.

    Open ##4997301

  • @senslayer@lemmy.ml 2026-10-12 04:29

    Is most of the training data for popular LLM tools stolen? Yes, but the algorithms are not so from a theoretical perspective there’s nothing inherently wrong with developers using AI (which itself is a broad term covering frontier models to simple neural net classifiers) but it’s a matter of their tools which afaik is the responsibility of the developer. (Ex. Devs aren’t banned from using VS Code even though Microsoft is not a good company) (Ex. Dont upload user PII to online tools just to convert a pdf you’re responsible if they steal user data) So really responsible AI means developers accept liability for any theft or plagarism these tools commit, just as they would if they plagarized code themselves which is less problematic for developers than introducing precedent for restricting developer tooling. In theory you could revert the commits that are labelled AI-generated but given the scale and application of LLMs that’s a lot of code to rewrite that was already reviewed by maintainers for a lot of important processes and will have likely undergone far less scrutiny and correctness tests. Until AI companies are held responsible for training data that’s stolen and their generated outputs are held to legally be plagarism there is negative incentive to rewrite ai-generated code.

    Open ##4997528

  • @Lettuceeatlettuce@lemmy.ml 2026-10-12 04:53

    Unless you literally programmed every component yourself, you can’t get away from some level of LLM involvement, even if the distro itself bans it. There is no 100% certain way to check code for LLM use. So if a developer doesn’t disclose it, and the maintainers accept the code, it’s in the official codebase now. There’s a deeper problem though, which is a problem of demarcation. What counts as an “AI contribution” to you? Obviously vibe-coding is. But what about more subtle uses? What if a developer uses an LLM to read the code and suggest a way to make a certain contribution, but it never actually generates any code, the developer implements the LLM’s suggestion completely by hand. Does that count? What about if a developer hand writes 95% of the code themselves, but that last 5% they aren’t as confident in, so they have the LLM generate it. Does that count? What if an extremely experienced developer uses an LLM to generate 100% of the code, but spends hours going over ever single line making sure it is correct and making little tweaks before submitting the code? What if a developer writes the initial code 100% by hand, and only uses an LLM to go through and optimize the formatting and performance before submitting it? What if a developer writes 100% of the code by hand, but uses an LLM to generate a bunch of unit tests and documentation? These are just some of the ways that LLMs can be involved in the process of software development, and most of these wouldn’t have any real chance of being caught by a maintainer doing some sort of scan to detect LLM usage. I’m not saying these uses are or aren’t justifiable/acceptable, but my point is it’s often not clear what people consider to be “over the line”. Almost no experienced devs in the FOSS world are advocating for the 100% vibe-code/token-maxing approach. But lots of them are comfortable with using LLMs in similar ways to what I listed earlier. The tough truth is that you’re almost certainly already using software that has LLM involvement at some level. Short of going full Amish mode, or using completely pre-LLM software in some kind of air gapped setup, you’re not going to be able to avoid it.

    Open ##4997697

  • I think you can see large Linux distributions like a supermarket. In a supermarket, you can find junk food, booze, and pringles, or bio fruits and vegetables which you prepate yourself. Of course there are differences between offers, but what ultimately matters is what you chose to buy. Distributions do have mostly influence over their internal build tools, packaging, infrastructural decisions like when to adopt Wayland or the choice of init system. They are unlikely to reject security fixes in the kernel or in a browser just because these contain AI-assisted bug fixes. The above might change if security gets affected by AI slop. For example, Debian is used a lot as a server distribution and security matters a lot. So, it is unlikely to compromise on that. One can use smaller, more minimalist distributions, or alternatively make minimalist choices in ones own package selection. Or use e.g. not vim but the ai free fork of vim.

    Open ##4998469

  • @StoneStar@feddit.nl 2026-10-12 09:03

    The linux kernel is compromised. Lets use NetBSD!

    Open ##5000632

  • @technocrit@lemmy.dbzer0.com 2026-10-12 14:29

    Are Anti-AI Linux distributions practical? No, because there’s no such thing as “AI”.

    Open ##5003614

  • @iusemybrain@sh.itjust.works 2026-10-16 15:42

    I’ve always said this, don’t switch to a different flavor of Linux because the developers are starting to use LLMs to code it. I would also say don’t jump into a distro that is completely vibe codes. Quality Information, contrary to popular belief, is becoming more and more scarce; what you could search early 2000s - 2010s you can’t really do now, there’s advertisements now, there’s LLM prompts at the top result, and you have to dig through pages of search results before finding a golden website. Information is being controlled and funneled by google and there is a price associated with that (your data). I think if a linux distro regulates its AI usage (IE not entirely vibecoded and pushed to the repository ) I don’t see a reason to be switching distros. Again the primary reason why developers are using LLMs to code has to do with the clusterfuck that is of attaining information.

    Open ##5063647