zarenki

That's actually a choice you're offered during Debian's interactive install. When you're offered the option to set a root password, if you leave it empty the system will disable direct root login and instead give your first normal user sudo access.

Debian. I was in a similar boat to OP and just a couple weeks ago migrated my almost 8-year-old home server setup from Ubuntu LTS to Debian Stable. Decided to finally move away from Ubuntu because I never cared for snap (had to keep removing it with every upgrade) and gradually gained a few smaller issues with Ubuntu. Seems good to me so far.

I considered RHEL/Rocky but decided against them largely because I wanted btrfs for my rootfs, which their stock kernel doesn't have, though I use a few Red Hat developed tools like podman and cockpit. Fedora Server and the like have too fast a release lifecycle for my liking, though I use Fedora for my desktop. That left Debian as the one remaining obvious choice.

I also briefly considered throwing a Debian VM into TrueNAS Scale, since I also use this system as a ZFS NAS, but setting that up felt like I was fighting against the "appliance" nature of what TrueNAS tries to be.

Every single other browser is Chromium.

One exception I'm aware of: GNOME Web (aka epiphany-browser) uses WebKitGTK, which is based on Apple's WebKit rather than Google's Chromium/Blink. But it's Linux desktops first and foremost. Not on mobile platforms, not exactly intended for Windows (might be usable with Cygwin/WSL) or macOS (seems to be on MacPorts) either, and even on non-GNOME desktops like KDE it might seem a bit out of place.

I daily drive Firefox but Epiphany is my first choice fallback on the rare occasion I encounter a site that's broken on Firefox.

The main reason people use Fandom in the first place is the free hosting. Whether you use MediaWiki or any other wiki software, paying for the server resources to host your own instance and taking the time to manage it is still a tall hurdle for many communities. There already are plenty of MediaWiki instances for specific interests that aren't affected by Fandom's problems.

Even so, federation tends to foster a culture of more self-hosting and less centralization, encouraging more people who have the means to host to do so, though I'm not sure how applicable that effect would be to wikis.

There's one more repo worth archiving that isn't included in this, was taken down at the same time as the others, is needed to build yuzu, and is a submodule in yuzu, yuzu-android, and yuzu-mainline: https://github.com/merryhime/dynarmic.git

I found one copy of it at https://github.com/ihaveamac/dynarmic

Most other submodules are from huge projects with no real risk of vanishing (mozilla, khronos, libusb, etc.), but a few others that might be worth noting (all still online in github) include: merryhime/oaknut, bylaws/libadrenotools, and lat9nq/tzdb_to_nx

I just uploaded a mirror of the wiki to https://codeberg.org/zarenki/yuzu-wiki/src/branch/master/Building-for-Linux.md

Downloaded it a week ago, so might not be the most recent change.

The passive adapters that connect to DP++ ports probably still rely on this HDMI specific driver/firmware support for these features.

Ethically, I agree with you. More than that, using a lockpick on a lock you bought shouldn't make you a thief. Unfortunately, DMCA has abysmal anti-circumvention measures that make the legality of using a device you own in ways you should be able to become questionable under US law, in the digital equivalent of Master Lock suing you for picking a lock you bought from them.

instructing users how to extract the prod.keys from their own switch

Yuzu's quick start guide links to the old download link for Lockpick RCM from the same repo that is still inaccessible ever since Nintendo's DMCA takedown last year (source: arstechnica). They never updated the page to link to any mirrors of Lockpick RCM or any other options to extract the keys; the guide doesn't even work right now. You can see in Yuzu site's changelog on github that the only changes made to that page in the last year are to minimum/recommended hardware requirements.

It seems even more absurd to argue that instructions are somehow infringing when the allegedly infringing part of them has already been broken for almost a year. Even the standing for taking down Lockpick RCM in the first place seems questionable, and telling users to use it with a broken link seems several layers further detached from that.

If you're assuming "as long as the hardware will function" in the first place: even digital copies, DLC, and updates installed on the system before the servers shutdown will continue working even without hacks. There's no check-in requirement except for the subscription-locked things like SNES games.

However, the result of a nonrepairable hardware failure when you have no hacks nor official servers is rather bad no matter how your games are obtained: OFW does not allow you to transfer save data from one system to another without going through Nintendo servers and a vast majority of cartridge games are incomplete without updates or DLC.

I never liked to play DS games on 3DS because of the blurry screen: DS games run at a 256x192 resolution while the 3DS screens stretch that out to 320x240. Non integer factor scaling at such low resolutions is incredibly noticeable.

DSi (and XL) similarly can be softmodded with nothing but an SD card, though using a DS Lite instead with a flashcart can enable GBA-Slot features in certain DS games including Pokemon.

If you're planning to subscribe to Proton Unlimited or Proton Family regardless, you might as well try Proton Drive. They try to be fairly privacy focused similar to Proton's other products.

Mega has a similar privacy-oriented design. Such that the server side shouldn't have direct access to your unencrypted file data or its decryption keys.

Still, any web-based service necessitates trusting the JavaScript you receive not to leak out your password or keys. Both Proton and Mega have a good track record so far in that regard, but the best practice for privacy with raw data storage is to encrypt your own data with local tools and treat any remote server as untrusted.