But it is far from neat enough to share for public use and the to-do-list is still long, so cleaning up has not reached top-prio.
I therefore applaud this effort to make knowledge available.

I will try to bring it to an usable form, in time. I have in mind users like me, that are new to Linux and Devuan especially, or migrated from another distribution and that want to know more about the Devuan Operating System, in general.
I know that Devuan has its own wiki, but it just doesn't fit for my project idea and also I don't like it, to be honest.

There are many good, general topics inside the forum that can have place in my devuan-knowledge_base. I will look for them and add them there.

So, who knows, maybe over one, two years if somebody from Devuan team consider that the content make sense for the general public, the repo will be always there.Just take the public folder, correct, throw away what is unecessary and that's all.
If somebody wants to have a look time to time, criticize, add corrections, ideas, etc. I would be glad to hear them. Is only one package to install.
But not so soon , there is nothing inside yet, just a sketch with some blank pages.

Finally, my strong opinion is that any good product needs to have a simple HandBook, accessible to anyone.

From the get-go, I was looking for a straightforward way to transfer files, preferably not involving Samba shares or complex server-client setups with encryption, compression etc. I researched several solutions, some of them seemed more feasible than others. To my surprise, finding a program capable of doing simple LAN transfers between different systems was not an easy task. Some of them could not be used because they were no longer supported on Windows 7 side, some worked but only one way (Win7 > Linux) because they detected wrong IP address due to a bug and had no manual way of setting up things. Some even required Internet access because they used a relay that could not be disabled!

Oh well. With patience and some trial and error, I eventually found a program called LanXchange, which works beautifully. It's not the prettiest or most featureful thing in existence, but it does its job very well.

To use it, you need to install Java Runtime Environment (JRE). You can get it via default-jre package in Excalibur repos, or from Eclipse Adoptium using this guide. I just got the repo version, while on Win7 I'm using the latter.

Unpack and launch LanXchange on both machines. On Windows, lxc.exe complained that I do not have Java installed, but the .jar file worked - so if you get the same error, just try that. On Linux side, use the provided lxc script. You can also run the .jar directly like this:

$ java -jar lanxchange.jar

but I noticed that it sometimes causes issues with incoming transfers not appearing until you unshare your previous files. Not a big problem, but I still recommend using the script.

Next, if you use a firewall like gufw, you will need to allow the following incoming ports: 27716, 27717, 27719. Create two separate 'Simple' rules both for TCP and UDP. On Windows, you probably don't need to do anything other than click 'Allow access' once.

So that's it! Now it should work - nothing beats sending files via a nice fat cable just like in the old days. Enjoy the speed and simplicity (and less wear for your USB Flash devices). Thanks to this wonderful program, I was able to forgo Samba entirely. I did not look into other solutions such as NFS, SFTP or a Python server - they do seem interesting though, so might experiment with them later as well.

It has on the desktop in prominent place :

* Release notes
* README_desktop-live.txt
* REAME.txt

Except from basic info they basically link to online help.

Devuan and Artix livecd that i tested they resort to plain text file as an entry help system. Interesting.

just to drop a note that, in recent versions or runit (currently in testing/unstable) I changed few bits in runit-heper and trigger_sv so that,
in order to disable a services you can just

touch /etc/service/.servicename

So you no longer have to create a .symlink, just touch a file with the service name with a leading dot; I hope that it makes easier to preseed and do custom setups

Best,
Lorenzo

OS ▸  Debian GNU/Linux Trixie x86_64
       BD++++D+D+::::::+D                               Kernel ▸  Linux 6.19.14-2-liquorix-amd64
      D+-::::=D+::::::::+BBDD+                          Uptime ▸  1 hour, 52 mins
     D=::::::=B=-::::::=BB++=+D                         Processes ▸  327
     D-:::::=BDD=-::-=+B=-::::=D                        Packages ▸  2217
     B+--==+++===++BDD+:::::::-D                        Window Manager ▸  dwm (XLibre)
   DB+++==:::::::::-+D-:::::::=D                        Shell ▸  zsh 5.9
  D=:::::::::::::::::++:::::-+D                         Terminal ▸  xterm 409
D+::::::::::::::::::+D++==+BD+                         Terminal Font ▸  JetBrains Mono Nerd Font:style=Regular (11pt)
  D=:::::::::::::::::+BD+=--:-+D                        Terminal Theme ▸  ● ● ● ● ● ● ● ●
   B+=-::::::::::::::B+-::::::=D                        Brightness ▸  100% [Built-in]
    DBB++-::::::::::-D:::::::-+D                        CPU ▸  12 x AMD Ryzen 7 7445HS
        DB+:::::::::+D=-:::-=+D                         GPU ▸  GeForce RTX 4050 Max-Q / Mobile
          D=:::::::-D +BDBBD+                           GPU ▸  AMD Radeon 740M Graphics
           B+--::-=D                                    RAM ▸  2.39 GiB / 14.88 GiB (16%)
            +BDBDD+                                     Swap ▸  0 B / 7.45 GiB (0%)
                                                        Disk ▸  1.09 TiB / 1.78 TiB (61%) - ext4

To answer a few questions I see in this thread.  For me XLibre performance is about 6-7% better than with non-XLibre.  Like many here, I am not a fan of Wayland- I ran it for a year to give it a test... and if I only ran a single wm without conky, I could make it work.  But I run with dwm,i3wm,openbox and choose not survive with a crippled conky (maybe its fixed these days; I don't know).   Should I use systemd... just to answer that item, I need my stupid VRAM (nVidia) to work because I run a local AI on my machine- for lots of reasons that would probably get this note thrown off here.  Suffice it to say, nVidia is necessary for resilience and grandsons- not optional and nVidia is also blindingly painful, but I have it working. Yay.

In general, the politics alluded to here re: XLibre are a pretty obvious issue for some folks.  I have not personally encountered any problems.  So, it's alright so far.  For any who would like to see my stupid-simple XLibre install it's freely available here: 

https://codeberg.org/eirenicon/dwm-XLibre

btw. it is worth every penny you paid for it, as well.

To be fair this is not a definitive protection but another countermeasure to reduce drastically the risks from such attacks when using public IPs.

# As a complementary measure you should NOT allow ssh root login using password but using ssh key in worst case escenario, to do that change the settings for sshd:

sudo nano /etc/ssh/sshd_config

# Uncomment the #PermitRootLogin line like:
PermitRootLogin prohibit-password

# Install packages:

sudo apt install -y fail2ban lnav python3-pyinotify

# Verify connection attemps

sudo lnav /var/log/auth.log

# You will see very often lines like:
<date> - <time> <hostname> sshd[pid]: Failed password for root from xxx.xxx.xxx.xxx port xxxx ssh2 <--- Brute force attack

# and also when you connect you will see a line like this:
<date> - <time> <hostname> sshd[pid]: Accepted publikey for <youruser> from <your.isp.public.ip> port xxxxx ssh2: EDxxxx <--- If you are using ssh keys instead of password this is you.
<date> - <time> <hostname> sshd-session[pid]: Accepted password for <youruser> from <your.isp.public.ip> port 39284 ssh2 <--- Or if you still using password authentication.
# We will whitelist this IP <your.isp.public.ip> just in case since we will use a very strict ban criteria/time.

# Press q to exit

# Create Local Configuration to preserve settings during updates.

sudo nano /etc/fail2ban/jail.local

# Configure SSH Protection, we will use 3 attemps to block earlier than 5 attemps and for 3 hours but later you can increase the bantime if you notice the same IP addresses repeating again and again:
[DEFAULT]
# Whitelist your own IP address (space-separated)
ignoreip = 127.0.0.1/8 ::1 <your.isp.public.ip>

[sshd]
backend = auto
enabled = true
maxretry = 3
bantime = 3h
findtime = 10m   

# Restart fail2ban service

sudo service fail2ban restart

# Verify ssh jail status

sudo fail2ban-client status sshd

# You will see something like:

Status for the jail: sshd
|- Filter
|  |- Currently failed:	1
|  |- Total failed:	5
|  `- File list:	/var/log/auth.log
`- Actions
   |- Currently banned:	6
   |- Total banned:	6
   `- Banned IP list:	2.57.122.189 2.57.122.192 45.148.10.147 45.148.10.151 45.148.10.157 92.118.39.236

   
# Now if you verify connection attemps again
sudo lnav /var/log/auth.log

You will notice the attemps wont repeat from the same IP since the moment fail2ban was restarted, keep it running and eventually they will realize is not worthy to keep trying or they will run out of public IPS or you can also increase the time if the same IP address keep showing up.

To add an extra layer of protection you can also enable 2FA with oathtool to make ssh ask for 6 digits code before you can enter any password, that way the attack never even begins since the client gets disconnected and banned when doens't provide a valid 6 digits code to begin with the login attemp, link to guide below.

[HowTo] 2FA TOTPs for SSH without google-authenticator.

Edited on April-29-2026, steps above tested on Devuan 5, but for Devuan 6 these 2 changes below are required:
Added package to install: python3-pyinotify
Added: backend = auto

Navigate to the upstream repository

Navigate to the Hyprshot GitHub repository for the source files and installation instructions. This guide is based on that repository, customized for Devuan.

Install dependencies

Install the dependencies mentioned in the Hyprshot repository, alongside the dunst notification daemon.

$ su -
# apt install jq grim slurp wl-clipboard libnotify-bin dunst
# exit

Creating the optimal directory for manually installed user scripts

For a manual installation (downloading the script directly), place it in a directory that is in your user's $PATH. The most common and recommended location is ~/.local/bin.

$ mkdir -p ~/.local/bin

If this directory does not exist or is not in your PATH, you will need to create it and add it to your shell's configuration file (e.g., ~/.bashrc or ~/.zshrc).

Clone Hyprshot source code into created directory

$ git clone https://github.com/Gustash/hyprshot.git ~/.local/bin/Hyprshot

Symbolically make the script executable

Create a symbolic link to make the script executable from anywhere.

$ cd ~/.local/bin
$ ln -s $(pwd)/Hyprshot/hyprshot $HOME/.local/bin
$ chmod +x Hyprshot/hyprshot

Restarting your system and testing the command

After completing the installation, restart your system to ensure all changes, environment variables, and the PATH are properly loaded.

$ su -
# reboot

To test Hyprshot, log in, open a terminal and run a command to capture a specific element, such as:

$ hyprshot -m window

This command will change your cursor, allowing you to click on any window to take a screenshot. If successful, the screenshot will be saved to your XDG_PICTURES_DIR (typically ~/Pictures) and copied to the clipboard. You can test other modes like -m region for a custom area or -m output for a full monitor.

Login as a root user

su - cleanly resets all environment variables, changes the working directory to the target user's home directory, and sources the target user's profile scripts, simulating a fresh login as root:

su -

Enable 32-bit architecture support

Steam requires 32-bit architecture support libraries and proprietary components, so enable it:

dpkg --add-architecture i386

Enable non-free & contrib repository sources

The Steam installer package resides in the contrib repository, and the non-free repository provides the essential 32-bit (i386) graphics drivers, Mesa libraries, and other hardware-specific components required for Steam to function and for games to run correctly. Ensure that both repositories are active in your sources list for your release. Depending on which source list is currently active on your PC, fill in the following information on one of these files:

1. Within /etc/apt/sources.list:

deb http://deb.devuan.org/merged ceres main non-free non-free-firmware contrib

2. Within /etc/apt/sources.list.d/devuan.sources:

# Modernized from /etc/apt/sources.list
Types: deb
URIs: http://deb.devuan.org/merged/
Suites: ceres
Components: main non-free non-free-firmware contrib
Signed-By: /usr/share/keyrings/devuan-archive-keyring.gpg

Update repositories and install Steam

After enabling the required repositories, update your package lists:

sudo apt update

Install the steam-installer package using:

sudo apt install steam-installer

Install and set up xwayland

The Steam client requires xwayland to run on a Wayland session because the Steam client itself is an X11-only application and lacks native Wayland support. If you're experiencing a display crash or the "Could not open connection to X" error, it's likely because Steam cannot connect to an X server. Currently, under a Wayland session, this is handled by xwayland, which acts as a compatibility layer allowing X11 applications like Steam to run.

Install xwayland via:

sudo apt install xwayland

Verify xwayland is active by running by printing the value of the $DISPLAY enviroment variable. This should return :0:

echo $DISPLAY

If the DISPLAY variable is not set, you can set it manually. The command export DISPLAY=:0 sets the DISPLAY environment variable to :0, telling graphical (a la X11) applications to render their graphical interface on the first local display (screen 0) of the local X server:

export DISPLAY=:0

Restart Wayland session

Restart your Wayland session to ensure xwayland starts with the compositor; an easy way to do that for Hyprland specifically would be:

hyprctl dispatch exit
dbus-run-session start-hyprland

Launch Steam

Finally, launch Steam from the application menu or via the terminal:

steam

By following these steps, you should be able to install and run Steam on your Devuan system using a Wayland-based desktop environment like Hyprland.

Kernel version: 6.12.48+deb13-amd64
Binary file: forgejo-13.0.3-linux-amd64
Partition scheme: / 12%, swap 12%, /home -1
Does these matters? I don't know but I have tried this steps only on systems having exactly the same specs like above, so if you get any error message related for example to swap memory and you have no swap then I won't know what to tell you but create a swap partition and try again.

# First, make sure the domain/host name on /etc/hosts it's like: IP <FQDN> <hostname>, for example for a local domain /etc/hosts should be like:
127.0.0.1    localhost
192.168.1.10 myhost.mydomain.home myhost
# Where 192.168.1.10 is the local network IP for your local forgejo host, to verify it then execute:

hostname -f

# The result should be for example:
myhost.mydomain.home
# This is a must since later we will use the variables FQDN and HOSTNAME to retreive those values automatically
# to generate the self signed cert and to avoid mistyping errors that could make the setup completely fail.

# Install dependencies

sudo apt install -y git git-lfs nginx openssl

# Download and install binary

wget https://codeberg.org/forgejo/forgejo/releases/download/v13.0.3/forgejo-13.0.3-linux-amd64
chmod +x forgejo-13.0.3-linux-amd64
sudo cp forgejo-13.0.3-linux-amd64 /usr/local/bin/forgejo
sudo chmod 755 /usr/local/bin/forgejo

# Create git user on the system. Forgejo will run as that user, and when accessing git through
# SSH (which is the default), this user is part of the URL (for example
# in: git clone git@git.example.com:YourOrg/YourRepo.git the "git" at the left of @ is the user you’ll create now).

sudo adduser --system --shell /bin/bash --gecos 'Git Version Control' \
  --group --disabled-password --home /home/git git

# Create the directory where Forgejo’s config, called app.ini it's stored in. Initially it needs to be writable by Forgejo,
# but after the installation you can make it read-only even for Forgejo because then it shouldn’t modify it anymore.

sudo mkdir -p /etc/forgejo/{ssl}
sudo chown -R root:git /etc/forgejo && sudo chmod -R 770 /etc/forgejo

# In this case, below will use the path "/home/git/" where Forgejo will store its data, including your repositories, 
# this in order to make it easier to preserve and backup when ussing separated /home partition and SQLite database,
# but that value can be modified to anything that suits best for you if you know what are you doing.

# Create Forgejo service file, copy and paste from #!/bin/sh line to "exit 0" line and save.

sudo nano /etc/init.d/forgejo

#!/bin/sh
### BEGIN INIT INFO
# Provides:          forgejo
# Required-Start:    $remote_fs $network $syslog
# Required-Stop:     $remote_fs $network $syslog
# Should-Start:      $local_fs
# Should-Stop:       $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Forgejo Git server daemon
# Description:       Starts, stops, and manages the Forgejo service.
### END INIT INFO

# Where Forgejo lives (binary, config, data)
FORGEJO_ROOT="/home/git/lib/forgejo"
FORGEJO_BINARY="/usr/local/bin/forgejo"
FORGEJO_WORK_DIR="/home/git/lib/forgejo"
FORGEJO_USER="git"
FORGEJO_GROUP="git"

# Config file
FORGEJO_CONFIG="/etc/forgejo/app.ini"

# Log files – same locations used by the systemd unit
FORGEJO_LOG_DIR="${FORGEJO_ROOT}/log"
STDOUT_LOG="${FORGEJO_LOG_DIR}/stdout.log"
STDERR_LOG="${FORGEJO_LOG_DIR}/stderr.log"

# PID file – used for status checks and clean shutdowns
PIDFILE="/var/run/forgejo.pid"

# Extra flags you might want to pass (e.g., --config)
DAEMON_OPTS="web --config ${FORGEJO_CONFIG}"

log_msg() {
    echo "[forgejo] $*"
}

# Ensure the binary exists before we try anything
[ -x "${FORGEJO_BINARY}" ] || {
    log_msg "Executable not found at ${FORGEJO_BINARY}. Aborting."
    exit 1
}

# Create log directory if missing
[ -d "${FORGEJO_LOG_DIR}" ] || mkdir -p "${FORGEJO_LOG_DIR}"
chown ${FORGEJO_USER}:${FORGEJO_GROUP} "${FORGEJO_LOG_DIR}"

do_start() {
    log_msg "Starting Forgejo…"
    # Run as the dedicated user, detach, and capture PID
    start-stop-daemon --start \
        --quiet \
        --background \
        --make-pidfile \
        --pidfile "${PIDFILE}" \
        --chuid "${FORGEJO_USER}:${FORGEJO_GROUP}" \
        --exec "${FORGEJO_BINARY}" \
        -- ${DAEMON_OPTS} >>"${STDOUT_LOG}" 2>>"${STDERR_LOG}"
    RET=$?
    [ $RET -eq 0 ] && log_msg "Forgejo started (PID $(cat ${PIDFILE}))"
    return $RET
}

do_stop() {
    log_msg "Stopping Forgejo…"
    if [ -f "${PIDFILE}" ]; then
        PID=$(cat "${PIDFILE}")
        start-stop-daemon --stop --quiet --pid "${PID}" --retry=TERM/30/KILL/5
        RET=$?
        [ $RET -eq 0 ] && rm -f "${PIDFILE}" && log_msg "Forgejo stopped"
    else
        log_msg "No PID file found – is Forgejo already stopped?"
        RET=1
    fi
    return $RET
}

do_restart() {
    do_stop && do_start
}

do_status() {
    if [ -f "${PIDFILE}" ]; then
        PID=$(cat "${PIDFILE}")
        if kill -0 "$PID" 2>/dev/null; then
            echo "Forgejo is running (PID $PID)"
            return 0
        else
            echo "Forgejo PID file exists but process is dead"
            return 1
        fi
    else
        echo "Forgejo is not running"
        return 3
    fi
}

case "$1" in
    start)
        do_start
        ;;
    stop)
        do_stop
        ;;
    restart|force-reload)
        do_restart
        ;;
    status)
        do_status
        ;;
    *)
        echo "Usage: $0 {start|stop|restart|status}"
        exit 2
        ;;
esac

exit 0

# Make it executable

sudo chmod +x /etc/init.d/forgejo

# Enable the service auto-start at boot

sudo update-rc.d forgejo defaults

# Generate self signed cert and key

sudo openssl genrsa -out /etc/nginx/ssl/$(hostname).key 4096
sudo openssl req -x509 -new -nodes -key /etc/nginx/ssl/$(hostname).key -sha256 -days 365 -subj "/CN=$(hostname -f)" -reqexts v3_req -extensions v3_ca -out /etc/nginx/ssl/$(hostname).crt

# Change cert and key group permissions but maintaining root ownership

sudo chgrp git /etc/nginx/ssl/$(hostname).crt
sudo chmod 644 /etc/nginx/ssl/$(hostname).crt
sudo chgrp git /etc/nginx/ssl/$(hostname).key
sudo chmod 600 /etc/nginx/ssl/$(hostname).key

# Prevent git error: server verification failed: certificate signer not trusted for your local repo/server

git config --global http."https://$(hostname -f)/".sslCAInfo /etc/nginx/ssl/$(hostname).crt

# Copy the new certificate system wide (optional):

sudo cp /etc/nginx/ssl/$(hostname).crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

# To prevent error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413

sudo nano /etc/nginx/nginx.conf

# Add this line inside the "http {" block

        # To prevent error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 41
        client_max_body_size 500M;  # Increase limit from default 1MB to 500M

# Create the initial forgejo settings: copy, paste and enter (to pass the hostname values).

sudo tee /etc/forgejo/app.ini > /dev/null <<'EOF'
[server]
PROTOCOL                   = http
DOMAIN                     = $(hostname -d)
ROOT_URL                   = https://$(hostname -f)
APP_DATA_PATH              = /home/git/data
LOCAL_ROOT_URL             =

[session]
COOKIE_SECURE              = true
EOF

# Change /etc/forgejo/app.ini ownership

sudo chown git:git /etc/forgejo/app.ini
sudo chmod 644 /etc/forgejo/app.ini

# Create the NGINX site configuration: copy, paste, press enter.

sudo tee /etc/nginx/sites-available/forgejo.conf > /dev/null <<'EOF'
# --------------------------------------------------------------
# HTTP → HTTPS redirect (listen on port 80)
# --------------------------------------------------------------
server {
    listen 80;
    listen [::]:80;
    server_name $(hostname -f);
    
    # Redirect every request to the same URL but with https
    return 301 https://$host$request_uri;
}

# --------------------------------------------------------------
# TLS termination + reverse‑proxy to Forgejo (listen on 443)
# --------------------------------------------------------------
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name $(hostname -f);

    # ----- TLS certificates -----
    ssl_certificate     /etc/nginx/ssl/$(hostname).crt;
    ssl_certificate_key /etc/nginx/ssl/$(hostname).key;

    # ----- Recommended SSL settings (Mozilla intermediate profile) -----
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    ssl_session_timeout 1d;
    ssl_session_cache   shared:SSL:10m;

    # ----- HSTS (force browsers to stay on HTTPS) -----
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # ----- Proxy settings -----
    location / {
        # Forgejo runs internally on HTTP port 3000 (unchanged)
        proxy_pass http://127.0.0.1:3000;

        # Preserve original host and scheme for Forgejo’s own link generation
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Optional: increase timeout for large git pushes
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }

    # ----- Optional: static assets cache (speed up UI) -----
    location ~* \.(css|js|png|jpg|jpeg|svg|ico|woff2?)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
        try_files $uri @forgejo;
    }

    # Fallback to the main proxy block if the static file isn’t found
    location @forgejo {
        proxy_pass http://127.0.0.1:3000;
    }
}
EOF

# Enable the site & test the NGINX config

sudo ln -sf /etc/nginx/sites-available/forgejo.conf /etc/nginx/sites-enabled/

# Test syntax (very important!)

sudo nginx -t

# You should see:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

# Open firewall ports (if applicable)
# If you have ufw, firewalld, or a cloud‑provider security group, allow only 80 and 443 inbound:

# UFW example

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# (Optionally deny direct access to 3000 from outside)

sudo ufw deny 3000/tcp

# For firewalld:

sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --add-service=https --permanent
sudo firewall-cmd --remove-port=3000/tcp --permanent   # optional
sudo firewall-cmd --reload

# Start both services

sudo service forgejo start
sudo service nginx start

# Finally, open your browser and go to http://<FQDN_here> to finish the setup.
# Yes, of course you will get the warning of self signed cert but other than that everything will work as intended.