i've been living on devuan stable for a while now but what is happening with amd in devuan ceres?

ah systemd and it's consequences... it gets annoying having to work around some of the systemd "innovations" and the upstream decisions to exclusively rely on them as the one and only interface, glad to read you are enjoying the devuan experience in spite of that

in regard to the many annoyances do not limit yourself to suffering alone with chatgpt, chances are someone else in the devuan forum has also suffered them and came up with some solution.

in regards to sound and pipewire there are many camps and proposed solutions, from simply configuring it as a user service in runit and openrc (tho i think that option is only available in testing and unstable at the time), to more terse solutions like using slackware's "daemon" program or even using shed the generic session process and user services provider, there are always the alsa purists that say that anything on top of alsa be it jack, pulseaudio or pipewire is a disease and symptom of the lack of understanding of alsa and the horrible documentation turning things into an absurdist comedy... so it all boils down to picking your camp and choosing a poison to drink

on a tangent check out https://github.com/eylles/devuan-scripts tho a portion of the scripts target window manager setups rather than full fledged desktop environments something or other in there may come out at the very least useful.

yes, there are multiple CVEs related to ssh, basically any ssh-server version under 9.5 is considered compromised with working exploits.

probably openrc since it does re-use some components such as the core init program from sysvinit init(8), with the rest of the openrc being pretty much a service supervision suite implemented on top of it, or at least that is what i understand as a condensed form of what the gentoo wiki says about openrc

https://wiki.gentoo.org/wiki/OpenRC

i guess it should be #!/usr/bin/python3 but since usrmerge it makes no difference whatsoever as /bin is the same as /usr/bin

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