> concealing that he is a former Apple engineer with direct contacts to the people involved in Apple Silicon development

This is false. I am a former Apple engineer. I did not conceal it (it's the top item of my resume and my LinkedIn and I made my PR from my public Github with my name attached, as opposed to a pseudonym which is expressly allowed by Asahi policy). I also had no exposure, at all, to any internal information or code about macOS, SPTM, or Apple Silicon during my time there.

I also don't have connections to people involved in Apple Silicon development (and I'd add that this does not mean someone cannot contribute, the question is were they exposed to tainted information, which is absolutely not true in my case). I have many friends who work for Apple (I'm a Stanford alum) but none in Apple Silicon directly.

I disagree with the phrasing of this entire thing, but this statement is demonstrably false.

I find it extremely ironic that big corp openly steals IP en masse to build their models but hackers are still concerned about using same models for their reverse engineering work.

I think at this point the hacking community needs to grow some balls.

Apple is a huge company with strong silo culture. I only interviewed with them, but it feels to me like different orgs are run almost like entirely different companies. If his work didn't concern Mac, it's quite unlikely he'd have any special insider knowledge about it.

I certainly dont care about hiding LLM contributions and all crazy anti-LLM policies, but I really hope author can share process completely so this can be reproduced by someone not working for Apple.

If Apple open sourced its drivers this issue wouldn't exist. AI at last gives the "community" a chance to use the hardware they bought the way they want. It's unreasonable to expect anybody to code this kind of stuff "by hand" when automated tools exist.

Why would anyone care about either of these things in a negative sense?

Isn’t that just saying “he uses modern tools and has subject matter expertise”?

Even if this is the case, this is still a valuable contribution to learn upon.

Now that this work is done and out in the open what in theory would prevent the next generation of LLMs from ingesting it and eventually a non-Apple employee creating yet another driver “from scratch” but with the knowledge of how the hardware works acquired from an LLM or with the help of one?

Basically, aren’t we facing a situation where LLM-assisted knowledge laundering is becoming a thing?

Linking to another HN comment: https://news.ycombinator.com/item?id=49719480

> and this creates a major conflict.

Apparently. But Apple should be ashamed of themselves for that fact. What are they so afraid of? That Mac OS is so inferior to Linux that if they publish specs so that a driver can be made, that everyone will wipe Mac OS off their disks like it's Windows ME??

Once again, modern Apple is allergic to competing on their product's merits, clinging to force as though it's the only way anyone will choose them. Which is insane to me given how loyal their following is. I'm typing this shit on Mac OS right now.

Apple comes off like the most insecure corporate culture in history.

Resume says : "Machine Learning Engineer".

Exactly how does that equate to knowing details of Apple's GPU implementation? Apple is a massive company.

> All this work is tainted since the poster is ex-Apple[1].

So if I worked as a janitor at Apple, I couldn't contribute anymore?

There were and are many important pieces of Linux kernel that live out of tree; ZFS is a big example.

The problem with this driver is not licensing or code quality; I assume it's under a threat of receiving C&D letter, or maybe also a legal suit for breaking some NDA.

Very sad. I really want to get Linux on newer Apple chips working flawlessly but I can understand the legal minefield about this particular work.

> There is no way Linux will take that code, since people from Apple also contribute to Linux and this creates a major conflict.

I guess author can cleanup the code and try upstream it themself. Then let's see what Linus thinks of it.

Might be one of the only use cases where LLMs are necessary to succeed. Can't imagine the pain of reverse engineering a technology of this scale and "secrecy".

The problem I’m finding, at least with today’s models, is that it produces disposable software. It’s not good at making well-architected, durable software. Stuff that could be maintained and bug-fixed.

I mean you can get good stuff out of it if you know what you are doing and guide it, but if you just say “here’s a regression suite. Write an implementation that passes” you will get something that works for a while but ages quickly and will need to be thrown away.

I’m sure it’s really easy when you can get help from the people who made the chip or write the Apple drivers.

:) I think we have a surprise in store here. Asahi don't have a monopoly over Linux for Apple Silicon, and upstream Linux absolutely does *NOT* ban LLMs.

Asahi's long term goal is to get everything possible merged into the (actually) upstream projects anyways so any distro can just work. It'd be nice to see that continue rather than have forks on forks for the sake of singular differences (and it looks like proper upstreaming is what they are going after per the Remaining Work section).

I imagine either they or others can take their discoveries and write a real driver now, though. The hard part was always the reversing the black box system.

For the kernel driver it's literally just: run the hypervisor, wait for the kick, save the UAT state, replay the whole thing, make sure the output pages change, then just follow the pointer to initdata until you've built the whole tree from scratch. LLM handles the rest.

I still can't quite believe it either!

Great observation, two things:

- During my time at Apple I never saw any of the macOS source code, at all, even for userspace components. I had not even heard of things like SPTM.

- I have not worked there since June 2025

I don't believe that there's any risk due to my former Apple employment. As another example, WINE does not ban all former Microsoft employees, they just ban anyone who has ever looked at the Windows source code. If I felt there was even a chance that my employment at Apple may have exposed me to relevant internal secrets, I would refrain from contributing to community projects.

If contributor policies are enough to make projects "dead in the water" for you, the rest of Linux' desktop efforts will leave you appalled.

TL;DR:

1. We want to guarantee our work is not a "derivative work" of anything Apple wrote.

2. If we look at any Apple binaries, there's no way prove that our code didn't borrow from Apple.

3. Since we didn't look at any Apple binaries, then there's no way our work can be a derivative work-- we didn't even look at their stuff.

Right now I'm focusing specifically on the M4 Mac Mini and Neo, I just don't own any M4 Pro or Max hardware. My guess is that most of the drivers will just work on the other platforms, but we'll have to test.

Claude models were blocked from logging into my own VM with my own credentials I gave it using ssh that I also gave it by its guard rails. I wouldn't doubt other models are nerfed but...you should provide some context around your comment

proof?

Can't disagree more, but my experiences are my own.

The title is literally "I Came, I Prompted, I Left". I'm not sure how this can be clearer.

> when there's even a chance the models have been trained on the thing I ultimately plan to reimplement.

Are you claiming models were trained on proprietary Apple code? How would that even be possible?

The previous “Part 1” post is very candid about the approach, and the titles of both posts mention prompting.