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.

True. Also, if this is really Leah, congrats on the release and thanks for all your hard work on this over the years.

yes i am leah rowe

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.

> U-Boot upstream itself is staunchly anti-AI, at least at the time of this release, and much discussion of the above was had on their mailing list.

I saw this as well, which is funny because I've sent plenty of patches written using AI assistance to upstream U-Boot. It was my understanding that U-Boot was mostly following kernel conventions in general as many U-Boot drivers share code(in addition to the actual subsystem maintainers themselves) with their kernel equivalents.

> 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".

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.

the kernel is like 20% AI code now

> 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

No. No it is not, despite how many times AI proponents like to claim it is.

> No. No it is not, despite how many times AI proponents like to claim it is.

Why do you think there isn't a huge difference? I've used AI tools over this time period and the difference is very obvious.

I have learned to treat statements like that as a general red flag.

Someone who acts like a radical on practical issues will almost certainly act like a radical in other areas as well - including areas that matter to me.

There are debates to be had on every technology, but foaming-at-the-mouth kind of talk is a sure sign of a maintainer (and by extension a project) I want nothing to do with.

I respect projects with a no AI policy, but if that policy starts with the words “fuck no”, I’m out of there.

It's possible this type of "radical" behavior is why this project exists in the first place. I'm willing to bet if the Libreboot maintainer(s) were not "radical" they'd just be using a Mac and be content with a closed source bootloader.

Not to say this "radical" behavior is helpful, and I understand why people don't like it.

The timeless debate of separating art from the artist.

In another project (literally: "Untitled") of theirs they are explicit about motivation:

> This is to fight against the trend of crappy github-powered websites that plague the internet.

I don't really see it as a question of "separating art from the artist". That's usually invoked when other aspects of the personal life of the artist has the potential to distract from the art itself.

The parent comment is closer to saying that Picasso wouldn't have been Picasso if in an alternate universe he had avoided controversial/politically charged subjects like the Spanish Civil War and instead appealed to the lowest common denominator for a mainstream commercial audience to sell postcards.

AI in its current form is a commercial product created from stolen labor.

I think there are extremely legitimate reasons to be critical of that part at the very least, and I don't think it's a particularly "radical" stance within Free Software, which is fundamentally conscientious of such questions.

(I don't know whether the Libreboot authors have this particular point in mind.)

All things are built on knowledge that came before it. In what way is AI built on stolen labor?

Has anyone who contributed to producing the wealth of human knowledge, art, code, and literature making up the training data been compensated in any way?

I'm certainly still waiting for my check.

Well since the early 18th Century (in a limited way) copyright rights have been given to creators - the overwhelming majority of countries are signatories to international treaties (for the last 100 years) that give creators control of created artistic works (which has been deemed to include program code).

Exploitation of those rights is down to individuals, only since Google came on the scene has any company been able to get away with broad ranging infringement of these rights without censure.

As for your cheque, you have the right to sell your work. No-one is obliged to buy it, of course. You also, under copyright, have the right to make a license to exchange use of your works for binding the users to conditions of release of their derivative/associated works ([F]OSS licensing).

You still have the right to sell it, and if ML models have been trained on those works you have the right to seek compensation.

That already didn't happen, regardless of AI. The thing about freely sharing knowledge is that people take that knowledge and use it to build further knowledge that helps you.

You might say that the fact LLMs are being provided as services by big techs invalidate that. But some people taking the provided knowledge for themselves has also always happened. More importantly, though, is that big tech provided LLMs aren't the only way to access the technology. Open weights and local models exist.

Well, it was literally stolen in some cases, for starters.

How do you steal knowledge? Knowledge shouldn't be locked up.

One thing is that most if not all models more likely than not were trained on leaked Microsoft and other proprietary code sets.

For projects like WINE or ReactOS that absolutely have to enforce hard firewalls between people with "insider knowledge" to avoid contamination and resulting legal issues, this alone makes the use of AI for coding highly problematic.

If you believe that, then why aren't LLMs free to use for every person on Earth?

If you want anybody to keep making anything, including programmers, artists, and writers, you're going to have to pay them somehow.

Anthropic and OpenAI would not have a product at all without the contributions of thousands of non-consenting humans. Yet they somehow have the gall to charge customers a premium.

Anthropic and OpenAI aren't the only ways to use LLMs. There are plenty of LLMs where you can download the weights and run them locally. There are even others that you can train yourself (see the LLM360 family).

You're paying for compute?

They refuse to release the models, the training method and, training data. They don't even want you to ask it too many questions lest you teach another ai. Very "open".

I'm all for it, free AI allotment and universal income is the future.

When your project is literally writing a BIOS/ UEFI alternative that exists for the purpose of making base runtime systems open and verifiable and to improve the user’s ability to trust in their system, an opposition to unverified machine generated code seems not only justifiable but sensible. If Leah were not taking steps to mitigate generated code in the project, the project would no longer meet my needs as a Libreboot user.

> Someone who acts like a radical on practical issues will almost certainly act like a radical in other areas as well - including areas that matter to me.

Not using LLMs is a practical choice. The tech doesn't work, and if you let it run amok in your software, your software becomes crap. I try to avoid projects that use LLMs for development as much as I can, because those projects have a much higher likelihood of being a buggy mess.

Well, yes, this is a project to create a fully libre, GPL'd boot chain free of binary blobs. The few users I know stick with aging ThinkPads. I'm not sure what you expected.

We've reached the godwin point quite quickly.

You realize that it is their "radicalism" that gives us the Libreboot project to begin with, right?

You make it sound like it's required to have nice, free things.

it absolutely is. appeasement never worked. i put my foot to the floor and that's it. without me, there would be no libreboot at all.

Richard Stallman was a noted centrist for decades after all

Hah! Glad I'm not the only one who has this theory https://news.ycombinator.com/item?id=50104114

Yeah its quite the contrast to the recent QGIS core "no AI" policy that very pointedly had no emotive language at all.

I find it hard to square treating that like such a red flag while supporting free open source software more generally. The entire ecosystem is rife with ethics/morals driving the initiative. There is a lot of flag planting and red line drawing.

People say AI or not, if the thing is good then it should be used. But if a group actively rejects it (which is valid even if I’m not that militant myself) it compromises the project suddenly?

Yes, anti fascism is a radical position these days.

Already in 2022, before the rise of these LLMs, there was a book "Resisting AI: An Anti-fascist Approach to Artificial Intelligence" by Dan McQuillan.

And then:

> The rapid development of digital technologies, including applications of artificial intelligence (AI), is having a significant impact on the social, economic, and political life. From the way individuals communicate and form relationships to the methods by which political discourse and economic transactions occur, digital technologies increasingly mediate our lives and societies. But while presented as milestones in innovation and progress, these technological transformations have also raised concerns about democracy (Nemitz 2018; Kreps and Kriner 2023; Jungherr 2023; Coeckelbergh 2024) and seem to introduce and support mechanisms of control, forms of organization, and ideological patterns that bear striking resemblances to historical fascist phenomena.

https://link.springer.com/article/10.1007/s00146-026-02862-9

Further,

> being plausible but slightly wrong and un-auditable-at scale-is the killer feature of LLMs, not a bug that will ever be meaningfully addressed, and this combination of properties makes it an essentially fascist technology. By “fascist” in this context, I mean that it is well suited to centralizing authority, eliminating checks on that authority and advancing an anti-science agenda.

https://blog.bgcarlisle.com/2025/05/16/a-plausible-scalable-...

Marc Andreessen have called one of the two authors of the very Fascist Manifesto his patron saint. Search for Marinetti on https://a16z.com/the-techno-optimist-manifesto/

A very influential blogger, Curtis Yarvin who have started Dark Enlightenment, the philosophy behind it all regularly posts straight nazi shit. He also has influenced JD Vance and Peter Thiel who have been instrumental in the creation of OpenAI. https://www.wired.com/story/book-excerpt-the-optimist-open-a... More on Dark Enlightenment https://www.cccb.org/en/w/articles/nick-land-or-the-origins-... and https://qz.com/1007144/the-neo-fascist-philosophy-that-under... "a few consistent themes, circling around technology, warfare, feudalism, corporate power, and racism".

I know this won't be popular with this crowd but most of you have become supporters of the rising fascism in the United States by not resisting these LLMs.

US Vice Presidents have a history of inventing important new computer technologies

I wouldn't trust their products simply because AI as a tool works and their refusal to use it means their software will be worse off for it.

Personally I treat whinging about other people's ideals as a red flag.

It's libreboot. The entire point of its creation was to take coreboot and rip out the non-libre blobs. Its author is trans (IIRC), which also carries its own very pointed perspective on the world.

Some of it goes too far in my own opinion - I have no problem trusting AMD's final microcode for the Opteron 63xx any differently than the baked-in mask for the 62xx. But regardless, I respect someone who is pushing the whole envelope as they see it. At the very least their effort creates a lot of things I do care about!

Likewise, it if claims something is “vibe coded” when it clearly is not (such as U-Boot).

Agentic AI has allowed 86Box to make massive strides forward. This includes a substantial contribution to emulate the Intel Inboard 386 that was created by someone who describes himself as a non-programmer. The community is now bigger and stronger, although we’ve had some aches and pains with slop AI generated PRs.

The same goes for Gravity Linux which is booting in my M4 Macs with working GPU and most other peripherals. What used to take years now takes weeks, so we can do much more thorough testing and ultimately have a better end product.

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.

This list seems...odd. For instance, the list decries the permissive AI policy of the Linux kernel, of Fedora, of Bazzite/Bluefin/etc...and then includes Secureblue as an alternative...?

Secureblue is a neat project, but as you say, this would make more sense as a generic discovery list. If you want to avoid projects with a permissive AI policy, you should probably take into account that Secureblue is based on bluebuild (from the Bazzite team), Fedora, Linux, etc etc etc.

Yeah, I saw this "open-slopware" list listing many battle-tested web servers as "permissive AI policy", while one of the alternatives (not all though, some inherit battle-testing) isn't really battle-tested. In fact, I saw entangled codebase and not-so-good coding practices.

> software discovery list

You're not kidding, I feel like this is better than most of those awesome-X lists that were popular for a while.

It is indeed a list, though not everyone will use it the same way!

But will you still feel this way once you try to actually use that software?

Considering how popular many of these projects are, I (and likely many others on HN) already do!

So yes, yes we will.

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.

how are they different? did the algorithms upon which they operate suddenly change?

>how are they different?

i do not believe you are asking that question in good faith.

and, if you are the leah who wrote the policy, i am positive this would be a completely fruitless discussion as you are obviously entrenched in your beliefs. i am not under the delusion that anything i could say, show, or prove to you would change your mind.

bots are unworthy of any faith.

calling anyone with a different view from you a bot does nothing except make you look immature, and just proves my point: you aren't engaging in good faith, and you don't want to actually have a conversation. i'm happy we both don't need to waste time on one.

good luck with your project. i'll mark this one down as "like the art, dislike the artist"

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

Ai and privacy in the same sentence is wierd. You supported your argument, I guess, but unless you are using local ai, the developer would be sacrificing their own privacy.

>the developer would be sacrificing their own privacy

How so?

Something about having a bot controlled by a third party comb your entire codebase and make changes on your behalf strikes me as not the most privacy-friendly approach to software. I know your question wasn't being asked in good faith, but I've answered it honestly.

It was asked in good faith.

Going by this definition [1]:

>Privacy is the assurance that your data is only seen by the parties you intend to view it.

I’ve been assuming we’re using open source software. When developing open source, you’re putting your code out publicly. Your code is not private data.

As far as the agent acting on your computer, you can easily use Claude Code on the web on Anthropic’s VMs, or just run it in something like UTM or another user on your laptop.

So I don’t see how this is a big loss of privacy. By the definition, you’re intending Anthropic to see your code just as anyone else can.

Ways you could use AI in a non-privacy respecting way would be like letting it read all your personal notes while assuming the AI company will not share them or look at them. I don’t see code as sensitive like this.

Your prompts, pattern of speech, usage patterns, when you work, stuff you say to the LLM besides coding related. Those would be a fair argument for compromising the privacy of the developer. But as long as you consider what you say to be public, then you're intending that data to be out their, so your privacy isn't being compromised. You could make the same argument about developing in the open on GitHub. Anyone can learn about your usage patterns, time zone, etc. It is also fair to say you're giving that AI company more power over you by giving them exclusively that information, while on GitHub it would be information given to everyone. .

[1] https://www.privacyguides.org/en/basics/why-privacy-matters/

You may not, but that entirely comes down to who you're willing to trust. Its certainly not unreasonable for an individual to handle information deemed too sensitive to be allowed to be exfiltrated to a third party. Your use case is not the same as the entire world's.

The comment I replied to was saying that "the developer sacrificing their own privacy". I don't think AI for coding significantly invades developers personal privacy.

The current hope is to eventually upstream the “fork” (Gravity) into the Linux kernel. The Asahi project can continue to run in parallel.

The Linux kernel extensively uses AI now; most lkml submissions have an Assisted-by: LLM tag.

Free Software was a moral & ideological issue to Stallman.

I feel people have the right to bring any sort of issue into the projects they make. Nobody is forced to participate.

I get it, but everything is ideological -- whether you want to hear about it or not.

In a world where software exerts considerable control and influence over peoples' lives, your ability to insulate yourself from that influence is a priveledge. Software IS ideological. Free software was created so people can have the freedom to share and collaborate on their own terms. There is an extent to which it gets extreme, but without the GPL we would live in an even more monopolistic "free" market hell world than we already do. That's a moral obligation that spawned a practical one. If no one ever took a moral stance because you find it annoying, the world would be an objectively worse place.

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!

We really don’t need to fit everything into simplistic US political memes.

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.

Are you publishing anywhere that I can follow? In particular, it would be really helpful if you could publish the prompts and workflow, so that the rest of us can more quickly use it to replicate your work on other machines:)

(Signed, the owner of several Chromebooks in need of better firmware)

Cool, that's why open source projects get left behind. The attitude

I think it's better that some people have strong opinions. For example, the world would suck if everyone was rms, but he has nevertheless had a positive impact on the world imo.

RMS is extremely radical but he's also reasonable and consistent unlike these guys. There's also GNU Guix which recently banned AI-assisted contributions [1] due to copyright infringement concerns and licensing doubts. This is an entirely reasonable take for a hardcore free software codebase, it's literally built around this political concept.

On the contrast, libreboot's stuff reads like a parody or a shitpost. It's hard to believe they're being entirely serious.

[1] https://codeberg.org/guix/guix/pulls/11407

Someone can always fork it if they find themselves sufficiently outraged.

Agree in general, though with Libreboot the pedantry is more or less the point of the project. You fork a project and put 'libre' in the name, I personally see that as a statement of dedication and expect you to stick to those guns. The experiment isnt much of an experiment otherwise.

Coreboot still exists.

Libreboot is not a fork of Coreboot.

It's a distribution. That is, they build and distribute firmware images. Coreboot just ships source.

Coreboot's docs lists the variety of distributions: https://doc.coreboot.org/distributions.html

Well, maybe you can bring it into the future with your favorite LLM!

> Cool, that's why open source projects get left behind. The attitude

They're making a political choice. It's a free country, and more power to them.

It's not a choice that I necessarily agree with, but one that may - who knows - prove prescient 5 years down the road.

No one can predict the future, that's what politics are partly about and the reason why diversity of opinion of choice matters.

Do you have a crystal ball?

i don't live in a free country. the UK has enacted several laws impeding fundamental civil liberties in recent years. rolling back on several human rights laws, now they're even removing the right to trial by jury, etc. it's quite troubling actually.

> I'd rather have the project that works

Then more often than not, you want the project that eschews LLMs. They can't program worth a damn.

I find they program very well.

It is bizarre having conversations with some people. There is a reverse engineering framework that had God of War remaster running natively on Linux at 120fps and then people tell me AI can't do anything, when you can download and run it yourself.

I just had it write a bunch of script hooks for gamemoderun.

What you are saying is utter nonsense. I really don't know where to start.

Why would AI matter? If you say legality, I really don't care that much about copyright law (I run a torrent box 24/7), and I would just git clone the repo and put it on tor. That is what people have been doing with plenty of projects that are more legally dubious.

Also, diversity of opinion doesn't necessarily help with survival either. I swear people just say things because other people have said it.

Libre software is a political movement. And it makes sense for libre contributors to be highly skeptical of a tool that may or may not violate copyright, profits from the work of other libre codebases and is controlled by tech giants.

I think there is a deeper point regarding software freedom specifically - if a person is unable to understand the source code of something, then they are less able to modify it. It's why the definition of libre software centers around source code, even though modifying binaries is entirely possible. Despite being able to have a libre vs non-libre disassembler (analogous to proprietary vs open weight AI models), needing to use a tool at all diminishes your own ability to make changes to the code.

Now having said that, AI also increases software freedom in that it enables many people who aren't otherwise able to understand codebases (or even write simple code) to create/modify their own software. When we're talking about AI in the context of libre software, this is the constructive aspect we should be focusing on! Well defined plugin APIs that we know people are going to lay slop upon, etc.

But still, this doesn't have much bearing on a well-established fundamental systems project that needs to remain generally concise and human-understandable.

The lack of political literacy and self-awareness in this thread is embarrassing.

> Having political strings attached is antithetical to the movement.

I believe you may have a rather narrow notion of what politics are.

In my book, politics is the art of making choices when your ability to predict the future is limited, and therefore the willingness, courage and fortitude to make choices under uncertainty.

Under that definition, they're making a choice, one that materially and obviously can't be backed by sound reasoning or logic (because predicting the future is hard), that's politics.

And yet people who are training models need more and more open source software to feed the beast. Quite the conundrum.

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.

Linus's take is just the same nonsensical false equivalence I've seen a million times. He sure has fallen a long way since his glory days.

Someone should ask him if he's also planning on no longer reviewing patches to the kernel and just accepting them unconditionally, since AI is no different from a compiler after all, and nobody reviews compiler outputs.

> the take is don't ban tools

Yes, and that take is bad, because AI is not a tool in the traditional sense. In the software world, tools are generally expected to be deterministic. Would Linus use a compiler that is known to have a random chance to output the wrong instructions? Or an editor that has a random chance to swap something you typed for something else?

> compiler outputs are tested by the compiler projects + the automated testing infra

And AI outputs are tested by the AI companies and the various testing suites that are run on the kernel. If they're really the same like Linus seems to believe, there's no reason to ever read AI generated patches before merging them.

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.

Wrong Pixel.

https://en.wikipedia.org/wiki/Chromebook_Pixel

Which is sad; a Pixel phone using libreboot + EDK2 to offer a "normal" boot path to Linux would be sweet.

Also the Pixelbook :)

This cross-industry corporate naming trend, where each company picks a word or two and then creates a convoluted web of products with overlapping functionality and intended audiences, and expects us to, like, follow along... This trend needs to end. Microsoft Copilot 365 for Azure, meet Gemini Pixel Colab for business, and kindly ritually immolate each other.

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.

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.

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!

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.

Oehhhhhhhhhhh Might check that out.

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.

I realize that, but what's the selling point of Libreboot on Chromebooks when Coreboot is already supported, and it merely merged in support from Coreboot?

Assurance that binary blobs and Intel ME support has been properly removed. It’s possible to do this with Coreboot if you know what you’re doing, but this is an off the shelf configuration.

Nothing has changed about modern Intel CPUs requiring binary blobs. Libreboot is no longer blobless. Canoeboot is blobless. Libreboot is like decaf. It's not caffeine free, it's decreased caffeine.

You’re correct, I guess haven’t been following this over the last few years. It looks like blobs are now merely minimized and ME is neutered with me_cleaner. So the only difference versus stock coreboot is that these minimizations are now the default configurations.

Old Libreboot is now apparently Canoeboot, same dev but different project name.

>"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!