any specific feature that makes it a "worth installing right now" over waiting for it to be added onto either debian or devuan experimental for your daily driver? cuz for testing environments and providing feedback onto the project i do consider an install now if you can spare a "testing machine"

well, more shell slop crudely typed by my hands, this time a handful of scripts that aim to wrap neovim and a terminal emulator into a makeshift gnvim program to better integrate with GUI programs and desktop environments

https://github.com/eylles/xterm-nvim

will try to create a .deb package for it tho.

Anyway, more on topic, password management really has got me thinking for a while that there is not a real "good" generic way to do password management on a unix like environment, seeing all the threads about complains on password managers like keepass, local secre/password access stuff via gnome-keyring-daemon, and browser/mobile password management where the only good solution is bitwarden as you can host your own server and there are at least 3 implementations of the bitwarden server, not to mention the need for OTP codes and all the problems that the gnome-authenticator package had at one point being removed from testing and how difficult it was for the maintainers to package the newer version of the project after it was rewritten from scratch in rust because the rust model of managing it's own dependencies with cargo has a lot of friction with how packages are built in debian...

All that to say, i've been thinking of looking into writing a set of programs for addressing that madness:

• password-keyring-daemon: a daemon to replace the secret store functionality of the gnome-keyring-daemon,will however not provide d-bus functionality by default, all the actual storing of secrets and passwords would be done with pass as a pluggable backend, so whoever doesn't like pass can roll his own password manager and backend wrapper to be used with this daemon.

• password-keyring-daemon-dbus-plugin: an optional plugin for said daemon to add the d-bus functionality for those who need it, this would include the org.freedesktop.secrets portal interface.

• password-bw-imexporter: a plugin to import-export to/from bitwarden, would use a config file to set the bitwarden server and account credentials so users can still self host bitwarden, the idea is to allow the daemon to fetch the passwords csv, merge with the local password store through the backend and then get a merged csv from the backend to export onto the bitwarden server, this would be one of the pieces of this whole set with network access to sync the password stores.

• password-keyring-favicon-fetcher: just a "dumb" program to fetch the favicons, the second program of this set to have net code and would serve to prevent the need of net access in the other programs.

• password-keyring-authenticator-lib: a library to handle all the OTP stuff, not something that would directly be called by the daemon.

• password-keyring-authenticator: a gui program to manage OTP authentication, be it just copy the OTP code to clipboard or add a new authentication entry be it by qr code image or a token.

• password-keyring-manager-lib: a thin client library to retrieve passwords from the password-keyring daemon, to be used by a gui program.

• password-keyring-manager: a gui program to actually manage the locally stored passwords, if the favicon fetcher is present it will show favicons, if the bw-imexporter is present will sync the password store on start and upon changes.

consider those names as placeholders, and for the actual development i would probably use python to have a fast development cycle as besides the very core daemon none of the other programs are "performance critical" to NEED be written in C, and even then re-writing the daemon in C would be something to consider for the time when everything else is working good enouhg..

Tho i got no timeframe whatsoever to do any of this, nor it is for sure i will with my history of starting cobbling together daemons and other programs then taking forever to add basic features...

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