>> You can't really expect volunteers to port the whole Rust to other architectures just to get cryptography back.
> It sounds like you're saying that your time as a Gentoo and NetBSD maintainer is worth more than the time of cryptography maintainers. They are volunteers as well, y' know. You expect those volunteers to keep their security-focused project dependent on inherently insecure technology because it would make your own job easier. Your goals and requirements might not be matching the goals and plans of the maintainers of cryptography. It might be unfortunate for you but it really is as simple as that.
Once again, there is a choice -- support old hardware or have secure software.
This happened before with the web browsers, and the solution was to either stop using using old computers for web, or run ancient versions, only go to "known good" websites, and hope really hard that you don't end up on a page with exploit by accident.
And now this trickles down to the non-web world as well, and this is potentially much worse -- after all, most of the modern languages require network connectivity of some sort.
For context... I don't think Gentoo has statistics for the relative number of users on each architecture, but Debian does (at https://popcon.debian.org/, scroll down to "Statistics per Debian architectures").
Relative to 185,729 samples from users on amd64, there are:
5 users on alpha
8 users on hppa
5 users on ia64
5 users on m68k
7 users on s390x
This is a vanishingly small number of users we are talking about here. Most of these architectures have been out of production for the last 10-15 years; they're largely only used by retrocomputing enthusiasts, not as production systems.
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.
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
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.
> 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.
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)
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.
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.
23 comments
[ 3.1 ms ] story [ 61.8 ms ] thread>> You can't really expect volunteers to port the whole Rust to other architectures just to get cryptography back.
> It sounds like you're saying that your time as a Gentoo and NetBSD maintainer is worth more than the time of cryptography maintainers. They are volunteers as well, y' know. You expect those volunteers to keep their security-focused project dependent on inherently insecure technology because it would make your own job easier. Your goals and requirements might not be matching the goals and plans of the maintainers of cryptography. It might be unfortunate for you but it really is as simple as that.
The only reasonable options are porting to something else or forking the module.
That’s been my experience with everything I’ve written or maintained in python, which is why I no longer consider using it for new projects.
It’s too bad. I dusted off some old python 2 scripts today, and (thanks to the frozen in time interpreter/modules) they worked fine.
https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
It's not tier 1 but it is supported. In fact, embedded Rust on risc-v is super hot right now.
This happened before with the web browsers, and the solution was to either stop using using old computers for web, or run ancient versions, only go to "known good" websites, and hope really hard that you don't end up on a page with exploit by accident.
And now this trickles down to the non-web world as well, and this is potentially much worse -- after all, most of the modern languages require network connectivity of some sort.
Relative to 185,729 samples from users on amd64, there are:
This is a vanishingly small number of users we are talking about here. Most of these architectures have been out of production for the last 10-15 years; they're largely only used by retrocomputing enthusiasts, not as production systems.Hopefully someone will tell me I'm wrong.
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.
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.
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.
https://popcon.debian.org/stat/sub-s390.png
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.)
[0] https://github.com/thepowersgang/mrustc