That is so few users that the situation is basically impossible. As a retrocomputing enthusiast and the owner of computers from some of those architectures, that doesn't make me happy. While I find some money, and provide access to a machine, there just aren't enough dollars to support bringing Rust and LLVM to Alpha or HPPA. It just isn't a thing that can happen.

Hopefully someone will tell me I'm wrong.

As a fellow retrocomputing enthusiast: vintage computers are most interesting when they're running appropriate period software (e.g. OpenVMS or early Windows NT on Alpha, HP-UX on HPPA, and a variety of manufacturer-specific OSes on 680x0). Running a modern Linux on them feels like a bit of a waste -- sure, it works, but a lot of what made those systems interesting is lost.

Personally, as a fan of retro games consoles (which are broadly in the same boat as retrocomputing hardware) I'm as interested in new independently-produced software as I am in the software released during the hardware's commercial lifespan. Original games aren't getting any cheaper as copies disappear into private collections, and the economic incentives don't exist for copyright holders to make new authentic cartridges.

As such, the vibrancy of these systems relies on writing new software being a pleasant experience, and there's a limit to how pleasant that experience can be when your only choice of non-assembly language is C.

Retro gaming consoles are kind of different. Any software for them is necessarily written for that console in particular, and can take advantage of its hardware capabilities in unique ways, even if you're using modern tools to write that software.

Standard Linux software running on a PC, even an older and weirder PC, probably isn't going to do anything that interesting. At the end of the day, an X server running Firefox (or whatever) isn't going to be any different on an old PA-RISC workstation than it is on a modern desktop computer or a Raspberry Pi or whatever.

On the other hand: do enthusiast/toy systems really need the very latest security patches? It's not like they turn into bricks without this support, the old code will keep working

> While I find some money, and provide access to a machine, there just aren't enough dollars to support bringing Rust and LLVM to Alpha or HPPA. It just isn't a thing that can happen.

The Motorola 68k architecture is apparently getting included in LLVM (albeit as an 'experimental', unsupported backend) so it seems that this could be an option. Another option is to support Rust via cranelift.

Is there any argument against focusing the effort on a rust to C compiler like mrustc [0]? It would allow the support of older architectures by taking advantage of their C compilers.

[0] https://github.com/thepowersgang/mrustc

s390x (linux on Z) != s390 (31 bit arch from the early 90s for IBM mainframes)

Oh, huh, you're right. That one's so rare that it looks like Debian stopped getting any popcon reports from it several years ago:

https://popcon.debian.org/stat/sub-s390.png

Worth keeping the reporting bias in mind in this case. It's extremely more likely that a home user will send data to popcon than a mainframe which may not even have a full internet connection. I wouldn't be surprised if many are run in isolated networks and with local repos. (I don't expect it to be more than 10 either way of course)

I doubt many mainframes are running Debian.

IBM recommends Red Hat, SUSE or Ubuntu. All three come with commercial support contracts. If you are already paying big bucks for a mainframe, it seems far more likely you'd go with one of the IBM-recommended distributions than go with Debian.

(Ubuntu may have an interest in keeping Debian on mainframe alive because doing so helps them in offering Ubuntu on mainframe.)

And I'd doubt even more that they're running Gentoo -- especially on older hardware, where having to compile everything from source is even more of a burden than usual.