You should probably use the longer one, "0000:00:0d.0"

Also, if you would put listings etc in code blocks, i.e. within a pair of [code] and [/code], it'd be easier to read.

It's a bit scary to reply to this, because you've raised a fair few issues in the one breath :-)
How about splitting them up into several (is it 3 or is it 4?) threads.

As for the the last issue, "compiling without systemd", I believe a search in the
dyne.org's mailing list may bring up some discussions. That would be my first target for "FAQs in one spot"; though I wouldn't be surprised if there are more spots than one available.

Not sure what 'the standard way' means to you, but for example, the group name 'storage' is not listed at https://wiki.debian.org/SystemGroups. I suppose, that might not be normative for Devuan, since Devuan is not Debian, but to me it implies that polkit is not standard.

In any case, whether standard or not doesn't help towards your problem, which rather seems to be, how to configure udisks and/or polkit to work the way you want.

Maybe https://www.stopforumspam.com could be of some use?

I've moved this project to gitlab,  https://git.devuan.org/ralph.ronnquist/rrq.git, and included control scripts with a full setup of tun interfaces, routing and iptables rules, as an OOTB filtering solution. Though, it doesn't include block list files; I only have the ones I bought, and no free ones.

There's also an HTTP admin tool for the brave hearted.

My friend, to use "ancient" about things from some 30 or so years ago is also a way to climb the scale. In any case, I got a good answer to my question. We can meet up and discuss the rest sometime, somewhere.

Thanks.

yes :-) a while ago I thought to experiment with the C-A-f1 console, to have black text on white instead of the washed out gray on black (or sometimes dirty dark green). I then found out that those console colours are hardcoded into the kernel, in a palette of 8 named colours, with "white" conveniently naming the gray colour. This seems to have happened many years ago, but that doesn't place it lower on the stupid scale. In any case, I eventually worked out how to achieve black on actual white on the console, and that it's not worth fighting for.

btw, re (8):

I think I would consider having a separate naming script, with code like

ln -sTf adapter0  /dev/dvb/adapterPCTV290e

to be run when starting the mythtv app, or manually, rather than making it vdevd magic; especially since there might be several adapters of the same brand.

E.g., for my own TV system I have 4 receivers of the same brand, so I can't use your approach off hand. (A separate comment is that it's enough to symlink to the adapterX directory rather than symlink each "control interface" [or what it's called]) As you might know, the product name for /dev/dvb/adapterX is (currently) available at e.g.

cat /sys/class/dvb/dvbX.demux0/device/product

But, I suppose there could be a helper script improvement for this in some way.

Re USB, (7): the overall issue is that several packages have been coded to utilize udev, via the rules files, for automagic hotplug handling, and they (of course) don't include a corresponding configuration (action+helper) for utilizing vdev.  I did start on a  "udev rules"-to-"vdev conf", but stopped (apart from incorporating scanner recognition into vdev), as I rather quickly saw it leading to insanity (mine). So, this aspect is in a state of pass the bucket game, where it really should be up to those other package developers to add their hotplug configuration wrt vdev.

That leads to your pt.8, and highlights the need for more/better documentations (and tools?) of how to "program" vdev.

(sorry. right now it's too hot here to think; I'll try again in the weekend...)

I got three: firstly, this is well beyond my expertise; secondly I tend to prefer using the shift key or ctrl key to wake a sleeping computer; and thirdly, the beep-beep-beep behaviour might suggest BIOS level concerns, which perhaps could be a dead battery. But again, I'm not expert on this (and I use a laptop, with acpid lid action).