Drama
7 piecesIn this section
pages
Let's talk about DHH
Drama · 28 min · p. —
Let's talk about XLibre
Drama · 11 min · p. —
Fosstodon's drama reveals a much deeper Mastodon problem
Social Networks · 13 min · p. —
Asahi Lina releases all code as CC0 out of frustration
Kernels · 12 min · p. —Asahi Lina pauses Apple GPU development, gets doxxed
Asahi Lina, who was working on Apple GPU drivers, has decided to take a break from Asahi Linux development.
She did so through a Bluesky post; she said:
For personal reasons, I no longer feel safe working on Linux GPU drivers or the Linux graphics ecosystem. I've paused work on Apple GPU drivers indefinitely. I can't share any more information at this time, so please don't ask for more details. Thank you.
She then added:
If you think you know what happened or the context, you probably don't. Please don't make assumptions. Thank you. I'm safe physically, but I'll be taking some time off in general to focus on my health.
I do not know why she might've decided to step back, so there's no risk of me making assumptions or guesses.
For context, Asahi Lina is a VTuber who's been active for a couple of years, mostly doing lives regarding Asahi Linux development. Some of these were quite popular, reaching 50/60k views.
Now, there is something weird about this story.
This is the Phoronix article about Asahi Lina pausing development. It mentions that it "is a hit to the Linux graphics support for the Apple Silicon GPU especially with the DRM kernel driver not yet being finished and upstreamed as well as still targeting the older M1/M2 hardware generations", which is all fair and correct.
However, if we check the Phoronix forum about this article - where people can post comments - you'll notice that the thread has been changed to a redirect to the forum homepage, making it inaccessible.
Similarly, the comment thread in the Reddit post about the news, in the Asahi Linux subreddit, has also been locked down; no one can add comments now.
There even was a thread in the Linux subreddit, which has since been entirely removed "awaiting moderator's approval". A few hours ago the post was public, which makes me think it was not an auto-mod decision.
Finally, doing some extra background checks - which I will not mention here - I can say that there had been an additional thread created in the Asahi Linux community, which was also quickly removed.
What's up with that? Well, some more work gave me a likely answer to this question. However, it's an answer that puts me in a difficult spot: do I want to report back to you, now that I know that there's a reason for hiding some content? Or should I avoid the topic entirely, and pretend I did not see anything?
After some thinking, I have decided to only partially reveal some of the information I found. Firstly, let's introduce you to the internet cesspool that Kiwi Farm is.
Let me simply read the Wikipedia description, as it's perfect already:
Kiwi Farms [...] is a web forum that facilitates the harassment of online figures and communities. Their targets are often subject to organized group trolling and stalking, as well as doxing and real-life harassment. Kiwi Farms has been tied to the deaths of three people who were victims of harassment and died by suicide.
One of the three people whose suicide was tied to this forum is Near, a developer who was known for their work on the video emulator higan. I will not get into details about this specific story, but it's worth noting that Near had some common friends with Asahi Linux developers, and they are the ones who reported the suicide in the first place.
Kiwi Farms decided that they did not have enough proof of the death of Near, and began a harassment campaign against those Asahi Linux developers. They claimed they were lying and acting weirdly, and went on for months about this. When - finally - the death was confirmed, they claimed that Asahi Linux developers were "utterly incompetent" in providing information about it.
I mention this because this is what prompted Kiwi Farm users to start harassing Asahi Linux developers, even outside the scope of the death.
Most importantly - for this article, at least - is that they tried doxxing Asahi Lina, attempting to reveal her real identity. In all of the comment threads that I've mentioned - except for the Phoronix one, which I wasn't able to access - some users were sharing the name provided by Kiwi Farm, which - I think - is why the comments were locked and hidden away.
Now, I have reviewed the evidence that Kiwi Farm (and Reddit commenters) brought to the table, and it's circumstantial.
One thing they did is to pitch down the voice and compare speech patterns and accents. I have listened to the provided audio samples and I have not found the similarity to be that striking, but what do I know.
Other pieces of evidence include Asahi Lina and this other person having similar software configuration and hostname, and Asahi Lina showing a home folder with the name of the other person.
If I had to guess, I would say it's more likely than not that Kiwi Farm is right, but there's no hard proof and they've been wrong before anyway. Regardless, it seems like many platforms decided that it was enough to be considered doxxing, and restricted comments.
Now, in the past Asahi Lina had complained about attempts of Kiwi Farm to dox her. This quote comes from a document where Lina was clarifying her interaction with Luna, another VTuber (a long story in itself, but for another time).
This, finally, brings me to the reason I decided to still make this video in the first place: when I first encountered the doxing, I had no idea it came from a place like Kiwi Farm and sort of assumed it was correct. I was not the only one: I talked with other people who had read the thread, and they were also lacking this context.
Thus, I thought it was important to point out what's behind this type of information. They might even be correct for all we know, but they are brought up by people who specifically try to harass others and are even linked to some suicides. This has been, for me, a reminder of how important it is to be careful when handling these kinds of information publicly.
Why OBS and Bottles got in a fight with Fedora
Let's start with Bottles, and then ease to OBS.
Bottles is an application that allows you to run Windows software.
It relies on Wine, thus the name, and it makes it easy to create environments with specific Windows prefixes, settings, and dependencies. It lets you select various components to run those applications and comes with an integrated package Windows manager.
Many people bring the project forward, two of them - which you will often see in this story - are Hani Rana, a.k.a. theEvilSkeleton, and Mirko.
Now, Bottles does not have a set release schedule; on top of that, its dependencies change really fast, sometimes they are even custom-made, and a reliable environment is necessary to triage any issues that might arise.
Due to these reasons, packaging Bottles has been a somewhat complex and time-consuming task; and, due to not enough developer time around it, the Fedora RPM package of Bottles quickly fell out of date.
This led users to continue reporting already-addressed bugs to Bottles developers; and, on top of that, the packaging - according to Rana - was done incorrectly, introducing some bugs of its own. According to them, these bugs account for the majority of reports to Bottles developers.
This causes many issues for Bottles developers; not only do they have to deal with an increased bug-triaging workload, but their brand is damaged by these issues. As a direct example, The Linux Cast wanted to do a video about the application, but - due to an RPM packaging issue - he was unable to even start the application.
Oh, and this is not relevant to the story, but Rana points out that "In the example I provided above, we were really lucky for being aware of it, only because we were pinged".
And that's me! I pinged them! I'm in this story, too!
Oh, and let me quickly mention that if you prefer reading over listening, this entire video is also available as an article at thelibre.news; link in the video description. But if you prefer the video, keep watching.
Anyhow, as a result of all of these issues with packaging, the Bottles team asked Fedora to remove the RPM package, so that Bottles would only be shipped via flatpak. This would also improve security, as Wine can introduce some vulnerabilities that are addressed by Flatpak's sandboxing.
Though the Fedora people maintaining this project initially agreed to retire the package, they had a change of mind and decided to make sure it was not outdated for the next major release, and then to start looking for other maintainers for the package.
The Fedora team here is trying to say: "we know how to deal with irregular release schedules and changing dependencies; we saw interest in this package, so we'd like to keep working on it".
According to Fabio, from the Fedora side, the reason that the Bottles package was out of that is that one of Bottle's dependencies, orjson, could cause some segfaults, and they were trying to push a fix to the project. To quote him,
Again, Bottles developers might not care, but this is the reason why linux distributions exist. Because *we need to care* about these nitty-gritty low-level things to *make things work*, even if upstream developers don't (or cannot).
However, Bottle developers quickly asked Bottles not to be shipped as a Fedora package; understandably, they had lost trust that Fedora could keep up with the quickly changing requirements of the project and preferred the stability that Flatpaks was giving them.
Another point that they raised is that the Fedora maintainer for the package was sort of asking the developers to work with them, to some extent, to make sure the package was done properly. This was not something Bottles developers had the time or interest to do.
However, it seems like these requests did not stop Fedora from still intending to ship the Bottles package:
As a result, Mirko decided to retire the AUR package as well, and make sure to disable support links for unofficially distributed Bottles version, along with a warning and request to use the official one. On top of that, he says that "in the event of the removal of these controls or falsification of the product's identity, we will consider implementing restrictions on Bottles repositories for unofficial packages".
Personally, I felt like the Fedora person here missed the mark of the comment by replying with, and I quote,
The above sounds to me like it's one step short of moving to a restrictive none FOSS license. But, seeing that most of you are involved in open source in some way or another, I'm sure you are aware that doing so would close the doors for your audience.
That was the end of the story; Bottles developers did end up feeling highly frustrated and disappointed in their experience with Fedora packaging. However, there are a couple of other examples to bring up concerning this, but they require some additional context.
You're probably aware of flatpaks and their sandboxing benefits. I believe most people associate them with Flathub, where most flatpaks are distributed.
To get an application on Flathub you have to respect many guidelines, with the goal of "ensuring that the applications hosted on Flathub are safe to use and integrate well in the desktop experience.".
On top of that, some Flathub applications are verified, which means that the official developers (or authorized third party) claimed ownership of that specific flatpak. This tells you that you're downloading an application as it the developers meant it to be.
Though Fedora offers both Flathub and RPM packages, they also maintain their own flatpak remote, called - unsurprisingly - Fedora Flatpaks. Though it was meant to be used on Fedora, it can also be used on other distributions.
Now, would it shock you to discover that the announcement that I've just shown you comes directly from Hari Rana, the Bottles developer? The Open Source world is a small place, I guess.
Fedora Flatpaks has a few differences from Flathub. Firstly, they do not allow for any proprietary application to be shipped there; all flatpaks are fully open source.
Secondly, Flathub does not impose any kind of limitation on which source the flatpak re-uses to be shipped; this means that sometimes it's a deb package, sometimes an appimage, or a snap package, or an archive… Fedora Flatpaks all consistently re-use RPM packages.
According to Matt, the Fedora Project Leader, Flathub rules are quite lax and there's not much of a review, without checking that it was built with good practices. Fedora Flatpaks are instead built with their secure pipeline so that the user can have more trust that the package is going to be what it says it is. By the way, he says this in a 40 minute interview with Brodie Robertson, which I would suggest that you go check out.
As a result of all of this, according to Neal Gompa, a few distros are considering to use Fedora Flatpaks over Flathub.
However, this new system also has its own issues; namely, sometimes applications are shipped with more bugs compared to upstream.
Take Fractal as an example. Recently, a missing dependency issue went completely unnoticed; as a result, the Fedora Flatpak version lost the ability to see images.
As a developer points out,
The upstream Flatpak on Flathub was properly tested by the developers, and included all the components needed for correct functionality. During the period when this broken Flatpak was available, a number of people came to the Fractal matrix channel looking for help. The response given to them was almost universally "The Fedora Flatpak is broken, switch to Flathub and report a bug to Fedora".
This is not an isolated example. Fedora codec policies also mean that Kdenlive and media players will not be able to edit or play media, without a clear indication on why this is happening in the first place.
A similar situation was happening with OBS, the program that I'm using right now to record this video.
The Fedora Flatpak version of OBS is shipped with multiple issues: missing hardware acceleration, crashes on X11, VLC plugin not working out of the box, and they also included third-party plugins out-of-the-box.
On top of that, due to either technical or legal reasons, that package also lacked a Twitch/YouTube panel.
The above issues (and many others, such as this one) were regularly reported to OBS directly, which often had to close them and point out that the Fedora Flatpak version of their program was unofficial.
Over time, the usage Fedora Flatpaks raised some concerns. As an example, one developer - Jordan Petridis - decided to propose GNOME Software to always use the verified Flathub application over any non-verified one. In practice, this would mean that if an application is shipped to Flathub by the developers themselves, then Software would always install that one, instead of using other remotes such as Fedora Flatpaks. This change was eventually accepted and merged.
Another discussion that's still ongoing is the ability to set a default remote to download applications from. Right now you can only select it on a per-application basis, and there's no UI way to say: hey, I always want to download from Flathub instead of Fedora Flatpaks.
Oh, by the way, KDE Discover does have this functionality out of the box. This does not matter, but I just had to point this out. I'm a KDE developer if you didn't know.
Oh, and since I drifted off topic anyway, let me mention that this video is not sponsored by anyone, and yet it took time and money in equipment and contractors to make it. You can help support this channel via a donation on Patreon, Liberapay, Ko-Fi, and Paypal. Anyhow, back to the topic.
The discussion did not just happen over GNOME, but an issue was opened in Fedora too, asking to "Deprioritize or remove Fedora Flatpaks, and prioritize Flathub in GNOME Software", due to "quality issues when using Fedora's flatpak apps".
One of the people who disagreed with this proposal was Yakoov Selkowitz, also the maintainer of the OBS Fedora flatpak. According to him,
Many of these complaints would apply equally to the RPMs. I see this as no different than the Bottles fiasco from earlier. If software is FOSS then by definition we must have the right to redistribute it as we please, and upstreams cannot restrict that and remain FOSS. As such, I don't think we should need to entertain any such "requests" by upstream to not distribute "their" software in whichever form it may be. (Personally, I take a very dim view on such "requests".)
Which, by the way, is why I started this story by talking about Bottles: I believe you should now start to see a pattern emerging. Another interesting quote from his message is:
Based on what I've seen in discussions along these lines, what we have is a new era in which upstreams now believe that, thanks to Flathub etc., they don't need distributions anymore for their software to reach users, no longer see the value in distributions, and simply wish to cut out the "middleman" entirely. However, that does not give them the right or power to do so.
The discussion continued for pages and pages; just a couple of weeks ago, developer Michael Catanzaro said that, after a long discussion during a Workstation Working Group meeting, there was some level of agreement that "Fedora Flatpaks are generally the worst software source for users to install" and that "Good Flathub should be preferred over Fedora Flatpaks".
During all of this, four weeks ago, Joel Bethke from the OBS project created an issue to ask the Fedora OSB flatpak to be either removed, or to make it clear that it is a third-party package. Given the issues presented above, this can only seem like a reasonable request.
Discussion about this was happening in the other thread I mentioned, but it was more general. Around the same time, Georges Stavracas also raised the issue, saying that overriding the only official version of OBS with a Fedora-specific flatpak was unacceptable.
However, in all of this, all the issues of the OBS Fedora flatpak were being reported to OBS, not Fedora, which meant that Yaakov was completely unaware of the issues; thus, he just asked for those issues to be raised to Fedora, a request that Stavracas deemed absurd.
Eventually, when told that Fedora does have the right to redistribute OBS, Stavracas asked for a rebrand to make sure it was clear that the project was unofficial. Overall, this came out to be yet another bad experience with Fedora packaging.
As a final bit of context, during the conversation on whether to deprioritize Fedora Flatpaks in favor of Flathub, it was pointed out that OBS was currently relying on a EOL (End Of Life) version of Qt, the graphical toolkit to display the interface due to regressions with more modern Qt versions.
My understanding is that Fedora Flatpak maintainers decided that this was unacceptable, and decided to ship OBS with a more recent Qt version; one one hand, I can understand the choice to avoid End Of Life runtimes; on the other hand, you're intentionally shipping something that was deemed too broken to work by OBS developers.
As a result, Michael Catanzaro pointed out that allowing this to happen was terrible maintainership on OBS side, and showed that Fedora Flatpaks did have an added value compared to Flathub (since it used a more up-to-date Qt version).
The words "terrible maintainership", plus Bethke's request to remove the OBS flatpak getting completely ignored, prompted OBS to take stronger measures. They thus threatened Fedora with legal action if they kept using their branding for the unofficial flatpak, asking for a response within 7 business days.
It's worth noting that the very first like that this comment got was by Hari Rana, who had been previously disappointed by Fedora handling of upstream "remove us" requests.
Immediately Neal Gompa, the maintainer of the RPM package of OBS, reached out to the project to try to do damage control.
He created an issue to remove the obs-studio flatpak from the registry, immediately. This raised some discussion on how exactly to do that: if you just remove it, it will still stay on the users computers, and the only result is that their version will slowly go unmaintained until they delete and re-install the application. However, this discussion was finally taking place.
The option to rebrand the flatpak to avoid using any of OBS branding was also briefly considered, but ultimately none of this ended up being necessary.
As another way to immediately address the situation, Yakoov marked the OBS flatpak as End Of Life, within hours of OBS's request.
Nonetheless, a great amount of discussion was raised in the thread. Hari Rana pointed out that previous response on these issues were "shallow and completely inconsiderate of our point of view", and specifically mentioned Yakoov's "unwillingness to cooperate until the trademark enforcement occurred".
Bethke agreed with Hari, mentioning a "lack of willingness to work with upstream".
Yakoov decided to apologize for the lack of responses in the initial thread and offered to have a direct talk with Bethke. This seemed to have worked, as he then retracted his request to remove the flatpak immediately and said that he felt like now he could work with Fedora to tackle the issues presented in the Fedora OBS flatpak. He said, and I quote,
The discussion was positive and they are actively working to resolve those issues as well, which should hopefully only affect a small number of users.
Thus, I can only praise the good damage control of the Fedora project here, especially - I think - by Neal, but also Yakoov and others. Of course, it would've been better to avoid this conflict altogether.
This does not solve the broader issue by any means, though. The Fedora Flatpaks still exist, discussion about them is still active, and it's not yet clear when users should be directed towards them, and when they should use Flathub instead. Matt, the Fedora Project Leader, has stressed that Fedora cares a lot about good collaboration with upstream projects, and I can believe that these were just a few exceptions where the discussion got heated; however, I'm still not fully comfortable with a Fedora maintainer saying that upstream does not have the right to ask Fedora not to re-package their application. I don't like that.
Why the Asahi Linux lead developer resigned
Let's take a step back.
I decided to begin this story in 2019, during the Linux Security Summit.
Developers Alex Gaynor and Geoffrey Thomas decided to hold a talk called Writing Linux Kernel Modules in Safe Rust. In it, they made the case for adopting Rust in the Linux kernel. According to them, that would improve security, as two-thirds of vulnerabilities were due to memory-safety issues.
A few months later, in June 2020, Linus expressed interest in this option during an interview with The Register. He said, and I quote,
[The kernel team is looking at] having interfaces to do those, for example, in Rust... I'm convinced it's going to happen. It might not be Rust. But it is going to happen that we will have different models for writing these kinds of things, and C won't be the only one.
Then, in August 2020, the Linux Plumbers Conference was held (virtually). The event's most attended session was about open questions on accepting Rust upstream in the Linux kernel. It featured both Thomas and Gaynor, but also Rust language team co-leader Josh Triplett and many others.
Finally, the Rust for Linux - or, in short, r4l - project was announced on the Linux mailing list. The goal is not to rewrite the entire kernel in Rust, but to allow new code to be added over time.
A few months later, Apple announced that they would be switching away from Intel x86 processors. I was quite shocked at the announcement, and the reviews quickly showed that we were dealing with a very well-performing device with a great battery life. Of course, there was no chance to run Linux out of the box on these.
In November 2020, Linus was asked what he thought of this new kind of device in the Real World Technologies forum. He replied,
I'd absolutely love to have one, if it just ran Linux... [...] And I don't have the time to tinker with it, or the inclination to fight companies that don't want to help.
Someone else picked up the challenge – Hector Martin. He was part of the Team Twiizers (later called fail0verflow), which allowed him to run unofficial applications on the Nintendo Wii. In 2016 he also ported Linux to the PlayStation 4, just after being sued for hacking the PlayStation 3.
However, he burned out. A major factor were users; quote,
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.
When Apple released the M1, he thought that could be a much more interesting challenge – there would be no entitled users who want to pirate software, plus no necessity for a jailbreak either.
He thus announced the Asahi Linux project, asking for funds to get it started. The name, by the way, comes from the Japanese name for McIntosh apple.
He started a Patreon with a 4k€ monthly donations goal, which was reached within days, and surpassed too. He now had both the money and the determination to bring Linux to M1 Macbooks.
When deciding what language to use to write drivers with, the project bet on the newly-announced Rust for Linux initiative and decided to go with that. According to Hector,
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.
Of course, this meant tying the long-term success of Asahi to the r4l project, at least to some extent.
In the short term, this bet paid off. In a couple of years, they were able to have great support for the M1 MacBook Air, and Linux 5.19 was even released by Linus from an M2 MacBook Air running Asahi.
Even better, during the Open Source Summit of 2022, Torvalds was interviewed by Steven Vaughan-Nichols of ZDNet. In the interview, Linus said that he would like the first signs of Rust infrastructure to be merged in Linux 6.0 and that he was cautiously optimistic about this goal.
Indeed, Linus was a bit too optimistic here. The merge request containing initial Rust support in the kernel was only merged in 6.1, and overall the r4l project was not advancing at the pace that Torvalds was expecting, or hoping, to see.
Indeed, during the 2024 Maintainers Summit (a 30 people invite-only event), Linus said that
nothing depends on Rust in the kernel now, and nothing will for some time yet. What is important is to make forward progress, so developers should "steam right ahead" and not worry about these problems for now.
Here's another important quote from Jonathan Corbet's report of the event:
Linus Torvalds admonished the group that he did not want to talk about every subsystem supporting Rust at this time; getting support into some of them is sufficient for now. When Airlie asked what would happen when some subsystem blocks progress, Torvalds answered "that's my job".
This is important, as Linus is directly taking some level of responsibility on this topic. Hector Martin was not part of the Maintainers Summit, but he did send an email to Linus to say he was available to talk, given his experience with using Rust in a high-profile downstream kernel. However, Torvalds never replied.
In a 2024 interview by the very same Steven Vaughan-Nichols, Linus expressed disappointment that the introduction of Rust was not going faster.
I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust.
This is an issue for the Asahi project, which relies on r4l to work. It's not the only one, though; Martin also started having issues with entitled users again.
According to him, users would repeat over and over the same questions and criticisms of the project: When is Thunderbolt coming? What about external monitors via USB-C? Battery life sucks compared to MacOS! …and so on.
If I may very quickly share a personal opinion in this otherwise somewhat objective piece, I would like to say that I've had the same issues before. I've implemented some features and received criticism for certain decisions behind them, or bugs that they caused; I've also received pushback when I instead chose not to implement this or that. This used to drag me down quite a bit, and it did have some impact on my mental health; I'm now starting to believe that it's part of what I do, and the feeling of being surrounded by entitled users is more a matter of how we community-driven developers approach our job rather than the world around us. But that's just my opinion.
Back to Martin, he also noticed that donations were decreasing month after month; the more features he implemented, the fewer donations he received. He interpreted this as a decreasing interest in Asahi.
Also, a lot of development time was spent rebasing Asahi Linux changes on top of the latest versions of the kernel. He tried to upstream code, but he found the experience to be "incredibly frustrating".
All of this was on top of some personal issues that he encountered in 2024, and which he prefers not to share publicly.
All of this gets us to this merge request, which aims to "add dma coherent allocator abstraction", in Rust. Now, I wish I could tell you what that means, but I haven't the slightest clue. The important part is that this was written in Rust (or at least uses Rust to some extent).
The patch was rejected by maintainer Hellwig, with the single sentence "No rust code in kernel/dma, please".
To be fair, Danilo, who had proposed the patch, did try to argue why the usage of Rust was justified here, and he did say he was willing to take care of the Rust abstraction that it needed to work.
Hellwig again replied with something along the lines of "don't force me to deal with Rust", to which Daniel replied with "We're not asking you to, we're doing an abstraction as you asked us"; Hellwig did not further reply, which Daniel interpreted as green lights from him. Other developers also pitched in saying that the level of abstraction seemed reasonable.
A couple of weeks later, Hellwig again replied by blocking the patch, and specifically saying that Danilo was trying to "spread this cancer to the core subsystem", where "cancer" refers to using multiple languages in the same codebase.
And, a few emails later, he explained that he opposed crosslanguage codebases (and, thus, the r4l project as a whole) so much that he would "do everything [he] can do to stop this". This seems to be a good example of the maintainer issues that Linus was talking about.
As you might've noticed, this entire thread went on without Hector Martin pitching in. However, as mentioned, the Asahi project relies on r4l, and this patch was needed for two of the three drivers they developed.
Martin expressed his frustration on Mastodon, pointing out that the "I will do everything I can do to stop this" can be interpreted as an attempt to sabotage the r4l project as a whole, and that he considers the usage of the word "cancer" to refer to r4l a Code of Conduct violation.
Now, he was deeply criticized for this post, and he has deleted it since then. However, I would like to defend him here. Hellwig words seem to be extremely hostile towards the r4l project, which has existed for years now with the explicit support of Torvalds. Though I might not agree with the wording Martin chose, or the Code of Conduct accusation, I believe the frustration is fully understandable, and ranting on his personal social media account is normal here. I don't take issue with this specific choice of his.
And, to be clear, he also sent a more detailed reply to the mailing list. He also added Linus to the thread – a fair action, I think, given how he has some responsibility over this development. He also suggested to Rust folks to "not waste your time on drama like this".
Now, this is not the first time Hector Martin has vented on Mastodon about the pushback from certain developers to the r4l project; as an example, here's another post that is pretty, uh, strong:
In the patch list thread, a few developers argued that this sort of attitude is toxic too. To quote them,
To back up Sima here, we don't need grandstanding, brigading, playing to the crowd, streamer drama creation or any of that in discussions around this. [...] Being toxic on the right side of an argument is still toxic.
And, finally, as a response to these last few messages, Martin replied with a exhausted message, explaining all of his frustration with the current processes in the kernel. He complains about outdated tooling, nitpicking, unnecessary delays, bikeshedding, and more.
This is where Torvalds stepped in, but he did not say a word about the patch itself and only commented on this last vent by Martin. To quote him,
How about you accept the fact that maybe the problem is you. You think you know better. But the current process works. [...] The social media brigading just makes me not want to have anything at all to do with your approach.
I feel like this accusation is somewhat unfair. Hector Martin did not organize any kind of brigading, which is when a community purposefully targets another space to damage it, flood it, or otherwise change its working. This did not take place at all: Hector Martin shared his frustration on social media, which I believe to be an understandable reaction. Linux news sites picked up on the accusation and some buzz arose, but nothing was organized, nor was the patch mailing list hijacked. Linus is pretty much saying, if you have a problem with how we do things, you are not allowed to vent about it on social media, otherwise I don't want to have anything at all to do with your approach.
Evidently, this last exchange raised some thoughts in Martin, who - given all of the context that I've given you, and not just this discussion specifically - decided he was no longer willing to give up his free time and hobbies to work on Asahi. He stepped down to seek better mental health, which is something I respect.
He has closed his Patreon and OpenCollective and asked his GitHub sponsors to unsubscribe from him.
However, the Asahi Linux project won't die off. A team of seven people - including, by the way, Neal Gompa, hi Neal! - will continue his work, focusing on upstreaming changes, implementing DP alt mode, sparse images, and getting internal microphones working.
You can donate to the Asahi Linux project directly, as they have now set up their own OpenCollective account that is independent of Martin. They say,
Our community will miss him. Still, with your support, the project has a bright future to come.
Before I go, did you know that this video took hours to make and yet it is not sponsored? I also have to pay servers, equipment, and collaborators – which renders this channel a net negative on my finances, right now. You can help me change that by donating on Patreon, Liberapay, Ko-Fi or PayPal – links in the video description.
But, you can also subscribe to or become a member of thelibre.news, the website which contains all of these videos but in an article format. There will soon be some extra content over there, I'm working on it.
Help us break even
We only run on donations. We have a goal of reaching 300 subscriptions, which would allow us to hire staff.
If you subscribe, you'll gain access to a few members-only pieces, though we aim to keep most of our content free for all.
no ads · no trackers · cancel whenever