There are four version of x86_64: v1, v2, v3, and v4.

RHEL 9 dropped support for anything prior to v3. That means RockyLinux doesn’t cover it, either. AlmaLinux has support for v2 in version 10, but there’s no way of knowing how long that will last.

Some binary packages are starting to drop support for earlier version. The latest numpy out of pip will not work on a v1 machine. You can sometimes use the system package manager’s numpy to work around it, or constrain pip to use an older numpy. I don’t know what else is lurking out there.

If you’ve got visions of taking a really old computer that you happened to max out on RAM back in the day and bringing it back to life there are surprises waiting for you.

They’ve been beaten on enough that industry is moving forward. The advantage of knowing and being able to prove that the algorithms are insecure would be incalcuable, so groups who want to be able to break into systems aren’t going to volunteer the information. It’s to the benefit of everyone else that the algorithms be secure. The third section of that paper I linked does a pretty good job explaining the why and why now.

tl;dr: Smart people have dug into it, and we know what we’re going to know for now.

• https://csrc.nist.gov/projects/post-quantum-cryptography
• https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF

I don’t know what he’s talking about, but maybe he’s saying that the US already has quantum computers capable of breaking modern cryptography, and that it’s time to move to Post Quantum Cryptography (PGC). The process is pretty far along:

• https://postquantum.com/industry-news/microsoft-pqc-windows/
• https://www.redhat.com/en/blog/whats-new-post-quantum-cryptography-rhel-101

Both sites mention “harvest now, decrypt later.” That’s an attack where someone could scoop up all the encrypted traffic/files/whatever, and just store it until quantum computers are effective at breaking it. Because of the nature of the topic nobody who knows for sure is going to say, but it’s not going to be cheap to replace all the crypto out there with PGC so there’s a reason to think there’s a need even if nobody will confirm anything. I personally think just the possibility of the attack is enough reason to move if the algorithms are already in place. If you’ve got encrypted data and you expected it to stay unreadable for hundreds of years, then there’s reason to think that’s not achievable right now.

https://nist.pqcrypto.org/foia/20250114/djb pqc paper.pdf

Lots of rose colored glasses being worn here.

I will take modern rust prevention tech every day all day. The control modules and circuit boards are a hole in repairablity, and there’ll be a wall where nobody makes them anymore and the specs are not published (considered proprietary/trade secret/whatever), and that whole vehicle will just have to be scrapped. The world won’t ever see the end of old body-on-frame vehicles with crate engines. Speaking for myself the “rose colored glasses” is a wish for the best of both worlds. I wouldn’t doubt it’s out there being done somewhere, but I’m sure it’s cost prohibitive to do it, or people are doing it for themselves.

Maybe I’m just complaining because I don’t personally have the time/knowledge/workspace to do what I want in that area. C’est la vie.

What kind of car?

They used to be. Go back far enough in time and you could climb up under the hood into the engine bay to work on it. All that went by the wayside to get smaller packaging, lighter weight, and better fuel efficiency.

Now you need special tools or special code readers to solve/diagnose all vehicle problems. The large scale farmers are dealing with this now with the large combines and harvesters needing a tech with special equipment to read all the codes where the older tractors from the 70s and 80s can be repaired.

Well, nothing to do but start at the first one and work our way down…

Try the c++23 standard. There’s been a lot of cross pollination. Contrived example follows:

#include <format>
#include <numbers>
#include <print>
#include <string>

int main(int argc, char *argv[]) {
    double pi = std::numbers::pi;
    std::string fstr = std::format("{}, {:>.2}, {:>.5}, {:>.10}", pi, pi, pi, pi);
    std::string h = "Hello";
    std::string w  = "World";
    std::println("{}, {}!", h, w);
    std::print("This won't have a {},", "newline");
    std::println(" but this will add it."); // Add a newline.

    // Can't put a non-constant string as the first argument to
    // print or println so they can be checked at compile time.
    std::println("{}", fstr);
    return EXIT_SUCCESS;
}