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.
@mrmasterkeyboard @thing making excuses to use this very unethical technology

your privilege is showing mintsuki and gamiee
โ€‹โ€‹

there is no ethical genai usage
@lumi @thing there were two others, but honestly, I don't want to drag anyone but Mint into this. They are responsible for this, no one else.
@mrmasterkeyboard @thing i feel like everyone being ok with the technology is responsible to some extent

there is ofc a gradation, but i still feel they are responsible

@lumi @thing Honestly, I pretty much give up with the whole forking Limine idea. I honestly have no idea how far back that undiscovered AI stuff could have slipped in.

The world is fucked.

@mrmasterkeyboard @thing make a best effort guess and start from there, i would say. eventually you're going to be overwriting the slop while developing it
@lumi @thing I honestly thought of forking from version 4 which was 3 years ago, specifically from the commit before aarch64 support was introduced. It would have made the fork x86,x86_64 only but it would have been easier to manage.