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?

There is no "magic protection" here, security is both an ongoing process and a matter of understanding what it is you are doing. SSH encryption extends between SSH client and SSH server, nothing more and nothing less. Likewise SSH authentication.

An SSH tunnel is exactly what the name implies, encapsulating and tunnelling other arbitrary TCP traffic through an SSH connection, where it benefits from whatever encryption your SSH session is using.
This is very useful for protecting unencrypted traffic over the open 'net (or as an ad-hoc "VPN"), but of questionable benefit on a trusted LAN. Operative word there is of course "trusted". If your LAN is not secure, you likely have bigger fish to fry... Such as isolating (or better, disposing of) internet-of-trash devices, and putting guest wireless connections on a restricted VLAN and/or dedicated access point.

In your scenario, the VNC client (remmina or whatever) makes an unencrypted VNC connection to port 5901 on localhost, where your SSH client is listening. SSH tunnels the connection inside it's encrypted channel to the remote machine, where the SSH server forwards it (unencrypted) to whatever is listening on the remote machine's port 5901 - in this case qemu's built-in VNC server.
Anything relating to the security of qemu (and it's VNC server) or the VM it is running is out of SSH's influence. It's simply passing network traffic from one machine to another.

Bear in mind that if the SSH server on the VM host can make a VNC connection to qemu, so can other processes or users on that machine.
You will still need to ensure the VNC server is configured to listen only on localhost and/or firewalled, and it has some kind of authentication enabled.
Local connections between processes (i.e. VNC client -> SSH client, SSH server -> qemu) are generally safe without any encryption, as they never leave the machine anyway. That said, if someone else has root on the server (i.e. it's not yours), all bets are off.

Welcome to Debian Stable (or more accurately, a distro with almost 1:1 tracking of the same).
Not having the latest SNS in the stable repos is not a bug, it's a feature. If a rolling-release with rapid updates is what you want, run a rolling release.

dd is simple, but it's also pretty slow as it'll copy everything, including empty blocks.

There's no need for a live distro here, regardless of the method used.
Just make the windows partition is not mounted and you can do it from Devuan (as the OP requested). dd is of course available by default, and partimage and clonezilla (which includes partimage) are in the repos.

$ cat /etc/devuan_version ; free -m
chimaera
               total        used        free      shared  buff/cache   available
Mem:          128887      102819       21226          61        4841       24548
Swap:          16383         179       16204

And this box doesn't even run a GUI

I will never understand this constant obsessing over memory, it's like some kind of religion here.

I have, and it has been. My question, i.e. are bugs in backports handled separately as they are in debian, appears to be answered by stint of said bug report being accepted.
It would still be nice if this was clearly explained on the bug reporting section of the devuan site.

That it was fixed so quickly is great. Logging being screwed up on multiple machines for multiple months before I noticed this, and me (who is not a package maintainer) being the only one who did... That isn't great at all.

I am well aware of it. Awareness does not make it any less of a problem when such borkage continues to slip through.

It happens in Devuan far more often than it does in Debian, and in far sillier ways.

You can take my word as: I am getting ever closer to migrating systems that I need to work reliably, without the intrusion of random "oops" class bugs in critical packages, over to Slackware or FreeBSD.

Apparently, Devuan derives from Debian and Veteran Unix Administrators... I took this to mean that the distro would cater to administrators (who, ya know, administer things, like production servers), and inherit the stability and reliabilty of Debian... Rather than turn into another hobby distro for anti-conformist tinkerers with old laptops.
I appear to be mistaken, if the apparent focus on desktop customisation and the attitude I see from many people here have any bearing on things.

As for my bug-tracking skills... That's kinda my point. If my relatively meagre expertise and attention are all that stands between Devuan and undetected broken packages in the repos, we have problems. How am I the only one to have noticed this, in rsyslog of all things?

I need some level of confidence that I can run headless servers, with unattended upgrades, and not have them break unexpectedly because somebody forgot to change the distro name in a default config or misplaced a patch in a shipping package version.
I especially need them not to stay broken through multiple updates - as happened here until I pointed out the borked script.

Hell, I don't have something as important as system logging go tits-up with a routine upgrade even on my bleeding-edge Gentoo desktop. If Devuan can't match the rollingist of roll-your-own rolling-release distros in terms of core package QA, I really don't know what purpose it serves.

What are we trying to achieve here anyway, Debian without the init upheaval or Debian without the stability and reliability?
Maybe FreeBSD is the answer after all.

Yeah, it's just the chimaera-backports package. Dog knows how that happened considering the backports are from daedalus to begin with.