worry not i have no problem sharing my ignorance with the world, that was the first thing i was taught about engineering at university

tangent aside, my point is not about ignorance but rather on function over a specific program, if a traditional program no longer works in the expected traditional way it did then it comes the question of is it the program or the setup around it

wall from the util-linux package should have the function of writing a message onto the terminals of all currently logged users, how does wall "get" the list of terminals associated with current users, on my system when i run who i get a list that contains my current terminal emulators (pts/N where N is an int starting at 0) but also contains tty7, the tty where the lightdm greeter spawns to initate the x11 server, the w command produces a similar list also showing the leader process inside each terminal, however no tty device is listed, doing a quick test running just wall "test" in my main machine on devuan 6 did produce the expected traditional behaviour of broadcasting a message to every running terminal i have

so it isn't much the program that isn't behaving traditionally but the setup around it, which begs the question if some specific program IS affecting the detection that wall should be able to do or is rather eating the message preventing it from propagating to the user terminals

all i can ask is what is bai4Iej2need's setup, a Desktop Environment, a window manager? which lightdm greeter?

i have lightdm with the slick greeter, i use a window manager but got some custom tooling so that my .xsession is a file that just launchs a program i wrote myself to be the session process which spawns my window manager, pulse audio daemons, picom and more,  yet when i run wall from any regular running terminal it works

well i have not updated any of the threads on shed for a while, also have not had super fresh news nor have made many impactful changes on shed in almost a month as the master branch can attest, which i think is a good thing as besides the pending points on the roadmap i do not think the design or architecture of shed requires any more radical changes right now and it is all implementing features as i feel the software is in a rather stable state at least from my own daily use

on a less uplifting note, i made a thread about shed on the freebsd forums and got no traction whatsoever, which i interpret as the BSD world having no interest in something like shed, yes i know FreeBSD isn't the only BSD DISTRO out there nor it represents the BSD side of unix and unix-like operating systems, tho i always got the impression that out of the different BSD distros FreeBSD was the one most interested in new software and new alternatives to ways in which things are done, so if they don't care i can only guess no one else in the BSD space will

which makes way for my decisions:

i will make no attempt at porting shed to any OS nor distro, i will keep writing in a portable manner as i've been doing until now, simply i will not make any effort nor collaborate first hand in code for porting shed to any specific OS nor distro, IF someone ever gets interested in the porting of shed i will take in any patch and merge any pull request

i will keep the development of shed with me, my uses and my preferences as the MAIN target and target audience of shed, which is to say the development of shed will keep assuming my setup first and foremost, not to say i will not care about issues reported by other nor that i will not care to implement features suggested or requested by others, simply that those will have a lot lower urgency and importance to anything that is essential to my usecase, also i will keep only testing shed on the distros i use mainly, which at the current time my main machine is a laptop on devuan 6 excalibur (stable) with elogind, sysvinit and xorg as the windowing server, the components entrailed on that setup are the ones i test and make sure work without issue first hand

i will only TRY to package shed for debian, i was thinking of not even packaging shed at all but i will make an attempt to package the next release of shed for debian, if i do succeed on creating a package and getting it accepted on debian so be it, if the package is rejected or i fail to create a package then so be it too, i will not try to package for any other distro after that

that's all for now, i do hope to have more positive news next time and to put out the next release of shed in august

the freebsd forum thead if anyone is interested: https://forums.freebsd.org/threads/shed … ng.103091/

well i've been messing some with greenjeans' initscript for my own machine-id initscript:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          machine-id
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Should-Start:      
# X-Start-Before:    dbus
# Default-Start:     2 3 4 5
# Default-Stop:      0 6
# Short-Description: Handle flexible machine-id modes and session cleanup
# Description:       Controls volatile or static machine-id layout variations
#                    and purges accumulated session bus files on shutdown.
### END INIT INFO

PATH=/sbin:/usr/sbin:/bin:/usr/bin
NAME=machine-id
DESC="Flexible machine-id and session management"

# Source the standard Debian/Devuan LSB logging utility library
. /lib/lsb/init-functions

CONFIG="/etc/default/${NAME}"
# Source configuration overrides if the file exists
if [ -f "$CONFIG" ]; then
    . "$CONFIG"
fi

EtcMachineID=/etc/machine-id
RunMachineID=/run/machine-id
BaseDbusSessDir=".dbus/session-bus"

clean_dir() {
    local target_dir="$1"
    if [ -d "$target_dir" ] && [ "$(echo "$target_dir"/*)" != "$target_dir/*" ]; then
        if [ "$DRYRUN" = "yes" ]; then
            for item in "$target_dir"/*; do
                log_action_msg "Dry-run: Would remove $item"
            done
        else
            rm -f -- "$target_dir"/*
        fi
    fi
}

fallback_machine_id_gen() {
    local mac_hex=""
    local needed_chars=32
    local machine_id_file="$1"

    local BaseNetDir="/sys/class/net"
    local net_dir
    local raw_mac
    # Only attempt MAC acquisition if explicitly enabled by the administrator
    if [ "$USE_MAC_FALLBACK" = "yes" ]; then
        for net_dir in "$BaseNetDir"/*; do
            if [ -d "$net_dir" ] && [ "${net_dir##*/}" != "lo" ] && [ -f "$net_dir/address" ]; then
                read -r raw_mac < "$net_dir/address"
                mac_hex=$(printf '%s' "$raw_mac" | tr -d ':' | tr '[:upper:]' '[:lower:]')
                if [ ${#mac_hex} -eq 12 ] && [ "$mac_hex" != "000000000000" ]; then
                    break
                fi
                mac_hex=""
            fi
        done
    fi

    # Calculate remainder space (defaults to 32 if MAC loop was bypassed or empty)
    needed_chars=$((32 - ${#mac_hex}))

    # Write out any discovered MAC slice first, then append random entropy
    printf "%s" "$mac_hex" > "$machine_id_file"
    tr -dc 'a-f0-8' < /dev/urandom 2>/dev/null | head -c "$needed_chars" >> "$machine_id_file"
    printf "\n" >> "$machine_id_file"
}

machine_id_gen() {
    local target_file="$1"
    
    if command -v dbus-uuidgen >/dev/null 2>&1; then
        dbus-uuidgen --ensure="$target_file"
    else
        fallback_machine_id_gen "$target_file"
    fi
}

do_start() {
    # VOLATILE MODE ENGINE
    if [ -n "$VOLATILE_MACHINE_ID" ] && [ "$VOLATILE_MACHINE_ID" != "no" ]; then
        log_daemon_msg "Setting up volatile machine-id" "$NAME"

        if [ ! -L "$EtcMachineID" ] || [ "$(readlink "$EtcMachineID")" != "$RunMachineID" ]; then
            rm -f "$EtcMachineID"
            ln -sf "$RunMachineID" "$EtcMachineID"
        fi

        if [ ! -s "$RunMachineID" ]; then
            machine_id_gen "$RunMachineID"
        fi
        log_end_msg 0

    # STATIC PERSISTENT MODE ENGINE
    else
        log_daemon_msg "Checking persistent static machine-id" "$NAME"

        # If it was a volatile symlink, safely capture its contents to disk before destroying it
        if [ -L "$EtcMachineID" ]; then
            if [ -s "$RunMachineID" ]; then
                local temp_id
                temp_id=$(cat "$RunMachineID")
                rm -f "$EtcMachineID" "$RunMachineID"
                printf "%s\n" "$temp_id" > "$EtcMachineID"
            else
                rm -f "$EtcMachineID"
            fi
        fi

        # Generate a standard static ID ONLY if the static file is genuinely missing or empty
        if [ ! -f "$EtcMachineID" ] || [ ! -s "$EtcMachineID" ]; then
            rm -f "$EtcMachineID"
            machine_id_gen "$EtcMachineID"
        fi
        log_end_msg 0
    fi
}

do_stop() {
    PowerState="/sys/power/state"
    PowerPMStatus="/sys/power/pm_status"
    if [ -f "$PowerState" ]; then
        if [ -f "$PowerPMStatus" ] && grep -q -E "freeze|suspend|hibernate" "$PowerPMStatus" 2>/dev/null; then
            return 0
        fi
    fi

    log_daemon_msg "Removing stale session-bus files" "$NAME"

    clean_dir "/root/${BaseDbusSessDir}"

    getent passwd | cut -d: -f6 | while read -r userhome; do
        if [ -z "$userhome" ] || [ "$userhome" = "/" ]; then
            continue
        fi
        clean_dir "$userhome/${BaseDbusSessDir}"
    done

    log_end_msg 0
}

case "$1" in
    start)
        do_start
        ;;
    stop)
        do_stop
        ;;
    restart|force-reload)
        do_stop
        do_start
        ;;
    status)
        if [ -L "$EtcMachineID" ]; then
            log_success_msg "Machine-ID Mode: Volatile RAM (Value: $(cat "$EtcMachineID"))"
            exit 0
        elif [ -s "$EtcMachineID" ]; then
            log_success_msg "Machine-ID Mode: Persistent Static (Value: $(cat "$EtcMachineID"))"
            exit 0
        else
            log_failure_msg "Machine-ID file missing or uninitialized."
            exit 3
        fi
        ;;
    *)
        echo "Usage: $NAME {start|stop|restart|force-reload|status}" >&2
        exit 3
        ;;
esac

the idea of this modified version wasn't so much to "just clean up files in devuan" but rather i intend it as part of the debian's initscripts package so that a debian sysvinit-core install would be more like a default devuan install as in having a volatile machine id

worth mentioning i'm still testing the initscript and have not really made full on testing with the different hibernation methods

tho i'm not sure it is polished enough yet to try to submit it to the debian initscripts package

BSD utils are released under a permissive license (BSD), there are ports of those to linux and there are distros that use the BSD utils by default (chimaera linux), so on the part of "this component has been rewritten in rust under a permissive license" the point is moot, on the part of "this component rewritten in rust is immature, has plenty of bugs, cannot pass the gnu implementation testsuite and even has/had multiple CVEs" is a more accurate technical criticism of uutils.

well yeh there's an argument of sysvinit doing too little, but that is also what allows/requires to just build the features on top as separate programs... werether that is a good or a bad thing should be the real argument, on one side if you don't like the way one of those components work you can just easily build your own and replace the original, on the other hand it means that the components on top of sysvinit have to be maintained apart from it and a single set of libraries containing re-usable function cannot be easily made for all components of debian's enhaced sysvinit... you can't have your cake and eat it too, everything is balancing the downsides.

one thing

there's a lack of really good and clear documentation to write man pages, i know there are videos out there, forum posts and articles about writing documents with roff and some even delve on the differences between roff dialects and implementations like groff, nroff, troff, etc... but they all have the same problem, they are written as narrations/articles which isn't the ideal form to ingest information dense topics, i find the best way to ingest and digest any topic with high information density is through the structured sections of wiki pages and ironically man pages as those are also structured by sections...

so, knowing that there are man pages that need to be written for this project it would be nice to have a wiki page and a manpage about writing manpages, and i know there will be some that will say "just write in asciidoc and convert to a manpage" and i'm not invalidating that but a manpage is not a mystical lost language, it is just roff, which is admittedly not great to write by hand but not impossible, so covering how to write a manpage by hand shouldn't really be a "no one will ever do that", that said for the task of writing the wiki page and the manpage that are to have the refference on how to write manpages both by hand and asciidoc it would make sense to write the source in asciidoc so it can be "easily" converted to both formats

for some repos i write manpages directly in roff and they come out okay cuz i cheat copying the manpages of other projects as template/base (usually the sxiv/nsxiv manpage) and editing it, but doing that has limits like when i want to add some usage or even code examples onto the manpage which i've had to format in less than ideal manners...

well the welcome app could take notes from bunsenlab's bunsen-welcome and antix's antix-control-center

rather than a begginers manual i'd push the idea of a "welcome app", which is to be a sort of "hub" app that autostarts and is available to run as is, the hub app would show options to launch things like the helpsystem, manual page search, software installation (name your favourite "software store" type program from synaptic to aptitude or apt-ui), set alternatives, etc...

not rushing to witch hunt? where is the fun in that?

personally i think it is a shame as flatpak is/was a great tool to supplement software when some package is not available or has usability downgrades in a distro, as examples i still use flatpak for primehack (a fork-mod of the dolphin gamecube and wii emulator that focuses on modern fps style mouse+keyboard and gamepad controls for metroid prime) which is so niche i doubt it will ever be packaged for debian, zoom since i really don't want the zoom software to be a too integrated part of my system when i've needed to take video conferences, adwsteamgtk which lets me theme steam to look like a gtk program using my custom stylesheet for adw-gtk3

i also use krita and kdenlive from flatpak and was counting on flatpak as a way to keep using krita and kdenlive after they drop support for x11 since the nice cool thing about flatpak is you can install older builds of the flatpak than the most recent release...

some other programs i use flatpak for cuz i've been lazy i can switch to the debian package, like obs studio, retroarch which i've been using from flatpak since the debian package had the online core downloader disabled and the emulator core list was heavily curated now it is just a matter of configuration altho annoying the default is to disable the core downloader and not have the emulator core dir set to a user writeable one but meh is just config, one that will be annoying long term in the future is the gnome-authenticator which in spite of being a seemingly simple program is fully commited to libadwaita so when that drops x11 the program is kill for my environment even from the debian repo and alternatives aren't great as otpclient currently is a gtk3 app on the repos but upstream has transitioned to libadwaita too leaving only cotp which is TUI but also rust, which here is the least of issues really but still makes me want to write my own tui program for that....

tangent aside, perhaps this could be the call to fork flatpak, i mean the current software works so a tentative fork would be really just a maintenance one rather than rushing to add every feature under the sun, question is if other systemd free distros like void linux, artix and chimaera would be interested to collab on forking flatpak and possibly even the flathub just to keep the convenience that currently exists, no idea about alpine as the distro is continually moving towards having greater systemd compatibility even now

gnome is the one desktop environment where the desired behaviour happens because of a bug, at this point anyone who like the gnome ecosystem but don't want mandatory systemd should look into forking gnome for the long term.