You could just use the upstream binary (alternatively, use this binary if your Python version is too old or plain C is more appealing to you).

Download that, move it to your /usr/local/bin, and then run chmod 744 on it so that it can be executed and run as a non-root user. Simply typing yt-dlp will point to that upstream binary you downloaded (by default), and when you want to check for updates, just run sudo yt-dlp -U.

Sounds like another W for AppImages. You can certainly use your package manager or compile from source, but they are nice to have for offline systems that haven't been updated in years... Or dropping them onto USB flash drives so that if you use a shared public computer with Ubuntu or Fedora, you can still use your favorite software without wondering if the distro has it available. That's the beauty of choice.

A Debian-based system could still benefit from its locally stored repositories contained in the point release ISOs, but you can also use the DEB files (as long as the dependencies resolve) to install software without the need for going online. Slackware is the only non-Debian-based distro where you can still do offline installs, as long as you have the TGZ or TXZ files. AppImages are perfect for a lot of the other distros that aren't that good with installing packages locally, such as the rolling release types.

No idea about a DM that doesn't suck eggs and swallow yolks, and couldn't care less about Wayland "usability". I just do everything from TTY, using this very antiquated command:

startx

Along with Orphaner, I think it got deprecated by Debian indefinitely, as nothing exists past Bookworm sans Sid for RISC-V. You could try to install it from Daedalus.

I just use Debfoster now.

Try enabling non-free-firmware if you haven't yet (shown example line below):

deb http://deb.devuan.org/merged/ excalibur main contrib non-free non-free-firmware

Update your repositorites, and then install the particular firmware package(s) you need. Things like firmware-iwlwifi (Intel), firmware-brcm80211 (Broadcom/Cypress 802.11), firmware-realtek (Realtek), and so on. Follow the same steps that worked for you in Debian, as they should be the same in Devuan. This respin appears to be using NetworkManager, so these firmware packages should work just fine if the hardware matches. It just depends on what your system's wireless card is for it to work. For example, I recently bought 802.11 USB wireless card adapters for my laptops that struggle to connect without one (the aforementioned firmware-brcm80211 didn't support it), and had to rely on building a driver from this repository, since none of the firmware packages I installed were working.

Why not just stick with IRC, XMPP, Mumble, Jitsi Meet, and a ton of other decentralized, privacy-respecting (as much as possible) FLOSS communication protocols?

You can definitely remove or disable Elogind itself. You might have a harder time using a computer without the libraries most "conventional" packages are built against. ConsoleKit2 and Seatd can both help out more, plus the dummy Logind package (dummy-logind) that Devuan has made available since Daedalus. Since I need incremental RSYNC backups from Timeshift and Back in Time, Polkitd must be kept. Still, it's nice to have KDE and Network Manager functioning without any issues without an existing Elogind process (again, only the libraries are kept to avoid breaking the entire system).

Eudev is still a problem. I also personally removed Udisks2 and now use Udevil for automatic USB mounting as a non-root user (you can optionally use SpaceFM as an extra safety cushion).

As of Trixie, Debian has made it harder to remove or replace ALL parts of Systemd, never mind D-Bus (which is completely impossible to rip out and still have a functional computer). Devuan simply follows Debian's steps and applies its own blacklists regarding packages that have a hard dependency on Systemd. Elogind is used in place.

The only other Debian-based distro that has gone the great lengths to remove or lessen the impacts of Systemd or Elogind would be antiX.

Mmm... Not quite.

chmod a+x /path/to/file.appimage

They will work then.

Greenjeans already clarified he didn't hardcode any of that "inaccessibility" crap, and he did say he'll look into it, simply because he wants to help. It mainly comes down to which theme you use, as Rations mentioned. Wanting to cater to the visually impaired is nice and all, but it's not "mandatory", and hardly at all the end of the world because the current theme in use made it harder for you to tell things apart. That MATE screenshot was way more evident of visual issues.

The "historical relationship" is a moot point when you're just nitpicking over a theme's color and contrast defaults. That's why you can change it. Not a big deal.

There is no one-size-fits-all theme, ever. People are still gonna complain.

@Daemonratte:

Consider using Devuan's official Git repository. That way, you ensure Micro$lop doesn't remove you for whatever reason, and your hard work isn't lost.