171–180 of 1001 posts
Earlier quoted context omitted.
Up until the point that he tried to leverage social media to get his way in a kernel maintainer dispute? That's just fundamentally not acceptable. Linus was right to reprimand him for the suggestion.
I don't think there's "the point" when it was pretty much modus operandi for years.
Earlier quoted context omitted.
> Starting to think it's not just a coincidence. Is your theory that rust makes people dramatic? Or that dramatic people like rust? What other options are there, if not coincidence?
>Is your theory that rust makes people dramatic? Or that dramatic people like rust? What other options are there, if not coincidence? There is a cognitive bias called "loyalty to the brand", in which it says that people prefer the things they have because they rationalize their choices to protect their sense of ego. When they invest time (or a lot of money) to something, they create an emotional connection, especiall…
Earlier quoted context omitted.
> The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things. Both sides of the argument are kernel developers here, though.
Well, one side just quit. And that particular side was told by Linus Torvalds himself that his way of Social Media brigading is inappropriate for kernel development, and that the current process works. I choose to believe Linus. His work on and guidance of the kernel used to and still does work pretty great.
Earlier quoted context omitted.
No, the point is nonsense. Rust is a consumer of the APIs just like every other driver / subsystem is. Any change to the C APIs would likely require collaboration with those other maintainers no different than Rust. And CH would be immediately shut down if he tried to roadblock some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".
I think you are using inflammatory language by calling the point nonsense. As an outside observer, literally no skin in this game, I can see his point. If his C code changes breaks other C code then he is at an advantage compared to if his C code breaks a Rust binding or Rust drivers. The degree to which this adds to his burden of maintenance is up to him to decide.
Earlier quoted context omitted.
is this just weird religious adherence to the belief that a multi-language codebase will be harder to maintain? what's the rationale, exactly?
I'm just parsing the thread but it seems that changes to the C api can break the Rust bindings. This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up. For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believ…
Linus already did that. This is the state of things today. C code is allowed to break the Rust, and it's the Rust for Linux people's responsibility to get it working again, not the C folks.
Earlier quoted context omitted.
Maintainers come and go, languages come and go. C will never go away and everyone working on kernels knows C, so there's a certain labour pool and skillset that will always be available that doesn't necessarily apply to Rust. That's even setting aside any technical issues, like bugs creeping up in the language interoperability layer, which obviously doesn't really happen if you're only using one compiler.
I think both arguments have credibility. The R4L says they will make sure the Rust code is fixed when the C code is, and that's admirable, but the concern it means a developer now has to wait for that, holding up their work for release/submission. The bus factor is now on the R4L team. Meanwhile, everyone involved in development for Linux already knows C.
They do not have to wait.
From what I can piece together it seems Hector is upset about someone ("Hellwig"?) doing something that was seen as intentionally sabotaging the rust efforts. Hector posted about it on socials. Linus came down on Hector for leveraging socials to fight kernel disputes. Hector quits. No doubt that is a flawed summary so feel free to correct
Hector wasn't the developer of this patch. However, he is a user of it. He has had some rough interactions over the last few years. And so seeing this happen (even though it's happening to someone else) is a "the straw that breaks the camel's back" kind of deal.
Earlier quoted context omitted.
> Maybe don't make comments like that on social media if you want to criticize people for leaning on social media in kernel disputes. This seems like a tu quoque fallacy. The feedback is either applicable or not, regardless of who said it. They're absolutely correct that Being toxic on the right side of an argument is still toxic . Even if there is hypocrisy (whether judged by you personally or someone else), it woul…
Of course it doesn't invalidate the point, but it's hard to blame being so exasperated by the incredible hypocrisy that you ragequit at that point.
Earlier quoted context omitted.
Yikes, re that fedi thread.
This one bit looks exactly right, though: > As for how to move forward, (...) Either Linus takes the pull, and whatever Christoph says is irrelevant, or he doesn't, and R4L dies. Everything else is a waste of everyone's time and energy. It does look like maintainers should have a "disagree and commit" mentality at some point, whatever decision they end up making. I thought Rust in Linux was evaluated, discussed and a…
It is not some million dollar RSUs getting vested by year end either way. A lot of them working for the love of craft and prestige. If they can just rollover on a technical disagreement then corporate office job is more suitable than open source OS kernel.
Earlier quoted context omitted.
I'm just parsing the thread but it seems that changes to the C api can break the Rust bindings. This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up. For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believ…
> Linus could make some of this go away by committing to let the Rust builds break. Linus already did that. This is the state of things today. C code is allowed to break the Rust, and it's the Rust for Linux people's responsibility to get it working again, not the C folks.
To be fair, I think another valid solution to this problem is just to bite the bullet and tell the grumpy C developers to deal with it. At some point the fallout from an exodus of grey beard Linux maintainers will actually be less than fighting this battle. As many point out, they are going to exit the project one way or another eventually.