Comment by gary_0

I think the response from Dr Greg to Linus, https://lore.kernel.org/rust-for-linux/20250207121638.GA7356... adds some interesting insights.

There seems to be some issue with unaccountable maintainers, and that’s a problem for innovation. If you can’t even get to the point of “technical debate” (we aren’t interested, sorry), then what hope innovation?

These are “people problems”, and there are no easy or good answers, but it doesn’t mean we should through our hands up and consider things “unfixable” either.

https://archive.is/rESxe

This is a recurring pattern I see with drama in some open source communities, where people measure others using yardsticks they themselves don't live up to. People can't post stuff like this while accusing everyone in the vicinity except themselves of bad behavior. Choose one.

I think this is an important data point, too:

Gunthorpe [nvidia]: https://lore.kernel.org/rust-for-linux/20250130154646.GA2298...

Basically, there is concern that even with a declaration that Rust-for-Linux devs will maintain this (and potentially every other) cross-language API translation layer file, the demarcation point between C and Rust isn't sufficient, and is causing C developers lag or headaches by having PRs rejected because of Rust-side failures. I don't see how that can be fixed without wholesale buy-in to Rust of enough kernel devs that they can fix whatever Rust problems are created by C API changes. Or Linus will have to accept PRs that break Rust-enabled builds. The R4L devs, by themselves, don't have the bandwidth to keep up. Even if they can rapidly fix problems, that adds potential friction to every C API change.

Hellwig may not be communicating in a good way, but he might be right, unfortunately. Linux may need to stay as a C-only codebase until an AI language-translation tool is good enough to do things like maintain the Rust API translation layer itself. Or until basically all maintainers learn and accept Rust.

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

That's just manipulative. Maybe it's just a moment of frustration and they'd take it back eventually, but blackmailing people with social drama is not cool. That's what X and Reddit is for.

> Rust folks: Please don't waste your time and mental cycles on drama like this [...] they know they're going to be on the losing side of history sooner or later.

That sounds very cult-like, doesn't it?

When i was the focus of the rust community, and trending #1 on HN, i simply deleted my repos and disappeared.

Some people in that community reflexively see a conspiracy or invoke the CoC or use whatever other non technical tools they find to derail the discussion.

It's not even that they're always wrong or that I directly oppose the culture they want to have, but the shotgun blast of drama that this comes with is just so much effort to navigate that i decided to just never contribute to rust again.

[flagged]

I feel the exact same. Marcan has done amazing work, and his random blog entries etc have saved me hours of debugging time in the past. But jeez, it is really painful to see him say absolute nonsense like "If shaming on social media does not work, then tell me what does, because I'm out of ideas." - he has gotta Stop Posting and keep those kinds of thoughts away from his keyboard.

I've said this before, but the rust community really seems to attract the most toxic and drama-thumping types as their icons. I'm not really sure why such types are drawn to it.

Like others have mentioned it was really the hypocrisy of this guy that made me side against him, not so much whether he was right or wrong.

He's a known, certified, card-carrying obnoxious rebel coming pretty close to violating a "Code of Conduct" himself pretty well every other day then his beef with Christoph about wanting to "mix languages" (C and Rust, of course) and Christoph said "I'm maintaining it and I'm not doing it, it's like a cancer" (I'm paraphrasing and he was notably not talking about Rust itself but "mixing" C and Rust) then Martin exploding and screaming that Christoph said "cancer" and that he had violated a Code of Conduct. Please.

A serious case of the pot calling the kettle black.

[flagged]

> > The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.

If a maintainer of a major subsystem has those objections, it is a good chance to try to convince them otherwise.

If something is not clear, ask him to elaborate.

But blackmailing with a social media campaign is not productive. Even more it’s anti-productive. This just adds to rust=drama=stayaway feeling.

It's not without merit. Two languages is an extreme cost in complexity compared to one, and you have to be a deep expert in both to fully figure out anything on the boundary.

Perhaps rusts potential benefits are worth it, but it's certainly possible to disagree with that

Where? Because "keep the wrappers in your code" and "do that in your driver so that you have to do it instead of spreading this" doesn't sound like that.

Are you referring to Hellwig saying, "No rust code in kernel/dma, please."? I took that to mean just dma.

Just curious. Why can't the wrapper be an independent library outside of the DMA infrastructure? It can still be used by all rust drivers.

I think Hellwig is against moving the wrapper into the DMA project that he's forced to maintain it.

I am aware. Doesn't mean it's not an option, or even a bad idea. Or maybe there is a third option; I don't know.

By the way: I don't agree with Hellwig, insofar I can judge things, I'm just saying his opinion is valid, and that "Linus agreed on Rust, so therefore we can merge this patch" is not really a valid argument.

And there is no issue with that. What's this pervasive need to spread Rust to every part of the software space. It's just becoming a little too pushy and desperate

Imagine if i would take a screenshot of your post and repost it to the fediverse, with a caption like "Look at this dude, he has the same delusions as marcan". Replies go like "omg peak HN again"

Would you consider that a healthy way of disagreeing? I think if i actually did that, you would probably feel like shit and be more empathetic to the harm that marcan causes.

What an absolutely awful statement about one of the most successful community projects ever. Direction usually comes from the community and the maintainers just steer it. Little in the kernel comes from maintainers saying "let's do X" and community members implementing it

Perhaps you could fork the kernel and start a better community?

All of those inventions were invented at least a couple years before the Apollo program.

[flagged]

Some of Linus's past messages came across as needlessly aggressive and insulting. There really was no practical reason for that and just served to alienate contributors, and it came across as unprofessional.

You can be a strong, opinionated leader and still be kind (or at least neutral) to the people you're working with.

A good leader is someone who can deliver hard messages while still keeping your team inspired. It doesn't do any good if the people working under you feel like trash.

It's the difference between telling a contributor "you're an f**ing idiot" vs "this code isn't up to standards, try again". Same message, but completely different impact on your team.

Bad faith arguments like this don't really belong on HN. Please represent the substance of your argument accurately rather than debating this inaccurate strawman argument.

You seem to be implying that he had nothing to apologise for, and that abusive behavior is an acceptable part of strong leadership.

It’s sad that this even needs to be called out.

Yep, that happened. "Forced to apologize" essentially describes it.

A quick sweep through recent messages in LKML shows that there's a healthy return to form for him, maybe with less curse words, but as succinct and impactful as it should be nonetheless.

There is an LWN summary of it out already:

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

I love Linux and have no preference to either C or Rust, but locking Linux in to a programming language that was designed in the relatively early stages of computing will lead to Linux dying in the long term.

There will be fewer and fewer new C programmers with people instead taking up newer systems programming languages like Rust or Zig.

I agree. If it wasn't for the memory safety meme this would have never been considered.

Then make it so, so that we can RWIR, and Linux can fade into the sunset with Linus.

Not "religious" (even though I've used the word "zealot" right here) but rather political or social.

those are still technical merits/non-merits, albeit on the project management level.

The rust doesn't write itself.

Nothing in Linux is "here to stay", it always has to demonstrate its worth, and what it's worth is depends enirely on the technology and its developers, not Linus.

> by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers

And let's not be obtuse, some of those subsystem maintainers are staunchly opposed, so "it's up to them" is obviously an indirect way of saying "no rust". I don't blame those maintainers for balking at a whole new very different language, but Torvalds has a choice of telling them either "suck it up, buttercup" or "I hear you; rust is gone". Instead, he's just letting things fester.

> that's a strategy decision that should not be up to any subsystem maintainer

So people are not allowed to hold positions and argue for them in public, or take actions that align with that position?

> I don't believe that was what the rust guys thought they'd be signing up for

It's not like there wasn't any existing precedence with C++, and many of the arguments I've read seem consistent with that history.

> that's a decision that should be up to Linus, by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers.

And that's a perfectly resonable position.

> Hellwig's argument was nothing more than "there shouldn't be a second language in the kernel".

Which is a valid viewpoint. Let's not pretend that's not a technical argument.

Having different technical views from yours isn't a crime, legally or morally.

> And Linus has already approved Rust in the Linux kernel, so what's the problem?

As an experiment, as clearly stated in the kernel docs. It's still up to the whole community to figure out how exactly to proceed with it.

https://docs.kernel.org/rust/index.html

https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...

Just read the email.

With a project as massive as Linux I doubt you can ever assert "there are 0 kernel devs who want [something]"

https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-2936148...

There is an Indian fork of the Linux kernel that has C++ drivers:

https://bosslinux.in/bossmool

Typo. I meant C.

And I still think the culture clash angle should be taken more seriously.

An accomplished senior C dev can find good jobs writing drivers or microcontroller code more easily than starting over into a junior rust dev and being talked down by whomever joined the rust wave before them.

(which would be even more aggravating if the C dev is doing it since before the rust adopter was born).

> C++ has been dead and buried for years

LOL, lmao even.

It wasn't going to work without ample support within the kernel.

At a minimum, all prominent developers would have to be convinced and ready to put a lot of effort into this.

As this was never the case, Linus should have put his foot down with a clear No, thus preventing the conflict and overall waste of resources we're seeing.

Rust devs would still be able to fork or otherwise (much better idea imho) work on their own kernel, hopefully with a much better design.

Redox is doing this, with a microkernel multiserver approach.

And look where it got us!

The Rust project started 15 years ago, and spent a decade growing userbase, library ecosystem, and proving that it's a serious language that's here to stay (which some C maintainers still don't believe).

We don't have a Rust-killer language yet. The closest one is SafeC++ (Circle), but it's still a single-dev proof of concept, and the C++ leadership firmly rejected it. Zig went in a different direction. Swift is adding Rust-like features, but it's unclear if that's going to be compelling. Ownership and borrowing is spreading to Mojo and Ocaml, but they're not kernel languages.

Even if there's a Rust-killer tomorrow, it will go through the same growing pains of rewriting everything and being treated as just a temporary hype. It will have to prove why use the new language instead of Rust that's already here, and had even more time to establish itself.

    > If you wait long enough a Rust competitor will gain traction.

Are you implying that a fork of the Linux kernel will win? I doubt it. The Linux kernel is over 30 years old and has resisted multiple attempts to fork. In all cases, it was the winner. What is different this time?

I guess you make a living writing zero day exploits?

> Go codebases? Switching to Rust so you can what exactly?

The way I heard it, the Rust's type system, async implementation(s), they way lifetimes just keep propagating once you start, and its macro languages are way more engaging, thus Rust must be superior.

That's a false equivalency. All of those languages are integrated through strong semantic and concrete abstractions (e.g. file system I/O or GCC interfaces) that evolve, if at all, very slowly. Some, like assembly, are necessary concessions, and are exceptions that prove the rule--developers prefer GCC builtins if available, for example.

The problem with Rust in the kernel is that the kernel has historically eschewed strong internal abstractions. The Linux kernel has no principled abstract architecture in the same way that Windows NT does; it has evolved very organically and even some of the most foundational subsystem APIs regularly see refactorings that touch almost every corner of the kernel.

The latest dispute (if it could be called that) regarding Rust was Rust building abstractions around the DMA interface. There's nothing wrong with this, per se. For Rust it's a necessary chore. But when you build complex abstractions atop something, you're either ossifying the interface or building a sand castle. If we're being charitable, some Linux developers felt like this was pressure to ossify the existing abstractions. Rust developers, OTOH, promised that they'd take full responsibility for any future refactoring, implicitly admitting that they understood they were building a sand castle.

How do you bridge that divide? Because of the lack of hard architectural line drawing in how Linux is developed, the norm is that both redesigns and refactoring are in many respects highly cooperative (notwithstanding the bickering and friction). A subsystem maintainer contemplating a redesign takes into consideration the burdens on other users, and how a redesign might be incrementally rolled out, if at all. Conversely, users of interfaces know--or should know--to take into consideration future potential changes in an interface when relying on an interface for their subsystems. It's a constant back-and-forth, give-and-take, but also messy and chaotic. Transparency in source code is key--this kind of development would never work in commercial projects across binary interfaces. Yet in important respects that's what the interface between C and Rust is like--opaque--especially when developers on one side aren't intimately familiar with the semantics of the other and how they translate, if at all, across the boundary.

Now here comes Rust, which has spent years putting into place the infrastructure just to get some drivers going. Rust as a language demands careful architecture and line drawing. It's no surprise that much of that initial infrastructure effort, excluding the build, was expended on building towers of abstraction. Refactoring can be painful in Rust when it involves very low-level changes in semantics (the kind that are common in kernel development), and while there are tools to help address that, they don't work well, or at all, outside of Rust. There's a huge impedance mismatch between Rust and historic Linux kernel development. In user land, developers' experience is that Rust is relatively easy to interface with C libraries. But that experience is primarily interfacing with public APIs, those public APIs have always been quite stable, and user land libraries (at least the good ones) are designed to be, as much as possible, blackboxes from the outside. Abstractions that leak tend to be fixed abstractions, like file descriptors, etc, that are typical for the environment and rather predictable.

That situation with user land C FFI is utterly incomparable to how interfaces evolve in Linux. The clash between these worlds, at both a technical and cultural level, was inevitable. Heck, it was evident from day 1. This doesn't make either side right or wrong, and I'm not trying to suggest that the Linux developer community can't figure out a path forward. But it's a difficult problem on many levels.

No, I feel this way about the Linux kernel.

>Isn't this the guy that blocked HackerNews links to the Asahi Linux homepage because the moderators wouldn't do his bidding?

Yup, that was Hector Martin (marcan) as well.

I don't know anything about him, but it seems like he has a pretty negative view of Reddit users as well:

> Added some clarifications in bold, because Reddit users having enough reading comprehension to understand what Christoph said and why it's exactly* what I described with other words is apparently a Lv.100 impossible challenge boss.*

https://web.archive.org/web/20250206022420/https://social.tr...

[flagged]

Throwing up a call to arms in unrelated discussion venues with the purpose of drawing people to the original venue, or to harass the original participants in other venues, would count though.

i.e. no one would consider it acceptable for me to go on reddit and start ranting about a Hacker News username, link the thread and argument, and imply either implicitly or explicitly that they should go and join the argument.

Martin has a habit of polarizing and aggregating discussions too much. It is not healthy at all. Linus is definitely correct, especially since he has the history of doing the same and he has tried to fix it.

Imagine if the discussion would have started with an article like this. Patch probably would be merged already:

https://lwn.net/SubscriberLink/1006805/f75d238e25728afe/

> "using social pressure to influence decisions" is so general that it could apply to just any discussion

Not really. It's one thing to discuss these things directly in the proper channels, namely the mailing list, but it's another thing entirely to make childish, passive-aggressive posts on not-Twitter about how anyone who disagrees with your actions is trying to "sabotage the project" and trying to rally your followers to cancel them on the grounds of "Code of Conduct violations" (once again proving that "Codes of Conduct" are little more than tools to enable cancel culture).

He himself acknowledged the fact that what he did was childish and embarrassing by deleting his entire Mastodon account.

The difference is between posting "ugh, having a hard time with someone on a project, they're blocking this merge and I don't think it's for a good reason" and literally starting your post with "Behold," linking directly to a mailing list post, and misrepresenting the other person's objections as "sabotage."

Yikes, re that fedi thread.

No, it is not the entire point. No one is really doubting whether you can write a driver in Rust, C++ or Swift. The whole experiment is whether you can slowly move in to existing mature kernel subsystems without being too disruptive.

> It's a failure of leadership to not intervene when discord threatens the group. He should weigh in, or make sure that someone else who has mutual trust weighs in.

Nothing in that particular "drama" threatens Linux kernel maintainers as a group. Multiple solutions were proposed, like just sending the change directly to Linus bypassing Hellwig or copy/pasting the code to each individual driver for now. Marcan having public meltdown in that thread probably makes option 1 no-go though and doesn't improve R4L standing with the skeptical group of maintainers.

> In youth sports, something similar happens when referees fail to call fouls on rough play. Players naturally test the limits and then others recognize the lack of protection and retaliate until it gets really out of hand.

For better or worse the social contract in LKLM is not like what a lot of Rust people used to where you come in with furry avatar and pronouns in your profile, then cry for mommy to enforce CoC on first signs of conflict. Basically, extending your analogy, you don't come to an American football match expecting the referee to enforce basketball no-contact rules.

> In youth sports, something similar happens when referees fail to call fouls on rough play.

This is actually not limited to youth sports, you can even see it happen with professional athletes.

It's a very common human reaction when participants feel like the rules aren't getting enforced. For all ages. Which only reinforces your point.

You can't rely on an authority to step in every time some disagrees. People need to resolve their own conflicts rather than yell until bailed out

There's C-- (and a few other similar efforts) that are basically C++ with a lot of features forbidden/disabled. I suspect Horizon OS also does this.

I'm not sure if we can still call it C++ in those cases. C++ is more/less a superset of C: we need to know what style of "C++" we're talking about.

> he is still beholden to all those downstream developers that rely on the Rust DMA wrapper's functionality, because if he breaks their code, he knows it'll cause a shitstorm.

It is the explicit policy of the project, and was repeated in the thread, that the Rust folks are solely responsible for fixing any breakage. There will be no shitstorm.