Notices by Bitslingers-R-Us (anachronistjohn@zia.io)

@kornel @chainq

Lack of obscure/legacy things is immaturity only if you assume having them is a goal, but Rust prioritized other things

You illustrate the problem perfectly here: thinking that it’s either / or is a broken way of thinking.

Even if it were the case that prioritizing certain things precludes others (which it most certainly isn’t, unless you’re doing things incorrectly), this is precisely why Rust is inappropriate for universal adoption.

If a certain corporate led group gets to decide what is “obscure/legacy”, then people either have to maintain their own forks of Rust, or we just have to blindly accept that things that aren’t popular enough or that don’t get enough attention by corporations will be deemed, “obscure/legacy”.

@kornel @chainq This is bad for the planet. We should make good use of our computing resources and not intentionally landfill them. m68k is an example of how we can maintain support for non-mainstream if we want, yet people who know nothing about m68k would love to kill it for emotional reasons. We don’t need this at all. We’re already seeing this with Debian and i386.

So when people want to lump things in to an “obscure/legacy” category and suggest that the problem isn’t Rust, that just means you’re cheerleading for reducing sustainability.

@chainq @kornel Here’s a good example. How many people are even aware of the existence of SuperH? Do you know about SuperH? People who advocate for the dropping of i386 make claims of “cost” and “developer time” - of course they’d advocate for dropping support for processors they’re not even aware exist. Yet if you have a working (non Rust) toolchain, you can compile thousands of open source packages that were written by people of whom a vast majority probably know little or nothing of SuperH:

https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/sh3el/

It’s somehow viable in 2025 to have something like this with a modern toolchain, a modern OS, and thousands of compiled packages. So should people like you, who would most certainly consider SuperH to be “obscure/legacy”, be listened to when you advocate for Rust and the exclusion of what you somewhat dismissively consider to be “obscure/legacy”?

Rust is fine, but the advocacy is a bit exhausting, especially from people who show little awareness of the implications of getting what you claim to want.

@kornel That’s the thing - you’re not asked to choose between “writing software that might run on SuperH (but probably won’t due to speed & RAM requirements) vs being able to write more reliable software that runs better on still-manufactured CPUs”.

You invented those limitations. If you received a problem report about running on SuperH, it sounds like you’d focus more on how “irrelevant” it is, how support is a waste of time, perhaps, rather than focusing on the idea that fixing something, even something that’s an edge case, generally means code is better.

The Rust ecosystem is nice and all, and nobody is saying that anyone should abandon it. Of course you’ll all have your npm moment when crates get backdoored, but that’s just how these things work.

The real issue is that people in the Rust community want to replace everything with Rust versions while dismissing fallout as unimportant because “obscure/legacy”.

Sorry, but no.

@kaia Several of my clients go through UPSes regularly. While I encourage them to just get batteries, they still sometimes replace them outright, and I take all the old ones.

The most common, of course, are APC. They’re also the most pricey when new. Some of the smaller ones are built to take smaller than standard 7.2 to 9VA batteries, but easily removable plastic in the case is all that’s taking up the additional space which, of course, I remove, so most of the UPSes all get the same batteries.

CyberPower UPSes are good, but sometimes they come with mediocre batteries, and people incorrectly assume the issue is the hardware when it’s the batteries.

I can’t think of any that are actually bad, but I’d say if you’re considering getting one or two, see about getting a used one and buying new batteries from a reputable seller with good ratings.

Most can be used with apcupsd, even when they’re not APC brand.

So now most of my friends and family have a UPS on their Internet / phone in their homes, thanks to recycling and new batteries :)

Did you know that #NetBSD #m68k can compile itself from scratch?

How long would you imagine it might take to compile NetBSD 10 from source on real m68k hardware? Earlier this year I wanted to find out, so I set up a Macintosh to try it.

The toolchain, OS and installation sets started on 16-March and finished on 10-May:

That’s 1303 and a half hours, or almost eight weeks, or 54 days.

Installing the OS using build.sh took another four hours (4:08:39).

The kernel took another almost 21 hours (20:55).

That’s a lot of time, but it worked without issues, and the system runs happily!