Post B4SBSwZbJoFdIQSJvc by jbc@mathstodon.xyz
(DIR) More posts by jbc@mathstodon.xyz
(DIR) Post #B4QSgxcjWG5LVsGq5w by phf@dmv.community
0 likes, 0 repeats
I only just got started on this, but maybe someone else is further along? I am trying to find out what the last commit of the Linux kernel is that's most likely free of LLM-generated slop. I am "militant" in this, so I don't care if it was "reviewed by a human" before it went in, that doesn't make it better in my view. The quick deductions I was able to make earlier today:- Sep 4 2025, commit 913e65a2fe1a16fa253c4a016e2306b2cf9ffef8 has the first "official" aka "documented via Assisted-by:" LLM slop- Jul 27 2025, commit 038d61fd642278bab63ee8ef722c50d10ab01e8f is Linux 6.16 so that might still be "clean" as it were; later stable kernels in that series would need to be checked- Nov 17 2024, commit adc218676eef25575469234709c2d87185ca223a is Linux 6.12 so that's probably the last "longterm" kernel that could be "clean"; later stable kernels in that series would need to be checked againAll in all it seems to me that some 6.12.y kernel is definitely the last one I'd want to use. Now given that I only run Linux on ancient hardware, that's probably not a big deal for me; your mileage may obviously vary.Anyone else have a better take already? Aside from "you worry too much, just use the new kernels, they're fine" because that's not really helpful to me. š#slop #linux #kernel #noslop
(DIR) Post #B4QSgy0q4dMqidY5fU by jbc@mathstodon.xyz
0 likes, 0 repeats
@phf I've been wondering about this too, in a general sense, which OS's will have non-LLM-touched kernels. From my little bit of looking around, I've seen explicit no-LLM statements from Redox (that someone mentioned), and NetBSD (that someone else mentioned).But both aren't using the Linux kernel. If the Linux kernel accepts LLM contributions, what will Linux-Libre, Guix, Trisquel (as in, the "free-distros" https://www.gnu.org/distros/free-distros.html) etc, do.I wonder if distros like, say, Devuan, who took a stance against systemd (now looking like they'll accept LLM contributions), and Void Linux, as examples, will be taking a strong stance too.@devuan @jaromil @lxo @freedo @civodul @guix I could think of more people but that's loads, pardon the mass tag but in case anyone wants to weigh in, I think it's an important topic :)
(DIR) Post #B4QSgyVKFHkoFBoRBg by lxo@snac.lx.oliva.nom.br
0 likes, 0 repeats
I don't think Linux-libre as a project would set out to clean up LLM-generated code from Linux.not only because that's not necessary to attain the goal of a freedom-respecting kernel, but because identifying and removing such code would probably make the project unsustainable.finding embedded blobs and blob requests turned out to be reasonably easy to automate, despite the large number of false positives that require manual intervention.I don't see that recognizing LLM-generated code is automatable. heck, I'm not even sure it can be done at all in general, whether algorithmically or intuitively.it would be interesting if someone with a lot more time in one's hands were to set out to identify this kind of code and strip it out.CC: @phf@dmv.community @devuan@toot.community @jaromil@mastodon.social @freedo@mastodon.social @civodul@toot.aquilenet.fr @guix@hachyderm.io
(DIR) Post #B4QcHy1Nu3CF33WQ8O by civodul@toot.aquilenet.fr
0 likes, 0 repeats
@jbc I donāt see an easy way out unfortunately, but the least we can do is create āzones of resistanceā: projects that value empowerment, human connections, knowledge sharing, creativityāthings that are central to free software as I understand it.Perhaps completely avoiding LLM-riddled code is hard in the short term, but we can start looking forward for other ways, and maybe accept eventual disconnect?@guix @freedo @lxo @jaromil @devuan @phf
(DIR) Post #B4SBSwZbJoFdIQSJvc by jbc@mathstodon.xyz
0 likes, 0 repeats
@civodul Yes, I am with you there. There is a sort of ideological blindness (although the word feels a bit strong...) which can impinge on the values you list there, of empowerment, knowledge sharing, creativity, etc. The four freedoms are a means to an end, and only one of the various means. Sometimes giving a little ground here and there, practically, and keeping spaces open, is the best long-term strategy.Still, a sad situation, I must say.Maybe kernels are bound to get big, bound to get centralised, and bound to be a sensitive point where power accrues, in that sense. Or maybe software generally, it seems to also happen with browsers, and init systems, and ...The recent wonderful developments with the Hurd come to mind as perhaps relevant. I know there's lots of work to be done, but that's a glimmer of hope.I wonder will we see a little upsurge in interest in projects like the Hurd, and other alternative spaces - 9front, Mezzano, Uxn/Varvara, etc.