ah offtopic discussions, the pepsi to the coca cola of on topic discussions, seems like the forum loves pepsi

anyway, back on track would be a good thing to have the easydeb repo and the DUR proposed repo in more forges than just gitea cuz the gitea links posted in this thread are innacessible to me, also cuz mirrors are a good thing and there's no such thing as too many mirrors

i have no idea how to avoid that tbh, what i did is reduce the speed/amount the cache buffers fill by implementing dynamic polling, sort of, the current master commit of afreq.sh increases the time of the sleep calls from a fixed 500ms up to 5000ms (5 seconds) if the governor and boost stay stable (say at idle) for at least 5 ticks (5 runs of the tick function), it also reduces the sleep time down by 100ms if there is not a stable state and will keep doing so until every sleep is just 100ms with time going up once there are 5 stable states.

in my testing the buffers usage went down by 1GB, but i got other daemons that are also written in posix shell and operate in the same type of wait sleep cycle...

did ya figure it out?

when there is no one young whom know how to build a bridge the standing bridges begin to fall with no one in sight to repair them less alone build new ones for generations, but all easy learning is bad, learning must be hard enough to chase away everyone otherwise there's no worth in the learning itself am i right?

that is extremely odd

you can get the PID of the running afreq instance by running cat /var/run/afreq/status

with vmrss https://github.com/ThePrimeagen/vmrss it says that afreq is using 1.88281 MB of memory

with btop tree view on the sleep part of the cycle it shows that afreq is using 1.8 MB while the busybox usleep is consuming also 1.8 MB (yes it does prefer busybox usleep when available as that is more reliable than just hoping sleep supports decimals as the system could be using a sleep implementation other than gnu sleep), the busybox usleep program runs every 500 milliseconds so at about 2MB per millisecond it uses 4 MB each second (even tho those are 2 different invocations), so if a program is measuring the memory usage every X seconds then it may get that afreq is using 6 MB times X seconds, say 5 seconds that ought to sum up to 30 MB, tho i dunno if some system monitoring program measures that way, unless this is some shenanigans with the caches...

during tick the programs vmstat, tail, awk and others are invocated, they complete so fast that btop could only register vmstat, tail and awk, in the tick step afreq would have a memory footprint of 12MB (i'm ceiling the sum)

looking at htop these are the numbers of resource usage for afreq and as far as i know those are in kilobytes

so i am at a loss of how afreq could balloon all the way to 1960 megabytes on your machine

yeh auto-cpufreq has one of the designs of all time... that and it requiring python for doing something so simple as it is to just write to a handful of locations inside the kernel sysfs among other reasons got me to write an alternative, it is tried and tested in devuan under sysvinit and elogind, have not tried on even more minimal setups like ones lacking elogind so cannot comment there, also i know it isn't what you want but just putting it out here since i was also unable to get the auto-cpufreq daemon properly running on devuan

https://github.com/eylles/afreq.sh

debian trixie does that with a systemd service iirc, devuan is not affected, not that you cannot mount /tmp or any other dir as a tmpfs if you want to for some usecase, just do it in fstab i guess.

as for the output of mount in a devuan excalibur system

mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=7816860k,nr_inodes=1954215,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1576544k,mode=755,inode64)
/dev/nvme0n1p4 on / type btrfs (rw,noatime,compress=zstd:10,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/@rootfs)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
securityfs on /sys/kernel/security type securityfs (rw,relatime)
pstore on /sys/fs/pstore type pstore (rw,relatime)
none on /sys/firmware/efi/efivars type efivarfs (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=7840540k,inode64)
/dev/nvme0n1p2 on /boot type ext2 (rw,relatime)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/nvme0n1p5 on /home type btrfs (rw,noatime,compress=zstd:10,ssd,discard=async,space_cache,subvolid=5,subvol=/)
/dev/sda1 on /media/storage type btrfs (rw,noatime,compress=zstd:10,ssd,discard=async,space_cache,subvolid=5,subvol=/)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
tmpfs on /run/user/112 type tmpfs (rw,nosuid,nodev,relatime,size=1576540k,nr_inodes=394135,mode=700,uid=112,gid=121,inode64)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1576540k,nr_inodes=394135,mode=700,uid=1000,gid=1000,inode64)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

speaking of image viewers, in my opinion nothing beats nsxiv https://codeberg.org/nsxiv/nsxiv the interface may be super minimalist but the extensibility and scripting are unmatched, not to mention the latest release is available on devuan stable.

as for optimizing images... i just convert jpg and webp to png and run the pngs through optipng with these scripts

topng

#!/bin/sh

myname="${0##*/}"

convert_to_png () {
    img="$1"
    imgname="${img%.*}"
    pngname="${imgname}.png"

    if [ -f "$pngname" ]; then
        printf 'image: %s already exists!\n' "$pngname"
        if [ -f "$img" ]; then
            trash-put "$img"
            printf 'image: %s deleted\n' "$img"
        fi
    else
        convert "$img" "$pngname"
        printf 'image: %s created\n' "$pngname"
        if [ -f "$img" ]; then
            trash-put "$img"
            printf 'image: %s deleted\n' "$img"
        fi
        optipng -quiet "$pngname"
        printf 'image: %s optimized\n' "$pngname"
    fi
}

if [ $# -lt 1 ]; then
    printf '%s\n' "$myname: error no images passed"
    exit 1
fi

while [ $# -gt 0 ]; do
    if [ -f "$1" ]; then
        if file "$1" | grep -q "image"; then
            convert_to_png "$1"
        else
            printf '%s\n' "$myname: '$1' is not an image!"
        fi
    else
        printf '%s\n' "$myname: '$1' does not exist!"
    fi
    shift
done

jpgconvert

#!/bin/sh

for image in "${PWD}"/*.jp*g; do
    topng "$image"
done

back to OP, wine does little assumptions so it only creates the default wine prefix and runs every program with said prefix unless a prefix is explicitly set.

personally i do not like letting wine create .desktop files and prefer to write runscripts and dedicated .desktop files for the programs i want to run with wine, that includes setting their wineprefix, for that reason i got a runscript template that works for most stuff you wanna run through wine

runscript template

#!/bin/sh
# wine runscript

myname="${0##*/}"
execdir=""
execname=""

# load config
configdir="${XDG_CONFIG_HOME:-$HOME/.config}/${myname}/"
config="${configdir}/config.rc"
if [ -r "${config}" ]; then
    . "${config}"
else
    if [ ! -d "$configdir" ]; then
        mkdir -p "$configdir"
    fi
    echo "# ${myname} runscript config" > "$config"
fi

# go to executable directory
cd "$execdir" || exit

# run executable
wine "$execname"

with that the runscript's config can be as follows

# runscript config
# wineprefix
export WINEPREFIX="${HOME}/.local/share/wineprefixes/pref1"

for a real example my photoshop cs6 runscript

#!/bin/sh
# wine runscript

myname="${0##*/}"
execdir="$HOME/Downloads/Photoshop portable/Photoshop cs6 portable/"
execname="PSCS6.exe"
WINEPREFIX="$HOME/.local/share/wineprefixes/photoshop"

# load config
configdir="${XDG_CONFIG_HOME:-$HOME/.config}/${myname}/"
config="${configdir}/config.rc"
if [ -r "${config}" ]; then
    . "${config}"
else
    if [ ! -d "$configdir" ]; then
        mkdir -p "$configdir"
    fi
    cat << __CONF__ > "$config"
# ${myname} runscript config
WINEPREFIX="\$HOME/.local/share/wineprefixes/photoshop"
__CONF__
fi

# go to executable directory
cd "$execdir" || exit

# export prefix
export WINEPREFIX
# run executable
wine "$execname"

i have hand written manpages by hand for scripts that aren't even 500 lines of code long and that is because i have not generalized redundant code into functions enough like for this systemact script https://github.com/eylles/systemact which as far as i know i'm the only user and i don't even use like half of the features i've added...

if ya miss the systemctl heuristics there's this script i call initctl which wraps update-rc.d(8) and service(8) in a familiar way while ya learn the ropes of using those commands.

https://github.com/eylles/devuan-script … er/initctl

hope it works in your setup, anyway i go back to my usual unemployed activities, play videogames while pretending i'm working on this one business idea thing that idk if will even work.

technically the logs are correct, fstrim sends the trim operation to every mounted partition with a filesystem that supports it, the discard is calculated and then passed from the filesystem (through the kernel i'd assume) onto the drive's firmware, the firmware accepts the trim operation with the provided discard parameters, reports back that the proposed operation was accepted but then ignores it internally as the firmware does it's own handling of empty/unused space, the kernel gets the success status back to fstrim and fstrim reports back that the operation was a success and prints out the output that as far as the process is concerned was correct, fstrim simply has no way to know that the drive's firmware is lying while ignoring the trim and discard so the log output is "correct"