Yes, the devil is obviously in the details. I would start off with: let's not include any projects that are wholly generated by large language models and work the debate from there.
I would also highly endorse picking alternatives to major projects that have turned to using large language models to drive development.
I don't know to what extent the Vim project is using large language models, but Vim Classic looks like a nice project to pick up as an alternative.
I've seen where Torvalds said that he considers them as just another tool in the Arsenal, he doesn't really care, if the code is good.
He doesn't want his time to be wasted He'll scream and shout if an LLM creates that time pit
These following words an extreme version of me would say
It looks like you will have to stop using Linux. Since from your perspective anything that uses remotely an LLM is bad, you will have to stop, otherwise you will contribute to the environment being destroyed willingly and actively
In practice that is impossible. If you drive a modern car it has the Linux kernel. If you have a smart TV or more you're also using the tainted kernel. Even if you have a stick which also streams or a camera you will have a Linux kernel in many cases.
These LLMs are an infection of the planet's code base
Since you're already using BSD a solution would be to cut using Linux on your computers drastically
I'm being entirely defeatist here, I know, but this isn't really possible. The Linux kernel itself has been slopped to hell. You're better off using NetBSD and hacking in functionality from glibc.
This entry was edited (Friday, June 12, 2026, 4:04 AM)
At this point, I kind of just stopped caring what on my stack was slop or not so long as it's at least working. I'm happy knowing I won't be using bullshit generators, I don't want the psychic pain of seeing something I use succumb to it and having to find entirely new software to account for it. I could waste my time without as much of a headache.
This entry was edited (Friday, June 12, 2026, 4:09 AM)
@Artur Manuel @R.L. Dane 🍵 I haven't ditched all slop-generated code for the same reason I haven't gone vegan. I agree with the ethics, and I'm trying to minimize my consumption of Bad Things in favour of Good Things, but I also don't have the resources or mental bandwidth to change everything out.
That would be great, but how to convince devs to not use LLMs when they make their life easier by writing the code? This is what they get right now and affects them directly. Issues arising from using LLMs do not affect them directly, right now.
I do not think that it is a good comparison, even if there will be something 100 meters down the road, I will "experience" it quickly and directly. If I live in let's say Maine, the fact that someone converts drinking water into a waste in Utah does not affect me directly, I still have drinking water and consequences maybe will hit me in the future. Or will not at all.
Forgive the religious analogy (if that's a dicey subject for you), but I'm reminded of the saying, "Beware the Leaven of the Pharisees*).
Destructive ideology and praxis worm their way in a little at a time, but the opposite is also true! A handful of people with noble aims and character can truly affect change a little at a time, and it can grow organically.
So be that noble person. I believe in you. =)
* Necessary disclaimer that the harsh criticism against "the Pharisees" is located in its particular time, and is in the context of criticizing abuse and empathic gaps among the wealthy and powerful in that time, and is not a criticism of Judaism itself, or even of religious figures in general.
Oh, we've got a lot more than just hope, my friend, but this hope is an [anchor for our souls](biblegateway.com/passage/?sear… for our soulsversion=NLT). 😁
I've wondered about combining this with having all parts of the OS userland written or translated to Rust. Just watching for supply chain issues during compile time may be better than hoping supply chain issues don't happen at runtime.
I don't know much about Rust, but they seme to be following the npm philosophy of "just throw hundreds of spidering nested dependencies at the problem."
Trying to compile even a small rust project on a raspberry pi-like device is not a fun time.
By virtue of that, and the very "Chesterton's Fence bulldozer" attitude of the Rust boosters, I'm not a huge fan of it.
Surprised that the backlash hasn't lead to someone assembling a desktop-oriented NetBSD. - disk encryption in the installer - GUI frontend for PKGIN - maybe even Wine, when @hikari releases Loss32 (it'd be funny to have a BSD that catered to disgruntled Windows users more directly than any Linux)
#NetBSD definitely deserves some love for being one of the very few, and perhaps the most featureful Operating Systems that has a strong #NOAi stance.❤️🔥
I definitely want to start supporting them. I need to get on that.
It’s a difficult thing to gauge what’s most desirable. For instance, NetBSD has no ability to install and run NVIDIA drivers, unlike FreeBSD and Linux. Some think that’s a bad thing, and some consider it a good thing.
In the case of “AI”, people say NetBSD will be left behind, but that’s a story we’ve heard for ages and will continue to hear. After all, Debian folks, in spite of all their funding and their corporate paid developers, can’t support non-mainstream things, like 32 bit x86, and seriously suggest dropping portability because it costs them too much time and energy.
So if NetBSD can support VAX, SuperH, Alpha, 32 bit x86, m68k and others, but Debian is having trouble supporting just six architectures, I think NetBSD is doing something right.
The problem with NetBSD being a good replacement desktop OS is that it runs well on the hardware it supports, so if you choose your hardware for NetBSD, you’ll likely be happy. But you can’t just assume that you’ll get accelerated video or that your wifi card will work on any randomly chosen system.
I'm squarely in the camp "there no chance for non-Win/Lin/Mac to catch up on drivers, workarounds for hardware bugs, and architecture support", so yeah, the kernel is something to live with. NetBSD is famous for "runs on your toaster", but I'm not sure if that's even still true for stuff newer than, let's say, 2015.
Linux has a better chance to run on non-x86 stuff that "new"…
A hybrid solution is your best bet. I run #FreeBSD, #OpenBSD, and various #Linux distros as the case requires. We set sail for the most virtuous heading we can manage, and we muddle along and pick up new skills along the way. It's a journey. ;)
If #NetBSD doesn't work on a particular bit of hardware, maybe try Open, then Free, then maybe try a principled #Linux distro like #Slackware or #Void. If you end up with Ubuntu or something, hey, you did your best.
Damien Malcolm
in reply to R.L. Dane 🍵 • • •R.L. Dane 🍵
in reply to Damien Malcolm • • •It has a lot of meanings but the most recent definition is content or code generated by large language models.
But it can also refer to slipshod programming practices in general.
Franklin
in reply to R.L. Dane 🍵 • • •R.L. Dane 🍵
in reply to Franklin • • •Yes, the devil is obviously in the details. I would start off with: let's not include any projects that are wholly generated by large language models and work the debate from there.
I would also highly endorse picking alternatives to major projects that have turned to using large language models to drive development.
I don't know to what extent the Vim project is using large language models, but Vim Classic looks like a nice project to pick up as an alternative.
Dendrobatus Azureus
in reply to R.L. Dane 🍵 • • •Point me please, to projects which are heavily dependent on LLM code generation which are older than 10 years.
The Linux distributions I use, have no code which is 100% LLM generated
@rl_dane @FranklinFrank
#LLM #slop #hallucinations #AI #programming #coding
R.L. Dane 🍵
in reply to Dendrobatus Azureus • • •I'm not sure how heavily is "heavily," but I've heard that both vim and tmux are accepting slop "contributions."
The Linux kernel, as well.
How prevalent that slop is, I don't know.
tmux: codeberg.org/ethical-foss/open…
vim: codeberg.org/ethical-foss/open…
open-slopware
Codeberg.orgDendrobatus Azureus
in reply to R.L. Dane 🍵 • • •I've seen where Torvalds said that he considers them as just another tool in the Arsenal, he doesn't really care, if the code is good.
He doesn't want his time to be wasted He'll scream and shout if an LLM creates that time pit
These following words an extreme version of me would say
In practice that is impossible. If you drive a modern car it has the Linux kernel. If you have a smart TV or more you're also using the tainted kernel. Even if you have a stick which also streams or a camera you will have a Linux kernel in many cases.
These LLMs are an infection of the planet's code base
Since you're already using BSD a solution would be to cut using Linux on your computers drastically
@rl_dane @FranklinFrank
#LLM #slop #hallucinations #AI #programming #coding
R.L. Dane 🍵
in reply to Dendrobatus Azureus • • •There's no good solution. Well, there's no perfect solution.
We mitigate the bad as much as we reasonably can while we wade chest deep through the muck of dystopia.
¯\_(ツ)_/¯Artur Manuel
in reply to R.L. Dane 🍵 • • •Artur Manuel
in reply to Artur Manuel • • •R.L. Dane 🍵
in reply to Artur Manuel • • •This is obviously where the rubber meets the road.
It's never going to be easy, and it's never going to be perfect, but I think making efforts in the direction of virtue is always worthwhile.
Jonathan Lamothe
in reply to Artur Manuel • •like this
Dragon of BSDCafe and goldfish like this.
R.L. Dane 🍵
in reply to Jonathan Lamothe • • •Totally.
But I do eat vegan sometimes, and I do switch out slop projects for non/pre-slop forks when possible.
The "impossibility" of "totality/perfection" isn't as important as the very real steps we make in the right direction.
Edit: typo
Bitslingers-R-Us likes this.
Jonathan Lamothe
in reply to R.L. Dane 🍵 • •pixx
in reply to R.L. Dane 🍵 • • •Did you mean: BSD?
(/joking.)
R.L. Dane 🍵
in reply to pixx • • •pixx
in reply to R.L. Dane 🍵 • • •R.L. Dane 🍵
in reply to pixx • • •From what I've heard, they still haven't made any comment about tmux including slop, which is now in base.
If I am mistaken, I would very much like to know.
pixx
in reply to R.L. Dane 🍵 • • •bpl
in reply to R.L. Dane 🍵 • • •R.L. Dane 🍵
in reply to bpl • • •bpl
in reply to R.L. Dane 🍵 • • •We have it. It is called TempleOS.
To be a little more serious, which distro maintainers will clean kernel from slop?
R.L. Dane 🍵
in reply to bpl • • •bpl
in reply to R.L. Dane 🍵 • • •R.L. Dane 🍵
in reply to bpl • • •Man, I dont know what to say. If someone can't see what's 100m down the road, what do you even say?
"Maybe don't drive."?!? 😄
bpl
in reply to R.L. Dane 🍵 • • •R.L. Dane 🍵
in reply to bpl • • •I'll admit it's an exaggeration, but accomplishing goals in the short-term with no regard to long-term consequences is still foolish and myopic.
FOSS is not about code. FOSS isn't really that much about software.
It's a virtue thing.
bpl
in reply to R.L. Dane 🍵 • • •R.L. Dane 🍵
in reply to bpl • • •Forgive the religious analogy (if that's a dicey subject for you), but I'm reminded of the saying, "Beware the Leaven of the Pharisees*).
Destructive ideology and praxis worm their way in a little at a time, but the opposite is also true! A handful of people with noble aims and character can truly affect change a little at a time, and it can grow organically.
So be that noble person. I believe in you. =)
* Necessary disclaimer that the harsh criticism against "the Pharisees" is located in its particular time, and is in the context of criticizing abuse and empathic gaps among the wealthy and powerful in that time, and is not a criticism of Judaism itself, or even of religious figures in general.
bpl
in reply to R.L. Dane 🍵 • • •R.L. Dane 🍵
in reply to bpl • • •Hebrews 6:19anchor - - Bible Gateway
www.biblegateway.comDouglas Floyd
in reply to R.L. Dane 🍵 • • •R.L. Dane 🍵
in reply to Douglas Floyd • • •Douglas Floyd
in reply to R.L. Dane 🍵 • • •R.L. Dane 🍵
in reply to Douglas Floyd • • •I don't know much about Rust, but they seme to be following the npm philosophy of "just throw hundreds of spidering nested dependencies at the problem."
Trying to compile even a small rust project on a raspberry pi-like device is not a fun time.
By virtue of that, and the very "Chesterton's Fence bulldozer" attitude of the Rust boosters, I'm not a huge fan of it.
Edit: typo, typing on glass. #ShrimpFingers #StrongBad
Douglas Floyd
in reply to R.L. Dane 🍵 • • •R.L. Dane 🍵
in reply to Douglas Floyd • • •Magitian
in reply to R.L. Dane 🍵 • • •R.L. Dane 🍵
in reply to Magitian • • •#TIL!!!
fil-c.org/
Fil-C
fil-c.orgretro
in reply to R.L. Dane 🍵 • • •Moses Izumi
in reply to R.L. Dane 🍵 • • •Surprised that the backlash hasn't lead to someone assembling a desktop-oriented NetBSD.
- disk encryption in the installer
- GUI frontend for PKGIN
- maybe even Wine, when @hikari releases Loss32 (it'd be funny to have a BSD that catered to disgruntled Windows users more directly than any Linux)
cc @AnachronistJohn
R.L. Dane 🍵
in reply to Moses Izumi • • •#NetBSD definitely deserves some love for being one of the very few, and perhaps the most featureful Operating Systems that has a strong #NOAi stance.❤️🔥
I definitely want to start supporting them. I need to get on that.
Bitslingers-R-Us
in reply to R.L. Dane 🍵 • • •It’s a difficult thing to gauge what’s most desirable. For instance, NetBSD has no ability to install and run NVIDIA drivers, unlike FreeBSD and Linux. Some think that’s a bad thing, and some consider it a good thing.
In the case of “AI”, people say NetBSD will be left behind, but that’s a story we’ve heard for ages and will continue to hear. After all, Debian folks, in spite of all their funding and their corporate paid developers, can’t support non-mainstream things, like 32 bit x86, and seriously suggest dropping portability because it costs them too much time and energy.
So if NetBSD can support VAX, SuperH, Alpha, 32 bit x86, m68k and others, but Debian is having trouble supporting just six architectures, I think NetBSD is doing something right.
The problem with NetBSD being a good replacement desktop OS is that it runs well on the hardware it supports, so if you choose your hardware for NetBSD, you’ll likely be happy. But you can’t just assume that you’ll get accelerated video or that your wifi card will work on any randomly chosen system.
R.L. Dane 🍵
in reply to Bitslingers-R-Us • • •DHeadshot's Alt
in reply to R.L. Dane 🍵 • • •R.L. Dane 🍵
in reply to DHeadshot's Alt • • •No idea, but there's always the kernel. I dunno.
No zero-sum game. We do the best we can, and try to make the principled stance as much as we're able.
"All or Nothing" is the anti-rallying-cry of the soulless usurers that would rather you not even try.
Forget that junk. 😁
Patrick Georgi
in reply to R.L. Dane 🍵 • • •I'm squarely in the camp "there no chance for non-Win/Lin/Mac to catch up on drivers, workarounds for hardware bugs, and architecture support", so yeah, the kernel is something to live with. NetBSD is famous for "runs on your toaster", but I'm not sure if that's even still true for stuff newer than, let's say, 2015.
Linux has a better chance to run on non-x86 stuff that "new"…
R.L. Dane 🍵
in reply to Patrick Georgi • • •A hybrid solution is your best bet. I run #FreeBSD, #OpenBSD, and various #Linux distros as the case requires. We set sail for the most virtuous heading we can manage, and we muddle along and pick up new skills along the way. It's a journey. ;)
If #NetBSD doesn't work on a particular bit of hardware, maybe try Open, then Free, then maybe try a principled #Linux distro like #Slackware or #Void. If you end up with Ubuntu or something, hey, you did your best.
Keep chipping away at the problem. 😁