4 ms·

I never agreed with this. Who defines what is considered "weird"? Should all projects declare up-front that it only is designed to work on: - x86_64 and aarch6

by ris 4y ago

I never agreed with this. Who defines what is considered "weird"? Should all projects declare up-front that it only is designed to work on: - x86_64 and aarch64 - linux, darwin and windows - glibc (no musl) - binutils x.xx - ... ... where do you stop before you're defining an exact linux distribution? If it weren't for people building and using packages for architectures that are "unsupported", I should point out that there would be no good userspace support for ARM or aarch64. These too were once "weird architectures" that only have good support now because of people building for (and using) these architectures without permission, then shaking all the bugs out. This is currently still happening for risc-v. I have to contrast this attitude to CPython, who, while I'm sure they never originally said that their code was designed to run on s390 (risc-v, pick your architecture..), would not go ahead with a change that froze out these users. I also don't think the "we're just a poor bunch of small-time package maintainers whose package accidentally became popular" angle quite works, because they call themselves the "Python Cryptographic Authority" and use the prominent package name `cryptography`, which certainly appears to imply some sort of official status. I wouldn't blame people for inferring that its support policies were somewhat aligned with the python foundation's.

jackmott 4y ago
[dead]
323 4y ago
> I have to contrast this attitude to CPython, who, while I'm sure they never originally said that their code was designed to run on s390 (risc-v, pick your architecture..), would not go ahead with a change that froze out these users. You have a wrong recollection of history. CPython removed support for several platforms, including former major ones like Windows XP and Vista. > Attached PR removes code to support Windows Vista. https://bugs.python.org/issue32592 https://bugs.python.org/issue32592 And Python 3.9+ doesn't work anymore on Windows 7: https://discuss.python.org/t/windows-7-support-for-python-3-9-or-3-10-without-a-fork/13842 https://discuss.python.org/t/windows-7-support-for-python-3-...
- tyingq 4y ago
  Perl might be a better stand in for the argument. It has supported oddball platforms for its entire history, with pretty extensive build support that checks for lots of platform specific settings.
  - whartung 4y ago
    “Congratulations! You aren’t running Eunice!” From the early Perl configuration script.
- ris 4y ago
  I'm not counting platforms removed because of deprecation.
  - spenczar5 4y ago
    Surely Hewlett Packard’s 1990s CPUs are at least as deprecated as Windows 7? Or IBM’s System 390 mainframes, which were discontinued in 2004? What is the difference?
jeroenhd 4y ago
I can't be bothered to support you if my choice of programming language doesn't work on your washing machine/Itanium server/IBM mainframe, and I don't see why others should. Maybe if you donated the necessary hardware to test the software against and pay for the extra effort required to make sure the software works, but only if the maintainers are interested in spending their time that way in the first place. All of these ports exist because volunteers or companies decide to put effort into porting these projects. They're usually outside the control of the original maintainers. If you want software to work on your machines, submit patches to make it work, pay someone to make it work for you, or pay for a support contract with someone who can make it work. You're entitled to the terms stated in the contract you've signed, which is usually nothing. If using a modern language is incompatible with your ISA of choice, ask the ISA developers to port the necessary compilers so it does work. In this instance, the language weird architectures don't support is Rust, which has a GCC frontend, assuming your operating system is at least somewhat up to date. This "if you call it open source you must make your code work for my niche use case" mentality is just one of the many ways of being entitled that make maintaining open source software suck. If you absolutely need software to keep working for you, buy hardware that's actually supported in the first place.
- captainmuon 4y ago
  "support" means two things. On the one extreme end, it means "provide commerical support for a product", on the other end it means "permit it to happen". I wouldn't support anything in the first sense, but if I would maintain a popular package I would strive to support as much as possible in the second sense. In my experience, keeping code general and cross platform is a great way to ensure correctness. Especially in C(++). I can't count how many bugs I caught by cross compiling Linux code on Windows, or with different compilers, or different architectures. Usually the kind of sleeping bug due to undefined behavior or wrong assumptions that kind of worked but might blow up a long time later. In most projects, if somebody provides a small patch to make my code work for their use case, and it's not too much trouble for me, and my tests pass, then I'll gladly include it. I'll not "support-support" it, but I think one should support it. At least if I open-sourced it because I want it to be useful to other people.
efficax 4y ago
aarch64 and riscv got ports and support primarily because they have major industry backing, not because of hobbyists.
- ris 4y ago
  Do you think it's hobbyists trying to run cryptography on s390?
  - rbanffy 4y ago
    Not sure, but I’d love to know more about their specific usage, because it seems something fixable.
woodruffw 4y ago
> I also don't think the "we're just a poor bunch of small-time package maintainers whose package accidentally became popular" angle quite works, because they call themselves the "Python Cryptographic Authority" and use the prominent package name `cryptography`, which certainly appears to imply some sort of official status. Author here; I think you might have misunderstood this point. It’s not about official status, blessing, size, or, funding: it’s the fact that cryptography (and many other things) are hard to do safely and reliably across multiple platforms, when the common layer of interaction is fundamentally unreliable. The problem here isn’t your own initiative (by all means, compile anything on any architecture you please), but whether it’s reasonable for projects to pretend to paper over those unreliabilities (and, in doing so, accept responsibility for platforms they didn’t want to support in the first place). My intuition is that it isn’t reasonable on its own, and that expecting maintainers to do this (particularly when so much of it boils down to free corporate support) is unfair and a security hazard.
- gavinhoward 4y ago
  Blogger who wrote a blog post about this too. [1] I disagree with you somewhat. > expecting maintainers to do this (particularly when so much of it boils down to free corporate support) is unfair and a security hazard. This would be true if its premise was true, but its premise is not quite true. One of the maintainers works for Red Hat Security Engineering. Another has a computer security company. If the latter wanted to charge for work on the library, he certainly could. The former probably gets paid to work on it already. So yeah, I'd expect something better from them. [1]: https://gavinhoward.com/2021/02/rust-zig-and-the-futility-of-replacing-c/ https://gavinhoward.com/2021/02/rust-zig-and-the-futility-of...
  - woodruffw 4y ago
    > One of the maintainers works for Red Hat Security Engineering. Another has a computer security company. I don't know where you got this from. I know Cryptography's maintainers well, and neither works at Red Hat or owns a security company. I know for a fact that neither gets paid to work on Cryptography. Even if they did, there is no guarantee that having a job in a company grants you the mandate (or latitude) to maintain support for random platforms, especially ones used by other companies.
pyuser583 4y ago
I one had to deal with a 12-bit OS because in the early Cold War the Navy had to do some targeting calculation that required exactly 12 bits. So they ordered a computer with 12 bits.

by ris 4y ago

jackmott 4y ago

[dead]

323 4y ago

> I have to contrast this attitude to CPython, who, while I'm sure they never originally said that their code was designed to run on s390 (risc-v, pick your architecture..), would not go ahead with a change that froze out these users. You have a wrong recollection of history. CPython removed support for several platforms, including former major ones like Windows XP and Vista. > Attached PR removes code to support Windows Vista. https://bugs.python.org/issue32592 https://bugs.python.org/issue32592 And Python 3.9+ doesn't work anymore on Windows 7: https://discuss.python.org/t/windows-7-support-for-python-3-9-or-3-10-without-a-fork/13842 https://discuss.python.org/t/windows-7-support-for-python-3-...

tyingq 4y ago
Perl might be a better stand in for the argument. It has supported oddball platforms for its entire history, with pretty extensive build support that checks for lots of platform specific settings.
- whartung 4y ago
  “Congratulations! You aren’t running Eunice!” From the early Perl configuration script.
ris 4y ago
I'm not counting platforms removed because of deprecation.
- spenczar5 4y ago
  Surely Hewlett Packard’s 1990s CPUs are at least as deprecated as Windows 7? Or IBM’s System 390 mainframes, which were discontinued in 2004? What is the difference?

jeroenhd 4y ago

I can't be bothered to support you if my choice of programming language doesn't work on your washing machine/Itanium server/IBM mainframe, and I don't see why others should. Maybe if you donated the necessary hardware to test the software against and pay for the extra effort required to make sure the software works, but only if the maintainers are interested in spending their time that way in the first place. All of these ports exist because volunteers or companies decide to put effort into porting these projects. They're usually outside the control of the original maintainers. If you want software to work on your machines, submit patches to make it work, pay someone to make it work for you, or pay for a support contract with someone who can make it work. You're entitled to the terms stated in the contract you've signed, which is usually nothing. If using a modern language is incompatible with your ISA of choice, ask the ISA developers to port the necessary compilers so it does work. In this instance, the language weird architectures don't support is Rust, which has a GCC frontend, assuming your operating system is at least somewhat up to date. This "if you call it open source you must make your code work for my niche use case" mentality is just one of the many ways of being entitled that make maintaining open source software suck. If you absolutely need software to keep working for you, buy hardware that's actually supported in the first place.

captainmuon 4y ago
"support" means two things. On the one extreme end, it means "provide commerical support for a product", on the other end it means "permit it to happen". I wouldn't support anything in the first sense, but if I would maintain a popular package I would strive to support as much as possible in the second sense. In my experience, keeping code general and cross platform is a great way to ensure correctness. Especially in C(++). I can't count how many bugs I caught by cross compiling Linux code on Windows, or with different compilers, or different architectures. Usually the kind of sleeping bug due to undefined behavior or wrong assumptions that kind of worked but might blow up a long time later. In most projects, if somebody provides a small patch to make my code work for their use case, and it's not too much trouble for me, and my tests pass, then I'll gladly include it. I'll not "support-support" it, but I think one should support it. At least if I open-sourced it because I want it to be useful to other people.

efficax 4y ago

aarch64 and riscv got ports and support primarily because they have major industry backing, not because of hobbyists.

ris 4y ago
Do you think it's hobbyists trying to run cryptography on s390?
- rbanffy 4y ago
  Not sure, but I’d love to know more about their specific usage, because it seems something fixable.

woodruffw 4y ago

> I also don't think the "we're just a poor bunch of small-time package maintainers whose package accidentally became popular" angle quite works, because they call themselves the "Python Cryptographic Authority" and use the prominent package name `cryptography`, which certainly appears to imply some sort of official status. Author here; I think you might have misunderstood this point. It’s not about official status, blessing, size, or, funding: it’s the fact that cryptography (and many other things) are hard to do safely and reliably across multiple platforms, when the common layer of interaction is fundamentally unreliable. The problem here isn’t your own initiative (by all means, compile anything on any architecture you please), but whether it’s reasonable for projects to pretend to paper over those unreliabilities (and, in doing so, accept responsibility for platforms they didn’t want to support in the first place). My intuition is that it isn’t reasonable on its own, and that expecting maintainers to do this (particularly when so much of it boils down to free corporate support) is unfair and a security hazard.

gavinhoward 4y ago
Blogger who wrote a blog post about this too. [1] I disagree with you somewhat. > expecting maintainers to do this (particularly when so much of it boils down to free corporate support) is unfair and a security hazard. This would be true if its premise was true, but its premise is not quite true. One of the maintainers works for Red Hat Security Engineering. Another has a computer security company. If the latter wanted to charge for work on the library, he certainly could. The former probably gets paid to work on it already. So yeah, I'd expect something better from them. [1]: https://gavinhoward.com/2021/02/rust-zig-and-the-futility-of-replacing-c/ https://gavinhoward.com/2021/02/rust-zig-and-the-futility-of...
- woodruffw 4y ago
  > One of the maintainers works for Red Hat Security Engineering. Another has a computer security company. I don't know where you got this from. I know Cryptography's maintainers well, and neither works at Red Hat or owns a security company. I know for a fact that neither gets paid to work on Cryptography. Even if they did, there is no guarantee that having a job in a company grants you the mandate (or latitude) to maintain support for random platforms, especially ones used by other companies.

pyuser583 4y ago

I one had to deal with a 12-bit OS because in the early Cold War the Navy had to do some targeting calculation that required exactly 12 bits. So they ordered a computer with 12 bits.