Resigning as Asahi Linux project lead
-
And, again, prove him wrong, maintain a tree that shows it's workable, and with minimum maintainability concerns. If there truly are minimal maintenance concerns, a separate tree would be quite simple to maintain!
-
Okay so if the point of the rust for Linux project isn’t to replace c code with rust then what is the point?
I understand the project maintains a coy line regarding that question but let’s be serious for a second and really consider why r4l is happening.
-
For the last time, the decision to include Rust has already been made. The "prove him wrong by developing out-of-tree" has already happened.
-
Okay so if the point of the rust for Linux project isn’t to replace c code with rust then what is the point?
The purpose is to allow new modules to be written in Rust, not to replace C code. Why are you acting like you don't know this already?
-
Apparently, it hasn't happened. Because nobody else beside R4L is helping it along.
Sorry, but ya'll just have more work to do, is all. Do it, or don't, I don't care. I honestly don't care one iota if Rust ever gets in the kernel, or not. What I do care about is that the Linux kernel remains a stable project.
Take the advice, or don't. Its on you.
-
There's no advice to take for working with maintainers who'll abuse their power to stop a project they don't like.
-
So why can’t rust modules use the c bindings?
What im building towards is: if r4l isn’t about replacing c code then it doesn’t need to be in the kernel. If its about replacing c code (which it absolutely should be, that’s the whole point of memory safe languages like rust) then r4l people need to have a clear process and understanding of how they expect to accomplish that goal and be open about it.
-
And these social media outbursts aren't accomplishing what they think they're accomplishing.
I'm extremely technical, but not actively into Linux. These posts have driven me away from Linux in an extremely hard way - anyone with opinions like the Kernel team simply don't deserve support, and Linus is clearly past his prime and making bad decisions. This has shown me that Linux is going to (likely already has) slowly stop improving due to its explicitly anti-progress leadership. Until a fork with good leaders manages to take a real market share, the OS will stagnate.
I'm sure this is a minority opinion, but to claim that the social media blitz hasn't had its intended effect is objectively false. Fuck the kernel team.
-
So why can’t rust modules use the c bindings?
They can, if wrappers are written. These wrappers were blocked by a maintainer.
What im building towards is: if r4l isn’t about replacing c code then it doesn’t need to be in the kernel.
Why? It needs to be in the kernel for new code to get written in Rust. Why can it only be in the kernel if the goal is to replace existing code?
r4l people need to have a clear process and understanding of how they expect to accomplish that goal and be open about it.
They do!
-
Ok, so then just toss in the towel, and make your own kernel, with hookers, blow, and Rust. Sorry.
-
Or I can ask Linus to do his job properly and lead on this issue, whether it's for or against R4L.
You seem to be under the impression that I'm somehow involved with R4L or Rust, or that I even use Rust. None of these are true. I'm just seeing an example of bad project management, and people like you that keep lying to justify the maintainers decision.
-
I've been using fractional scaling on my laptop with GNOME since I installed it about four years ago. It's a bit heavy on battery usage but it's worked as expected for all this time.
-
congratulations
none of that is true
-
more so. windows is horrible and macos is distinctly average, it's only selling point is their service/device integration which is the best
-
This is where you lose me. I’m not a good programmer or a very smart person, 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.
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.
There’s a fundamental disconnect here. When people speaking about r4l including official statements from the r4l project say “our plan to add rust, a language intended to address shortcomings of c, to the kernel is only for new code, not a rewrite of existing systems.” I don’t believe them.
Not only do supporters of and contributors to the r4l project make offhanded remarks about how different things would be better if they were written in rust but if they truly believed in the language’s superiority to c then they would be trying to replace existing c code with rust.
Then the whole rust using and supporting world melts down when people oppose adding it into an existing huge c codebase.
Then they all complain that they’re being discriminated against for “nontechnical reasons”, which is becoming a great dog whistle for if you should just disregard someone’s opinion on rust outright.
Perhaps that explains some of why I don’t believe rust people when they flip out over not being allowed to do the thing that no one else is allowed to do either.
-
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?