i've looked some times at the power profiles daemon, if you think it will do the job you want just feed the systemd unit to https://github.com/RosstheRoss/sysd2v and it will output an init-d-script style initscript, you can read more about that framework with man 5 init-d-script

speaking of the power profiles daemon you do have to "manually" change which power profile you want to use, i personally much prefer something more automatic  since i do not like to be thinking about what "profile" i want as i usually want my laptop to respond to
A) power source state, ie: is it running on battery or the AC adapter is connected.
B) the load on the system, the more cpu demanding some task is the higher performance options i want.

for that matter i considered rolling an initscript to use https://github.com/AdnanHodzic/auto-cpufreq but after reading the code it does additional stuff that i don't need and is running on a python interpreter which is not lightweight to say... so i ended up rolling out my own solution which is a very lightweight shellscript that only makes use of very few utilities not to mention can react to the usage of the gamemoderun tool which i use for prioritizing games over other processes when gaming, finally my solution does set some of kernel tunables wihch auto-cpufreq doesn't even touch (tho TLP does set some from what i've seen).
you can grab the latest release tarball from the releases section https://github.com/eylles/afreq.sh and install with a simple sudo make install install-sysv , the daemon is highly configurable tho i have not made a manpage yet, neither does it support pstates for intel or amd tho it is on my list to implement support for those.

okay this is now released software

https://github.com/eylles/zram-service

now i just have to see if i can get it packaged on debian...

still the split to the /usr was something that happened due to technical limitations and turning the /usr sub directories into symlinks should have happened since the time that ext4 became a thing.

then again there are some interesting distros out there like gobo linux that don't even care about the "traditional" unix directory layout as gobo can install multiple concurrent versions of a program by having the program versions in their own directories and only symlink the latest libraries and program versions to the "canonical" file names and locations while the other versions may have their own library versions redirected inside their environment.

to explain it is similar to the mechanism that debian already uses with the linux kernel where you can have multiple kernel version and only the latest version installed is linked to the "canonical" location.

to give a more concrete example, gobo with multiple bash versions:

/Programs/bash/
/Programs/bash/5.2.32/usr/bin/bash
/Programs/bash/4.5.11/usr/bin/bash
/Programs/bash/4.0.2/usr/bin/bash

ls -l /usr/bin
/usr/bin -> /bin

ls -l /usr/bin/bash
/usr/bin/bash -> /Programs/bash/5.2.32/usr/bin/bash

which is not only a neat thing but may even be possible to do something similar with apt but that would probably require a fork of dpkg and a lot of scripting for the symlinks.

usrmerge is not the end of the world tho there are valid critiscisms on the way it is implemented, mainly that the decision was taken to just symlink the directories without consulting with the author of dpkg and how that impacted dpkg, as it may lead to some issues (big may, so far i have not experienced any but could) not to mention taking that decision the way it was taken put a lot more pressure on the dpkg author to figure a way to support the usrmerge scheme fast and without potentially impacting packages, tho a situation arose where packages built for usrmerge systems would not work on non usrmerge systems due to autotools resolving the destination paths in a different manner, personally i do see the benefit of the usrmerge as there is no longer a good reason to make the separation of the directories and it is more compatible with very legacy stuff that had binaries in the "wrong" directory for one reason or another.

daemon is on the repos and i will say is a good solution all things considered.

regardless i'm still working on this: https://github.com/eylles/shed with the goal of perhaps having a release this month.

there are 2 alternatives that ARE in debian and devuan without messing with outdated packages.

one is to use an askpass frontend for sudo, sudo with the -A flag will launch a helper program to get the user password, i've seen even rofi used for that purpose (mind you the author recomends to NOT use rofi for sudo askpass) but a good package for that is ssh-askpass-gnome (gtk frontend), then simply put this line on your .profile export SUDO_ASKPASS="/usr/bin/ssh-askpass"

two is to use pkexec with some polkit authentication agent, most desktop environments have their own polkit agent autostarted but if your's doesn't or you use a window manager then the package policykit-1-gnome provides a gtk polkit auth agent, the autostart desktop file specifies it as gnome only iirc, but you can add your own autostart entry in ~/.config/autostart or simply run /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 somewhere in your .xsession.

the package is on unstable, https://tracker.debian.org/pkg/scrcpy

with elogind you should not need sudo to run loginctl hibernate, tho nowadays i use suspend-then-hibernate, and configure logind so that 30 minutes after suspend-then-hibernate the laptop shuts down for hibernation, i find that more useful than either suspend or hibernate as if it is on StH for less than 30 mins i get practically instant resume, but for more than that it saves battery.

what is the problem? it should add just like any other repo, if it is for the part of the script where it uses lsb_release just use the debian suite name i guess.

well, necroposting side, it doesn't seem like there would be complication to the plan of using the systemd sources to build an 'egummyboot' after rolling a shim that provides the functionality of kernel install, at least so long as the upstream systemd-boot does NOT integrate the libraries and utilities of systemd more into it's own code beyond the level of simply calling their named binaries for the function, tho still i will say for as simple as that seems it almost feels like there's a foot gun waiting to happen there...

i do personally use pipewire and it works for what i do, which is using software that relies on pulse while using software that relies on jack, last i checked that was still a set of hoops to jump with pulse and jack, but since pipewire can provide the interfaces for both pulse and jack from the same daemon it is just a matter of simply running any DAW or plugboard and it just works.