Asahi Linux Lead Developer Hector Martin Resigns from Linux Kernel
160 comments
·February 7, 2025gary_0
dralley
>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.
gary_0
Positive, yes, but can you point to where he says R4L is here to stay and an integral part of the kernel? He needs to commit, or drama like this will continue to boil over. He also seems content to let the C-only old guard give the R4L guys a hard time. If you only enforce the rules on one side of a conflict, it makes it pretty clear which side you agree with.
starspangled
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.
gauge_field
Agree with that. His statements are available on youtube. I was suprised how positive and eager to the change he was.
tptacek
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.
duxup
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?
mauricioc
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...
tptacek
Yikes, re that fedi thread.
null
chippiewill
> 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.
nialv7
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!
ChocolateGod
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?
Philpax
Because the community here were frequently assholes about specific maintainers, yes.
nozzlegear
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...
Hamuko
>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.
duxup
I'm not arguing that this is or isn't a problem but I think the statement "using social pressure to influence decisions" is so general that it could apply to just any discussion. That's kinda what discussion is.
Granted there are acceptable methods within that, and not acceptable.
nicce
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:
bakugo
> "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.
trollied
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.ho_schi
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...
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.
mplewis9z
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...
nubinetwork
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.
naasking
> 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.
harvey9
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.
mid-kid
why bother infering such intent when the obvious answer - that they simply forgot about it with no ill intentions - is right there?
arghwhat
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.
cataphract
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".
Philpax
What is the interpretation of "cancer" in this context that isn't rude, offensive, or hostile to the R4L project?
dearing
Mixing codebases in the Linux core.
I think the conversation is more about people equating R4L as validation for rust or even themselves.
Ygg2
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.tptacek
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.
Hamuko
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.
tptacek
They do, but they have a stated goal of maximizing contribution. Linux does not, right? I'm asking.
threatofrain
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.
nialv7
Looks like @marcan deleted his existence on mastodon? Does anyone have a copy of what he said on there?
ndiddy
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."
dralley
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.
hexmiles
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
AgentME
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.
jeroenhd
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.
CopperWing
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.
Zollerboy1
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.
paholg
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.
Longhanks
> 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.
pyrale
> 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.
tedivm
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.
noirscape
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.
gpm
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.
noirscape
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).
nicce
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.
dralley
>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.
nicce
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..
Dr_Emann
"The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux." https://lwn.net/ml/all/20250204052916.GA28741@lst.de/
That doesn't sound like he's only talking about in his area to me
rcxdude
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.
bjord
is this just weird religious adherence to the belief that a multi-language codebase will be harder to maintain? what's the rationale, exactly?
null
znpy
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.
sgt
Give him time, Linus will reach out soon regarding Rust.
Tomte
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.
Dalewyn
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.
7e
[flagged]
Havoc
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
chippiewill
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.
lloeki
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.
null
coldtea
Martin has worked hard on Asahi, but comes of as looking for drama and virtue signalling oftentimes. I'd give this to Linus.
duxup
>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.
ubermonkey
My usual take is that anyone who uses the phrase is most often not speaking in good faith.
duxup
I like to not assume the worst, more so on HN, but I do run into a lot of situations elsewhere on the internet where "virtue signaling" just means "someone said something I don't like".
But generally I do like to wait to understand specifically what someone means before assuming.
Dansvidania
so how should it be called, in good faith?
Cumpiler69
>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.
wolvesechoes
"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.
bmicraft
It's called systemd, all lowercase, no punctuation :)
randmeerkat
> 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.
aleph_minus_one
> 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.
flohofwoe
> 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.
Dansvidania
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)
duxup
I hate to mention this but closed source appears to involve humans too. I was disappointed when I discovered this as well.
bakugo
> but comes off as looking for drama and virtue signaling oftentimes
I haven't met a single Rust developer that this description didn't apply to. Starting to think it's not just a coincidence.
ziddoap
>Starting to think it's not just a coincidence.
Is your theory that rust makes people dramatic? Or that dramatic people like rust? What other options are there, if not coincidence?
Eval-Apply
>Is your theory that rust makes people dramatic? Or that dramatic people like rust? What other options are there, if not coincidence?
There is a cognitive bias called "loyalty to the brand", in which it says that people prefer the things they have because they rationalize their choices to protect their sense of ego. When they invest time (or a lot of money) to something, they create an emotional connection, especially if that was a choice and not something imposed on it. It is choosing one thing about the other that leads to narratives about why you have done a certain thing, something that is usually connected to your self-image.
There are a number of cognitive trends that converge to create this behavior. This assignment effect appears when you feel that the things you have are superior to things you don't have. Another bias is the fallacy of irrecoverable costs. This happens when you spend time or money on something you don't want to have or don't want to do, but you can't avoid. For example, imagine that you spent time studying Rust. You will be "hooked" on the idea that given the time spent in this, it is better to defend the language, even if you imagine that it is not for all things.
To combat post-decisional dissonance, the feeling that you committed to one option when the other option could have been better, you strive to feel justified as to what you selected to reduce the anxiety created when questioning himself. All this forms a gigantic group of neurological associations, emotions, details of self-image and trends around the things you have.
Pannoniae
I think the second one is more likely. People choose languages and ecosystems which fit their way of thinking so naturally, the ecosystem shifts to that direction. This is a self-reinforcing loop :) (one can naturally see this in many languages when the language advocates say "you are just holding it wrong...")
zoogeny
I would argue the second.
I think it is a human trait to like to win arguments. In some card games, there is a thing called a trump card [1]. The trump card has this special ability to beat all other cards.
Rust has a kind of trump card: memory safety. If you get in an argument about code it is often possible to maneuver the argument in the direction of memory safety at which point the Rust advocate gets to default win the discussion.
I think this "trump card" aspect attracts a particular kind of person to advocate for Rust simply because they like to feel technically superior to others. Whenever they are in an argument, no matter what the context, they simply have to play the game: how can I make this technical argument about memory safety so that I can win by default.
bakugo
> Is your theory that rust makes people dramatic? Or that dramatic people like rust?
Both, really. As a language that was designed from the ground up to be a replacement for C and C++ (thus implying that it's superior to these established languages), it positions itself as inherently "dramatic" and anti-establishment.
This obviously attracts these political activist types who love to insist that their way of thinking is the way forward, that everyone else was simply doing it wrong before they came along, and that anyone who questions their beliefs is an obvious enemy of progress who should be silenced at all costs. It's a cult, basically.
dralley
...As opposed to kernel developers? Or even Linus himself 5 years ago?
markus_zhang
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.
lelanthran
> 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".
gpm
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).
pjmlp
They have,
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.
plagiarist
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.
markus_zhang
That's good to hear. Thanks.
pjmlp
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.
yarosh
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.
cosmic_cheese
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.
null
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".