5 ms·

I think the response from Dr Greg to Linus, https://lore.kernel.org/rust-for-linux/20250207121638.GA7356@wind.enjellic.com/ https://lore.kernel.org/rust-for-lin

I think the response from Dr Greg to Linus, https://lore.kernel.org/rust-for-linux/20250207121638.GA7356@wind.enjellic.com/ https://lore.kernel.org/rust-for-linux/20250207121638.GA7356... adds some interesting insights. There seems to be some issue with unaccountable maintainers, and that’s a problem for innovation. If you can’t even get to the point of “technical debate” (we aren’t interested, sorry), then what hope innovation? These are “people problems”, and there are no easy or good answers, but it doesn’t mean we should through our hands up and consider things “unfixable” either.

mmooss 2y ago
People should read it: "... I come at this from the perspective of having worked on Linux since around December of 1991. I first met you and Tove in 1995 at the Free Software Conference at MIT that Stallman sponsored. ... Probably the last technical contribution of my career is leading an initiative to provide the Linux community a generic security modeling architecture. Not to supplant or replace anything currently being done, but to provide a flexible alternative to the development of alternate and/or customized workload models, particularly in this era of machine learning and modeling. Four patch series over two years, as of yesterday, not a single line of code ever reviewed. ... We were meticulous in our submissions to avoid wasting maintainers time. We even waited two months without hearing a word before we sent an inquiry as to the status of one of the submissions. We were told, rather curtly, that anything we sent would likely be ignored if we ever inquired about them. We tried to engage, perhaps to excess, in technical discussions attempting to explain why and how we chose to implement what we were proposing. ... There were never any relevant technical exchanges. The discussion consisted of, we have decided to do things a certain way, no discussion, if you don't like that you should really consider doing something other than submitting to upstream Linux."
- bonzini 2y ago
  I don't know, dropping 17000 lines of code is probably not the best way to solicit technical discussions (https://lore.kernel.org/lkml/20240826103728.3378-1-greg@enjellic.com/ https://lore.kernel.org/lkml/20240826103728.3378-1-greg@enje... is the patch set in question)
  - mmooss 2y ago
    That's version 4. Here's version 2, which looks like the first patch submission: https://lore.kernel.org/linux-security-module/20230204050954.11583-1-greg@enjellic.com/T/ https://lore.kernel.org/linux-security-module/20230204050954...
    - bonzini 2y ago
      7000 is not a lot better.
      - vaidhy 2y ago
        Not everything can be broken down into 5 line patches. Some of the bigger features need bigger code. You can look at the impact radius and see if the patch is behind a feature flag to make a decision. In this case, it seems like it is elective and does not have any changes beyond what is self-contained.
        macNchz 2y ago
        I don’t follow the Linux kernel development process closely, but on most projects—open source or proprietary—that I’ve been involved in, dropping a big diff without having proposed or discussed anything about it beforehand would have been fairly unwelcome, even if it’s something that would be infeasible to break down smaller. I’d also argue that even quite substantial changes can be made with incremental patches, if you choose to do so.
        raverbashing 2y ago
        There had probably been a lot of discussion in the background The "every change can be a small patch, can be split in such" is part now of the Linux folklore IMHO. As in, a belief that people kinda heard about but nobody has concrete proof Also do you know what would make it much easier to review long changes? Not using email patches But I'm glad there's an good answer on "how to do it" in the thread https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home.goodmis.org/ https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home...
- mmooss 2y ago
  A maintiner's perpsecitive on the above: https://lore.kernel.org/rust-for-linux/20250208204416.GL1130956@mit.edu/ https://lore.kernel.org/rust-for-linux/20250208204416.GL1130...
  - jorvi 2y ago
    Important to note that Ted is extremely anti-Rust and literally shouted down someone irl that was doing a presentation on Rust in the Linux kernel.
HereIGoAgain 2y ago
The short of his rant is that he wants a "Code Of Standards for maintainers" in addition to a CoC, in order to witch hunt people he feels "gets in the way." Yikes, this is EXACTLY what Linus was talking about except an order of magnitude worse!
- lll-o-lll 2y ago
  > The short of his rant… This does not read as a rant at all to me. Rather it seeks to highlight a problem using an example from his own work and proposes a possible solution (with a previous caveat of “I don’t know how to fix this”). > "Code Of Standards for maintainers" in addition to a CoC He wants maintainers to behave in some pre-determined understandable fashion. He wants some accountability, and that seems reasonable to me. This is not a “maintainers must do what I want”, this is “let’s set basic expectations” and ensure people follow them. Whatever those should be. > in order to witch hunt people he feels "gets in the way." B does not follow A. You are simply straw-manning here, so I have nothing to say to it other than it’s a fallacious point.
  - robertlagrant 2y ago
    > This is not a “maintainers must do what I want”, this is “let’s set basic expectations” and ensure people follow them. Whatever those should be. But presumably it's not whatever they should be. It's what he wants them to be. And what should happen if they're not followed?
    - rincebrain 2y ago
      His complaint is, in essence, that people will block technical proposals for nontechnical reasons, and that attempts to resolve this result in people complaining that you're talking about nontechnical things at all. Few people like dealing with interpersonal conflict. They want to think that technical meritocracy wins the arguments. But in that discussion, a maintainer said "I am going to try to sabotage this because I hate it.", and there's no technical argument to resolve that. And there's not really any route other than escalation to some kind of authority if there's not a common negotiation baseline. "You can't reason someone out of a position they weren't reasoned into."
hitekker 2y ago
Looks like Dr Greg (not Greg KH) is just piling his own personal grievance on top of the drama. Saying "Jim are you listening?" makes me wonder who he's sniping at. Speaking as an actual People Manager, his ideas sound pretty shallow.
- the-smug-one 2y ago
  I'm not a "People Manager" -- what is shallow about the ideas?
- bonzini 2y ago
  Maybe Jim Zemlin, who is the executive director of the Linux Foundation and has nothing to do with Linux.
  - CRConrad 2y ago
    > Jim Zemlin, who is the executive director of the Linux Foundation and has nothing to do with Linux. That sounds... Not good. Seems like like this is exactly what's wrong with... Well, not just this, but much of the "FOSS" world. (Maybe about since "Free Software" became "Open Source"?)
trod1234 2y ago
There are easy and good answers, just none that every single one would agree with, and that is the problem. The current management model is based on consensus in some parts, and a dictatorship in others. Its not clear which parts are which because of sprawl, and non-responsiveness. This is a core communication people issue. The problems arise because in consensus models, people are expected to adopt archetypical roles based somewhat on preference, but mostly on the needs of the group, towards productivity. If no one else is doing that type of role, someone will be forced into doing it, and will adopt characteristics of that role, regardless of their personal opinions about it. When they get punished for fulfilling the role, you lose people. > doesn't mean we should throw our hands up and consider things "unfixable" either. The given structure is unfixable, because it sets the stage for a trauma loop where actions can't take place without people who are expected to fulfill a role to meet consensus, but in doing so they get punished for volunteering. There is no way around this structure so long as you use a consensus model in whole or part, in dysfunctional groups the people involved either fail to communicate or worse there are members that impose coercive cost by assuming the unproductive roles so no action happens while resources are wasted. This really is basic stuff covered in your college level intro to communications coursework. For those wanting to know more about this, you can read more about the roles at the link below. https://pressbooks.pub/smallgroup/chapter/roles/ https://pressbooks.pub/smallgroup/chapter/roles/
throwaway2037 2y ago
This part is wild. Some people get in so deep they cannot see the forest from the trees. > there is the tangible risk of stifling innovation and Linux is the only place that innovation can occur in the operating system space. One thing I know: HN loves drama, and this stuff reads like first class drama.
- markhahn 2y ago
  The proponents think the value of their "innovation" is obvious, but it is not. Is it innovative? Is it valuable? Is it worth the cost? Who is it valuable to? I don't see why the kernel team should be obligated to react in any particular way to a random submission.
washadjeffmad 2y ago
I think "Code of Civility" is what Dr. G was describing. Conduct presupposes civility, but acceptable online discourse has changed amongst new internet natives raised in the era of moral totalitarianism, aggression as a service, and popular outrage incubators.
tura11 2y ago
[dead]
tura11 2y ago
[dead]

mmooss 2y ago

People should read it: "... I come at this from the perspective of having worked on Linux since around December of 1991. I first met you and Tove in 1995 at the Free Software Conference at MIT that Stallman sponsored. ... Probably the last technical contribution of my career is leading an initiative to provide the Linux community a generic security modeling architecture. Not to supplant or replace anything currently being done, but to provide a flexible alternative to the development of alternate and/or customized workload models, particularly in this era of machine learning and modeling. Four patch series over two years, as of yesterday, not a single line of code ever reviewed. ... We were meticulous in our submissions to avoid wasting maintainers time. We even waited two months without hearing a word before we sent an inquiry as to the status of one of the submissions. We were told, rather curtly, that anything we sent would likely be ignored if we ever inquired about them. We tried to engage, perhaps to excess, in technical discussions attempting to explain why and how we chose to implement what we were proposing. ... There were never any relevant technical exchanges. The discussion consisted of, we have decided to do things a certain way, no discussion, if you don't like that you should really consider doing something other than submitting to upstream Linux."

bonzini 2y ago
I don't know, dropping 17000 lines of code is probably not the best way to solicit technical discussions (https://lore.kernel.org/lkml/20240826103728.3378-1-greg@enjellic.com/ https://lore.kernel.org/lkml/20240826103728.3378-1-greg@enje... is the patch set in question)
- mmooss 2y ago
  That's version 4. Here's version 2, which looks like the first patch submission: https://lore.kernel.org/linux-security-module/20230204050954.11583-1-greg@enjellic.com/T/ https://lore.kernel.org/linux-security-module/20230204050954...
  - bonzini 2y ago
    7000 is not a lot better.
    - vaidhy 2y ago
      Not everything can be broken down into 5 line patches. Some of the bigger features need bigger code. You can look at the impact radius and see if the patch is behind a feature flag to make a decision. In this case, it seems like it is elective and does not have any changes beyond what is self-contained.
      - macNchz 2y ago
        I don’t follow the Linux kernel development process closely, but on most projects—open source or proprietary—that I’ve been involved in, dropping a big diff without having proposed or discussed anything about it beforehand would have been fairly unwelcome, even if it’s something that would be infeasible to break down smaller. I’d also argue that even quite substantial changes can be made with incremental patches, if you choose to do so.
        raverbashing 2y ago
        There had probably been a lot of discussion in the background The "every change can be a small patch, can be split in such" is part now of the Linux folklore IMHO. As in, a belief that people kinda heard about but nobody has concrete proof Also do you know what would make it much easier to review long changes? Not using email patches But I'm glad there's an good answer on "how to do it" in the thread https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home.goodmis.org/ https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home...
mmooss 2y ago
A maintiner's perpsecitive on the above: https://lore.kernel.org/rust-for-linux/20250208204416.GL1130956@mit.edu/ https://lore.kernel.org/rust-for-linux/20250208204416.GL1130...
- jorvi 2y ago
  Important to note that Ted is extremely anti-Rust and literally shouted down someone irl that was doing a presentation on Rust in the Linux kernel.

HereIGoAgain 2y ago

The short of his rant is that he wants a "Code Of Standards for maintainers" in addition to a CoC, in order to witch hunt people he feels "gets in the way." Yikes, this is EXACTLY what Linus was talking about except an order of magnitude worse!

lll-o-lll 2y ago
> The short of his rant… This does not read as a rant at all to me. Rather it seeks to highlight a problem using an example from his own work and proposes a possible solution (with a previous caveat of “I don’t know how to fix this”). > "Code Of Standards for maintainers" in addition to a CoC He wants maintainers to behave in some pre-determined understandable fashion. He wants some accountability, and that seems reasonable to me. This is not a “maintainers must do what I want”, this is “let’s set basic expectations” and ensure people follow them. Whatever those should be. > in order to witch hunt people he feels "gets in the way." B does not follow A. You are simply straw-manning here, so I have nothing to say to it other than it’s a fallacious point.
- robertlagrant 2y ago
  > This is not a “maintainers must do what I want”, this is “let’s set basic expectations” and ensure people follow them. Whatever those should be. But presumably it's not whatever they should be. It's what he wants them to be. And what should happen if they're not followed?
  - rincebrain 2y ago
    His complaint is, in essence, that people will block technical proposals for nontechnical reasons, and that attempts to resolve this result in people complaining that you're talking about nontechnical things at all. Few people like dealing with interpersonal conflict. They want to think that technical meritocracy wins the arguments. But in that discussion, a maintainer said "I am going to try to sabotage this because I hate it.", and there's no technical argument to resolve that. And there's not really any route other than escalation to some kind of authority if there's not a common negotiation baseline. "You can't reason someone out of a position they weren't reasoned into."

hitekker 2y ago

Looks like Dr Greg (not Greg KH) is just piling his own personal grievance on top of the drama. Saying "Jim are you listening?" makes me wonder who he's sniping at. Speaking as an actual People Manager, his ideas sound pretty shallow.

the-smug-one 2y ago
I'm not a "People Manager" -- what is shallow about the ideas?
bonzini 2y ago
Maybe Jim Zemlin, who is the executive director of the Linux Foundation and has nothing to do with Linux.
- CRConrad 2y ago
  > Jim Zemlin, who is the executive director of the Linux Foundation and has nothing to do with Linux. That sounds... Not good. Seems like like this is exactly what's wrong with... Well, not just this, but much of the "FOSS" world. (Maybe about since "Free Software" became "Open Source"?)

trod1234 2y ago

There are easy and good answers, just none that every single one would agree with, and that is the problem. The current management model is based on consensus in some parts, and a dictatorship in others. Its not clear which parts are which because of sprawl, and non-responsiveness. This is a core communication people issue. The problems arise because in consensus models, people are expected to adopt archetypical roles based somewhat on preference, but mostly on the needs of the group, towards productivity. If no one else is doing that type of role, someone will be forced into doing it, and will adopt characteristics of that role, regardless of their personal opinions about it. When they get punished for fulfilling the role, you lose people. > doesn't mean we should throw our hands up and consider things "unfixable" either. The given structure is unfixable, because it sets the stage for a trauma loop where actions can't take place without people who are expected to fulfill a role to meet consensus, but in doing so they get punished for volunteering. There is no way around this structure so long as you use a consensus model in whole or part, in dysfunctional groups the people involved either fail to communicate or worse there are members that impose coercive cost by assuming the unproductive roles so no action happens while resources are wasted. This really is basic stuff covered in your college level intro to communications coursework. For those wanting to know more about this, you can read more about the roles at the link below. https://pressbooks.pub/smallgroup/chapter/roles/ https://pressbooks.pub/smallgroup/chapter/roles/

throwaway2037 2y ago

This part is wild. Some people get in so deep they cannot see the forest from the trees. > there is the tangible risk of stifling innovation and Linux is the only place that innovation can occur in the operating system space. One thing I know: HN loves drama, and this stuff reads like first class drama.

markhahn 2y ago
The proponents think the value of their "innovation" is obvious, but it is not. Is it innovative? Is it valuable? Is it worth the cost? Who is it valuable to? I don't see why the kernel team should be obligated to react in any particular way to a random submission.

washadjeffmad 2y ago

I think "Code of Civility" is what Dr. G was describing. Conduct presupposes civility, but acceptable online discourse has changed amongst new internet natives raised in the era of moral totalitarianism, aggression as a service, and popular outrage incubators.

tura11 2y ago

[dead]

tura11 2y ago

[dead]