Resigning as Asahi Linux project lead
-
If that does happen, I just hope there will be enough developers by then that can/will want to use it (as in, write rust code). Especially developers that can put up with the kernel process and its people.
-
If R4L authors want to use Rust so badly, then still:
Maintain your own tree! Let's see how simple and clean these interfaces are over the longer haul.
They will get mainlined if they are technically superior.
-
Take this case, it all started over a bit of code. The subsystem maintainer refuses to take it. But it does not require any changes to existing code. It just has to be merged.
Linus can take it directly. If he does that, the Rust folks can start to use it. The sub-system maintainer will lose in the end.
At some point, the battle will be lost by those trying to block Rust.
It all depends on Linus. We will see.
Linus hasn't been merging the necessary code, by virtue of supporting a maintainer who was very obviously trying to sabotage R4L; if Linus was going to stand up for R4L, this would have been the time.
-
Linus can merge whatever patches he wants to, and the stonewalling subsystem maintainers would have to deal with it--like he did with the eBPF scheduler. R4L maintainers already wrote the patches, they literally just needed to be merged.
-
Slightly OT but I always thought Asahi Lina was a woman. TIL.
-
You're probably right from a legal perspective, but the difference between "donation" and "salary" is pretty murky in this context.
-
Yes, but asking him in this case was basically a courtesy, the code isn't going into anything he manages. He can reject it, but that's an opinion, not a decision. It can still be merged if the regular maintainer (or someone senior like Linus himself) approves.
-
It was merged into mainline, in 6.1, over a year ago.
-
People are not under sanctions, and no linux developer worked for the Russian government, and since when has a war affected who works on what open source project. There are wars all over the place all the damn time ..
I am not talking about the sanctions, I am talking about the additional remarks on how nationalist and racist both the leaders of the project appeared to be from their statements.
-
It sounds like you really value skill and precision.
-
It's never been confirmed that they are the same person, and they both operate as if they are completely separate people. Lina goes by she/her on stream as well.
-
They are not irrelevant points and hopefully I can show why.
So I went fishing through the kernel rust directory and didn’t find any drivers. It’s late and I definitely missed a lot (I didn’t even go through the drivers branch, but should rust code be there? I thought it all lived in /rust…), but the r4l page lists the nvme driver, an implementation of existing functionality in rust that is in the words of its description page “not suitable for general use”. The r4l page also has the null block driver, which is not a strictly speaking useful thing for actually doing stuff with the computer but is a great way to do a bunch of goofy crap and its page on the r4l website explains why it’s being rewritten in rust.
I just want to pause here in the comment and say that the null block driver is actually a phenomenal thing to be rewriting in rust for so many reasons.
Then there’s the android binder driver which is not something I understand enough to comment on, but is a rewrite in rust. I also saw a puzzlefs driver on the r4l page. Puzzlefs is an experimental file system written in rust to begin with so it’s no surprise the Linux driver is rust.
Last the r4l page offers two gpu drivers, the apple one that asahi uses and the nvidia nova one which seems to be in the early stages of development.
As I said, I probably missed some drivers and other rust code that needs to use —since it’s our topic of discussion— the c dma bindings through a wrapper.
But if all six of those used the dma c bindings wrapper then that’s still far short of my agreement with you that the right way would be to write a bunch of good rust shit that uses the wrapper then say “hey, if we move this wrapper into dma directly it’ll save 10k lines of code because it’s a hundred lines and used in a hundred things”.
Instead it’s used by three rewrites (the point of r4l!), an experimental file system, a in development gpu driver and the asahi mac driver.
For a third time, I’m absolutely 100% sure there’s more rust drivers than that, but enough to make the argument that you’re taking a hundred lines out of a hundred places?
When I was younger I was involved in local government. I was idealistic and thought that having been accepted at the table, the correctness of my ideas would be evident and they would be accepted and implemented quickly. Of course I was very wrong and was surrounded by competing interests vying for limited resources so the force of my argumentation had almost no effect.
What was effective was constructing scenarios that made it almost impossible for people to act in ways other than what I wanted.
I chose a narrative analogous to the common rust person complaint of “political reasons” here on purpose because ultimately instead of appealing to an authority to settle the chicken or egg problem for them (which is somehow not political, despite the authority existing within some governing structure but whatever!) rust devs should be saying “who the fuck cares, I’m headed to market with a cartload of chickens and eggs, you gonna give me a stall to sell out of or am I gonna be clogging up the thouroughfares?”
-
Then this isn't being blocked?
-
You really think it is okay to say “I will try project A, I need donations” and then go on a holiday with the donated money and do nothing else?
Yes. A donation is a donation, fullstop.
Would I feel good or morally okay doing such a thing? Absolutely no way. I acknowledge that internal inconsistency. If someone gives me something, I feel obligation to give back.. simple as that.
Objectively speaking though, a donation is not a contract, and to expect a donation to have future influence is a messy method of doing business that should be viewed with a pretty critical eye. If a person giving money wants an obligation, they should pursue a contract.. If they don't care what happens after they give the money but just want to show support or appreciation, that's where donations shine.
If I gave a donation to my favorite videogame dev, but then 2 hours later they stopped supporting that game, I'd still be happy I showed them support for what they had given me so far. I believe retroactively being unhappy about giving a donation shouldn't cast the receiver in a bad light, and that it's the giver that didn't understand what they were doing and what the potential outcomes were.
-
I don't know if the code marcan was talking about is still going to be merged. It wasn't actually being blocked, but that doesn't mean it was approved either.
-
So, not blocked, merged in, already maintaining a tree, just one maintainer isn't sold yet on the implementation.
Im just not seeing a problem then? Aside from the person experiencing burnout, which I get. But burnout may not indicate a cultural problem, either. Especially if the person is coming off of a rough year, personally.
-
What code has he not merged? Was his argument technical or political?
I see lots of R4L code being merged in each of the last few releases.
I also do not see the email where Linus supported Christoph. I see the one where he chewed out Hector for “social media brigading”. That is not the same thing as supporting the maintainer. Hector is not even the one submitting the Rust code in question. He just piled on in the LKML later.
-
Fair point. I do think burn out is a problem for the process in general. I guess Linux has always benefited from the long line of people looking to contribute. As long as progress is being made, I expect that to continue here.
-
I doubt you care but others may want to know that you just hit the nail on the head. Just not the way you think.
All the Rust folks want is for “technically superior” solutions to be accepted on their merits. The exact problem is that some influential Linux folks have decided that “technically superior” is not the benchmark.
Take the exact case that has led to the current debate. The maintainer said explicitly that he will NEVER accept Rust. It was NOT a technical argument. It was a purely political one.
In the Ted Tso debacle. a high profile Rust contributor quite Linux with the explicit explanation that the best technical solutions were being rejected and that the C folks were only interested in political arguments instead of technical ones.
If it was true that “technically superior” solutions were being accepted, the R4L team would be busy building those instead of arguing.
-
The project has said it is a goal to move to a dual language model. So, no, it is not reasonable.
What would be reasonable would be technical arguments or pragmatic logistical concerns with the goal of finding solutions. What would be reasonable would be asking for and accepting help.
None of the reasonable stuff is happening. So, it not reasonable.