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.

Added a function for clickable hyperlinks to open in default browser, and a first run dialog that now offers to install the save folder in the default location or let the user select one via the file-chooser dialog. Thanks to ceeslans and Zathras for the suggestions! Note: Have not packaged or uploaded this new version yet, this will be v. 1.0-2

EDIT: I don't know why the pics are blurry but the app is nice and sharp actually, lol.
EDIT2: VuuPew is an acronym, it stands for "Veteran Unix User's Projectile Estimation Widget", my wife came up with that name, I think it's brilliant.
EDIT3 3-29-2026 : Added wind drift but my math is still off a bit, got everything else done and the save function puts out a great simple printable chart + notes and details, updating the screenie below.

Note that I included a .desktop for the standard version in case you want to do a full manual install, but there's not one for the portable version, it doesn't need one, just drop the binary on a USB stick and click it to run, it will do the rest.

It probably goes without saying but you need gtk3 and libsodium onboard to run it.

https://sourceforge.net/projects/vuu-do … s/VuuPass/

Remember, this is first test of experimental software, test only with dummy data for now until more test results come in.

Welp, w/e.

• snapshots can now have multiple kernels

• snapshots now have a loopback.cfg

• which is handy for the new multi-usb script that now supporst just drag and drop the iso file and run the updater script to update grub

• the initramfs for devuan is now generated with dracut (as it is for void)

but there is still one thing i would like to add,
and that is for the multi-usb to have a live system with a persistent overlayfs
i thought dracut could help me out here but if i read the scripts correct, it requires systemd for this trick

so i guess my best bet is to just add my own script into the initramfs that checks if "live-overlay.img" file is present on the iso partition of the usb-stick and then mount the overlay and remount root. can anyone help me with this?

I don't use the one click open a folder or file, I did like it in vuudo I had never tired it before, but I would click things I did not mean to. In the default double click to open, the first click does display the size of a file down the bottom of the window but only the name for folders. Maybe, if you could try add the size next to the name in the bottom of the window for the default double click they might be more open to your icon suggestion.

Different topic, In gtk-greeter I could set my own wallpaper and icon in the login dialog box thingy. Do you know how to make the white background of the dialog box transparent? Is it possible? I'm using the default setup not your vuudo one. Everything I've tried has failed.

It seems I found a way, I misunderstood what I was seeing on the search engine.

I tried typing in sendkey ctrl alt f1 or something like that in qemu part and it worked.

That was a result I saw, but I misunderstood the sendkey part. where that was.

Here it is: https://sources.debian.org/src/getdns/1 … tubby.init

Also, what happened to the repository, was it deleted or relocated? If so, where is it?

I know of no OS that uses /opt according to older FSH documenation. There might be, but it's none of the BSDs, macOS or any Linux distribution that I have come across. That same site also has the section for /usr/local and describes its historic purpose and its use today.

Nowadays /opt is for software that fits the description "self contained binary distribution". e.g. the Mozilla Firefox binaries.

/usr/local is for software you compile locally and install into a structure that matches /usr . The idea there is that your locally compiled version doesn't clobber the version provided by the OS. This is exactly how FreeBSD and OpenBSD ports are installed.

So I'm not sure installing packages into /usr/local makes any sense.

If I'm going to go to great lengths to package something, then I'm going to install it into /usr and I'm going to ensure dependencies are handled, and that I have correct conflicts in place to ensure I'm not overwriting anything. However I might not do any of the above, and we're back to where we were 10 + years ago with those user created Ubuntu packages which were frowned on by Debian users. This is why the likes of flatpak and snap appeared...

Otherwise I'm not going to bother packaging it in the first place.

For those who don't know, Xearth is a program written in the 90's that generates a 3D image of the earth showing it's current position with shading for the sides where it's night. See the homepage of Xearth: https://xearth.org/

To build Xearth just download the source code tarball from the above link, apply the below patch (otherwise the build fails) and then run xmkmf and then make.

diff -uNr xearth-1.1-orig/gifout.c xearth-1.1-new/gifout.c
--- xearth-1.1-orig/gifout.c	1999-11-07 07:51:34.000000000 +0100
+++ xearth-1.1-new/gifout.c	2025-12-03 11:17:28.970312517 +0100
@@ -44,6 +44,7 @@
  */
 
 #include <stdio.h>
+#include <stdlib.h>
 #include "port.h"
 #include "gifint.h"
 #include "kljcpyrt.h"

After 'make' completes you will find the generated binary 'xearth' and the man page that you can copy to /usr/local/bin and /usr/local/man.

To actually use xearth as a desktop background in XFCE I added the following lines to /etc/rc.local:
(I chose /dev/shm as temp folder for the generated images as that's in RAM to reduce write cycles on the SSD)

# create initial xearth desktop background images
/usr/bin/su - user -c "/usr/local/bin/xearth -grid -ppm -size 1920,1080 > /dev/shm/desktop-01.ppm"
/usr/bin/ln -fs /dev/shm/desktop-01.ppm /dev/shm/desktop-02.ppm

Replace 'user' with you actual username that you use to login to your PC and adjust the size parameter to match your screen resolution.

Then add the following entry to the crontab of your user (again adjust the resolution to suit your screen):

*/5 * * * * /usr/local/bin/xearth -grid -ppm -size 1920,1080 > /dev/shm/desktop-01.ppm ; DISPLAY=:0.0 /usr/bin/xfdesktop -N

This will generate a new image every 5 minutes and refresh your desktop background with this newly generated image.

Last thing, you need to configure the Desktop Settings -> Background of XFCE as follows:

Folder: /dev/shm/
Style: Centered
Colour: Transparent
[X] Apply to all workspaces   (this is optional)
[X] Change the background [at start up]

And here is a screenshot of how it looks like (obviously the part of the earth seen changes over the course of the day and the earth axis inclination changes over the course of the year so this is simply a snapshot of how it looked like when I made the screenshot):
http://pkgrepo.linuxtech.net/files/Scre … xearth.png

Enjoy!