zarenki

Something I've noticed that is somewhat related but tangential to your problem: The result I've always gotten from using compose files is that container names and volume names get assigned names that contain a shared prefix by default. I don't use docker and instead prefer podman but I would expect both to behave the same on this front. For example, when I have a file at nextcloud/compose.yml that looks like this:

volumes:
  nextcloud:
  db:

services:
  db:
    image: docker.io/mariadb:10.6
    ...
  app:
    image: docker.io/nextcloud
    ...

I end up with volumes named nextcloud_nextcloud and nextcloud_db, with containers named nextcloud_db and nextcloud_app, as long as neither of those services overrides this behavior by specifying a container_name. I believe this prefix probably comes from the file-level name: if there is one and the parent directory's name otherwise.

The reasons I adjust my own compose files to be different from the image maintainer's recommendation include: to accommodate the differences between podman and docker, avoiding conflicts between the exported listen ports, any host filesystem paths I want to mount in the container, and my own preferences. The only conflict I've had with other containers there is the exported port. zigbee2mqtt, nextcloud, and freshrss all suggest using port 8080 so I had to change at least two of them in order to run all three.

Likely reversing a major anti-consumer decision is nice, even if it took seven years.

Knowing that consumer protections repeatedly flip back and forth every time the executive branch switches political party, and even then only if we're lucky, is not so reassuring. What's stopping it from being repealed again in a few years?

if the featureset is not clear enough at first glance

My experience as someone who has barely dabbled in Matrix, tried comparing clients, and knows a lot of people who stick to Discord: a lot of Discord users heavily use custom emotes, voice chat, and screen sharing. It's not even easy to figure out which Matrix clients support each of those features without installing everything and trying it out. There's a clients comparison on matrix.org that mentions Voip but not stickers or video.

For stickers alone:

• Element is widely considered the go-to Matrix client but uses a strange integration system for predefined sticker packs instead of the MSC2545 stickers that more closely resemble what users coming from Discord would want.
• Cinny seems to have the best support for stickers/emotes but its site doesn't mention them at all. It supports uploading and managing sticker packs at either a channel or user level, provides a nice picker UI to send any picture from those packs as either a large "sticker" or a small inline "emoji", and allows using them for reactions.
• FluffyChat mentions stickers on its site and has the second best sticker support, with all of those except reactions and a graphical sticker picker for inline emoji (need to type them as shortcode).
• SchildiChat, Nheko, and NeoChat have some sort of limited support for custom stickers/emoji. NeoChat is the only one of those that advertises stickers on its main site. Nheko mentions them in a GitHub readme.

Being able to freely use custom emotes without paying for a Discord Nitro subscription nor server boosts would be a great selling point but it's not something most users would be able to figure out before signing up. The limited client support isn't great; e.g. Fluffy is the only Android client that supports sending custom stickers but some people may dislike the chat bubbles style UI.

Not every work environment is the same.

When I first started with my current employer I was given a system with RHEL preinstalled and I replaced it with Fedora on my first day. I was told to use LUKS and given a normal OpenVPN profile but otherwise they don't control or monitor anything about my workstation. No matter how many years or decades I stay at this company, it's extremely unlikely I'll ever touch an OS that isn't Linux-based during work time.

Every previous job I've been at also had me use Linux for my primary workstation, because my field of work more or less requires it, but some have needed me to access a separate Windows system/server/VM on rare occasions.

The readme file, gitmodules file, and other links within that repo all still reference the now-dead gitlab links. The builds don't seem to be present at all.

That will all probably be fixed soon enough but right now that mirror which seems to have just been pushed as-is isn't entirely usable.

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 passive adapters that connect to DP++ ports probably still rely on this HDMI specific driver/firmware support for these features.

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.