You should submit some issues for those sites with these steps - maybe they’ll add them to the list. The addon supports 453 sites at the moment by my count, so I’m sure they’d love for you to tell them about more sites that haven’t been bypassed yet.
They’re available as an option. You can source from any of Fitgirl, DODI, or KaOs if they have the game you want. Other repackers do exist and they’re all generally trustworthy, but those 3 put out a lot of content and have a good track record. ElAmigos is another good one that puts out a lot of releases.
Try this answer. I guarantee there is a way to read the file front to back while skipping errors, but I run so much data redundancy that I don’t have any experience with it.
Okay cool. I would be wary of that drive just in case, and I would definitely schedule weekly SMART short tests and monthly BTRFS scrubs on it if you go with BTRFS in the future. EXT4/XFS/etc do not have a concept of data checksums, which means they can’t scrub and check for bitrot - this might be problematic if you find that your disk starts causing bitrot because you won’t know where it’s happening.
It goes without saying but the number of errors you should get on a scrub is ideally 0. Bitrot happens from time to time which is why you should keep some data redundancy/backups so you can repair it when it’s detected, but that number seems higher than normal. Your disk may be going bad if you’re getting that many read errors; I’m not sure. I believe you’re already backing up data off this drive but yeah I would get everything important off the drive ASAP, then run a SMART short test and a SMART long test to see if that reports that anything is wrong. The disk may be fine but better to be safe than sorry.
Back to the video file, I’m assuming it was not one of the ones that BTRFS fixed automatically? The only real options for data recovery are to rescue the file minus the bad blocks with e.g. ddrescue (which I don’t personally have familiarity with) or something similar, or to encode through the errors with ffmpeg if it will let you.
To add on here, you can use the Are We Anti-Cheat Yet? site to track which games are not working due to anti-cheat. In my experience it’s extremely rare for “Linux” (aka Wine/DXVK/VKD3D/et al) to not support arbitrary games. If a game is not working on Linux it’s almost certainly because of an anti-cheat or some bloated/obscure DRM telling Linux “no you cannot run this”.
If you want NSFW on /c/all it shouldn’t take too long to block each community instead - I’ve done that to most of lemmynsfw and haven’t seen anything in a while. Scrolling /c/all in peace is really only an option because Lemmy is so new - if you browse /c/all in a year from now you’re gonna get a lot of stuff you don’t want.
Are NPCs silent when talking? If so you’ll need to install faudio into your Wine prefix with Winetricks. Running with Steam may help a little also but l don’t remember if Proton includes faudio by default.
As for the cart crashing that’s probably just Skyrim. The opening cutscene is notoriously buggy.
I no longer use Arch, but this wouldn’t have happened to me because I used vanilla Arch. On Manjaro it can happen at any moment that an AUR package silently depends on a new part of a dependency not implemented in the older versions. The AUR does not care to figure out which exact version dependencies are needed for a program, because you are expected to always have an up-to-date Arch system before installing. If the AUR cared about Manjaro compatibility they would need to mark every dependency with a minimum version number, but that’s a lot of effort and the AUR understandably doesn’t care about supporting Manjaro’s repos. If Manjaro stood up its own AUR this would no longer be a problem.
(Personally, I don’t think AUR packages are a good idea for system stability/security even on vanilla Arch, but it is understandable that people like them for their convenience.)
Arch has made a lot of mistakes, and their most recent one where they bricked everyone’s GRUB loader is the one that caused me to stop using it as a general recommendation. This sort of thing would never happen in Debian, and pretending that “every distro makes massive mistakes!” is disrespectful to distros that actually put a ton of effort into making sure these things don’t happen. Sweeping those mistakes under the rug is harmful to new users who don’t know what they’re signing up for when they download the distro that you are sugarcoating, and that is the primary reason to make sure that anyone considering Manjaro is aware of its past so they can make their own decisions.
Security updates aren’t delayed in Manjaro, they’re pushed through out of band.
Manually. Also read as: delayed. The comment from Arch’s security team that you are minimizing is part of the reason why this is a bad idea: “They just forward our security advisories without reading them. Leaving critical security issues to rot in their “stable” repositories while only pushing forward issues that are publicized or users telling them about”. Once again, why would I trust the Manjaro team to be on top of security when they can’t figure out how to keep an SSL cert alive? Their security mailing list hasn’t even been updated in a year.
Once you’ve compiled an AUR package it will remain compatible with the system you compiled it on until you update and introduce an incompatibility.
You are dodging the real dependency problem by focusing on this half. The real dependency problem is that when an AUR package updates and Manjaro’s packages are not new enough for the update, it will cause breakage. AUR packages are built with Arch Linux’s repos in mind and no care whatsoever for the versions of packages that Manjaro holds. Updating your AUR packages frequently will all but guarantee that you will eventually run an AUR update that requires a dependency with a newer version than Manjaro provides, and that app will break (or worse, the AUR package is a dependency for other apps which will cause further breakage). Even Manjaro knows this: “Using AUR also implies Arch stable branch - which is only achievable by using Manjaro unstable or testing branch.”. Also take it from their team: “The AUR is neither officially supported by Arch nor Manjaro. If you do use the AUR on Manjaro, use our unstable branch. Problem solved.”
That’s not the “Arch’s security team”, it’s one person on a 3rd party forum, with a history of issuing personal statements reeking of personal grudge. Yeah I know that comment unfortunately. It’s a singular, isolated piece of flamebait and it makes me sad to see it’s still being bookmarked and passed around 5 years later.
Yes very sad that a member of Arch’s security team made a warning about Manjaro’s security 5 years ago and still we have people pretending that it’s “flamebait” because that’s a convenient excuse to dismiss it.
The receipts that I just linked show far more than 2 mistakes. I don’t care whether they have fixed them or not, I care that they have made so many. Trust arrives on foot and leaves on horseback. Distro forks are nothing special, so why use the one with a history of bad management? Use Arch proper or any of the countless Arch forks that use the real Arch repos, which will inherently sidestep a lot of issues that Manjaro created for itself.
You say that delaying packages makes things more stable but there is a clear history of that not being the case, which has already been described in the links I posted. This is most importantly true in terms of delayed security updates. You also don’t understand how the AUR works in conjunction with outdated Manjaro packages, which will cause dependency problems and lead to breakage. This is a very simple cause and effect so I’m not sure how you think you can try to assert “everyone else must misunderstand how dependencies work”.
As for the last bit, no Arch is obviously not being hurt when Manjaro is called out. If anything I’ll bet Arch wishes Manjaro would stop tripping over itself and giving Arch a bad name. They are already sick of Manjaro users using the AUR and complaining every time it breaks their packages, and you can read what Arch’s security team thinks about Manjaro here on r/archlinux (image mirror here if you don’t want to visit that site).
That gets my normal GTK theme properly. I found a little more discussion on this here. Nothing very actionable but I did also confirm that my xdg-desktop-portal-gtk is running. It seems like this is supposed to be working, but I have a mostly stock Debian 12.1 KDE install and something seems to be wrong somewhere in the chain. I’ve also tried multiple GTK Flatpaks with the same results.
Edit: Also, I have both my themes folder exposed and the theme installed as a Flatpak via the linked script.
I do have xdg-desktop-portal-gtk on Debian Stable, which is currently at 1.14.1-1. I’ll look around to see if there’s more documentation on this method, because I would prefer to not use the debug variables if possible.
Edit: I launched with GTK_DEBUG=interactive and I can see the theme inside the Flatpak gets set to Adwaita-empty instead of my actual theme, which does get properly returned via gsettings get org.gnome.desktop.interface gtk-theme