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.
This is a fundamental misunderstanding of the structure of the linux kernel, the nature of kernels in general, and the ways one performs automated verification of computer code.
Automated verification (including as done by rust in it's compiler) does not involve anything popularly known as AI, and automated verification as it exists today is more complete for rust than for any other system (because no other widely used language today places the information needed for verification into the language itself, which results rust code being widely analyzable for safety).
Human validation is insufficient and error prone, which is why automated verification of code is something developers have been seeking and working on for a long time (before rust, even).
Having "explicit" (manual?) memory management is not a benefit to enabling verification either by humans or by machines. Neither is using a low level language which does not specify enough detail in the type system to perform verification.
Kernel modules aren't that special. One can put a _lot_ of code in them, that can do effectively anything (other than early boot bits, because they aren't loaded yet). Kernel modules exist for distribution reasons, and do not define any strict boundary.
If we're talking about out-of-tree kernel modules, those are not something the tend to exist for a long time. The only real examples today of long lived out-of-tree modules are zfs (filesystem) and nvidia (gpu driver). These only exist out-of-tree because of licensing and secrecy. This is because getting code in-tree generally helps keep code up to date with less effort from everyone involved: the people already making in-tree changes can see how certain APIs are being used and if those in-tree folks are more familiar with the API they can/may improve the now-merged code. And the formerly out-of-tree folks don't have to run their own release process, don't have to deal with constant compatibility issues as kernel APIs change, etc.
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.
I didn't downvote you, but I think you have a misunderstanding of a couple of things that are clouding your judgement: (1) the sheer size & inertia of the Linux kernel; there are tens of millions of lines of code, and even thinking about integrating another language will take time- lots of it; and (2) the distributed nature of its development and the diversity of its engineers; the community is not one that can be brought into an auditorium and made to change direction on a dime. Rust may have been around for 10 years, but no one was going to go all in on day one.
Further, this attitude of "Rust is clearly superior, so what's the holdup" is itself a holdup. You can't expect people to just spend their time learning a new language just because it's there, especially professionals with personal lives. These people do serious work, on a codebase that millions of people around the world, including virtually every tech company, relies on in some fashion. That's not a game. It's "serious business."
Serious business doesn't just chase something because it's new and hot and solves a certain class of problems (while simultaneously introducing its own set of problems).
Nothing is a panacea (yet, I suppose). This ship has been sailing for 30+ years. So many millions of man-hours have been put into it that people are justifiably cautious.
Now, all of that being said, I read the DMA maintainer's comments a few days ago and I thought he was being unreasonable, however, he is correct about the external dependency on his code. Even if the Rust DMA wrapper is kept completely separate, under a separate tree, he would still have to contend with the fact that any changes he makes might influence that wrapper and all the code that depends on it. So now, even if they claim to maintain the wrapper 100%, he is still beholden to all those downstream developers that rely on the Rust DMA wrapper's functionality, because if he breaks their code, he knows it'll cause a shitstorm. It's easy to say you'll maintain something 100% and the upstream guy doesn't have to worry, but time passes, things change, and all of a sudden, his hands get tied because it'll impact too many people. That's just reality.
Truth be told, I would eventually suspect some (or maybe many) Rust developers will migrate to a new project, because the rate of change is not going to be fast enough to ever satisfy them. And that's understandable. People want to make an impact, especially when contributing to an open source project (and doubly so on an unpaid basis).
Unfortunately I don't think Redox is the answer. UNIX and its clones/derivatives have had a long run, but anyone who wants to create the next big thing is not going to want just another clone of UNIX, even if it is in Rust.
We have seen the enemy. We understand the threat models and know far more about virtualization, containerization, sandboxing, etc., just by virtue of having had to dogfood these technologies for the last 25 years.
The next big thing (if there is one), will likely be something more like a cross between the Windows world (where ACLs rule the roost, and centralized management is built-in), UNIX with its CLI focus, process composition & command familiarity, and something like L4 which has unforgeable capabilities built in and a formally verified kernel.
Or we'll just go back to a modern day version of the UNIX wars, lol. Something, something about history rhyming.
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.
How is this not the top comment? I was scratching my head wondering until I found your links.
So the smackdown from Linus is what motivated it. Honestly though if you read the email Linus is replying to, it was deserved. To be fair, Hector Martin may be one of the smartest hackers alive today. His fame goes way back to hacking the Playstation 3 with geohot and Hector has even found security vulnerabilities in Apple Silicon. He's done great work with Asahi Linux by weaponizing his keen penetrating mind to support open source freedom. But like his buddy geohot he can be a bit childish. Right now Hector seems to be laying low. His social media accounts are no longer accessible. It seems even archive.org and archive.today have no recollection of him. That's impressive.
So what triggered him to act out of character? It seems like he wrote his Apple GPU driver in Rust and he needed Rust DMA support in the kernel. I know, a curious thing for a Rust developer to want more power to do things that are memory unsafe. So the DMA maintainer Christoph Hellwig hates Rust. He thinks Rust is a cancer in the kernel. Cristoph refused to help Martin create Rust APIs for DMA. That's why he went ballistic.
Chances are they'll all make up when this blows over, or someone will just rewrite his GPU driver in C. There's not going to be as big of a push for Rust with this recent government. For example, the White House recently took down its paper about the future of programming being memory safe. The money for Rust is going to dry up. It's becoming socially acceptable to push back against efforts to convert everyone to Rust.
> Cristoph refused to help Martin create Rust APIs for DMA. That's why he went ballistic.
No, he tried to prevent other people from doing the work to create Rust APIs, and said that he would do everything in his power to prevent anyone from doing it.
He also got his treehouse.systems Mastodon account "suspended by a moderator". Not sure if the treehouse people have said anything more specfic, but I am entirely unsurprised given how he behaved on there.
It's a quite clear case of "what you accuse others of is what you yourself resort to". He was calling out others for unreasonableness, flaming and sabotage — and did exactly that himself.
It doesn't say anything about moderator action for me.
He closed the account himself:
> I actually wasn't sure if I wanted to delete my Mastodon entirely or not, but as I intended to fill in my password for confirmation and decide whether to click the button, my password manager auto-submitted the form for me. Call it fate, I guess. I mostly don't regret it. Maybe I'll be back some day, maybe not.
It is gone now and gives a generic "nothing here"; I have no idea whether the "suspended by moderator" display was some kind of bug, transient state, or whether he's just lying, or both things are true and he just deleted his account after it was suspended.
(Well, his Reddit post doesn't claim his Mastodon account didn't get suspended, so it'd "only" be the omission kind of lie…)
FWIW, I don't understand the logic of deleting the Mastodon account but continuing to post on Reddit… those are both "social media" in my mind…
> Apple/ARM platform development will continue downstream. If I feel like
sending some patches upstream in the future myself for whatever subtree
I may, or I may not.
I suppose it's possible that that could turn out well.
The situation with Apple hardware feels a bit like the early days of Linux (including the fast pace of development). There was a time when if you wanted broad hardware support it was better to run an Alan Cox kernel than a Linus kernel. And the whole point of git was to have a system that didn't require one central blessed tree.
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.
My impression, while still struggling to follow the message flow:
I think social media and shaming are harmful and understand the reaction of Torvalds. The position of the DMA maintainer seems also to make sense for me, to keep code maintainable over decades it must remain in a nice and tidy state. That is the hard work.
>Maintainer of DMA wants to keep the code clean and not mixing languages[1]. And tries to avoid dangerous offers like "we will maintain it for you".[2]
The Rust bindings are not in his tree. They do not touch his code. They are effectively no different than any other subsystem or driver which uses DMA. If he tried to veto some random driver that needed DMA from using DMA for no reason other than because he didn't want to have to deal with it if he changed the API in the future, that maintainer would be told to F-off because that's not his call.
Christoph is throwing NACKs around that he doesn't actually have the authority to NACK.
> The position of the DMA maintainer seems also to make sense for me, to keep code maintainable over decades it must remain in a nice and tidy state.
Perhaps so, but that discussion was two or three years ago. Stalling other contributors' work now is counterproductive, especially for changes that do not touch files maintained by them.
This does not justify any brigading behavior, though.
Is that a typo or he indeed intended to escape that 'k'?
(Sorry, I know this doesn't add to the drama or what's going on there, which really doesn't interest me one way or the other, but this tiny bit had me curious)
I don't have anything to add regarding the Hector v. Linus debate, who was in the wrong, who was in the right, who's to blame etc...
All I want to know is what's the long term viability of Asahi Linux or Linux for that matter on M series chip'd Macs? What's the burden going to be for Fedora Asahi if the work remains out of tree? Has Redhat/IBM stated they'll support it via the Fedora project going forward? What if they pull support?
I think right now Marcan can work magic and reverse these chips and other pieces. Long term it's an arms race and Apple has other motivations to lock the platform down further. They may even get told to make it compatible, but they seem to be willing to maliciously comply with those directives.
I am reminded of the Beeper messenger stuff. Like it's cool when people hack these things together to do stuff, but the community as a whole has seen this episode before. We probably shouldn't be making any choices or compromises to make Apple stuff work, because they are adversarial.
Wow, this thread is wild. It’s like everyone’s losing their minds over mixing Rust into our old, battle-tested C kernel. Sure, Rust promises a ton of safety benefits and could really help keep nasty bugs at bay, but some folks are super worried that every time a C API changes, the Rust side will break—and then someone’s stuck fixing it. It’s as if everyone’s saying, “We’re cool with experimenting, but don’t force us into a multi-language mess we didn’t sign up for.”
What really gets me is the whole leadership vibe. If Linus had just clearly said, “Alright, Rust is in, but only in these specific parts and under these conditions,” a lot of this back-and-forth and social media shouting would’ve been avoided. Instead, we’ve got a bunch of maintainers arguing about process and even threatening to use social media to shame people, which just adds more fuel to the fire.
At the end of the day, it’s not as simple as “Rust or no Rust.” Some parts of the kernel might really benefit from Rust’s safety, while other parts might be fine sticking to C. The real challenge is figuring out how to integrate Rust without turning everything into a maintenance nightmare. We’re all aiming for a better, more robust kernel here, but if we keep getting bogged down in personal drama and endless debates about process, nobody wins. Maybe it’s time to take a deep breath, set some clear rules, and move on instead of letting all this online drama derail progress.
Linus vs. Rustaceans: the get off my lawn sequel nobody asked for. Kernel devs now double as drama critics, social media is the new mailing list flamewar arena, and somewhere a C pointer quietly segfaults out of spite. Will rust ever "make install"? Stay tuned! To find out in the next episode of Keeping Up with the Rustaceans
Marcan is still posting to the LKML as himself too and he said he might contribute patches in the future if he feels like it. What he did, and this entire thread is about, is he resigned as a maintainer:
> I am supported
exclusively by donations, which incidentally, have been steadily
decreasing since the start of the Asahi Linux project. The project has
zero corporate sponsorship.
People’s donations to Asahi Linux have decreased, according to Hector from this thread [0]
He basically said goodbye like 4 times and continued to make long ass rants that lead to nothing. Is this what you want to spend your time on? I already feel gross that I went through all these threads. I can't imagine how you would feel having written all these paragraphs of slop.
You know, Redox (as the "most serious" Rust kernel I can think of) could probably do with non-trivial drivers. It would be unfortunate for aspiring or even seasoned kernel developers to step away from the practice entirely, simply because R4L fails to launch.
Part of me feels like something like Redox isn't exactly worthit. Now I hope the project succeeds in whatever goals they have, and honestly where they've gotten to is impressive; what I mean to say is that I think it would be far more interesting to imagine beyond just Unix and especially the problems of POSIX. I think the "next" thing, if that even ever materializes needs to be that, something reimagined. Computers aren't emulated PDP-11's anymore.
If the upstream maintainers don’t want to adopt it, the Rust folks can gradually rewrite the bits they want to and let the market decide. Use the Ballmer “embrace, extend, extinguish” model.
Linux is not a side project. It has thousands of developers being paid by chip and hardware manufacturers to ensure that linux works on their products.
With the complexity of systems engineering, for a single driver, it takes months to build one from scratch. Plus, there is not enough expertise within the rust community to take on a project like the linux kernel to match the rate of development by many large corporations with hobbyists.
They may not match the rate of upstream development, but doing their own thing is going to be a faster path to their goal of Rust in the kernel than trying to convince everyone else to do something that they don’t seem to want.
Because forking requires a lot of hard work and time to even get acknowledged, while bringing Rust into the kernel, given enough PR, establishes a whole new hierarchy in which not only do they get to be at the top of right away, but they also get to depose the old guard!
> ABSOLUTELY NO C++ in the kernel EVER. But Rust is totally fine.
stance? It seems pretty absurd when you consider the closer similarity between C and C++ (and the more straight-forward migration path from C to C++), and the fact that GCC supports C++ (even recent vintages) natively on many more architectures.
The rust folks should make a Linux compatible kernel and distros that include a stripped down Linux kernel as a compatibility layer for legacy software.
There was actually a proposal to do what he's suggesting in redox at some point, some sort of emulator layer to run linux to take advantage of linux drivers. I haven't followed up to see what's happening with it.
It is a quandry, the kernel is predominantly C, Rust has demonstrated a path forward, producing safer code without sacrificing performance, but it is undeniable that a mixed code base is far harder to maintain, not impossible.
Here's the thing, in the next couple of years languages like Carbon, Zig, even Jai, will come of age. They will have their proponents and people who want to introduce them into kernel code.
If there is a rust developer out there who doesn't resist the introduction of these languages as ardently as the chosen people (C) are resisting rust, then I will show you someone who lives in some kind of alternate reality.
Personally, I'd be pressuring the C committee to introduce defer, tout suite, otherwise Zig looks favourite. But the reality is that your preferred language is just that, your preferred language, most have seen this drama before and will choose not to participate.
As to whether Linus is failing in his leadership role? Nah, Then again, I wish Sony would open source the PS OS and we can be done with this juvenile debate as to which OS should rule the world. Either that or let's have an exokernal and move on from this monololithic story, surely that would meet the needs of the MY FAVOURITE LANGUAGE isn't appreciated crowd!!
There will be a similar drama when Zig reaches 1.0. There will be a bunch of Ziggers trying to get it into the kernal. The Rust fad is already slowing down. Maybe it's a good idea to wait 10-15 years before trying to rewrite the universe in a "memory safe" language and pushing that upstream.
Zig brings developer velocity benefits over C, but developer velocity is not the reason R4L exists. Until Zig has an easily segmented part that is memory safe, there is no demand for its potential benefits in Linux. Memory safety is the only reason a new language was considered within Linux.
Zig fixes many of my woes with C. Compilation time is better than Rust’s, and there’s no borrow checker. I also find the Zig community more pleasant than Rust’s.
The Rust ecosystem never clicked for me the way Go or Zig did. But I work with I/O-heavy distributed systems, where Go outshines Rust in most cases, so that’s what I use the most.
Systems programming is a different beast, though, and I’m glad the push for rewriting everything in Rust has lost its initial momentum while Zig is emerging as a strong contender. Even then, I wouldn’t want Ziggers to start pushing things upstream into the kernel anytime soon.
Maybe, I think it's more likely that a Zig soft fork would first replace the kernel build system and then, with unit tests, piece by piece port the whole beautiful thing. Zig is on a strong path to compile and interact with C better than existing C compilers.
I like Zig a lot over Rust but I guess people should give it a while (10y) before attempting something like that. Zig isn’t even 1.0 yet and it’s not going to be for at least 2 more years.
I understand the frustration, but I don't understand the drama.
There are other big Linux forks that met a similar resistance, best example is probably Realtime Linux / RTLinux that was not welcome in the Kernel for what, 15 years? Yet they still continued in their own fork and now most of their patches have finally gone in.
The way they're going to work now should have been the default. Just as RTLinux was a big change to the Linux kernel, Rust will be a big change. You cannot expect the Kernel community to welcome such a huge change with open arms and deal with all the fallout (build system, interfaces, etc.)
Just be ready for your project to take a decade, instead of trying to force it in "now or never". Until then, maintain some out-of-tree modules written in rust that every Linux distro/user can try and test without much fuss. For example, I don't think it will be a huge problem if Mac users have to get their DRM driver at some other repo (or if distributions would have to package some `linux-module-drm-apple` package separately from the Kernel)
Rust or not, mixing two different languages within a single project is a sure fire way for a maintenance nightmare. Specially for a large project like Linux. I sincerely don’t want something like that happening to the Linux kernel. Just let it die with C. However it may seem improbable, writing a kernel from scratch is the way to go for new wanna be system programming languages.
Indeed. I grew up with open-source. I still like C very much. I do not think Linux would die. But I may be wrong and Rust is the future. In the past, people just created their own projects. If they were truly better, eventually the were adopted more and more, but who did not like it, could also just stay with the older projects as long as they were recently maintained.
Likewise most Rust efforts going on from Microsoft and Google are on downstream, Android, Sphere OS,...
This was to be expected, many of their anti-C++ complaints also apply to Rust, given that both languages share many common ideas, even if presented in different forms.
> This was to be expected, many of their anti-C++ complaints also apply to Rust, given that both languages share many common ideas, even if presented in different forms.
I was genuinely surprised when Linus opened the door for Rust in the Kernel for that reason. And the real waste is there: had Linux said a straight “no”, then nobody would have lost their time trying to make this work against all odds.
Or maybe Linus really thinks Rust is the future, but he doesn't want to enforce its inclusion in the Kernel against his senior maintainers because he's afraid of an uprising.
Linus said he's worried that he and core kernel maintainers are getting old, and there may not be enough younger contributors to replace them. There's an implication there that Rust will continue to grow and attract more talent, and it'll get harder and harder to find devs passionate about old C codebases.
It's cowardly and easy for me to say now after the fact, but I saw the original Mastodon post because I follow Hector Martin. I didn't think that it was going to make the situation any better but I didn't have the energy to even fire off a one-off comment saying so.
I absolutely get emotional about my work. I have absolutely sabotaged myself by not having the presence of mind to step back and take a deep breath. I had a moment of clarity reading Hector's post on Mastodon, and I'm sad that my suspicion that this was going to just make things worse was correct
I think it looks like both sides are making some pretty valid points here.
Those who are nervous about embracing Rust further are just fine. Rust is still a young language. It shows an awful lot of promise, but it isn't a magic cure for safety and security concerns, especially at the kernel level. It is entirely possible that Linux is a bad fit for the language, and the real way to get ta Rust kernel is for a team to come together and implement a kernel in Rust, from scratch, perhaps with POSIX compatibility.
On the flip side, Hector is entirely correct that the overall process of maintaining and improving Linux is incredibly baroque and grounded squarely in some tooling that just stinks in the modern ecosystem. It has worked for Linux for ages. It is also increasingly making working on Linux a specialized project space because nobody else manages projects like this. Hector is fine leaving if he finds that process two owners to be worth his volunteered time. And it is entirely possible that there will come a day when the value of the project itself is outweighed by the cost of interacting with the project and Linux will get supplanted in the common ecosystem by something else.
In short, Hector is probably making the right move here. If he wants to continue working on a problem like this, a new operating system might actually be the right solution.
Linux is one of the most complicated OS in the history of OS and both of them understand this in someway or the other, it's still not cracked enough market share to dominate the personal computer market even in 2025, but is already on millions of other devices except PCs and a small change in decision like r4l brings the whole perspective into matter, after the fact that rust is highly compute intensive language and low end processors might not be able to catchup the speed in the best possible way these industries work, memory is cheap to include and hence the decision to include Python was a comparatively easy one, but rust is a highly balanced choice currently which makes the decision more difficult for Linux to include R4L in kernel, hence the dissolution on parts in which to include.
This is based on my limited experience with rust, but I believe we really need to give rust more time to mature it enough to see where we're going with the builds to actually decide on this matter, even personally. Plus, Linux has been keeping the Linux Kernel project alive for so long that he probably already has got the experience of knowing the repercussions of a wrong decision. Being hasty in this scenario doesn't solve the problem
rust utilizes various methods at compile time which significantly increases compute, such as compiler is optimised for memory safety, which causes it do a lot of tasks and changes at compile time unlike C and inturn during execution to ensure ms, which could easily be avoided, it is good for overflow situations but in terms of compute required in exchange for the program is simply(currently) not at the level that would be great to have in Linux kernel, in a few years maybe
Exactly my point in terms of the chipsets, and the limited acceleration in capacity of evolution per year for small chip manufacturing companies unlike mediatek and qualcomm, furthered by silicon shortage and many other manufacturing facts, including a language like Rust at this stage should be subject to observation.
I have a question. Instead of fighting an uphill war in the Linux kernel community, why don't Rush developers just make a new kernel or fork their own? Sure it's going to take years, but at least they don't have to suffer the mental outrages from time to time and can do whatever they want? I mean I'd do it if that's what I want.
P.S I don't have skin and skill for the kernel game. I'm just a curious bystander.
Linux is a cooperation between numerous companies to develop a shared artifact that works with all of their hardware, solves all of their use cases, etc. No one company involved can just go make their own replacement, because they need the cooperation of the other companies involved to get it to work on the hardware manufactured by the other companies.
Even ignoring the driver problem, it's not really an economically viable amount of work. Right now everyone benefits from everyone else's bug fixes, from everyone else's security improvements (like introducing rust!), etc. Going it on your own means you have to redo everything everyone else has done (unless you just fork linux), and that you don't get the benefit of everyone else working on the shared codebase (I suppose unless you fork linux and keep merging in upstream... which is actually what projects like Android do).
A complete rewrite also means a huge time lag before you start seeing payback in terms of faster development speed and a more reliable/secure operating system. Unlike introducing rust in new work to the existing kernel which sees relatively immediate payback.
I suppose I wouldn't be too surprised to see a project like Android just maintaining a whole series of rust changes in their own branch if the RFL project continues to be impeded by the maintainers. That's what Asahi linux (Linux on apple computers) is already doing (and poking at the android-mainline branch it looks like there are some rust additions that aren't in Linus's tree... but I'm not sure what the extent is).
Also note that many of Rust 4 Linux contributors are Microsoft and Google employees that would like to upstream their changes, they already have plenty Rust on their own Linux derived systems.
Redox looks great. Device drivers should be in userspace, though I think that's far easier said than done with everything being on shared busses. A kernel cannot (safely) just simply check permissions for accessing a device and route the messages.
> I have a question. Instead of fighting an uphill war in the Linux kernel community, why don't Rush developers just make a new kernel or fork their own?
Because their primary goal is to widen the community and reach of Rust, with "preventing memory error class bugs in the kernel" a secondary objective.
After all, the Rust additions, if properly designed, can be maintained in an out-of-tree fork that tracks the main Linux repo. If they did that, there'd be no one to block their patches but themselves, and yet they don't do that.
Rust is more about community than Linux is. Within the Rust community they make it very clear that it is vital that everyone goes the same way, while the Linux community has had, for decades, people each doing what they or their employer are interested in.
These two communities are not going to mix well, TBH. A community in which every member is a vocal prosyletiser isn't going to mix well with a community which prides itself on "Show Me The Code".
> After all, the Rust additions, if properly designed, can be maintained in an out-of-tree fork that tracks the main Linux repo. If they did that, there'd be no one to block their patches but themselves, and yet they don't do that.
Mainlining whenever possible is highly incentivized by technical and organizational aspects of linux[1], nothing about rust changes that. Obviously R4L introduces complexity and tradeoffs but I don't see why a rust kernel dev whose only goal was preventing bugs would do anything differently in this regard. Linux is a consensus project and opting out of the process of building consensus would mean not actually preventing any bugs.
I don't quite get the fuzz. A subsystem's maintainer's job is to maintain. If he cannot guarantee the maintenance of something, it's his/her job to say no
You are free to either take over maintenance of the Subsystem or do a fork
But throwing a tamper tantrum on social media is definitely the wrong way forward
This isn’t impartial. Jonathan Corbet is naming and shaming, on behalf of one side.
> But Christoph Hellwig … turned this submission away with a message reading, in its entirety: "No rust code in kernel/dma, please" (despite the fact that the patch did not put any code in that directory)
> Already overworked kernel maintainers will have to find time to learn Rust well enough to manage it within their subsystems.
Frankly, this article feels like it’s steps away from social media brigading.
Journalists having an opinion in a news article, or even printing an opinion in an op-ed page, is not the same as—or even close to—social media brigading. It’s also a practice as old as the press itself. Brigading is about harassment and intimidation, not about possessing or publishing an opinion.
I came away with the opposite interpretation of yours.
The first quote of yours edited out the part where it says he does a lot of work in the DMA subsystem. It’s saying “someone who does a lot of work in the kernel turned the patch away”, which is absolutely true.
The second quote is understanding of the maintainers’ side, saying that they’re already overworked and now they’ll have to find time to learn rust on top of that. Not so much “I think these people ought to learn Rust”, but “accepting these patches means they will now have to learn rust”. This seems true to me? If anything it’s overly partial to the maintainer’s side, admitting that rust patches put more work on the old guard maintainers who are already overworked. It’s interesting that you feel this is too partial to the Rust side.
Zig will likely go through the same trials and tribulations that Rust has for introduction into the Linux kernel. Considering Zig's better C interopt, the fact that the Zig compiler can natively compile C, the Zig community's lack of zealotry and proselytizing that plagues the Rust community, etc., I believe it will be better received.
Damn, I liked watching the YT streams, above my head but yeah
Edit: I'm not super invested in the topic at hand I use all 3 OS's and only use Mac to develop with/for using MacOS
But kernel-level dev is hardcore and especially for open source, I've experienced that with the Pine64 devices which are almost worthless without the devs contributing to its software
Such a huge discussion and I can’t really understand the problem from reading the comments or some of the excerpts linked. Can anyone explain to me what is the real issue here?
Developer A wants to make a change. Developer B rejects it. Developer A makes a big fuss about it on social media. The creator of the project steps in and chastises Developer A for his behavior.
And as additional context, developer A has a history of causing drama on social media. So much that he even has his own page on KiwiFarms.
Also, developer B publicly stated that he will do everything he can to prevent changes written in language 2 from getting merged regardless of technical merit.
silly hector, everyone knows that bullying, screaming at people in public and insulting them online is a privilege of long-term maintainers who can do no wrong
Linus has to have one of the most stressful and difficult jobs available.¹
The Linux kernel is part of so many different things, projects, products, companies, etc. A change can really duck things up.
Being conservative, and slow, in adopting new things is good for the main line.
You have idealistic developers who have seen a way to do something better,
that is great. I know the feeling.
I have never done anything with the Linux kernel, but I have worked on some
large legacy codebases. and it is to come in, look around, and just go
"Gosh, this here is just slow, I'll just fix this".
and it will be a good solution right there, but it might be suboptimal overall.
Chances are really good that you dont understand the entire picture when you
"fix something", and someone who does, may not like the change.
and even if the technical solution is clearly better from one angle.
I am glad I will never be involved in blessing or passing on 1.000.000 different
changes being proposed as improvements to Linux every week.
I haven’t read the entire thread but based on the except I did, while I won’t claim that Hector isn’t entirely in the right there’s also major longstanding issues with the process that the kernel devs seem to refuse to do anything about.
It seems like big enough of a sticking point that if a forked alternative with a less insular contribution model appeared, it could gain enough steam to keep itself afloat. All it’d take is for someone with deep enough pockets to fund a few founding engineers to be the subject of this kind of frustration.
Absolutely! If Rust and the modern development practices are truly so much better (I doubt this, but I am old and could be wrong), then why not show this by creating better kernels and other projects!
Exactly. And I feel the same as you do: the Rust community can put it’s money where it’s mouth is and if nobody wants safe Linux or they can’t make it happen, then fine they can be happy to lose.
Can't be many years until we can take the first ever version of Linux kernel, ask an LLM to port it to Rust, spin it up in QEMU and re-prompt until it works, then feed in every patch set and ask the LLM to add these changes to the Rust version, ... repeat for 30 years of patches until the full kernel is rewritten in Rust.
because that's what the world needs, an obscure half assed implementation of unix? why not innovate and come up with a new paradigm instead. No one is asking for this.
in my mind Swift is a much better language to include than rust, unfortunately the support for Swift on Linux is so bad currently that it's not worth exploring.
If ever integrated Swift might change the whole paradigm
“How did you hurt yourself today?” - “I threatened Linux devs with social media shaming and publicly quit contributing to Linux to teach them a lesson. But it boomeranged, and now everyone is talking about my behavior”
Not wanting 2 languages is ridiculous. Only one of them is actually safe. Whatever Linus thinks, empowering someone to say “no” to “two languages” is pretty idiotic; if someone did that to me, I wouldn’t go to social media to bitch about it, but I can sure as heck sympathize with the sentiment.
Whoever owns DMA or whatever and rejected rust out of hand like this should frankly be _forced_ to resign. This is truly arrogant and egotistical behavior, almost certainly contingent upon FUD and insecurity and laziness about not just learning Rust.
Good grief, last time I feel excited about submitting a kernel patch; what a ridiculous situation.
It's hard enough to get a single programming language to work right. C is old and stable.
Rust is new and mostly stable, mostly stable isn't going to cut it when billions upon billions of devices depend on your work.
At the same time this type of ego driven drama keeps me out of the open source community. I have enough people telling me how to code during my 9-5.
I open source most of my projects, but it's not a collaboration. I'll even admit, I get really annoyed when someone puts in a PR that's literally just a bunch of spacing changes in a readme. I think there was some influencer who was claiming that you should go through GitHub, and submit as many changes for things like grammar as possible to a bunch of different projects .
And then on your resume you can put that you contribute it to all these projects. Not fun.
I don't agree with this anymore tbh. But for a project as large, mature, and widely worked on as the Linux Kernel, I absolutely agree.
I think it's a noble goal worth working towards, but Marcan's smug as hell "ill merge and y'all will fix all your broken shit" attitude predictably backfired
Consider using Codeberg for personal projects and reserve GitHub to just collaborative contributions. Codeberg lets you disable pull requests and other unwanted features that GitHub forces down your throat.
In any big project your going to have disagreements.
I need to get paid to deal with stuff like that. No one is going to tell me how to write code without writing me a check.
Even at work I have my limits, although now that I'm older I'm much more inclined to just go with the flow. But if I'm not getting paid what's the point.
I do enjoy game jams though. We only need to work together for a weekend. Plus at least in my circle we only care if the code works.
fwiw, i always make my first PR to an open source as simple / uncomplicated as possible. Something like a spelling or grammar fix in documentation. It's a litmus test for how much drama I will need to face on the more complicated code issues to follow. When the project owners ignore or reject simple stuff, I generally wander off somewhere else.
So I heard some rumors about US policy affecting Rust. That Rust formely got money from USAID, and also the thing about the US government should promote memory safety (or smth like that?) was removed.
Could that be relevant to this story, or is that a complete sidetrack?
This has absolutely nothing to do with the US government. This current drama started before January 20th.
Rust has never as far as I'm aware or can tell via google recieved money from USAID. Though amusingly there has been money invested by USAID to combat it's namesake - a category of fungus - from destroying coffee plants.
What you're probably thinking of with regards to the US government is that the Trump administration has been deleting all sorts of websites and guidance, and one of the things deleted was a report by the White House Office of the National Cyber Director calling on developers to use memory safe languages [0]. Various other similar documents (e.g. randomly picked via google [1]) still exist and it's unlikely that this document was deleted because of its contents and not because the white house was just destroying the entire category of things related to the ONCD - even the landing page 404s [2].
That report was just a "this is a good idea", I don't believe it ever came with any funding or support.
It wouldn't surprise me if other similar things were deleted too, that's just the one I saw hit the news, so I'm guessing that's the news you saw.
again, as a user, I don't care. I use linux & visiting HN because of tech, not because of any politics.
Martin's patch should not be delayed or rejected because of the rust language, it is an approved language. If some maintainer has issue with such rust language approval, they should address that particular issue not patches using that language. They can also choose to resign.
always knew rust was good for nothing... now look what it did. the language itswlf is in conflict with itself and anything it touches in a serious way reflect that silly state
1. I do believe that Rust type system needs to be reworked, so all the drama around it is needlessly bloated. We have RustBelt, RustHornBelt and myriads ways of converting HIR/THIR/MIR to CoQ, for better or worse, but no MLIR support for rust codegen whatsoever. Rust is temporary, we'll get a simpler and better Lang further down the road.
2. The upstream fight had always followed the Cash Flow. If you have so called "problems" you either act yourself, or let other people do something about it, the way it won't result in more long-term issues. Deliberate Detraction IS a Sign of Corruption and Abuse of Power.
3. An ambiguous Point of Conflict may not be Conflict at all, but just an outcome of the Lack of Proper Communication and Transparency. Detraction is Accountable, social dynamics and social incline with explicit or implicit motives is Accountable as well. The lack of Effective Code of Conduct, and absence of Proper Punitive Action, for everyone, will cause Authoritarianism (or just Genocide of Engineering Thought).
I do feel bad about the state of Linux Kernel development, but we'll have either to move on, and learn from This Mistake, or do something about it.
I get this impression that the Rust people think they are a stage where Rust is a viral phenom but it's really not. Nevertheless, they are behaving like its viral and trying to force it down everybody's throats, even though I never heard of some software package or system that was built natively in rust that truly went viral. The other day I tried to install a python package and - big surprise - it REQUIRED me to install a rust toolchain to install the python package! Well, that package went straight into the dumpster (i'm on WSL which DOES NOT have a rust toolchain)!
This "we're viral" behavior when "it's really not" is very childish.
Was this comment written by an 80 year old who’s watched a Fox News segment on Rust? It definitely reads like that.
wsl ‘DOES’ have a rust toolchain, nobody is saying rust is going viral (what on earth…), you tried to install the python packages’ sdist rather than the wheel.
Regarding the point of "community" being difficult to manage in "open source" projects, I would argue managing a large group of developers on any project is difficult and full of drama.
I'm personally not an advocate of the "open source" obfuscation term myself, but the public license of the linux kernel has little to do with the drama.
Maybe the fact that linux developers have some kind of say at all, as opposed to some proprietary dev projects where every decision is handled by fiat (and Linus has certainly served this role at times), causes it to have more drama.
But no matter what model is followed, people do love their drama, and a large dev group is a social activity regardless of the licensing of the software itself.
Its like every social issue ever: the thing all participants have in common is that they are all humans...
The frustration seems justified.
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.
> Christoph Hellwig is one of the oldest subsystem maintainer.
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.
[flagged]
This is a fundamental misunderstanding of the structure of the linux kernel, the nature of kernels in general, and the ways one performs automated verification of computer code.
Automated verification (including as done by rust in it's compiler) does not involve anything popularly known as AI, and automated verification as it exists today is more complete for rust than for any other system (because no other widely used language today places the information needed for verification into the language itself, which results rust code being widely analyzable for safety).
Human validation is insufficient and error prone, which is why automated verification of code is something developers have been seeking and working on for a long time (before rust, even).
Having "explicit" (manual?) memory management is not a benefit to enabling verification either by humans or by machines. Neither is using a low level language which does not specify enough detail in the type system to perform verification.
Kernel modules aren't that special. One can put a _lot_ of code in them, that can do effectively anything (other than early boot bits, because they aren't loaded yet). Kernel modules exist for distribution reasons, and do not define any strict boundary.
If we're talking about out-of-tree kernel modules, those are not something the tend to exist for a long time. The only real examples today of long lived out-of-tree modules are zfs (filesystem) and nvidia (gpu driver). These only exist out-of-tree because of licensing and secrecy. This is because getting code in-tree generally helps keep code up to date with less effort from everyone involved: the people already making in-tree changes can see how certain APIs are being used and if those in-tree folks are more familiar with the API they can/may improve the now-merged code. And the formerly out-of-tree folks don't have to run their own release process, don't have to deal with constant compatibility issues as kernel APIs change, etc.
1 reply →
This doesn't make sense to me, why is a manual language that requires validation better than a language that enforces some safety on its own?
2 replies →
I don't get this what so ever, is there memory allocation bugs in GC languages such as Java?
Even if that is the case Rust specifically is design not to be GC.
Ontop of that you csn do manual memory management if you want in Rust afaik.
2 replies →
The patch is just a binding / abstraction of DMA for writing Rust drivers.
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.
1 reply →
> 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.
1 reply →
Why do people think rejecting rust drivers is a bad thing? It's a fucking c project.
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?
11 replies →
> controlled by Google/Samsung/Redhat/Microsoft.
Can they do that to openssl instead?
Thank you.
1 reply →
[flagged]
> 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!
Projects don't just live or die purely on technical merits. There are so many examples across history of this.
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).
Has anyone done that?
https://github.com/asterinas/asterinas
Asterinas is such an experiment. Purely written in Rust and Linux ABI compatible.
https://www.redox-os.org/
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
2 replies →
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.
5 replies →
completely agree on the fork side of things, just show its merits already or be done with it
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
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.
https://gitlab.com/uxrt/uxrt-toplevel
[flagged]
You could read books older than 2000+ years to realize this drama can't be avoided (though neither can this smug feel re other's ignorance)
Genuinely curious, what book are you talking about?
Please enlighten us, oh knowledgeable one.
3 replies →
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.
https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
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).
Both were wrong, but only one was corrected.
> 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.
3 replies →
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=43591 https://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.
1 reply →
> 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.
13 replies →
People forget things etc.
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"
9 replies →
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.
7 replies →
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.
2 replies →
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.
6 replies →
Every time I have to interact with mailing list based projects I feel like I must be missing some secret set of tools and workflows to make it easier.
Then I talk to the old timers and they act like I just need to get used to it.
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.
12 replies →
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?
And why not?
1 reply →
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.
7 replies →
> 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
I'm tired of anaphoras.
And he's not just abrasive He's a troublemaker. Seriously, code of conduct violation? It was perfectly clear what Hellwig meant by "cancer".
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.
8 replies →
Even if you put that aside, the problem is you offer Hellwig two solutions and he NACKs them both.
4 replies →
What is the interpretation of "cancer" in this context that isn't rude, offensive, or hostile to the R4L project?
4 replies →
> 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.
And Linus’ immediate reply
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
(not taking either side, just interesting to read the reply)
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.
1 reply →
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?
1 reply →
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.
Up until the point that he tried to leverage social media to get his way in a kernel maintainer dispute? That's just fundamentally not acceptable.
Linus was right to reprimand him for the suggestion.
I don't think there's "the point" when it was pretty much modus operandi for years.
1 reply →
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.
You broke Linus’ printer driver and you’re still alive to post? WOW! ;)
Looks like @marcan deleted his existence on mastodon? Does anyone have a copy of what he said on there?
The tweet he got called out for on the thread was
"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."
8 replies →
You can use the waybackmachine:
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 follower of him on Mastodon this makes me sad. Hector posted a lot of valuable, very informative toots that I learned a lot from.
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.
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.
93 replies →
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
70 replies →
> Other than that, it's not a binary yes/no question; no one is really against some Rust in some parts of the kernel, but which parts? How? Where? That's the big disagreement. Linus has always been fairly hands-off on these types of disagreements.
Some Kernel maintainers are absolutely against Rust anywhere in the kernel tree [0]:
> The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.
This is from Christoph Hellwig, the DMA maintainer. And is in fact what started the thread that led to Hector Martin quitting Linux. You can see other comments by Hellwig in that thread as well, he is extremely explicit - any Rust anywhere in the kernel is a big problem, and even if he can't stop it everywhere, he will do what he can to make it harder to use Rust by blocking it from the pieces he maintains.
[0] https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...
18 replies →
> no one is really against some Rust in some parts of the kernel
This drama included the dma maintainer saying he is categorically opposed to any Rust in any part of the kernel.
17 replies →
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.
36 replies →
One lesson I feel we can all learn from this is that social media really should not be used for self-therapy.
IMHO social media is toxic period and has no place in any professional interaction. It is inherently biased toward drama and bullshit by design, since this “maximizes engagement.”
The sooner politicians are outright banned from using it for anything connected to their office the better.
> no one is really against some Rust in some parts of the kernel
Dude, this was literally caused by a stubborn maintainer, Hellwig, saying he wants NO second language in the kernel at all, and his explicit vow to do anything he can to stop it.
5 replies →
Completely agree with you.
I totally agree that even "just threatening" a social media campaign is the wrong way. We are on the same page here.
I totally disagree that the other contributor is "a bit" abrasive though.
It's like a religious war. Brings the worst out of otherwise smart and not asshole people.
[dead]
[flagged]
1 reply →
> an uncommon failure of leadership for Torvalds
Exactly the point. IMHO the one and only thing that made Linux successful as a project is Linus' strong leadership - which has been criticized ad-nauseam over the years; yet it's the only thing that yields results.
So in the specific instances (like this one) where he's not decisively, unequivocally, and even harshly saying "yes" or "no" to something, the community shows a very clear incapability of reaching a decision.
Reminds me of a similar scenario that happened years ago with GVR stepping down as BDFL for Python - just after a tiresome and wasteful fight with the community's opinions.
"Community" is just a very naive ideal for me. There's a finite number of people that can do the job, and even a more finite number of people that can make a decision and stand by it.
Agree
The more I hear about "community" the more I roll my eyes
It can be great at doing the work but it is awful at setting direction, evolving with the times and focusing on what's important
Going by another story on the front page, I have my long list of criticism about systemd but the "get things done" attitude needed to be commended
5 replies →
> IMHO the one and only thing that made Linux successful as a project is Linus' strong leadership - which has been criticized ad-nauseam over the years; yet it's the only thing that yields results.
I wear garlic every day and have yet to be attacked by a vampire; clearly this is due to the garlic!
Tang/ballpoint pens/velcro never would have been invented if it weren't for the Apollo program.
etc.
1 reply →
>"Community" is just a very naive ideal for me.
I guess you are safe to say this now. But from 2014 to 2024, open source is not about code licensing but about the Community.
1 reply →
> IMHO the one and only thing that made Linux successful as a project is Linus' strong leadership
Naah, I don't think that's the only thing that did it. It was that, and the fact that people dared rely on it -- dared trust it to stick around, and to stay a single thing in stead of splintering up. And the thing that made it Open Source that stays Open Source -- that made it, in fact, Free Software -- is the license.
The two things that made Linux successful as a project are Linus' strong leadership and the GPL.
Just look at BSD: It had the backing of a whole darn university near Silicon Valley, not a single student somewhere North of The Wall. It had a head start by several years. And it had name recognition far beyond its home country[1]. And look where it is now: There are (at least?) three of them, and even together they're a marginal phenomenon among operating systems. I think that's because of the too-permissive BSD license.
___
[1]: The first I heard of "Open Systems" was well before I got into working with computers for a living, as a student at another university in the Frozen North in the late 1980s. My fiend and neighbour, a computer student, raved about how cool Unix was: "And you can even get it for free! It's called BSD!"
[flagged]
27 replies →
No, you get it backwards. Open source community folks despise any commands, the moment Linus orders free folks like you to do something will be the moment his leadership ends.
The drama, though, is due to personalities.
A directive from Linus on the technical roadmap isn't going to solve anything. It could declare someone the "winner" in this particular thread or this particular issue, but lets the personality issue fester.
It's probably best for Linux to work through its technical issues in boring email threads which never get any attention on social media. And its organizational issues and its personality issues, for that matter.
So it's probably good all around that Martin has bowed out. If you reach for the nuclear button whenever the people you're working with don't give you what you want, it's time to go work on your own (nothing wrong with that, BTW). It's not really a question of who's right, but whether people can find a way to work together. That's quite difficult in a big project, so you have to both really want it and be good at it or it's just not the place for you.
Coincidentally there is a very good talk related to this @ FOSDEM 2025 by James Bottomley: https://fosdem.org/2025/schedule/event/fosdem-2025-6540-the-...
Video isn't out yet, hopefully soon.
1 reply →
It's definitely a ballpark estimate, but "boring email threads" are 99% of LKML.
There's an average of 1000 messages per day, we get news of a drama-fueled thread like, three times on a bad year?
My ballpark estimate is probably low.
Well, while Hector had a long history of frustrations with working with kernel development, the project of integrating rust drivers in the kernel has reached a cross-roads. Either to take the next steps or effectively close the door of the kernel progressing further with C and all the debt it brings.
From what I saw, the project of writing the graphic drivers for ARM Macs was quite a success, so the door for those projects shouldn't be closed.
The policy of "No C++, because I don't want to deal with C++ people", should be extended to the Rust community. Whatever you think of the merits of the Rust language, the drama, the lecturing and the general superiority complex of the Rust community is quite off putting, at least to C developers.
I also agree that Linux should close the door to Rust as a matter of principle, as it has done to any other language other than C. I don't believe in a mixed language kernel, it is just nonsense, specially with such a different language such as Rust which is closer to C++ in philosophy.
17 replies →
Linux kernel community is afraid of drama? I've been using Rust as a primary language for years now and would agree that the community is lead by immature drama queens. However, the linux kernel team would be the best comparison.
> at least to C developers.
so it is not about technical merits, but just some language religious thing? nice.
3 replies →
>Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor
You're reading way too far into this. Linus has been publicly positive about the R4L project plenty of times.
Positive, yes, but can you point to where he says R4L is here to stay and an integral part of the kernel? He needs to commit, or drama like this will continue to boil over. He also seems content to let the C-only old guard give the R4L guys a hard time. If you only enforce the rules on one side of a conflict, it makes it pretty clear which side you agree with.
56 replies →
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.
5 replies →
Agree with that. His statements are available on youtube. I was suprised how positive and eager to the change he was.
Why would he make such blanket decision on something he does not completely understand?
The maintainers of core subsystems are the people he trusts, at least trusts as much as you can in this space. He'll take their opinions before anyone else, since they know best about the subsystems they maintain.
To get Linux to overrule them you not only need to come up with very very convincing technical argument, you have to make sure you also posses the depth and competence required to maintain any such subsystem if the maintainers rage quit. Because you see, maintainers of these subsystems resigning is the bigger blow
> The maintainers of core subsystems are the people he trusts, at least trusts as much as you can in this space. He'll take their opinions before anyone else, since they know best about the subsystems they maintain
But there were no technical arguments against the Rust wrapper. And in any case, the Rust wrapper isn't in that subsystem, it just uses that subsystem. Hellwig's argument was nothing more than "there shouldn't be a second language in the kernel". He had nothing specific about the DMA wrapper. And Linus has already approved Rust in the Linux kernel, so what's the problem? Why can't Linus put his foot down on an issue that he has already decided on?
8 replies →
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?
1 reply →
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?
[1] https://stackoverflow.blog/2024/12/30/in-rust-we-trust-white...
> over half of the C++ devs will feel betrayed and quit supporting the Linux project. They've been working on C++ for Decades and things mostly worked, so they won't pivot for a new language and way of developing for something that exists for less than 30 years.
You mean C? C++ has been dead and buried for years and there are 0 kernel devs thinking that C++ will ever be allowed in (that idea was killed in the 00s if I recall correctly).
I don't think the situation is quite as extreme as you're making it out. For example, the employers of Linux kernel devs are getting pressure to use Rust because of the push from within & without the industry. I think push comes to shove, most people have a stronger preference for their paycheck than for the language they work in.
5 replies →
> like DARPA and other departments of the American government[1]
Eh, that White House link is dead right now and I would not be shocked if whole department is purged soon, so who knows anymore…
I do wonder if Linus is actually opposed to Rust in the kernel, but for whatever reason thinks that he can't afford to openly ban it or do anything beyond deniably letting it be obstructed by maintainers. The Rust language project and community are political and politically savvy in ways that few other open-source infrastructure projects are - it seems conceivable that if he declared against it, this might result in personal attacks and pressure on key backers/sponsors that would endanger his position or Linux itself.
It would be a silly strategy compared to saying that mixing languages is a bad idea and rely on inertia.
Also, letting rust in doesn't seem to stop the personal attacks, case in point
Very reasonable take. I feel the same. Any kind of real or perceived attack on Rust is heresy today.
> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor, but he hasn't said anything explicitly. [...]
I don't see it that way. Linus is conscious of not becoming a bottleneck on every topic; he doesn't want to baby-sit overly grown adults. I read most of the relevant LKML thread[1]. Martin did the unwise thing of escalating it on social media:
"If shaming on social media does not work, then tell me what does, because I'm out of ideas."
That is not the way to build bridges and relationships in a community! No matter how frustrated you are. He reaped the whirlwind for taking that destructive approach.
Also, Christoph Hellwig, as an established maintainer, totally missed the mark by using the highly-flammable word, "cancer", to describe Rust. It scorched the LKML and the internet. He should have showed more restraint and wisdom.
[1] https://lore.kernel.org/rust-for-linux/Z6YPfsDSNdRUskvp@phen...
Last year, Linus approached the topic of Rust in the kernel as if it were two opposite communities that were each passionate about their cause: https://www.theregister.com/2024/09/19/torvalds_talks_rust_i...
And his viewpoint at the time seemed fairly agnostic - he enjoyed the passion on both sides but said nothing about what his thoughts were. This leads me to believe that he hasn't spent the time to think about the important issues on either side and make a decision (the failure of leadership mentioned in the parent comment).
Personally, I'm surprised Linus hasn't gone 100% in on Rust as he is normally very forward-thinking, so perhaps that has added to the frustration from so many kernel developers like Hector.
If you're gonna lead a group of people effectively, you kinda have to listen to them. leading by decree works occasionally, but you can't afford to do it often.
If there's a lot of people sceptical to rust, doing a limited experiment is one way to figure out if it's going to work. Rust people working in the kernel should act accordingly. Drama like this is not helpful
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".
People get old and stop caring. Linus is still doing amazing. But I agree he should have just said no to Rust and move on.
Why? Was it not worth seeing where it would go, or how many would be interested? Is it possible he believed the tides could turn that way?
2 replies →
>..... Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue.......if Linus had just said "no, keep it downstream".
I have been thinking for years that the reason why Linux dont attack Rust like all other languages is that his close friend or close subordinate like Greg actually like rust. So rust as a language has huge leverage within the Linus decision mental model.
Not to mention the huge Rust gang both on the internet and around him. Friends that support Rust. Having the usual strong opinions of Rust like he had for C++ will obviously damage friendship.
I always suspected it was commercial/government pressure. Hard to argue against "doing something" for safety.
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?
6 replies →
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.
15 replies →
Rust is bad news for Linux.
No because its Rust, but because it's a bad idea to use more than one single language across the entire code base.
I also am surprised that Linus has not ended this folly.
If Rust wants a Linux kernel it should make one.
Do you feel the same about Make, Device Tree, KConfig, Python, the myriad of machine-specific assembly, POSIX shell, Perl, and every other non-C language currently in the code base?
10 replies →
> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor
His reprimand is a clear signal that he won't tolerate brigading. Marcan was making a pretty blatant attempt at using social pressure to influence decisions.
And that is very fair since brigading is definitely not helping here. However, he should have also done the same to Hellwig for his unproductive behavior, yet he did nothing.
Oh and I got this quote for you:
> Linus Torvalds admonished the group that he did not want to talk about every subsystem supporting Rust at this time; getting support into some of them is sufficient for now. When Airlie asked what would happen when some subsystem blocks progress, Torvalds answered "that's my job".
Source: https://lwn.net/Articles/991062/
Do your job then, Linus!
People using Mastodon to promote pile-ons or brigading?
No, never! That's actually one reason I don't use Mastodon, it's extremely common. Isn't this the guy that blocked HackerNews links to the Asahi Linux homepage because the moderators wouldn't do his bidding?
35 replies →
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.
5 replies →
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"?
5 replies →
Help me out here because I'm not sure how to navigate the submitted link https://lkml.org/lkml/2025/2/7/9. Where is this reprimand / can it be seen?
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
Edit: For further context for Linus's reply, there's http://web.archive.org/web/20250206022420/https://social.tre...
20 replies →
> 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. .
7 replies →
> 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.
3 replies →
> We all know his stance on C++, for instance.
Yeah, but that's because Linux was actually built with g++ for a few versions! The opinion was informed by experience, not an a priori thing. And it was likewise extremely controversial at the time. And eventually they rolled it back out and gave up.
Maybe that will happen with Rust too, or maybe not. But The Process, such as it is, is working today the same way it always has. They try stuff and fight about it, and eventually a winner is clear and a consensus emerges. And, yeah, there are losers, too.
> Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue.
He probably didn't want to end up like Stallman.
> And it's quite out of character for Linus not to have a blazingly clear opinion. (We all know his stance on C++, for instance.)
People change. As you get older, you might find you no longer care that much about subjects you previously had very strong opinions about
Linus actually writes C++ code though:
https://github.com/subsurface/subsurface/commit/1b16d570a1b6...
someone <cough>https://news.ycombinator.com/user?id=simonw</cough> should create a browser plugin where you can highlight and right-click to get a explanation / context of a chunk of text...
For example: https://gist.github.com/rayvoelker/c5f480f46c80a7a3c22386b29...
> As a pilot program, R4L should have graduated or ended a long time ago.
Disagree. These things take time. Linus knows that, and as I see it, he's giving it the time it needs. "After years of active development" we've only recently arrived at a point where actual driver development in Rust is possible.
> We all know [Linus'] stance on C++
Yes. And looking back I think that was a good stance. C++ is not for kernels: the language is too big, containing features that don't fit well with kernel development, thereby inviting all kinds of discussion not conductive to kernel development.
Rust is another story. Rust has potential to bring benefits to the kernel. I think Linus knows that.
Off-topic: I'm looking forward to an --largely automated (maybe with use of LLMs)-- port of the kernel in Zig. Just because I think the developer ergonomics of Zig are so much better than C. Not holding my breath: in 10 years or so would be nice.
> C++ is not for kernels
That's a broad generalization to make.
Nintendo's custom OS (Horizon OS, used on Switch and a previous version on 3DS) is almost fully written in C++, including the entire kernel and all drivers.
I agree with you that C++ has plenty of misfeatures. Fortunately, compiler vendors make it fairly easy to dodge the bad parts of the language.
2 replies →
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.
I agree with all statement from Linus. Keep it separated/downlined project I think is the best for both worlds.
Could you please post more details on the reprimand you refer to?
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
> How about you accept the fact that maybe the problem is you.
> You think you know better. But the current process works.
> It has problems, but problems are a fact of life. There is no perfect.
> However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.
> Because if we have issues in the kernel development model, then social media sure as hell isn't the solution. The same way it sure as hell wasn't the solution to politics.
> Technical patches and discussions matter. Social media brigading - no than\k you.
> Linus
Obviously he does not like Rust just as much as C++, which is understandable.
The difference is that he is a little bit more diplomatic than he used to be.
But why someone want to push a language into someone else's kernel? Fork your own, if you want.
thank Linus for you
[flagged]
I think you overestimate rust and misunderstand the problems. This is classic junior engineer "rewrite everything" thinking
I didn't downvote you, but I think you have a misunderstanding of a couple of things that are clouding your judgement: (1) the sheer size & inertia of the Linux kernel; there are tens of millions of lines of code, and even thinking about integrating another language will take time- lots of it; and (2) the distributed nature of its development and the diversity of its engineers; the community is not one that can be brought into an auditorium and made to change direction on a dime. Rust may have been around for 10 years, but no one was going to go all in on day one.
Further, this attitude of "Rust is clearly superior, so what's the holdup" is itself a holdup. You can't expect people to just spend their time learning a new language just because it's there, especially professionals with personal lives. These people do serious work, on a codebase that millions of people around the world, including virtually every tech company, relies on in some fashion. That's not a game. It's "serious business."
Serious business doesn't just chase something because it's new and hot and solves a certain class of problems (while simultaneously introducing its own set of problems).
Nothing is a panacea (yet, I suppose). This ship has been sailing for 30+ years. So many millions of man-hours have been put into it that people are justifiably cautious.
Now, all of that being said, I read the DMA maintainer's comments a few days ago and I thought he was being unreasonable, however, he is correct about the external dependency on his code. Even if the Rust DMA wrapper is kept completely separate, under a separate tree, he would still have to contend with the fact that any changes he makes might influence that wrapper and all the code that depends on it. So now, even if they claim to maintain the wrapper 100%, he is still beholden to all those downstream developers that rely on the Rust DMA wrapper's functionality, because if he breaks their code, he knows it'll cause a shitstorm. It's easy to say you'll maintain something 100% and the upstream guy doesn't have to worry, but time passes, things change, and all of a sudden, his hands get tied because it'll impact too many people. That's just reality.
Truth be told, I would eventually suspect some (or maybe many) Rust developers will migrate to a new project, because the rate of change is not going to be fast enough to ever satisfy them. And that's understandable. People want to make an impact, especially when contributing to an open source project (and doubly so on an unpaid basis).
Unfortunately I don't think Redox is the answer. UNIX and its clones/derivatives have had a long run, but anyone who wants to create the next big thing is not going to want just another clone of UNIX, even if it is in Rust.
We have seen the enemy. We understand the threat models and know far more about virtualization, containerization, sandboxing, etc., just by virtue of having had to dogfood these technologies for the last 25 years.
The next big thing (if there is one), will likely be something more like a cross between the Windows world (where ACLs rule the roost, and centralized management is built-in), UNIX with its CLI focus, process composition & command familiarity, and something like L4 which has unforgeable capabilities built in and a formally verified kernel.
Or we'll just go back to a modern day version of the UNIX wars, lol. Something, something about history rhyming.
3 replies →
Or dump linux and move to freebsd / haiku
Get rust out of the kernel, now! Rust as a language is meant to be the output of an llm which can be verfied by humans.
Torvalds lost respect of a lot of people, that's the most important thing.
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.
3 replies →
> However, the discussion is over
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.
> 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.
Luckily, the kernel seems to be doing fine.
40 replies →
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.
1 reply →
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.
19 replies →
"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
24 replies →
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.
1 reply →
I can easily fork your project with 1k lines of code, but not Linux kernel and stay up-to-date with all the latest commits. Nobody can.
1 reply →
Give him time, Linus will reach out soon regarding Rust.
He has at least said this to Martin: "How about you accept the fact that maybe the problem is you." (https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...)
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.
9 replies →
[flagged]
Quoting from this thread https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phen...
> 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.
Sima also went way too far with some of her comments this morning:
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.
Is Sima paid for his contributions?
1 reply →
Sima is another Rust for Linux member, right?
Yeah I commented before I saw that one toot from @sima. Indeed they both look bad here.
[flagged]
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.
No that's 100% accurate.
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.
[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...
I suppose this is what you're looking for:
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.
I saw the social media post, and it didn’t even register as “trying to start a brigade” IMO.
I read it as “look at this shit” and general frustration with the likes of DMA-guys behaviour.
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.
Martin has worked hard on Asahi, but comes of as looking for drama and virtue signalling oftentimes. I'd give this to Linus.
>and virtue signalling
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.
[flagged]
6 replies →
>but comes of as looking for drama and virtue signalling oftentimes
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.
"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.
1 reply →
It's called systemd, all lowercase, no punctuation :)
> 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.
11 replies →
[flagged]
>Starting to think it's not just a coincidence.
Is your theory that rust makes people dramatic? Or that dramatic people like rust? What other options are there, if not coincidence?
9 replies →
...As opposed to kernel developers? Or even Linus himself 5 years ago?
> 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.
There's more than one flavor of virtue.
I cannot find it, but I distinctly remember a post by Rachel on her blog (rachelbythebay) that talks about this exact problem in open source.
Sometimes the nuance of appealing to maintainers emotions is more work than writing the software yourself and maintaining your own private fork.
If someone could find that blog post (and subsequent hacker news ref) it would be a fun way to compare this discourse to Rachel’s discourse.
Edit:
Found it: Choosing to stay out of the community.
https://news.ycombinator.com/item?id=18181409
https://rachelbythebay.com/w/2013/06/03/bugs/
EDIT Wrong one sorry
For context: https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
How is this not the top comment? I was scratching my head wondering until I found your links.
So the smackdown from Linus is what motivated it. Honestly though if you read the email Linus is replying to, it was deserved. To be fair, Hector Martin may be one of the smartest hackers alive today. His fame goes way back to hacking the Playstation 3 with geohot and Hector has even found security vulnerabilities in Apple Silicon. He's done great work with Asahi Linux by weaponizing his keen penetrating mind to support open source freedom. But like his buddy geohot he can be a bit childish. Right now Hector seems to be laying low. His social media accounts are no longer accessible. It seems even archive.org and archive.today have no recollection of him. That's impressive.
So what triggered him to act out of character? It seems like he wrote his Apple GPU driver in Rust and he needed Rust DMA support in the kernel. I know, a curious thing for a Rust developer to want more power to do things that are memory unsafe. So the DMA maintainer Christoph Hellwig hates Rust. He thinks Rust is a cancer in the kernel. Cristoph refused to help Martin create Rust APIs for DMA. That's why he went ballistic.
Chances are they'll all make up when this blows over, or someone will just rewrite his GPU driver in C. There's not going to be as big of a push for Rust with this recent government. For example, the White House recently took down its paper about the future of programming being memory safe. The money for Rust is going to dry up. It's becoming socially acceptable to push back against efforts to convert everyone to Rust.
> Cristoph refused to help Martin create Rust APIs for DMA. That's why he went ballistic.
No, he tried to prevent other people from doing the work to create Rust APIs, and said that he would do everything in his power to prevent anyone from doing it.
> the White House recently took down its paper about the future of programming being memory safe
They took down all of https://www.whitehouse.gov/oncd/, what makes you think they gave any thought to this paper in particular?
> It seems like he wrote his Apple GPU driver in Rust and he needed Rust DMA support in the kernel.
Did he really NEED it? Why he couldn't use the C API?
1 reply →
Thanks for explaining what rust had to do with apple hardware drivers.
He also got his treehouse.systems Mastodon account "suspended by a moderator". Not sure if the treehouse people have said anything more specfic, but I am entirely unsurprised given how he behaved on there.
It's a quite clear case of "what you accuse others of is what you yourself resort to". He was calling out others for unreasonableness, flaming and sabotage — and did exactly that himself.
It doesn't say anything about moderator action for me.
He closed the account himself:
> I actually wasn't sure if I wanted to delete my Mastodon entirely or not, but as I intended to fill in my password for confirmation and decide whether to click the button, my password manager auto-submitted the form for me. Call it fate, I guess. I mostly don't regret it. Maybe I'll be back some day, maybe not.
https://old.reddit.com/r/AsahiLinux/comments/1ijvq7y/asahi_l...
This is what I got when I posted my comment: https://imgur.com/a/zlNmWtF (TZ is UTC+1)
It is gone now and gives a generic "nothing here"; I have no idea whether the "suspended by moderator" display was some kind of bug, transient state, or whether he's just lying, or both things are true and he just deleted his account after it was suspended.
(Well, his Reddit post doesn't claim his Mastodon account didn't get suspended, so it'd "only" be the omission kind of lie…)
FWIW, I don't understand the logic of deleting the Mastodon account but continuing to post on Reddit… those are both "social media" in my mind…
6 replies →
See, nobody would close his account if he was still on Twitter.... sorry X now
Yeah, on X he would've been shadow banned long ago instead, for some random left-leaning post that just happened to get too much attention…
> Apple/ARM platform development will continue downstream. If I feel like sending some patches upstream in the future myself for whatever subtree I may, or I may not.
I suppose it's possible that that could turn out well.
The situation with Apple hardware feels a bit like the early days of Linux (including the fast pace of development). There was a time when if you wanted broad hardware support it was better to run an Alan Cox kernel than a Linus kernel. And the whole point of git was to have a system that didn't require one central blessed tree.
Linus replied:
Context
I struggle to follow the LKML through the web-interface. LORE seems to provide a better view:
1. https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15...
Maintainer of DMA wants to keep the code clean and not mixing languages[1]. And tries to avoid dangerous offers like "we will maintain it for you".[2]
2. https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15...
Somebody references social media posts.
3. https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15...
4. https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15...
Torvalds reaction.
My impression, while still struggling to follow the message flow:
I think social media and shaming are harmful and understand the reaction of Torvalds. The position of the DMA maintainer seems also to make sense for me, to keep code maintainable over decades it must remain in a nice and tidy state. That is the hard work.
PS: I want to avoid actual names of persons.
>Maintainer of DMA wants to keep the code clean and not mixing languages[1]. And tries to avoid dangerous offers like "we will maintain it for you".[2]
The Rust bindings are not in his tree. They do not touch his code. They are effectively no different than any other subsystem or driver which uses DMA. If he tried to veto some random driver that needed DMA from using DMA for no reason other than because he didn't want to have to deal with it if he changed the API in the future, that maintainer would be told to F-off because that's not his call.
Christoph is throwing NACKs around that he doesn't actually have the authority to NACK.
> The position of the DMA maintainer seems also to make sense for me, to keep code maintainable over decades it must remain in a nice and tidy state.
Perhaps so, but that discussion was two or three years ago. Stalling other contributors' work now is counterproductive, especially for changes that do not touch files maintained by them.
This does not justify any brigading behavior, though.
> no than\k you
Is that a typo or he indeed intended to escape that 'k'?
(Sorry, I know this doesn't add to the drama or what's going on there, which really doesn't interest me one way or the other, but this tiny bit had me curious)
I don't have anything to add regarding the Hector v. Linus debate, who was in the wrong, who was in the right, who's to blame etc...
All I want to know is what's the long term viability of Asahi Linux or Linux for that matter on M series chip'd Macs? What's the burden going to be for Fedora Asahi if the work remains out of tree? Has Redhat/IBM stated they'll support it via the Fedora project going forward? What if they pull support?
I think right now Marcan can work magic and reverse these chips and other pieces. Long term it's an arms race and Apple has other motivations to lock the platform down further. They may even get told to make it compatible, but they seem to be willing to maliciously comply with those directives.
I am reminded of the Beeper messenger stuff. Like it's cool when people hack these things together to do stuff, but the community as a whole has seen this episode before. We probably shouldn't be making any choices or compromises to make Apple stuff work, because they are adversarial.
Some other devs from the project have stepped up to coordinate getting their work into the kernel!
Wow, this thread is wild. It’s like everyone’s losing their minds over mixing Rust into our old, battle-tested C kernel. Sure, Rust promises a ton of safety benefits and could really help keep nasty bugs at bay, but some folks are super worried that every time a C API changes, the Rust side will break—and then someone’s stuck fixing it. It’s as if everyone’s saying, “We’re cool with experimenting, but don’t force us into a multi-language mess we didn’t sign up for.”
What really gets me is the whole leadership vibe. If Linus had just clearly said, “Alright, Rust is in, but only in these specific parts and under these conditions,” a lot of this back-and-forth and social media shouting would’ve been avoided. Instead, we’ve got a bunch of maintainers arguing about process and even threatening to use social media to shame people, which just adds more fuel to the fire.
At the end of the day, it’s not as simple as “Rust or no Rust.” Some parts of the kernel might really benefit from Rust’s safety, while other parts might be fine sticking to C. The real challenge is figuring out how to integrate Rust without turning everything into a maintenance nightmare. We’re all aiming for a better, more robust kernel here, but if we keep getting bogged down in personal drama and endless debates about process, nobody wins. Maybe it’s time to take a deep breath, set some clear rules, and move on instead of letting all this online drama derail progress.
Linus vs. Rustaceans: the get off my lawn sequel nobody asked for. Kernel devs now double as drama critics, social media is the new mailing list flamewar arena, and somewhere a C pointer quietly segfaults out of spite. Will rust ever "make install"? Stay tuned! To find out in the next episode of Keeping Up with the Rustaceans
Marcan hasn't actually resigned. He's still posting on the LKML under a well-known alias.
See https://lkml.org/lkml/2025/2/7/15 for example.
Marcan is still posting to the LKML as himself too and he said he might contribute patches in the future if he feels like it. What he did, and this entire thread is about, is he resigned as a maintainer:
https://github.com/torvalds/linux/commit/1b3291f00013c86a9bb...
So the title is factually correct. But I wouldn't be surprised if he tries to add Lina as a maintainer once things calm down.
I always enjoyed watching Marcan's streams. But I couldn't do Lina's, only because the high pitched voice changing was grating.
Is this the same person who has YouTube videos narrated by a cartoon Japanese schoolgirl?
> I am supported exclusively by donations, which incidentally, have been steadily decreasing since the start of the Asahi Linux project. The project has zero corporate sponsorship.
People’s donations to Asahi Linux have decreased, according to Hector from this thread [0]
Here’s how to donate: https://asahilinux.org/support/
[0] https://lore.kernel.org/rust-for-linux/c5a49bcb-45cf-4295-80...
He basically said goodbye like 4 times and continued to make long ass rants that lead to nothing. Is this what you want to spend your time on? I already feel gross that I went through all these threads. I can't imagine how you would feel having written all these paragraphs of slop.
I had to remove marcan from my social media because he constantly generates this kind if drama. :/
You know, Redox (as the "most serious" Rust kernel I can think of) could probably do with non-trivial drivers. It would be unfortunate for aspiring or even seasoned kernel developers to step away from the practice entirely, simply because R4L fails to launch.
Part of me feels like something like Redox isn't exactly worthit. Now I hope the project succeeds in whatever goals they have, and honestly where they've gotten to is impressive; what I mean to say is that I think it would be far more interesting to imagine beyond just Unix and especially the problems of POSIX. I think the "next" thing, if that even ever materializes needs to be that, something reimagined. Computers aren't emulated PDP-11's anymore.
It seems fuchsia might me something for you
I don’t see why forking is not an option here.
If the upstream maintainers don’t want to adopt it, the Rust folks can gradually rewrite the bits they want to and let the market decide. Use the Ballmer “embrace, extend, extinguish” model.
Linux is not a side project. It has thousands of developers being paid by chip and hardware manufacturers to ensure that linux works on their products.
With the complexity of systems engineering, for a single driver, it takes months to build one from scratch. Plus, there is not enough expertise within the rust community to take on a project like the linux kernel to match the rate of development by many large corporations with hobbyists.
It started as a side project.
They may not match the rate of upstream development, but doing their own thing is going to be a faster path to their goal of Rust in the kernel than trying to convince everyone else to do something that they don’t seem to want.
1 reply →
Because forking requires a lot of hard work and time to even get acknowledged, while bringing Rust into the kernel, given enough PR, establishes a whole new hierarchy in which not only do they get to be at the top of right away, but they also get to depose the old guard!
Can someone steelman Linus's:
> ABSOLUTELY NO C++ in the kernel EVER. But Rust is totally fine.
stance? It seems pretty absurd when you consider the closer similarity between C and C++ (and the more straight-forward migration path from C to C++), and the fact that GCC supports C++ (even recent vintages) natively on many more architectures.
The rust folks should make a Linux compatible kernel and distros that include a stripped down Linux kernel as a compatibility layer for legacy software.
There's this... (not quite what you wanted)
https://www.redox-os.org/
There was actually a proposal to do what he's suggesting in redox at some point, some sort of emulator layer to run linux to take advantage of linux drivers. I haven't followed up to see what's happening with it.
This is what you want: https://news.ycombinator.com/item?id=41847640
It is a quandry, the kernel is predominantly C, Rust has demonstrated a path forward, producing safer code without sacrificing performance, but it is undeniable that a mixed code base is far harder to maintain, not impossible.
Here's the thing, in the next couple of years languages like Carbon, Zig, even Jai, will come of age. They will have their proponents and people who want to introduce them into kernel code.
If there is a rust developer out there who doesn't resist the introduction of these languages as ardently as the chosen people (C) are resisting rust, then I will show you someone who lives in some kind of alternate reality.
Personally, I'd be pressuring the C committee to introduce defer, tout suite, otherwise Zig looks favourite. But the reality is that your preferred language is just that, your preferred language, most have seen this drama before and will choose not to participate.
As to whether Linus is failing in his leadership role? Nah, Then again, I wish Sony would open source the PS OS and we can be done with this juvenile debate as to which OS should rule the world. Either that or let's have an exokernal and move on from this monololithic story, surely that would meet the needs of the MY FAVOURITE LANGUAGE isn't appreciated crowd!!
Hi! I’m a Rust developer. The kernel should include whatever languages they want to include. I’m in the same reality as you.
There will be a similar drama when Zig reaches 1.0. There will be a bunch of Ziggers trying to get it into the kernal. The Rust fad is already slowing down. Maybe it's a good idea to wait 10-15 years before trying to rewrite the universe in a "memory safe" language and pushing that upstream.
Zig brings developer velocity benefits over C, but developer velocity is not the reason R4L exists. Until Zig has an easily segmented part that is memory safe, there is no demand for its potential benefits in Linux. Memory safety is the only reason a new language was considered within Linux.
Zig is at least better impedance matched to C. Procedural and relatively small conceptually. Simple interop. Rust feels closer to C++ than C.
Zig fixes many of my woes with C. Compilation time is better than Rust’s, and there’s no borrow checker. I also find the Zig community more pleasant than Rust’s.
The Rust ecosystem never clicked for me the way Go or Zig did. But I work with I/O-heavy distributed systems, where Go outshines Rust in most cases, so that’s what I use the most.
Systems programming is a different beast, though, and I’m glad the push for rewriting everything in Rust has lost its initial momentum while Zig is emerging as a strong contender. Even then, I wouldn’t want Ziggers to start pushing things upstream into the kernel anytime soon.
Maybe, I think it's more likely that a Zig soft fork would first replace the kernel build system and then, with unit tests, piece by piece port the whole beautiful thing. Zig is on a strong path to compile and interact with C better than existing C compilers.
I like Zig a lot over Rust but I guess people should give it a while (10y) before attempting something like that. Zig isn’t even 1.0 yet and it’s not going to be for at least 2 more years.
In 10 years C compiler may include the benefits of a borrow checker but in a more flexible manner.
Or C can get cleaned up and become something like Zig. I would rather read messy C or Zig code over Rust in any day.
I understand the frustration, but I don't understand the drama.
There are other big Linux forks that met a similar resistance, best example is probably Realtime Linux / RTLinux that was not welcome in the Kernel for what, 15 years? Yet they still continued in their own fork and now most of their patches have finally gone in.
The way they're going to work now should have been the default. Just as RTLinux was a big change to the Linux kernel, Rust will be a big change. You cannot expect the Kernel community to welcome such a huge change with open arms and deal with all the fallout (build system, interfaces, etc.)
Just be ready for your project to take a decade, instead of trying to force it in "now or never". Until then, maintain some out-of-tree modules written in rust that every Linux distro/user can try and test without much fuss. For example, I don't think it will be a huge problem if Mac users have to get their DRM driver at some other repo (or if distributions would have to package some `linux-module-drm-apple` package separately from the Kernel)
> and now most of their patches have finally gone in.
Is there anything outstanding? I thought they recently reached the point where everything from -RT is in mainline.
yeah, probably. Sorry, I admit I haven't been following them too closely.
Rust or not, mixing two different languages within a single project is a sure fire way for a maintenance nightmare. Specially for a large project like Linux. I sincerely don’t want something like that happening to the Linux kernel. Just let it die with C. However it may seem improbable, writing a kernel from scratch is the way to go for new wanna be system programming languages.
Indeed. I grew up with open-source. I still like C very much. I do not think Linux would die. But I may be wrong and Rust is the future. In the past, people just created their own projects. If they were truly better, eventually the were adopted more and more, but who did not like it, could also just stay with the older projects as long as they were recently maintained.
and they have one: Redox
Likewise most Rust efforts going on from Microsoft and Google are on downstream, Android, Sphere OS,...
This was to be expected, many of their anti-C++ complaints also apply to Rust, given that both languages share many common ideas, even if presented in different forms.
> This was to be expected, many of their anti-C++ complaints also apply to Rust, given that both languages share many common ideas, even if presented in different forms.
I was genuinely surprised when Linus opened the door for Rust in the Kernel for that reason. And the real waste is there: had Linux said a straight “no”, then nobody would have lost their time trying to make this work against all odds.
Or maybe Linus really thinks Rust is the future, but he doesn't want to enforce its inclusion in the Kernel against his senior maintainers because he's afraid of an uprising.
Linus said he's worried that he and core kernel maintainers are getting old, and there may not be enough younger contributors to replace them. There's an implication there that Rust will continue to grow and attract more talent, and it'll get harder and harder to find devs passionate about old C codebases.
1 reply →
[flagged]
It's cowardly and easy for me to say now after the fact, but I saw the original Mastodon post because I follow Hector Martin. I didn't think that it was going to make the situation any better but I didn't have the energy to even fire off a one-off comment saying so.
I absolutely get emotional about my work. I have absolutely sabotaged myself by not having the presence of mind to step back and take a deep breath. I had a moment of clarity reading Hector's post on Mastodon, and I'm sad that my suspicion that this was going to just make things worse was correct
I think it looks like both sides are making some pretty valid points here.
Those who are nervous about embracing Rust further are just fine. Rust is still a young language. It shows an awful lot of promise, but it isn't a magic cure for safety and security concerns, especially at the kernel level. It is entirely possible that Linux is a bad fit for the language, and the real way to get ta Rust kernel is for a team to come together and implement a kernel in Rust, from scratch, perhaps with POSIX compatibility.
On the flip side, Hector is entirely correct that the overall process of maintaining and improving Linux is incredibly baroque and grounded squarely in some tooling that just stinks in the modern ecosystem. It has worked for Linux for ages. It is also increasingly making working on Linux a specialized project space because nobody else manages projects like this. Hector is fine leaving if he finds that process two owners to be worth his volunteered time. And it is entirely possible that there will come a day when the value of the project itself is outweighed by the cost of interacting with the project and Linux will get supplanted in the common ecosystem by something else.
In short, Hector is probably making the right move here. If he wants to continue working on a problem like this, a new operating system might actually be the right solution.
Linux is one of the most complicated OS in the history of OS and both of them understand this in someway or the other, it's still not cracked enough market share to dominate the personal computer market even in 2025, but is already on millions of other devices except PCs and a small change in decision like r4l brings the whole perspective into matter, after the fact that rust is highly compute intensive language and low end processors might not be able to catchup the speed in the best possible way these industries work, memory is cheap to include and hence the decision to include Python was a comparatively easy one, but rust is a highly balanced choice currently which makes the decision more difficult for Linux to include R4L in kernel, hence the dissolution on parts in which to include.
This is based on my limited experience with rust, but I believe we really need to give rust more time to mature it enough to see where we're going with the builds to actually decide on this matter, even personally. Plus, Linux has been keeping the Linux Kernel project alive for so long that he probably already has got the experience of knowing the repercussions of a wrong decision. Being hasty in this scenario doesn't solve the problem
> the fact that rust is highly compute intensive language
care to elaborate on that?
rust utilizes various methods at compile time which significantly increases compute, such as compiler is optimised for memory safety, which causes it do a lot of tasks and changes at compile time unlike C and inturn during execution to ensure ms, which could easily be avoided, it is good for overflow situations but in terms of compute required in exchange for the program is simply(currently) not at the level that would be great to have in Linux kernel, in a few years maybe
2 replies →
Arguably the billions of Android phones/tablets running the Linux kernel are the personal computer market.
Exactly my point in terms of the chipsets, and the limited acceleration in capacity of evolution per year for small chip manufacturing companies unlike mediatek and qualcomm, furthered by silicon shortage and many other manufacturing facts, including a language like Rust at this stage should be subject to observation.
I have a question. Instead of fighting an uphill war in the Linux kernel community, why don't Rush developers just make a new kernel or fork their own? Sure it's going to take years, but at least they don't have to suffer the mental outrages from time to time and can do whatever they want? I mean I'd do it if that's what I want.
P.S I don't have skin and skill for the kernel game. I'm just a curious bystander.
Linux is a cooperation between numerous companies to develop a shared artifact that works with all of their hardware, solves all of their use cases, etc. No one company involved can just go make their own replacement, because they need the cooperation of the other companies involved to get it to work on the hardware manufactured by the other companies.
Even ignoring the driver problem, it's not really an economically viable amount of work. Right now everyone benefits from everyone else's bug fixes, from everyone else's security improvements (like introducing rust!), etc. Going it on your own means you have to redo everything everyone else has done (unless you just fork linux), and that you don't get the benefit of everyone else working on the shared codebase (I suppose unless you fork linux and keep merging in upstream... which is actually what projects like Android do).
A complete rewrite also means a huge time lag before you start seeing payback in terms of faster development speed and a more reliable/secure operating system. Unlike introducing rust in new work to the existing kernel which sees relatively immediate payback.
I suppose I wouldn't be too surprised to see a project like Android just maintaining a whole series of rust changes in their own branch if the RFL project continues to be impeded by the maintainers. That's what Asahi linux (Linux on apple computers) is already doing (and poking at the android-mainline branch it looks like there are some rust additions that aren't in Linus's tree... but I'm not sure what the extent is).
They have,
https://www.redox-os.org/
https://tockos.org/
Also note that many of Rust 4 Linux contributors are Microsoft and Google employees that would like to upstream their changes, they already have plenty Rust on their own Linux derived systems.
Redox looks great. Device drivers should be in userspace, though I think that's far easier said than done with everything being on shared busses. A kernel cannot (safely) just simply check permissions for accessing a device and route the messages.
1 reply →
That's good to hear. Thanks.
> I have a question. Instead of fighting an uphill war in the Linux kernel community, why don't Rush developers just make a new kernel or fork their own?
Because their primary goal is to widen the community and reach of Rust, with "preventing memory error class bugs in the kernel" a secondary objective.
After all, the Rust additions, if properly designed, can be maintained in an out-of-tree fork that tracks the main Linux repo. If they did that, there'd be no one to block their patches but themselves, and yet they don't do that.
Rust is more about community than Linux is. Within the Rust community they make it very clear that it is vital that everyone goes the same way, while the Linux community has had, for decades, people each doing what they or their employer are interested in.
These two communities are not going to mix well, TBH. A community in which every member is a vocal prosyletiser isn't going to mix well with a community which prides itself on "Show Me The Code".
> After all, the Rust additions, if properly designed, can be maintained in an out-of-tree fork that tracks the main Linux repo. If they did that, there'd be no one to block their patches but themselves, and yet they don't do that.
Mainlining whenever possible is highly incentivized by technical and organizational aspects of linux[1], nothing about rust changes that. Obviously R4L introduces complexity and tradeoffs but I don't see why a rust kernel dev whose only goal was preventing bugs would do anything differently in this regard. Linux is a consensus project and opting out of the process of building consensus would mean not actually preventing any bugs.
[1] https://docs.kernel.org/process/1.Intro.html#the-importance-...
So they're ... a religion?
No idea what the particular bit of drama discussed here is about, but that's my impression of the Rust "community".
2 replies →
That sounds like a pretty dishonest interpretation of that effort.
I don't quite get the fuzz. A subsystem's maintainer's job is to maintain. If he cannot guarantee the maintenance of something, it's his/her job to say no
You are free to either take over maintenance of the Subsystem or do a fork
But throwing a tamper tantrum on social media is definitely the wrong way forward
LWN has a great impartial summary of what is occurring, including background on why the DMA subsystem is an important interface point for rust drivers: https://lwn.net/SubscriberLink/1006805/be4cb766fd906623/
(This is a shared link to a subscriber-only LWN article, please consider a paid subscription to LWN if you liked it!)
This isn’t impartial. Jonathan Corbet is naming and shaming, on behalf of one side.
> But Christoph Hellwig … turned this submission away with a message reading, in its entirety: "No rust code in kernel/dma, please" (despite the fact that the patch did not put any code in that directory)
> Already overworked kernel maintainers will have to find time to learn Rust well enough to manage it within their subsystems.
Frankly, this article feels like it’s steps away from social media brigading.
Journalists having an opinion in a news article, or even printing an opinion in an op-ed page, is not the same as—or even close to—social media brigading. It’s also a practice as old as the press itself. Brigading is about harassment and intimidation, not about possessing or publishing an opinion.
I came away with the opposite interpretation of yours.
The first quote of yours edited out the part where it says he does a lot of work in the DMA subsystem. It’s saying “someone who does a lot of work in the kernel turned the patch away”, which is absolutely true.
The second quote is understanding of the maintainers’ side, saying that they’re already overworked and now they’ll have to find time to learn rust on top of that. Not so much “I think these people ought to learn Rust”, but “accepting these patches means they will now have to learn rust”. This seems true to me? If anything it’s overly partial to the maintainer’s side, admitting that rust patches put more work on the old guard maintainers who are already overworked. It’s interesting that you feel this is too partial to the Rust side.
Zig will likely go through the same trials and tribulations that Rust has for introduction into the Linux kernel. Considering Zig's better C interopt, the fact that the Zig compiler can natively compile C, the Zig community's lack of zealotry and proselytizing that plagues the Rust community, etc., I believe it will be better received.
Damn, I liked watching the YT streams, above my head but yeah
Edit: I'm not super invested in the topic at hand I use all 3 OS's and only use Mac to develop with/for using MacOS
But kernel-level dev is hardcore and especially for open source, I've experienced that with the Pine64 devices which are almost worthless without the devs contributing to its software
I tried helping with the Linux kernel once, in 2001. I haven't since. I don't need abrasive people in my life.
It's fine to say no to a particular patch on technical grounds.
It's fine to say no to any other language but C in the Linux Kernel on a global basis.
What's not fine is caprice and depotism.
Either Rust is allowed, or it is not.
Stop wasting time.
And stop C-zealotry, it's as embarrassing as Rust zealotry, if not more so.
An interesting question: Who is the Linus Torvalds for Rust in the kernel? Who says no to slop?
Such a huge discussion and I can’t really understand the problem from reading the comments or some of the excerpts linked. Can anyone explain to me what is the real issue here?
Developer A wants to make a change. Developer B rejects it. Developer A makes a big fuss about it on social media. The creator of the project steps in and chastises Developer A for his behavior.
And as additional context, developer A has a history of causing drama on social media. So much that he even has his own page on KiwiFarms.
Also, developer B publicly stated that he will do everything he can to prevent changes written in language 2 from getting merged regardless of technical merit.
Incredibly biased summary there
1 reply →
silly hector, everyone knows that bullying, screaming at people in public and insulting them online is a privilege of long-term maintainers who can do no wrong
Linus has to have one of the most stressful and difficult jobs available.¹
The Linux kernel is part of so many different things, projects, products, companies, etc. A change can really duck things up.
Being conservative, and slow, in adopting new things is good for the main line.
You have idealistic developers who have seen a way to do something better, that is great. I know the feeling.
I have never done anything with the Linux kernel, but I have worked on some large legacy codebases. and it is to come in, look around, and just go "Gosh, this here is just slow, I'll just fix this". and it will be a good solution right there, but it might be suboptimal overall.
Chances are really good that you dont understand the entire picture when you "fix something", and someone who does, may not like the change. and even if the technical solution is clearly better from one angle.
I am glad I will never be involved in blessing or passing on 1.000.000 different changes being proposed as improvements to Linux every week.
I wish Linus Torvalds to have long life and powers to keep his down-to-earth approach as long as it is possible. I wish his era was never replaced.
I haven’t read the entire thread but based on the except I did, while I won’t claim that Hector isn’t entirely in the right there’s also major longstanding issues with the process that the kernel devs seem to refuse to do anything about.
It seems like big enough of a sticking point that if a forked alternative with a less insular contribution model appeared, it could gain enough steam to keep itself afloat. All it’d take is for someone with deep enough pockets to fund a few founding engineers to be the subject of this kind of frustration.
I hope they fork Linux. A safer kernel and modern faster development practices would be excellent for the entire ecosystem
Absolutely! If Rust and the modern development practices are truly so much better (I doubt this, but I am old and could be wrong), then why not show this by creating better kernels and other projects!
Exactly. And I feel the same as you do: the Rust community can put it’s money where it’s mouth is and if nobody wants safe Linux or they can’t make it happen, then fine they can be happy to lose.
Not an especially significant event, by the numbers. It's a large community so there are tails.
By the time Rust is welcome in the Linux kernel, projects like Redox will be full fledged competitors. I'd bet Hector would be welcomed there.
https://www.redox-os.org
It's taken Wayland 16 years to become a serious alternative to X11. You think a whole kernel can do it faster?
Well, with AGI...
Can't be many years until we can take the first ever version of Linux kernel, ask an LLM to port it to Rust, spin it up in QEMU and re-prompt until it works, then feed in every patch set and ask the LLM to add these changes to the Rust version, ... repeat for 30 years of patches until the full kernel is rewritten in Rust.
because that's what the world needs, an obscure half assed implementation of unix? why not innovate and come up with a new paradigm instead. No one is asking for this.
It sounds like you don’t know anything about Redox.
1 reply →
Good reminder to take a look at FreeBSD
in my mind Swift is a much better language to include than rust, unfortunately the support for Swift on Linux is so bad currently that it's not worth exploring.
If ever integrated Swift might change the whole paradigm
This really makes me want to learn rust and contribute to Redox.
Do it.
“How did you hurt yourself today?” - “I threatened Linux devs with social media shaming and publicly quit contributing to Linux to teach them a lesson. But it boomeranged, and now everyone is talking about my behavior”
How dare he be tired of using emails for reviews. Or manual formatting his work.
Let him fork!
Jokes aside: I hope he forks and establishes a CoC and if what he does is more effective we will all benefit by it.
Good reminder to look at FreeBSD
Not wanting 2 languages is ridiculous. Only one of them is actually safe. Whatever Linus thinks, empowering someone to say “no” to “two languages” is pretty idiotic; if someone did that to me, I wouldn’t go to social media to bitch about it, but I can sure as heck sympathize with the sentiment.
Whoever owns DMA or whatever and rejected rust out of hand like this should frankly be _forced_ to resign. This is truly arrogant and egotistical behavior, almost certainly contingent upon FUD and insecurity and laziness about not just learning Rust.
Good grief, last time I feel excited about submitting a kernel patch; what a ridiculous situation.
Have to side with the one language argument here.
It's hard enough to get a single programming language to work right. C is old and stable.
Rust is new and mostly stable, mostly stable isn't going to cut it when billions upon billions of devices depend on your work.
At the same time this type of ego driven drama keeps me out of the open source community. I have enough people telling me how to code during my 9-5.
I open source most of my projects, but it's not a collaboration. I'll even admit, I get really annoyed when someone puts in a PR that's literally just a bunch of spacing changes in a readme. I think there was some influencer who was claiming that you should go through GitHub, and submit as many changes for things like grammar as possible to a bunch of different projects .
And then on your resume you can put that you contribute it to all these projects. Not fun.
I don't agree with this anymore tbh. But for a project as large, mature, and widely worked on as the Linux Kernel, I absolutely agree.
I think it's a noble goal worth working towards, but Marcan's smug as hell "ill merge and y'all will fix all your broken shit" attitude predictably backfired
Consider using Codeberg for personal projects and reserve GitHub to just collaborative contributions. Codeberg lets you disable pull requests and other unwanted features that GitHub forces down your throat.
Everybody hates spam and abuse, I don't think it supports your claim that much. This is definitely not what anybody thinks of as "collaboration".
In any big project your going to have disagreements.
I need to get paid to deal with stuff like that. No one is going to tell me how to write code without writing me a check.
Even at work I have my limits, although now that I'm older I'm much more inclined to just go with the flow. But if I'm not getting paid what's the point.
I do enjoy game jams though. We only need to work together for a weekend. Plus at least in my circle we only care if the code works.
fwiw, i always make my first PR to an open source as simple / uncomplicated as possible. Something like a spelling or grammar fix in documentation. It's a litmus test for how much drama I will need to face on the more complicated code issues to follow. When the project owners ignore or reject simple stuff, I generally wander off somewhere else.
Not to mention Rust tooling is painfully slow compared to C, last I checked. I wouldn’t want to switch unless that problem went away somehow.
[dead]
[dead]
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
So I heard some rumors about US policy affecting Rust. That Rust formely got money from USAID, and also the thing about the US government should promote memory safety (or smth like that?) was removed.
Could that be relevant to this story, or is that a complete sidetrack?
Edit: Asking because the timing is curious.
This has absolutely nothing to do with the US government. This current drama started before January 20th.
Rust has never as far as I'm aware or can tell via google recieved money from USAID. Though amusingly there has been money invested by USAID to combat it's namesake - a category of fungus - from destroying coffee plants.
What you're probably thinking of with regards to the US government is that the Trump administration has been deleting all sorts of websites and guidance, and one of the things deleted was a report by the White House Office of the National Cyber Director calling on developers to use memory safe languages [0]. Various other similar documents (e.g. randomly picked via google [1]) still exist and it's unlikely that this document was deleted because of its contents and not because the white house was just destroying the entire category of things related to the ONCD - even the landing page 404s [2].
That report was just a "this is a good idea", I don't believe it ever came with any funding or support.
It wouldn't surprise me if other similar things were deleted too, that's just the one I saw hit the news, so I'm guessing that's the news you saw.
[0] https://bidenwhitehouse.archives.gov/wp-content/uploads/2024...
[1] https://media.defense.gov/2023/Apr/27/2003210083/-1/-1/0/CSI...
[2] https://www.whitehouse.gov/oncd/ - Link from https://en.wikipedia.org/wiki/Office_of_the_National_Cyber_D...
[flagged]
Frankly I immediately knew incidents like these would increase when it was added.
Not possible to have rust without the "" community"", it seems.
Obvious from the start for anyone paying attention, take a look at the founder.
[flagged]
You're missing context. Linux Rust devs themselves were unhappy with Hector's flaming "on their behalf".
again, as a user, I don't care. I use linux & visiting HN because of tech, not because of any politics.
Martin's patch should not be delayed or rejected because of the rust language, it is an approved language. If some maintainer has issue with such rust language approval, they should address that particular issue not patches using that language. They can also choose to resign.
1 reply →
always knew rust was good for nothing... now look what it did. the language itswlf is in conflict with itself and anything it touches in a serious way reflect that silly state
I agree with Hector Martin here. The mailing list format is putting off so many developers. Linux needs to modernize.
Rust has probably the most toxic people in open source software.
I would encourage it in the Kernel. Maybe even go as far as porting large portions to Rust.
Linus should have already accepted the C++ patch instead of these Rust dramas.
We have plenty of drama on C++ community as well, rest assured.
1. I do believe that Rust type system needs to be reworked, so all the drama around it is needlessly bloated. We have RustBelt, RustHornBelt and myriads ways of converting HIR/THIR/MIR to CoQ, for better or worse, but no MLIR support for rust codegen whatsoever. Rust is temporary, we'll get a simpler and better Lang further down the road.
2. The upstream fight had always followed the Cash Flow. If you have so called "problems" you either act yourself, or let other people do something about it, the way it won't result in more long-term issues. Deliberate Detraction IS a Sign of Corruption and Abuse of Power.
3. An ambiguous Point of Conflict may not be Conflict at all, but just an outcome of the Lack of Proper Communication and Transparency. Detraction is Accountable, social dynamics and social incline with explicit or implicit motives is Accountable as well. The lack of Effective Code of Conduct, and absence of Proper Punitive Action, for everyone, will cause Authoritarianism (or just Genocide of Engineering Thought).
I do feel bad about the state of Linux Kernel development, but we'll have either to move on, and learn from This Mistake, or do something about it.
I get this impression that the Rust people think they are a stage where Rust is a viral phenom but it's really not. Nevertheless, they are behaving like its viral and trying to force it down everybody's throats, even though I never heard of some software package or system that was built natively in rust that truly went viral. The other day I tried to install a python package and - big surprise - it REQUIRED me to install a rust toolchain to install the python package! Well, that package went straight into the dumpster (i'm on WSL which DOES NOT have a rust toolchain)!
This "we're viral" behavior when "it's really not" is very childish.
Was this comment written by an 80 year old who’s watched a Fox News segment on Rust? It definitely reads like that.
wsl ‘DOES’ have a rust toolchain, nobody is saying rust is going viral (what on earth…), you tried to install the python packages’ sdist rather than the wheel.
Get it together.
Not wanting a huge dependency tree is something understandable by any seasoned developer.
Was your comment wrote by a junior javascript developer?
1 reply →
Where are you seeing these "we're viral" statements?
If you're using WSL, then you can just run the linux rustup installer to have a linux version of the toolchain installed.
> (i'm on WSL which DOES NOT have a rust toolchain)!
This is plainly false.
People do love their drama don't they 8-)
Regarding the point of "community" being difficult to manage in "open source" projects, I would argue managing a large group of developers on any project is difficult and full of drama.
I'm personally not an advocate of the "open source" obfuscation term myself, but the public license of the linux kernel has little to do with the drama.
Maybe the fact that linux developers have some kind of say at all, as opposed to some proprietary dev projects where every decision is handled by fiat (and Linus has certainly served this role at times), causes it to have more drama.
But no matter what model is followed, people do love their drama, and a large dev group is a social activity regardless of the licensing of the software itself.
Its like every social issue ever: the thing all participants have in common is that they are all humans...