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.
If you start with the assumption of a), there are no valid technical challenges to merging it. It's just better for everyone. Before Hellwig put his foot down as "not merging because rust sucks", he made a series of technical arguments against the patch, which were all transparently bullshit. It was those arguments that really raised such a furor, instead of all the other ways some C devs have disdained rust in the kernel in the past, because they were obviously made in bad faith. And when he was called out for them, he just went full "no rust in kernel".
He didn't say this at all. He explicitly and repeatedly said he has no problems with Rust as a language.
And you can't just assert "there are no valid technical reasons". Just because you don't agree with the objections, or even think they're dumb, doesn't mean you can just dismiss them and start ascribing bad faith motives.
Okay, sorry. He just said there should be no rust in the kernel.
You can ascribe bad faith motivations when someone presents technical objections that are already fully answered in the patch that was submitted, and when this is pointed out, they admit that, but don't retract their objections.
The original objections are specifically not a case of differing values or design ideas. They are nonsensical, the equivalent of 1 = 2.
That's also not what he said; it's "no Rust in kernel/dma". He pretty much explicitly said it's okay for drivers to do their thing in Rust, but with their own wrappers. You can consider that dumb, but you can't shorten that to "no Rust in the kernel".
And "I replied to your objections, therefore the matter is settled" is arrogant beyond belief. People can disagree, you know, because they have different priorities, different preferences, different perspectives, etc.
> Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. 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.
Have you actually taken a look at the patch?
There was NO RUST CODE ADDED TO kernel/dma, they wanted to add a dma wrapper to a rust/ folder.
I'm sorry for not being clearer, but that is specifically not what is going on. The objections were of factual, technical nature. As in, "do not do X". The problem is that the code in question was not doing X, and it was not doing anything that could be construed as doing X. The objections did not arise from differences in priorities, preferences, or perspectives, they were just factually wrong.
"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)."
Stop spreading this kind of misinformation.
And no, I don't think he came off very well here, but please, give it a good faith reading.[2]
rust/bindings/bindings_helper.h | 1 +
rust/kernel/dma.rs | 271 ++++++++++++++++++++++++++++++++
rust/kernel/lib.rs | 1 +
rejecting such patch is the exact cancer that need to cured. stop misleading people.
And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel. And if said wrapper accepted then maintaner of DMA will have to make sure that all patches he accepts also fix Rust parts.
So he just dont want extra burden for himself.
if multiple rust based drivers all need to have DMA support, what should they do? each come up with their own little magic?
> And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel.
this has been explained like 10+ times in this thread - it was made crystal clear to the DMA maintainer that he/she doesn't need to maintain the rust stuff, it is totally okay to break it.
> So he just dont want extra burden for himself
he can just resign. simple and period. no one is ever forcing him/her to be the maintainer.
Sorry to ask, but couldn't it be solved with cargo? I hear all the time about the benefits of Rust tooling and zero-cost abstractions.
Why can't a driver just pull/include the latest-dma-bindings crate and glue the gap with zero-cost abstractions?
If kernel DMA code/API changes, then nothing breaks in the kernel (hopefully) and the "Rust devs will quickly solve the changes" theory can be really proven and tested by quickly updating the bindings AND the updating the drivers.
No, he didnt refer to Rust as cancer, but to Rust in the Linux kernel / the R4L project.
I think Hellwig is against moving the wrapper into the DMA project that he's forced to maintain it.
That is the crux of the entire drama and why R4L developers got upset at Christoph in the first place, and asked Linus to intervene.
It's a great question. I mean, my read of it is he hates the idea of Rust4Linux and is using his position to obstruct.
> He has no control over an independent library outside of C DMA?
Apparently not.
> Just that the maintenance of such including any wrapper cannot fall into C DMA's lap.
The patch he rejected did not add any code to C DMA, nor C DMA's directory (kernel/dma). Just:
rust/bindings/bindings_helper.h | 1 +
rust/kernel/dma.rs | 271 ++++++++++++++++++++++++++++++++
rust/kernel/lib.rs | 1 +
Here is a link to this explicit claim: https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...
Dinosaurs don't want to live in the age of tech.
Surprised? I am not.
I'm no where near in the loop on this, but that sounds incredibly toxic. Are there some good links to summarize this?
EDIT:
OK, these are fully enough to allow me to understand the issue.
Marcan: https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
Linus: https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
I must say, I think I'm on Linus' side on this one.
EDIT2:
I was a $$ supporter of Marcan for over a year on github. I was predisposed to believe him, I'd say.
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.
"... I come at this from the perspective of having worked on Linux since around December of 1991. I first met you and Tove in 1995 at the Free Software Conference at MIT that Stallman sponsored. ...
Probably the last technical contribution of my career is leading an initiative to provide the Linux community a generic security modeling architecture. Not to supplant or replace anything currently being done, but to provide a flexible alternative to the development of alternate and/or customized workload models, particularly in this era of machine learning and modeling.
Four patch series over two years, as of yesterday, not a single line of code ever reviewed. ...
We were meticulous in our submissions to avoid wasting maintainers time. We even waited two months without hearing a word before we sent an inquiry as to the status of one of the submissions. We were told, rather curtly, that anything we sent would likely be ignored if we ever inquired about them.
We tried to engage, perhaps to excess, in technical discussions attempting to explain why and how we chose to implement what we were proposing. ...
There were never any relevant technical exchanges. The discussion consisted of, we have decided to do things a certain way, no discussion, if you don't like that you should really consider doing something other than submitting to upstream Linux."
(https://lore.kernel.org/lkml/20240826103728.3378-1-greg@enje... is the patch set in question)
https://lore.kernel.org/linux-security-module/20230204050954...
The "every change can be a small patch, can be split in such" is part now of the Linux folklore IMHO. As in, a belief that people kinda heard about but nobody has concrete proof
Also do you know what would make it much easier to review long changes? Not using email patches
But I'm glad there's an good answer on "how to do it" in the thread https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home...
GitHub issues with "load 450 hidden comments" on it? No threads, no comparisons between multiple submissions of the same patch, changes from rebasing impossible to separate from everything else? Having to drop anyway to the command line to merge a subset that has been reviewed? Encouraging squash merging makes it easier to work with long changes?
Email is complex and bare bones, but GitHub/GitLab reviews are a dumpster fire for anything that isn't trivial.
And I agree, GH has several issues
IIUC, the Kernel project doesn't want to use it because of the single-point-of-failure argument and other federation issues. Once the "main" Gerrit instance is down, suddenly it's become a massive liability. This[1] is good context from the kernel.org administrator, Konstantin Ryabitsev:
"From my perspective, there are several camps clashing when it comes to the kernel development model. One is people who are (rightfully) pointing out that using the mailing lists was fine 20 years ago, but the world of software development has vastly moved on to forges.
"The other camp is people who (also rightfully) point out that kernel development has always been decentralized and we should resist all attempts to get ourselves into a position where Linux is dependent on any single Benevolent Entity (Github, Gitlab, LF, kernel.org, etc), because this would give that entity too much political or commercial control or, at the very least, introduce SPoFs. [...]"
[1] https://lore.kernel.org/rust-for-linux/20250207-mature-paste...
By that measure, kernel.org is a SPoF as well
Maybe we can figure out a way to archive Gerrit discussions
(offtopic note - don't upvote the comment you're responding to while you're commenting as you'll lose your comment)
In contrast, I use Mutt for dealing with high-volume email-based projects with thousands of emails. It's blazingly fast, and an absolute delight to use—particularly when you're dealing with lists that run like a fire-hose. It gives a good productivity boost.
I'm not saying, "don't drag me out of my email cave". I'm totally happy to adapt; I did live in "both worlds" :-)
Yes, the model is not scaling. Yes the current model is turning people away from contributing
I don't think linux itself is risking extinction, but someday the last person in an IRC channel will turn the lights off and I wonder if then they will think about what could they have done better and why don't people care about finicky buildsystems with liberal use of M4. Probably not.
If that were the case then the patch would have a lot more CCs.
> We were meticulous in our submissions to avoid wasting maintainers time. We even waited two months without hearing a word before we sent an inquiry as to the status of one of the submissions. We were told, rather curtly, that anything we sent would likely be ignored if we ever inquired about them.
It's reasonable to ask that people make smaller-sized patches to get reviewed, and it's reasonable to have to rule out some things due to not having the bandwidth for it compared to other priorities, but it's pretty ridiculous to expect people to know that those are the reason their code isn't getting reviewed if they're not allowed to inquire once after two months of radio silence.
if someone is willing to put in the efforts to submit such a huge patch, how about just show them a little bit respect, I mean the minimum amount of respect, for such efforts and send them a one line reply asking them to break the patch into smaller ones.
surely that won't take more than 45 seconds. still too hard to get the point?
I hate to appeal to authority, but I have been working with large cathedral-style open source projects (mostly three: GCC, QEMU, Linux itself) for about 20 years at this time and have been a maintainer for a Linux subsystem for 12. So I do know what I am posting and talking about.
The very fact that I had never learned about this subsystem from LWN, Linux Plumbers Conference, Linux Security Summit etc. means that the problem is not technical and is not with the maintainers not replying it.
A previous submission (7000 lines) did have some replies from the maintainers. Apparently instead of simplifying the submission it ballooned into something 150% larger. At some point I am not sure what the maintainers could do except ignoring it.
It sounds like there was willingness to meet any requirements, but submitters end up in a position of not knowing what the requirements are and if they have met them or not.
Ignoring people is a childs approach to communication. If there is a problem, its your responsibility to communicate it. If you have communicated the issue and the other party is refusing to hear it, that is a different issue, but it is your responsibility to communicate.
https://lore.kernel.org/rust-for-linux/20250208204416.GL1130...
Yikes, this is EXACTLY what Linus was talking about except an order of magnitude worse!
This does not read as a rant at all to me. Rather it seeks to highlight a problem using an example from his own work and proposes a possible solution (with a previous caveat of “I don’t know how to fix this”).
> "Code Of Standards for maintainers" in addition to a CoC
He wants maintainers to behave in some pre-determined understandable fashion. He wants some accountability, and that seems reasonable to me. This is not a “maintainers must do what I want”, this is “let’s set basic expectations” and ensure people follow them. Whatever those should be.
> in order to witch hunt people he feels "gets in the way."
B does not follow A. You are simply straw-manning here, so I have nothing to say to it other than it’s a fallacious point.
But presumably it's not whatever they should be. It's what he wants them to be. And what should happen if they're not followed?
Few people like dealing with interpersonal conflict. They want to think that technical meritocracy wins the arguments.
But in that discussion, a maintainer said "I am going to try to sabotage this because I hate it.", and there's no technical argument to resolve that. And there's not really any route other than escalation to some kind of authority if there's not a common negotiation baseline.
"You can't reason someone out of a position they weren't reasoned into."
When has this ever happened with the Linux CoC? The only people who I've seen banging pots and pans together about the CoC are folks who like to sealion [1]
Speaking as an actual People Manager, his ideas sound pretty shallow.
That sounds... Not good. Seems like like this is exactly what's wrong with... Well, not just this, but much of the "FOSS" world. (Maybe about since "Free Software" became "Open Source"?)
The current management model is based on consensus in some parts, and a dictatorship in others. Its not clear which parts are which because of sprawl, and non-responsiveness.
This is a core communication people issue. The problems arise because in consensus models, people are expected to adopt archetypical roles based somewhat on preference, but mostly on the needs of the group, towards productivity.
If no one else is doing that type of role, someone will be forced into doing it, and will adopt characteristics of that role, regardless of their personal opinions about it.
When they get punished for fulfilling the role, you lose people.
> doesn't mean we should throw our hands up and consider things "unfixable" either.
The given structure is unfixable, because it sets the stage for a trauma loop where actions can't take place without people who are expected to fulfill a role to meet consensus, but in doing so they get punished for volunteering.
There is no way around this structure so long as you use a consensus model in whole or part, in dysfunctional groups the people involved either fail to communicate or worse there are members that impose coercive cost by assuming the unproductive roles so no action happens while resources are wasted.
This really is basic stuff covered in your college level intro to communications coursework.
For those wanting to know more about this, you can read more about the roles at the link below.
> there is the tangible risk of stifling innovation and Linux is the only place that innovation can occur in the operating system space.
Is it innovative? Is it valuable? Is it worth the cost? Who is it valuable to?
I don't see why the kernel team should be obligated to react in any particular way to a random submission.
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.
https://geekfeminism.fandom.com/wiki/Harming_the_community
and
https://geekfeminism.fandom.com/wiki/Tone_argument
and
And please, stop using the concept of ad hominems to selectively justify blatant abuse. That's not what the term is about.
It was a move of frustration due to having exhausted all other avenues. It wasn't his first action.
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?
That might reflect my environment, but all of the things I’d consider C variations for I’d use Rust for as well…
An example is Muratori from handmade hero, who publicly stated he dislikes Zig and pretty much sees it as a confused mess[1]. He thinks Odin is kind of OK, because it has metaprogramming (which other languages do too), but is way below Jai. Between Jai and Odin, he thought Jai was the one with potential and could get him to switch/use. Odin's slight popularity, as a kind of Jai-lite, is often attributed to Jai being a closed beta. But, it appears that might change soon (Jai going public or opening up beta use more), along with an upcoming book on Jai.
Programming languages like Go and V (Vlang), have more of a use case for new programmers and general-purpose, because they are easier to learn and use. That was the point of their creation.
[1]: https://www.youtube.com/watch?v=uVVhwALd0o4 (Full Casey Muratori: Language Perf and Picking A Lang Stream)
C programmers (and C++ programmers) who don't like Zig or Odin can simply use C (or C++), it's not really the case that they have to switch to anything, much less something as overwrought as Rust. My point is that it is natural for someone who is at any proficiency level above 0 in C to want to apply that proficiency in something that allows them to make use of those skills, and C, C++, Odin and Zig all allow them to do that, pretty much immediately.
You contend that "It's an investment to become as proficient in the other language" but I would argue that this is a very wide spectrum where Rust falls somewhere in the distance as opposed to all of the languages I mentioned instead being far closer and more immediately familiar.
The counter, in regards to "any proficiency above 0", is there are other alternative languages (that are easier to learn and use) where knowledge of C can be put to immediate use too. Getting up to speed in those languages, would likely be much faster, if not more productive for less proficient or experienced programmers.
I work full time with Odin and I wouldn't put too much stress on this point as I've found that whatever issues we have with Odin are simply issues you'd have with C for the most part, i.e. C knowledge will help solve it. It's not a complex language, it doesn't need to do much and language-specific issues are few and far between because of it. Tooling is a bit of a mixed bag but it's about 80% solved as far as we're concerned.
Odin day-to-day for working on 3D engines (which I do) is not beta quality, whatever that means. I would rate it a better net fit for that purpose than I would C++, and I wrote the kind of C++ you would write for engine work for about 10-11 years (at least what we knew to be that kind of C++ at around 2001). For server software I'd rate it worse, but this is mostly because there are a few missing FFI wrappers for things that usually come up, it's not really because of the language per se.
As for Jai, I can't claim to know much of anything about it because I've never used it, and I wouldn't take many peoples' word for much of anything about the language. As far as I'm concerned Jai will exist when it's publicly available and until then it's basically irrelevant. This is not to disparage the effort, but a language is really only relevant to talk about once anyone with motivation and an idea can sit down, download/procure it and use it to build something, which is not the case with Jai.
You cannot claim this when even codebases with veteran C developers will be virtually guaranteed to have memory safety issues at some point.
Also, I know this may shock a lot of people who don't regularly use sharp tools: The possibility (and even occurrence) of memory safety issues and memory corruption doesn't tank a project, or make it more costly than if you'd used a GC, or Rust. Memory bugs range from very easily avoided and solved to surprising and very, very hard to solve.
I never said this. The Linux kernel and any other project will thrive with or without Rust. But it is a certainty that the higher the ratio of C-to-Rust in the world (or well, any memory-safe systems language), the higher the amount of CVEs we will see. It would seem reasonable to me to assume that we want as few CVEs as possible.
To be honest, I also don't understand the dogmatic stance a lot of C developers have against Rust. Yes, it does cause some friction to learn a new language. But many of the correct idioms Rust enforces are things you should be doing in C anyway, its just that the compiler is a lot more strict instead of just nagging you, or not even nagging at all.
Social bubbles can work like that.
I'm amazed that Hector is doing this fully in public using his real name.
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. Probably because they're trained to defend their space in the differently toxic C++ community. Mozilla was a breeding ground for what they see as a holy crusade.
It's not even that they're always wrong, but the shotgun blast of culture war that they come with is just so much effort to navigate that i decided to just never contribute to rust again.
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.
> Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not.
> Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders".
> It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build.
The matter and the question at heart is still unsettled. The answer of whether or not Rust being in a broken state is a blocker for working and valid C code will hopefully be addressed by the end of this cycle of development. Either the patches are accepted and Rust is truly allowed to be broken or the patches will not be accepted due to breaking the Rust builds. If it is the latter, as many of the C developers fear, that is the exact burden being placed upon them that they have been stressing very loudly that they have no interest in taking on. And once other maintainers see this, what is the inevitable response to this metastasization? Comments like those from Ted and Christoph will pale in comparison. The only bright side might be that this finally accelerates the inevitable demise of this failed Rust experiment so that all parties can move on with their business.
That one bug happened one time does not mean that the promise is broken. To be clear, it's a bad thing, but acting like this means the entire working rules are a lie is overreacting.
It's not been once. Don't you understand that is why things have gotten to this point? Are you aware of how the developers have been using Coccinelle in their workflows and how many subsystems support it? And are you aware that the Coccinelle for Rust implementation is constantly in a dire state? Have some empathy for the folks who have had their workflows broken and burdens increased because of it.
> Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems.
Clarity will be communicated by the result of this patch set.
Okay. Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?
R4L folks thought that preliminary R4L infrastructure being accepted upstream meant that all the changes they needed in the future would be accepted easily as well, and now that there are concerns from subsystem maintainers, a few R4L folks are playing the dramatic victim card.
From what I understand, market pressures are causing R4L folks to panic. If they can't get more R4L stuff upstream, people can't ship Rust drivers, and R4L development falls apart.
That's not kernel maintainers' problem, though. They have a job to do to, and it has nothing to do with Rust kernel drivers except as far as they're persuaded Rust drivers help the linux community overall and will be maintainable without unacceptably disrupting their tool-assisted workflows. Several of them have concluded, so far, that R4L PRs will unacceptably disrupt existing workflows.
That's where R4L has failed. They've failed to persuade subsystem maintainers that some added headaches/retooling/efficiency-loss is worth it to enable Rust drivers. Which drivers, and who wants to use them? Perhaps the potential downstream users of those drivers can talk with kernel devs, persuade them it's really valuable, and figure out a plan?
Not just 'a few R4L folks', these are basically the spearhead of the effort. And it hasn't been a single occurrence, we now have seen two of those Rust developers resign from the effort out of pure frustration from the entrenched, heels-in-the-sand attitude from kernel maintainers.
The same thing has happened in the past. I will point to TuxOnIce, which got stonewalled by a stubborn maintainer. It would have moved most suspend and hibernation code to userspace, where it would have been easier to maintain and iterate. Or right now we have two divergent RAM compression paths (Zram and Zswap). There are patches for Zram to use the unified Zpool API, but the Zram maintainer refuses to integrate these for absolutely no solid technical reason.
It seems that the R4L peoples are fine with doing any effort required, as long as they know it is not in vain. So far, comments akin to "language barriers in the kernel are a cancer" and "I will do everything to prevent/sabotage this" do not exactly build trust in that regard.
As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust? This is not a dire ask for someone in the software world, your job will often ask this of you. And I can't imagine the maintainers haven't ever dabbled in other languages and/or aren't capable enough to learn a second language.
I understand the fear that saying "ok, we can do more languages than one" opens up the door to a third and fourth language down the road, but that seems unlikely. There's a reason Rust has passed Linus' sniff test where no other language has so far.
> Which drivers, and who wants to use them?
Short term it seems mostly GPU drivers.
Long, looong term (multiple decades?) the plan is probably to rewrite more important parts of the kernel, to significantly increase memory safety.
Well they are. Second class citizens like this just cause problems.
> As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust?
Are the Rust folks planning to pay the existing kernel developers for spending that time? Because otherwise it should be up to those existing maintainers to decide and not something anyone else gets to demand.
Overall this just sounds like people crying that their hostile takeover of an existing project is being met with resistance.
> Not just 'a few R4L folks', these are basically the spearhead of the effort.
A "spearhead" is by definition a few people.
> As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust?
If they want to contribute to the Linux kernel, would it really be so horrible for these Rust programmers to learn the language the kernel is written in?
> There's a reason Rust has passed Linus' sniff test where no other language has so far.
Doesn't seem it has, really.
> the plan is probably to rewrite more important parts of the kernel
So just fork it and rewrite it all in Rust.
But the thing is, the kernel isn't "the R4L folks"' "fuel tank", is it? Doesn't the very name you use, "kernel maintainers", tell you that that's their "fuel tank"? Seems the people pouring sand into that are "the R4L folks".
I've had to remove Hector's postings from my feeds because he just constantly bitches and complains about pretty much everything. He's capable, smart, and is doing more than anybody ever will for Apple hardware. But he desperately needs to Stop Posting. Without anybody he works with regularly to give him a reality check, I don't think he's going to change course.
I think Hector has some valid complaints about the contribution process to the kernel, I know. It fucking sucks ass and I've given up on trying. But screaming the way he does is counter productive to improving it
Linus should have stepped in long before a maintainer blew their stack and started throwing out ultimatums. Once that happened, Linus could have still stopped everything with one sentence -- "Let me look into this.", but he did not.
Linus only got an opinion once things blew up on social media which proves that social media works which is the exact opposite of what he says he wants (and will just encourage more of the same).
That is really an apt point. You can't condition people one way, and tell them to do the opposite.
10 years back, Linus _was_ "that guy". And it worked, extremely effectively, if you measure success by the ability to stamp on someone else's technical contribution by ridiculing them in public instead of making a convincing technical defense of his position in the discussion.
Going to have to disagree on that one.
You can certainly imagine ways an authority figure could have defused a situation of a maintainer blowing their stack, but your framing kinda absolves the maintainer of any accountability for their actions.
A team member who needs a lot of defusing is doing something wrong, and needs to learn how to defuse themselves.
Not in the sense of "he wants the mailing lists private", but in the sense that "he doesn't want public complaint about private discussions", which feels like an evolution of "technical merit should win", as a position.
That shouldn't be too surprising - I mean, its an old project with a whole lot of technical baggage. Projects tend to slow down over time. And that is legitimately really frustrating when you want to shake things up or push for change. I would be rubbish as a linux kernel developer. I have the wrong temperament for it.
There's a reason why some tech companies interview for both technical skill and culture fit. Sounds like he's got the technical chops, but he's not a good fit for linux.
And when you're in a situation like that, your choices are essentially Voice or Exit. Voice is to do what he's tried to do - kick up a fuss about the problems to try and get them fixed. Thats a skill on its own - and it sounds like he's not been super effective at that. The other option is Exit. Which of course - sensibly, he's now done.
> he has gotta Stop Posting and keep those kinds of thoughts away from his keyboard.
Nah. Bottling this stuff up is a bad long term play. You end up getting bitter, cynical and resentful. I think we've all worked with people like that, and its miserable - both for the person and for their coworkers. I think its better to shoot your shot. Even if you miss - as he has here - you learn a lot about yourself and the world. And there's no shortage of interesting projects out there to work on. Pick something that matches your speed.
You're right.
To fit with historical "linux culture" he needs to be much more aggressive and rude.
He needed to lead with something more inline with linux project leadership's examples, perhaps something like: Christoph " ... should be retroactively aborted. Who the f*ck does idiotic things like that? How did they noty die as babies, considering that they were likely too stupid to find a tit to suck on?"
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.
You don't even take time to figure out who's the commit author.
First of all because we're talking about the kernel community here, which was incredibly toxic and dramatic long before Rust even existed. Linus has chilled out in the past few years but that legacy isn't entirely gone.
C++ drama has nearly come to fistfights at conferences, and the only reason that doesn't get talked about more is that the toxicity stays mostly on private (not public) mailing lists as a result of the more insular nature of that ecosystem.
There are plenty of "C supremacists" in the tech influencer community and the maintainer mailing list of every distribution.
And streamers like PrimeTime that eagerly jump on every opportunity to shit on Rust and actively dump gasoline on every flareup of drama for ad revenue.
In general, programmers seem to love being elitist about languages and tools. Remember how everyone used to dump on PHP constantly?
He's not a fan of Rust for totally legitimate reasons.
From shaming everything else as either slow or unsafe to rewrite the universe, the Rust community makes it hard for new comers to consider the language by its merit.
But the good thing is, the hype has settled down and Rust has found its niche. It’s not tackling Go or Python anytime soon and competes in a different plane.
Zig is another great alternative for someone like me who never found Rust a pleasant language to work with.
There are softer ways to work with abrasive attitudes that can ultimately accomplish your goals. A key part of that is knowing which battles are worth fighting. Sometimes, it's better to let a suboptimal solution in to appease an ego.
I think Hector's change is the right one, but I also think with the dma maintainer being unwilling to budge the next move is to hack in a location with less resistance, potentially making more work and churn, but ultimately achieving the goal of rust in Linux.
Two people being abrasive to each other with code involved is a disaster.
This one. The code in question, AFAIK, is a rust wrapper around the DMA subsystem. I think that does best belong in the DMA subsystem but with the maintainer unwilling to accept it the next place to put it is either in a new rust-dma subsystem/wrapper or to pull out the parts needed and integrate them directly in the drivers in question (certainly nasty and a lot of duplicate effort).
The goal for such code should ultimately be to cause as little friction as possible with the DMA maintainer.
If it comes up in the mailing list that "this is dumb and you shouldn't do this" that's when you loop in the DMA maintainer and request their suggestions on how to proceed with whoever challenges the change. Put them in the seat of making the decision of where the code should go.
They have been trying for years now to integrate Rust in the Linux kernel they could have made some good progress on a rust only OS by now. If only just a kernel that can run server like application without a gui shell.
Surely it should be easy if you're asking the Linux people to do the same thing for drivers written in Rust?
This was never about the languages primarily though. The C programmers here would react the same way towards any other language, be it Zig or Swift, its not Rust specific. They just don't want to partake the additional headache they'll have to deal with to for making the Linux kernel more accessible to languages other than C.
Despite than, Rust devs kept on pushing it after all that was clearly stated, just to make things more and more annoying. Maintaining a software as huge and widely used as the Linux kernel is a huge responsibility that can't be relied on words like "leave it on our shoulders", especially when real time, immediate response is demanded. Development of something like the Linux kernel in Rust will be left unmaintained eventually, unless millions of dollahs are constantly invested into maintaining it because Rust is not as simple as C and the need to avoid accidental copying, memory leaks and almost all memory related issues will add more work because you can't escape "unsafe" when dealing with low level hadrware and C, making the usage of the Rust programming language for Linux kernel development utterly pointless.
Also, there is nothing wrong with any "unsafe language". Memory safety is a skill issue, not a language issue. All functional languages are safe and procedural languages are unsafe by nature. Its better to settle on a functional language and compromise on performance if memory safety is of utmost priority. The additional complexity and performance overhead of any supposedly safe procedural language is not worth it for doing low level stuff but it sure could be a fun choice when doing high level stuff.
The hardware is outside of Rust's safety guarantees. This is truly a fundamental issue.
There seems to be an entire second world of “Rust community” and Rust zealots online who are heavy on the drama, though. It really does feel like an alternate Rust universe.
Although when I think about it, several of my other interests and hobbies are exactly like this. Great in the real world, but as soon as you step into certain online spaces it’s drama and toxicity.
In this specific case, I think this is more about kernel drama than Rust drama.
You can lie to yourself and say that the same security problems exist in other languages, but that isn't true.
When I check the vulnerabilities marked as HIGH on a JVM based project, it's often banal stuff like a denial of service in Spring. The consequences of an attack are a few days of downtime until we patch the library, but the truth is that while downtime on our application might be profitable for a competitor, it's not profitable for a black hat hacker working alone. They can't blackmail us, because we can update the library without paying them to stop.
Meanwhile the average C vulnerability is usually some form of RCE that would let the hacker install ransomware.
Yes, there was a popular logger library that was written badly that tried to interpret log messages as potential source for fetching code dynamically from remote locations. Something that was thought to be the future 25 years ago, but had mostly been abandoned in all modern code.
It get pushed with the argument for better memory safety but then wants to change the entire world as well.
That stackoverflow survey rust folks so proudly crow about shows it’s the #1 ‘admired’ language, well #2 was closure and Zig over the years which clearly shows the value of the survey. Just marketing slop.
The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core library has 7K (of 21k) unsafe functions. So any Rust program that claims not to have “unsafe” code is most likely not true since any program that doesn’t use the standard library is a toy.
https://aws.amazon.com/blogs/opensource/verify-the-safety-of...
The rust community unearned arrogance is only surpassed by the Haskel folks. It’s breathtaking. Yes yes not all in the rust community are like this, but the social media amplified squeaky wheels one sure are loud.
Why does any of that imply that Rust doesn't produce safe code? There's no argument here - just some numbers and unjustified conclusions.
> To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
That was 2022. I am aware of at least one security bug in their Rust code, but it wasn't a memory safety issue. I'll be interested to see what they say when they post updated numbers.
"it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks"[1]. Using the Rust keyword 'unsafe' doesn't make the code inside it the Wild West or automatically an exploit or a problem, it is a limited-scope relaxing of only some checks.
If rust ends up being mainstream successful, those people will move on to something else and start attacking rust for whatever they feel their new language is superior in
Someone should have hugged them when they were kids
fixed for you - you can print it out, frame it and put it on your wall.
Just hate the fact that quite often people get judged or even treated differently just based on the languages they choose to use. It is just a tool, nothing different from a screwdriver.
This drama included the dma maintainer saying he is categorically opposed to any Rust in any part of the kernel.
>Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this. You might not like my answer, but I will do everything I can do to stop this.
I think that clearly means he is out to sabotage any other language than C making it into Linux.
> I do not want it anywhere near a huge C code base that I need to maintain.
Link to mailing list: https://lwn.net/ml/all/[email protected]/
This was also on a patch that did "keep the wrappers in [rust-folder, not DMA] code". Arp242's interpretation isn't just belied by the direct words of the maintainer, it's belied by the fact that the code the maintainer rejected was exactly what Arp242 is suggesting the maintainer was asking for.
The fact that he is using his powers as maintainer of the DMA module to prevent Rust code from being added, with the explicit goal of making it harder to develop Rust drivers so that maybe the Rust-for-Linux project might get abandoned is an explicit act of sabotage against the R4L project (no one is saying he is sabotaging the Linux project itself).
In contrast, even accepting the "two languages bad" perspective, you can't call the R4L project "sabotage" in the same way, because they are clearly not intending to prevent or break anything in the Linux kernel, even if you think they will end up doing so as this maintainer does.
This is a misinterpretation of the facts. It's not actually up to Hellwig whether or not the patch gets accepted; the relevant maintainer that would merge the patch is somebody else.
He's totally within his right to express his opinion in a NACK.
When it became clear that wasn't an option, they decided to put it somewhere else, but since he'd been consulted, he still wanted to make it clear he isn't ok with the patch regardless of where the files go or any other aspect of it; but you're right that he is not the final authority on what code goes into that new subpath.
I never said in any way that he doesn't have a right to his opinion. Just that he is explicitly and vehemently opposed to Rust in the kernel, and to anything that makes that easier to happen.
If any of
> Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this.
is correct, he is actually fighting against sabotage.
edit for readability
> The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux.
Dude, this was literally caused by a stubborn maintainer, Hellwig, saying he wants NO second language in the kernel at all, and his explicit vow to do anything he can to stop it.
The rust for linux project exists because Linus approved it. It's that simple. Linus thinks it a good idea to at least try Rust in the kernel. If he didn't, then none of this would be happening.
Pepople can change their minds; after a while, they may come to think that what they once thought was a good idea wasn't actually so.
With stuff like this going on -- and I gather this is not the first time something like it has happened -- how long do you think Linus will continue to think so? Do you think stuff like this is likely to make Linus more convinced, or less convinced, that setting himself (and all the other Linux kernel maintainers) up to have to interact with Rust people on an ongoing basis really was a good idea?
Some Kernel maintainers are absolutely against Rust anywhere in the kernel tree [0]:
> 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.
This is from Christoph Hellwig, the DMA maintainer. And is in fact what started the thread that led to Hector Martin quitting Linux. You can see other comments by Hellwig in that thread as well, he is extremely explicit - any Rust anywhere in the kernel is a big problem, and even if he can't stop it everywhere, he will do what he can to make it harder to use Rust by blocking it from the pieces he maintains.
[0] https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...
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.
I was just pointing out that the positions are much more binary and un-nuanced than the previous poster was claiming, even in the thread in question. I'd bet the DMA maintainer is not the only one who holds this dogmatic position, either.
I'll also note that the complaints from this maintainer aren't even social though. He is very explicit in his reasoning: two+ languages bad, single language good. There's clearly little that will change this, other than working around him (though, again, I agree that social media blackmail certainly won't improve anything).
I see you're not even considering the possibility that he might be right, so working around him would be bad.
___
ETA: I see on further reading that you are indeed acknowledging that possibility, good for you! I just didn't see that in this comment.
What about the part quoted in GPs comment?
> > The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this
Wouldn't adding another language add an internal boundary? I don't know enough the kernel or kernel development to say it's an good argument or not, but it doesn't seem to be tribalism. I do know Rust already seems to be in some/few places in the kernel, but adding more would add more internal boundaries, as it'll get more and more divided. But again, maybe I don't understand clearly.
However, I don't think it is in any way acceptable to insert this in discussions about a random Rust patch. It's disrespectful to the time and expertise of the people who submitted these patches to first nitpick various technical items, only to later make it clear you were never going to accept their patch in the first place, because you dislike and oppose the decision that you know has already been made, to allow Rust in the kernel.
If he instead was (1) upfront about the fact that he would never allow Rust code in the subcomponent he maintains, and (2) stepped out of the discussion of this patch once it was moved out of said component, and then (3) started a completely separate thread on changing the kernel's stance on Rust to block all future patches and consider removing it entirely, that would all have been normal respectable behavior.
Wait what? Thought I saw somwehere that he's the DMA maintainer, and wasn't this a DMA patch?
> he is simply being obstructionist out of tribalism.
Or is it the Rust people who are being intrusionist out of their tribalism? Looks at least as much like that to me.
Although it was a DMA patch, it was not in the DMA subsystem that Christoph maintains. More specifically, it was not a file in the kernel/dma directory, but rather a file in the rust/kernel directory, which is where the Rust subsystem lives.
The Rust code is essentially a consumer of the DMA public API, much like many other subsystems in the kernel that consume it.
This is why some people are upset and confused about the situation; he added a Nacked-by tag to a patch that is outside his area. He had good reasons for it, but it was hard to see them based on the way he wrote his replies.
Perhaps rusts potential benefits are worth it, but it's certainly possible to disagree with that
That ship could come back to port anytime.
Basically, it's an obstructionist, uncivilized thing to hold up every discussion about a topic that you get to participate in by insisting the topic shouldn't be discussed in this forum. It's perfectly OK to advocate for the removal of Rust from the kernel, it's not ok to bring this up in every random Rust patch while the consensus is that Rust has a place in the kernel.
I'm 100% behind Christoph, the last thing Linux needs is the extra complexity that Rust brings. I'm fairly optimistic that Rust will never be a hard dependency for the foreseeable future.
I totally disagree that the other contributor is "a bit" abrasive though.
It's like a religious war. Brings the worst out of otherwise smart and not asshole people.
you are probably right regarding whether it is the best approach. however, his email with those 12 "I am tired" means something.
labelling his action toxic itself is toxic.
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.
The sooner politicians are outright banned from using it for anything connected to their office the better.
That doesn't really have anything to do with Rust; but with Hector's behaviour. Threatening a social media campaign to out people is completely toxic behaviour. This is a long-term contributor who is perhaps a bit abrasive, not Jimmy fucking Saville.
Other than that, it's not a binary yes/no question; no one is really against some Rust in some parts of the kernel, but which parts? How? Where? That's the big disagreement. Linus has always been fairly hands-off on these types of disagreements.