From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
Are Anti-AI Linux distributions practical?
No, because there's no such thing as "AI". It's irrational to try to remove something that doesn't exist. People will continue using computers to compute regardless.
On the other hand I don't think developers should accept generated slop. I guess that's what "responsible" means.
The linux kernel is compromised. Lets use NetBSD!
I hope this whole thing makes hurd grow.
Hurd's tAInted too :/
Wait... WHAT!?
Yea, apparently AS is now being heavily used in its development. I need to look up the reference, but I read a while ago that AS-assisted 'coding' was used for making SMP work in Hurd.
I've spent quite some time pondering my options now that OpenBSD, my former OS of choice, has been slowly but surely giving in to the hype, and I can tell you that currently the most sensible option seems to be (I'm not joking) 9Front.
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.
Man, my friend said he made a web app. He asked me if it would be secure to deploy. I check the front end and immediately check if his formatting was readable.
Two javascript blocks embedded: one was beautified, normal, tabbed out.
The other block was debeautified, which JS developers do so people can't steal their code (as if that works these days).
I said, "You didn't make this."
"Yeah I did!"
"You used AI."
"But I wrote the prompts!"
"To prompt a computer to steal two separate snippets of javascript from actual developers to achieve the goal.
"Man, this is fine for prototyping, just to demo an idea. But I wouldn't release this to the public, because if I saw that, I am going to use the tools I already have, and my LLM to speed up the actions, and I will show you how hackable the app actually is.
"You didn't make a steak. You ordered a steak and got a McRib with carrots."
He responds, "Does it look ok?"
"Yeah, we can use the css, and we can adjust that as needed, but if your frontend is this sloppy, I wouldn't release the backend and take customer data. Hell no."
What if someone does a copy/paste of a code snippet from a google search and then modified it for their own purposes?
According to the grifters, this is "AI" but it's not and nobody cares. There is no boundary for something that doesn't exist ("AI"). That's fundamental to the grift.
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.
Yeah, all the FOSS communities have been starving for labor since they started. Likely the best we could hope for is that the true experts at the top are maintaining a critical eye on what makes it in.
Even in that case we need to hope they’re using ai tools because they’ll be seeing a volume of cases too high for their previous workflow.
It's a mix right?
In some cases, you have absolute neophyte coders trying to shove unvetted vibe code in. There needs to be some bars on entry for what is submitted. I'd like to see at least mid level code in the same style and verbosity and not something that's on the fringe of the vibe where it failed 15 times and ended up shoving some great atrocity in for a lack of context. As long as the person asking for a PR isn't trying to insert horrors, inspecting the input using tools isn't the worst thing either.
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 prepare yourself. Of course there are differences between what different markets offer, 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. They do not have real control over upstream development practices.
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.
One distribution which stands out in its philosophy is Guix. It is entirely reproducible and stresses that anyone can built it from reviewable source code. This is so important that non-free firmwares are rejected (which gets them a lot of hate and negative astroturfing). That gives a lot of transparency and a solid base for trust.
Now, accepting vibecoded, unreviewable packages would make the whole buildable-from-source aspect moot, so I guess they are unlikely to accept slop packages.
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.)
Yeah the Debian Project's position makes a lot of sense to me. They're basically saying that they won't be wasting a bunch of resources trying to seek out LLM generated code and purge it and will instead just focus on making sure ALL the code is up to their quality standards. This will likely mean they spend a lot of time sifting out slop anyway, and will allow them to keep just focusing on making the project do what it's always done. Ship a stable, usable, and free distro.
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 of style, logic, and cleanliness that all human code goes through to get into release.
Maybe it's time to consider your switch?
Plus NetBSD has Anti AI contributor policy these two are safe haven for people that don't want AI. Also Ironclad OS GPLv3 licensed also available for anyone wants to.
NetBSD! I am currently learning UVM and it's really impressive to a memory newbie
I heard that OpenBSD is not so friendly enough to daily drive as a primary operating system. Are you using it?
Yeah but i run it on an x220T. It definitely depends on what you wanna do, but i find it reliable.
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.