Eine neue Linux-Distribution für Apple Silicon hat geschafft, was dem alteingesessenen Asahi-Projekt bislang nicht gelungen ist: ein GPU-beschleunigter Desktop auf dem M4 Mac mini. Und sie schreibt die Geschwindigkeit KI-Coding-Agenten zu.
Gravity Linux bezeichnet sich als Fedora-Remix, der einen modernen Linux-Desktop auf Apple Silicon bringt. Die About-Seite erklärt, das Projekt sei „ursprünglich wegen Policy-Unterschieden, namentlich beim LLM-Einsatz, von Asahi Linux abgespalten“ worden – verbunden mit dem Hinweis auf Respekt für das ältere Projekt und ein gemeinsames Ziel.
## Was die Alpha tatsächlich leistet Die erste experimentelle Alpha zielt auf den M4 Mac mini, den Apple im Oktober 2024 vorstellte. Sie liefert GPU-Beschleunigung mit OpenGL ES 3.0 und OpenGL 3.3 und richtet sich ausdrücklich an Entwickler, nicht an den Alltagsbetrieb. HDMI funktioniert; USB-C-Displays, USB4, Thunderbolt und Suspend nicht, die Energieverwaltung ist unvollständig.
Trotzdem liegt Gravity bei den Hardware-Generationen vor Asahi. Asahi hat erst kürzlich vorläufige M3-Unterstützung ergänzt – ohne Grafikbeschleunigung –, während Apple bereits auf M6-Macs umgestiegen ist. Der Vergleich hinkt: Gravitys M4-Build ist eine frühe Entwickler-Alpha, Asahi ein etabliertes Projekt mit deutlich größerer Hardware-Abdeckung.
## Warum die Methode der Streitpunkt ist Gravitys Leiter Cody Ho arbeitete zuvor bei Apple und bei OpenAI. Mit dem Mitentwickler Niklas Sheth veröffentlichte er einen zweiteiligen Bericht über KI-gestütztes Reverse Engineering für Apple Silicon, „I Came, I Prompted, I Left“ (3. August und 15. September): erst ein eigener Hypervisor für neuere Apple-Silicon-Chips, dann ein M4-GPU-Treiber, gebaut in rund einem Monat. Ein Großteil der Arbeit, so Ho, lief in weitgehend unbeaufsichtigten LLM-Schleifen.
Darin liegt der schärfste Unterschied zu Asahi, dessen Generative-AI-Policy „die Nutzung generativer KI-Werkzeuge für wesentliche Beiträge grundsätzlich untersagt“. Gravity erlaubt solche Werkzeuge, versucht das rechtliche Risiko aber durch eine prozedurale Trennung zu begrenzen. Die LLM-Use-and-Clean-Room-Policy erklärt, wer in einer Sitzung Disassembly, Dekompilierung oder andere geschützte Implementierungsdetails einer Apple-Komponente gesehen hat, müsse sich bezüglich dieser Komponente als „kontaminiert“ betrachten.
Die Regel wurde praktisch angewandt. Beim Hypervisor nutzte Ho ein LLM, um Apples proprietäre SPTM-Komponente zu disassemblieren – damit war er für die zugehörige Clean-Room-Implementierung gesperrt; das Wissen wurde dokumentiert und an jemanden übergeben, der das geschützte Material nicht gesehen hatte. Die GPU-Arbeit folgte einem strengeren Weg: Hardware-Traces, Live-Probing und selbst geschriebene Shader statt Einblick in Apple-Binaries – gestützt auf Asahis frühere M1- und M2-Arbeit und dessen Userspace-API.
## Was damit nicht bewiesen ist Die Entwickler bleiben vorsichtig: Der Code braucht umfangreiche Tests, menschliche Prüfung und Refactoring, bevor er upstream gehen kann, und der Kernel-Treiber muss womöglich warten, bis Asahis M1/M2-Treiber upstream landet. Die Veröffentlichung ist damit eine faszinierende Demonstration KI-gestützten Reverse Engineerings – kein kontrolliertes Experiment, das Asahis Policy als Bremse erweist.
