Following what I said in a thread days ago, I repurposed an old Codeberg org I never used.

Introducing Project Anchorage. A (soon-to-be proper) group of users who aim to take back computing from the slop machines and sloperators.

The current goal to, over time, make a non-slop stack. An OS, apps, etc. However, to enforce this, I plan to only let people with a history of resisting/not using AI in.

https://codeberg.org/ProjectAnchorage

Fluxer: https://fluxer.gg/XlrYjF5a
Matrix: #project-anchorage:matrix.org

Project Anchorage

Users who aim to take back computing from the slop machines and sloperators.

Codeberg.org
Echium

A slop-free kernel.

Codeberg.org
Echium/README.md at main

Echium - A slop-free kernel.

Codeberg.org
Bootloaders/protocols, other architectures and languages

Currently, I would focus on x86(_64) as it's the most supported in general and a majority of people would daily drive x86 systems. Later on we could do RISC-V or ARM. I plan to stick to C and architecture-dependent assembly for almost all of this. Zig and Rust use LLVM which has devolved into slo...

Codeberg.org

Also, on a related note, Project Anchorage is open to adding people on who have a history of opposing AI and writing non-AI code.

If you want to be added to the org, just let me know.

I do want to call the OS/userland Echinops as well in the future once Echium is stable enough.
I kind of want to give Project Anchorage a fedi account but I dunno where. mastodon.social is totally out of the question honestly, I wouldn't put it here at all.

I have made a new commit in Echium, bringing in a stable Limine base from limine-c-template and implemented Flanterm!

https://codeberg.org/ProjectAnchorage/Echium/commit/0eae5cb00f954c02ec6564fa124db5af681420c6

Adapt the Limine C Template for Echium, implement Flanterm · 0eae5cb00f

https://codeberg.org/Limine/limine-c-template

Codeberg.org

Everyone, I apologise profusely. Limine contains AI slop introduced by the creator.

The commit mentioned there has been reverted and force-pushed away out of master.

Meanwhile, I've made a PR for Limine in open-slopware. https://codeberg.org/small-hack/open-slopware/pulls/263

#FuckAI

Add Limine

The creator of Limine has started to allow AI slop into the codebase from Claude. They've also been pretty for genAI in the "Low Level / Assembly" Fluxer server in the #off-topic channel, although I'm not really wanting to upload those as this commit is enough proof. I must also mention, there...

Codeberg.org
@mrmasterkeyboard O_O
that was a damn close call...
opening a issue to ban ai contributions NOW
we cannot lose this bootloader, efi boot stubs are a fucking pain :(
(systemd-boot is just...bleh, and grub is dated & bloated)
@mrmasterkeyboard wait hold on.
what about rEFInd?
@thing I'm not even going to begin to fuck with that. Nothing directly compares with Limine at all. Limine made it easier and now we're losing it.
@mrmasterkeyboard I'm aware. but having a fallback is always good.
@thing If Limine doesn't back down from AI, I'm going to fork their org repos under Project Anchorage. I swear to god, I will revert back to fucking v8.x if I have to.
@thing actually though, I don't think the creator will ban AI tbh.

Welp, nice. Now we know that Limine accepts AI and the creator is in favour of it, including one of the people in charge of the OSDev and Low Level / Assembly community on Fluxer who reacted with a thumbs up.

https://codeberg.org/small-hack/open-slopware/pulls/263#issuecomment-12690237

Fuck AI.

cc @gryphonmyers if you want to add Limine to the dirty list

#FuckAI #OpenSource #FOSS #OSDev

@mrmasterkeyboard @gryphonmyers I don't like AI either but can't take that list too seriously either with stuff like this making it in https://codeberg.org/small-hack/open-slopware/issues/234 really? recommending fucking nvdia drivers over mesa??

Now I only use this list to see what projects have a strict no LLM policy and not which ones allow "AI usage", projects letting Claude directly commit/author and a dev replying in a comment section that they used AI one time for *review* are lumped together. To me those scenario's are not the same.

[Discussion]: What is the point of recommending proprietary software with almost certain LLM usage?

### Discussion Topic Reading through this list, I have stumbled upon a strange phenomenon - NVIDIA's and AMD's proprietary GPU drivers being recommended as a replacement of Mesa. Thus, the question is - given NVIDIA's and AMD's explicit focus on generative AI, and their certain (https://www.wsj....

Codeberg.org
@zyx @mrmasterkeyboard as in you think one or two ai generated commits are okay? What makes you think they would stop there though?

@gryphonmyers especially considering what Mintsuki has said.

> "No need to go grep the commits for proof, you can just ask me and I'll tell you that I have no issues with LLM-aided contributions from either me or anybody else as long as the code is solid."

@gryphonmyers @mrmasterkeyboard no as in someone who uses AI to review their own commits not just slop out to it. And only one or two direct AI commits is ok for me, anymore than that and they're dead to me e.g hugo is dead to me but not zola.

@zyx @mrmasterkeyboard ah I see. IMO relying too much on AI code review will eventually lead to cognitive surrender and is likely a precursor to ai generated code so it's still not great. ALSO plenty of maintainers are likely hiding their slop (e.g., from what I can tell, React has no slop commits but they do have an agents.md... very suspicious especially with it being a Meta product)

BTW if you want just a raw list of popular repos with ai commits I made this https://aidirtylist.info/repositories/1

AI Dirty List - Repositories

Tracking which open source repositories contain AI generated code.

The AI Dirty List