evaluate CPU/power usage of unattended upgrades
after running unattended-upgrades for a while everywhere now, one has to wonder how well it works! in general, we've had some issues with packages updating and breaking (i'm looking at you grub), and restarts breaking things (i'm looking at you needrestart and open vswitch!), but otherwise it seems to work okay...
... but does it!?
on my laptop, i run debian bookworm, and i have found that it is much slower at resolving dependencies on large upgrades (say a couple hundred packages, which can definitely happen when you follow testing/unstable). and by slower I mean "it's taking a long time just resolving the dep tree or decision tree or whatever that thing is doing, while apt upgrade
does the equivalent in an instant".
so i wonder if we're not wasting a microton of CPU usage (and therefore power and therefore destroying civilzation) because of this possible flaw.
because we've instrumented per-service metrics elsewhere (i'm looking at you postgresql), i figured we might be able to do something similar, which could help the entire community and, ultimately, possibly save us some resources as well.
the end goal here is that maybe we'd switch away from u-u, either when running testing or altogether. alternatives range from "just write your own damn systemd service" to "oh, is cronapt still around? that was cute"