[kakwa_]

While I absolutely love the technical write-up from the Asahi team, and being absolutely impressed by their accomplishment, to the risk of being an overly negative contrarian, I remain a bit skeptical.

I'm concerned that after all these years, it's still a separate project and not an effort sustained directly within the kernel mainline and mainstream distributions like Ubuntu, Debian or Fedora.

These kinds of reverse engineering projects are extremely challenging. With skills & field knowledge, it's "easy" to get to "80%" and have something useful for you and the most dedicated users. But reaching the "95%" required for a polished & general public ready experience needs nearly as much effort, often on tedious and time consuming tidbits.

[dagmx]

For what it’s worth, Asahi do upstream a lot of changes to do exactly what you’re saying.

That’s a big reason why progress slowed recently because they were focusing on reducing their diff count.

A lot of stuff has landed in the mainline kernel, but Asahi is how they keep experimenting on new functionality.

[omcnoe]

I think there is also the added challenge that ARM macs are a moving target, and Apple has less than no desire to provide any kind of stability or support for Asahi Linux. Unlike the PC space where laptop manufacturers have to maintain broad compatibility over time, Apple will make future changes that are really awkward for Asahi and will not care one bit because they can do the compat work on their own software.

[xoa]

>I think there is also the added challenge that ARM macs are a moving target

Yes, but also no? Because I think a reasonable argument can be made that ARM Macs are like game consoles with a more rapid generation: yes there are changes between each generation, but then you've got millions of units which are good for a very long time that are all near identical. Apple definitely is not changing everything between gens at all, work they've done for M1 has been plenty useful since. And support stretches awhile. The final M3 generation chip only came out about a year ago (the M3 Ultra for the Mac Studio was March 2025).

So sure there's ongoing effort needed for newer systems, and that may require ongoing RE more then typical. I don't want to brush aside the effort there at all. But at the same time there doesn't seem to be the same long tail of hardware variations and dozens to hundreds of players doing their own little tweaks either. Aside from memory and storage, every single Mac of a given SoC is the same so each time one gets covered they all get covered and are a stable experience. It's definitely a different thing then developing for PCs, and I definitely wish there was and support serious legal backing for no rug pulls being allowed, ever. Hardware owners should always have access to the root of trust if they want it. But that aside, I don't think their efforts are wrong or somehow wasted just because each new generation might need some new work. That doesn't appear from the outside to be intractable, and fact is the pace of hardware change for computers has slowed and continues to slow. A system from many years ago can still be very good for most tasks... so long as the OS can still be updated and work. Apple themselves seem more then limiting factor there, whereas Linux shines in long term support.

[mort96]

The huge advantage of x86_64 isn't that it's a stable platform, but that the big hardware vendors maintain their own Linux driver. Nobody needs to reverse engineer how AMD GPUs work, you can just use AMD's driver. Nobody needs to reverse engineer how Intel power states work, just use Intel's pstate driver. Nobody needs to reverse engineer how Broadcom's WiFi driver works, Broadcom maintains their own Linux driver and contributes to the upstream brcm80211 driver. And commodity hardware that's not directly supported by the vendor typically has detailed data sheets, meaning that someone has to contribute a driver but no reverse engineering is needed.

[StillBored]

Its more than that, its that x86 vendors know how to maintain hardware backwards compatibility, they don't throw out the entire USB subsystem every time a new phy/whatever shows up because there is a standardized mailbox interface sitting in front of the actual HW. Same with the core platform, which works out of the box using 25+ year old firmware standards that are flexible enough to support simple sensors and behaviors, like lid close notification on a laptop for example across multiple OS's. Even something as simple as the firmware interface for handing off a frame buffer to the OS isn't universally support on arm platforms because a significant fraction don't support uefi. Apple was an early uefi adopter, but whatever internal politics they have, means they tossed even that on the latest mac's.

[unfitted2545]

From an end user perspective, I think the best thing the Asahi team could have done was solely focus on getting the M1 Air/Pro working 100% before moving onto other devices.

But that would probably result in burn out from the crazily talented dev team :P

[walterbell]

Asahi focusing on M1 would also encourage secondary market sales of M1 laptops, which are already a primary competitor (see Apple marketing) to current Apple laptops. If Apple wanted to encourage Asahi Linux users to move from M1 or Qualcomm to M5/M6 Apple devices, they could improve device firmware compatibility with Linux, or contribute directly to mainline Linux.

[apatheticonion]

Haha, I can't imagine Apple contributing open source driver code to mainline Linux.

My assumption is that if they ever decided they would provide support for Linux, it would be a private Mac-linux fork.

It's hard to imagine they would go the shim + blob route like nvidia as that would still require upstreaming stuff.

Honestly, they should just document their hardware so we can write our own drivers without hurclean reverse engineering efforts.

[rowanG077]

Considering that M1 and M2 are almost the same architecturally isn't that exactly what they are doing? M3 are two new contributors who decided they wanted that.

[mort96]

I'm not really sure what it would mean for M1 air/pro to work better at this point to be honest, other than I guess power consumption during sleep but that's supposedly a super tricky problem that can't be "solved", it can just be incrementally improved through immense effort. But the main problems I have on my M1 Pro now are just the normal Linux laptop problems: bad trackpad palm rejection, input latency, inconsistent scroll speed between apps, high latency tap to click, somewhat janky fractional scaling (at least in GNOME). These aren't really problems for Asahi to fix, I feel.

[miki123211]

On one hand, yes they're a moving target, on the other, they're a lot more uniform than X86 machines.

X86 can also be a moving target now; with Windows's driver autodiscovery mechanisms, manufacturers that don't care about Linux could still make people's life hell.

[mschuster91]

> Unlike the PC space where laptop manufacturers have to maintain broad compatibility over time

LOL

If anything Apple is infamous for keeping around hardware blocks for as long as they can. IIRC the serial port driver for everything Apple ARM dates back to the very first generations of iPods.

Of course Apple will remain a moving target, but they are orders of magnitude more stable than everyone else in the non-x86 universe.

[walterbell]

How does Ubuntu Linux on recent Qualcomm (ex-Apple Nuvia) Arm laptops compare to Asahi Linux on Apple Silicon?

[neobrain]

Most people don't realize that the Asahi team ship features only once they work without quirks. For the set of supported hardware features, Asahi is much closer to a macOS experience than to an average x86 Linux laptop experience.

Meanwhile, Linux on my Lenovo X13s "works" but has tons of quirks: Boot fails 2 out of 3 times, the device hard-resets sometimes when waking up with a display connected, and the speakers are unusable due to lack of active overheat protection (and somehow this affects even external speakers). It technically works, but it's incredibly frustrating to use in practice.

If you plan to use Linux and don't need an ARM laptop, there's little reason to prefer a Qualcomm device over an x86 one currently. On the other hand, M1/M2 easily outperform a broad class of x86 laptops, and they have a Linux experience that's for many use cases close to on par with official vendor support.

[jauntywundrkind]

Pretty rude to call this ex Apple Nuvia. I don't think any of those lawsuits by Apple or ARM have been won. Qualcomm declares this to be a new chip. But yes it has talent from those places. Still, let's not try to tip the scales of perception quite so indelicately?

I am curious what the boot situation is. It seems like Qualcomm actually has pretty good support for their cores. But since these PC systems sort of lack a bios, each one needing a hand built DeviceTree: it makes supporting them kind of a nightmare. Even a raspberry pi has a much more advanced and accommodating boot environment than these frustrating Qualcomm laptops. Alas. I don't know but I expect Asahi has to do similar hand tailoring. I am curious to know what the boot chain looks like! How much the system willingly helps vs how much hard to be bespoke hand coded system config! (Wish it wasn't like this, it's so bad)

[walterbell]

Circular talent economy, https://www.tomshardware.com/pc-components/cpus/legendary-qu...

  Just several months after leaving Qualcomm, distinguished CPU and system architects Gerard Williams, John Bruno, and Ram Srinivasan, who are celebrated for their high-performance processors developed at Apple, Nuvia, and, more recently, Qualcomm, established a new CPU startup — Nuvacore — that promises no less than to 'rewrite the rules of silicon.'

[glaslong]

Seems like a good thing, no? People getting paid well to skip around and improve products across the board. A virtuosos cycle, as opposed to the cynical cycle of ruining one project and parachuting to the next.

[walterbell]

Also keeps lawyers busy.

[appplication]

Without stirring the pot too much, I’m a bit out of the loop on what the above poster implied and you took slight to. Could you share a little more about this and why you feel what they said was rude?

[wtallis]

There's nothing rude about it; the Nuvia CPU core is pretty much the entire selling point of the Snapdragon X Elite product family. Everything else on those chips is underwhelming. But the provenance of the CPU core is really irrelevant to the question of Linux support, which is gated by driver support for the rest of the SoC, which didn't come from Nuvia. So focusing on the Nuvia aspect is a bit of a red herring.

[Danox]

Qualcomm may be a tech company, but they behave more like a pack of lawyers (probably the best in the tech business at extracting money” double dipping”) they will never support Linux in any usable way, not without a huge ongoing fee/payola on their so called partners.

[walterbell]

> bit of a red herring

It offers an A/B test of "similar" SoC performance and battery life (which users now expect from laptops), without a vertically integrated operating system that was also created by the company who designed the SoC.

[saagarjha]

Apple and ARM have sued Qualcomm over the Nuvia talent.

[Danox]

Qualcomm at its heart is a patent troll company. They and Microsoft actually deserve each other. Long-term their partnership will end in tears.

BecauseMicrosoft is at this time in different to the Surface computers they are all in on copilot. It is basically copilot or bust for Microsoft.

[bri3d]

> these PC systems sort of lack a bios, each one needing a hand built DeviceTree: it makes supporting them kind of a nightmare.

Modern PC ARM systems like Snapdragon Elite X use UEFI and ACPI. This is actually what makes them difficult, because they're trying to operate in a "new world" while most ARM SOC IP and peripheral drivers work in the "old world."

The issue with ARM has never _really_ been early boot; yes, it's arcane and a pain in the butt on some platforms, but it really only needs to be done once - once your DRAM is trained and running (this is usually the hardest part) and you can load and jump into a kernel, you're set. Hypervisor / security processor driven systems like Qualcomm (and for that matter, Intel and AMD) actually make this even easier at the expense of openness, because the vendor blob usually brought everything up for you already.

The issue has always been hardware discovery and mutable device configuration. When ARM devices were first supported by Linux, they were mostly embedded devices with one configuration, ever. So, they used devicetree, which is a fixed structure for each board, defined before boot and provided by the bootloader.

Because of this, most SOC / platform / IP soft-core drivers were built to work with fixed, proprietary configurations and usually only tested against a single platform to start.

On the other hand, x86 devices have been forced to work as highly mutable, arbitrary combinations of hardware (Plug n Play) with dynamic reconfiguration using ACPI since the start, so the drivers for x86 peripherals have always had to cope with a completely unpredictable environment.

What this means is that there's a ton of effort required to transition ARM _peripheral drivers_ from the "devicetree" world where drivers took fixed arbitrary, proprietary key=value parameters provided by a magic blob at boot to the ACPI world, where everything is dynamic, scripted, and abstract.

I'd actually argue that Pi have the most hacked tooling on top of the "old devicetree way," which means they're the most set on it. Pi peripherals are usually configured at pre-boot time using devicetree overlays and their drivers usually don't support any kind of probing/autodiscovery. As far as I know there's no real plan to change this (and maybe there doesn't have to be; it seems to work for them).

Anyway, this is all to say: I don't think the issue with either system is the "boot situation," it's the "peripheral configuration situation." In this sense, Asahi are actually in a fine situation to use devicetrees, which they do, because basically all of the SOC peripherals are proprietary and there are a fixed number of Apple devices to target and the only external interfaces are existing hot plug standards (USB/Thunderbolt/HDMI/DP). Qualcomm are smart to have started to try to use ACPI, because their SoCs could be hosted on boards with standard peripherals configured in thousands of different ways, like all PCs. But, they're playing on hard mode because most of the existing ARM peripheral drivers weren't made to support this model.

[tmzt]

While it's true that early Linux ARM devices where embedded and generally only supported a single configuration, they didn't actually use devicetree.

Originally, embedded Linux ARM devices used a board file with a platform bus and hard-coded device metadata. The bootloader had to pass a machine id which told the kernel which hardware you were running on and which board file to use.

You can see remenants of this in the kernel still, though it's quickly being removed. I'm actually working on a hybrid kernel with the goal of bringing modern Linux support (on an lts branch) to old MSM7x300 devices, like the Evo 4G Shift I intent to use a tmux console/cyberdeck.

On another note, ACPI/UEFI doesn't always give you a clean abstract surface to work with either. ACPI is notorious for building in OS checks into it's compiled bytecode to the point that Linux often lies to it about what OS is running.

[bri3d]

I remember that era (and it's still present on some other architectures) - devicetrees were at least a huge improvement over compile-time board config!

> ACPI/UEFI doesn't always give you a clean abstract surface to work with either.

That's putting it lightly. I think the best abstraction would probably land somewhere inside the big gap in the board config headers -> devicetree --------------> ACPI complexity continuum, but I'm not sure it's possible to do that at this point in the game as both sides are so entrenched.

> ACPI is notorious for building in OS checks into it's compiled bytecode to the point that Linux often lies

The problem with ACPI in this dimension is that there's a bidirectional errata game: the bytecode tries to work around the OS and the OS tries to work around the bytecode.

Unfortunately, there was never a real version standard for the Linux firmware interface early on (the _OSI("Linux") debacle), so the only testable versioned ACPI interface is Windows. This means that Linux is basically forced to become a Windows ACPI emulator. I think there are political reasons for this (obviously the 90s and 2000s were a bad time for Linux/Microsoft coexistence) but also just some decisions that look like big engineering mistakes in hindsight - the historic allergy of Linux maintainers to any kind of specified or versioned interface aimed at anything but user land definitely strikes again here.

I think that the versioning/errata issue and the native code trapdoor are the two biggest issues with ACPI (and admittedly both are large enough to drive a bus through); otherwise it's a kind of nasty thing but it fills in nicely for a lot of much nastier ideas and covers a really broad problem space reasonably well.

[kmeisthax]

This actually is the case for a few other competing Apple Silicon support projects that came and went prior to Asahi. Assuming you have a way to load code into EL2[0], it's fairly easy to bring up the main CPU and USB, plug in a bunch of external peripherals before boot, and say you got Linux running on Apple chips. Only true in the most literal case.

In contrast, Asahi is specifically doing all the challenging RE work that typically gets passed over in favor of flashy headlines. If anyone can get to 95%, it's them.

[0] Prior to the M1 Mac, Apple did not allow anyone but themselves to load EL2 code. The ability to load other OSes on Apple Silicon Macs is, strangely enough, an allowed use-case. Prior to this we had to rely on once-in-a-decade bootrom security bugs.

[bennett_dev]

There was a nice task on 39c3 https://youtu.be/3OAiOfCcYFM

They do try to upstream and eventually just have Linux natively support Apple Silicon!

[__turbobrew__]

Why would any group want to take on a project which could be instantly killed by an external for profit entity? For now Asahi is left alone by Apple but that could change in a single day and the entire project is dead. It doesn’t seem like a productive way to direct the limited energy that distribution foundations have on hand.

[tomnipotent]

Except there's no legal basis Apple could use to "instantly kill" the project.

[__turbobrew__]

Apple could change the platform/firmware to break Asahi if they wanted to. They could lock down the hardware to make it nearly impossible to install another OS like they do with iphone.

[mort96]

I mean so could any other hardware vendor?

No Mac in history has been locked down in the way you describe, and there's really no indication that Apple would start now. If they were ever going to, the ARM transition would've been the perfect time to do it, yet they invested engineering resources into adding support for booting non-Apple kernels into their bootloader.

They could of course release a new line of laptops or a firmware update tomorrow which locks down the bootloader and prevents booting non-Apple kernels. But so could Lenovo, Dell, HP, Samsung, Sony, or any other laptop vendor. Or Microsoft, Intel, AMD or Qualcomm could exert their influence, as owners of various parts of the ecosystem, to shift the PC landscape in that direction.

[__turbobrew__]

Most hardware vendors don’t make operating systems, so they are not incentivized to limit what software can run on the hardware.

For example, intel and AMD contribute a lot of code and engineering hours to open source projects because they WANT people to be able to run that software on their hardware.

[mort96]

What you're saying is true for phones too, yet phone manufacturers lock down their hardware to only allow it to run Google's operating system. The argument that "hardware manufacturers live by selling hardware and don't care what software customers run as long as it's on their hardware" clearly doesn't work.

But if you truly do believe that's a good argument, consider Microsoft's position. They wouldn't want you to run non-Windows operating systems and hold considerable power over the Windows PC ecosystem.

[tomnipotent]

They could, but that wouldn't change that there's still no legal basis that jeopardizes anything that's already been contributed.

[__turbobrew__]

Sure, there is no legal issue with these contributions. The problem is why would a project like Debian spend a bunch of work stewarding the Asahi project when Apple can just make the project impossible to progress if they so desire? The Debian project already is strapped for resources to build their distribution and stewarding a possibly throw away project is probably not the best use of their time.

[tomnipotent]

Your entire argument is based on a random hypothetical. Why should Debian steward any work if a meteor could collide with our planet and wipe out all life?

[bri3d]

> I'm concerned that after all these years, it's still a separate project and not an effort sustained directly within the kernel mainline and mainstream distributions

What does this mean? Hardware support is rarely developed inside these organizations; what makes it seem like these groups would be a good home for this effort?

It makes sense to have a group of experts in a field (Apple hardware/firmware) contribute patches upstream, which is the exact system here. And Asahi have done an above and beyond job also maintaining their installation framework while carefully moving changes upstream as well.

[kakwa_]

Well, after a while, the effort of maintaining and improving M-series kernel support should be directly be done by kernel maintainers, not within a fork with periodic merges (maybe some Asahi folks should become kernel maintainers).

Doing so would enabled mainstream distributions to provide maintainable M-series builds, with all that entails in terms of stability, enabling choice, maintenance or security fixes.

The whole fork + dedicated distribution made sense at the start of the project since it provided a playground for quickly iterating and experimenting (which is a no-no to do directly in the mainline kernel or in a major distribution).

But Asahi is still the only Linux on Silicon option after all these years, which is a bit worrisome. Asahi should have been a cool but temporary initiative.

At some point, the project will lose momentum and for its accomplishments to last, it should be merged into the general effort, i.e. drivers maintained directly in the Linux kernel, and the userland stuff made to be easily packaged and shipped by mainstream distributions.

[bri3d]

This is... literally exactly what they are doing?

Of all of the reverse engineering related Linux efforts (and most corporate Linux efforts), Asahi have been the most methodical and relentless about upstreaming changes into the kernel and all of their upstream intermediaries (freedesktop/Mesa etc.), specifically so it's maintained, even at the detriment of the project velocity and contributor health.

Asahi is explicitly not supposed to be a fork + dedicated distribution long term and over time, the delta between Fedora Asahi Remix and Fedora has grown smaller and smaller.

> Asahi is still the only Linux on Silicon option

What do you mean? There are non-Fedora Remix distributions which incorporate the "edge" Asahi changes, like https://ubuntuasahi.org . And again, as more and more gets mainlined, it becomes increasingly plausible that many distributions will be able to support Apple Silicon "out of the box" without much special consideration.

[kakwa_]

I would have been happy if all that happened like 3 years ago.

Now, it's 5 years in, the Asahi effort is losing momentum. Core developers are going on to do other things, significant chunks (3922 commits) are still not merged upstream and no major distribution has an official build.

Sorry, but in my opinion, the project is at risk of becoming a dead and unmaintained branch.

Don't get me wrong, the Asahi team did an incredible job on this bloody difficult endeavor, but now is time to properly merge it and not let it go to waste.

[Danox]

It is a dying quail effort doomed from the start if those three ex Apple engineers could get a license from Arm to design chips it is still baffling why no one else across the whole wide world didn’t follow in their footsteps. There is a Linux market.

I’m just shocked that it has not happened. With all the money flying around for AI data-centers you would think that this would be a more worthwhile effort?

Where is the European effort in this area? I would think it would be a natural for something to come out of the EU in this area.

[kakwa_]

I feel like more money would not have helped that much. Maybe it would have enabled a few of the devs to work on it full time, but I doubt it would have brought more people into the project.

I would indeed love the EU to step in but not in the way you are probably thinking.

I would rather see such effort being made unnecessary through a law forcing the manufacturers to provide enough information/specification or even code for alternative/after-market OSes to be viable on the devices they produced.

And also, if possible, mandate a degree of standardization (looking at you Android phones and ARM SBCs) enabling commonality of efforts when supporting a device class.

[samiv]

Like they say, "when you're 90% done you just need to take care of the other 90%"

[mort96]

The way mainline kernel development happens is that people work in their own fork and then send patches upstream, just like what Asahi is doing. The only thing that makes Asahi special is that there's so much weird bespoke hardware which requires special drivers. But nobody develops directly against Linus's tree.

[flomo]

What everyone is missing is any org who pays Ubuntu or RedHat for support is going to buy officially supported hardware from Lenovo, Dell, Framework or etc. Asahi is a cool project, but there's zero money in it.

[cybercatgurrl]

as someone who has had several official asahi fedora remix updates break the boot up of a m1 mac mini, this is it. it’s just too damn risky. i’ve had it happen so frequently that i’m genuinely at a point where im considering retiring the machine for something more stable and less likely to break during an update and it’s not even like i used it for a GUI, it’s a headless machine.

i would genuinely advise anyone thinking about seriously using asahi to consider another machine for uptime and stability

[KetoManx64]

That's the amazing thing about Linux. It's free and open source and not beholden to shareholders and having to have a fully fleshed out project that they can make money on. I have an M1 Macbook Air with Asahi running as the default OS. I'm very satisfied and happy with it, even though there's some things that could be better (eg. The battery draining 1%/hour while it's sleeping). I would much rather have Asahi as it is than not have it because it's "Not 100% feature complete". I don't really care that it's not polished enough for "general audience

[rweichler]

I'm with you. This entire game has already played out in the iOS jailbreak scene.

[throwaway27448]

What does "mainlined" driver development even look like?

[2OEH8eoCRo0]

It's disappointing that so much talent is wasted trying to support user hostile Apple hardware.

[Danox]

What is disappointing? Is that a three ex Apple engineers could get a license from Arm and design chips there’s got to be talent in Europe to do that and to also follow up and do something with Linux as a OS. It just baffles me why all this effort is spent trying to be a parasite on someone else’s chip the talent is there in Europe to go the full distance an offer something that isn’t dependent upon someone else?

I am rooting for someone to do something from the ground up in Europe. Maybe it’s gonna take someone that’s still in junior high, high school, or college who doesn’t know any better and is open towards breaking out of the boundaries.