> 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).
This sounds so rough. I can't imagine pouring your heart out into this labor of love and continue to have to face something like this. Back in the early days of Quora, when it used to be good, there used to be a be nice be respectful policy (they might still have it), I wonder if something like that would be helpful for open source community engagement.
Regardless, major props to Marcan for doing the great work that he did, our community is lucky to have people like him!
A person can be in a tough spot personally and then things seem to spiral out of control around them because that just cannot be 100% isolated from professional stuff or other spheres of life. It seems like this might have happened to Hector based on the post. We've all been there and that part is completely understandable.
> 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.
The abrasiveness though is the reason people react that way. Not everyone is going to respond with "hey that was abrasive, that's not how we do things, here is a better way to phrase it". The majority will simply shut down or start forming cliques in the background. I can't completely blame them either. Here is Hector threatening to launch a shaming social media campaign on kernel devs:
"If shaming on social media does not work, then tell me what does, because I'm out of ideas."
That's not ok. Even if he feels he is right and they are wrong. People will create cliques and talk behind your back if you act that way. People will look on Rust community after this and say "Remember that time when _they_ where threatening kernel devs with social media drama?". It's not right but that's the perception that will last.
Marcan links to an email by Ted Tso'o (https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed...) that is interesting to read. Although it starts on a polarising note ("thin blue line"), it does a good job of explaining the difficulties that Linux maintainers face and why they make the choices they do.
It makes sense to be extremely adversarial about accepting code because they're on the hook for maintaining it after that. They have maximum leverage at review time, and 0 leverage after. It also makes sense to relax that attitude for someone in the old boys' network because you know they'll help maintain it in the future. So far so good. A really good look into his perspective.
And then he can't help himself. After being so reasonable, he throws shade on Rust. Shade that is just unfortunately, just false?
- "an upstream language
community which refuses to make any kind of backwards compatibility
guarantees" -> Rust has a stability guarantee since 1.0 in 2015. Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug.
- "which is actively hostile to a second Rust compiler
implementation" - except that isn't true? Here's the maintainer on the gccrs project (a second Rust compiler implementation), posting on the official Rust Blog -> "The amount of help we have received from Rust folks is great, and we think gccrs can be an interesting project for a wide range of users." (https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-c...)
This is par for the course I guess, and what exhausts folks like marcan. I wouldn't want to work with someone like Ted Tso'o, who clearly has a penchant for flame wars and isn't interested in being truthful.
I understand the challenges he's facing. But I think he put a bit too much of himself into the project. So everything is personal. When someone asks for functionality "why no thund3rb01t OmG" you should be able to say without taking it personally "driver will take time or a volunteer".
> 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.
Honestly I think working like 10+ hour days and not doing other things that are less stressful and enjoyable (people being their biggest stressor in this regard).
They likely have PTSD at this point.
Whatever you need Marcan. I hope you find it. I'm rooting for your health and happiness.
It seems like there's a balancing act between the benefits of writing drivers in Rust (easier, more maintainable), and getting those drivers mainlined (apparently soul-destroying, morale killing), I wonder if the Asahi team is considering simply abandoning linux in favor of something more rust friendly (redox being an obvious candidate, but maybe one of the BSDs?). Given the narrow set of hardware they're aiming to support and that they're writing many of their own drivers _anyway_ (and so are not relying as much on the large # of existing linux drivers), that approach might be more viable. I'd be surprised if the Asahi GPU work wasn't the largest problem by far that their team faces, and as such it would make sense to choose a kernel that lowers the difficulty on that aspect to the greatest degree possible.
> 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”
This is still my position on Asahi Linux: that it is not something that I would use as a daily driver nor recommend to others for use as a daily driver.
> “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).
These would be dealbreakers for me, too. To be clear, I am not saying that it is anyone's job to fix these issues for me. And this isn't meant as an attack on the Asahi Linux team - I think it's incredible what they have been able to do.
But those comments, without any larger context to demonstrate harassment or anything like that, just don't seem too bad to me. The language could be softened a bit, sure, but the criticisms themselves resonate with me and would be valid reasons to not use Asahi Linux IMO.
God bless. Asahi introduced me to fedora/gnome, it feels rock solid on my m1 MacBook, and it's now my daily driver on a 2014 Intel Mac mini
Wishing I had donated before, I'll sign up for opencollective now. I can only imagine the anticlimactic nature of releasing the emulation stack for gaming [0] and not seeing any increase in interest financially. One wonders what funding might have made it more worthwhile than simply passing the hat.
Open source can be brutal, especially with larger and well established projects.
I contribute to several projects as a well recognized person in my field, not at their scale, but everything they say rings true.
Established developers often push back extremely hard on anything new, until and unless it aligns with their current goals. I’ve had maintainers shut me down without hearing out the merits, only to come back a year later when whatever company they work for suddenly sees it as important.
Project leads who will shift goalposts to avoid confronting the clear hostility their deputies show.
I’ve had OSS users call me personal number, or harass me over email for not having their pet interest prioritized over everything else. Often that’s because I’m blocked by the maintainers.
Open source can be extremely brutal and it’s a battle of stamina and politics as much as it’s one of technical merit.
> primarily due to the very large fraction of entitled users
I think anyone working in serious open source projects just need to learn to ignore those users. I definitely would have the attitude of "I'm perfectly fine if no one uses my product" and have a lot of fun banning entitled users left and right.
I read this entire post because the man deserves not only to have his say but also to have his say listened to.
That said, I detect a lot of one sided thinking in his post. He took on an incredibly difficult challenge, faced huge opposition, made incredible technical accomplishments and he feels entitled to a standing ovation. When what he receives is criticism, entitlement and obstructionism he takes it personally. If he did all of this work hoping to get accolades, fame, clout, influence then he did it for the wrong reason. There is a mismatch between his expectations and the reality of the world.
In the best of worlds, we do the right thing because it is the right thing, not because we hope for a pat on the back once it is done. In dharmic religions (e.g. Buddhism), one of the principle mental states one is to aim for is detachment from the outcomes of our actions. Suffering is attachment and Martin is clearly suffering. The other thing in Buddhism is recognizing the suffering in others, and I see a distinct lack of that recognition in Martin's post here. He acknowledges his own abrasiveness but not once does he show compassion for the maintainers who have suffered everything he has suffered, perhaps even from actions Martin himself has done.
Martin has several outcomes he wants, mostly his changes (including the inclusion of Rust) being welcomed in the Linux kernel. He is attached to those outcomes and therefore takes it personally when those outcomes are not achieved. Taking a step away from this attachment is a very good step. IMO, his desire to push for these outcomes has been a significant contribution to the toxicity.
This is unfortunate, but before pointing fingers, it's worth putting things into perspective.
The linked "thin blue line" message[1] also says this:
> One of the things which gets very frustrating from the maintainer's perspective is development teams that are only interested in their pet feature, and we know, through very bitter experience, that 95+% of the time, once the code is accepted, the engineers which contribute the code will disappear, never to be seen again. As a result, a very common dynamic is that maintainers will exercise the one and only power which they have --- which is to refuse to accept code until it is pretty much perfect --- since once we accept the code, we instantly lose all leverge, and the contributors will be disappear, and we will be left with the responsibility of cleanig up the mess. (And once there are users, we can't even rip out the code, since that would be a user-visible regression.)
Which seems very reasonable. Maintainers shouldn't be expected to support a feature indefinitely just because a 3rd party is interested in upstreaming it. In the case of Rust for Linux and the Asahi project specifically, I imagine this would entail a much larger effort than any other contribution. So just based on this alone, the bar for entry for Asahi-related features should be much higher.
Perhaps this is ultimately a failure of leadership as TFA claims, but it would be foolish to blame the Linux maintainers or its development process, and take sides either way. Maybe what Asahi is trying to accomplish just isn't a good fit for mainline Linux, and they would be better served by maintaining a hard fork, or developing their own kernel.
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).
This is _not_ ok in any form, what the actual hell?
Hector, I know you deleted your account here but in the off chance you browse by - thank you for all of your hard work and knowledge sharing on this over the years. Hope you find time to take a long well deserved 'mental health break' and destress.
Marcan brings up plenty of good points regarding contributing to kernel.org being stuck in the 1990s.
However, he's got no social skills nor does he have what it takes to man up and understand he won't get his way.
Additionally I doubt that he really is dealing with stalkers to the degree that he is implying; real people don't talk about their stalkers so much. When I was stalked and harassed I kept the details light and didn't provide much in the way of actual community details because I went to the FBI and local police to deal with it. And yes a few people not only got no contact orders, but lost jobs, families, and more over their exposure.
Marcan is extremely talented, but talent doesn't equal "I get to get my way." All the time. This idea that conflicts need to be resolved quickly and in the favor of a golden boy is a millennial/zoomer issue.
I'm not sure about why they are upset with the issue of upstreaming the changes into the kernal.
They want to upstream drivers for a device that the creator of clearly has no interest in allowing others to use outside of their walled garden. The knowledge around it is from a massive , albeit impressive, RE effort.
Who is going to support it? Where is the demand for it? It would be different if Apple were to provide patches and drivers for their own hardware, at least then you know there is a vested interest in supporting the hardware from the people who know it better than anyone else and have the means to continue supporting it.
I applaud Hector and everyone else that contributes to Asahi, its genuinely a cool project and the progress they have made is insanely impressive given the lack of any official documentation about the hardware they are working on, but its one of these things that will remain in the realm of a cool curiosity much like running Linux on a games console.
Marcan is a legend, it's a shame it ended like this. The communities around certain software technologies can act incredibly hostile and entitled towards developers, paradoxically even more so for free and open source projects. I've seen this many times happen in audio production and game emulation software.
But Marcan clearly has true hacker spirit, I'd wager we'll see him again in the future with an equally cool project. It's often best if the visionaries just spend their efforts to get the ball rolling and then let the project evolve on it's own as they move onto their next challenge.
One aspect of all of this which I haven't seen directly addressed[0] is the question of what might be going on with Torvalds and the Rust Foundation from a longer term, dare I say "political" standpoint. Torvalds seems to usually position himself as a kind of anti-political, code-is-code type, but then, perhaps there's more to him and to this story?
There's an awful lot of money and power associated with operating systems and programming languages (obviously), and the resulting "realpolitik" of situations like these seem to get swallowed up in these discussions.
It makes sense for technical people to think that the technical debate is what essentially matters, but it usually never actually is.
I've found the way Linux has approached Rust in the last couple of years to be a tad confusing. Always cutting a hard line, suddenly Torvalds' opinion is quite wishy washy. Oh, we'll try it, who knows, what's the worst that can happen, type thing? What induced this change, one wonders.
[0] Well-written blog posts on the subject are very welcome, please share if you know one!
Reading this I cannot help thinking about what Linus Torvalds said more than 20 years ago[1] in an interview.
When asked if he feared competition for Linux his answer was that few liked writing device drivers and as long as no one "young and hungry" came along that could write device drivers and liked it he'd be safe.
There you have him, Hector Martin, young[2] and hungry and loves writing drivers. No surprise he clashes with the old guard.
[1] I don't remember the date but it was still on analog TV, so definitely more than 20 years.
[2] At least a different generation from Linus and could easily be his son. Young enough for generational conflict at any rate.
First, maybe Linux just is bound to always be a C only project. Linus Torvalds infamously dislikes C++, its sorta odd he didn't shut down Rust for Linux in the first place. Redox is on its way...
Second, there are multiple types of compensation. I think the author was probably looking to be compensated in validation from others. Maybe if Linus Torvalds, replied to his email the author would be more inclined to continue.
However, I can't be mad at someone for deciding how they want to spend their time. You only have so many hours in the day.
Would be cool if Qualcomm hired Marcan and worked with an OEM to roll out a series of Arm Linux laptops. That's what we ultimately want.
Staying away from the emotional part of this blog post.
I was about to write a question to ask why, if these downstreams are forked, that it is such a big deal to be gatekeeping the upstream and I think I got my answer from this:
"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. "
Is it wrong for Linus to take the side of the kernel and not of the various distros? Serious question. I don't completely understand all of the background here.
"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 think we are dealing with a maintenance problem of downstream forks and trying to make their lives easier by convincing the kernel maintainers to accept the changes upstream.
Does Linux have a standards committee or some sort of design committee? I thought they had something to decide what goes in and what doesn't. If it doesn't then is it necessarily gatekeeping then? It seems like someone has to make the hard technical choices whether something becomes part of Linux or not and that is what Linus is doing.
I am trying to understand the real issue here. It seems like the difficulty in upstreaming changes to help the downstream folks is the issue not necessarily that the downstream folks are blocked.
> 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.
That person is someone called `Sima` and their posts on Mastodon are pure gas lighting. These are the worst abusers.
>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?”
This is awful framing. It isn't entitled to ask when something is happenint or to say what makes something unsuitable for you. Marcan seems to take every single social media comment about Asahi Linux as a direct personal attack. No wonder he is burnt out, anyone with such a habit would be...
I think if I was indicted by Linus and told I'm a problem over spreading awareness about a position on social media, I too would burn out pretty quickly. That's how you crush motivation. There's a deeper issue in open-source culture where harshness and gatekeeping drive away passionate contributors.
Two HUGE roadblocks were self-inflicted: adopting a hardware platform that doesn't care about external development (Apple silicon) and a programming language that has almost zero support in the Linux kernel (being the first ever to try to achieve multilanguage Linux kernel development).
The odds were set against the Asahi Linux project from the beginning.
I have no dog in the Rust-for-Linux fight, but it seems fairly obvious that is the major reason for the burnout here.
The financial situation sucks. I just threw a small donation their way but funding a project of this scale just from end users is rarely a viable long-term solution...feel like they need to find some high level corporate sponsors.
My best to Hector, what he managed to pull off with the other Asahi developers is remarkable.
Drama needs to be worked against, not expanded upon.
A lot of what I’m reading seems to make me feel that drama was… not avoided by this person, putting it charitably.
And I'm someone who I believe still sponsors them! Asahi Linux is an awesome, and dare I say necessary, project.
There is value in learning how to relinquish a constant "defensive posture" mentally. (I have struggled with, and am still working through this, personally, btw.) Heading a project like this surely challenges everyone's stoicism, though.
I don't think it's the first time, nor the last, we'll see maintainers and otherwise really great people being turned off from FOSS because of the massive weight that entitled outsiders and toxic "collaborators" seem to add.
So on that, is there any guides for FOSS maintainers out there about how to deal with the emotional toll of FOSS, with a focus on self-care, how to say "No", generally just how to deal with the people/human part of FOSS, without focusing on the technical details?
We have a ton of guides from companies and individuals how to make the technical, infrastructure, product, software parts work, but I don't remember ever seeing a guide how to deal with emotions one might feel when doing this sort of work.
I think I'm lucky that it's relatively easy for me to tell people to fuck off when I find them not contributing or being toxic, but judging by the amount of people who feel a real emotional toll, border-lining to the feelings of burnout while working on their dream projects, this doesn't seem to come as easily to everyone, so having a guide/manual about this would be amazing.
If Marcan (Hector Martin) is serious about quitting Linux development, he will stop contributing to the project using his Asahi Lina persona as well. Until then this is just empty posturing trying to elicit a reaction from the community.
"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)."
Few maintainers care about the platform in question (to whom it's more a curiosity like maybe 68k), and don't have the hardware to test any submitted patches. It's painful to have to accept code that you can't test (though it may be common in certain parts of the kernel). It's painful to see a bunch of changes for just one random feature on a random platform. It's unclear how the code will affect other platforms, etc.
Now throw in some controversial stuff. The vendor of the platform is Apple and some patches are written in Rust... oh em gee!
One thing that I notice often - people just do not take 5 minutes to appreciate someone or send 5 dollars to a project that they use daily etc. Not just in the software world, but life in general. Someone I know works full time, takes care of her two kids, takes care of her husband. Kids are almost teens now, but she gets zero support from them or her husband. Or even an occasional thanks. I see this everywhere, this is just one example.
Are we so busy or egoistic or ignorant that we can't stop and say thanks? What is even more worse is the entitlement. People who wouldn't lift a finger to help anyone (even their own families) are usually the loudest and the most entitled ones.
I don't know if this is the case around the world (probably is?) and I don't know what the solution is. It just sucks
I'm sad to see this happen. I bought an M2 Air a year ago and I've been running Asahi on it since the day I got it. It hasn't been without hitches, but that was something I signed up for.
I'm incredibly grateful for all the work Hector and the others have done on this project. The Air is my dream hardware (I'm a sucker for sleek fanless laptops) and getting to run Linux on it is quite amazing.
With all due respect to the effort.. Projects built around unsupported ways to use someone else's products, aren't they doomed from the very start? This race that you can't win isn't it a recipe for imminent burnout? I don't even mean that Apple has no interest in this project in the best case, but why Linux maintainers would want to accept changes that are necessary to support such a marginal use case?
First of all, yay Asahi — one of the great modern hacking / hacker stories in my opinion.
Second, what’s the drama? I read the blog, and I’m guessing that on top of being burned out, which sucks, Marcan didn’t like a kernel developer using the phrase “we are the thin blue line” implies he’s politically liberal, in the US sense. He then says he may have been toxic on Mastodon, which might have got him secretly canceled?
All that said, I found his assessment of downstream v. upstream economics (if you can’t successfully upstream you’re doomed to rebase off a massive patch list) pretty interesting. I think the way it is now is the only way that’s good for users — if downstream forks could somehow maintain viability longer term, we would be splitting, e.g. security budgets, performance budgets, etc. I get that it sucks for a group working to upstream, and I am in no way shocked to hear personal politics plays some role in success upstreaming — open source is largely a personal / social capital economy - I guess all that said, hopefully the new Asahi maintainers can work well across what seems like ideology bounds. Maybe?
Well written. I think the accusations of drama-hunting are unfounded. What else are you supposed to do in the face of persistent "non-technical nonsense"? Linus doesn't seem to care.
Definitely a shame. I wonder if it would be in Apple's interests to actively support Linux on Mac. It would make Macs more attractive as developer machines, and I don't see how it would disadvantage them.
The Rust criticism is valid - the hidden "breaking changes" have been a hallmark of rust releases and anyone maintaining a serious codebase in rust needs to really be on top of testing and validating if they want to stay current - moreso than any other language in the same stable as rust.
You can't however claim the right and reason to refuse PRs and code changes under the moniker of maintenance while simultaneously claiming that the rust community is "actively hostile to a second rust compiler implementation" - you can't have it both ways.
The entire narrative is very indicative of the state of open source unfortunately - incredibly adept programmers getting chewed up by the externalities of maintaining code (and by extension an application). Sometimes it's unappreciative users asking for handouts and sometimes it's other developers (or an organization's development resources) causing contention for a project's trajectory.
I think the entirety of it can be summed up as: forking is there for a reason.
Perhaps it is no longer realistic to push such a huge changeset into linux anymore. Could this be solved with some hypervisor layer? That is, a hypervisor doing most of the work (in rust) and a small support layer upstreamed into the kernel? Of course, no actual virtualization is even necessary. Just some kind of ABI to the kernel running underneath.
His two major complaints are demanding consumers and the rejection of upstreaming his rust driver patches. He has some legitimate complaints since users depend on kernel features like Mesa Integration and Docker support for GPUs, which are critical now that people are training & doing inference .
I still think the best outcome is to fork and recruit some lieutenants for community management. To me the community is losing a lot with his departure. His complaints are legitimate and hopefully linux kernel team can better accommodate his patches. many distros and corporations deliver tremendous value from their forks and it's a better solution than quitting.
In an effort like Linux it's difficult for everyone to have their way - there are many "ways" but only one kernel.
I have had to do maintenance on a distributed filesystem driver at one point. This was outside the kernel. I can see why no kernel maintainer would have wanted to look after it even if it was open sourced because the file server was a mixture of C++ and an interpreted language and working out if you'd broken the driver somehow was a miserable job. You would need obscure expertise to understand it all.
Anyone with a good idea can still fork Linux. If their idea is so great it may end up that their branch gets adopted - if they bother to maintain it.
Supporting and developing Rust is a nice to have, but too often its proponent try to force stuff it deeply inside important stacks that are using other languages like for Linux, or what is going on with major things in Python also.
Here we can see the case, that is almost a blackmail that the Linux community is not nice and will die if they don't make Rust support core and mandatory.
My point is that, if you like Rust and Rust is so nice, just go all-in, do your own kernel, do your own stuffs, and we will see the result in the end. But don't ruin existing good stuffs that were working well on their own.
I found it interesting, because what the writer calls "entitled users" I would call "honest feedback". The features they need may not be what you need. Sure, they are "entitled" in that they are hoping someone else will just hand them what they want, but that's just a human thing.
I'm sorry that it burned him out. But I think it is intrinsic to putting anything in the public sphere that it won't match everyone's hopes/desires/needs, that you will get such feedback, and that you have to find a way to be OK with that. (Or step back from such roles, as the author did.)
As a 20-year Mac enthusiast who knew a thing or two about Hackintoshing, Marcan got me excited about Linux. The idea that someone could just say, “we can solve this difficult problem and make it work, with little external help”? That is the core of FOSS right there, and he helped so much work happen, so quickly.
Loved following his various social feeds. I was sad when he stepped away from the fediverse. I hope he comes back as just a regular hacker without this massive weight on his back.
Modern Linux kernel is a corporate project which is open source.
It seems that it's impossible even for very talented folks to push such work load without corporate backing both without monetary compensation and other resources like non-public documentation. It is very impressive that Asahi team has achieved, but the more hardware advances, the less realistic is to support it on enthusiasm alone.
Damn shame, both for the burnout and for the project. I was talking to the team which laptops next to get and kind of everyone wanted something like Arm with battery and performance and there are only MBPs (except damn notch) out there. Except no one wants MacOS. And then there's Asahi. I said it might come down to exactly this, what's happening now.
> My personal Patreon will be paused, and those who supported me personally are encouraged to transfer their support
That seems silly; just assume people know about the change in circumstances and are trying to give you money for whatever you are doing at the moment, or in gratitude for what you've done before. The person exists, why pause the personal support?
Thank you for your efforts. Unfortunately people are people and the loudest are usually the complainers. I wish we, your supporters, were able to muster as loud of applause when the complaints come in, but we are too busy enjoying your work. Thank you again.
Sidenote: thank you also to all those project leads that put themselves out there. Not easy being the $h1t magnet.
Don' let the door hit you on the way out i guess. I mean it sounds mean but the scene can do with less toxic types like this, who try to bully people who know better, in order to get their way. Even worse in this case since he actually tried to create a social media shit-storm against those he disagreed with.
He even has defenders calling for yet more CoCs in order to better "deal with" people who "get in the way." It doesn't get much more toxic than that.
> 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).
> "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"
I read the post and I am thankful that these people exist, most of my life is made possible through the selfless work of wonderful open source developers like this person.
Sometimes I wish I was so passionate, whereas my philosophy in life towards strangers is a much simpler “fuck you, or pay me”. It allows me to sleep fairly well at night.
I have a few toy projects on GitHub, a couple of which gained a tiny bit of popularity, and I simply ignored every new feature request that I didn’t need, and especially those large PRs “here, I refactored your code to make it functional and it’s so much better now”. I simply said, with no regret: “I won’t merge this, feel free to fork the project, if it’s better I might even switch myself to your project!”. Some got mad, but I truly and genuinely couldn’t care less.
Was any of the Corellium port [1] usable for mainline Linux? In theory, they have a commercial interest in Linux for Apple Silicon, plus emulation tools.
> 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
#2 is the cause of #1.
Running commercial games for free has always been the killer application for jailbreaks/custom firmware for game systems. And game system emulators, for that matter.
It's sort of a perfect storm of gaming enthusiasts (particularly those with more free time than money) who want to run commercial games for free vs. companies like Nintendo who have an affinity for (overly) vigorous copyright and trademark enforcement, with jailbreak/custom firmware and emulator developers caught in the crossfire.
Thank you Macan! Asahi is a heroic effort, but way larger than a hobby. To be sustainable, it would require full buy-in from Linus and kernel maintainers indeed.
Hope you enjoy well deserved better hobbies and family time.
This the functional equivalent of a self-pitying LiveJournal post by a moody teen that's been called out by his friends for being a bit of a dick.
Marcan wants to use social brigading to get his way, Marcan wants the entire Linux kernel dev flow to bend for him, and, when none of his poorly presented demands get him what he wants, he is - of course - the victim here.
Asahi is neat, but it clearly isn't a working daily driver yet, and it's not abusive to make feature requests and bug reports. Discussions around Rust in the kernel are not, and can never be, an 'injustice'. In Marcan's world, everything other than vehement agreement and immediate compliance is abusive, hostile, toxic, etc. But of course, the only toxic person here is the one threatening to wield the mob to get his way.
Honestly, I'd query whether the benefit is worth the cost. I'll take average code from well-adjusted anons over clever code from bullying, hyper-online micro-influencers any day of the week.
What a shame. Seems like such a bright and articulate person.
Working/contributing in FOSS is already slave labor in itself (literally, billion dollar companies depend on FOSS and many do not contribute back to the ecosystem they depend on). Then the abuse from other FOSS developers and community is just cruel.
Hope the guy is able to recover mentally and physically.
It's awful that someone who is doing this kind of work as a volunteer experiences harassment for not making proprietary hardware work with open-source quickly enough.
"... 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)."
Hmmm. Seems to me they took on a little too much technical risk at the start of an already complex project, to wit, buying into Rust on the kernel side.
Rust in the linux kernel was always going to be a long game. You don't want to have that be a blocker when you really want is to make larger kernel changes.
I'm really sorry about this and I've seen your magnificent work bring so much joy to people. The harassers and abusers should be named and shamed so we can strengthen the resilience of the open source community. Let's see how they react when they get a taste of their own medicine.
This was a heartbreaking and terrible read. I've been feeling a bit of disillusionment about linux quite a bit lately, mostly due to bad/weird decisions being made at the distribution level. Reading this extends that disillusionment down to the kernel level.
The problems cited are portrayed as sociological problems, but I really wish people could recognize that all of them can be mitigated, either substantially or entirely, with a single purely-technical solution: microkernels.
* Almost nobody needs to upstream code to the kernel
* Trusted codebase size becomes negligibly small
* Maintenance burden for drivers, subsystems, etc., falls on the users of the subsystems affected, and not the entire community
* Broad language compatibility by service interface instead of ABI compatibility. The need for a singular compiler is reduced in scope down to the size of the subsystem instead of the entire ecosystem.
The biggest problem that can't be solved purely technically is the entitled user problem, but even that is partially solved. This is because the barrier to contribution is substantially lower:
* I can write code in Rust, but I don't know C.
* I can easily write simple drivers for some hardware features like battery managers and fan controllers and temperature sensors, but I don't know anything about kernels.
* I have a lower, but non-zero understanding of security, and would not feel comfortable writing code that runs on ring 0, but wouldn't feel inhibited writing code that benefits from process isolation.
Those attributes about myself inherently mean that for a microkernel OS, I can be a contributor, but for Linux, the best I can be is an entitled user.
Do the demigods of the Linux kernel - Linus and the core maintainers - personally want the kind of code Asahi is developing to be merged into the kernel? The author writes as if part of his drive was that Linus himself showed enthusiasm for getting Linux on Apple Silicon.
If there is interest in the work Asahi has done, then the Linux team needs to describe what they see as the gap between today's code quality and support model and what they want to see before upstreaming.
It sounds like the Linux team has been wishy-washy and needs to draw a line in the sand on their needs rather than handwaving about being part of the "community".
It would be fair to say "we don't like your attitude or trust you to work with us kindly over the years and don't want to deal with you", if that's the case. Just don't dance around it.
from just reading the post sounds like a shit situation for him and there is blame on the linux kernel maintainers for not handling it well. Especially if the claim about them going behind his back and shit talking him is true.
What i will say, Is that i get the impression that the he is quite sensitive and takes things too personally which is a death wish online. People are savage online and if you don't have thick skin then they will destroy you. Not justifying it but it is what it is
Either way hope all goes well for him. Sad to see this happen i bought a m2 mac because of linux support :(
I was contributing a (very small) amount of money each month until 2024, when it seemed like Marcan had stopped working on the project.
It was hard to decide to stop the financial support. On the one had I want maintainers to be able to take breaks without worrying about their livelihood. On the other hand, it was very difficult to tell what was going on and whether Marcan would ever get back to working on the project.
It's a shame to see but inevitable when trying to get open software working on such a proprietary platform with so many hardware cut corners and incomplete/non-standard implementations. Just an insane amount of work of the most frustrating kind. What they did manage to do was incredible... but Apple is Apple.
It seems at the heart of the issue is the vision for the future of Linux kernel.
One group believes it is Rust (progressives), one group doesn't believe that and wants to continue with C (conservatives).
If they cannot find a way to live at peace with each other, I think the only solution is for the Rust folks to start building the kernel in Rust and not try to "convert" the existing kernel to Rust piece by piece.
Why they cannot live in peace seems to be: a way that C kernel folks would not need to deal with Rust code.
At the core, the story is not that different from introducing new languages to a project.
You are introducing a new tax on everyone to pay for the new goodies you like, and those who are going to be taxed and don't like the new goodies are resisting.
It’s absurd that the C/C++ community is so hard-headed about Rust. Is the Linux kernel in fifty years still going to be written in the same language it is now?
Unfortunately it is not the first time a good developer leaves the project for a famous "Linu(s)x shitshow", and it will not be the latest...
I don't believe in the Linux project since a few years now, especially as "the bearded ones" are not interested in moving the project to a certain future, but only jerking on their old own code.
Good luck for the futur Hector, and thanks for what you managed to do until now with your team.
> I ended up burning out, primarily due to the very large fraction of entitled users.
I stopped reading after this sentence. The God complex is simply too much for me to digest. TL;DR: "I am a programming God; they are newbie peons who refused to bow at my altar of greatness." On other posts about this person, I read multiple comments from people that could be summarised as: "This person is an (amazeballs) amazing programmer, but also a total drama queen." I say, with respect, "You will be missed. Thank you for your contributions." <sigh of relief>
The Rust situation was handled badly. Two languages (one of which has panics and all sorts of version issues) in one kernel are clearly not viable. Linus should have put his foot down and mandated C instead of stringing people along.
That of course was difficult in the corporate environment of 2014-2024. Perhaps he was forced to do it.
In many areas, sanity has returned, so perhaps we can get clearer messaging again in the future.
Trying to push Rust code into Linux and after a year calling it a "failure of leadership" when people are reluctant don't welcome your code with open arms is not very professional. It has taken other projects decades of out-of-tree maintenance until their code finally got in (RTLinux).
The correct way would have been to maintain the Rust code out-of-tree, for as long as it would take, which would also somewhat prove that you are ready to maintain that code over a longer time period.
Sad that this led to him stepping down, but maybe others in the Asahi Linux circle are ready to keep maintaining the code out-of-tree until everyone is ready for it
Resigning as Asahi Linux project lead
(marcan.st)1115 points by Shank 13 February 2025 | 991 comments
Comments
This sounds so rough. I can't imagine pouring your heart out into this labor of love and continue to have to face something like this. Back in the early days of Quora, when it used to be good, there used to be a be nice be respectful policy (they might still have it), I wonder if something like that would be helpful for open source community engagement.
Regardless, major props to Marcan for doing the great work that he did, our community is lucky to have people like him!
> 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.
The abrasiveness though is the reason people react that way. Not everyone is going to respond with "hey that was abrasive, that's not how we do things, here is a better way to phrase it". The majority will simply shut down or start forming cliques in the background. I can't completely blame them either. Here is Hector threatening to launch a shaming social media campaign on kernel devs:
> https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
"If shaming on social media does not work, then tell me what does, because I'm out of ideas."
That's not ok. Even if he feels he is right and they are wrong. People will create cliques and talk behind your back if you act that way. People will look on Rust community after this and say "Remember that time when _they_ where threatening kernel devs with social media drama?". It's not right but that's the perception that will last.
It makes sense to be extremely adversarial about accepting code because they're on the hook for maintaining it after that. They have maximum leverage at review time, and 0 leverage after. It also makes sense to relax that attitude for someone in the old boys' network because you know they'll help maintain it in the future. So far so good. A really good look into his perspective.
And then he can't help himself. After being so reasonable, he throws shade on Rust. Shade that is just unfortunately, just false?
- "an upstream language community which refuses to make any kind of backwards compatibility guarantees" -> Rust has a stability guarantee since 1.0 in 2015. Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug.
- "which is actively hostile to a second Rust compiler implementation" - except that isn't true? Here's the maintainer on the gccrs project (a second Rust compiler implementation), posting on the official Rust Blog -> "The amount of help we have received from Rust folks is great, and we think gccrs can be an interesting project for a wide range of users." (https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-c...)
This is par for the course I guess, and what exhausts folks like marcan. I wouldn't want to work with someone like Ted Tso'o, who clearly has a penchant for flame wars and isn't interested in being truthful.
> 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.
Honestly I think working like 10+ hour days and not doing other things that are less stressful and enjoyable (people being their biggest stressor in this regard).
They likely have PTSD at this point.
Whatever you need Marcan. I hope you find it. I'm rooting for your health and happiness.
It seems like there's a balancing act between the benefits of writing drivers in Rust (easier, more maintainable), and getting those drivers mainlined (apparently soul-destroying, morale killing), I wonder if the Asahi team is considering simply abandoning linux in favor of something more rust friendly (redox being an obvious candidate, but maybe one of the BSDs?). Given the narrow set of hardware they're aiming to support and that they're writing many of their own drivers _anyway_ (and so are not relying as much on the large # of existing linux drivers), that approach might be more viable. I'd be surprised if the Asahi GPU work wasn't the largest problem by far that their team faces, and as such it would make sense to choose a kernel that lowers the difficulty on that aspect to the greatest degree possible.
This is still my position on Asahi Linux: that it is not something that I would use as a daily driver nor recommend to others for use as a daily driver.
> “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).
These would be dealbreakers for me, too. To be clear, I am not saying that it is anyone's job to fix these issues for me. And this isn't meant as an attack on the Asahi Linux team - I think it's incredible what they have been able to do.
But those comments, without any larger context to demonstrate harassment or anything like that, just don't seem too bad to me. The language could be softened a bit, sure, but the criticisms themselves resonate with me and would be valid reasons to not use Asahi Linux IMO.
Wishing I had donated before, I'll sign up for opencollective now. I can only imagine the anticlimactic nature of releasing the emulation stack for gaming [0] and not seeing any increase in interest financially. One wonders what funding might have made it more worthwhile than simply passing the hat.
[0] https://asahilinux.org/2024/10/aaa-gaming-on-asahi-linux/
Open source can be brutal, especially with larger and well established projects.
I contribute to several projects as a well recognized person in my field, not at their scale, but everything they say rings true.
Established developers often push back extremely hard on anything new, until and unless it aligns with their current goals. I’ve had maintainers shut me down without hearing out the merits, only to come back a year later when whatever company they work for suddenly sees it as important.
Project leads who will shift goalposts to avoid confronting the clear hostility their deputies show.
I’ve had OSS users call me personal number, or harass me over email for not having their pet interest prioritized over everything else. Often that’s because I’m blocked by the maintainers.
Open source can be extremely brutal and it’s a battle of stamina and politics as much as it’s one of technical merit.
I think anyone working in serious open source projects just need to learn to ignore those users. I definitely would have the attitude of "I'm perfectly fine if no one uses my product" and have a lot of fun banning entitled users left and right.
That said, I detect a lot of one sided thinking in his post. He took on an incredibly difficult challenge, faced huge opposition, made incredible technical accomplishments and he feels entitled to a standing ovation. When what he receives is criticism, entitlement and obstructionism he takes it personally. If he did all of this work hoping to get accolades, fame, clout, influence then he did it for the wrong reason. There is a mismatch between his expectations and the reality of the world.
In the best of worlds, we do the right thing because it is the right thing, not because we hope for a pat on the back once it is done. In dharmic religions (e.g. Buddhism), one of the principle mental states one is to aim for is detachment from the outcomes of our actions. Suffering is attachment and Martin is clearly suffering. The other thing in Buddhism is recognizing the suffering in others, and I see a distinct lack of that recognition in Martin's post here. He acknowledges his own abrasiveness but not once does he show compassion for the maintainers who have suffered everything he has suffered, perhaps even from actions Martin himself has done.
Martin has several outcomes he wants, mostly his changes (including the inclusion of Rust) being welcomed in the Linux kernel. He is attached to those outcomes and therefore takes it personally when those outcomes are not achieved. Taking a step away from this attachment is a very good step. IMO, his desire to push for these outcomes has been a significant contribution to the toxicity.
The linked "thin blue line" message[1] also says this:
> One of the things which gets very frustrating from the maintainer's perspective is development teams that are only interested in their pet feature, and we know, through very bitter experience, that 95+% of the time, once the code is accepted, the engineers which contribute the code will disappear, never to be seen again. As a result, a very common dynamic is that maintainers will exercise the one and only power which they have --- which is to refuse to accept code until it is pretty much perfect --- since once we accept the code, we instantly lose all leverge, and the contributors will be disappear, and we will be left with the responsibility of cleanig up the mess. (And once there are users, we can't even rip out the code, since that would be a user-visible regression.)
Which seems very reasonable. Maintainers shouldn't be expected to support a feature indefinitely just because a 3rd party is interested in upstreaming it. In the case of Rust for Linux and the Asahi project specifically, I imagine this would entail a much larger effort than any other contribution. So just based on this alone, the bar for entry for Asahi-related features should be much higher.
Perhaps this is ultimately a failure of leadership as TFA claims, but it would be foolish to blame the Linux maintainers or its development process, and take sides either way. Maybe what Asahi is trying to accomplish just isn't a good fit for mainline Linux, and they would be better served by maintaining a hard fork, or developing their own kernel.
[1]: https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed...
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).
This is _not_ ok in any form, what the actual hell?
Asahi Linux lead developer Hector Martin resigns from Linux kernel
https://news.ycombinator.com/item?id=42972062
New Apple Silicon Co-Maintainer Steps Up for the Linux Kernel
https://news.ycombinator.com/item?id=42990588
However, he's got no social skills nor does he have what it takes to man up and understand he won't get his way.
Additionally I doubt that he really is dealing with stalkers to the degree that he is implying; real people don't talk about their stalkers so much. When I was stalked and harassed I kept the details light and didn't provide much in the way of actual community details because I went to the FBI and local police to deal with it. And yes a few people not only got no contact orders, but lost jobs, families, and more over their exposure.
Marcan is extremely talented, but talent doesn't equal "I get to get my way." All the time. This idea that conflicts need to be resolved quickly and in the favor of a golden boy is a millennial/zoomer issue.
They want to upstream drivers for a device that the creator of clearly has no interest in allowing others to use outside of their walled garden. The knowledge around it is from a massive , albeit impressive, RE effort.
Who is going to support it? Where is the demand for it? It would be different if Apple were to provide patches and drivers for their own hardware, at least then you know there is a vested interest in supporting the hardware from the people who know it better than anyone else and have the means to continue supporting it.
I applaud Hector and everyone else that contributes to Asahi, its genuinely a cool project and the progress they have made is insanely impressive given the lack of any official documentation about the hardware they are working on, but its one of these things that will remain in the realm of a cool curiosity much like running Linux on a games console.
But Marcan clearly has true hacker spirit, I'd wager we'll see him again in the future with an equally cool project. It's often best if the visionaries just spend their efforts to get the ball rolling and then let the project evolve on it's own as they move onto their next challenge.
There's an awful lot of money and power associated with operating systems and programming languages (obviously), and the resulting "realpolitik" of situations like these seem to get swallowed up in these discussions.
It makes sense for technical people to think that the technical debate is what essentially matters, but it usually never actually is.
I've found the way Linux has approached Rust in the last couple of years to be a tad confusing. Always cutting a hard line, suddenly Torvalds' opinion is quite wishy washy. Oh, we'll try it, who knows, what's the worst that can happen, type thing? What induced this change, one wonders.
[0] Well-written blog posts on the subject are very welcome, please share if you know one!
When asked if he feared competition for Linux his answer was that few liked writing device drivers and as long as no one "young and hungry" came along that could write device drivers and liked it he'd be safe.
There you have him, Hector Martin, young[2] and hungry and loves writing drivers. No surprise he clashes with the old guard.
[1] I don't remember the date but it was still on analog TV, so definitely more than 20 years.
[2] At least a different generation from Linus and could easily be his son. Young enough for generational conflict at any rate.
First, maybe Linux just is bound to always be a C only project. Linus Torvalds infamously dislikes C++, its sorta odd he didn't shut down Rust for Linux in the first place. Redox is on its way...
Second, there are multiple types of compensation. I think the author was probably looking to be compensated in validation from others. Maybe if Linus Torvalds, replied to his email the author would be more inclined to continue.
However, I can't be mad at someone for deciding how they want to spend their time. You only have so many hours in the day.
Would be cool if Qualcomm hired Marcan and worked with an OEM to roll out a series of Arm Linux laptops. That's what we ultimately want.
I was about to write a question to ask why, if these downstreams are forked, that it is such a big deal to be gatekeeping the upstream and I think I got my answer from this:
"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. "
Is it wrong for Linus to take the side of the kernel and not of the various distros? Serious question. I don't completely understand all of the background here.
"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 think we are dealing with a maintenance problem of downstream forks and trying to make their lives easier by convincing the kernel maintainers to accept the changes upstream.
Does Linux have a standards committee or some sort of design committee? I thought they had something to decide what goes in and what doesn't. If it doesn't then is it necessarily gatekeeping then? It seems like someone has to make the hard technical choices whether something becomes part of Linux or not and that is what Linus is doing.
I am trying to understand the real issue here. It seems like the difficulty in upstreaming changes to help the downstream folks is the issue not necessarily that the downstream folks are blocked.
That person is someone called `Sima` and their posts on Mastodon are pure gas lighting. These are the worst abusers.
>And, of course, “When is M3/M4 support coming?”
This is awful framing. It isn't entitled to ask when something is happenint or to say what makes something unsuitable for you. Marcan seems to take every single social media comment about Asahi Linux as a direct personal attack. No wonder he is burnt out, anyone with such a habit would be...
The odds were set against the Asahi Linux project from the beginning.
The financial situation sucks. I just threw a small donation their way but funding a project of this scale just from end users is rarely a viable long-term solution...feel like they need to find some high level corporate sponsors.
My best to Hector, what he managed to pull off with the other Asahi developers is remarkable.
A lot of what I’m reading seems to make me feel that drama was… not avoided by this person, putting it charitably.
And I'm someone who I believe still sponsors them! Asahi Linux is an awesome, and dare I say necessary, project.
There is value in learning how to relinquish a constant "defensive posture" mentally. (I have struggled with, and am still working through this, personally, btw.) Heading a project like this surely challenges everyone's stoicism, though.
So on that, is there any guides for FOSS maintainers out there about how to deal with the emotional toll of FOSS, with a focus on self-care, how to say "No", generally just how to deal with the people/human part of FOSS, without focusing on the technical details?
We have a ton of guides from companies and individuals how to make the technical, infrastructure, product, software parts work, but I don't remember ever seeing a guide how to deal with emotions one might feel when doing this sort of work.
I think I'm lucky that it's relatively easy for me to tell people to fuck off when I find them not contributing or being toxic, but judging by the amount of people who feel a real emotional toll, border-lining to the feelings of burnout while working on their dream projects, this doesn't seem to come as easily to everyone, so having a guide/manual about this would be amazing.
Few maintainers care about the platform in question (to whom it's more a curiosity like maybe 68k), and don't have the hardware to test any submitted patches. It's painful to have to accept code that you can't test (though it may be common in certain parts of the kernel). It's painful to see a bunch of changes for just one random feature on a random platform. It's unclear how the code will affect other platforms, etc.
Now throw in some controversial stuff. The vendor of the platform is Apple and some patches are written in Rust... oh em gee!
Are we so busy or egoistic or ignorant that we can't stop and say thanks? What is even more worse is the entitlement. People who wouldn't lift a finger to help anyone (even their own families) are usually the loudest and the most entitled ones.
I don't know if this is the case around the world (probably is?) and I don't know what the solution is. It just sucks
I'm incredibly grateful for all the work Hector and the others have done on this project. The Air is my dream hardware (I'm a sucker for sleek fanless laptops) and getting to run Linux on it is quite amazing.
Second, what’s the drama? I read the blog, and I’m guessing that on top of being burned out, which sucks, Marcan didn’t like a kernel developer using the phrase “we are the thin blue line” implies he’s politically liberal, in the US sense. He then says he may have been toxic on Mastodon, which might have got him secretly canceled?
All that said, I found his assessment of downstream v. upstream economics (if you can’t successfully upstream you’re doomed to rebase off a massive patch list) pretty interesting. I think the way it is now is the only way that’s good for users — if downstream forks could somehow maintain viability longer term, we would be splitting, e.g. security budgets, performance budgets, etc. I get that it sucks for a group working to upstream, and I am in no way shocked to hear personal politics plays some role in success upstreaming — open source is largely a personal / social capital economy - I guess all that said, hopefully the new Asahi maintainers can work well across what seems like ideology bounds. Maybe?
Definitely a shame. I wonder if it would be in Apple's interests to actively support Linux on Mac. It would make Macs more attractive as developer machines, and I don't see how it would disadvantage them.
You can't however claim the right and reason to refuse PRs and code changes under the moniker of maintenance while simultaneously claiming that the rust community is "actively hostile to a second rust compiler implementation" - you can't have it both ways.
The entire narrative is very indicative of the state of open source unfortunately - incredibly adept programmers getting chewed up by the externalities of maintaining code (and by extension an application). Sometimes it's unappreciative users asking for handouts and sometimes it's other developers (or an organization's development resources) causing contention for a project's trajectory.
I think the entirety of it can be summed up as: forking is there for a reason.
I still think the best outcome is to fork and recruit some lieutenants for community management. To me the community is losing a lot with his departure. His complaints are legitimate and hopefully linux kernel team can better accommodate his patches. many distros and corporations deliver tremendous value from their forks and it's a better solution than quitting.
I have had to do maintenance on a distributed filesystem driver at one point. This was outside the kernel. I can see why no kernel maintainer would have wanted to look after it even if it was open sourced because the file server was a mixture of C++ and an interpreted language and working out if you'd broken the driver somehow was a miserable job. You would need obscure expertise to understand it all.
Anyone with a good idea can still fork Linux. If their idea is so great it may end up that their branch gets adopted - if they bother to maintain it.
Supporting and developing Rust is a nice to have, but too often its proponent try to force stuff it deeply inside important stacks that are using other languages like for Linux, or what is going on with major things in Python also.
Here we can see the case, that is almost a blackmail that the Linux community is not nice and will die if they don't make Rust support core and mandatory.
My point is that, if you like Rust and Rust is so nice, just go all-in, do your own kernel, do your own stuffs, and we will see the result in the end. But don't ruin existing good stuffs that were working well on their own.
I'm sorry that it burned him out. But I think it is intrinsic to putting anything in the public sphere that it won't match everyone's hopes/desires/needs, that you will get such feedback, and that you have to find a way to be OK with that. (Or step back from such roles, as the author did.)
People aren't going to change.
Loved following his various social feeds. I was sad when he stepped away from the fediverse. I hope he comes back as just a regular hacker without this massive weight on his back.
It seems that it's impossible even for very talented folks to push such work load without corporate backing both without monetary compensation and other resources like non-public documentation. It is very impressive that Asahi team has achieved, but the more hardware advances, the less realistic is to support it on enthusiasm alone.
Criticism hits incredibly hard. I'd watch a friend play for hundreds of people at a concert and he'd receive a standing ovation.
But he overheard a single disgruntled remark from someone which nullified the whole experience for him.
I know he was being overly sensitive about it, but I've heard similar stories from other people too.
That seems silly; just assume people know about the change in circumstances and are trying to give you money for whatever you are doing at the moment, or in gratitude for what you've done before. The person exists, why pause the personal support?
Sidenote: thank you also to all those project leads that put themselves out there. Not easy being the $h1t magnet.
<3
He even has defenders calling for yet more CoCs in order to better "deal with" people who "get in the way." It doesn't get much more toxic than that.
Well, they were proved right.
https://youtu.be/2HJxya0CWco
Sometimes I wish I was so passionate, whereas my philosophy in life towards strangers is a much simpler “fuck you, or pay me”. It allows me to sleep fairly well at night.
I have a few toy projects on GitHub, a couple of which gained a tiny bit of popularity, and I simply ignored every new feature request that I didn’t need, and especially those large PRs “here, I refactored your code to make it functional and it’s so much better now”. I simply said, with no regret: “I won’t merge this, feel free to fork the project, if it’s better I might even switch myself to your project!”. Some got mad, but I truly and genuinely couldn’t care less.
[1] https://www.corellium.com/blog/linux-m1
#2 is the cause of #1.
Running commercial games for free has always been the killer application for jailbreaks/custom firmware for game systems. And game system emulators, for that matter.
It's sort of a perfect storm of gaming enthusiasts (particularly those with more free time than money) who want to run commercial games for free vs. companies like Nintendo who have an affinity for (overly) vigorous copyright and trademark enforcement, with jailbreak/custom firmware and emulator developers caught in the crossfire.
Rinux
Marcan wants to use social brigading to get his way, Marcan wants the entire Linux kernel dev flow to bend for him, and, when none of his poorly presented demands get him what he wants, he is - of course - the victim here.
Asahi is neat, but it clearly isn't a working daily driver yet, and it's not abusive to make feature requests and bug reports. Discussions around Rust in the kernel are not, and can never be, an 'injustice'. In Marcan's world, everything other than vehement agreement and immediate compliance is abusive, hostile, toxic, etc. But of course, the only toxic person here is the one threatening to wield the mob to get his way.
Honestly, I'd query whether the benefit is worth the cost. I'll take average code from well-adjusted anons over clever code from bullying, hyper-online micro-influencers any day of the week.
marcan had indicated donations are down, and it's hard to support ones livelihood just from donations alone - especially when they are down.
https://lore.kernel.org/rust-for-linux/c5a49bcb-45cf-4295-80...
Working/contributing in FOSS is already slave labor in itself (literally, billion dollar companies depend on FOSS and many do not contribute back to the ecosystem they depend on). Then the abuse from other FOSS developers and community is just cruel.
Hope the guy is able to recover mentally and physically.
"... 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)."
Rust in the linux kernel was always going to be a long game. You don't want to have that be a blocker when you really want is to make larger kernel changes.
The problems cited are portrayed as sociological problems, but I really wish people could recognize that all of them can be mitigated, either substantially or entirely, with a single purely-technical solution: microkernels.
* Almost nobody needs to upstream code to the kernel
* Trusted codebase size becomes negligibly small
* Maintenance burden for drivers, subsystems, etc., falls on the users of the subsystems affected, and not the entire community
* Broad language compatibility by service interface instead of ABI compatibility. The need for a singular compiler is reduced in scope down to the size of the subsystem instead of the entire ecosystem.
The biggest problem that can't be solved purely technically is the entitled user problem, but even that is partially solved. This is because the barrier to contribution is substantially lower:
* I can write code in Rust, but I don't know C.
* I can easily write simple drivers for some hardware features like battery managers and fan controllers and temperature sensors, but I don't know anything about kernels.
* I have a lower, but non-zero understanding of security, and would not feel comfortable writing code that runs on ring 0, but wouldn't feel inhibited writing code that benefits from process isolation.
Those attributes about myself inherently mean that for a microkernel OS, I can be a contributor, but for Linux, the best I can be is an entitled user.
I hope someone else can take up the lead and that the clever people involved can continue that work
Do the demigods of the Linux kernel - Linus and the core maintainers - personally want the kind of code Asahi is developing to be merged into the kernel? The author writes as if part of his drive was that Linus himself showed enthusiasm for getting Linux on Apple Silicon.
If there is interest in the work Asahi has done, then the Linux team needs to describe what they see as the gap between today's code quality and support model and what they want to see before upstreaming.
It sounds like the Linux team has been wishy-washy and needs to draw a line in the sand on their needs rather than handwaving about being part of the "community".
It would be fair to say "we don't like your attitude or trust you to work with us kindly over the years and don't want to deal with you", if that's the case. Just don't dance around it.
What i will say, Is that i get the impression that the he is quite sensitive and takes things too personally which is a death wish online. People are savage online and if you don't have thick skin then they will destroy you. Not justifying it but it is what it is
Either way hope all goes well for him. Sad to see this happen i bought a m2 mac because of linux support :(
Why not fork Linux and call it something new, with the hardware support that is exclusively for M1/2/3/4 Mac’s?
It was hard to decide to stop the financial support. On the one had I want maintainers to be able to take breaks without worrying about their livelihood. On the other hand, it was very difficult to tell what was going on and whether Marcan would ever get back to working on the project.
One group believes it is Rust (progressives), one group doesn't believe that and wants to continue with C (conservatives).
If they cannot find a way to live at peace with each other, I think the only solution is for the Rust folks to start building the kernel in Rust and not try to "convert" the existing kernel to Rust piece by piece.
Why they cannot live in peace seems to be: a way that C kernel folks would not need to deal with Rust code.
At the core, the story is not that different from introducing new languages to a project.
You are introducing a new tax on everyone to pay for the new goodies you like, and those who are going to be taxed and don't like the new goodies are resisting.
I don't believe in the Linux project since a few years now, especially as "the bearded ones" are not interested in moving the project to a certain future, but only jerking on their old own code.
Good luck for the futur Hector, and thanks for what you managed to do until now with your team.
C is simple language
Rust is lojban.
Trying to convince people who like C to Rust was bad idea.
That of course was difficult in the corporate environment of 2014-2024. Perhaps he was forced to do it.
In many areas, sanity has returned, so perhaps we can get clearer messaging again in the future.
https://asahilinux.org/2025/02/passing-the-torch/
what if after Linux and Git, Linus came up with his own memory safe language suited for kernel development?
I hope the language industry will either make safer languages, or at least push hard to use static analysers.
The correct way would have been to maintain the Rust code out-of-tree, for as long as it would take, which would also somewhat prove that you are ready to maintain that code over a longer time period.
Sad that this led to him stepping down, but maybe others in the Asahi Linux circle are ready to keep maintaining the code out-of-tree until everyone is ready for it