These kind of project reports showing consistent breakthroughs and clearly a finger on the pulse of what users are encountering as pain points are a good indication that the Asahi team are real pros :)
Look forward to switching back to Asahi full time soon!!
It feels very close to “right to repair”. The coffee grinder you bought came as a single package but it has burrs, gears, machine screws, a motor, etc. If one of those components fails, we should be able to replace it ourselves and as such they should be documented.
The laptop has various pieces of hardware in it and corresponding drivers in macOS to make them tick. Did we buy the hardware and the drivers as an inseparable package, or should we be provided with the manual to make one component work when the other breaks, be that either third party trackpads or third party (Linux) drivers.
Apple might argue that drivers, unlike gears or motors, will never wear down and fail. They won’t need repairing so you don’t get to know how they work. Does right to repair only apply to products that could ever need repairing? Does it also extend to knowing how your purchased product is built so that you could repair it?
Maybe we’ll see a test case some day when a cosmic ray blows out /System/Trackpad.kext and a litigant applies to a court for the documentation to repair their laptop — to write their own driver!
(Or vice versa: a manufacturer of coffee grinders arguing in court that they are exempt from right-to-repair because they repair their machines for free at their Genius Espresso Bar.)
I think the biggest value Apple gets from Asahi is they can point EU regulators at it as proof the Mac isn't a closed platform that should be a designated DMA gatekeeper. They don't need Asahi to be complete, they just need it to exist.
I wonder if there would be interest in an Asahi Remix spin focused on a more Mac-like out-of-the-box experience: cmd as the main modifier key, Mac-like keyboard shortcuts, theming, gestures, etc.
Of course, you can tweak any distro however you want, but I think a curated default experience is a different thing.
I’ve had the same thought and would love this. MacOS shortcuts are too deeply ingrained in my fingers.
But every attempt of mine to make Linux shortcuts Mac-like has had too many sharp edges to be useable.
Toshy didn’t seem to work well with Wayland and felt heavy.
Probably the best so far I’ve found has been keyd and custom configs for your most used apps.
A community effort might get us there. Distribute the hours of tinkering across many passionate users instead of everyone doing it in a vacuum.
>.. macOS only ever programs CS42L84 to operate at either 48 or 96 kHz, we could only add support for those two sample rates to the Linux driver ..
> However, CS42L42 supports all the other common sample rates, and while the register layout and programming sequence is different, the actual values programmed in for 48 and 96 kHz are the same across both chips. What would happen if we simply took the values for all other sample rates from the CS42L42 datasheet and added those to the CS42L84 driver? As it turns out, you get support for those sample rates!
> The patch to enable hardware support for 44.1, 88.2, 176.4 and 192 kHz sample rates on both the input and output of the headphone jack was submitted directly upstream, and has been merged for 7.1. We also backported this to Asahi kernel 6.19.9, allowing users to take advantage of this immediately.
Nice bit of chip sleuthing and reverse engineering from the Asahi team!
The following is actually the most surprising part to me.
> This is quite limiting, as it forces PipeWire to waste CPU cycles (and therefore battery life) on resampling audio streams that are not either 48 or 96 kHz.
So the Asahi team thinks that only supporting 48 or 96 kHz wastes battery life by forcing the software to resample audio streams. But why does Apple still do this? Presumably Apple has a very high commitment to save power and increase battery life.
I'm glad they dropped the ban on HN readers[1]. That was my very first impression of Asahi Linux that I ever encountered and it's unfortunately what I think of every time I see it show up here.
I really hope this project continues to gain momentum. Apple Hardware + Linux is the least fscked OS running on the best hardware. MacOS continues to be a tire fire with endless bugs and churn between versions.
Generally yes, but the community around MLX has rallied pretty strong. Sure your disk io is awful, and your OS is buggy, but at least ML compiles and works on a modern OS.
M3 support nearly at alpha is fantastic news, and I'm really looking forward to M4 in the future. I am not looking forward to whatever Apple has planned this year for macOS, or next.
Genuine answer: sometimes. I've done similar levels of reverse engineering. Keep in mind that LLMs, and all other AI, "think" as they are programmed to. When you need to do something they don't know how to do, because you're the first person in history to do it, it turns into a lot of hand holding. Especially when you're dealing with physical devices that can explode if misprogrammed, I've found it's best to keep them working on the lower hanging fruit.
While I love Asahi as such and am really blown away by the effort, my setup requires an encrypted ZFS root file system, which is unreasonably hard to achieve with a Mac.
The fact, that there has to be a macOS partition for maintenance ruling out ZFSBootMenu somehow is very unfortunate - but I've accepted it.
Maybe the new Framework 13 Pro will be at least in the region of an alternative... :-/
I’m curious, broadly, what is involved with this. I just got encrypted (LUKS) BTRFS root going on my two Asahi machines and it wasn’t _terrible_… but also definitely not easy.
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.
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.
> 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.
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.
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.
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.
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.
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.
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
Really hope that by the time all my M4 Macs are no longer updated by Apple I can just switch to Asahi and get a 1:1 compatible OS in terms of supporting all the hardware my Macs come with.
Nice to see M3 support coming along as they work their way through the upstreaming backlog and improve tooling:
> finding their way into the Asahi kernel tree are patches to enable more hardware on M3 machines. This includes support for PCIe, MacBook keyboards and trackpads support, the SMC-based RTC and reboot controller, and the NVMe controller, courtesy once again of Michael Reeves and Alyssa Milburn. This brings Linux support for the M3 up to roughly the same level as the first Asahi Linux alpha for M1!
I am both a monthly supporter of the Asahi project and a full-time macOS user. Why? I love to support hackers. But I am also a realist and have given up on the idea of a linux laptop that "just works" and have embraced teh first party experience of the wholly integrated software and hardware experience of the apple ecosystem.
am I just a smooth brained dumb dumb that has drunk the koolaid? perhaps. but I don't lose sleep on it and am not tinkering with hardware, or software anymore, I just get stuff done now.
The mentioned light sensor started malfunctioning on my work's m3 after upgrading to tahoe. After a sleep it sometimes dimms the screen at max. Thankfully I have the monitor control app which brings it back for me. Such unneeded and faulty mechanism.
Does somebody know the power values for idle and sleep for this release? When I tried Remix 43 on a m2 mb pro 1 month ago the idle power usage was above 5W (max 10h) and sleep roughly 3W (~20h).
66 comments
[ 0.30 ms ] story [ 52.8 ms ] threadLook forward to switching back to Asahi full time soon!!
All the classic reasons ("competitive advantage", "secrets", etc) do not hold water in this day and age.
The laptop has various pieces of hardware in it and corresponding drivers in macOS to make them tick. Did we buy the hardware and the drivers as an inseparable package, or should we be provided with the manual to make one component work when the other breaks, be that either third party trackpads or third party (Linux) drivers.
Apple might argue that drivers, unlike gears or motors, will never wear down and fail. They won’t need repairing so you don’t get to know how they work. Does right to repair only apply to products that could ever need repairing? Does it also extend to knowing how your purchased product is built so that you could repair it?
Maybe we’ll see a test case some day when a cosmic ray blows out /System/Trackpad.kext and a litigant applies to a court for the documentation to repair their laptop — to write their own driver!
(Or vice versa: a manufacturer of coffee grinders arguing in court that they are exempt from right-to-repair because they repair their machines for free at their Genius Espresso Bar.)
I wonder if there would be interest in an Asahi Remix spin focused on a more Mac-like out-of-the-box experience: cmd as the main modifier key, Mac-like keyboard shortcuts, theming, gestures, etc.
Of course, you can tweak any distro however you want, but I think a curated default experience is a different thing.
But every attempt of mine to make Linux shortcuts Mac-like has had too many sharp edges to be useable. Toshy didn’t seem to work well with Wayland and felt heavy. Probably the best so far I’ve found has been keyd and custom configs for your most used apps.
A community effort might get us there. Distribute the hours of tinkering across many passionate users instead of everyone doing it in a vacuum.
> However, CS42L42 supports all the other common sample rates, and while the register layout and programming sequence is different, the actual values programmed in for 48 and 96 kHz are the same across both chips. What would happen if we simply took the values for all other sample rates from the CS42L42 datasheet and added those to the CS42L84 driver? As it turns out, you get support for those sample rates!
> The patch to enable hardware support for 44.1, 88.2, 176.4 and 192 kHz sample rates on both the input and output of the headphone jack was submitted directly upstream, and has been merged for 7.1. We also backported this to Asahi kernel 6.19.9, allowing users to take advantage of this immediately.
Nice bit of chip sleuthing and reverse engineering from the Asahi team!
> This is quite limiting, as it forces PipeWire to waste CPU cycles (and therefore battery life) on resampling audio streams that are not either 48 or 96 kHz.
So the Asahi team thinks that only supporting 48 or 96 kHz wastes battery life by forcing the software to resample audio streams. But why does Apple still do this? Presumably Apple has a very high commitment to save power and increase battery life.
[1] https://github.com/AsahiLinux/AsahiLinux.github.io/commit/e0...
Works like rocm seem so close. But you need either the pre-compiled packages or 2+ year old Ubuntu to compile them. https://github.com/ROCm/TheRock/issues/3477
The fact, that there has to be a macOS partition for maintenance ruling out ZFSBootMenu somehow is very unfortunate - but I've accepted it.
Maybe the new Framework 13 Pro will be at least in the region of an alternative... :-/
I still want to run it on an M3 MBP so it's nice to hear progress on that is happening.
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.
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.
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.
They do try to upstream and eventually just have Linux natively support Apple Silicon!
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.
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.
either Asahi gets there from the software side or Framework gets there from the hardware side
> finding their way into the Asahi kernel tree are patches to enable more hardware on M3 machines. This includes support for PCIe, MacBook keyboards and trackpads support, the SMC-based RTC and reboot controller, and the NVMe controller, courtesy once again of Michael Reeves and Alyssa Milburn. This brings Linux support for the M3 up to roughly the same level as the first Asahi Linux alpha for M1!
am I just a smooth brained dumb dumb that has drunk the koolaid? perhaps. but I don't lose sleep on it and am not tinkering with hardware, or software anymore, I just get stuff done now.