Is this a troll, or are we really asking if gzipped package digests are malware?
The mind boggles.

IMO your best option is to run unbound as a local caching resolver. This is what OpenBSD does, and configuration examples for such should be easy enough to adapt.
Pretty sure dnsmasq can do this as well, if you prefer it.

Did you honestly expect anyone to read that wall of barely-coherent rant, or were you just thinking aloud to yourself?
This board some days

Ed. No, wait, it's most days. Guess that's why I don't bother trying to be helpful here, far too much crazy for my taste.

IME playback issues with VAAPI/VDPAU acceleration are more often than not GPU driver bugs. It might be worth keeping an eye on backported kernels and/or drivers (why nobody bother to mention GPU vendor or driver version here?) whenever they appear for Daedalus.
I've also tracked similar accelerated decoding problems (including a hard GPU crash on amdgpu) down to mesa in the past, but that's unlikely to get updates until the next stable.

In any case, all disabling hardware decoding will really cost you is some power efficiency. Any modern CPU should be fast enough to decode [insert whatever stupid number of "K" everyone wants today] video without it.

Devuan inherits the shadow -> util-linux change to su behavior from upstream Debian as mentioned here, and the same solutions apply.

IMO, sysvinit did need to be replaced... Just not at the expense of such excessive complexity and taking over so much unrelated functionality (and freedom to interchange low-level components).
Redhat thought sysvinit needed replacing as well, systemd fitted their vision of a "modern, standardised GNU/Linux system" (and that fitted the needs of IBM and their corporate customers), so they backed it and it's developer(s) then leveraged their influence in other projects (e.g. gnome) to force adoption.

Both business customers and casual users fleeing Windows like standardisation and "modern" (i.e. faster boot, secure restricted boot, better hotplugging, and other laptop-centric) features, nothing else had the developers budget or backing that systemd had, everyone wanted to be able to ship gnome in their distro... so here we are.
We here like our GNU/Linux a flexible, customisable, freedom-respecting hacker OS we can have full control over, but those are all bad things to corporations and normie users who have been drinking the "safety" koolaid, and they have deeper pockets and a larger userbase than we.

Like it or not, GNU/Linux is not the cool little OS by nerds for nerds it used to be. There's a huge amount of money involved these days, and whoever has the money calls the shots because even FOSS developers need paying jobs.

Lutris does not and never has used the term "bottles", nor does one have to manually manage wine prefixes.
As for selecting wine/proton versions from a dropdown list... That's literally exactly how it works in the lutris runner configuration.

OTOH, If connect GOG account -> refresh list -> select game -> click "install" -> click "next" a bunch of times -> click "launch" is a "web of nonsense" to you, perhaps you are better off sticking to steams proprietary, curated, walled garden of not-thinking-too-hard...

If this was used as "expanded storage" on a modern android device (and I expect it was by the [android_expand] partition type), it's almost certainly encrypted.
I'm not familiar with that particular device (nor do I remember in exactly which android version this changed), but encrypting user data storage has been the default for some time now, and unless you explicitly set up the device otherwise a card used for "expanded storage" qualifies.
If it was formatted as removable, it should just be a normal exFAT filesystem.

Many projects automate this with a "janitor" bot, e.g.

Might not be a terrible idea to implement something similar for the Devuan bugtracker.

The most available resource for initial investigation of a bug only you have encountered is... You.

You appear to want want somebody else to take responsibility for this, yet you have so far:
* Reported it to a team that is not directly responsible for the component in question, with minimal information, no reproduction steps, and no logs or debug output.
* Tried to divert discussion and tracking away from the official channels (bugtracker & mailing lists) to a user forum (which few developers frequent).
* Failed to follow up when asked to reproduce the problem with an untainted kernel (taint disables kernel debugging), or engage on the bugtracker at all beyond the initial report. (hint: replies to the bugtracker mail people who might care, forum posts do not)
* Continually stated a "suspicion" that this is a software problem that "somebody" should investigate, yet focused your own cursory "investigation" entirely on hardware.

Why exactly do you expect the Devuan developers, of all people, to work on reproducing a "bug" you "suspect" you have found, when you yourself are apparently unwilling to do the same? Do you want them to feed and burp you as well?

It is not at all uncommon, regardless of the size of a project, for a bug report to remain that - just a report - until either the reporter or somebody else with the same problem provides enough information to reproduce the issue. Developers are not psychic, and what cannot be seen cannot be fixed.
Only then can it move to [confirmed] and work on finding the cause begin.

* OS-prober and avahi have nothing whatsoever to do with each other.
* If something as benign as mdns service discovery (avahi) "crashes" a network, that's the network admins problem. Likewise if their printers are discoverable on public wifi when they shouldn't be.
* Don't claim "bug" in a piece of software (or OS) unless you come with enough information and reproduction steps to identify it as such. One anecdote (and probably completely coincidental) is not even remotely that.

Again, there is no "cable" that will convert USB to analog video + audio. They are completely different signals, and would require a non-trivial interface device, the equivalent of an external video card + video converter (as modern video cards no longer have analog out), and sound card. Such devices do exist, but they're a long way from "a connecting cable".

Converting HDMI, displayport or either of those running over USB-C "alternate mode" to analog video is easier, as you only need the analog encoder. A cursory search search indicates such devices are readily available and relatively cheap... But until one falls out of the sky for me to play with, I have no Idea WRT to compatibility or configuration.
You'd also need an HDMI, displayport or modern USB-C port to use with it, obviously.

FWIW, video out from a USB-C port isn't really USB at all, it's effectively just repurposing the USB connector for HDMI digital video (one of the reasons USB-C has 24 pins, vs 4 for USB A & B). Getting analog video from that is still not a simple "connecting cable", but it's closer.
Have a look at the Alternate Mode protocol support matrix table here, you want "Component video". Note that all those entries specify "construction" as "active"... Anything labeled as an "active" cable is far more than just a cable, and implies a converter of some kind.

Then I suggest you use it, that's exactly what it's for. Why bugger about with any of this when you already have the right electrical signal, the right video format, and the right connector already present?