That's very true. I recommend some people to read "The Four Agreements", because that thin book has real potential to improve people's lives through active and passive communication.

stoics don't write multi-paragraph goodbye letters

That is part of the challenge he chose to take on.

> Headwinds from users, because of the stripped down experience.

Users can be ignored. How much you get users to you is your own choice.

> Headwinds from the kernel team, who are in the unenviable situation of having to accept and maintain code they can't test for hardware they don't own

You don't have to upstream. Again, it's not the kernel team that chose to add support for "hostile" hardware so don't try to make this their problem.

> and who apparently have some sort of schism over rust support?

Resistance when trying to push an entirely different language into an established project is entirely expected. The maintainers in question did not ask for people to add Rust to the kernel. They have no obligation to be welcoming to it.

> Be a heck of a lot easier if at least one of them was on your side.

Except for the users all the conflicts are the direct result from the choice of work. And the users are something you have to choose to listen to as well.

Humans are shaped by experience. This is both a boon and a curse. I have been also been on the hot end of the stick and burned myself down, sometimes rightly, sometimes wrongly. Understanding that I don't want to go through this anymore was the point I started to change.

> Collaborating on software development is a social activity and stuff like convincing maintainers to trust you and your approach is just as important part of it (if not more important) as writing code.

Writing the code is at most 5% of software development IME. This is what I always say to people I work with. I absolutely love writing code, but there are so many and more important activities around that, I can't just ignore them and churn out code.

Yeah but FFS using email for patches when there are so much better ways of doing development with git? The Linux Foundation could selfhost a fucking GitLab instance and even in the event of GitLab going down the route of enshittification or closed-source they could reasonably take over the maintenance of a fork.

I get that the Linux folks want to stay on email to gatekeep themselves from, let's be clear, utter morons who spam on any Github PR/issue they can find. But at the same time it makes finding new people to replace those who will literally die out in the next decade or two so much harder.

What I found is being able have this "afterburner mode" alongside "advanced communications" capabilities gives the real edge in real life. So, this is why I wish he can build his soft skills.

These skills occupy different slots. You don't have to sacrifice one for the other.

«Undocumented» – yes, but «hostile» is an emotionally charged term that elicits a strong negative reaction; more significantly, though, it constitutes a flagrant misrepresentation of the veritable truth as stipulated within the resignation letter itself:

  When Apple released the M1, I realized that making it run Linux was my dream project. The technical challenges were the same as my console homebrew projects of the past (in fact, much bigger), but this time, the platform was already open - there was no need for a jailbreak, and no drama and entitled users who want to pirate software to worry about.

Also, if you had a chance to reverse-engineer a closed source system, you would have known that «hostile» has a very specific meaning in such a context as it refers to a system that has been designed to resist the reverse-engineering attempts. No such resistance has been observed on the Apple Silion computing contraptions.

This is when the underrated skill of saying NO pays off massive dividends. One long-term client once told me the thing he appreciated the most, compared to most other consultants, was that I wasn't afraid of pushing back on his requests and saying no (within reason). Probably the most valuable feedback I have ever received.

Obviously, there was some oversight from managers, but overall it worked pretty well.

Great idea about the priority queue.

Does it have to be a meeting? Although it's about sales calls, I'm reminded of https://keygen.sh/blog/no-calls/ (HN discussion: https://news.ycombinator.com/item?id=42725385 )

I've read your comments here (and elsewhere) for a long time, and I'm sure you'd have some great ideas or at least opinions about this, which is pretty relevant to what you just wrote: https://news.ycombinator.com/item?id=43037537

Imo modern linux experience is much better than the situation you describe, at least as long as you use certain type of hardware. In the past it was definitely harder. But wrt asahi, I want the "luxury" of using an external monitor with my 13" macbook air, and sadly, while in the past x86 machines I put linux I would put some effort and get AMD mesa drivers to work, I cannot do that here. I respect the effort put in the asahi project, but calling it suitable for a daily driver is misleading, unless you specify exactly what sort of daily driver you mean. Stuff like using an external monitor is pretty basic in my book of daily usage.

In hindsight.

> [Linux] did become reliable over the years.

Might have gone the other way. And if it had, nobody would be surprised at that either, now.

There's a broader topic of ... just be nice to people. It doesn't cost anything. It does reassure me that this universe has been struggling with this for decades upon decades--witness the Malvin and Jim scene in WarGames. "Remember when you told me to tell you when you were acting rudely and insensitively?"

> I miss having free time where I can relax and not worry about the features we haven’t shipped yet. I miss making music. I miss attending jam sessions. I miss going out for dinner with my friends and family and not having to worry about how much we haven’t upstreamed. I miss being able to sit down and play a game or watch a movie without feeling guilty.

This is the big problem really. He should have just turned down his work hours to a regular 40 a week, asked for more donations to pay more people and asked for more volunteer help. And honestly, probably therapy.

I can't imagine then what's his problem. I don't get offended by people that can't even read. I don't normally call them people let alone entitled :\ Set up a bot that links them the device support page, and problem solved? I don't get it

When I want to give something away, I list it for some nominal fee like $10, then just tell them to keep it. Because when I used to list things for free, I got the dredges of society bothering me. Asking for delivery, asking me to hold it for 3 months til they can find a truck, cussing at me for saying no to both of these, cussing me because I sold it to someone else already, telling me long sob stories to guilt me. I've never had any of that happen when asking for money(except one guy wanted me to deliver it for $20, which was a fair-ish offer).

I wonder if that same 'pay but you'll get it back under the table' model could work for software? At least until the word got out, I guess.

Sounds like a great time to give them a refund because they didn’t get the product they thought they were getting.

Too passive aggressive? :)

Yes.

> The only way to do that is to never collaborate with anyone else.

Not necessarily. You can also treat project politics and social skills like any other technical skills that you need on your team like network engineering or database optimization.

If you can find trusted collaborators with those social and political skills, you can make a lot of things happen without necessarily being very good at it yourself.

Team building has a lot of parallels with building a full stack technology. Or building a sports team.

Who's demanding a rewrite of Linux?

People become vocal when they are pissed.

It is unfortunately wrapped up in larger-scale outrage culture than just within tech/programming circles. Rust as a community is very gay and very trans:

https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve...

https://blog.rust-lang.org/2025/02/13/2024-State-Of-Rust-Sur...

To be clear I am 111% down for that as one of the Alphabet People myself lol. We just can't pretend like it isn't a factor.

Disclaimer: I realize these numbers are probably skewed high due to self-selection of people who are willing to take diversity surveys. The actual percentages are probably somewhat lower, but Rust undoubtedly has the highest concentration of any programming-language community. Zero question.

Get an HN article about C++, and you can be certain the comment section is going to deteriorate at some point into a religious war mentioning Rust. Get an article about Rust, and there is going to be drama in the comments.

As a programmer that could potential consider Rust, it is off-putting.

Should they be? Well…

https://en.wikipedia.org/wiki/Carcinisation

I mean, that's the kind of abusive dynamic I'd expect from a horrible corporation: stringing along underpaid or unpaid interns for several years and refusing to hire them at the end of it without giving any actual feedback.

I'd argue that we're basically at the point where that _is_ what the de facto policy is, except without it being actually stated. There's a subsystem maintainer blocking any Rust code from being merged (even to be imported as a dependency from outside their subsystem) who said they will do "everything in their power" to stop Rust from being merged into any part of the kernel, and when people asked Linus to clarify whether he still thought it was viable to have Rust in the kernel, he said nothing. Hector made the infamous comment about social media, and _then_ Linus stepped in to say that we needed technical debate rather than social media brigading, which gives the not-so-great precedent that invoking social media was actually more effective at getting some sort of response than the technical debate that he actually said he wants. So now, the status quo is that someone with the power to completely block any progress towards actually including any amount of Rust in the kernel will presumably continue to do so, but Linus still is sticking to the line that we can have "technical debate" about it even though the outcome is predetermined to end in failure.

You're right that not everything has a clear and fast resolution, but given that the only possible ways for this to end other than just making the "no Rust in the kernel" policy explicit is either for Linus overrule the maintainer blocking any Rust code from being merged or every single patch containing any Rust code to be blocked, it seems pretty clear to me that the way things are now is just a slower, less clear version of the negative outcome, so having a clear and fast resolution with an undesired outcome would be far better. This seems like the real cause of frustration that Hector has; it's hard not to feel like the reasons for this path to "resolution" was picked over just admitting that it's essentially official policy that Rust isn't allowed for reasons that are ultimately purely social rather than technical. The correct resolution in my opinion would be if Linus said something like "regardless of my opinion on whether Rust should be allowed in the kernel, I'm not willing to overrule the decision of the subsystem maintainer in this case, so the current status quo will remain unless someone is able to convince people to merge things on their own". My best guess for why he didn't want to do that is that it would essentially paint a target on any maintainers refusing to merge Rust code, which is understandable but seems like it will just cause more frustration in the long run than simply ending acknowledging the reality of the current situation.

Given the online temper tantrum thrown by marcan, Ted Tso'o's comment seems totally reasonable, regardless of one's opinion of Rust in the Linux kernel.

He did not fail to address that concern. And then Ted shouted him down for 2 minutes such that he couldn't get 2 syllables in to respond.

I'm not disagreeing with anything you said, just curious who the "we" you're referring to here, are you a kernel developer or something similar?

Why would we assume that Ted repeatedly using strawman fallacies, bleating appeals to emotion and acting like a victim...all the while shouting people down...evidence of "acting in good faith"?

When you shout over someone like that you're nothing but a bully.

> he fails to address the concern that a change they introduce would error downstream and someone else had to clean up afterwards.

Because that "concern" was a strawman. It demonstrated that Ted either did not understand what the presenters were asking for, or simply didn't like others asking him to do something, because he's very important and nobody tells him what to do.

As has been exhaustively explained by others in previous HN threads and elsewhere: the Rust developers were asking to be informed of changes so that Rust developers could update their code to accommodate the change.

Ted loses his shit and starts shouting nonsense about others forcing people to learn Rust, and so on.

> but most of all the moderator unable to prevent the situation from exploding

When someone is being abusive to others, the issue is never "the people on the receiving end are not handling it as best they can."

Further: did it occur to you that Ted's infamous short temper, and his "status" as a senior kernel developer, might be why the moderator was hesitating to respond?

Imagine how Ted would have reacted if he was told to speak respectfully, lower his voice, and stop talking over others. Imagine how the army of nerds who think Ted's behavior was acceptable or understandable.

I had the same impression.

Why all this drama is 90% of the time around Rust people?

You have to encode your API semantics somewhere.

Either you encode them at the type system and find out when it compiles, or you encode it at runtime, and find out when it crashes (or worse, fails silently).

There are more breakage in rust due to the type-system-related semantics, but ideally a C dev would also want their system to break if the semantics aren't right. So this is a criticism on C..?

So following this argument, they don't want Rust because C falls short? Nonsense.

edit: The speaker did mention that they didn't want to force limited use on the base APIs, but that for a great deal of their usage, they could have determined fixed semantics, and make intermediary APIs for it. So this was not about limiting the basic APIs.

that's a very healthy and - I feel - correct attitude towards this kind of criticism. I love when wisdom comes from stupid places.

An honest "no one will be forced to use Rust in the Kernel" would be exactly what it says. A paltering reading could be "we want to make Rust the only language used in the Kernel but you won't be forced to use it because you can quit". i.e. if you are "literally shoving facts in someone's face" and they don't change then they might think you are not telling the whole truth, or are simply lying about your goals.

[1] https://en.wikipedia.org/wiki/Paltering

I've read and re-read this several times now and for the life of me I can't understand the hair you're trying to split here. The only reason to do semantic versioning is compatibility...

Yes: adding a trait to an existing type can cause inference failures. The Into trait fallback, when calling a.into() which gives you back a is particularly prone to it, and I've been working on a lint for it.

Semver, or any compatibility scheme, really, is going to have to obey this:

> it is important that this API be clear and precise

—SemVer

Any detectable change being considered breaking is just Hyrum's Law.

(I don't want to speak to this particular instance. It may well be that "I don't feel that this is adequately documented or well-known that Drop isn't considered part of the API" is valid, or arguments that it should be, etc.)

And yet the operating mantra...the single policy that trumps all others in Linux kernel development...

is don't break user space.

I think that's missing the point of the context though. When Linux breaks internal compatibility, that is something the maintainers have control over and can choose not to do. When it happens to the underlying infrastructure the kernel depends on, they don't have a choice in the matter.

While GCC with few basic flag will, in general, produce binary that cooperates with kernel, kbuild does load all those flags for a reason.

Since Rust doesn't have a standard, the guarantee is "whatever the current version of the compiler can compile". To check if they broke anything they compile everything on crates.io (called a crater run).

But if you check results of crater runs, almost every release some crates that compiled in the previous version stop compiling in the new version. But as long as the number of such breakages it not too large, they say "nothing is broken" and push the release.

> opposed to the idea of multiple implementations, which is plainly false, as evidenced by the link to the official blog post celebrating gccrs. Ted T'so is speaking from ignorance here.

Why use so strong words? Yes, there's clearly a misunderstanding here, but why do we need to use equally negative words towards them? Isn't it more interesting to discuss why they have this impression? Maybe there's something with the communication from the upstream language developers which hasn't been clear enough? It's a blog post which is a few months old so if that's the only signal it's maybe not so strange that they've missed it?

Or maybe they are just actively lying because they have their own agenda. But I don't see how this kind of communication, assuming the worst of the other part, beings us any closer.

What I really meant is the case where a method is added to a standard struct impl that conflicts with a user-defined trait.

For example, you might have implemented some trait OptionExt on Option with a method called foo. If now a method called foo is added to the standard option struct, it will conflict.

Rust, despite having Linus' blessing to be in the kernel, is still just getting rejected just because it's Rust, completely unrelated to any technical merits of the code itself.

Directly, "the thin blue line" expresses the idea that the police are what separates society from chaos.

It doesn't inherently suggest police are justified in acting outside the law themselves, though, of course, various people have suggested this (interestingly, from both a pro-police and anti-police perspective).

It seems obvious to me that the post was using this phrase in the sense of being a thin shield from chaos.

Rowan Atkinson had a sitcom set in a London police station in the 90s called "The Thin Blue Line". Are you under the impression he was dogwhistling about extrajudicial violence?

A more charitable interpretation would be “we’re the only line of defense protecting something good and valuable from the outside world, so people should give significant weight to our opinions and decisions”. Which, to be clear, I would still mostly disagree with WRT the police, but it at least doesn’t explicitly endorse corruption.

At least that's my understanding from the outside, someone please do correct me if wrong.

Conversely some codepath might use * but that is not in the interface, so your generic code works for numbers but fails for other types that should work.

That’s a sort of weird statement to make without reference to any particular programming language. Types are an amazing way to achieve static safety.

The question of how much safety you can reasonably achieve using types varies wildly between languages. C’s types are pretty useless for lots of reasons - like the fact that all C pointers are nullable. But moving from C to C++ to Rust to Haskell to ADA gives you ever more compile time expressivity. That type expressivity directly translates into reduced bug density. I’ve been writing rust for years, and I’m still blown away by how often my code works correctly the first time I run it. Yesterday the typescript compiler (technically esbuild) caught an infinite loop in my code at compile time. Wow!

I’d agree that every language has a sweet spot. Most languages let you do backflips in your code to get a little more control at compile time at the expense of readability. For example, C has an endless list of obscure __compiler_directives that do all sorts of things. Rust has types like NonZeroUsize - which seem like a good idea until you try it out. It’s a good idea, but the ergonomics are horrible.

But types can - and will - take you incredibly far. Structs are a large part of what separates C from assembler. And types are what separates rust from C. Like sum types. Just amazing.

> [..]Attempting to do so results in code that is harder to read and write.

> You have a choice between code that statically asserts all assumptions in the type system but doesn't exist, is slow, or a pain to work with, and code that is beautiful, obvious, performant, but does contain the occasional bug.

I don't think you are expressing objective truth, this is all rather subjective. I find code that encodes many assumptions in the type system beautiful and obvious. In part this is due to familiarity, of course something like this will seem inscrutable to someone who doesn't know Rust, in the same way that C looks inscrutable to someone who doesn't know any programming.

Right but the problem here is that RAM is produced in different units than storage. It seems strictly worse if your 16GB of RAM doesn't fit in your 16GB of storage because you didn't study the historical marketing practices of these two industries, than if your 16 GiB of RAM doesn't fit in your 16 GB of storage because at least in the second case you have something to tip you off to the fact that they're not using the same units .

The existence of other ARM laptops is irrelevant; the reason MBPs are so good has little to do with ARM. Yes x86 makes the processor frontend more complicated but this doesn't make a big enough difference to come close to accounting for how much better the MBP is than its competitors. I would guess the biggest factors are Apple's ability to buy the entire run of TSMC's best process node, and the fact that they have a high level of competence at designing CPU cores and other hardware. The instruction set the core uses is just not that important in comparison.

Even if you consider the hardware "tech jewelry", isn't it strictly better to have a way to run Linux on it instead of sending it to landfill? Seems silly to exclude a particular set of hardware from consideration for arbitrary reasons?

Even the OS-specific parts are at least permissively-licensed. OpenBSD is about as religious about "all new code must be under an ISC-compatible license" as it gets, and even they pull in Linux DRM/Mesa code for hardware graphics acceleration: https://man.openbsd.org/drm.7

IDK. I'm not familiar with mesa enough to know how portable it is. That said, I do know that it's primarily deployed on linux. An issue with portability is simply that when big projects like mesa are developed, non-linux environments are rarely developed (No clue, for example, if you can build mesa for BSD).

> Or do you mean that being on Linux makes GNU stuff easy?

Mostly this. I don't think, for example, those GNU tools will port over to redox. Building them targeting android is a snap.

Perhaps you’re confusing it with XNU? (Which is Mach merged with some BSD stuff).

So leading well known open source project is politics on a small scale and there will be a lot of people who want to hurt or manipulate you.

If you decide to become a public person and want to have fans and supporters then be ready to have haters as well.

In the context of a long-term good faith maintainer in what is clearly a constructive good faith email, assigning bad faith meaning to a simple phrase is in itself a bad faith action IMHO.

Or maybe it's not as "widely understood" to mean that?

Unless he got an extensive posting online on social media platforms I doubt he would garner much attention.

Dug up my old comment on the issue here: https://news.ycombinator.com/item?id=36972907

> The project itself is popular, but HN allows people to talk about the fairly compelling circumstantial evidence that Asahi Lina is marcan's alter ego. Per previous discussion, they have /home/marcan and /home/lina on the same box [0], have the same hostname [1], and have similar accents and speaking patterns [2]. Marcan is free to do this, but it's completely bizarre behavior acted out in public which is now impacting the actual Asahi project. Doing v-tubing under a pseudonym is one thing, but maintaining a sockpuppet contributor on a major open source project and pretending to interact with it is a giant red flag.

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

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

[2] - https://news.ycombinator.com/item?id=35238601

I think it's naive to suggest this would achieve anything when the platform is anonymous and he was based outside the US.

> Outside of that, just get used to be thrown abuse of all kinds.

This is far easier to say than to do. Particularly when you have a public profile as part of your work.

> If you get tagged by a group like that the more you talk about them the more you give them ammo.

Agreed but that still doesn't make it easy to ignore.

And if the other side is Kiwifarms and its associated offspring, the cops can't do anything at all. These guys are the utterly perfect storm - technically extremely competent but socially they're highly deranged narcissists.

And they explicitly chose against a UEFI interface like prior Macs, which would have actually enabled proper Linux support. Now you have poor people trying to reverse-engineer a Devicetree from scratch to get basic features to kinda work, emulating hardware features in software and working with no documentation from Apple. They "explicitly" chose to expose iBoot because otherwise you wouldn't be able to reinstall MacOS in a full data loss situation.

By comparison - reverse engineering an unsupported AMD or Intel CPU would at least give you some basis to work off of. You have UEFI as standard, ACPI tables provided by hardware, even CPU documentation and Open Source drivers to work off of most the time. Asahi shot themselves in the foot by trying to support hardware that doesn't support them back. You can argue that Apple was conspiring to help, but we have no actual evidence of that.

> Their SoC stuff dates in some components AFAIK back to the very first iPod SoCs in its design.

And none of those platforms ever got proper Linux support either. I love Linux as much as the next nerd, but it doesn't seem wild to suggest that Apple Silicon will never have feature-complete Linux support. And for many people, maybe that's okay!

I'm now thinking the solution is "no Rust in the kernel, but we promise to revisit in X years" (then if in X years the picture isn't clearer, revisit in X more years). As someone who greatly prefers Rust, it's unfortunate, but the alternative adds lots of complexity (IMO more than Rust's type system removes) and that's too big an issue.

Moreover, the would-be-contributors who use Rust can (and IMO should) unite and fork the project, creating a "Rusty-Linux" which would be the base for many distros like Linux is the base for all distros. If the fork ends up higher-quality than Linux, especially if Rust adoption keeps growing and C usage starts shrinking, in X years (or 2X, or 3X, etc.) Rust will be so clearly beneficial that nay-sayers will be overpowered (or even convinced), and Rusty-Linux will become Linux.

https://archive.is/uLiWXhttps://archive.is/rESxe

"Behold, a Linux maintainer openly admitting to attempting to sabotage the entire Rust for Linux project (...) Personally, I would consider this grounds for removal of Christoph from the Linux project on Code of Conduct violation grounds, but sadly I doubt much will happen other than draining a lot of people's energy and will to continue the project until Linus says "fuck you" or something. (...)"

"Thinking of literally starting a Linux maintainer hall of shame. Not for public consumption, but to help new kernel contributors know what to expect. Every experienced kernel submitter has this in their head, maybe it should be finally written down."

"Okay I literally just started this privately and the first 3 names involved are all people named variants on "Christ". Maybe there's a pattern here... religion secretly trying to sabotage the Linux kernel behind the scenes??? Edit: /s because apparently some people need it."

Social media is an amplifier of interpersonal problems, not a place to seek for a resolution for them - unless your intended "resolution" is to beat down the other side, the people you have to work alongside by necessity, via potshots from random strangers who hardly ever bother to inform themselves fully of the situation. That is never going to be a true resolution, and I think Linus, for all his faults, recognizes that and that's why he draws the line there.

It sounded to me like a list of "friends who want to get more involved, I'll let you know who to avoid". Then, I read the interactions that sparked that post, and I could totally understand the frustration from OP's part.

Linus being unwilling to take a real stand on maintainers blocking Rust just because doesn't really help.

If the C developers make it a "Them vs Us" thing, there IS NO ALTERNATIVE for the Rust developers.

Linus' reaction is quite literally the equivalent of a parent only punishing the loudest child, not the child that's been silently bullying that kid for months.

However... this is the same man who made a sock puppet V-Tuber account, and acts in every way like they are two people; even though they've accidentally on-stream shared the system username, shared they have exactly the same kernel version, same KDE configuration, same login, same time zone, even (if I recall correctly) accidentally making GitHub commits as the other person once in a while. He also did this on the Linux kernel mailing lists, where he still maintains the charade.

Point out that's weird, or that it's weird for a maintainer to have a fake persona as a walking female stereotype; and you're the one he shreds and mocks - while simultaneously not denying it. For me, I caught on immediately when I saw the supposed "hijacking" of his stream on April Fool's day, which was her first appearance; and stopped donating. I don't pay people to support stereotypes about women in STEM.

The original message I read (https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...) they quite explicitly said (verbatim): "If shaming on social media does not work, then tell me what does, because I'm out of ideas."

> It's a magnitude more professional than the extremely over the top and public emails that Linus shares

Since when do two wrongs make a right? I think it's perfectly fair to say Linus hasn't shown the best leadership here. But that doesn't excuse Marcan's behavior.

The problem with the brigading (which has been done by the Rust for Linux community) is that it invites these zealots into the conversation. It's totally inappropriate and not at all constructive towards a compromise.

Plus the stated goal of Rust for Linux is to enable people to write drivers in Rust, not to rewrite the whole kernel in Rust. Yet there are countless people in the wider Rust community that believe Rust is the future and every line of C code still in use should be rewritten in Rust. It's gotten so prominent that "Rewrite it in Rust" has become a meme at this point [2]. There are now many developers in other languages (C and C++ especially) who reject Rust simply because they don't like the community.

[1] https://www.phoronix.com/forums/forum/software/general-linux...

[2] https://goto.ucsd.edu/~rjhala/hotos-ffi.pdf

In fact, he said that as his very first reply to that thread:

https://lore.kernel.org/lkml/2b9b75d1-eb8e-494a-b05f-59f75c9...

>Everything else is distractions orchestrated by a subset of saboteur maintainers who are trying to demoralize you until you give up, because they know they're going to be on the losing side of history sooner or later. No amount of sabotage from old entrenched maintainers is going to stop the world from moving forward towards memory-safe languages.

There are _already_ dozens of hobby OS projects and embedded groups doing systems work in Zig. Everyone knows Zig is a systems language. It doesn't have a chip on their shoulder.

Nothing. That's why this was said:

>> *There's a deeper issue* in open-source culture where harshness and gatekeeping drive away passionate contributors.

It's separate gatekeeping.

I entertained getting involved in the kernel for about 3 days, in college. The process is so complex, I just went on to do other fun things. The drama will turn off others. Organizational apathy is much worse, imo. I have quit jobs for this reason and that was when I got paid to stay.

Linux said no brigading. Hector resigns twice and in the second time, despite saying he wouldn’t elaborate on Rust vs Linux, proceeds to blame Linus and start another social media brigade.

From the horse's mouth (lkml; Hellwig's headers chopped for brevity):

On Thu, Jan 16, 2025 at 02:17:24PM +0100, Danilo Krummrich wrote: > Since there hasn't been a reply so far, I assume that we're good with > maintaining the DMA Rust abstractions separately.

No, I'm not. This was an explicit:

Nacked-by: Christoph Hellwig <hch@lst.de>

And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).

---

Hellwig was abrasive and unreasonable. But there is no need to perpetuate, repeat, and repost absolutely one-sided, self-serving misrepresentations of the words he used.

You don't need to paraphrase. You don't need to guess. You don't need to distill or simplify.

He wrote English so we could read it; stop paraphrasing. It's unhelpful at best and nefarious at worst.

Edit: I think it's very telling that there is a crowd here that would literally downvote the actual quote. Actually it's more sad than anything.

The amount of drama that this has created for Linux when the entire situation was being handled in a non-dramatic way is staggering.

At its root, nothing about the entire situation had anything to do with marcan anyway and yet somehow he has focused an enormous amount of attention on himself and negative opinions at those he disagreed with. He habitually does things that draw attention to himself (in situations that aren't about him specifically) and then points to _any_ form of criticism he receives and cries harassment.

Of course anyone reasonable would never want to work with him.

Jesus, I wouldn't want to work with either of you...

that sentence carries a lot of weight. How many millions of users are left in the dust? Last time I touched a PC, the USB-C port could charge the laptop, unless the battery was empty. Then only the barrel plug could be used. It. was. infuriating.

It’s a poor choice of words for such (relatively) public communication.

Apple is selling a custom CPU core that has no driver support for anything but XNU with a BSD userland. It doesn't support UEFI, it depends on Devicetree bindings and would demand constant updating and support to render a "first class" Linux experience. Once again, anyone with a protracted interest in staying supported by upstream Linux should not be using a Mac and praying the community cares enough to make it good. Apple knows it's a novelty, and they're not going to take it seriously because that's just what they do. MacOS and the App Store is profitable, Linux is not.

Define "a lot" and we can get closer to a common understanding.

Out of curiosity what are his political views? It has been mentioned a couple of times here already and it seems to be part of the story.

As someone not in the know, would you mind elaborating.

Is this about Marcan’s outspoken support for transgender people? If so, why not simply say that in your comment, rather than framing it in such vague terms?

The challenge is not dictating from high above some criteria; the challenge is discovering the criteria that will let the Linux project continue development as well as can be arranged. This is why you'll hear Linus say it's a learning experience, and not just make proclamation of how things shall be (at this stage).

Did you read the rest of it?

Sure Apple being not as great to develop drivers, but ~99% of the article is about displeasure working with Linux maintainers.

EDIT: Here is the breakdown by paragraphs.

    | Paragraph # | Tone                                                                       |
    | ----------- | -------------------------------------------------------------------------- |
    | 1           | History recap                                                              |
    | 2           | History recap                                                              |
    | 3           | mentions Apple and M1 in positive light.                                   |
    | 4           | Mostly positive, slight negative towards Apple not being having good docs. |
    | 5           | Negative Linux kernel development (upstreaming)                            |
    | 6           | Negative user focused                                                      |
    | 7           | Negative user focused, complaints about M3/M4 support.                     |
    | 8           | Negative user reviews                                                      |
    | 9           | Money troubles regarding support.                                          |
    | 10          | Linux maintainers, mostly negative                                         |
    | 11          | Unknown 2024 event                                                         |
    | 12          | Negative about users (demanding more features and support)                 |
    | 13          | Stress about Kernel development                                            |
    | 14          | Negative about Linux kernel development roadblock                          |
    | 15          | Negative about Linux kernel development (Linus leadership failures)        |
    | 16          | Positive about Rust                                                        |
    | 17          | Negative about Linux kernel development (Why Rust can't wait)              |
    | 18          | Negative about Linux kernel development (downstreaming)                    |
    | 19          | Negative about Linux maintainer (thin blue line)                           |
    | 20          | Negative about Linux kernel maintainers (two faced)                        |
    | 21          | Negative about Linux kernel maintainers                                    |
    | 22          | Negative about Linux (disapointment in refusing invitation) and Linus      |
    | 23          | Negative about Linux maintainers (being corporate)                         |
    | 24          | Negative about Asahi, and dreading to turn on Apple                        |
    | 25          | Negative about burnout                                                     |
    | 26          | Resignation                                                                |
    | 27          | Positive about Asahi Linux team                                            |
    | 28          | Hiring proposition.                                                        |

I was wrong about it being 99% about LKM but it's more accurate than saying 50% of issues are Apple.

* "bad actors" links to https://en.wikipedia.org/wiki/Kiwi_Farms

* "destroy lives" links to https://en.wikipedia.org/wiki/Kiwi_Farms#Suicides_of_harassm...

While you may be correct that initial "trolls get flagged", the statement on the Asahi site agrees that while the initial comment may be flagged & killed, the other comments in the subthread are still indexed, visible & tend not to get moderated/flag:

"Unfortunately, when a comment is flagged and killed, its child subthread is not. [...] but the reduced moderation activity enables abuse to continue. Although you don't see those threads, search engines do."

Based on other remarks about the content of such subthreads it seems surprising to claim that follow-on comments are made by "honest nice people".

I'm as much of a fan of adverbs as the next person but using words like "categorically", "extremely" & "patently" doesn't seem to leave much room for nuance of interpretation when written by someone who I'd have assumed was a third party observer?

While I could understand someone describing JWZ's HN-tailored "banner" (I wouldn't suggest researching this if anyone is not already familiar) gauche and immature, it feels like somewhat of a stretch in relation to a plain text message who last sentence starts with "Please".

Turn the other cheek. Ignore it. It's 2025 we're learning lessons from USENET all over again and having to reign in the over-sensitive, disregulated behavior of some people.

I'm gay, on the spectrum, and my wife is trans. What certain people in "my" community do from places of relative comfort makes life for those of us in more moderate / conservative-leaning places worse. The screeching from our community [2] has turned our little demographic into a major culture war topic, and it's all because of the bad attention and friction you manufacture.

Conservatives let LGBT and trans issues slide for over two decades of my adult life. But by being loud and attempting to silence them -- by harassing them -- you've become the nail that sticks out and have now created a tidal wave of opinion against us.

It's easy for some European or SF trans person to call for universal outlawing and censoring of speech, but you have to realize your message is being read all over the world. It's interpreted by an overwhelming number of people as attempting to memory hole conservatives and flush away their culture.

Simultaneous to your harmful messages, folks are also being inundated with social media rage/engagement bait to make them think liberals are literally attempting to destroy and annihilate conservatives [3].

Your message adds weight to this perception, and all you accomplish here is making the majority of voters angry at us. It even turns moderates and would-be supporters sour.

I hate that you represent me by association and think that this is acceptable behavior.

As another anecdote, when I talk to my friends about Rust, the subject of "drama" frequently comes up. Why is that? Suddenly my work becomes harder for an entirely unrelated and unmerited reason. That's just me as an LGBT person - imagine how straight people feel.

We shouldn't have to keep reading about this over and over. It's orthogonal, childish, dysfunctional behavior.

Take one more look at that loud disgusting banner on the top of the Asahi page. That's neener-neenering in front of everyone. Even the moderates you hope to be your allies. Please, for god's sake, put yourself into different shoes. You're asking them to do it for you, but it's your turn.

I think you'll see that your behavior is also harassment.

Please calm down, slow down, and behave like adults. Not everything warrants a response or attention. Chances are, it'll just go away and get totally ignored. When you engage, you shift the conversation and bring yourselves down to their level. You create a firestorm of drama that everyone watches like a burning wreck.

Stand above that.

[1] I only wanted to talk about the very public, inflammatory resignation and the immature handling of this by certain parties.

[2] eg, folks whose entire personality is to harass people on social media: https://www.tiktok.com/@lillytino_/video/7295890626539687210

[3] Just look at this image and how religious people take it: https://danolinger.com/2018/11/01/responding-to-persecution-...

"Everyone else is a bully, but not me - I'm just trying to raise awareness."

I can dig up many such examples, but I suspect the response would be, "of course that's not moderated" because this community has a different set of values than some others.

Moderation is always an editorial action, and as such we tend to view it as strong when it aligns with our own values and weak when it doesn't.

There were a number of remarks on the prior thread by people making conspiracy claims, harassment, insults etc. Some of them get flag-killed, some just down voted but ultimately the users on the site still remain.

Of course I'm not one to be above such a thing in terms of insulting people occasionally but HN is really quite permissive in terms of what you can post and get away with. It takes consistent and repeated bad behavior to get a warning, and even more to get banned. And if you're an expert in being politely venomous you can get away with even more. That's why the outside perception of HN tends to be a lot worse than the inward one.