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.

you could always look into building a display manager for the framebuffer, that way it won't use neither x11 nor wayland, and you can make it to your own desires.

i mean, writing the software i want to use is what i do when the existing software doesn't work the way i want and i cannot reconcile with the codebase to work on fixing existing software.

so i was not happy with the icon i had drawn, anyway that is just a cosmetic and there's more of
shed to develop in the future as this release is more to get the ball rolling as shed is now easier
to use than ever, i can take the time and draw an svg with patience for the cycle of v0.4.0, for
now there is no icon nor logo whatsoever but that is not important.

shed v0.3.0 is finally out, all tweaks and last minute changes were made so that it would still
release on May 14 at least in UTC -0600...

anyway, go have fun setting up shed on your system, i'll try to cobble a package through the
weekend, once i got something that builds with debian tooling i'll look to get the package on
debian, ought to wonder if the people working on init diversity would be interested in shed or
they'll prefer to invest into another solution, regardless now i can look on ways to get the
ball rolling.

i personally keep using github for visibility of my projects, i'm just slow at mirroring everything to other forges like gitlab and codeberg.

the state of shed as of today, year 2026, month 04 (april) day 10

this is to address what works, which features ara available and how shed can be used as of the latest commit to master (c4f77b1), what is still to be implemented, what features does shed need and also as a request for feedback from prospective users to gather interest on either cutting a release of shed this week or wait until more capabilities are implemented, any further commits pushed today to the repo will only be documentation related.

What shed can do right now:

shed can run as the x session process leader, that is if you use startx to start your x11 session from tty your .xinitrc (or .xsession in debian and all derivates) file can perfectly well be just a shebang with the line "exec shed" right below, shed will work as the session process and so long as you logout with "shedc logout" the session will be terminated correctly.

shed can also be used as the session process for a wayland session, however i'm barely versed in wayland beyond the minimum needed to make shed into something that can work for the architecture of how a wayland's session leader is not just their window manager but their compositor and actual windowing server.

that said in the current state both x11 and wayland sessions can be started from a display manager like sddm just needing the correct .desktop files to be provided, for example:

the current shed x11 session could be /usr/share/xsessions/shed.desktop

[Desktop Entry]
Name=shed
Comment=an x11 session in shed
Exec=shed
Type=Application

the current shed wayland session could be /usr/share/wayland-sessions/shed.desktop

[Desktop Entry]
Name=shed
Comment=a wayland session in shed
Exec=shed
Type=Application

of note to the interest of wayland users, as far as i know shed is the only tool out there that can be a viable alternative to the Universal Wayland Session Manager (UWSM), which is the only other generic tool for managing wayland compositors and it does so with systemd units.

current capabilities of a shed session daemon are:

set XDG_RUNTIME_DIR - meaning you can even run without elogind, just shed.
set XDG_SESSION_ID  - the only feature so far that CANNOT be used as is in *BSD as it gets the session id from cgroups
set XDG_SESSION_DESKTOP and XDG_CURRENT_DESKTOP - env vars used to identify the desktop environment AND xdg-portals config for using the xdg-portals
set xdg home dirs - the XDG_DATA_HOME as $HOME/.local/share, XDG_CACHE_HOME as $HOME/.cache, XDG_STATE_HOME as $HOME/.local/state, not to mention XDG_DESKTOP_DIR, XDG_DOWNLOAD_DIR, XDG_TEMPLATES_DIR, XDG_PUBLICSHARE_DIR, XDG_DOCUMENTS_DIR, XDG_MUSIC_DIR, XDG_PICTURES_DIR, XDG_VIDEOS_DIR, defined with xdg-user-dirs-update, worth mentioning that for this purpose shed only exports their ENV var values it however does not initialize (mkdir) the directories as that step is not a strong requirement imposed on all session processes as far as i know.
can also export an "exports" file in shell loadable format containing the values of XDG_RUNTIME_DIR, XDG_SESSION_ID and shed's own SHED_SESSION_PID, this was an option that previously could be a requirement back when shed could not run as the session process, i'm keeping it for the time being as an option that may be of use to someone tho removal of this capability is open to possibility.

besides the configuration file shed supports:

loading of .env files to set up the environment during session initialization and before starting of components and services, .env files are just posix compliant shell scripts (no bashisms) which are to be stored in ${XDG_CONFIG_HOME:-${HOME}/.config}/shed/shallow.d for the files to be loaded during the shallow phase and ${XDG_CONFIG_HOME:-${HOME}/.config}/shed/env.d for the ones to be loaded during the transient phase, shed will only ever load them during the initial run as loading of .env files is ignored during reloads such as when calling shedc reload and shedc relaunch.

starting session components, session component definitions are stored in ${XDG_CONFIG_HOME:-${HOME}/.config}/shed/components, session components are services that will only be started at session start and terminated upon logout, meaning no attempt is made to start them from shed re-executions.

starting and managing user-services, one of the main reasons i wrote shed and the core functionality that was extended to session components, service definition files are stored in ${XDG_CONFIG_HOME:-${HOME}/.config}/shed/services, oneshot and daemon type services are supported, worth mentioning that with daemon type services the called program must NOT fork to background and exec to daemonize itself, such behaviour breaks the way that shed manages services, i know sysvinit in debian has no problem with that thanks to leveraging start-stop-daemon but shed does not use that program instead going for pure shell in hopes of portability.

do a shallow to transient initialization process in which shed starts in shallow mode only setting up the environment, then checks for a "transient" script which should be executable, if the check succeeds the script is ran with exec allowing it to inherit the PID of the shed instance, then it has to execute the program that will become session leader (also with exec so it inherites the session pid) and then the program has to launch a new instance of shed as a child, if the check fails shed will simply execute itself again, at this point execution of shed converging and completeing the session by starting session components and user services

what shed cannot do:

start programs from the xdg-autostart spec, in theory user services are better as they are explicit with their lifecycle behaviour (daemon or oneshot), tho a way to support xdg-autostart entries would be to run a script to parse and convert them into the shed service definition format, an additional feature would be required from shed when starting services to keep polling on the pid for a while and checking the exec name and flags to ensure it is the same program and so determine if it is a daemon or was a one shot, for that reason i did not have support for xdg-autostart as a goal for release v0.3.0 from the start of the development cycle.

use a proper implementation of the XDG_CONFIG standar, in fact shed only supports to have ONE set of configurations for ONE session, changes are planned to re-structure the shed configuration from:

$XDG_CONFIG_HOME/shed/
|- shed.rc
|- shallow.d/
|- env.d/
|- components/
|- services/
|- transient

to:

/etc/shed
|- sessions/
   |- session_name/
      |- shed.rc
      |- shallow.d/
      |- env.d/
      |- components/
      |- services/
      |- transient

$XDG_CONFIG_HOME/shed
|- sessions
   |- session_name      
      |- shed.rc
      |- shallow.d/
      |- env.d/
      |- components/
      |- services/
      |- transient

 
as this schema would allow for distributors to ship sessions, say if tomorrow someone wanted to create their own "desktop environment" using shed, say it was named Joe's Desktop Environment, and it was to use pekwm, picom, pipewire, xfce-polkit, and betterxsecurelock, then the default files that would be shipped for that session would be:

/etc/shed
|- sessions/
   |- JDM/
      |- shed.rc
      |- shallow.d/
      |- env.d/
         |- xrdb.env
      |- components/
         |- 99x11-windowmanager
      |- services/
         |- compositor
         |- pipewire-daemon
         |- pipewire-daemon-pulse
         |- pipewire-media-session
         |- polkit-agent
         |- xscreenlocker

       
however i'm very tempted to make the release of shed v0.3.0 and just leave these pending features for the dev cycle of v0.4.0 as i personally have no use for them and so far i feel shed has not gained enough traction to justify working on them.

yeh, i know that the way i'm using pid files is not the best, cleanest or even most reliable, i did have my eyes set on leveraging the start-stop-daemon program early on but decided against it at the start of the project as a proof of concept to see if i could get away without as a dependency, i do want to add use of start-stop-daemon to shed before the v0.3.0 release but as a soft dependency rather than a hard one, as in "do we got 'start-stop-daemon'? yes we do, that will be used and things will be more reliable. no we don't but we can fallback to the less reliable shell backend, that is okay." rather than "ya didn't install 'start-stop-daemon' in this thing? lol get rekt nothing works lmao"

as a sidenote, maybe i should try passing shed as a suckless program, say label it like a "suckless session process", perhaps it would generate more interest that way...

@coder-hase ya could always look into "breaking up" components form pico-init to a collection of smaller utilities, ya know to cheat the whole line count.

as for shed i've been working on it and i'm quite satisfied that many of the commits from this week have incurred in deduplication and generalization of code as that has vastly cleaned up the project.