Gravity Linux Brings Alpha M4 Mac Mini Support
The Gravity Linux project released an early alpha version of Linux for the M4 Mac mini. Moreover, the system already utilizes hardware graphics acceleration. Developers Cody Ho and Niklas Schutt assert they crafted the graphics processing unit driver in roughly a month. Specifically, they actively delegated hardware analysis and code generation to large language models. This process is detailed in Cody Ho’s blog on the GPU driver.
Alpha Features and Current Limitations
The alpha version successfully runs the DCP display controller. Furthermore, it supports a GPU featuring OpenGL ES 3.0 and OpenGL 3.3. Gravity Linux builds upon Fedora natively. Additionally, it launches KDE Plasma via Wayland by default. The developers explicitly warn that this release serves primarily testing purposes. Consequently, it remains unsuitable as a primary operating system.
Substantial Hardware Restrictions
The list of limitations remains substantial. For instance, the Mac mini cannot currently enter sleep mode. USB-C image output completely fails, alongside Thunderbolt and USB4 functions. Power management remains unfinished today. Additionally, shutdowns and reboots occasionally malfunction. Upgrading from this current alpha to a future beta might require a complete system reinstallation.
A Unique AI-Driven Development Approach
The main distinguishing feature of Gravity Linux relates less to running Linux on the M4. Instead, it highlights their unique development methodology. This project emerged as an Asahi Linux fork following disagreements regarding large language models. The Asahi Linux LLM rules strictly prohibit using generative models for substantial project contributions. The team fears copyright issues, code provenance disputes, and Apple component reverse-engineering complications.
Gravity Linux’s Open AI Policy
Conversely, Gravity Linux embraced a completely different approach. The project actively permits AI models. However, their official LLM policy requires disclosing their participation and maintaining separation during closed component analysis. If a model or developer studies a disassembled Apple component, they cannot directly use that knowledge. They must write the corresponding independent implementation separately. The team may also demand agent operation logs and model queries to verify code origins.
The Role of Software Agents in Driver Creation
Ho detailed the graphics driver development comprehensively in an early alpha release post. Instead of relying on Apple documentation, the team observed hardware behavior. They recorded macOS requests to the GPU. Subsequently, they conducted custom experiments. They gradually reconstructed the interface between Linux and the GPU firmware. According to the developer, the team never analyzed Apple executable files. They strictly utilized hardware traces and custom shaders.
Delegating Repetitive Tasks to LLMs
Ho and Schutt delegated a significant portion of repetitive tasks to software agents. These agents relied heavily on Codex and Claude. The models ran experiments and compared memory states autonomously. Furthermore, they attempted to replicate GPU commands and wrote driver segments. Humans still needed to intervene when agents chose incorrect paths. They also stepped in when AI stalled on secondary tasks. Ho separately describes instances where the model proposed erroneous explanations. It frequently failed to independently locate the crash source.
Performance, Testing, and Future Goals
Ultimately, the developers claim full compatibility with the OpenGL ES 3.0 test suite. In one demonstrated test, Minecraft ran flawlessly on the M4 Mac mini. It achieved approximately 200 frames per second easily. Ho calls the resulting implementation the first known graphics driver largely written by LLMs. Nevertheless, he acknowledges that serious human testing remains absolutely necessary. Extensive refactoring and verification must happen before merging this into main Linux projects.
Outpacing Asahi on Newer Hardware
Gravity Linux noticeably outpaced the main project regarding supported hardware generations. For Asahi Linux, official M4 support remains unready for standard installation. Most components for M4, M4 Pro, and M4 Max computers still await development. However, comparing the projects directly proves difficult. Gravity offers an experimental system tailored for developers. Meanwhile, Asahi supports significantly more Mac models and systematically submits drivers to the main Linux kernel.
Overcoming M4 Architecture Challenges
Difficulties with the M4 arose due to Apple’s recent architectural changes. They significantly altered the boot sequences and security mechanisms of new processors. Previously, developers found that the familiar hypervisor for macOS analysis stopped working on these new chips. Ho created a custom hypervisor specifically for modern Apple Silicon. He claims that predominantly autonomous software agents enabled bypassing certain reverse-engineering stages within mere weeks. This achievement is further explored in Cody Ho’s GPU driver blog.
Long-Term Vision for Mainline Linux Integration
Meanwhile, mainstream Asahi Linux recently added the M3 to its installer. However, the graphical component for the M3 generation lags behind the M1 and M2 levels. Gravity Linux intends to continue focusing on the M4, M4 Pro, and M4 Max. Later, they will tackle even newer processors. The team’s long-term goal does not involve developing an independent distribution. The developers passionately want to transfer their unified drivers into the main Linux projects. After that, the distinct necessity for a standalone Gravity Linux build should completely disappear.
