4 ms·

They do welcome contributions at all stages. Just because it doesn't happen at your terms doesn't make it exclusive or about building walls. Do you think there

They do welcome contributions at all stages. Just because it doesn't happen at your terms doesn't make it exclusive or about building walls. Do you think there is a contribution model that will make everyone happy AND the kernel good?

bitcharmer 5y ago
> Just because it doesn't happen at your terms That's a good example of the toxic attitude I'm referring to. I never said anything about my terms. Just a healthy OSS ecosystem with more balanced control over what and how gets done. > Do you think there is a contribution model that will make everyone happy I don't know, do you? It'd be safe to assume however that the Linux project could benefit from some improvements. Or are you trying to suggest it's perfect in its current form?
- janto 5y ago
  It's safer to assume that what you perceive as toxic is actually working much better than what you have in mind, given the success of the Linux ecosystem.
  - bitcharmer 5y ago
    The level of toxicity and success are orthogonal. The warehouse part of Amazon's business is even more successful and more toxic (as a workplace) at the same time. So what is the point you are trying to make here?
    - TeMPOraL 5y ago
      Depends on the metric of success you pick. Comparing Linux Kernel to Amazon warehouse business is apples to elephants. Amazon's warehousing is successful financially, perhaps less so reputationally, but the workers in general aren't very happy about the conditions - and they're not exactly volunteers[0]. A proprietary business is also by definition extremely exclusive - it's not like Amazon will give you their blueprints and operations book for free, to help you start your semi-automated warehouse, and it won't let you contribute to their business either, without a great degree of vetting. Meanwhile, Linux Kernel is built by true volunteers, and is successful in terms of spread and reliability as a software engineering artifact. Its process is very much inclusive - they'll accept just about anything that contributes positively to the final artifact, according to goals the "core team" defines[1], without much regard for who you are or where are you from. The people contributing regularly don't seem to complain about conditions either. There's no actual toxicity in there. Unfortunately, in recent years it's become popular for people to call out anything they don't like as "toxic". It often reads like a 5 year old complaining that their grandma makes them wear a hat outside in winter[2]. I've never heard that Linus "just wants the billion dollar enterprises to be testing it not the kernel team which are more of an academic community", but I can see this as a valid point of view. Neither him nor the other early Linux Kernel contributors wanted the whole planetary economy to become critically dependent on their little project. They don't automatically inherit responsibility for everyone else - especially that the whole project is open and inclusive, so anyone who wants to help can help - for instance by creating their own test suites and using it to create and submit bugfixes. -- [0] - Not in the ways that matter. Sure, they've approached Amazon on their own, but they did that only because they don't have any better way of housing and feeding themselves and their kin. The market may not be putting a literal gun to your head, but that doesn't make economic desperation less of a threat to life. [1] - Without that part, you'd have a ball of mud, not a software project. [2] - Though every now and then, the "toxicity" line is more like playing with a WMD. Like a 5 year old who thinks threatening to call CPS on their parents for not giving them candy is being clever.
      - bitcharmer 5y ago
        I'm not comparing Linux project to Amazon. I'm saying you can be highly successful and toxic at the same time and provide Amazon as an example. > they'll accept just about anything that contributes positively to the final artifact That is simply not true. See my example a few comments up.
    - janto 5y ago
      Labelling something as "toxic" likely implies "bad for the success of the ecosystem". So no, they are definitely not orthogonal. They are (presumably negatively) correlated. The point made was: seeing that the Linux project is pretty successful already, it's not "safe to assume" that these changes you envision would lead to either a good kernel or a healthy ecosystem. You seem to want to optimize for something else...?
- encryptluks2 5y ago
  How many projects have you worked on that claimed they were coming into restructure things to make them better and they just made things a lot worse? Everyone has opinions on what could be improved, but rarely do they actually get things accomplished like the Linux kernel team has done. They already have contribution documents as well: https://www.kernel.org/doc/html/latest/process/1.Intro.html https://www.kernel.org/doc/html/latest/process/1.Intro.html > Sadly current kernel dev culture still promotes exclusion and building walls instead of reducing tension and removing barriers for entry I suggest if you are being excluded then you say what that exclusion is. I keep seeing people say this, but then asked about it they say things like... well I wanted to develop a driver in JavaScript and they said no. If you have legitimate issues then bring them forward to the Code of Conduct committee: https://www.kernel.org/code-of-conduct.html https://www.kernel.org/code-of-conduct.html
  - bitcharmer 5y ago
    Ok, I'll bite, here's a good example... Working for a large institution that heavily employs the latest hardware we stumbled upon an issue with tsc calibration on skylake platforms with overclocked BCLK. The issue stemmed from the fact that cpuid for our particular SKU returned nominal instead of actual tsc frequency. We submitted a simple patch that just introduced a kcmdline parameter to disable cpuid based calibration and fall back to msr-based method that works fine. The maintainer shot it down only because _in theory_ the cpuid method should work even for over clocked cases. In practice an Intel person admitted that the firmware for our particular SKU should be updated to fix this. Over two years later Intel still didn't release fw update and our simple patch hasn't been accepted because the maintainer sees the world as a perfect place. You know who helped us? RedHat. They saw the value of adding this workaround to allow their users use Linux even if it was the cpu vendor that messed up. Now tell me, how is this welcoming attitude on Linux kernel part? How can you blame me for my opinion when a partial fix to a real problem gets rejected for completely academic reasons?
    - encryptluks2 5y ago
      Where is the mailing list thread discussing the fix? I'd need more context. It does sound like Intel admitted that they need to update the firmware to resolve this. Are you loading the Intel microcode? I found a related patch here: https://lkml.org/lkml/2008/9/29/178 https://lkml.org/lkml/2008/9/29/178
- unglaublich 5y ago
  > That's a good example of the toxic attitude I'm referring to. [...] Calling a counter argument toxic is very... ah well, you know. > [...] Just a healthy OSS ecosystem with more balanced control over what and how gets done. [...] Those are _your_ terms I was referring to. > I don't know, do you? [...] No, but I'm also not saying: "current kernel dev culture still promotes exclusion and building walls". If you come up with such bold allegations you'll have to back them up. > [...] Or are you trying to suggest it's perfect in its current form? No, because "perfect" is an individual opinion.

bitcharmer 5y ago

> Just because it doesn't happen at your terms That's a good example of the toxic attitude I'm referring to. I never said anything about my terms. Just a healthy OSS ecosystem with more balanced control over what and how gets done. > Do you think there is a contribution model that will make everyone happy I don't know, do you? It'd be safe to assume however that the Linux project could benefit from some improvements. Or are you trying to suggest it's perfect in its current form?

janto 5y ago
It's safer to assume that what you perceive as toxic is actually working much better than what you have in mind, given the success of the Linux ecosystem.
- bitcharmer 5y ago
  The level of toxicity and success are orthogonal. The warehouse part of Amazon's business is even more successful and more toxic (as a workplace) at the same time. So what is the point you are trying to make here?
  - TeMPOraL 5y ago
    Depends on the metric of success you pick. Comparing Linux Kernel to Amazon warehouse business is apples to elephants. Amazon's warehousing is successful financially, perhaps less so reputationally, but the workers in general aren't very happy about the conditions - and they're not exactly volunteers[0]. A proprietary business is also by definition extremely exclusive - it's not like Amazon will give you their blueprints and operations book for free, to help you start your semi-automated warehouse, and it won't let you contribute to their business either, without a great degree of vetting. Meanwhile, Linux Kernel is built by true volunteers, and is successful in terms of spread and reliability as a software engineering artifact. Its process is very much inclusive - they'll accept just about anything that contributes positively to the final artifact, according to goals the "core team" defines[1], without much regard for who you are or where are you from. The people contributing regularly don't seem to complain about conditions either. There's no actual toxicity in there. Unfortunately, in recent years it's become popular for people to call out anything they don't like as "toxic". It often reads like a 5 year old complaining that their grandma makes them wear a hat outside in winter[2]. I've never heard that Linus "just wants the billion dollar enterprises to be testing it not the kernel team which are more of an academic community", but I can see this as a valid point of view. Neither him nor the other early Linux Kernel contributors wanted the whole planetary economy to become critically dependent on their little project. They don't automatically inherit responsibility for everyone else - especially that the whole project is open and inclusive, so anyone who wants to help can help - for instance by creating their own test suites and using it to create and submit bugfixes. -- [0] - Not in the ways that matter. Sure, they've approached Amazon on their own, but they did that only because they don't have any better way of housing and feeding themselves and their kin. The market may not be putting a literal gun to your head, but that doesn't make economic desperation less of a threat to life. [1] - Without that part, you'd have a ball of mud, not a software project. [2] - Though every now and then, the "toxicity" line is more like playing with a WMD. Like a 5 year old who thinks threatening to call CPS on their parents for not giving them candy is being clever.
    - bitcharmer 5y ago
      I'm not comparing Linux project to Amazon. I'm saying you can be highly successful and toxic at the same time and provide Amazon as an example. > they'll accept just about anything that contributes positively to the final artifact That is simply not true. See my example a few comments up.
  - janto 5y ago
    Labelling something as "toxic" likely implies "bad for the success of the ecosystem". So no, they are definitely not orthogonal. They are (presumably negatively) correlated. The point made was: seeing that the Linux project is pretty successful already, it's not "safe to assume" that these changes you envision would lead to either a good kernel or a healthy ecosystem. You seem to want to optimize for something else...?
encryptluks2 5y ago
How many projects have you worked on that claimed they were coming into restructure things to make them better and they just made things a lot worse? Everyone has opinions on what could be improved, but rarely do they actually get things accomplished like the Linux kernel team has done. They already have contribution documents as well: https://www.kernel.org/doc/html/latest/process/1.Intro.html https://www.kernel.org/doc/html/latest/process/1.Intro.html > Sadly current kernel dev culture still promotes exclusion and building walls instead of reducing tension and removing barriers for entry I suggest if you are being excluded then you say what that exclusion is. I keep seeing people say this, but then asked about it they say things like... well I wanted to develop a driver in JavaScript and they said no. If you have legitimate issues then bring them forward to the Code of Conduct committee: https://www.kernel.org/code-of-conduct.html https://www.kernel.org/code-of-conduct.html
- bitcharmer 5y ago
  Ok, I'll bite, here's a good example... Working for a large institution that heavily employs the latest hardware we stumbled upon an issue with tsc calibration on skylake platforms with overclocked BCLK. The issue stemmed from the fact that cpuid for our particular SKU returned nominal instead of actual tsc frequency. We submitted a simple patch that just introduced a kcmdline parameter to disable cpuid based calibration and fall back to msr-based method that works fine. The maintainer shot it down only because _in theory_ the cpuid method should work even for over clocked cases. In practice an Intel person admitted that the firmware for our particular SKU should be updated to fix this. Over two years later Intel still didn't release fw update and our simple patch hasn't been accepted because the maintainer sees the world as a perfect place. You know who helped us? RedHat. They saw the value of adding this workaround to allow their users use Linux even if it was the cpu vendor that messed up. Now tell me, how is this welcoming attitude on Linux kernel part? How can you blame me for my opinion when a partial fix to a real problem gets rejected for completely academic reasons?
  - encryptluks2 5y ago
    Where is the mailing list thread discussing the fix? I'd need more context. It does sound like Intel admitted that they need to update the firmware to resolve this. Are you loading the Intel microcode? I found a related patch here: https://lkml.org/lkml/2008/9/29/178 https://lkml.org/lkml/2008/9/29/178
unglaublich 5y ago
> That's a good example of the toxic attitude I'm referring to. [...] Calling a counter argument toxic is very... ah well, you know. > [...] Just a healthy OSS ecosystem with more balanced control over what and how gets done. [...] Those are _your_ terms I was referring to. > I don't know, do you? [...] No, but I'm also not saying: "current kernel dev culture still promotes exclusion and building walls". If you come up with such bold allegations you'll have to back them up. > [...] Or are you trying to suggest it's perfect in its current form? No, because "perfect" is an individual opinion.