9 ms·

RISC-V support in Android just got a big setback

104 points by ammo1662 2y ago

fidotron 2y ago
The quote in there mentions “rate of iteration”, which given the noise Qualcomm were making makes me speculate Qualcomm are planning on forking RISCV to be more arm64ish and Google would not want to be maintaining both that and vanilla RISCV in this until the dust settles. It is something like that or they really are removing it.
- snvzz 2y ago
  It's the other way around. Support for Qualcomm's incompatible platform is being removed[0]. 0. https://news.ycombinator.com/item?id=40212173 https://news.ycombinator.com/item?id=40212173
- themiddleupper 2y ago
  I suspected it was not good news for RISC V when Qualcomm got involved. They are going to split the RISC V ecosystem.
  - deleted 2y ago
    [deleted]
  - Pet_Ant 2y ago
    > They are going to split the RISC V ecosystem. Part of the DNA of RISC-V is to provide a basis from which a million flowers can bloom. Instead of homebrewing, you can reuse RISC-V and make tweaks as you need... if you really do need a custom variant. Think of it as English, a common substratum from which there are lots of mostly interoperable dialects. This is what happened with Unix. Now if we want a mainstream consumer then we will need a dominant strain or two. The RISC-V foundation is doing that with the RVA23 profiles etc, but if there is a few major ones that should be navigable. Linux had support for PC-98[1] which was a Japanese alternate x86 platform. The changes I've seen proposed by Qualcomm don't seem drastically different [2], and could be incorporated in the same binaries with sniffing the supported features. The semantics are what are important, and it's not different there at all. Could be supported with trap and emulate [1] https://en.wikipedia.org/wiki/PC-98 https://en.wikipedia.org/wiki/PC-98 [2] https://lists.riscv.org/g/tech-profiles/attachment/332/0/code_size_extension_rvi_20231006.pdf https://lists.riscv.org/g/tech-profiles/attachment/332/0/cod...
    - Tuna-Fish 2y ago
      The code size reduction instructions are an extension that will go through and will eventually be supported by everyone, and is not the bone of contention here. They are designed to be "brown-field" instructions, that is, fit into the unimplemented holes in the current spec. The reason the spec is going to split is not them, but the fact that Qualcomm also wants to remove the C extension, and put something else in the encoding space it frees.
      - Pet_Ant 2y ago
        Hmm, that seems like a mistake because C allows for instruction compression with low cost to decode that is perfect for embedded use which is a big part of the RISC-V usage now. That said, if they implemented C, and then had their replacement toggleable with a CSR that would still be backwards (albeit not forwards) compatible so that'd only be an issue if Qualcomm RISC-V binaries become dominant, but I don't think binaries are gonna be that dominant outside of firmware going forward, and any that are will be from vendors that will multi-target.
        phkahler 2y ago
        >> Hmm, that seems like a mistake because C allows for instruction compression with low cost to decode that is perfect for embedded use which is a big part of the RISC-V usage now. It may be low cost to decode a compressed instruction, but having them means regular 32-bit instructions can cross cache lines and page boundaries. My own thought is that there should be a "next" version or RISC-VI that is mostly assembler-level compatible but changes all the instruction encodings to be more sane. What that means exactly is still a bit fuzzy, but I am a fan of immediate data being stored after the opcode.
        __s 2y ago
        yes, was curious why compression format didn't require 1. non compressed instructions are always 4 byte aligned (pad a 2 byte NOP if necessary, or use uncompressed 4 byte instruction to fix sizing) 2. jump targets are always 4 byte aligned (which exists without C, but C relaxes) This avoids cache line issues & avoids jumps landing inside an instruction. Can consider each 2 compressed instructions as a single 4 byte instruction Bit redundant to encode C prefix twice, so there's room to make use of that (take up less encoding space at least by having prefix be 2x as long), but not important
  - Tuna-Fish 2y ago
    The solution to this is not to split, but just follow Qualcomm. Their vision for the future of the ISA is simply much better than SiFive's. Right now, most devices on the market do not support the C extension, and any code that tries to be compatible does not use it. Qualcomm wants to remove it because it is actively harmful for fast implementations, and burns 75% of the entire encoding space, which is already extremely tight. SiFive really wants to keep it. The solution to fragmentation is to just disable the C extension everywhere, but SiFive doesn't want to hear that.
    - camel-cdr 2y ago
      > most devices on the market do not support the C extension Name one that doesn't, it's exactly the opposite (for 64-bit).
      - GeorgeTirebiter 2y ago
        Maybe you've found the solution: RV32 must have the C extension. RV64 and RV128 must NOT have the C extension. Problem solved?
        camel-cdr 2y ago
        No I meant, that for 64-bit CPUs virtually every available one supports the C extension.
    - sitkack 2y ago
      > Right now, most devices on the market do not support the C extension This is not true and easily verifiable. The C extension is defacto required, the only cores that don't support it are special purpose soft cores. C extension in the smallest IP available core https://github.com/olofk/serv?tab=readme-ov-file https://github.com/olofk/serv?tab=readme-ov-file Supports M and C extensions https://github.com/YosysHQ/picorv32 https://github.com/YosysHQ/picorv32 Another sized optimized core with C extension support https://github.com/lowrisc/ibex https://github.com/lowrisc/ibex C extension in the 10 cent microcontroller https://www.wch-ic.com/products/CH32V003.html https://www.wch-ic.com/products/CH32V003.html This one should get your goat, it implements as much as it can using only compressed instructions https://github.com/gsmecher/minimax https://github.com/gsmecher/minimax
- Dylan16807 2y ago
  > to be more arm64ish I have a hard time picturing what this means. There's so much flexibility in implementing a core; what would they want to change in the ISA to make them like it better in a non-negligible way?
  - fidotron 2y ago
    Prior discussion includes https://news.ycombinator.com/item?id=37996820 https://news.ycombinator.com/item?id=37996820
  - Tuna-Fish 2y ago
    Mainly, richer addressing modes. SiFive designed RISC-V to have braindead-level simple addressing modes, with the idea that you use 2-4 normal alu ops to do addressing instead of a single op with a more complicated addressing mode. Then, to reduce the horrible impact this has on code size, they introduced the C extension that burns 75% of the encoding space of 32-bit instructions on 16-bit instructions, but this is still only a bandaid and a much weaker solution than having better addressing modes in the first place.
    - camel-cdr 2y ago
      It's not as black and white as you portray it. Both sides of the argument agree that high-performance implementations are doable and not hindered much buy both, you can watch the debate in the profiles SIG zoom meetings. I think the real dispute was how the opcode space and code density will evolve when more and more extension will need to be added. Will more 32 opcode space and aligned 64 bit instructions but no 16 and no 48 bit instructions in the longterm be a better choice than fewer 32 bit instructions, but 16/48/64 bit instructions? Qualcomm is also currently involved in the Combined Instructions SIG, and proposed a few instructions in that vain: https://docs.google.com/spreadsheets/d/1dQYU7QQ-SnIoXp9vVvVjS6Jz9vGWhwmsdbEOF3JBwUg/edit#gid=0 https://docs.google.com/spreadsheets/d/1dQYU7QQ-SnIoXp9vVvVj.... Notice that these are currently very mild combined instructions, like BEQI, or CLO, which are unlikely to be cracked into uops compared to more complex addressing modes (e.g. apple silicon needs to crack pre/post increment load/stores). BTW, this article is actually about removing Qualcomm specific stuff from android, see: https://lists.riscv.org/g/sig-android/topic/105816077#msg389 https://lists.riscv.org/g/sig-android/topic/105816077#msg389
justinclift 2y ago
Wonder if this is due to US gov pressure, with the aim to slow the growth of chip making in China?
- acdha 2y ago
  Being quick to jump to conspiracy theories means you’ll have trouble being taken seriously when something real happens. I’d go with the most parsimonious explanation: Google doesn’t have plans to ship anything soon and isn’t going to commit to supporting an entire platform they don’t need. Especially given their slash-and-burn management culture, I wouldn’t read anything more into it than nobody at Google thinking that they’re going to be promoted for working on that. I am curious whether we’ll see Qualcomm or someone else step up to do the work.
  - Dylan16807 2y ago
    Is the idea of government pressure automatically a conspiracy theory?
    - acdha 2y ago
      In the absence of any evidence or even a sensible motive, what is it? There’s no reason to think Google’s stated reason isn’t true, and as an attempt to obstruct China it would be rather pointless to go after something they have almost no deployed usage of which is starting behind things they do use.
    - stusmall 2y ago
      It is their guess at what is happening without proof. That is the definition of a theory. It is about two entities secretly working together to do something harmful. That's a conspiracy. So... I mean... yeah. The comment is a perfect example a conspiracy theory. Both in literal textbook definition and the broader cultural understanding of the term.
      - Dylan16807 2y ago
        Two entities, not publicly, very minor harm from reduced competition, you could say the same thing about a huge fraction of discussions between two companies. Government pressure isn't some big deal, it happens all the time. For the broader cultural understanding, it needs to be something where making it public wouldn't be extremely boring.
RetroTechie 2y ago
Reads like a typical "will be released when it's ready, but it's not ready". Or providing a (single) generic kernel for RISC-V is impractical, so support for that is removed until another approach is figured out? Just speculating here. But Android-on-RISC-V is pretty much unavoidable at this point. Google-blessed or otherwise. If Google won't do it (article does not suggest that?), the open source community will. Or the Chinese. Or some other deep-pocketed corp interested in pushing this ahead.
- whimsicalism 2y ago
  Does it? They say the risc-v support “is discontinued”, which seems to imply something much stronger than what you say.
  - camel-cdr 2y ago
    The article says: > Android will continue to support RISC-V. Due to the rapid rate of iteration, we are not ready to provide a single supported image for all vendors. This particular series of patches removes RISC-V support from the Android Generic Kernel Image (GKI). There is some more context in the android SIG: https://lists.riscv.org/g/sig-android/topic/105816077#msg389 https://lists.riscv.org/g/sig-android/topic/105816077#msg389
    - andrekandre 2y ago
      that link makes it much more clear > they are removing older code for Qualcomm specific use case that is no longer supported (Wear OS IIRC was discontinued). That pre-dates all the current work, so I expect this was removed because the platform was deprecated and > since maintenance of an officially _labelled_ GKI kernel is more expensive, we're removing the sticker for now. so... basically a nothingburger?
- tadfisher 2y ago
  The question is, which RISC-V? You're providing a single kernel for phone-like things, so probably RV64I as a base. MAFD is pretty much required for running a Java VM. Q, no. C, are you shipping for Si-Five or Qualcomm? J/T/P/V would be useful, but does the kernel need it? H is needed for Android phones these days but not watches. S, no idea. The explanation makes sense to me; let the dust settle and have real hardware shipping before defining the base feature set in a generic kernel image.
ponow 2y ago
Supporting extra architectures isn't free, and cost matters in an era when devs are getting laid off in numbers.
YouCantBanMe1 2y ago
[dead]
YouCantBanMe1 2y ago
[dead]
not_your_vase 2y ago
Tangentially related to RISC-V current events: just a few weeks ago came some news[0], that the RISC-V community doesn't consider the support of Yocto project to be too important, and they don't want to support it anymore... (which was quite interesting, considering that RISC-V supposed to be big wannabe embedded competitor). [0]: https://lists.yoctoproject.org/g/yocto/message/62906 https://lists.yoctoproject.org/g/yocto/message/62906
- smashed 2y ago
  > We received some disappointing feedback from a key organization in the RISC-V ecosystem that the Yocto Project was not important and not worth funding. We will take this feedback into account. That's a bummer. But the core Risc-V support should be contributed straight to the Linux kernel/u-boot/gcc/glibc anyway I guess. Then board makers, not chip makers, should contribute/provide yocto support, based on that foundational work. Not sure which key organization they are referring too though.
  - snvzz 2y ago
    Strong agree. It would be bad for RISC-V to favor a Linux distribution of all things. The favoritism would look bad. Distributions will properly support RISC-V even without RISC-V funding them directly, if they wish to remain relevant.
1attice 2y ago
I see a lot of comments on whether this is motivated by geopolitics -- an attempt to deal a setback to China. I have no way of knowing whether this is the case, but in general, I would suggest that this is at least plausible, and, if I am right in this, we need to have an existential conversation about what happens to Open Source in a global warfare scenario. (cf https://www.noahpinion.blog/p/americans-are-still-not-worried-enough https://www.noahpinion.blog/p/americans-are-still-not-worrie...) High-risk-low-liklihood scenarios are a fact of life, and we get used to dismissing them as the cost of doing business. But when those same habitual reflexes get used to dismiss scenarios that are now of moderate liklihood, we collectively make mistakes that are hard to recover from. Such mistakes are especially likely when (a) contextualizing an additional piece of information, such as a seemingly-unrelated product cancelation, or (b) making plans for the future (either personally, or for a project, company, or industry.) It's time to at least _have a conversation_ about what open source looks like under present global conditions, and that conversation needs to foreground the _exceptionality_ of the past thirty years of relatively peaceful relations between great powers. Nobody wants to have this conversation, not because it's scary, but because of significant social pressure we all experience to discount the liklihood of unpleasant futures. But here we are. What does trust look like in Open Source in 2030? How should we model threats? How do we ensure that as many people as possible can contribute to projects, while at the same time minimizing the risk of another xz? A spookier question: _can_ we?

104 points by ammo1662 2y ago

The quote in there mentions “rate of iteration”, which given the noise Qualcomm were making makes me speculate Qualcomm are planning on forking RISCV to be more arm64ish and Google would not want to be maintaining both that and vanilla RISCV in this until the dust settles. It is something like that or they really are removing it.

snvzz 2y ago
It's the other way around. Support for Qualcomm's incompatible platform is being removed[0]. 0. https://news.ycombinator.com/item?id=40212173 https://news.ycombinator.com/item?id=40212173
themiddleupper 2y ago
I suspected it was not good news for RISC V when Qualcomm got involved. They are going to split the RISC V ecosystem.
- deleted 2y ago
  [deleted]
- Pet_Ant 2y ago
  > They are going to split the RISC V ecosystem. Part of the DNA of RISC-V is to provide a basis from which a million flowers can bloom. Instead of homebrewing, you can reuse RISC-V and make tweaks as you need... if you really do need a custom variant. Think of it as English, a common substratum from which there are lots of mostly interoperable dialects. This is what happened with Unix. Now if we want a mainstream consumer then we will need a dominant strain or two. The RISC-V foundation is doing that with the RVA23 profiles etc, but if there is a few major ones that should be navigable. Linux had support for PC-98[1] which was a Japanese alternate x86 platform. The changes I've seen proposed by Qualcomm don't seem drastically different [2], and could be incorporated in the same binaries with sniffing the supported features. The semantics are what are important, and it's not different there at all. Could be supported with trap and emulate [1] https://en.wikipedia.org/wiki/PC-98 https://en.wikipedia.org/wiki/PC-98 [2] https://lists.riscv.org/g/tech-profiles/attachment/332/0/code_size_extension_rvi_20231006.pdf https://lists.riscv.org/g/tech-profiles/attachment/332/0/cod...
  - Tuna-Fish 2y ago
    The code size reduction instructions are an extension that will go through and will eventually be supported by everyone, and is not the bone of contention here. They are designed to be "brown-field" instructions, that is, fit into the unimplemented holes in the current spec. The reason the spec is going to split is not them, but the fact that Qualcomm also wants to remove the C extension, and put something else in the encoding space it frees.
    - Pet_Ant 2y ago
      Hmm, that seems like a mistake because C allows for instruction compression with low cost to decode that is perfect for embedded use which is a big part of the RISC-V usage now. That said, if they implemented C, and then had their replacement toggleable with a CSR that would still be backwards (albeit not forwards) compatible so that'd only be an issue if Qualcomm RISC-V binaries become dominant, but I don't think binaries are gonna be that dominant outside of firmware going forward, and any that are will be from vendors that will multi-target.
      - phkahler 2y ago
        >> Hmm, that seems like a mistake because C allows for instruction compression with low cost to decode that is perfect for embedded use which is a big part of the RISC-V usage now. It may be low cost to decode a compressed instruction, but having them means regular 32-bit instructions can cross cache lines and page boundaries. My own thought is that there should be a "next" version or RISC-VI that is mostly assembler-level compatible but changes all the instruction encodings to be more sane. What that means exactly is still a bit fuzzy, but I am a fan of immediate data being stored after the opcode.
        __s 2y ago
        yes, was curious why compression format didn't require 1. non compressed instructions are always 4 byte aligned (pad a 2 byte NOP if necessary, or use uncompressed 4 byte instruction to fix sizing) 2. jump targets are always 4 byte aligned (which exists without C, but C relaxes) This avoids cache line issues & avoids jumps landing inside an instruction. Can consider each 2 compressed instructions as a single 4 byte instruction Bit redundant to encode C prefix twice, so there's room to make use of that (take up less encoding space at least by having prefix be 2x as long), but not important
- Tuna-Fish 2y ago
  The solution to this is not to split, but just follow Qualcomm. Their vision for the future of the ISA is simply much better than SiFive's. Right now, most devices on the market do not support the C extension, and any code that tries to be compatible does not use it. Qualcomm wants to remove it because it is actively harmful for fast implementations, and burns 75% of the entire encoding space, which is already extremely tight. SiFive really wants to keep it. The solution to fragmentation is to just disable the C extension everywhere, but SiFive doesn't want to hear that.
  - camel-cdr 2y ago
    > most devices on the market do not support the C extension Name one that doesn't, it's exactly the opposite (for 64-bit).
    - GeorgeTirebiter 2y ago
      Maybe you've found the solution: RV32 must have the C extension. RV64 and RV128 must NOT have the C extension. Problem solved?
      - camel-cdr 2y ago
        No I meant, that for 64-bit CPUs virtually every available one supports the C extension.
  - sitkack 2y ago
    > Right now, most devices on the market do not support the C extension This is not true and easily verifiable. The C extension is defacto required, the only cores that don't support it are special purpose soft cores. C extension in the smallest IP available core https://github.com/olofk/serv?tab=readme-ov-file https://github.com/olofk/serv?tab=readme-ov-file Supports M and C extensions https://github.com/YosysHQ/picorv32 https://github.com/YosysHQ/picorv32 Another sized optimized core with C extension support https://github.com/lowrisc/ibex https://github.com/lowrisc/ibex C extension in the 10 cent microcontroller https://www.wch-ic.com/products/CH32V003.html https://www.wch-ic.com/products/CH32V003.html This one should get your goat, it implements as much as it can using only compressed instructions https://github.com/gsmecher/minimax https://github.com/gsmecher/minimax
Dylan16807 2y ago
> to be more arm64ish I have a hard time picturing what this means. There's so much flexibility in implementing a core; what would they want to change in the ISA to make them like it better in a non-negligible way?
- fidotron 2y ago
  Prior discussion includes https://news.ycombinator.com/item?id=37996820 https://news.ycombinator.com/item?id=37996820
- Tuna-Fish 2y ago
  Mainly, richer addressing modes. SiFive designed RISC-V to have braindead-level simple addressing modes, with the idea that you use 2-4 normal alu ops to do addressing instead of a single op with a more complicated addressing mode. Then, to reduce the horrible impact this has on code size, they introduced the C extension that burns 75% of the encoding space of 32-bit instructions on 16-bit instructions, but this is still only a bandaid and a much weaker solution than having better addressing modes in the first place.
  - camel-cdr 2y ago
    It's not as black and white as you portray it. Both sides of the argument agree that high-performance implementations are doable and not hindered much buy both, you can watch the debate in the profiles SIG zoom meetings. I think the real dispute was how the opcode space and code density will evolve when more and more extension will need to be added. Will more 32 opcode space and aligned 64 bit instructions but no 16 and no 48 bit instructions in the longterm be a better choice than fewer 32 bit instructions, but 16/48/64 bit instructions? Qualcomm is also currently involved in the Combined Instructions SIG, and proposed a few instructions in that vain: https://docs.google.com/spreadsheets/d/1dQYU7QQ-SnIoXp9vVvVjS6Jz9vGWhwmsdbEOF3JBwUg/edit#gid=0 https://docs.google.com/spreadsheets/d/1dQYU7QQ-SnIoXp9vVvVj.... Notice that these are currently very mild combined instructions, like BEQI, or CLO, which are unlikely to be cracked into uops compared to more complex addressing modes (e.g. apple silicon needs to crack pre/post increment load/stores). BTW, this article is actually about removing Qualcomm specific stuff from android, see: https://lists.riscv.org/g/sig-android/topic/105816077#msg389 https://lists.riscv.org/g/sig-android/topic/105816077#msg389

justinclift 2y ago

Wonder if this is due to US gov pressure, with the aim to slow the growth of chip making in China?

acdha 2y ago
Being quick to jump to conspiracy theories means you’ll have trouble being taken seriously when something real happens. I’d go with the most parsimonious explanation: Google doesn’t have plans to ship anything soon and isn’t going to commit to supporting an entire platform they don’t need. Especially given their slash-and-burn management culture, I wouldn’t read anything more into it than nobody at Google thinking that they’re going to be promoted for working on that. I am curious whether we’ll see Qualcomm or someone else step up to do the work.
- Dylan16807 2y ago
  Is the idea of government pressure automatically a conspiracy theory?
  - acdha 2y ago
    In the absence of any evidence or even a sensible motive, what is it? There’s no reason to think Google’s stated reason isn’t true, and as an attempt to obstruct China it would be rather pointless to go after something they have almost no deployed usage of which is starting behind things they do use.
  - stusmall 2y ago
    It is their guess at what is happening without proof. That is the definition of a theory. It is about two entities secretly working together to do something harmful. That's a conspiracy. So... I mean... yeah. The comment is a perfect example a conspiracy theory. Both in literal textbook definition and the broader cultural understanding of the term.
    - Dylan16807 2y ago
      Two entities, not publicly, very minor harm from reduced competition, you could say the same thing about a huge fraction of discussions between two companies. Government pressure isn't some big deal, it happens all the time. For the broader cultural understanding, it needs to be something where making it public wouldn't be extremely boring.

RetroTechie 2y ago

Reads like a typical "will be released when it's ready, but it's not ready". Or providing a (single) generic kernel for RISC-V is impractical, so support for that is removed until another approach is figured out? Just speculating here. But Android-on-RISC-V is pretty much unavoidable at this point. Google-blessed or otherwise. If Google won't do it (article does not suggest that?), the open source community will. Or the Chinese. Or some other deep-pocketed corp interested in pushing this ahead.

whimsicalism 2y ago
Does it? They say the risc-v support “is discontinued”, which seems to imply something much stronger than what you say.
- camel-cdr 2y ago
  The article says: > Android will continue to support RISC-V. Due to the rapid rate of iteration, we are not ready to provide a single supported image for all vendors. This particular series of patches removes RISC-V support from the Android Generic Kernel Image (GKI). There is some more context in the android SIG: https://lists.riscv.org/g/sig-android/topic/105816077#msg389 https://lists.riscv.org/g/sig-android/topic/105816077#msg389
  - andrekandre 2y ago
    that link makes it much more clear > they are removing older code for Qualcomm specific use case that is no longer supported (Wear OS IIRC was discontinued). That pre-dates all the current work, so I expect this was removed because the platform was deprecated and > since maintenance of an officially _labelled_ GKI kernel is more expensive, we're removing the sticker for now. so... basically a nothingburger?
tadfisher 2y ago
The question is, which RISC-V? You're providing a single kernel for phone-like things, so probably RV64I as a base. MAFD is pretty much required for running a Java VM. Q, no. C, are you shipping for Si-Five or Qualcomm? J/T/P/V would be useful, but does the kernel need it? H is needed for Android phones these days but not watches. S, no idea. The explanation makes sense to me; let the dust settle and have real hardware shipping before defining the base feature set in a generic kernel image.

ponow 2y ago

Supporting extra architectures isn't free, and cost matters in an era when devs are getting laid off in numbers.

YouCantBanMe1 2y ago

[dead]

YouCantBanMe1 2y ago

[dead]

not_your_vase 2y ago

Tangentially related to RISC-V current events: just a few weeks ago came some news[0], that the RISC-V community doesn't consider the support of Yocto project to be too important, and they don't want to support it anymore... (which was quite interesting, considering that RISC-V supposed to be big wannabe embedded competitor). [0]: https://lists.yoctoproject.org/g/yocto/message/62906 https://lists.yoctoproject.org/g/yocto/message/62906

smashed 2y ago
> We received some disappointing feedback from a key organization in the RISC-V ecosystem that the Yocto Project was not important and not worth funding. We will take this feedback into account. That's a bummer. But the core Risc-V support should be contributed straight to the Linux kernel/u-boot/gcc/glibc anyway I guess. Then board makers, not chip makers, should contribute/provide yocto support, based on that foundational work. Not sure which key organization they are referring too though.
- snvzz 2y ago
  Strong agree. It would be bad for RISC-V to favor a Linux distribution of all things. The favoritism would look bad. Distributions will properly support RISC-V even without RISC-V funding them directly, if they wish to remain relevant.

1attice 2y ago

I see a lot of comments on whether this is motivated by geopolitics -- an attempt to deal a setback to China. I have no way of knowing whether this is the case, but in general, I would suggest that this is at least plausible, and, if I am right in this, we need to have an existential conversation about what happens to Open Source in a global warfare scenario. (cf https://www.noahpinion.blog/p/americans-are-still-not-worried-enough https://www.noahpinion.blog/p/americans-are-still-not-worrie...) High-risk-low-liklihood scenarios are a fact of life, and we get used to dismissing them as the cost of doing business. But when those same habitual reflexes get used to dismiss scenarios that are now of moderate liklihood, we collectively make mistakes that are hard to recover from. Such mistakes are especially likely when (a) contextualizing an additional piece of information, such as a seemingly-unrelated product cancelation, or (b) making plans for the future (either personally, or for a project, company, or industry.) It's time to at least _have a conversation_ about what open source looks like under present global conditions, and that conversation needs to foreground the _exceptionality_ of the past thirty years of relatively peaceful relations between great powers. Nobody wants to have this conversation, not because it's scary, but because of significant social pressure we all experience to discount the liklihood of unpleasant futures. But here we are. What does trust look like in Open Source in 2030? How should we model threats? How do we ensure that as many people as possible can contribute to projects, while at the same time minimizing the risk of another xz? A spookier question: _can_ we?