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.

sudo should not be used on init scripts, not directly because of security, but it is assumed not every system may had sudo installed as a minimal install with a root account and password will only have su and require running su to change into the root account to perform all administrative tasks.

that aside in a proper initscript the variable RUN_AS_USER is defined, usually as RUN_AS_USER=root for daemons intended to be ran by the root user, for daemons that need to be ran under a specific user the variable is defined with the intended user.

accordingly the start-stop-daemon program will be used to guarantee correct behaviour, ie check for initialization of instance and creation of the pid file.

an example standar use of start-stop-daemon would be as follows:

start-stop-daemon -S --pidfile ${PIDFILE} --make-pidfile --background \
            --chuid ${RUN_AS_USER} --startas ${DAEMON} -- ${DAEMON_ARGS}

as for the options straight from the manual:

-S, --start [--] arguments
           Check  for  the existence of a specified process.  If such a process exists, start-stop-daemon does nothing, and exits with error status 1 (0 if --oknodo is specified).  If such a process does not exist, it
           starts an instance, using either the executable specified by --exec or, if specified, by --startas.  Any arguments given after -- on the command line are passed unmodified to the program being started.

the flags and the vars passed should be descriptive enough and those are expected to be defined earlier on the initscript.

as for --background it is used with prgrams that will not fork to background by themselves.

if you want an okay example of a proper initscript file for an arbitrary daemon check https://github.com/eylles/afreq.sh
the file acpufreq.is is the definition of the initscrip, mind you that when you write initscript files not every daemon will support options like reloading the configuration so the route that many initscripts take is to just have the restart idiom also match reload and force-reload like so:

    restart|reload|force-reload)
        $0 stop && sleep 3 && $0 start
        ;;

took a look at the pipewire setup, left a suggestion in an issue.

honestly as sad as it may seem the devuan forum is not a good place to get feedback on software you are writing on principle of barely getting feedback for one reason or another.

in march i had to move from devuan unstable to testing because the t64 migration wasn't kind to my system and i needed some extra time running as i was, i really want to avoid a re-install but seems like that is what i will have to do.

weird i installed usrmerge back in at least march and everything works, then again i'm on ceres so maybe the usrmerge is more "volatile" on stable but still nothing has broke, as for the argument about uptimes it ain't weird when i clock about 70 days of uptime, the only thing that i've ever noticed not working is the plugin scripts of krita but i never tried using them before the usrmerge so as far as i'm concerned krita on debian is slightly broken and may as well have been forever broken.

speaking of themes, i've been playing with adw-gtk3 and how configurable it is, the styling room to adjust the radius elements and colors, with somthing i'm working to build themes to apply to adw-gtk3 and libadwaita (via gradience) and qt via kvantum there will be possible to have fully consistent themeing on linux with the small caveat that all the wdigets use the adwaita styling... which is not compact...

i mean, php is not great but calling it malware isn't a bit too much?

it doesn't help either that devuan is on a weird spot regarding eudev, eudev upstream is already on 3.2.14 and moving towards what could be 3.2.15 or 3.3.0 while we got 3.2.12 with a couple PRs from upstream merged in (#253 that adds the api from udev 247 and bumps compat to udev 251, a fix to sgx groups and fix of the walrus operator) the devuan package still lacks important PRs from upstream such as #255 that cleans the sysattr cache (important to get upower and other stuff that relies on the new api to work), and after trying to build eudev from source it ain't as trivial as it seems (doesn't help that i also need an i386 build for steam stuff) so the current options are to wait until the next release of eudev hits devuan unstable OR maintain a repo to build the devuan eudev source with the important missing commits added as patches.

nevermind, thanks Boian! https://pkginfo.devuan.org/cgi-bin/pack … v=3.2.14-1

huh, interesting how the advancement of artificial intelligence correlates with the growth of the natural human stupidity.

let's hope that AI essays break the education system so hard a real reform is finally deployed... but knowing it is a goverment run chimp cage the most likely is that they will come up with a useless method to try and ban AI written essays...

well, it works okay but i need to add checks that the values from the config file are valid before applying them, also perhaps adding a logging functionality, other than that it is okay enough.