Spending significant time adapting core kernel code or developing a safe Rust abstraction for DMA, only to be summarily shut down by a single gatekeeper who cites "not wanting multiple languages" is demotivating. It's especially incongruent given that others have championed Rust in the kernel, and Linux has begun hosting Rust modules.
If the project leadership — i.e. Linus — truly wants Rust integrated, that stance needs to be firmly established as policy rather than left up to maintainers who can veto work they personally dislike. Otherwise, contributors end up in a limbo where they invest weeks or months, navigate the intricacies of the kernel's development model, and then find out a single personality is enough to block them. Even if that personality has valid technical reasons, the lack of a centralized, consistent direction on Rust's role causes friction.
Hector's decision to leave is understandable: either you have an official green light to push Rust forward or you don't. Half measures invite exactly this kind of conflict. And expecting one massive rewrite or an all‐encompassing patch is unrealistic. Integration into something as large and historically C‐centric as Linux must be iterative and carefully built out. If one top‐level developer says "no Rust", while others push "Rust for safety", that is a sign that the project's governance lacks clarity on this point.
Hector's departure highlights how messy these half signals can get, and if I were him, I'd also want to see an unambiguous stance on Rust — otherwise, it's not worth investing the time just to beg that your code, no matter how well engineered, might be turned down by personal preference.
I think initially Linus stance of encouraging Rust drivers as an experiment to see how they turn out was a right decisions. There should be some experience before doing long term commitments to a new technology.
But since then a lot of experience was made and I got the notion that the Rust drivers were quite a success.
And now we are at a point where proceeding further does need a decision by Linus, especially as one of the kernel maintainers is actively blocking further work.
> Spending significant time adapting core kernel code or developing a safe Rust abstraction for DMA, only to be summarily shut down by a single gatekeeper who cites "not wanting multiple languages" is demotivating
Christoph Hellwig is one of the oldest subsystem maintainer.
Maybe the Rust developer shall have a more careful behaviour. Nobody wants to break core kernel code.
I've been saying this for years now: the rust4linux folks are putting so much effort into trying to upstream their work, seems like they should instead put that effort into maintaining a fork. Arguably it would be less hours spent porting than arguing with humans. Certainly more pleasant!
Then one of two things will happen:
* Rust will prove its worth and their fork will be the better operating system. Distros will start switching to it one by one due to its increased performance and stability, and they will have dethroned Linus and become gods of the new world.
* The project will die because the C programmers will outcompete it with good ol' C, and all their talk about safety doesn't pan out in the real world.
If I were the rust4linux leadership, I'd roll those dice.
Sounds like Hector Martin is doing exactly that, burning the bridge along the way. Good luck! I think it's the right move (minus the bridge burning).
I think you're discounting the very real damage that would be done by Linux a project controlled by Linus and a community being replaced by Linux a project controlled by Google/Samsung/Redhat/Microsoft. I'm afraid that this is what is going to happen with the Linus tree effectively rejecting rust drivers by subjecting anyone attempting to upstream rust code to persistent bullying, but I don't want it to happen.
> I think you're discounting the very real damage that would be done by [Linux a project controlled by Linus and a community] being replaced by [Linux a project controlled by Google/Samsung/Redhat/Microsoft.]
(Brackets added for clarity)
Isn't the current Linux already Linus + communities + companies?
More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync.
> subject upstream rust code to persistent bullying
I don’t remember seeing this bullying accusation in your original comment. Was it edited in?
Regardless, the “bullying” happened on both sides. Hector Martin started the social media brigading and quit when he couldn’t get his personal enemy suspended for CoC violations. Jonathan Corbet wrote a letter naming and shaming maintainers, in the guise of a report.
All in all, I agree with the GP. Most of the arguments against (even temporary) forking feel like excuses for a lack of will and a maybe even a lack of ability. The space is open for a fork.
Does Linux have the ability to load drivers dynamically (like Windows)? Is there a reason why developers don't develop drivers outside of the kernel and have users simply install them post-install?
> Sounds like Hector Martin is doing exactly that, burning the bridge along the way. Good luck! I think it's the right move (minus the bridge burning).
Unfortunately, what Hector Martin was actually doing is producing rather spectacular flame on LKML and Mastodon. And he isn't representative of other Rust developers either, at least one has voiced their disagreement with him: https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phen...
I agree maintaining a fork would've been a more productive use of Hector's time, but that's not what has been happening and I see no reason to believe it is what will be happening from now on. From my own experience, personalities like Hector quit after not getting their way, rather than looking for other constructive options.
> Now I'm left with the unlikely explanation that
you just like thundering in as the cavalry, fashionably late, maximally
destructive, because it entertains the masses on fedi or reddit or
wherever. I have no idea what you're trying to achieve here, I really
don't get it, but I am for sure fed up dealing with the fallout.
That is a perfect description on what has been happening over the years.
Even if they made a fork and made it super great from a technical perspective, it still would face an uphill battle from the perspective of adoption. The amount of work to get people to switch over would be enormous, and the fact that there's at least some willingness on the part of Linux to adopt Rust in places makes me skeptical that there really would be less work to try to compete. I'd be thrilled if you're right though!
I think a fork with a mission to aggressively rewrite the kernel into Rust would be a great experiment. Lessons learned could be applied to the more mainstream C/Rust kernel(s).
Who would use a kernel that is essentially the mainline kernel with more Rust? Would Debian or Red Hat use it? Maybe some very hard-core Rust hobbyists, but otherwise, why use the Rustier kernel?
But if they could demonstrate significant improvements in security and stability, then they would have something to say. Maybe the plan should be to rewrite a component that the mainline maintainers wouldn't agree to - something important with a significant affect on security and stability. Yes, it's a risk, but if their claims for Rust are true, then it shouldn't be a problem. If Rust doesn't offer a major improvement then it isn't worth the effort anyway. Put their money (or time) where their mouth is.
There are drivers that exist only in Rust, so any distro that wants to support that hardware will. Like the Apple A3 silicon graphics driver. Iirc red hat and nvidia are also working on some Rust based drivers.
I'm a little bit skeptical as to how successful a hard fork of Linux that only differs from the mainline kernel by having a bit more Rust code actually would be.
If you're going to rewrite significant parts of the kernel, you might as well do what I've been doing and try to write what amounts to a better Linux than Linux that tries to maintain compatibility, but moves beyond the rather limiting conventional Unix architecture. The conventional Unix architecture was fine on a something like a 70s/80s-era PDP-11/VAX, but in the modern world its limitations have been apparent for quite some time.
What I've been working on is an OS very similar to QNX Neutrino in terms of general architecture, but with a somewhat different IPC protocol layering that reduces the number of user-visible primitives and allows for more consistent management of security. Most of the functionality of the system will be implemented in user-level server processes that export their services through special filesystems, with the only special/irregular parts of the system being the microkernel, the process manager (which also contains the core VFS and memory filesystems since these will be tightly linked to the process model), and the base syscall library (vaguely akin to the vDSO under Linux). Literally everything else will just be a regular process. It's not a "Rust OS" as such, as there will still be some C (for instance, the microkernel, which was forked from an older version of seL4), although it will have a fair bit of Rust code.
IMO the issues with Linux are mostly due to a combination of poor/ad-hoc extensibility and the development model that's way too decentralized in some places but excessively centralized in others. The architecture I'm going with will allow for more experimentation, since adding functionality to it will typically just be a matter of adding a regular user program (or a plugin for a regular user program), and much of the system will be based around standardized filesystem-based RPC protocols (generic tooling for implementing RPC interfaces will of course be provided). Therefore it would be easier to maintain experimental functionality in a separate repository and merge it into the base system later on.
Currently it's still quite preliminary, and it only runs some hardcoded tests built into the process server, although despite that, some developers from a major company have taken interest in it recently because of the possibility of using it as a replacement for QNX both in embedded systems and development workstations. I'm working on the VFS layer and built-in special filesystems at the moment, and hopefully should be able to get user processes running pretty soon.
Marcan certainly can be abrasive (I mean lol, so can Linus), but all the things he points out in the message below are 100% valid - I highly recommend for anyone here to try to contribute something even very small and logical to the Linux kernel or git (which use similar processes), it’s an eye-opening experience that’s incredibly unapproachable, frustrating, and demoralizing.
Having read through the email thread, I think both vocal people are basically in the wrong here. There is a way to constructively disagree and the DMA maintainer did not do that. The Rust maintainer should not have brigaded using social media.
The “in hindsight” version of how this should have gone without ego:
* Patch adds Rust bindings to C API
* Maintainer has concerns about increased maintenance cost and clarifies policy about C changes and Rust abstraction if unsure.
* Since R4L is approved, the binding is allowed to exist in a form that doesn’t inhibit changes to C API. C API is allowed to break Rust (I assume, otherwise the entire effort is moot).
* Any concerns about tooling etc which DON’T exhibit this property (and can demonstrably show that merging this Rust code will make C code harder to change) are brought up.
* These are resolved as a tooling issue before the change is merged (I don’t think there are any in this case).
All the discussion about multi-language projects etc is for the project as a whole to decide, which happened when R4L was approved and the breakage policy was decided (might need to be properly formalised).
If the maintainer (or anyone) is unreasonable, then the only approach is to have someone with more authority weigh in and make the decision to bypass their objections or sustain them (which is sort of the direction this was going before the diatribes).
> If the maintainer (or anyone) is unreasonable, then the only approach is to have someone with more authority weigh in and make the decision to bypass their objections or sustain them (which is sort of the direction this was going before the diatribes).
While they were arguing, Linus said nothing. While the maintainer was issuing ultimatums, Linus said nothing. Linus only said something when social media forced his hand. This is the real issue.
While I never submitted a patch personally, I had once conferred with some of the input devs to add a trackpad to the synaptics driver... they were queueing up an update to add other trackpads, and they said they would add mine... 5 years later, it's still not there. It was just a one-liner, and I'm not really sure why it never got added...
On the other hand, I once ran into an issue with uboot where a bad update knocked out my emmc, usb and sata controllers... found an email address of someone developing the dtb files and got in touch with them, and it was fixed in under a week.
At the end of the day, people are weird sometimes. I wish all the best for marcan.
I tried once to contribute a fix to be able to use the track-pad on my laptop many years ago. But it was not accepted as the maintainer claimed it was an problem in userspace that did not process out of order events correctly. Despite none of the other drivers sent the events out of order. I had no intention to fix the problem on X11 (the only userspace for this at the time), so I used the patched kernel driver locally until I stopped using that laptop.
https://bugzilla.kernel.org/show_bug.cgi?id=43591https://lore.kernel.org/all/1340829375-4995-1-git-send-email...
FWIW, I have submitted a couple small patches to get the display and gamepad for my Lenovo Legion Go recognized correctly - probably similar levels of complexity to your change. One was to input and one was to display quirks.
They did take months to finally land, and the whole process of getting my corp email address to be compatible with their email-based PR system was way more of a faff than it had any right to be, but they did land. You can install mainline Linux on a Legion Go now and the display and controller will behave as expected, out-of-the-box.
> 5 years later, it's still not there. It was just a one-liner, and I'm not really sure why it never got added.
I think they expect people who want things to advocate harder than just mentioning it once. If no one brings it up again, then they assume that no one cares.
Having contributed a few times, I'd rate it as similar (sometimes much easier!) than contributing to Firefox and Chromium. That is to say that it is indeed extremely time-consuming and frustrating, but when compared to projects of the same scale it does not necessarily come out as more time-consuming or more frustrating - this will never be a small team collaborating on a random Github repo. A simple "swap out X workflow for Y" does not fix these annoyances, and false dichotomies and peer pressure towards is not a way to cooperate.
I cannot claim to have felt the effects on the maintainer-side of this workflow in large-scale projects though.
It's way more painful to contribute to the kernel than contribute to Firefox, at least, unless things have changed since I was involved with Firefox.
Suppose you find a bug in the kernel and come up with a patch. You email the patch to some kernel mailing list and ask for feedback. Typically, you will receive no response whatsoever, because no-one is responsible for responding. You can try emailing random developers and eventually maybe one of them will have mercy on you.
In Firefox and I think Chromium, you can file a bug, attach your patch, request review from someone (the UI will help you choose a suitable person), and it's their job to respond.
Besides the current drama, I'm glad someone of his stature agrees with and can call out the horrible processes and tooling involved in the kernel. Using email and a pile of hacks to mess around with patches just sounds nuts and makes it so much harder to understand or contribute. I don't think decentralized necessitates such a terrible workflow - you can run a local website with a distributed DB, distributed git forges exist, you can use federated chats instead of email, there has to be a better way than email.
I don’t think there is enough demonstrable benefit to sacrifice the ubiquity and flexibility of email for a newer solution, especially for existing maintainers who are probably very comfortable with the current workflow.
Harder to understand and contribute is a bad, but unless there is a proposal for a similarly flexible system that has minimal downsides and massive advantages, the preference of existing maintainers should dominate over potential future contributors. Especially factoring in how expensive of a migration it would be.
Afaik Linus tried Github in the past, but had several significant complaints about it hiding information, messing with basic git operations, generating bad commit messages, etc. . So it is not as if they wouldn't use something better, there just isn't anything that has feature parity with a workflow they have been optimizing for decades.
I always thought it was a pretty blatant "vibe check" to filter out people who are so uncomfortable with software that they can't customize their environment to create an email workflow that works for them.
As someone who has never used mailing lists before (for software development), how much harder/less advantageous it is to migrate to an issues or thread-based approach, like with Github?
It's not Wikipedia, right? Getting the maximum number of contributors isn't a stated goal? I'm a C programmer with a fair bit of kernel experience, and they don't want me, I'm pretty sure, and I'm completely fine with that.
Wikipedia has plenty of gatekeeping too. I once had to submit a single edit three times before the moderators safeguarding the article begrudgingly accepted it.
> Marcan certainly can be abrasive (I mean lol, so can Linus)
My impression of a few glancing online interactions is that they're both abrasive but marcan is quite unwise in a way that Linus has had beaten out of him
In my opinion, calling the well-intentioned hard work of others "cancer" is undeniably hyperbolic and dismissive. It is clear that Hellwig used it in this way. To interpret it differently requires bending the mind. Most people would also consider it rude, but I'll grant that rudeness is more subjective.
There is an argument that being hyperbolic, dismissive, and maybe a bit rude isn't as bad as some people make it out to be, and that it is a fine way to hash out disagreements and arrive at the best solution - that it is simply a result of the passion of exceptional engineers. There has historically been much of it in kernel development. But it seems that as the background and culture of kernel maintainers has broadened, that a more measured and positive approach to communication is more constructive.
It doesn't seem like marcan exemplifies this very well either. It is a loss for someone so skilled to abandon collaboration on the kernel, and seems like the unfortunate result of someone being dismissive and rude, and someone else taking that harder than is warranted or healthy.
Even if you put that aside, the problem is you offer Hellwig two solutions and he NACKs them both.
H: I don't want to support multilanguage codebase
R: We'll have a maintainer verify R4L is behaving properly.
H: I solved issues because they were unified.
R: Rust will be mirror of whatever C is, and you're free to break it, R4L will maintain it.
H: No.
> It was perfectly clear what Hellwig meant by "cancer".
No, it is not perfectly clear.
The generous interpretation is that they meant it is "viral", spreading through dependencies across the codebase (which I don't think is technically accurate as long as CONFIG_RUST=n exists).
The less generous way to interpret it is "harmful". The later messages in the thread suggests that this is more likely.
But I'm left guessing here, and I'm willing to give some some benefit of doubt here.
That said, the response to this comment was incredibly bad as well.
This part of the reply exemplifies one of the big problems in the kernel community:
> You think you know better. But the current process works.
Regardless of how badly broken the kernel development process is, Linus and others observe that Linux continues to dominate and conclude that therefore the development process "works". Success in the market blinds the successful vendor to their defects. Sound familiar?
If Linux carries on down this path then eventually something else that has been subject to more evolutionary pressure will displace Linux, and we'll all be telling stories about how Linux got complacent and how it was obvious to everyone they were heading for a fall.
And honestly, with maintainers like Hellwig maybe that's what needs to happen.
I find this reply interesting. Linus says that what matters is technical stuff, but even before the social media brigading, the whole thread was nothing but non-technical drama. So why is Linus focused only on that and not Hellwig's behavior?
Definitely interesting to read both sides. I think they both present compelling arguments. There's a need to ensure stability with the kernel and avoid interference with outside forces. I suppose balancing that principle with eventual change is an inevitable difficulty.
I've contributed here and there over there years, even got something merged that broke Linus's printer driver. It really isn't unapproachable, frustrating, or demoralizing.
Haha it’s funny that this stuff is still going on. The difficulty of getting things into mainline is why Con Kolivas stopped developing his interactivity-prioritizing schedulers for Linux some 20 years ago. It’s just how the project works.
I agree contributing code to the kernel is by no means as approachable or easy going but it's not self-evident that alone is supposed to be the sign of bad things™ unlike more specific examples boiling up to be part of that picture. Are there things and ways I think it could be improved? For sure! I just don't necessarily think they imply the resulting process would be quick and painless.
The Rust drama is an uncommon failure of leadership for Torvalds. Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue. Given the crisis of confidence among a sizeable (and very vocal) contingent of the Linux community, that decision has backfired horribly. And it's quite out of character for Linus not to have a blazingly clear opinion. (We all know his stance on C++, for instance.)
As a pilot program, R4L should have graduated or ended a long time ago. After several years of active development, its status remains unclear. Instead of cracking heads to get everyone on the same page, Linus has instead spent all this time sitting back and watching his subordinates fight amongst themselves, only to then place responsibility for the drama on Martin's shoulders. Poor form.
Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor, but he hasn't said anything explicitly. Maybe he knows he should, but he fears the shitstorm it will cause. Maybe it's time for him to rip off the band-aid, though.
And again, all of this could have been avoided if he'd just put his foot down one way or the other. Imagine how much time and energy (even just Martin's alone) could have been saved if Linus had just said "no, keep it downstream".
> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor
That doesn't really have anything to do with Rust; but with Hector's behaviour. Threatening a social media campaign to out people is completely toxic behaviour. This is a long-term contributor who is perhaps a bit abrasive, not Jimmy fucking Saville.
Other than that, it's not a binary yes/no question; no one is really against some Rust in some parts of the kernel, but which parts? How? Where? That's the big disagreement. Linus has always been fairly hands-off on these types of disagreements.
> Threatening a social media campaign to out people is completely toxic behaviour. This is a long-term contributor who is perhaps a bit abrasive, not Jimmy fucking Saville.
I'm no where near in the loop on this, but that sounds incredibly toxic. Are there some good links to summarize this?
EDIT:
OK, these are fully enough to allow me to understand the issue.
I'm usually very critical of how Torvolds treats the people around him and the culture he maintains but this is a rare case when I'm not really against Torvalds on this.
I've had to remove Hector's postings from my feeds because he just constantly bitches and complains about pretty much everything. He's capable, smart, and is doing more than anybody ever will for Apple hardware. But he desperately needs to Stop Posting. Without anybody he works with regularly to give him a reality check, I don't think he's going to change course.
I think Hector has some valid complaints about the contribution process to the kernel, I know. It fucking sucks ass and I've given up on trying. But screaming the way he does is counter productive to improving it
> Other than that, it's not a binary yes/no question; no one is really against some Rust in some parts of the kernel, but which parts? How? Where? That's the big disagreement. Linus has always been fairly hands-off on these types of disagreements.
Some Kernel maintainers are absolutely against Rust anywhere in the kernel tree [0]:
> The only reason Linux managed to survive so
long is by not having internal boundaries, and adding another language
complely breaks this. You might not like my answer, but I will do
everything I can do to stop this.
This is from Christoph Hellwig, the DMA maintainer. And is in fact what started the thread that led to Hector Martin quitting Linux. You can see other comments by Hellwig in that thread as well, he is extremely explicit - any Rust anywhere in the kernel is a big problem, and even if he can't stop it everywhere, he will do what he can to make it harder to use Rust by blocking it from the pieces he maintains.
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.
IMHO social media is toxic period and has no place in any professional interaction. It is inherently biased toward drama and bullshit by design, since this “maximizes engagement.”
The sooner politicians are outright banned from using it for anything connected to their office the better.
> no one is really against some Rust in some parts of the kernel
Dude, this was literally caused by a stubborn maintainer, Hellwig, saying he wants NO second language in the kernel at all, and his explicit vow to do anything he can to stop it.
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.
> IMHO the one and only thing that made Linux successful as a project is Linus' strong leadership - which has been criticized ad-nauseam over the years; yet it's the only thing that yields results.
I wear garlic every day and have yet to be attacked by a vampire; clearly this is due to the garlic!
Tang/ballpoint pens/velcro never would have been invented if it weren't for the Apollo program.
> IMHO the one and only thing that made Linux successful as a project is Linus' strong leadership
Naah, I don't think that's the only thing that did it. It was that, and the fact that people dared rely on it -- dared trust it to stick around, and to stay a single thing in stead of splintering up. And the thing that made it Open Source that stays Open Source -- that made it, in fact, Free Software -- is the license.
The two things that made Linux successful as a project are Linus' strong leadership and the GPL.
Just look at BSD: It had the backing of a whole darn university near Silicon Valley, not a single student somewhere North of The Wall. It had a head start by several years. And it had name recognition far beyond its home country[1]. And look where it is now: There are (at least?) three of them, and even together they're a marginal phenomenon among operating systems. I think that's because of the too-permissive BSD license.
___
[1]: The first I heard of "Open Systems" was well before I got into working with computers for a living, as a student at another university in the Frozen North in the late 1980s. My fiend and neighbour, a computer student, raved about how cool Unix was: "And you can even get it for free! It's called BSD!"
No, you get it backwards. Open source community folks despise any commands, the moment Linus orders free folks like you to do something will be the moment his leadership ends.
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.
Well, while Hector had a long history of frustrations with working with kernel development, the project of integrating rust drivers in the kernel has reached a cross-roads. Either to take the next steps or effectively close the door of the kernel progressing further with C and all the debt it brings.
From what I saw, the project of writing the graphic drivers for ARM Macs was quite a success, so the door for those projects shouldn't be closed.
The policy of "No C++, because I don't want to deal with C++ people", should be extended to the Rust community. Whatever you think of the merits of the Rust language, the drama, the lecturing and the general superiority complex of the Rust community is quite off putting, at least to C developers.
I also agree that Linux should close the door to Rust as a matter of principle, as it has done to any other language other than C. I don't believe in a mixed language kernel, it is just nonsense, specially with such a different language such as Rust which is closer to C++ in philosophy.
Linux kernel community is afraid of drama? I've been using Rust as a primary language for years now and would agree that the community is lead by immature drama queens. However, the linux kernel team would be the best comparison.
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.
The problem is, that he let's a maintainer say he is going to fight any Rust code getting into any "core" (whatever he considers core) part of the kernel, even if it's just a wrapper to make driver code more maintainable. I would say, that's a strategy decision that should not be up to any subsystem maintainer, that's a decision that should be up to Linus, by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers. I don't believe that was what the rust guys thought they'd be signing up for.
Why would he make such blanket decision on something he does not completely understand?
The maintainers of core subsystems are the people he trusts, at least trusts as much as you can in this space. He'll take their opinions before anyone else, since they know best about the subsystems they maintain.
To get Linux to overrule them you not only need to come up with very very convincing technical argument, you have to make sure you also posses the depth and competence required to maintain any such subsystem if the maintainers rage quit. Because you see, maintainers of these subsystems resigning is the bigger blow
> The maintainers of core subsystems are the people he trusts, at least trusts as much as you can in this space. He'll take their opinions before anyone else, since they know best about the subsystems they maintain
But there were no technical arguments against the Rust wrapper. And in any case, the Rust wrapper isn't in that subsystem, it just uses that subsystem. Hellwig's argument was nothing more than "there shouldn't be a second language in the kernel". He had nothing specific about the DMA wrapper. And Linus has already approved Rust in the Linux kernel, so what's the problem? Why can't Linus put his foot down on an issue that he has already decided on?
I think at the point where you're loudly complaining about the email patch process (and hey, I agree it's the worst), this has stopped being about Rust.
May I ask which aspect of the email patch process you're referring to?
Arguably, I've used it only once to contribute a kernel bugfix, and I was lucky enough that my patch got accepted as is. So I found the process pretty straightforward.
But even with iterations and revisions factored in, kernel work itself feels orders of magnitude more complex and cumbersome to me than a patch process based on a mailing list could ever be?
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."
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?
> 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.
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.
> 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.
And his viewpoint at the time seemed fairly agnostic - he enjoyed the passion on both sides but said nothing about what his thoughts were. This leads me to believe that he hasn't spent the time to think about the important issues on either side and make a decision (the failure of leadership mentioned in the parent comment).
Personally, I'm surprised Linus hasn't gone 100% in on Rust as he is normally very forward-thinking, so perhaps that has added to the frustration from so many kernel developers like Hector.
If you're gonna lead a group of people effectively, you kinda have to listen to them. leading by decree works occasionally, but you can't afford to do it often.
If there's a lot of people sceptical to rust, doing a limited experiment is one way to figure out if it's going to work. Rust people working in the kernel should act accordingly. Drama like this is not helpful
How is it uncommon if the issues identified in this drama cycle (eg from here https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...) are systemic and have existed for many years? That's just a continuous failure of leadership, all ignored by said leadership under the pretense that "it works, so it must be right"
> 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".
>..... 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.
Can I ask something controversial? What if Rust never becomes a significant part of the Linux kernel? What if they keep stalling and all the people pushing for it give up? There seems to be this faith on HN that Rust absolutely belongs in the Linux kernel and if not, the project is a failure.
If you wait long enough a Rust competitor will gain traction. And honestly I wonder if that might not be for the best. How many of rust’s features have only been tried a couple of times?
My thought is what's telling is the 'rewrite it in rust'. Rust doesn't have a new business case.
C was better than assembly.
C++ was better than C for GUI applications.
JAVA has garbage collection and usually won't force you to fix your machine after a bad crash.
Python is better than Perl for quick and dirty stuff.
PHP lets you build a web service without much pain.
C# is a better Java that also gives you better integration with Windows.
Go does a good job with small quick running services.
Lua is easy to integrate into programs.
I look at existing C codebases. They're usually well worn and work okay.
C++ codebases would probably be better rewritten in Go or C#
Go codebases? Switching to Rust so you can what exactly?
PHP? Keep using it or us Go.
I also feel like Go, C#, and Python are designed to be fairly easy for a noob to come up to speed. Where Rust is the opposite.
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?
> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor
His reprimand is a clear signal that he won't tolerate brigading. Marcan was making a pretty blatant attempt at using social pressure to influence decisions.
And that is very fair since brigading is definitely not helping here. However, he should have also done the same to Hellwig for his unproductive behavior, yet he did nothing.
Oh and I got this quote for you:
> Linus Torvalds admonished the group that he did not want to talk about every subsystem supporting Rust at this time; getting support into some of them is sufficient for now. When Airlie asked what would happen when some subsystem blocks progress, Torvalds answered "that's my job".
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?
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.
I honestly don't understand what the difference is between "brigading" and "complaining about a thing on mastodon". It's not uncommon to express frustration about something/someone associated with the kernel development process, what makes this particular instance "brigading"?
> The Rust drama is an uncommon failure of leadership for Torvalds. Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue. Given the crisis of confidence among a sizeable (and very vocal) contingent of the Linux community, that decision has backfired horribly.
Efficiently collaborating on large distributed open source projects like Linux is as much social activity as technical. For people like Kent Overstreet or marcan and many before them this is apparently a hard thing to grasp and they have been failing badly at following the process, building consensus, earning respect and trust of people from other subsystems, that kind of things. To me it looks like that for Linux big part of R4L experiment is to specifically understand whether Rust people can convince key stakeholders that R4L is good idea and get their buy-in and that is why he doesn't attempt to force it. Also, what is he gonna do to the reluctant but key maintainers? Refuse to accept anything from them until each of them shows him a repo with all Rustlings exercises solved to ensure they are ready for Rust or what?
> And it's quite out of character for Linus not to have a blazingly clear opinion.
Linus tends to have clear opinions on things he is world class in. He is technically brilliant and very knowledgeable in most of the low level systems things but likely not in Rust, so it is understandable for him to just keep being open minded about it and let the chips fall where they may.
> As a pilot program, R4L should have graduated or ended a long time ago. After several years of active development, its status remains unclear.
Which is absolutely normal for the kernel. You can have a driver spending years in staging or RTLinux taking 20 years to get there. It is totally expected for such a disruptive change as introducing new (and quite complicated) programming language to take a few more years to reach maturity.
> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor, but he hasn't said anything explicitly.
Not it isn't.
> decision has backfired horribly
> place responsibility for the drama on Martin's shoulders
> Imagine how much time and energy (even just Martin's alone) could have been saved if Linus had just said "no, keep it downstream".
HN crowd and random JavaScript-kids on Reddit are only hotly debating this because the "drama" has the word "Rust" in the title. For Linux maintainers it is just another day at the office, nothing much to see here honestly.
> To me it looks like that for Linux big part of R4L experiment is to specifically understand whether Rust people can convince key stakeholders that R4L is good idea and get their buy-in and that is why he doesn't attempt to force it.
This is the entire point. This has been DONE. First its "lets see if you can build a good driver", now its "ew rust". The maintainer of the DMA subsystem is showing how they're actively trying to make sure Rust doesn't make it in. .
> just keep being open minded about it and let the chips fall where they may.
It's a failure of leadership to not intervene when discord threatens the group. He should weigh in, or make sure that someone else who has mutual trust weighs in.
In youth sports, something similar happens when referees fail to call fouls on rough play. Players naturally test the limits and then others recognize the lack of protection and retaliate until it gets really out of hand.
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.
> 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.
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.
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.
> 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.
If an individual maintainer can veto critical parts of the Rust for Linux project and announce they'll do everything they can to stop it, then Linus is wasting everyone else's time pretending it's a real project. It's not a proper environment to put contributors in.
I think it's rather silly to have some subsystem maintainers do everything in their power to sabotage the improvement projects by subsystem and even high level maintainers in the kernel.
It was a fine position to take back when introduction of Rust into the kernel was still very much a discussion point. However, the discussion is over, Rust has been accepted into the kernel. This entire struggle has been kernel developers sabotaging other kernel developers.
This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything.
That said, using social media to cause drama when a Linux maintainer is being an ass is just as stupid, if not worse. Both sides of the conflict are in the wrong here.
The DMA subsystem maintainer has some reasons: at this time you can disable all rust drivers when building the Linux kernel but you cannot disable rust wrappers to C language APIs. So if you need to change for example the DMA APIs, you also need to fix the rust wrapper before submitting the C patches otherwise you cannot even build a C only kernel.
> This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything.
Well, this is your take, as you explicitly wrote "I walk away with the feeling". My take is: The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things. If too many people aren't happy with the way the linux kernel is developed, they are free to fork it and develop in the way that they see fit.
He couldn't veto it anyway; by reading the entire thread, you'll see that the maintainer NACKed the request.
After that, Greg KH stepped in (since he was soft asked to help earlier in the thread with an @) to reconfirm that what seems to be the general policy for r4l is followed (aka it'll be a separate file with its own maintainer), with the subtle implication that it would probably just get merged as a separate patch to Linus directly, the complaints of the maintainer be damned.
Marcan's sudden outburst and forcibly adding Linus and Greg to the thread he was responding to came afterwards. You can even see some other rust4linux devs asking him to please not do this, since the situation is under control.
Put yourself in the shoes of the person submitting this patch. Is a "subtle implication" (and to be clear, it was a very subtle one if it was one at all) that a senior maintainers NAK on a patch is going to be ignored enough to make the whole situation not incredibly demoralizing?
Does it do much of anything to solve the fact they've publicly declared that they are going to do everything they can to stop the project, and that there's a history of them doing just that going on for years now?
Marcan's response clearly wasn't the most productive way to raise these issues, but the issues are there and are not being addressed.
That is not what the maintainer said. The maintainer said that for Rust code in the area he is currently maintaining. I think the main issue was, the he was not accepting second maintainer to take care the Rust part on the same area.
About the Rust code itself; the primary issue was code duplication rather than preventing the use of Rust altogether. Since the suggested code is not merged, every driver needs to write the same code over and over again. That was also something that the maintainer suggested himself (?). There is of course a big downside, but I am not sure if this justifies all the hate.
>That is not what the maintainer said. The maintainer said that for Rust code in the area he is currently maintaining. I think the main issue was, the he was not accepting second maintainer to take care the Rust part on the same area.
The Rust code is not in the area he was currently maintaining. Christoph didn't even look at the patches before objecting to them. Once it was pointed out that they were not in his area, he rejected them anyway.
Note that, because they are not in his area, he does not actually have the authority to do this. He was CC'd in an advisory sense, it's not really his call to accept them or not, and as a longtime kernel maintainer he surely knows this.
"The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux." https://lwn.net/ml/all/20250204052916.GA28741@lst.de/
That doesn't sound like he's only talking about in his area to me
I think the core of the issue is expecting people to agree with stuff.
Linux is free software and there's really nobody stopping people from forking it and doing things the way they want. It used to happen all the time once upon a time, nowadays people seems to be afraid of doing it.
The kernel is nearly 30 million lines of code. I would love to see a fork where Rust starts taking over sections of it, but that's a huge undertaking that would clearly take many years.
I wouldn‘t expect a grand Rust announcement anytime soon, above what has already been said. Rust in the kernel seems to be fine, but it will have to adapt to longstanding kernel processes. And if it means there won‘t be Rust in some maintainers‘ subsystems, so be it. The kernel won‘t be 100% Rust next year anyway.
> Simona Vetter: (addressing Hector) ...Now I'm left with the unlikely explanation that you just like thundering in as the cavalry, fashionably late, maximally destructive, because it entertains the masses on fedi or reddit or wherever. I have no idea what you're trying to achieve here, I really don't get it, but I am for sure fed up dealing with the fallout.
> Dave Airlie: To back up Sima here, we don't need grandstanding, brigading, playing to the crowd, streamer drama creation or any of that in discussions around this. The r4l team and drm maintainer team have this sort of thing in hand, it's not like we don't understand the community of the Linux kernel, and having this first reaction to blow shit up and dramatise it just isn't helpful.
(Obviously I am taking things a bit out of context here, I recommend giving this thread a read.)
Seems to be pretty level-headed, on point, and damning. So yeah, I don't know if I am on marcan's side this time.
> Being toxic on the right side of an argument is still toxic, [...]
unironically, immediately after saying @marcan
> and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off
...is quite tonedeaf at the very least. Especially given what Marcan said about dealing with this not being his paid job.
From what I can piece together it seems Hector is upset about someone ("Hellwig"?) doing something that was seen as intentionally sabotaging the rust efforts. Hector posted about it on socials. Linus came down on Hector for leveraging socials to fight kernel disputes. Hector quits.
No doubt that is a flawed summary so feel free to correct
You're roughly correct but you're missing some important context.
Hector wasn't the developer of this patch. However, he is a user of it. He has had some rough interactions over the last few years. And so seeing this happen (even though it's happening to someone else) is a "the straw that breaks the camel's back" kind of deal.
Marcan is probably a little acutely upset not just because he was told off, but also because Linus hasn't waded into the actual issue at hand (which he needs to, not even Greg K-h can answer it). But that issue is less urgent and it's probably reasonable for Linus to:
a) Mull it over before making a rash decision
b) let tempers calm.
I would guess Linus will wait til Monday and is probably also having some off-list chats anyway.
I couldn't speak to off-list chats, but this has been going on for awhile.
The statement that they were going to maintain this without the support of the DMA maintainer was made 22 days ago [1]. That statement was rejected 11 days ago [2]. Linus was explicitly asked to intervene 10 days ago [3]. (Too complete the timeline Hector Martin first got involved 4 days ago, Linus intervened about that yesterday).
I don't know why you think Linus will suddenly choose to address this Monday.
Note: I did not intend to particularly link to Christoph Hellwig comments, it just so happens that these contain enough quoting form previous answers to trace out something coherent.
For the complete context, you should walk up/down (and laterally) the thread to get more details and make your own opinion of it. It doesn't take very long.
Yup, I'm not at all understanding the framing of those posts as "brigading". He's venting, justifiably angry. He wasn't like "go post at these guys and help me fight!", at least I didn't see anything in his messages suggesting anything along those lines.
I'm not disagreeing as I don't know what exact things you're talking about, but I find "virtue signalling" and "communication" to be very similar terms these days. From statement to statement I'm not sure what anyone means by that phrase anymore.
"Turns out FOSS devs are humas just like everybody else and suffer from the same flaws."
Hell no. FOSS communities, as other spaces created by permanently online individuals, definitely have higher-than-average number of mentally unhinged snowflakes.
> Turns out FOSS devs are humas just like everybody else and suffer from the same flaws.
It is rather anticlimactic. I had always imagined FOSS to be this free exchange of ideas, thoughtful consideration, and intentional action. Seeing what it has become though… Maybe closed source is better.
> Martin has worked hard on Asahi, but comes of as looking for drama and virtue signalling oftentimes.
Aren't these diametrically opposed? Virtue signaling is loudly claiming to have some virtue in the absence of that virtue. Hector has receipts, in the form of commits, as proof.
Virtue signaling would be me appearing on the mailing list and spouting my beliefs.
Readit News
Spending significant time adapting core kernel code or developing a safe Rust abstraction for DMA, only to be summarily shut down by a single gatekeeper who cites "not wanting multiple languages" is demotivating. It's especially incongruent given that others have championed Rust in the kernel, and Linux has begun hosting Rust modules.
If the project leadership — i.e. Linus — truly wants Rust integrated, that stance needs to be firmly established as policy rather than left up to maintainers who can veto work they personally dislike. Otherwise, contributors end up in a limbo where they invest weeks or months, navigate the intricacies of the kernel's development model, and then find out a single personality is enough to block them. Even if that personality has valid technical reasons, the lack of a centralized, consistent direction on Rust's role causes friction.
Hector's decision to leave is understandable: either you have an official green light to push Rust forward or you don't. Half measures invite exactly this kind of conflict. And expecting one massive rewrite or an all‐encompassing patch is unrealistic. Integration into something as large and historically C‐centric as Linux must be iterative and carefully built out. If one top‐level developer says "no Rust", while others push "Rust for safety", that is a sign that the project's governance lacks clarity on this point.
Hector's departure highlights how messy these half signals can get, and if I were him, I'd also want to see an unambiguous stance on Rust — otherwise, it's not worth investing the time just to beg that your code, no matter how well engineered, might be turned down by personal preference.
But since then a lot of experience was made and I got the notion that the Rust drivers were quite a success.
And now we are at a point where proceeding further does need a decision by Linus, especially as one of the kernel maintainers is actively blocking further work.
Christoph Hellwig is one of the oldest subsystem maintainer.
Maybe the Rust developer shall have a more careful behaviour. Nobody wants to break core kernel code.
Also it's not his domain, from Marcan's Reddit response Greg is one in charge of maintaining this area.
So this is drive by reviewing.
Dead Comment
Then one of two things will happen:
* Rust will prove its worth and their fork will be the better operating system. Distros will start switching to it one by one due to its increased performance and stability, and they will have dethroned Linus and become gods of the new world.
* The project will die because the C programmers will outcompete it with good ol' C, and all their talk about safety doesn't pan out in the real world.
If I were the rust4linux leadership, I'd roll those dice.
Sounds like Hector Martin is doing exactly that, burning the bridge along the way. Good luck! I think it's the right move (minus the bridge burning).
(Brackets added for clarity)
Isn't the current Linux already Linus + communities + companies?
More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync.
I don’t remember seeing this bullying accusation in your original comment. Was it edited in?
Regardless, the “bullying” happened on both sides. Hector Martin started the social media brigading and quit when he couldn’t get his personal enemy suspended for CoC violations. Jonathan Corbet wrote a letter naming and shaming maintainers, in the guise of a report.
All in all, I agree with the GP. Most of the arguments against (even temporary) forking feel like excuses for a lack of will and a maybe even a lack of ability. The space is open for a fork.
Can they do that to openssl instead?
Thank you.
Dead Comment
Unfortunately, what Hector Martin was actually doing is producing rather spectacular flame on LKML and Mastodon. And he isn't representative of other Rust developers either, at least one has voiced their disagreement with him: https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phen...
I agree maintaining a fork would've been a more productive use of Hector's time, but that's not what has been happening and I see no reason to believe it is what will be happening from now on. From my own experience, personalities like Hector quit after not getting their way, rather than looking for other constructive options.
That is a perfect description on what has been happening over the years.
Has anyone done that?
Asterinas is such an experiment. Purely written in Rust and Linux ABI compatible.
It's not a fork of Linux but a ground up effort to write a kernel in Rust. Still they're trying to make it compatible with Linux/BSD
But if they could demonstrate significant improvements in security and stability, then they would have something to say. Maybe the plan should be to rewrite a component that the mainline maintainers wouldn't agree to - something important with a significant affect on security and stability. Yes, it's a risk, but if their claims for Rust are true, then it shouldn't be a problem. If Rust doesn't offer a major improvement then it isn't worth the effort anyway. Put their money (or time) where their mouth is.
i think it's going to fail because of rust as a language, not because the ideas in rust are bad but because there's infinite complications
If you're going to rewrite significant parts of the kernel, you might as well do what I've been doing and try to write what amounts to a better Linux than Linux that tries to maintain compatibility, but moves beyond the rather limiting conventional Unix architecture. The conventional Unix architecture was fine on a something like a 70s/80s-era PDP-11/VAX, but in the modern world its limitations have been apparent for quite some time.
What I've been working on is an OS very similar to QNX Neutrino in terms of general architecture, but with a somewhat different IPC protocol layering that reduces the number of user-visible primitives and allows for more consistent management of security. Most of the functionality of the system will be implemented in user-level server processes that export their services through special filesystems, with the only special/irregular parts of the system being the microkernel, the process manager (which also contains the core VFS and memory filesystems since these will be tightly linked to the process model), and the base syscall library (vaguely akin to the vDSO under Linux). Literally everything else will just be a regular process. It's not a "Rust OS" as such, as there will still be some C (for instance, the microkernel, which was forked from an older version of seL4), although it will have a fair bit of Rust code.
IMO the issues with Linux are mostly due to a combination of poor/ad-hoc extensibility and the development model that's way too decentralized in some places but excessively centralized in others. The architecture I'm going with will allow for more experimentation, since adding functionality to it will typically just be a matter of adding a regular user program (or a plugin for a regular user program), and much of the system will be based around standardized filesystem-based RPC protocols (generic tooling for implementing RPC interfaces will of course be provided). Therefore it would be easier to maintain experimental functionality in a separate repository and merge it into the base system later on.
Currently it's still quite preliminary, and it only runs some hardcoded tests built into the process server, although despite that, some developers from a major company have taken interest in it recently because of the possibility of using it as a replacement for QNX both in embedded systems and development workstations. I'm working on the VFS layer and built-in special filesystems at the moment, and hopefully should be able to get user processes running pretty soon.
https://gitlab.com/uxrt/uxrt-toplevel
Deleted Comment
Dead Comment
https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
The “in hindsight” version of how this should have gone without ego:
* Patch adds Rust bindings to C API
* Maintainer has concerns about increased maintenance cost and clarifies policy about C changes and Rust abstraction if unsure.
* Since R4L is approved, the binding is allowed to exist in a form that doesn’t inhibit changes to C API. C API is allowed to break Rust (I assume, otherwise the entire effort is moot).
* Any concerns about tooling etc which DON’T exhibit this property (and can demonstrably show that merging this Rust code will make C code harder to change) are brought up.
* These are resolved as a tooling issue before the change is merged (I don’t think there are any in this case).
All the discussion about multi-language projects etc is for the project as a whole to decide, which happened when R4L was approved and the breakage policy was decided (might need to be properly formalised).
If the maintainer (or anyone) is unreasonable, then the only approach is to have someone with more authority weigh in and make the decision to bypass their objections or sustain them (which is sort of the direction this was going before the diatribes).
> If the maintainer (or anyone) is unreasonable, then the only approach is to have someone with more authority weigh in and make the decision to bypass their objections or sustain them (which is sort of the direction this was going before the diatribes).
While they were arguing, Linus said nothing. While the maintainer was issuing ultimatums, Linus said nothing. Linus only said something when social media forced his hand. This is the real issue.
On the other hand, I once ran into an issue with uboot where a bad update knocked out my emmc, usb and sata controllers... found an email address of someone developing the dtb files and got in touch with them, and it was fixed in under a week.
At the end of the day, people are weird sometimes. I wish all the best for marcan.
They did take months to finally land, and the whole process of getting my corp email address to be compatible with their email-based PR system was way more of a faff than it had any right to be, but they did land. You can install mainline Linux on a Legion Go now and the display and controller will behave as expected, out-of-the-box.
I think they expect people who want things to advocate harder than just mentioning it once. If no one brings it up again, then they assume that no one cares.
Should probably have just asked again, or sent a small one-line patch. It's "mention something on Slack" vs "creating a GitHub issue/PR"
I cannot claim to have felt the effects on the maintainer-side of this workflow in large-scale projects though.
Suppose you find a bug in the kernel and come up with a patch. You email the patch to some kernel mailing list and ask for feedback. Typically, you will receive no response whatsoever, because no-one is responsible for responding. You can try emailing random developers and eventually maybe one of them will have mercy on you.
In Firefox and I think Chromium, you can file a bug, attach your patch, request review from someone (the UI will help you choose a suitable person), and it's their job to respond.
Harder to understand and contribute is a bad, but unless there is a proposal for a similarly flexible system that has minimal downsides and massive advantages, the preference of existing maintainers should dominate over potential future contributors. Especially factoring in how expensive of a migration it would be.
Then I talk to the old timers and they act like I just need to get used to it.
And why not?
My impression of a few glancing online interactions is that they're both abrasive but marcan is quite unwise in a way that Linus has had beaten out of him
And he's not just abrasive He's a troublemaker. Seriously, code of conduct violation? It was perfectly clear what Hellwig meant by "cancer".
There is an argument that being hyperbolic, dismissive, and maybe a bit rude isn't as bad as some people make it out to be, and that it is a fine way to hash out disagreements and arrive at the best solution - that it is simply a result of the passion of exceptional engineers. There has historically been much of it in kernel development. But it seems that as the background and culture of kernel maintainers has broadened, that a more measured and positive approach to communication is more constructive.
It doesn't seem like marcan exemplifies this very well either. It is a loss for someone so skilled to abandon collaboration on the kernel, and seems like the unfortunate result of someone being dismissive and rude, and someone else taking that harder than is warranted or healthy.
No, it is not perfectly clear.
The generous interpretation is that they meant it is "viral", spreading through dependencies across the codebase (which I don't think is technically accurate as long as CONFIG_RUST=n exists).
The less generous way to interpret it is "harmful". The later messages in the thread suggests that this is more likely.
But I'm left guessing here, and I'm willing to give some some benefit of doubt here.
That said, the response to this comment was incredibly bad as well.
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
(not taking either side, just interesting to read the reply)
> You think you know better. But the current process works.
Regardless of how badly broken the kernel development process is, Linus and others observe that Linux continues to dominate and conclude that therefore the development process "works". Success in the market blinds the successful vendor to their defects. Sound familiar?
If Linux carries on down this path then eventually something else that has been subject to more evolutionary pressure will displace Linux, and we'll all be telling stories about how Linux got complacent and how it was obvious to everyone they were heading for a fall.
And honestly, with maintainers like Hellwig maybe that's what needs to happen.
Linus was right to reprimand him for the suggestion.
"Thinking of literally starting a Linux maintainer hall of shame. Not for public consumption, but to help new kernel contributors know what to expect.
Every experienced kernel submitter has this in their head, maybe it should be finally written down."
https://web.archive.org/web/20250204162031/https://social.tr...
However it seem that you need to disable js as soon as the content load or it will be overwritten by a 404
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".
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.
I'm no where near in the loop on this, but that sounds incredibly toxic. Are there some good links to summarize this?
EDIT:
OK, these are fully enough to allow me to understand the issue.
Marcan: https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
Linus: https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
I must say, I think I'm on Linus' side on this one.
EDIT2:
I was a $$ supporter of Marcan for over a year on github. I was predisposed to believe him, I'd say.
I've had to remove Hector's postings from my feeds because he just constantly bitches and complains about pretty much everything. He's capable, smart, and is doing more than anybody ever will for Apple hardware. But he desperately needs to Stop Posting. Without anybody he works with regularly to give him a reality check, I don't think he's going to change course.
I think Hector has some valid complaints about the contribution process to the kernel, I know. It fucking sucks ass and I've given up on trying. But screaming the way he does is counter productive to improving it
Some Kernel maintainers are absolutely against Rust anywhere in the kernel tree [0]:
> The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.
This is from Christoph Hellwig, the DMA maintainer. And is in fact what started the thread that led to Hector Martin quitting Linux. You can see other comments by Hellwig in that thread as well, he is extremely explicit - any Rust anywhere in the kernel is a big problem, and even if he can't stop it everywhere, he will do what he can to make it harder to use Rust by blocking it from the pieces he maintains.
[0] https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...
This drama included the dma maintainer saying he is categorically opposed to any Rust in any part of the kernel.
The sooner politicians are outright banned from using it for anything connected to their office the better.
Dude, this was literally caused by a stubborn maintainer, Hellwig, saying he wants NO second language in the kernel at all, and his explicit vow to do anything he can to stop it.
I totally disagree that the other contributor is "a bit" abrasive though.
It's like a religious war. Brings the worst out of otherwise smart and not asshole people.
Dead Comment
Dead Comment
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.
The more I hear about "community" the more I roll my eyes
It can be great at doing the work but it is awful at setting direction, evolving with the times and focusing on what's important
Going by another story on the front page, I have my long list of criticism about systemd but the "get things done" attitude needed to be commended
I wear garlic every day and have yet to be attacked by a vampire; clearly this is due to the garlic!
Tang/ballpoint pens/velcro never would have been invented if it weren't for the Apollo program.
etc.
I guess you are safe to say this now. But from 2014 to 2024, open source is not about code licensing but about the Community.
Naah, I don't think that's the only thing that did it. It was that, and the fact that people dared rely on it -- dared trust it to stick around, and to stay a single thing in stead of splintering up. And the thing that made it Open Source that stays Open Source -- that made it, in fact, Free Software -- is the license.
The two things that made Linux successful as a project are Linus' strong leadership and the GPL.
Just look at BSD: It had the backing of a whole darn university near Silicon Valley, not a single student somewhere North of The Wall. It had a head start by several years. And it had name recognition far beyond its home country[1]. And look where it is now: There are (at least?) three of them, and even together they're a marginal phenomenon among operating systems. I think that's because of the too-permissive BSD license.
___
[1]: The first I heard of "Open Systems" was well before I got into working with computers for a living, as a student at another university in the Frozen North in the late 1980s. My fiend and neighbour, a computer student, raved about how cool Unix was: "And you can even get it for free! It's called BSD!"
Deleted Comment
Dead Comment
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.
Video isn't out yet, hopefully soon.
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.
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.
so it is not about technical merits, but just some language religious thing? nice.
You're reading way too far into this. Linus has been publicly positive about the R4L project plenty of times.
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
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?
Arguably, I've used it only once to contribute a kernel bugfix, and I was lucky enough that my patch got accepted as is. So I found the process pretty straightforward.
But even with iterations and revisions factored in, kernel work itself feels orders of magnitude more complex and cumbersome to me than a patch process based on a mailing list could ever be?
> Maybe 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 Comment
- 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...
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.
Eh, that White House link is dead right now and I would not be shocked if whole department is purged soon, so who knows anymore…
Also, letting rust in doesn't seem to stop the personal attacks, case in point
I don't see it that way. Linus is conscious of not becoming a bottleneck on every topic; he doesn't want to baby-sit overly grown adults. I read most of the relevant LKML thread[1]. Martin did the unwise thing of escalating it on social media:
"If shaming on social media does not work, then tell me what does, because I'm out of ideas."
That is not the way to build bridges and relationships in a community! No matter how frustrated you are. He reaped the whirlwind for taking that destructive approach.
Also, Christoph Hellwig, as an established maintainer, totally missed the mark by using the highly-flammable word, "cancer", to describe Rust. It scorched the LKML and the internet. He should have showed more restraint and wisdom.
[1] https://lore.kernel.org/rust-for-linux/Z6YPfsDSNdRUskvp@phen...
And his viewpoint at the time seemed fairly agnostic - he enjoyed the passion on both sides but said nothing about what his thoughts were. This leads me to believe that he hasn't spent the time to think about the important issues on either side and make a decision (the failure of leadership mentioned in the parent comment).
Personally, I'm surprised Linus hasn't gone 100% in on Rust as he is normally very forward-thinking, so perhaps that has added to the frustration from so many kernel developers like Hector.
If 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
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".
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.
C was better than assembly. C++ was better than C for GUI applications. JAVA has garbage collection and usually won't force you to fix your machine after a bad crash. Python is better than Perl for quick and dirty stuff. PHP lets you build a web service without much pain. C# is a better Java that also gives you better integration with Windows. Go does a good job with small quick running services. Lua is easy to integrate into programs.
I look at existing C codebases. They're usually well worn and work okay.
C++ codebases would probably be better rewritten in Go or C#
Go codebases? Switching to Rust so you can what exactly?
PHP? Keep using it or us Go.
I also feel like Go, C#, and Python are designed to be fairly easy for a noob to come up to speed. Where Rust is the opposite.
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.
Deleted Comment
His reprimand is a clear signal that he won't tolerate brigading. Marcan was making a pretty blatant attempt at using social pressure to influence decisions.
Oh and I got this quote for you:
> Linus Torvalds admonished the group that he did not want to talk about every subsystem supporting Rust at this time; getting support into some of them is sufficient for now. When Airlie asked what would happen when some subsystem blocks progress, Torvalds answered "that's my job".
Source: https://lwn.net/Articles/991062/
Do your job then, Linus!
No, never! That's actually one reason I don't use Mastodon, it's extremely common. Isn't this the guy that blocked HackerNews links to the Asahi Linux homepage because the moderators wouldn't do his bidding?
Granted there are acceptable methods within that, and not acceptable.
Edit: For further context for Linus's reply, there's http://web.archive.org/web/20250206022420/https://social.tre...
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.
This is the entire point. This has been DONE. First its "lets see if you can build a good driver", now its "ew rust". The maintainer of the DMA subsystem is showing how they're actively trying to make sure Rust doesn't make it in. .
It's a failure of leadership to not intervene when discord threatens the group. He should weigh in, or make sure that someone else who has mutual trust weighs in.
In youth sports, something similar happens when referees fail to call fouls on rough play. Players naturally test the limits and then others recognize the lack of protection and retaliate until it gets really out of hand.
Deleted Comment
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.
He probably didn't want to end up like Stallman.
People change. As you get older, you might find you no longer care that much about subjects you previously had very strong opinions about
https://github.com/subsurface/subsurface/commit/1b16d570a1b6...
For example: https://gist.github.com/rayvoelker/c5f480f46c80a7a3c22386b29...
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.
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.
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.
> 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
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.
Dead Comment
It was a fine position to take back when introduction of Rust into the kernel was still very much a discussion point. However, the discussion is over, Rust has been accepted into the kernel. This entire struggle has been kernel developers sabotaging other kernel developers.
This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything.
That said, using social media to cause drama when a Linux maintainer is being an ass is just as stupid, if not worse. Both sides of the conflict are in the wrong here.
It's not. Certainly not until Linus says it is.
> Rust has been accepted into the kernel.
As a limited experiment. This kind of drama may be an indication that the experiment has failed and should be rolled back.
Well, this is your take, as you explicitly wrote "I walk away with the feeling". My take is: The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things. If too many people aren't happy with the way the linux kernel is developed, they are free to fork it and develop in the way that they see fit.
Luckily, the kernel seems to be doing fine.
After that, Greg KH stepped in (since he was soft asked to help earlier in the thread with an @) to reconfirm that what seems to be the general policy for r4l is followed (aka it'll be a separate file with its own maintainer), with the subtle implication that it would probably just get merged as a separate patch to Linus directly, the complaints of the maintainer be damned.
Marcan's sudden outburst and forcibly adding Linus and Greg to the thread he was responding to came afterwards. You can even see some other rust4linux devs asking him to please not do this, since the situation is under control.
Does it do much of anything to solve the fact they've publicly declared that they are going to do everything they can to stop the project, and that there's a history of them doing just that going on for years now?
Marcan's response clearly wasn't the most productive way to raise these issues, but the issues are there and are not being addressed.
About the Rust code itself; the primary issue was code duplication rather than preventing the use of Rust altogether. Since the suggested code is not merged, every driver needs to write the same code over and over again. That was also something that the maintainer suggested himself (?). There is of course a big downside, but I am not sure if this justifies all the hate.
The Rust code is not in the area he was currently maintaining. Christoph didn't even look at the patches before objecting to them. Once it was pointed out that they were not in his area, he rejected them anyway.
Note that, because they are not in his area, he does not actually have the authority to do this. He was CC'd in an advisory sense, it's not really his call to accept them or not, and as a longtime kernel maintainer he surely knows this.
That doesn't sound like he's only talking about in his area to me
Deleted Comment
Linux is free software and there's really nobody stopping people from forking it and doing things the way they want. It used to happen all the time once upon a time, nowadays people seems to be afraid of doing it.
I wouldn‘t expect a grand Rust announcement anytime soon, above what has already been said. Rust in the kernel seems to be fine, but it will have to adapt to longstanding kernel processes. And if it means there won‘t be Rust in some maintainers‘ subsystems, so be it. The kernel won‘t be 100% Rust next year anyway.
Dead Comment
> Simona Vetter: (addressing Hector) ...Now I'm left with the unlikely explanation that you just like thundering in as the cavalry, fashionably late, maximally destructive, because it entertains the masses on fedi or reddit or wherever. I have no idea what you're trying to achieve here, I really don't get it, but I am for sure fed up dealing with the fallout.
> Dave Airlie: To back up Sima here, we don't need grandstanding, brigading, playing to the crowd, streamer drama creation or any of that in discussions around this. The r4l team and drm maintainer team have this sort of thing in hand, it's not like we don't understand the community of the Linux kernel, and having this first reaction to blow shit up and dramatise it just isn't helpful.
(Obviously I am taking things a bit out of context here, I recommend giving this thread a read.)
Seems to be pretty level-headed, on point, and damning. So yeah, I don't know if I am on marcan's side this time.
https://lore.kernel.org/rust-for-linux/2b9b75d1-eb8e-494a-b0...
Quoting
> Being toxic on the right side of an argument is still toxic, [...]
unironically, immediately after saying @marcan
> and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off
...is quite tonedeaf at the very least. Especially given what Marcan said about dealing with this not being his paid job.
Nobody comes off looking good here.
Dead Comment
No doubt that is a flawed summary so feel free to correct
Hector wasn't the developer of this patch. However, he is a user of it. He has had some rough interactions over the last few years. And so seeing this happen (even though it's happening to someone else) is a "the straw that breaks the camel's back" kind of deal.
Marcan is probably a little acutely upset not just because he was told off, but also because Linus hasn't waded into the actual issue at hand (which he needs to, not even Greg K-h can answer it). But that issue is less urgent and it's probably reasonable for Linus to:
a) Mull it over before making a rash decision b) let tempers calm.
I would guess Linus will wait til Monday and is probably also having some off-list chats anyway.
The statement that they were going to maintain this without the support of the DMA maintainer was made 22 days ago [1]. That statement was rejected 11 days ago [2]. Linus was explicitly asked to intervene 10 days ago [3]. (Too complete the timeline Hector Martin first got involved 4 days ago, Linus intervened about that yesterday).
I don't know why you think Linus will suddenly choose to address this Monday.
[1] https://lore.kernel.org/rust-for-linux/Z4kG5AcVeQKegLnb@poll...
[2] https://lore.kernel.org/rust-for-linux/20250128092334.GA2854...
[3] https://lore.kernel.org/rust-for-linux/Z5qeoqRZKjiR1YAD@poll...
https://lore.kernel.org/rust-for-linux/20250110083955.GA5395...
https://lore.kernel.org/rust-for-linux/20250128092334.GA2854...
https://lore.kernel.org/rust-for-linux/Z5qeoqRZKjiR1YAD@poll...
https://lore.kernel.org/rust-for-linux/20250204052916.GA2874...
https://lore.kernel.org/rust-for-linux/20250131135421.GO5556...
Note: I did not intend to particularly link to Christoph Hellwig comments, it just so happens that these contain enough quoting form previous answers to trace out something coherent.
For the complete context, you should walk up/down (and laterally) the thread to get more details and make your own opinion of it. It doesn't take very long.
Deleted Comment
I read it as “look at this shit” and general frustration with the likes of DMA-guys behaviour.
I'm not disagreeing as I don't know what exact things you're talking about, but I find "virtue signalling" and "communication" to be very similar terms these days. From statement to statement I'm not sure what anyone means by that phrase anymore.
Dead Comment
It's easier to name the major Linux FOSS projects that DON'T have drama and virtue signaling than the ones with.
If you read the Github comments on System-D, GNOME, etc, it's like watching children bickering on Sega VS Nintendo.
Turns out FOSS devs are humas just like everybody else and suffer from the same flaws.
Hell no. FOSS communities, as other spaces created by permanently online individuals, definitely have higher-than-average number of mentally unhinged snowflakes.
It is rather anticlimactic. I had always imagined FOSS to be this free exchange of ideas, thoughtful consideration, and intentional action. Seeing what it has become though… Maybe closed source is better.
Dead Comment
Aren't these diametrically opposed? Virtue signaling is loudly claiming to have some virtue in the absence of that virtue. Hector has receipts, in the form of commits, as proof.
Virtue signaling would be me appearing on the mailing list and spouting my beliefs.