7 ms·

Problem is that ARM & AArch64 were considered a "weird architecture" by the non-Android linux stack until really very recently, and the migration to a new archi

by ris 6y ago

Problem is that ARM & AArch64 were considered a "weird architecture" by the non-Android linux stack until really very recently, and the migration to a new architecture is still not plain-sailing in many peoples' experience. Without the assumption that most open source package authors are implicitly trying to be architecture-independent to some degree, we will literally all be stuck on x86_64 for the rest of our lives (the migration to amd64 itself I remember as being a number of years of people working on "unsupported" stuff FWIW). For users on "weird architectures" to be petitioning that a move the pyca authors are making is causing inconvenience to them is perfectly reasonable in my eyes.

steveklabnik 6y ago
Incidentally, aarch64-unknown-linux-gnu became a Tier 1 supported platform in Rust recently, in part because of the support of ARM themselves. (My day job involves a lot of Tier 2 ARM work, and I don't personally run into any more bugs than Tier 1 platforms. YMMV.)
rodgerd 6y ago
> Problem is that ARM & AArch64 were considered a "weird architecture" The ARM world is a blizzard of proprietary, undocumented implementations with limited support for the upstream kernels, often can boot only a vendor-specific distro that is quickly abandoned, and full of boards that blink in and out of existence at the drop of a hat. It absolutely is a weird architecture. > For users on "weird architectures" to be petitioning that a move the pyca authors are making is causing inconvenience to them is perfectly reasonable in my eyes. Yes, this is exactly the sense of entitlement that the author is talking about when he describes the destruction of people's interest in working on open source.
- ris 6y ago
  > this is exactly the sense of entitlement Now come on with your "entitlement". It's not as though we're talking about some random people who made some little package for their own use and decided to make it available in case anyone else found it useful, and now the community demands from them are becoming too much and are something they never asked for. This is a group that have named themselves the Python Cryptographic Authority and have chosen the prominent pypi package name of just "cryptography". They couldn't have done any more to encourage the broader community to depend on it and make it a core part of their stack. In comparison, I couldn't imagine the python core team (also largely unpaid) doing this with one of their stdlib modules and then dismissing those objecting as "entitled". (FWIW I'm not particularly interested in taking a side in this issue, but think your labelling as "entitled" is unhelpful)
  - darksaints 6y ago
    I agree with the idea that it is entitled. Hell, Python itself is only directly supported on a couple of architectures and operating systems. It has even fewer "tier 1" targets than Rust does! It is made available in source format only for other packagers to use as they see fit, but it is not python's responsibility to support it. Why should a library maintainer feel any obligation to support platforms that the language doesn't provide first class support for?
- casept 6y ago
  That may be true for peripherals, but all a compiler has to care about is the core ISA. The board zoo is very much not relevant.
  - rodgerd 6y ago
    But to meaningfully support a thing - per the original author - "compiles on a version of the ISA" (and there are many of those for ARM) - and "actually works as intended" do have to care about things like "this ARM core runs these extensions. This ARM core is really just a coprocessor to a binary blob processor. This ARM core is buggy as fuck but no longer supported by the vendor" matter. Where's your source of randomness for crypto, just as a starting point? People want - to borrow from the BSD world - FreeBSD levels of support for specific chipsets and features, with OpenBSD levels of support for security, and NetBSD levels of portability. These are not compatible outcomes, and folks should stop pretending that they are.
simias 6y ago
I don't think it's a good comparison. The architectures mentioned in the pyca/cryptography repo are: - Alpha: introduced 1992, discontinued in the early 2000s - HP/PA: introduced 1986, discontinued in 2008 - Itanium: introduced 2001, end of life 2021 - s390: introduced 1990, discontinued in ~1998 - m68k: introduced 1979, still in use in some embedded systems but not developed at Motorola since 1994. ARM was once not as popular as it is nowadays but it was never moribund and in my experience has always had decent tooling and compiler support. Furthermore I'm sure that if tomorrow HP/PA makes a comeback for some reason, LLVM will add support for it. Out of the list I'd argue that the only two who may be worth supporting are Motorola 68k and maybe Itanium but even then it's ultra niche. I personally maintain software that runs on old/niche DSPs and I like emulation, so I can definitely feel the pain of people who find new release of software breaking on some of the niche arch they use (I tried running Rust on MIPS-I but couldn't get it to work properly because of lack of support in LLVM for instance). These architectures are dead or dying, not up-and-coming like, say, RISC-V which has gained some momentum lately. But while I sympathize with people who are concerned by this sort of breakage, it's simply not reasonable to expect these open source projects to maintain backward compatibility with CPUs that haven't been manufactured in decades. As TFA points out it's a huge maintenance burden: you need to regression test against these architectures you may know nothing about, you may not have an easy way to fix the bugs that arise etc... >open source groups should not be unconditionally supporting the ecosystem for a >large corporation’s hardware and/or platforms. Preach. Intel is dropping Itanium, HP dropped HP/PA a long time ago. Why should volunteers be expected to provide support for free instead? It's like users who complain that software drops support for Windows 7 when MS themselves don't support the OS anymore.
- monocasa 6y ago
  FWIW, s390 wasn't really discontinued in 1998. There's still new s390 chips being designed and used.
  - zozbot234 6y ago
    s390 is the 31-bit-only variant, that has been discontinued for some time. Modern variants are 64-bit based, and still supported. All that being said, it's quite worthwhile to include these "dead" architectures in LLVM and Rust, if only for educational reasons. That need not imply the high level of support one would expect for, e.g. RISC-V.
darksaints 6y ago
But it is unreasonable, for one of two reasons: 1) If the architecture is in active production, there is someone somewhere trying to make money by selling it. If they are intent on only supporting proprietary compilers, they need to accept the consequences of that decision: users won't use their hardware because they can't use the software that they want to use. If they want the architecture to be widely used, they have a fiduciary obligation to ensure that they have reliable and well tested backends to major compilers. 2) If the user is using old architectures that are no longer in production or no longer supported, there isn't ever any reasonable expectation of continuing software support. You're stuck with old software, full stop. In the case of your objection, AArch64 and ARM manufacturers have the obligation to develop openly available backends for their architectures. And they've taken that seriously, as should any newcomer architectures.
- zozbot234 6y ago
  > If the user is using old architectures that are no longer in production or no longer supported, there isn't ever any reasonable expectation of continuing software support. You're stuck with old software, full stop. That's not a very reasonable POV. Many of these architectures are very well understood and very easily supported via emulation. There's no need to run them on actual hardware, especially if you aren't dealing with anything close to bare-metal quirks.
phire 6y ago
But ARM/AArch64 did always have good compiler support. ARM was the second arch added to llvm.

by ris 6y ago

steveklabnik 6y ago

Incidentally, aarch64-unknown-linux-gnu became a Tier 1 supported platform in Rust recently, in part because of the support of ARM themselves. (My day job involves a lot of Tier 2 ARM work, and I don't personally run into any more bugs than Tier 1 platforms. YMMV.)

rodgerd 6y ago

> Problem is that ARM & AArch64 were considered a "weird architecture" The ARM world is a blizzard of proprietary, undocumented implementations with limited support for the upstream kernels, often can boot only a vendor-specific distro that is quickly abandoned, and full of boards that blink in and out of existence at the drop of a hat. It absolutely is a weird architecture. > For users on "weird architectures" to be petitioning that a move the pyca authors are making is causing inconvenience to them is perfectly reasonable in my eyes. Yes, this is exactly the sense of entitlement that the author is talking about when he describes the destruction of people's interest in working on open source.

ris 6y ago
> this is exactly the sense of entitlement Now come on with your "entitlement". It's not as though we're talking about some random people who made some little package for their own use and decided to make it available in case anyone else found it useful, and now the community demands from them are becoming too much and are something they never asked for. This is a group that have named themselves the Python Cryptographic Authority and have chosen the prominent pypi package name of just "cryptography". They couldn't have done any more to encourage the broader community to depend on it and make it a core part of their stack. In comparison, I couldn't imagine the python core team (also largely unpaid) doing this with one of their stdlib modules and then dismissing those objecting as "entitled". (FWIW I'm not particularly interested in taking a side in this issue, but think your labelling as "entitled" is unhelpful)
- darksaints 6y ago
  I agree with the idea that it is entitled. Hell, Python itself is only directly supported on a couple of architectures and operating systems. It has even fewer "tier 1" targets than Rust does! It is made available in source format only for other packagers to use as they see fit, but it is not python's responsibility to support it. Why should a library maintainer feel any obligation to support platforms that the language doesn't provide first class support for?
casept 6y ago
That may be true for peripherals, but all a compiler has to care about is the core ISA. The board zoo is very much not relevant.
- rodgerd 6y ago
  But to meaningfully support a thing - per the original author - "compiles on a version of the ISA" (and there are many of those for ARM) - and "actually works as intended" do have to care about things like "this ARM core runs these extensions. This ARM core is really just a coprocessor to a binary blob processor. This ARM core is buggy as fuck but no longer supported by the vendor" matter. Where's your source of randomness for crypto, just as a starting point? People want - to borrow from the BSD world - FreeBSD levels of support for specific chipsets and features, with OpenBSD levels of support for security, and NetBSD levels of portability. These are not compatible outcomes, and folks should stop pretending that they are.

simias 6y ago

I don't think it's a good comparison. The architectures mentioned in the pyca/cryptography repo are: - Alpha: introduced 1992, discontinued in the early 2000s - HP/PA: introduced 1986, discontinued in 2008 - Itanium: introduced 2001, end of life 2021 - s390: introduced 1990, discontinued in ~1998 - m68k: introduced 1979, still in use in some embedded systems but not developed at Motorola since 1994. ARM was once not as popular as it is nowadays but it was never moribund and in my experience has always had decent tooling and compiler support. Furthermore I'm sure that if tomorrow HP/PA makes a comeback for some reason, LLVM will add support for it. Out of the list I'd argue that the only two who may be worth supporting are Motorola 68k and maybe Itanium but even then it's ultra niche. I personally maintain software that runs on old/niche DSPs and I like emulation, so I can definitely feel the pain of people who find new release of software breaking on some of the niche arch they use (I tried running Rust on MIPS-I but couldn't get it to work properly because of lack of support in LLVM for instance). These architectures are dead or dying, not up-and-coming like, say, RISC-V which has gained some momentum lately. But while I sympathize with people who are concerned by this sort of breakage, it's simply not reasonable to expect these open source projects to maintain backward compatibility with CPUs that haven't been manufactured in decades. As TFA points out it's a huge maintenance burden: you need to regression test against these architectures you may know nothing about, you may not have an easy way to fix the bugs that arise etc... >open source groups should not be unconditionally supporting the ecosystem for a >large corporation’s hardware and/or platforms. Preach. Intel is dropping Itanium, HP dropped HP/PA a long time ago. Why should volunteers be expected to provide support for free instead? It's like users who complain that software drops support for Windows 7 when MS themselves don't support the OS anymore.

monocasa 6y ago
FWIW, s390 wasn't really discontinued in 1998. There's still new s390 chips being designed and used.
- zozbot234 6y ago
  s390 is the 31-bit-only variant, that has been discontinued for some time. Modern variants are 64-bit based, and still supported. All that being said, it's quite worthwhile to include these "dead" architectures in LLVM and Rust, if only for educational reasons. That need not imply the high level of support one would expect for, e.g. RISC-V.

darksaints 6y ago

But it is unreasonable, for one of two reasons: 1) If the architecture is in active production, there is someone somewhere trying to make money by selling it. If they are intent on only supporting proprietary compilers, they need to accept the consequences of that decision: users won't use their hardware because they can't use the software that they want to use. If they want the architecture to be widely used, they have a fiduciary obligation to ensure that they have reliable and well tested backends to major compilers. 2) If the user is using old architectures that are no longer in production or no longer supported, there isn't ever any reasonable expectation of continuing software support. You're stuck with old software, full stop. In the case of your objection, AArch64 and ARM manufacturers have the obligation to develop openly available backends for their architectures. And they've taken that seriously, as should any newcomer architectures.

zozbot234 6y ago
> If the user is using old architectures that are no longer in production or no longer supported, there isn't ever any reasonable expectation of continuing software support. You're stuck with old software, full stop. That's not a very reasonable POV. Many of these architectures are very well understood and very easily supported via emulation. There's no need to run them on actual hardware, especially if you aren't dealing with anything close to bare-metal quirks.

phire 6y ago

But ARM/AArch64 did always have good compiler support. ARM was the second arch added to llvm.