3 ms·

> Imagine, for a moment, that you’re a maintainer of a popular project. [...] You’ve also got a CI/CD pipeline that produces canonical releases of your project

> Imagine, for a moment, that you’re a maintainer of a popular project. [...] You’ve also got a CI/CD pipeline that produces canonical releases of your project on tested architectures; [...] Because your project is popular, others also distribute it: Linux distributions, third-party package managers, and corporations seeking to deploy their own controlled builds. > You don’t know about any of the above until the bug reports start rolling in: users will report bugs that have already been fixed, bugs that you explicitly document as caused by unsupported configurations, bugs that don’t make any sense whatsoever. If 3rd-party build recipients are sending their bugs directly to you, that's a failure of the 3rd-party builders to take responsibility for their packages. They should be telling you to submit your bugs to them, so they can check their packaging, and then the packagers should talk to upstream only if there are issues to be resolved there. > You struggle to debug your users’ reports, since you don’t have access to the niche hardware, environments, or corporate systems that they’re running on. Yes, C supports lots of environments, and Rust supports quite a few (and hopefully more, soon), but I think it's perfectly fine for an upstream author to only support a subset of those. The benefits of Free Software is that if you want to get some software running on platforms the original author doesn't support but the language does, you can do that. Investigate the bug yourself. Figure out if it's in the app, or a 3rd-party library, or even the toolchain. Submit a patch. A good proportion of authors will happily accept patches for systems they themselves can't test on, if it's not too intrusive, and doesn't cause regressions on the platforms the author does support. They might be willing to entertain an intrusive patch series that allows for better cross-arch support, if you're willing to work with them on that. And if an author is not interested in helping you scratch your itch (ew! :-), create a fork. That should be easier than ever these days with the version control tools we have now, so much more than when Free Software was first envisioned. The author may even be willing to point other people who want to use their software on your platform your way (e.g. in their README), if only to get those users of their back!

slondr 4y ago
> The benefits of Free Software is that if you want to get some software running on platforms the original author doesn't support but the language does, you can do that. The exact cause of this entire controversy is that the software in question is switching to a language that supports less platforms.
- Karellen 4y ago
  Huh. I didn't read the article as being about the pyca/cryptography-on-rust controversy. I read it as using the pyca/cryptography-on-rust controversy as a jumping off point to discuss the difference between platforms-supported-by-the-toolchain, and platforms-supported-by-upstream-software, and whether users should expect to consider all platforms-supported-by-the-toolchain as being supported by all software written for that toolchain. Or not. And how far authors should go to help users on "niche" platforms they don't have access to. (Might be the 2.5 rewrites making it easy for different readers to come away with different conclusions?)
- sophacles 4y ago
  And? They don't (and never have) promised you guarantees that future versions would work in your use case. It's open source - you are welcome to use the last version that worked for your case, and if you want to change it and get new features, you can fork it. You got a hand from someone who built a thing you can use and gave it to you for free. This doesn't obligate them to continue to help you, there's no contract (implicit or explicit), and there's no warranty. It's your choice (or maybe obligation) to have your software work for your case, you agreed to it. If you made that agreement based on the assumption that someone else will keep giving you effort for free, the only problem when they say "no" is your bad assumption.

slondr 4y ago

> The benefits of Free Software is that if you want to get some software running on platforms the original author doesn't support but the language does, you can do that. The exact cause of this entire controversy is that the software in question is switching to a language that supports less platforms.

Karellen 4y ago
Huh. I didn't read the article as being about the pyca/cryptography-on-rust controversy. I read it as using the pyca/cryptography-on-rust controversy as a jumping off point to discuss the difference between platforms-supported-by-the-toolchain, and platforms-supported-by-upstream-software, and whether users should expect to consider all platforms-supported-by-the-toolchain as being supported by all software written for that toolchain. Or not. And how far authors should go to help users on "niche" platforms they don't have access to. (Might be the 2.5 rewrites making it easy for different readers to come away with different conclusions?)
sophacles 4y ago
And? They don't (and never have) promised you guarantees that future versions would work in your use case. It's open source - you are welcome to use the last version that worked for your case, and if you want to change it and get new features, you can fork it. You got a hand from someone who built a thing you can use and gave it to you for free. This doesn't obligate them to continue to help you, there's no contract (implicit or explicit), and there's no warranty. It's your choice (or maybe obligation) to have your software work for your case, you agreed to it. If you made that agreement based on the assumption that someone else will keep giving you effort for free, the only problem when they say "no" is your bad assumption.