shed is not an "init" program in the manner that sysvinit or runit are, shed is closer to an x-session-manager, as for "bloated linux frameworks" shed does not interact with, understand less alone know about frameworks, all interaction that shed ever has with something like elogind is check if the XDG_RUNTIME_DIR env var was set, if it wasn't then shed sets it to something reasonable, shed is written in purely shell script so it doesn't matter if you don't know something like C, you can go ahead to the code repo and read the code, i suggest ya do read the code, it has some nice shell script tricks, i guarantee your shell scripting will improve from just reading it.

i have all my repos in github, been mirroring to gitlab, codeberg and more recently the devuan gitea instance, i'm not getting any repo off github cuz it does help visibility but i do have to update all my readme files with links to the mirrors.

yes, everything is worse than deno security wise, but deno is le rust, rust bad, also rust anything is conflicting with the debian way of packaging thanks to the rust package manager, cargo...

the challenge to package deno for debian is open, but after that comes the challenge of convincing users that something written in rust is not bad.

i still remember this thread about keepassxc https://dev1galaxy.org/viewtopic.php?id=7379

using pass as the "backend" or rolled out your own?

heh i got into linux back in ubuntu 10.04 but never got used to how synaptic works, dunno didn't mesh with my thought process so a while ago i found a script named "debianUI" which implemented a TUI wrapper over apt with fzf, seems like the author deleted the repo so i began working and created my own version in posix shell, still using fzf and made it configurable, it fuzzy searches packages by name and short description, provide a scrollable preview with the long description of the package under the "cursor".

the script is available at https://github.com/eylles/devuan-script … /apt-ui.sh and https://git.devuan.org/eylles/devuan-sc … /apt-ui.sh

i reckon just a description of a TUI program is not enough to have a couple screenshots, expect colors to be different in your terminal emulator

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