This doesn't seem to be a Rust problem, but a modern development trend appearing in a Rust tool shipped with Cargo. The issue appears to be the way things are versioned and (reading between the lines maybe?) vendoring and/or lockfiles. Lockfiles exist in a lot of modern languages and package managers: Go has go.sum, Rust has Cargo which has Cargo.lock, Python has pip which gives a few different ways to pin versions, JavaScript has npm and yarn with lock files. I'm sure there are tons of others. I'm actually surprised this doesn't happen all the time with newer projects. Maybe it does actually and this instance just gains traction because people get to say "look Rust bad Debian doesn't like it".

This seems like a big issue if you want your code to be packaged by Debian, and it doesn't seem easy to resolve if you also want to use the modern packaging tools. I'm not actually sure how they resolve this? There are real benefits to pinning versions, but there are also real benefits to Debian's model (of controlling all the dependencies themselves, to some extent Debian is a lockfile implemented on the OS level). Seems like a tough problem and seems like it'll end up with a lot of newer tools just not being available in Debian (by that I mean just not packaged by Debian, they'll likely all run fine on Debian).

Yes for example Python implements them using semaphores.

It doesn't violate any rules.. Imagine both the "speaker" and the "text" are being updated by separate threads. A program that would eventually display the behavior in this meme is simple, and I'm a bit embarrassed to have written it because of this comment:

#include <pthread.h>
#include <stdio.h>

char* speakers[] = {
    "Alice",
    "Bob"
};
int speaker = 0;

void* change_speaker(void* arg)
{
    (void)arg;

    for (;;) {
        speaker = speaker == 0 ? 1 : 0;
    }
}

char* texts[] = {
    "Hi Bob",
    "Hi Alice, what's up?",
    "Not much Bob",
};
int text = 0;

void* change_text(void* arg)
{
    (void)arg;
    for (;;) {
        switch (text) {
        case 0:
            text = 1;
            break;
        case 1:
            text = 2;
            break;
        case 2:
            text = 0;
            break;
        }
    }
}

int main(int argc, char* argv[])
{
    pthread_t speaker_swapper, text_swapper;

    pthread_create(&text_swapper, NULL, change_text, NULL);
    pthread_create(&speaker_swapper, NULL, change_speaker, NULL);
    for (int i = 0; i < 3; ++i) {
        printf("%s: %s\n", speakers[speaker], texts[text]);
    }
}

I'm relatively qualified. Studied physics all through college and spent a couple years working in quantum computing. I'll chime in here because Schrodinger's cat jokes are a pet peeve.

You are correct that, as far as we understand, it is literally impossible. There has been a competing theory for decades, but I'm not really up on the specifics https://en.wikipedia.org/wiki/De_Broglie%E2%80%93Bohm_theory. The reason it is generally rejected is that it appears to violate relativity.

Anyway.. the cat thought experiment is such a fun thought experiment to me because it specifically makes us think about a very practical issue with respect to quantum computing: decoherence. If you take his thought experiment to an extreme, it actually should be theoretically possible to create a state in which a macroscopic object (the cat) and a quantum object (the radioactive source) are indeed entangled. But that is absurd according to everything we've ever seen. So what's up? The missing concept here is decoherence -- while this state may theoretically exist, it'd decohere on timescales so small we can't even imagine. The fun connection here is that decoherence is the exact thing we're trying to fight in quantum computing. Essentially we're trying to make this thought experiment a reality for a much less complex system.

Some more on decoherence: https://en.wikipedia.org/wiki/Quantum_decoherence

Async features in almost all popular languages are a single thread running an event loop (Go being an exception there I believe). Multi threading is still quite difficult to get right if the task isn't trivially parallelizable.

You can use udev to make a symlink with a consistent name

Good explanation but a little nit: Colorado is a very purple state. We're the home of Lauren Boebert and Focus on the Family after all.

I don't think a Republican has won the presidential vote since GW Bush here though

This has always been a weird take, what do you think attracts people to that kind of SAR work? Generally a love for the outdoors and activities like this. You'll have a hard time finding someone capable of high angle rescue that doesn't enjoy or understand climbing as a sport.

I hate getting into these discussions.

This is Arnaud Petit and Stéphanie Bodet, two professional climbers with far more experience than you. They are doing the second ascent of a 900 meter 8a on Angel Falls (Rainbow Jambaia, 31 pitches) which is about the same height as El Capitan in Yosemite National Park. Here is a story about it. You almost never plan to climb routes this long in a single day, especially not on the second ascent. They most definitely planned to sleep on the wall and brought the proper equipment. This is called big wall climbing

Just be happy for people doing what they love and do what you love: your life will be better. We're all motivated by different things.

They're just having fun

Most responsible climbers bring something with them to pack it out, but there are some irresponsible ones that do what the comment above mentioned. That is the exception, not the rule though.

They were very clear it was for research in my memory. That was the reason I did it.