Asahi Linux lead developer Hector Martin resigns from Linux kernel(lkml.org)
lkml.org
Asahi Linux lead developer Hector Martin resigns from Linux kernel
https://lkml.org/lkml/2025/2/7/9
1,083 comments
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.
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.
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?
They took down all of https://www.whitehouse.gov/oncd/, what makes you think they gave any thought to this paper in particular?
Thanks for explaining what rust had to do with apple hardware drivers.
Martin has worked hard on Asahi, but comes of as looking for drama and virtue signalling oftentimes. I'd give this to Linus.
>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.
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.
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.
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.
I hate to mention this but closed source appears to involve humans too. I was disappointed when I discovered this as well.
"People are a problem" - Douglas Adams
FOSS devs put a lot of time in what they do and they are understandably attached to whether what they do is good/successful, at least in the same proportion the general population is (but arguably more due to how much dedication goes into FOSS, kind of by construction)
> Maybe closed source is better.
At least in some cases this is plausible. The money people get for working on closed source software irons out some issues, for example:
Some people who voluntarily work on open source code do it for self-actualization, which indicates that they have a strong desire to push their wishes through. This implies that a lot of drama gets involved if these people don't get their way.
At least in some cases this is plausible. The money people get for working on closed source software irons out some issues, for example:
Some people who voluntarily work on open source code do it for self-actualization, which indicates that they have a strong desire to push their wishes through. This implies that a lot of drama gets involved if these people don't get their way.
> Seeing what it has become though...
Was it ever different? Not as far as I can remember at least. I think one of the main strengths of open source development is that it works despite the drama.
With open source projects, everybody is free to start their own fork over disagreements, and if the fork actually turns out to be objectively better it will replace the original project.
> Maybe closed source is better.
It's the same and worse over there, the drama just isn't public.
Was it ever different? Not as far as I can remember at least. I think one of the main strengths of open source development is that it works despite the drama.
With open source projects, everybody is free to start their own fork over disagreements, and if the fork actually turns out to be objectively better it will replace the original project.
> Maybe closed source is better.
It's the same and worse over there, the drama just isn't public.
> It's the same and worse over there, the drama just isn't public.
At least you’re getting paid. What’s the point of spending one’s free time arguing with strangers on the internet over some code that will be refactored anyway ten years from now..? Life is short, have fun, enjoy it. If you’re spending time or money on something that sucks, walk away.
At least you’re getting paid. What’s the point of spending one’s free time arguing with strangers on the internet over some code that will be refactored anyway ten years from now..? Life is short, have fun, enjoy it. If you’re spending time or money on something that sucks, walk away.
This is much less likely in a company. Any sane company decides on a clear direction which way to go. Either do X and put resources in it, or not and instead focus on something else. They may change directions, but never "maybe X" at a specific point in time. Someone at the company makes a decision on this.
Of course, with notable exceptions. See Apple Car, Android tablets etc.
Of course, with notable exceptions. See Apple Car, Android tablets etc.
> Seeing what it has become though… Maybe closed source is better.
You thought it was better in the past? Read up on the great ncurses maintainer drama. Or the NetBSD/OpenBSD split. Or FreeBSD/DragonflyBSD split. Or the Emacs forks, GNU libc forks, GCC fork, etc. etc. etc.
This kind of drama has always existed. Difficult people have always existed. And even good people have always been struggling with their emotions.
And in all my closed-source $dayjobs I've had to deal with all of that too. Sometimes significantly worse than I'm seeing here.
You thought it was better in the past? Read up on the great ncurses maintainer drama. Or the NetBSD/OpenBSD split. Or FreeBSD/DragonflyBSD split. Or the Emacs forks, GNU libc forks, GCC fork, etc. etc. etc.
This kind of drama has always existed. Difficult people have always existed. And even good people have always been struggling with their emotions.
And in all my closed-source $dayjobs I've had to deal with all of that too. Sometimes significantly worse than I'm seeing here.
> "Maybe closed source is better."
I assure you it isn't; it really, really isn't. You don't see the drama because 1) it's behind closed doors and 2) because the people involved know their job is at risk if they cross the line.
I assure you it isn't; it really, really isn't. You don't see the drama because 1) it's behind closed doors and 2) because the people involved know their job is at risk if they cross the line.
> Maybe closed source is better.
I've had similar pissing matches in closed source development, instigated by me and not...
Often, these things get resolved or left simmering without any public visibility, so that's nice as a user. And there's usually a somewhat clear heirarchy of authority, where the boss can say I don't care who's right, do X; which resolves issues in ways that sometimes a technically minded open source project can't; that can often help with bikeshedding between usable options.
But sometimes you just keep working somewhere because deep in your heart of hearts you want to do it your way, and once that other person quits or maybe even goes on vacation, you can. And sometimes people endeavor to actively push that person out, which I guess I've seen on FOSS drama too, but office politics have a way of lurking under the surface more, IMHO.
I've had similar pissing matches in closed source development, instigated by me and not...
Often, these things get resolved or left simmering without any public visibility, so that's nice as a user. And there's usually a somewhat clear heirarchy of authority, where the boss can say I don't care who's right, do X; which resolves issues in ways that sometimes a technically minded open source project can't; that can often help with bikeshedding between usable options.
But sometimes you just keep working somewhere because deep in your heart of hearts you want to do it your way, and once that other person quits or maybe even goes on vacation, you can. And sometimes people endeavor to actively push that person out, which I guess I've seen on FOSS drama too, but office politics have a way of lurking under the surface more, IMHO.
It's called systemd, all lowercase, no punctuation :)
"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.
Hell no. FOSS communities, as other spaces created by permanently online individuals, definitely have higher-than-average number of mentally unhinged snowflakes.
>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.
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.
ubermonkey(2)
bakugo(2)
> 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.
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.
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.
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.
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.
I've conversed with marcan a few times (on completely unrelated and inconsequential things). As far as I know he's a decent man.
That said, I'm going to agree with Linus there: Cancel culture ("social media brigading") isn't the solution.
That said, I'm going to agree with Linus there: Cancel culture ("social media brigading") isn't the solution.
Indeed, but where is the 'real' solution? If no-one higher up is going to step in and merge the patches despite the blocking maintainer, how is "the process" going to move R4L forward?
(Edit: Ok, reading some other context, it seems like this is indeed what's happening, which does make this reaction a little less justified. I can certainly see why it's no fun to have people in the project saying they will do whatever they can to stop an initiative, but if they aren't actually able to block it, then it doesn't seem worth quitting over)
(Edit: Ok, reading some other context, it seems like this is indeed what's happening, which does make this reaction a little less justified. I can certainly see why it's no fun to have people in the project saying they will do whatever they can to stop an initiative, but if they aren't actually able to block it, then it doesn't seem worth quitting over)
They can merge regardless. The maintainer nacked something they don't even own, they were asked for a review as a courtesy as it wraps their subsystem.
That said there's an outstanding question about whether Linus would accept something that breaks Rust builds for merge. Linus hasn't commented on this yet, but I'm sure he will.
That said there's an outstanding question about whether Linus would accept something that breaks Rust builds for merge. Linus hasn't commented on this yet, but I'm sure he will.
Sometimes there's no win-win-win solution.
I think people who write C should stop unless it's to fix security bugs and should do something else, anything else, maybe even learn about programming. But even with this mindset Linux is a C project and the R4L folks promised to thread the needle, if it cannot be done this time, then it cannot be done this time. They need to wait.
I think people who write C should stop unless it's to fix security bugs and should do something else, anything else, maybe even learn about programming. But even with this mindset Linux is a C project and the R4L folks promised to thread the needle, if it cannot be done this time, then it cannot be done this time. They need to wait.
> "I think people who write C should stop unless it's to fix security bugs and should do something else"
That's pretty harsh. C has provided so much value to the world and security isn't the most important thing in the world - functionality is. Not saying security isn't important overall though.
And also, imagine another Rust competitor comes up in 5 years called "Moose" and M4L comes up, competing with R4L?
That's pretty harsh. C has provided so much value to the world and security isn't the most important thing in the world - functionality is. Not saying security isn't important overall though.
And also, imagine another Rust competitor comes up in 5 years called "Moose" and M4L comes up, competing with R4L?
Of course, internal combustion engine motorcycles too, but I hate the aggressively noisy noxious little shits whizzing around my code, I mean, me. :)
... but I'm aware that it's simply not realistic. These are raw thoughts not "working policy" . My problem is that old software is just barely functional (huurah, we achieved the barely standing equivalency from civil engineering) and we are not spending enough resources on that, nor on security.
And probably my Linux honeymoon period ended after ~10-20 years of work (and/or personal) use, and I feel every point of Marcan's letter, even though I never did kernel development, only the usual troubleshooting and trying to figure out which bug/patch/feature has what status.
But, of course, as long as this blessed circus continues to deliver every ~3 months a new version with this velocity it'll keep going. And Linus is right, if we don't like it maybe (:p) it's on us to accept that. And also maybe Drew's humble suggestion will be the prescient one.
https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-...
If Moose is better I expect people to fairly consider it, and when the consensus forms that yes it's at least as good as C then I want the C people to realize their own responsibility in maintaining critical infrastructure, and I want them to at least have a plan on how to improve, because even in civil engineering the baseline for "barely" has increased a lot over the past decades. (And of course in many cases arguably society has overshoot that, for example with the 2-stairs requirements and so on, where these concerns drastically disincentivize evolution of population centers and transportation networks.)
... but I'm aware that it's simply not realistic. These are raw thoughts not "working policy" . My problem is that old software is just barely functional (huurah, we achieved the barely standing equivalency from civil engineering) and we are not spending enough resources on that, nor on security.
And probably my Linux honeymoon period ended after ~10-20 years of work (and/or personal) use, and I feel every point of Marcan's letter, even though I never did kernel development, only the usual troubleshooting and trying to figure out which bug/patch/feature has what status.
But, of course, as long as this blessed circus continues to deliver every ~3 months a new version with this velocity it'll keep going. And Linus is right, if we don't like it maybe (:p) it's on us to accept that. And also maybe Drew's humble suggestion will be the prescient one.
https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-...
If Moose is better I expect people to fairly consider it, and when the consensus forms that yes it's at least as good as C then I want the C people to realize their own responsibility in maintaining critical infrastructure, and I want them to at least have a plan on how to improve, because even in civil engineering the baseline for "barely" has increased a lot over the past decades. (And of course in many cases arguably society has overshoot that, for example with the 2-stairs requirements and so on, where these concerns drastically disincentivize evolution of population centers and transportation networks.)
Given the choice between a Linux compatible OS made in Rust and R4L I would absolutely hope sanity prevails and the latter is chosen. It's just going to take them forever to get the optimizations right, then people will still prefer Linux since that's going to be the "server OS" standard for a very long time.
Ideally there's room for both. I'd argue for many many things stability/security is more important than performance.
[deleted]
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.
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.
> 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.
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.
The kernel is doing fine today, but I don't think that's sustainable. The average age of the maintainers seems to be rising, and plenty of skilled people completely avoid kernel development explicitly because of the hostility and, frankly, assholish behavior that comes from the folks on these mailing lists.
Eventually a lot of these people are going to age out, retire, or otherwise move on. I do think there will be a crisis moment at some point in the future.
Eventually a lot of these people are going to age out, retire, or otherwise move on. I do think there will be a crisis moment at some point in the future.
ta8645(1)
how forkable is the whole thing? I mean, it is several decades of code but...
It's not.
What?! Almost every major server and desktop Linux distribution ships a kernel full of patches, which are absolutely forks. That’s before we start getting into the crazy town of the embedded world. Clearly the software can be forked. The question is whether the community can - and that is yet to be seen.
All those "forks" are dependent on regularly rebasing their patch sets on top of mainline (or they never get updated and lose what semblance of support they had once the SoC they were made for reaches EoL), so they're pretty much irrelevant to this conversation. We have seen no indication that it's feasible for anyone to hard-fork the kernel and continue development in a way that's independent from what we today call "mainline".
its totally forkable. in fact its totally possible to write a 99% workalike.
the issue here is whether or not the broader community would ever seriously consider using an alternative, and whether contributors, particular commercial ones writing drivers for products, would ever agree to maintain two versions.
the issue here is whether or not the broader community would ever seriously consider using an alternative, and whether contributors, particular commercial ones writing drivers for products, would ever agree to maintain two versions.
Also it's, y'know, written in C.
I used to know C. It was my first language, and I spent a fair bit of time in it, but that was before compilers started to treat undefined behaviour as an excuse to break reality.
Arguably I'm not smart enough, or disciplined enough, to write C. This may be the case, and therefore I have naturally focused on other languages. Rust, to no-one's surprise, is my current favorite. I've never contributed to the kernel — for more reasons than just the language — but the language would be reason enough on its own.
C programmers are getting rare...
I used to know C. It was my first language, and I spent a fair bit of time in it, but that was before compilers started to treat undefined behaviour as an excuse to break reality.
Arguably I'm not smart enough, or disciplined enough, to write C. This may be the case, and therefore I have naturally focused on other languages. Rust, to no-one's surprise, is my current favorite. I've never contributed to the kernel — for more reasons than just the language — but the language would be reason enough on its own.
C programmers are getting rare...
Why are you projecting your own feelings onto others?
There’s plenty of people who write C, there’s plenty of newcomers who start writing C and if they’re willing to, they can find guidance, mentoring, and tooling to improve their skills. If that’s not the path you want to pursue, that’s fine. But C isn’t going anywhere soon and if you go to any university/college, there’s lots of C being taught and lots of people eager to learn.
There’s plenty of people who write C, there’s plenty of newcomers who start writing C and if they’re willing to, they can find guidance, mentoring, and tooling to improve their skills. If that’s not the path you want to pursue, that’s fine. But C isn’t going anywhere soon and if you go to any university/college, there’s lots of C being taught and lots of people eager to learn.
they don't avoid it cause the hostility , they avoid it case we live in this high level era , where nobody knows where code runs or how it runs.
> The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things.
Both sides of the argument are kernel developers here, though.
Both sides of the argument are kernel developers here, though.
Well, one side just quit.
And that particular side was told by Linus Torvalds himself that his way of Social Media brigading is inappropriate for kernel development, and that the current process works.
I choose to believe Linus. His work on and guidance of the kernel used to and still does work pretty great.
And that particular side was told by Linus Torvalds himself that his way of Social Media brigading is inappropriate for kernel development, and that the current process works.
I choose to believe Linus. His work on and guidance of the kernel used to and still does work pretty great.
The person who quit was not the author of the patch, or a member of Rust for Linux.
So they stirred a whole lot of drama for not much, potentially harming R4L.
I am not willing to pass a value judgement on his decision to do this, but I do agree that I don't think it ended up being helpful to R4L.
The person who quit wrote the Linux graphics driver for Apple M-series GPUs in Rust.
edit: I may have gotten some things confused, please see below
edit: I may have gotten some things confused, please see below
No. The person who quit upstream kernel work is Marcan, the head of the Asahi Linux project. The person who developed the kernel driver for M-series GPUs is Lina.
platybubsy(1)
Not sure why my comment was flagged, but marcan is Asahi Lina. There is demonstrable proof in threads all over this comment section.
No, the entirety of the Rust for Linux kernel development community didn't just quit. One guy quit. There are plenty of other kernel developers who are trying to push Rust 4 Linux forwards and make it viable for more kinds of drivers.
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.
I don't think that's true. I have seen R4L folks reiterate time and again that C changes are allowed to break Rust code, and they will be the ones to fix it.
A C only kernel build without CONFIG_RUST will not build a single line of Rust code nor will it touch anything in the rust subdirectory. If you don’t want to deal with rust, you don’t have to at all.
It’s a little bit more nuanced than this. Your parent commenter is wrong, by the way.
Suppose you want Rust, just not a single Rust driver using PCI. But CONFIG_PCI and CONFIG_RUST both selected will cause the PCI abstractions to get built anyway, even if not a single driver using them is selected. Then if the PCI subsystem introduces a change but the Rust counterpart fails to follow it fast enough, the build will break for the kernel as a whole.
This was illustrated with an example in that email thread.
I have some sad experience with polyglot projects. Unless you enjoy pain and drudgery, it’s an extremely unrewarding thing requiring very careful treading.
Suppose you want Rust, just not a single Rust driver using PCI. But CONFIG_PCI and CONFIG_RUST both selected will cause the PCI abstractions to get built anyway, even if not a single driver using them is selected. Then if the PCI subsystem introduces a change but the Rust counterpart fails to follow it fast enough, the build will break for the kernel as a whole.
This was illustrated with an example in that email thread.
I have some sad experience with polyglot projects. Unless you enjoy pain and drudgery, it’s an extremely unrewarding thing requiring very careful treading.
> 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.
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.
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.
About the Rust code itself; the primary issue was code duplication rather than preventing the use of Rust altogether. Since the suggested code is not merged, every driver needs to write the same code over and over again. That was also something that the maintainer suggested himself (?). There is of course a big downside, but I am not sure if this justifies all the hate.
"The 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/[email protected]/
That doesn't sound like he's only talking about in his area to me
That doesn't sound like he's only talking about in his area to me
is this just weird religious adherence to the belief that a multi-language codebase will be harder to maintain? what's the rationale, exactly?
Maintainers come and go, languages come and go. C will never go away and everyone working on kernels knows C, so there's a certain labour pool and skillset that will always be available that doesn't necessarily apply to Rust. That's even setting aside any technical issues, like bugs creeping up in the language interoperability layer, which obviously doesn't really happen if you're only using one compiler.
I think both arguments have credibility.
The R4L says they will make sure the Rust code is fixed when the C code is, and that's admirable, but the concern it means a developer now has to wait for that, holding up their work for release/submission. The bus factor is now on the R4L team.
Meanwhile, everyone involved in development for Linux already knows C.
The R4L says they will make sure the Rust code is fixed when the C code is, and that's admirable, but the concern it means a developer now has to wait for that, holding up their work for release/submission. The bus factor is now on the R4L team.
Meanwhile, everyone involved in development for Linux already knows C.
> the concern it means a developer now has to wait for that, holding up their work for release/submission.
They do not have to wait.
They do not have to wait.
That's apparently still unclear according to the LKML.
The linux kernel project specifically cares about the labor pool of maintainers.
My assumption is that it's easier to train someone on rust then to train someone to be a kernel subsystem maintainer
My assumption is that it's easier to train someone on rust then to train someone to be a kernel subsystem maintainer
I'm just parsing the thread but it seems that changes to the C api can break the Rust bindings.
This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up.
For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believes it is unfair to force every C maintainer to learn enough Rust to keep their integration points working.
For the second solution, the C maintainer is pointing out that Linus has a history of refusing to merge C patches that break Rust builds. So even though the Rust advocates promise they will handle all of the Rust stuff and they are OK with their stuff being broken after C changes until they get around to fixing it, Linus doesn't seem to actually allow for this in practice.
I can see the maintainers point. Sooner or later Rust bindings on critical systems will be essential and changes to the C code will be gated on changes to the Rust code. It is a fantasy of the Rust maintainers that they will have to shoulder that entire burden. But even if they did, it would give them some pretty hefty leverage over the C maintainers in those essential cases. And it also introduces a requirement that someone with enough Rust and subsystem knowledge is even available for the job. People making promises today may disappear tomorrow, leaving the maintainer with an essential binding to a language he doesn't want to support.
edit: as has been said elsewhere, Linus could make some of this go away by committing to let the Rust builds break. I don't know if that could be done in a way that wouldn't be a de facto fork.
This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up.
For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believes it is unfair to force every C maintainer to learn enough Rust to keep their integration points working.
For the second solution, the C maintainer is pointing out that Linus has a history of refusing to merge C patches that break Rust builds. So even though the Rust advocates promise they will handle all of the Rust stuff and they are OK with their stuff being broken after C changes until they get around to fixing it, Linus doesn't seem to actually allow for this in practice.
I can see the maintainers point. Sooner or later Rust bindings on critical systems will be essential and changes to the C code will be gated on changes to the Rust code. It is a fantasy of the Rust maintainers that they will have to shoulder that entire burden. But even if they did, it would give them some pretty hefty leverage over the C maintainers in those essential cases. And it also introduces a requirement that someone with enough Rust and subsystem knowledge is even available for the job. People making promises today may disappear tomorrow, leaving the maintainer with an essential binding to a language he doesn't want to support.
edit: as has been said elsewhere, Linus could make some of this go away by committing to let the Rust builds break. I don't know if that could be done in a way that wouldn't be a de facto fork.
No, the point is nonsense. Rust is a consumer of the APIs just like every other driver / subsystem is. Any change to the C APIs would likely require collaboration with those other maintainers no different than Rust. And CH would be immediately shut down if he tried to roadblock some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".
I think you are using inflammatory language by calling the point nonsense.
As an outside observer, literally no skin in this game, I can see his point. If his C code changes breaks other C code then he is at an advantage compared to if his C code breaks a Rust binding or Rust drivers. The degree to which this adds to his burden of maintenance is up to him to decide.
As an outside observer, literally no skin in this game, I can see his point. If his C code changes breaks other C code then he is at an advantage compared to if his C code breaks a Rust binding or Rust drivers. The degree to which this adds to his burden of maintenance is up to him to decide.
The kernel is extremely complex. He very likely still needs to work with other maintainers if his code breaks their code. In this case he has LESS work to do, because the R4L developers own all fixes to Rust code, and he is free to break them, and they have to clean it up themselves.
The complexity of kernel isn't relevant, unless your point is that the kernel is already so complex that maintainers shouldn't advocate against new and significant complexity?
As for less work, that is alternative two from my original post which states the maintainer now has to wait for someone else to do the work or risk his change being stalled (worse case: indefinitely). It doesn't matter if the R4L team promises that they are OK with broken Rust code since the only person whose decision matters is Linus. Until Linus clarifies his stance on broken Rust builds the promises of the R4L team are promises that they are literally incapable of delivering on.
As for less work, that is alternative two from my original post which states the maintainer now has to wait for someone else to do the work or risk his change being stalled (worse case: indefinitely). It doesn't matter if the R4L team promises that they are OK with broken Rust code since the only person whose decision matters is Linus. Until Linus clarifies his stance on broken Rust builds the promises of the R4L team are promises that they are literally incapable of delivering on.
It's nonsense because if his C code breaks the Rust binding or drivers, that is not his problem. It adds zero maintenance for him.
But it does. He has to notify R4L of what his changes were and how it broke the Rust driver. Even if he didn’t, he will still be contacted for information regarding these things.
How is that different from any C driver currently in existence? Notifying API consumers of what is changing and how and answering the occasional is absolute table stakes for any software developer and throwing a tantrum about that is incredibly juvenile.
He does not have to notify them.
> he will still be contacted for information regarding these things.
Just like any other user, and he is free to ignore them just like any other person doing so.
> he will still be contacted for information regarding these things.
Just like any other user, and he is free to ignore them just like any other person doing so.
How is that literally any different from C code?
There’s 2 kinds of scenarios here:
- Rust code involved: C code change breaks Rust. ~Send~ ~an~ ~email~ ~and~ move on.
- C code involved: inform other C devs, either work with them or wait for them to fix.
The way I see it, either way, the “Rust stuff adds unacceptable amounts of workload” doesn’t really check out.
Edit: turns out he doesn’t even need to inform the Rust devs.
There’s 2 kinds of scenarios here:
- Rust code involved: C code change breaks Rust. ~Send~ ~an~ ~email~ ~and~ move on.
- C code involved: inform other C devs, either work with them or wait for them to fix.
The way I see it, either way, the “Rust stuff adds unacceptable amounts of workload” doesn’t really check out.
Edit: turns out he doesn’t even need to inform the Rust devs.
> some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".
This isn’t blocking any drivers. Just adds duplicate code.
This isn’t blocking any drivers. Just adds duplicate code.
Thanks.
> Linus could make some of this go away by committing to let the Rust builds break.
Linus already did that. This is the state of things today. C code is allowed to break the Rust, and it's the Rust for Linux people's responsibility to get it working again, not the C folks.
Linus already did that. This is the state of things today. C code is allowed to break the Rust, and it's the Rust for Linux people's responsibility to get it working again, not the C folks.
I'm just an interloper and only going on the linked thread, but there are specific patches that missed merge windows due to Rust build breaks. The patches referenced are claimed to be exceptions but I can understand the fear. Linus is saying one thing but making exceptions in some cases. As Rust becomes more and more integrated into core Linux systems those exceptions may become more frequent and may eventually become the rule.
To be fair, I think another valid solution to this problem is just to bite the bullet and tell the grumpy C developers to deal with it. At some point the fallout from an exodus of grey beard Linux maintainers will actually be less than fighting this battle. As many point out, they are going to exit the project one way or another eventually.
To be fair, I think another valid solution to this problem is just to bite the bullet and tell the grumpy C developers to deal with it. At some point the fallout from an exodus of grey beard Linux maintainers will actually be less than fighting this battle. As many point out, they are going to exit the project one way or another eventually.
> The patches referenced are claimed to be exceptions
From what I understand, this is correct, or at least that is, this was a build system bug that caused accidental breakage, not a deliberate change in the policy that the kernel must be able to be built with Rust support turned off, and that that is the build that matters. Exceptional in a "rarely happens" sense and not a "deliberate choice to create an exception to a rule" sense.
From what I understand, this is correct, or at least that is, this was a build system bug that caused accidental breakage, not a deliberate change in the policy that the kernel must be able to be built with Rust support turned off, and that that is the build that matters. Exceptional in a "rarely happens" sense and not a "deliberate choice to create an exception to a rule" sense.
This entirely depends on the supposition that there are more new kernel developers who want to, and are able to, use Rust then C.
I don't think this is proven: what we have is a specific group of Rust developers, but they are there by virtue of that group existing. There are numerous more kernel contributors today who work in C, and since the greybeards are happy to keep up the work it's not like anyone else is going to easily step in to replace them (since it would be a coup not a handover, if they didn't actually want to step down).
An equally plausible future is some such Rust mandate happens, you drive off the existing C developers, then it turns out the Rust developers aren't actually numerous enough or committed enough (or even good enough at long term project social management) to keep the project going and it dies (or forks into CLinux or something).
Linux itself was a "hobby project" which ultimately succeeded because it did the work which needed to be done, while everyone else was still completely sure the microkernels were the way of the future.
I don't think this is proven: what we have is a specific group of Rust developers, but they are there by virtue of that group existing. There are numerous more kernel contributors today who work in C, and since the greybeards are happy to keep up the work it's not like anyone else is going to easily step in to replace them (since it would be a coup not a handover, if they didn't actually want to step down).
An equally plausible future is some such Rust mandate happens, you drive off the existing C developers, then it turns out the Rust developers aren't actually numerous enough or committed enough (or even good enough at long term project social management) to keep the project going and it dies (or forks into CLinux or something).
Linux itself was a "hobby project" which ultimately succeeded because it did the work which needed to be done, while everyone else was still completely sure the microkernels were the way of the future.
It’s adherence dictated by lived experience, if anything.
Much like the “don’t rewrite from scratch” mantra was written in blood and tears.
Much like the “don’t rewrite from scratch” mantra was written in blood and tears.
It's just in his area where he has the power to say no, and it's important enough to be a big impediment to the whole project.
[deleted]
>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 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.
If that is true, why he was the one that was asked to review/ or why his opinion even matters here? The must be some sort of correlation to his code or this does not make sense at all..
He wasn't asked, he was CC'd on the patchset because it wraps his subsystem. If he was interested in doing a driveby review in good faith, or taking interest in what was going on, then he could have done so.
The issue is it creates a downstream dependency on his code, even if it is 100% separate and separately maintained.
Once the wrapper is written, any breaking changes he makes in the DMA subsystem will, by their very nature, percolate downstream to the Rust wrapper and then to any Rust code that relies on it.
So basically from that point forth, he will always have to consider the ramifications of his changes on another group of developers, and deal with any backlash those may cause.
Is he being unreasonable? I tend to lean on the side of "yes," but I can certainly empathize with his point of view (not necessarily his approach, however).
Once the wrapper is written, any breaking changes he makes in the DMA subsystem will, by their very nature, percolate downstream to the Rust wrapper and then to any Rust code that relies on it.
So basically from that point forth, he will always have to consider the ramifications of his changes on another group of developers, and deal with any backlash those may cause.
Is he being unreasonable? I tend to lean on the side of "yes," but I can certainly empathize with his point of view (not necessarily his approach, however).
He does not need to consider those ramifications because it is up to the rust for Linux people to fix the issues. He does not need to care about them at all.
They reiterated that in the thread too.
They reiterated that in the thread too.
This works only if you trust the Rust people to do their job.
Obviously the maintainer does not trust the Rust people, but they also did nothing to gain his trust, but the opposite.
Just saying "Trust me, or else I will shame you" is not a viable strategy.
The default position of any code maintainer who sees some people coming and saying that they would maintain from now on some parts of the code and that there should be no worries about that, is to not trust them immediately, but only after enough time passes during which they demonstrate that they are really competent and not just claiming to be so.
Obviously the maintainer does not trust the Rust people, but they also did nothing to gain his trust, but the opposite.
Just saying "Trust me, or else I will shame you" is not a viable strategy.
The default position of any code maintainer who sees some people coming and saying that they would maintain from now on some parts of the code and that there should be no worries about that, is to not trust them immediately, but only after enough time passes during which they demonstrate that they are really competent and not just claiming to be so.
No it does not require trust.
If the RfL people don't do their job, well then Linux releases with the Rust parts marked broken and that's that.
Saying "I do not trust you, so I'm going to stonewall your entire work with which you could have built that trust" is not viable either.
Besides, none of this was said. Hellwig did not say "I do not trust you enough". He said "you are cancer, go away". First is harsh, but at least somewhat reasonable (in the sense that it _can be reasoned with_); second is not reasonable at all. Your interpretation is excessively charitable to an obvious bad-faith actor.
Besides, none of this was said. Hellwig did not say "I do not trust you enough". He said "you are cancer, go away". First is harsh, but at least somewhat reasonable (in the sense that it _can be reasoned with_); second is not reasonable at all. Your interpretation is excessively charitable to an obvious bad-faith actor.
Why do you guys keep saying he said this?? He did not say that, and you (and everybody else) can see it for yourselves:
> If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
https://lore.kernel.org/rust-for-linux/20250128092334.GA2854...
That's totally, utterly different than your characterization of it.
(So many other people were also falsely claiming that he said it like that, I initially assumed it was true, so I'm a little irritated.)
> If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
https://lore.kernel.org/rust-for-linux/20250128092334.GA2854...
That's totally, utterly different than your characterization of it.
(So many other people were also falsely claiming that he said it like that, I initially assumed it was true, so I'm a little irritated.)
His reply after that: https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...
> You might not like my answer, but I will do everything I can do to stop this.
> You might not like my answer, but I will do everything I can do to stop this.
In the face of Coccinelle for Rust still being unreliable, can you blame him or any maintainer? The codebase is too large to suggest that manual intervention every time something breaks is acceptable, especially when the same automated tool has been in place for C for nearly two decades. And worse yet, much of the code that is generated for Rust is in the form of macros which are quite possibly some of the most unmaintainable and difficult to parse parts of Rust.
You might not like the response for being strongly worded but it is indeed backed by a technical stance and not a political or social one as has been repeatedly suggested. Already overworked maintainers are not willing to sign up for additional maintenance to what has been a solved problem. Objectively, no one should disagree with that stance.
You might not like the response for being strongly worded but it is indeed backed by a technical stance and not a political or social one as has been repeatedly suggested. Already overworked maintainers are not willing to sign up for additional maintenance to what has been a solved problem. Objectively, no one should disagree with that stance.
Yes, I do think endlessly relitigating project decisions that have been made is inappropriate.
It is not a technical stance. It is a project management one.
> Objectively, no one should disagree with that stance.
That is exactly why the maintenance burden is not his problem. He is under no obligation to take any additional work here.
It is not a technical stance. It is a project management one.
> Objectively, no one should disagree with that stance.
That is exactly why the maintenance burden is not his problem. He is under no obligation to take any additional work here.
> Yes, I do think endlessly relitigating project decisions that have been made is inappropriate.
Will you feel this way when the ruling eventually comes down that the Rust for Linux experiment has been declared a failure? Referring to what is currently an experiment as a decision is a rather bold misrepresentation of the current state. You want to present Rust in the kernel as a foregone conclusion when the reality couldn't be further from that.
> It is not a technical stance. It is a project management one.
Unstable infrastructure becoming a bottleneck is project management? Maybe a working implementation of Coccinelle for Rust should have been among the criteria before the experiment should have been allowed to proceed. That would have precluded the years of furor this has otherwise caused.
> That is exactly why the maintenance burden is not his problem. He is under no obligation to take any additional work here.
This highlights the crux of the issue and the reason your bias is clouding your view of the issue objectively. You are operating on the belief and trust of the small amount of Rust developers. Reality is proving otherwise time and time again.
Will you feel this way when the ruling eventually comes down that the Rust for Linux experiment has been declared a failure? Referring to what is currently an experiment as a decision is a rather bold misrepresentation of the current state. You want to present Rust in the kernel as a foregone conclusion when the reality couldn't be further from that.
> It is not a technical stance. It is a project management one.
Unstable infrastructure becoming a bottleneck is project management? Maybe a working implementation of Coccinelle for Rust should have been among the criteria before the experiment should have been allowed to proceed. That would have precluded the years of furor this has otherwise caused.
> That is exactly why the maintenance burden is not his problem. He is under no obligation to take any additional work here.
This highlights the crux of the issue and the reason your bias is clouding your view of the issue objectively. You are operating on the belief and trust of the small amount of Rust developers. Reality is proving otherwise time and time again.
I know, and I in fact do not like his answer, and think he is wrong in general.
But he didn't say "rust is a cancer", "you are a cancer", "your work is a cancer", or the other permutations of that I've read in this long thread; that's what I was replying to.
His technical assessment doesn't make sense, and apparently isn't even his to make. So that can, and should be, rebutted and refuted. But not by distorting his words, by attacking the substance of it.
(Which I do acknowldge that you have been doing; I've read the entire HN thread, so kudos for that.)
But he didn't say "rust is a cancer", "you are a cancer", "your work is a cancer", or the other permutations of that I've read in this long thread; that's what I was replying to.
His technical assessment doesn't make sense, and apparently isn't even his to make. So that can, and should be, rebutted and refuted. But not by distorting his words, by attacking the substance of it.
(Which I do acknowldge that you have been doing; I've read the entire HN thread, so kudos for that.)
He said
> (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
Where the cross-langauge in this case is Rust. Rust for Linux is creating a cross-language codebase. That means Rust for Linux is cancer.
> and not rust itself, just to escape the flameware brigade
is like when people say "I'm not trying to be rude, but" and then says an incredibly rude thing. Saying "I think this abstract idea is cancer, and you're the specific instance of this abstract idea, that doesn't mean I'm saying you are the thing" is incoherent.
> (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
Where the cross-langauge in this case is Rust. Rust for Linux is creating a cross-language codebase. That means Rust for Linux is cancer.
> and not rust itself, just to escape the flameware brigade
is like when people say "I'm not trying to be rude, but" and then says an incredibly rude thing. Saying "I think this abstract idea is cancer, and you're the specific instance of this abstract idea, that doesn't mean I'm saying you are the thing" is incoherent.
Echoing @steveklabnik's words, you're just hanging up on the semantics of how a particular insult has been made. This does not refute or diminish the fact of an insult.
If I actively participate in and align myself with a community that is committed to doing the $thing, and you come and say to me that "$thing is cancer", or that "the fact of doing of $thing is cancer", then it's functionally equivalent to insulting this community, and by extension to insulting me. In other words, it's clearly supposed to make _me_ feel bad (for pushing $thing, or participating in the doing of $thing), regardless of the precise wording.
It's still an unprofessional, uncooperative, and _unreasonable_ thing to do.
If I actively participate in and align myself with a community that is committed to doing the $thing, and you come and say to me that "$thing is cancer", or that "the fact of doing of $thing is cancer", then it's functionally equivalent to insulting this community, and by extension to insulting me. In other words, it's clearly supposed to make _me_ feel bad (for pushing $thing, or participating in the doing of $thing), regardless of the precise wording.
It's still an unprofessional, uncooperative, and _unreasonable_ thing to do.
Sorry; although I'm "on your side" in the sense that I want Rust in Linux and am bummed out that it seems increasingly like it's going to be a multigenerational slog, thanks to entrenched opposition from some of the C old guard, and which might even outlive Linux's window of viability.
But this is Linux kernel development. You just can't be such snowflakes, and so quick to be outraged. My mom died young, of cancer. I don't like cancer. I know that using "cancer" as a metaphor is a very negative way to characterize anything.
But the qualifier he added in the original statement is absolutely enough to make it a fair comment.
He really, really doesn't think using multiple programming languages is a sane approach. Would you really feel better if he said, "I think a multi-language approach is a very bad idea, it will inevitably spread, and it will end up causing systemic problems far away from this initial usage, and make the kernel increasingly frail and unhealthy over time" ?
If so, ... weird?
If not, then I think you are overreacting to the blunt (but technical, if perhaps motivated from some more emotional response) that he really doesn't like this idea at all.
"Cancer" is an appropriate shorthand to refer to a practice that you think causes systemic harm that compounds or grows worse over time. (I'm afraid I myself may have used it to describe PowerPoint presentations as the basis for meetings.)
I think his comment meets the minimal etiquette bar for a serious technical discussion. I mean, it wasn't nice. But the fact that he doesn't agree with you, or like your work, isn't an insult.
> He said "you are cancer, go away".
I find this absurd mischaracterization of what he said a lot more unacceptable than what he actually said. He's bluntly stating his technical opinion (which, again, I don't agree with). But you're not paraphrasing; you're basically lying.
But this is Linux kernel development. You just can't be such snowflakes, and so quick to be outraged. My mom died young, of cancer. I don't like cancer. I know that using "cancer" as a metaphor is a very negative way to characterize anything.
But the qualifier he added in the original statement is absolutely enough to make it a fair comment.
He really, really doesn't think using multiple programming languages is a sane approach. Would you really feel better if he said, "I think a multi-language approach is a very bad idea, it will inevitably spread, and it will end up causing systemic problems far away from this initial usage, and make the kernel increasingly frail and unhealthy over time" ?
If so, ... weird?
If not, then I think you are overreacting to the blunt (but technical, if perhaps motivated from some more emotional response) that he really doesn't like this idea at all.
"Cancer" is an appropriate shorthand to refer to a practice that you think causes systemic harm that compounds or grows worse over time. (I'm afraid I myself may have used it to describe PowerPoint presentations as the basis for meetings.)
I think his comment meets the minimal etiquette bar for a serious technical discussion. I mean, it wasn't nice. But the fact that he doesn't agree with you, or like your work, isn't an insult.
> He said "you are cancer, go away".
I find this absurd mischaracterization of what he said a lot more unacceptable than what he actually said. He's bluntly stating his technical opinion (which, again, I don't agree with). But you're not paraphrasing; you're basically lying.
> Would you really feel better if he said, "I think a multi-language approach is a very bad idea, it will inevitably spread, and it will end up causing systemic problems far away from this initial usage, and make the kernel increasingly frail and unhealthy over time" ?
Yes, I absolutely would. Because this statement is neutral, specific, and technical (if unfounded, so I'd feel even better if such a statement would have been supplemented with justifications), therefore it can be attacked, argued, and refuted point-by-point on a technical basis. No such thing is possible when technical concerns are replaced with emotionally loaded metaphors.
So yes, I stand by my belief that saying "$thing is a cancer" when talking to someone who is good-faith committed to doing $thing is 1) unreasonable (because it cannot be reasoned with), and 2) an insult (because it is designed to appeal to emotions rather than facts).
Yes, I absolutely would. Because this statement is neutral, specific, and technical (if unfounded, so I'd feel even better if such a statement would have been supplemented with justifications), therefore it can be attacked, argued, and refuted point-by-point on a technical basis. No such thing is possible when technical concerns are replaced with emotionally loaded metaphors.
So yes, I stand by my belief that saying "$thing is a cancer" when talking to someone who is good-faith committed to doing $thing is 1) unreasonable (because it cannot be reasoned with), and 2) an insult (because it is designed to appeal to emotions rather than facts).
> Your interpretation is excessively charitable to an obvious bad-faith actor.
And yet you keep defending Hector.
And yet you keep defending Hector.
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.
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.
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.
To me the implication isn't subtle; the maintainer NACKs, the response from someone on the contributing team is "maybe we should involve @Linus or @Greg" and from that point on, you see Greg KH get involved to note what the proper procedure is and to ensure that it'll be followed. Hellwig is completely sidelined from that point onwards, minus some grumbling noise on his side.
Hellwig is a jerk, yes (probably crosses a few lines), but there's a procedure that sidelines him and his mention for this patch was a mere courtesy (since r4l maintains the wrappers and they're not even kept in his folder).
Marcan's insertion in the thread is extremely overblown and as someone in the thread notes, comes across more like a several hours late cavalry to appeal to his social feed. I have a slightly "nicer" interpretation of it than that (in that I don't think Marcan is that kind of person) since it reads like it's probably just the sort of rage best reserved for a private message to a friend, but he's making it everyone else's problem by threatening social media brigading (which is plain and simple: harassment and unlike Hellwig's rudeness, extremely easy to identify as something to push back on).
Hellwig is a jerk, yes (probably crosses a few lines), but there's a procedure that sidelines him and his mention for this patch was a mere courtesy (since r4l maintains the wrappers and they're not even kept in his folder).
Marcan's insertion in the thread is extremely overblown and as someone in the thread notes, comes across more like a several hours late cavalry to appeal to his social feed. I have a slightly "nicer" interpretation of it than that (in that I don't think Marcan is that kind of person) since it reads like it's probably just the sort of rage best reserved for a private message to a friend, but he's making it everyone else's problem by threatening social media brigading (which is plain and simple: harassment and unlike Hellwig's rudeness, extremely easy to identify as something to push back on).
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.
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.
Yep, either people are willing to do the fork and take the challenge or they accept that nobody has to be forced to accept their opinions and contributions, good or not.
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.
Why would a Rust for Linux fork want to stay up-to-date with all the latest commits that are in C?
If all the latest commits in C are so useful, even to a Rust fork, perhaps the Linux C devs are not off-base that Rust isn't worth it for now.
If all the latest commits in C are so useful, even to a Rust fork, perhaps the Linux C devs are not off-base that Rust isn't worth it for now.
[deleted]
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...
https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
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.
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.
> 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.
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.
this seems very inefficient and the opposite of what I assumed. repeated requests take up time on both sides and are not a very good measure of how important something is.
it's not perfect but it works.
well, apparently it doesn't.
Well, apparently nobody even noticed for 5 years, so that's 5 years that nobody had to even think about that code.
This is how the most of the open-source development works. There are many projects with thousands of issues and PRs. Those that will get most attention, typically gets prioritized.
This is even how closed source development works. If you throw issues in a backlog and never follow up to advocate for it then it will never get done.
why bother infering such intent when the obvious answer - that they simply forgot about it with no ill intentions - is right there?
Requiring people to advocate for their changes is not ill-intent. It handles all cases such as forgetting/missing a patch, and disagreement whether something is needed. The point is there's no system in place to track which patches "should ideally be included but weren't for some reason", it's up for the people who need them to push for them.
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...
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"
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"
Which sounds inefficient and exactly the sort of problem that doesn't happen with a Github issue/PR.
But Github, being a platform, is a nonstarter.
Have there been any recent popular developments on a similar workflow that is as robust as e-mail ?
Have there been any recent popular developments on a similar workflow that is as robust as e-mail ?
They "just" need to settle on a platform. GitLab sounds good and is used by a lot of important Open Source projects.
Did you miss the part where being a platform was most of the issue ?
I'm not sure how long GitLab can be trusted either, as well as git becoming a bit too synonymous with GitHub...
I'm not sure how long GitLab can be trusted either, as well as git becoming a bit too synonymous with GitHub...
Yeah instead the issue will be auto-closed by some bot. Yay.
Then you get stories like Greg in the linked mail thread, who emailed to check after not hearing anything and got told that now he'd been annoying and it would never be done.
A story about a 17000 line patch with seemingly no discussion before dumping it on the kernel maintainers. Understandable that noone felt like reviewing it.
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.
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.
Thanks!
Looks like @marcan deleted his existence on mastodon? Does anyone have a copy of what he said on there?
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
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
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."
"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."
The person who called him out for that made some testy social media comments of her own this morning.
Personally, seeing
> Being toxic on the right side of an argument is still toxic, [...]
written unironically, on social media, immediately after that person wrote @marcan
> and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off
leaves me feeling more sympathetic to marcan's argument about the kernel being full of toxic attitudes, not less. Maybe public shaming isn't the answer but there's a problem here. Maybe don't make comments like that on social media if you want to criticize people for leaning on social media in kernel disputes.
Personally, seeing
> Being toxic on the right side of an argument is still toxic, [...]
written unironically, on social media, immediately after that person wrote @marcan
> and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off
leaves me feeling more sympathetic to marcan's argument about the kernel being full of toxic attitudes, not less. Maybe public shaming isn't the answer but there's a problem here. Maybe don't make comments like that on social media if you want to criticize people for leaning on social media in kernel disputes.
> Maybe don't make comments like that on social media if you want to criticize people for leaning on social media in kernel disputes.
This seems like a tu quoque fallacy. The feedback is either applicable or not, regardless of who said it. They're absolutely correct that Being toxic on the right side of an argument is still toxic.
Even if there is hypocrisy (whether judged by you personally or someone else), it wouldn't invalidate the point.
This seems like a tu quoque fallacy. The feedback is either applicable or not, regardless of who said it. They're absolutely correct that Being toxic on the right side of an argument is still toxic.
Even if there is hypocrisy (whether judged by you personally or someone else), it wouldn't invalidate the point.
Of course it doesn't invalidate the point, but it's hard to blame being so exasperated by the incredible hypocrisy that you ragequit at that point.
I can also see him quitting because he was unhappy with people pointing out the toxicity of some of his posts
Kind of reminds me of Kenneth Reitz somehow
I disagree. The behavior of the person who complains about decorum is relevant because it may indicate a double standard in the community. If a community (such as the Linux kernel maintainer community) is ganging up on an outsider using arguments of decorum, it's highly relevant that the already-accepted members of that community themselves act in a way which would've been deemed unacceptable if they were outsiders.
> 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
Certainly in context, this seems fairly reasonable: https://chaos.social/@sima/113961283260455876
Yeah this isn't about "being civil" or "friendly" and even less about "don't call out". This is about calling out in an ineffective and imprecise way, so that the people actually trying to change things are busy patching up your collateral damage instead of implementing real changes, while all you've achieved is airing your frustration for internet drama points.
When you're that harmful with your calling out, eventually I'm going to be fed up, and you get a live round shot across your bow.
And if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off.
Or as Dave Airlie put it upthread in this conversation: "Being toxic on the right side of an argument is still toxic, [...]"
So please do call out broken things, do change things, I've been doing it for well over a decade in the linux kernel. But do it in a way that you're not just becoming part of the problem and making it bigger.
---
And this is not the first time something like this has happened with Marcan. He may be tired of the Linux devs, but many of them are also tired with him (including some of the people working on Rust, it seems).
And this is part of a conversation on what went wrong here, not an attempt to rally the troops. You really can't compare it to Marcan's stuff. This kind of (selective) demand for absolute perfection is really not great.
Certainly in context, this seems fairly reasonable: https://chaos.social/@sima/113961283260455876
Yeah this isn't about "being civil" or "friendly" and even less about "don't call out". This is about calling out in an ineffective and imprecise way, so that the people actually trying to change things are busy patching up your collateral damage instead of implementing real changes, while all you've achieved is airing your frustration for internet drama points.
When you're that harmful with your calling out, eventually I'm going to be fed up, and you get a live round shot across your bow.
And if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off.
Or as Dave Airlie put it upthread in this conversation: "Being toxic on the right side of an argument is still toxic, [...]"
So please do call out broken things, do change things, I've been doing it for well over a decade in the linux kernel. But do it in a way that you're not just becoming part of the problem and making it bigger.
---
And this is not the first time something like this has happened with Marcan. He may be tired of the Linux devs, but many of them are also tired with him (including some of the people working on Rust, it seems).
And this is part of a conversation on what went wrong here, not an attempt to rally the troops. You really can't compare it to Marcan's stuff. This kind of (selective) demand for absolute perfection is really not great.
> Every experienced kernel submitter has this in their head, maybe it should be finally written down
If true, then it sounds like there are some “missing stairs”[1] (the professionally difficult kind, hopefully not the other kind) in Kernel development.
[1]: https://en.wikipedia.org/wiki/Missing_stair
If true, then it sounds like there are some “missing stairs”[1] (the professionally difficult kind, hopefully not the other kind) in Kernel development.
[1]: https://en.wikipedia.org/wiki/Missing_stair
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.
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.
Linus was right to reprimand him for the suggestion.
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.
They do, but they have a stated goal of maximizing contribution. Linux does not, right? I'm asking.
"Maximum number", perhaps not, but Greg KH did at one point want new contributors:
https://old.reddit.com/r/linux/comments/2ny1lz/im_greg_kroah...
Q: What would make you even more happy with Linux? GregKH: If you contribute to it.
Q: What would make you even more happy with Linux? GregKH: If you contribute to it.
The kernel dev process is more pathological than what I deal with at $DAYJOB.
Why the hell would I wish that upon myself?
Why the hell would I wish that upon myself?
A stable career where you can move to any of the companies who have a dependency on your subsystem.
Different Wikipedia communities have different governance policies. In the math wikis there's generally a rule that small fixes are not allowed. This stops people from arguing whether slightly better explained sentences are the right edits.
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.
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.
Suppose you find a bug in the kernel and come up with a patch. You email the patch to some kernel mailing list and ask for feedback. Typically, you will receive no response whatsoever, because no-one is responsible for responding. You can try emailing random developers and eventually maybe one of them will have mercy on you.
In Firefox and I think Chromium, you can file a bug, attach your patch, request review from someone (the UI will help you choose a suitable person), and it's their job to respond.
In my experience it's the opposite - the email patch usually gets dealt with within a week or two, Firefox and Chromium dragged out because it wasn't whatever Mozilla or Google prioritized right now. Or worse, it might go against an internal corporate KPI.
In Firefox you have to fiddle with Mercurial, phabricator, and their homegrown CI. In Chromium its Gerrit and their homegrown CI, and oh btw you touched code that lacked tests so tag, you're it.
In Firefox you have to fiddle with Mercurial, phabricator, and their homegrown CI. In Chromium its Gerrit and their homegrown CI, and oh btw you touched code that lacked tests so tag, you're it.
"The email patch usually gets dealt with within a week or two" is absolutely not my experience dealing with the kernel.
Firefox and Chromium's bespoke tools have their pluses and minuses but they're a lot easier to deal with that the kernel "workflow".
Firefox and Chromium's bespoke tools have their pluses and minuses but they're a lot easier to deal with that the kernel "workflow".
That your experience is not shared suggests that the other "workflows" are not in fact objectively easier to deal with than the kernel workflow, but instead that there's a high variability in the frustration experienced across all three workflows.
I haven't touched Gecko in a decade, but your second paragraph sounds like my experience. My best record was something like a single character bug fix taking months (might have been years?). Yes, the review flag was set to the right person.
I still remember the story where some other guys had to meet some Mozilla folks for lunch and nag them for reviews…
I still remember the story where some other guys had to meet some Mozilla folks for lunch and nag them for reviews…
I'm sorry you had a bad experience with someone, but at least you know who wasn't doing their job. On the kernel side, you don't.
get_maintainer.pl gives you the list. Theres no equivalent in Firefox or Chromium to flag which Mozilla/Red Hat/Google/... manager does not consider your ticket an area of focus.
A kernel maintainer can completely ignore any submission with no repercussions even in principle. And they often do.
In Firefox, in my era at least, a reviewer who simply ignores a review request indefinitely was not doing their job and would get yelled at by someone --- me, if it came to my attention.
In Firefox, in my era at least, a reviewer who simply ignores a review request indefinitely was not doing their job and would get yelled at by someone --- me, if it came to my attention.
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".
And he's not just abrasive He's a troublemaker. Seriously, code of conduct violation? It was perfectly clear what Hellwig meant by "cancer".
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.I'll bite and play devils advocate here - both of those are not a solution to his problem. Ultimately he's the maintainer and he gets the emails if X driver is broken, so because of that he doesn't want to rely on another group to maintain the 'Rust half' of his part of the code. It's also a system that works until it doesn't, the biggest rule of the kernel is no breaking userspace - at some point in the future it won't matter if it's his C changes breaking the Rust drivers, it's still his changes that have to be rolled back if the Rust code isn't updated.
And to clarify I'm not saying he's right or wrong or acting good or bad. I have however expected R4L to ultimately fall apart because of this exact issue, the maintainers have never been on board with maintaining Rust code and that hasn't changed. While that remains the case the project is going to be stuck at a wall - to the point that if they're confident they can maintain the Rust code themselves they should just fork it and do that. If it works well enough they'll eventually be too popular to ignore with people choosing to write their new modules in Rust instead.
And to clarify I'm not saying he's right or wrong or acting good or bad. I have however expected R4L to ultimately fall apart because of this exact issue, the maintainers have never been on board with maintaining Rust code and that hasn't changed. While that remains the case the project is going to be stuck at a wall - to the point that if they're confident they can maintain the Rust code themselves they should just fork it and do that. If it works well enough they'll eventually be too popular to ignore with people choosing to write their new modules in Rust instead.
What is the interpretation of "cancer" in this context that isn't rude, offensive, or hostile to the R4L project?
He meant to say "the Rust code will spread everywhere [like cancer]".
I agree it's rude, offensive, and hostile, but there are degrees of things and context matters. "You are cancer" would be much worse. I feel we should try and interpret things in good faith and maintain some perspective. For a single word like this: you can just read over it (which is also what the other Rust people did).
Certainly outright removing Hellwig from the Linux project, as Marcan suggested, is bizarrely draconian.
As I argued a few days ago: part of "being nice" is accepting that people aren't perfect and dealing with that – https://news.ycombinator.com/item?id=42940591
I agree it's rude, offensive, and hostile, but there are degrees of things and context matters. "You are cancer" would be much worse. I feel we should try and interpret things in good faith and maintain some perspective. For a single word like this: you can just read over it (which is also what the other Rust people did).
Certainly outright removing Hellwig from the Linux project, as Marcan suggested, is bizarrely draconian.
As I argued a few days ago: part of "being nice" is accepting that people aren't perfect and dealing with that – https://news.ycombinator.com/item?id=42940591
He wasnt talking about Rust specifically, he was referring to codebases in any other language.
He said: “ And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).”
He said: “ And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).”
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.
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.
"To interpret it differently requires bending the mind."
Stange, I think interpreting it your way requires bending the mind. Hellwig clearly used it to describe what he sees at the ill effects of multiple languages in the kernel. It was not used to describe either Rust the language or this specifically this particular submission.
Stange, I think interpreting it your way requires bending the mind. Hellwig clearly used it to describe what he sees at the ill effects of multiple languages in the kernel. It was not used to describe either Rust the language or this specifically this particular submission.
I agree with Vegenoid that using diseases for labeling poorly written code is at the very least highly unprofessional. This practice not only diminishes the seriousness of illnesses like cancer when used so casually, but it also cannot provide helpful constructive feedback.
Instead of providing helpful advice like outlining the current situation and suggesting specific improvements (action A, task B, and goal C) to reach the goal, it feels rude and offensive.
Instead of providing helpful advice like outlining the current situation and suggesting specific improvements (action A, task B, and goal C) to reach the goal, it feels rude and offensive.
There is no specific improvement if the problem is fundamental. There is no "better/right" way to spread a cancer. (I'm not saying it is, just that that is the argument, and in that context, there is no such thing as a common goal to reach some better way. Everyone does not actually have to agree that all goals are valid and should be reached.)
The only helpful advice, which they did give, is don't even start doing this because it's fundamentally wrong.
The linux kernel is like a house where everyone is a vegan. Marcan believes that incorporating some meat in the diet is important, and better that being a vegan. He may even be right. But so what? He makes his pitch, the family says that's nice but no thanks. He then demands that they eat this chicken because he wants to live in the house and wants to eat chicken while living in the vegan house?
I don't see how he has any right to what he wants, and I don't see an existing kernel devs refusal to cooperate, or even entertain cooperating, as automatically wrong or unreasonable.
The only helpful advice, which they did give, is don't even start doing this because it's fundamentally wrong.
The linux kernel is like a house where everyone is a vegan. Marcan believes that incorporating some meat in the diet is important, and better that being a vegan. He may even be right. But so what? He makes his pitch, the family says that's nice but no thanks. He then demands that they eat this chicken because he wants to live in the house and wants to eat chicken while living in the vegan house?
I don't see how he has any right to what he wants, and I don't see an existing kernel devs refusal to cooperate, or even entertain cooperating, as automatically wrong or unreasonable.
> The linux kernel is like a house where everyone is a vegan. Marcan believes that incorporating some meat in the diet is important, and better that being a vegan. He may even be right. But so what? He makes his pitch, the family says that's nice but no thanks. He then demands that they eat this chicken because he wants to live in the house and wants to eat chicken while living in the vegan house?
While I think this a dumb metaphor, it's also incorrect in this context. The Linux kernel explicitly supports C and Rust code, and there are very clear parameters to allow for Rust code to be integrated into parts of the kernel.
Or in other words, the decision has already been made to allow meat into the vegan household, and now one maintainer is explicitly blocking a package of meat from entering the building, even though it has already been decided from on high that meat should be allowed in.
This isn't quite accurate, though, because of the unnecessary metaphor thing. Reading the original mailing list chain all the way through and talking about these events directly is completely sufficient here. The patch was reasonable within the parameters set out for the R4L project. The maintainer of this subsystem blocked it explicitly because they disagree with the idea of R4L in general (calling it a cancer).
The question is not whether or not R4L is a good thing or a bad thing - anyone can have their own opinion on that. R4L is part of Linux, and will be for the foreseeable future, until it either clearly demonstrates its use, or clearly demonstrates its failure. The question (at least as regards the "cancer" comment) is whether it is okay for a maintainer to describe another team's work as cancer, and to publicly block it as much as they can.
While I think this a dumb metaphor, it's also incorrect in this context. The Linux kernel explicitly supports C and Rust code, and there are very clear parameters to allow for Rust code to be integrated into parts of the kernel.
Or in other words, the decision has already been made to allow meat into the vegan household, and now one maintainer is explicitly blocking a package of meat from entering the building, even though it has already been decided from on high that meat should be allowed in.
This isn't quite accurate, though, because of the unnecessary metaphor thing. Reading the original mailing list chain all the way through and talking about these events directly is completely sufficient here. The patch was reasonable within the parameters set out for the R4L project. The maintainer of this subsystem blocked it explicitly because they disagree with the idea of R4L in general (calling it a cancer).
The question is not whether or not R4L is a good thing or a bad thing - anyone can have their own opinion on that. R4L is part of Linux, and will be for the foreseeable future, until it either clearly demonstrates its use, or clearly demonstrates its failure. The question (at least as regards the "cancer" comment) is whether it is okay for a maintainer to describe another team's work as cancer, and to publicly block it as much as they can.
Of course it's ok to block something they judge to be harmful as much as they can. That is their explicit job as maintainer is to make exactly that type of judgement.
If they are overstepping, then Linus will make that known. Until then, apparently they are not overstepping.
And he can use that image if it communicates the concept he wants to communicate.
It sounds like a valid image to me to apply to the concept of polyglot.
He is saying that "If there is really no way for a rust driver to exist all by itself without any of the c code having to do anything special to accomodate it, then so be it, I guess rust doesn't fit here after all."
rust devs are saying "you're not even helping a tiny bit!". I am saying, no, they're not, so what? They don't have to. They did not request what rust devs are trying to do.
The concession rust devs got to proceed to attempt to use rust in the kernel at all doesn't promise almost anything beyond "well you can try". It does not promise to facilitate that try at all really.
If they are overstepping, then Linus will make that known. Until then, apparently they are not overstepping.
And he can use that image if it communicates the concept he wants to communicate.
It sounds like a valid image to me to apply to the concept of polyglot.
He is saying that "If there is really no way for a rust driver to exist all by itself without any of the c code having to do anything special to accomodate it, then so be it, I guess rust doesn't fit here after all."
rust devs are saying "you're not even helping a tiny bit!". I am saying, no, they're not, so what? They don't have to. They did not request what rust devs are trying to do.
The concession rust devs got to proceed to attempt to use rust in the kernel at all doesn't promise almost anything beyond "well you can try". It does not promise to facilitate that try at all really.
No, the rust devs are saying “you do not need to accommodate” and he’s saying “I say no anyway.”
It's like the trope of the hyper emotional significant other that turns practically any statement into "You just called me a dog!!??".
> And I also do not want another maintainer. If you want to make Linux
impossible to maintain due to a cross-language codebase do that in
your driver so that you have to do it instead of spreading this cancer
to core subsystems. (where this cancer explicitly is a cross-language
codebase and not rust itself, just to escape the flameware brigade).
It was used to describe the Rust for Linux project, as well as any other potential efforts to bring other languages into the kernel, of which there are none. It is clear why someone working on the Rust for Linux project would feel that "this cancer" refers to the project that they are working on.
I'm not trying to pull out pitchforks, I don't want anyone to burn. I just want people to collaborate effectively and be happy, and I think it is empirically clear that calling something that grows/spreads and that you think is bad "cancer" is not useful, and only inflames things. It is not an illuminating metaphor.
It was used to describe the Rust for Linux project, as well as any other potential efforts to bring other languages into the kernel, of which there are none. It is clear why someone working on the Rust for Linux project would feel that "this cancer" refers to the project that they are working on.
I'm not trying to pull out pitchforks, I don't want anyone to burn. I just want people to collaborate effectively and be happy, and I think it is empirically clear that calling something that grows/spreads and that you think is bad "cancer" is not useful, and only inflames things. It is not an illuminating metaphor.
> 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.
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.
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.
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 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.
Can't or won't? Surely what you just read would make you reconsider?
shrug maybe "won't" is a false positive, maybe a true positive, I dunno man, not my vibe check.
That sounds about right - the medium is the message. If you can't stand the clunky-but-working, decades-old, patch process, you probably won't stand the clunky-but-working decades-old code.
I'm grateful the kernel still supports MIPS, which means an old appliance of mine still works perfectly fine and is upgradable. I would be cery sad if someone were to rip-out support of an old MIPS arch, just because it's old and unwieldy
I'm grateful the kernel still supports MIPS, which means an old appliance of mine still works perfectly fine and is upgradable. I would be cery sad if someone were to rip-out support of an old MIPS arch, just because it's old and unwieldy
I've contributed to a couple of projects that use email based workflows. I can customize my environment, but it takes a lot of time, and I would rather do something else than figure out how to filter the firehose of a mailing list to the few emails I actually care about, or learn how to use a new email client that is slightly better and handling patches.
The first few times, it took me longer to figure out how to send a patch than it did to fix the bug I was writing a patch for.
The first few times, it took me longer to figure out how to send a patch than it did to fix the bug I was writing a patch for.
But you only have to figure that out once. Amortized over many contributions the cost is essentially nothing.
We only have so many hours in our sadly finite lives.
But the initial cost is what determines whether the first patch will ever be sent, so the amortization may never happen.
I guess technically that’s true, but it cannot possibly take long to learn how to use `git format-patch`, and everyone should already know how to attach a file to an email. Even if you have to spend half an hour reading the entire output of `git format-patch --help`, is that really enough to prevent you from sending your first patch?
Yes.
Ok, let me get this straight. You diagnosed a problem in the Linux kernel. You debugged it and figured out how to fix it. You edited the kernel source code, recompiled it, and tested your fix. After all that, if you have to read a man page you’ll just give up?
That’s seriously lame.
That’s seriously lame.
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.
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.
I can understand this mindset, but I also think this is how communities die. They go to great lengths to avoid inconveniencing existing members while neglecting to welcome new ones. In the short term, the better choice is always to favor the existing contributors right up until they start dropping out and there's no one left to replace them.
Linux is so ubiquitous & important that might never happen, maybe it will just become increasingly captured by corporate contributors who can at least build long lasting repos of knowledge and networks of apprenticeship to help onboard newbies. Open source in name only.
Linux is so ubiquitous & important that might never happen, maybe it will just become increasingly captured by corporate contributors who can at least build long lasting repos of knowledge and networks of apprenticeship to help onboard newbies. Open source in name only.
I really like the way sourcehut integrates mailing list patches with a good UI. I’d like to see that become more common in some of these “classic” open source projects.
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.
> [..] a workflow they have been optimizing for decades.
it sounds the opposite of optimized to me. Unless we're optimizing for something other than developer experience and efficiency?
it sounds the opposite of optimized to me. Unless we're optimizing for something other than developer experience and efficiency?
> Unless we're optimizing for something other than developer experience and efficiency?
It's almost like there are more important goals wrt software development.
It's almost like there are more important goals wrt software development.
Once you realize the kernel workflow is optimized for Linus’s (and a few other top honchos) efficiency it all begins to make sense.
Any change introduces anomalies and those cause all sorts of hell.
Any change introduces anomalies and those cause all sorts of hell.
That optimization includes things like email filters and email client customization that is individualized to longtime contributors, not to mention that it is just what Linus and others are used to. And the long time contributors have had years, or decades to incrementally set up their tools, and become familiar with the workflow. The problem is that new contributors and maintainers don't have that, and learning the workflow, and setting up tools so that the email based workflow is manageable is daunting and takes a lot of time.
I won't contest that there are advantages to the linux Kernel's workflow, but there are downsides too, and a major one is that it scares off potential contributors.
That said GitHub definitely is far from perfect as well, and has different strengths and weaknesses from email based flows. As do any other options.
But just because there isn't currently anything that is unilaterally better doesn't mean things can't be improved. There is clearly a problem with onboarding new developers to the linux workflow. That should be acknowledged, and a solution sought. That solution doesn't have to be switching to GitHub or similar. Maybe there just needs to be better documentation on how to set up the necessary tools, that is oriented towards developers used to the Github process. Maybe there needs to be better tooling. Maybe the mailing lists need to be organized better, or have the mailing list automatically add metadata in a standard, machine-readable format to emails. Etc.
I won't contest that there are advantages to the linux Kernel's workflow, but there are downsides too, and a major one is that it scares off potential contributors.
That said GitHub definitely is far from perfect as well, and has different strengths and weaknesses from email based flows. As do any other options.
But just because there isn't currently anything that is unilaterally better doesn't mean things can't be improved. There is clearly a problem with onboarding new developers to the linux workflow. That should be acknowledged, and a solution sought. That solution doesn't have to be switching to GitHub or similar. Maybe there just needs to be better documentation on how to set up the necessary tools, that is oriented towards developers used to the Github process. Maybe there needs to be better tooling. Maybe the mailing lists need to be organized better, or have the mailing list automatically add metadata in a standard, machine-readable format to emails. Etc.
[deleted]
> a workflow they have been optimizing for decades
obligatory reminder about breaking someone's workflow https://xkcd.com/1172/
obligatory reminder about breaking someone's workflow https://xkcd.com/1172/
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.
Then I talk to the old timers and they act like I just need to get used to it.
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?
And why not?
The short version is:
- Distributing patches via email is more scalable than web hosting. Even GitHub could not host the level of activity happening on the LKML mailing list
- Web hosting has a variety of access and legal problems when working with international teams; email crosses borders more easily
- Email is a decentralized and distributed system that prevents any single company from controlling a project's development infrastructure (release infrastructure is another story, but multiple companies will generally manage their own release process anyway)
- Distributing patches via email is more scalable than web hosting. Even GitHub could not host the level of activity happening on the LKML mailing list
- Web hosting has a variety of access and legal problems when working with international teams; email crosses borders more easily
- Email is a decentralized and distributed system that prevents any single company from controlling a project's development infrastructure (release infrastructure is another story, but multiple companies will generally manage their own release process anyway)
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)
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
(not taking either side, just interesting to read the 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.
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?
You have to be pretty clueless not to understand that Martin's is wrong here, he, and the rest of Rust bozos he clicks with should have been kicked out of the Kernel the minute they started with their social media drama... of course, drama and rust are just bound to be hand in hand.
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.
> 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.
Or worse: Linux is so widespread and managed to practically kill most Unix alternatives, that progress in OS development is slowed down globally. I would strongly prefer Linux being an OS with a lot of progress to stagnation and possible no alternative in the next decades.
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).
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.
> 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.
You’re right - add insufficient leadership to the list as well.
IMO, it seems inconsistent to green light R4L and not declare a clear policy for Rust code interacting with C code without adding a hard dependency (and if it WAS declared, not enforcing it).
The only benefit of doubt I can give is that there wasn’t enough time for Linus etc to weigh in before the thread got sidetracked (and the decision became much more politically charged). It’s unclear what would have happened if only the maintainer was unreasonable.
IMO, it seems inconsistent to green light R4L and not declare a clear policy for Rust code interacting with C code without adding a hard dependency (and if it WAS declared, not enforcing it).
The only benefit of doubt I can give is that there wasn’t enough time for Linus etc to weigh in before the thread got sidetracked (and the decision became much more politically charged). It’s unclear what would have happened if only the maintainer was unreasonable.
Apparently GregH(?) had already stepped in earlier to resolve the issue before it blew up again. But I’ve not been following it closely.
>Both were wrong, but only one was corrected.
People are wrong in LKML often.
This time, somebody was wrong in a much worse way than usual.
People are wrong in LKML often.
This time, somebody was wrong in a much worse way than usual.
> 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
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
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.
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
No doubt that is a flawed summary so feel free to correct
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.
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...
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.
https://lore.kernel.org/rust-for-linux/20250110083955.GA5395...
https://lore.kernel.org/rust-for-linux/20250128092334.GA2854...
https://lore.kernel.org/rust-for-linux/Z5qeoqRZKjiR1YAD@poll...
https://lore.kernel.org/rust-for-linux/20250204052916.GA2874...
https://lore.kernel.org/rust-for-linux/20250131135421.GO5556...
Note: I did not intend to particularly link to Christoph Hellwig comments, it just so happens that these contain enough quoting form previous answers to trace out something coherent.
For the complete context, you should walk up/down (and laterally) the thread to get more details and make your own opinion of it. It doesn't take very long.
[deleted]
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.
Hector wasn't the developer of this patch. However, he is a user of it. He has had some rough interactions over the last few years. And so seeing this happen (even though it's happening to someone else) is a "the straw that breaks the camel's back" kind of deal.
I 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.
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.
codr7(1)
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".
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
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.
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.
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.
Granted there are acceptable methods within that, and not acceptable.
Martin has a habit of polarizing and aggregating discussions too much. It is not healthy at all. Linus is definitely correct, especially since he has the history of doing the same and he has tried to fix it.
Imagine if the discussion would have started with an article like this. Patch probably would be merged already:
https://lwn.net/SubscriberLink/1006805/f75d238e25728afe/
Imagine if the discussion would have started with an article like this. Patch probably would be merged already:
https://lwn.net/SubscriberLink/1006805/f75d238e25728afe/
Very doubtful. The maintainer was clear and nothing in there is sufficient to address his criticism: polyglot is unmaintainable and Rust people should write a whole new OS as a separate effort.
Well, Fuschia has been largely ported to Rust, I believe, so... that's coming.
> "using social pressure to influence decisions" is so general that it could apply to just any discussion
Not really. It's one thing to discuss these things directly in the proper channels, namely the mailing list, but it's another thing entirely to make childish, passive-aggressive posts on not-Twitter about how anyone who disagrees with your actions is trying to "sabotage the project" and trying to rally your followers to cancel them on the grounds of "Code of Conduct violations" (once again proving that "Codes of Conduct" are little more than tools to enable cancel culture).
He himself acknowledged the fact that what he did was childish and embarrassing by deleting his entire Mastodon account.
Not really. It's one thing to discuss these things directly in the proper channels, namely the mailing list, but it's another thing entirely to make childish, passive-aggressive posts on not-Twitter about how anyone who disagrees with your actions is trying to "sabotage the project" and trying to rally your followers to cancel them on the grounds of "Code of Conduct violations" (once again proving that "Codes of Conduct" are little more than tools to enable cancel culture).
He himself acknowledged the fact that what he did was childish and embarrassing by deleting his entire Mastodon account.
Throwing up a call to arms in unrelated discussion venues with the purpose of drawing people to the original venue, or to harass the original participants in other venues, would count though.
i.e. no one would consider it acceptable for me to go on reddit and start ranting about a Hacker News username, link the thread and argument, and imply either implicitly or explicitly that they should go and join the argument.
i.e. no one would consider it acceptable for me to go on reddit and start ranting about a Hacker News username, link the thread and argument, and imply either implicitly or explicitly that they should go and join the argument.
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?
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?
Philpax(3)
>Isn't this the guy that blocked HackerNews links to the Asahi Linux homepage because the moderators wouldn't do his bidding?
Yup, that was Hector Martin (marcan) as well.
Yup, that was Hector Martin (marcan) as well.
I don't know anything about him, but it seems like he has a pretty negative view of Reddit users as well:
> Added some clarifications in bold, because Reddit users having enough reading comprehension to understand what Christoph said and why it's exactly* what I described with other words is apparently a Lv.100 impossible challenge boss.*
https://web.archive.org/web/20250206022420/https://social.tr...
> Added some clarifications in bold, because Reddit users having enough reading comprehension to understand what Christoph said and why it's exactly* what I described with other words is apparently a Lv.100 impossible challenge boss.*
https://web.archive.org/web/20250206022420/https://social.tr...
An Intel employee in a reply makes a extremely good point that I think everyone these days needs to follow
> And if you're wondering why you didn't realize this: It's impossible to change people by telling them they're wrong. What does tend to work is explaining different perspectives, so that they can figure it out themselves. And sometimes that's just way too subtle to ever register.
> And if you're wondering why you didn't realize this: It's impossible to change people by telling them they're wrong. What does tend to work is explaining different perspectives, so that they can figure it out themselves. And sometimes that's just way too subtle to ever register.
Said Intel employee needs to follow their own advice.
https://chaos.social/@sima/113961285815637787
> when you're that harmful with your calling out, eventually I'm going to be fed up, and you get a live round shot across your bow and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off
>or as Dave put it "Being toxic on the right side of an argument is still toxic, [...]"
(that second comment made apparently without any sense of irony re: the first)
https://chaos.social/@sima/113961285815637787
> when you're that harmful with your calling out, eventually I'm going to be fed up, and you get a live round shot across your bow and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off
>or as Dave put it "Being toxic on the right side of an argument is still toxic, [...]"
(that second comment made apparently without any sense of irony re: the first)
This seems like a perfectly reasonable response given Hector's prior comments. Pushing someones buttons until they explode and then pointing out they exploded isn't the indictment people think it is.
No, not really.
The meaning of
> "Being toxic on the right side of an argument is still toxic, [...]"
Is very straightforwards. Toxic behavior is toxic behavior. Sima shouldn't lash out in "toxic" ways even if she thinks she's right.
Otherwise shouldn't Hector be given grace because "his buttons were pushed until he exploded"?
Like, you fundamentally can't have it both ways. Excuses for Sima's comments work for Hector. Condemnations of Hector's comments apply to Sima. Anything else is a double standard.
The meaning of
> "Being toxic on the right side of an argument is still toxic, [...]"
Is very straightforwards. Toxic behavior is toxic behavior. Sima shouldn't lash out in "toxic" ways even if she thinks she's right.
Otherwise shouldn't Hector be given grace because "his buttons were pushed until he exploded"?
Like, you fundamentally can't have it both ways. Excuses for Sima's comments work for Hector. Condemnations of Hector's comments apply to Sima. Anything else is a double standard.
I fail to see anything in Sima's post that you linked that could be interpreted as toxic, rather than a perfectly normal human response. It's absolutely unreasonable to expect everyone to be perfect, always take the high road, or otherwise shrug off personal attacks.
Sima's responses can be excused. Even Hector's initial frustrations and his reactions to it can be excused. Hector's continued public reactions and escalations, however, are a different story and the reason folks are piling on him.
Sima's responses can be excused. Even Hector's initial frustrations and his reactions to it can be excused. Hector's continued public reactions and escalations, however, are a different story and the reason folks are piling on him.
[deleted]
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!
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!
I honestly don't understand what the difference is between "brigading" and "complaining about a thing on mastodon". It's not uncommon to express frustration about something/someone associated with the kernel development process, what makes this particular instance "brigading"?
The difference is between posting "ugh, having a hard time with someone on a project, they're blocking this merge and I don't think it's for a good reason" and literally starting your post with "Behold," linking directly to a mailing list post, and misrepresenting the other person's objections as "sabotage."
I mean when what you're frustrated about is a leader actively sabotaging what you're working on...
Go on?
Then complaining about that on social media is going to sound a lot like "the leader of this subsystem is sabotaging this thing I'm involved with"
Right, and phrased just like that, it wouldn't have been as objectionable. As I said before, the problem is in the specificity and the direct linking to the conversation. I still take issue with the word 'sabotage' being used here, since the person in question didn't do anything except express objections and an intent not to cooperate. Since this was in a context where that person's cooperation is not needed, I'm not sure he sabotaged anything.
>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.
You're reading way too far into this. Linus has been publicly positive about the R4L project plenty of times.
Agree with that. His statements are available on youtube. I was suprised how positive and eager to the change he was.
Positive, yes, but can you point to where he says R4L is here to stay and an integral part of the kernel? He needs to commit, or drama like this will continue to boil over. He also seems content to let the C-only old guard give the R4L guys a hard time. If you only enforce the rules on one side of a conflict, it makes it pretty clear which side you agree with.
Nothing in Linux is "here to stay", it always has to demonstrate its worth, and what it's worth is depends enirely on the technology and its developers, not Linus.
Perhaps C is here to stay and that is the way Linux should live and naturally die. That's what's being proposed here by the guy who opposes multi-language projects.
Most UNIX systems that were not implemented in C, and thus lacked the symbiotic relationship, never survived in the market, sadly.
There have been UNIX systems implemented, Pascal, Ada, Modula-2, Modula-3, as the most relevant ones.
All gone.
Also note that POSIX/UNIX certification requires a C compiler presence.
There have been UNIX systems implemented, Pascal, Ada, Modula-2, Modula-3, as the most relevant ones.
All gone.
Also note that POSIX/UNIX certification requires a C compiler presence.
Linux kernel is also one of the few that do not use C ABI as entry point for user programs at all.
As for C compiler presence in POSIX, only existence of C-accessible APIs with specific structure are mandated, C compiler is optional just like Fortran runtime and compiler are.
As for C compiler presence in POSIX, only existence of C-accessible APIs with specific structure are mandated, C compiler is optional just like Fortran runtime and compiler are.
Are you sure?
https://pubs.opengroup.org/onlinepubs/9799919799/nframe.html
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
https://pubs.opengroup.org/onlinepubs/015967575/toc.htm
And copying this from UNIX 03, the most widespread certification,
"A single configuration of the system shall meet all of the conformance requirements defined in the following mandatory Product Standards:
https://pubs.opengroup.org/onlinepubs/9799919799/nframe.html
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
https://pubs.opengroup.org/onlinepubs/015967575/toc.htm
And copying this from UNIX 03, the most widespread certification,
"A single configuration of the system shall meet all of the conformance requirements defined in the following mandatory Product Standards:
Internationalized System Calls and Libraries Extended V3
Commands and Utilities V4
C Language V2
Internationalized Terminal Interfaces
[deleted]
Depends on exact level of conformance and options chosen:
From POSIX 2017 edition https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
> On systems providing POSIX Conformance (see XBD Conformance), c99 is required only with the C-Language Development option; XSI-conformant systems always provide c99.
If XSI conformance is not asserted, only requirement is that C APIs and runtime libs for use by C programs exist on the system, and presence of C compiler is optional,
2017 POSIX had done away with including Fortran 77 in the same category as C, only providing an option for Fortran runtime libs but no longer specifying a Fortran development environment.
Also, I do not have relevant systems on hands to check, but as far as I know multiple Unix systems including behemoths like SunOS/Solaris shipped as POSIX compliant without C compiler.
From POSIX 2017 edition https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
> On systems providing POSIX Conformance (see XBD Conformance), c99 is required only with the C-Language Development option; XSI-conformant systems always provide c99.
If XSI conformance is not asserted, only requirement is that C APIs and runtime libs for use by C programs exist on the system, and presence of C compiler is optional,
2017 POSIX had done away with including Fortran 77 in the same category as C, only providing an option for Fortran runtime libs but no longer specifying a Fortran development environment.
Also, I do not have relevant systems on hands to check, but as far as I know multiple Unix systems including behemoths like SunOS/Solaris shipped as POSIX compliant without C compiler.
Ok, but that is the split certification due to the way Sun started to introduce on UNIX world the SDK concept, where customers had to additionally pay for the development tools, the UNIX version of UNIX Home and UNIX Pro editions.
Naturally UNIX Home users are also using a UNIX, and UNIX Pro, users have anyway a C compiler.
Also to note, exactly because nothing else is required, there used to be UNIX vendors, like Sun, that only included C and C++ on their base SDK. Fortran and Ada compilers were additional products to acquire on top of the SDK. Naturally most folks didn't even bother.
Naturally UNIX Home users are also using a UNIX, and UNIX Pro, users have anyway a C compiler.
Also to note, exactly because nothing else is required, there used to be UNIX vendors, like Sun, that only included C and C++ on their base SDK. Fortran and Ada compilers were additional products to acquire on top of the SDK. Naturally most folks didn't even bother.
I don't think you can conclude anything from that since a ton of UNIX systems implemented in C are also dead.
C was created to rewrite UNIX from its original Assembly implementation, naturally it is a symbiotic relationship not shared by other languages.
Note that many folks even forget that C++ was equally developed on the same Bell Labs group, and is probably one of the first examples of guest languages, making their best to fit into the platform, taking advantage of the ecosystem with almost zero friction, but never being able to control where the platform goes.
Note that many folks even forget that C++ was equally developed on the same Bell Labs group, and is probably one of the first examples of guest languages, making their best to fit into the platform, taking advantage of the ecosystem with almost zero friction, but never being able to control where the platform goes.
> C was created to rewrite UNIX from its original Assembly implementation
I don't think I can go with that one. C was created in the same period as people were trying to find a way to create a common platform, but C was more about trying to solve the problem of having a higher-level language that wasn't available for the low-end hardware (ie PDP-11, etc) of the time. Richie wasn't trying to reinvent the wheel.
He would have been happy to use other languages, but they were either design for large platforms which needed more resources (Fortran) or looking to be locked behind companies (IBM's PL/I). Richie considered BCPL, which at the time had a design that made it pretty easy to port if your computer was word-based (same size of bit-width for all numbers regardless of purpose). But, mini-frames were moving towards byte-based data and word or multi-word-based addressing. Plus, mini-frames had poorer hardware to make it cheaper, so typing on them meant more physical work.
A lot of UNIX design came from trying to use less: less memory, less paper, less typing. Richie tried to simplify BCPL to be less wordy by making B, but ultimately decided to jump to the next thing by making a language that would require as few keystroke as possible. That's why C is so symbolic: what is the least amount of typing to perform the concept? That made it pretty easy to translate to a fixed set assembly instructions; however, it hasn't had a symbiotic relationship with assembly.
If anything, it is the reverse. Just look at the compiler for all of the memory addressing it has to know. Look at any reasonably complex program of all of the compiler directives to see all the platform exceptions. C++ really took failure modes to the next level. My favorites is "a = b/*c;" Is that "a equals b divided by value pointed at by c" or "a equals b" with a comment? I left C++ a long time ago because I could take code that would compile on two different platforms and result in totally different behavior.
I think all of this drama has to do with the simple fact of there a bunch of people content to live in a one-langauge dominated environment and the head of Linux doesn't want to decide if that is or isn't the mandate; however, by not taking sides, he has effectively taken the one-language mandate. Rust needs to reimplement Linux.
I don't think I can go with that one. C was created in the same period as people were trying to find a way to create a common platform, but C was more about trying to solve the problem of having a higher-level language that wasn't available for the low-end hardware (ie PDP-11, etc) of the time. Richie wasn't trying to reinvent the wheel.
He would have been happy to use other languages, but they were either design for large platforms which needed more resources (Fortran) or looking to be locked behind companies (IBM's PL/I). Richie considered BCPL, which at the time had a design that made it pretty easy to port if your computer was word-based (same size of bit-width for all numbers regardless of purpose). But, mini-frames were moving towards byte-based data and word or multi-word-based addressing. Plus, mini-frames had poorer hardware to make it cheaper, so typing on them meant more physical work.
A lot of UNIX design came from trying to use less: less memory, less paper, less typing. Richie tried to simplify BCPL to be less wordy by making B, but ultimately decided to jump to the next thing by making a language that would require as few keystroke as possible. That's why C is so symbolic: what is the least amount of typing to perform the concept? That made it pretty easy to translate to a fixed set assembly instructions; however, it hasn't had a symbiotic relationship with assembly.
If anything, it is the reverse. Just look at the compiler for all of the memory addressing it has to know. Look at any reasonably complex program of all of the compiler directives to see all the platform exceptions. C++ really took failure modes to the next level. My favorites is "a = b/*c;" Is that "a equals b divided by value pointed at by c" or "a equals b" with a comment? I left C++ a long time ago because I could take code that would compile on two different platforms and result in totally different behavior.
I think all of this drama has to do with the simple fact of there a bunch of people content to live in a one-langauge dominated environment and the head of Linux doesn't want to decide if that is or isn't the mandate; however, by not taking sides, he has effectively taken the one-language mandate. Rust needs to reimplement Linux.
That is the usual cargo cult story of C, systems programming languages go back to JOVIAL in 1958, NEWP in 1961, one of the first systems programming languages with intrinsics and unsafe code blocks.
You surely aren't advocating that hardware predating PDP-11 for a decade are more powerful.
There is enough material that show had UNIX been a commercial product instead of free beer source code, most likely C would have been just another systems language in the mysts of time.
You surely aren't advocating that hardware predating PDP-11 for a decade are more powerful.
There is enough material that show had UNIX been a commercial product instead of free beer source code, most likely C would have been just another systems language in the mysts of time.
> You surely aren't advocating that hardware predating PDP-11 for a decade are more powerful.
That's correct. The PDP-11 used for the first Unix system had 24KBytes of memory, and no virtual memory. The kernel and the current running process had to both fit in 24KB. This PDP-11 minicomputer was vastly underpowered compared to ten year old mainframes (but was also far less expensive). The ability of Unix to run on such underpowered (and cheap) machines was a factor in its early popularity.
BCPL was first implemented on an IBM 7094 running CTSS at Project Mac at MIT. This was one of the most powerful mainframes of its era. It had 12× the memory of the Unix group’s PDP-11, plus memory protection to separate kernel memory from user memory. One of the historical papers about C noted that a BCPL compiler could not be made to run on the PDP-11 because it needed too much memory. It needed to keep the entire parse tree of a function in memory while generating code for that function. C was designed so that machine code could be generated one statement at a time while parsing a function.
That's correct. The PDP-11 used for the first Unix system had 24KBytes of memory, and no virtual memory. The kernel and the current running process had to both fit in 24KB. This PDP-11 minicomputer was vastly underpowered compared to ten year old mainframes (but was also far less expensive). The ability of Unix to run on such underpowered (and cheap) machines was a factor in its early popularity.
BCPL was first implemented on an IBM 7094 running CTSS at Project Mac at MIT. This was one of the most powerful mainframes of its era. It had 12× the memory of the Unix group’s PDP-11, plus memory protection to separate kernel memory from user memory. One of the historical papers about C noted that a BCPL compiler could not be made to run on the PDP-11 because it needed too much memory. It needed to keep the entire parse tree of a function in memory while generating code for that function. C was designed so that machine code could be generated one statement at a time while parsing a function.
> C++ really took failure modes to the next level. My favorites is "a = b/*c;" Is that "a equals b divided by value pointed at by c" or "a equals b" with a comment?
That is a really bizarre comment, especially including a comment that is perfectly valid K&R C, and just as "ambiguous" in that. The answer is of course that it is an assignment of the value b to a variable called a, followed by a comment. "/*" is always the start of a block comment.
Since C99 (and since forever in C++) there is also the new style comment, //, for commenting out the rest of the line, and this in fact broke certain older C programs (`a = b//* my comment*/ c;` used to mean a = b / c; in C89, and means `a = b` in C++ or C99).
That is a really bizarre comment, especially including a comment that is perfectly valid K&R C, and just as "ambiguous" in that. The answer is of course that it is an assignment of the value b to a variable called a, followed by a comment. "/*" is always the start of a block comment.
Since C99 (and since forever in C++) there is also the new style comment, //, for commenting out the rest of the line, and this in fact broke certain older C programs (`a = b//* my comment*/ c;` used to mean a = b / c; in C89, and means `a = b` in C++ or C99).
Well, it is kinda weird to take what would otherwise be perfectly legitimate and meaningful syntax and make it a comment. E.g. Pascal uses (* *) instead, and there's no other construct in the language where those can legitimately appear in this order.
Sure, but it's still a choice that C made, long before C++, so it's bizarre to see it in reference to how much worse C++ is.
As for the actual syntax itself, I do wonder why they didn't use ## or #{ }# or something similar, since # was only being used for the preprocessor, whereas / and * were much more common.
As for the actual syntax itself, I do wonder why they didn't use ## or #{ }# or something similar, since # was only being used for the preprocessor, whereas / and * were much more common.
OSX would like to disagree with you.
First of all I mentioned most, not all.
Second, while OS X, and NeXTSTEP before it, are technically UNIX, they aren't seen as such by either NeXT, nor Apple.
The focus of the whole userspace experience is on Objective-C frameworks, nowadays also a mix of Swift and C++.
Steve Jobs was famously against UNIX culture, there was even a famous attendance of him at USENIX.
NeXTSTEP was based on UNIX, because Steve Job wanted to win the workstation market against Sun, using UNIX compatibility as EEE, bringing folks into NeXTSTEP and keeping them there with Objective-C development experience, Lotus Improv, Renderman and such.
Second, while OS X, and NeXTSTEP before it, are technically UNIX, they aren't seen as such by either NeXT, nor Apple.
The focus of the whole userspace experience is on Objective-C frameworks, nowadays also a mix of Swift and C++.
Steve Jobs was famously against UNIX culture, there was even a famous attendance of him at USENIX.
NeXTSTEP was based on UNIX, because Steve Job wanted to win the workstation market against Sun, using UNIX compatibility as EEE, bringing folks into NeXTSTEP and keeping them there with Objective-C development experience, Lotus Improv, Renderman and such.
> NeXTSTEP was based on UNIX, because Steve Job wanted to win the workstation market against Sun, using UNIX compatibility as EEE, bringing folks into NeXTSTEP and keeping them there with Objective-C development experience, Lotus Improv, Renderman and such.
So Embrace, Extend and Extinguish?
So Embrace, Extend and Extinguish?
If macOS isn't see as UNIX by Apple, why does the latter continue to submit it for certification?
Market failures of the other Unices aren't necessarily related to the technical advantages or disadvantages or symbiosis with C or being implemented in C. However, making C programmers' life easier was crucial.
Linux was at the correct place at the correct time. It was the only free version of Unix-like OSes that didn't have legal bullshit to deal with. IBM and Intel's support also made GNU/Linux ecosystem successful, without them it would stay as an academic project. Being free meant that it had an advantage where price sensitivity mattered and dotcom boom and VC explosion is very sensitive to cheaping out and preffers suffering with less-than-ideal software. So Linux stayed popular while other ones died slowly.
C had a huge following and all OSes had to support it. Simplicity made it popular when average hardware at the hands of many academics and young professionals was very weak. Being written in C may have made things marginally easier but neglecting it for Ada or Pascal was a terminal mistake. Windows isn't Unix at all but it also had to support C well.
Linux was at the correct place at the correct time. It was the only free version of Unix-like OSes that didn't have legal bullshit to deal with. IBM and Intel's support also made GNU/Linux ecosystem successful, without them it would stay as an academic project. Being free meant that it had an advantage where price sensitivity mattered and dotcom boom and VC explosion is very sensitive to cheaping out and preffers suffering with less-than-ideal software. So Linux stayed popular while other ones died slowly.
C had a huge following and all OSes had to support it. Simplicity made it popular when average hardware at the hands of many academics and young professionals was very weak. Being written in C may have made things marginally easier but neglecting it for Ada or Pascal was a terminal mistake. Windows isn't Unix at all but it also had to support C well.
Free beer OS with source tapes and the Lions book made the huge following of academics and young professionals.
Had AT&T been able to sell UNIX, and naturally C, at the same price points as VMS, System 360, and many other contemporary OSes, and none of us would be talking about them today, other than history curiosities.
Instead we are left with UNIX haters handbook, and still trying to fix the security issues across the industry caused by C's adoption, the JavaScript and PHP of systems programming languages, both in adoption scale, and code quality.
Had AT&T been able to sell UNIX, and naturally C, at the same price points as VMS, System 360, and many other contemporary OSes, and none of us would be talking about them today, other than history curiosities.
Instead we are left with UNIX haters handbook, and still trying to fix the security issues across the industry caused by C's adoption, the JavaScript and PHP of systems programming languages, both in adoption scale, and code quality.
That's my overall point of view too. Regardless of infinite technical discussions about one or another, if Alice and Bob can't live together than just don't get married.
Why spend all this energy on conflict and drama to no end? If one language/technology/group is so much better then just fork the thing and follow their own path.
I'm actually not defending the C guys, I just want to leave them alone and let "Nature" take his course, if they die on obsolescence, then they die. who cares..
Why spend all this energy on conflict and drama to no end? If one language/technology/group is so much better then just fork the thing and follow their own path.
I'm actually not defending the C guys, I just want to leave them alone and let "Nature" take his course, if they die on obsolescence, then they die. who cares..
I concur. Personally, I'd love to see all the Linux Rust effort being redirected at Redox OS.
If the Asahi team focused their efforts on Redox, with all the genius talent they they have, we could see an actually practical, usable implementation of Redox on real hardware; a potential daily-driver which would catapult the development of whole ecosystem - and that can only be a good thing.
If the Asahi team focused their efforts on Redox, with all the genius talent they they have, we could see an actually practical, usable implementation of Redox on real hardware; a potential daily-driver which would catapult the development of whole ecosystem - and that can only be a good thing.
Redox has stayed drama free so far.
I am sure most people involved with the Linux rust effort are also not problematic; these would be very welcome there.
OTOH, please don't let Redox be taken over by problematic people.
I am sure most people involved with the Linux rust effort are also not problematic; these would be very welcome there.
OTOH, please don't let Redox be taken over by problematic people.
Redox is drama-free because Redox has very few developers working on it. In the last 12 months, Redox had 7 contributors that touched more than 100 lines of code.
Hard to have too much drama if you have a handful of developers that do code changes, and no users to complain about any of your decisions.
Hard to have too much drama if you have a handful of developers that do code changes, and no users to complain about any of your decisions.
"In 2010, after twenty years under development, Stallman said that he was "not very optimistic about the GNU Hurd. It makes some progress, but to be really superior it would require solving a lot of deep problems" - https://en.wikipedia.org/wiki/GNU_Hurd
Yes, perhaps a C-only Linux would do that and die, and perhaps it would continue its customization of C flavor and runtime it uses (e.g., the various static and dynamic memory limitations and checkers) and closes the gap with Rust to a point where the incremental benefit of using it is not significant enough that it makes a Rust based competitor an inevitability. We may already be beyond that point, even.
The changes required to bring C to a Rust level of safety would make it an entirely different language, even when restricted to the kernel's domain. Also, if you're already doing codebase-specific patches to the language itself, many of the arguments around codebase portability that justify the use of C fall apart.
Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined.
[0]: https://lwn.net/Articles/978738/
Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined.
[0]: https://lwn.net/Articles/978738/
> The changes required to bring C to a Rust level of safety would make it an entirely different language, even when restricted to the kernel's domain.
Maybe. 1. It may not have to be "Rust-level of safety" to be good enough to make Rust benefit less compelling. 2. Linux C is already a different languag than C, continued incremental changes might be a better way to get there than adding Rust even if it does become very different in the end.
> Also, if you're already doing codebase-specific patches to the language itself, many of the arguments around codebase portability that justify the use of C fall apart.
Sure, but Linux never had a "codebase portability" argument. It always had to be GCC C. It eventually made some relatively small changes to allow clang to compile it, the far bulk of that work being changing of clang to behave like GCC.
> Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined.
Yeah, it's not only safety improvements that are in Linux-C.
Maybe. 1. It may not have to be "Rust-level of safety" to be good enough to make Rust benefit less compelling. 2. Linux C is already a different languag than C, continued incremental changes might be a better way to get there than adding Rust even if it does become very different in the end.
> Also, if you're already doing codebase-specific patches to the language itself, many of the arguments around codebase portability that justify the use of C fall apart.
Sure, but Linux never had a "codebase portability" argument. It always had to be GCC C. It eventually made some relatively small changes to allow clang to compile it, the far bulk of that work being changing of clang to behave like GCC.
> Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined.
Yeah, it's not only safety improvements that are in Linux-C.
> The changes required to bring C to a Rust level of safety
cough* Cargo cough* /s
You cannot have safety or security when you download your code from the internet and this code is a moving target.
cough* Cargo cough* /s
You cannot have safety or security when you download your code from the internet and this code is a moving target.
Or may be Zig might be more acceptable to the Kernal team, once it becomes mature enough?
This is inevitable: Rust is proposed as a safe language, but there is no way to have a "half-secure" kernel. The only option for people who believe in Rust is to have its own kernel, and Linux should have no part on this.
> there is no way to have a "half-secure" kernel.
There is, and this is how Rust naturally works. If you look at its standard library, you will see a lot of unsafe code or libc calls hidden away under safe interfaces.
In fact, this is how all memory safe languages work, including Java, Python, etc: A small trusted base written in an unsafe language that exposes a safe interface (i.e. the interpreter, the JVM, etc), with the large majority of the code written over that safe interface (i.e. the Java/Python code).
Rust is used to make kernel drivers secure by providing a safe interface for them to use.
There is, and this is how Rust naturally works. If you look at its standard library, you will see a lot of unsafe code or libc calls hidden away under safe interfaces.
In fact, this is how all memory safe languages work, including Java, Python, etc: A small trusted base written in an unsafe language that exposes a safe interface (i.e. the interpreter, the JVM, etc), with the large majority of the code written over that safe interface (i.e. the Java/Python code).
Rust is used to make kernel drivers secure by providing a safe interface for them to use.
Keeping the project single language doesn't mean that the project can't change. The C used today is not the same C used when when the project was started. Changing language is also possible. Using two different languages long-term however means that everyone effectively needs to be proficient in both languages and a lot of work is duplicated.
Would you say that C is "here to stay" in Linux? I would say so. I think you understood what was meant.
The drama is the problem, not rust. I don't know why, but either zealots choose rust or rust induces zealotry.
Its exactly what Linus said.
Its exactly what Linus said.
I don't understand how this is related to what I said.
>. I don't know why, but either zealots choose rust or rust induces zealotry.
That is actually quite well put together. May be The language that introduce absolute control also induces zealotry and produce zealots.
However that doesn't happen with Ada. So that cant be the full explanation.
That is actually quite well put together. May be The language that introduce absolute control also induces zealotry and produce zealots.
However that doesn't happen with Ada. So that cant be the full explanation.
No I wouldn't say that. If Rust or another language eventually proved itself more value than C and things were eventually all rewritten, C would go away.
For that matter the C of Linux 10 years ago was not there to stay either, it has changed and certain features and practices are deprecated and dropped and others adopted. It's not the same C.
For that matter the C of Linux 10 years ago was not there to stay either, it has changed and certain features and practices are deprecated and dropped and others adopted. It's not the same C.
DEC Alpha support is somehow still in the mainline Linux kernel...
Slowly getting removed: https://lore.kernel.org/lkml/e8612e21-4ea4-4e6f-8c73-9fbee11...
To be fair, anything that does not support BWX is really painful to deal with.
Take, for example, an 8-bit/byte store. Without BWX the sequence would be something like:
Take, for example, an 8-bit/byte store. Without BWX the sequence would be something like:
bic a0, #3, t1
and a0, #3, t4
ldl t2, (t1)
insbl a1, t4, t3
mskbl t2, t4, t2
bis t2, t3, t2
stl t2, (t1)
ret zero, (ra)
stb a1, 0(a0)
ret zero, (ra)Yeah m68k is still around too and it has more than a decade on alpha.
People use and maintain them and they have very little impact outside arch/ nowadays so they're on the happy side of cost/benefit I guess.
People use and maintain them and they have very little impact outside arch/ nowadays so they're on the happy side of cost/benefit I guess.
I guess the biggest difference is that Coldfire parts are still being produced (c.f: MCF52256CVN66).
I'm not sure if Alphas are even being made anymore, even 15-20 years ago.
I'm not sure if Alphas are even being made anymore, even 15-20 years ago.
M68k has the advantage that it has a fairly typical memory model.
Alpha's memory model has problems with providing atomic access to single bytes, which i'd imagine in a kernel is a bit annoying :-)
And then there's just the social aspect, m68k was used in the Amiga/Atari/Mac/QL/x68k, so there is a whole generation of us m68k fans who are willing to keep it alive.
Alpha has it's fans (me included!), but it's not exactly the same. So in a way it's no surprise it's slowly bitrotting away.
Alpha's memory model has problems with providing atomic access to single bytes, which i'd imagine in a kernel is a bit annoying :-)
And then there's just the social aspect, m68k was used in the Amiga/Atari/Mac/QL/x68k, so there is a whole generation of us m68k fans who are willing to keep it alive.
Alpha has it's fans (me included!), but it's not exactly the same. So in a way it's no surprise it's slowly bitrotting away.
Ah, my favorite instructions, 'hw_ldl/l', 'hw_stl/c', 'ldl_l', 'stl_c' and their quadword siblings.
Since the C compiler can hide that, for core kernel code I think the more problematic thing was Alpha's memory consistency model where (data-)dependent loads accesses did not imply ordering, which is unusual and more burdensome to the programmer than any other ISA.
That required this smp_read_barrier_depends() through the kernel, but actually in recent years that has basically been subsumed by other concurrent access primitives that all the core kernel must use, so I think alpha is no longer much of a problem outside arch/alpha
That required this smp_read_barrier_depends() through the kernel, but actually in recent years that has basically been subsumed by other concurrent access primitives that all the core kernel must use, so I think alpha is no longer much of a problem outside arch/alpha
The ghost of the Alpha's infamously weak memory model coming back to bite it's undead self.
The problem is, that he let's a maintainer say he is going to fight any Rust code getting into any "core" (whatever he considers core) part of the kernel, even if it's just a wrapper to make driver code more maintainable. I would say, that's a strategy decision that should not be up to any subsystem maintainer, that's a decision that should be up to Linus, by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers. I don't believe that was what the rust guys thought they'd be signing up for.
> by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers
And let's not be obtuse, some of those subsystem maintainers are staunchly opposed, so "it's up to them" is obviously an indirect way of saying "no rust". I don't blame those maintainers for balking at a whole new very different language, but Torvalds has a choice of telling them either "suck it up, buttercup" or "I hear you; rust is gone". Instead, he's just letting things fester.
And let's not be obtuse, some of those subsystem maintainers are staunchly opposed, so "it's up to them" is obviously an indirect way of saying "no rust". I don't blame those maintainers for balking at a whole new very different language, but Torvalds has a choice of telling them either "suck it up, buttercup" or "I hear you; rust is gone". Instead, he's just letting things fester.
This seems like black and white thinking. There's a huge spectrum between
> "suck it up, buttercup" or "I hear you; rust is gone".
where various levels of compromise happens.
Maintainers are people and people can change their mind over time. If rust was a huge success in large parts of the kernel and you still had a few holdouts, sure, you could tell them to adapt or go away. In this early stage, it's kinda up to rust people to show that both they and rust can work in this setting
> "suck it up, buttercup" or "I hear you; rust is gone".
where various levels of compromise happens.
Maintainers are people and people can change their mind over time. If rust was a huge success in large parts of the kernel and you still had a few holdouts, sure, you could tell them to adapt or go away. In this early stage, it's kinda up to rust people to show that both they and rust can work in this setting
> that's a strategy decision that should not be up to any subsystem maintainer
So people are not allowed to hold positions and argue for them in public, or take actions that align with that position?
> I don't believe that was what the rust guys thought they'd be signing up for
It's not like there wasn't any existing precedence with C++, and many of the arguments I've read seem consistent with that history.
So people are not allowed to hold positions and argue for them in public, or take actions that align with that position?
> I don't believe that was what the rust guys thought they'd be signing up for
It's not like there wasn't any existing precedence with C++, and many of the arguments I've read seem consistent with that history.
The C++ situation was completely different, Linus said from the get go "no way", thus nobody put serious work writing c++ code for the kernel. With Rust Linus essentially said let's see how it goes, but specifically said he would deal with maintainers who would be unwilling to consider code that would be necessary for R4L.
Based on this people invested significant work into writing code that is quite widely used, only to now have a maintainer saying he'll oppose any Rust code coming into the kernel, and Linus saying the guys trying to get the code in are the problem.
> that's a decision that should be up to Linus, by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers.
And that's a perfectly resonable position.
And that's a perfectly resonable position.
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...
Edit: For further context for Linus's reply, there's http://web.archive.org/web/20250206022420/https://social.tre...
Yikes, re that fedi thread.
This one bit looks exactly right, though:
> As for how to move forward, (...) Either Linus takes the pull, and whatever Christoph says is irrelevant, or he doesn't, and R4L dies. Everything else is a waste of everyone's time and energy.
It does look like maintainers should have a "disagree and commit" mentality at some point, whatever decision they end up making.
I thought Rust in Linux was evaluated, discussed and agreed upon years ago. The fact that there are people still trying to sabotage it shows that they don't follow the "disagree and commit" principle.
They are more like "disagree and make the others lives a living hell until they bend to my will".
> As for how to move forward, (...) Either Linus takes the pull, and whatever Christoph says is irrelevant, or he doesn't, and R4L dies. Everything else is a waste of everyone's time and energy.
It does look like maintainers should have a "disagree and commit" mentality at some point, whatever decision they end up making.
I thought Rust in Linux was evaluated, discussed and agreed upon years ago. The fact that there are people still trying to sabotage it shows that they don't follow the "disagree and commit" principle.
They are more like "disagree and make the others lives a living hell until they bend to my will".
That's a much stronger argument when you aren't at the same time yelling about the email patch system. I want R4L to succeed!
> disagree and commit
It is not some million dollar RSUs getting vested by year end either way. A lot of them working for the love of craft and prestige. If they can just rollover on a technical disagreement then corporate office job is more suitable than open source OS kernel.
It is not some million dollar RSUs getting vested by year end either way. A lot of them working for the love of craft and prestige. If they can just rollover on a technical disagreement then corporate office job is more suitable than open source OS kernel.
The Linux kernel is most definitely not developed for free by some college student in their bedroom for the most part. It's Intel and Red Hat and similar.
Edit: related email by Hector: https://lore.kernel.org/rust-for-linux/c5a49bcb-45cf-4295-80...
Edit: related email by Hector: https://lore.kernel.org/rust-for-linux/c5a49bcb-45cf-4295-80...
> I thought Rust in Linux was evaluated, discussed and agreed upon years ago.
I've seen Linus talk about it in one of his public chats with Dirk Hohndel as an interesting experiment that might succeed or fail, or that's the impression I got. I'm not sure everyone else got that memo.
I've seen Linus talk about it in one of his public chats with Dirk Hohndel as an interesting experiment that might succeed or fail, or that's the impression I got. I'm not sure everyone else got that memo.
"R4L dies" is hyperbolic nonsense. There are many ways/places to integrate Rust in the kernel, even for wrappers. It's not like "I think this code should be someone else" automatically means the death of Rust.
Marcan goes full nuclear every other time someone disagrees with him. He's very much the "if it's not my preferred way then we might as well not do it at all"-type of engineer (many of us have worked with those people).
Marcan goes full nuclear every other time someone disagrees with him. He's very much the "if it's not my preferred way then we might as well not do it at all"-type of engineer (many of us have worked with those people).
Rust is only allowed for drivers, because that sidesteps the platform support questions.
DMA is needed for an overwhelming number of useful drivers.
If you can’t use DMA from Rust, then you can’t really properly evaluate the usefulness of Rust, hence the effort is basically dead.
DMA is needed for an overwhelming number of useful drivers.
If you can’t use DMA from Rust, then you can’t really properly evaluate the usefulness of Rust, hence the effort is basically dead.
People can just include their own dma.rs in driver/.../mydriver/
Whether that's a good or bad approach is besides the point. It's what was suggested as an alternative, and clearly it's something that would work. "You can't use DMA from Rust" is just not true.
Whether that's a good or bad approach is besides the point. It's what was suggested as an alternative, and clearly it's something that would work. "You can't use DMA from Rust" is just not true.
If it was a good approach, the C folks would have copied around C files instead of having common core code. They did not do that though, because it'd be counter productive due to increasing maintenance burden.
Everyone knows it would increase maintenance burden, decrease reliability, and increase the amount of apparent churn of rust code in the linux kernel.
Everyone knows it would increase maintenance burden, decrease reliability, and increase the amount of apparent churn of rust code in the linux kernel.
Everyone knows you could start the crude way today and refactor the duplication later after it proves itself, if you actually wanted to proceed rather than throw fits.
You can't just endlessly dump more busywork on Rust developers (including genuinely bad code practices) and expect them to deal with it.
There is zero good reason to duplicate that code and refactor it later.
There is zero good reason to duplicate that code and refactor it later.
I don't know the better way to ask this question, so I'm just going to ask it:
"Congratulations, you're right, and nobody cares."
Now what? Just complain that the kernel isn't hospitable to Rust, and hope 15 years from now we're all using some Linux-compatible kernel built ground-up in Rust?
I genuinely want to know where you go from this position.
"Congratulations, you're right, and nobody cares."
Now what? Just complain that the kernel isn't hospitable to Rust, and hope 15 years from now we're all using some Linux-compatible kernel built ground-up in Rust?
I genuinely want to know where you go from this position.
I am trying to explain why someone would say this.
I think Rust in Linux makes sense, but honestly, Rust doesn’t need Linux to be successful, and I barely use Linux personally. If they decide Rust for Linux is not a thing, that’s for the folks who work on and care about Linux to deal with. This isn’t my fight, I am just observing.
I’ve been primarily a Windows user for many years now, but I do use some WSL. My main OS is already shipping Rust, and in the actual kernel, without all of this wailing and gnashing of teeth. (That said I respect the approach Linux is taking here, I don't think it's inherently bad.)
Oh, and honestly, what I believe is happening here is just that, from Linus's perspective, folks should know that because this isn't in Hellwig's part of the tree, his NACK doesn't actually matter, and he'll just end up pulling this patch in anyway. There's no need to intervene because there isn't actually obstruction going on. The internet is just going wild about this drama because they fundamentally misunderstand how kernel development works, and because people are slinging mud on the LKML. That's why he only commented on Hector's behavior.
I can see that perspective, though I would prefer a different management style, but that's also why (among other reasons) I don't care to contribute to the kernel.
I think Rust in Linux makes sense, but honestly, Rust doesn’t need Linux to be successful, and I barely use Linux personally. If they decide Rust for Linux is not a thing, that’s for the folks who work on and care about Linux to deal with. This isn’t my fight, I am just observing.
I’ve been primarily a Windows user for many years now, but I do use some WSL. My main OS is already shipping Rust, and in the actual kernel, without all of this wailing and gnashing of teeth. (That said I respect the approach Linux is taking here, I don't think it's inherently bad.)
Oh, and honestly, what I believe is happening here is just that, from Linus's perspective, folks should know that because this isn't in Hellwig's part of the tree, his NACK doesn't actually matter, and he'll just end up pulling this patch in anyway. There's no need to intervene because there isn't actually obstruction going on. The internet is just going wild about this drama because they fundamentally misunderstand how kernel development works, and because people are slinging mud on the LKML. That's why he only commented on Hector's behavior.
I can see that perspective, though I would prefer a different management style, but that's also why (among other reasons) I don't care to contribute to the kernel.
> Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do
everything I can do to stop this.
https://lwn.net/ml/all/[email protected]/
Maybe you can try to read what Christoph Hellwig said first.
https://lwn.net/ml/all/[email protected]/
Maybe you can try to read what Christoph Hellwig said first.
[deleted]
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?
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?
https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
Just read the email.
Just read the email.
devit(3)
> 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.
That doesn't really have anything to do with Rust; but with Hector's behaviour. Threatening a social media campaign to out people is completely toxic behaviour. This is a long-term contributor who is perhaps a bit abrasive, not Jimmy fucking Saville.
Other than that, it's not a binary yes/no question; no one is really against some Rust in some parts of the kernel, but which parts? How? Where? That's the big disagreement. Linus has always been fairly hands-off on these types of disagreements.
> Threatening a social media campaign to out people is completely toxic behaviour. This is a long-term contributor who is perhaps a bit abrasive, not Jimmy fucking Saville.
I'm no where near in the loop on this, but that sounds incredibly toxic. Are there some good links to summarize this?
EDIT:
OK, these are fully enough to allow me to understand the issue.
Marcan: https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
Linus: https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
I must say, I think I'm on Linus' side on this one.
EDIT2:
I was a $$ supporter of Marcan for over a year on github. I was predisposed to believe him, I'd say.
I'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.
> If shaming on social media does not work, then tell me what does, because I'm out of ideas.
That's just manipulative. Maybe it's just a moment of frustration and they'd take it back eventually, but blackmailing people with social drama is not cool. That's what X and Reddit is for.
> Rust folks: Please don't waste your time and mental cycles on drama like this [...] they know they're going to be on the losing side of history sooner or later.
That sounds very cult-like, doesn't it?
That's just manipulative. Maybe it's just a moment of frustration and they'd take it back eventually, but blackmailing people with social drama is not cool. That's what X and Reddit is for.
> Rust folks: Please don't waste your time and mental cycles on drama like this [...] they know they're going to be on the losing side of history sooner or later.
That sounds very cult-like, doesn't it?
It’s true though? I don’t see anyone picking C/C++ over Rust/Go in my immediate environment.
That might reflect my environment, but all of the things I’d consider C variations for I’d use Rust for as well…
That might reflect my environment, but all of the things I’d consider C variations for I’d use Rust for as well…
It's definitely your environment, Rust isn't nearly as popular for actual projects getting done as it is in (for example) StackOverflow's survey. C, C++, Odin and Zig are all languages where whatever C knowledge you have right now can trivially be put to use to do things, immediately, I think it makes perfect sense that unless someone is just really into doing Rust things they'll just take the trivially applicable ways of working and use the aforementioned languages (which all have much better support for batch memory management and custom allocators than Rust, it should be added).
There are a lot of C programmers who do not like or are not fond of Zig or Odin. For highly proficient C and C++ programmers, many consider them not worth their time. Not even counting, that both Zig and Odin are in beta. It's an investment to become as proficient in the other language.
An example is Muratori from handmade hero, who publicly stated he dislikes Zig and pretty much sees it as a confused mess[1]. He thinks Odin is kind of OK, because it has metaprogramming (which other languages do too), but is way below Jai. Between Jai and Odin, he thought Jai was the one with potential and could get him to switch/use. Odin's slight popularity, as a kind of Jai-lite, is often attributed to Jai being a closed beta. But, it appears that might change soon (Jai going public or opening up beta use more), along with an upcoming book on Jai.
Programming languages like Go and V (Vlang), have more of a use case for new programmers and general-purpose, because they are easier to learn and use. That was the point of their creation.
[1]: https://www.youtube.com/watch?v=uVVhwALd0o4 (Full Casey Muratori: Language Perf and Picking A Lang Stream)
An example is Muratori from handmade hero, who publicly stated he dislikes Zig and pretty much sees it as a confused mess[1]. He thinks Odin is kind of OK, because it has metaprogramming (which other languages do too), but is way below Jai. Between Jai and Odin, he thought Jai was the one with potential and could get him to switch/use. Odin's slight popularity, as a kind of Jai-lite, is often attributed to Jai being a closed beta. But, it appears that might change soon (Jai going public or opening up beta use more), along with an upcoming book on Jai.
Programming languages like Go and V (Vlang), have more of a use case for new programmers and general-purpose, because they are easier to learn and use. That was the point of their creation.
[1]: https://www.youtube.com/watch?v=uVVhwALd0o4 (Full Casey Muratori: Language Perf and Picking A Lang Stream)
I would suggest linking to a timestamped point in the video instead of the entire thing. With regards to Odin having metaprogramming this is either a misunderstanding on your part of what was said or a misunderstanding from Casey Muratori with regards to Odin; Zig has a much stronger claim to having metaprogramming with `comptime` being as powerful as it is, whereas Odin only scarcely can be said to have a limited "static if" in the `when` keyword, plus your average parametric polymorphism via template parameters.
C programmers (and C++ programmers) who don't like Zig or Odin can simply use C (or C++), it's not really the case that they have to switch to anything, much less something as overwrought as Rust. My point is that it is natural for someone who is at any proficiency level above 0 in C to want to apply that proficiency in something that allows them to make use of those skills, and C, C++, Odin and Zig all allow them to do that, pretty much immediately.
You contend that "It's an investment to become as proficient in the other language" but I would argue that this is a very wide spectrum where Rust falls somewhere in the distance as opposed to all of the languages I mentioned instead being far closer and more immediately familiar.
C programmers (and C++ programmers) who don't like Zig or Odin can simply use C (or C++), it's not really the case that they have to switch to anything, much less something as overwrought as Rust. My point is that it is natural for someone who is at any proficiency level above 0 in C to want to apply that proficiency in something that allows them to make use of those skills, and C, C++, Odin and Zig all allow them to do that, pretty much immediately.
You contend that "It's an investment to become as proficient in the other language" but I would argue that this is a very wide spectrum where Rust falls somewhere in the distance as opposed to all of the languages I mentioned instead being far closer and more immediately familiar.
True that Odin is admittedly quite limited in that area. Muratori made the case that Jai was far beyond both Zig and Odin, thus recommending its use and what made it attractive for him. The other issue, is investing in languages that are in beta.
The counter, in regards to "any proficiency above 0", is there are other alternative languages (that are easier to learn and use) where knowledge of C can be put to immediate use too. Getting up to speed in those languages, would likely be much faster, if not more productive for less proficient or experienced programmers.
The counter, in regards to "any proficiency above 0", is there are other alternative languages (that are easier to learn and use) where knowledge of C can be put to immediate use too. Getting up to speed in those languages, would likely be much faster, if not more productive for less proficient or experienced programmers.
> The other issue, is investing in languages that are in beta.
I work full time with Odin and I wouldn't put too much stress on this point as I've found that whatever issues we have with Odin are simply issues you'd have with C for the most part, i.e. C knowledge will help solve it. It's not a complex language, it doesn't need to do much and language-specific issues are few and far between because of it. Tooling is a bit of a mixed bag but it's about 80% solved as far as we're concerned.
Odin day-to-day for working on 3D engines (which I do) is not beta quality, whatever that means. I would rate it a better net fit for that purpose than I would C++, and I wrote the kind of C++ you would write for engine work for about 10-11 years (at least what we knew to be that kind of C++ at around 2001). For server software I'd rate it worse, but this is mostly because there are a few missing FFI wrappers for things that usually come up, it's not really because of the language per se.
As for Jai, I can't claim to know much of anything about it because I've never used it, and I wouldn't take many peoples' word for much of anything about the language. As far as I'm concerned Jai will exist when it's publicly available and until then it's basically irrelevant. This is not to disparage the effort, but a language is really only relevant to talk about once anyone with motivation and an idea can sit down, download/procure it and use it to build something, which is not the case with Jai.
I work full time with Odin and I wouldn't put too much stress on this point as I've found that whatever issues we have with Odin are simply issues you'd have with C for the most part, i.e. C knowledge will help solve it. It's not a complex language, it doesn't need to do much and language-specific issues are few and far between because of it. Tooling is a bit of a mixed bag but it's about 80% solved as far as we're concerned.
Odin day-to-day for working on 3D engines (which I do) is not beta quality, whatever that means. I would rate it a better net fit for that purpose than I would C++, and I wrote the kind of C++ you would write for engine work for about 10-11 years (at least what we knew to be that kind of C++ at around 2001). For server software I'd rate it worse, but this is mostly because there are a few missing FFI wrappers for things that usually come up, it's not really because of the language per se.
As for Jai, I can't claim to know much of anything about it because I've never used it, and I wouldn't take many peoples' word for much of anything about the language. As far as I'm concerned Jai will exist when it's publicly available and until then it's basically irrelevant. This is not to disparage the effort, but a language is really only relevant to talk about once anyone with motivation and an idea can sit down, download/procure it and use it to build something, which is not the case with Jai.
> It's not a complex language
You cannot claim this when even codebases with veteran C developers will be virtually guaranteed to have memory safety issues at some point.
You cannot claim this when even codebases with veteran C developers will be virtually guaranteed to have memory safety issues at some point.
My comment was addressing the idea that Odin is a "beta language" in comparison to C and my assertion was that the issues we have with using Odin are the same ones you'd have with C. So assuming that you have accepted C-style issues, then Odin really does not present many or common additional roadblocks despite being relatively young.
Also, I know this may shock a lot of people who don't regularly use sharp tools: The possibility (and even occurrence) of memory safety issues and memory corruption doesn't tank a project, or make it more costly than if you'd used a GC, or Rust. Memory bugs range from very easily avoided and solved to surprising and very, very hard to solve.
Also, I know this may shock a lot of people who don't regularly use sharp tools: The possibility (and even occurrence) of memory safety issues and memory corruption doesn't tank a project, or make it more costly than if you'd used a GC, or Rust. Memory bugs range from very easily avoided and solved to surprising and very, very hard to solve.
[deleted]
I meant the whole “we are on the right side of history” and if you’re not with us you’re against us and we’ll wage a public drama campaign against you.
[deleted]
> in my immediate environment
Social bubbles can work like that.
Social bubbles can work like that.
Threatening with social media seems to me like a professional suicide, especially when it's followed by a doubling down and a complete lack of anything resembling an apology.
I'm amazed that Hector is doing this fully in public using his real name.
I'm amazed that Hector is doing this fully in public using his real name.
[deleted]
https://archive.is/rESxe
This is a recurring pattern I see with drama in some open source communities, where people measure others using yardsticks they themselves don't live up to. People can't post stuff like this while accusing everyone in the vicinity except themselves of bad behavior. Choose one.
This is a recurring pattern I see with drama in some open source communities, where people measure others using yardsticks they themselves don't live up to. People can't post stuff like this while accusing everyone in the vicinity except themselves of bad behavior. Choose one.
I think the response from Dr Greg to Linus, https://lore.kernel.org/rust-for-linux/20250207121638.GA7356... adds some interesting insights.
There seems to be some issue with unaccountable maintainers, and that’s a problem for innovation. If you can’t even get to the point of “technical debate” (we aren’t interested, sorry), then what hope innovation?
These are “people problems”, and there are no easy or good answers, but it doesn’t mean we should through our hands up and consider things “unfixable” either.
There seems to be some issue with unaccountable maintainers, and that’s a problem for innovation. If you can’t even get to the point of “technical debate” (we aren’t interested, sorry), then what hope innovation?
These are “people problems”, and there are no easy or good answers, but it doesn’t mean we should through our hands up and consider things “unfixable” either.
People should read it:
"... I come at this from the perspective of having worked on Linux since around December of 1991. I first met you and Tove in 1995 at the Free Software Conference at MIT that Stallman sponsored. ...
Probably the last technical contribution of my career is leading an initiative to provide the Linux community a generic security modeling architecture. Not to supplant or replace anything currently being done, but to provide a flexible alternative to the development of alternate and/or customized workload models, particularly in this era of machine learning and modeling.
Four patch series over two years, as of yesterday, not a single line of code ever reviewed. ...
We were meticulous in our submissions to avoid wasting maintainers time. We even waited two months without hearing a word before we sent an inquiry as to the status of one of the submissions. We were told, rather curtly, that anything we sent would likely be ignored if we ever inquired about them.
We tried to engage, perhaps to excess, in technical discussions attempting to explain why and how we chose to implement what we were proposing. ...
There were never any relevant technical exchanges. The discussion consisted of, we have decided to do things a certain way, no discussion, if you don't like that you should really consider doing something other than submitting to upstream Linux."
"... I come at this from the perspective of having worked on Linux since around December of 1991. I first met you and Tove in 1995 at the Free Software Conference at MIT that Stallman sponsored. ...
Probably the last technical contribution of my career is leading an initiative to provide the Linux community a generic security modeling architecture. Not to supplant or replace anything currently being done, but to provide a flexible alternative to the development of alternate and/or customized workload models, particularly in this era of machine learning and modeling.
Four patch series over two years, as of yesterday, not a single line of code ever reviewed. ...
We were meticulous in our submissions to avoid wasting maintainers time. We even waited two months without hearing a word before we sent an inquiry as to the status of one of the submissions. We were told, rather curtly, that anything we sent would likely be ignored if we ever inquired about them.
We tried to engage, perhaps to excess, in technical discussions attempting to explain why and how we chose to implement what we were proposing. ...
There were never any relevant technical exchanges. The discussion consisted of, we have decided to do things a certain way, no discussion, if you don't like that you should really consider doing something other than submitting to upstream Linux."
I don't know, dropping 17000 lines of code is probably not the best way to solicit technical discussions
(https://lore.kernel.org/lkml/20240826103728.3378-1-greg@enje... is the patch set in question)
(https://lore.kernel.org/lkml/20240826103728.3378-1-greg@enje... is the patch set in question)
That's version 4. Here's version 2, which looks like the first patch submission:
https://lore.kernel.org/linux-security-module/20230204050954...
https://lore.kernel.org/linux-security-module/20230204050954...
7000 is not a lot better.
Not everything can be broken down into 5 line patches. Some of the bigger features need bigger code. You can look at the impact radius and see if the patch is behind a feature flag to make a decision. In this case, it seems like it is elective and does not have any changes beyond what is self-contained.
I don’t follow the Linux kernel development process closely, but on most projects—open source or proprietary—that I’ve been involved in, dropping a big diff without having proposed or discussed anything about it beforehand would have been fairly unwelcome, even if it’s something that would be infeasible to break down smaller. I’d also argue that even quite substantial changes can be made with incremental patches, if you choose to do so.
There had probably been a lot of discussion in the background
The "every change can be a small patch, can be split in such" is part now of the Linux folklore IMHO. As in, a belief that people kinda heard about but nobody has concrete proof
Also do you know what would make it much easier to review long changes? Not using email patches
But I'm glad there's an good answer on "how to do it" in the thread https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home...
The "every change can be a small patch, can be split in such" is part now of the Linux folklore IMHO. As in, a belief that people kinda heard about but nobody has concrete proof
Also do you know what would make it much easier to review long changes? Not using email patches
But I'm glad there's an good answer on "how to do it" in the thread https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home...
> Not using email patches
GitHub issues with "load 450 hidden comments" on it? No threads, no comparisons between multiple submissions of the same patch, changes from rebasing impossible to separate from everything else? Having to drop anyway to the command line to merge a subset that has been reviewed? Encouraging squash merging makes it easier to work with long changes?
Email is complex and bare bones, but GitHub/GitLab reviews are a dumpster fire for anything that isn't trivial.
GitHub issues with "load 450 hidden comments" on it? No threads, no comparisons between multiple submissions of the same patch, changes from rebasing impossible to separate from everything else? Having to drop anyway to the command line to merge a subset that has been reviewed? Encouraging squash merging makes it easier to work with long changes?
Email is complex and bare bones, but GitHub/GitLab reviews are a dumpster fire for anything that isn't trivial.
> There had probably been a lot of discussion in the background
If that were the case then the patch would have a lot more CCs.
If that were the case then the patch would have a lot more CCs.
Then you have to discuss first, before throwing tousands of lines of code at somebody.
One of the first habits I learned at BigCo was to have a sense of the DAG in any work over 400 lines, so I could make patches arbitrarily large or small. Because whichever I chose, someone would complain eventually
Indeed, and that's exactly what the Rust for Linux guys are doing. They have Binder, multiple changes with various degrees of dependency on newer compilers, support for different kinds of drivers, and they are extracting them and sending them to Linux in small bits.
Okay, but how long is reasonable to take to tell someone that their patch is too big to be reviewed?
> We were meticulous in our submissions to avoid wasting maintainers time. We even waited two months without hearing a word before we sent an inquiry as to the status of one of the submissions. We were told, rather curtly, that anything we sent would likely be ignored if we ever inquired about them.
It's reasonable to ask that people make smaller-sized patches to get reviewed, and it's reasonable to have to rule out some things due to not having the bandwidth for it compared to other priorities, but it's pretty ridiculous to expect people to know that those are the reason their code isn't getting reviewed if they're not allowed to inquire once after two months of radio silence.
> We were meticulous in our submissions to avoid wasting maintainers time. We even waited two months without hearing a word before we sent an inquiry as to the status of one of the submissions. We were told, rather curtly, that anything we sent would likely be ignored if we ever inquired about them.
It's reasonable to ask that people make smaller-sized patches to get reviewed, and it's reasonable to have to rule out some things due to not having the bandwidth for it compared to other priorities, but it's pretty ridiculous to expect people to know that those are the reason their code isn't getting reviewed if they're not allowed to inquire once after two months of radio silence.
Totally. And also: the discussion must take place FIRST!
no feedback whatsoever for 2 months - just because it was 17k lines - and you are blindly defending it? if you don't know what you are posting & talking about, then maybe you shouldn't.
if someone is willing to put in the efforts to submit such a huge patch, how about just show them a little bit respect, I mean the minimum amount of respect, for such efforts and send them a one line reply asking them to break the patch into smaller ones.
surely that won't take more than 45 seconds. still too hard to get the point?
if someone is willing to put in the efforts to submit such a huge patch, how about just show them a little bit respect, I mean the minimum amount of respect, for such efforts and send them a one line reply asking them to break the patch into smaller ones.
surely that won't take more than 45 seconds. still too hard to get the point?
> if you don't know what you are posting & talking about, then maybe you shouldn't
I hate to appeal to authority, but I have been working with large cathedral-style open source projects (mostly three: GCC, QEMU, Linux itself) for about 20 years at this time and have been a maintainer for a Linux subsystem for 12. So I do know what I am posting and talking about.
The very fact that I had never learned about this subsystem from LWN, Linux Plumbers Conference, Linux Security Summit etc. means that the problem is not technical and is not with the maintainers not replying it.
A previous submission (7000 lines) did have some replies from the maintainers. Apparently instead of simplifying the submission it ballooned into something 150% larger. At some point I am not sure what the maintainers could do except ignoring it.
I hate to appeal to authority, but I have been working with large cathedral-style open source projects (mostly three: GCC, QEMU, Linux itself) for about 20 years at this time and have been a maintainer for a Linux subsystem for 12. So I do know what I am posting and talking about.
The very fact that I had never learned about this subsystem from LWN, Linux Plumbers Conference, Linux Security Summit etc. means that the problem is not technical and is not with the maintainers not replying it.
A previous submission (7000 lines) did have some replies from the maintainers. Apparently instead of simplifying the submission it ballooned into something 150% larger. At some point I am not sure what the maintainers could do except ignoring it.
Surely if there were insufficient established context for a reviewer to easily follow a large patch the correct response would be a swift rejection with a request that such context be established prior to submitting again.
It sounds like there was willingness to meet any requirements, but submitters end up in a position of not knowing what the requirements are and if they have met them or not.
It sounds like there was willingness to meet any requirements, but submitters end up in a position of not knowing what the requirements are and if they have met them or not.
It's very easy to develop tunnel vision when working remotely with people you've not even ever met. It's happened to me multiple times and there's a very high chance that this is happening here.
> At some point I am not sure what the maintainers could do except ignoring it.
Ignoring people is a childs approach to communication. If there is a problem, its your responsibility to communicate it. If you have communicated the issue and the other party is refusing to hear it, that is a different issue, but it is your responsibility to communicate.
Ignoring people is a childs approach to communication. If there is a problem, its your responsibility to communicate it. If you have communicated the issue and the other party is refusing to hear it, that is a different issue, but it is your responsibility to communicate.
Yes, as I wrote they had communicated it before. (BTW of course it's bazaar not cathedral... Brain fart for me).
17KLoC? Maybe he should consider they’re probably still reviewing it through bloody eyes. But seriously I wouldn’t want to review that much code.
I'd get mildly angry if someone sent a giant patch without having discussed with me first. (Not working with any kernel things) But a quicker "no, don't have time, probably never will" response would have been nice I guess?
A maintiner's perpsecitive on the above:
https://lore.kernel.org/rust-for-linux/20250208204416.GL1130...
https://lore.kernel.org/rust-for-linux/20250208204416.GL1130...
Important to note that Ted is extremely anti-Rust and literally shouted down someone irl that was doing a presentation on Rust in the Linux kernel.
The short of his rant is that he wants a "Code Of Standards for maintainers" in addition to a CoC, in order to witch hunt people he feels "gets in the way."
Yikes, this is EXACTLY what Linus was talking about except an order of magnitude worse!
Yikes, this is EXACTLY what Linus was talking about except an order of magnitude worse!
> The short of his rant…
This does not read as a rant at all to me. Rather it seeks to highlight a problem using an example from his own work and proposes a possible solution (with a previous caveat of “I don’t know how to fix this”).
> "Code Of Standards for maintainers" in addition to a CoC
He wants maintainers to behave in some pre-determined understandable fashion. He wants some accountability, and that seems reasonable to me. This is not a “maintainers must do what I want”, this is “let’s set basic expectations” and ensure people follow them. Whatever those should be.
> in order to witch hunt people he feels "gets in the way."
B does not follow A. You are simply straw-manning here, so I have nothing to say to it other than it’s a fallacious point.
This does not read as a rant at all to me. Rather it seeks to highlight a problem using an example from his own work and proposes a possible solution (with a previous caveat of “I don’t know how to fix this”).
> "Code Of Standards for maintainers" in addition to a CoC
He wants maintainers to behave in some pre-determined understandable fashion. He wants some accountability, and that seems reasonable to me. This is not a “maintainers must do what I want”, this is “let’s set basic expectations” and ensure people follow them. Whatever those should be.
> in order to witch hunt people he feels "gets in the way."
B does not follow A. You are simply straw-manning here, so I have nothing to say to it other than it’s a fallacious point.
> This is not a “maintainers must do what I want”, this is “let’s set basic expectations” and ensure people follow them. Whatever those should be.
But presumably it's not whatever they should be. It's what he wants them to be. And what should happen if they're not followed?
But presumably it's not whatever they should be. It's what he wants them to be. And what should happen if they're not followed?
His complaint is, in essence, that people will block technical proposals for nontechnical reasons, and that attempts to resolve this result in people complaining that you're talking about nontechnical things at all.
Few people like dealing with interpersonal conflict. They want to think that technical meritocracy wins the arguments.
But in that discussion, a maintainer said "I am going to try to sabotage this because I hate it.", and there's no technical argument to resolve that. And there's not really any route other than escalation to some kind of authority if there's not a common negotiation baseline.
"You can't reason someone out of a position they weren't reasoned into."
Few people like dealing with interpersonal conflict. They want to think that technical meritocracy wins the arguments.
But in that discussion, a maintainer said "I am going to try to sabotage this because I hate it.", and there's no technical argument to resolve that. And there's not really any route other than escalation to some kind of authority if there's not a common negotiation baseline.
"You can't reason someone out of a position they weren't reasoned into."
Ex falso quodlibet
>in order to witch hunt people he feels "gets in the way."
When has this ever happened with the Linux CoC? The only people who I've seen banging pots and pans together about the CoC are folks who like to sealion [1]
[1] https://en.wikipedia.org/wiki/Sealioning
When has this ever happened with the Linux CoC? The only people who I've seen banging pots and pans together about the CoC are folks who like to sealion [1]
[1] https://en.wikipedia.org/wiki/Sealioning
Looks like Dr Greg (not Greg KH) is just piling his own personal grievance on top of the drama. Saying "Jim are you listening?" makes me wonder who he's sniping at.
Speaking as an actual People Manager, his ideas sound pretty shallow.
Speaking as an actual People Manager, his ideas sound pretty shallow.
I'm not a "People Manager" -- what is shallow about the ideas?
Maybe Jim Zemlin, who is the executive director of the Linux Foundation and has nothing to do with Linux.
> Jim Zemlin, who is the executive director of the Linux Foundation and has nothing to do with Linux.
That sounds... Not good. Seems like like this is exactly what's wrong with... Well, not just this, but much of the "FOSS" world. (Maybe about since "Free Software" became "Open Source"?)
That sounds... Not good. Seems like like this is exactly what's wrong with... Well, not just this, but much of the "FOSS" world. (Maybe about since "Free Software" became "Open Source"?)
There are easy and good answers, just none that every single one would agree with, and that is the problem.
The current management model is based on consensus in some parts, and a dictatorship in others. Its not clear which parts are which because of sprawl, and non-responsiveness.
This is a core communication people issue. The problems arise because in consensus models, people are expected to adopt archetypical roles based somewhat on preference, but mostly on the needs of the group, towards productivity.
If no one else is doing that type of role, someone will be forced into doing it, and will adopt characteristics of that role, regardless of their personal opinions about it.
When they get punished for fulfilling the role, you lose people.
> doesn't mean we should throw our hands up and consider things "unfixable" either.
The given structure is unfixable, because it sets the stage for a trauma loop where actions can't take place without people who are expected to fulfill a role to meet consensus, but in doing so they get punished for volunteering.
There is no way around this structure so long as you use a consensus model in whole or part, in dysfunctional groups the people involved either fail to communicate or worse there are members that impose coercive cost by assuming the unproductive roles so no action happens while resources are wasted.
This really is basic stuff covered in your college level intro to communications coursework.
For those wanting to know more about this, you can read more about the roles at the link below.
https://pressbooks.pub/smallgroup/chapter/roles/
The current management model is based on consensus in some parts, and a dictatorship in others. Its not clear which parts are which because of sprawl, and non-responsiveness.
This is a core communication people issue. The problems arise because in consensus models, people are expected to adopt archetypical roles based somewhat on preference, but mostly on the needs of the group, towards productivity.
If no one else is doing that type of role, someone will be forced into doing it, and will adopt characteristics of that role, regardless of their personal opinions about it.
When they get punished for fulfilling the role, you lose people.
> doesn't mean we should throw our hands up and consider things "unfixable" either.
The given structure is unfixable, because it sets the stage for a trauma loop where actions can't take place without people who are expected to fulfill a role to meet consensus, but in doing so they get punished for volunteering.
There is no way around this structure so long as you use a consensus model in whole or part, in dysfunctional groups the people involved either fail to communicate or worse there are members that impose coercive cost by assuming the unproductive roles so no action happens while resources are wasted.
This really is basic stuff covered in your college level intro to communications coursework.
For those wanting to know more about this, you can read more about the roles at the link below.
https://pressbooks.pub/smallgroup/chapter/roles/
This part is wild. Some people get in so deep they cannot see the forest from the trees.
> there is the tangible risk of stifling innovation and Linux is the only place that innovation can occur in the operating system space.
The proponents think the value of their "innovation" is obvious, but it is not.
Is it innovative? Is it valuable? Is it worth the cost? Who is it valuable to?
I don't see why the kernel team should be obligated to react in any particular way to a random submission.
Is it innovative? Is it valuable? Is it worth the cost? Who is it valuable to?
I don't see why the kernel team should be obligated to react in any particular way to a random submission.
I think "Code of Civility" is what Dr. G was describing. Conduct presupposes civility, but acceptable online discourse has changed amongst new internet natives raised in the era of moral totalitarianism, aggression as a service, and popular outrage incubators.
KennyBlanken(2)
When i was the focus of the rust community, and trending #1 on HN, i simply deleted my repos and disappeared.
Some people in that community reflexively see a conspiracy or invoke the CoC or use whatever other non technical tools they find to derail the discussion.
It's not even that they're always wrong or that I directly oppose the culture they want to have, but the shotgun blast of drama that this comes with is just so much effort to navigate that i decided to just never contribute to rust again.
Some people in that community reflexively see a conspiracy or invoke the CoC or use whatever other non technical tools they find to derail the discussion.
It's not even that they're always wrong or that I directly oppose the culture they want to have, but the shotgun blast of drama that this comes with is just so much effort to navigate that i decided to just never contribute to rust again.
I think this is an important data point, too:
Gunthorpe [nvidia]: https://lore.kernel.org/rust-for-linux/20250130154646.GA2298...
Basically, there is concern that even with a declaration that Rust-for-Linux devs will maintain this (and potentially every other) cross-language API translation layer file, the demarcation point between C and Rust isn't sufficient, and is causing C developers lag or headaches by having PRs rejected because of Rust-side failures. I don't see how that can be fixed without wholesale buy-in to Rust of enough kernel devs that they can fix whatever Rust problems are created by C API changes. Or Linus will have to accept PRs that break Rust-enabled builds. The R4L devs, by themselves, don't have the bandwidth to keep up. Even if they can rapidly fix problems, that adds potential friction to every C API change.
Hellwig may not be communicating in a good way, but he might be right, unfortunately. Linux may need to stay as a C-only codebase until an AI language-translation tool is good enough to do things like maintain the Rust API translation layer itself. Or until basically all maintainers learn and accept Rust.
Gunthorpe [nvidia]: https://lore.kernel.org/rust-for-linux/20250130154646.GA2298...
Basically, there is concern that even with a declaration that Rust-for-Linux devs will maintain this (and potentially every other) cross-language API translation layer file, the demarcation point between C and Rust isn't sufficient, and is causing C developers lag or headaches by having PRs rejected because of Rust-side failures. I don't see how that can be fixed without wholesale buy-in to Rust of enough kernel devs that they can fix whatever Rust problems are created by C API changes. Or Linus will have to accept PRs that break Rust-enabled builds. The R4L devs, by themselves, don't have the bandwidth to keep up. Even if they can rapidly fix problems, that adds potential friction to every C API change.
Hellwig may not be communicating in a good way, but he might be right, unfortunately. Linux may need to stay as a C-only codebase until an AI language-translation tool is good enough to do things like maintain the Rust API translation layer itself. Or until basically all maintainers learn and accept Rust.
Greg replied and explained that this is a mischaracterization https://lore.kernel.org/rust-for-linux/2025013030-gummy-cosm...
You are misrepresenting the current state. The thread was unfortunately diverted before Jason's question received an appropriate response and conclusion: https://lore.kernel.org/rust-for-linux/20250131135421.GO5556...
> Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not.
> Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders".
> It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build.
The matter and the question at heart is still unsettled. The answer of whether or not Rust being in a broken state is a blocker for working and valid C code will hopefully be addressed by the end of this cycle of development. Either the patches are accepted and Rust is truly allowed to be broken or the patches will not be accepted due to breaking the Rust builds. If it is the latter, as many of the C developers fear, that is the exact burden being placed upon them that they have been stressing very loudly that they have no interest in taking on. And once other maintainers see this, what is the inevitable response to this metastasization? Comments like those from Ted and Christoph will pale in comparison. The only bright side might be that this finally accelerates the inevitable demise of this failed Rust experiment so that all parties can move on with their business.
> Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not.
> Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders".
> It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build.
The matter and the question at heart is still unsettled. The answer of whether or not Rust being in a broken state is a blocker for working and valid C code will hopefully be addressed by the end of this cycle of development. Either the patches are accepted and Rust is truly allowed to be broken or the patches will not be accepted due to breaking the Rust builds. If it is the latter, as many of the C developers fear, that is the exact burden being placed upon them that they have been stressing very loudly that they have no interest in taking on. And once other maintainers see this, what is the inevitable response to this metastasization? Comments like those from Ted and Christoph will pale in comparison. The only bright side might be that this finally accelerates the inevitable demise of this failed Rust experiment so that all parties can move on with their business.
Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems.
That one bug happened one time does not mean that the promise is broken. To be clear, it's a bad thing, but acting like this means the entire working rules are a lie is overreacting.
That one bug happened one time does not mean that the promise is broken. To be clear, it's a bad thing, but acting like this means the entire working rules are a lie is overreacting.
> That one bug happened one time does not mean that the promise is broken.
It's not been once. Don't you understand that is why things have gotten to this point? Are you aware of how the developers have been using Coccinelle in their workflows and how many subsystems support it? And are you aware that the Coccinelle for Rust implementation is constantly in a dire state? Have some empathy for the folks who have had their workflows broken and burdens increased because of it.
> Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems.
Clarity will be communicated by the result of this patch set.
It's not been once. Don't you understand that is why things have gotten to this point? Are you aware of how the developers have been using Coccinelle in their workflows and how many subsystems support it? And are you aware that the Coccinelle for Rust implementation is constantly in a dire state? Have some empathy for the folks who have had their workflows broken and burdens increased because of it.
> Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems.
Clarity will be communicated by the result of this patch set.
> Have some empathy for the folks who have had their workflows broken and burdens increased because of it.
Okay. Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?
Okay. Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?
Kernel maintainers aren't doing anything to R4L folks except where their activities intersect with the upstream linux kernel. Your analogy isn't right.
R4L folks thought that preliminary R4L infrastructure being accepted upstream meant that all the changes they needed in the future would be accepted easily as well, and now that there are concerns from subsystem maintainers, a few R4L folks are playing the dramatic victim card.
From what I understand, market pressures are causing R4L folks to panic. If they can't get more R4L stuff upstream, people can't ship Rust drivers, and R4L development falls apart.
That's not kernel maintainers' problem, though. They have a job to do to, and it has nothing to do with Rust kernel drivers except as far as they're persuaded Rust drivers help the linux community overall and will be maintainable without unacceptably disrupting their tool-assisted workflows. Several of them have concluded, so far, that R4L PRs will unacceptably disrupt existing workflows.
That's where R4L has failed. They've failed to persuade subsystem maintainers that some added headaches/retooling/efficiency-loss is worth it to enable Rust drivers. Which drivers, and who wants to use them? Perhaps the potential downstream users of those drivers can talk with kernel devs, persuade them it's really valuable, and figure out a plan?
R4L folks thought that preliminary R4L infrastructure being accepted upstream meant that all the changes they needed in the future would be accepted easily as well, and now that there are concerns from subsystem maintainers, a few R4L folks are playing the dramatic victim card.
From what I understand, market pressures are causing R4L folks to panic. If they can't get more R4L stuff upstream, people can't ship Rust drivers, and R4L development falls apart.
That's not kernel maintainers' problem, though. They have a job to do to, and it has nothing to do with Rust kernel drivers except as far as they're persuaded Rust drivers help the linux community overall and will be maintainable without unacceptably disrupting their tool-assisted workflows. Several of them have concluded, so far, that R4L PRs will unacceptably disrupt existing workflows.
That's where R4L has failed. They've failed to persuade subsystem maintainers that some added headaches/retooling/efficiency-loss is worth it to enable Rust drivers. Which drivers, and who wants to use them? Perhaps the potential downstream users of those drivers can talk with kernel devs, persuade them it's really valuable, and figure out a plan?
> a few R4L folks are playing the dramatic victim card.
Not just 'a few R4L folks', these are basically the spearhead of the effort. And it hasn't been a single occurrence, we now have seen two of those Rust developers resign from the effort out of pure frustration from the entrenched, heels-in-the-sand attitude from kernel maintainers.
The same thing has happened in the past. I will point to TuxOnIce, which got stonewalled by a stubborn maintainer. It would have moved most suspend and hibernation code to userspace, where it would have been easier to maintain and iterate. Or right now we have two divergent RAM compression paths (Zram and Zswap). There are patches for Zram to use the unified Zpool API, but the Zram maintainer refuses to integrate these for absolutely no solid technical reason.
It seems that the R4L peoples are fine with doing any effort required, as long as they know it is not in vain. So far, comments akin to "language barriers in the kernel are a cancer" and "I will do everything to prevent/sabotage this" do not exactly build trust in that regard.
As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust? This is not a dire ask for someone in the software world, your job will often ask this of you. And I can't imagine the maintainers haven't ever dabbled in other languages and/or aren't capable enough to learn a second language.
I understand the fear that saying "ok, we can do more languages than one" opens up the door to a third and fourth language down the road, but that seems unlikely. There's a reason Rust has passed Linus' sniff test where no other language has so far.
> Which drivers, and who wants to use them?
Short term it seems mostly GPU drivers.
Long, looong term (multiple decades?) the plan is probably to rewrite more important parts of the kernel, to significantly increase memory safety.
Not just 'a few R4L folks', these are basically the spearhead of the effort. And it hasn't been a single occurrence, we now have seen two of those Rust developers resign from the effort out of pure frustration from the entrenched, heels-in-the-sand attitude from kernel maintainers.
The same thing has happened in the past. I will point to TuxOnIce, which got stonewalled by a stubborn maintainer. It would have moved most suspend and hibernation code to userspace, where it would have been easier to maintain and iterate. Or right now we have two divergent RAM compression paths (Zram and Zswap). There are patches for Zram to use the unified Zpool API, but the Zram maintainer refuses to integrate these for absolutely no solid technical reason.
It seems that the R4L peoples are fine with doing any effort required, as long as they know it is not in vain. So far, comments akin to "language barriers in the kernel are a cancer" and "I will do everything to prevent/sabotage this" do not exactly build trust in that regard.
As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust? This is not a dire ask for someone in the software world, your job will often ask this of you. And I can't imagine the maintainers haven't ever dabbled in other languages and/or aren't capable enough to learn a second language.
I understand the fear that saying "ok, we can do more languages than one" opens up the door to a third and fourth language down the road, but that seems unlikely. There's a reason Rust has passed Linus' sniff test where no other language has so far.
> Which drivers, and who wants to use them?
Short term it seems mostly GPU drivers.
Long, looong term (multiple decades?) the plan is probably to rewrite more important parts of the kernel, to significantly increase memory safety.
> language barriers in the kernel are a cancer
Well they are. Second class citizens like this just cause problems.
> As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust?
Are the Rust folks planning to pay the existing kernel developers for spending that time? Because otherwise it should be up to those existing maintainers to decide and not something anyone else gets to demand.
Overall this just sounds like people crying that their hostile takeover of an existing project is being met with resistance.
Well they are. Second class citizens like this just cause problems.
> As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust?
Are the Rust folks planning to pay the existing kernel developers for spending that time? Because otherwise it should be up to those existing maintainers to decide and not something anyone else gets to demand.
Overall this just sounds like people crying that their hostile takeover of an existing project is being met with resistance.
> > a few R4L folks are playing the dramatic victim card.
> Not just 'a few R4L folks', these are basically the spearhead of the effort.
A "spearhead" is by definition a few people.
> As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust?
If they want to contribute to the Linux kernel, would it really be so horrible for these Rust programmers to learn the language the kernel is written in?
> There's a reason Rust has passed Linus' sniff test where no other language has so far.
Doesn't seem it has, really.
> the plan is probably to rewrite more important parts of the kernel
So just fork it and rewrite it all in Rust.
> Not just 'a few R4L folks', these are basically the spearhead of the effort.
A "spearhead" is by definition a few people.
> As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust?
If they want to contribute to the Linux kernel, would it really be so horrible for these Rust programmers to learn the language the kernel is written in?
> There's a reason Rust has passed Linus' sniff test where no other language has so far.
Doesn't seem it has, really.
> the plan is probably to rewrite more important parts of the kernel
So just fork it and rewrite it all in Rust.
No, because they are the once choosing to add this complexity to an existing project because of their own interests/ideals.
Calling memory safety an 'ideal' is like calling back-ups an 'ideal'. You can cast it off as a "nice to have", until you get bitten in the ass by a lack of it.
To quote myself[1]: I don't get why those Rustafaris do this in the first place. Like, if you want to contribute to a piece of software written in C, then write your contributions in C. If, on the other hand, you want a Linux kernel in Rust... Then just fork it and rewrite it in Rust. It's not as if that were a new idea, is it? Heck, most days it feels like about half the top headlines here are “<Software X> rewritten in Rust!” So why don't they just do that in stead of this constant drama???
[1]: https://news.ycombinator.com/item?id=42993961
[1]: https://news.ycombinator.com/item?id=42993961
> Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?
But the thing is, the kernel isn't "the R4L folks"' "fuel tank", is it? Doesn't the very name you use, "kernel maintainers", tell you that that's their "fuel tank"? Seems the people pouring sand into that are "the R4L folks".
But the thing is, the kernel isn't "the R4L folks"' "fuel tank", is it? Doesn't the very name you use, "kernel maintainers", tell you that that's their "fuel tank"? Seems the people pouring sand into that are "the R4L folks".
I'm not sure this is fundamentally different from e.g. a complex filesystem implementation relying on a specific MM or VFS or whatever API, and a "C developer" wanting to change that API. Just because the callers are in C doesn't necessarily make the global change easy.
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.
I am aware. Doesn't mean it's not an option, or even a bad idea. Or maybe there is a third option; I don't know.
By the way: I don't agree with Hellwig, insofar I can judge things, I'm just saying his opinion is valid, and that "Linus agreed on Rust, so therefore we can merge this patch" is not really a valid argument.
By the way: I don't agree with Hellwig, insofar I can judge things, I'm just saying his opinion is valid, and that "Linus agreed on Rust, so therefore we can merge this patch" is not really a valid argument.
It's just really, really dumb to both a) have rust drivers in the kernel and b) not merge this patch. It's just obviously stupid.
If you start with the assumption of a), there are no valid technical challenges to merging it. It's just better for everyone. Before Hellwig put his foot down as "not merging because rust sucks", he made a series of technical arguments against the patch, which were all transparently bullshit. It was those arguments that really raised such a furor, instead of all the other ways some C devs have disdained rust in the kernel in the past, because they were obviously made in bad faith. And when he was called out for them, he just went full "no rust in kernel".
If you start with the assumption of a), there are no valid technical challenges to merging it. It's just better for everyone. Before Hellwig put his foot down as "not merging because rust sucks", he made a series of technical arguments against the patch, which were all transparently bullshit. It was those arguments that really raised such a furor, instead of all the other ways some C devs have disdained rust in the kernel in the past, because they were obviously made in bad faith. And when he was called out for them, he just went full "no rust in kernel".
> Before Hellwig put his foot down as "not merging because rust sucks"
He didn't say this at all. He explicitly and repeatedly said he has no problems with Rust as a language.
And you can't just assert "there are no valid technical reasons". Just because you don't agree with the objections, or even think they're dumb, doesn't mean you can just dismiss them and start ascribing bad faith motives.
He didn't say this at all. He explicitly and repeatedly said he has no problems with Rust as a language.
And you can't just assert "there are no valid technical reasons". Just because you don't agree with the objections, or even think they're dumb, doesn't mean you can just dismiss them and start ascribing bad faith motives.
It's pretty clear that the battle over rust is a power struggle. You can't take any of it at face value
So what are you saying? That it's okay to just invent quotes and spread misinformation about people, based on what you suspect their true thoughts might be?
You’re the one doing that by pretending that Hellwig is acting contrary to his own statements.
wait a second, I thought you are the one labelling people as "toxic" when completely ignoring the context that really matters.
He literally called "Rust" a "cancer".
He literally did not. He literally explicitly said right there in the (in)famous "cancer" message that it didn't refer to Rust as a language.[1]
"And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade)."
Stop spreading this kind of misinformation.
And no, I don't think he came off very well here, but please, give it a good faith reading.[2]
[1]: https://lwn.net/ml/all/[email protected]/
[2]: https://news.ycombinator.com/item?id=42977720
"And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade)."
Stop spreading this kind of misinformation.
And no, I don't think he came off very well here, but please, give it a good faith reading.[2]
[1]: https://lwn.net/ml/all/[email protected]/
[2]: https://news.ycombinator.com/item?id=42977720
care to explain why the following patch that touches nothing got rejected?
rust/bindings/bindings_helper.h | 1 +
rust/kernel/dma.rs | 271 ++++++++++++++++++++++++++++++++
rust/kernel/lib.rs | 1 +
rejecting such patch is the exact cancer that need to cured. stop misleading people.
rust/bindings/bindings_helper.h | 1 +
rust/kernel/dma.rs | 271 ++++++++++++++++++++++++++++++++
rust/kernel/lib.rs | 1 +
rejecting such patch is the exact cancer that need to cured. stop misleading people.
The reason patch got rejected is super simple: because this wrapper not lives in specific driver and depends on DMA subsystem internal API.
And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel. And if said wrapper accepted then maintaner of DMA will have to make sure that all patches he accepts also fix Rust parts.
So he just dont want extra burden for himself.
And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel. And if said wrapper accepted then maintaner of DMA will have to make sure that all patches he accepts also fix Rust parts.
So he just dont want extra burden for himself.
> because this wrapper not lives in specific driver and depends on DMA subsystem internal API.
if multiple rust based drivers all need to have DMA support, what should they do? each come up with their own little magic?
> And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel.
this has been explained like 10+ times in this thread - it was made crystal clear to the DMA maintainer that he/she doesn't need to maintain the rust stuff, it is totally okay to break it.
> So he just dont want extra burden for himself
he can just resign. simple and period. no one is ever forcing him/her to be the maintainer when he/she is literally forcing other people to stop developing Linux support for the only powerful & affordable ARM machine for home use.
if multiple rust based drivers all need to have DMA support, what should they do? each come up with their own little magic?
> And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel.
this has been explained like 10+ times in this thread - it was made crystal clear to the DMA maintainer that he/she doesn't need to maintain the rust stuff, it is totally okay to break it.
> So he just dont want extra burden for himself
he can just resign. simple and period. no one is ever forcing him/her to be the maintainer when he/she is literally forcing other people to stop developing Linux support for the only powerful & affordable ARM machine for home use.
[deleted]
> what should they do?
Sorry to ask, but couldn't it be solved with cargo? I hear all the time about the benefits of Rust tooling and zero-cost abstractions.
Why can't a driver just pull/include the latest-dma-bindings crate and glue the gap with zero-cost abstractions?
If kernel DMA code/API changes, then nothing breaks in the kernel (hopefully) and the "Rust devs will quickly solve the changes" theory can be really proven and tested by quickly updating the bindings AND the updating the drivers.
Sorry to ask, but couldn't it be solved with cargo? I hear all the time about the benefits of Rust tooling and zero-cost abstractions.
Why can't a driver just pull/include the latest-dma-bindings crate and glue the gap with zero-cost abstractions?
If kernel DMA code/API changes, then nothing breaks in the kernel (hopefully) and the "Rust devs will quickly solve the changes" theory can be really proven and tested by quickly updating the bindings AND the updating the drivers.
> that it didn't refer to Rust as a language.
No, he didnt refer to Rust as cancer, but to Rust in the Linux kernel / the R4L project.
No, he didnt refer to Rust as cancer, but to Rust in the Linux kernel / the R4L project.
I beleive he clarified in the same sentence that he was not calling the language Rust cancer... to quote "where this cancer explicitly is a cross-language codebase and not Rust itself, just to escape the flameware brigade"
> He didn't say this at all.
Okay, sorry. He just said there should be no rust in the kernel.
You can ascribe bad faith motivations when someone presents technical objections that are already fully answered in the patch that was submitted, and when this is pointed out, they admit that, but don't retract their objections.
The original objections are specifically not a case of differing values or design ideas. They are nonsensical, the equivalent of 1 = 2.
Okay, sorry. He just said there should be no rust in the kernel.
You can ascribe bad faith motivations when someone presents technical objections that are already fully answered in the patch that was submitted, and when this is pointed out, they admit that, but don't retract their objections.
The original objections are specifically not a case of differing values or design ideas. They are nonsensical, the equivalent of 1 = 2.
> Okay, sorry. He just said there should be no rust in the kernel.
That's also not what he said; it's "no Rust in kernel/dma". He pretty much explicitly said it's okay for drivers to do their thing in Rust, but with their own wrappers. You can consider that dumb, but you can't shorten that to "no Rust in the kernel".
And "I replied to your objections, therefore the matter is settled" is arrogant beyond belief. People can disagree, you know, because they have different priorities, different preferences, different perspectives, etc.
That's also not what he said; it's "no Rust in kernel/dma". He pretty much explicitly said it's okay for drivers to do their thing in Rust, but with their own wrappers. You can consider that dumb, but you can't shorten that to "no Rust in the kernel".
And "I replied to your objections, therefore the matter is settled" is arrogant beyond belief. People can disagree, you know, because they have different priorities, different preferences, different perspectives, etc.
No he did say he doesn’t want rust in Linux at all. Now I understand that he didn’t say “I won’t allow rust to be in Linux”, which is a useful distinction to make. But let’s not pretend like he didn’t say “rust shouldn’t be in Linux” at all.
https://lwn.net/ml/all/[email protected]/
https://lwn.net/ml/all/[email protected]/
He said no Rust (or any other language except C) in any core code. Notably the patch was not eve being added to kernel/dma
I think he even hates non-C code in the drivers, he just cares less about that. But his position is that kernel maintenance will only work longterm if it's all a single language (C).
He literally said this:
> Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.
https://lwn.net/ml/all/[email protected]/
> Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.
https://lwn.net/ml/all/[email protected]/
> 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/[email protected]/
https://lwn.net/ml/all/[email protected]/
please stop spreading such highly misleading nonsense. look at what is black and white. blindly defending such toxic people is not doing linux any good.
> That's also not what he said; it's "no Rust in kernel/dma". He pretty much explicitly said it's okay for drivers to do their thing in Rust, but with their own wrappers. You can consider that dumb, but you can't shorten that to "no Rust in the kernel".
Have you actually taken a look at the patch?
There was NO RUST CODE ADDED TO kernel/dma, they wanted to add a dma wrapper to a rust/ folder.
Have you actually taken a look at the patch?
There was NO RUST CODE ADDED TO kernel/dma, they wanted to add a dma wrapper to a rust/ folder.
> "I replied to your objections, therefore the matter is settled" is arrogant beyond belief. People can disagree, you know, because they have different priorities, different preferences, different perspectives, etc.
I'm sorry for not being clearer, but that is specifically not what is going on. The objections were of factual, technical nature. As in, "do not do X". The problem is that the code in question was not doing X, and it was not doing anything that could be construed as doing X. The objections did not arise from differences in priorities, preferences, or perspectives, they were just factually wrong.
I'm sorry for not being clearer, but that is specifically not what is going on. The objections were of factual, technical nature. As in, "do not do X". The problem is that the code in question was not doing X, and it was not doing anything that could be construed as doing X. The objections did not arise from differences in priorities, preferences, or perspectives, they were just factually wrong.
Just curious. Why can't the wrapper be an independent library outside of the DMA infrastructure? It can still be used by all rust drivers.
I think Hellwig is against moving the wrapper into the DMA project that he's forced to maintain it.
I think Hellwig is against moving the wrapper into the DMA project that he's forced to maintain it.
No, Hellwig also Nack'd the patch that added the wrapper to an independent library outside of the core C DMA directory.
Why would he do that? He has no control over an independent library outside of C DMA? I thought he said he's fine with any drivers written in Rust. Just that the maintenance of such including any wrapper cannot fall into C DMA's lap.
> Why would he do that?
It's a great question. I mean, my read of it is he hates the idea of Rust4Linux and is using his position to obstruct.
> He has no control over an independent library outside of C DMA?
Apparently not.
> Just that the maintenance of such including any wrapper cannot fall into C DMA's lap.
The patch he rejected did not add any code to C DMA, nor C DMA's directory (kernel/dma). Just:
It's a great question. I mean, my read of it is he hates the idea of Rust4Linux and is using his position to obstruct.
> He has no control over an independent library outside of C DMA?
Apparently not.
> Just that the maintenance of such including any wrapper cannot fall into C DMA's lap.
The patch he rejected did not add any code to C DMA, nor C DMA's directory (kernel/dma). Just:
rust/bindings/bindings_helper.h | 1 +
rust/kernel/dma.rs | 271 ++++++++++++++++++++++++++++++++
rust/kernel/lib.rs | 1 +
This isn't even just your read of it; as other people in this thread have pointed out, he's pretty explicitly stated it at this point.
> Why would he do that? He has no control over an independent library outside of C DMA?
That is the crux of the entire drama and why R4L developers got upset at Christoph in the first place, and asked Linus to intervene.
That is the crux of the entire drama and why R4L developers got upset at Christoph in the first place, and asked Linus to intervene.
No, he said very explicitly that he is against any Rust code in Linux whatsoever. He doesn't have any beef with Rust, the same would be true for him if people tried to add C++ or Pascal or Ada or any other kind of drivers or infra in Linux: he believes that the project will be much harder to maintain if it's not 100% pure C (and assembly).
Here is a link to this explicit claim: https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...
Here is a link to this explicit claim: https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...
I'm usually very critical of how Torvolds treats the people around him and the culture he maintains but this is a rare case when I'm not really against Torvalds on this.
I've had to remove Hector's postings from my feeds because he just constantly bitches and complains about pretty much everything. He's capable, smart, and is doing more than anybody ever will for Apple hardware. But he desperately needs to Stop Posting. Without anybody he works with regularly to give him a reality check, I don't think he's going to change course.
I think Hector has some valid complaints about the contribution process to the kernel, I know. It fucking sucks ass and I've given up on trying. But screaming the way he does is counter productive to improving it
I'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
ToucanLoucan(1)
I feel the exact same. Marcan has done amazing work, and his random blog entries etc have saved me hours of debugging time in the past. But jeez, it is really painful to see him say absolute nonsense like "If shaming on social media does not work, then tell me what does, because I'm out of ideas." - he has gotta Stop Posting and keep those kinds of thoughts away from his keyboard.
If Linus thinks that the social media angle is wrong, he should defuse situations before they become explosive because even if one of the devs didn't bring up the drama, there are dozens of news companies that would have printed up articles the second they found the discussion anyway.
Linus should have stepped in long before a maintainer blew their stack and started throwing out ultimatums. Once that happened, Linus could have still stopped everything with one sentence -- "Let me look into this.", but he did not.
Linus only got an opinion once things blew up on social media which proves that social media works which is the exact opposite of what he says he wants (and will just encourage more of the same).
Linus should have stepped in long before a maintainer blew their stack and started throwing out ultimatums. Once that happened, Linus could have still stopped everything with one sentence -- "Let me look into this.", but he did not.
Linus only got an opinion once things blew up on social media which proves that social media works which is the exact opposite of what he says he wants (and will just encourage more of the same).
> Linus only got an opinion once things blew up on social media which proves that social media works which is the exact opposite of what he claims.
That is really an apt point. You can't condition people one way, and tell them to do the opposite.
That is really an apt point. You can't condition people one way, and tell them to do the opposite.
And it's not _that_ long ago since Linus was King of the arrogant and rude flame posts on what's effectively hos own "social media", the linux kernel mailing list.
10 years back, Linus _was_ "that guy". And it worked, extremely effectively, if you measure success by the ability to stamp on someone else's technical contribution by ridiculing them in public instead of making a convincing technical defense of his position in the discussion.
https://github.com/corollari/linusrants
10 years back, Linus _was_ "that guy". And it worked, extremely effectively, if you measure success by the ability to stamp on someone else's technical contribution by ridiculing them in public instead of making a convincing technical defense of his position in the discussion.
https://github.com/corollari/linusrants
You can expect professionals to not act like trained monkeys.
What happens when Linus retires (or god forbid dies)? He can't defuse those situations forever, there needs to be some sort of process.
Someone will have to take over Linus' role. There's no way that kernel development can work without a person in charge, at least not in anyway that is remotely similar to today.
Not being remotely similar to today could be a very good thing.
If you can point to a better model of a more successful kernel that would be interesting to read about.
FreeBSD? But there is nothing fundamentally different in open-source project management between a kernel and any other large open-source project. The linux code base is the largest, but not by a large margin. Chrome, GCC, OpenOffice, Android (excluding the linux part obvs.), and the various BSDs are all comparable in scope, complexity, lines of code, and number of contributors. Only linux is (in)famous for having a toxic and unproductive culture.
Odd. Linux is by far the most/largest/longest successful project. Or do you have a counterexample?
I assume we're only comparing to operating systems, as I would say that e.g. Chrome as an open-source project is just as impactful if not more so. But generally speaking the Linux support experience is decidedly worse than *BSD or any proprietary OS. It is much harder to get patches upstreamed, and many hardware have errata that never get fixed. (If you haven't experienced this, it might be because companies like canonical and red hat maintain their own patches to support their customers.)
> But generally speaking the Linux support experience is decidedly worse than *BSD or any proprietary OS.
Going to have to disagree on that one.
Going to have to disagree on that one.
Good for who? External parties that want to force their vision of what the project should be?
Well... the maintainer also shouldn't blow their stack
You can certainly imagine ways an authority figure could have defused a situation of a maintainer blowing their stack, but your framing kinda absolves the maintainer of any accountability for their actions.
A team member who needs a lot of defusing is doing something wrong, and needs to learn how to defuse themselves.
You can certainly imagine ways an authority figure could have defused a situation of a maintainer blowing their stack, but your framing kinda absolves the maintainer of any accountability for their actions.
A team member who needs a lot of defusing is doing something wrong, and needs to learn how to defuse themselves.
[deleted]
Linus, as someone far removed from LKML, seems like he hates external visibility of what he wants to be effectively "internal" discussion more than anything else.
Not in the sense of "he wants the mailing lists private", but in the sense that "he doesn't want public complaint about private discussions", which feels like an evolution of "technical merit should win", as a position.
Not in the sense of "he wants the mailing lists private", but in the sense that "he doesn't want public complaint about private discussions", which feels like an evolution of "technical merit should win", as a position.
I dont think Linus gives a damn about any social media drama. Why should he care?
It just ("just") sounds like he's out of alignment with the kernel development process.
That shouldn't be too surprising - I mean, its an old project with a whole lot of technical baggage. Projects tend to slow down over time. And that is legitimately really frustrating when you want to shake things up or push for change. I would be rubbish as a linux kernel developer. I have the wrong temperament for it.
There's a reason why some tech companies interview for both technical skill and culture fit. Sounds like he's got the technical chops, but he's not a good fit for linux.
And when you're in a situation like that, your choices are essentially Voice or Exit. Voice is to do what he's tried to do - kick up a fuss about the problems to try and get them fixed. Thats a skill on its own - and it sounds like he's not been super effective at that. The other option is Exit. Which of course - sensibly, he's now done.
> he has gotta Stop Posting and keep those kinds of thoughts away from his keyboard.
Nah. Bottling this stuff up is a bad long term play. You end up getting bitter, cynical and resentful. I think we've all worked with people like that, and its miserable - both for the person and for their coworkers. I think its better to shoot your shot. Even if you miss - as he has here - you learn a lot about yourself and the world. And there's no shortage of interesting projects out there to work on. Pick something that matches your speed.
That shouldn't be too surprising - I mean, its an old project with a whole lot of technical baggage. Projects tend to slow down over time. And that is legitimately really frustrating when you want to shake things up or push for change. I would be rubbish as a linux kernel developer. I have the wrong temperament for it.
There's a reason why some tech companies interview for both technical skill and culture fit. Sounds like he's got the technical chops, but he's not a good fit for linux.
And when you're in a situation like that, your choices are essentially Voice or Exit. Voice is to do what he's tried to do - kick up a fuss about the problems to try and get them fixed. Thats a skill on its own - and it sounds like he's not been super effective at that. The other option is Exit. Which of course - sensibly, he's now done.
> he has gotta Stop Posting and keep those kinds of thoughts away from his keyboard.
Nah. Bottling this stuff up is a bad long term play. You end up getting bitter, cynical and resentful. I think we've all worked with people like that, and its miserable - both for the person and for their coworkers. I think its better to shoot your shot. Even if you miss - as he has here - you learn a lot about yourself and the world. And there's no shortage of interesting projects out there to work on. Pick something that matches your speed.
> some tech companies interview for both technical skill and culture fit. Sounds like he's got the technical chops, but he's not a good fit for linux.
You're right.
To fit with historical "linux culture" he needs to be much more aggressive and rude.
He needed to lead with something more inline with linux project leadership's examples, perhaps something like: Christoph " ... should be retroactively aborted. Who the f*ck does idiotic things like that? How did they noty die as babies, considering that they were likely too stupid to find a tit to suck on?"
https://github.com/corollari/linusrants
You're right.
To fit with historical "linux culture" he needs to be much more aggressive and rude.
He needed to lead with something more inline with linux project leadership's examples, perhaps something like: Christoph " ... should be retroactively aborted. Who the f*ck does idiotic things like that? How did they noty die as babies, considering that they were likely too stupid to find a tit to suck on?"
https://github.com/corollari/linusrants
Yeah, reading these back in 2025 it's amazing Linux got as far as it did with Linus being like this for a long time.
But this is just frustration coming out. I don’t think for a moment he expected shaming on social media to work.
But it did work. Linus actually got involved because of it...
If we were dealing with a toddler, one could blame the parent for rewarding their misbehaviour attention... an adult developer not so much
Like others have mentioned it was really the hypocrisy of this guy that made me side against him, not so much whether he was right or wrong.
He's a known, certified, card-carrying obnoxious rebel coming pretty close to violating a "Code of Conduct" himself pretty well every other day then his beef with Christoph about wanting to "mix languages" (C and Rust, of course) and Christoph said "I'm maintaining it and I'm not doing it, it's like a cancer" (I'm paraphrasing and he was notably not talking about Rust itself but "mixing" C and Rust) then Martin exploding and screaming that Christoph said "cancer" and that he had violated a Code of Conduct. Please.
A serious case of the pot calling the kettle black.
He's a known, certified, card-carrying obnoxious rebel coming pretty close to violating a "Code of Conduct" himself pretty well every other day then his beef with Christoph about wanting to "mix languages" (C and Rust, of course) and Christoph said "I'm maintaining it and I'm not doing it, it's like a cancer" (I'm paraphrasing and he was notably not talking about Rust itself but "mixing" C and Rust) then Martin exploding and screaming that Christoph said "cancer" and that he had violated a Code of Conduct. Please.
A serious case of the pot calling the kettle black.
> then his beef with Christoph about wanting to "mix languages" (C and Rust, of course) and Christoph said "I'm maintaining it and I'm not doing it, it's like a cancer"
You don't even take time to figure out who's the commit author.
You don't even take time to figure out who's the commit author.
I've said this before, but the rust community really seems to attract the most toxic and drama-thumping types as their icons. I'm not really sure why such types are drawn to it.
This.
From shaming everything else as either slow or unsafe to rewrite the universe, the Rust community makes it hard for new comers to consider the language by its merit.
But the good thing is, the hype has settled down and Rust has found its niche. It’s not tackling Go or Python anytime soon and competes in a different plane.
Zig is another great alternative for someone like me who never found Rust a pleasant language to work with.
From shaming everything else as either slow or unsafe to rewrite the universe, the Rust community makes it hard for new comers to consider the language by its merit.
But the good thing is, the hype has settled down and Rust has found its niche. It’s not tackling Go or Python anytime soon and competes in a different plane.
Zig is another great alternative for someone like me who never found Rust a pleasant language to work with.
This is not because of Rust, but C.
Ar-Curunir(3)
Who are these icons?
This is profoundly silly.
First of all because we're talking about the kernel community here, which was incredibly toxic and dramatic long before Rust even existed. Linus has chilled out in the past few years but that legacy isn't entirely gone.
C++ drama has nearly come to fistfights at conferences, and the only reason that doesn't get talked about more is that the toxicity stays mostly on private (not public) mailing lists as a result of the more insular nature of that ecosystem. Nowadays you have a lot of people just quitting over things like the fact that a member of the standard committee was convicted on CSAM charges.
There are plenty of "C supremacists" in the tech influencer community and the maintainer mailing list of every distribution.
And streamers like PrimeTime that eagerly jump on every opportunity to shit on Rust and actively dump gasoline on every flareup of drama for ad revenue.
In general, programmers seem to love being elitist about languages and tools. Remember how everyone used to dump on PHP constantly?
First of all because we're talking about the kernel community here, which was incredibly toxic and dramatic long before Rust even existed. Linus has chilled out in the past few years but that legacy isn't entirely gone.
C++ drama has nearly come to fistfights at conferences, and the only reason that doesn't get talked about more is that the toxicity stays mostly on private (not public) mailing lists as a result of the more insular nature of that ecosystem. Nowadays you have a lot of people just quitting over things like the fact that a member of the standard committee was convicted on CSAM charges.
There are plenty of "C supremacists" in the tech influencer community and the maintainer mailing list of every distribution.
And streamers like PrimeTime that eagerly jump on every opportunity to shit on Rust and actively dump gasoline on every flareup of drama for ad revenue.
In general, programmers seem to love being elitist about languages and tools. Remember how everyone used to dump on PHP constantly?
I'm a Rust coder who also occasionally watches Prime, and I've never seen Prime casually pour gasoline on fires. Yes his whole business model is reacting to whatever content is hot right now, but he always does so in a considerate and non inflammatory manner.
He's not a fan of Rust for totally legitimate reasons.
He's not a fan of Rust for totally legitimate reasons.
If not Rust, what does he prefer? Zig?
Discussions on the internet often were dramatic. There are certainly also many "C supremacists", but I don't generally see C people coming to C++ or Rust projects and insisting that it should be rewritten in C because "C is better". I believe C is a better language myself and definitely much better than how it is currently perceived, but I do not mind if other people have a different opinion and do projects using other languages. While the mindset of many C++ and Rust proponents seems to be that "C has to die", so is inherently much more hostile. This makes it then sometimes difficult to ignore this completely.
My experience with Rust and people who use Rust has actually been great.
There seems to be an entire second world of “Rust community” and Rust zealots online who are heavy on the drama, though. It really does feel like an alternate Rust universe.
Although when I think about it, several of my other interests and hobbies are exactly like this. Great in the real world, but as soon as you step into certain online spaces it’s drama and toxicity.
In this specific case, I think this is more about kernel drama than Rust drama.
There seems to be an entire second world of “Rust community” and Rust zealots online who are heavy on the drama, though. It really does feel like an alternate Rust universe.
Although when I think about it, several of my other interests and hobbies are exactly like this. Great in the real world, but as soon as you step into certain online spaces it’s drama and toxicity.
In this specific case, I think this is more about kernel drama than Rust drama.
I don't think that's true. I think the C guys told themselves that writing safe C code is just a matter of skill, but data shows that the amount of skill necessary to avoid writing unsafe C just isn't there. The average C developer isn't as competent as they claim.
You can lie to yourself and say that the same security problems exist in other languages, but that isn't true.
When I check the vulnerabilities marked as HIGH on a JVM based project, it's often banal stuff like a denial of service in Spring. The consequences of an attack are a few days of downtime until we patch the library, but the truth is that while downtime on our application might be profitable for a competitor, it's not profitable for a black hat hacker working alone. They can't blackmail us, because we can update the library without paying them to stop.
Meanwhile the average C vulnerability is usually some form of RCE that would let the hacker install ransomware.
You can lie to yourself and say that the same security problems exist in other languages, but that isn't true.
When I check the vulnerabilities marked as HIGH on a JVM based project, it's often banal stuff like a denial of service in Spring. The consequences of an attack are a few days of downtime until we patch the library, but the truth is that while downtime on our application might be profitable for a competitor, it's not profitable for a black hat hacker working alone. They can't blackmail us, because we can update the library without paying them to stop.
Meanwhile the average C vulnerability is usually some form of RCE that would let the hacker install ransomware.
Java also had its share of remote code execution attacks. Security is quite complex domain and it is not just memory overwrites that can allow RCE attacks. Though I can agree that in average C/C++ is more vulnerable.
Most CVEs for Java are about untrusted code escaping the sandbox. No one is saying JavaScript is a bad language for server side development despite browser sandboxes constantly leaking.
Yes, there was a popular logger library that was written badly that tried to interpret log messages as potential source for fetching code dynamically from remote locations. Something that was thought to be the future 25 years ago, but had mostly been abandoned in all modern code.
Yes, there was a popular logger library that was written badly that tried to interpret log messages as potential source for fetching code dynamically from remote locations. Something that was thought to be the future 25 years ago, but had mostly been abandoned in all modern code.
I think already phrasing it like this "the C guys" is inflammatory and not helpful. The C community is huge and there is also a large part interested in more secure programming. Also the idea that tall C code is hopelessly unsafe while all Rust code is perfectly memory safe are both far from the truth. In reality, you can make C code quite good and you make Rust code very unsafe. While Rust certainly has some advantage, this is not as black-and-white as the Rust marketing wants you to believe. But this fuels the "C must die" and "we are on the right side of history and if you can not see this, you are an enemy" lines of thinking some people have.
It also doesn't help that the Rust comes with more than just the safty changes. The expectations for development models, distribution models, backwards compatibility guarantees not to mention the cultural aspects are very different which is the real reason it causes so many clashes.
It get pushed with the argument for better memory safety but then wants to change the entire world as well.
It get pushed with the argument for better memory safety but then wants to change the entire world as well.
Rust is sadly more about marketing than actually being popular or safe.
That stackoverflow survey rust folks so proudly crow about shows it’s the #1 ‘admired’ language, well #2 was closure and Zig over the years which clearly shows the value of the survey. Just marketing slop.
The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core library has 7K (of 21k) unsafe functions. So any Rust program that claims not to have “unsafe” code is most likely not true since any program that doesn’t use the standard library is a toy.
https://aws.amazon.com/blogs/opensource/verify-the-safety-of...
The rust community unearned arrogance is only surpassed by the Haskel folks. It’s breathtaking. Yes yes not all in the rust community are like this, but the social media amplified squeaky wheels one sure are loud.
That stackoverflow survey rust folks so proudly crow about shows it’s the #1 ‘admired’ language, well #2 was closure and Zig over the years which clearly shows the value of the survey. Just marketing slop.
The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core library has 7K (of 21k) unsafe functions. So any Rust program that claims not to have “unsafe” code is most likely not true since any program that doesn’t use the standard library is a toy.
https://aws.amazon.com/blogs/opensource/verify-the-safety-of...
The rust community unearned arrogance is only surpassed by the Haskel folks. It’s breathtaking. Yes yes not all in the rust community are like this, but the social media amplified squeaky wheels one sure are loud.
> The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core library has 7K (of 21k) unsafe functions. So any Rust program that claims not to have “unsafe” code is most likely not true since any program that doesn’t use the standard library is a toy.
Why does any of that imply that Rust doesn't produce safe code? There's no argument here - just some numbers and unjustified conclusions.
Why does any of that imply that Rust doesn't produce safe code? There's no argument here - just some numbers and unjustified conclusions.
Google has published direct evidence of Rust improving memory safety in practice: https://security.googleblog.com/2022/12/memory-safe-language...
> To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
That was 2022. I am aware of at least one security bug in their Rust code, but it wasn't a memory safety issue. I'll be interested to see what they say when they post updated numbers.
> To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
That was 2022. I am aware of at least one security bug in their Rust code, but it wasn't a memory safety issue. I'll be interested to see what they say when they post updated numbers.
> "The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core library has 7K (of 21k) unsafe functions."
"it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks"[1]. Using the Rust keyword 'unsafe' doesn't make the code inside it the Wild West or automatically an exploit or a problem, it is a limited-scope relaxing of only some checks.
[1] https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
"it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks"[1]. Using the Rust keyword 'unsafe' doesn't make the code inside it the Wild West or automatically an exploit or a problem, it is a limited-scope relaxing of only some checks.
[1] https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
Any trending language will attract some not so great people who make their choice of a shiny language their whole personality. It's really a pity for rust to be in that position now, as those people are there for the feeling of superiority and will cause drama to get it
If rust ends up being mainstream successful, those people will move on to something else and start attacking rust for whatever they feel their new language is superior in
Someone should have hugged them when they were kids
If rust ends up being mainstream successful, those people will move on to something else and start attacking rust for whatever they feel their new language is superior in
Someone should have hugged them when they were kids
tw1984(1)
This is unfortunately my take with almost every interaction I had with the Rust community. Expressing any diverging opinion is enough to get ostracized.
[deleted]
One lesson I feel we can all learn from this is that social media really should not be used for self-therapy.
> 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.
This drama included the dma maintainer saying he is categorically opposed to any Rust in any part of the kernel.
Where? Because "keep the wrappers in your code" and "do that in your driver so that you have to do it instead of spreading this" doesn't sound like that.
This [0] seems to be the closest to your parent's statement:
> The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux.
[0] https://lwn.net/ml/all/[email protected]/
> The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux.
[0] https://lwn.net/ml/all/[email protected]/
He needs really to be removed from the process. He may be useful for now but for long term he is an impediment. C is the 1970’s. Sure it’s proven itself… but so had Assembly when Unix was invented.
This kind of zealotry is not going to convince people over to accept Rust into their projects.
He said explicitely:
>Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this. You might not like my answer, but I will do everything I can do to stop this.
I think that clearly means he is out to sabotage any other language than C making it into Linux.
>Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this. You might not like my answer, but I will do everything I can do to stop this.
I think that clearly means he is out to sabotage any other language than C making it into Linux.
The end of the paragraph also emphasized the point
> I do not want it anywhere near a huge C code base that I need to maintain.
Link to mailing list: https://lwn.net/ml/all/[email protected]/
This was also on a patch that did "keep the wrappers in [rust-folder, not DMA] code". Arp242's interpretation isn't just belied by the direct words of the maintainer, it's belied by the fact that the code the maintainer rejected was exactly what Arp242 is suggesting the maintainer was asking for.
> I do not want it anywhere near a huge C code base that I need to maintain.
Link to mailing list: https://lwn.net/ml/all/[email protected]/
This was also on a patch that did "keep the wrappers in [rust-folder, not DMA] code". Arp242's interpretation isn't just belied by the direct words of the maintainer, it's belied by the fact that the code the maintainer rejected was exactly what Arp242 is suggesting the maintainer was asking for.
I wouldn't call being vocally against something "sabotage". Would it be reasonable if that person said anyone trying to get rust integrated is sabotaging the Linux kernel?
You're conflating two things. The fact that he voices his belief that Rust is harmful for kernel development is fair.
The fact that he is using his powers as maintainer of the DMA module to prevent Rust code from being added, with the explicit goal of making it harder to develop Rust drivers so that maybe the Rust-for-Linux project might get abandoned is an explicit act of sabotage against the R4L project (no one is saying he is sabotaging the Linux project itself).
In contrast, even accepting the "two languages bad" perspective, you can't call the R4L project "sabotage" in the same way, because they are clearly not intending to prevent or break anything in the Linux kernel, even if you think they will end up doing so as this maintainer does.
The fact that he is using his powers as maintainer of the DMA module to prevent Rust code from being added, with the explicit goal of making it harder to develop Rust drivers so that maybe the Rust-for-Linux project might get abandoned is an explicit act of sabotage against the R4L project (no one is saying he is sabotaging the Linux project itself).
In contrast, even accepting the "two languages bad" perspective, you can't call the R4L project "sabotage" in the same way, because they are clearly not intending to prevent or break anything in the Linux kernel, even if you think they will end up doing so as this maintainer does.
>The fact that he is using his powers as maintainer of the DMA module to prevent Rust code from being added
This is a misinterpretation of the facts. It's not actually up to Hellwig whether or not the patch gets accepted; the relevant maintainer that would merge the patch is somebody else.
He's totally within his right to express his opinion in a NACK.
This is a misinterpretation of the facts. It's not actually up to Hellwig whether or not the patch gets accepted; the relevant maintainer that would merge the patch is somebody else.
He's totally within his right to express his opinion in a NACK.
At least at some point, the proposal was to add this code in the DMA submodule, where he did have the ~final say whether it would be merged in.
When it became clear that wasn't an option, they decided to put it somewhere else, but since he'd been consulted, he still wanted to make it clear he isn't ok with the patch regardless of where the files go or any other aspect of it; but you're right that he is not the final authority on what code goes into that new subpath.
I never said in any way that he doesn't have a right to his opinion. Just that he is explicitly and vehemently opposed to Rust in the kernel, and to anything that makes that easier to happen.
When it became clear that wasn't an option, they decided to put it somewhere else, but since he'd been consulted, he still wanted to make it clear he isn't ok with the patch regardless of where the files go or any other aspect of it; but you're right that he is not the final authority on what code goes into that new subpath.
I never said in any way that he doesn't have a right to his opinion. Just that he is explicitly and vehemently opposed to Rust in the kernel, and to anything that makes that easier to happen.
You're comparing the actual intent of one side of the argument to a watered down version of the other side. "I will do anything in my power to stop this" is the stated intent of sabotage, not "I'm vocally stating my opposition to this" If someone said "I will do anything in my power to stop Linux development to proceed without Rust integrated into it", then yes, that would sound like intent to sabotage, but that's not anywhere close to what anyone is saying.
So there's actually a reasoning behind this and not just personal preference or someone being stubborn. And as someone who has maintained large old code bases I must say the reasoning sounds pretty convincing.
If any of
> Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this.
is correct, he is actually fighting against sabotage.
edit for readability
If any of
> Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this.
is correct, he is actually fighting against sabotage.
edit for readability
Are you referring to Hellwig saying, "No rust code in kernel/dma, please."? I took that to mean just dma.
The objection was to a separate file entirely outside of his subtree, describing its interface, which is apparently supposed to be duplicated instead in each rust driver that references it, for no clear reason -- other than his stated reason of not wanting to see languages other than C in the kernel at all.
I was referring to the statements provided by the children of this comment: https://news.ycombinator.com/item?id=42978746 (they were made at roughly the same time you posted this, so you wouldn't have seen them then)
Completely agree with you.
> 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.
Dude, this was literally caused by a stubborn maintainer, Hellwig, saying he wants NO second language in the kernel at all, and his explicit vow to do anything he can to stop it.
And there is no issue with that. What's this pervasive need to spread Rust to every part of the software space. It's just becoming a little too pushy and desperate
c'mon.. please know about the issue at all to some level before commenting.
The rust for linux project exists because Linus approved it. It's that simple. Linus thinks it a good idea to at least try Rust in the kernel. If he didn't, then none of this would be happening.
The rust for linux project exists because Linus approved it. It's that simple. Linus thinks it a good idea to at least try Rust in the kernel. If he didn't, then none of this would be happening.
That may be what you want the situation to be but at this point it isn't what the situation is.
> The rust for linux project exists because Linus approved it. It's that simple. Linus thinks it a good idea to at least try Rust in the kernel.
Pepople can change their minds; after a while, they may come to think that what they once thought was a good idea wasn't actually so.
With stuff like this going on -- and I gather this is not the first time something like it has happened -- how long do you think Linus will continue to think so? Do you think stuff like this is likely to make Linus more convinced, or less convinced, that setting himself (and all the other Linux kernel maintainers) up to have to interact with Rust people on an ongoing basis really was a good idea?
Pepople can change their minds; after a while, they may come to think that what they once thought was a good idea wasn't actually so.
With stuff like this going on -- and I gather this is not the first time something like it has happened -- how long do you think Linus will continue to think so? Do you think stuff like this is likely to make Linus more convinced, or less convinced, that setting himself (and all the other Linux kernel maintainers) up to have to interact with Rust people on an ongoing basis really was a good idea?
He continued to express his support on the subject as of yesterday (i think).
> 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...
Some Kernel maintainers are absolutely against Rust anywhere in the kernel tree [0]:
> The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.
This is from Christoph Hellwig, the DMA maintainer. And is in fact what started the thread that led to Hector Martin quitting Linux. You can see other comments by Hellwig in that thread as well, he is extremely explicit - any Rust anywhere in the kernel is a big problem, and even if he can't stop it everywhere, he will do what he can to make it harder to use Rust by blocking it from the pieces he maintains.
[0] https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...
> > The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.
If a maintainer of a major subsystem has those objections, it is a good chance to try to convince them otherwise.
If something is not clear, ask him to elaborate.
But blackmailing with a social media campaign is not productive. Even more it’s anti-productive. This just adds to rust=drama=stayaway feeling.
If a maintainer of a major subsystem has those objections, it is a good chance to try to convince them otherwise.
If something is not clear, ask him to elaborate.
But blackmailing with a social media campaign is not productive. Even more it’s anti-productive. This just adds to rust=drama=stayaway feeling.
Oh, yes, the idea of settling anything on social media is horrible.
I was just pointing out that the positions are much more binary and un-nuanced than the previous poster was claiming, even in the thread in question. I'd bet the DMA maintainer is not the only one who holds this dogmatic position, either.
I'll also note that the complaints from this maintainer aren't even social though. He is very explicit in his reasoning: two+ languages bad, single language good. There's clearly little that will change this, other than working around him (though, again, I agree that social media blackmail certainly won't improve anything).
I was just pointing out that the positions are much more binary and un-nuanced than the previous poster was claiming, even in the thread in question. I'd bet the DMA maintainer is not the only one who holds this dogmatic position, either.
I'll also note that the complaints from this maintainer aren't even social though. He is very explicit in his reasoning: two+ languages bad, single language good. There's clearly little that will change this, other than working around him (though, again, I agree that social media blackmail certainly won't improve anything).
> He is very explicit in his reasoning: two+ languages bad, single language good. There's clearly little that will change this, other than working around him
I see you're not even considering the possibility that he might be right, so working around him would be bad.
___
ETA: I see on further reading that you are indeed acknowledging that possibility, good for you! I just didn't see that in this comment.
I see you're not even considering the possibility that he might be right, so working around him would be bad.
___
ETA: I see on further reading that you are indeed acknowledging that possibility, good for you! I just didn't see that in this comment.
If you looks at the history then you will see that many different solutions have been proposed but Christoph's responses essentially boil down to 'do it somewhere else' and 'no not there', until it is basically 'not at all'. He is not in a position to make this decision, only Linus is. The patch as it stands lives outside of any sub-systems within Christoph's purview, he is simply being obstructionist out of tribalism.
> he is simply being obstructionist out of tribalism.
What about the part quoted in GPs comment?
> > The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this
Wouldn't adding another language add an internal boundary? I don't know enough the kernel or kernel development to say it's an good argument or not, but it doesn't seem to be tribalism. I do know Rust already seems to be in some/few places in the kernel, but adding more would add more internal boundaries, as it'll get more and more divided. But again, maybe I don't understand clearly.
What about the part quoted in GPs comment?
> > The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this
Wouldn't adding another language add an internal boundary? I don't know enough the kernel or kernel development to say it's an good argument or not, but it doesn't seem to be tribalism. I do know Rust already seems to be in some/few places in the kernel, but adding more would add more internal boundaries, as it'll get more and more divided. But again, maybe I don't understand clearly.
I agree that it may not be tribalistic, it's very possible that the maintainer has a valid technical/social opinion on this.
However, I don't think it is in any way acceptable to insert this in discussions about a random Rust patch. It's disrespectful to the time and expertise of the people who submitted these patches to first nitpick various technical items, only to later make it clear you were never going to accept their patch in the first place, because you dislike and oppose the decision that you know has already been made, to allow Rust in the kernel.
If he instead was (1) upfront about the fact that he would never allow Rust code in the subcomponent he maintains, and (2) stepped out of the discussion of this patch once it was moved out of said component, and then (3) started a completely separate thread on changing the kernel's stance on Rust to block all future patches and consider removing it entirely, that would all have been normal respectable behavior.
However, I don't think it is in any way acceptable to insert this in discussions about a random Rust patch. It's disrespectful to the time and expertise of the people who submitted these patches to first nitpick various technical items, only to later make it clear you were never going to accept their patch in the first place, because you dislike and oppose the decision that you know has already been made, to allow Rust in the kernel.
If he instead was (1) upfront about the fact that he would never allow Rust code in the subcomponent he maintains, and (2) stepped out of the discussion of this patch once it was moved out of said component, and then (3) started a completely separate thread on changing the kernel's stance on Rust to block all future patches and consider removing it entirely, that would all have been normal respectable behavior.
> The patch as it stands lives outside of any sub-systems within Christoph's purview
Wait what? Thought I saw somwehere that he's the DMA maintainer, and wasn't this a DMA patch?
> he is simply being obstructionist out of tribalism.
Or is it the Rust people who are being intrusionist out of their tribalism? Looks at least as much like that to me.
Wait what? Thought I saw somwehere that he's the DMA maintainer, and wasn't this a DMA patch?
> he is simply being obstructionist out of tribalism.
Or is it the Rust people who are being intrusionist out of their tribalism? Looks at least as much like that to me.
> wasn't this a DMA patch?
Although it was a DMA patch, it was not in the DMA subsystem that Christoph maintains. More specifically, it was not a file in the kernel/dma directory, but rather a file in the rust/kernel directory, which is where the Rust subsystem lives.
The Rust code is essentially a consumer of the DMA public API, much like many other subsystems in the kernel that consume it.
This is why some people are upset and confused about the situation; he added a Nacked-by tag to a patch that is outside his area. He had good reasons for it, but it was hard to see them based on the way he wrote his replies.
Although it was a DMA patch, it was not in the DMA subsystem that Christoph maintains. More specifically, it was not a file in the kernel/dma directory, but rather a file in the rust/kernel directory, which is where the Rust subsystem lives.
The Rust code is essentially a consumer of the DMA public API, much like many other subsystems in the kernel that consume it.
This is why some people are upset and confused about the situation; he added a Nacked-by tag to a patch that is outside his area. He had good reasons for it, but it was hard to see them based on the way he wrote his replies.
Aha, I see. Thanks!
It's not without merit. Two languages is an extreme cost in complexity compared to one, and you have to be a deep expert in both to fully figure out anything on the boundary.
Perhaps rusts potential benefits are worth it, but it's certainly possible to disagree with that
Perhaps rusts potential benefits are worth it, but it's certainly possible to disagree with that
Sure, but (1) that ship has sailed for now, there are already Rust bits in the kernel; and (2) a patch email thread is not the best place to start discussing whether Rust has a place in the kernel.
Is it impossible to just delete the rust parts and go back to pure C?
That ship could come back to port anytime.
That ship could come back to port anytime.
That's not a decision that can or should come out of a patch review. I agree it's a possible decision, not something unthinkable. But if it were, it should be taken at a completely different level.
Basically, it's an obstructionist, uncivilized thing to hold up every discussion about a topic that you get to participate in by insisting the topic shouldn't be discussed in this forum. It's perfectly OK to advocate for the removal of Rust from the kernel, it's not ok to bring this up in every random Rust patch while the consensus is that Rust has a place in the kernel.
Basically, it's an obstructionist, uncivilized thing to hold up every discussion about a topic that you get to participate in by insisting the topic shouldn't be discussed in this forum. It's perfectly OK to advocate for the removal of Rust from the kernel, it's not ok to bring this up in every random Rust patch while the consensus is that Rust has a place in the kernel.
The kernel doesn't really have a better system mechanism for having these sorts of decisions made unfortunately.
I would quite like my laptop to keep working, and half its drivers are rust…
The Linux drivers can be maintained in a downstream fork. Ultimately that seems to be what upstream wants, unfortunate as that may be.
Then you (and others interested in running Linux on fruit company hardware) can sponsor someone to rewrite those drivers in a way that fits the Linux project.
There are no Rust bits anywhere outside drivers, and hopefully that will continue to be the case. This means that mainline Linux kernel has no hard dependency on Rust whatsoever, which also means that Rust can be excised at any point with a minimum of effort.
I'm 100% behind Christoph, the last thing Linux needs is the extra complexity that Rust brings. I'm fairly optimistic that Rust will never be a hard dependency for the foreseeable future.
I'm 100% behind Christoph, the last thing Linux needs is the extra complexity that Rust brings. I'm fairly optimistic that Rust will never be a hard dependency for the foreseeable future.
I totally 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.
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.
tw1984(1)
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.
The sooner politicians are outright banned from using it for anything connected to their office the better.
> 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.
Exactly the point. IMHO the one and only thing that made Linux successful as a project is Linus' strong leadership - which has been criticized ad-nauseam over the years; yet it's the only thing that yields results.
So in the specific instances (like this one) where he's not decisively, unequivocally, and even harshly saying "yes" or "no" to something, the community shows a very clear incapability of reaching a decision.
Reminds me of a similar scenario that happened years ago with GVR stepping down as BDFL for Python - just after a tiresome and wasteful fight with the community's opinions.
"Community" is just a very naive ideal for me. There's a finite number of people that can do the job, and even a more finite number of people that can make a decision and stand by it.
pipes(4)
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
The more I hear about "community" the more I roll my eyes
It can be great at doing the work but it is awful at setting direction, evolving with the times and focusing on what's important
Going by another story on the front page, I have my long list of criticism about systemd but the "get things done" attitude needed to be commended
What an absolutely awful statement about one of the most successful community projects ever. Direction usually comes from the community and the maintainers just steer it. Little in the kernel comes from maintainers saying "let's do X" and community members implementing it
See how slow Wayland progress has been for an example of my grudges with that model of development
Almost two decades later, for unexplicable reasons, every new client not piggybacking on an eatablished toolkit or a new toolkit/compositor struggles with clipboard support, I shit you not.
> Little in the kernel comes from maintainers saying "let's do X" and community members implementing it
Maintainers do steer direction of development though. A lot comes from maintainer saying "we are not accepting XYZ".
Today we only have proper open source GPU drivers because people like David Airlie who stand for their principle against likes of Nvidia and AMD.
Maintainers do steer direction of development though. A lot comes from maintainer saying "we are not accepting XYZ".
Today we only have proper open source GPU drivers because people like David Airlie who stand for their principle against likes of Nvidia and AMD.
Perhaps you could fork the kernel and start a better community?
[deleted]
> 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.
I wear garlic every day and have yet to be attacked by a vampire; clearly this is due to the garlic!
Tang/ballpoint pens/velcro never would have been invented if it weren't for the Apollo program.
etc.
All of those inventions were invented at least a couple years before the Apollo program.
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.
> 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!"
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!"
> 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.
Efficiently collaborating on large distributed open source projects like Linux is as much social activity as technical. For people like Kent Overstreet or marcan and many before them this is apparently a hard thing to grasp and they have been failing badly at following the process, building consensus, earning respect and trust of people from other subsystems, that kind of things. To me it looks like that for Linux big part of R4L experiment is to specifically understand whether Rust people can convince key stakeholders that R4L is good idea and get their buy-in and that is why he doesn't attempt to force it. Also, what is he gonna do to the reluctant but key maintainers? Refuse to accept anything from them until each of them shows him a repo with all Rustlings exercises solved to ensure they are ready for Rust or what?
> And it's quite out of character for Linus not to have a blazingly clear opinion.
Linus tends to have clear opinions on things he is world class in. He is technically brilliant and very knowledgeable in most of the low level systems things but likely not in Rust, so it is understandable for him to just keep being open minded about it and let the chips fall where they may.
> As a pilot program, R4L should have graduated or ended a long time ago. After several years of active development, its status remains unclear.
Which is absolutely normal for the kernel. You can have a driver spending years in staging or RTLinux taking 20 years to get there. It is totally expected for such a disruptive change as introducing new (and quite complicated) programming language to take a few more years to reach maturity.
> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor, but he hasn't said anything explicitly.
Not it isn't.
> decision has backfired horribly
> place responsibility for the drama on Martin's shoulders
> Imagine how much time and energy (even just Martin's alone) could have been saved if Linus had just said "no, keep it downstream".
HN crowd and random JavaScript-kids on Reddit are only hotly debating this because the "drama" has the word "Rust" in the title. For Linux maintainers it is just another day at the office, nothing much to see here honestly.
[deleted]
> 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. .
This is the entire point. This has been DONE. First its "lets see if you can build a good driver", now its "ew rust". The maintainer of the DMA subsystem is showing how they're actively trying to make sure Rust doesn't make it in. .
No, it is not the entire point. No one is really doubting whether you can write a driver in Rust, C++ or Swift. The whole experiment is whether you can slowly move in to existing mature kernel subsystems without being too disruptive.
If the minority maintainers scream every time they see other languages due to their insecurities, technical inability and stubbornness, and their overreactions get a pass, it is not the fault of Rust, C++ or Swift. The source of the disturbance is not the people who are making an effort to cause as little disturbance.
Blatant NIMBYism is the problem here and you cannot reduce it by accepting everything.
Blatant NIMBYism is the problem here and you cannot reduce it by accepting everything.
In general, upstreaming code to Linux involves interacting with difficult and sometimes outright hostile people. I've certainly had my share of both with much smaller changes. IMO pushing something like R4L requires very thick skin and almost infinite amount of patience. Bitching about that won't get you far, you need to be able to either work with or around those people.
This again gets back to the main point which you keep misrepresenting. This has nothing to do with a thick skin, this is a core subsystem maintainer outright saying they won't support R4L, which means its dead.
I'm not misrepresenting anything and R4L is not dead. In fact, two ways forward where suggested right in the LKLM email thread:
- Send the series directly to Linus since there is no code that Hellwig is maintainer of is actually being changed by it and let Linus decide whether to ignore Hellwig's nack. Linus may have done so before, but likely not after marcan's public meltdown.
- Copy/paste the code to every driver that will be using it. If it becomes useful, it will cause more pressure on Hellwig down the road because people will question why every change in code that is being wrapped by this is causing a fix in 10 different copies.
People here and on Reddit who are unfamiliar with the Linux development process but are attracted to the "drama" because it involves Rust somehow keep missing it.
- Send the series directly to Linus since there is no code that Hellwig is maintainer of is actually being changed by it and let Linus decide whether to ignore Hellwig's nack. Linus may have done so before, but likely not after marcan's public meltdown.
- Copy/paste the code to every driver that will be using it. If it becomes useful, it will cause more pressure on Hellwig down the road because people will question why every change in code that is being wrapped by this is causing a fix in 10 different copies.
People here and on Reddit who are unfamiliar with the Linux development process but are attracted to the "drama" because it involves Rust somehow keep missing it.
> No, it is not the entire point. No one is really doubting whether you can write a driver in Rust, C++ or Swift. The whole experiment is whether you can slowly move in to existing mature kernel subsystems without being too disruptive.
Which Chris did doubt, as a way to gatekeep Rust (as you misrepresented, and which is clearly visible in the LKML thread).
regardless, back to the other stuff: First point: Which is what was suggested as well in the LKML and still does not really solve the problem, which is not TECHNICAL but POLITICAL. Second point: Obvious, and wasteful, and again is thus a political move which is the entire point of this entire saga. It isn't about drama, its about the political aspect of the kernel dev being tiring and wasteful.
Which Chris did doubt, as a way to gatekeep Rust (as you misrepresented, and which is clearly visible in the LKML thread).
regardless, back to the other stuff: First point: Which is what was suggested as well in the LKML and still does not really solve the problem, which is not TECHNICAL but POLITICAL. Second point: Obvious, and wasteful, and again is thus a political move which is the entire point of this entire saga. It isn't about drama, its about the political aspect of the kernel dev being tiring and wasteful.
> Which Chris did doubt, as a way to gatekeep Rust (as you misrepresented, and which is clearly visible in the LKML thread).
Can you provide the exact quote where Hellwig is suggesting that it is impossible to write a driver in Rust? No, you can't? So who exactly is misrepresenting here?
> regardless, back to the other stuff: First point: Which is what was suggested as well in the LKML and still does not really solve the problem, which is not TECHNICAL but POLITICAL. Second point: Obvious, and wasteful, and again is thus a political move which is the entire point of this entire saga. It isn't about drama, its about the political aspect of the kernel dev being tiring and wasteful.
You are shifting the goalpost from this making R4L "dead" to the way forward being "tiring and wasteful". It doesn't look like you are arguing in a good faith so I won't participate in the discussion with you anymore.
Can you provide the exact quote where Hellwig is suggesting that it is impossible to write a driver in Rust? No, you can't? So who exactly is misrepresenting here?
> regardless, back to the other stuff: First point: Which is what was suggested as well in the LKML and still does not really solve the problem, which is not TECHNICAL but POLITICAL. Second point: Obvious, and wasteful, and again is thus a political move which is the entire point of this entire saga. It isn't about drama, its about the political aspect of the kernel dev being tiring and wasteful.
You are shifting the goalpost from this making R4L "dead" to the way forward being "tiring and wasteful". It doesn't look like you are arguing in a good faith so I won't participate in the discussion with you anymore.
> just keep being open minded about it and let the chips fall where they may.
It's a failure of leadership to not intervene when discord threatens the group. He should weigh in, or make sure that someone else who has mutual trust weighs in.
In youth sports, something similar happens when referees fail to call fouls on rough play. Players naturally test the limits and then others recognize the lack of protection and retaliate until it gets really out of hand.
It's a failure of leadership to not intervene when discord threatens the group. He should weigh in, or make sure that someone else who has mutual trust weighs in.
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.
> In youth sports, something similar happens when referees fail to call fouls on rough play.
This is actually not limited to youth sports, you can even see it happen with professional athletes.
It's a very common human reaction when participants feel like the rules aren't getting enforced. For all ages. Which only reinforces your point.
This is actually not limited to youth sports, you can even see it happen with professional athletes.
It's a very common human reaction when participants feel like the rules aren't getting enforced. For all ages. Which only reinforces your point.
> It's a failure of leadership to not intervene when discord threatens the group. He should weigh in, or make sure that someone else who has mutual trust weighs in.
Nothing in that particular "drama" threatens Linux kernel maintainers as a group. Multiple solutions were proposed, like just sending the change directly to Linus bypassing Hellwig or copy/pasting the code to each individual driver for now. Marcan having public meltdown in that thread probably makes option 1 no-go though and doesn't improve R4L standing with the skeptical group of maintainers.
> In youth sports, something similar happens when referees fail to call fouls on rough play. Players naturally test the limits and then others recognize the lack of protection and retaliate until it gets really out of hand.
For better or worse the social contract in LKLM is not like what a lot of Rust people used to where you come in with furry avatar and pronouns in your profile, then cry for mommy to enforce CoC on first signs of conflict. Basically, extending your analogy, you don't come to an American football match expecting the referee to enforce basketball no-contact rules.
Nothing in that particular "drama" threatens Linux kernel maintainers as a group. Multiple solutions were proposed, like just sending the change directly to Linus bypassing Hellwig or copy/pasting the code to each individual driver for now. Marcan having public meltdown in that thread probably makes option 1 no-go though and doesn't improve R4L standing with the skeptical group of maintainers.
> In youth sports, something similar happens when referees fail to call fouls on rough play. Players naturally test the limits and then others recognize the lack of protection and retaliate until it gets really out of hand.
For better or worse the social contract in LKLM is not like what a lot of Rust people used to where you come in with furry avatar and pronouns in your profile, then cry for mommy to enforce CoC on first signs of conflict. Basically, extending your analogy, you don't come to an American football match expecting the referee to enforce basketball no-contact rules.
You can't rely on an authority to step in every time some disagrees. People need to resolve their own conflicts rather than yell until bailed out
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.
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.
Video isn't out yet, hopefully soon.
There is an LWN summary of it out already:
https://news.ycombinator.com/item?id=42968782
https://news.ycombinator.com/item?id=42968782
It's definitely a ballpark estimate, but "boring email threads" are 99% of LKML.
There's an average of 1000 messages per day, we get news of a drama-fueled thread like, three times on a bad year?
My ballpark estimate is probably low.
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.
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.
Then make it so, so that we can RWIR, and Linux can fade into the sunset with Linus.
Nothing is stopping you
If the Kernel stopped all development it would still not fade into the sunset in our lifetime.
I love Linux and have no preference to either C or Rust, but locking Linux in to a programming language that was designed in the relatively early stages of computing will lead to Linux dying in the long term.
There will be fewer and fewer new C programmers with people instead taking up newer systems programming languages like Rust or Zig.
There will be fewer and fewer new C programmers with people instead taking up newer systems programming languages like Rust or Zig.
C and Unix have stood the test of time. It has been 50 years since they were designed, this is a long time in terms on computing. It is not unreasonable to think that they will stay for another 50 years.
Yes, they SHOULD be adding Fortran, another language that has stood the test of time, to the Linux kernel.
Or... Maybe it's good that they add a new (still 10 years old) language with security and DX improvements occasionally. 50 years ago, that language was C...
Or... Maybe it's good that they add a new (still 10 years old) language with security and DX improvements occasionally. 50 years ago, that language was C...
If other, safer language would have existed the same time as C, I don’t think it would have stood the time as you say.
They did. But they were disregarded.
that's just hindsight. You can also argue the same for the dvorak keyboard vs qwerty. And yet, qwerty stood the test of time.
Momentum and legacy is hard to displace, when the new fangled thing attemping to be an improvement is not proven, and has unknown unknowns.
Momentum and legacy is hard to displace, when the new fangled thing attemping to be an improvement is not proven, and has unknown unknowns.
> that's just hindsight.
Is it? Do you think it's hindsight to use the only "successful" story as "the only way forward?" Look at the gas vs electric vehicles. Yes, displacing legacy is hard but not insurmountable when there is a clear improvement. I don't think anyone can argue in good faith the Rust is NOT an improvement in C.
Is it? Do you think it's hindsight to use the only "successful" story as "the only way forward?" Look at the gas vs electric vehicles. Yes, displacing legacy is hard but not insurmountable when there is a clear improvement. I don't think anyone can argue in good faith the Rust is NOT an improvement in C.
Electric vehicles are also not a clear improvement over combustion engines. Which is why they need to be forced into use.
There are zero indicators for that happening. In fact, if history is by any means an indicator for the future, we might see these dying out over the years in favor of new hyped ones and C standing against the time. Zig is nothing so far, personally I believe Rust has some staying power for now, but we'll see. As for C, kernel C is not all that C where C was led to in recent years.
Interestingly enough the Windows kernel is slowly rusting. If they they see a significant drop in CVEs eventually (which is bound to happen, with how easy it is to footgun memory safety in C), it blows a huge hole in the stance of "no Rust in the Linux kernel". It'd be akin to saying "yes, more security issues please".
Just like C++ has already led to there being fewer new C programmers and has caused C projects to die out? I don't think the programming language is a real problem for someone capable of working on the kernel. Some people might prefer to work in another language but with a large project you need to compromise in many ways and the language is just part of that.
I agree. If it wasn't for the memory safety meme this would have never been considered.
> at least to C developers.
so it is not about technical merits, but just some language religious thing? nice.
so it is not about technical merits, but just some language religious thing? nice.
Not "religious" (even though I've used the word "zealot" right here) but rather political or social.
those are still technical merits/non-merits, albeit on the project management level.
The rust doesn't write itself.
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.
Torvalds lost respect of a lot of people, that's the most important thing.
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?
And look where it got us!
It wasn't going to work without ample support within the kernel.
At a minimum, all prominent developers would have to be convinced and ready to put a lot of effort into this.
As this was never the case, Linus should have put his foot down with a clear No, thus preventing the conflict and overall waste of resources we're seeing.
Rust devs would still be able to fork or otherwise (much better idea imho) work on their own kernel, hopefully with a much better design.
Redox is doing this, with a microkernel multiserver approach.
At a minimum, all prominent developers would have to be convinced and ready to put a lot of effort into this.
As this was never the case, Linus should have put his foot down with a clear No, thus preventing the conflict and overall waste of resources we're seeing.
Rust devs would still be able to fork or otherwise (much better idea imho) work on their own kernel, hopefully with a much better design.
Redox is doing this, with a microkernel multiserver approach.
> 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.
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.
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.
No because its Rust, but because it's a bad idea to use more than one single language across the entire code base.
I also am surprised that Linus has not ended this folly.
If Rust wants a Linux kernel it should make one.
Do you feel the same about Make, Device Tree, KConfig, Python, the myriad of machine-specific assembly, POSIX shell, Perl, and every other non-C language currently in the code base?
That's a false equivalency. All of those languages are integrated through strong semantic and concrete abstractions (e.g. file system I/O or GCC interfaces) that evolve, if at all, very slowly. Some, like assembly, are necessary concessions, and are exceptions that prove the rule--developers prefer GCC builtins if available, for example.
The problem with Rust in the kernel is that the kernel has historically eschewed strong internal abstractions. The Linux kernel has no principled abstract architecture in the same way that Windows NT does; it has evolved very organically and even some of the most foundational subsystem APIs regularly see refactorings that touch almost every corner of the kernel.
The latest dispute (if it could be called that) regarding Rust was Rust building abstractions around the DMA interface. There's nothing wrong with this, per se. For Rust it's a necessary chore. But when you build complex abstractions atop something, you're either ossifying the interface or building a sand castle. If we're being charitable, some Linux developers felt like this was pressure to ossify the existing abstractions. Rust developers, OTOH, promised that they'd take full responsibility for any future refactoring, implicitly admitting that they understood they were building a sand castle.
How do you bridge that divide? Because of the lack of hard architectural line drawing in how Linux is developed, the norm is that both redesigns and refactoring are in many respects highly cooperative (notwithstanding the bickering and friction). A subsystem maintainer contemplating a redesign takes into consideration the burdens on other users, and how a redesign might be incrementally rolled out, if at all. Conversely, users of interfaces know--or should know--to take into consideration future potential changes in an interface when relying on an interface for their subsystems. It's a constant back-and-forth, give-and-take, but also messy and chaotic. Transparency in source code is key--this kind of development would never work in commercial projects across binary interfaces. Yet in important respects that's what the interface between C and Rust is like--opaque--especially when developers on one side aren't intimately familiar with the semantics of the other and how they translate, if at all, across the boundary.
Now here comes Rust, which has spent years putting into place the infrastructure just to get some drivers going. Rust as a language demands careful architecture and line drawing. It's no surprise that much of that initial infrastructure effort, excluding the build, was expended on building towers of abstraction. Refactoring can be painful in Rust when it involves very low-level changes in semantics (the kind that are common in kernel development), and while there are tools to help address that, they don't work well, or at all, outside of Rust. There's a huge impedance mismatch between Rust and historic Linux kernel development. In user land, developers' experience is that Rust is relatively easy to interface with C libraries. But that experience is primarily interfacing with public APIs, those public APIs have always been quite stable, and user land libraries (at least the good ones) are designed to be, as much as possible, blackboxes from the outside. Abstractions that leak tend to be fixed abstractions, like file descriptors, etc, that are typical for the environment and rather predictable.
That situation with user land C FFI is utterly incomparable to how interfaces evolve in Linux. The clash between these worlds, at both a technical and cultural level, was inevitable. Heck, it was evident from day 1. This doesn't make either side right or wrong, and I'm not trying to suggest that the Linux developer community can't figure out a path forward. But it's a difficult problem on many levels.
The problem with Rust in the kernel is that the kernel has historically eschewed strong internal abstractions. The Linux kernel has no principled abstract architecture in the same way that Windows NT does; it has evolved very organically and even some of the most foundational subsystem APIs regularly see refactorings that touch almost every corner of the kernel.
The latest dispute (if it could be called that) regarding Rust was Rust building abstractions around the DMA interface. There's nothing wrong with this, per se. For Rust it's a necessary chore. But when you build complex abstractions atop something, you're either ossifying the interface or building a sand castle. If we're being charitable, some Linux developers felt like this was pressure to ossify the existing abstractions. Rust developers, OTOH, promised that they'd take full responsibility for any future refactoring, implicitly admitting that they understood they were building a sand castle.
How do you bridge that divide? Because of the lack of hard architectural line drawing in how Linux is developed, the norm is that both redesigns and refactoring are in many respects highly cooperative (notwithstanding the bickering and friction). A subsystem maintainer contemplating a redesign takes into consideration the burdens on other users, and how a redesign might be incrementally rolled out, if at all. Conversely, users of interfaces know--or should know--to take into consideration future potential changes in an interface when relying on an interface for their subsystems. It's a constant back-and-forth, give-and-take, but also messy and chaotic. Transparency in source code is key--this kind of development would never work in commercial projects across binary interfaces. Yet in important respects that's what the interface between C and Rust is like--opaque--especially when developers on one side aren't intimately familiar with the semantics of the other and how they translate, if at all, across the boundary.
Now here comes Rust, which has spent years putting into place the infrastructure just to get some drivers going. Rust as a language demands careful architecture and line drawing. It's no surprise that much of that initial infrastructure effort, excluding the build, was expended on building towers of abstraction. Refactoring can be painful in Rust when it involves very low-level changes in semantics (the kind that are common in kernel development), and while there are tools to help address that, they don't work well, or at all, outside of Rust. There's a huge impedance mismatch between Rust and historic Linux kernel development. In user land, developers' experience is that Rust is relatively easy to interface with C libraries. But that experience is primarily interfacing with public APIs, those public APIs have always been quite stable, and user land libraries (at least the good ones) are designed to be, as much as possible, blackboxes from the outside. Abstractions that leak tend to be fixed abstractions, like file descriptors, etc, that are typical for the environment and rather predictable.
That situation with user land C FFI is utterly incomparable to how interfaces evolve in Linux. The clash between these worlds, at both a technical and cultural level, was inevitable. Heck, it was evident from day 1. This doesn't make either side right or wrong, and I'm not trying to suggest that the Linux developer community can't figure out a path forward. But it's a difficult problem on many levels.
> Refactoring can be painful in Rust when it involves very low-level changes in semantics
I don't know what this is about. In my experience, refactorings that change the semantics of APIs are much easier in Rust than in C. E.g., change assumptions about the lifetimes of pointers passed into APIs: the Rust compiler will tell you where you need to change anything; the C compiler will happily compile your code and you'll corrupt memory at runtime.
I don't know what this is about. In my experience, refactorings that change the semantics of APIs are much easier in Rust than in C. E.g., change assumptions about the lifetimes of pointers passed into APIs: the Rust compiler will tell you where you need to change anything; the C compiler will happily compile your code and you'll corrupt memory at runtime.
Right, and while sometimes a lot of code needs to change in Rust, it's often largely mechanical, at least in typical contexts (e.g. user land development). But Rust won't automatically detect changes in semantics that happen across FFI boundaries. And I didn't argue that refactoring is easier in C than Rust. For one thing, it's an inapt comparison in the context of a mixed C and Rust kernel codebase in which the vast majority of the code and semantics come from the C side.
And there are more subtle issues. From the perspective of C code, Rust looks and behave as if it assumes strict aliasing, a consequence of the borrowing rules--a mutable pointer can never alias. But the Linux kernel uses -fno-strict-alias (i.e. any pointer can alias, regardless of type), so a subtle change in C code which works fine for the kernel could silently break Rust code if the C-side developer wasn't aware of these subtle nuances in memory models and how they were expressed in the unsafe wrappers. This might be a totally contrived scenario[1], or it could be very real given the tower of abstractions built on the Rust side over the C APIs, which might overspecify certain semantics to fit "cleanly" (i.e. best practice) into the Rust model.
Which points at another issue: all of these hypotheticals might be (probably are?) overblown. But over the past 2-3 years, with the exception of a couple of high-profile drivers not yet mainlined (AFAIU), the vast majority of the effort on the Rust side has been building towers of abstraction. In almost any open source project, C or otherwise, a newcomer who starts writing towers of abstractions rather than concrete, usable code would be shooed away. There are reasonable justifications for why Rust has been doing this, yet its also understandable why this might draw suspicions about the practicality and utility of mixing C and Rust in the kernel. But either way it means that after all this time people are still largely arguing over hypotheticals.
[1] Or entirely wrong. Maybe kernel Rust is using flags to ensure aliasing optimizations can't happen. clang (and thus LLVM) supports -fno-strict-alias, but AFAIU alot of Rust code massaging happens on the Rust (MIR or equivalent) side.
And there are more subtle issues. From the perspective of C code, Rust looks and behave as if it assumes strict aliasing, a consequence of the borrowing rules--a mutable pointer can never alias. But the Linux kernel uses -fno-strict-alias (i.e. any pointer can alias, regardless of type), so a subtle change in C code which works fine for the kernel could silently break Rust code if the C-side developer wasn't aware of these subtle nuances in memory models and how they were expressed in the unsafe wrappers. This might be a totally contrived scenario[1], or it could be very real given the tower of abstractions built on the Rust side over the C APIs, which might overspecify certain semantics to fit "cleanly" (i.e. best practice) into the Rust model.
Which points at another issue: all of these hypotheticals might be (probably are?) overblown. But over the past 2-3 years, with the exception of a couple of high-profile drivers not yet mainlined (AFAIU), the vast majority of the effort on the Rust side has been building towers of abstraction. In almost any open source project, C or otherwise, a newcomer who starts writing towers of abstractions rather than concrete, usable code would be shooed away. There are reasonable justifications for why Rust has been doing this, yet its also understandable why this might draw suspicions about the practicality and utility of mixing C and Rust in the kernel. But either way it means that after all this time people are still largely arguing over hypotheticals.
[1] Or entirely wrong. Maybe kernel Rust is using flags to ensure aliasing optimizations can't happen. clang (and thus LLVM) supports -fno-strict-alias, but AFAIU alot of Rust code massaging happens on the Rust (MIR or equivalent) side.
Just to be super clear about it, Rust does not do strict aliasing. That’s a totally different set of rules than Rust’s aliasing rules.
I know Rust doesn't do "strict aliasing", literally speaking. But that's partly because Rust's borrowing rules change the framing of the term strict aliasing as used in C, etc. It's similar for terms like "undefined behavior", where there's sometimes a certain amount of pedanticism from Rust developers that merely serves to deflect the point of contention.
Is this wrong? https://doc.rust-lang.org/nomicon/aliasing.html Specifically
> In the previous example, we used the fact that &mut u32 can't be aliased to prove that writes to output can't possibly affect input. This lets us cache *input in a register, eliminating a read.
Is this wrong? https://doc.rust-lang.org/nomicon/aliasing.html Specifically
> In the previous example, we used the fact that &mut u32 can't be aliased to prove that writes to output can't possibly affect input. This lets us cache *input in a register, eliminating a read.
Yes, it is a completely different set of rules. Strict aliasing is also referred to as type based aliasing analysis. Rust has categorically rejected this form of analysis, the aliasing rules are very different. It has nothing to do with types.
Oh, and "undefined behavior" has effectively the same definition in Rust and in C and C++. There's wording differences:
C/C++: behavior for which this document imposes no requirements
Rust: is not bound by any specification
But that's just a wording difference, not a semantic difference.
There are some instances where Rust and C/C++ use similar words to mean different things, but that's also changed over time. For example, Rust used to use rvalue and lvalue, but has moved to
"place expression", defined as "lvalue" in C and "glvalue" in C++
"value expression", defined as "rvalue" in C and "prvalue" in C++
The only reason to not use the C++ terms here is that these are the only two value categories in Rust, and it's unlikely to need all of the other three that C++ has.
You're not wrong that there's stuff called the same but has different meanings, for example, "reference," but what can you do.
C/C++: behavior for which this document imposes no requirements
Rust: is not bound by any specification
But that's just a wording difference, not a semantic difference.
There are some instances where Rust and C/C++ use similar words to mean different things, but that's also changed over time. For example, Rust used to use rvalue and lvalue, but has moved to
"place expression", defined as "lvalue" in C and "glvalue" in C++
"value expression", defined as "rvalue" in C and "prvalue" in C++
The only reason to not use the C++ terms here is that these are the only two value categories in Rust, and it's unlikely to need all of the other three that C++ has.
You're not wrong that there's stuff called the same but has different meanings, for example, "reference," but what can you do.
"The problem with Rust in the kernel is that the kernel has historically eschewed strong internal abstractions. The Linux kernel has no principled abstract architecture in the same way that Windows NT does; it has evolved very organically and even some of the most foundational subsystem APIs regularly see refactorings that touch almost every corner of the kernel."
And this is the reason why it's always regressing and never moves beyond alpha.
And this is the reason why it's always regressing and never moves beyond alpha.
No, I feel this way about the Linux kernel.
Those all exist in the Linux kernel repository. Granted they are not overlapping with c in their purpose for the most part.
One language per repo rules makes sense when you can have many smaller repos, but for something as immense as the Linux monorepo it's really limiting. Especially considering the lack of desire to add stable interfaces from which other repos could operate independently.
One language per repo rules makes sense when you can have many smaller repos, but for something as immense as the Linux monorepo it's really limiting. Especially considering the lack of desire to add stable interfaces from which other repos could operate independently.
[deleted]
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.
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
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
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...
- 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.
You mean C? C++ has been dead and buried for years and there are 0 kernel devs thinking that C++ will ever be allowed in (that idea was killed in the 00s if I recall correctly).
I don't think the situation is quite as extreme as you're making it out. For example, the employers of Linux kernel devs are getting pressure to use Rust because of the push from within & without the industry. I think push comes to shove, most people have a stronger preference for their paycheck than for the language they work in.
With a project as massive as Linux I doubt you can ever assert "there are 0 kernel devs who want [something]"
https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-2936148...
https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-2936148...
There is an Indian fork of the Linux kernel that has C++ drivers:
https://bosslinux.in/bossmool
https://bosslinux.in/bossmool
Typo. I meant C.
And I still think the culture clash angle should be taken more seriously.
An accomplished senior C dev can find good jobs writing drivers or microcontroller code more easily than starting over into a junior rust dev and being talked down by whomever joined the rust wave before them.
(which would be even more aggravating if the C dev is doing it since before the rust adopter was born).
And I still think the culture clash angle should be taken more seriously.
An accomplished senior C dev can find good jobs writing drivers or microcontroller code more easily than starting over into a junior rust dev and being talked down by whomever joined the rust wave before them.
(which would be even more aggravating if the C dev is doing it since before the rust adopter was born).
> 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…
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…
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...
For example: https://gist.github.com/rayvoelker/c5f480f46c80a7a3c22386b29...
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.
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?
But there were no technical arguments against the Rust wrapper. And in any case, the Rust wrapper isn't in that subsystem, it just uses that subsystem. Hellwig's argument was nothing more than "there shouldn't be a second language in the kernel". He had nothing specific about the DMA wrapper. And Linus has already approved Rust in the Linux kernel, so what's the problem? Why can't Linus put his foot down on an issue that he has already decided on?
> Hellwig's argument was nothing more than "there shouldn't be a second language in the kernel".
Which is a valid viewpoint. Let's not pretend that's not a technical argument.
Having different technical views from yours isn't a crime, legally or morally.
> And Linus has already approved Rust in the Linux kernel, so what's the problem?
As an experiment, as clearly stated in the kernel docs. It's still up to the whole community to figure out how exactly to proceed with it.
https://docs.kernel.org/rust/index.html
Which is a valid viewpoint. Let's not pretend that's not a technical argument.
Having different technical views from yours isn't a crime, legally or morally.
> And Linus has already approved Rust in the Linux kernel, so what's the problem?
As an experiment, as clearly stated in the kernel docs. It's still up to the whole community to figure out how exactly to proceed with it.
https://docs.kernel.org/rust/index.html
It is not a valid reason to reject a patch when the decision to include the second language in the kernel has already been made.
A decision to include Rust in the kernel isn't a decision to include any patches from any specific person with no questions asked.
It's valid for maintainers to reject a patch even if you disagree with the reason. Repeatedly causing social media storms to "shame" them for doing so, Marcan's own word BTW, isn't.
Rust is young and efforts to use it in kernel programming is even more so. It's completely understandable for wanting to take things slow and not be too quick to put it in places where there would be no going back. Everyone should at least be able to recognize that this concern exists, regardless of their opinions on Rust.
It's valid for maintainers to reject a patch even if you disagree with the reason. Repeatedly causing social media storms to "shame" them for doing so, Marcan's own word BTW, isn't.
Rust is young and efforts to use it in kernel programming is even more so. It's completely understandable for wanting to take things slow and not be too quick to put it in places where there would be no going back. Everyone should at least be able to recognize that this concern exists, regardless of their opinions on Rust.
I'm sorry, but no. Christoph clearly didn't even spend 5 seconds looking at the patches before rejecting them. His first objection was obviously false, and when this was pointed out he fell back on blanket objection to rust without any real technical argument.
[deleted]
> A decision to include Rust in the kernel isn't a decision to include any patches from any specific person with no questions asked.
This is not what's happening.
This is not what's happening.
> It's completely understandable for wanting to take things slow and not be too quick to put it in places where there would be no going back.
Have you even seen the original thread? It wasnt about "taking it slow", he was trying to block R4L permanently.
Have you even seen the original thread? It wasnt about "taking it slow", he was trying to block R4L permanently.
> > Hellwig's argument was nothing more than "there shouldn't be a second language in the kernel".
> Which is a valid viewpoint. Let's not pretend that's not a technical argument.
So if Linus shouldn't overrule his deputies, and one deputy can completely block something in a subsystem that isn't theirs and has explicitly stated to do "everything in their power" to stop it, what exactly can the community "figure out" to get it to proceed? His decision not to get involved literally makes it impossible for the situation to change, so the confusion is why it's being phrased as if it's anything other than that.
If Linus were to come out and say "I changed my mind, I no longer think it's worth pursing trying to integrate Rust in the kernel due given the issues at hand" or even "regardless of my personal views, I don't have any desire to change the current system we have for how code gets merged into subsystems or who has the ability to block it, so I'm not going to overrule this", it would make a lot more sense to me, but by making it sound like there's anything left to figure out when someone with veto power has a stated intent to stop things from moving forward is just going to let the issue fester and produce more frustration on both sides. It almost seems inevitable that any future discussions will spiral out of control; there's no other way for it to conclude than either Linus overruling his deputy or the experiment just ending as a failure at this point, so he might as well just make that decision now rather than later.
> Which is a valid viewpoint. Let's not pretend that's not a technical argument.
So if Linus shouldn't overrule his deputies, and one deputy can completely block something in a subsystem that isn't theirs and has explicitly stated to do "everything in their power" to stop it, what exactly can the community "figure out" to get it to proceed? His decision not to get involved literally makes it impossible for the situation to change, so the confusion is why it's being phrased as if it's anything other than that.
If Linus were to come out and say "I changed my mind, I no longer think it's worth pursing trying to integrate Rust in the kernel due given the issues at hand" or even "regardless of my personal views, I don't have any desire to change the current system we have for how code gets merged into subsystems or who has the ability to block it, so I'm not going to overrule this", it would make a lot more sense to me, but by making it sound like there's anything left to figure out when someone with veto power has a stated intent to stop things from moving forward is just going to let the issue fester and produce more frustration on both sides. It almost seems inevitable that any future discussions will spiral out of control; there's no other way for it to conclude than either Linus overruling his deputy or the experiment just ending as a failure at this point, so he might as well just make that decision now rather than later.
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
> 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
Linus actually writes C++ code though:
https://github.com/subsurface/subsurface/commit/1b16d570a1b6...
https://github.com/subsurface/subsurface/commit/1b16d570a1b6...
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"
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 he knows he should, but he fears the shitstorm it will cause.
I always felt that the Rust community is creating a huge social pressure on lots of projects. Rust was more forced into the Linux kernel than being welcomed by Linus and many core maintainers. The pronounced evangelism (not a compliment!) in the Rust community is not only off-putting by being a form of non-violent aggression but creates real problems like wasted energy and resources. This is not generally true, as there're great examples of Rust being adopted from within projects. But also others where Rust was pushed from the outside, like curl.
In my opinion it's a failed experiment. The reason for the failure might not be on the technical side, but on the social side. On the other hand, if Linus wants Rust in the kernel as a way to get new, young, enthusiastic devs into Linux core development, than he should use his role and make a very clear statement as he's done before, like: "Everybody shut up and accept and welcome Rust as first class citizen."
[deleted]
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.
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.
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
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.
Can I ask something controversial? What if Rust never becomes a significant part of the Linux kernel? What if they keep stalling and all the people pushing for it give up? There seems to be this faith on HN that Rust absolutely belongs in the Linux kernel and if not, the project is a failure.
If you wait long enough a Rust competitor will gain traction. And honestly I wonder if that might not be for the best. How many of rust’s features have only been tried a couple of times?
The Rust project started 15 years ago, and spent a decade growing userbase, library ecosystem, and proving that it's a serious language that's here to stay (which some C maintainers still don't believe).
We don't have a Rust-killer language yet. The closest one is SafeC++ (Circle), but it's still a single-dev proof of concept, and the C++ leadership firmly rejected it. Zig went in a different direction. Swift is adding Rust-like features, but it's unclear if that's going to be compelling. Ownership and borrowing is spreading to Mojo and Ocaml, but they're not kernel languages.
Even if there's a Rust-killer tomorrow, it will go through the same growing pains of rewriting everything and being treated as just a temporary hype. It will have to prove why use the new language instead of Rust that's already here, and had even more time to establish itself.
We don't have a Rust-killer language yet. The closest one is SafeC++ (Circle), but it's still a single-dev proof of concept, and the C++ leadership firmly rejected it. Zig went in a different direction. Swift is adding Rust-like features, but it's unclear if that's going to be compelling. Ownership and borrowing is spreading to Mojo and Ocaml, but they're not kernel languages.
Even if there's a Rust-killer tomorrow, it will go through the same growing pains of rewriting everything and being treated as just a temporary hype. It will have to prove why use the new language instead of Rust that's already here, and had even more time to establish itself.
> We don't have a Rust-killer language yet.
The type-system analysis of Rust is smart, but not restricted to the language per se, see https://github.com/ityonemo/clr. One merely has to have proper namespacing and necessary type info from generic code to do annotations and solve them. These things are solved in Rust via trait system.
Retroactively patching C to have namespaces will not work and same holds for generics, meaning concrete how to attach lifetimes to generic code.
> Zig went in a different direction.
There is stuff cooking for debugging comptime and better than lsp infos, but this is only wip and hearsay. Might be enough to write external static analysis or not.
Correct me, if wrong etc.
The type-system analysis of Rust is smart, but not restricted to the language per se, see https://github.com/ityonemo/clr. One merely has to have proper namespacing and necessary type info from generic code to do annotations and solve them. These things are solved in Rust via trait system.
Retroactively patching C to have namespaces will not work and same holds for generics, meaning concrete how to attach lifetimes to generic code.
> Zig went in a different direction.
There is stuff cooking for debugging comptime and better than lsp infos, but this is only wip and hearsay. Might be enough to write external static analysis or not.
Correct me, if wrong etc.
There was also Cyclone before Rust, and Checked-C in the meantime. The concepts like regions and affine types existed long before Rust, and Rust started out by copying from older languages (http://venge.net/graydon/talks/intro-talk-2.pdf).
It's not enough to have just a proof-of-concept compiler that could match Rust's checks — that's where Rust was 10 years ago. Rust had time to polish its compiler, expand tooling, integrations, platform support, attract contributors, grow userbase, create learning materials, etc. To displace Rust of today you don't need to just match the old starting point, but offer something better by a margin large enough to offset the cost and risk of switching to a less mature language. That's the same problem that Rust is facing when trying to displace even more established C and C++.
It's not enough to have just a proof-of-concept compiler that could match Rust's checks — that's where Rust was 10 years ago. Rust had time to polish its compiler, expand tooling, integrations, platform support, attract contributors, grow userbase, create learning materials, etc. To displace Rust of today you don't need to just match the old starting point, but offer something better by a margin large enough to offset the cost and risk of switching to a less mature language. That's the same problem that Rust is facing when trying to displace even more established C and C++.
Yes, I do agree with you. Just wanted to inform you that it may still be possible in principle and as you can see with development speed, build system, dependencies etc there is a potential angle.
> We don't have a Rust-killer language yet.
We don't even have a C++ killer language yet. These things move very slowly.
We don't even have a C++ killer language yet. These things move very slowly.
> If you wait long enough a Rust competitor will gain traction.
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.
C was better than assembly. C++ was better than C for GUI applications. JAVA has garbage collection and usually won't force you to fix your machine after a bad crash. Python is better than Perl for quick and dirty stuff. PHP lets you build a web service without much pain. C# is a better Java that also gives you better integration with Windows. Go does a good job with small quick running services. Lua is easy to integrate into programs.
I look at existing C codebases. They're usually well worn and work okay.
C++ codebases would probably be better rewritten in Go or C#
Go codebases? Switching to Rust so you can what exactly?
PHP? Keep using it or us Go.
I also feel like Go, C#, and Python are designed to be fairly easy for a noob to come up to speed. Where Rust is the opposite.
I guess you make a living writing zero day exploits?
Keep believing that Rust magically prevents you from getting owned when you fuck up.
Still owns you, but without data races!
That is a fallacy. No one has claimed that Rust magically prevents you from getting owned. Quite to the contrary: there is no magic in preventing most, if not all memory handling errors. Which are the most common reason for security problems. Removing one category of errors entirely would free a lot of resources to deal with the remaining ones.
Even the "removing one category of errors" is not true when you use unsafe blocks in Rust, which is done generously in system programming.
Is that so? How large parts of the Rust kernel drivers in existence are inside unsafe blocks?
Yes, unsafe, as the name says, allows unsafe parts. But it is trivial to audit code for the usage of unsafe. Which means, everything else isn't. And it is there where the most common mistakes are made.
Yes, unsafe, as the name says, allows unsafe parts. But it is trivial to audit code for the usage of unsafe. Which means, everything else isn't. And it is there where the most common mistakes are made.
Is it trivial to audit? Here is a critical overflow in a matrix transpose: https://vulert.com/vuln-db/crates-io-transpose-125781
This is exactly the mistakes we also have in C and Rust people would do a little dance and take such bugs as argument why C is really dangerous and needs to be avoided. But rather obviously, mistakes can also happen in Rust and Rust does not "eliminate a class of errors" except when completely avoiding unsafe blocks. Maybe Rust is still more memory safe than C, I actually also believe this, but it is nowhere as safe as people like to claim and whether this is worth all the complexity is entirely unclear.
This is exactly the mistakes we also have in C and Rust people would do a little dance and take such bugs as argument why C is really dangerous and needs to be avoided. But rather obviously, mistakes can also happen in Rust and Rust does not "eliminate a class of errors" except when completely avoiding unsafe blocks. Maybe Rust is still more memory safe than C, I actually also believe this, but it is nowhere as safe as people like to claim and whether this is worth all the complexity is entirely unclear.
It is trivial to audit the usage of "unsafe". Grep does this. Of course auditing the unsafe functions is another thing. But you can have large codebases without unsafe and consequently a lot of less work with auditing your code.
I don't have personal experience with Rust, but quite a bit with Go. It is almost ridiculous, how much more safe Go is in comparison with C. So yes, it is worth every bit.
The example shows that Rust can not even prevent an error as something simple as in a matrix transpose. Sure, you could write safe code, but how does this help if people don't do it? It is the exact same problem as in C and I have seen C code that is very reasonable.
Do you have a link to the code with the error? Following your link I didn't see it.
> Go codebases? Switching to Rust so you can what exactly?
The way I heard it, the Rust's type system, async implementation(s), they way lifetimes just keep propagating once you start, and its macro languages are way more engaging, thus Rust must be superior.
The way I heard it, the Rust's type system, async implementation(s), they way lifetimes just keep propagating once you start, and its macro languages are way more engaging, thus Rust must be superior.
but those improvements, and the complexity that they bring, are not enough to make the switch from a Go codebase to a Rust codebase unless performance is REALLY an issue.
> 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".
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".
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.
> 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.
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.
That's a broad generalization to make.
Nintendo's custom OS (Horizon OS, used on Switch and a previous version on 3DS) is almost fully written in C++, including the entire kernel and all drivers.
I agree with you that C++ has plenty of misfeatures. Fortunately, compiler vendors make it fairly easy to dodge the bad parts of the language.
There's C-- (and a few other similar efforts) that are basically C++ with a lot of features forbidden/disabled. I suspect Horizon OS also does this.
I'm not sure if we can still call it C++ in those cases. C++ is more/less a superset of C: we need to know what style of "C++" we're talking about.
I'm not sure if we can still call it C++ in those cases. C++ is more/less a superset of C: we need to know what style of "C++" we're talking about.
3DS HOS was known to be using armcc and Switch HOS is known to be using clang.
Both OSes are huge C++ codebases. Features being disabled or forbidden is a non-userland thing (basically only because resources are constrained. 20KB of exception runtime bload isn't the same thing when you only have 200KB of available RAM vs. when you have 20MB+)
My opinion (and the opinion of people using C++ in such constrained envs.):
* C++ (the language itself along with stuff like <type_traits> and other freestanding headers) is the best thing since sliced bread. So many ways of reducing boilerplate while both writing safe code (RAII) and being mostly in control of produced asm
* most of the other parts of the stdlib are defective
* the committee process sucks, but fortunately compiler vendors allow us to dodge their bad decisions (making #embed available for C++, -fno-exceptions, etc.)
Both OSes are huge C++ codebases. Features being disabled or forbidden is a non-userland thing (basically only because resources are constrained. 20KB of exception runtime bload isn't the same thing when you only have 200KB of available RAM vs. when you have 20MB+)
My opinion (and the opinion of people using C++ in such constrained envs.):
* C++ (the language itself along with stuff like <type_traits> and other freestanding headers) is the best thing since sliced bread. So many ways of reducing boilerplate while both writing safe code (RAII) and being mostly in control of produced asm
* most of the other parts of the stdlib are defective
* the committee process sucks, but fortunately compiler vendors allow us to dodge their bad decisions (making #embed available for C++, -fno-exceptions, etc.)
thank Linus for you
> 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.
He probably didn't want to end up like Stallman.
> 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...
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...
I agree with all statement from Linus. Keep it separated/downlined project I think is the best for both worlds.
> 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
People change. As you get older, you might find you no longer care that much about subjects you previously had very strong opinions about
>..... 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 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.
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.
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.
This really makes me want to learn rust and contribute to Redox.
[deleted]
Do it.
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.
> 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.
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.
Yeah I commented before I saw that one toot from @sima. Indeed they both look bad here.
Is Sima paid for his contributions?
https://blog.ffwll.ch/about/
> Currently I work at Intel’s Linux Cloud SE group, mostly creating havoc in kernel driver’s given my more than a decade of work in the graphics subsystem. I’m also co-maintaining the graphics subsystem. I also have been drm/i915 kernel maintainer for a few years, but handed that all off to a great new team.
> Currently I work at Intel’s Linux Cloud SE group, mostly creating havoc in kernel driver’s given my more than a decade of work in the graphics subsystem. I’m also co-maintaining the graphics subsystem. I also have been drm/i915 kernel maintainer for a few years, but handed that all off to a great new team.
Sima is another Rust for Linux member, right?
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.
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.
Linus replied:
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.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...
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.
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...
If shaming on social media does not work, then tell me what does, because I'm out of ideas.
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 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.
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.
[deleted]
> 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)
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)
[deleted]
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.
P.S I don't have skin and skill for the kernel game. I'm just a curious bystander.
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.
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.
That's good to hear. Thanks.
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.
IOMMUs do help.
> 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".
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".
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".
No idea what the particular bit of drama discussed here is about, but that's my impression of the Rust "community".
any community can be called that if you squint hard enough and especially if you ignore the silent, get-the-job-done-and-go-home members of it and only listen to evangelists.
Not all communities have evangelists tho.
And if they need evangelists, it's a safe assumption for me that they don't have other merits.
And if they need evangelists, it's a safe assumption for me that they don't have other merits.
That sounds like a pretty dishonest interpretation of that effort.
> 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-...
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-...
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).
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).
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.
> 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.
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 absolutely a wild to me how this is not talked about more. All it takes is for a set of highly praised institutions to use Rust for their major courses and now you will have generations which C is just something you know about.
[deleted]
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.
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.
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.
and they have one: Redox
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.
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.
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.
ActorNightly(4)
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
[deleted]
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.
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.
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.
[deleted]
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.
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.
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.
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.
The goal is to make rust relevant to Linux raising its own importance and legitimacy. The value is at least in part political. It can't achieve that goal in a branch.
[deleted]
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!
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.
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...
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...
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...
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...
> 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.
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.
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
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
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
https://www.redox-os.org
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's taken Wayland 16 years to become a serious alternative to X11. You think a whole kernel can do it faster?
Well, with AGI...
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.
An interesting question: Who is the Linus Torvalds for Rust in the kernel? Who says no to slop?
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/
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
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?
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.
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!
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.
This "we're viral" behavior when "it's really not" is very childish.
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.
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.
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?
Was your comment wrote by a junior javascript developer?
Get a room you two
> (i'm on WSL which DOES NOT have a rust toolchain)!
This is plainly false.
This is plainly false.
[deleted]
I would encourage it in the Kernel. Maybe even go as far as porting large portions to Rust.
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://rachelbythebay.com/w/2018/10/09/moat/
https://news.ycombinator.com/item?id=18181409
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://rachelbythebay.com/w/2018/10/09/moat/
https://news.ycombinator.com/item?id=18181409
https://rachelbythebay.com/w/2013/06/03/bugs/
EDIT Wrong one sorry
EDIT Wrong one sorry
> 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...
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...
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).
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).
[deleted]
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.
(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.
> Isn't the current Linux already Linus + communities + companies?
Absolutely. To that point the companies I listed are the ones that I'm aware of employing kernel developers who work specifically on rust in linux.
The control of the project is in Linus's/community hands though, not corporate ones, and I think that's a good thing.
> More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync.
I don't think so. Linux is a huge modular system, and no one is really interested in rewriting the core components of it at this point. Nor maintaining their own copies of components that some other company is responsible for (like graphics drivers). Until and unless it became the dominant fork I'd expect that they'd keep merging in the mainline branch and updating their things as necessary.
This is already how projects like Android work.
Absolutely. To that point the companies I listed are the ones that I'm aware of employing kernel developers who work specifically on rust in linux.
The control of the project is in Linus's/community hands though, not corporate ones, and I think that's a good thing.
> More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync.
I don't think so. Linux is a huge modular system, and no one is really interested in rewriting the core components of it at this point. Nor maintaining their own copies of components that some other company is responsible for (like graphics drivers). Until and unless it became the dominant fork I'd expect that they'd keep merging in the mainline branch and updating their things as necessary.
This is already how projects like Android work.
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?
It can, but Linux does not have a stable driver ABI. Whoever wrote the out-of-tree drivers would have to constantly update them whenever there was a breaking change to the kernel, which I understand is relatively common.
That's interesting. Dumb question but why doesn't Linux aim for a stable driver ABI? Does it impede delivery speed?
I think nvidia uses out-of-tree drivers that are dynamically loaded - does that mean that nvidia drivers are tied to specific kernel versions?
I think nvidia uses out-of-tree drivers that are dynamically loaded - does that mean that nvidia drivers are tied to specific kernel versions?
The rationale for not having a stable driver ABI is here: https://www.kernel.org/doc/Documentation/process/stable-api-...
RE: nvidia - yes
RE: nvidia - yes
nvidia uses "DKMS" to rebuild itself for each running kernel.
Closed source modules like nvidia frequently have a kernel-independent proprietary piece and a kernel-specific (open source) ABI piece. Whenever you upgrade your kernel, DKMS will re-build the kernel-specific shim and re-link the proprietary blob. The result is a .ko tailor made for your running kernel, even though most of the code is in a kernel-independent blob.
Closed source modules like nvidia frequently have a kernel-independent proprietary piece and a kernel-specific (open source) ABI piece. Whenever you upgrade your kernel, DKMS will re-build the kernel-specific shim and re-link the proprietary blob. The result is a .ko tailor made for your running kernel, even though most of the code is in a kernel-independent blob.
It looks like nVidia is open to moving their open driver (which requires a card that as a GSP) upstream [1] but with Rust being killed from the Linux kernel that's probably dead.
[1] https://www.phoronix.com/news/NVIDIA-Exploring-Upstream-KMD
[1] https://www.phoronix.com/news/NVIDIA-Exploring-Upstream-KMD
Yes, it can load drivers dynamically.
There is a reason why in-tree drivers are preferred, and that's because the Linux driver interface and API changes with kernel API changes. The API is considered unstable in the sense that is it not unchanging.
A driver written for one release of Linux may not work with the next release as the API changes.
There is a reason why in-tree drivers are preferred, and that's because the Linux driver interface and API changes with kernel API changes. The API is considered unstable in the sense that is it not unchanging.
A driver written for one release of Linux may not work with the next release as the API changes.
Yes, it technically does (kernel modules), but the difference between Linux and NT is that Microsoft guarantees (as much as possible) that its ABIs are stable whereas Linux explicitly does not preserve backwards compatibility in the kernel (only the userspace is the stable interface).
EDIT: Reading this: https://www.kernel.org/doc/Documentation/process/stable-api-...
It seems like a huge technical factor holding back a stable ABI is the C compiler itself. Binaries changing between compiler versions and changing with different compiler flags.
So while your code can be written such that it appears to respect the interface of an external library, the underlying binary representation might not line up correctly.
If there is agreement that modularity is good for the kernel but technical limitations prevent that from being a reality - surely the solution is to improve C's interoperability first?
---
I'm not a kernel developer and am probably naive here, but on the surface it feels like offering a stable driver ABI is one possible solution to the rust-in-linux controversy that has lead to so many people exiting kernel development.
I'd imagine if projects like Asahi could simply offer out-of-tree drivers, they wouldn't need to maintain a kernel fork (at least not for drivers) or negotiate with core maintainers (which I understand is stressful).
Might also make it easier for vendors like Qualcomm/Samsung/Nvidia to distribute drivers out-of-tree, perhaps reducing the need for long running Linux forks and allowing devices to update to modern Linux kernels.
As a novice hacker, I'd imagine the ability to reuse proprietary driver blobs would allow distros to be created targeting hardware that was otherwise impossible to access as drivers were hidden behind custom kernel forks (e.g. install mainline Fedora on a Samsung phone, taking the GPU driver from the Samsung build of Android - or OpenWRT on an Android powered portable 5g modem).
It seems like a huge technical factor holding back a stable ABI is the C compiler itself. Binaries changing between compiler versions and changing with different compiler flags.
So while your code can be written such that it appears to respect the interface of an external library, the underlying binary representation might not line up correctly.
If there is agreement that modularity is good for the kernel but technical limitations prevent that from being a reality - surely the solution is to improve C's interoperability first?
---
I'm not a kernel developer and am probably naive here, but on the surface it feels like offering a stable driver ABI is one possible solution to the rust-in-linux controversy that has lead to so many people exiting kernel development.
I'd imagine if projects like Asahi could simply offer out-of-tree drivers, they wouldn't need to maintain a kernel fork (at least not for drivers) or negotiate with core maintainers (which I understand is stressful).
Might also make it easier for vendors like Qualcomm/Samsung/Nvidia to distribute drivers out-of-tree, perhaps reducing the need for long running Linux forks and allowing devices to update to modern Linux kernels.
As a novice hacker, I'd imagine the ability to reuse proprietary driver blobs would allow distros to be created targeting hardware that was otherwise impossible to access as drivers were hidden behind custom kernel forks (e.g. install mainline Fedora on a Samsung phone, taking the GPU driver from the Samsung build of Android - or OpenWRT on an Android powered portable 5g modem).
DrillShopper has already posted (https://news.ycombinator.com/item?id=42979848) the technical reason on why Linux does not do it this way: https://www.kernel.org/doc/Documentation/process/stable-api-...
Additionally, there is politics in play here. Not the politics that is normally discussed outside of HN, but the politics of having companies (at least) release the detailed specifications of their hardware. I cannot really state authoritatively what the Linux developers think on this side, but Linus brandishing his middle finger to Nvidia (https://youtu.be/MShbP3OpASA?si=GJ1_0B81b7bFY_iZ&t=2890) says a lot of things.
Additionally, there is politics in play here. Not the politics that is normally discussed outside of HN, but the politics of having companies (at least) release the detailed specifications of their hardware. I cannot really state authoritatively what the Linux developers think on this side, but Linus brandishing his middle finger to Nvidia (https://youtu.be/MShbP3OpASA?si=GJ1_0B81b7bFY_iZ&t=2890) says a lot of things.
> It seems like a huge technical factor holding back a stable ABI is the C compiler itself.
Not really. Every OS has a stable C ABI, otherwise there would be no stable OS API functions and no application plugin APIs. The actual reason seems to be that they simply do not want to commit to a stable ABI/API so they are free to make breaking changes and remove outdated APIs. Fair enough, but don't blame it on the compiler!
Not really. Every OS has a stable C ABI, otherwise there would be no stable OS API functions and no application plugin APIs. The actual reason seems to be that they simply do not want to commit to a stable ABI/API so they are free to make breaking changes and remove outdated APIs. Fair enough, but don't blame it on the compiler!
To my knowledge, out-of-tree drivers are quite inconvenient to maintain compared to in-tree drivers, due to the kernel's unstable API (a driver that works on a given version of the kernel likely only works on that single version unless it has lots of ifdefs to handle all the other versions).
> controlled by Google/Samsung/Redhat/Microsoft.
Can they do that to openssl instead?
Thank you.
Can they do that to openssl instead?
Thank you.
They did: https://github.com/aws/aws-lc / https://github.com/google/boringssl
(Not in rust, but it's mostly assembly anyways so I'm not sure rust provides much. There is https://github.com/briansmith/ring in rust, not sure if it's sponsored by anyone)
(Not in rust, but it's mostly assembly anyways so I'm not sure rust provides much. There is https://github.com/briansmith/ring in rust, not sure if it's sponsored by anyone)
> 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.
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.
I may have edited the phrasing within a minute or two of posting, couldn't say. I haven't edited the comment in the 14 hours since then, and the sentiment was in the original.
(I have edited this comment on the other hand, first to explicitly disagree with various statements in the above, then to delete those disagreements since I don't really want to get baited into an argument)
(I have edited this comment on the other hand, first to explicitly disagree with various statements in the above, then to delete those disagreements since I don't really want to get baited into an argument)
Why do people think rejecting rust drivers is a bad thing? It's a fucking c project.
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?
Has anyone done that?
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
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
Rust aside, it uses a microkernel, multiserver architecture.
And, of course, drivers run in userspace and interact with the system through a clearly defined API.
Other systems like this include Robigalia, Lions OS and Genode.
They would likely quickly overtake Linux if they got 1% of the resources Linux receives.
And, of course, drivers run in userspace and interact with the system through a clearly defined API.
Other systems like this include Robigalia, Lions OS and Genode.
They would likely quickly overtake Linux if they got 1% of the resources Linux receives.
Correction, where I said Robigalia I meant Managarm.
Robigalia is also an effort, but one that hasn't been touched in nearly a decade.
Robigalia is also an effort, but one that hasn't been touched in nearly a decade.
https://github.com/asterinas/asterinas
Asterinas is such an experiment. Purely written in Rust and Linux ABI compatible.
Asterinas is such an experiment. Purely written in Rust and Linux ABI compatible.
Projects don't just live or die purely on technical merits. There are so many examples across history of this.
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'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
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
> 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.
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.
That is a perfect description on what has been happening over the years.
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 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
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.
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.
Do the Rust drivers provide significant benefits over C equivalents (or over typical C drivers), enough to make it worth switching?
Rust may have to really prove itself with results. And why shouldn't it?
Rust may have to really prove itself with results. And why shouldn't it?
There are no C equivalents for the drivers I’m talking about.
I got that - that's why I added the parenthetical. My point was the second sentence. Anyway, thanks for the input about the drivers.
And for what it's worth, I expect Rust would offer significant improvements.
And for what it's worth, I expect Rust would offer significant improvements.
Ah, sorry, I misunderstood you. I don’t have a link handy, but Marcan had a post about how they actually re-wrote some in progress drivers from C to Rust because it was easier to do, and so didn’t expect a c version to exist. Basically it was about how driver complexity has increased over time, and Rust helps tackle that in a way that C can’t.
Yes, I realized later that I should add 'efficiency' (for development) to security and stability, which could also be a big win for Rust in particular.
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.
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.
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 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.
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.
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.
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.
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 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
Good reminder to take a look at FreeBSD
Good reminder to look at FreeBSD
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.
> 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.
I tried helping with the Linux kernel once, in 2001.
I haven't since.
I don't need abrasive people in my life.
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
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
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.
> the fact that rust is highly compute intensive language
care to elaborate on that?
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
I agree with Hector Martin here. The mailing list format is putting off so many developers. Linux needs to modernize.
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.
See https://lkml.org/lkml/2025/2/7/15 for example.
Is this the same person who has YouTube videos narrated by a cartoon Japanese schoolgirl?
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.
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.
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.
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.
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
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”
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 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.
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.
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.
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
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)
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)
[deleted]
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.
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.
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'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...
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…
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…
Actually… I'm really not a fan of how Mastodon handles account deletion. I've interacted with him there about a week ago, and all of his posts are now missing from those threads. I guess it makes sense from a "be able to change your ways and not be stuck with ancient bad things you did" perspective, and there's a right to deletion/"be forgotten" in some legal frameworks, but this hinders necessary community processes. At least the LKML mails are permanent…
I would've liked to link a post or two of his to show just how little flexibility and tolerance there was from his end regarding his social interactions, even when being questioned about them in an outside context and in a reasonably neutral manner. Ohwell…
I would've liked to link a post or two of his to show just how little flexibility and tolerance there was from his end regarding his social interactions, even when being questioned about them in an outside context and in a reasonably neutral manner. Ohwell…
When you delete something, your instance sends Delete events to other instances. Well behaved instances respect this request, but you could have an instance that does not.
> whether he's just lying, or both things are true and he just deleted his account after it was suspended
This is obviously just a Mastodon bug (backend treats suspension and deletion as the same thing, for example). I'm not sure why one would entertain the idea of marcan making up a lie about being suspended from an instance he's an admin of.
This is obviously just a Mastodon bug (backend treats suspension and deletion as the same thing, for example). I'm not sure why one would entertain the idea of marcan making up a lie about being suspended from an instance he's an admin of.
I am on the moderation team at Treehouse. Marcan has not violated any of our community guidelines and he categorically was not suspended from our Fediverse instance. He chose to delete his own account.
I can reproduce the bug:
1. go to https://social.treehouse.systems/explore
2. type @marcan in the search box
3. select "go to profile" from suggestions
Feels like a problem with the dynamic/partial JS content loading.
(Apologies for the confusion, there's no indication that made me suspect a bug... and I hadn't at that point seen anything about him deleting his own account yet.)
1. go to https://social.treehouse.systems/explore
2. type @marcan in the search box
3. select "go to profile" from suggestions
Feels like a problem with the dynamic/partial JS content loading.
(Apologies for the confusion, there's no indication that made me suspect a bug... and I hadn't at that point seen anything about him deleting his own account yet.)
Thanks, yeah, this is definitely a bug or something.
[deleted]
tw1984(1)
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
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. :/
Rust has probably the most toxic people in open source software.
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.
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.
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.
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 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.
> 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.
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.
[deleted]
Not an especially significant event, by the numbers. It's a large community so there are tails.
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.
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.
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.
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.
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.
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
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
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!!
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.
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...