dev-python/cryptography to use rust, killing alpha, hppa, ia64, m68k, s390(archives.gentoo.org)
archives.gentoo.org
dev-python/cryptography to use rust, killing alpha, hppa, ia64, m68k, s390
https://archives.gentoo.org/gentoo-dev/message/17e24acecf8c42edbdbfff38935e86fa
23 comments
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.
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.
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.
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.
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
[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
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.)
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.
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.
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.
The post says that risc-v isn't supported by Rust but this is incorrect:
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.
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.
It says the riscv rust gentoo packages are missing. That seems plausible.
[deleted]
Michał Górny's later post in the thread is worth a read: https://archives.gentoo.org/gentoo-dev/message/167c5156a80d6...
It seems at least portage will be able to remove the dependency on dev-python/cryptography: https://archives.gentoo.org/gentoo-dev/message/73e4a44a8d047...
The kinda-response from cryptography thread:
https://github.com/pyca/cryptography/issues/5771#issuecommen...
>> 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.
>> 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.
That’s pretty definitive: the cryptography module is developed by volunteers that have neither the time nor inclination to support existing users.
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.
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.
Python itself doesn't actually support these architectures! It just happens to work, and well they broke it. IDK what else you'd expect.
Related discussion: lwn.net article about this situation
https://news.ycombinator.com/item?id=26097153
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.