Asahi Linux Progress Linux 7.0
asahilinux.org
asahilinux.org
> 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.
So either someone said "we must disallow the other options" or they didn't and it's a bug.
i think the only time ive ever run into an apple engineer was on mastodon related to gptk it was interesting to see they actually are quite tuned into what is possible on these devices and what that could mean for gaming. despite being a developer toolkit to help studios get a read on the work needed to optimize a game for a metal port, they were expressing that they were well aware such tools showed a lot of promise for getting games going on mac. not much of a gamer myself, but thought it was interesting to see a slice into engineering there & that they weren't as hostile as HN would believe them to be and broadly aligned with many of us. id be mega curious what apple engineers think about asahi.
E.g, an AppKit engineer or two, or the primary dev behind Rosetta 2. Not so sure of any hardware-engineers tho.
Very rarely. I believe because Apple has a culture of secrecy and contractually forbids employees from sharing details about their work in most circumstances (and actually enforces this).
There’s also extreme secrecy both between teams on different projects and even between teams within the same project just working on different parts of it. At least that was my experience.
I did enjoy my time there, but it was a very unique/strange development culture.
If Apple only focuses on audible sounds, their devices lack the ability to maximize the thrill of horror movies.
[0] https://en.wikipedia.org/wiki/Infrasound
[1] https://nightscapestories.com/the-art-of-sound-design-horror...
[2] https://www.theguardian.com/science/2026/apr/27/spooky-feeli...
https://github.com/hasenbanck/resampler#quality-analysis
This is presumably what Apple does. You kind of have to anyway or you have the stupid situation Linux used to have where only one app could play audio at a time.
When was that? I think my first Linux distribution was Ubuntu 8.04 and fairly sure it shipped with PulseAudio which in mind always been able to play audio from multiple sources at the same time, maybe I misremember?
Upsite: Highest quality playback.
Downside: Only one process could play audio at a time.
The most common solution at the time was PulseAudio, which was so bad it usually was better to just use direct ALSA and live with the idiotic one-at-a-time limitation.
Thankfully Pipewire seems to actually work reliably so I guess that's at least one thing ticked off the Year of the Linux Desktop checklist.
Which is why the whole "we must use pulseaudio even if it's terrible and has awful standards that blast volume or multiple streams won't work!" was so weird… everybody who tried knew that just removing pulseaudio the multiple streams kept working :)
So only those who never applied the scientific method kept insisting that without PA it was not possible to do that.
Around 2000 I was only able to play sound from different apps because my soundcard exposed two sound devices /dev/dsp0 and /dev/dsp1
I still don’t know what purpose pulseaudio serves, other than adding latency and making stuff less reliable.
PipeWire is better, but it turns out you can just use OSS under freebsd these days, and everything just works, but with lower latency.
If you have some sort of potato sound card that can’t mix output channels in hardware, note that OSS added sw mixing by 2007 (with support for 16 channels by default).
OpenBSD still present raw audio devices, but they have sndio which provides a more helpful interface for applications including resampling (not the best algorithms there, according to them).
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.
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.
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.
But that would probably result in burn out from the crazily talented dev team :P
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.
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.
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.
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.
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)
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.'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.
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.
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.
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.
> 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.
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.
They do try to upstream and eventually just have Linux natively support Apple Silicon!
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.
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.
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.
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.
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.
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.
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.
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.
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.
i would genuinely advise anyone thinking about seriously using asahi to consider another machine for uptime and stability
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 only way to get the battery life Framework advertised is on Windows' 'Ultra Efficiency' mode which cuts CPU performance by 25-50%, lowers brightness by 30% and deprioritizes everything in the background to such an extreme that responsiveness of those is measured in seconds.
It is not comparable at all to M-series or Snapdragon laptops happily chugging along at full capability and getting (compared to AMD / Intel) stellar battery life.
Anecdotally, comparing to recent (but still older than these) generations of Intel chips I can run my M2 Max MacBook Pro with 78% battery health for longer (without any special considerations) than colleagues running their Windows Intel laptops in Power Saver mode, while performing similar tasks.
https://www.jeffgeerling.com/blog/2026/arm-mainboard-for-fra...
- Screen
- Speakers
- The unbelievable trackpad
- Battery life
- GPU performance (Linux gaming on this would be amazing)
When I play Bitburner, if I want to run it in the background, I have to run the game on Firefox or chrome. It’s a shame because safari actually gives best performance by quite a large margin.
Of course, currently Asahi only supports up to M2, so if you really want Linux, the Panther Lake should still outperform most of the 4 year old M2 devices. It remains to be seen which of the following can come sooner:
* new faster chips come out that support Linux
* Asahi finally supports M5
Right now it seems that the former is more likely to be true. But we shall see.
35% is the generational difference between the M4 pro to the M5 pro¹. Don't drink Apple marketing koolaid: this has less to do with x86 falling behind than it has to do with Apple using their stash of gold to outbid the intel/AMD competition out of the latest TSMC capacity.
An M4 Pro 12c gets 32731 out of TSMC's 2nm-E².
An AMD Ryzen AI 9 HX 370 gets 35093 out of TSMC's 4nm³.
The true unsung hero of the "Apple M miracle" is TSMC, not ARM, and Apple mostly in the sense that it has the deepest pockets.
With the first M chips, anyone who could afford to wait 18-24 months was pretty much where Apple was at. This decreased to 12-18 months in the last couple years. Panther lake signifies that it could further decrease to 9-12 months.
¹: https://www.cpubenchmark.net/compare/6346vs6345vs7230vs6397v...
²: https://www.notebookcheck.net/Apple-M4-Pro-12-cores-Processo...
³: https://www.techpowerup.com/cpu-specs/ryzen-ai-9-hx-370.c365...
Don't get me wrong. I do really enjoy my FW but the mac hardware is still number one for me. I'd really love is an ARM based FW. Though if I could wave a magic wand it would be mac hardware running pure linux with no caveats. I really love seeing what Asahi is building
My variosu Linux adventures have always resulted in doing random patches for audio or screen incompatibility.
My windows days were plagued with battery issues.
I feel like most Linux ricers wishs for a MacOS-like experience, except with more customisation. (Which is entirely possible now with the ricing on Mac)
This is the kind of dated argument that really makes me dismiss most of the critics. I was running xubuntu as my main desktop since 2010 at least, switched to Debian + nix + XFCE in 2022 and switched to full-on nixOS in 2024. I never had issues with audio then and had to go out of my way to "break" audio on NixOS when I wanted to try pipewire instead of pulse.
> feel like most Linux ricers wises for a MacOS-like experience
I've put together a Hackintosh once, tried for a few weeks as the daily driver. Aside from being able to use tools that dealt with real-time audio processing, there was nothing else I wanted to copy or bring to my Linux system. It cemented my opinion that most software developers that keep touting the "superiority of MacOS" never gave a fair shot at Linux on decent hardware and were just rationalizing their prior choice.
I am not a Linux novice, I have been using every major OS for decades at this point, but I’ll be damned if I didn’t install Windows, decrapify it, and everything just worked. You can say I should have done more research on hardware compatibility or whatever, but I didn’t have to for Windows.
And I like how you complain most devs never give Linux a fair shot on decent hardware right after describing that you MacOS experience is a hackintosh. That makes a lot of sense.
I'm not saying that I was expecting to run a Hackintosh and suddenly get the advantages of Apple hardware. I am doing a pure software-to-software comparison.
There was no application in the MacOS desktop that made me feel like I was missing out on something. Of all the tools that I am used to use - emacs + developer tools, email clients, messaging clients, media players, media managers, browsers, the occasional office productivity - none of the MacOS counterparts had any significant advantage over what I have in a Linux desktop.
I would argue this is impossible at this point. Most of the benefits of the entire Apple ecosystem are about integration - Macbook Pros are the fastest machines with the best battery life because of the great hardware but also the software integration.
> There was no application in the MacOS desktop that made me feel like I was missing out on something. Of all the tools that I am used to use - emacs + developer tools, email clients, messaging clients, media players, media managers, browsers, the occasional office productivity - none of the MacOS counterparts had any significant advantage over what I have in a Linux desktop.
This isn't really comparing OSes is it? You're comparing software that runs on the OS. Every tool I have on my linux machines I have an equivalent tool for on Mac, or I use the same tool, but the Macbook with MacOS is a workhorse that I can trust to "just work."
I don't think desktop Linux is bad, not by any means, and there are reasons I still go to it first on my personal machines until something forces me to make a different decision, but I also get tired of Linux users telling all of us that our experiences are old and all of these issues are fixed when they're just not, even if that isn't Linux' or the distro's fault.
All this wall of texts to say that, respectfully, when you write >Earlier this year I built a new desktop and installed my normal Linux distro and the screen wouldn’t work after login the issue might simply be that you are doing something very wrong and/or not following the proper instructions for whatever distro you are using.
But I've had multiple Lenovo laptops not work with Ubuntun or nixOS in multiple situations.
Any new yoga variants just always had trouble.
E.g. my yoga slim 7i had a keyboard issue in Ubuntu such that for the first minute, I can't use my keyboard. Had to change boot configbto use "dumb keyboard" or something
The yoga also had speaker issues in nixos as the drivers haven't been mainlined yet. It was onenof those 6 speaker (2 tweeter) setups. I had to download a random driver and chuck it in my nix config to get the subwoofers working.
I gave up after mic issues in multiple zoom calls or gmeet calls.
You can say it's all skills issue, but Mac worked first try.
And, of course macs work first try. Apple makes both the hardware and software, if it didn't work it would be extremely impressive. The fact it's working is expected, not exceptional or noteworthy.
How interesting! This mirrors my experience with some of my devices, and not with some of my others.
> All this wall of texts to say that, respectfully, when you write >Earlier this year I built a new desktop and installed my normal Linux distro and the screen wouldn’t work after login the issue might simply be that you are doing something very wrong and/or not following the proper instructions for whatever distro you are using.
Ahh yes, the complicated instructions of writing the ISO to a thumb drive, running the installer, and trying to login after the installation is complete.
My sin was using a current gen nvidia GPU (a 5080) and a 4K monitor with high refresh rates. This unprecedented combo fails to make the transition from SDDM to Plasma Wayland with the latest (at the time) nvidia drivers baked into the distros I tried. Fortunately, I wasn't alone in this issue based on the forum posts across a couple of distros, so I can be confident that at least some others failed to hold it right as well.
You can blame Linux all you want but there's nothing anybody can do except Nvidia. The whole thing is locked down, no distro or developer on Earth can save Nvidia users.
I don’t understand all the folks who crawl out of the woodworks as Acolytes of the Holy Linux Empire every time this topic comes up. Linux is a good desktop OS these days, it is my default, but I don’t have any problems acknowledging its issues and moving to another OS if it can’t meet my needs or if I have hardware/software that it has issues with.
What I am refuting is basically the idea that MacOS provides a better "experience" than a modern LInux Desktop installed on any reasonably conventional hardware.
I don't refute that are limitations on Linux. I am not saying that it will run everywhere flawlessly. But I am saying that the average college student, the average "web developer" and the average "elderly folk with basic computing needs" can have a good desktop experience without being forced to pay the Apple tax.
Any new yoga variants just always had trouble.
E.g. my yoga slim 7i had a keyboard issue in Ubuntu such that for the first minute, I can't use my keyboard. Had to change boot configbto use "dumb keyboard" or something
The yoga also had speaker issues in nixos as the drivers haven't been mainlined yet. It was onenof those 6 speaker (2 tweeter) setups. I had to download a random driver and chuck it in my nix config to get the subwoofers working.
I gave up after mic issues in multiple zoom calls or gmeet calls.
You can say it's all skills issue, but Mac worked first try.
Not giving Linux a fair shot is not something I'd categorise myself doing given how much I riced my dell xps back in the day.
Did you ever do any DAW ? Did you have to use is jackd ?
Stuff like streaming games from my desktop in a non native resolution is a no-go with Wayland. I can't do HDMI 4k/120 with HDR/VRR like I can on windows (I know it's HDMI fault, but that doesn't change the fact it doesn't work).
Oh and I've given up on using Linux for productivity a year ago - one can take only so many full browser crashes for simple stuff like desktop sharing, camera/mic stopping mid call.
I'm running linux on my desktop with about as vanilla hardware as you can imagine - the amount of compromises/stuff that just doesn't work is quite annoying.
It's just nowhere near the level of reliability of MacOS - that's why I use my air for productivity and I SSH into the workstation to do actual work in VMs (with all the recent supply chain compromises no way in hell I'm ever doing dev work outside of a sandbox environment).
I've never used a device that claims first party linux support so maybe it's better.
But honestly I'm not a fan of linux desktop in general - flatpack is nice in theory but comes with so many "gotchas" and installing stuff otherwise is just "here you have all the privileges of my user". MacOS sandboxing/security scoping feels way better for desktop use.
Everything else I have it on pretty much "just works". I am not a big gamer, but Steam works. Bluetooth works. Wi-Fi works. It detects my printer and scanner better than my wife's windows laptop. No browser crashes.
NixOS is well supported on the Framework and on my workstation. The worst type of inconveniences I have nowadays would be things like what I had some weeks ago: Zoom wouldn't find an already-running process and would get stuck in a loop, solved it by running "nixos-rebuild switch --upgrade".
Compare that with the complaints that you hear from Apple users and the constant reporting on declining quality on MacOS and iOS, and you see why I take issue with statements like "most linux users want the MacOS experience, except with more customization".
Modern Apple laptops seem less special now but you also have to look at them through the lens of their introduction.
A similar thing is true for Sonos. They don't seem all that special now, but you have to realize they have been offering multi-room synced audio with a good UX since 2006. That's before the iPhone even was released.
On Apple hardware. Call me when you put MacOS on any random laptop and get suspend to work.
Windows and Linux is judged by whether it works on any hardware, including the so-cheap-it-should-not-have-been-produced-ever machines, that will obviously just plain suck. No amount of software can save shitty hardware.
Also, Linux expressly aims to run on a wide array of hardware, and macOS doesn’t. So Linux should be judged across a large range of hardware and macOS shouldn’t, in the same way a Jeep should be judged on its off-roading abilities and a Civic shouldn’t.
:/
That combined with a lack of good creative software on Linux kind of kills it for me. I’d rather use it than Windows, but MacOS seems like the best option currently.
Some people seem to get better battery life with Windows than with Linux.
Most users on any OSes are not ricers. Most of my customisation is functional - panels and widgets placed for practical reasons. A lot of people do not seem to customise at all, or barely.
MacOS is sometimes so weird and inconsistent that it's hard to tell whether it's a bug of Apple usual's "you are not smart/cool-enough to understand" kind of feature.
Is that on Mac hardware? I run a 14 year old Mac Book Air, and it works flawlessly with the latest Nixos, and has done for the last 11 years.
If you have issues on random PCs, it's because there are an enormous variety of them out there, with all kinds of incompatibilities that have to be worked around. On Mac hardware, there tends to be a more restricted number of variants, and after a few years, Linux becomes rock solid on them.
So the OP is correct, Linux on Mac hardware is the best combo.
M series Macs are still very much a work in progress. I'm typing this on one, in Linux, so plenty of things work, but not for example USB-C output to an external display, and a lot of the processor power level / suspend stuff is still not fully there so battery life is quite a bit worse, especially when suspended. I think the situation is rather worse on the latest generation hardware, too.
I was burned by the 2016 MacBook Pro keyboard, and once Liquid Ass was announced I knew it was time to get out.
Sold my MacBook Pro M2 Pro, which has a stupid gigantic notch that blocks the menu bar items with no built-in mechanism for getting to them when they overflow.
Now I’m on a Framework 13” and I’ve had zero issues with Linux. Everything just works. KDE Plasma is way more customizable than macOS or Windows. I’m finally able to ditch slow Homebrew and use a real package manager. I can finally play light PC games on my laptop without dealing with streaming or Crossover.
My preorder is in for the Framework 13 Pro, which looks to get even closer to delivering a MacBook Pro for Linux. Meanwhile, Apple hasn’t changed their chassis design in 5 years, while Framework updates their hardware constantly while maintaining cross-compatibility. A company with less than 500 employees is catching up to a trillion dollar corporation.
I’ve already got my fully modular LPCAMM RAM delivered and ready with no Apple tax. I’ll get better battery life watching YouTube videos than a MacBook Pro and the graphics are just as powerful as the M5 base chip.
And if something breaks I won’t have to deal with the nightmare I went through with my 2016 MacBook Pro.
What that convinced me of is that macOS is just not for power users.
Definitely good to have the option, but you'll most likely never get quite the same performance or battery life on linux
Linux GUIs are _fine enough_ though the jank is still present. The good news is they will get better with more users entering the chat.
The thing to note is that, we don't want to confuse "it's not as good right now" with "It's bad so I will never use it" because that signals a lack of interest.
There is a non-zero chance that Apple could be compelled to support it if enough people express interest (historically, they have with bootcamp).
Competition is good, even if the competition is bad right now. We must encourage it.
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
Sad because I really want the better One drive integration that Ubuntu 24+ comes with.
But who should AMD for example target? It seems obvious to me. Personally I think if you are trying to make tools like ai acceleration software, you should 100% be focused on the alpha geeks. The people who want bleeding edge new stuff, the people who will take that and roll with it and expand your ecosystem are almost entirely the early adopters. The progressives are the social tastemakers, are the point on the adoption curve where cool and good happens.
It's infuriating watching AMD bungle their chances by targeting people interested in ancient technology, for their incredibly advanced powerful rich new stack. What are you doing?!?! There needs to be a starting point for the alpha geeks, those who are willing.
I used to be a tech enthusiast who installed the latest bleeding edge everything.
Now days I need a stable machine that lets me work. Sometimes my work is bleeding edge, but I want my machine to be boring and stable.
I can't run the latest open source models if I can't get my machine to even boot.
Also some of the latest AI stuff (desktop control, full screen recording, etc) doesn't support wayland. E.g. https://pieces.app/ prefer x11 due to the simpler security model.
> * we need to build our business by offering the best possible product to the most excited community.*
https://news.ycombinator.com/item?id=47936612
TheRock is so close but there just doesn't seem to be an eye on the ball for actually making this usable. This stack of issues blocking even vaguely modern systems has been sitting untouched for months.
All the classic reasons ("competitive advantage", "secrets", etc) do not hold water in this day and age.
Apple documents lots of things the genius bar won't help with. For example, Apple provides instructions for compiling custom builds of the XNU kernel. However, if you replace the stock kernel and your Mac kernel panics, the genius bar isn't going to help you. (Maybe they'd help you wipe the computer and restore everything to stock, but I imagine they'd do that if a Linux user walked in too, even today.)
I suspect Apple hasn't shared documentation because it would take time to prepare for external release (legal stuff, plus the need to avoid leaking future products). What I don't understand is why Apple hasn't made an engineer available to talk on the phone for a couple of hours a month. This would amount to a rounding error in their budget.
What do you mean by needed? A lock-in is more profitable so is needed to maximise profits.
You can't lock-in Linux users because vast majority of them won't switch to macOS and ecosystem at large. This is simply a currently untapped market they could easily almost entirely own if they wanted to. With growing Linux popularity, extra 3-4% of the laptop market share is nothing they can ignore in front of shareholders.
untrue. There are no obligations from other hardware vendors, yet you can sometimes get good drivers from them, or at least specs. I think Apple indeed want their hardware to fade out to enforce buying another. Imagine that 20% of your returning customers no longer return after 3-5 years of planned obsolence
Go team Asahi!
A 1-3% of the market out of the 5% that Linux already is, is little to no monetary benefit?
Apple's MO is that it's their baby. End of. They don't do open. Their compiler is closed source, and so on.
I’d love to dual boot Linux too but I’m under no delusions about being a very small segment of the Mac population.
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.)
Could I then submit a warranty claim and demand Apple replace my aging laptop with their latest model?
But the US still doesn't have the right to repair hardware, haha.
I hope the EU is listening. They won't get far with their sovereign software push if hardware cannot be used. Even on the Android side, you can't write an alternative to Android because all of the hardware has locked bootloaders and hidden drivers. Good luck reverse engineering the hardware/drivers on a Samsung Galaxy - let alone an iPhone or MacBook.
I'm running asahi on my macbook. And never touch OSX. I wouldn't even had gotten it if asahi wasn't so well supported.
Important context to understand why.
There's a portion of another market: people who want to run Linux and want a powerful laptop who buy x86 Laptops right now. Apple could expend very little relative effort while offering no official support by helping Asahi get that to a first class platform. They won't capture them in the ecosystem (and they never would have) but will still benefit from hardware sales to them.
Obviously, if they sold their hardware at a loss and subsidized that with ecosystem capture that would be a non-starter. But from everything we know, the hardware itself is very profitable.
We really need to retire this phrase, it’s become a humblebrag way of calling the other party delusional without even trying to understand.
The list here though is long: priorities, accuracy concerns, blurring the line on official support, IP restrictions with third parties (even Apple uses plenty of licensed cores), etc.
> We really need to retire this phrase, it’s become a humblebrag way of calling the other party delusional without even trying to understand.
My dear friend I thought I was alone on this hill. It brings a tear to my eye, to learn I will not die alone.
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.
Ok typical X/Wayland setups, Cmd is already the main modifier for DE features, while Ctrl is the modifier used at an application level.
There would be a lot of weird overlap with changing that.
DE features don't matter at all outside of cmd-tab and whatever the equivalent of spotlight is. The application level is the main modifier, and changing them all to cmd is essentially impossible at this point. A detail Haiku got just about perfect, I think.
Either way, ctrl as a gui modifier is a dealbreaker for me. It also breaks the use of readline keybindings for text entry.
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.
> 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!
either Asahi gets there from the software side or Framework gets there from the hardware side
Look forward to switching back to Asahi full time soon!!
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... :-/
1: https://forum.cgsecurity.org/phpBB3/viewtopic.php?p=39143#p3...
I still want to run it on an M3 MBP so it's nice to hear progress on that is happening.
Intelligence comes in many forms. This decision is one of them.
When is Asahi likely to be viable as a daily OS?
I think I'm going back to Linux when this laptop is no longer functioning.
Maybe I'll be returning to Lenovo.
Now there are things I can't get with Linux that I value with macOS. The integration with the phone is just not possible if am running Linux. The power management and convenient things like Apple Music, too.
I was disgusted to see Tim Cook abase himself before Trump and spent a while researching alternative phones. I did not find anything that looked like a serious option. There are things I need that are only available for iPhone or Android, it's become table stakes for life nowadays. My E-car charger required an app to function, for instance.
I admire people who "vote with their wallet" and/or suffer inconvenience for their ideals. But I am not going to install Linux (or OpenBSD) on my M1 Macbook pro. It's too essential for me the way it is.
For the record, I pour a lot of time into my 2014 macbook running arch and a thinkpad running OpenBSD, and keep an arch server/desktop running pretty much 24/7. I spend tons of time trying to find/devise things on Linux to match things I use that are closed-source/apple only.
Hats off to people who can program at the level required to make this happen. It's beyond me. And also to those trying to make Pine Phone etc a realistic option. I think that's the most important free software battleground now.
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.
I mean, if you only use laptops that are explicitly unsupported by the Linux kernel then I could see what gave you that impression.
Well that's a weird choice of systems programming language.
[1] https://github.com/AsahiLinux/AsahiLinux.github.io/commit/e0...
Not to just shit all over him or anything, but it really sucks to see someone who is genuinely top-ten-on-earth when it comes to "real hacking" struggle so much with socialisation and mental health.
They do currently ban LLM-assisted submissions. To be honest, even if LLMs are technically capable of writing code that assists the project, this at least helps keeps the 'floodgate' closed for certain low-quality PRs that other open-source projects are getting.