Most don't need to be rebranded. Alpha and hppa are retro computing and haven't been available to buy for 18 and 15 years respectively. Sh4 died this year. Only m68k is still holding on, but is a rounding error in the number is users.

Aren’t m68k computers only a few models from the 1990s and 1980s, and some more recent hobby projects? That’s squarely in the retro computing enthusiasts category.

I’m not in the Debian world, but those do seem to me like the types of systems that could use their own specialized distros rather than being a burden to the mass market ones. It’s not as if you could run a stock configuration of any desktop environment on them anyway.

m68k is used in a number of embedded systems today. It is unknown (to me) how many of those run linux (as opposed to some other embedded OS), but I would guess at least some do. I also don't know how many run (or want to run) debian vs something else (a custom yacto distribution is my first guess), but that might be non-zero. It is possible someone is running a non-debian distribution and using debian packages to provide their updates.

Does or should debian care? I don't know.

All I find searching for “embedded m68k Linux distro” is people looking for, or coming up with, alternatives, as Debian was already “too big” fifteen years ago.

I don’t get the fuzz around the “retro computing” verbiage. I doubt anyone is actually running Debian on these devices out of necessity, someone who plays baroque music in reconstructed period instruments won’t balk at being called an “early music” enthusiast.

Well, we are on a mission to create The Universal Operating System. So maybe.

But I'm not sure. I think the new Rust dependencies are good. In an ideal world, the people who care about niche systems step up to help Rust target those systems.

> In an ideal world, the people who care about niche systems step up to help Rust target those systems.

I’m actually the person who added the m68k target to the Rust compiler and was also one of the driving forces of getting the backend into LLVM.

Generally speaking, getting a new backend into the Rust compiler is not trivial as it depends on LLVM support at the moment which is why asking someone to just do it is a bit arrogant.

Luckily, both rustc_codegen_gcc and gccrs are being worked on, so this problem will be resolved in the future.

Sorry, I didn't mean to insinuate that there's anything minor about it, or that nobody is doing the work. I should have phrased myself differently.

I'll try to rephrase: if we never want to give up support for a platform we've supported in the past, then I think we only have two options: (1) never adopt new technology where support for said platforms doesn't come for free, or (2) leave it up to those who care about the niches to ensure support.

Neither is pain-free, but the first seems like a recipe for stagnation.

It's lovely to see the two alternative compiler paths for Rust moving forward though! Thank you!

Interesting bit about SH-4. I thought that Renesas had previously promised parts availability until 2029?

Sh-4 is on the Product Longevity Program https://www.renesas.com/en/support/product-longevity-program... but what it actually means, I really cannot easily figure out. It's marked as "Last Time Buy" right now.