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

[royce]

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.

If it had been such a large problem in this particular project I'm sure they'd been removed long ago.

[ssokolow]

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?

I meant that modern compilers support the arches just fine, but they're not fully backwards compatible with old versions of the C or C++ language, so you need a certain amount of skill to compile tools or libraries written for old GCC and not updated... especially when the errors for "that syntax is no longer supported" tend to be cryptic.

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.

Now you're getting into "don't make me code in your textbox" territory where you start to implicitly penalize people who want to integrate with stuff outside your blessed bundle, such as code formatters or linters you don't use.

Yes, Retro68 is an example of what you're arguing for, but it's questionable whether it would have been achievable by the manpower available if all the components involved had actively purged support for m68k and PPC.

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.

And yet enthusiasts do the legwork to maintain support in the parts of the toolchain they use... to the point where some wrote a backend for GCC for targeting real-mode DOS... back in the day, enthusiasts had only written a GCC backend for protected-mode DOS so that's new.

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.

Forking massively increases the amount of labour involved and reduces the chances of changes that are beneficial to everybody getting shared. That's why it doesn't happen often. (eg. I've seen various tools with crappy bespoke CLI argument parsing and a lack of standard flags... such as leaving -h "blank" while only accepting -?. I write all my stuff for modern, network-attached PCs in Rust or Python so, If I were to contribute a patch to implement a proper argument parser, that'd go exclusively to your hypothetical retrocomputing fork of C tooling.)

[ssokolow]

Imagine if every website was still required to work on the original IE. This forum would not work.

As someone who prioritizes progressive enhancement/graceful degratation in his web creations and has been working on some retro-hobby web pages for the machines on his retro-hobby subnet, I can assure you that this forum is a very poor example of requiring a modern browser. Aside from the WYSIWYG mode for the post editor, everything here is trivial for a competent coder to implement in a manner that works without JavaScript, and this layout exists because forums like phpBB (of "bbcode" fame) set the standard back in the days of MS-IE. Hell, the reason you have those matching-height sidebars is that it originated in the days of <table>-based page layouts.

Granted, for the really early IE versions, you're gonna need to lay it out using HTML templates, but Internet Explorer 5 for Windows 3.1 and Classic Mac OS is quite capable of providing the basis for a discussion forum and, if you don't mind it looking "View > Page Style > No Style"-level ugly on old IE, you use stunnel to terminate the TLS connection on a modern machine, and you keep this kind of manual pagination instead of infinite scrolling, you can make modern, maintained forum software that's also readable and usable on an early IE version.

...not to mention that Classilla, TenFourFox, and K-Meleon can offer much newer, Gecko-based browsers for classic Mac OS, Mac OS X PPC, and Windows 9x, respectively, so you're usually not going to see a big demand for old MS-IE support among retro-computing hobbyists. (I do it because the thing I'm building is a retro-nostalgic download site for my hobby LAN, where you want to use IE in its iconic role as "Microsoft Better Browser Downloader"... well, that and an opportunity to experience the nostalgia of using Netscape 4.x.)

TL;DR: Aside from the WYSIWYG post editor and the flat design aesthetic, everything you see was invented on old Internet Explorer.

[Daktyl198]

Forking massively increases the amount of labour involved and reduces the chances of changes that are beneficial to everybody getting shared. That's why it doesn't happen often. (eg. I've seen various tools with crappy bespoke CLI argument parsing and a lack of standard flags... such as leaving -h "blank" while only accepting -?. I write all my stuff for modern, network-attached PCs in Rust or Python so, If I were to contribute a patch to implement a proper argument parser, that'd go exclusively to your hypothetical retrocomputing fork of C tooling.)

You don't have to hard-fork. They can soft-fork and maintain out-of-tree patches. The surface-linux project still has out-of-tree patches they maintain for the bespoke hardware in the Surface series of laptops and tablets. While their ultimate goal is to upstream them, they prove that it's a perfectly reasonable option. The point is that 99.9999% of users should not be affected by the wants of the 0.0001%. If it's a soft-fork, they can easily contribute any global improvements upstream while keeping support for their extremely niche hardware out of tree, where the upstream devs don't have to think about it.

[Daktyl198]

As someone who prioritizes progressive enhancement/graceful degratation in his web creations and has been working on some retro-hobby web pages for the machines on his retro-hobby subnet, I can assure you that this forum is a very poor example of requiring a modern browser...

True, a vBulletin forum was a bad example. But as you say, most forums by their very nature are reminiscent of old ways of doing things and so might, by sheer virtue of design, work on older browsers. SMF used to be my go-to forum and purposely built in "no-js" fallbacks. But not all forum software is designed as such, e.g. NodeBB or Discourse would be hard pressed to even support IE11, let alone older versions simply due to the JavaScript utilized in many of their core features. You don't see NodeBB all that often anymore, but Discourse is extremely popular. And that's just talking about Forums, not other web apps that make heavy usage of javascript or modern HTML and CSS features.

Try running YouTube in IE3. Even the Google search engine, which has fairly good backwards compatibility, cuts the line off at some point. That's why Frog Find exists.

[hotaru]

Wow! But.. how?

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!

I'm not.

[ssokolow]

True, a vBulletin forum was a bad example. But as you say, most forums by their very nature are reminiscent of old ways of doing things and so might, by sheer virtue of design, work on older browsers. SMF used to be my go-to forum and purposely built in "no-js" fallbacks. But not all forum software is designed as such, e.g. NodeBB or Discourse would be hard pressed to even support IE11, let alone older versions simply due to the JavaScript utilized in many of their core features. You don't see NodeBB all that often anymore, but Discourse is extremely popular. And that's just talking about Forums, not other web apps that make heavy usage of javascript or modern HTML and CSS features.

I never said vintage browsers are useful on the modern web. Hell, the push to TLS has killed pretty much anything that's not either on an OS receiving updates or receiving updates through a cert store of its own.

I was reacting specifically to how much your argument overreached.

[carewolf]

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.

If you have MIPS and POWER in you might as well count s390 and zArch.. And both MIPS and POWER probably counts as multiple architectures with the various endians and bitwidths supported,not to mention instruction set expansions.

But with Qt we are down to just x64, arm64 and armv7 now see https://doc.qt.io/qt-6/supported-platforms.html, since x86 was dropped from Windows and macOS, 32bit platforms are only armv7, and only on embedded platforms and everything is now little endian. Now how am I going to embarress senior developers when their code isn't endian neutral?