Only looked at the Cargo.toml files.

• (pet peeve) Considering there is (presumably) no compatibility concerns, why not use an efficient binary format instead of JSON?
• Not checking in Cargo.lock files, and using = dependency versions for Phoenix_Desktop, is a bit odd!

man 7 hier is much older than linux itself. The 1994 start date in the article is not doing the history of the tradition justice.

It would have been weirder if the creepy “init system” (with its 58 executables and counting, 52 + 6 arg0 links) dictating the future of that tradition didn’t raise some eye brows.

What’s wrong with it

• It’s a random crate no one uses.
• You’re not even really “using” it. You are just importing a re-export of reqwest, which is what I expected you to immediately notice after I brought it into attention. You can obviously just remove it and use reqwest directly.
• Still, trusting a re-export is not a trivial matter. The random author of the no-name crate could replace the original reqwest with something malicious, or bad in some other way, in a v0.1.1 release. That (theoretical) release will be picked up after a cargo update call, or when Cargo.lock is not checked, which is the case by default with libraries.

How did you find that crate?
Why do you think you need it?

Can you explain the rust-fetch dependency?

Why Peter Thiel though?

It was a (failed) joke about your user-name.

How much “vibe coding” is involved?

And are you Peter Thiel by any chance 😉

Thought it was on my end.

Change your mirror!

I’ve been using the repos relatively frequently, and never noticed anything.

I also just tested my mirror of choice with a random big package.

https://mirror.dogado.de/archlinux/extra/os/x86_64/libreoffice-still-24.8.7-5-x86_64.pkg.tar.zst

All good!

reflector uses https://archlinux.org/mirrors/status/json/ to get mirror status info, and caches it under ~/.cache/Reflector/. So as long as that end-point works, reflector should work.

I just grabbed a copy and pasted it at http://0x0.st/Ki3Y.json.

Anyone can grab that JSON data and use file:// URLs so they are never out. e.g.

curl -L https://archlinux.org/mirrors/status/json/ > /tmp/mirror_status.json
# or if down, use pasted json
curl -L http://0x0.st/Ki3Y.json > /tmp/mirror_status.json
# and then
reflector --url file:///tmp/mirror_status.json ...

But, as you noted, this has been mostly a nothing-burger from a user perspective anyway. Other than the homepage being unavailable on occasion, everything else has been mostly available just fine as you can see from https://status.archlinux.org/.

I didn’t notice https://gitlab.archlinux.org/ going down either.

BTW, and as a general rule of thumb, NEVER take specific technical advice from these editors. They don’t actually know much, and this is me trying to be nice.

Take for example:

For AUR disruptions, it’s a bit of a pain if you’re not a regular git user, but you cloned packages directly from the GitHub Arch Linux mirror. To do this, use the command:

See that link ;) At least he got the command below it correctly, somehow.

You are in a thread where a user is having a problem because of the push for flatpaks, and because of some distros like Fedora crippling their packages and providing objectively worse alternatives on purpose (because they don’t want to risk RH IBM getting sued). If the user was using some sane community distro like Arch, the user would have never come to realize that such unnecessary issues even exist.

As for flatpak hate specifically, see my ramblings here.

Users are better off using a “freeworld” ffmpeg package, or not using Fedora at all. The cisco decoder is shit.

your life will be better if you stop using both flatpaks and openh264.