10 ms·

> Threatening a social media campaign to out people is completely toxic behaviour. This is a long-term contributor who is perhaps a bit abrasive, not Jimmy fuck

by e40 2y ago

> Threatening a social media campaign to out people is completely toxic behaviour. This is a long-term contributor who is perhaps a bit abrasive, not Jimmy fucking Saville. I'm no where near in the loop on this, but that sounds incredibly toxic. Are there some good links to summarize this? EDIT: OK, these are fully enough to allow me to understand the issue. Marcan: https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98c3-a48ab35bb9db@marcan.st/ https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98... Linus: https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSUGq8vUZAOWWSK1vrJarMaOhReDRQRYQ@mail.gmail.com/ https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU... I must say, I think I'm on Linus' side on this one. EDIT2: I was a $$ supporter of Marcan for over a year on github. I was predisposed to believe him, I'd say.

soraminazuki 2y ago
https://archive.is/rESxe https://archive.is/rESxe This is a recurring pattern I see with drama in some open source communities, where people measure others using yardsticks they themselves don't live up to. People can't post stuff like this while accusing everyone in the vicinity except themselves of bad behavior. Choose one.
- account42 2y ago
  Yikes, at great example of how not all thoughts that pop into your head should be publicised.
  - CRConrad 2y ago
    Hm, good thing I'm not a Linux maintainer. 'Coz that first C in my username... (My given name is the only thing about me that has anything to do with "Christ".)
lll-o-lll 2y ago
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.
KennyBlanken 2y ago
[flagged]
- serf 2y ago
  .. or it could just be that 'the public' has little to add to kernel development other than social landmines that the kernel teams have to navigate in order to achieve technical work..
- soraminazuki 2y ago
  The dirty laundry of the entire kernel community not immediately knuckling under and implementing a rather long list of technical changes in the preferred way of one specific individual? That's an unreasonable take. It would be disastrous for all of us if the project ever went that way, considering the importance of Linux today. It's not like I disagree with some of the points that Marcan raised, but others have equally valid concerns as well. However, he wants to get discussion and compromise out the window and go straight to social media drama. That's never okay. And please, stop using the concept of ad hominems to selectively justify blatant abuse. That's not what the term is about.
  - jorvi 2y ago
    > straight to social media drama. It was a move of frustration due to having exhausted all other avenues. It wasn't his first action.
    - account42 2y ago
      Things not moving as fast as he wants isn't the same as having exhausted all other avenues.
rdtsc 2y ago
> If shaming on social media does not work, then tell me what does, because I'm out of ideas. That's just manipulative. Maybe it's just a moment of frustration and they'd take it back eventually, but blackmailing people with social drama is not cool. That's what X and Reddit is for. > Rust folks: Please don't waste your time and mental cycles on drama like this [...] they know they're going to be on the losing side of history sooner or later. That sounds very cult-like, doesn't it?
- Aeolun 2y ago
  It’s true though? I don’t see anyone picking C/C++ over Rust/Go in my immediate environment. That might reflect my environment, but all of the things I’d consider C variations for I’d use Rust for as well…
  - rdtsc 2y ago
    I meant the whole “we are on the right side of history” and if you’re not with us you’re against us and we’ll wage a public drama campaign against you.
    - uecker 2y ago
      Exactly.
    - markhahn 2y ago
      Brings to mind certain world figures who have normalized this kind of petulance (which is bullying when real power is involved).
  - 59nadir 2y ago
    It's definitely your environment, Rust isn't nearly as popular for actual projects getting done as it is in (for example) StackOverflow's survey. C, C++, Odin and Zig are all languages where whatever C knowledge you have right now can trivially be put to use to do things, immediately, I think it makes perfect sense that unless someone is just really into doing Rust things they'll just take the trivially applicable ways of working and use the aforementioned languages (which all have much better support for batch memory management and custom allocators than Rust, it should be added).
a3p 2y ago
When i was the focus of the rust community, and trending #1 on HN, i simply deleted my repos and disappeared. Some people in that community reflexively see a conspiracy or invoke the CoC or use whatever other non technical tools they find to derail the discussion. It's not even that they're always wrong or that I directly oppose the culture they want to have, but the shotgun blast of drama that this comes with is just so much effort to navigate that i decided to just never contribute to rust again.
harshreality 2y ago
I think this is an important data point, too: Gunthorpe [nvidia]: https://lore.kernel.org/rust-for-linux/20250130154646.GA2298732@nvidia.com/ https://lore.kernel.org/rust-for-linux/20250130154646.GA2298... Basically, there is concern that even with a declaration that Rust-for-Linux devs will maintain this (and potentially every other) cross-language API translation layer file, the demarcation point between C and Rust isn't sufficient, and is causing C developers lag or headaches by having PRs rejected because of Rust-side failures. I don't see how that can be fixed without wholesale buy-in to Rust of enough kernel devs that they can fix whatever Rust problems are created by C API changes. Or Linus will have to accept PRs that break Rust-enabled builds. The R4L devs, by themselves, don't have the bandwidth to keep up. Even if they can rapidly fix problems, that adds potential friction to every C API change. Hellwig may not be communicating in a good way, but he might be right, unfortunately. Linux may need to stay as a C-only codebase until an AI language-translation tool is good enough to do things like maintain the Rust API translation layer itself. Or until basically all maintainers learn and accept Rust.
- steveklabnik 2y ago
  Greg replied and explained that this is a mischaracterization https://lore.kernel.org/rust-for-linux/2025013030-gummy-cosmic-7927@gregkh/ https://lore.kernel.org/rust-for-linux/2025013030-gummy-cosm...
  - rc00 2y ago
    You are misrepresenting the current state. The thread was unfortunately diverted before Jason's question received an appropriate response and conclusion: https://lore.kernel.org/rust-for-linux/20250131135421.GO5556@nvidia.com/ https://lore.kernel.org/rust-for-linux/20250131135421.GO5556... > Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not. > Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders". > It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build. The matter and the question at heart is still unsettled. The answer of whether or not Rust being in a broken state is a blocker for working and valid C code will hopefully be addressed by the end of this cycle of development. Either the patches are accepted and Rust is truly allowed to be broken or the patches will not be accepted due to breaking the Rust builds. If it is the latter, as many of the C developers fear, that is the exact burden being placed upon them that they have been stressing very loudly that they have no interest in taking on. And once other maintainers see this, what is the inevitable response to this metastasization? Comments like those from Ted and Christoph will pale in comparison. The only bright side might be that this finally accelerates the inevitable demise of this failed Rust experiment so that all parties can move on with their business.

by e40 2y ago

soraminazuki 2y ago

https://archive.is/rESxe https://archive.is/rESxe This is a recurring pattern I see with drama in some open source communities, where people measure others using yardsticks they themselves don't live up to. People can't post stuff like this while accusing everyone in the vicinity except themselves of bad behavior. Choose one.

account42 2y ago
Yikes, at great example of how not all thoughts that pop into your head should be publicised.
- CRConrad 2y ago
  Hm, good thing I'm not a Linux maintainer. 'Coz that first C in my username... (My given name is the only thing about me that has anything to do with "Christ".)

lll-o-lll 2y ago

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.

KennyBlanken 2y ago

[flagged]

serf 2y ago
.. or it could just be that 'the public' has little to add to kernel development other than social landmines that the kernel teams have to navigate in order to achieve technical work..
soraminazuki 2y ago
The dirty laundry of the entire kernel community not immediately knuckling under and implementing a rather long list of technical changes in the preferred way of one specific individual? That's an unreasonable take. It would be disastrous for all of us if the project ever went that way, considering the importance of Linux today. It's not like I disagree with some of the points that Marcan raised, but others have equally valid concerns as well. However, he wants to get discussion and compromise out the window and go straight to social media drama. That's never okay. And please, stop using the concept of ad hominems to selectively justify blatant abuse. That's not what the term is about.
- jorvi 2y ago
  > straight to social media drama. It was a move of frustration due to having exhausted all other avenues. It wasn't his first action.
  - account42 2y ago
    Things not moving as fast as he wants isn't the same as having exhausted all other avenues.

rdtsc 2y ago

> If shaming on social media does not work, then tell me what does, because I'm out of ideas. That's just manipulative. Maybe it's just a moment of frustration and they'd take it back eventually, but blackmailing people with social drama is not cool. That's what X and Reddit is for. > Rust folks: Please don't waste your time and mental cycles on drama like this [...] they know they're going to be on the losing side of history sooner or later. That sounds very cult-like, doesn't it?

Aeolun 2y ago
It’s true though? I don’t see anyone picking C/C++ over Rust/Go in my immediate environment. That might reflect my environment, but all of the things I’d consider C variations for I’d use Rust for as well…
- rdtsc 2y ago
  I meant the whole “we are on the right side of history” and if you’re not with us you’re against us and we’ll wage a public drama campaign against you.
  - uecker 2y ago
    Exactly.
  - markhahn 2y ago
    Brings to mind certain world figures who have normalized this kind of petulance (which is bullying when real power is involved).
- 59nadir 2y ago
  It's definitely your environment, Rust isn't nearly as popular for actual projects getting done as it is in (for example) StackOverflow's survey. C, C++, Odin and Zig are all languages where whatever C knowledge you have right now can trivially be put to use to do things, immediately, I think it makes perfect sense that unless someone is just really into doing Rust things they'll just take the trivially applicable ways of working and use the aforementioned languages (which all have much better support for batch memory management and custom allocators than Rust, it should be added).

a3p 2y ago

When i was the focus of the rust community, and trending #1 on HN, i simply deleted my repos and disappeared. Some people in that community reflexively see a conspiracy or invoke the CoC or use whatever other non technical tools they find to derail the discussion. It's not even that they're always wrong or that I directly oppose the culture they want to have, but the shotgun blast of drama that this comes with is just so much effort to navigate that i decided to just never contribute to rust again.

harshreality 2y ago

I think this is an important data point, too: Gunthorpe [nvidia]: https://lore.kernel.org/rust-for-linux/20250130154646.GA2298732@nvidia.com/ https://lore.kernel.org/rust-for-linux/20250130154646.GA2298... Basically, there is concern that even with a declaration that Rust-for-Linux devs will maintain this (and potentially every other) cross-language API translation layer file, the demarcation point between C and Rust isn't sufficient, and is causing C developers lag or headaches by having PRs rejected because of Rust-side failures. I don't see how that can be fixed without wholesale buy-in to Rust of enough kernel devs that they can fix whatever Rust problems are created by C API changes. Or Linus will have to accept PRs that break Rust-enabled builds. The R4L devs, by themselves, don't have the bandwidth to keep up. Even if they can rapidly fix problems, that adds potential friction to every C API change. Hellwig may not be communicating in a good way, but he might be right, unfortunately. Linux may need to stay as a C-only codebase until an AI language-translation tool is good enough to do things like maintain the Rust API translation layer itself. Or until basically all maintainers learn and accept Rust.

steveklabnik 2y ago
Greg replied and explained that this is a mischaracterization https://lore.kernel.org/rust-for-linux/2025013030-gummy-cosmic-7927@gregkh/ https://lore.kernel.org/rust-for-linux/2025013030-gummy-cosm...
- rc00 2y ago
  You are misrepresenting the current state. The thread was unfortunately diverted before Jason's question received an appropriate response and conclusion: https://lore.kernel.org/rust-for-linux/20250131135421.GO5556@nvidia.com/ https://lore.kernel.org/rust-for-linux/20250131135421.GO5556... > Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not. > Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders". > It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build. The matter and the question at heart is still unsettled. The answer of whether or not Rust being in a broken state is a blocker for working and valid C code will hopefully be addressed by the end of this cycle of development. Either the patches are accepted and Rust is truly allowed to be broken or the patches will not be accepted due to breaking the Rust builds. If it is the latter, as many of the C developers fear, that is the exact burden being placed upon them that they have been stressing very loudly that they have no interest in taking on. And once other maintainers see this, what is the inevitable response to this metastasization? Comments like those from Ted and Christoph will pale in comparison. The only bright side might be that this finally accelerates the inevitable demise of this failed Rust experiment so that all parties can move on with their business.