I wasn't sure if it was a joke and I read another comment here that seemed to indicate that it was not. Thanks for clearing that up, unfortunately sarcasm is easily lost across the internet.
Depends on your use case. Manjaro is in the unique position of having such a poor management track record, that almost any other Arch derivative (or, you know.. Arch) is preferable. They've let their SSL certificate expire for the 7th time just last week I think? I honestly haven't kept count, but it happened at least a few times. If it works for you, that's fine. I imagine most reasonable people don't really care. I personally dislike Manjaro for their poor track record managing their repositories or SSL certificates, their historically stupid approach to the AUR and the generally negative effect it had on Arch linux (tech support). Honestly I think Manjaro benefits most from its popularity in the tech influencer spheres and the fact that most of its userbase doesn't seem to question if a rolling release model actually makes sense for their use case.
If the graphical fidelity and the animations in the trailer are actually in-game, then I suspect we've already seen at least half of the Pokémon that will be available, in this trailer.
I mean, yeah that would be my solution. I get that the AUR is attractive, precisely because it has a low barrier for anyone to submit their PKGBUILD. The level of oversight and verification is just a bit too low to recommend it to an average user, without a lot of caution. You've mentioned some alternatives that fall on different points along the spectrum of delivering software. Something like flatpak is a much more reliable tool in the hands of someone who just wants a GUI app and not think about how it gets to their desktop. For everything else that isn't part of your distros repositories, there's really not a good noob-friendly solution that doesn't carry a big potential risk. Most distros have third-party repositories that use the same underlying tools to deliver software, but are less strict about QA and stuff. This is kind of a bad fit for rolling release distros in my opinion and is probably one of the reasons the AUR is so hands-off and DIY oriented.
There's probably a better way to handle this, but I don't think it's an easy thing to solve (especially for the rolling release model) and the AUR isn't really appropriate for mass-consumption by average users. Also, there will always be a certain point beyond which you're on your own, it's just not feasible to have reliable, safe, distro-agnostic packaging for every piece of software out there.
All official resources, Arch maintainers and high quality guides have been putting a ton of effort into teaching people how to use the AUR safely. That hasn't stopped some people, even back before Arch got really popular, but you can't reach everyone. Alternative package managers and pacman wrappers made the AUR a lot more accessible, which isn't necessarily a bad thing, but there are good reasons for all the caution. Combine that with Arch increasing in popularity and getting picked up by all the shitty influencers and you get a lot of people ,who don't know what they're doing, installing everything from the AUR with their CLI/GUI of choice. Then you've got Arch derivatives making AUR packages easily accessible from the start, bad advice on places like reddit etc.
Long story short: it seems that over the years whenever I check in, users that barely know how it works are happily installing random shit from random people on the AUR because they saw it in a YT video or something.
The AUR is a great resource but it's also being sold as a package repository users don't need to actively think about or understand. I honestly think malware is going to be much more common on the AUR if we aren't careful.
The US spends a shit-ton of money on sports... as long as it's basketball, baseball, football or soccer. Stadium construction for those sports is breaking records in the US and all of those projects are heavily subsidized. It's a giant, capitalist industry and as such it is propped up by tax money, lol.
I'd be fine with it, but I had to pin the flatpak to an old release for now, because the redesign fucked up the migration, deleted all my presets and also caused issues with voice chat apps not getting any audio input. The new UI is also unquestionably a downgrade and less accessible when it comes to setting slider values, but I hope that can be fixed with time. I certainly don't blame FOSS devs for their work.
Btw. seeing some of the comments in here: is it the fate of all Linux shitposting forums to be filled with hardliners who really care what software you install on you Linux system? Let me use my GTK apps in peace. I don't need opinions on UI cleanliness and density from people who don't even use easyeffects, because my god, is it a mess currently.
Being able to own a car without a license probably isn't the main cause behind the rise in these statistics. At least I'm not convinced that requiring a DL to own one will do any good. Many countries don't require a license to own or even register a car and have far better traffic accident statistics.
At least in Germany, most unlicensed drivers are just the ones that continue driving after having their license revoked, which explains why they are a big source of accidents. This also means however, that most of them have completed their driver training at least once. From what I'm reading it sounds like in NY, administrative chaos during covid has caused some people to just not get a license at all? If so, then the most obvious solution to me is lowering administrative hurdles for getting a license. In car-dependent places like the US and Germany, it's very difficult to prevent people from driving a car at all. So, why not focus instead on making sure the people who need to drive can get a license?
If anything, post-war occupation and the close relationship with the US in the decades to follow have done more to shape this particular aspect of German foreign policy. Ironically, you'll probably find more people who obviously haven't learned from the second world war outside of Germany, particularly in the USA. You can criticise Germany for many things, but certainly not for actually confronting the past.
It only checks mirror latency every transaction if you enable "fastestmirror". Repositories are only synced if the local cache is out of date or the metadata timestamp has changed. There might be a way to prevent dnf from refreshing repository metadata at all, but I really don't think that's a good idea.
In my experience, dnf has pretty good mirror selection by default. Setting "fastestmirror=true" replaces the more complex mirrormanager2 heuristic, which tries to select an appropriate mirror by available bandwidth, with a simple latency check that runs before transactions. In most cases this has no effect or worsens dnfs performance. They changed the description in dnf5 to better reflect the behaviour.
Having said that, it's worth giving a try in a case like this. I just want to make sure that people realize that there is a reason this was never enabled by default, since this is a popular configuration tweak suggested all over the internet, whose actual function very few seem to know.
I wasn't sure if it was a joke and I read another comment here that seemed to indicate that it was not. Thanks for clearing that up, unfortunately sarcasm is easily lost across the internet.