Very cool! I'd love to see a prominent section on their website explaining what does work and what doesn't work at the moment. I'm assuming there are probably quite a few things which aren't functional.
> The following features are known not to work: suspend, display out on the USB-C ports (HDMI works), and Thunderbolt/USB4. Additionally, 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). Every feature not listed here works and has been tested.
> Gravity Linux and Asahi Linux are two independent projects working towards the shared goal of a strong, open OS ecosystem on Apple Silicon devices. Gravity Linux was initially forked from Asahi Linux over differences in policy, namely regarding LLM use. We have tremendous respect for the Asahi Linux project and emphasize our shared goal of running Linux on Apple Silicon.
OP is the same poster from https://news.ycombinator.com/item?id=49717638 who was noted as having been banned from Asahi Linux over hiding use of LLMs (doesn't seem to be any disagreement about this) and accusations of having Apple proprietary knowledge (challenged by OP).
I disagree with this also, but the latter was so obviously wrong that I figured I should leave a reply. We are separate projects and what Asahi does is their business, our interactions will be in upstream projects and follow upstream guidelines.
It's kinda sad that this cool project is mired in controversy. On one hand it is kinda radioactive for a former Apple engineer to work on this, even if you worked on something else entirely while at Apple. On the other hand I really, really want proper Linux support with full GPU support on modern Macs and I feel like AI is an incredibly useful tool towards that effort.
Oh well, if this doesn't pan out, hopefully someone else will vibe code for a week and get it working in the near future.
Let’s take the kind view? If Apple has a problem in a former engineer possibly using insider knowledge that is first and foremost a problem between Apple and said engineer. Reasonably if that first round kicks off, in the second round of problems an OSS project is possible in scope.
The engineer and the project have discussed these risks and decided to continue in a fork from Asahi. So I would say that this is (nearly) how it is supposed to go. Asahi stays clean from contagion and Gravity Linux has taken a, hopefully well considered, risk.
From a brief look, it seems separate from Asahi, although it builds on some of Asahi's existing work. I'm still not clear why it needed to be a separate project rather than contributing M4 support upstream. Could be a good reason, but it does look a bit duplicative at first glance.
Asahi’s approach avoids any use of AI coding agents, etc at all (even for debugging, testing, and so forth). The amount of work/effort the Asahi team did for M1/M2/M3 is near superhuman, and M4 is gonna take all that effort again, since Apple likes to change things, a lot, and doesn’t really document their hardware device interfaces in detail.
Gravity approaches this with an attitude that using an LLM is indeed allowed (per upstream Linux contribute requirements), particularly for analysis, debugging and testing. The goal is to get M4 support contributed back to to the upstream kernel. (And eventually M5, M6, A18…)
Ideally, the documentation about hardware interfaces from this project could be used for other people who want to write kernel drivers for Linux or even for other operating systems. It’s mostly a matter of documenting what the device interface actually is.
None of this would be possible without Asahi’s foundational work and techniques to make clean room reverse engineering possible. Despite differences on opinions about AI, I can’t stress the quality of their work or the effort they’ve put in enough.
Very cool! I'd love to see a prominent section on their website explaining what does work and what doesn't work at the moment. I'm assuming there are probably quite a few things which aren't functional.
It is a few paragraphs down on the linked page:
> The following features are known not to work: suspend, display out on the USB-C ports (HDMI works), and Thunderbolt/USB4. Additionally, 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). Every feature not listed here works and has been tested.
Is this related to Asahi Linux in any way? Or is it a completely separate project for some reason?
https://gravitylinux.org/about/
> Gravity Linux vs Asahi Linux
> Gravity Linux and Asahi Linux are two independent projects working towards the shared goal of a strong, open OS ecosystem on Apple Silicon devices. Gravity Linux was initially forked from Asahi Linux over differences in policy, namely regarding LLM use. We have tremendous respect for the Asahi Linux project and emphasize our shared goal of running Linux on Apple Silicon.
OP is the same poster from https://news.ycombinator.com/item?id=49717638 who was noted as having been banned from Asahi Linux over hiding use of LLMs (doesn't seem to be any disagreement about this) and accusations of having Apple proprietary knowledge (challenged by OP).
> hiding use of LLMs
I disagree with this also, but the latter was so obviously wrong that I figured I should leave a reply. We are separate projects and what Asahi does is their business, our interactions will be in upstream projects and follow upstream guidelines.
It's kinda sad that this cool project is mired in controversy. On one hand it is kinda radioactive for a former Apple engineer to work on this, even if you worked on something else entirely while at Apple. On the other hand I really, really want proper Linux support with full GPU support on modern Macs and I feel like AI is an incredibly useful tool towards that effort.
Oh well, if this doesn't pan out, hopefully someone else will vibe code for a week and get it working in the near future.
Let’s take the kind view? If Apple has a problem in a former engineer possibly using insider knowledge that is first and foremost a problem between Apple and said engineer. Reasonably if that first round kicks off, in the second round of problems an OSS project is possible in scope.
The engineer and the project have discussed these risks and decided to continue in a fork from Asahi. So I would say that this is (nearly) how it is supposed to go. Asahi stays clean from contagion and Gravity Linux has taken a, hopefully well considered, risk.
If the Gravity Linux work is upstreamed into the kernel project, any issues with Apple sort of become everyone's problem.
> On one hand it is kinda radioactive for a former Apple engineer to work on this
If this were the case, then Wine and its forks like Proton would have the same issue.
Former Microsoft employees have contributed to Wine in the past.
From a brief look, it seems separate from Asahi, although it builds on some of Asahi's existing work. I'm still not clear why it needed to be a separate project rather than contributing M4 support upstream. Could be a good reason, but it does look a bit duplicative at first glance.
It’s a different approach to adding M4 support.
Asahi’s approach avoids any use of AI coding agents, etc at all (even for debugging, testing, and so forth). The amount of work/effort the Asahi team did for M1/M2/M3 is near superhuman, and M4 is gonna take all that effort again, since Apple likes to change things, a lot, and doesn’t really document their hardware device interfaces in detail.
Gravity approaches this with an attitude that using an LLM is indeed allowed (per upstream Linux contribute requirements), particularly for analysis, debugging and testing. The goal is to get M4 support contributed back to to the upstream kernel. (And eventually M5, M6, A18…)
Ideally, the documentation about hardware interfaces from this project could be used for other people who want to write kernel drivers for Linux or even for other operating systems. It’s mostly a matter of documenting what the device interface actually is.
None of this would be possible without Asahi’s foundational work and techniques to make clean room reverse engineering possible. Despite differences on opinions about AI, I can’t stress the quality of their work or the effort they’ve put in enough.
Asahi is aiphobic
Seems to be 100% entirely different, as Asahi uses Arch, this is on Fedora.
This is intended to eventually be distribution agnostic; Asahi uses Fedora and this is following in those footsteps to be a fairly similar experience.
Asahi is available in a variety of distros, too.
Asahi is on Fedora now (and has been for a couple of years)