Resigning as Asahi Linux project lead
-
This comment is exactly why R4L isn't happening: "Not my problem, go fork it."
You're correct, Linus's role isn't to promote or aid R4L. However, he certainly seems to turn a blind eye to the devs who actively block rust initiatives and are quite nasty about it.
If Rust is going to happen, then it’ll happen.
People are trying to make it happen. It's not blocked by technical obstacles, it's blocked by people. Go read the mailing lists, it's embarrassing.
This situation is not new by a long shot. But the folks maintaining the linux now won't be around forever, and neither will C. It would be in our collective best interests if we figured out how to move beyond a C-only kernel and included potential paths of inclusion for other arguably more modern coding languages, and without being at each other's throats about it.
-
but I have enough experience with c, c++ and rust to know that those wrappers don’t need to be in the kernel if the kernel has c bindings.
I think you have a fundamental misunderstanding of the topic.
If I were writing something in rust I could just include the r4l wrapper for the kernels c bindings and everything would work fine. The wrapper doesn’t need to be in the kernel.
We're talking about device drivers, which are part of the Linux kernel. If you develop these wrappers outside the kernel tree, you're making the situation even worse, since the kernel suddenly has a new dependency.
This approach was never considered, even by the maintainers that blocked wrappers, because it would be far worse than every other possibility.
Instead the question is: does every driver have to include a copy of the wrapper, or can there be one copy that's used by all the drivers? And obviously one copy makes far more sense than N different copies.
I'll skip over the rest of your comment, since it all seems to be built on a broken foundation.
-
Or I can ask Linus to do his job properly and lead on this issue, whether it’s for or against R4L.
Linus owes you, nor anybody not signing his paycheck, a goddamed thing. Did you bother to read the article linked here?
You seem to be under the impression that I’m somehow involved with R4L or Rust, or that I even use Rust.
Ok then.
I’m just seeing an example of bad project management, and people like you that keep lying to justify the maintainers decision.
Nobody committing code to the Linux project, nor anybody doing the administrivia work owes anyone not involved in the project a goddamned thing. If you think you can manage it better, then fork, and do it.
Otherwise, you're expecting other people to do free labor for you, and to do it to your specs. The world doesn't work that way, and nobody owes you their labor.
-
I am with you on that last line. However, I remain more hopeful.
As long as Linus keeps merging code, Rust will eventually win. And by win I just mean that it will overcome the haters sufficiently to render their resistance futile.
There is only so much support infrastructure needed before large chinks of Rust can be committed ( at least on the driver side ). We are not so far away from that. Once real code starts to appear the “show me” will drive adoption elsewhere.
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 l, the battle will be lost by those trying to block Rust.
It all depends on Linus. We will see.
-
Are you referring to the time they kicked out a bunch of people employed by the companies associated with the Russian government and that are under direct sanctions for supporting the war?
-
Linus owes you, nor anybody not signing his paycheck, a goddamed thing.
No, he owes the community to fulfill his role in this community project. He's not a king or a monarch or whatever you think he is. If he's not ready to fulfill this role, he should step down as project lead.
-
If you are replying with "isn't this the guy" it means you didn't bother to read the post, which also removes the merits of you questioning if what he is claiming is fiction or not.
But people on HN provided context and it indeed seem he was stalked and harassed, but through his VTuber persona and there was even a GDocs document with the details.
-
I'm sorry for having said something untrue. For example, I saw someone saying that they do have fractional scaling with GNOME on their laptop. I see how it's untrue to say "fractional scaling is non-existent".
However, is my experience untrue? Was I lying when I said that my track-pad two-finger scrolling is frustrating? Furthermore, it's not unusual for people at work to try my track-pad and it being way too sensitive or too un-sensitive, but no in between.
Was I lying when I said that, for me, it's hard to get software? Was I lying when I said that maybe this is a skill issue on my part, but even that is indicative of a lack of easy ways of getting reassurance in the way that Apple makes it easy to find software in their App Store?
Was the creator of the Mojo language lying when he recounted his experience developing Swift?
-
Amazing. I should look into that! How did you enable it? I did a quick search and found I just need to do
gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"; is that it? -
Sima (Simona Vetter) quotes "Being toxic on the right side of an argument is still toxic, [...]" while being toxic
-
I believe it was enabled by default on Ubuntu.
-
Thing is, there is already Rust in Linux, and Torvalds wants more, faster. Ved being sabotaged by C purists, who at this point should stop acting unprofessionally, or at the very least make their own "only C" fork if they disagree with his leadership so much.
-
No, he owes the community to fulfill his role in this community project
Not really. He owes nobody his labor. If people don't like how he runs it, they can fork, and run it as they please.
He’s not a king or a monarch or whatever you think he is.
Of course he's not. And, neither are you. Neither of you can place demands on others to perform free labor.
If he’s not ready to fulfill this role, he should step down as project lead.
Well, he thinks he is fulfilling his role. You don't. So, its up to you to show everyone how to do it right.
I've found most people who claim others "aren't doing it right" actually mean that "they aren't doing it how I want it to be done, and therefore I demand they do the work per my spec, even though I'm not meeting any of their material needs."
-
Yes, literally include the wrapper code in every rust driver that needs it then when you push the wrapper on its own you can say “this code is currently duplicated 900 times because there isn’t a rust wrapper” not “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future” and no one will bat an eye!
That’s how you get things added to the kernel!
If it was about adding rust code to the kernel, which is what r4l universally says they’re doing, then they’d be taking that approach instead of farting around with the chicken and egg problem trying to get rust everything first.
That’s the whole point of the part of my comment that you dismissed out of hand. They’re nearly universally behaving in a way that it takes actual concerted brainpower to read as anything other than duplicitous.
And then when people say “hey, why don’t you not act like that” you get responses like “Linus said we could!” And “nontechnical nonsense” and “Dino devs”.
I don’t think that’s a broken foundation.
-
The build quality may not be that good but the technology and the designs are excellent. I say that as somebody that does not use macOS (well, not much).
As somebody that buys older hardware, I cannot wait to use Linux on Apple Silicon in a year or two. When I do, I will be immensely appreciative of all the effort that is going into it now. It will feel pretty open to me by that point.
Most importantly though, people put effort into the things that they want to. I am thankful that they have that freedom.
-
If people can use Linux on their Apple hardware after macOS stops supporting it, it keeps them from having to buy new Apple hardware a little longer.
-
Fair enough. Now that I think about it, maybe the developer experience in Apple products are not universally lauded.
For example, I remembered Pirate Software saying that he didn't develop for Mac because it was a pain, including having to pay Apple $100 yearly to distribute code without issues. Additionally, I remember my brother meeting a Spotify developer, and the Spotify developer said that Apple makes great hardware but lackluster software.
At the same time, it seems like Swift is not a hated language. The 2023 and 2024 Stack Overflow developer survey reports that, even though few people use Swift (~5% of developers), there's ~60% of admiration for the language.
-
Yes, literally include the wrapper code in every rust driver that needs it then when you push the wrapper on its own you can say “this code is currently duplicated 900 times because there isn’t a rust wrapper” not “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future” and no one will bat an eye!
That is what they are already doing and it's introducing unnecessary work! There's nothing about "hypothetical rust drivers", it's the case right now.
-
apart from the Mojo thing you it wasn't clear that this was only your experience, and none of which are accurate or useful observations
-
I’m not at a computer with the source on it, so if you get to it before me, how many rust drivers are there? How many that would use the rust dma wrapper?
I ask because last year there were relatively few.
People writing in c don’t have to use a wrapper because there’s no need to wrap c code for use by other c code.
More broadly there are times when duplicated c code has been condensed into a library or something and added to the kernel.
