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.

nah, the age verification daemon must be themed after jeffrey epstein, there's no one whom governments and age verification pushers will trust more on werether someone is underage or not than jeffrey epstein, with only a "virtual" jeffrey epstein coming in second in that level of trust.

was just noticing, the current development cycle of shed v0.3.0 constitutes more than half of the total commits to shed and yet i've barely made a dent on the pending side of the roadmap... most of the commits have been either tangentially unrelated to the roadmap or refactors and improvements over early poor design decisions when i barely had a concrete vision of what shed was supposed to be...

by "x-session-manager" i mean what debian means, which is a program that can work like "xfce4-session" and "lxsession", which is getting exec'd by either the xsession script or display manager, becoming the "session leader process" (the process whose PID keeps the x11 session alive) and has the task of starting every session component, window manager, compositor, panel, etc... AND while we're at it also serve as a way to provide "user services" and eventually have a way to convert XDG_AUTOSTART entries into manageable monitoreable services just like the "user services", for an idea of what "user services" are look at systemd user units, runit user services and since last year openrc user services.

worth clarifiying that altho i mention x11 shed is NOT tied nor enthralled to x11, i need to make some DIR structure changes and introduce some features but once done shed will be able to work as a extremely generic "session manager" meaning the open possibility to use shed for wayland, tty, framebuffer and ssh "sessions".

shed is not an "init" program in the manner that sysvinit or runit are, shed is closer to an x-session-manager, as for "bloated linux frameworks" shed does not interact with, understand less alone know about frameworks, all interaction that shed ever has with something like elogind is check if the XDG_RUNTIME_DIR env var was set, if it wasn't then shed sets it to something reasonable, shed is written in purely shell script so it doesn't matter if you don't know something like C, you can go ahead to the code repo and read the code, i suggest ya do read the code, it has some nice shell script tricks, i guarantee your shell scripting will improve from just reading it.

i have all my repos in github, been mirroring to gitlab, codeberg and more recently the devuan gitea instance, i'm not getting any repo off github cuz it does help visibility but i do have to update all my readme files with links to the mirrors.

yes, everything is worse than deno security wise, but deno is le rust, rust bad, also rust anything is conflicting with the debian way of packaging thanks to the rust package manager, cargo...

the challenge to package deno for debian is open, but after that comes the challenge of convincing users that something written in rust is not bad.

i still remember this thread about keepassxc https://dev1galaxy.org/viewtopic.php?id=7379

using pass as the "backend" or rolled out your own?

heh i got into linux back in ubuntu 10.04 but never got used to how synaptic works, dunno didn't mesh with my thought process so a while ago i found a script named "debianUI" which implemented a TUI wrapper over apt with fzf, seems like the author deleted the repo so i began working and created my own version in posix shell, still using fzf and made it configurable, it fuzzy searches packages by name and short description, provide a scrollable preview with the long description of the package under the "cursor".

the script is available at https://github.com/eylles/devuan-script … /apt-ui.sh and https://git.devuan.org/eylles/devuan-sc … /apt-ui.sh

i reckon just a description of a TUI program is not enough to have a couple screenshots, expect colors to be different in your terminal emulator