Hacker News new | past | comments | ask | show | jobs | submit | gary_0's comments login

The Rust drama is an uncommon failure of leadership for Torvalds. Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue. Given the crisis of confidence among a sizeable (and very vocal) contingent of the Linux community, that decision has backfired horribly. And it's quite out of character for Linus not to have a blazingly clear opinion. (We all know his stance on C++, for instance.)

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


> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor

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.


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

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.


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

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

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


People should read it:

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


I don't know, dropping 17000 lines of code is probably not the best way to solicit technical discussions

(https://lore.kernel.org/lkml/20240826103728.3378-1-greg@enje... is the patch set in question)


That's version 4. Here's version 2, which looks like the first patch submission:

https://lore.kernel.org/linux-security-module/20230204050954...


7000 is not a lot better.

Okay, but how long is reasonable to take to tell someone that their patch is too big to be 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.

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.


Not everything can be broken down into 5 line patches. Some of the bigger features need bigger code. You can look at the impact radius and see if the patch is behind a feature flag to make a decision. In this case, it seems like it is elective and does not have any changes beyond what is self-contained.

I don’t follow the Linux kernel development process closely, but on most projects—open source or proprietary—that I’ve been involved in, dropping a big diff without having proposed or discussed anything about it beforehand would have been fairly unwelcome, even if it’s something that would be infeasible to break down smaller. I’d also argue that even quite substantial changes can be made with incremental patches, if you choose to do so.

There had probably been a lot of discussion in the background

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


> Not using email patches

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.


Try modern/patched versions of Gerrit, I'm sure Linus could tune it to his preference

And I agree, GH has several issues


I've used Gerrit myself for nearly 10 years. I recognize it's strengths and like it for what it does. I also am comfortable with mailing lists and Git Hub and Git Lab. I've lived in "both worlds".

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


That's interesting, but I think the preocupation with SPoF to be overblown

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)


SPoF is not the only concern. Gerrit search is painful. You can't search the internet for a keyword that you wrote in v10 of some Gerrit patch, unlike on list-based workflows. Also, there's too much point-and-click for my taste, but I lived with it, as that's the tool chosen by that community. It's on me to adapt if I want to participate. (There are some ncurses-based tools, such as "gertty"[1]; but it was not reliable for me—the database crashed when I last tried it five years ago.)

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


Linus wrote this on kernel.org not being a SPoF: https://lore.kernel.org/rust-for-linux/CAHk-=wiQUya5_zTwLFNT...

For what it's worth, I think the main issue is archival. Like it or not, there's nothing that beats email when it comes to preservation.


That's a great post, and also the presentation linked there is very interesting and hints at some of the issues (though I disagree with some of the prescriptions there)

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.


> There had probably been a lot of discussion in the background

If that were the case then the patch would have a lot more CCs.


Then you have to discuss first, before throwing tousands of lines of code at somebody.

Totally. And also: the discussion must take place FIRST!

One of the first habits I learned at BigCo was to have a sense of the DAG in any work over 400 lines, so I could make patches arbitrarily large or small. Because whichever I chose, someone would complain eventually

Indeed, and that's exactly what the Rust for Linux guys are doing. They have Binder, multiple changes with various degrees of dependency on newer compilers, support for different kinds of drivers, and they are extracting them and sending them to Linux in small bits.

17KLoC? Maybe he should consider they’re probably still reviewing it through bloody eyes. But seriously I wouldn’t want to review that much code.

I'd get mildly angry if someone sent a giant patch without having discussed with me first. (Not working with any kernel things) But a quicker "no, don't have time, probably never will" response would have been nice I guess?

no feedback whatsoever for 2 months - just because it was 17k lines - and you are blindly defending it? if you don't know what you are posting & talking about, then maybe you shouldn't.

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?


> if you don't know what you are posting & talking about, then maybe you shouldn't

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.


> At some point I am not sure what the maintainers could do except ignoring it.

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.


Yes, as I wrote they had communicated it before. (BTW of course it's bazaar not cathedral... Brain fart for me).

Surely if there were insufficient established context for a reviewer to easily follow a large patch the correct response would be a swift rejection with a request that such context be established prior to submitting again.

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.


It's very easy to develop tunnel vision when working remotely with people you've not even ever met. It's happened to me multiple times and there's a very high chance that this is happening here.


Important to note that Ted is extremely anti-Rust and literally shouted down someone irl that was doing a presentation on Rust in the Linux kernel.

The short of his rant is that he wants a "Code Of Standards for maintainers" in addition to a CoC, in order to witch hunt people he feels "gets in the way."

Yikes, this is EXACTLY what Linus was talking about except an order of magnitude worse!


No. He just wants people to have some decency and standards in communication and not arbitrarily decide that their little kingdom can never be touched.

> The short of his rant…

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.


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

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?


His complaint is, in essence, that people will block technical proposals for nontechnical reasons, and that attempts to resolve this result in people complaining that you're talking about nontechnical things at all.

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


>in order to witch hunt people he feels "gets in the way."

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


Ex falso quodlibet

There are easy and good answers, just none that every single one would agree with, and that is the problem.

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/


I think "Code of Civility" is what Dr. G was describing. Conduct presupposes civility, but acceptable online discourse has changed amongst new internet natives raised in the era of moral totalitarianism, aggression as a service, and popular outrage incubators.

Looks like Dr Greg (not Greg KH) is just piling his own personal grievance on top of the drama. Saying "Jim are you listening?" makes me wonder who he's sniping at.

Speaking as an actual People Manager, his ideas sound pretty shallow.


I'm not a "People Manager" -- what is shallow about the ideas?

Maybe Jim Zemlin, who is the executive director of the Linux Foundation and has nothing to do with Linux.

> Jim Zemlin, who is the executive director of the Linux Foundation and has nothing to do with Linux.

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


This part is wild. Some people get in so deep they cannot see the forest from the trees.

    > there is the tangible risk of stifling innovation and Linux is the only place that innovation can occur in the operating system space.
One thing I know: HN loves drama, and this stuff reads like first class drama.

The proponents think the value of their "innovation" is obvious, but it is not.

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.


https://archive.is/rESxe

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


Yikes, at great example of how not all thoughts that pop into your head should be publicised.

Hm, good thing I'm not a Linux maintainer. 'Coz that first C in my username... (My given name is the only thing about me that has anything to do with "Christ".)

I think this is an important data point, too:

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

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

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


Greg replied and explained that this is a mischaracterization https://lore.kernel.org/rust-for-linux/2025013030-gummy-cosm...

You are misrepresenting the current state. The thread was unfortunately diverted before Jason's question received an appropriate response and conclusion: https://lore.kernel.org/rust-for-linux/20250131135421.GO5556...

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


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.

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.


> That one bug happened one time does not mean that the promise is broken.

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.


> Have some empathy for the folks who have had their workflows broken and burdens increased because of it.

Okay. Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?


No, because they are the once choosing to add this complexity to an existing project because of their own interests/ideals.

Calling memory safety an 'ideal' is like calling back-ups an 'ideal'. You can cast it off as a "nice to have", until you get bitten in the ass by a lack of it.

To quote myself[1]: I don't get why those Rustafaris do this in the first place. Like, if you want to contribute to a piece of software written in C, then write your contributions in C. If, on the other hand, you want a Linux kernel in Rust... Then just fork it and rewrite it in Rust. It's not as if that were a new idea, is it? Heck, most days it feels like about half the top headlines here are “<Software X> rewritten in Rust!” So why don't they just do that in stead of this constant drama???

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


Kernel maintainers aren't doing anything to R4L folks except where their activities intersect with the upstream linux kernel. Your analogy isn't right.

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?


> a few R4L folks are playing the dramatic victim card.

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.


> language barriers in the kernel are a cancer

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.


> > a few R4L folks are playing the dramatic victim card.

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


> Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?

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'm not sure this is fundamentally different from e.g. a complex filesystem implementation relying on a specific MM or VFS or whatever API, and a "C developer" wanting to change that API. Just because the callers are in C doesn't necessarily make the global change easy.

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

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

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

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


Threatening with social media seems to me like a professional suicide, especially when it's followed by a doubling down and a complete lack of anything resembling an apology.

I'm amazed that Hector is doing this fully in public using his real name.


It’s true though? I don’t see anyone picking C/C++ over Rust/Go in my immediate environment.

That might reflect my environment, but all of the things I’d consider C variations for I’d use Rust for as well…


It's definitely your environment, Rust isn't nearly as popular for actual projects getting done as it is in (for example) StackOverflow's survey. C, C++, Odin and Zig are all languages where whatever C knowledge you have right now can trivially be put to use to do things, immediately, I think it makes perfect sense that unless someone is just really into doing Rust things they'll just take the trivially applicable ways of working and use the aforementioned languages (which all have much better support for batch memory management and custom allocators than Rust, it should be added).

There are a lot of C programmers who do not like or are not fond of Zig or Odin. For highly proficient C and C++ programmers, many consider them not worth their time. Not even counting, that both Zig and Odin are in beta. It's an investment to become as proficient in the other language.

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)


I would suggest linking to a timestamped point in the video instead of the entire thing. With regards to Odin having metaprogramming this is either a misunderstanding on your part of what was said or a misunderstanding from Casey Muratori with regards to Odin; Zig has a much stronger claim to having metaprogramming with `comptime` being as powerful as it is, whereas Odin only scarcely can be said to have a limited "static if" in the `when` keyword, plus your average parametric polymorphism via template parameters.

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.


True that Odin is admittedly quite limited in that area. Muratori made the case that Jai was far beyond both Zig and Odin, thus recommending its use and what made it attractive for him. The other issue, is investing in languages that are in beta.

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.


> The other issue, is investing in languages that are in beta.

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.


> It's not a complex language

You cannot claim this when even codebases with veteran C developers will be virtually guaranteed to have memory safety issues at some point.


My comment was addressing the idea that Odin is a "beta language" in comparison to C and my assertion was that the issues we have with using Odin are the same ones you'd have with C. So assuming that you have accepted C-style issues, then Odin really does not present many or common additional roadblocks despite being relatively young.

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.


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


I meant the whole “we are on the right side of history” and if you’re not with us you’re against us and we’ll wage a public drama campaign against you.

Exactly.

Brings to mind certain world figures who have normalized this kind of petulance (which is bullying when real power is involved).

> in my immediate environment

Social bubbles can work like that.


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

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

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


[flagged]


The dirty laundry of the entire kernel community not immediately knuckling under and implementing a rather long list of technical changes in the preferred way of one specific individual? That's an unreasonable take. It would be disastrous for all of us if the project ever went that way, considering the importance of Linux today. It's not like I disagree with some of the points that Marcan raised, but others have equally valid concerns as well. However, he wants to get discussion and compromise out the window and go straight to social media drama. That's never okay.

And please, stop using the concept of ad hominems to selectively justify blatant abuse. That's not what the term is about.


> straight to social media drama.

It was a move of frustration due to having exhausted all other avenues. It wasn't his first action.


Things not moving as fast as he wants isn't the same as having exhausted all other avenues.

.. or it could just be that 'the public' has little to add to kernel development other than social landmines that the kernel teams have to navigate in order to achieve technical work..

I'm usually very critical of how Torvolds treats the people around him and the culture he maintains but this is a rare case when I'm not really against Torvalds on this.

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


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

If Linus thinks that the social media angle is wrong, he should defuse situations before they become explosive because even if one of the devs didn't bring up the drama, there are dozens of news companies that would have printed up articles the second they found the discussion anyway.

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


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

That is really an apt point. You can't condition people one way, and tell them to do the opposite.


And it's not _that_ long ago since Linus was King of the arrogant and rude flame posts on what's effectively hos own "social media", the linux kernel mailing list.

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


You can expect professionals to not act like trained monkeys.

Well... the maintainer also shouldn't blow their stack

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.


What happens when Linus retires (or god forbid dies)? He can't defuse those situations forever, there needs to be some sort of process.

Someone will have to take over Linus' role. There's no way that kernel development can work without a person in charge, at least not in anyway that is remotely similar to today.

Not being remotely similar to today could be a very good thing.

If you can point to a better model of a more successful kernel that would be interesting to read about.

FreeBSD? But there is nothing fundamentally different in open-source project management between a kernel and any other large open-source project. The linux code base is the largest, but not by a large margin. Chrome, GCC, OpenOffice, Android (excluding the linux part obvs.), and the various BSDs are all comparable in scope, complexity, lines of code, and number of contributors. Only linux is (in)famous for having a toxic and unproductive culture.

Odd. Linux is by far the most/largest/longest successful project. Or do you have a counterexample?

I assume we're only comparing to operating systems, as I would say that e.g. Chrome as an open-source project is just as impactful if not more so. But generally speaking the Linux support experience is decidedly worse than *BSD or any proprietary OS. It is much harder to get patches upstreamed, and many hardware have errata that never get fixed. (If you haven't experienced this, it might be because companies like canonical and red hat maintain their own patches to support their customers.)

> But generally speaking the Linux support experience is decidedly worse than *BSD or any proprietary OS.

Going to have to disagree on that one.


Good for who? External parties that want to force their vision of what the project should be?

Linus, as someone far removed from LKML, seems like he hates external visibility of what he wants to be effectively "internal" discussion more than anything else.

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.


I dont think Linus gives a damn about any social media drama. Why should he care?

It just ("just") sounds like he's out of alignment with the kernel development process.

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.


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

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


Yeah, reading these back in 2025 it's amazing Linux got as far as it did with Linus being like this for a long time.

But this is just frustration coming out. I don’t think for a moment he expected shaming on social media to work.

But it did work. Linus actually got involved because of it...

If we were dealing with a toddler, one could blame the parent for rewarding their misbehaviour attention... an adult developer not so much

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

This is profoundly silly.

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. Nowadays you have a lot of people just quitting over things like the fact that a member of the standard committee was convicted on CSAM charges.

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?


Discussions on the internet often were dramatic. There are certainly also many "C supremacists", but I don't generally see C people coming to C++ or Rust projects and insisting that it should be rewritten in C because "C is better". I believe C is a better language myself and definitely much better than how it is currently perceived, but I do not mind if other people have a different opinion and do projects using other languages. While the mindset of many C++ and Rust proponents seems to be that "C has to die", so is inherently much more hostile. This makes it then sometimes difficult to ignore this completely.

I'm a Rust coder who also occasionally watches Prime, and I've never seen Prime casually pour gasoline on fires. Yes his whole business model is reacting to whatever content is hot right now, but he always does so in a considerate and non inflammatory manner.

He's not a fan of Rust for totally legitimate reasons.


If not Rust, what does he prefer? Zig?

Yeah, mostly Golang and Zig I think.

He is apparently mostly a Golang guy, and has stated he would play around/experiment with Zig. However, this was against the advice of Muratori (who does not like Zig), and suggested Jai (preferred choice) or Odin.

My experience with Rust and people who use Rust has actually been great.

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.


I don't think that's true. I think the C guys told themselves that writing safe C code is just a matter of skill, but data shows that the amount of skill necessary to avoid writing unsafe C just isn't there. The average C developer isn't as competent as they claim.

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.


Rust is sadly more about marketing than actually being popular or safe.

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.


Google has published direct evidence of Rust improving memory safety in practice: https://security.googleblog.com/2022/12/memory-safe-language...

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


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

"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


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

Why does any of that imply that Rust doesn't produce safe code? There's no argument here - just some numbers and unjustified conclusions.


Java also had its share of remote code execution attacks. Security is quite complex domain and it is not just memory overwrites that can allow RCE attacks. Though I can agree that in average C/C++ is more vulnerable.

Most CVEs for Java are about untrusted code escaping the sandbox. No one is saying JavaScript is a bad language for server side development despite browser sandboxes constantly leaking.

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.


I think already phrasing it like this "the C guys" is inflammatory and not helpful. The C community is huge and there is also a large part interested in more secure programming. Also the idea that tall C code is hopelessly unsafe while all Rust code is perfectly memory safe are both far from the truth. In reality, you can make C code quite good and you make Rust code very unsafe. While Rust certainly has some advantage, this is not as black-and-white as the Rust marketing wants you to believe. But this fuels the "C must die" and "we are on the right side of history and if you can not see this, you are an enemy" lines of thinking some people have.

It also doesn't help that the Rust comes with more than just the safty changes. The expectations for development models, distribution models, backwards compatibility guarantees not to mention the cultural aspects are very different which is the real reason it causes so many clashes.

It get pushed with the argument for better memory safety but then wants to change the entire world as well.


This.

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.


This is not because of Rust, but C.

Any trending language will attract some not so great people who make their choice of a shiny language their whole personality. It's really a pity for rust to be in that position now, as those people are there for the feeling of superiority and will cause drama to get it

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


[flagged]


I haven't seen that as much. The horde of people chasing the hype curve left C behind long ago. When they leave rust, rust will be better off

I don't care as I don't use rust. I learned and played with it, it is just horrible. I use Python, Golang and C almost everyday for living and fun!

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 is unfortunately my take with almost every interaction I had with the Rust community. Expressing any diverging opinion is enough to get ostracized.

Who are these icons?

[flagged]


If you don't want to use C perhaps you shouldn't contribute to a 33 year old project written in C?

It sounds so simple, I don't get it why the Rust people don't write their own operating system or bundle their human capital to such a project.

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.


There are many Rust OS mentioned in this thread. (Eg Redox) But the success of an OS also depends on the availability of drivers, and it's hard to compete with existing proven OS such as Linux on that front.

So build a kernel that uses the same API as Linux but in Rust.

Surely it should be easy if you're asking the Linux people to do the same thing for drivers written in Rust?


Defining a rust API to the linux kernel is one of the endeavours of the Linux kernel project AFAIK

No?

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.


I somewhat disagree on the "you can't escape unsafe" part. It's true for a C+Rust project, but the idea that you need an unsafe language for low level hardware access is plain wrong. That's a "C-ism". Something that might seem true in a universe where most low level work is done in C, but wouldn't be true in a universe where C doesn't exist at all.

At work, we have an OS written entirely in Rust. You still need unsafe to make it work. Not much (3%) but it's nonzero.

The hardware is outside of Rust's safety guarantees. This is truly a fundamental issue.


its fine if you disagree and think that using "unsafe language" for low level hardware access is wrong but that doesn't change the fact that the more closer one operates to the hardware, the more bare-bone they need the tools to be or else they'll only get in the way of the job. Having to worry about something like a borrow checker or a reference counter just to manipulate a couple of bytes is not an efficient way to perform low level hardware programming.

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.


As long as you can directly write registers, you can screw it.

Partially, but it takes two to tango.

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.


Do you mean location as in different subsystem than dma, which is required for all modern devices. Or just location as in stash the files outside the dma directory?

> Or just location as in stash the files outside the dma directory?

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.


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

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

A serious case of the pot calling the kettle black.


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

You don't even take time to figure out who's the commit author.


[flagged]


This is the logic that generates generic corporate PR speak and a fear of being honest in organizational communication. It's not a more 'adult' world, it's just heavily sanitized. Calling something "a cancer in x" is a common analogy, we know what they mean.

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

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


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

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

If something is not clear, ask him to elaborate.

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


If you looks at the history then you will see that many different solutions have been proposed but Christoph's responses essentially boil down to 'do it somewhere else' and 'no not there', until it is basically 'not at all'. He is not in a position to make this decision, only Linus is. The patch as it stands lives outside of any sub-systems within Christoph's purview, he is simply being obstructionist out of tribalism.

> he is simply being obstructionist out of tribalism.

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.


I agree that it may not be tribalistic, it's very possible that the maintainer has a valid technical/social opinion on this.

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.


> The patch as it stands lives outside of any sub-systems within Christoph's purview

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.


> wasn't this a DMA patch?

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.


Aha, I see. Thanks!

Oh, yes, the idea of settling anything on social media is horrible.

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


> 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

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.


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

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


Sure, but (1) that ship has sailed for now, there are already Rust bits in the kernel; and (2) a patch email thread is not the best place to start discussing whether Rust has a place in the kernel.

There are no Rust bits anywhere outside drivers, and hopefully that will continue to be the case. This means that mainline Linux kernel has no hard dependency on Rust whatsoever, which also means that Rust can be excised at any point with a minimum of effort.

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.


Is it impossible to just delete the rust parts and go back to pure C?

That ship could come back to port anytime.


That's not a decision that can or should come out of a patch review. I agree it's a possible decision, not something unthinkable. But if it were, it should be taken at a completely different level.

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.


The kernel doesn't really have a better system mechanism for having these sorts of decisions made unfortunately.

I would quite like my laptop to keep working, and half its drivers are rust…

The Linux drivers can be maintained in a downstream fork. Ultimately that seems to be what upstream wants, unfortunate as that may be.

Then you (and others interested in running Linux on fruit company hardware) can sponsor someone to rewrite those drivers in a way that fits the Linux project.

> no one is really against some Rust in some parts of the kernel

This drama included the dma maintainer saying he is categorically opposed to any Rust in any part of the kernel.


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

He said explicitely:

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


The end of the paragraph also emphasized the point

> 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/20250131075751.GA16720@lst.de/

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.


I wouldn't call being vocally against something "sabotage". Would it be reasonable if that person said anyone trying to get rust integrated is sabotaging the Linux kernel?

You're conflating two things. The fact that he voices his belief that Rust is harmful for kernel development is fair.

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.


>The fact that he is using his powers as maintainer of the DMA module to prevent Rust code from being added

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.


At least at some point, the proposal was to add this code in the DMA submodule, where he did have the ~final say whether it would be merged in.

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.


You're comparing the actual intent of one side of the argument to a watered down version of the other side. "I will do anything in my power to stop this" is the stated intent of sabotage, not "I'm vocally stating my opposition to this" If someone said "I will do anything in my power to stop Linux development to proceed without Rust integrated into it", then yes, that would sound like intent to sabotage, but that's not anywhere close to what anyone is saying.

So there's actually a reasoning behind this and not just personal preference or someone being stubborn. And as someone who has maintained large old code bases I must say the reasoning sounds pretty convincing.

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


This [0] seems to be the closest to your parent's statement:

> 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/20250204052916.GA28741@lst.de/


He needs really to be removed from the process. He may be useful for now but for long term he is an impediment. C is the 1970’s. Sure it’s proven itself… but so had Assembly when Unix was invented.

This kind of zealotry is not going to convince people over to accept Rust into their projects.

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

The objection was to a separate file entirely outside of his subtree, describing its interface, which is apparently supposed to be duplicated instead in each rust driver that references it, for no clear reason -- other than his stated reason of not wanting to see languages other than C in the kernel at all.

I was referring to the statements provided by the children of this comment: https://news.ycombinator.com/item?id=42978746 (they were made at roughly the same time you posted this, so you wouldn't have seen them then)

Ah, sorry. I see it now.

No need to be sorry, you're all good!

The DMA infrastructure is core to drivers. Saying no to having a wrapper to use it in rust means every rust driver needs to reimplement it, which creates more work and issues.

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

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


No, Hellwig also Nack'd the patch that added the wrapper to an independent library outside of the core C DMA directory.

Why would he do that? He has no control over an independent library outside of C DMA? I thought he said he's fine with any drivers written in Rust. Just that the maintenance of such including any wrapper cannot fall into C DMA's lap.

> Why would he do that?

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 +
(Nor does any Rust4Linux code add any maintenance burden to C -- C maintainers are allowed to break Rust code at will.)

This isn't even just your read of it; as other people in this thread have pointed out, he's pretty explicitly stated it at this point.

No, he said very explicitly that he is against any Rust code in Linux whatsoever. He doesn't have any beef with Rust, the same would be true for him if people tried to add C++ or Pascal or Ada or any other kind of drivers or infra in Linux: he believes that the project will be much harder to maintain if it's not 100% pure C (and assembly).

Here is a link to this explicit claim: https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...


> Why would he do that? He has no control over an independent library outside of C DMA?

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.


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

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


It's just really, really dumb to both a) have rust drivers in the kernel and b) not merge this patch. It's just obviously stupid.

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


> Before Hellwig put his foot down as "not merging because rust sucks"

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.


> He didn't say this at all.

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.


> Okay, sorry. He just said there should be no rust in the kernel.

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.


No he did say he doesn’t want rust in Linux at all. Now I understand that he didn’t say “I won’t allow rust to be in Linux”, which is a useful distinction to make. But let’s not pretend like he didn’t say “rust shouldn’t be in Linux” at all.

https://lwn.net/ml/all/20250204052916.GA28741@lst.de/


He literally said this:

> 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/20250131075751.GA16720@lst.de/


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

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.


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

https://lwn.net/ml/all/20250204052916.GA28741@lst.de/


He said no Rust (or any other language except C) in any core code. Notably the patch was not eve being added to kernel/dma

I think he even hates non-C code in the drivers, he just cares less about that. But his position is that kernel maintenance will only work longterm if it's all a single language (C).

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

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.


please stop spreading such highly misleading nonsense. look at what is black and white. blindly defending such toxic people is not doing linux any good.

It's pretty clear that the battle over rust is a power struggle. You can't take any of it at face value

So what are you saying? That it's okay to just invent quotes and spread misinformation about people, based on what you suspect their true thoughts might be?

You’re the one doing that by pretending that Hellwig is acting contrary to his own statements.

wait a second, I thought you are the one labelling people as "toxic" when completely ignoring the context that really matters.

He literally called "Rust" a "cancer".

I beleive he clarified in the same sentence that he was not calling the language Rust cancer... to quote "where this cancer explicitly is a cross-language codebase and not Rust itself, just to escape the flameware brigade"

So, to be more specific, he called Rust in Linux kernel source a cancer.

It needs to be a little more specific to be correct; a cross language codebase would be the cancer.

He literally did not. He literally explicitly said right there in the (in)famous "cancer" message that it didn't refer to Rust as a language.[1]

"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/20250128092334.GA28548@lst.de/

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


care to explain why the following patch that touches nothing got rejected?

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.


The reason patch got rejected is super simple: because this wrapper not lives in specific driver and depends on DMA subsystem internal API.

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.


> because this wrapper not lives in specific driver and depends on DMA subsystem internal API.

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 when he/she is literally forcing other people to stop developing Linux support for the only powerful & affordable ARM machine for home use.


> what should they do?

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.


> that it didn't refer to Rust as a language.

No, he didnt refer to Rust as cancer, but to Rust in the Linux kernel / the R4L project.


One lesson I feel we can all learn from this is that social media really should not be used for self-therapy.

IMHO social media is toxic period and has no place in any professional interaction. It is inherently biased toward drama and bullshit by design, since this “maximizes engagement.”

The sooner politicians are outright banned from using it for anything connected to their office the better.


> no one is really against some Rust in some parts of the kernel

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.


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

c'mon.. please know about the issue at all to some level before commenting.

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.


That may be what you want the situation to be but at this point it isn't what the situation is.

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

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?


Completely agree with you.

I totally agree that even "just threatening" a social media campaign is the wrong way. We are on the same page here.

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.


[flagged]


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

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


> an uncommon failure of leadership for Torvalds

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.


Agree

The more I hear about "community" the more I roll my eyes

It can be great at doing the work but it is awful at setting direction, evolving with the times and focusing on what's important

Going by another story on the front page, I have my long list of criticism about systemd but the "get things done" attitude needed to be commended


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

> Little in the kernel comes from maintainers saying "let's do X" and community members implementing it

Maintainers do steer direction of development though. A lot comes from maintainer saying "we are not accepting XYZ".

Today we only have proper open source GPU drivers because people like David Airlie who stand for their principle against likes of Nvidia and AMD.


See how slow Wayland progress has been for an example of my grudges with that model of development

Almost two decades later, for unexplicable reasons, every new client not piggybacking on an eatablished toolkit or a new toolkit/compositor struggles with clipboard support, I shit you not.

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

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

I wear garlic every day and have yet to be attacked by a vampire; clearly this is due to the garlic!

Tang/ballpoint pens/velcro never would have been invented if it weren't for the Apollo program.

etc.


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

>"Community" is just a very naive ideal for me.

I guess you are safe to say this now. But from 2014 to 2024, open source is not about code licensing but about the Community.


> IMHO the one and only thing that made Linux successful as a project is Linus' strong leadership

Naah, I don't think that's the only thing that did it. It was that, and the fact that people dared rely on it -- dared trust it to stick around, and to stay a single thing in stead of splintering up. And the thing that made it Open Source that stays Open Source -- that made it, in fact, Free Software -- is the license.

The two things that made Linux successful as a project are Linus' strong leadership and the GPL.

Just look at BSD: It had the backing of a whole darn university near Silicon Valley, not a single student somewhere North of The Wall. It had a head start by several years. And it had name recognition far beyond its home country[1]. And look where it is now: There are (at least?) three of them, and even together they're a marginal phenomenon among operating systems. I think that's because of the too-permissive BSD license.

___

[1]: The first I heard of "Open Systems" was well before I got into working with computers for a living, as a student at another university in the Frozen North in the late 1980s. My fiend and neighbour, a computer student, raved about how cool Unix was: "And you can even get it for free! It's called BSD!"


[flagged]


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

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

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

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


> A good leader is someone who can deliver hard messages while still keeping your team inspired.

Do you have examples of this? The only "good" leaders that are strong and opinionated I can think of always comes across as leans towards being an asshole.

> Same message, but completely different impact on your team.

Let's change it from "you're a fucking idiot" to "this code is fucking trash". It's not insulting to the specific person, but it definitely gets the point across that the code is no good and much less ambiguous to "it's not up to standards".


A few public ones off the top of my head: Satya Nadella (Microsoft) and Ed Catmull (Pixar) are both folks who I consider to be strongly opinionated and effective leaders but who don't come across as jerks.

I'm not sure how "this code is not up to standards, try again" is ambiguous? That seems pretty direct to me.

Ultimately it's about showing empathy. Especially when you're dealing with employees who are struggling with anxiety, impostor syndrome, or burnout - all of which seem to be overrepresented in tech.


Using business-approved language doesn't actually make your message more friendly.

It's not line Linus was prone to using flowery prose against random novices - the rant he's known for were mostly addressed at senior maintainers who really should have known better.


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

You disagreeing with an argument does not mean it was made in bad faith (or is without merit for that matter).

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

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


Except you have no authority to call that out, and we're not forced by law to agree with you.

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.


Are you serious? Linus has a long history of being abusive, it is no secret. He has gotten better for sure in recent years, but especially in the earlier days he would fairly regularly insult people, tell them to kill themselves because it would make the world a better place, and more.

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

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


Not appropriate for what exactly?

could you give some examples of "nice empty words"?

Seriously? I’m a huge fan of Linus, but you have to be delusional to not find his rants abusive or disrespectful.

Seriously. And I say this because apparently every comment on this thread has to be on either side, with no actions being considered counterbalance whatsoever. So given that I have to pick a side, yep, seriously.

Not as disrespectful as calling those who don't agree with you "delusional".


[flagged]


I agree, engaging in further conversation would be futile.

Can you explain in simple terms why a person cannot reply abusively (whatever that means) if he so desires? You're not obliged to interact with him, it's a free choice to join or to quit the lkml.

https://www.theregister.com/2020/06/30/hard_to_find_linux_ma...

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.


Perhaps, but if Linus would rather see the mainline kernel development dwindle than compromise his way of managing people and code, he's still well within his rights.

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.


Do you genuinely think an employer ordering an employee "don't tell people to kill themselves" is "high expectations"?

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


I'm sorry, but I just can't make any sense out of this.

> This presenting it as a trivial "if you don't like it, leave" is a deliberate and bad-faith oversimplification

This is not an oversimplification, this is a fact that you don't like and prefer to ignore. It doesn't disappear when you close your eyes though.

A grumpy person made an open source project that by chance became successful. He didn't force all these people and corporations to use it and fund it, it was a free choice on their part.

What is he supposed to do now, change his personality to please random people on the internet? Why? How do you even see this happening? Or you think grumpy people should have been prohibited from writing code in the first place?

Furthermore he does not hold anyone hostage as you try to present this. Linux is not Linux Foundation. You can use and develop Linux without funding the Linux Foundation. It's just more convenient like that but again you are free to exchange patches outside of it.

People who walk in and say "nice project you have here, now you comply or we take it away from you" don't have my sympathy.


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

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


No, you get it backwards. Open source community folks despise any commands, the moment Linus orders free folks like you to do something will be the moment his leadership ends.

The drama, though, is due to personalities.

A directive from Linus on the technical roadmap isn't going to solve anything. It could declare someone the "winner" in this particular thread or this particular issue, but lets the personality issue fester.

It's probably best for Linux to work through its technical issues in boring email threads which never get any attention on social media. And its organizational issues and its personality issues, for that matter.

So it's probably good all around that Martin has bowed out. If you reach for the nuclear button whenever the people you're working with don't give you what you want, it's time to go work on your own (nothing wrong with that, BTW). It's not really a question of who's right, but whether people can find a way to work together. That's quite difficult in a big project, so you have to both really want it and be good at it or it's just not the place for you.


Coincidentally there is a very good talk related to this @ FOSDEM 2025 by James Bottomley: https://fosdem.org/2025/schedule/event/fosdem-2025-6540-the-...

Video isn't out yet, hopefully soon.


There is an LWN summary of it out already:

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


It's definitely a ballpark estimate, but "boring email threads" are 99% of LKML.

There's an average of 1000 messages per day, we get news of a drama-fueled thread like, three times on a bad year?

My ballpark estimate is probably low.


Well, while Hector had a long history of frustrations with working with kernel development, the project of integrating rust drivers in the kernel has reached a cross-roads. Either to take the next steps or effectively close the door of the kernel progressing further with C and all the debt it brings.

From what I saw, the project of writing the graphic drivers for ARM Macs was quite a success, so the door for those projects shouldn't be closed.


The policy of "No C++, because I don't want to deal with C++ people", should be extended to the Rust community. Whatever you think of the merits of the Rust language, the drama, the lecturing and the general superiority complex of the Rust community is quite off putting, at least to C developers.

I also agree that Linux should close the door to Rust as a matter of principle, as it has done to any other language other than C. I don't believe in a mixed language kernel, it is just nonsense, specially with such a different language such as Rust which is closer to C++ in philosophy.

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

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


There are zero indicators for that happening. In fact, if history is by any means an indicator for the future, we might see these dying out over the years in favor of new hyped ones and C standing against the time. Zig is nothing so far, personally I believe Rust has some staying power for now, but we'll see. As for C, kernel C is not all that C where C was led to in recent years.

C and Unix have stood the test of time. It has been 50 years since they were designed, this is a long time in terms on computing. It is not unreasonable to think that they will stay for another 50 years.

Yes, they SHOULD be adding Fortran, another language that has stood the test of time, to the Linux kernel.

Or... Maybe it's good that they add a new (still 10 years old) language with security and DX improvements occasionally. 50 years ago, that language was C...


Adding languages is plainly a bad idea. Migrating to a different language might make sense at a time but IMO rust is still too young to consider that.

How many operating systems are written in FORTRAN and still widely used?

If other, safer language would have existed the same time as C, I don’t think it would have stood the time as you say.

that's just hindsight. You can also argue the same for the dvorak keyboard vs qwerty. And yet, qwerty stood the test of time.

Momentum and legacy is hard to displace, when the new fangled thing attemping to be an improvement is not proven, and has unknown unknowns.


> that's just hindsight.

Is it? Do you think it's hindsight to use the only "successful" story as "the only way forward?" Look at the gas vs electric vehicles. Yes, displacing legacy is hard but not insurmountable when there is a clear improvement. I don't think anyone can argue in good faith the Rust is NOT an improvement in C.


Electric vehicles are also not a clear improvement over combustion engines. Which is why they need to be forced into use.

They did. But they were disregarded.

Just like C++ has already led to there being fewer new C programmers and has caused C projects to die out? I don't think the programming language is a real problem for someone capable of working on the kernel. Some people might prefer to work in another language but with a large project you need to compromise in many ways and the language is just part of that.

Interestingly enough the Windows kernel is slowly rusting. If they they see a significant drop in CVEs eventually (which is bound to happen, with how easy it is to footgun memory safety in C), it blows a huge hole in the stance of "no Rust in the Linux kernel". It'd be akin to saying "yes, more security issues please".

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

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

Nothing is stopping you

If the Kernel stopped all development it would still not fade into the sunset in our lifetime.

Linux kernel community is afraid of drama? I've been using Rust as a primary language for years now and would agree that the community is lead by immature drama queens. However, the linux kernel team would be the best comparison.

> at least to C developers.

so it is not about technical merits, but just some language religious thing? nice.


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

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

The rust doesn't write itself.

>Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor

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


Positive, yes, but can you point to where he says R4L is here to stay and an integral part of the kernel? He needs to commit, or drama like this will continue to boil over. He also seems content to let the C-only old guard give the R4L guys a hard time. If you only enforce the rules on one side of a conflict, it makes it pretty clear which side you agree with.

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

Would you say that C is "here to stay" in Linux? I would say so. I think you understood what was meant.

The drama is the problem, not rust. I don't know why, but either zealots choose rust or rust induces zealotry.

Its exactly what Linus said.


Of perfectly moderate Rust users get annoyed with C zealots?

That might be an argument if those C zealots were trying to add their language to a Rust project. Don't play in someone else's back yard and then complain that their are not pampering you enough.

I don't understand how this is related to what I said.

>. I don't know why, but either zealots choose rust or rust induces zealotry.

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.


No I wouldn't say that. If Rust or another language eventually proved itself more value than C and things were eventually all rewritten, C would go away.

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.


Perhaps C is here to stay and that is the way Linux should live and naturally die. That's what's being proposed here by the guy who opposes multi-language projects.

That's my overall point of view too. Regardless of infinite technical discussions about one or another, if Alice and Bob can't live together than just don't get married.

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


I concur. Personally, I'd love to see all the Linux Rust effort being redirected at Redox OS.

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.


Redox has stayed drama free so far.

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.


Redox is drama-free because Redox has very few developers working on it. In the last 12 months, Redox had 7 contributors that touched more than 100 lines of code.

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.


"In 2010, after twenty years under development, Stallman said that he was "not very optimistic about the GNU Hurd. It makes some progress, but to be really superior it would require solving a lot of deep problems" - https://en.wikipedia.org/wiki/GNU_Hurd

Most UNIX systems that were not implemented in C, and thus lacked the symbiotic relationship, never survived in the market, sadly.

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.


I don't think you can conclude anything from that since a ton of UNIX systems implemented in C are also dead.

C was created to rewrite UNIX from its original Assembly implementation, naturally it is a symbiotic relationship not shared by other languages.

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.


> C was created to rewrite UNIX from its original Assembly implementation

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.


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

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


Well, it is kinda weird to take what would otherwise be perfectly legitimate and meaningful syntax and make it a comment. E.g. Pascal uses (* *) instead, and there's no other construct in the language where those can legitimately appear in this order.

Sure, but it's still a choice that C made, long before C++, so it's bizarre to see it in reference to how much worse C++ is.

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.


/* */ is a PL/I thing that somehow ended up in B. I suspect that Ritchie just wanted multiline comments (which BCPL didn't have - it only had // line comments), and just grabbed the syntax from another language he was familiar with without much consideration.

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.


That is the usual cargo cult story of C, systems programming languages go back to JOVIAL in 1958, NEWP in 1961, one of the first systems programming languages with intrinsics and unsafe code blocks.

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.


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

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.


Market failures of the other Unices aren't necessarily related to the technical advantages or disadvantages or symbiosis with C or being implemented in C. However, making C programmers' life easier was crucial.

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.


Free beer OS with source tapes and the Lions book made the huge following of academics and young professionals.

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.


OSX would like to disagree with you.

First of all I mentioned most, not all.

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.


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


If macOS isn't see as UNIX by Apple, why does the latter continue to submit it for certification?

Is the OSX kernel not written in C?

the modular parts (IOKit) are C++

Linux kernel is also one of the few that do not use C ABI as entry point for user programs at all.

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.


Are you sure?

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
The product must be registered as conformant to the Product Standards prior to, or concurrent with, the UNIX 03 Product Standard registration."

Depends on exact level of conformance and options chosen:

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.


Ok, but that is the split certification due to the way Sun started to introduce on UNIX world the SDK concept, where customers had to additionally pay for the development tools, the UNIX version of UNIX Home and UNIX Pro editions.

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.


Yes, perhaps a C-only Linux would do that and die, and perhaps it would continue its customization of C flavor and runtime it uses (e.g., the various static and dynamic memory limitations and checkers) and closes the gap with Rust to a point where the incremental benefit of using it is not significant enough that it makes a Rust based competitor an inevitability. We may already be beyond that point, even.

The changes required to bring C to a Rust level of safety would make it an entirely different language, even when restricted to the kernel's domain. 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.

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/


> The changes required to bring C to a Rust level of safety would make it an entirely different language, even when restricted to the kernel's domain.

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.


> The changes required to bring C to a Rust level of safety

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.


The kernel does not use Cargo.

For the moment./s

Or may be Zig might be more acceptable to the Kernal team, once it becomes mature enough?

This is inevitable: Rust is proposed as a safe language, but there is no way to have a "half-secure" kernel. The only option for people who believe in Rust is to have its own kernel, and Linux should have no part on this.

> there is no way to have a "half-secure" kernel.

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.


Keeping the project single language doesn't mean that the project can't change. The C used today is not the same C used when when the project was started. Changing language is also possible. Using two different languages long-term however means that everyone effectively needs to be proficient in both languages and a lot of work is duplicated.

DEC Alpha support is somehow still in the mainline Linux kernel...


To be fair, anything that does not support BWX is really painful to deal with.

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)
But with BWX, it becomes:

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

The ghost of the Alpha's infamously weak memory model coming back to bite it's undead self.

Yeah m68k is still around too and it has more than a decade on alpha.

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 guess the biggest difference is that Coldfire parts are still being produced (c.f: MCF52256CVN66).

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


M68k has the advantage that it has a fairly typical memory model.

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.


Since the C compiler can hide that, for core kernel code I think the more problematic thing was Alpha's memory consistency model where (data-)dependent loads accesses did not imply ordering, which is unusual and more burdensome to the programmer than any other ISA.

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


Ah, my favorite instructions, 'hw_ldl/l', 'hw_stl/c', 'ldl_l', 'stl_c' and their quadword siblings.

The problem is, that he let's a maintainer say he is going to fight any Rust code getting into any "core" (whatever he considers core) part of the kernel, even if it's just a wrapper to make driver code more maintainable. I would say, that's a strategy decision that should not be up to any subsystem maintainer, that's a decision that should be up to Linus, by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers. I don't believe that was what the rust guys thought they'd be signing up for.

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

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


This seems like black and white thinking. There's a huge spectrum between

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


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

And that's a perfectly resonable position.


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

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

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

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


The C++ situation was completely different, Linus said from the get go "no way", thus nobody put serious work writing c++ code for the kernel. With Rust Linus essentially said let's see how it goes, but specifically said he would deal with maintainers who would be unwilling to consider code that would be necessary for R4L. Based on this people invested significant work into writing code that is quite widely used, only to now have a maintainer saying he'll oppose any Rust code coming into the kernel, and Linus saying the guys trying to get the code in are the problem.

Agree with that. His statements are available on youtube. I was suprised how positive and eager to the change he was.

Why would he make such blanket decision on something he does not completely understand?

The maintainers of core subsystems are the people he trusts, at least trusts as much as you can in this space. He'll take their opinions before anyone else, since they know best about the subsystems they maintain.

To get Linux to overrule them you not only need to come up with very very convincing technical argument, you have to make sure you also posses the depth and competence required to maintain any such subsystem if the maintainers rage quit. Because you see, maintainers of these subsystems resigning is the bigger blow


> The maintainers of core subsystems are the people he trusts, at least trusts as much as you can in this space. He'll take their opinions before anyone else, since they know best about the subsystems they maintain

But there were no technical arguments against the Rust wrapper. And in any case, the Rust wrapper isn't in that subsystem, it just uses that subsystem. Hellwig's argument was nothing more than "there shouldn't be a second language in the kernel". He had nothing specific about the DMA wrapper. And Linus has already approved Rust in the Linux kernel, so what's the problem? Why can't Linus put his foot down on an issue that he has already decided on?


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

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

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

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

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

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


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

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

So if Linus shouldn't overrule his deputies, and one deputy can completely block something in a subsystem that isn't theirs and has explicitly stated to do "everything in their power" to stop it, what exactly can the community "figure out" to get it to proceed? His decision not to get involved literally makes it impossible for the situation to change, so the confusion is why it's being phrased as if it's anything other than that.

If Linus were to come out and say "I changed my mind, I no longer think it's worth pursing trying to integrate Rust in the kernel due given the issues at hand" or even "regardless of my personal views, I don't have any desire to change the current system we have for how code gets merged into subsystems or who has the ability to block it, so I'm not going to overrule this", it would make a lot more sense to me, but by making it sound like there's anything left to figure out when someone with veto power has a stated intent to stop things from moving forward is just going to let the issue fester and produce more frustration on both sides. It almost seems inevitable that any future discussions will spiral out of control; there's no other way for it to conclude than either Linus overruling his deputy or the experiment just ending as a failure at this point, so he might as well just make that decision now rather than later.


It is not a valid reason to reject a patch when the decision to include the second language in the kernel has already been made.

A decision to include Rust in the kernel isn't a decision to include any patches from any specific person with no questions asked.

It's valid for maintainers to reject a patch even if you disagree with the reason. Repeatedly causing social media storms to "shame" them for doing so, Marcan's own word BTW, isn't.

Rust is young and efforts to use it in kernel programming is even more so. It's completely understandable for wanting to take things slow and not be too quick to put it in places where there would be no going back. Everyone should at least be able to recognize that this concern exists, regardless of their opinions on Rust.


> A decision to include Rust in the kernel isn't a decision to include any patches from any specific person with no questions asked.

This is not what's happening.


> It's completely understandable for wanting to take things slow and not be too quick to put it in places where there would be no going back.

Have you even seen the original thread? It wasnt about "taking it slow", he was trying to block R4L permanently.


I'm sorry, but no. Christoph clearly didn't even spend 5 seconds looking at the patches before rejecting them. His first objection was obviously false, and when this was pointed out he fell back on blanket objection to rust without any real technical argument.

I agree that Linus should have made a clear statement.

> Maybe he knows he should, but he fears the shitstorm it will cause.

I always felt that the Rust community is creating a huge social pressure on lots of projects. Rust was more forced into the Linux kernel than being welcomed by Linus and many core maintainers. The pronounced evangelism (not a compliment!) in the Rust community is not only off-putting by being a form of non-violent aggression but creates real problems like wasted energy and resources. This is not generally true, as there're great examples of Rust being adopted from within projects. But also others where Rust was pushed from the outside, like curl.

In my opinion it's a failed experiment. The reason for the failure might not be on the technical side, but on the social side. On the other hand, if Linus wants Rust in the kernel as a way to get new, young, enthusiastic devs into Linux core development, than he should use his role and make a very clear statement as he's done before, like: "Everybody shut up and accept and welcome Rust as first class citizen."


I think at the point where you're loudly complaining about the email patch process (and hey, I agree it's the worst), this has stopped being about Rust.

May I ask which aspect of the email patch process you're referring to?

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?



Maybe it's because of Linus' age or because the players involved are bigger than many past issues, but the way I see it, both decisions are really costly:

- Endorse Rust with little reserve and over half of the C++ devs will feel betrayed and quit supporting the Linux project. They've been working on C++ for Decades and things mostly worked, so they won't pivot for a new language and way of developing for something that exists for less than 30 years.

- Ban rust contributions and the entire Linux foundation goes directly against some big players, like DARPA and other departments of the American government[1], which itself is a trend setter. Some big sponsors might also pull out and that ALSO removes devs from the project.

So, which decision would be so overwhelmingly more advantageous that's worth taking all the negatives of the other on the chin rather than trying to minimize harm and wait to see if either Rust software proves to be not so magically immune to memory leaks and vulnerabilities or if some tool makes the transition less contentious?

[1] https://stackoverflow.blog/2024/12/30/in-rust-we-trust-white...


> over half of the C++ devs will feel betrayed and quit supporting the Linux project. They've been working on C++ for Decades and things mostly worked, so they won't pivot for a new language and way of developing for something that exists for less than 30 years.

You mean C? C++ has been dead and buried for years and there are 0 kernel devs thinking that C++ will ever be allowed in (that idea was killed in the 00s if I recall correctly).

I don't think the situation is quite as extreme as you're making it out. For example, the employers of Linux kernel devs are getting pressure to use Rust because of the push from within & without the industry. I think push comes to shove, most people have a stronger preference for their paycheck than for the language they work in.


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

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


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

https://bosslinux.in/bossmool


Typo. I meant C.

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

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

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


> C++ has been dead and buried for years

LOL, lmao even.


In the Linux kernel

> like DARPA and other departments of the American government[1]

Eh, that White House link is dead right now and I would not be shocked if whole department is purged soon, so who knows anymore…


I do wonder if Linus is actually opposed to Rust in the kernel, but for whatever reason thinks that he can't afford to openly ban it or do anything beyond deniably letting it be obstructed by maintainers. The Rust language project and community are political and politically savvy in ways that few other open-source infrastructure projects are - it seems conceivable that if he declared against it, this might result in personal attacks and pressure on key backers/sponsors that would endanger his position or Linux itself.

It would be a silly strategy compared to saying that mixing languages is a bad idea and rely on inertia.

Also, letting rust in doesn't seem to stop the personal attacks, case in point


Very reasonable take. I feel the same. Any kind of real or perceived attack on Rust is heresy today.

> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor, but he hasn't said anything explicitly. [...]

I don't see it that way. Linus is conscious of not becoming a bottleneck on every topic; he doesn't want to baby-sit overly grown adults. I read most of the relevant LKML thread[1]. Martin did the unwise thing of escalating it on social media:

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

That is not the way to build bridges and relationships in a community! No matter how frustrated you are. He reaped the whirlwind for taking that destructive approach.

Also, Christoph Hellwig, as an established maintainer, totally missed the mark by using the highly-flammable word, "cancer", to describe Rust. It scorched the LKML and the internet. He should have showed more restraint and wisdom.

[1] https://lore.kernel.org/rust-for-linux/Z6YPfsDSNdRUskvp@phen...


Last year, Linus approached the topic of Rust in the kernel as if it were two opposite communities that were each passionate about their cause: https://www.theregister.com/2024/09/19/torvalds_talks_rust_i...

And his viewpoint at the time seemed fairly agnostic - he enjoyed the passion on both sides but said nothing about what his thoughts were. This leads me to believe that he hasn't spent the time to think about the important issues on either side and make a decision (the failure of leadership mentioned in the parent comment).

Personally, I'm surprised Linus hasn't gone 100% in on Rust as he is normally very forward-thinking, so perhaps that has added to the frustration from so many kernel developers like Hector.


If you're gonna lead a group of people effectively, you kinda have to listen to them. leading by decree works occasionally, but you can't afford to do it often.

If there's a lot of people sceptical to rust, doing a limited experiment is one way to figure out if it's going to work. Rust people working in the kernel should act accordingly. Drama like this is not helpful


> The Rust drama is an uncommon failure of leadership for Torvalds. Instead of decisively saying "no, never" or "yes, make it so," [...]

It feels like over the year he has been sort of beaten into submission both for his outbursts (which I've always found more funny than offensive) and the lobbying of the zealots of a certain relatively young programming language (which sometimes has a little taste of propaganda) against "memory unsafe languages".


How is it uncommon if the issues identified in this drama cycle (eg from here https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...) are systemic and have existed for many years? That's just a continuous failure of leadership, all ignored by said leadership under the pretense that "it works, so it must be right"

>..... Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue.......if Linus had just said "no, keep it downstream".

I have been thinking for years that the reason why Linux dont attack Rust like all other languages is that his close friend or close subordinate like Greg actually like rust. So rust as a language has huge leverage within the Linus decision mental model.

Not to mention the huge Rust gang both on the internet and around him. Friends that support Rust. Having the usual strong opinions of Rust like he had for C++ will obviously damage friendship.


I always suspected it was commercial/government pressure. Hard to argue against "doing something" for safety.

People get old and stop caring. Linus is still doing amazing. But I agree he should have just said no to Rust and move on.

Why? Was it not worth seeing where it would go, or how many would be interested? Is it possible he believed the tides could turn that way?

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

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

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

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

Redox is doing this, with a microkernel multiserver approach.


And look where it got us!

Can I ask something controversial? What if Rust never becomes a significant part of the Linux kernel? What if they keep stalling and all the people pushing for it give up? There seems to be this faith on HN that Rust absolutely belongs in the Linux kernel and if not, the project is a failure.

If you wait long enough a Rust competitor will gain traction. And honestly I wonder if that might not be for the best. How many of rust’s features have only been tried a couple of times?

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

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

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


> We don't have a Rust-killer language yet.

The type-system analysis of Rust is smart, but not restricted to the language per se, see https://github.com/ityonemo/clr. One merely has to have proper namespacing and necessary type info from generic code to do annotations and solve them. These things are solved in Rust via trait system.

Retroactively patching C to have namespaces will not work and same holds for generics, meaning concrete how to attach lifetimes to generic code.

> Zig went in a different direction.

There is stuff cooking for debugging comptime and better than lsp infos, but this is only wip and hearsay. Might be enough to write external static analysis or not.

Correct me, if wrong etc.


There was also Cyclone before Rust, and Checked-C in the meantime. The concepts like regions and affine types existed long before Rust, and Rust started out by copying from older languages (http://venge.net/graydon/talks/intro-talk-2.pdf).

It's not enough to have just a proof-of-concept compiler that could match Rust's checks — that's where Rust was 10 years ago. Rust had time to polish its compiler, expand tooling, integrations, platform support, attract contributors, grow userbase, create learning materials, etc. To displace Rust of today you don't need to just match the old starting point, but offer something better by a margin large enough to offset the cost and risk of switching to a less mature language. That's the same problem that Rust is facing when trying to displace even more established C and C++.


Yes, I do agree with you. Just wanted to inform you that it may still be possible in principle and as you can see with development speed, build system, dependencies etc there is a potential angle.

> We don't have a Rust-killer language yet.

We don't even have a C++ killer language yet. These things move very slowly.


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

My thought is what's telling is the 'rewrite it in rust'. Rust doesn't have a new business case.

C was better than assembly. C++ was better than C for GUI applications. JAVA has garbage collection and usually won't force you to fix your machine after a bad crash. Python is better than Perl for quick and dirty stuff. PHP lets you build a web service without much pain. C# is a better Java that also gives you better integration with Windows. Go does a good job with small quick running services. Lua is easy to integrate into programs.

I look at existing C codebases. They're usually well worn and work okay.

C++ codebases would probably be better rewritten in Go or C#

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

PHP? Keep using it or us Go.

I also feel like Go, C#, and Python are designed to be fairly easy for a noob to come up to speed. Where Rust is the opposite.


I guess you make a living writing zero day exploits?

Keep believing that Rust magically prevents you from getting owned when you fuck up.

That is a fallacy. No one has claimed that Rust magically prevents you from getting owned. Quite to the contrary: there is no magic in preventing most, if not all memory handling errors. Which are the most common reason for security problems. Removing one category of errors entirely would free a lot of resources to deal with the remaining ones.

Even the "removing one category of errors" is not true when you use unsafe blocks in Rust, which is done generously in system programming.

Is that so? How large parts of the Rust kernel drivers in existence are inside unsafe blocks?

Yes, unsafe, as the name says, allows unsafe parts. But it is trivial to audit code for the usage of unsafe. Which means, everything else isn't. And it is there where the most common mistakes are made.


Is it trivial to audit? Here is a critical overflow in a matrix transpose: https://vulert.com/vuln-db/crates-io-transpose-125781

This is exactly the mistakes we also have in C and Rust people would do a little dance and take such bugs as argument why C is really dangerous and needs to be avoided. But rather obviously, mistakes can also happen in Rust and Rust does not "eliminate a class of errors" except when completely avoiding unsafe blocks. Maybe Rust is still more memory safe than C, I actually also believe this, but it is nowhere as safe as people like to claim and whether this is worth all the complexity is entirely unclear.


It is trivial to audit the usage of "unsafe". Grep does this. Of course auditing the unsafe functions is another thing. But you can have large codebases without unsafe and consequently a lot of less work with auditing your code. I don't have personal experience with Rust, but quite a bit with Go. It is almost ridiculous, how much more safe Go is in comparison with C. So yes, it is worth every bit.

The example shows that Rust can not even prevent an error as something simple as in a matrix transpose. Sure, you could write safe code, but how does this help if people don't do it? It is the exact same problem as in C and I have seen C code that is very reasonable.

Do you have a link to the code with the error? Following your link I didn't see it.

This is a better link which then has a link to the Github issues: https://rustsec.org/advisories/RUSTSEC-2023-0080

Ok, thanks, finally found the source of transpose. That uses unsafe. Which of course means, all guarantees of safety are off. I am not sure why the usage of unsafe is necessary here, but one way or the other, safety now is in the hand of the programmer.

My point rather was: wherever you don't use unsafe, you are protected by the compiler from certain errors. Which I consider extremely important, that is why I am a strong proponent of memory-safe languages.

Now, if there is a question whether Rust requires you to use unsafe to often, that would be a valid technical critique of Rust, but that didn't seem to drive the Linux discussion.


I think this is exactly the life lie of Rust. It claims to be memory safe and equally suited for system programming. But you get memory safety only when completely avoiding unsafe and it competes with C only when using unsafe. And it is certainly not true that you get memory safety in the part not using unsafe or that you only need to review the unsafe part. The memory safety of the safe part depends on the programmer maintaining invariances in the unsafe part that the Rust compilers needs to ensure the memory safety. At the same time the safety prerequisites of the unsafe parts can be violated by logic errors in the safe part (as in the transpose examples). It still helps to isolate the unsafe part, but in practice I am not convinced that the typical Rust code I see for system programming is fundamentally more secure than equally well designed C code which was also written with an eye towards memory safety and with use of modern tools to find problems.

Still owns you, but without data races!

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

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


but those improvements, and the complexity that they bring, are not enough to make the switch from a Go codebase to a Rust codebase unless performance is REALLY an issue.

> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor

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.


And that is very fair since brigading is definitely not helping here. However, he should have also done the same to Hellwig for his unproductive behavior, yet he did nothing.

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!


People using Mastodon to promote pile-ons or brigading?

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?


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

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


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

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

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


An Intel employee in a reply makes a extremely good point that I think everyone these days needs to follow

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


Said Intel employee needs to follow their own advice.

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)


This seems like a perfectly reasonable response given Hector's prior comments. Pushing someones buttons until they explode and then pointing out they exploded isn't the indictment people think it is.

No, not really.

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.


I fail to see anything in Sima's post that you linked that could be interpreted as toxic, rather than a perfectly normal human response. It's absolutely unreasonable to expect everyone to be perfect, always take the high road, or otherwise shrug off personal attacks.

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.


[flagged]


I have paid special attention to these threads, and I have not seen this. And [flagged] comments don't count: any asshole can create an account and post any ol' bollocks. These posts are not "the community": these are posts "the community" has explicitly flagged and rejected.

So moving to effectively censor criticism that you can't control is justified?

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.


[flagged]


I remember that HN thread[0] and don't think Asahi's version is a good-faith, accurate summary of the contents. IMO they are inaccurately viewing a small number of flagged/dead comments as representative of HN in general.

[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


Do you have a source for this with proof?

Or is it just cause someone said so.


Basically he has to avoid any community with significant numbers of people. Not liking HN, reddit, twitter and so on, its just a numbers game.

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.


I call bullshit on that. The Asahi Linux intiative got a lot of respect and praise on this site whenever I looked at those threads. It's very very unlikely that this negative depiction is accurate. Please show a specific example of a thread that got out of hand like that, otherwise this is completely unbelievable.

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.


I said opinions on a spectrum. Yes, an extreme end of that spectrum is an extreme response.

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.


[flagged]


To think that you can control opinions people have of you in public forums is kind of insane.

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.


[flagged]


No, to your first two points. 100% of the discussion was happening on HN. The blocking of links from HN was 100% about silencing discussion _happening on HN_.

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.


> The blocking of links from HN was 100% about silencing discussion _happening on HN_.

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.


> Haven't noticed people moaning about how those sites are silencing discussion on HN, mind.

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.


Your argument is valid. But the person you are supporting is in favour of "social media brigading". So, there is a fundamental dichotomy here, since by your argument he should be kicked and banned.

>doxxing content

Gonna go out on a limb here and guess that he means there are people in the thread pointing out that the VTuber Asahi Lina is blatantly obviously Hector with a voice changer and that it's really weird that he vehemently insists that it isn't him.

That's not doxxing if so.


It's extra weird to me that people try to live a very public life but then accuse anyone with the slightest amount of criticism of behaving criminally...

Who has made accusations of behaving criminally?..

doxxing. harassment.

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.


I think you are generally correct. I think also the personality types who become public makers, etc. tend to also be controlling, so any negative comments / discussion, etc. that they can’t suppress really irks them and often they go to great lengths to try to get rid of it

Yeah it's really weird. Why push your weird subculture into the spotlight and then cry foul when people are weirded out. Kind of feels like it's all about fishing for even more attention.

[flagged]


[flagged]


Holy false equivalence, how is keeping a pseudonimous vtuber identity comparable to verbal abuse, adultery or social media brigading? See, I'm ok with discussing his mistakes as well, but exposing Lina despite being irrelevant, which happens in every thread about her, feels like bigotry. "Heads up, they're one of those!"

I'm not arguing that this is or isn't a problem but I think the statement "using social pressure to influence decisions" is so general that it could apply to just any discussion. That's kinda what discussion is.

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


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

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


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

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

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


Very doubtful. The maintainer was clear and nothing in there is sufficient to address his criticism: polyglot is unmaintainable and Rust people should write a whole new OS as a separate effort.

Well, Fuschia has been largely ported to Rust, I believe, so... that's coming.

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

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

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


I honestly don't understand what the difference is between "brigading" and "complaining about a thing on mastodon". It's not uncommon to express frustration about something/someone associated with the kernel development process, what makes this particular instance "brigading"?

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

I mean when what you're frustrated about is a leader actively sabotaging what you're working on...

Go on?

Then complaining about that on social media is going to sound a lot like "the leader of this subsystem is sabotaging this thing I'm involved with"

Right, and phrased just like that, it wouldn't have been as objectionable. As I said before, the problem is in the specificity and the direct linking to the conversation. I still take issue with the word 'sabotage' being used here, since the person in question didn't do anything except express objections and an intent not to cooperate. Since this was in a context where that person's cooperation is not needed, I'm not sure he sabotaged anything.

Rust is bad news for Linux.

No because its Rust, but because it's a bad idea to use more than one single language across the entire code base.

I also am surprised that Linus has not ended this folly.

If Rust wants a Linux kernel it should make one.


Do you feel the same about Make, Device Tree, KConfig, Python, the myriad of machine-specific assembly, POSIX shell, Perl, and every other non-C language currently in the code base?

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

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

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

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

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

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


> Refactoring can be painful in Rust when it involves very low-level changes in semantics

I don't know what this is about. In my experience, refactorings that change the semantics of APIs are much easier in Rust than in C. E.g., change assumptions about the lifetimes of pointers passed into APIs: the Rust compiler will tell you where you need to change anything; the C compiler will happily compile your code and you'll corrupt memory at runtime.


Right, and while sometimes a lot of code needs to change in Rust, it's often largely mechanical, at least in typical contexts (e.g. user land development). But Rust won't automatically detect changes in semantics that happen across FFI boundaries. And I didn't argue that refactoring is easier in C than Rust. For one thing, it's an inapt comparison in the context of a mixed C and Rust kernel codebase in which the vast majority of the code and semantics come from the C side.

And there are more subtle issues. From the perspective of C code, Rust looks and behave as if it assumes strict aliasing, a consequence of the borrowing rules--a mutable pointer can never alias. But the Linux kernel uses -fno-strict-alias (i.e. any pointer can alias, regardless of type), so a subtle change in C code which works fine for the kernel could silently break Rust code if the C-side developer wasn't aware of these subtle nuances in memory models and how they were expressed in the unsafe wrappers. This might be a totally contrived scenario[1], or it could be very real given the tower of abstractions built on the Rust side over the C APIs, which might overspecify certain semantics to fit "cleanly" (i.e. best practice) into the Rust model.

Which points at another issue: all of these hypotheticals might be (probably are?) overblown. But over the past 2-3 years, with the exception of a couple of high-profile drivers not yet mainlined (AFAIU), the vast majority of the effort on the Rust side has been building towers of abstraction. In almost any open source project, C or otherwise, a newcomer who starts writing towers of abstractions rather than concrete, usable code would be shooed away. There are reasonable justifications for why Rust has been doing this, yet its also understandable why this might draw suspicions about the practicality and utility of mixing C and Rust in the kernel. But either way it means that after all this time people are still largely arguing over hypotheticals.

[1] Or entirely wrong. Maybe kernel Rust is using flags to ensure aliasing optimizations can't happen. clang (and thus LLVM) supports -fno-strict-alias, but AFAIU alot of Rust code massaging happens on the Rust (MIR or equivalent) side.


Just to be super clear about it, Rust does not do strict aliasing. That’s a totally different set of rules than Rust’s aliasing rules.

I know Rust doesn't do "strict aliasing", literally speaking. But that's partly because Rust's borrowing rules change the framing of the term strict aliasing as used in C, etc. It's similar for terms like "undefined behavior", where there's sometimes a certain amount of pedanticism from Rust developers that merely serves to deflect the point of contention.

Is this wrong? https://doc.rust-lang.org/nomicon/aliasing.html Specifically

> In the previous example, we used the fact that &mut u32 can't be aliased to prove that writes to output can't possibly affect input. This lets us cache *input in a register, eliminating a read.


Yes, it is a completely different set of rules. Strict aliasing is also referred to as type based aliasing analysis. Rust has categorically rejected this form of analysis, the aliasing rules are very different. It has nothing to do with types.

Oh, and "undefined behavior" has effectively the same definition in Rust and in C and C++. There's wording differences:

C/C++: behavior for which this document imposes no requirements

Rust: is not bound by any specification

But that's just a wording difference, not a semantic difference.

There are some instances where Rust and C/C++ use similar words to mean different things, but that's also changed over time. For example, Rust used to use rvalue and lvalue, but has moved to

"place expression", defined as "lvalue" in C and "glvalue" in C++

"value expression", defined as "rvalue" in C and "prvalue" in C++

The only reason to not use the C++ terms here is that these are the only two value categories in Rust, and it's unlikely to need all of the other three that C++ has.

You're not wrong that there's stuff called the same but has different meanings, for example, "reference," but what can you do.


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

And this is the reason why it's always regressing and never moves beyond alpha.


No, I feel this way about the Linux kernel.

Those all exist in the Linux kernel repository. Granted they are not overlapping with c in their purpose for the most part.

One language per repo rules makes sense when you can have many smaller repos, but for something as immense as the Linux monorepo it's really limiting. Especially considering the lack of desire to add stable interfaces from which other repos could operate independently.


Help me out here because I'm not sure how to navigate the submitted link https://lkml.org/lkml/2025/2/7/9. Where is this reprimand / can it be seen?


Yikes, re that fedi thread.

This one bit looks exactly right, though:

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


> I thought Rust in Linux was evaluated, discussed and agreed upon years ago.

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.


> disagree and commit

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.


The Linux kernel is most definitely not developed for free by some college student in their bedroom for the most part. It's Intel and Red Hat and similar.

Edit: related email by Hector: https://lore.kernel.org/rust-for-linux/c5a49bcb-45cf-4295-80...


"R4L dies" is hyperbolic nonsense. There are many ways/places to integrate Rust in the kernel, even for wrappers. It's not like "I think this code should be someone else" automatically means the death of Rust.

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


Rust is only allowed for drivers, because that sidesteps the platform support questions.

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.


People can just include their own dma.rs in driver/.../mydriver/

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.


If it was a good approach, the C folks would have copied around C files instead of having common core code. They did not do that though, because it'd be counter productive due to increasing maintenance burden.

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


Everyone knows you could start the crude way today and refactor the duplication later after it proves itself, if you actually wanted to proceed rather than throw fits.

You can't just endlessly dump more busywork on Rust developers (including genuinely bad code practices) and expect them to deal with it.

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


[flagged]


Hey I think you’re missing important context and in the meantime getting a bit aggressive. Neither is helpful.

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.


So do it. Paste it in.

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.


I don't know the better way to ask this question, so I'm just going to ask it:

"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 am trying to explain why someone would say this.

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.


> 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/20250131075751.GA16720@lst.de/

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


That's a much stronger argument when you aren't at the same time yelling about the email patch system. I want R4L to succeed!

> The Rust drama is an uncommon failure of leadership for Torvalds. Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue. Given the crisis of confidence among a sizeable (and very vocal) contingent of the Linux community, that decision has backfired horribly.

Efficiently collaborating on large distributed open source projects like Linux is as much social activity as technical. For people like Kent Overstreet or marcan and many before them this is apparently a hard thing to grasp and they have been failing badly at following the process, building consensus, earning respect and trust of people from other subsystems, that kind of things. To me it looks like that for Linux big part of R4L experiment is to specifically understand whether Rust people can convince key stakeholders that R4L is good idea and get their buy-in and that is why he doesn't attempt to force it. Also, what is he gonna do to the reluctant but key maintainers? Refuse to accept anything from them until each of them shows him a repo with all Rustlings exercises solved to ensure they are ready for Rust or what?

> And it's quite out of character for Linus not to have a blazingly clear opinion.

Linus tends to have clear opinions on things he is world class in. He is technically brilliant and very knowledgeable in most of the low level systems things but likely not in Rust, so it is understandable for him to just keep being open minded about it and let the chips fall where they may.

> As a pilot program, R4L should have graduated or ended a long time ago. After several years of active development, its status remains unclear.

Which is absolutely normal for the kernel. You can have a driver spending years in staging or RTLinux taking 20 years to get there. It is totally expected for such a disruptive change as introducing new (and quite complicated) programming language to take a few more years to reach maturity.

> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor, but he hasn't said anything explicitly.

Not it isn't.

> decision has backfired horribly

> place responsibility for the drama on Martin's shoulders

> Imagine how much time and energy (even just Martin's alone) could have been saved if Linus had just said "no, keep it downstream".

HN crowd and random JavaScript-kids on Reddit are only hotly debating this because the "drama" has the word "Rust" in the title. For Linux maintainers it is just another day at the office, nothing much to see here honestly.


> To me it looks like that for Linux big part of R4L experiment is to specifically understand whether Rust people can convince key stakeholders that R4L is good idea and get their buy-in and that is why he doesn't attempt to force it.

This is the entire point. This has been DONE. First its "lets see if you can build a good driver", now its "ew rust". The maintainer of the DMA subsystem is showing how they're actively trying to make sure Rust doesn't make it in. .


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

If the minority maintainers scream every time they see other languages due to their insecurities, technical inability and stubbornness, and their overreactions get a pass, it is not the fault of Rust, C++ or Swift. The source of the disturbance is not the people who are making an effort to cause as little disturbance.

Blatant NIMBYism is the problem here and you cannot reduce it by accepting everything.


In general, upstreaming code to Linux involves interacting with difficult and sometimes outright hostile people. I've certainly had my share of both with much smaller changes. IMO pushing something like R4L requires very thick skin and almost infinite amount of patience. Bitching about that won't get you far, you need to be able to either work with or around those people.

This again gets back to the main point which you keep misrepresenting. This has nothing to do with a thick skin, this is a core subsystem maintainer outright saying they won't support R4L, which means its dead.

I'm not misrepresenting anything and R4L is not dead. In fact, two ways forward where suggested right in the LKLM email thread:

- Send the series directly to Linus since there is no code that Hellwig is maintainer of is actually being changed by it and let Linus decide whether to ignore Hellwig's nack. Linus may have done so before, but likely not after marcan's public meltdown.

- Copy/paste the code to every driver that will be using it. If it becomes useful, it will cause more pressure on Hellwig down the road because people will question why every change in code that is being wrapped by this is causing a fix in 10 different copies.

People here and on Reddit who are unfamiliar with the Linux development process but are attracted to the "drama" because it involves Rust somehow keep missing it.


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

Which Chris did doubt, as a way to gatekeep Rust (as you misrepresented, and which is clearly visible in the LKML thread).

regardless, back to the other stuff: First point: Which is what was suggested as well in the LKML and still does not really solve the problem, which is not TECHNICAL but POLITICAL. Second point: Obvious, and wasteful, and again is thus a political move which is the entire point of this entire saga. It isn't about drama, its about the political aspect of the kernel dev being tiring and wasteful.


> Which Chris did doubt, as a way to gatekeep Rust (as you misrepresented, and which is clearly visible in the LKML thread).

Can you provide the exact quote where Hellwig is suggesting that it is impossible to write a driver in Rust? No, you can't? So who exactly is misrepresenting here?

> regardless, back to the other stuff: First point: Which is what was suggested as well in the LKML and still does not really solve the problem, which is not TECHNICAL but POLITICAL. Second point: Obvious, and wasteful, and again is thus a political move which is the entire point of this entire saga. It isn't about drama, its about the political aspect of the kernel dev being tiring and wasteful.

You are shifting the goalpost from this making R4L "dead" to the way forward being "tiring and wasteful". It doesn't look like you are arguing in a good faith so I won't participate in the discussion with you anymore.


> just keep being open minded about it and let the chips fall where they may.

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

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


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

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

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

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


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

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

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


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

> We all know his stance on C++, for instance.

Yeah, but that's because Linux was actually built with g++ for a few versions! The opinion was informed by experience, not an a priori thing. And it was likewise extremely controversial at the time. And eventually they rolled it back out and gave up.

Maybe that will happen with Rust too, or maybe not. But The Process, such as it is, is working today the same way it always has. They try stuff and fight about it, and eventually a winner is clear and a consensus emerges. And, yeah, there are losers, too.


> Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue.

He probably didn't want to end up like Stallman.


> And it's quite out of character for Linus not to have a blazingly clear opinion. (We all know his stance on C++, for instance.)

People change. As you get older, you might find you no longer care that much about subjects you previously had very strong opinions about



someone <cough>https://news.ycombinator.com/user?id=simonw</cough> should create a browser plugin where you can highlight and right-click to get a explanation / context of a chunk of text...

For example: https://gist.github.com/rayvoelker/c5f480f46c80a7a3c22386b29...


I agree with all statement from Linus. Keep it separated/downlined project I think is the best for both worlds.

Could you please post more details on the reprimand you refer to?

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

> How about you accept the fact that maybe the problem is you.

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

> It has problems, but problems are a fact of life. There is no perfect.

> However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.

> Because if we have issues in the kernel development model, then social media sure as hell isn't the solution. The same way it sure as hell wasn't the solution to politics.

> Technical patches and discussions matter. Social media brigading - no than\k you.

> Linus


Obviously he does not like Rust just as much as C++, which is understandable.

The difference is that he is a little bit more diplomatic than he used to be.

But why someone want to push a language into someone else's kernel? Fork your own, if you want.


> As a pilot program, R4L should have graduated or ended a long time ago.

Disagree. These things take time. Linus knows that, and as I see it, he's giving it the time it needs. "After years of active development" we've only recently arrived at a point where actual driver development in Rust is possible.

> We all know [Linus'] stance on C++

Yes. And looking back I think that was a good stance. C++ is not for kernels: the language is too big, containing features that don't fit well with kernel development, thereby inviting all kinds of discussion not conductive to kernel development.

Rust is another story. Rust has potential to bring benefits to the kernel. I think Linus knows that.

Off-topic: I'm looking forward to an --largely automated (maybe with use of LLMs)-- port of the kernel in Zig. Just because I think the developer ergonomics of Zig are so much better than C. Not holding my breath: in 10 years or so would be nice.


> C++ is not for kernels

That's a broad generalization to make.

Nintendo's custom OS (Horizon OS, used on Switch and a previous version on 3DS) is almost fully written in C++, including the entire kernel and all drivers.

I agree with you that C++ has plenty of misfeatures. Fortunately, compiler vendors make it fairly easy to dodge the bad parts of the language.


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

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


3DS HOS was known to be using armcc and Switch HOS is known to be using clang.

Both OSes are huge C++ codebases. Features being disabled or forbidden is a non-userland thing (basically only because resources are constrained. 20KB of exception runtime bload isn't the same thing when you only have 200KB of available RAM vs. when you have 20MB+)

My opinion (and the opinion of people using C++ in such constrained envs.):

* C++ (the language itself along with stuff like <type_traits> and other freestanding headers) is the best thing since sliced bread. So many ways of reducing boilerplate while both writing safe code (RAII) and being mostly in control of produced asm

* most of the other parts of the stdlib are defective

* the committee process sucks, but fortunately compiler vendors allow us to dodge their bad decisions (making #embed available for C++, -fno-exceptions, etc.)


thank Linus for you

[flagged]


I think you overestimate rust and misunderstand the problems. This is classic junior engineer "rewrite everything" thinking

I didn't downvote you, but I think you have a misunderstanding of a couple of things that are clouding your judgement: (1) the sheer size & inertia of the Linux kernel; there are tens of millions of lines of code, and even thinking about integrating another language will take time- lots of it; and (2) the distributed nature of its development and the diversity of its engineers; the community is not one that can be brought into an auditorium and made to change direction on a dime. Rust may have been around for 10 years, but no one was going to go all in on day one.

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.


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

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


I see you responded to both of my comments in this thread, but I'll save us both the trouble by doing a single reply.

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.


I think Linus should change this though, so that the maintainers that don't want to learn Rust have to step down, and there are no more conflicts.

Or dump linux and move to freebsd / haiku

Get rust out of the kernel, now! Rust as a language is meant to be the output of an llm which can be verfied by humans.

Torvalds lost respect of a lot of people, that's the most important thing.

> it shows me the source and I can click on the link to verify the source ... (search engine use case)

To me, this is exactly a search engine. I type my query into 2005-2015 Google, I scan the page summaries under the links to see the answer, and click the best-looking result to confirm or read the details. Occasionally you need to re-word your query to get the answer you're looking for. Sometimes I don't bother clicking through because the answer is right there.

I don't really care that I can use plainer English with an "AI"; I'd be happier if I just got 2010 Google back. But sadly, it's gone.


The "what if you don't have the software" argument doesn't hold water for me. What if you don't have git? What if you don't have a text editor? What if you don't have a filesystem?

Most programming language communities are okay with expecting a certain amount of (modern) tooling, and C can't rely on legacy to remain relevant forever...



That's 32.5 megabits/sec, not MB/s. It uses the 802.11ah standard.

https://www.morsemicro.com/products/

https://en.wikipedia.org/wiki/IEEE_802.11ah


… which is about 4MB/s


And halve that to get "real world" speeds.


> Nobody said they wanted an iPod or iPhone or iPad or a Macbook Air before

What do you mean? There were MP3 players before the iPod, Blackberries and PDAs before the iPhone, and tablet computers and lightweight laptops before Apple popularized them, and people did expect the somewhat clunky early versions of these technologies to improve. For instance, there were a lot of jokes and commentary about the rapid evolution of cellphones in the 1995-2005 era as they went from horrible bricks to trendy gadgets with cameras, software, multimedia, and e-mail -- all before the iPhone had even started development. People were not totally blindsided when Apple offered their streamlined version of already-existing ideas.

Jobs should get credit for the leap in quality, functionality, and mass appeal his products represented, but lately I've noticed the history is getting exaggerated to the point where we were all using rotary phones and beige boxes like cavemen before Steve Jobs singlehandedly invented the laptop, tablet, and smartphone. But the truth is far more nuanced than that.


> For instance, there were a lot of jokes and commentary about the rapid evolution of cellphones in the 1995-2005 era as they went from horrible bricks to trendy gadgets with cameras, software, multimedia, and e-mail -- all before the iPhone had even started development. People were not totally blindsided when Apple offered their streamlined version of already-existing ideas.

In my opinion, the biggest innovation by Apple with the iPhone was that the touch screen is glass and works with skin instead of with the finger nail / stylus. I understand apple didn't invent this but it made multi touch capacitive touchscreen popular.


I remember vividly how unfun resistive touchscreens were.

Especially on tablet computers, which existed long before the iPad, but never caught on. They also had terrible battery life, ugly TFT screens and backlights, unreliable wireless connectivity, laggy UI (Apple seems to be the only company that cared about a consistent 60Hz response), and I think a lot of them ran Windows CE? I'm not sure about that last one, I don't remember, but I'm sure the software sucked.

(I'm excluding the Palm-Pilot-ish devices with low-powered CPUs and monochrome LCDs here; those started popping up in the 80's, and of course there was the failed Apple Newton. The devices I'm talking about were basically x86 laptops without keyboards.)


Was the first iPhone touchscreen even capacitive? I remember using android phones circa 2009 that had resistive touchscreens, it took a bit for capacitive screens to become the norm.


Yes, Apple iPhones have all had a "glass" as opposed to a "plastic" display.

Edit: looked it up. I was wrong. The original demo was plastic. All production iPhones have all had a glass as opposed to a plastic display.

https://www.theverge.com/2019/7/9/20687299/plastic-iphone-go...


While it didn't come out with enough of a gap to suggest Apple was directly copying it, the first capacitative smartphone on the market was the LG Prada.


Did those Mac vs PC commercials also personally offend you?


Whenever anyone says "JavaScript" they actually mean "ECMAScript", which is the language browsers and scripting engines actually implement. The Web standard documents cannot use the term "JavaScript" because of the trademark issue.

There isn't even such a thing as "Oracle JavaScript", they are sitting on the trademark without using it.


> Whenever anyone says "JavaScript" they actually mean "ECMAScript", which is the language browsers and scripting engines actually implement.

It’s the exact opposite though. Whenever someone says ECMAScript they actually mean “I want to say JavaScript but for legal reasons I’m using another name for it” but that also happens so rarely that it’s not worth considering.

If I invent a new term for iPads and say “well actually when people say iPad they mean ECMApad which is technically the same just a different branding of it” that doesn’t give me grounds to have Apples trademark on iPad discarded.

Programmers may not like it, but JavaScript is a pretty well established and robust trademark and people use it correctly to refer to the same one thing. The problem really just is that people don’t like the owners of it, but that’s hardly a case to have it invalidated.


> I invent a new term for iPads and say “well actually when people say iPad they mean ECMApad which is technically the same just a different branding of it” that doesn’t give me grounds to have Apples trademark on iPad discarded.

The point of a trademark is to protect Your brand.

Oracle doesn't make any product called JavaScript nor do they use JavaScript as a trademark in anything.

Your example with Apple is wrong because Apple makes devices that they call iPads.


> and people use it correctly to refer to the same one thing.

Yes, ECMAScript, standardized here: https://ecma-international.org/publications-and-standards/st...


I had ECMAScript on my resume (as JavaScript/ECMAScript) and a technical recruiter asked me what that was.

"Oh, I've never heard of ECMAScript before".

Well, it's a thing. You'll have to trust me on that one.


I’ve been using JavaScript since the first version in Netscape navigator. When I say JavaScript, that’s what I’m referring to. It may have had some things bolted on over the past quarter century, but I still think of it as that thing way back when.


Technically from a legal perspective you aren't using JavaScript any more because it's being produced by a company (Google, Apple, whoever) who doesn't own the trademark to call it JavaScript. So it legally isn't JavaScript even if it's directly descended from something that was legally JavaScript.

The fact that you and everyone else still call this thing we have now JavaScript is exactly why this trademark thing is stupid and most likely invalid.


> hasn't it been dead and burried for decades?

"It's called the American Dream because you have to be asleep to believe it." - George Carlin, like 30 years ago. Just after he observed that "hard-working people of modest means continue to elect these rich cocksuckers who don't give a fuck about them."


America is the best country in the world for growing something new.

Source: I am a non-American who does business in America.


Even if I assume you’re right, upward mobility and ease of starting a business are quite different things.


My thinking has been that society only pays attention to the mechanisms that favour upward movement while completely neglecting how to push down - from the top.

Maybe because of naive concepts like "enlarging the cake for everyone" or - more likely - the top won't allow the protections they raised to be lowered.


How is “enlarging the cake” (usually the metaphor is “pie”) naïve?


If everyone’s slices get enlarged in proportion, the naive assumption, then it works as expected. If some people are clever enough to direct the enlargement towards their slices, then it doesn’t.


The “growing the pie” metaphor has never been about growing all the pieces proportionately. It’s an illustration of how economic growth and Pareto optimization works: you can have a bigger slice (be richer) AND less of the pie (economy grew faster).


When I hear it nowadays, especially from politicians, it sounds more like another way to say “rising tide lifts all ships.” I think it’s taken on a more jingoistic meaning colloquially.


>