I think if I was indicted by Linus and told I'm a problem over spreading awareness about a position on social media, I too would burn out pretty quickly. That's how you crush motivation. There's a deeper issue in open-source culture where harshness and gatekeeping drive away passionate contributors.
"spreading awareness about a position" isn't a very accurate way to describe what happened. This is the guy who said he wanted to use social media to create a "hall of shame" for kernel developers. Of course Linus told him to knock it off, that's ridiculously unprofessional behavior.
1. I think the the DMA maintainer is correct. Don't intertwine implementation languages, that is bad idea and a maintenance hell.
2. Social media "hall of shame"
3. Torvalds is forced to make a statement because of 2. Not 1.
"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."
The issue is that Linus put the Rust developers in an impossible position: On the one hand he approved Rust in the kernel, but then never ever ever has the balls to enforce that decision.
Then, the fanatical C developers openly sabotage and work against all the Rust developers efforts. So, the last option for the Rust developers is to take it to social media. Otherwise, the C developers get away with creating a self fulfilling prophecy: Sabotage all Rust efforts, then claim the Rust experiment failed.
Linus didn't seem to ever have the time to actually take a stance, except of course on the social media issue. Fully ignoring all context. It's the equivalent of a school principal suspending the bullied victim for finally snapping and punching their bully.
The thread didn't really have drama before marcan stirred the pot. There was a disagreement, but the individuals pushing for the merge were not attempting to escalate, only try to find a path forward in a way that might make both parties happy with the compromise. The drama and social media outrage arguably did nothing to help, and as far as I can tell, simply makes for good entertainment for onlookers who like to gossip. While it would be nice to have Linus help out here with a clear resolution after escalation, it's clear to me that the behavior marcan displayed is the higher priority problem to address.
I think this isn't the right take. the "disagreement" was a kernel maintainer saying "Rust in the Linux kernel is a mistake and I will do everything in my power to sabotage Rust adoption" (as feedback on version 8 of a patch). The fact that open undermining of Rust for Linux receives no pushback from Linus or anyone else with power in the Kernel is shocking.
100% this. Yes, Hector went nuclear, but he begged Linus to step in and provide leadership (either merge or reject) and instead Linus ignored the whole technical issue with regards to rust being totally blocked.
Even now with Hector out of the picture, there’s still no suitable path forward for rust in Linux. No wonder why people are giving up (exactly what the blockers want).
>Even now with Hector out of the picture, there’s still no suitable path forward for rust in Linux
The suitable path forward is to submit the patch series like normal to Linus, where it will be merged regardless of CH's NACK. CH isn't able to actually stop this process, he's just being a jerk.
However, I agree with you that it would have been nice to actually publicly clarify the situation rather than ignore it and deal with the whole thing behind closed doors. It shouldn't need to be explained that letting this sort of thing fester is a great way to kill motivation in a project and ensure it's less likely that new people will get involved.
The reasoning Linus himself gives for greenlighting Rust is, among other things, to avoid stagnation.
In practice, CH is doing everything he can to stonewall and sabotage efforts to subsequently bring Rust to solve problems.
This explosion, now, was plainly a consequence of months and months of failure. And that anyone name-calls to blame that failure on “a drama-seeker” leaves me to wonder about the future of Linux 20 years from now.
Counterpoint: prior to going nuclear, is there any evidence that Marcan directly tried to get Linus's attention, given the huge quanity of mailing-list mail Linus is sure to get every day?
I only see Danilo doing that in that thread. And admittedly Linus didn't respond (and Greg KH only minimally responded). But even CC probably means a lot of mail for top maintainers, and at that point I don't see anything that would've gotten in the way of "send a PR despite the Nacked-by", which has been done in the past.
He literally says in the post he reached out to Linus directly and to this day haven’t gotten a response. He also himself was (trying to) upstream patches for years, usually ending up similarly getting stonewalled
I don't see the word "reach" or any relevant mention of "Linus" in either the "shaming" post or in the resignation post.
Even if there was, I'm not sure I trust the word of such a drama-seeker directly, so it's reasonable to a evidence of on-mailing-list appeals adding CC (as Danilo did), and if that fails mention of contacting Linus off-list in that specific subthread.
The rust project is not stalled. There is pushback from maintainers, but as trust is established, things will hopefully change and it'll get easier. Escalating erodes trust and simply will make the process take longer. Anything that fuels us vs them narratives are simply damaging. Everyone needs to focus on the shared objectives of the overall Linux project. Ignoring the maintainers and pretending their opinions are wrong or don't matter won't help. I'm not sure a top down directive is necessarily the right way to establish a healthy space for rust in linux.
I agree. Everyone here seems to be criticising Marcan for not being professional, but it’s very difficult to remain professional when the people you’re working with gloat in public that they intend to completely sabotage your work product despite it being given explicit support by the CEO. Why are you the only one criticising the coworkers? I feel like I’m taking crazy pills reading this thread.
Because this thread is about Marcan's behavior, not others'. I think it's perfectly fair to claim that everyone behaved badly in this situation, but the person I replied to was insinuating that Marcan didn't do anything wrong. That is not true, and why I highlighted his behavior.
> So, the last option for the Rust developers is to take it to social media.
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.
The C maintainer in question had no power to stop the code from being merged, it wasn't in his directory. He was tagged as a courtesy in case he wanted to do a drive-by review since the code was wrapping his subsystem. The Rust code being reviewed wasn't written by marcan, and the other Rust developers called him out for taking the argument to social media when the code was likely going to be merged anyway (see https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phen... and https://lore.kernel.org/rust-for-linux/CAPM=9tzPR9wd=3Wbjnp-... ).
The fact is, you need buy in from other devs and if a dev won't buy in you need to work out a way to avoid them or avoid conflict. It sucks, it slows things down, but frankly making it a "them vs us" is a sure fire way to make them oppose any change you want to make.
Public shaming even more disastrous as there's no better way to entrench someone in a position.
I'm not entirely convinced they meant to truly make a public hall of shame.
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.
> However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.
> Because if we have issues in the kernel development model, then social media sure as hell isn't the solution. The same way it sure as hell wasn't the solution to politics.
To me, it sure sounds like Marcan is making the case that they tried other venues, didn't feel like it worked, so they resolved to using their social media following to shame kernel developers if they didn't stop.
But the point is that the Rust developers have tried literally everything else.
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.
Don't know what to tell you. The C developers have the keys of the kingdom. It's up to the rust devs to appease them. When you are a new-comer to an old project a big part of that is working with the current gatekeepers to get your changes through in a way they'll accept. That can sometimes mean doing things sub optimally in your view.
In particular, the DMA maintainer didn't want rust code in their DMA subsystem. That sucks, but it means you need to relocate your dma bridge code out of their subsystem. It does mean your driver will be a second-class citizen in the kernel tree (which was always going to be the case for rust).
Linus' reaction was to someone who started a public campaign against another kernel developer and tried to use that following to pressure the maintainers of the kernel to bend to the will of the newcommer. I'm sorry, but I'd also have a pretty negative reaction to that.
The workplace equivalent is you publishing a whistle blowing article against a team in your company because they'd not accept a pull request you worked very hard on. You don't do that. You handle things internally and privately and sometimes you tell the boss "sorry, I can't get this done because another team is blocking the change and they are unwilling to work with me".
And do not mistake my post. I'm not siding with the C dev just because I'm critiquing the rust dev. Guy sounds like he's too stuck in his way. The problem is you don't get a big well working and long running project like the kernel without having these sorts of long-term maintainers that make the calls and shots on what to reject.
>In particular, the DMA maintainer didn't want rust code in their DMA subsystem. That sucks, but it means you need to relocate your dma bridge code out of their subsystem
The code was never in the DMA subsystem. At no point was there ever any Rust code in the DMA subsystem.
CH didn't even look at the patch before throwing the wall up. When it was pointed out that the patch already was the way he claimed he wanted it, he came up with a 2nd excuse, and then when that avenue was shut down he said he would do anything to stop Rust being put in the kernel, period, he wouldn't work with any Rust developers and he wouldn't accept adding a second maintainer for his subsystem that would do that engagement either.
From that point it's pretty clear that all previous engagement was just in bad faith.
> The workplace equivalent is you publishing a whistle blowing article against a team in your company because they'd not accept a pull request you worked very hard on.
The workplace equivalent is your CEO making a public statement that your work is to be supported, then not firing people who openly gloat about their intent to sabotage your work.
I mean, I hope that you'd get fired for trying to publicly shame people who you see as trying to "sabotage" you in any normal corporation, regardless of how much your vision aligns with the CEO's lol.
Not that it even makes sense to call it sabotage considering that most people that were involved in the original debate (in the rust for Linux side) didn't see it like that, that the normal kernel development processes were on their way to actually make the change happen anyways, and that Marcan's actions probably did more to sabotage actual support from other maintainers and Linus himself than the original NACK that started all of this ever did.
(Not that Linus ever even gave a blank check for rust on Linux, so I don't think that disagreements and even NACKs are somehow going against what Linus decided)
NACKs of bad Rust code, or Rust code that you don’t want in the system that you maintain, would be fine. The specific NACK at issue here was a NACK of code that used a maintainer’s API from a language that he didn’t like, which Linus has confirmed is not allowed.
> Maintainers like Hellwig who do not want to integrate Rust do not have to. But they also cannot dictate the language or manner of code that touches their area of control but does not alter it. The pull request Hellwig objected to "DID NOT TOUCH THE DMA LAYER AT ALL," Torvalds writes (all-caps emphasis his), and was "literally just another user of it, in a completely separate subdirectory."
> "Honestly, what you have been doing is basically saying 'as a DMA maintainer I control what the DMA code is used for.' And that is not how any of this works," Torvalds writes.
> Torvalds writes Hellwig that "I respect you technically, and I like working with you," and that he likes when Hellwig "call[s] me out on my bullshit," as there "needs to be people who just stand up to me and tell me I'm full of shit." But, Torvalds writes, "Now I'm calling you out on YOURS."
> The leader goes on to state that maintainers who want to be involved in Rust can be, and can influence what Rust bindings look like. Those who "are taking the 'I don't want to deal with Rust' option," Torvalds writes, can do so—later describing it as a "wall of protection"—but also have no say on Rust code that builds on their C interfaces.
> "Put another way: the 'nobody is forced to deal with Rust' does not imply 'everybody is allowed to veto any Rust code.'" Maintainers might also find space in the middle, being aware of Rust bindings and working with Rust developers, but not actively involved, Torvalds writes.
> If the C developers make it a "Them vs Us" thing, there IS NO ALTERNATIVE for the Rust developers.
There is always an alternative. Exit the project quietly and gracefully if Linus won't show proper leadership. Don't engage in poor behavior back at the C developers, that is just as wrong.
It's deeply ironic that he's complaining about kernel maintainers supposedly forming secret cliques.
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.
Having an alter-ego is one thing, but I strongly suspect that he had at least one sock puppet here during the drama with HN [0]
* a brand new account suddenly appears, defending Marcan's behavior (the only comment/post ever of this account) with a very similar writing style
* Marcan immediately "notices" the new comment while doing "random search" (how ? he claims he doesn't browse HN, and even posted a screenshot of news.ycombinator.com being routed to 0.0.0.0 to block his own access to it the day before)
* Marcan highlights the comment in question on his media account [1], praising them "at least [this commenter] gets it"
Only circumstantial stuff, but sure smells very fishy to me.
Reminder that he did this on the Linux kernel mailing lists. If I was a Linux maintainer who found out that two of the people I'm talking to, are actually with high likelihood the same person secretly maintaining a charade, I wouldn't be far from banning both.
I also certainly wouldn't take any of his complaints about cliques or brigading with any seriousness or self-reflection afterwards.
This subject also gets inexplicably downvoted and flagged every time you bring it up on Hacker News (look at that, it just happened to my original post); but again, nobody can prove otherwise, and Marcan himself has never denied it, only thrown flames.
Wow, what an uncharitable read. Are you aware of what that term means? He said it was not about literally shaming people, but showing what contributing to the kernel is like, and even clarified it wouldn't be for public consumption. It's a colloquialism for a resource where peers can learn from each other's mistakes. My high school Spanish class had a hall of shame.
It's a magnitude more professional than the extremely over the top and public emails that Linus shares, which HN jerks off over. I too would be burnt out if people were picking apart what I said so closely but clapping when Linus says "this code is retarded"
Yes I'm aware of that quote, which doesn't make sense to link with the original quote because his intentions with the "Hall of shame" are different from this quote.
This message brings up a lot of valid complaints about talented developers being stonewalled and you're honing in on one word that is not being used the way you think. Again, there are dozens of emails from Linus that are vastly more unprofessional than this.
My complaint is not that this maintainer would be charitable in their reads or should stay on the project, but that they are unevenly being examined because they are not one of the greybeards.
If you don't want a maintainer, that's fine, but to claim it has anything to do with professionalism is dumb when this is seen as communication to admire.
"hall of shame" inherently means it's about literally shaming people. If that isn't what he meant, then he shouldn't have used those words.
> 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.
Brigading has no place in open source communities. There are some members of the Rust community who believe C is obsolete and that C programmers should either switch to Rust or get out of the way. This is an extremely toxic attitude that has no place in the Linux kernel!
The fact remains: Rust doesn’t solve all of C’s problems. It trades them off for a whole lot of new problems, many of which are challenging to address in a kernel development setting (and much less of a problem for userspace software).
This makes the “C is obsolete” position even harder to defend and ignoring the concerns of long-term kernel maintainers is not going to get anywhere! I think these folks ought to learn the lesson of Chesterton’s Fence [1] before continuing on their journey to promote Rust, which does a lot of great things!
> Brigading has no place in open source communities.
Agreed.
> There are some members of the Rust community who believe C is obsolete and that C programmers should either switch to Rust or get out of the way. This is an extremely toxic attitude that has no place in the Linux kernel!
Would you care to share some examples of the Rust for Linux community who have said this? I'm unaware of Hector or anyone else saying anything similar? Or is this just a fear of yours?
I think we should be very clear -- believing the future of systems programming is mostly memory safe isn't the same thing as saying "C programmers should...get out of the way".
I didn't say Rust for Linux community, I said Rust community. Here's an example [1]. You don't have to search online forums and mailing lists very long to find countless others like this.
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.
I'm quite familiar with both, and Phoronix is much worse. Imagine the worst of flagged/downvoted HN comments, and even worse than that, but instead of being flagged/downvoted, they're just one more comment, which begets replies and further trolling, and gets treated as a fixture. "Oh, there's X again."
> You don't have to search online forums and mailing lists very long to find countless others like this.
So -- you're bothered by people on the internet, but not specifically the Rust for Linux people or the Rust project people? I guess -- I'm sorry people are saying mean things about a programming language on the internet?
There are also just as many (more!) anti-Rust partisans out there too, who say lots of crazy stuff too. I'm not sure there is much to be done about it.
> 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.
So what? Does your C code still run? I'm struggling to understand what the problem is. People are free to think whatever they want, and, if they what to rewrite things in Rust or Swift or Hylo or Zig or Java, that's how many of them learn!
People are free to think whatever they want, and, if they what to rewrite things in Rust or whatever language, that's how many of us learn!
Yes, they're free to rewrite their own projects in Rust. They aren't free to force others to do the same to their projects. That's what this is all about: a prominent R4L community leader tried to use brigading and shaming to force a Linux kernel maintainer into accepting and maintaining Rust code (along with the entire toolchain to support it). The maintainer refused, Linus got involved, and marcan stormed out of the room.
This isn't a debate about technical merits. It's a debate about maturity and what's appropriate for collaborating with others (and what's not). The Rust community has been going through a lot of growing pains over this issue for a while now.
>Yes, they're free to rewrite their own projects in Rust. They aren't free to force others to do the same to their projects. That's what this is all about: a prominent R4L community leader tried to use brigading and shaming to force a Linux kernel maintainer into accepting and maintaining Rust code (along with the entire toolchain to support it).
Nobody tried to force Christoph into accepting or maintaining Rust code. This was stated repeatedly.
I don't see how you can possibly have actually read the discussion and come to this conclusion. At this point you're just making false accusations and contributing to the flamewar.
They're offering to maintain it themselves but that's not good enough for long-term maintainers. It's like when a teenager brings home a puppy and promises to take care of it. The parents know that they will be the ones looking after it eventually.
I wish I knew of a less condescending analogy but I think it gets the point across. The list of former kernel maintainers is extremely long. Anyone who leaves the project, as marcan did, leaves all of their code for someone else to maintain. This is not a problem for drivers which can be left orphaned. For all other code it is a problem!
You're imposing your own rationales on top of CH, not expressing his own.
He expressed complete opposition to having Rust anywhere in the kernel at all, including places he doesn't maintain. He was opposed to any other maintainer deal with Rust for him, even though Robin Murphy (who is already a reviewer on the DMA side) expressed willingness to do so. His initial replies were an exercise in goal-post-moving.
The kernel is not CH's project. It's not his call to reject things he doesn't like anywhere in the kernel, including places he doesn't personally maintain.
Since Linus backed him up on this issue I’m left with the impression that Christoph is not a lone maintainer standing in the way of the inevitable march of progress; that his concerns are valid and shared by the founder and leader of the project and represent the views of other maintainers who preferred not to step into the ring on this debate.
Furthermore, the Rust code depends on his C dma code. That automatically makes it Christoph’s problem when something breaks, regardless of how many R4L maintainers come and go from the project.
If you're forking the Linux kernel then it becomes your own project, de facto, since you're taking over maintenance of the fork. You're free to rewrite it in Rust when you do that!
Where is anyone forcing anyone else to do a rewrite in Rust?
When hellwig likened the R4L project to a cancer, he was implying exactly this. He saw this one patch as a Trojan horse (in the original Greek sense, not in the computer virus sense) to get Rust into the main kernel tree. This brings all of the toolchain and language issues into it. By relegating Rust to drivers only, the kernel maintainers avoid the issue of having to maintain a cross-language codebase and toolchain, whether they like it or not.
Being a maintainer of a project that accepts patches from contributors is like operating an orphanage. Allowing anyone to just drop off their unwanted babies results in an unmaintainable nightmare. You can say that the Rust for Linux team have been acting in good faith but the very public actions of one of their (now former) leaders contradicts this. The stated goal of the project was to allow drivers to be written in Rust. Adding Rust bindings to the kernel oversteps that goal. It's a legitimate concern.
> The stated goal of the project was to allow drivers to be written in Rust. Adding Rust bindings to the kernel oversteps that goal. It's a legitimate concern.
You do recognize that all drivers will need to bind to some C interfaces? So -- your argument (or the argument you suppose Hellwig has) is that it is better that each driver author recreate each such interface for themselves? Now, when these interfaces break as a result of a change in the underlying C code, instead of fixing that breakage at possibly a single place, that one true binding, now a maintainer might have to fix that breakage in a dozen such places? And this is preferable? This will cause less work for the overburdened maintainer?
You are aware this patch introduced no code into the main kernel tree?
It doesn't have to. By becoming a single point of failure for all Rust drivers that depend on it, it becomes the responsibility of all maintainers of the kernel to avoid breaking it when they change the C interfaces. It's a foothold into a world where all kernel maintainers need to run and test Rust builds, something Christoph does not want the headache of dealing with.
When your teenager brings home a puppy and promises you he'll never let the puppy leave his room, you know that's not true and it won't be long before you're the one taking care of it.
Ultimately it's about motivations. Long-term kernel maintainers are motivated to protect and promote the kernel as a maintainable and successful project. R4L developers, on the other hand, seem more interested in promoting Rust than promoting Linux.
>> You are aware this patch introduced no code into the main kernel tree?
> It doesn't have to.
Ah, it's one of those other kinds of Trojan horses that don't enter the city walls.
> By becoming a single point of failure for all Rust drivers that depend on it, it becomes the responsibility of all maintainers of the kernel to avoid breaking it when they change the C interfaces.
So -- I'll ask what the Rust for Linux people asked Hellwig -- what is your suggested alternative? Where do we go from here? Is it Rust drivers not be allowed to common interfaces ever? In that case, what are the Rust for Linux team doing?
Or is it that you would like Linus rethink his decision re: adding Rust to the kernel? And if so, why didn't Hellwig make that case directly to Linus? What's with all this performative bellyaching on the LKML?
Ah, it's one of those other kinds of Trojan horses that don't enter the city walls.
The kind that have to be invited in, yes.
So -- I'll ask what the Rust for Linux people asked Hellwig -- what is your suggested alternative? Where do we go from here? Is it Rust drivers not be allowed to common interfaces ever? In that case, what are the Rust for Linux team doing?
That's not the kernel team's problem. They provide a common C interface. The fact that there's an impedance mismatch with binding to them from Rust code is a Rust problem.
Or is it that you would like Linus rethink his decision re: adding Rust to the kernel? And if so, why didn't Hellwig make that case directly to Linus? What's with all this performative bellyaching on the LKML?
I don't know what Linus's goals are, apart from keeping his maintainers happy and keeping the kernel rolling along smoothly. That's not a small thing. From what I can see, Christoph has been a maintainer for over 25 years.
Does Linus want to have his cake and eat it too? Sure. But I think he earned that right by building Linux into what it is today. The R4L team hasn't paid their dues. As someone else mentioned, it took 10 years for Clang to become a supported compiler for the kernel.
>Would you care to share some examples of the Rust for Linux community who have said this? I'm unaware of Hector or anyone else saying anything similar?
In fact, he said that as his very first reply to that thread:
>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.
> In fact, he said that as his very first reply to that thread:
I think it's clear from the surrounding context that you are likely over-interpreting some of Hector's comments.
What is the losing side of history here? There is simply too much C code in the Linux project to say "stop this ride, I want to get off and only use Rust" right now. This is a fight about some new code. Rust drivers in kernel and perhaps in the future Rust in other places it makes sense. I believe Hector's arguing Rust drivers are inevitable, because they are already here!
What did I say above:
> I think we should be very clear -- believing the future of systems programming is mostly memory safe isn't the same thing as saying "C programmers should...get out of the way".
As I read it, "the losing side of history" refers to insisting on using C, possibly at all. The last part about the "world moving forward towards memory-safe languages" doesn't suggest a limited scope for the statement.
The thread was not about Rust drivers, it was about adding Rust code to the DMA module. I.e. about mixing two different languages in a single module, thus requiring being knowledgeable about both languages in order to maintain it, thus making the module less maintainable. In fact, a few developers were saying that they didn't mind Rust drivers, if they used the C ABI as-is. Someone wanted to expose new Rust-specific interfaces to support cleaner abstractions from Rust drivers.
> The thread was not about Rust drivers, it was about adding Rust code to the DMA module. I.e. about mixing two different languages in a single module
AFAIK this is false. The patch was CCed to the maintainer as FYI, but all the code was in a Rust a module binding to the C DMA interface. If I'm wrong, show me the code.
>I'm just going by what was mentioned in the thread. If that interpretation is wrong, the thread makes no sense.
You've now discovered why this blew up in the first place. All of the excuses used to reject the code were not just petty but also outright false, and trivially so.
My impression is the average Zig programmer is more interested in making a better Linux than trying to prove Zig can be used in Linux.
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.
Aside from hatred of Rust and Rust developers there is a bigger problem. The Rust guys are twisting the C developers' arms to iron out API semantics because there is so much behavior and API usage that can't be defined in C and it's driving C devs insane. The Rust people are doing the right thing but doing the right thing is extremely annoying for the C devs.
The last drama wasn't about the guy not liking drama, he just don't like nor want to maintain a codebase with two languages, but I think they really need to say it directly instead of calling it canser and leaving people to think he was calling rust cancer and not multiple languages codebase cancer
Im pretty sure he specifically said the cancer was trying to inter-op 2 languages in a code base and not Rust. Even went on to say that he thinks Rust is good and recommends people implement new Greenfield projects in it.
> What does social media have to do with bad code, though?
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.
I disagree. Provoking up a mob on social media will not endear you to anyone. You're just making the gatekeeper's jobs harder, and since their job is hard enough, they will simply gatekeep you to simplify things.
Regardless of whether you think the project should be maintained differently, that's not your call, that's their call. Fork it if you want different policies.
Isn't that also what Linus is doing but on a professional forum, which is even worse? The issue comes down to de-escalation, and there wasn't enough on both sides. It's also not unreasonable to expect more from a figure head who is a role model in open-source development in general.
A maintainer's job is to keep contributors on track and in line so the project moves in the right direction, and he did so on the forum in which it's supposed to happen. Not sure what the issue is.
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.
Your comment has nothing to do with someone trying to ironically gatekeep me from commenting on Linus' public behavior in response to my comment about gatekeeping.
Oh, bullpucky. People are hostile towards you because A) you employed ludicrously tendential wording, and B) when this was pointed out to you, you refused to own up to it -- or, more probably, to even realise or acknowledge it to yourself. In stead you went on to whine about "gatekeeping".
This kind of rant is typical of the public behaviour of the (typically young and "woke") modern social-media "developer" crowd, and your behaviour here only illustrates why so many dislike them. If there are any "hive mind effects" here, they're in your mind.
Not to mention stalkers ? Doesn't matter how much you love a community, one or two psychopaths can maybe it simply not-worth-it.
It's hard enough in physical spaces to remove abusers (usually the abused just stop showing up), I can't imagine there's an answer for preventing this kind of behavior in online spaces
If you want your code merged in the kernel, you have to think about things from Linus' perspective. You cannot in any circumstances try to shame someone into adopting an enormous and unsustainable workload.
The linked article doesn't say the submitted driver code was awful. In fact, it says Paragon submitted the driver after Linus suggested they submit it.
What the article quotes Linus complaining about is a process issue. Paragon apparently used GitHub's GUI to merge some of their branches rather than the git CLI. Linus would prefer they use the CLI to merge branches because the GitHub GUI reportedly omits important metadata from merge commits, such as the developer email, and encourages uninformative commit messages.
As that kernel maintainer clearly stated this was not because the code was awful, but because the code was written in Rust and it was therefore cancer.
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.
You’re right, it’s mostly any open source code projects too. I’ve tried to contribute to projects where they ignore my merge request and take my code and merge it in under their own account. I call this behavior “demonstrating the moat” in which the Maintainers are more concerned with maintaining a moat around their project that they actively go out of their way to prevent contribution under the guise that your contribution did not correctly cross the moat. Even if the moat is mostly decorative and ceremonial.
Then turn off merge requests if you don’t want your project accepting contributions. Remove your CONTRIBUTING.md. Stop being welcoming if all you want to do is show off your source code. Don’t have a document explaining that I need to sign an agreement to contribute.
