if you don't like where linux is headed then write software to help prevent that path or at the very least keep the existing path running

the madness of initscripts was/is that they allow for daemons to have subpar behaviour that is abstracted from the init system, and systemd was "sold" as the solution as it could handle some of those badly behaved daemons that needed complex initscripts which were "hard to debug", but developers managed to defeat that idea and re-invent initscripts in a worse language. here's an extract from a conversation i had on this a while ago, should probably put it in my github along other stuff from my vimwiki or use some static site generator to make a blog of sorts

in the unix world we have services and daemons, while many equate "services" with running a web server (or ftp server, or ssh server) of some sort, a "service" in the unix world is not a web server, but just a process that is managed, started, stopped and maybe even monitored by another process.
a daemon is a "long running process", could be one that runs for as long as a user is logged in or for a long as the computer is on, but in spite of daemons mostly being services, they aren't always services, and services aren't always necessarely daemons
there are 2 basic types of services from which all others are but variations of:

daemon: the most basic type of service as it is just a daemon that will run, it can run for multiple runlevels or it can run for as long as a user is logged in, it has a process identification digit (PID), a PID file, it runs with the priviledges of some user, the PID file can be used to monitor the service.

oneshot: a process that will be ran and not linger nor have a PID, it will run, do something and then terminate, maybe with an exit status, whatever command is ran to "start" the service can have a "stop" counterpart, or not.

the "traditional" manner to handle that madness was with initscripts, which are nothing more than just shell scripts that can accept the "start", "stop", "status", "restart" and optionally the "reload" and "force-reload" arguments, the init system needs not to know how the initscript handles those as whatever madness and witchcraft is needed to get the service running is done in the initscript
most inits use the initscript or a similar paradigm of abstracting the sorcery from the init system

systemd has the units system, the paradigm is that the madness is not necessary to abstract from systemd and can be thrown into the multiple options of the systemd unit so long as the systemd unit options can handle said madness... the main options are:
ExecStartPre=
ExecStart=
ExecStartPost=
ExecStopPre=
ExecStop=
ExecStopPost=
ExecReloadPre=
ExecReload=
ExecReloadPost=

now there is nothing bad with those, systemd allows you to just write commands in there and it will evaluate said commands to run them
and then ya got stuff like this, because systemd had to allow multi line commands in some way, and what better and more natural way than to do so with shell style line breaks
ExecReload=busctl call org.freedesktop.DBus \
        /org/freedesktop/DBus org.freedesktop.DBus \
        ReloadConfig
until now there is nothing bad in how units are defined
but that applies for simple commands
the problem starts when people start to abuse the systemd units and treat them like a fully fledged shell-like scripting language just because the documentation says you can throw some madness into the unit file
and you wound up with systemd unit files which are over 50 lines long where at least 40 of those lines are some Exec*Pre/Exec*Post command that juggles values to and from tmp files...

at that point it is just re-inventing initscripts but with a way worse "scripting" language that only got support for a form of conditionals in version 243...
and then someone comes in with some sense to put all that madness of pre and post exec commands inside scripts...
which was what the paradigm that systemd was trying to prevent from happening in the first place because "initscripts are hard to debug" (if you don't know bash)

so the proper way would be to split the initscript to multiple scripts handling start, stop, restart etc. respectively and the define then unit using these scripts?

not really, the "proper" way would be that services should not need much wizardry to be started and stopped, but since that ain't happening... then the less bad way would be to have a (or multiple) script(s) to handle the madness needed by the service and then let both .service unit files and initscripts for whatever init needs them be "dumb" files that deal only with an abstracted and simple interface with a predictable behaviour

yes, apt-get is intended to be the stable APT interface intended to be used in scripts while apt is understood to be the interactive friendly and ever changing interface.

i liked your metadata viewer but did some modifications

#!/bin/sh

# Name: metaview
# Copyleft: greenjeans 2025, use as you see fit.
# This script when combined with a .desktop file, 
# is to give you a "view metadata" option for a given file 
# when you right click on audio/video files in the file manager.
# Depends: ffmpeg, yad, libimage-exiftool-perl

c=0
sep="_"
separator="$sep"
while [ "$c" -lt 80 ]; do
    separator="${separator}${sep}"
    c=$(( c + 1 ))
done

# basename? we don't need that!
filename="${1##*/}"

thumbnail="preview-file"

encode_thumbnail () {
    filepath=$(realpath "$1")
    # ah perl, what would we do without ya and what can we do with ya...
    perl -MURI::file -MDigest::MD5=md5_hex \
        -e 'printf "%s.png\n", md5_hex(URI::file->new(shift))' "$filepath"
}

find_thumbnail () {
    thumbdir="${XDG_CACHE_HOME:-$HOME/.cache}/thumbnails/normal"
    thumbpath=$(encode_thumbnail "$1")
    thumbpath="$thumbdir/$thumbpath"
    if [ -r "$thumbpath" ]; then
        thumbnail="$thumbpath"
    fi
}

find_thumbnail "$1"

# no idea if this will work on a multi-display setup
geometry=$(xdpyinfo | grep 'dimensions:' | cut -d' ' -f7)
w="${geometry%x*}"
h="${geometry#*x}"
w=$(( w - 400 ))
h=$(( h - 200 ))

{
  printf '\n---- %s ----\n' "Metadata for $filename"
  printf '\n%s\n\n' "$separator"
  printf '\n---- %s ----\n' "FFprobe"
  ffprobe -hide_banner "$1" 2>&1
  printf '\n%s\n\n' "$separator"
  exiftool -a -u -g1 "$1"
} | yad \
    --text-info --borders=10 --title="Metadata" --width="$w" --height="$h" \
    --center --window-icon=preview-file --image="$thumbnail" --margins=10 \
    --button=gtk-close:0

the changes are:
make the underline separators 80 columns wide
show the thumbnail of the file if it exists
make the window size depend on the display geometr

he is become browser, the viewer of websites

not every "keyring" is the same type, this stems from the miss labeling of keyring packages

the debian and devuan keyrings would be the "true" keyrings as those contains the keys to authenticate the packages in fact come from debian or devuan

the gnome keyring is misslabeled as it should be the gnome-keyring-daemon, what it does is store your passwords and secrets, provide the dbus interface so that other programs can use the passwords and secrets (so that for example upon login your browser does not ask for your local user password to unlock it's password store and allow you to login onto websites), it also implements the gpg and ssh agents to load the user keys and ask for passphrases only when needed, so for example if you are staging a commit with git and want to sign the commit with a gpg key, the gnome keyring daemon loads the key so that you don't need to enter the key's passphrase every time, then when you push that commit, if you do it through ssh the keyring daemon loads the ssh key so that you don't have to enter the passphrase for that one too

as for replacing the gnome keyring daemon with keepass, you need to install a plugin because that functionality is not part of the main keepassxc program, the pass passoword manager also has a similar plugin https://github.com/mdellweg/pass_secret_service

personally i use bitwarden as my password manager so the gnome keyring daemon is what integrates the best with my environment, if i was invested with either pass or keepassxc then i'd consider replacing functionality of the keyring daemon with plugins for either of those.

yes, shed is pretty much a "per user session" sysvinit-like program, that is what i took as a base when i wrote it or well rather my understanding of how sysvinit works is what served as the base for shed tho that is the long term goal for now it is gearing more towards being a generic session process that can provide the debian x-session-manager spec, that is why i wrote about the problems with a fully shell script written service manager as with shed i am stuck in the refactoring purgatory planning multiple refactorings of various functions, a pair of interfaces, shared code and even the build system just so that the features from the todo list are painless to implement once i eventually get there...

now fedora of all distros has a proposal to ditch xorg for x11libre: https://fedoraproject.org/wiki/Changes/X11Libre

you could also give my https://github.com/eylles/zram-service script a try, it just works perfectly on my machine, also i'm planning to make it have some feature parity with what the rust-systemd-zram-generator so that it can also do mounts not just a single zram device as zramswap.

well taking inspiration from https://docs.xfce.org/xfce/tumbler/available_plugins with the webp thumbnailer i decided to check and turns out that yes, this once again imagemagick comes to the rescue as it can properly understand the xcf format.

just one small caveat, xcf files are multi-layer and while imagemagick can understand multi-frame, multi-page and multi-layer just fine however a simple convert image.xcf image.png will produce

image-0.png
image-1.png
...
image-n.png

for every layer of the xcf file, so a dirty solution if your xcf files got low layer counts is to use /usr/bin/convert "$1[0]" -thumbnail "$2" "$3" to hardcode layer 0, otherwise you got to extract every single layer and compose them in the correct position.

for image viewing i use nsxiv, may be biased in that i sometimes contribute to the repo and have helped cobble some scripts to extend the functionality tho

for a fetch program i use neofetch which i've been tempted to take maintenance of for a while but have not (i mean i've been maintaining a fork of pywal since 2021)

for screenshotting i like flameshot since it already packs everything i need to do the light editing of screenshots, but is not like i could not use maim with imagemagick like i was doing before.

for clipboard manager i have found nothing better than copyq, it just works, supports images and has vi-like bindings by default

for window management i personally like awesome tho i'm not the biggest fan of lua tho i did re-write my neovim config in lua a while ago...

for file management i use both thunar and vifm, most stuff i do in vifm but having thunar as the default is my preference for when the browser opens a file dir

i use webmail but lately i've been thinking of installing thunderbird, used neomutt for a while but it wasn't doing it for me tho, even using luke smith's muttwizard script to set up neomutt it didn't feel "complete" enough so i went back to using webmail