16 ms·

Theodore Ts'o, the person you are implying is not an engineer, started working on Linux in 1991. Just look at the MAINTAINERS file of the Linux kernel source t

Theodore Ts'o, the person you are implying is not an engineer, started working on Linux in 1991. Just look at the MAINTAINERS file of the Linux kernel source tree. You'll find Theo maintaining several critical pieces, including leading the ext4 file system development, but really, take a look. Just to underline this. You are calling the credibility of a man whose code has most assuredly had a hand in storing your files, whether on your laptops/workstations or servers you've deployed to. A person who has been contributing for nearly *32 years*. How about we flip this around ? Here's a person who's been a large part of the success of the Linux kernel project for 32 years, and here's this presumptuous group coming in left field, telling him he's doing it all wrong and that it's time to get with the program or buzz off. People like him, the old guard, the core contributors, the main drivers of maintenance, should absolutely be heard. Linux is what it is today because of them. It's too precious to entrust to a bunch of well-meaning, but somewhat preachy and largely unproven developers. ----- So he comes off rude. But how come the people driving the Rust integration into the kernel are still ducking the hard discussion? It is almost as if everything is proceeding under the banner of "just an experiment" until, hopefully, a switch can be flipped and it becomes required, and everyone either has to maintain those bindings or see their patches rejected. Even better, then people who never wanted to pick up Rust, has to, or twiddle their thumbs in the background until some kindly soul decides to provide the updates to the bindings. Would you labor under such uncertainty and creeping adoption for a year or two, raise the points ad nauseam, get no concrete answers and NOT, at some point, lose your patience ?

SSLy 2y ago
> Would you labor under such uncertainty and creeping adoption for a year or two, raise the points ad nauseam, get no concrete answers and NOT, at some point, lose your patience ? Yep, that's what was happening to the RfL devs.
- pseudony 2y ago
  Nope. RfL was accepted as an experiment[0], with the understanding that it CAN be ejected again if the evaluation fails. Its mandate was as an opt-in functionality, primarily left for individual maintainers to decide on whether to use and leaf-nodes to use. It is very likely that this was the very best the RfL project could hope for at that time. Had they pushed for first-class citizenship, other contributors would, sensing the impending impact on their work, likely have revolted and the proposal would have been rejected. So here we are - this is what the RfL people of the time chose over rejection. No one is changing the game on the RfL devs - if you contribute, you are doing so knowing that this is the official state of affairs. The problem arises because while individual device drivers and subsystem maintainers indeed can opt-in, bindings provided by RfL impact contributors and maintainers who otherwise wish to avoid using Rust. Namely, if you write Rust bindings for my subsystem and my changes break those bindings, what then ? Am I barred from maintaining my subsystem because you decided to wrap the API for a language I don't know ? This is not the same as some C code consuming my subsystem breaks on a change, which I can easily fix. This means I now have to read those bindings, understand how they wrap my C API and how their expose API differs from mine (remember: idiomatic (fat) Rust bindings is the goal). I am now on the hook for bindings I had no say in providing or designing? If you don't understand how this can seem problematic, or how this can seem like maintainers are being forced into learning Rust and maintaining bindings which may well be a non-trivial layer in between the C API and consuming Rust code, then I don't know how to make the problem easier to grasp. Essentially, it's a very simple instance of "your freedom to swing your hands ends at the point where my face begins" - someone (the RfL binding writers) are swinging their fists about, hitting some maintainers on the nose, and being surprised that said maintainers are angry about that. [0] - https://docs.kernel.org/rust/ https://docs.kernel.org/rust/
  - still_grokking 2y ago
    There is a flaw in this reasoning. Nobody ever said that a subsystem maintainer needs to fix Rust bindings. As Ts'o correctly states, that's the problem of the bindings maintainers. But there is no problem at all. All that the Rust people want is to be informed about breaking changes. Also they said they're happy to get instructions on the semantics of the C APIs. They seem to want to collaborate. The C people just want them out, as it seems looking at this episode.
simjnd 2y ago
> Theodore Ts'o, the person you are implying is not an engineer Wow slow down there. Where did I imply he wasn't? I did imply he absolutely didn't act as one. When you're having an engineering discussion and you are being dismissive of actual arguments and reduce that to """religion""" you are not acting as one, you are acting like a fool. > Would you labor under such uncertainty and creeping adoption for a year or two, raise the points ad nauseam, get no concrete answers and NOT, at some point, lose your patience ? Whatever the circumstances, I'm not giving a pass to anyone to act like a complete dickhead. Whether that be to Theodore and other toxic kernel devs or to the toxic Rust community. If you lose patience just take a break, don't shit on other people. How is that a controversial take?

SSLy 2y ago

> Would you labor under such uncertainty and creeping adoption for a year or two, raise the points ad nauseam, get no concrete answers and NOT, at some point, lose your patience ? Yep, that's what was happening to the RfL devs.

pseudony 2y ago
Nope. RfL was accepted as an experiment[0], with the understanding that it CAN be ejected again if the evaluation fails. Its mandate was as an opt-in functionality, primarily left for individual maintainers to decide on whether to use and leaf-nodes to use. It is very likely that this was the very best the RfL project could hope for at that time. Had they pushed for first-class citizenship, other contributors would, sensing the impending impact on their work, likely have revolted and the proposal would have been rejected. So here we are - this is what the RfL people of the time chose over rejection. No one is changing the game on the RfL devs - if you contribute, you are doing so knowing that this is the official state of affairs. The problem arises because while individual device drivers and subsystem maintainers indeed can opt-in, bindings provided by RfL impact contributors and maintainers who otherwise wish to avoid using Rust. Namely, if you write Rust bindings for my subsystem and my changes break those bindings, what then ? Am I barred from maintaining my subsystem because you decided to wrap the API for a language I don't know ? This is not the same as some C code consuming my subsystem breaks on a change, which I can easily fix. This means I now have to read those bindings, understand how they wrap my C API and how their expose API differs from mine (remember: idiomatic (fat) Rust bindings is the goal). I am now on the hook for bindings I had no say in providing or designing? If you don't understand how this can seem problematic, or how this can seem like maintainers are being forced into learning Rust and maintaining bindings which may well be a non-trivial layer in between the C API and consuming Rust code, then I don't know how to make the problem easier to grasp. Essentially, it's a very simple instance of "your freedom to swing your hands ends at the point where my face begins" - someone (the RfL binding writers) are swinging their fists about, hitting some maintainers on the nose, and being surprised that said maintainers are angry about that. [0] - https://docs.kernel.org/rust/ https://docs.kernel.org/rust/
- still_grokking 2y ago
  There is a flaw in this reasoning. Nobody ever said that a subsystem maintainer needs to fix Rust bindings. As Ts'o correctly states, that's the problem of the bindings maintainers. But there is no problem at all. All that the Rust people want is to be informed about breaking changes. Also they said they're happy to get instructions on the semantics of the C APIs. They seem to want to collaborate. The C people just want them out, as it seems looking at this episode.

simjnd 2y ago

> Theodore Ts'o, the person you are implying is not an engineer Wow slow down there. Where did I imply he wasn't? I did imply he absolutely didn't act as one. When you're having an engineering discussion and you are being dismissive of actual arguments and reduce that to """religion""" you are not acting as one, you are acting like a fool. > Would you labor under such uncertainty and creeping adoption for a year or two, raise the points ad nauseam, get no concrete answers and NOT, at some point, lose your patience ? Whatever the circumstances, I'm not giving a pass to anyone to act like a complete dickhead. Whether that be to Theodore and other toxic kernel devs or to the toxic Rust community. If you lose patience just take a break, don't shit on other people. How is that a controversial take?