Resigning as Asahi Linux project lead
-
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.
-
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?
... of course there aren't many Rust drivers so far, since the project is still young, and it's evidently still facing hurdles and not really accepted by everyone. But if there's already a couple of Rust drivers and Rust has explicitly been accepted into the Kernel, we're already past your “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future”, so why argue such irrelevant points?
More broadly there are times when duplicated c code has been condensed into a library or something and added to the kernel.
And that's what has been blocked here...
-
Going to need you to cite your sources on that one. https://www.adelaidenow.com.au/sport/football/the-major-flaw-with-racial-charge-against-sam-kerr-that-shouldve-seen-the-case-abandoned/news-story/62e5fad93d835c9f432923375e5e833d
-
In the same way a swastika is no longer linked to an ancient peace symbol.
-
Can a maintainer really NACK any patch they dislike? I mean I get that Hellwig said he won't merge it. Fine. What if for example Kroah-Hartmann says "whatever, I like it" and merges it nonetheless in his tree?
-
Linus is pro-Rust. It is not clear from what you wrote that you realize that. He has merged plenty of Rust code. I personally expect him to merge the change that caused all this current drama (though I could clearly be wrong about that).
Right or wrong, this is how Linux kernel dev has always worked. How long did it take for real time to get in? How smoothly is the bcachefs merge going? Have you read any of the GPU driver chatter?
Honestly though, it is not just the kernel. How much different is the Wayland scene?
I am hardly defending Linux here by the way. I think the maintainers are blocking progress. I am merely pointing out that it is hardly new or unique.
Anyway, RedoxOS is quite progressive. They would probably love help from anybody that finds Linux kernel dev too stodgy.
-
I doubt Greg is pulling in Rust until it has been through the mainline. That said, Linus can merge anything he wants.
-
If we are going to be honest, let’s not be misleading.
Nobody is looking to replace C in the kernel. This is not a “rewrite it in Rust” initiative.
What the R4L folks want is to be able to write “new” code in Rust and for that code to calling into the C parts of the kernel in an idiomatic way (idiomatic for Rust). So they need to create Rust interfaces (which they, the R4L side, or doing). This whole controversy is over such an example.
At this point, we are talking about platform specific drivers.
Now, new kernel code is written all the time. Sometimes newer designs replace older code that did something similar. So yes, in the future, that new code may be written in Rust and replace older code that was written in C.
Core kernel code is not getting written in Rust for a while though I do not think. For one thing, Rust does not have broad enough architecture support (platforms). Perhaps if a Rust compiler as part of GCC reaches maturity, we could start to see Rust in the core.
That is not what is being talked about right now though. So, it is not a reasonable objection to current activity.
-
GNOME is not user-centric. GNOME is GNOME-centric.
-
It was an example. I don't have a fucking clue how all the maintainers are named.
The main question was: why can a maintainer NACK something not in their responsibility? Isn't it simply necessary to find one maintainer who is fine with it and pulls it in?
Or even asked differently: shouldn't you need to find someone who ACKs it rather than caring about who NACKs it?
