Mold Linker Decides To Drop DEC Alpha Support: Likely Broken & No Actual Users

[PuckPoltergeist]

Essentially the entire global financial industry runs on s390x. Z outsells Power by a lot.

Insurance too

[Eirikr1848]

Ahem, I am using it on m68k, and several of us donated to get that support in.

Not to mention ArchPOWER is going strong (ArchLinuxPOWER.org with links to his GitHub there) AND Wii-Linux.org is now using ArchPOWER as a base.

All those Wiis still out there are now millions of potential Linux devices… running on 32-bit PPC.

(And for 32-bit x86? Projects like the ITX Llama exist that utilize an 86Duino powered by a Vortex86SX CPU… and this stuff keeps gaining popularity as nostalgia is quite contagious)

https://youtu.be/ogHqmjn6sY4?si=SQmjocJU1A8kPsgH

[Estranged1906]

realistically, the list of major ones right now would be:

• x86
• POWER
• ARM
• MIPS

hopefully RISC-V will replace MIPS and ARM within a few years, so we can narrow that list down to 3, but it'll have to go up to 5 (by adding RISC-V) before that happens.

I thought the MIPS ISA is dead (unless you count LoongArch as the continuation), so this would be legacy devices only. Or are there still many new devices fitted with MIPS CPUs, e.g. routers? I would have thought they are now mostly using ARM or even RISC-V.

[egorfine]

$ uname -mrs
Linux 6.11.0 alpha
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux trixie/sid"

Wow! But.. how?

[royce]

Why not strip out any architecture not actively maintained or produced in the last 15 years, and anybody using that architecture just has to use older software that actually works on it in the first place.

Isn't that what they're doing here?

[Daktyl198]

The point of having modern toolchain components for retro platforms is cross-compilation. See, for example, Retro68 or Open Watcom v2. ...or, for that matter, gcc-ia16.

Example problems with just using an old version:

• Difficulty getting old C or C++ programs to build with modern compilers. (I've encountered this with things as recent as the last release version of OpenSLP from 2013.)
• Not everyone has experience plumbing together a toolchain when they're not just installing all the bits and pieces in the system-default locations.
• Some parts of the toolchain (eg. the version of GCC with the latest and greatest optimizers) may assume command-line flags that your frozen version is too old to have.

1. doesn't that support my argument rather than go against it? If modern compilers broke those architecture's software anyway, why are we pretending to support them?
2. I'm sure enthusiasts could put together a simple bundled toolkit that supported the architecture and make it easy to install a compiler + emulator/etc in a single package. Maybe even make it a flatpak.
3. My argument is that ALL parts of the build chain should drop support in modern releases, not just for the linker. That includes GCC, Linux itself, etc. So this would never come into play.

Supporting architectures that old costs time and effort when developing new features and fixing bugs, for an install base of 0.000001% of the software's users. Logistically it doesn't make sense, and they should be relegated to older software releases. "Updates" to that target platform could be maintained by a fork. It's FOSS software, it's easy to fork at a prior release.

[Daktyl198]

not using Mold, but...

$ uname -mrs
Linux 6.11.0 alpha
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux trixie/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=trixie
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

_{$ cat /proc/cpuinfo|grep 'system type'
system type : QEMU}

If you're actually running Linux 6.11 on a DEC Alpha... what exactly do you use it for? Surely none of the original software written for it work on a modern platform, and most modern software won't work (or at least work well) due to minimum hardware requirements. I'm genuinely curious!

[Daktyl198]

Isn't that what they're doing here?

To one of the 30+ unique architectures that existed in the 70s and 80s that are still supported by modern FOSS software because god forbid they ever drop support for anything despite it actively hurting modern development time and time again. Imagine if every website was still required to work on the original IE. This forum would not work.

[Ananace]

Can anybody explain to me why open-source software, that has extremely easy to acquire older versions of themselves, need to keep support for such ancient architectures readily available? Like, nobody is running Linux 6.11 and using Mold on a DEC Alpha because it's literally not powerful enough to do so, and yet here we are with "support" for the architecture.

Reasonable assumption all things considered, actually running development versions of OpenVMS on two dual-node Alpha servers instead. (And two Itanium blades, but that's a different story)

[Vistaus]

I feel like we don't need all these architectures. What is it good for, have all these niche architectures? That is just division and scattered resources. It is better to streamline things and get rid of all these niche architectures and just keep the major ones like x86, ARM and RISC-V. Less is more.

In what world is RISC-V major? Don't get me wrong: I'm rooting for them and I would love to have RISC-V hardware in the future, when software support and performance are better then they are now to replace my 64-bit system(s). But RISC-V is nowhere near being major at the moment.