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

So the smackdown from Linus is what motivated it. Honestly though if you read the email Linus is replying to, it was deserved. To be fair, Hector Martin may be one of the smartest hackers alive today. His fame goes way back to hacking the Playstation 3 with geohot and Hector has even found security vulnerabilities in Apple Silicon. He's done great work with Asahi Linux by weaponizing his keen penetrating mind to support open source freedom. But like his buddy geohot he can be a bit childish. Right now Hector seems to be laying low. His social media accounts are no longer accessible. It seems even archive.org and archive.today have no recollection of him. That's impressive.

So what triggered him to act out of character? It seems like he wrote his Apple GPU driver in Rust and he needed Rust DMA support in the kernel. I know, a curious thing for a Rust developer to want more power to do things that are memory unsafe. So the DMA maintainer Christoph Hellwig hates Rust. He thinks Rust is a cancer in the kernel. Cristoph refused to help Martin create Rust APIs for DMA. That's why he went ballistic.

Chances are they'll all make up when this blows over, or someone will just rewrite his GPU driver in C. There's not going to be as big of a push for Rust with this recent government. For example, the White House recently took down its paper about the future of programming being memory safe. The money for Rust is going to dry up. It's becoming socially acceptable to push back against efforts to convert everyone to Rust.

No, he tried to prevent other people from doing the work to create Rust APIs, and said that he would do everything in his power to prevent anyone from doing it.

They took down all of https://www.whitehouse.gov/oncd/, what makes you think they gave any thought to this paper in particular?

Did he really NEED it? Why he couldn't use the C API?

I'm not disagreeing as I don't know what exact things you're talking about, but I find "virtue signalling" and "communication" to be very similar terms these days. From statement to statement I'm not sure what anyone means by that phrase anymore.

But generally I do like to wait to understand specifically what someone means before assuming.

It's easier to name the major Linux FOSS projects that DON'T have drama and virtue signaling than the ones with.

If you read the Github comments on System-D, GNOME, etc, it's like watching children bickering on Sega VS Nintendo.

Turns out FOSS devs are humas just like everybody else and suffer from the same flaws.

Hell no. FOSS communities, as other spaces created by permanently online individuals, definitely have higher-than-average number of mentally unhinged snowflakes.

It is rather anticlimactic. I had always imagined FOSS to be this free exchange of ideas, thoughtful consideration, and intentional action. Seeing what it has become though… Maybe closed source is better.

At least in some cases this is plausible. The money people get for working on closed source software irons out some issues, for example:

Some people who voluntarily work on open source code do it for self-actualization, which indicates that they have a strong desire to push their wishes through. This implies that a lot of drama gets involved if these people don't get their way.

Was it ever different? Not as far as I can remember at least. I think one of the main strengths of open source development is that it works despite the drama.

With open source projects, everybody is free to start their own fork over disagreements, and if the fork actually turns out to be objectively better it will replace the original project.

> Maybe closed source is better.

It's the same and worse over there, the drama just isn't public.

At least you’re getting paid. What’s the point of spending one’s free time arguing with strangers on the internet over some code that will be refactored anyway ten years from now..? Life is short, have fun, enjoy it. If you’re spending time or money on something that sucks, walk away.

Of course, with notable exceptions. See Apple Car, Android tablets etc.

You thought it was better in the past? Read up on the great ncurses maintainer drama. Or the NetBSD/OpenBSD split. Or FreeBSD/DragonflyBSD split. Or the Emacs forks, GNU libc forks, GCC fork, etc. etc. etc.

This kind of drama has always existed. Difficult people have always existed. And even good people have always been struggling with their emotions.

And in all my closed-source $dayjobs I've had to deal with all of that too. Sometimes significantly worse than I'm seeing here.

I assure you it isn't; it really, really isn't. You don't see the drama because 1) it's behind closed doors and 2) because the people involved know their job is at risk if they cross the line.

I've had similar pissing matches in closed source development, instigated by me and not...

Often, these things get resolved or left simmering without any public visibility, so that's nice as a user. And there's usually a somewhat clear heirarchy of authority, where the boss can say I don't care who's right, do X; which resolves issues in ways that sometimes a technically minded open source project can't; that can often help with bikeshedding between usable options.

But sometimes you just keep working somewhere because deep in your heart of hearts you want to do it your way, and once that other person quits or maybe even goes on vacation, you can. And sometimes people endeavor to actively push that person out, which I guess I've seen on FOSS drama too, but office politics have a way of lurking under the surface more, IMHO.

I haven't met a single Rust developer that this description didn't apply to. Starting to think it's not just a coincidence.

Is your theory that rust makes people dramatic? Or that dramatic people like rust? What other options are there, if not coincidence?

There is a cognitive bias called "loyalty to the brand", in which it says that people prefer the things they have because they rationalize their choices to protect their sense of ego. When they invest time (or a lot of money) to something, they create an emotional connection, especially if that was a choice and not something imposed on it. It is choosing one thing about the other that leads to narratives about why you have done a certain thing, something that is usually connected to your self-image.

There are a number of cognitive trends that converge to create this behavior. This assignment effect appears when you feel that the things you have are superior to things you don't have. Another bias is the fallacy of irrecoverable costs. This happens when you spend time or money on something you don't want to have or don't want to do, but you can't avoid. For example, imagine that you spent time studying Rust. You will be "hooked" on the idea that given the time spent in this, it is better to defend the language, even if you imagine that it is not for all things.

To combat post-decisional dissonance, the feeling that you committed to one option when the other option could have been better, you strive to feel justified as to what you selected to reduce the anxiety created when questioning himself. All this forms a gigantic group of neurological associations, emotions, details of self-image and trends around the things you have.

I think it is a human trait to like to win arguments. In some card games, there is a thing called a trump card [1]. The trump card has this special ability to beat all other cards.

Rust has a kind of trump card: memory safety. If you get in an argument about code it is often possible to maneuver the argument in the direction of memory safety at which point the Rust advocate gets to default win the discussion.

I think this "trump card" aspect attracts a particular kind of person to advocate for Rust simply because they like to feel technically superior to others. Whenever they are in an argument, no matter what the context, they simply have to play the game: how can I make this technical argument about memory safety so that I can win by default.

1. https://en.wikipedia.org/wiki/Trump_(card_games)

Thus, instead of drama, we get meta-drama, i.e. nothing has changed.

Both, really. As a language that was designed from the ground up to be a replacement for C and C++ (thus implying that it's superior to these established languages), it positions itself as inherently "dramatic" and anti-establishment.

This obviously attracts these political activist types who love to insist that their way of thinking is the way forward, that everyone else was simply doing it wrong before they came along, and that anyone who questions their beliefs is an obvious enemy of progress who should be silenced at all costs. It's a cult, basically.

Aren't these diametrically opposed? Virtue signaling is loudly claiming to have some virtue in the absence of that virtue. Hector has receipts, in the form of commits, as proof.

Virtue signaling would be me appearing on the mailing list and spouting my beliefs.

It was a fine position to take back when introduction of Rust into the kernel was still very much a discussion point. However, the discussion is over, Rust has been accepted into the kernel. This entire struggle has been kernel developers sabotaging other kernel developers.

This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything.

That said, using social media to cause drama when a Linux maintainer is being an ass is just as stupid, if not worse. Both sides of the conflict are in the wrong here.

Suppose you want Rust, just not a single Rust driver using PCI. But CONFIG_PCI and CONFIG_RUST both selected will cause the PCI abstractions to get built anyway, even if not a single driver using them is selected. Then if the PCI subsystem introduces a change but the Rust counterpart fails to follow it fast enough, the build will break for the kernel as a whole.

This was illustrated with an example in that email thread.

I have some sad experience with polyglot projects. Unless you enjoy pain and drudgery, it’s an extremely unrewarding thing requiring very careful treading.

Well, this is your take, as you explicitly wrote "I walk away with the feeling". My take is: The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things. If too many people aren't happy with the way the linux kernel is developed, they are free to fork it and develop in the way that they see fit.

Luckily, the kernel seems to be doing fine.

Both sides of the argument are kernel developers here, though.

And that particular side was told by Linus Torvalds himself that his way of Social Media brigading is inappropriate for kernel development, and that the current process works.

I choose to believe Linus. His work on and guidance of the kernel used to and still does work pretty great.

We're talking about a developer, and a persona they created. Yes, they haven't outwardly said they were one and the same but it's pretty obvious. There's nothing to joke about and no feelings to be hurt here.

The DNS for asahilina.net points to the same servers as marcansoft.com.

Their KDE setups are oddly similar (the same).

The list goes on. Is it circumstantial? Sure...

Or it could mean that they're close friends? Seems like extremely weak grounds to go around claiming with certainty that they're actually the same person. Hell, I have people in my life which this would almost describe: people whose Linux system I helped set up and whom I host infrastructure for.

Could they be the same person? Sure! But why the hell are people going around confidently stating that they absolutely are, based on such weak evidence? If my sister had stuck with Linux when I helped her install it some years ago, you could literally use the same evidence against me.

If it quacks like a duck...

They had a falling out some time ago, but let's check in on what Lina's co-creator is saying today on Twitter:

https://x.com/LunaFoxgirlVT/status/1887896920732876819

> It's the worst kept secret in history that I had to keep alive, I have no interest in keeping it alive anymore.

> I mean, Lina started as an april fools joke on Marcan's youtube channel

https://x.com/LunaFoxgirlVT/status/1887897472527458689

> So yes, Marcan is Asahi Lina, Asahi Lina is Marcan. It's not a secret, it never really was.

> Only really became one when Marcan found out he liked vtubing.

And if you don't like Twitter, Luna is also saying it on Bluesky:

https://bsky.app/profile/lunafoxgirlvt.foxgirls.gay/post/3lh...

> My abuser (asahi lina/marcan) is a Linux kernel contributor.

The first line of your Google document, written by "Asahi Lina", confirms it straight up:

> Unfortunately, on August 1st, Luna publicly: Doxxed me with a real-world identity

You should verify that reference for yourself, archives of what Luna said are readily available on the internet. I can confirm that what Luna said on August 1st, 2024, is the same thing she's saying today: Hector Martin is Asahi Lina.

The dossier corroborates Luna's claims.

(Also, what kind of person has a dossier ready to go if their contributor goes rogue? A controlling and manipulative person, that's who.)

We don't know who "Jia Tan" is, nor "Jigar Kumar", but we know that the person, or group of people behind these identities and others, used sockpuppetry to bully Andres Freund into giving them control over xz-utils, and we know what they did with that access. Even if pseudonyms are accepted, there should be zero tolerance for sockpuppetry in the Linux Kernel. If Hector Martin quits (https://lore.kernel.org/lkml/20250207-rm-maint-v1-1-10f069a2...), the personas/pseudonyms/avatars/characters of Hector Martin should quit too, but "Asahi Lina" continues to post on LKML.

When your argument is "a person said it so it's probably true", the natural next step is to ascertain whether that person is credible or not. That's not an instance of the ad hominem fallacy.

You know this.

You also know the document you linked affirms that "Asahi Lina" (not a real person) did not like being "doxxed" on the date that Luna said Asahi Lina was Hector Martin.

What I take from that is Hector Martin wrote the document. Do you disagree?

The document you brought up says "Unfortunately, on August 1st, Luna publicly: Doxxed me with a real-world identity". On that day, Luna said Asahi Lina was Hector Martin. Discuss.

It doesn't refer to providing the WRONG identity, as that wouldn't break their pseudoanonymity. You, hananova -- are the QUEEN OF FRANCE! Did I doxx you or not? I don't believe I did.

You can't have it both ways. Either Hector Martin is Asahi Lina (which he is), and Luna revealed this to Martin's chagrin, and Martin published a document to try and trash Luna's reputation as a clumsy attempt at damage control, or Luna didn't reveal Martin's barely-concealed secret and no need to publish the document.

By publishing the document, we know which interpretation is correct.

Eventually a lot of these people are going to age out, retire, or otherwise move on. I do think there will be a crisis moment at some point in the future.

You need some extraordinary evidence to claim things like that.

To stretch things a bit, it's like saying, while male dominated the field of engineering in the 60s (and still do), it was exactly that kind of environment that made it possible for humans to get to the moon. Can you actually prove it? Really?

It's hard for me to imagine using git will slow down kernel development compared to sending patches in emails.

No. It's a legitimate possibility. Maybe it wont happen. But maybe it will. There's a reason that military training is meant to be hard though, and not filled with comfort and affordances for personal feelings.

> To stretch things a bit, it's like saying, while male dominated the field of engineering in the 60s (and still do), it was exactly that kind of environment that made it possible for humans to get to the moon. Can you actually prove it? Really?

No human has been back to the moon since that male dominated field sent them there. And when they added women, they couldn't produce a shuttle that could work without huge budget overruns, or reliably. And the only example of a real surge in a return to space, is run by an asshole dictator at Space X.

> It's hard for me to imagine using git will slow down kernel development compared to sending patches in emails.

No, that definitely worked out great. It was created by a gruff guy who was an asshole to everyone, and wrote the basics of Git by himself in a week.

the issue here is whether or not the broader community would ever seriously consider using an alternative, and whether contributors, particular commercial ones writing drivers for products, would ever agree to maintain two versions.

I used to know C. It was my first language, and I spent a fair bit of time in it, but that was before compilers started to treat undefined behaviour as an excuse to break reality.

Arguably I'm not smart enough, or disciplined enough, to write C. This may be the case, and therefore I have naturally focused on other languages. Rust, to no-one's surprise, is my current favorite. I've never contributed to the kernel — for more reasons than just the language — but the language would be reason enough on its own.

C programmers are getting rare...

There’s plenty of people who write C, there’s plenty of newcomers who start writing C and if they’re willing to, they can find guidance, mentoring, and tooling to improve their skills. If that’s not the path you want to pursue, that’s fine. But C isn’t going anywhere soon and if you go to any university/college, there’s lots of C being taught and lots of people eager to learn.

It's not. Certainly not until Linus says it is.

> Rust has been accepted into the kernel.

As a limited experiment. This kind of drama may be an indication that the experiment has failed and should be rolled back.

After that, Greg KH stepped in (since he was soft asked to help earlier in the thread with an @) to reconfirm that what seems to be the general policy for r4l is followed (aka it'll be a separate file with its own maintainer), with the subtle implication that it would probably just get merged as a separate patch to Linus directly, the complaints of the maintainer be damned.

Marcan's sudden outburst and forcibly adding Linus and Greg to the thread he was responding to came afterwards. You can even see some other rust4linux devs asking him to please not do this, since the situation is under control.

Does it do much of anything to solve the fact they've publicly declared that they are going to do everything they can to stop the project, and that there's a history of them doing just that going on for years now?

Marcan's response clearly wasn't the most productive way to raise these issues, but the issues are there and are not being addressed.

Hellwig is a jerk, yes (probably crosses a few lines), but there's a procedure that sidelines him and his mention for this patch was a mere courtesy (since r4l maintains the wrappers and they're not even kept in his folder).

Marcan's insertion in the thread is extremely overblown and as someone in the thread notes, comes across more like a several hours late cavalry to appeal to his social feed. I have a slightly "nicer" interpretation of it than that (in that I don't think Marcan is that kind of person) since it reads like it's probably just the sort of rage best reserved for a private message to a friend, but he's making it everyone else's problem by threatening social media brigading (which is plain and simple: harassment and unlike Hellwig's rudeness, extremely easy to identify as something to push back on).

About the Rust code itself; the primary issue was code duplication rather than preventing the use of Rust altogether. Since the suggested code is not merged, every driver needs to write the same code over and over again. That was also something that the maintainer suggested himself (?). There is of course a big downside, but I am not sure if this justifies all the hate.

The Rust code is not in the area he was currently maintaining. Christoph didn't even look at the patches before objecting to them. Once it was pointed out that they were not in his area, he rejected them anyway.

Note that, because they are not in his area, he does not actually have the authority to do this. He was CC'd in an advisory sense, it's not really his call to accept them or not, and as a longtime kernel maintainer he surely knows this.

Once the wrapper is written, any breaking changes he makes in the DMA subsystem will, by their very nature, percolate downstream to the Rust wrapper and then to any Rust code that relies on it.

So basically from that point forth, he will always have to consider the ramifications of his changes on another group of developers, and deal with any backlash those may cause.

Is he being unreasonable? I tend to lean on the side of "yes," but I can certainly empathize with his point of view (not necessarily his approach, however).

They reiterated that in the thread too.

Obviously the maintainer does not trust the Rust people, but they also did nothing to gain his trust, but the opposite.

Just saying "Trust me, or else I will shame you" is not a viable strategy.

The default position of any code maintainer who sees some people coming and saying that they would maintain from now on some parts of the code and that there should be no worries about that, is to not trust them immediately, but only after enough time passes during which they demonstrate that they are really competent and not just claiming to be so.

Besides, none of this was said. Hellwig did not say "I do not trust you enough". He said "you are cancer, go away". First is harsh, but at least somewhat reasonable (in the sense that it _can be reasoned with_); second is not reasonable at all. Your interpretation is excessively charitable to an obvious bad-faith actor.

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

https://lore.kernel.org/rust-for-linux/20250128092334.GA2854...

That's totally, utterly different than your characterization of it.

(So many other people were also falsely claiming that he said it like that, I initially assumed it was true, so I'm a little irritated.)

> You might not like my answer, but I will do everything I can do to stop this.

You might not like the response for being strongly worded but it is indeed backed by a technical stance and not a political or social one as has been repeatedly suggested. Already overworked maintainers are not willing to sign up for additional maintenance to what has been a solved problem. Objectively, no one should disagree with that stance.

It is not a technical stance. It is a project management one.

> Objectively, no one should disagree with that stance.

That is exactly why the maintenance burden is not his problem. He is under no obligation to take any additional work here.

Will you feel this way when the ruling eventually comes down that the Rust for Linux experiment has been declared a failure? Referring to what is currently an experiment as a decision is a rather bold misrepresentation of the current state. You want to present Rust in the kernel as a foregone conclusion when the reality couldn't be further from that.

> It is not a technical stance. It is a project management one.

Unstable infrastructure becoming a bottleneck is project management? Maybe a working implementation of Coccinelle for Rust should have been among the criteria before the experiment should have been allowed to proceed. That would have precluded the years of furor this has otherwise caused.

> That is exactly why the maintenance burden is not his problem. He is under no obligation to take any additional work here.

This highlights the crux of the issue and the reason your bias is clouding your view of the issue objectively. You are operating on the belief and trust of the small amount of Rust developers. Reality is proving otherwise time and time again.

Yes. What Linus says goes. That's how Linux works.

> Referring to what is currently an experiment as a decision is a rather bold misrepresentation of the current state.

It has been decided that having Rust in tree currently is acceptable. That is not a misrepresentation.

> Unstable infrastructure becoming a bottleneck is project management?

That is not the argument, it is a reason the argument is being made. The argument being made is "Linus should not have allowed Rust in the codebase." That there are technical consequences to project management decisions is not surprising, and they can be good or bad, but it's not the direct objection here, it's a reason why the objection is being made.

> That would have precluded the years of furor this has otherwise caused.

He himself said that he is unilaterally opposed, full stop, and nothing will change his mind. The state of Coccinelle wouldn't make any difference.

> You are operating on the belief and trust of the small amount of Rust developers.

I am taking Linus at his word.

But he didn't say "rust is a cancer", "you are a cancer", "your work is a cancer", or the other permutations of that I've read in this long thread; that's what I was replying to.

His technical assessment doesn't make sense, and apparently isn't even his to make. So that can, and should be, rebutted and refuted. But not by distorting his words, by attacking the substance of it.

(Which I do acknowldge that you have been doing; I've read the entire HN thread, so kudos for that.)

> (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).

Where the cross-langauge in this case is Rust. Rust for Linux is creating a cross-language codebase. That means Rust for Linux is cancer.

> and not rust itself, just to escape the flameware brigade

is like when people say "I'm not trying to be rude, but" and then says an incredibly rude thing. Saying "I think this abstract idea is cancer, and you're the specific instance of this abstract idea, that doesn't mean I'm saying you are the thing" is incoherent.

If I actively participate in and align myself with a community that is committed to doing the $thing, and you come and say to me that "$thing is cancer", or that "the fact of doing of $thing is cancer", then it's functionally equivalent to insulting this community, and by extension to insulting me. In other words, it's clearly supposed to make _me_ feel bad (for pushing $thing, or participating in the doing of $thing), regardless of the precise wording.

It's still an unprofessional, uncooperative, and _unreasonable_ thing to do.

But this is Linux kernel development. You just can't be such snowflakes, and so quick to be outraged. My mom died young, of cancer. I don't like cancer. I know that using "cancer" as a metaphor is a very negative way to characterize anything.

But the qualifier he added in the original statement is absolutely enough to make it a fair comment.

He really, really doesn't think using multiple programming languages is a sane approach. Would you really feel better if he said, "I think a multi-language approach is a very bad idea, it will inevitably spread, and it will end up causing systemic problems far away from this initial usage, and make the kernel increasingly frail and unhealthy over time" ?

If so, ... weird?

If not, then I think you are overreacting to the blunt (but technical, if perhaps motivated from some more emotional response) that he really doesn't like this idea at all.

"Cancer" is an appropriate shorthand to refer to a practice that you think causes systemic harm that compounds or grows worse over time. (I'm afraid I myself may have used it to describe PowerPoint presentations as the basis for meetings.)

I think his comment meets the minimal etiquette bar for a serious technical discussion. I mean, it wasn't nice. But the fact that he doesn't agree with you, or like your work, isn't an insult.

> He said "you are cancer, go away".

I find this absurd mischaracterization of what he said a lot more unacceptable than what he actually said. He's bluntly stating his technical opinion (which, again, I don't agree with). But you're not paraphrasing; you're basically lying.

Yes, I absolutely would. Because this statement is neutral, specific, and technical (if unfounded, so I'd feel even better if such a statement would have been supplemented with justifications), therefore it can be attacked, argued, and refuted point-by-point on a technical basis. No such thing is possible when technical concerns are replaced with emotionally loaded metaphors.

So yes, I stand by my belief that saying "$thing is a cancer" when talking to someone who is good-faith committed to doing $thing is 1) unreasonable (because it cannot be reasoned with), and 2) an insult (because it is designed to appeal to emotions rather than facts).

And yet you keep defending Hector.

That doesn't sound like he's only talking about in his area to me

This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up.

For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believes it is unfair to force every C maintainer to learn enough Rust to keep their integration points working.

For the second solution, the C maintainer is pointing out that Linus has a history of refusing to merge C patches that break Rust builds. So even though the Rust advocates promise they will handle all of the Rust stuff and they are OK with their stuff being broken after C changes until they get around to fixing it, Linus doesn't seem to actually allow for this in practice.

I can see the maintainers point. Sooner or later Rust bindings on critical systems will be essential and changes to the C code will be gated on changes to the Rust code. It is a fantasy of the Rust maintainers that they will have to shoulder that entire burden. But even if they did, it would give them some pretty hefty leverage over the C maintainers in those essential cases. And it also introduces a requirement that someone with enough Rust and subsystem knowledge is even available for the job. People making promises today may disappear tomorrow, leaving the maintainer with an essential binding to a language he doesn't want to support.

edit: as has been said elsewhere, Linus could make some of this go away by committing to let the Rust builds break. I don't know if that could be done in a way that wouldn't be a de facto fork.

As an outside observer, literally no skin in this game, I can see his point. If his C code changes breaks other C code then he is at an advantage compared to if his C code breaks a Rust binding or Rust drivers. The degree to which this adds to his burden of maintenance is up to him to decide.

As for less work, that is alternative two from my original post which states the maintainer now has to wait for someone else to do the work or risk his change being stalled. It doesn't matter if the R4L team promises that they are OK with broken Rust code since the only person whose decision matters is Linus. Until Linus clarifies his stance on broken Rust builds the promises of the R4L team are promises that they are literally incapable of delivering on.

> he will still be contacted for information regarding these things.

Just like any other user, and he is free to ignore them just like any other person doing so.

There’s 2 kinds of scenarios here:

- Rust code involved: C code change breaks Rust. ~Send~ ~an~ ~email~ ~and~ move on.

- C code involved: inform other C devs, either work with them or wait for them to fix.

The way I see it, either way, the “Rust stuff adds unacceptable amounts of workload” doesn’t really check out.

Edit: turns out he doesn’t even need to inform the Rust devs.

This isn’t blocking any drivers. Just adds duplicate code.

Linus already did that. This is the state of things today. C code is allowed to break the Rust, and it's the Rust for Linux people's responsibility to get it working again, not the C folks.

To be fair, I think another valid solution to this problem is just to bite the bullet and tell the grumpy C developers to deal with it. At some point the fallout from an exodus of grey beard Linux maintainers will actually be less than fighting this battle. As many point out, they are going to exit the project one way or another eventually.

From what I understand, this is correct, or at least that is, this was a build system bug that caused accidental breakage, not a deliberate change in the policy that the kernel must be able to be built with Rust support turned off, and that that is the build that matters. Exceptional in a "rarely happens" sense and not a "deliberate choice to create an exception to a rule" sense.

I don't think this is proven: what we have is a specific group of Rust developers, but they are there by virtue of that group existing. There are numerous more kernel contributors today who work in C, and since the greybeards are happy to keep up the work it's not like anyone else is going to easily step in to replace them (since it would be a coup not a handover, if they didn't actually want to step down).

An equally plausible future is some such Rust mandate happens, you drive off the existing C developers, then it turns out the Rust developers aren't actually numerous enough or committed enough (or even good enough at long term project social management) to keep the project going and it dies (or forks into CLinux or something).

Linux itself was a "hobby project" which ultimately succeeded because it did the work which needed to be done, while everyone else was still completely sure the microkernels were the way of the future.

The R4L says they will make sure the Rust code is fixed when the C code is, and that's admirable, but the concern it means a developer now has to wait for that, holding up their work for release/submission. The bus factor is now on the R4L team.

Meanwhile, everyone involved in development for Linux already knows C.

They do not have to wait.

My assumption is that it's easier to train someone on rust then to train someone to be a kernel subsystem maintainer

Much like the “don’t rewrite from scratch” mantra was written in blood and tears.

Linux is free software and there's really nobody stopping people from forking it and doing things the way they want. It used to happen all the time once upon a time, nowadays people seems to be afraid of doing it.

If all the latest commits in C are so useful, even to a Rust fork, perhaps the Linux C devs are not off-base that Rust isn't worth it for now.

I wouldn‘t expect a grand Rust announcement anytime soon, above what has already been said. Rust in the kernel seems to be fine, but it will have to adapt to longstanding kernel processes. And if it means there won‘t be Rust in some maintainers‘ subsystems, so be it. The kernel won‘t be 100% Rust next year anyway.

That said, I'm going to agree with Linus there: Cancel culture ("social media brigading") isn't the solution.

(Edit: Ok, reading some other context, it seems like this is indeed what's happening, which does make this reaction a little less justified. I can certainly see why it's no fun to have people in the project saying they will do whatever they can to stop an initiative, but if they aren't actually able to block it, then it doesn't seem worth quitting over)

That said there's an outstanding question about whether Linus would accept something that breaks Rust builds for merge. Linus hasn't commented on this yet, but I'm sure he will.

I think people who write C should stop unless it's to fix security bugs and should do something else, anything else, maybe even learn about programming. But even with this mindset Linux is a C project and the R4L folks promised to thread the needle, if it cannot be done this time, then it cannot be done this time. They need to wait.

That's pretty harsh. C has provided so much value to the world and security isn't the most important thing in the world - functionality is. Not saying security isn't important overall though.

And also, imagine another Rust competitor comes up in 5 years called "Moose" and M4L comes up, competing with R4L?

... but I'm aware that it's simply not realistic. These are raw thoughts not "working policy" . My problem is that old software is just barely functional (huurah, we achieved the barely standing equivalency from civil engineering) and we are not spending enough resources on that, nor on security.

And probably my Linux honeymoon period ended after ~10-20 years of work (and/or personal) use, and I feel every point of Marcan's letter, even though I never did kernel development, only the usual troubleshooting and trying to figure out which bug/patch/feature has what status.

But, of course, as long as this blessed circus continues to deliver every ~3 months a new version with this velocity it'll keep going. And Linus is right, if we don't like it maybe (:p) it's on us to accept that. And also maybe Drew's humble suggestion will be the prescient one.

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

https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-...

If Moose is better I expect people to fairly consider it, and when the consensus forms that yes it's at least as good as C then I want the C people to realize their own responsibility in maintaining critical infrastructure, and I want them to at least have a plan on how to improve, because even in civil engineering the baseline for "barely" has increased a lot over the past decades. (And of course in many cases arguably society has overshoot that, for example with the 2-stairs requirements and so on, where these concerns drastically disincentivize evolution of population centers and transportation networks.)

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

On the other hand, I once ran into an issue with uboot where a bad update knocked out my emmc, usb and sata controllers... found an email address of someone developing the dtb files and got in touch with them, and it was fixed in under a week.

At the end of the day, people are weird sometimes. I wish all the best for marcan.

I think they expect people who want things to advocate harder than just mentioning it once. If no one brings it up again, then they assume that no one cares.

Should probably have just asked again, or sent a small one-line patch. It's "mention something on Slack" vs "creating a GitHub issue/PR"

Have there been any recent popular developments on a similar workflow that is as robust as e-mail ?

I'm not sure how long GitLab can be trusted either, as well as git becoming a bit too synonymous with GitHub...

What? PRs or issues being forgotten happens all the time, especially for large projects.

They did take months to finally land, and the whole process of getting my corp email address to be compatible with their email-based PR system was way more of a faff than it had any right to be, but they did land. You can install mainline Linux on a Legion Go now and the display and controller will behave as expected, out-of-the-box.

I cannot claim to have felt the effects on the maintainer-side of this workflow in large-scale projects though.

Suppose you find a bug in the kernel and come up with a patch. You email the patch to some kernel mailing list and ask for feedback. Typically, you will receive no response whatsoever, because no-one is responsible for responding. You can try emailing random developers and eventually maybe one of them will have mercy on you.

In Firefox and I think Chromium, you can file a bug, attach your patch, request review from someone (the UI will help you choose a suitable person), and it's their job to respond.

In Firefox you have to fiddle with Mercurial, phabricator, and their homegrown CI. In Chromium its Gerrit and their homegrown CI, and oh btw you touched code that lacked tests so tag, you're it.

Firefox and Chromium's bespoke tools have their pluses and minuses but they're a lot easier to deal with that the kernel "workflow".

I still remember the story where some other guys had to meet some Mozilla folks for lunch and nag them for reviews…

In Firefox, in my era at least, a reviewer who simply ignores a review request indefinitely was not doing their job and would get yelled at by someone --- me, if it came to my attention.

And he's not just abrasive He's a troublemaker. Seriously, code of conduct violation? It was perfectly clear what Hellwig meant by "cancer".

I think the conversation is more about people equating R4L as validation for rust or even themselves.

I agree it's rude, offensive, and hostile, but there are degrees of things and context matters. "You are cancer" would be much worse. I feel we should try and interpret things in good faith and maintain some perspective. For a single word like this: you can just read over it (which is also what the other Rust people did).

Certainly outright removing Hellwig from the Linux project, as Marcan suggested, is bizarrely draconian.

As I argued a few days ago: part of "being nice" is accepting that people aren't perfect and dealing with that – https://news.ycombinator.com/item?id=42940591

He said: “ 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).”

  H: I don't want to support multilanguage codebase
  R: We'll have a maintainer verify R4L is behaving properly.
  H: I solved issues because they were unified.
  R: Rust will be mirror of whatever C is, and you're free to break it, R4L will maintain it.
  H: No.

And to clarify I'm not saying he's right or wrong or acting good or bad. I have however expected R4L to ultimately fall apart because of this exact issue, the maintainers have never been on board with maintaining Rust code and that hasn't changed. While that remains the case the project is going to be stuck at a wall - to the point that if they're confident they can maintain the Rust code themselves they should just fork it and do that. If it works well enough they'll eventually be too popular to ignore with people choosing to write their new modules in Rust instead.

it is never about a certain language or the maintainability of the kernel - it is all about keeping his power being the maintainer who can randomly reject other people's work without providing any technical justification.

two easy and practical solutions here -

1. start maintaining the rust part as well

2. stop being the maintainer

There is an argument that being hyperbolic, dismissive, and maybe a bit rude isn't as bad as some people make it out to be, and that it is a fine way to hash out disagreements and arrive at the best solution - that it is simply a result of the passion of exceptional engineers. There has historically been much of it in kernel development. But it seems that as the background and culture of kernel maintainers has broadened, that a more measured and positive approach to communication is more constructive.

It doesn't seem like marcan exemplifies this very well either. It is a loss for someone so skilled to abandon collaboration on the kernel, and seems like the unfortunate result of someone being dismissive and rude, and someone else taking that harder than is warranted or healthy.

Stange, I think interpreting it your way requires bending the mind. Hellwig clearly used it to describe what he sees at the ill effects of multiple languages in the kernel. It was not used to describe either Rust the language or this specifically this particular submission.

Instead of providing helpful advice like outlining the current situation and suggesting specific improvements (action A, task B, and goal C) to reach the goal, it feels rude and offensive.

The only helpful advice, which they did give, is don't even start doing this because it's fundamentally wrong.

The linux kernel is like a house where everyone is a vegan. Marcan believes that incorporating some meat in the diet is important, and better that being a vegan. He may even be right. But so what? He makes his pitch, the family says that's nice but no thanks. He then demands that they eat this chicken because he wants to live in the house and wants to eat chicken while living in the vegan house?

I don't see how he has any right to what he wants, and I don't see an existing kernel devs refusal to cooperate, or even entertain cooperating, as automatically wrong or unreasonable.

While I think this a dumb metaphor, it's also incorrect in this context. The Linux kernel explicitly supports C and Rust code, and there are very clear parameters to allow for Rust code to be integrated into parts of the kernel.

Or in other words, the decision has already been made to allow meat into the vegan household, and now one maintainer is explicitly blocking a package of meat from entering the building, even though it has already been decided from on high that meat should be allowed in.

This isn't quite accurate, though, because of the unnecessary metaphor thing. Reading the original mailing list chain all the way through and talking about these events directly is completely sufficient here. The patch was reasonable within the parameters set out for the R4L project. The maintainer of this subsystem blocked it explicitly because they disagree with the idea of R4L in general (calling it a cancer).

The question is not whether or not R4L is a good thing or a bad thing - anyone can have their own opinion on that. R4L is part of Linux, and will be for the foreseeable future, until it either clearly demonstrates its use, or clearly demonstrates its failure. The question (at least as regards the "cancer" comment) is whether it is okay for a maintainer to describe another team's work as cancer, and to publicly block it as much as they can.

If they are overstepping, then Linus will make that known. Until then, apparently they are not overstepping.

And he can use that image if it communicates the concept he wants to communicate.

It sounds like a valid image to me to apply to the concept of polyglot.

He is saying that "If there is really no way for a rust driver to exist all by itself without any of the c code having to do anything special to accomodate it, then so be it, I guess rust doesn't fit here after all."

rust devs are saying "you're not even helping a tiny bit!". I am saying, no, they're not, so what? They don't have to. They did not request what rust devs are trying to do.

The concession rust devs got to proceed to attempt to use rust in the kernel at all doesn't promise almost anything beyond "well you can try". It does not promise to facilitate that try at all really.

It was used to describe the Rust for Linux project, as well as any other potential efforts to bring other languages into the kernel, of which there are none. It is clear why someone working on the Rust for Linux project would feel that "this cancer" refers to the project that they are working on.

I'm not trying to pull out pitchforks, I don't want anyone to burn. I just want people to collaborate effectively and be happy, and I think it is empirically clear that calling something that grows/spreads and that you think is bad "cancer" is not useful, and only inflames things. It is not an illuminating metaphor.

No, it is not perfectly clear.

The generous interpretation is that they meant it is "viral", spreading through dependencies across the codebase (which I don't think is technically accurate as long as CONFIG_RUST=n exists).

The less generous way to interpret it is "harmful". The later messages in the thread suggests that this is more likely.

But I'm left guessing here, and I'm willing to give some some benefit of doubt here.

That said, the response to this comment was incredibly bad as well.

Q: What would make you even more happy with Linux? GregKH: If you contribute to it.

Why the hell would I wish that upon myself?

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

Personally, seeing

> Being toxic on the right side of an argument is still toxic, [...]

written unironically, on social media, immediately after that person wrote @marcan

> and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off

leaves me feeling more sympathetic to marcan's argument about the kernel being full of toxic attitudes, not less. Maybe public shaming isn't the answer but there's a problem here. Maybe don't make comments like that on social media if you want to criticize people for leaning on social media in kernel disputes.

This seems like a tu quoque fallacy. The feedback is either applicable or not, regardless of who said it. They're absolutely correct that Being toxic on the right side of an argument is still toxic.

Even if there is hypocrisy (whether judged by you personally or someone else), it wouldn't invalidate the point.

Certainly in context, this seems fairly reasonable: https://chaos.social/@sima/113961283260455876

Yeah this isn't about "being civil" or "friendly" and even less about "don't call out". This is about calling out in an ineffective and imprecise way, so that the people actually trying to change things are busy patching up your collateral damage instead of implementing real changes, while all you've achieved is airing your frustration for internet drama points.

When you're that harmful with your calling out, eventually I'm going to be fed up, and you get a live round shot across your bow.

And if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off.

Or as Dave Airlie put it upthread in this conversation: "Being toxic on the right side of an argument is still toxic, [...]"

So please do call out broken things, do change things, I've been doing it for well over a decade in the linux kernel. But do it in a way that you're not just becoming part of the problem and making it bigger.

---

And this is not the first time something like this has happened with Marcan. He may be tired of the Linux devs, but many of them are also tired with him (including some of the people working on Rust, it seems).

And this is part of a conversation on what went wrong here, not an attempt to rally the troops. You really can't compare it to Marcan's stuff. This kind of (selective) demand for absolute perfection is really not great.

If true, then it sounds like there are some “missing stairs”[1] (the professionally difficult kind, hopefully not the other kind) in Kernel development.

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

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

However it seem that you need to disable js as soon as the content load or it will be overwritten by a 404

Linus was right to reprimand him for the suggestion.

Harder to understand and contribute is a bad, but unless there is a proposal for a similarly flexible system that has minimal downsides and massive advantages, the preference of existing maintainers should dominate over potential future contributors. Especially factoring in how expensive of a migration it would be.

Linux is so ubiquitous & important that might never happen, maybe it will just become increasingly captured by corporate contributors who can at least build long lasting repos of knowledge and networks of apprenticeship to help onboard newbies. Open source in name only.

it sounds the opposite of optimized to me. Unless we're optimizing for something other than developer experience and efficiency?

It's almost like there are more important goals wrt software development.

Any change introduces anomalies and those cause all sorts of hell.

I won't contest that there are advantages to the linux Kernel's workflow, but there are downsides too, and a major one is that it scares off potential contributors.

That said GitHub definitely is far from perfect as well, and has different strengths and weaknesses from email based flows. As do any other options.

But just because there isn't currently anything that is unilaterally better doesn't mean things can't be improved. There is clearly a problem with onboarding new developers to the linux workflow. That should be acknowledged, and a solution sought. That solution doesn't have to be switching to GitHub or similar. Maybe there just needs to be better documentation on how to set up the necessary tools, that is oriented towards developers used to the Github process. Maybe there needs to be better tooling. Maybe the mailing lists need to be organized better, or have the mailing list automatically add metadata in a standard, machine-readable format to emails. Etc.

obligatory reminder about breaking someone's workflow https://xkcd.com/1172/

I'm grateful the kernel still supports MIPS, which means an old appliance of mine still works perfectly fine and is upgradable. I would be cery sad if someone were to rip-out support of an old MIPS arch, just because it's old and unwieldy

The first few times, it took me longer to figure out how to send a patch than it did to fix the bug I was writing a patch for.

That’s seriously lame.

Then I talk to the old timers and they act like I just need to get used to it.

And why not?

- Distributing patches via email is more scalable than web hosting. Even GitHub could not host the level of activity happening on the LKML mailing list

- Web hosting has a variety of access and legal problems when working with international teams; email crosses borders more easily

- Email is a decentralized and distributed system that prevents any single company from controlling a project's development infrastructure (release infrastructure is another story, but multiple companies will generally manage their own release process anyway)

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

(not taking either side, just interesting to read the reply)

> You think you know better. But the current process works.

Regardless of how badly broken the kernel development process is, Linus and others observe that Linux continues to dominate and conclude that therefore the development process "works". Success in the market blinds the successful vendor to their defects. Sound familiar?

If Linux carries on down this path then eventually something else that has been subject to more evolutionary pressure will displace Linux, and we'll all be telling stories about how Linux got complacent and how it was obvious to everyone they were heading for a fall.

And honestly, with maintainers like Hellwig maybe that's what needs to happen.

The “in hindsight” version of how this should have gone without ego:

* Patch adds Rust bindings to C API

* Maintainer has concerns about increased maintenance cost and clarifies policy about C changes and Rust abstraction if unsure.

* Since R4L is approved, the binding is allowed to exist in a form that doesn’t inhibit changes to C API. C API is allowed to break Rust (I assume, otherwise the entire effort is moot).

* Any concerns about tooling etc which DON’T exhibit this property (and can demonstrably show that merging this Rust code will make C code harder to change) are brought up.

* These are resolved as a tooling issue before the change is merged (I don’t think there are any in this case).

All the discussion about multi-language projects etc is for the project as a whole to decide, which happened when R4L was approved and the breakage policy was decided (might need to be properly formalised).

If the maintainer (or anyone) is unreasonable, then the only approach is to have someone with more authority weigh in and make the decision to bypass their objections or sustain them (which is sort of the direction this was going before the diatribes).

> If the maintainer (or anyone) is unreasonable, then the only approach is to have someone with more authority weigh in and make the decision to bypass their objections or sustain them (which is sort of the direction this was going before the diatribes).

While they were arguing, Linus said nothing. While the maintainer was issuing ultimatums, Linus said nothing. Linus only said something when social media forced his hand. This is the real issue.

IMO, it seems inconsistent to green light R4L and not declare a clear policy for Rust code interacting with C code without adding a hard dependency (and if it WAS declared, not enforcing it).

The only benefit of doubt I can give is that there wasn’t enough time for Linus etc to weigh in before the thread got sidetracked (and the decision became much more politically charged). It’s unclear what would have happened if only the maintainer was unreasonable.

People are wrong in LKML often.

This time, somebody was wrong in a much worse way than usual.

My impression of a few glancing online interactions is that they're both abrasive but marcan is quite unwise in a way that Linus has had beaten out of him

No doubt that is a flawed summary so feel free to correct

Marcan is probably a little acutely upset not just because he was told off, but also because Linus hasn't waded into the actual issue at hand (which he needs to, not even Greg K-h can answer it). But that issue is less urgent and it's probably reasonable for Linus to:

a) Mull it over before making a rash decision b) let tempers calm.

I would guess Linus will wait til Monday and is probably also having some off-list chats anyway.

The statement that they were going to maintain this without the support of the DMA maintainer was made 22 days ago [1]. That statement was rejected 11 days ago [2]. Linus was explicitly asked to intervene 10 days ago [3]. (Too complete the timeline Hector Martin first got involved 4 days ago, Linus intervened about that yesterday).

I don't know why you think Linus will suddenly choose to address this Monday.

[1] https://lore.kernel.org/rust-for-linux/Z4kG5AcVeQKegLnb@poll...

[2] https://lore.kernel.org/rust-for-linux/20250128092334.GA2854...

[3] https://lore.kernel.org/rust-for-linux/Z5qeoqRZKjiR1YAD@poll...

https://lore.kernel.org/rust-for-linux/20250110083955.GA5395...

https://lore.kernel.org/rust-for-linux/20250128092334.GA2854...

https://lore.kernel.org/rust-for-linux/Z5qeoqRZKjiR1YAD@poll...

https://lore.kernel.org/rust-for-linux/20250204052916.GA2874...

https://lore.kernel.org/rust-for-linux/20250131135421.GO5556...

Note: I did not intend to particularly link to Christoph Hellwig comments, it just so happens that these contain enough quoting form previous answers to trace out something coherent.

For the complete context, you should walk up/down (and laterally) the thread to get more details and make your own opinion of it. It doesn't take very long.

Hector wasn't the developer of this patch. However, he is a user of it. He has had some rough interactions over the last few years. And so seeing this happen (even though it's happening to someone else) is a "the straw that breaks the camel's back" kind of deal.

I read it as “look at this shit” and general frustration with the likes of DMA-guys behaviour.

As a pilot program, R4L should have graduated or ended a long time ago. After several years of active development, its status remains unclear. Instead of cracking heads to get everyone on the same page, Linus has instead spent all this time sitting back and watching his subordinates fight amongst themselves, only to then place responsibility for the drama on Martin's shoulders. Poor form.

Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor, but he hasn't said anything explicitly. Maybe he knows he should, but he fears the shitstorm it will cause. Maybe it's time for him to rip off the band-aid, though.

And again, all of this could have been avoided if he'd just put his foot down one way or the other. Imagine how much time and energy (even just Martin's alone) could have been saved if Linus had just said "no, keep it downstream".

You're reading way too far into this. Linus has been publicly positive about the R4L project plenty of times.

Why spend all this energy on conflict and drama to no end? If one language/technology/group is so much better then just fork the thing and follow their own path.

I'm actually not defending the C guys, I just want to leave them alone and let "Nature" take his course, if they die on obsolescence, then they die. who cares..

If the Asahi team focused their efforts on Redox, with all the genius talent they they have, we could see an actually practical, usable implementation of Redox on real hardware; a potential daily-driver which would catapult the development of whole ecosystem - and that can only be a good thing.

I am sure most people involved with the Linux rust effort are also not problematic; these would be very welcome there.

OTOH, please don't let Redox be taken over by problematic people.

Hard to have too much drama if you have a handful of developers that do code changes, and no users to complain about any of your decisions.

There have been UNIX systems implemented, Pascal, Ada, Modula-2, Modula-3, as the most relevant ones.

All gone.

Also note that POSIX/UNIX certification requires a C compiler presence.

Note that many folks even forget that C++ was equally developed on the same Bell Labs group, and is probably one of the first examples of guest languages, making their best to fit into the platform, taking advantage of the ecosystem with almost zero friction, but never being able to control where the platform goes.

I don't think I can go with that one. C was created in the same period as people were trying to find a way to create a common platform, but C was more about trying to solve the problem of having a higher-level language that wasn't available for the low-end hardware (ie PDP-11, etc) of the time. Richie wasn't trying to reinvent the wheel.

He would have been happy to use other languages, but they were either design for large platforms which needed more resources (Fortran) or looking to be locked behind companies (IBM's PL/I). Richie considered BCPL, which at the time had a design that made it pretty easy to port if your computer was word-based (same size of bit-width for all numbers regardless of purpose). But, mini-frames were moving towards byte-based data and word or multi-word-based addressing. Plus, mini-frames had poorer hardware to make it cheaper, so typing on them meant more physical work.

A lot of UNIX design came from trying to use less: less memory, less paper, less typing. Richie tried to simplify BCPL to be less wordy by making B, but ultimately decided to jump to the next thing by making a language that would require as few keystroke as possible. That's why C is so symbolic: what is the least amount of typing to perform the concept? That made it pretty easy to translate to a fixed set assembly instructions; however, it hasn't had a symbiotic relationship with assembly.

If anything, it is the reverse. Just look at the compiler for all of the memory addressing it has to know. Look at any reasonably complex program of all of the compiler directives to see all the platform exceptions. C++ really took failure modes to the next level. My favorites is "a = b/*c;" Is that "a equals b divided by value pointed at by c" or "a equals b" with a comment? I left C++ a long time ago because I could take code that would compile on two different platforms and result in totally different behavior.

I think all of this drama has to do with the simple fact of there a bunch of people content to live in a one-langauge dominated environment and the head of Linux doesn't want to decide if that is or isn't the mandate; however, by not taking sides, he has effectively taken the one-language mandate. Rust needs to reimplement Linux.

You surely aren't advocating that hardware predating PDP-11 for a decade are more powerful.

There is enough material that show had UNIX been a commercial product instead of free beer source code, most likely C would have been just another systems language in the mysts of time.

That's correct. The PDP-11 used for the first Unix system had 24KBytes of memory, and no virtual memory. The kernel and the current running process had to both fit in 24KB. This PDP-11 minicomputer was vastly underpowered compared to ten year old mainframes (but was also far less expensive). The ability of Unix to run on such underpowered (and cheap) machines was a factor in its early popularity.

BCPL was first implemented on an IBM 7094 running CTSS at Project Mac at MIT. This was one of the most powerful mainframes of its era. It had 12× the memory of the Unix group’s PDP-11, plus memory protection to separate kernel memory from user memory. One of the historical papers about C noted that a BCPL compiler could not be made to run on the PDP-11 because it needed too much memory. It needed to keep the entire parse tree of a function in memory while generating code for that function. C was designed so that machine code could be generated one statement at a time while parsing a function.

That is a really bizarre comment, especially including a comment that is perfectly valid K&R C, and just as "ambiguous" in that. The answer is of course that it is an assignment of the value b to a variable called a, followed by a comment. "/*" is always the start of a block comment.

Since C99 (and since forever in C++) there is also the new style comment, //, for commenting out the rest of the line, and this in fact broke certain older C programs (`a = b//* my comment*/ c;` used to mean a = b / c; in C89, and means `a = b` in C++ or C99).

As for the actual syntax itself, I do wonder why they didn't use ## or #{ }# or something similar, since # was only being used for the preprocessor, whereas / and * were much more common.

Or maybe he just didn't care about having to use whitespace to disambiguate. The other piece of similarly ambiguous syntax in B is the compound assignment, which was =+ =- =* =/ rather than the more familiar C-style += etc. So a=+a and a= +a would have different meaning.

As for C compiler presence in POSIX, only existence of C-accessible APIs with specific structure are mandated, C compiler is optional just like Fortran runtime and compiler are.

https://pubs.opengroup.org/onlinepubs/9799919799/nframe.html

https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...

https://pubs.opengroup.org/onlinepubs/015967575/toc.htm

And copying this from UNIX 03, the most widespread certification,

"A single configuration of the system shall meet all of the conformance requirements defined in the following mandatory Product Standards:

    Internationalized System Calls and Libraries Extended V3

    Commands and Utilities V4

    C Language V2

    Internationalized Terminal Interfaces

From POSIX 2017 edition https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...

> On systems providing POSIX Conformance (see XBD Conformance), c99 is required only with the C-Language Development option; XSI-conformant systems always provide c99.

If XSI conformance is not asserted, only requirement is that C APIs and runtime libs for use by C programs exist on the system, and presence of C compiler is optional,

2017 POSIX had done away with including Fortran 77 in the same category as C, only providing an option for Fortran runtime libs but no longer specifying a Fortran development environment.

Also, I do not have relevant systems on hands to check, but as far as I know multiple Unix systems including behemoths like SunOS/Solaris shipped as POSIX compliant without C compiler.

Naturally UNIX Home users are also using a UNIX, and UNIX Pro, users have anyway a C compiler.

Also to note, exactly because nothing else is required, there used to be UNIX vendors, like Sun, that only included C and C++ on their base SDK. Fortran and Ada compilers were additional products to acquire on top of the SDK. Naturally most folks didn't even bother.

Second, while OS X, and NeXTSTEP before it, are technically UNIX, they aren't seen as such by either NeXT, nor Apple.

The focus of the whole userspace experience is on Objective-C frameworks, nowadays also a mix of Swift and C++.

Steve Jobs was famously against UNIX culture, there was even a famous attendance of him at USENIX.

NeXTSTEP was based on UNIX, because Steve Job wanted to win the workstation market against Sun, using UNIX compatibility as EEE, bringing folks into NeXTSTEP and keeping them there with Objective-C development experience, Lotus Improv, Renderman and such.

So Embrace, Extend and Extinguish?

Linux was at the correct place at the correct time. It was the only free version of Unix-like OSes that didn't have legal bullshit to deal with. IBM and Intel's support also made GNU/Linux ecosystem successful, without them it would stay as an academic project. Being free meant that it had an advantage where price sensitivity mattered and dotcom boom and VC explosion is very sensitive to cheaping out and preffers suffering with less-than-ideal software. So Linux stayed popular while other ones died slowly.

C had a huge following and all OSes had to support it. Simplicity made it popular when average hardware at the hands of many academics and young professionals was very weak. Being written in C may have made things marginally easier but neglecting it for Ada or Pascal was a terminal mistake. Windows isn't Unix at all but it also had to support C well.

Had AT&T been able to sell UNIX, and naturally C, at the same price points as VMS, System 360, and many other contemporary OSes, and none of us would be talking about them today, other than history curiosities.

Instead we are left with UNIX haters handbook, and still trying to fix the security issues across the industry caused by C's adoption, the JavaScript and PHP of systems programming languages, both in adoption scale, and code quality.

Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined.

[0]: https://lwn.net/Articles/978738/

Maybe. 1. It may not have to be "Rust-level of safety" to be good enough to make Rust benefit less compelling. 2. Linux C is already a different languag than C, continued incremental changes might be a better way to get there than adding Rust even if it does become very different in the end.

> Also, if you're already doing codebase-specific patches to the language itself, many of the arguments around codebase portability that justify the use of C fall apart.

Sure, but Linux never had a "codebase portability" argument. It always had to be GCC C. It eventually made some relatively small changes to allow clang to compile it, the far bulk of that work being changing of clang to behave like GCC.

> Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined.

Yeah, it's not only safety improvements that are in Linux-C.

cough* Cargo cough* /s

You cannot have safety or security when you download your code from the internet and this code is a moving target.

There is, and this is how Rust naturally works. If you look at its standard library, you will see a lot of unsafe code or libc calls hidden away under safe interfaces.

In fact, this is how all memory safe languages work, including Java, Python, etc: A small trusted base written in an unsafe language that exposes a safe interface (i.e. the interpreter, the JVM, etc), with the large majority of the code written over that safe interface (i.e. the Java/Python code).

Rust is used to make kernel drivers secure by providing a safe interface for them to use.

Its exactly what Linus said.

That is actually quite well put together. May be The language that introduce absolute control also induces zealotry and produce zealots.

However that doesn't happen with Ada. So that cant be the full explanation.

For that matter the C of Linux 10 years ago was not there to stay either, it has changed and certain features and practices are deprecated and dropped and others adopted. It's not the same C.

Take, for example, an 8-bit/byte store. Without BWX the sequence would be something like:

        bic     a0, #3, t1
        and     a0, #3, t4
        ldl     t2, (t1)
        insbl   a1, t4, t3
        mskbl   t2, t4, t2
        bis     t2, t3, t2
        stl     t2, (t1)
        ret     zero, (ra)

        stb     a1, 0(a0)
        ret     zero, (ra)

People use and maintain them and they have very little impact outside arch/ nowadays so they're on the happy side of cost/benefit I guess.

I'm not sure if Alphas are even being made anymore, even 15-20 years ago.

Alpha's memory model has problems with providing atomic access to single bytes, which i'd imagine in a kernel is a bit annoying :-)

And then there's just the social aspect, m68k was used in the Amiga/Atari/Mac/QL/x68k, so there is a whole generation of us m68k fans who are willing to keep it alive.

Alpha has it's fans (me included!), but it's not exactly the same. So in a way it's no surprise it's slowly bitrotting away.

That required this smp_read_barrier_depends() through the kernel, but actually in recent years that has basically been subsumed by other concurrent access primitives that all the core kernel must use, so I think alpha is no longer much of a problem outside arch/alpha

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

> "suck it up, buttercup" or "I hear you; rust is gone".

where various levels of compromise happens.

Maintainers are people and people can change their mind over time. If rust was a huge success in large parts of the kernel and you still had a few holdouts, sure, you could tell them to adapt or go away. In this early stage, it's kinda up to rust people to show that both they and rust can work in this setting

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

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

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

And that's a perfectly resonable position.

Edit: For further context for Linus's reply, there's http://web.archive.org/web/20250206022420/https://social.tre...

> As for how to move forward, (...) Either Linus takes the pull, and whatever Christoph says is irrelevant, or he doesn't, and R4L dies. Everything else is a waste of everyone's time and energy.

It does look like maintainers should have a "disagree and commit" mentality at some point to whatever decision they end up making. I thought Rust in Linux was evaluated, discussed and agreed upon years ago. The fact that there are people still not trying to sabotage it shows that they don't follow the "disagree and commit" principle.

They are more like "disagree and make the others lives a living hell until they bend to my will".

It is not some million dollar RSUs getting vested by year end either way. A lot of them working for the love of craft and prestige. If they can just rollover on a technical disagreement then corporate office job is more suitable than open source OS kernel.

I've seen Linus talk about it in one of his public chats with Dirk Hohndel as an interesting experiment that might succeed or fail, or that's the impression I got. I'm not sure everyone else got that memo.

Marcan goes full nuclear every other time someone disagrees with him. He's very much the "if it's not my preferred way then we might as well not do it at all"-type of engineer (many of us have worked with those people).

DMA is needed for an overwhelming number of useful drivers.

If you can’t use DMA from Rust, then you can’t really properly evaluate the usefulness of Rust, hence the effort is basically dead.

Whether that's a good or bad approach is besides the point. It's what was suggested as an alternative, and clearly it's something that would work. "You can't use DMA from Rust" is just not true.

Everyone knows it would increase maintenance burden, decrease reliability, and increase the amount of apparent churn of rust code in the linux kernel.

There is zero good reason to duplicate that code and refactor it later.

A redundant wrapper is such a trivial mechanical problem to solve or work around, that failing to do so can only mean that the goal is unimportant, not worth that trivial effort. But they throw this ridiculous fit claiming that the goal is critical.

Which is it? It can't be both at the same time.

It's right in line with caring the tiniest bit about the email based workflow. I don't mean everyone has to like it, I just mean that even while not liking it, it's beneath remark next to the significant priority.

You're working on the cure for cancer and the medical journal requires your paper be written in codepage 437 not utf8. Yeah that's dumb but if you care the tiniest bit about that no matter how stupid it is, it is not the dumbest thing in that scenario.

What busywork did anyone dump on rust developers? Did I miss that day when the linux kernel approached rust developers and demanded them to put rust into linux?

Ridiculous. Go cry to someone less informed and more credulous about the meanies abusing the poor rust developers.

Regarding the context:

> A redundant wrapper is such a trivial mechanical problem to solve or work around,

The DMA maintainer explicitly NAKd a wrapper. He insisted that each Rust driver copy and paste the needed Rust code.

He even explicitly stated the reason was to ensure he did everything possible to keep C the only language in the kernel.

And after that driver is in use for a while and a million users all depend on it because it works so good, other developers will all on their own start asking "why are we diing this this stupid way? I think the original argument is no longer valid, or we can see now that it never was valid. We should revisit that."

Or as more rust devs work on more modules that each need some similar redundant boilerplate, a larger number of individual devs who each ask the same "hey, can we please get at least this level of concession to have a shim somewhere we can interface with instead of all this fragile tight coupling?" When that grows to become a respectful request from many, including users, instead of a disrespectful demand from a few, you get a different result.

But that is step 2. The opportunity for step 2 sometimes simply will not exist without first going through a step 1.

You want in? Yes but the terms are shitty. Yeah, so, you don't want in? It's obviously OK with most of the kernel devs if the rust devs decide this is not rewarding and go away. They are not eagerly welcoming to this particular development. And they don't have to be. How welcoming would rust developers be to c developers demanding to rewrite cargo in c? Go work on redox and make it so great it takes over and replaces linux by simply being the better choice while being equally free and at least as well managed and clearly visioned.

"Congratulations, you're right, and nobody cares."

Now what? Just complain that the kernel isn't hospitable to Rust, and hope 15 years from now we're all using some Linux-compatible kernel built ground-up in Rust?

I genuinely want to know where you go from this position.

I think Rust in Linux makes sense, but honestly, Rust doesn’t need Linux to be successful, and I barely use Linux personally. If they decide Rust for Linux is not a thing, that’s for the folks who work on and care about Linux to deal with. This isn’t my fight, I am just observing.

I’ve been primarily a Windows user for many years now, but I do use some WSL. My main OS is already shipping Rust, and in the actual kernel, without all of this wailing and gnashing of teeth. (That said I respect the approach Linux is taking here, I don't think it's inherently bad.)

Oh, and honestly, what I believe is happening here is just that, from Linus's perspective, folks should know that because this isn't in Hellwig's part of the tree, his NACK doesn't actually matter, and he'll just end up pulling this patch in anyway. There's no need to intervene because there isn't actually obstruction going on. The internet is just going wild about this drama because they fundamentally misunderstand how kernel development works, and because people are slinging mud on the LKML. That's why he only commented on Hector's behavior.

I can see that perspective, though I would prefer a different management style, but that's also why (among other reasons) I don't care to contribute to the kernel.

https://lwn.net/ml/all/[email protected]/

Maybe you can try to read what Christoph Hellwig said first.

Arguably, I've used it only once to contribute a kernel bugfix, and I was lucky enough that my patch got accepted as is. So I found the process pretty straightforward.

But even with iterations and revisions factored in, kernel work itself feels orders of magnitude more complex and cumbersome to me than a patch process based on a mailing list could ever be?

Just read the email.

His reprimand is a clear signal that he won't tolerate brigading. Marcan was making a pretty blatant attempt at using social pressure to influence decisions.

Oh and I got this quote for you:

> Linus Torvalds admonished the group that he did not want to talk about every subsystem supporting Rust at this time; getting support into some of them is sufficient for now. When Airlie asked what would happen when some subsystem blocks progress, Torvalds answered "that's my job".

Source: https://lwn.net/Articles/991062/

Do your job then, Linus!

No, never! That's actually one reason I don't use Mastodon, it's extremely common. Isn't this the guy that blocked HackerNews links to the Asahi Linux homepage because the moderators wouldn't do his bidding?

Maybe the problem IS marcan, as Linus suggested.

If you do things that are in the public interest, people are going to have opinions about what you do and on a wide spectrum. If you can't handle that, you probably shouldn't be doing work that's so public and visible. Especially something like maintainer work that is inherently social.

> A significant number of Hacker News commenters have repeatedly directed harassment, abuse, doxxing, and bigotry at multiple Asahi Linux developers, and much of this content remains available and not flagged or downvoted.

> At the time of this writing, a recent HN subthread of a killed comment contained replies including comparisons between an Asahi Linux developer and Hans Reiser, direct support for Kiwi Farms, doxxing content, and general insults and abusive assertions. These comments were at most slightly downvoted by the community, but still readable and not in any way killed or hidden by default. These threads pop up more often than not on Asahi Linux discussions on Hacker News; previous comments that again remain unkilled to this day include transphobic abuse, allegations of mental illness, etc.

There's criticism, and then there's outright harassment. I can't really blame them for not wanting to be subject to the latter.

Or is it just cause someone said so.

This is something you have to put up with some amount of if you do work in public, just like if you were a public figure or celebrity. Being a kernel or even package maintainer is like being a politician.

It sucks, but if your response is to cut off that channel of opinion _entirely_, that says more about you than the people you're silencing.

If something violates HN Guidelines, flag it and dang will see it. If there's anything that should be blatantly obvious by now it's that HN's moderation staff does not have the kind of alt-right bias suggested by your quote.

No, it isn't. It might be something that will happen if you do work in public but you absolutely, 100%, certifiably DO NOT have to put up with it. That is absolute bullshit of the "everyone should hear MY opinions" kind.

> if your response is to cut off that channel of opinion _entirely_, that says more about you than the people you're silencing

By this argument, someone leaving a room because they're being insulted to their face is somehow /worse/ than the people doing the insulting. Which makes no sense, does it?

Also denying links to their site isn't equivalent to "leaving the room". It's more like demolishing the room entirely, given the way that HN works. If your site can't be linked to it can't be the topic of discussion.

No-one is suggesting that. You can control whether you see them or give them more publicity though.

> Also denying links to their site isn't equivalent to "leaving the room".

True, it's more like locking the door to not let them in. Which, I think you'd agree, is everyone's prerogative if there's a constant stream of assholes coming through the door purely to shit on the carpet.

> If your site can't be linked to it can't be the topic of discussion.

Well, it can. It may not be as convenient as people like but then why would the target of abuse be concerned about the convenience for the abusive party?

It has nothing to with "not letting assholes in". Asahi Linux doesn't have a discussion board.

To your third point, also no. HN guidelines keep the content of our posts relevant to the topics they are in. They also guide us to link to original sources, not archive links. Both of these mean that if you can't link to Asahi Linux content, it can't be the topic of discussion unless for some reason it's otherwise newsworthy and was posted elsewhere.

How does blocking HN from linking to a site silence discussion on HN? Because, as you say, "100% of the discussion was happening on HN" which seems to imply that blocking HN from linking didn't actually silence the discussion.

> Both of these mean that if you can't link to Asahi Linux content, it can't be the topic of discussion

You can link to it - you just get the "HN referer" block page just as other people get other block pages (eg. [0], [1]. Haven't noticed people moaning about how those sites are silencing discussion on HN, mind.)

Copy and paste the URL and you can read the link perfectly happily[2].

[0] Much like many of us in Europe get block pages for sites in the US who can't be bothered with GDPR or the cookie law.

[1] Or those of us who aren't subscribed to the various news sites which show a paragraph before putting up a blocker.

[2] Or someone pastes an archive.ph link.

People whine about GDPR blocks and paywalls all the time. But also, clearly, those sites are not specifically targeting HN. It's not the same thing.

Why do we talk about Linus Torvalds being so cranky and ornery? Why can't we just talk about his programming talent and the tremendous impact he's had on the world of computing?

Why do we talk about John Carmack being nominally right-wing (by HN standards) and being close friends with Elon Musk? Why don't we just talk about him being a brilliant programmer and his work on Doom and Quake, with maybe the occasional mention of Armadillo Aerospace?

Why do we talk about Oppenheimer's communist party ties and adultery, and not just his work on the atomic bomb?

Why do we talk about Hector Martin's weird vtuber alter-ego and his tendency to stir up shit and start social media brigades? Why can't we just talk about his work on Asahi Linux and on jailbreaking game consoles?

And to answer your question of "who?", marcan themselves based on marcan being the one to block HN links.

But more generally, the majority of people posting online (especially streamers, content creators, even just twitter posters) these days seem to be very thin-skinned and will claim that any amount of pushback that they get for their words or actions is an organized harassment campaign.

[0] probably: https://news.ycombinator.com/item?id=33789940 , though you could look at any of the big 2022-2023 asahilinux.org discussions and find something flagged/dead

To respond to that by trying to cut of access to any place where many people exists is a questionable approach.

And judging people simply by from where they arrived in a place is also questionable tactic one that we should not tolerate in real live.

Otherwise I would suggest that it says a lot when downvoting of comments is not understood as disapproval. And that it is a big warning sign when public devs/maintainers hallucinate hostile intentions to other communities as a whole.

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

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

> And if you're wondering why you didn't realize this: It's impossible to change people by telling them they're wrong. What does tend to work is explaining different perspectives, so that they can figure it out themselves. And sometimes that's just way too subtle to ever register.

https://chaos.social/@sima/113961285815637787

> when you're that harmful with your calling out, eventually I'm going to be fed up, and you get a live round shot across your bow and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off

>or as Dave put it "Being toxic on the right side of an argument is still toxic, [...]"

(that second comment made apparently without any sense of irony re: the first)

The meaning of

> "Being toxic on the right side of an argument is still toxic, [...]"

Is very straightforwards. Toxic behavior is toxic behavior. Sima shouldn't lash out in "toxic" ways even if she thinks she's right.

Otherwise shouldn't Hector be given grace because "his buttons were pushed until he exploded"?

Like, you fundamentally can't have it both ways. Excuses for Sima's comments work for Hector. Condemnations of Hector's comments apply to Sima. Anything else is a double standard.

Sima's responses can be excused. Even Hector's initial frustrations and his reactions to it can be excused. Hector's continued public reactions and escalations, however, are a different story and the reason folks are piling on him.

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

Granted there are acceptable methods within that, and not acceptable.

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

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

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

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

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

Linux kernel maintainership is for skilled, experienced, and passionate C programmers, and any such programmer would have found the interest and time to become proficient with Rust in the past decade it existed for, given that Rust fixes most/all of the well-known problems with C and also provides a way to formalize memory-safe C code (as "downgrading" of Rust code) and is thus of extreme interest to any such programmer.

In fact, any good system programmer's reaction to learning about Rust's existence and the possibility of doing static borrow checking has likely been "wait, that's possible? WTF? how was this not done before if it's possible?!?" or alternatively "finally someone does this obvious thing" if they are very smart, followed by immediately learning everything about Rust and switching to it.

I mean, the whole reason for the existence and usage of the C programming language was the conjecture that it was impossible to make a zero-cost memory safe language, and once Rust proved that false, C immediately became obsolete and pointless to use in new codebases.

So if they can't be bothered to learn Rust, maybe retiring is more suitable for them than maintaining the Linux kernel.

Further, this attitude of "Rust is clearly superior, so what's the holdup" is itself a holdup. You can't expect people to just spend their time learning a new language just because it's there, especially professionals with personal lives. These people do serious work, on a codebase that millions of people around the world, including virtually every tech company, relies on in some fashion. That's not a game. It's "serious business."

Serious business doesn't just chase something because it's new and hot and solves a certain class of problems (while simultaneously introducing its own set of problems).

Nothing is a panacea (yet, I suppose). This ship has been sailing for 30+ years. So many millions of man-hours have been put into it that people are justifiably cautious.

Now, all of that being said, I read the DMA maintainer's comments a few days ago and I thought he was being unreasonable, however, he is correct about the external dependency on his code. Even if the Rust DMA wrapper is kept completely separate, under a separate tree, he would still have to contend with the fact that any changes he makes might influence that wrapper and all the code that depends on it. So now, even if they claim to maintain the wrapper 100%, he is still beholden to all those downstream developers that rely on the Rust DMA wrapper's functionality, because if he breaks their code, he knows it'll cause a shitstorm. It's easy to say you'll maintain something 100% and the upstream guy doesn't have to worry, but time passes, things change, and all of a sudden, his hands get tied because it'll impact too many people. That's just reality.

Truth be told, I would eventually suspect some (or maybe many) Rust developers will migrate to a new project, because the rate of change is not going to be fast enough to ever satisfy them. And that's understandable. People want to make an impact, especially when contributing to an open source project (and doubly so on an unpaid basis).

Unfortunately I don't think Redox is the answer. UNIX and its clones/derivatives have had a long run, but anyone who wants to create the next big thing is not going to want just another clone of UNIX, even if it is in Rust.

We have seen the enemy. We understand the threat models and know far more about virtualization, containerization, sandboxing, etc., just by virtue of having had to dogfood these technologies for the last 25 years.

The next big thing (if there is one), will likely be something more like a cross between the Windows world (where ACLs rule the roost, and centralized management is built-in), UNIX with its CLI focus, process composition & command familiarity, and something like L4 which has unforgeable capabilities built in and a formally verified kernel.

Or we'll just go back to a modern day version of the UNIX wars, lol. Something, something about history rhyming.

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

I understood/understand the representations, and I am sure they are made in good faith.

At the same time, I also understand the reality of having the things you do seriously impact the work of others and the types of issues that can cause.

I did state that I was leaning on the side of him being unreasonable, but also that I understood the concern. Nothing more, nothing less.

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.

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.

https://lwn.net/ml/all/[email protected]/

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

https://lwn.net/ml/all/[email protected]/

https://lwn.net/ml/all/[email protected]/

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]

[1]: https://lwn.net/ml/all/[email protected]/

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

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" :-)

[1] https://opendev.org/ttygroup/gertty

https://lore.kernel.org/rust-for-linux/20250208204416.GL1130...

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]

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

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.

https://pressbooks.pub/smallgroup/chapter/roles/

    > 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

https://geekfeminism.fandom.com/wiki/You%27re_the_bully

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.

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

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.

https://github.com/corollari/linusrants

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?"

https://github.com/corollari/linusrants

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.

[1] https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

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.

[0] https://lwn.net/ml/all/[email protected]/

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.

Exactly the point. IMHO the one and only thing that made Linux successful as a project is Linus' strong leadership - which has been criticized ad-nauseam over the years; yet it's the only thing that yields results.

So in the specific instances (like this one) where he's not decisively, unequivocally, and even harshly saying "yes" or "no" to something, the community shows a very clear incapability of reaching a decision.

Reminds me of a similar scenario that happened years ago with GVR stepping down as BDFL for Python - just after a tiresome and wasteful fight with the community's opinions.

"Community" is just a very naive ideal for me. There's a finite number of people that can do the job, and even a more finite number of people that can make a decision and stand by it.

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

In my opinion Linus was never abusive or disrespectful - just blunt and direct.

Unfortunately, there seems to exist people (like me) that would prefer such individuals instead of nice empty words just in case someone gets offended.

The way he spoke with Alan Cox was "not apropiate".

https://github.com/corollari/linusrants

What a bizarre reaction. I’m anonymously commenting on an internet forum, not taking you to court.

> Linus was never abusive or disrespectful

Comments like this support and enable abusive behavior.

> just in case someone gets offended

And this is just plain victim blaming, implying they’re being too sensitive.

Unfortunately, you are so egregiously wrong that it’s futile to engage in further conversation.

One of the main issues Torvalds says the kernel has is not being able to find maintainers. People don’t want to be abused while volunteering could be part of that.

Another possibility is that he gets paid over a million dollars a year by an employer, who will have some concerns over legal risks, reputation, etc.

As for his relationship with his employer — they both have the freedom to terminate it when their interests do not align anymore.

I genuinely struggle to understand where all the high expectations come from. Somehow people think that an open source project leader is obliged to be kind and polite and humble and understanding. None of these obligations exist as far as I can tell.

This is tragedy of the commons stuff, everyone is sitting quietly on the commons in a shared space, respecting the other people, and you drive your modified pickup truck through the middle rolling coal and blaring dance music and jeering "if you don't like it you can always move to another city" as if toning it down a bit is unreasonable but telling people to uproot their entire lives is reasonable.

> "Somehow people think that an open source project leader is obliged to be kind and polite"

Everybody is obliged to be kind and polite[1], that's one of the foundational parts of society - saying please and thank you, 'don't stare', consider the effect of your actions on other people - is kindergarten teachings; we all live in a shared space, and politeness is the grease that smoothes all the interactions between different peoples.

In any other situation, if a person has some power, authority or influence over people who can't leave or won't leave, and they immediately turn to abusing them just because they can, we would say that was bad. If a husband abuses a wife who can't leave, if a manager abuses employees who won't quit, if a religious leader abuses devotees, if a child abuses a pet, if a teacher abuses students, if a government mistreats illegal immigrants, we (society, possibly the legal system) would object quite strongly. Why does invoking the words "open source" excuse anyone from these expectations as if 'leading an open source project' makes someone above everyone else and outside the normal expected behaviours?

It is also a thing that you can't separate "don't scream abuse at people" with whining "why do I have to be polite?" as if those are the only two options, there's quite a range of rude responses which are not abusive - saying the code sucks, saying 'I wont read all that' - and there are polite responses which are blunt and not saccharine - saying 'I have the decision making authority and do not want to do it that way.', 'nope, PR rejected, do not try again', 'I am not taking PRs of any kind, I do not want to'.

Aside from that, as mentioned, this is not just any open source - he's a paid employee, this is not him sharing his work on his own server with the scope of him being rude or abusive limited to a few people; this is a hugely important worldwide system. The Linux Foundation is funded by companies who use Linux such as Amazon and Google. They employ people who work on the Linux kernel and have to be subscribed to lkml to do their jobs. The Linux Foundation benefits from the work they do and the changes they upstream. The companies donating money have shareholders and expectations of the companies they work with and charities they donate to. And presumably they have some ability to lean on their donations to ask for favours. All this happens under US employment laws and regulations on several sides. This presenting it as a trivial "if you don't like it, leave" is a deliberate and bad-faith oversimplification. It's the race to "person who cares less wins, and I'm a cynical nihilist so I care about nothing, hah!".

[1] https://www.penny-arcade.com/comic/2004/03/19/green-blackboa...