Resigning as Asahi Linux project lead

[Putting my dusty Linux Distro Maintainer Hat on]

First of all, I wholeheartedly applaud Marcan for carrying the project this far. They, both as individuals and as a team proper, did great things. What I can say is a rest is well deserved at this point, because he really poured his soul into this and worn himself down.

On the other hand, I'll need to say something, however not in bad faith. He needs to stop fighting with the winds he can't control. Users gonna be users, and people gonna be people. Everyone won't be happy, never ever. Even you integrate from applications to silicon level, not everyone is happy what Apple has accomplished technically. Even though Linux is making the world go on, we have seen friction now and then (tipping my hat to another thing he just went through), so he need to improve his soft skills.

Make no mistake, I'm not making this comment from high above. I was extremely bad at it, and I was bullied online and offline for a decade, and it didn't help to be on the right side of the argument, either. So, I understand how it feels and how he's heartbroken and fuming right now, and rightly so. However, humans are not an exact science, and learning to work together with people with strong technical chops is a literal superpower.

I wish Hector a speedy recovery, a good rest and a bright future. I want to finish with the opening page of Joel Spolsky's "Joel on Software":

Technical problems are easy, people are hard.

Godspeed Hector. I'm waiting for your return.

This is every successful product, small, medium, large. I've never ever worked on a big corporate or small personal project and not experienced this.

The secret is to have a healthy system for taking in those requests, queueing them by priority, and saying, "you are 117 in the queue, you can make it faster by contributing or by explaining why its higher priority".

You can't let feature requests get to you, the moment you do your users become your opponent. None of those requests are entitled, the author has clearly already reached a point where they are antagonistic towards requests.

I think entitlement like that is stupid and bad for open source (and everything). However, in the next paragraph the author gets into criticising the opposite position, that asahi linux was not ready for everyday use. The entitled requests came from users that thought of asahi linux as exactly covering an everyday use case, a linux distro they should be able to use to carry on their tasks. This I find contradictory. While some entitled users always exist, you can either admit that asahi is not a daily driver for people who want to use most of basic features of a laptop, or admit that the requests make sense. You cannot both claim that asahi is fine to be used, and complain that users ask for being able to connect an external monitor on a M1 macbook air. I am not sure what is wrong with the claim that asahi linux is an experimental (and no less amazing) project that people lacks certain (widely considered basic when things come to this) functionality, or that the functionality of it is restricted to these use cases that may include using it as a headless server but exclude some common other ones. I am not sure how this would matter, but setting user expectations to a level that matched the state of development may have helped to limit such requests.

I say that also because I have been gotten quite a few responses from people that I should use asahi, while looking at what it supports it definitely would not make sense for me, and you cannot just present it to a macos alternative right now.

I work for a company that is open source and has a large community. I blows my mind (and often aggravates me) how rude some people can be.

For some reason people feel that it is appropriate to throw barbs in their issue reports. Please to everyone out there, if you find an issue and want to report it (hurray open source!) please be kind with your words. There are real people on the other side of the issue.

Always remember, you catch more flies with honey than vinegar.

It sounds like he really got invested too much into what people wrote.

> “Asahi is useless to me until I can use monitors over USB-C” “The battery life sucks compared to macOS”

These are not even requests. These are objective statements he can either take note of for prioritisation or ignore. I can also say Asahi is useless to me until usb-c monitors support, but that's just my situation - there's no bad faith or request here. Previously that was the same for WiFi support.

I wish there was some good model for maintainers of bigger projects to deal with this on a personal level. The bigger the project, the more people there will be with unmet requirements and that's just life. It literally can't be solved.

I don't get that complaint. None of those messages demand anything from anyone or berate Asahi Linux. It's just useful feedback and questions.

> 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.

Or: he shouldn't steal people's time with false advertising :shrug:

Also if he wants to create an operating system, then these aren't even requests, but bug reports. So the users ate his false advertising, spent time to try out his system, then spent some more time to file bug reports, and then he calls them "entitled users".

Open source attracts some of the very worst users. Often people pretending to be trying to help by "suggesting improvements", but just as often entitled people who want to work for free. I don't think policies will change that. It's just something you have to accept when you provide something useful to lots of people for free. Even if you use moderated environments for user feedback (adding the burden of constantly banning people), people will find your email address and complain to you directly. See also: jwz/xscreensaver/Debian drama. Seeing how people treat open source developers makes me hesitant to upload any code I write to a public repository.

I'd expect the worst part for an Asahi project contributor to be the active sabotage some angry Linux kernel devs are trying to pull because they don't like Rust. Users being unreasonable is one thing, but your fellow maintainers are supposed to be allies at least.

I hope Marcan can find a new project to take on that doesn't involve all of this mess.

This whole post feels like typical burnout. Imagine porting something as complex as Linux to a platform who's creators actively do not want Linux ported to it. Of course you will burn our eventually. Not to dismiss his experiences, but I wonder if there is some deflection going on here - burnout was happening anyway but blaming others is a good smoke-screen.

>"I can’t even check my CPU temperature” (yes, I seriously got that one"

Actually if this distro is my primary / only one I would like to be able to check CPU, GPU, etc. temperature. It is important to know if cooling is adequate or requires cleaning / repair.

In any case Marcan would be way better off having thick skin. Users will always be assholes (well same is generally true about vendors).

why not tag it as pre-alpha, not suitable for daily use? Saying smoothest linux experience on one side and expecting people to not expect basic features of the hardware working...how does that work?

"Heavily under development and not ready for prime time use" should have been first line in readme and only reply to such feature request.

So it sounds like they bit more than they could chew.

I have been maintaining open source projects, and really: users of open source projects suck. They get your work for free, but it's not enough; they have to be assholes on top of that.

Let's be honest it's still pretty useless.

People complain about things that they care about. People also don't usually have as much tact as we would like them to.

I think the best way to deal with this is to just confidently say what you are and are not ready to get done. The social dynamic will always be this way, so we may as well take whatever criticism is useful, leave the rest behind, and move on.

Never ever give away anything for free if you intend to support it is an evergreen advice.

Selling ads? Using it as a gateway to a commercial product? Selling support? Have some genius business plan that allows you to make money in the future? Fine, give it away no strings attached but expecting that users will be grateful is a mistake developers keep repeating. The free users are just as entitled, even more entitled as they don’t have a price tag for your efforts and don’t have a document specifying what are your obligations so they can assume scope of entitlements anyway they wish.

Since you gave it for free, you can’t refund an unhappy customers to make it go away. If it looks like a product, You will be stuck with people who think they did their part by using your products and you failed them. Some may make it a full time job to take a revenge on this injustice.

I’m not even sure that these users are at fault, you actually took something in exchange(like fame, street cred etc) and you are not delivering your part.

from what I've seen of his grandstanding on the LKML suggesting to bully people on social media, I've lost all respect for the guy. He is a person in power considering all his social media clout, and this is how he uses it. I'm glad he realizes that it's time to sit back and reflect. And I don't mean that in a disrespectful way. He will be of much more use to the community, and more importantly himself after confronting his ego.

You gotta have super thick skin to be a maintainer of an opensource project or even be popular on the net these days. Folks are going to come for you for whatever reason, if you read too much into it you're going to have a bad time.

It's fair criticism. Asahi is paraded around like a real alternative, well where are the features?

> we brought the platform from nothing to one of the smoothest Linux experiences you can get on a laptop.

Despite the accomplishment this overselling irks me.

Apple users today are just Windows users with even more entitlement.

Wasn’t always like this, I think. Personally have seen the same with other projects and dealing with proprietary Apple APIs and their walled in garden is hard enough.

No good deed goes unpunished.

> I wonder if something like that would be helpful for open source community engagement.

It’s called a Code of Conduct. It exists and is in use by many organisations, including several open-source projects.

> 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.

Happened with actix, happened with serde, and now being threatened by kernel contributors. The perception seems at least somewhat based in reality.

> "If shaming on social media does not work, then tell me what does, because I'm out of ideas."

This is just an incredibly odd thing to say. It's so obviously out of line that it seems like someone's joking around.

The Rust community (generally-speaking) just can't see why people have a visceral reaction against them, independent of its technical qualities. In all my years, I've not seen anything like it.

I started reading the article, having little background on kernel drama, and ended it thinking to myself, “Jesus, what did this poor guy do to deserve all this hate?”

Then I read the thread you linked and thought, “Oh. That.”

To be clear nobody deserves to be harassed or threatened, but Hector’s messages make it clear he is astoundingly good at making himself into a victim of injustice. When his messages mentioned “cancer” I immediately thought that meant another kernel dev told someone to get cancer or die of cancer or something, which would be completely unacceptable. He was using the word metaphorically to describe the way Rust is slowly making its way into the kernel, like a cancer growing.

How anyone (read: Hector) could think this requires CoC action is baffling to me. Insane language policing.

> That’s not ok.

Then entertain his question and tell us what is? Bringing up people’s attention to the matter to finally somehow resolve the situation is his last resort, after spending years trying to upstream even trivial patches. You can eat your cake and have it too - you can’t say you want rust in the kernel and then sabotage any upstreaming efforts

> And then he can't help himself. After being so reasonable, he throws shade on Rust. Shade that is just unfortunately, just false?

Many discussions online (and offline) suffer from a huge-group of people who just can't stop themselves from making their knee-jerk reactions public, and then not thinking about it more.

I remember the "Filesystem in Rust" video (https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s) where there are people who misunderstand what the "plan" is, and argue against being forced to use Rust in the Kernel, while the speaker is literally standing in front of them and saying "no one will be forced to use Rust in the Kernel".

You can literally shove facts in someone's face, and they won't admit to being wrong or misunderstand, and instead continue to argue against some points whose premise isn't even true.

I personally don't know how to deal with this either, and tend to just leave/stop responding when it becomes clear people aren't looking to collaborate/learn together, but instead just wanna prove their point somehow and that's the most important part for them.

> 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.

Unfortunately OP has a valid point regarding Rust's lack of commitment to backwards compatibility. Rust has a number of things that can break you that are not considered breaking changes. For example, implementing a trait (like Drop) on a type is a breaking change[1] that Rust does not consider to be breaking.

[1]: https://users.rust-lang.org/t/til-removing-an-explicit-drop-...

> "which is actively hostile to a second Rust compiler implementation" - except that isn't true?

Historically the Rust community has been extremely hostile towards gccrs. Many have claimed that the work would be detrimental to Rust as a language since it would split the language in two (despite gccrs constantly claiming they're not trying to do that). I'm not sure if it was an opinion shared by the core team, but if you just browse Reddit and Twitter you would immediately see a bunch of people being outright hostile towards gccrs. I was very happy to see that blog post where the Rust leadership stepped up to endorse it properly.

Just one reference: In one of the monthly updates that got posted on Reddit (https://old.reddit.com/r/rust/comments/1g1343h/an_update_on_...) a moderator had to write this:

> Hi folks, because threads on gccrs have gotten detailed in the past, a reminder to please adhere to the subreddit rules by keeping criticism constructive and keeping things in perspective.

These are often the same classification of individual who tend to modify their viewpoints towards “change is progressing rapidly in an area that I don’t understand and this scares me.” Anytime an expert in a particular area has their expertise challenged or even threatened by a new technology it is perfectly human to react in a way that is defensive towards the perceived threat. Part of growth as a human is recognizing our perceived biases and attempting to mitigate them, hopefully extending this into other areas of our lives as well. After all, NIMBYS probably started out with reasonable justifications for why they want to keep their communities the way they currently are - it’s comfortable and it works, and they’re a significant contributor to the community. Any external “threat” to this concept becomes elevated to a moral crusade against the invaders who are encroaching upon their land, when really they’re jousting against windmills.

> Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug.

This is a very persistent myth, but it’s wrong. Adding any public method to any impl can break BC (because its name might conflict with a user-defined method in a trait), and the Rust project adds methods to standard library impls all the time.

> which is actively hostile to a second Rust compiler implementation

Which is hilarious since Linux itself was actively hostile to the idea of a second C compiler supporting it. Just getting Linux to support Clang instead of only GCC was a monumental task that almost certainly only happened because Android forced it to happen.

Thank you to share the Ted T'so LKM post. Can you explain the culture reference "thin blue line"? I never heard it before.

> - "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.

The most charitable interpretation I can imagine is that the Rust-in-Linux project needs specific nightly features, and those don't get stability guarantees. But I think this is still pretty unfair to complain about; my impression is there's a lot of appetite on the Rust side to get those stabilized.

I also think...

> 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.

...that while there's truth in this, there's also a large extent to which it's a self-fulfilling prophecy. Someone might want to stick it out to get their work into mainstream once, but then take a look at the process once it's in the mirror and say never again.

...and:

> Instead of complaining about maintainers for who are unreasonably caring about these things, when they are desparately under-resourced to do as good of a job as they industry demands, how about meeting us half-way and helping us with these sort of long-term code health issues?

It's really hard for me to not see "let's actually write down the contract for these functions, ideally via the type system" as doing exactly that. Which seems to me to be the central idea Ted Ts'o was ranting about in that infamous video.

If comments as benign as "thin blue line" causes fragile entryist/activists to flee, I say Ted and the kernel team are doing the right thing. Projects as critical as the Linux kernel shouldn't be battlegrounds for the grievance of the week, nor should they be platforms for proselytizing. Marcan and others like him leave long paths of destruction in their wake. Lots of projects have been turned upsidedown by the drama they seem to bring with them everywhere. The salient point is contributors need to be more than "drive by" submitters for their pet projects. This isn't specific to Rust in the kernel, look at how much of an uphill battle bcachefs was/is.

> 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.

The community is more than just the language and compiler vendor(s). It's everyone using the language, with particular emphasis on the developers of essential libraries and tools that those users use and on which they're reliant.

In this sense, based on every time I've attempted to use Rust (even after 1.0), Ts'o's remark ain't inaccurate from what I can tell. If I had a nickel for every Rust library I've seen that claims to only support Rust Nightly, I'd have... well, a lot of nickels. Same with Rust libraries not caring much about backward-compatibility; like yeah, I get it during pre-1.0, or while hardly anyone's using it, but at some point people are using it and you are signaling that your library's "released", and compatibility-breaking changes after that point make things painful for downstream users.

> Here's the maintainer on the gccrs project (a second Rust compiler implementation), posting on the official Rust Blog

Same deal here. The Rust developers might be welcoming of additional implementations, but the broader community might not be. I don't have enough information to assess whether the Rust community is "actively hostile" to a GCC-based Rust implementation, but from what I can tell there's little enthusiasm about it; the mainstream assumption seems to be that "Rust" and its LLVM-based reference compiler are one and the same. Maybe (hopefully) that'll change.

----

The bigger irony here, in any case, is that the Linux community has both of these very same problems:

- While the kernel itself has strict backwards-compatibility guarantees for applications, the libraries those applications use (including absolutely critical ones like glibc) very much do not. The ha-ha-only-serious observation in the Linux gaming community is that - thanks to Wine/Proton - the Windows API is the most stable ABI for Linux applications. Yeah, a lot of these issues are addressable with containerization, or by static compilation, but it's annoying that either are necessary for Linux-native applications to work on old and new distros alike.

- As marcan alludes to in the article, the Linux community is at least antipathetic (if not "actively hostile") to Linux-compatible kernels that are not Linux, be they forks of Linux (like Android) or independent projects that support running Linux applications (WSL 1/2, FreeBSD, some illumos distros, etc.). The expectation is that things be upstreamed into "the" Linux, and the norms around Linux development make out-of-tree modules less-than-practical. This is of course for good reason (namely: to encourage developers to contribute back to upstream Linux instead of working in silos), but it has its downsides - as marcan experienced firsthand.

It's also not truthful because many of the Rust maintainers are long time C contributors.

Marcan also linked to this resignation of a Rust Maintainer:

https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@...

which references this fantastic exchange:

https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s

I am not a C person, or a kernel level person, I just watch this from the sideline to learn something every now and then (and for the drama). But this exchange is really stunning to me. It seems so blatantly obvious to me that systematically documenting (in code!) and automatically checking semantic information that is required to correctly use an API is a massive win. But I have encountered this type of resistance (by very smart developers building large systems) in my own much smaller and more trivial context. To some degree, the approach seems to be: "If I never write down what I mean precisely, I won't have to explain why I changed things." A more charitable reading of the resistance is: Adding a new place where the semantics are written down (code, documentation and now type system) gives one more way in which they can be out of sync or subtly inconsistent or overly restrictive.

But yeah, my intuitive reaction to the snippet above is just incredulity at the extreme resistance to precisely encoding your assumptions.

> 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.

I don't follow. The one with zero leverage is the contributor, no? They have to beg and plead with the maintainers to get anything done. Whereas the maintainers can yank code out at any time, at least before when the code makes it into an official stable release. (Which they can control - if they're not sure, they can disable the code to delay the release as long as they want.)

That's useful context because as a complete laymen I thought his message was largely reasonable (albeit I am not unsympathetic to the frustration of being on the other side)!

> 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")

Can I say that I was immediately put off by the author conflating the "thin blue line" quote from with a political orientation?

The full quote (from the article) being: "Later in that thread, another major maintainer unironically stated “We are the ‘thin blue line’”, and nobody cared, which just further confirmed to me that I don’t want to have anything to do with them."

The way I read it, "thin blue line" is being used as a figure of speech. I get what they are referring to and I don't see an endorsement. It doesn't necessarily means a right-wing affiliation or sympathy.

To me it seems like the author is projecting a right-wing affiliation and a political connotation where there is none (at least not officially, as far as I can see on https://thunk.org/tytso/) in order to discredit Theodore Ts'o. Which is a low point, because attacking Ts'o on a personal level means Martin is out of ammunitions to back their arguments.

But then again, Hector Martin is the same person that though that brigading and shaming on social media is an acceptable approach to collaboration in the open source space:

    "If shaming on social media does not work, then tell me what does, because I'm out of ideas."

from https://lkml.org/lkml/2025/2/6/404

To me, from outside, Hector Martin looks like a technically talented but otherwise toxic person that is trying to use public shaming on social media and ranting on his blog as tools and tactics to impose their will and force the otherwise democratic process of development the linux kernel. And the on top of everything it's behaving like a victim.

It's a good thing they are resigning, in my opinion.

Perhaps merge requests should have to go through a process of learning the codebase first, and submitting increasingly more complex fixes before jumping to really complex requests.

It can be hard when solving your own acute issue - doing so doesn't mean it is the only fix or the one the project should accept.

Even if it's beneath someone's talent to have to do it, it is an exercise of community building.

> 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 am acquainted with Ted via the open source community, we have each other on multiple social media networks, and I think he's a really great person. That said, I also recognize when he gets into flame wars with other people in the open source social circles, and sometimes those other people are also friends or acquaintances.

I can think of many times Ted was overly hyperbolic, but he was ultimately correct. Here is the part of the Linux project I don't like sometimes, which was recently described well in this recent thread. Being correct, or at least being subjectively correct by having extremely persuasive arguments, yet being toxic... is still toxic and unacceptable. There are a bazillion geniuses out there, and being smart is not good enough anymore in the open source world, one has to overcome those toxic "on the spectrum" tendencies or whatever, and be polite while making reasonable points. This policy extends to conduct as well as words written in email/chat threads. Ted is one of those, along side Linus himself, who has in the past indulged into a bit of shady conduct or remarks, but their arguments are usually compelling.

I personally think of these threads in a way related to calculus of infinitesimals, using the "Standard Parts" function to zero away hyperbolic remarks the same way the math function zeros away infinitesimals from real numbers, sorta leaving the real remarks. This is a problem, because it's people like me, arguably the reasonable people, who through our silence enable these kind of behaviours.

I personally think Ted is more right than wrong, most of the time. We do disagree sometimes though, for example Ted hates the new MiB/KiB system of base-2 units, and for whatever reasons like the previous more ambiguous system of confusingly mixed base-10/base-2 units of MB/Mb/mb/KB/Kb/kb... and I totally got his arguments that a new standard makes something confusing already even more confusing, or something like that. Meh...

I agree. I mean constant nagging about features can definitely be annoying so I can understand that part but having the rest sounds like burnout.

PTSD seems a bit of a stretch in my (perhaps uneducated opinion), but he's definitely been under a pile of stress that he's internalizing more than he should be.

The goal of Asahi Linux is to create a Linux distribution that is compatible with Apple devices. Using Rust is not a goal of the project, it's just something they decided to use due to personal preference, and is making the process of upstreaming anything much harder. If anything, it works against them in achieving their goal. Abandoning Rust is a possibility, abandoning Linux is not.

> 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.

They are relying heavily on mesa. I'd also assume that GNU stuff is also pretty essential.

Perhaps Android would be possible? It has a HAL that might be easier to work with than the raw linux kernel. The android devs have put in a lot of effort to make downstream driver development not painful. With android, they'd also still have GNU stuff available.

The big issue is non-linux will mean every single open source tool may have a compatibility problem. You also end up dumping a huge amount of capabilities (like running docker containers).

> I wonder if the Asahi team is considering simply abandoning linux in favor of something more rust friendly

The entire point of Asahi is to run Linux on macOS (edit: on Mac hardware, not macOS). If they did what you’re suggesting it would be a completely different project.

If you don't use Linux it will end up as a dead project, no one is going to use redox.

Redox would probably be the best option. The BSDs, it would probably be an uphill fight to. I believe it's been floated, but no movement on incorporating Rust in the BSD kernels. So I they would have to start form scratch. The benefit of Linux in this case is, the Asahi team isn't single handily doing all the Rust in the Linux kernel, right. There are other Rust people and Rust for Linux was already getting somewhat bootstrapped before the Asahi project. With the BSDs, you would have to start with bootstrapping Rust in the kernels and build systems.

FreeBSD may be open to it? It's been awhile, and I haven't kept up to date on it for a year or two. But once again, I think you'd have to start from scratch. So everything for R4L that was built before Asahi Linux needs to be done on the FreeBSD side.

NetBSD is probably a no go. NetBSD supports architectures that Rust (due to LLVM) can't support. Which means it is most likely a no go for NetBSD, NetBSD's schtick is that it can run on anything and they will fully do everything in their power to make sure NetBSD can run on any hardware and be maintained. Hardware portability matters for them.

The attitude I've seen from OpenBSD devs is, the answer is to 'git gud' at C and, not replace C code with Rust. Or in other words, they have no interest in Rust in the OpenBSD kernel.

I don't really know where DragonFlyBSD falls in this. Its the BSD I know the least about.

They would need to completely reset to do that. Do BSDs even have rust support for their drivers?

OT, Have you had any issues with WiFi setup with this Mac Mini? I tried multiple distributions and most of them have troubles with detecting WiFi chip on 2014 mini.

I feel like Asahi is pretty nice as a lightweight daily driver for web browsing, web development, and stuff like that. Obviously, heavy duty tasks like gaming, CAD, photo/video editing, etc are not quite there yet. I bought an M2 Macbook Air and run Asahi Linux full time and it's surprisingly smooth and bug-free (even smoother than my Arch Linux desktop tbh).

i don't think anyone on the asahi team doesn't know that there are missing functionalities. if they're dealbreakers for anyone, fine.

what's out of line is incessant reporting (via issues, emails, whatever) of what you consider a dealbreaker. that's my impression of what he's complaining about. let the people work. no one likes to respond "not yet" a billion times.

This is not something specific to open source. Unfortunately if you want to be well-known person who works on well-known project you must either ignore all the shit thrown at you altogether or you must be very very resilient. When you react to attacks on internet you will be attacked, often.

And while I appreciate Marcan's work a lot he is also partically responsible because he himself often jumped on bandwagon attacking other people exactly the same way.

That is why I absolute love the quote from FFmpeg maintainers towards a drive-by complainer:

Talk is cheap, send patches.

https://x.com/FFmpeg/status/1762805900035686805

I see a lot of FOSS maintainers continue to engage and defend themselves against people who have demonstrated themselves as unwilling to contribute in any way, yet expecting that free work be done for them. I wish more open source devs will keep in mind that FOSS work is a gift they're sending out into the world, and it's a common good that anyone can contribute to. That is not to say ignore all criticism or user requests, just that you hold absolutely no responsibility to placate emotionally draining people - the project is just as much their responsibility as yours.

Easier said than done. If you care about users, and then realize most of them are jerks, it’s deflating. Maybe the secret is to not care about users, but the risk is that you end up doing self-gratifying work that leads nowhere.

To me, unless there is an exchange of money and a signed statement of work, I have absolutely zero entitlement as a user. And the maintainers are well within their rights (by law and social contract) to tell me to go away. I wish this was a more adopted mindset.

It’s why things like CentOS being abandoned, terraform licensing, et. al. never bothered me. I’m not paying them, so :shrug:.

I've worked with plenty of talented engineers who behave like this. It takes a certain psychology to achieve incredible technical feats, however they often come at the cost of personality issues in playing with others.

You add these personalities together, where everybody believes they are right an everybody else is wrong then it's a recipe for disaster.

People have to learn to adapt to change, or they get burnt out continually hitting the brick wall.

I don't really follow what's objectionable about Ted's email, or why it's being singled out. It matches my experience as an open source maintainer pretty accurately. It's also pretty constructive (it goes on to lay out a plan on how to constructively proceed and make everyone happy).

It's hard to know what he exactly means by this. It sounds pretty bad but this guy does seem to attract and develop a fair bit of drama and this could be a bit exaggerated from the truth.

Absolutely not okay and I somehow hope it hadn’t todo with Asahi Linux.

It's not okay but he's giving them ammunition by mentioning them and complaining about them. It proves that it's working.

When I started getting harassed in 2022 over an ill advised post on a site, the only thing that stopped it was to sandbag everything and rethink how I interacted on the internet.

pretty sure he's one of kiwifarm's lolcows. so he's quite not ok, i'd imagine.

If there are such stalkers they are probably ITT as well.

It seems like mostly personal problems, and if this is not going into detail, whoo I don't know what detail would be:

https://vt.social/@lina/112887550181123672

https://docs.google.com/document/d/1W2Vvwg0rwSVb5r4TQ_NmAF8S...

They pretty much straight up confirm the identity of Asahi Lina, so enough with the gaslighting that merely mentioning this (and having a totally reasonable discussion on contributor persona policies and sockpuppeting, which is what this is) is somehow unethical doxxing.

Yes, I second that! Thank you for the unbelievable amount of work you did. I would have never thought that it was even possible to do without vendor support. You made history, and it won't be forgotten or disappear. Now, please take a rest and enjoy life and other hobbies. I wish you the best!

I second the motion. So many of us are deeply thankful for this tremendous work.

I don't doubt him about the stalking problem (by online trolls, not necessarily IRL). He was a prominent voice in the trans supporter community and was regularly attacked by Kiwifarms.

> 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

You actually provided more details here than he did, so I guess that's not true.

>> 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).

If anything, I am more doubtful you had stalkers since you are also in this thread saying this[1]. What an unsympathetic reply. You certainly don't come off like you're aware of the stress and fear that can bring if your answer to other people being stalked is "rethink your life choices."

> Sounds to me like you just need to take a break from the internet friend. If you're that high profile that you're getting hit over and over, maybe you need to rethink your life choices. If it bothers you that much especially.

[1] https://news.ycombinator.com/item?id=43038512

Yes, he’s clearly an extremely talented individual, but can’t seem to cope with not being the centre of other people’s worlds.

Undiagnosed burnout possibly also played a role here.

> This idea that conflicts need to be resolved quickly and in the favor of a golden boy is a millennial/zoomer issue.

This is a strawman with no support behind it in the actual blog post. Marcan's issue wasn't that he wasn't "getting his way", his issue (from his viewpoint) was with Linus and co. claiming to support Rust on Linux while doing nothing to aid in adoption and in the case of some maintainers, actively sabotaging its implementation.

If you're going to do something, then do something. Don't say you're going to do something, then do nothing while your underlings actually do the opposite.

You should click through some of the links to see where the clashes actually happened. It didn't have anything to do with the actual hardware support. Rather, it was over stupid shit like the kernel DMA team throwing a hissy fit over the idea of there being Rust bindings for the DMA interface: https://lore.kernel.org/lkml/20250108122825.136021-3-abdiel....

When the response to such a small contribution is just "No rust code in kernel/dma, please" with a complete shutdown of any attempt to discuss alternatives, it's kinda pointless. Even though Rust is supposed to be an allowed language in the kernel now, with blessing from Linus himself, there's apparently just submaintainers of critical, highly shared infrasture that outright refuse it.

So this has nothing to do with "who will own the Apple drivers?!" but just the rest of the kernel going "your integration layers are an affront to our Holy C, begone religious heretics!"

Agreed, supporting apple devices is going to be a maintenance nightmare as it goes against the wishes of apple. At best, apple involuntarily makes reverse incompatible changes which breaks the drivers and at worst apple specifically sabotages the drivers to keep people in the walled garden.

This may be controversial but you also don’t have a right to merge in code to the kernel. If the maintainers don’t want rust code then you should write your drivers in C. And if you don’t like that you can maintain your own kernel tree in rust and take on the maintenance burden.

> a device that the creator of clearly has no interest in allowing others to use outside of their walled garden

This doesn’t seem accurate.

> In macOS 12.1, Apple has added the ability to directly boot a raw image directly instead of a Mach-O, even though Apple has absolutely no use for this functionality. According to Hector Martin (Asahi Linux developer) making things easier for Linux developers is the only known reason Apple would have added this.

https://linustechtips.com/topic/1396740-apple-adds-feature-i...

> Where is the demand for it?

There was at least one person who said[0]:

"I'd absolutely love to have one, if it just ran Linux.. [...] I've been waiting for an ARM laptop that can run Linux for a long time. The new Air would be almost perfect, except for the OS."

Seems like the same person has even used Asahi to make a Linux kernel release[1][2].

But Linux presumably doesn't have the resources to go chasing hardware platform support based on the whims of a singular Linux kernel developer/maintainer/creator.

----

[0] https://www.realworldtech.com/forum/?threadid=196533&curpost...

[1] https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0X...

[2] via: https://arstechnica.com/gadgets/2022/08/linus-torvalds-uses-...

This quite literally the story of nouveau. The driver exists because people need it, and the driver is maintained by the people who wrote it. I don't see why the same doesn't apply to Linux on Apple Silicon.

linux on game consoles might be a small part of the market, but it's a reality. there's a fair amount of manufacturers, devices and people buying them.

Starting social media shame wars over minor disagreements isn't exactly what I would call hacker spirit, but whatever.

I've heard "Linus Torvalds has refused to decide whether to accept or reject Rust, and this is a leadership failure".

Maybe I'm don't know the situation enough, but I think he's not deciding because he has no idea. The "wrong" option may create far more consequences than the "right" one (so he can't e.g. flip a coin) but he has no idea which is "right".

Torvalds has spent so long working with C, even if he went out of his way to learn Rust, he'd never have as much experience to get an unbiased view of both. Perhaps he's hoping people who are younger and have more equal experience, but who are still smart and experienced, will shift the project towards the correct decision. Unfortunately that's not happening, because as a solid BDFL, he's the only one who can make a shift of that size. But either shift could be a huge stain on Linux's history, and he has no idea which, so he's stuck in a horrible conundrum.

If that's the case, keeping in mind that Linux is Torvalds's life's work, even if doing nothing is itself a bad choice, I don't blame him.

Regardless, since Torvalds can't decide, I think the community has to come together and 1) agree on a consensus mechanism then reach a consensus (e.g. vote on it), or 2) come up with a magic third option which Torvalds can accept*.

e.g. "integrate Rust into the kernel, but ensure that all future Rust compatibility issues are handled by Rust developers, even if they are caused by C code changes, through the commitment of a team of general-purpose Rust developers large enough relative to the number of C developers". I don't know if one can really ensure there are enough Rust developers to not block the C developers, but Rust is very popular and maybe growing faster than C, so maybe it's possible.

I can't agree more. Linus position here is not dissimilar to CEOs and alike. He's trying to deal with R4L using his (allegedly) 100% technical and 0% political perspective but in this case it simply doesn't work. R4L is a political challange that require political discussions; who decides? what's the bar? who maintains what? etc

By not answering this questions and saying he doesn't want to have anything to do with the arguments, Linus simply decided that he doesn't want to solve the problem that only him can solve. The result is clear: R4L will fail if Linus decides that any maintainer can stop the "cancer" to spread and block Rust changes.

R4L implies that Rust will be present in the kernel and will need to be maintained. If Linus is ok with maintainers that have a deep/fundamental problem maintaining/coordinating the maintenance of Rust code, R4L will never happen.

> Torvalds seems to usually position himself as a kind of anti-political

except when he suddenly wasn't

he lost my respect the moment he went there

But this conflict isn't about competing with Linux, it's about having a vision for what Linux should be that clashes with the core maintainers' vision.

They aren't competing with Linux though.

> Would be cool if Qualcomm hired Marcan

Marcan had a whole rant[0] in the thread that started all of this about kernel people being payed by corporations instead of being freelance like him. I'm not sure he wants to work for a corporation.

[0] https://lore.kernel.org/lkml/c5a49bcb-45cf-4295-80e0-c4b0708...

Why does disliking C++ make it odd that he is open to Rust? C++ is uniquely bad; disliking it doesn’t necessarily mean you only like C.

I was thinking the same on this. It is a classic case of division of responsibility. The argument appears to be: should we force a small number of downstream maintainers to suffer a big maintenance burden or should we make upstream handle a smaller burden.

Martin's position rests on his claim that the big maintenance burden he would be forced to bear is unfair. I mean, he is the one who chose Rust. No one forced that on him. It is kind of hard for me to see his claim that the maintenance burden of his choice is somehow the responsibility of the upstream maintainers who are all C developers, no matter how small he insists such maintenance would be. My own opinion is that he made his bed, he needs to sleep in it. Or wait for the tides to change in his favor over Rust inclusion in the kernel. All of this crying foul just doesn't sit well with me.

>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.

Linus is pro-R4L. He wants to see Rust drivers in the kernel upstream, and has expressed frustration that it has been such a slow process, and that he doesn't understand why some maintainers turn it into a religious issue.

The problem is that he hasn't done much in the way of actually standing up against arbitrary stonewalling by those maintainers. This ensures that everyone gets pissed off and creates a giant mess of arguments. Rust people get pissed off because they were told their contributions were welcome and feel like their time investment is being wasted on bullshit, and C maintainers because the lack of a clear policy leads to ruminating and imaginations running wild.

https://news.ycombinator.com/item?id=42972062 ("Asahi Linux lead developer Hector Martin resigns from Linux kernel" from last week, 1014 comments)

"spreading awareness about a position" isn't a very accurate way to describe what happened. This is the guy who said he wanted to use social media to create a "hall of shame" for kernel developers. Of course Linus told him to knock it off, that's ridiculously unprofessional behavior.

Brigading has no place in open source communities. There are some members of the Rust community who believe C is obsolete and that C programmers should either switch to Rust or get out of the way. This is an extremely toxic attitude that has no place in the Linux kernel!

The fact remains: Rust doesn’t solve all of C’s problems. It trades them off for a whole lot of new problems, many of which are challenging to address in a kernel development setting (and much less of a problem for userspace software).

This makes the “C is obsolete” position even harder to defend and ignoring the concerns of long-term kernel maintainers is not going to get anywhere! I think these folks ought to learn the lesson of Chesterton’s Fence [1] before continuing on their journey to promote Rust, which does a lot of great things!

[1] https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...

Maintaining the Linux kernel is all about gatekeeping. How else do you keep out bad code?

Ok, so you are just "spreading awareness" but Linus is "indicting". I guess it is good if you and Linus go their separate ways.

Not to mention stalkers ? Doesn't matter how much you love a community, one or two psychopaths can maybe it simply not-worth-it.

It's hard enough in physical spaces to remove abusers (usually the abused just stop showing up), I can't imagine there's an answer for preventing this kind of behavior in online spaces

It's not really unprecedented. Reminds me of Paragon Software trying to merge their code for an NTFS driver and getting told-off because the driver code was so awful: https://www.theregister.com/2021/09/06/github_merges_useless...

If you want your code merged in the kernel, you have to think about things from Linus' perspective. You cannot in any circumstances try to shame someone into adopting an enormous and unsustainable workload.

Linus didn't say he was the problem, he said he should consider that maybe he was the problem.

That's an invitation to self-reflection.

We all should consider that, in every discussion.

The opposite is to think that everyone who disagrees is by definition wrong, which can never be productive.

You’re right, it’s mostly any open source code projects too. I’ve tried to contribute to projects where they ignore my merge request and take my code and merge it in under their own account. I call this behavior “demonstrating the moat” in which the Maintainers are more concerned with maintaining a moat around their project that they actively go out of their way to prevent contribution under the guise that your contribution did not correctly cross the moat. Even if the moat is mostly decorative and ceremonial.

To be fair, nothing in human history has psychologically prepared us for semi-real-time two-way interaction with thousands or millions many people at once. Once I realized this, I began to become much more empathetic toward popular public figures who “crash out” (as the kids say these days) on social media. I've never experienced this myself, firsthand, but after seeing this happen time and again over the course of the past two decades or so—especially since the advent of smartphones, which dramatically increased the possible frequency of such communication—it's the logical conclusion I've reached.

Totally—on the hardware platform piece, I've owned Macs since the 90s, first installed Linux on one in like 2003ish, tried it on all of my various Macs since at some point, but switched to a desktop Linux machine full time in 2020. I'm generally not one to crap on ambition, but Linux is just so much more enjoyable on hardware that isn't totally closed/undocumented/hostile/unsupported by the manufacturer. With the Macs there was just always something slightly unsupported, regularly broken by updates, or otherwise not quite right, and that was before the architecture switch.

Apple makes great hardware (I have an M1 laptop I use away from home), but if I'm intending to run Linux as my primary OS, I'm buying from a company that is more open to it.

Agreed. There's such a victim mentality throughout this post.

While it's clear that marcan faced into headwinds, they're also definitely not somebody that I want to be around me in any kind of leadership position.

Avoiding drama is a two-way street. I'm not saying marcan wasn't at least somewhat at fault here, but the reason the drama happened in the first place is a leadership crisis and Linux folks calling Rust a cancerous religion without any pushback. Might be valuable to resolve these problems instead of blaming a scapegoat, don't you think?

I have a few projects that I've abandoned because they only made sense as a FOSS project, and I saw how FOSS maintainers were being treated. I love FOSS, I love the philosophy, and I would love to "give back" one day by making the ecosystem richer, but I've not yet found a project that I love enough to be abused over.

For anyone who complains, everyone knows.

https://news.ycombinator.com/item?id=35234480

https://news.ycombinator.com/item?id=32947939

https://news.ycombinator.com/item?id=33792670

https://news.ycombinator.com/item?id=35251905

https://news.ycombinator.com/item?id=36107998

https://news.ycombinator.com/item?id=35238601

https://news.ycombinator.com/item?id=42990443

https://news.ycombinator.com/item?id=37550189

https://news.ycombinator.com/item?id=36231241

What exactly is the basis for the claim that this is the same person?

Is he really still pretending that his vtuber persona is a different person? That makes this way more of an embarrassing attention-grab than it already was.

Are you saying that PCs do not usually have the ability to plug into a monitor, to charge, and to connect to a USB hub for the rest of your devices from a single USB-C port?

You guys still plug three cables each time you sit at a desk?

> Few maintainers care about the platform in question (to whom it's more a curiosity [...]) and don't have the hardware to test any submitted patches.

Yeah, from some very brief research I could only find a singular Linux kernel developer/maintainer/creator who said[0] "I'd absolutely love to have [the new 2020 Air], if it just ran Linux".

Who knows if that one person has even used Apple hardware before or has access to the necessary hardware to put toward a practical use such as a "development platform" while travelling, or, "doing test builds and boots and now the actual [Linux kernel] release tagging"[1][2], let alone be supportive of experimenting with Rust in the Linux kernel[3].

The history of Linux demonstrates the project doesn't have the resources to go chasing support for a hardware platform just because Linus cares about the platform in question...

...even if at least "173 people, and many more" "contributed both to the Linux kernel side but also to the upstream Rust side to support the kernel's needs" in the initial merge[3].

----

[0] https://www.realworldtech.com/forum/?threadid=196533&curpost...

[1] https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0X...

[2] via: https://arstechnica.com/gadgets/2022/08/linus-torvalds-uses-...

[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

> Kids are almost teens now, but she gets zero support from them or her husband

This is a good analogy. Children are the people who they've been raised to become, so it stands to reason that people will give money and appreciation in the same ways that these things are originally given to them. These things are social constructs; we are inevitably taught how to use them by way of social dynamics. This is all to say that people love to support their darlings... but they've been socially conditioned to expect reciprocity in all transactions. That's how the sausage is made in content-based monetization -- you produce the actual product at a loss and then try to claw it back selling high-margin merchandise that nobody'd ever buy otherwise. The merch acts as social permission to finally do your part and pay the creators.

To risk stating the obvious: this is not a good thing and I think the majority of people would likewise agree. People should be fairly rewarded for their work and we should desire a culture which openly and freely encourages doing so. Culture, however, reflects society. The society we've created is transactional, so that's how people frame the spending of their money and efforts -- indeed, "spending" and "transaction" are practically interchangeable in our collective lexicon. Effort isn't strictly scarce in the same way eggs are, however, so we fail to value it.

> 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

It's not a total disaster... so we'll undoubtedly continue to ignore the cracks in the foundation. Martin still got paid good money for his efforts and it was good for him for a time. That podcast you like will sell enough t-shirts and get the rent paid on time, at least for a little while longer. This seems to be about as good as we've collectively agreed to make the world for the time being. A local maxima, so to speak: we've gotten stuck asking for more when less might do better. With a bit of luck and effort, however, we can still catch that pendulum when it eventually begins swinging in the other direction. That's my hope, anyway! For the time being I try to do the things I'd like to see become normal in a more decent world -- sharing generously, paying for the things I like, etc. -- because hopeless accelerationism is for chumps.

> unsupported ways to use someone else's products [Emphasis added -- CRC]

So we're now officially acknowledging that the ostensible "owners" of Apple products don't really own their machines at all; Apple does?

Stuff like this is fairly common. Drivers for the Wiimote and other Nintendo controllers were not put in the kernel by Nintendo employees or with their blessing. Sometimes you want something to work and the only way is to handle it yourself.

My understanding from afar is that a Rust dev wanted to interact with C code in a way that the C maintainer didn't like. This led to the C dev saying that while he likes Rust, he believes multi-language codebases are cancer and would stonewall all Rust code that touches his code.

Marcan watched it unfold on the mailing list wanted Linus to step in and force the C dev to play nice. Since nothing happened, he went to social media and lashed out as a last resort. That's when Linus finally chimed in and pretty much said "you might be right, but this isn't the way to handle things".

>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.

From what I saw on urbandictionary, it seems more likely to be something cops in high crime areas in the UK say.

Thank you for pointing out the blue line comment, I didn’t grasp it and continued. If you are right I’m saddened to see this type of politics being played in the kernel development. Especially since the Russian maintainer incident.

That's not really Apple's game anymore. They don't really care about selling Macs, what they want to sell you is their ecosystem. So that way you'll get a Mac and an iWatch and an iPhone and whatever else they push out once they get their hooks and lock you in.

> I wonder if it would be in Apple's interests to actively support Linux on Mac

Trust me, we would know by now if it was. It's not.

> It would make Macs more attractive as developer machines, and I don't see how it would disadvantage them.

The only development they want is development inside XCode. Anything else is a hard no.

There was a proposal to do something like what you suggest in redox: https://www.redox-os.org/news/rsoc-2023-eny-1/

I'm not sure how much work has actually been put into it though.

Buying MacBooks and doing your development work in a full screen Linux VM (with e.g. UTM) is a surprisingly good solution, that’s what I’ve done for the past year with no regrets.

The Patreon was specifically started to fund the Asahi development, so it's fairly disingenuous to continue taking those donations as not everyone will keep track. He can always start a new patreon.

They were, sadly, proved right not by Apple's actions, but by the kernel development community.

I actually helped with some of the beta testing for it. They worked on it very early on in the Apple silicon Mac lifecycle, and it hasn’t been updated in nearly half a decade. I consider it a proof of concept.

https://github.com/corellium/linux-m1

The name is kind of ridiculous though. Sounds like a misspelling by East Asians, so nah, it'd have to be named something different.

Otherwise people are going to get accusations that it's a South Park thing.

My perspective is it might be a chicken-or-egg problem. I would willingly donate to the Asahi project...if/when I were to buy a Macbook for the purpose of running Asahi Linux on it.

And I've been watching from the sidelines, waiting for Asahi Linux to become "stable" enough to consider buying a Macbook and putting Asahi Linux on it.

> The author writes as if part of his drive was that Linus himself showed enthusiasm for getting Linux on Apple Silicon.

Perhaps the author jumped to conclusions after Linus himself started using Asahi Linux on his own laptop for Linux kernel development[0]. Note the praise for the Asahi team in the commit message.

[0]: https://news.ycombinator.com/item?id=32311150

And it sounds like you read just one side of the story, with no background in Linux kernel internals. This is about how C APIs are typically inherently unsafe, Rust people wanting to build safe(r) abstractions on top, and a question of who is responsible for changing what code when it's time to refactor the underlying C API. And yes, marcan is being overly dramatic, though he is not alone in that.

They would have to play catch up for a few years rebasing off the latest and then eventually lose interest and it will all stop working. Same thing that happens with most arm devices that aren't upstreamed.

As written in the article, Mesa will not enable drivers if there is no HW driver in Linux.

My sense from the article was that it seems less of an Apple is Apple issue, and more of a Linux maintainers are Linux maintainers issue. The big problems listed are all interpersonal conflicts and a sense that the maintainers were making his life upstreaming Rust changes hell.

This isn't an Apple issue. Maybe Linux on Apple is inherently more problematic, but the issue here came from Linux maintainers hostility towards Rust.

The people in the thread were complaining about having mixed languages in a core kernel module, not about the language being Rust. Replace Rust with any other language and their complaint would have remained. The Rust people complain about not getting technical arguments against their proposals, but how is "a module that's coded in two languages is more difficult to maintain than one coded in a single language" not a technical argument?

I hope so

> 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.

I personally lost my confidence in it when they stopped properly triaging security issues and flooded everyone interested with just noise.

Someone posted a Google doc in this thread that goes through all of it.

> That of course was difficult in the corporate environment of 2014-2024.

No clue what you could mean by this

>Perhaps he was forced to do it.

By whom? Linus is the one who decides these things.

Plenty of people disagree with your rust take. Are you a Linux maintainer?

At the top of the page:

> Hi! It looks like you might have come from Hacker News.

> Asahi Linux developers are frequent targets of abuse on Hacker News. Despite our pleas, the moderators have not taken effective action to improve the situation.

> Overtly hateful content is often flagged on HN and not immediately visible. Unfortunately, when a comment is flagged and killed, its child subthread is not. That preserves the 'clean' image of the website, but the reduced moderation activity enables abuse to continue. Although you don't see those threads, search engines do. HN uniquely has a high page rank and low moderation, making it a prime target for bad actors to poison search results with abuse, bigotry, and nastiness. This isn't low-level trolling, but an organized attempt to destroy lives, including of developers in our communities.

> Please demand change within your community.

This is an unfair and gross assessment. I've lost some respect from Asahi for this.

They're calling for extreme moderation of opinions they don't agree with, which is the opposite of open discourse.

Asahi: deal with it. You're Streisand Effecting this. Your inability to handle drama is actually causing more drama. Just turn the other cheek and ignore it.

"Although you don't see those threads, search engines do. HN uniquely has a high page rank and low moderation, making it a prime target for bad actors to poison search results with abuse, bigotry, and nastiness. This isn't low-level trolling, but an organized attempt to destroy lives, including of developers in our communities."

He likes C, hate c++, allowing rust in the kernel is trying something new, and maybe to attract new maintainers that don't care too much about C, and as he said "maybe it work, maybe don't, if don't we learn"

Rust is static analyzer built into a compiler frontend

I checked into Reiser4 and they are still indeed working on that out of tree. Hats off to people who stick to it, though I think renaming the file system would have been a smart idea.

That's the only other project I can think of that's out of tree besides the usual suspect (ZoL)