No. I am not clickbaiting at all. Must say that very clearly. Up to You everyone understood that i was talking on a devuan based server.
And maybe one could consider that not all users here are native speakers and therefore tend to express things differently.

But there are always people who apparently feel good at misunderstanding.

This is not a company but a family's private server. With only two people knowing the password. And the root login came came from outside

BTW: a newer server initally set up as devuan chimaera or daedalus vie apt-get from a corresponding debian installation apparently has not (yet) been compromised.
But here the SSHD config did also permit root logins. Is that an issue of the, well actually not too outdated, debians or an issue of devuan? Or maybe an issue of the inital setup from the vserver provider's template?

Anyway, scanbot.me seems to be pretty well known as a phishing site which usually works through email appendices. Which rises the question if and if yes, how, the door could have been the mail server (older postfix with greylisting, no DKIM/DMARC, but otherwise thoroughly configured) in combination with recent thunderbird.

I am running claws-mail which cannot execute garbage in the emails, but the other users (ex wife and my son) use thunderbird.

Did that. Works nicely. But there are things remaining

a) the udev error messages mentioned elsewhere ... on my TODO list.
b) all the rc*d directories from sysvinit. harmless but potentially irritating. can be safely removed after activation of openrc-init and -shutdown stuff.

c) one of them causes a problem: rc.local
In Alpine that directory is used by openrc to add some fine tuning after the runlevel has completed its setup.

I need to use something like this in connection with iwd - configure an AP on wlan0, set up ip forwarding in the kernel and the appropriate firewall rule for masquerading/forwarding.
Four simple commands dependent on iwd up and running. Similar use cases come to mind, e.q. "real" firewalls.

And, honestly, i do not find an "official" place to do that cleanly in devuan (excalibur). Mhmm.

This regard not the script by itself, just the question where to establish it. (/etc/conf.d/iwd will be executed before iwd is set up)

Have been experimenting with the eqalizer a bit. Not with Your tool, just with the basics.

alsamixer -D equal will show the sliders of the EQ. Alsamixer provides keystrokes to split a stereo track and adjust the two channels seperately. More or less, here in devuan not all strokes seem to work, but anyway.

On my notebook i am using qasmixer anyway and for a few years.
quasmixer provides a field for user defined devices. Entering "equal" there shows the eualizer controls, and they are working. There does not seem to be a way to split stereo channels, but  channels that have already been split using alsamixer appear split in qasmixer as well, and they are grouped nicely. And the can be operated perfectly from that interface.
Which means that that little and well established program serves 90% of my needs.

So that kind of behavior might be what should be expected for Your little tool as well.

(in my opinion the main work should be some kind of alsa-jack-only overlay on devuan, mainly because possibly all the desktop environments and other apps pull either pulseaudio or pipewire and thus cause problems: after the upgrade to excalibur, my intentionally alsa only machine had pulled pipewire and started the daemon. Which caused audio from freetube not to work. An overlay to devuan might provide dummy packages to resolve those nasty dependencies.

For my current problem with one sided hearing loss that result is really cool: i would just need to run a mono track, adjust the bad side range by range until i hear that frequency range appearing in the center, and i'll end up with a nice overall setting. Being able to enjoy music again is *really* cool.

Another question/suggestion: optionally integrating some kind of loudnes correction? Something like https://github.com/dpapavas/alsaloudness ?

Interesting stuff,

but did You notice that ardour pulls pipewire on Excalibur (through libfluidsynth3) end even emacs nowadays does (i'm currently using mg instead, but sometimes a bit more versatility and some gui might be nice as well)?
BTW: the installed pipewire had prevented some stuff from playing audio because pipewire had made the default audio devide unavailable even when it was not running.

So today i spent some hours to clean up my notebook (initially pure alsa+quasmixer, possibly also jack).
Moreover i am setting up an XFCE based setup for my (NON-Tech) friend, and for something like that Your project will hopefully really helpful.

Mhmm the question was actually not sticking to alpine which i intend to install on a 2nd old machine (replacing chimaera) but that very specific virtuozzo instance which cannot be upgraded beyond ASCII (at least not without dirty tricks). And ASCII has already passed EOL. And that on a production server visible to the world.

I'm aware that this will affect version 3 and not the current one. Nevertheless i set audacity on hold on 4 machines (all running chimaera).

Firejail and the like is nothing for unexperienced users - simply because they do not know or will not dare to use it.

But anyway: the other affected software is musescore. Chimaera provides Musescore 2 and 3, the first due to problems regarding backward compatibility.

I would guess that version 2 is probably "clean" but version 3 ? Or will the new policie affect only recent versions? BTW: the recent android versions of musescore have already been changed - a friend of mine told me that it was unclear wether she could use it free of charge.

IMO version 2 should be prevailed as long as possible. Regardles how long it'll be maintained by Debian.

... works until the next upgrade to chimaera.

And then murphy will predict that You forget to update the release entry before doing the update.

EDIT: the mixer problem appears to be due to an incompatibility with the rests of the old installation (as far as i remember, it could have been 0.96 or even older). Which looks like a bug in hydrogen itself and not an issue with the packaging.