This is standard practice for low-volume legacy parts. A single production run will often yield enough parts for months or even years of demand; once demand gets low enough, the manufacturer will just sell what's left of the last batch, and discontinue the part when that runs out.

Also along these lines: test prep and study guide books. Same deal really.

Anyways, "real UNIX systems must implement UUCP" is still extremely silly.

> ... copy the binaries uucp, uuname, uustat, and uux from /usr/bin to /usr/local/bin and the binaries uucico and uuxqt from /usr/sbin to /usr/local/bin ...

This should be your hint that UNIX certification is more of a box-checking exercise than a real test of functionality. UUCP has been functionally obsolete since at least the mid-1990s; it's surprising that macOS even bothers shipping its binaries, and it's exceptionally silly that UNIX certification requires it to be present and installed in /usr/local.

That "laptop" will also absolutely smoke the Pi on performance, too:

https://browser.geekbench.com/v5/cpu/compare/24356484?baseli...

It's a lot easier for a large plaintiff - like a record label, a movie studio, or a software publisher - to file a lawsuit than it is for a small defendant like a web site operator to defend against one.

(What's the alternative, after all? Having no one responsible for what the AI summary says is clearly untenable.)

But I agree, that's probably not what OP meant.

Later in the operating system's lifecycle, applications typically used a single code segment and a custom loader to apply relocations, allowing them to use JSR within that segment.

Interestingly, you could print tokens in strings - e.g. you could Disp "Disp ".

It's an ICANN requirement. They all do it.

In principle, it could be designed to do so to handle cases where a new email address has been confirmed out of band, e.g. for an account representing a company or a political office. But that's a relatively unusual situation, not something you'd want to be available to every user writing in. (Even if you had an all-human support department, this sort of functionality would only be available to a select few agents.)

You might be surprised. C applications which interact heavily with the system - like rsync - can be tricky to test comprehensively, as it's nontrivial to inject faults into system calls. If the application is architected to support this kind of testing, or uses a HAL, that may make matters easier - but an older codebase like rsync probably isn't.