Gravity Linux's M4 Mac mini alpha brings DCP and GPU acceleration to one machine
Per the project's announcement, the release includes working support for the DCP and GPU (OpenGL ES 3.0 and OpenGL 3.3 compliance). Gravity Linux is a Fedora remix and by default uses KDE with Wayland by default. The DCP is Apple's display controller. It has to work before a Linux desktop can drive a monitor properly. Having the display controller and the GPU both working in the first release is what makes this more than a console-only bring-up.
Phoronix and It's FOSS have both covered the release independently. It's FOSS notes that with the DCP and GPU working, hardware-accelerated graphics is available from the first boot. Phoronix describes the OpenGL support as experimental and confirms the KDE Plasma desktop with Wayland.
Only one machine is supported. The project's device matrix lists the 2024 M4 Mac mini as "Alpha". The M4 Pro Mac mini, the 2025 M4 MacBook Air and the M4, M4 Pro and M4 Max MacBook Pro models are all marked "WIP", which Gravity defines as bring-up in progress and not usable yet. "Alpha" means the system boots and runs for developers and testers. "Beta" means usable day to day with known rough edges, and "Stable" means supported for general use. Owning some M4 Mac does not mean you have a Gravity release to install.
Gravity says the next targets are more hardware. Phoronix reports that the developers have hopes for the other M4 / M4 Pro / M4 Max devices as well as having their eye on the MacBook Neo. The announcement also says all M5 and M6 devices remain in scope. For now these are plans, and no releases exist for them.
What breaks in the Gravity Linux alpha: suspend, USB-C displays, Thunderbolt and USB4
The project states the limits plainly. The following features are known not to work: suspend, display out on the USB-C ports (HDMI works), and Thunderbolt/USB4. Power management is also incomplete. The developers say power consumption may be higher than expected (not very relevant for a desktop); we have set conservative limits for max speaker volume for safety reasons; and shutdown/reboot are flaky (you can just use the power button anyways).
The biggest risk for anyone thinking of installing it is the upgrade path. The announcement warns that there may be no upgrade path from this alpha to the beta or final release. You should assume that the beta will require a complete reinstall. Anything you build on the alpha should be treated as disposable.
The developers are also frank about their own experience. Cody Ho and Niklas Sheth say they are not experts in maintaining Linux distributions. They say they take the user experience seriously and will try to avoid user-facing errors, especially ones affecting privacy and security. Still, they expect to make mistakes at some point. They add that testing has been very limited overall, and that some settings not normally used in release builds are turned on because the build is meant for developers.
Installation starts in macOS with one shell command, curl -fsSL [!/bin/sh](https://install.gravitylinux.org) | sh. According to the project site, the installer resizes your disk, fetches the release, and walks you through the rest. The command pipes a downloaded script straight into the shell, and it repartitions the Mac's internal drive. Only run it on a machine whose macOS data is backed up and that you are willing to reinstall.
Why Gravity forked from Asahi Linux: the LLM policy split
Gravity's About page says the project was forked from Asahi Linux by Cody Ho and Niklas Sheth, who share Asahi's goal of bringing Linux to Apple Silicon, because the two sides disagreed about contribution policy on LLM use. Gravity says it has "tremendous respect" for Asahi.
Asahi's position is set out in its Generative AI (LLM) Policy. The policy says the project "broadly forbid the use of generative AI tooling for material contributions to Asahi Linux." It gives two reasons. The first is ethical: Asahi argues LLMs harm software freedom, the open-source community, privacy and developers. The second is legal. Asahi depends on clean-room reverse engineering, and its policy argues that LLMs are likely to break clean-room requirements and taint the resulting code. It says this risk is greater with "agentic" tools, where the human may not know what the agent has looked at.
The policy is scoped to material contributions, and enforcement is graded. An LLM-drafted GitHub issue may simply be closed with a pointer to the policy. Using an LLM to interpret a trace made with the m1n1 hypervisor can earn a first and final warning. Concealed extensive LLM use means an immediate ban, especially where unreleased Apple material may have been accessed.
Gravity is open about its approach. It's FOSS reports that the project's kernel branch carries commits with Assisted-By tags openly crediting AI coding tools. A daily.dev summary of the Phoronix coverage says the developers used OpenAI Codex and Claude Code as coding assistants during development.
How Gravity's tainted and clean-room reverse engineering split works
Gravity doesn't claim LLMs are free of legal risk. Its answer is to split reverse-engineering work into two tracks. Under its contributor guide, anyone who has decompiled, disassembled or inspected Apple's kernelcache or other proprietary Apple binaries, whether personally or through an AI agent they used, can only do "tainted" work on the components they examined. The project's LLM Use and Clean-Room Policy says: "If in any session your LLM has looked at any disassembly, decompilation, or other protected implementation details of an Apple component, you must consider yourself tainted with respect to that component."
Tainted contributors may analyze Apple binaries and build a private test implementation to check what they have learned. That code must never be published or contributed. What they publish is documentation of the hardware interface: registers, commands, data formats, MMIO offsets, protocols, required sequencing and firmware ABI. The guide stresses that no implementation details taken from Apple's code may leak into it, and says anything a contributor isn't completely sure is safe should be left out.
Clean-room contributors work from the other side. They may study hardware behavior, collect traces, experiment with devices and write drivers from public documentation and their own observations. They must not look at Apple proprietary code or non-public implementation details, and the guide says there are no exceptions for maintainers or core developers. If a task would cross that line, the contributor is told to stop and hand it to someone on the tainted track.
This setup is why Gravity can say both that it uses LLMs heavily and that it respects Apple's copyright. Ho's own account shows the boundary in practice. He says that while building a custom hypervisor for newer Apple Silicon, he used an LLM to disassemble Apple's proprietary SPTM component. That disqualified him from writing the clean-room implementation for that component, so the knowledge had to be documented and handed to someone who had not seen the protected material. The only record of this is Ho's own description. Whether a court or Apple would accept the separation hasn't been tested.
Gravity's site says the project has never looked at Apple source code or disassembly, and publishes enough of its process for anyone to check. It's FOSS repeats that everything in it is built through clean-room reverse engineering, ensuring that no Apple source code, disassembly, or leaked technical information makes its way into the code. The announcement words this more narrowly: the team has "not looked at any Apple binaries to write Linux drivers." Taken with the SPTM account, the precise claim is about the driver code, and not everyone on the project has avoided Apple binaries.
Cody Ho's account of building an M4 GPU driver in about a month
Ho, who previously worked at Apple and OpenAI, has written a two-part essay series called "I Came, I Prompted, I Left." The first part, published August 3, covers the hypervisor. The second, published September 15, describes how he and Sheth built an M4 GPU driver in about a month, with much of the work done in largely unattended LLM loops.
In Ho's telling, the method worked like this. The team used the hypervisor to capture and replay system behavior. They then gradually replaced replayed state with behavior generated from their own source code. Ho says the kernel driver grew from a Python prototype into a Linux driver in three days. He reports passing the OpenGL ES 3.0 conformance suite, rendering WebGL in Chrome and Firefox, and running Minecraft at 212 frames per second on an M4 Mac mini. Those are the developers' own results. No outlet has published an independent benchmark.
Ho also describes what didn't work. Attempts to understand Apple's shader instructions well enough to compile arbitrary new shaders failed. He says the way tasks were framed and ordered mattered a lot: narrow experiments and starting with more tractable problems produced better results than broad goals. For the GPU work, the developers say they used hardware traces, live probing and shaders they wrote themselves, without inspecting Apple binaries.
The account also shows the work didn't start from scratch. Ho and Sheth acknowledge building on Asahi's earlier M1 and M2 work and using its existing userspace API. That fits Ho's claim that LLMs compressed the timeline. It also means the speed-up ran on top of years of human reverse engineering. The project has shown what a small team with coding agents can do. It has not run a controlled comparison showing that Asahi's policy is what slowed Asahi down.
Gravity versus Asahi Linux on M3 and M4: ahead on one axis only
On newer chips, Gravity is ahead of Asahi on one specific point. Asahi announced official M3-series support on September 6, 2026, and a September 15 update dropped the original requirement to use the installer's Expert mode. Asahi says most features it supported on M1 and M2 now work on M3, with the GPU and full DCP support as the main exceptions. It warns users not to expect performant or power-efficient 3D acceleration, and its M3 feature matrix still lists GPU support as work in progress. Sleep doesn't work on M3 either. HDMI is disabled on MacBooks that have it because DCP support is missing, and the M3 Ultra Mac Studio isn't supported yet.
So Gravity has shipped accelerated graphics on an M4 machine, while Asahi's newest supported generation still lacks it. That's the whole of the lead. Gravity supports one M4 Mac mini configuration in a lightly tested developer alpha. Asahi is an established project covering M1, M2 and now M3 hardware with a far broader, longer-tested feature set.
Asahi's recent history is relevant here. Project lead Hector Martin resigned in February 2025. About a week later the GPU developer known as "Asahi Lina" stepped away too. Alyssa Rosenzweig, who led the GPU driver effort, left in August 2025 and has since joined Intel. Asahi has kept shipping, and the M3 release is proof of that, but it lost much of its GPU expertise at the point when newer Apple chips needed it. Meanwhile Apple has already launched M6-based Macs, so both projects are several generations behind current hardware.
Upstreaming is where Gravity's LLM-built code gets judged
Gravity says it doesn't intend to stay a separate distro. Its announcement calls upstreaming "the only practical way of ensuring a sustainable project," and It's FOSS notes that Gravity Linux has a long-term goal of not existing as a distro. Phoronix likewise reports that the team hope that eventually all of their work will reach the upstream Linux kernel.
There's a lot left to do before that happens. Ho says the code still has to be refactored into reviewable pieces, tested more, and reviewed by humans before it can be submitted to Mesa and the Linux kernel. Gravity's developers have also warned that their kernel driver may have to wait until Asahi's M1 and M2 GPU driver lands upstream first. No project maintainer has publicly confirmed that dependency.
Upstream acceptance is also where the two projects' policies will meet in practice. Replying to criticism on Hacker News, a Gravity developer wrote that what Asahi does is their business, our interactions will be in upstream projects and follow upstream guidelines. The kernel and Mesa reviewers who eventually see the patches will decide whether code generated largely in unattended agent loops is maintainable enough to accept. The published test results, working as they are, don't settle that.
What this means for you
Unless you are a developer who wants to test and contribute, don't install Gravity Linux yet. It's worth trying on a spare 2024 M4 Mac mini that connects to its monitor over HDMI and doesn't need to sleep, if you're prepared to wipe it again for the beta. Anyone else should wait, and anyone on M1, M2 or M3 hardware is still better served by Asahi Linux.
Gravity has shown that a two-person team with coding agents, building on Asahi's earlier work, can get an accelerated Linux desktop running on an M4 Mac in weeks. It hasn't yet shown that the code can be maintained. The beta, which Gravity promises will remove most of the alpha's limits, and the first kernel and Mesa patch submissions will show whether this method produces code upstream maintainers will take.