Everyone’s focusing on the AI policy (perhaps because Leah for some reason said this was the most important part of the release), but the UEFI/EDK integration and Chromebook support is a massive step forward. Suddenly Libreboot has multiplied the devices available by many times, and future devices will be much easier to add. This is huge.
They REALLY don't like AI, to the point of "wish I didn't need to rely on GCC and GRUB because they have AI in them" levels of hate AI. See this further down the linked page:
>The fork in question, of U-Boot, is heavily AI vibe-coded and thus useless to Libreboot. This is not mere conjecture; in said aforementioned U-Boot mailing list thread, the author stated thus. We will not, in any way, encourage or facilitate use of AI. It has been made clear that several projects Libreboot uses also have some AI-assisted commits; GCC, GRUB, etc. This is not our fault, but it is my intention that I and others will audit these projects in the future, de-slopping them and possibly even forking them entirely for that very reason.
not that im particularly pro-ai, but it seems a bit silly to rely on a paper about early-2025 ai when people are using late-2026 ai, given how different they are.
Yeah, the (poisoned) AGENTS.md file reads lots like "f*ck AI", which feels like anti-AI dogmatism for me. If I really wanted to use this project, I would use Coreboot instead or fork it to remove proprietary blobs.
I can't use critical software that rejects AI to this degree for privacy reasons.
You can't expect to sufficiently protect your users privacy when not using AI for finding vulnerabilities.
Same thing with Asahi Linux with their highly anti-AI stance. I had a bit of hope when I saw someone was making an LLM assisted fork but it's not the same support.
While MacOS is likely becoming much more secure, Linux distros that reject AI would fall even further behind, if that's possible.
There is a respectable way to approach this and this.
The right way is something like, we've been getting spammed with a bunch of PR's from AI that we find difficult to review (because AI allows the average bob who isn't technically minded to make a PR). We have therefore decided not to allow AI submissions.
---
I think the people who have some moral / ideological issue and bring that into projects kind of feel like clowns to me. I agree with Linus that the point is to make something that people find useful, and obviously you want it to be maintainable.
Saying "it makes you dumber etc" is not related to the project, with all due respect it's non of your fucking business how I learn / retain skills.
Unfortunately this is bad for one of my projects, a slop detector extension... it assumes that AGENTS.md be short in size to say stuff like "You may view and use this code but not edit or commit anything"... this rant is long enough that it classifies as slop itself!
I find this hilarious since I'm actively having my clankers work on porting EDK2 to an SoC that's used in a Chromebook, though not the ones mentioned here.
I can't be the only one who thinks the way they handled that is incredibly disrespectful right?
It's their own business to disallow AI contributions.
But instead of adding that to the Code Of Conduct they chose to knowingly misuse a file to target a group of people they don't like.
If I want to use AI on my copy of that repo, I have to delete that file and consider if the developer has added any more of what is (by intent) basically malware to the source code. Sure the file is just an unhinged rant, but now I have to wonder if they attempted to put some prompt injection in the repo.
I'm surprised Libreboot was able to add all the ChromeOS devices at once, Just adding the 2 ports for Heads hasn't been easy, although I'm not an expert when it comes to Coreboot.
Anyway, I love seeing more support for Chromebooks, they are great devices. Funny enough my Acer Chromebook (Kano) is now more open and more secure than my Framework 13s.
It’s great to see this happening at the same time—Heads has some important features that Libreboot lacks.
It may be harder to port it if those features require neutered (rather than simply removed) blobs. Maybe that’s why the Libreboot port was easier? Not sure, I’m aware of the benefits that Heads provides but I don’t know much about the internals.
It's refreshing to see serious open-source projects adopting a strict policy on LLM-assisted contributions.
Besides considering frontier LLMs a serious threat to humanity, I find LLM-assisted programming simply...not fun! I tolerate only AI-assisted bug reports, as they are genuinely useful.
> Imported all 233 currently supported Chromebooks from the MrChromebox coreboot distro. Baytrail (Kip) tested - others need testing. Source-only in this release (must build from source, no binaries provided).
Nice. I think I loaded MrChromebox onto my Google Pixel some years ago. I should see if it can get Libreboot now.
Neat project. I find their new anti-AI policy to be interesting, but not at all useful to anyone. There are no objective arguments. No evidence of poor code quality in late 2026. No examples of why AI can't help the project. Just a rant.
I am very glad to see people with opinions that flow into what they do, but the question becomes: are you trying to make the best software, or make the most idealistic software? There's a big difference.
I am not at all advocating the use of straight AI slop, but with a policy like that you're opening yourself up for missed bugs, security issues, delayed features, and other things. Especially if you move away from software just because an AI wrote one line of code in it. You can still review the code. If it does the thing right, then use it!
If you want something with more power look into the Dell Latitude 5400 Chromebook Enterprise or the Dell latitude 5300 2-in-1 Chromebook Enterprise. Both of these devices have DDR4 user replaceable memory.
There is also the Framework 13 Chromebook edition, but that seems almost impossible to find now-a-days.
there is upstream code but it's not well-integrated, and google's tree is largely optimised for their own payload called Deptchcharge. mrchromebox tweaks coreboot for use with edk2 so you can use normal operating systems, and the modifications that they make are extensive, e.g. mechanism in EDK2 to update EC firmware at boot time. mrchromebox is, for our purposes, a coreboot distro or indeed its own upstream. libreboot takes mrchromebox and makes several of its own modifications. "just use coreboot" is easier said than done :)
>"Libreboot is free, open source boot firmware replacing proprietary BIOS/UEFI firmware on supported Intel/AMD and ARM64 hardware." [...] MrChromebox supports nearly every Chromebook..."
This is great news! Finally an open-source UEFI replacement which can work on nearly every Chromebook, including used/old Chromebooks!
Now, I haven't reviewed the source... it may still contain binary blobs for various drivers; I don't know. If it doesn't, then that's absolutely awesome! But if it does, then remember that having some of the UEFI firmware code open-source is a huge step forward, and it's only a matter of time before those closed-source binary blobs are reverse engineered (possibly by AI) and/or rewritten from scratch entirely, as open-source codebases...
So, a good step forward for open-source, right-to-repair, understandability of the boot chain, the Chromebook hardware ecosystem (used and new), and tranparency in general!
Everyone’s focusing on the AI policy (perhaps because Leah for some reason said this was the most important part of the release), but the UEFI/EDK integration and Chromebook support is a massive step forward. Suddenly Libreboot has multiplied the devices available by many times, and future devices will be much easier to add. This is huge.
some of the comments about ai policy are probably bots too. it's common these days to see political discourse spammed by bots on projects.
I will finally be able to use my old chromebook for something.
They don't seem to like AI.
https://codeberg.org/libreboot/lbmk/src/branch/master/AGENTS...
They REALLY don't like AI, to the point of "wish I didn't need to rely on GCC and GRUB because they have AI in them" levels of hate AI. See this further down the linked page:
>The fork in question, of U-Boot, is heavily AI vibe-coded and thus useless to Libreboot. This is not mere conjecture; in said aforementioned U-Boot mailing list thread, the author stated thus. We will not, in any way, encourage or facilitate use of AI. It has been made clear that several projects Libreboot uses also have some AI-assisted commits; GCC, GRUB, etc. This is not our fault, but it is my intention that I and others will audit these projects in the future, de-slopping them and possibly even forking them entirely for that very reason.
Some of that reads really funny.
Also
> https://codeberg.org/ethical-foss/open-slopware
Feels more like a software discovery list than an indictment. Thanks for the categorization.
you arent kidding!
>"think AI makes you super hacker? think again: https://arxiv.org/abs/2507.09089"
not that im particularly pro-ai, but it seems a bit silly to rely on a paper about early-2025 ai when people are using late-2026 ai, given how different they are.
Yeah, the (poisoned) AGENTS.md file reads lots like "f*ck AI", which feels like anti-AI dogmatism for me. If I really wanted to use this project, I would use Coreboot instead or fork it to remove proprietary blobs.
I can't use critical software that rejects AI to this degree for privacy reasons.
You can't expect to sufficiently protect your users privacy when not using AI for finding vulnerabilities.
Same thing with Asahi Linux with their highly anti-AI stance. I had a bit of hope when I saw someone was making an LLM assisted fork but it's not the same support.
While MacOS is likely becoming much more secure, Linux distros that reject AI would fall even further behind, if that's possible.
Edit: added critical
There is a respectable way to approach this and this.
The right way is something like, we've been getting spammed with a bunch of PR's from AI that we find difficult to review (because AI allows the average bob who isn't technically minded to make a PR). We have therefore decided not to allow AI submissions.
---
I think the people who have some moral / ideological issue and bring that into projects kind of feel like clowns to me. I agree with Linus that the point is to make something that people find useful, and obviously you want it to be maintainable.
Saying "it makes you dumber etc" is not related to the project, with all due respect it's non of your fucking business how I learn / retain skills.
good!
Okay? Their repo, their rules.
Fork it and use Ai if you have a problem.
Unfortunately this is bad for one of my projects, a slop detector extension... it assumes that AGENTS.md be short in size to say stuff like "You may view and use this code but not edit or commit anything"... this rant is long enough that it classifies as slop itself!
Huh, good to see sane people still exist. Good on them.
I find this hilarious since I'm actively having my clankers work on porting EDK2 to an SoC that's used in a Chromebook, though not the ones mentioned here.
Cool, that's why open source projects get left behind. The attitude
I can't be the only one who thinks the way they handled that is incredibly disrespectful right?
It's their own business to disallow AI contributions. But instead of adding that to the Code Of Conduct they chose to knowingly misuse a file to target a group of people they don't like.
If I want to use AI on my copy of that repo, I have to delete that file and consider if the developer has added any more of what is (by intent) basically malware to the source code. Sure the file is just an unhinged rant, but now I have to wonder if they attempted to put some prompt injection in the repo.
Anti-AI is rationally and logically incorrect, because it focuses on inputs, rather than outputs.
The Linux kernel has always been focused on outcomes and outputs, which is the right focus. Here's Linus: https://x.com/LundukeJournal/status/2110524360377458786
Outputs: Code quality and long term maintenance matters. Outputs: Serving users with correctness, security and performance matters.
Focus on "purity of input" is a faith-based political filter, not engineering.
Wow, this is awesome! This relates to work I've been doing with the [Heads](https://osresearch.net/) project. Specifically I got a PR merged for the first ChromeOS Port using MrChromebox's code as an upstream dependency: https://github.com/linuxboot/heads/pull/2133
I'm now working on the 2nd ChromeOS device in this PR right now: https://github.com/linuxboot/heads/pull/2225 And there is a 3rd port by someone else: https://github.com/linuxboot/heads/pull/2219
I'm surprised Libreboot was able to add all the ChromeOS devices at once, Just adding the 2 ports for Heads hasn't been easy, although I'm not an expert when it comes to Coreboot.
Anyway, I love seeing more support for Chromebooks, they are great devices. Funny enough my Acer Chromebook (Kano) is now more open and more secure than my Framework 13s.
It’s great to see this happening at the same time—Heads has some important features that Libreboot lacks.
It may be harder to port it if those features require neutered (rather than simply removed) blobs. Maybe that’s why the Libreboot port was easier? Not sure, I’m aware of the benefits that Heads provides but I don’t know much about the internals.
Either way, thanks for your work on this.
It's refreshing to see serious open-source projects adopting a strict policy on LLM-assisted contributions.
Besides considering frontier LLMs a serious threat to humanity, I find LLM-assisted programming simply...not fun! I tolerate only AI-assisted bug reports, as they are genuinely useful.
> Imported all 233 currently supported Chromebooks from the MrChromebox coreboot distro. Baytrail (Kip) tested - others need testing. Source-only in this release (must build from source, no binaries provided).
Nice. I think I loaded MrChromebox onto my Google Pixel some years ago. I should see if it can get Libreboot now.
Getting Libreboot running on a Pixel would be a pretty wild second life for a phone that was never meant to be a Chromebook.
If it runs on Chromebooks does that mean Chromebooks can be made into generic UEFI laptops?
This is interesting given Googlebooks actually use the same boot process as Chromebooks, they just chain into aboot.
Yes. Even before this you could use MrChromebox's UEFI Coreboot on a lot of ChromeOS devices. You can run Linux or even Windows on them.
For Intel/AMD Chromebooks, yes.
Neat project. I find their new anti-AI policy to be interesting, but not at all useful to anyone. There are no objective arguments. No evidence of poor code quality in late 2026. No examples of why AI can't help the project. Just a rant.
I am very glad to see people with opinions that flow into what they do, but the question becomes: are you trying to make the best software, or make the most idealistic software? There's a big difference.
I am not at all advocating the use of straight AI slop, but with a policy like that you're opening yourself up for missed bugs, security issues, delayed features, and other things. Especially if you move away from software just because an AI wrote one line of code in it. You can still review the code. If it does the thing right, then use it!
I'm on a libreboot-only infrastructure and can recommend. It's easy to do and you dont need to keep track of how to configure coreboot.
It just works and that's great.
Nice! I took a 250eu chromebook, turned it into my Linux laptop perfect little machine. A bit slow but 4 cores + 8gb ram will do.
If you want something with more power look into the Dell Latitude 5400 Chromebook Enterprise or the Dell latitude 5300 2-in-1 Chromebook Enterprise. Both of these devices have DDR4 user replaceable memory.
There is also the Framework 13 Chromebook edition, but that seems almost impossible to find now-a-days.
I thought Chromebooks natively came with Coreboot support.
there is upstream code but it's not well-integrated, and google's tree is largely optimised for their own payload called Deptchcharge. mrchromebox tweaks coreboot for use with edk2 so you can use normal operating systems, and the modifications that they make are extensive, e.g. mechanism in EDK2 to update EC firmware at boot time. mrchromebox is, for our purposes, a coreboot distro or indeed its own upstream. libreboot takes mrchromebox and makes several of its own modifications. "just use coreboot" is easier said than done :)
This is Libreboot, not Coreboot. Libreboot removes binary blobs and Intel ME. It’s a freedom-oriented distribution of Coreboot.
>"Libreboot is free, open source boot firmware replacing proprietary BIOS/UEFI firmware on supported Intel/AMD and ARM64 hardware." [...] MrChromebox supports nearly every Chromebook..."
This is great news! Finally an open-source UEFI replacement which can work on nearly every Chromebook, including used/old Chromebooks!
Now, I haven't reviewed the source... it may still contain binary blobs for various drivers; I don't know. If it doesn't, then that's absolutely awesome! But if it does, then remember that having some of the UEFI firmware code open-source is a huge step forward, and it's only a matter of time before those closed-source binary blobs are reverse engineered (possibly by AI) and/or rewritten from scratch entirely, as open-source codebases...
So, a good step forward for open-source, right-to-repair, understandability of the boot chain, the Chromebook hardware ecosystem (used and new), and tranparency in general!