Resigning as Asahi Linux project lead

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.

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.

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.

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.

Yeah, I agree. Maybe that's why I'm not doing great work -- I simply don't care about users. But again, you don't have to care about all users. You only need to care about the ones that have the same mindset. That's why I think working in smaller communities is better. Asahi Linux and Rust in Linux are the worst projects in that perspective because they both try to touch too many users.

But again, maybe they can hire someone like me, whose sole job is to block the very worst entitled users.