Talk Around Town: Two Developers Claim They Cracked Apple's M4 GPU for Linux in About a Month

What Folks Are Chattering About

Well, slap a catfish and call it Tuesday — the tech watering hole known as Hacker News is buzzing louder than a chainsaw at a church picnic. A self-published blog post from a developer going by Cody Ho landed on September 15, 2026, and folks have been passing it around like a dish of deviled eggs at a family reunion, racking up around 266 upvotes and 161 comments according to community aggregators. The gist: Ho's post describes how he and a collaborator named Niklas say they went and assembled a Linux GPU driver for the Apple M4 Mac Mini — in roughly one month flat — by poking at Apple's AGX GPU firmware from the outside using a homemade hypervisor.

Now, before y'all go hollering from the barn roof, let's be crystal clear: this whole story originates from Ho's own blog over at codyho.dev, which is about as peer-reviewed as a note slid under a outhouse door. No independent journalist, hardware reviewer, or technical publication has sat down with the hardware and kicked the tires themselves. What we've got is a very interesting claim drawing a whole lot of eyeballs, and that's worth talking about — but it ain't the same as proven fact.

What Ho's Post Actually Claims

According to Ho's blog post, he and Niklas managed to put together a driver that satisfies the full OpenGL ES 3.0 specification for the M4 Mac Mini and a machine described as the MacBook Neo. Ho's post further states that the whole undertaking was accomplished through clean-room methodology — meaning, the developers say they relied only on behavioral observations captured via live hardware traces from their custom hypervisor, deliberately avoiding any examination of Apple's own binaries. Ho's post specifically frames this as a transparent and verifiable approach using well-established techniques in the reverse-engineering world.

In terms of what Ho's post claims the driver can actually do: according to that same blog post, it can run Minecraft at a stated 200 frames per second, and it reportedly enables both Chrome and Firefox to execute WebGL content on M4 hardware, along with working desktop compositing. Community summaries of the project, including one from thefrontpage.dev, indicate the kernel-side portion was written in Rust and that the team assembled a purpose-built shader compiler from scratch. Now, those are some punchy numbers — but every single one of those figures comes straight from Ho's own post, and not a soul outside the project has checked them against actual hardware yet.

What Is Actually Confirmed by Outside Sources

Here's where the ground gets a mite firmer underfoot. Both Phoronix and Linux Magazine — two publications with solid track records covering Linux hardware — have independently documented that the Asahi Linux project is genuinely stuck on M4 GPU support. According to Phoronix's reporting from late 2025, Apple's SPTM firmware architecture introduced changes that broke the hardware-observation tools Asahi had been using for earlier chips. Linux Magazine separately confirmed that M4 support has been a serious obstacle for the project. This context matters: it tells us the problem Ho and Niklas claim to have cracked is a real and documented hard problem, not something someone dreamed up to make a story sound juicier.

Additionally, Botmonster Tech reported as recently as August 2026 that the Fedora Asahi Remix 44 release — Asahi's consumer-facing Linux distribution — still only officially supports hardware up through the M2 generation. Every M4 machine remains outside the supported list. So whatever Ho and Niklas may or may not have pulled off, the established project's situation on M4 is genuinely as bleak as advertised. Ho's post itself acknowledges the code isn't ready for everyday users yet, but states the intent to get it out as soon as possible and to eventually add Vulkan support — which, to be fair, is the one part of this whole story that even Ho isn't overselling.

The Controversy Mucking Up the Pond

Down in the Hacker News comment thread, somebody lobbed a question that hit the water like a dropped anvil: a commenter alleged that one of the contributors previously worked at Apple and may have walked away with knowledge that ain't exactly in the public domain. That's the kind of allegation that can turn a feel-good barn-raising story into a property-line dispute real fast. According to the Hacker News thread, the contributor in question — identified in the broader discussion as Ho himself — responded directly, stating that during his time at the company he had absolutely no access to internal information or source code related to macOS, SPTM, or Apple Silicon. The dispute sits there, unresolved, like a wet dog nobody wants to claim.

What Remains Completely Unverified

Let's count the unknowns here like we're counting missing fence posts. No independent technical publication has examined the source code to assess whether the clean-room methodology claim holds water. No outside tester has hooked up an M4 Mac Mini and watched Minecraft do what Ho's post says it does. The allegation about proprietary knowledge exposure has not been resolved — and frankly, neither side of that argument has produced documentation to settle it. Whether the custom hypervisor approach genuinely gets around the SPTM barrier that stymied Asahi Linux is an open engineering question that nobody outside the team has evaluated.

The Hacker News aggregation and the community chatter confirms that a whole lot of smart people find this story plausible and interesting — but 'plausible and interesting' and 'independently verified' are about as different as a muddy truck and a luxury sedan. Until somebody with their own M4 hardware and no dog in this fight goes through the code and the methodology, every capability claim in Ho's post should be treated as the developers' own assertion, not as established fact.

Editorial Analysis: Why This Matters Even If It's Half True

This is analysis, not reporting — but it's worth chewing on. If Ho and Niklas's claims survive independent scrutiny, it would represent a meaningful development in the Linux-on-Apple-Silicon story, because the established Asahi Linux project, as documented by Phoronix and Linux Magazine, is genuinely stalled on this exact problem. The M4 generation has been sitting there like a perfectly good tractor that nobody can get started. A pair of independent developers claiming to have found a workaround in a month — using a technique the bigger project apparently didn't try — would be the kind of thing worth watching closely.

That said, the combination of unverified technical claims, a self-published primary source, and an active dispute about one contributor's background makes this about as solid as a dirt road after a three-day rain. The most sensible posture here is to note that Hacker News is interested, that the underlying problem is real and confirmed, and that the claims deserve independent evaluation before anyone treats them as gospel. Keep your boots on and wait for the mud to dry.