Back in the late 2000s, I was a major contributor to the Wii homebrew scene. At the time, I worked on software (people call them “jailbreaks” these days) to allow users to run their own unofficial apps on the Nintendo Wii.
I was passionate about my work and the team I was part of (Team Twiizers, later fail0verflow). Despite that, I ended up burning out, primarily due to the very large fraction of entitled users. Most people using our software just wanted to play pirated games (something we did not support, condone, or directly enable). We kept playing a cat and mouse game with the manufacturer to keep the platform open, only to see our efforts primarily used by people who just wanted to steal other people’s work, and very loudly felt entitled to it. It got really old after a while. As newer game consoles were released, I ended up focusing on Linux ports purely for fun, and didn’t attempt to build a community nor work on the jailbreaks/exploits that would end up becoming a tool used by pirates.
When Apple released the M1, I realized that making it run Linux was my dream project. The technical challenges were the same as my console homebrew projects of the past (in fact, much bigger), but this time, the platform was already open - there was no need for a jailbreak, and no drama and entitled users who want to pirate software to worry about. And running Linux on an M1 was a much bigger deal than running it on a PS4.
I launched the Asahi Linux project, and received an immense amount of support and donations. Incredibly, I had the support I needed to make the project happen just a few days after my call to action, so I got to work. The first couple of years were amazing, as we brought the platform from nothing to one of the smoothest Linux experiences you can get on a laptop. Sure, there were/are still some bits and pieces of hardware support missing, but the overall experience rivaled or exceeded what you could get on most x86 laptops. And we built it all from scratch, with zero vendor support or documentation. It was an impossible feat, something that had never been done before, and we pulled it off.
Unfortunately, things became less fun after a while. First, there were the issues upstreaming code to the Linux kernel, which I’ve already spoken at length about and I won’t repeat here. Suffice it to say, being in a position to have to upstream code across practically every Linux subsystem, touching drivers of all categories as well as some common code, is an incredibly frustrating experience.
But then also came the entitled users. This time, it wasn’t about stealing games, it was about features. “When is Thunderbolt coming?” “Asahi is useless to me until I can use monitors over USB-C” “The battery life sucks compared to macOS” (nobody ever complained when compared to x86 laptops…) “I can’t even check my CPU temperature” (yes, I seriously got that one).
And, of course, “When is M3/M4 support coming?”
For a long time, well after we had a stable release, people kept claiming Asahi Linux and Fedora Asahi Remix in particular were “alpha” and “unstable” and “not suitable for a daily driver” (despite thousands of users, myself included, daily driving it and even using it for servers).
No matter how much we did, how many impossible feats we pulled off, people always wanted more. And more. Meanwhile, donations and pledges kept slowly decreasing, and have done so since the project launched. Not enough to spell immediate doom for my dream of working on Asahi full time in the short term, but enough to make me wonder if any of this was really appreciated. The all-time peak monthly donation volume was the very first month or two. It seemed the more things we accomplished, the less support we had.
I knew burnout was a very real risk and managed this by limiting my time spent on certain areas, such as kernel upstreaming. This worked reasonably well and was mostly sustainable at the time.
Then 2024 happened. Last year was incredibly tumultuous for me due to personal reasons which I won’t go into detail about. Suffice it to say, I ended up traveling for most of the year, all the while having to handle various abusers and stalkers who harassed and attacked me and my family (and continue to do so).
I did make some progress in 2024, but this left me in a very vulnerable position. I hadn’t gotten nearly as much Asahi work done as I’d liked, and the users weren’t getting any quieter about demanding more features and machine support.
We shipped conformant Vulkan drivers and a whole emulation stack for x86-64 games and apps, but we were still stuck without DP Alt Mode (a feature which required deep reverse engineering, debugging, and kernel surgery to pull off, and which, if it were to be implemented properly and robustly, would require a major refactor of certain kernel subsystems or perhaps even the introduction of an entirely new subsystem).
I slowly started to ramp work up again at the beginning of this year, feeling very stressed out and guilty about having gotten very little work done for the previous year. “Full” DP Alt support was still a ways away, but we were hoping to ship a limited version that only worked on a specific Type C port for each machine type in the first month or two of the year. Sven had gotten some progress into the PHY code in December, so I picked it up and ended up beating the code of three drivers into enough shape that it mostly worked reliably. Even though it wasn’t the best approach, it was the most I could manage without having another huge bikeshed discussion with the kernel community (I did try to bring the subject up on the mailing lists, but it didn’t get much response).
The issues Rust for Linux has had surviving as an upstream Linux project are well documented, so I won’t repeat them in detail here. Suffice it to say, I consider Linus’ handling of the integration of Rust into Linux a major failure of leadership. Such a large project needs significant support from major stakeholders to survive, while his approach seems to have been to just wait and see. Meanwhile, multiple subsystem maintainers downstream of him have done their best to stonewall or hinder the project, issue unacceptable verbal abuse, and generally hurt morale, with no consequence. One major Rust for Linux maintainer already resigned a few months ago.
As you know, this is deeply personal to me, as we’ve made a bet on Rust for Linux for Asahi. Not just for fun (or just for memory safety), either: Rust is the entire reason our GPU driver was able to succeed in the time it did. We have two more Rust drivers in our downstream tree now, and a third one on track to be rewritten from C to Rust, because Rust is simply much better suited to the unique challenges we face, and the C driver is becoming unmaintainable. This is, by the way, the same reason the new Nova driver for Nvidia GPUs is being written in Rust. More modern programming languages are better suited to writing drivers for more modern hardware with more complexity and novel challenges, unsurprisingly.
Some might be wondering why we can’t just let the Rust situation play out on its own over a longer period of time, perhaps several more years, and simply maintain things downstream until then. One reason is that, of course, this situation is hurting developer morale in the present. Another is that our Apple GPU driver is itself major evidence that Rust for Linux is fit for purpose (it was the first big driver to be written from scratch in Rust and brought along with it lots of development in Rust kernel abstractions). Simply not aiming for upstream might be seen as lack of interest, and hurt the chances of survival of the Rust for Linux effort. But there’s more.
In fact, the Linux kernel development model is (perhaps paradoxically) designed to encourage upstreaming and punish downstream forks. While it is possible to just not care about upstream and maintain an outright hard fork, this is not a viable long-term solution (that’s how you get vendor Android kernel trees that die off in 2 years). The Asahi Linux downstream tree is continuously rebased on top of the latest upstream kernel, and that means that every extra patch we carry downstream increases our maintenance workload, sometimes significantly. But it goes deeper than that: Kernel/Mesa policy states that upstream Mesa support for a GPU driver cannot be merged and enabled until the kernel side is ready for merge. This means that we also have to ship a Mesa fork to users. While our GPU driver is 99% upstreamed into Mesa, it is intentionally hard-disabled and we are not allowed to submit a change that would enable it until the kernel side lands. This, in practice, means that users cannot have GPU acceleration work together with container technologies (such as Docker/Podman, but also including things like Waydroid), since standard container images will ship upstream Mesa builds, which would not be compatible. We have a partial workaround for Flatpak, but all other container systems are out of luck. Due to all this and more, the difficulty of upstreaming to the Linux kernel is hurting our downstream users today.
I’m not the kind to let injustices go when I see them, so when yet another long-term maintainer abused his position to attempt to hinder R4L and block upstreaming progress, I spoke out. And the response (which has been pretty widely covered) was the last drop that put me over the edge. I resigned from my position as an upstream maintainer for Apple ARM support, as I no longer want to be involved with that community. Later in that thread, another major maintainer unironically stated “We are the ‘thin blue line’”, and nobody cared, which just further confirmed to me that I don’t want to have anything to do with them. This is the same person that previously prompted a Rust for Linux maintainer to quit.
But it goes well beyond the public incident. In the days that followed, I learned that some members of the kernel and adjacent Linux spaces have been playing a two-faced game with me, where they feigned support for me and Asahi Linux while secretly resenting me and rallying resentment behind closed doors. All this occurred without anyone ever sending me any private email or otherwise clueing me into what was going on. I heard that one of these people, one who has a high level position in multiple projects that Asahi Linux must interact with to survive, had sided with and continues to side with individuals who have abused and harassed me directly. Apparently there were also implied falsehoods, such as the idea that I am employed by someone to work on Asahi (I am not, we have zero corporate sponsorship other than bunny.net giving us free CDN credits for the hosting).
I get that some people might not have liked my Mastodon posts. Yes, I can be abrasive sometimes, and that is a fault I own up to. But this is simply not okay. I cannot work with people who form cliques behind the scenes and lie about their intentions. I cannot work with those who place blame on the messenger, instead of those who are truly toxic in the community. I cannot work with those who resent public commentary and claim things are better handled in private despite the fact that nothing ever seems to change in private. I cannot work with those who denounce calling out misbehavior on social media to thousands of followers, while themselves roasting people both on social media and on mailing lists with thousands of subscribers. I cannot work with those in high-level positions who use politically charged and discriminatory language in public and face no repercussions. I cannot work with those who say I’m the problem and everything is going great, while major supporters and maintainers are actively resigning and I keep receiving messages from all kinds of people saying they won’t touch the Linux kernel with a 10-foot pole.
When Apple released the M1, Linus Torvalds wished it could run Linux, but didn’t have much hope it would ever happen. We made it happen, and Linux 5.19 was released from an M2 MacBook Air running Asahi Linux. I had hoped his enthusiasm would translate to some support for our community and help with our upstreaming struggles. Sadly, that never came to pass. In November 2023 I sent him an invitation to discuss the challenges of kernel contributions and maintenace and see how we could help. He never replied.
Back in 2011, Con Kolivas left the Linux kernel community. An anaesthetist by day, he was arguably the last great Linux kernel hobbyist hacker. In the years since it seems things have, if anything, only gotten worse. Today, it is practically impossible to survive being a significant Linux maintainer or cross-subsystem contributor if you’re not employed to do it by a corporation. Linux started out as a hobbyist project, but it has well and truly lost its hobbyist roots.
When I started Asahi Linux, I let it take over most of my life. I gave up most of my hobbies (after all, this was my dream hobby), and spent significantly more than full time working on the project. It was fun back then, but it’s not fun any more. I have an M3 Pro in a box and I haven’t even turned it on yet. I dread doing the bring-up work. It doesn’t feel worth the trouble.
I miss having free time where I can relax and not worry about the features we haven’t shipped yet. I miss making music. I miss attending jam sessions. I miss going out for dinner with my friends and family and not having to worry about how much we haven’t upstreamed. I miss being able to sit down and play a game or watch a movie without feeling guilty.
I’m resigning as lead of the Asahi Linux project, effective immediately. The project will continue on without me, and I’m working with the rest of the team to handle transfer of responsibilities and administrative credentials. My personal Patreon will be paused, and those who supported me personally are encouraged to transfer their support to the Asahi Linux OpenCollective (GitHub Sponsors does not allow me to unilaterally pause payments, but my sponsors will be notified of this change so they can manually cancel their sponsorship).
I want to thank the entire Asahi Linux team, without whom I would’ve never gotten anywhere alone. You all know who you are. I also give my utmost gratitude to all of my Patreon and GitHub sponsors, who made the project a viable reality to begin with.
If you are interested in hiring me or know someone who might be, please get in touch. Remote positions only please, on a consulting or flexible time/non exclusive basis. Contact: marcan@marcan.st.