Hacker News new | ask | show | jobs
by curtis3389 485 days ago
The Rust for Linux politics mess should be laid squarely at Linus' feet. He's the BDFL. He approved adding Rust to Linux, and he massively failed at communicating what that even meant. If he wants Rust in the kernel, he needs to kick some maintainers in the ass and get everyone aligned.
4 comments

To play (BDFL's) advocate - Linux is an -enornous- project. It's not physically possible for any effort to be unilaterally directed. Linus does not personally maintain the whole thing, it's just not possible. So he has maintainers under him who are in charge of the subsystems - the implication being that he trusts their judgment and technical expertise. There's no other way the system could work, really.

Linus's position, as far as I've heard and ascertained, is that introducing any language into the kernel is going to require case-by-case and subsystem-by-subsystem analyses. He's not going to reject the language wholesale, but at the same time it's impossible for him to wholesale mandate its adoption. "Kicking maintainers in the ass" sounds great but nothing is ever that simple.

I think this is an important point. People believe "dictator" means "complete control" when instead "dictator" mean "authority to make any decision." The difference is exactly what you say, that you still have to rely on the hierarchical structure and trust that your "underlings" are making the right decisions. Complete control doesn't scale very well and even a small project or team has many moving parts and the only way to have full control is to be involved in every part. With scale, rapidly comes the necessity for trust. There's only so much time in a day, and only so much can be done in an hour. Damned physics, always getting in the way.
Why do you assume he either wants it or doesn't want it?

The only way I ever interpreted his actions so far is he's willing to allow those who want to try.

And I see nothing unreasonable and no failure in that. It is a hashing out process, in process.

"If he wants" != "he wants"

"He approved" != "He wants"

Either he failed at communicating, or he does not care. Reading the recent thread/flamewar on R4L and DRM I wonder if he was somewhat pressured to accept Rust but does not actually care. If you were the leader of a project and explicitly authorized a sub-project, would you tolerate a maintainer undermining it?
FWIW, there are plenty of backchannels through which discussions about this stuff can be had that aren't the public mailing list. My limited understanding is that those discussions have in fact taken place and the R4L people aren't concerned about things working out eventually.

However, I do wish he would say something publicly, so that the internet peanut gallery doesn't fill the void with negativity. It doesn't exactly help attract more interest in the project.

And if he doesn't want it in the kernel?
I don't know enough to agree or disagree with the person you're replying to. But I assume the logic would be that if Linus doesn't approve then he should have shut the discussion down long ago or at least do it now without half measures
> then he should have shut the discussion down long ago

It's interesting that people expect Linus to simultaneously chill out and be more inclusive while at the same time acting like a dictator over the entirety of the project.

In any case, perhaps it's worthwhile to remember where it started, and what the attitudes were at the time [1]. It was an experiment. Experiments sometimes fail or reveal themselves to not lead anywhere useful. The choices were to let that experiment happen on the actual kernel or force the rust people to fork some version of the kernel and instantly be left behind.

It clearly wasn't an easy choice and I can only imagine the uproar from the rust community if he then did what you suggest today. So, that leaves us with the question, what if he's decided it's no longer worth it? What then should we do with a mostly failed kernel experiment?

[1]: https://www.zdnet.com/article/linus-torvalds-on-where-rust-w...

> It's interesting that people expect Linus to simultaneously chill out and be more inclusive while at the same time acting like a dictator over the entirety of the project.

It's not particularly interesting that different people have different expectations on different issues

It's interesting that you moved the goalposts to an entirely different point. I'm clearly talking about the overall "community," which whether you care about it or not, has been used as a point to successfully force Linus' hand before.

In other words, there are clearly politics involved, so perhaps that should be taken into consideration before making a blithe point about a complex human organizational issue?

You can be decisive and inclusive without being a prick who is personally targeting developers and publicly demeaning. Linus was like that. No sane developer wants that. A true inclusive environment also requires leaders to tell rowdy maintainers calling people "cancer" to know their place and watch their tone.

It is not really a good experiment in technical qualification nor in developer collaboration, if the leadership lets individuals to constantly blockade work, isn't it?

> personally targeting developers

How else would you target them? You can disagree over tone and scope but this is an open source project with an open contribution model.

> publicly demeaning. Linus was like that. No sane developer wants that.

Show me someone who hasn't been turned to this behavior over frustration. In isolation you can always find this from a leader what you should be concerned with is context and persistence. While it was occasionally over the top the majority of the time he was perfectly "sane."

> A true inclusive environment also requires leaders to tell rowdy maintainers calling people "cancer" to know their place and watch their tone.

This is open source. What exactly is "their place?" How much time should one dedicate to policing tone? Isn't that personally targeting people but in a different direction?

Which is part of my point here. Previously we just developed and ignored Linus' hot head behavior. This push for a vaguely defined "truly" inclusive community is what I feel led Linus into the mistake of allowing Rust into core.

> if the leadership lets individuals to constantly blockade work

What if the work just isn't very good or is counterproductive to the project as a whole? What if there is no consensus on this point? How much time should one dedicate to building consensus?

archive.ph/rESxe

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

https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...

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

Hector Martin went way beyond being a "prick". And Linus Torvalds told him to stop it.

Have you considered that the problem may be the people that are making "hall of shame" lists of people and doing social media brigading?

Worsening matters, Steve Klabnik (major Rust community figure, has run @rustlang, primary author of the Rust Programming Language Book, former Rust Core member, and moderator of r/rust), have been busy here and on reddit making excuses for Hector Martin. What kind of community is the Rust community?

I have never moderated /r/rust.

I haven’t been involved with the Rust Project for years, I speak only for myself.

I said that I feel for Hector, he’s clearly hurting, and that I hope he feels better. I’ve said I don’t want to pass judgement on if what he did is right or wrong, because I’m trying to stick to facts here. I’ve said that I don’t think what he did was particularly effective.

That’s not making excuses. Hector’s actions aren’t the main point of this story. It’s not even his patch!

>rowdy maintainers calling people "cancer"

Where was this done? In the recent mailing list, the maintainer never called people cancer, he said

https://lore.kernel.org/lkml/20250128092334.GA28548@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).

Not referring to people. And many developers would agree that a multilanguage codebase can easily end up becoming a nightmare and pure cancer to maintain, whether or not Rust is one of those languages.

Another C project has not had good experiences with all interop attempts, pulling the plug on interop with one Rust library, while keeping support for two other Rust libraries.

https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/

>Before this step, we supported three different backends backed up by libraries written in rust. Now we are down to two: rustls (for TLS) and quiche (for QUIC and HTTP/3). Both of them are still marked experimental. >These two backends use better internal APIs in curl and are hooked into libcurl in a cleaner way that makes them easier to support and less of burden to maintain over time.

He needs to say so before wasting everyone's time
I remember seeing an interview where Linus said that at one time, he rejected a contribution and felt bad because he wasn't clear enough in that he didn't wanted that.

He said he now tries to be very clear about what he doesn't want. So I guess he is ok with how things are going, otherwise, we would be likely to see another of his famous rants.

Exactly. The recent DRM issue was about who's time would be wasted. Rust is either happening, and they are wasting time by not having proper bindings, or it is not, and all the drivers written were a waste of time. In either case, the discussions around it are already a waste of time.
fork, runix? (/s?)