if ya wanna be lazy and barely type commands to install brave there's always https://github.com/eylles/devuan-script … -installer

just run the script as brave-installer install and it takes care of the installation, it uses classic style sources tho, i have to add the option to use the deb822 format

ah nice, gotta love western digital, they truly embody their name.

but where is the fun of writing manpages by hand and having formatting not work cuz you typed one extra char after the macro?

well this thread if anything vindicates my refusal to create packages for anything i develop, less alone packaging for debian as it is an unnecesarely complicated crapshow or at least everything i've read so far has painted the creation of a new deb package from an upstream source that has not been previously packaged, admitedly i have not read the guide in the link shared by golinux but by this point i don't got high hopes.

ah yes, sorry it took me until today but it should be sorta kinda solved-ish in master as of now.

by mistake i was using the hardcoded path of the XDG_RUNTIME_DIR instead of using the env var.... shedc should use the env var now

as for the env var, i added the option to have a shed.rc file inside ${XDG_CONFIG_HOME:-${HOME}/.config}/shed/conf, that file is just loaded as a script file so use with care, there you can set the variable SHED_ENV_EXPORT_LOC to a filepath that your user can write to, say if you are already setting and exporting the GUI_SESSION_PID var inside your .xsession then you should be able to define the var like so:

# this is just a suggestion that hopefully ought to work if you startx in multiple ttys
SHED_ENV_EXPORT_LOC="/tmp/shed_session_${GUI_SESSION_PID}/shed.env"

the shed.rc being a loaded "script" the variable substitution should just work with dash, yes the variable definition should end in a filename at the end of a path, no you cannot just give a path as it will break how it works, no there is no checking of werether the variable definition ends in a path or a file since this is THAT cobbled together.

as for the contents of the export file it would look something akin to this:

export XDG_RUNTIME_DIR="/tmp/1000-runtime-dir"
export XDG_SESSION_ID="67"
export GUI_SESSION_PID="42069"

this ought to let ya just load that file inside your .xsession right after starting shed and before launching the window manager, or at least i hope, otherwise you'll have to use an until waiter loop like this

until [ -f "/tmp/shed_session_${GUI_SESSION_PID}/shed.env" ]; do
    # 50 miliseconds
    sleep 0.050
done

. /tmp/shed_session_${GUI_SESSION_PID}/shed.env"

anyways sorry for shed being such a hacked together thing that works all the time like 60% of the time outside of my setup, the whole thing started as a pair of scripts i cobbled for myself to be part of my dotfiles until i broke it "free" from my dotfiles into it's own script that has only continued to grow at a snailpace cuz i'm the only moron working on it and i mean MORON cuz i don't see anyone else stupid enough to write such a piece of software in posix(-ish) compliant shell...

it all depends on the specific hard drive, yours has a firmware scheme that accepts trim but ignores it, others may actively make use of the trim instruction but handle it differently at the firmware/hardware level

yes i know that, hence why shed is currently flawed and needs to become the session process and be a compliant x-session-manager, to give an example think of say xfce, if you start x11 from a display manager like lightdm and select xfce it will run an x11 session with the program xfce-session as the session "leader" program, xfce-session exports all env vars, starts all session components (window manager, panel program, wallpaper setter, desktop manager (program that provides desktop icons)), starts the settings manager and then runs the xdg-autostart programs, then finally waits and stays running until you logout, reboot or poweroff, in the logout process xfce-session acts as a middleman and cleans after itself killing every process it started (or at least those it knows about), kills every one of it's child processes and then terminates, once the session leader is terminated x11 terminates and you get sent back to the display manager.

when starting from a tty and running startx, the last program specified in your .xinitrc (or .xsession in debian based distros) as exec will become the session process leader, an .xsession can export environment variables before execking the last program, but again say we use xfce, the last line of the .xsession wold be exec xfce-session and then again xfce-session will have all the responsability.

the flaw of shed is that it is not currently the program that starts the window manager, ie the window manager and every GUI program is not a child of shed and thus won't properly inherit it's environment, only the programs started by shed inherit shed's environment, the window manager runs as a sibling of shed, so programs started from within the environment of the window manager have the window manager's environment.

a dirty hack would be to have shed first export all it's environment to a plain text file, then have the .xsession load shed's environment file... but the real solution is still to implement session components so the window manager can be started by shed...

how do you log out? by all means shedc logout should take care of cleaning after itself, if it doesn't then i gotta fix that.

yes, the last release tag (0.2.0) expects you to have elogind OR something else that did define the XDG_RUNTIME_DIR, master since commit cc6d537 will define the XDG_RUNTIME_DIR and since commit 95d95c4 it will fallback to create an XDG_RUNTIME_DIR in a similar manner to the one that gentoo recommends to launch sway from a tty, additionally on linux (not really targetting other unixes at the time) it can also set the XDG_SESSION_ID

but all those are features i've added on master, the warning in the readme was because at the start of the development cycle for 0.3.0 i was breaking stuff more often, while you can do use master safely for now i still have to break more things to add the concept of "sessions" and "session components"

for shed will have to receive an argument specifiying the session name or it fallbacks to default, every session name, including default would be a subdirectory of the XDG_CONFIG_HOME/shed/sessions dir (will need to add fallback dirs for sessions bundled with shed, defined by vendor, defined by admin, and have the user config sessions have priority with falling back to each subsequent dir) where the name is the name of the subdir, each session will have to contain a loadable "session.rc" file that adds configuration and information about the session and how some processes ought to be started and treated, an optional "session.d" directory for other files (scripts) to load, then the "components" subdir for the session components and finally the "services" subdir for the session specific user level services to be managed by shed

the "session components" will be a class of services apart from the "user services" already understood by shed, in that these are meant to be core components of the session like the window manager, compositor, panel, notifications daemon, keyring daemon, etc... they differ in that this class will normally only get started on shed's first run and only get terminated on shed's logout but not touched during reload (when shed execs itself) nor to be touched by the regular stop, start, status and restart operations.

also gotta add support for oneshot services as right now shed assumes every service is a daemon...

those intended changes are so that shed can be used as a proper x-session-manager instead of a very hacked together thing shoved into the .xsession

that said, use shed from master without worry for the time being, just whenever you pull your local copy of the repo to update check the git log to see what (if any) has changed in order to adapt your setup as i continue to develop shed on the road for 0.3.0

it really warms my heart to see the joke fly over everyone's head thanks to my posts being ignored unless i join the whining...

still interesting to see how simple the approach of the start_user_pipewire script is when i went ahead like an idiot and engineered a whole crappy process manager + incomplete session process in shell (not even bash because arrays are the devil) all to have pipewire "just work" with 3 files that barely classify as config files...

https://dev1galaxy.org/viewtopic.php?pid=49728#p49728

again, the repo i posted is the script i use on my machine, it works nicely for sysvinit + elogind.

open a thread in DIY and post the repo in the opening post, tho if any of my projects is an indication expect no traction nor engagement from the forum whatsoever.

yeh, desktop environment GUI copy tooling is not great, for large numbers of files rsync is always the way to go, mainly because you can cancel the operation and continue it later by running the same command

there is also grsync to ease things up a little