Linus responds to Hellwig - "the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL... if you as a maintainer feel that you control who or what can use your code, YOU ARE WRONG."
-
How many months should he have waited for an authoritative response?
Well, Marcan should wait as long as feels right to him. As I said previously, I'm pretty sure he was already pissed off about previous R4L issues and he didn't quit because of this alone. I want to be clear that I'm commenting solely on the expectation of a swifter response from leadership in the original email thread and not on Marcan's decision to step down, which I can't be the judge of.
So, I expect people in places of power to take their time when they respond publicly to issues like this, for various reasons. Eg:
- they might try to resolve things in private first (seems to be the case)
- they might want to discuss with their peers to double check their decision making and to take collective action, this is especially true if the CoC committee gets involved
- they might want to chime in when people have calmed down and they expect to be able to have meaningful conversations with them
At the very least, I would have waited to see what happens with the patches if I were in his position. The review process, which kept going in the meantime, essentially sets a timer for a decision to be made. In the end, Hellwig's objections would either be acknowledged as blocking or they would be ignored. In any case there would have been a clear stance from the project's leadership. It makes sense to me to wait for this inevitable outcome before making a committal decision such as stepping down.
I want to be clear that I'm commenting solely on the expectation of a swifter response from leadership in the original email thread and not on Marcan's decision to step down, which I can't be the judge of.
One was a direct result of the other. You can't separate them.
they might try to resolve things in private first (seems to be the case)
Neither of them have the authority to resolve it in private and it was clear by the third message that there would be no resolution between them.
they might want to chime in when people have calmed down
They didn't calm down, it was plain to see that things were only becoming more and more heated until the conversation reached a breaking point.
Marcan asked Linus to come in and make an authoritative statement and end the bickering and he did not. Hector interpreted that as Linus being apathetic (which is a rational position given the time that had passed). I'm not going to try and judge Linus, I don't know what was going on in his life at the time, but it was, as Hector stated, a failure of leadership regardless.
-
I can relate. I can emphasize with someone who's learned every nuance of a language, and after 30-40 years suddenly these kids come in with their strange hieroglyphics slowly replacing everything you've worked on.
Except that's literally the reality with computers. Everything evolves and things go obsolete. I'm sure the COBOL and Fortran programmers were pissed when the kids started using C too.
-
God damn if these Rust glazers are so offended by this, just go work on Redox
You mean the operating system with a cuckold license? Nothx
-
I'd venture to guess this isn't the first time Linus has had to deal with devs who have ideological disagreements and one quits. It's not also his job to keep that from happening. What he said is true, there's a process they have for maintaining Linux, and it doesn't involve flame wars on social media.....it involves flame wars over email
.But seriously, if a devs are going to get upset at each other and rage quit, it's not Linus' job to play mediator.
it used to be hard to imagining anyone wanting to work w someone as toxic as linus; but i've learned after my first 2 tenures at faang that developers are no different than kardashian worshippers.
devs getting angry at each other and then rage quiting is just a sympton of a tribalistically shared belief of intellectual superiority among developers like when kardashian sisters have beef with each other and their followers attack each other for it.
-
cross-posted from: https://lemmy.world/post/25857381
Hellwig is the maintainer of the DMA subsystem. Hellwig previously blocked rust bindings for DMA code, which in part resulted in Hector Martin from stepping down as a kernel maintainer and eventually Asahi Linux as a whole.
Are we hating on Linus here or agreeing with him? I'm so out of the loop.
-
What does glazer mean in this context? (English is my fourth language)
(slang) Someone who glazes (to compliment or praise someone excessively in a cringeworthy way); an asskisser or sycophant.
-
Are we hating on Linus here or agreeing with him? I'm so out of the loop.
Agreeing
-
New people don't realize that Linux is really a soap opera with a small software project attached.
That's not to say any other OS effort is not also a soap opera. I bet Microsoft has its fair share of drama, too; it's just that no one sees it because the development effort is proprietary.
-
Rust is great, but you are not thinking from a long-term project perspective. Rust is safer, but Linux needs to be maintainable or it dies.
Based on what you're saying, the only way its going to reasonably be converted to Rust is if someone forks Linux and matches all the changes in C as they happen but converts it all to Rust. Once its all converted and maintainability has been proven, a merge request would need to be made.
That is not how it will happen, if it ever fully converts at all.
Rust will first be added in a way that allows it to run on top of existing C code. That is what we are seeing here with Rust being used to write drivers.
As sub-systems get overhauled and replaced, sometimes Rust will be chosen as the language to do that. In these cases, a sub-system or module will be written in Rust and both C code and Rust code will use it (call into it).
The above is how the Linux kernel may migrate to Rust (or mostly Rust) over time.
As devs get more comfortable, there may be some areas of the kernel that mix C and Rust. This is likely to be less common and is probably the most difficult to maintain.
Nobody wants to rewrite working, solid kernel modules in Rust though. So, it seems very likely that the kernel will remain mostly C for a long, long time. There are no doubt a few areas though where Rust will really shine
No need for a fork or a rewrite.
-
Yea but if someone uses those bindings then you can't just not support it.
By the time this code gets into a large scale production system it will be 2029. That is when the bugs will come in if someone leveraged the Rust bindings.
You can ask the big company users at that time to contribute their fixes upstream, but if they get resistance because they have relatively junior Rust devs trying to push up changes that only a handful of maintainers understand, the company will just stop upstreaming their changes.
The primary concern that a major open source project like this will have is that the major contributors will decide that interacting with it is more trouble than it is worth. That is how open source projects move to being passion projects and then die when the passion dies.
Instead of thinking about the bindings as part of the sub-system, think of them as part of the driver. That is what Linus is saying here.
The Rust code will be maintained, by those writing Rust code. By those writing the drivers. These are not junior people.
Except the bindings are written so that they can be used not just by this driver but others as well.
If companies write crappy code that calls into these bindings, that is nothing new. They do that today with C. Like C, the code will not be accepted if crappy and / or there is nobody credible to maintain it.
None of this is a good argument for not letting these bindings in.
-
Yea and if the Rust developers don't show up to the show? Rust is a baby and it has done so little on its own. This isn't a neat little side project, this is code that a major vendor will want to take up and will demand be maintained. There are implications on a global scale.
This is such a red herring.
The Rust side we are talking about here have been involved for years. They have written amazing code (eg. Apple Silicon GPU drivers). There is an official Fedora spin based on their work.
What makes you think any of that is going to go away?
In fact, this whole incident shows their depth as the project lead quit Linux in disgust and was quickly replaced with another talented, dedicated, and proven developer.
There is a lot more drive-by C code you should worry about.
-
A lot of people commenting on this seem to have gaps in their knowledge of what happened. I highly recommend reading the linked email, as it is both short and has valuable context.
A lot of people commenting on this seem to have gaps in their knowledge of what happened
We're in a Linus-email-
-thread, so that kind of goes without saying doesn't it? 
-
Yah took him long enough and should have never got to this point. Now we have lost a contributer.
We've lost two this week
-
Are we hating on Linus here or agreeing with him? I'm so out of the loop.
Excuse me sir why would You ever disagree with our king linus
-
I really appreciated him saying 'I don't want yes men, I need people to call me on my bullshit, but I'm calling you out on yours'.
I read through the next few replies, and it seems like the anti-rust maintainer just has an axe to grind and can't stand people working in a language they don't understand.
He understands Rust and claims to like it. He simply disagrees with the decision to have a mixed language kernel and is trying to unilaterally stop it from happening.
-
How many months should he have waited for an authoritative response?
Well, Marcan should wait as long as feels right to him. As I said previously, I'm pretty sure he was already pissed off about previous R4L issues and he didn't quit because of this alone. I want to be clear that I'm commenting solely on the expectation of a swifter response from leadership in the original email thread and not on Marcan's decision to step down, which I can't be the judge of.
So, I expect people in places of power to take their time when they respond publicly to issues like this, for various reasons. Eg:
- they might try to resolve things in private first (seems to be the case)
- they might want to discuss with their peers to double check their decision making and to take collective action, this is especially true if the CoC committee gets involved
- they might want to chime in when people have calmed down and they expect to be able to have meaningful conversations with them
At the very least, I would have waited to see what happens with the patches if I were in his position. The review process, which kept going in the meantime, essentially sets a timer for a decision to be made. In the end, Hellwig's objections would either be acknowledged as blocking or they would be ignored. In any case there would have been a clear stance from the project's leadership. It makes sense to me to wait for this inevitable outcome before making a committal decision such as stepping down.
Here's the thing though, is Marcan got called out (rightfully) for his shit by Linus, but Linus could have called out Hellwig in the same email. The lack of that, to my reading, felt like implicit support of Hellwig's position to me, and I can see why Marcan would have felt the same way.
In saying that, it would also be fair for Linus to not "give in to the pressure" of Marcan's actions on social media and basically given him what he wanted.
-
It appears so now, yes, but when the drama initially came out it sounded like they were asking for a tiny amount of rust in the kernel to make it work, or if not rust, changing the C to tailor it specifically to the rust. Which I think is a reasonable thing to be concerned about from a maintainability perspective long-term, especially if the rust developers decide to leave randomly (Hector's abrupt quitting over this very issue is a prime example).
A bunch of people were trying to make that argument to explain Hellwig's disagreement, but it was never the case. His argument amounted to "you can't make create unified code to reference mine, you must have each driver maintain its own independent calls to my code".
-
You mean the operating system with a cuckold license? Nothx
I'm personally not a fan of permissible licenses, but you don't need to bring your fetishes up in every conversation.
-
Are we hating on Linus here or agreeing with him? I'm so out of the loop.
He has very solidly worded points and correct analysis of the problem. 100% agree with what was written by Linus.
-
Rust is great, but you are not thinking from a long-term project perspective. Rust is safer, but Linux needs to be maintainable or it dies.
Based on what you're saying, the only way its going to reasonably be converted to Rust is if someone forks Linux and matches all the changes in C as they happen but converts it all to Rust. Once its all converted and maintainability has been proven, a merge request would need to be made.
I can't fathom how do you mean Rust is not maintainable. If anything for a new programmer C code is much more mind boggling than Rust.
Writing in Rust might make it much more maintainable.
