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

just to provide more context on the problems you mention:

the licensing is the licensing of the COMPILER, rustc, not the language syntax itself, and yes the license of the compiler does seems a bit in bad faith, but for that there is a project implementing a rust compiler over gcc https://github.com/Rust-GCC/gccrs , it still is a work in progress but the project is already on the stage of compiling the rust stable core library and focusing on increasing coverage of the testsuite.

the ubuntu fiasco with the rust core utilities project, uutils, stems not from the uutils project itself but rather from the ubuntu developers whom decided to ship as default a core utils package whose compatibility level is not just lower than busybox but even right now is not able to pass the gnu coreutils testsuite, so for credit where it is due and blame where it causes shame, this is fault of the ubuntu developers rushing to push a not ready for production package into a "production ready" release as a default core component

that context provided, there is the posibility that the addition of rust into apt could be a very rushed one seeing that the push does come from an ubuntu developer tho beyond that there is nothing else i can comment on a technical level at the time.

makes sense, if anything it should install the policykit-1-gnome as that does provide the polkit-1-auth-agent that would integrate the best with gtk and the network-manager-applet, however my guess is that apt resolved the dependencies getting a list of which packages provide polkit-1-auth and choose the first available option by alphabetical order, were the lxqt agent not available it would had gone with the mate agent...

edit: i just noticed that the policykit-1-gnome agent was removed in trixie because it is unmaintained upstream as stated here https://bugs.debian.org/cgi-bin/bugrepo … bug=990271

so the real solution is to install the mate-polkit-bin package as that WILL integrate with a mainly gtk environment without pulling the lxqt session NOR the mate-session package

unless someone (probably not from the forum), forks and continues the work of stlwrt to have a toolkit library compatible with gtk2 to gtk4 with whichever rendering appearance is desired all that complaining about qt6, gtk4 and the eventually upcoming qt7 and gtk5 will accomplish is to have a bunch of written complains in our corner of the internet

stlwrt: https://github.com/thesquash/stlwrt
ubuntu mate forum thread (where stlwrt repo got posted): https://ubuntu-mate.community/t/horribl … 4/22028/63

posted that from phone and autocorrect screwed me over, forgot to turn that off in this phone lol

ah yes i can explain why even when the ubuntu patch does remove the Client Side Decorations no Server Side Decorations are added, the EWMH and _MOTIF_WM_HINTS, to be more precise the MWM_DECOR_TITLE hint which when set requests the window manager to NOT add titlebars (Server Side Decorations) to a window be it because the window is of type dialog or some other reason like having Client Side Decorations, the ubuntu patch manages to disable the Client Side Decorations on gtk4 but fails to set the appropriate window hints to allow the window manager to decorate the window with a titlebar, if you got a configurable window manager that is a non issue as ya can simply set the window manager to ignore the title hint for gtk4 apps.

for example on greenjames suggestion of using a CSS hack to hide window buttons on gtk4 apps and then just add decorations through the window manager selectively ignoring the title hints of gtk4 apps.

some reference from the hand of awesome wm documentation:
https://awesomewm.org/doc/api/classes/c … o_titlebar

there was a talk a while ago about forking the systemd-boot outta the systemd source tree as egummy-boot for the whole reason that for it to work completely free of any systemd tree untility it just needs a shim, the reason for the fork being to ensure that it remains requiring only that one shim instead of relaying on other systmed "utilities"

edit: the link of the thread https://dev1galaxy.org/viewtopic.php?id=6095

in usual dev1 forum fashion the idea of a shim was discussed along the idea of maintaining a fork to ensure just the shim is needed but the proposal got no traction and nothing was done.