Comment by cromka
4 days ago
> de-slopping them and possibly even forking
Or, hear me out, they could instead just improve and contribute the code they think is suboptimal
4 days ago
> de-slopping them and possibly even forking
Or, hear me out, they could instead just improve and contribute the code they think is suboptimal
I put "de-slopping" in the same bucket as "rolling your own crypto" and "let's rewrite done software in Rust just because".
Seems more like clean room RE to me, or general free software stuff. You can't contribute proprietary code to free software, if someone doesn't agree to a license change you have to remove/rewrite their contributions, if you've seen the Windows source code you aren't allowed to contribute to ReactOS (IIRC), etc. LLMs are black boxes with dubious training data and aren't really "you" writing the code directly, so whether you can then license that is questionable. This is especially important for a project like LibreBoot that is trying to liberate machines. The only "easy" solution I see is to abolish copyright, which would be fine. As it is a lot of software is being tainted and the whole world of free software is in danger. It's a shame people gloss over this because they think LLMs are cool or help productivity or whatever. Everything's been irradiated now. Now if someone wants to guarantee a given project had no AI contributions they have to fork a years-old version and likely lose a lot of good non-LLM code in the process. What a waste of time and resources that is. Setting us way back. This needed to be taken way more seriously on day 0.
That's in the previous half of the sentence you removed:
> ...it is my intention that I and others will audit these projects in the future, de-slopping them...
That's not what it implies to me. And let's not pretend that a person with this approach and this manifesto is going to publish their patches to deslop slopped upstream projects.
contributing to projects that have slop in them has legal liability. you'd have to essentially hardfork to remove the slop from git history and such.
for my part, when i do work on this, what i will do is this: re-use existing nuke.list mechanism in lbmk (used already to delete dubious files, e.g. code files with unclear licensing in u-boot) to delete the slopped files. then provide cleaned versions of the same files, with necessary patching re-written as necessary, and files that use it patched to include e.g. foo.deslop.c instead of foo.c - then git history is removed inside tarballs. filter out the changelogs for projects accordingly.
this is the most reasonable way to do it on projects with very little slop. with projects that become almost entirely slop, a hard fork becomes necessary.
So what OS are you building on and running on the machine? https://codeberg.org/ethical-foss/open-slopware#kernels doesn't seem to list anything I would consider a good alternative to Linux, although illumos or 9front becoming the preferred build environment for libreboot would make my inner nerd happy.
currently debian linux, though i have porting lbmk to openbsd on TODO. with a few small exceptions (e.g. recent tmux patch) they're generally quite hostile to use of AI.
3 replies →
How do you use the Linux kernel?
> think for yourself. AI will only ruin your mind and deskill you. here are some articles:
> think AI makes you super hacker? think again: https://arxiv.org/abs/2507.09089 ["Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"]
> https://blog.codeberg.org/protecting-our-floss-commons-from-...
> consider that the infrastructure for AI is economically unsustainable; when the bubble bursts, and it will, we will suddenly be left with millions of people thoroughly deskilled who will be useless. lots of reeducation needed, and lots of people will just be left behind.
> consider that it is controlled by only a minority of very wealthy individuals; with it, they have unprecedented control over human thought through manipulation of information, and control over what information is presented through filtering (what they call training).
> AI is a threat to the health and democracy of our entire world.
> libreboot will not facilitate its use. AI is the most dangerous technology ever invented by human beings.
...
They have plenty of reasons not to.
> Early-2025 AI
This one especially really just shows they are cherry picking things which support a particular position regardless of the relevance, the difference between Early-2025 AI and Late-2026 AI is absolutely massive. Early 2026 it was reported by Greg Kroah-Hartman that AI bug reports rapidly went from obviously wrong or low quality to being real reports.[0] The kernel now has AI tooling heavily integrated into patch review workflows as well with quite good results.[1]
> They have plenty of reasons not to.
Not really any good reasons however.
[0] https://www.theregister.com/software/2026/03/26/linux-kernel...
[1] https://github.com/sashiko-dev/sashiko
> the difference between Early-2025 AI and Late-2026 AI is absolutely massive
If you only accept papers that were published in reputable venues and analyze LLMs that are less than a month old, you are left with zero useful papers (since writing a useful paper takes longer than a month). It is impossible to have an intellectual discussion if all scientific material is disregarded.
1 reply →
> the difference between Early-2025 AI and Late-2026 AI is absolutely massive
No. No it is not, despite how many times AI proponents like to claim it is.
2 replies →
> when the bubble bursts, and it will, we will suddenly be left with millions of people thoroughly deskilled who will be useless. lots of reeducation needed, and lots of people will just be left behind.
what do you mean by this, that costs will become too high and people won't afford it? hardware won't go up in smoke "when the bubble bursts"
People won't be left without AI/LLMs. They'll be left with less value in their investments. The tech is here to stay, the market discovering the actual commercial value of these products won't change that.