Hacker News Reader

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.

"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.

Many (most?) projects bypass this by simply not specifying which platforms are supported, and making decisions about breaking support on an ad hoc basis. Of course OSS developers are entitled to do this if they think it's best, but that's a good way to either create a burden for yourself when people start using your package in unintended ways, or to annoy people when something suddenly stops working because you never intended to support it.

Rust is doing it right by explicitly stating which targets are supported and to what extent. You can use it for other targets (I've written a lot of code for AVR which isn't supported at all) but if something breaks they stated up front that it wasn't supported.

> 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

And Python 3.9+ doesn't work anymore on Windows 7:

https://discuss.python.org/t/windows-7-support-for-python-3-...

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.

“Congratulations! You aren’t running Eunice!” From the early Perl configuration script.

I'm not counting platforms removed because of deprecation.

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?

> 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.

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...

> 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.

> 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).

Borderline agree, though the debate around this post always expanded to cover projects in general (which is not your fault).

Yep -- I don't want this post to be read as a dictum, but as an identification of a conflict between two principles the OSS communities generally tries to uphold: we all generally agree that (1) we should be able to do whatever we like with free and open software, and (2) that maintainers are not responsible for what we do, or for fixing our problems.

Open source ate the world, which has meant a heavy lilt towards (1): we see people go out and do stuff without questioning the underlying design and system invariants that made a piece of open source software secure and desirable in the first place. That ends up eroding (2); I'd like to see us rebalance a bit back towards maintainers' interests.

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

Do you think it's hobbyists trying to run cryptography on s390?

Not sure, but I’d love to know more about their specific usage, because it seems something fixable.

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.