24 ms·

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

by gary_0 2y ago

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

chippiewill 2y ago
> 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.
- duxup 2y ago
  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.
  - nicce 2y ago
    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/ https://lwn.net/SubscriberLink/1006805/f75d238e25728afe/
    - threatofrain 2y ago
      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.
      - Yoric 2y ago
        Well, Fuschia has been largely ported to Rust, I believe, so... that's coming.
  - bakugo 2y ago
    > "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.
  - XorNot 2y ago
    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.
- ChocolateGod 2y ago
  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?
  - Hamuko 2y ago
    >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.
  - Philpax 2y ago
    [flagged]
    - busterarm 2y ago
      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.
      - Philpax 2y ago
        [flagged]
        ChocolateGod 2y ago
        Do you have a source for this with proof? Or is it just cause someone said so.
        HideousKojima 2y ago
        [flagged]
- nialv7 2y ago
  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/ https://lwn.net/Articles/991062/ Do your job then, Linus!
- mort96 2y ago
  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"?
  - stonogo 2y ago
    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."
    - mort96 2y ago
      I mean when what you're frustrated about is a leader actively sabotaging what you're working on...
      - stonogo 2y ago
        Go on?
        mort96 2y ago
        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"
        stonogo 2y ago
        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.
dralley 2y ago
>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.
- gauge_field 2y ago
  Agree with that. His statements are available on youtube. I was suprised how positive and eager to the change he was.
- gary_0 2y ago
  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.
  - starspangled 2y ago
    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.
    - threatofrain 2y ago
      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.
      - pjmlp 2y ago
        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.
duxup 2y ago
Help me out here because I'm not sure how to navigate the submitted link https://lkml.org/lkml/2025/2/7/9 https://lkml.org/lkml/2025/2/7/9. Where is this reprimand / can it be seen?
- mauricioc 2y ago
  https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSUGq8vUZAOWWSK1vrJarMaOhReDRQRYQ@mail.gmail.com/ https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU... Edit: For further context for Linus's reply, there's http://web.archive.org/web/20250206022420/https://social.treehouse.systems/@marcan http://web.archive.org/web/20250206022420/https://social.tre...
  - tptacek 2y ago
    Yikes, re that fedi thread.
    - serial_dev 2y ago
      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".
      - tptacek 2y ago
        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!
      - geodel 2y ago
        > 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.
tptacek 2y ago
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.
- Hackbraten 2y ago
  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?
  - imtringued 2y ago
    https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98c3-a48ab35bb9db@marcan.st/ https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98... Just read the email.
devit 2y ago
[flagged]
- doublerabbit 2y ago
  Or dump linux and move to freebsd / haiku
- mu53 2y ago
  I think you overestimate rust and misunderstand the problems. This is classic junior engineer "rewrite everything" thinking
- caspper69 2y ago
  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.
arp242 2y ago
> 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.
- wbl 2y ago
  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.
  - arp242 2y ago
    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.
    - Tuna-Fish 2y ago
      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".
      - 2y ago
artyom 2y ago
> 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.
- pipes 2y ago
  [flagged]
  - sevg 2y ago
    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.
    - artyom 2y ago
      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.
      - dafelst 2y ago
        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.
lII1lIlI11ll 2y ago
> 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.
- deleted 2y ago
  [deleted]
- 2y ago
jmull 2y ago
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.
- nialv7 2y ago
  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-selfish-contributor-revisited/ https://fosdem.org/2025/schedule/event/fosdem-2025-6540-the-... Video isn't out yet, hopefully soon.
  - pabs3 2y ago
    There is an LWN summary of it out already: https://news.ycombinator.com/item?id=42968782 https://news.ycombinator.com/item?id=42968782
- artyom 2y ago
  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.
- _ph_ 2y ago
  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.
quelsolaar 2y ago
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.
- coliveira 2y ago
  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.
  - J_Shelby_J 2y ago
    Then make it so, so that we can RWIR, and Linux can fade into the sunset with Linus.
    - chikere232 2y ago
      Nothing is stopping you
    - mrits 2y ago
      If the Kernel stopped all development it would still not fade into the sunset in our lifetime.
  - preisschild 2y ago
    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.
    - coliveira 2y ago
mathfailure 2y ago
Torvalds lost respect of a lot of people, that's the most important thing.
rednafi 2y ago
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.
- nomel 2y ago
  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?
  - rednafi 2y ago
    And look where it got us!
  - snvzz 2y ago
    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.
ajross 2y ago
> 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.
andrewstuart 2y ago
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.
- tadfisher 2y ago
  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?
  - andrewstuart 2y ago
    No, I feel this way about the Linux kernel.
    - surajrmal 2y ago
      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.
  - wahern 2y ago
    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.
jasoneckert 2y ago
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_in_linux/ 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.
- chikere232 2y ago
  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
ouraf 2y ago
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-house-office-urges-memory-safety/ https://stackoverflow.blog/2024/12/30/in-rust-we-trust-white...
- vlovich123 2y ago
  > 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.
  - stycznik 2y ago
    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-29361481f805@zytor.com/ https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-2936148...
ray_v 2y ago
someone <cough>https://news.ycombinator.com/user?id=simonw</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/c5f480f46c80a7a3c22386b29cd57c90#file-news-ycombinator-com-reply-id-42972525-goto-item-3fid-3d42972062-2342972525-md https://gist.github.com/rayvoelker/c5f480f46c80a7a3c22386b29...
melodyogonna 2y ago
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
- lonjil 2y ago
  > 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?
  - soraminazuki 2y ago
    > 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 https://docs.kernel.org/rust/index.html
    - Ar-Curunir 2y ago
      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.
bhasi 2y ago
Could you please post more details on the reprimand you refer to?
- veidr 2y ago
  https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSUGq8vUZAOWWSK1vrJarMaOhReDRQRYQ@mail.gmail.com/ 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
ranger_danger 2y ago
Linus actually writes C++ code though: https://github.com/subsurface/subsurface/commit/1b16d570a1b6700295153bd6597b148b65000458 https://github.com/subsurface/subsurface/commit/1b16d570a1b6...
eviks 2y ago
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-98c3-a48ab35bb9db@marcan.st/ 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"
MichiB221 2y ago
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."
- deleted 2y ago
  [deleted]
up2isomorphism 2y ago
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.
4bpp 2y ago
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.
- chikere232 2y ago
  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
- geodel 2y ago
  Very reasonable take. I feel the same. Any kind of real or perceived attack on Rust is heresy today.
throwaway2037 2y ago
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.
- hinkley 2y ago
  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?
  - pornel 2y ago
    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.
    - matu3ba 2y ago
      > 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 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.
astrobe_ 2y ago
> 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".
jhoechtl 2y ago
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.
cies 2y ago
> 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.
- TuxSH 2y ago
  > 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.
  - cies 2y ago
    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.
    - TuxSH 2y ago
      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.)
mariconrobot 2y ago
thank Linus for you
meindnoch 2y ago
> 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.
kashyapc 2y ago
> 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@phenom.ffwll.local/ https://lore.kernel.org/rust-for-linux/Z6YPfsDSNdRUskvp@phen...
hadad 2y ago
I agree with all statement from Linus. Keep it separated/downlined project I think is the best for both worlds.
tarruda 2y ago
> 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
ksec 2y ago
>..... 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.
- account42 2y ago
  I always suspected it was commercial/government pressure. Hard to argue against "doing something" for safety.
gerritjvv 2y ago
He sould've and should say no. No Linux has and will be a C project. Imagine going to a project like Rails and trying to convince them they should use C# instead because its better than their language and everyone is wrong. Then if they refuse to change you start going on social media shit posting how all of them are wrong and and they should use the language you decided is king. I think Linus was happy for people to use Rust peripherally, but then they needed changes to the kernel and slowly wants to infiltrate every other project to become rust dependent. This didn't sit well with other maintainers as they use C and arguably don't want or need to deal with Rust. The same they don't want to use Zig, V or C++. You're welcome to develop your driver in Zig, but don't expect others to change their code for you so you can be happy.

by gary_0 2y ago

chippiewill 2y ago

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

duxup 2y ago
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.
- nicce 2y ago
  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/ https://lwn.net/SubscriberLink/1006805/f75d238e25728afe/
  - threatofrain 2y ago
    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.
    - Yoric 2y ago
      Well, Fuschia has been largely ported to Rust, I believe, so... that's coming.
- bakugo 2y ago
  > "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.
- XorNot 2y ago
  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.
ChocolateGod 2y ago
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?
- Hamuko 2y ago
  >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.
- Philpax 2y ago
  [flagged]
  - busterarm 2y ago
    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.
    - Philpax 2y ago
      [flagged]
      - ChocolateGod 2y ago
        Do you have a source for this with proof? Or is it just cause someone said so.
      - HideousKojima 2y ago
        [flagged]
nialv7 2y ago
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/ https://lwn.net/Articles/991062/ Do your job then, Linus!
mort96 2y ago
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"?
- stonogo 2y ago
  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."
  - mort96 2y ago
    I mean when what you're frustrated about is a leader actively sabotaging what you're working on...
    - stonogo 2y ago
      Go on?
      - mort96 2y ago
        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"
        stonogo 2y ago
        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.

dralley 2y ago

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

gauge_field 2y ago
Agree with that. His statements are available on youtube. I was suprised how positive and eager to the change he was.
gary_0 2y ago
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.
- starspangled 2y ago
  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.
  - threatofrain 2y ago
    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.
    - pjmlp 2y ago
      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.

duxup 2y ago

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

mauricioc 2y ago
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSUGq8vUZAOWWSK1vrJarMaOhReDRQRYQ@mail.gmail.com/ https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU... Edit: For further context for Linus's reply, there's http://web.archive.org/web/20250206022420/https://social.treehouse.systems/@marcan http://web.archive.org/web/20250206022420/https://social.tre...
- tptacek 2y ago
  Yikes, re that fedi thread.
  - serial_dev 2y ago
    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".
    - tptacek 2y ago
      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!
    - geodel 2y ago
      > 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.

tptacek 2y ago

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.

Hackbraten 2y ago
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?
- imtringued 2y ago
  https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98c3-a48ab35bb9db@marcan.st/ https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98... Just read the email.

devit 2y ago

[flagged]

doublerabbit 2y ago
Or dump linux and move to freebsd / haiku
mu53 2y ago
I think you overestimate rust and misunderstand the problems. This is classic junior engineer "rewrite everything" thinking
caspper69 2y ago
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.

arp242 2y ago

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

wbl 2y ago
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.
- arp242 2y ago
  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.
  - Tuna-Fish 2y ago
    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".
    - 2y ago

artyom 2y ago

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

pipes 2y ago
[flagged]
- sevg 2y ago
  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.
  - artyom 2y ago
    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.
    - dafelst 2y ago
      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.

lII1lIlI11ll 2y ago

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

deleted 2y ago
[deleted]
2y ago

jmull 2y ago

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.

nialv7 2y ago
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-selfish-contributor-revisited/ https://fosdem.org/2025/schedule/event/fosdem-2025-6540-the-... Video isn't out yet, hopefully soon.
- pabs3 2y ago
  There is an LWN summary of it out already: https://news.ycombinator.com/item?id=42968782 https://news.ycombinator.com/item?id=42968782
artyom 2y ago
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.
_ph_ 2y ago
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.

quelsolaar 2y ago

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.

coliveira 2y ago
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.
- J_Shelby_J 2y ago
  Then make it so, so that we can RWIR, and Linux can fade into the sunset with Linus.
  - chikere232 2y ago
    Nothing is stopping you
  - mrits 2y ago
    If the Kernel stopped all development it would still not fade into the sunset in our lifetime.
- preisschild 2y ago
  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.
  - coliveira 2y ago

mathfailure 2y ago

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

rednafi 2y ago

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.

nomel 2y ago
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?
- rednafi 2y ago
  And look where it got us!
- snvzz 2y ago
  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.

ajross 2y ago

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

andrewstuart 2y ago

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.

tadfisher 2y ago
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?
- andrewstuart 2y ago
  No, I feel this way about the Linux kernel.
  - surajrmal 2y ago
    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.
- wahern 2y ago
  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.

jasoneckert 2y ago

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

chikere232 2y ago
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

ouraf 2y ago

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-house-office-urges-memory-safety/ https://stackoverflow.blog/2024/12/30/in-rust-we-trust-white...

vlovich123 2y ago
> 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.
- stycznik 2y ago
  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-29361481f805@zytor.com/ https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-2936148...

ray_v 2y ago

someone <cough>https://news.ycombinator.com/user?id=simonw</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/c5f480f46c80a7a3c22386b29cd57c90#file-news-ycombinator-com-reply-id-42972525-goto-item-3fid-3d42972062-2342972525-md https://gist.github.com/rayvoelker/c5f480f46c80a7a3c22386b29...

melodyogonna 2y ago

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

lonjil 2y ago
> 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?
- soraminazuki 2y ago
  > 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 https://docs.kernel.org/rust/index.html
  - Ar-Curunir 2y ago
    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.

bhasi 2y ago

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

veidr 2y ago
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSUGq8vUZAOWWSK1vrJarMaOhReDRQRYQ@mail.gmail.com/ 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

ranger_danger 2y ago

Linus actually writes C++ code though: https://github.com/subsurface/subsurface/commit/1b16d570a1b6700295153bd6597b148b65000458 https://github.com/subsurface/subsurface/commit/1b16d570a1b6...

eviks 2y ago

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-98c3-a48ab35bb9db@marcan.st/ 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"

MichiB221 2y ago

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

deleted 2y ago
[deleted]

up2isomorphism 2y ago

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.

4bpp 2y ago

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.

chikere232 2y ago
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
geodel 2y ago
Very reasonable take. I feel the same. Any kind of real or perceived attack on Rust is heresy today.

throwaway2037 2y ago

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.

hinkley 2y ago
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?
- pornel 2y ago
  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.
  - matu3ba 2y ago
    > 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 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.

astrobe_ 2y ago

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

jhoechtl 2y ago

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.

cies 2y ago

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

TuxSH 2y ago
> 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.
- cies 2y ago
  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.
  - TuxSH 2y ago
    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.)

mariconrobot 2y ago

thank Linus for you

meindnoch 2y ago

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

kashyapc 2y ago

> 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@phenom.ffwll.local/ https://lore.kernel.org/rust-for-linux/Z6YPfsDSNdRUskvp@phen...

hadad 2y ago

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

tarruda 2y ago

> 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

ksec 2y ago

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

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

gerritjvv 2y ago

He sould've and should say no. No Linux has and will be a C project. Imagine going to a project like Rails and trying to convince them they should use C# instead because its better than their language and everyone is wrong. Then if they refuse to change you start going on social media shit posting how all of them are wrong and and they should use the language you decided is king. I think Linus was happy for people to use Rust peripherally, but then they needed changes to the kernel and slowly wants to infiltrate every other project to become rust dependent. This didn't sit well with other maintainers as they use C and arguably don't want or need to deal with Rust. The same they don't want to use Zig, V or C++. You're welcome to develop your driver in Zig, but don't expect others to change their code for you so you can be happy.