5 ms·

I think it's rather silly to have some subsystem maintainers do everything in their power to sabotage the improvement projects by subsystem and even high level

I think it's rather silly to have some subsystem maintainers do everything in their power to sabotage the improvement projects by subsystem and even high level maintainers in the kernel. It was a fine position to take back when introduction of Rust into the kernel was still very much a discussion point. However, the discussion is over, Rust has been accepted into the kernel. This entire struggle has been kernel developers sabotaging other kernel developers. This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything. That said, using social media to cause drama when a Linux maintainer is being an ass is just as stupid, if not worse. Both sides of the conflict are in the wrong here.

Longhanks 2y ago
> This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything. Well, this is your take, as you explicitly wrote "I walk away with the feeling". My take is: The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things. If too many people aren't happy with the way the linux kernel is developed, they are free to fork it and develop in the way that they see fit. Luckily, the kernel seems to be doing fine.
- tedivm 2y ago
  The kernel is doing fine today, but I don't think that's sustainable. The average age of the maintainers seems to be rising, and plenty of skilled people completely avoid kernel development explicitly because of the hostility and, frankly, assholish behavior that comes from the folks on these mailing lists. Eventually a lot of these people are going to age out, retire, or otherwise move on. I do think there will be a crisis moment at some point in the future.
  - ta8645 2y ago
    [flagged]
    - n144q 2y ago
      > At least, it was exactly that environment that gave us the amazing product that has changed the world. You need some extraordinary evidence to claim things like that. To stretch things a bit, it's like saying, while male dominated the field of engineering in the 60s (and still do), it was exactly that kind of environment that made it possible for humans to get to the moon. Can you actually prove it? Really? It's hard for me to imagine using git will slow down kernel development compared to sending patches in emails.
      - ta8645 2y ago
        > You need some extraordinary evidence to claim things like that. No. It's a legitimate possibility. Maybe it wont happen. But maybe it will. There's a reason that military training is meant to be hard though, and not filled with comfort and affordances for personal feelings. > To stretch things a bit, it's like saying, while male dominated the field of engineering in the 60s (and still do), it was exactly that kind of environment that made it possible for humans to get to the moon. Can you actually prove it? Really? No human has been back to the moon since that male dominated field sent them there. And when they added women, they couldn't produce a shuttle that could work without huge budget overruns, or reliably. And the only example of a real surge in a return to space, is run by an asshole dictator at Space X. > It's hard for me to imagine using git will slow down kernel development compared to sending patches in emails. No, that definitely worked out great. It was created by a gruff guy who was an asshole to everyone, and wrote the basics of Git by himself in a week.
  - caycep 2y ago
    how forkable is the whole thing? I mean, it is several decades of code but...
    - mort96 2y ago
- pyrale 2y ago
  > 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.
  - Longhanks 2y ago
    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.
    - steveklabnik 2y ago
      The person who quit was not the author of the patch, or a member of Rust for Linux.
      - alchemio 2y ago
        So they stirred a whole lot of drama for not much, potentially harming R4L.
        steveklabnik 2y ago
        I am not willing to pass a value judgement on his decision to do this, but I do agree that I don't think it ended up being helpful to R4L.
      - iczero 2y ago
        The person who quit wrote the Linux graphics driver for Apple M-series GPUs in Rust. edit: I may have gotten some things confused, please see below
        mort96 2y ago
        No. The person who quit upstream kernel work is Marcan, the head of the Asahi Linux project. The person who developed the kernel driver for M-series GPUs is Lina.
CopperWing 2y ago
The DMA subsystem maintainer has some reasons: at this time you can disable all rust drivers when building the Linux kernel but you cannot disable rust wrappers to C language APIs. So if you need to change for example the DMA APIs, you also need to fix the rust wrapper before submitting the C patches otherwise you cannot even build a C only kernel.
- paholg 2y ago
  I don't think that's true. I have seen R4L folks reiterate time and again that C changes are allowed to break Rust code, and they will be the ones to fix it.
- Zollerboy1 2y ago
  A C only kernel build without CONFIG_RUST will not build a single line of Rust code nor will it touch anything in the rust subdirectory. If you don’t want to deal with rust, you don’t have to at all.
  - WesolyKubeczek 2y ago
    It’s a little bit more nuanced than this. Your parent commenter is wrong, by the way. Suppose you want Rust, just not a single Rust driver using PCI. But CONFIG_PCI and CONFIG_RUST both selected will cause the PCI abstractions to get built anyway, even if not a single driver using them is selected. Then if the PCI subsystem introduces a change but the Rust counterpart fails to follow it fast enough, the build will break for the kernel as a whole. This was illustrated with an example in that email thread. I have some sad experience with polyglot projects. Unless you enjoy pain and drudgery, it’s an extremely unrewarding thing requiring very careful treading.
account42 2y ago
> However, the discussion is over It's not. Certainly not until Linus says it is. > Rust has been accepted into the kernel. As a limited experiment. This kind of drama may be an indication that the experiment has failed and should be rolled back.

Longhanks 2y ago

> This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything. Well, this is your take, as you explicitly wrote "I walk away with the feeling". My take is: The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things. If too many people aren't happy with the way the linux kernel is developed, they are free to fork it and develop in the way that they see fit. Luckily, the kernel seems to be doing fine.

tedivm 2y ago
The kernel is doing fine today, but I don't think that's sustainable. The average age of the maintainers seems to be rising, and plenty of skilled people completely avoid kernel development explicitly because of the hostility and, frankly, assholish behavior that comes from the folks on these mailing lists. Eventually a lot of these people are going to age out, retire, or otherwise move on. I do think there will be a crisis moment at some point in the future.
- ta8645 2y ago
  [flagged]
  - n144q 2y ago
    > At least, it was exactly that environment that gave us the amazing product that has changed the world. You need some extraordinary evidence to claim things like that. To stretch things a bit, it's like saying, while male dominated the field of engineering in the 60s (and still do), it was exactly that kind of environment that made it possible for humans to get to the moon. Can you actually prove it? Really? It's hard for me to imagine using git will slow down kernel development compared to sending patches in emails.
    - ta8645 2y ago
      > You need some extraordinary evidence to claim things like that. No. It's a legitimate possibility. Maybe it wont happen. But maybe it will. There's a reason that military training is meant to be hard though, and not filled with comfort and affordances for personal feelings. > To stretch things a bit, it's like saying, while male dominated the field of engineering in the 60s (and still do), it was exactly that kind of environment that made it possible for humans to get to the moon. Can you actually prove it? Really? No human has been back to the moon since that male dominated field sent them there. And when they added women, they couldn't produce a shuttle that could work without huge budget overruns, or reliably. And the only example of a real surge in a return to space, is run by an asshole dictator at Space X. > It's hard for me to imagine using git will slow down kernel development compared to sending patches in emails. No, that definitely worked out great. It was created by a gruff guy who was an asshole to everyone, and wrote the basics of Git by himself in a week.
- caycep 2y ago
  how forkable is the whole thing? I mean, it is several decades of code but...
  - mort96 2y ago
pyrale 2y ago
> 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.
- Longhanks 2y ago
  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.
  - steveklabnik 2y ago
    The person who quit was not the author of the patch, or a member of Rust for Linux.
    - alchemio 2y ago
      So they stirred a whole lot of drama for not much, potentially harming R4L.
      - steveklabnik 2y ago
        I am not willing to pass a value judgement on his decision to do this, but I do agree that I don't think it ended up being helpful to R4L.
    - iczero 2y ago
      The person who quit wrote the Linux graphics driver for Apple M-series GPUs in Rust. edit: I may have gotten some things confused, please see below
      - mort96 2y ago
        No. The person who quit upstream kernel work is Marcan, the head of the Asahi Linux project. The person who developed the kernel driver for M-series GPUs is Lina.

CopperWing 2y ago

The DMA subsystem maintainer has some reasons: at this time you can disable all rust drivers when building the Linux kernel but you cannot disable rust wrappers to C language APIs. So if you need to change for example the DMA APIs, you also need to fix the rust wrapper before submitting the C patches otherwise you cannot even build a C only kernel.

paholg 2y ago
I don't think that's true. I have seen R4L folks reiterate time and again that C changes are allowed to break Rust code, and they will be the ones to fix it.
Zollerboy1 2y ago
A C only kernel build without CONFIG_RUST will not build a single line of Rust code nor will it touch anything in the rust subdirectory. If you don’t want to deal with rust, you don’t have to at all.
- WesolyKubeczek 2y ago
  It’s a little bit more nuanced than this. Your parent commenter is wrong, by the way. Suppose you want Rust, just not a single Rust driver using PCI. But CONFIG_PCI and CONFIG_RUST both selected will cause the PCI abstractions to get built anyway, even if not a single driver using them is selected. Then if the PCI subsystem introduces a change but the Rust counterpart fails to follow it fast enough, the build will break for the kernel as a whole. This was illustrated with an example in that email thread. I have some sad experience with polyglot projects. Unless you enjoy pain and drudgery, it’s an extremely unrewarding thing requiring very careful treading.

account42 2y ago

> However, the discussion is over It's not. Certainly not until Linus says it is. > Rust has been accepted into the kernel. As a limited experiment. This kind of drama may be an indication that the experiment has failed and should be rolled back.