Devuan Beowulf, like Debian Buster is the stable version, so doesn't get the latest and shiniest version of applications automatically.

Mint and Ubuntu are based on the unstable versions. If you really want new and shiny in everthing then you need to upgrade to Ceres.

Beowulf does however receive any security fixes, albeit with a slight delay, which isn't always bad since security fixes can also have bugs (vide the latest fiasco with grub).

For example the version of Firefox supplied on Devuan is Firefox-esr (the 'enterprise' version), which only resyncs with the latest Firefox once a year. However it does get all the monthly security fixes inbetween. At the moment, although there is a  newly resyced version we will continue to get the security fixed older version for an overlap period.

You can configure Devuan to install updates automatically using the unattended-upgrades package.
This can be configured to run daily from cron, or if you don't keep your computer on all the time but hibernate or suspend , from anacron. which runs a daily check and conditional install when you first resume. You get a email notification if it upgrades anything. I use it but only for security upgrades.

There is also a notifier package (not part of the official Devuan repositories) written by MiyoLinux (see https://dev1galaxy.org/viewtopic.php?pid=22152#p22152) that notifies you, and allows you to install upgrades. It's not quite as slick as the applets in Mint and Ubuntu but is quite flexible. However it doesn't yet work in Ceres: another example of how the Unstable version may break things.

Also if you find you really need a feature in a more recent version you can often get something newer from backports. I  use a LibreOffice backport as its an application where I'm always looking for new shiny but wouldn't search for a postfix backport as I value the stability of the latter. I did backport dnscrypt-proxy as I needed a fix in a feature I used and the backport had it.

Bit surprised by you find that

as that's not my experience with either Ascii or Beowulf (albeit I use Cinnamon rather than Xfce). Which hardware is your system not recognising?

My own choice is to use dnscrypt-proxy, which:

1) Gives you a wide choice of DNS provider, including Cloudflare, using either DoH or Dnscrypt. You can choose from a large number of non-logging (or at least services that say they are) and/or DNSSEC and/or filtered/non-filtered DNS providers.

2) You get periodically to randomise your DNS provider, so no one service sees it all.

3) You will usually choose nearer DNS providers with a lower RTT than Cloudflare (at least here where Ii am in the UK).

4) You can cache your queries, reducing what hits your provider and proving near-instant lookups on your most used sites.

5) You can select from multiple blocklists.

6) it works for all your internet traffic, not just your browser. On mine I also provide a DNS service for other nodes on my network.

7) In the latest versions you can set up a (set of) DNS relays between you and the DNS provider, which masks your IP from them and your query form the relays.

In Firefox (about:config) you set your Network.TRR.mode to 5, so bypass the internal DoH with /etc/resolv.conf pointing to your dnscrypt-proxy. There is also an option that allows you to provide a DoH server for Firefox, which then connects to the internet using any of the other dnscrypt-proxy options.

Just to provide another example.

Beowulf/Cinnamon, default terminal is gnome-terminal and I've not noticed any issues using it (including a display from the xpra server over ssh on another machine), but I'm running it from an applet, so I don't see any messages.

However:

marjorie@grendel:~$ gnome-terminal
# watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0)
# unwatch_fast: "/org/gnome/terminal/legacy/" (active: 0, establishing: 1)
# watch_established: "/org/gnome/terminal/legacy/" (establishing: 0)

and child terminal opens OK.

marjorie@grendel:~$   

And then as sudo:

marjorie@grendel:~$ sudo gnome-terminal
# posix_spawn avoided (fd close requested) 
# watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0)
# unwatch_fast: "/org/gnome/terminal/legacy/" (active: 0, establishing: 1)
# watch_established: "/org/gnome/terminal/legacy/" (establishing: 0)

and child terminal opens OK as root in my home directory.

root@grendel:/home/marjorie#      

I don't have ash, nor xterm for that matter.

Logged on this afternoon and unattended-upgrade has just updated grub-common.

Start-Date: 2020-07-31  12:10:26                                       
Commandline: /usr/bin/unattended-upgrade
Requested-By: marjorie (1000)
Upgrade: grub-common:amd64 (2.02+dfsg1-20+deb10u1, 2.02+dfsg1-20+deb10u2)
End-Date: 2020-07-31  12:10:28 

Maybe this fixes the problem?

https://linuxsecurity.com/advisories/de … e-17-52-37

Package        : grub2
Debian Bug     : 966554

The update for grub2 released as DSA 4735-1 caused a boot-regression
when chainloading another bootlaoder and breaking notably dual-boot with
Windows. Updated grub2 packages are now available to correct this issue.

For the stable distribution (buster), this problem has been fixed in
version 2.02+dfsg1-20+deb10u2.

We recommend that you upgrade your grub2 packages.

For the detailed security status of grub2 please refer to its security
tracker page at:
https://security-tracker.debian.org/tracker/grub2

Oddly 'grub-common' is the only grub package I have on this PC, my other (my mail server) has 'grub-common', 'grub2-common', 'grub-pc' and and 'grub-pc-bin'. Both were fresh Beowulf Beta installs.

As I understand it the correct way is to re-build the .deb package from the source using deb_helper.
There a tutorial on the overall process here: https://wiki.debian.org/BuildingTutorial.
Though the tutorial uses an example where you want to change the source code (and recompile) not just the packaging.

Essentially to create a Devuan compatible .deb you need to:
1) add a suitable init script to the files tree (your /etc/init.d/zoneminder). As has been pointed out by Head_on_a_Stick you can generate one from the systemd service file using the sysv2d.sh script.
2) Adding a Debian rule to generate the sysvinit additions to the postinst and postrm scripts.
The rule will be a parametrisation of the deb helper program dh_installinit.
3) Change the version number and annotate the change.
4) If you then want to submit as a bug to Debian create a diff on the original and submit  it with the bug report.

When you've recreated your .deb you might see in your postinst file something like this :

# Automatically added by dh_installinit/12.1.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
	if [ -x "/etc/init.d/chrony" ]; then
		update-rc.d chrony defaults >/dev/null
		if [ -n "$2" ]; then
			_dh_action=restart
		else
			_dh_action=start
		fi
		invoke-rc.d --skip-systemd-native chrony $_dh_action || exit 1
	fi
fi
# End automatically added section

This example (for chrony) enables (using update-rc.d) and starts (using invoke-rc.d) the init.

The corresponding addition to postrm is:

# Automatically added by dh_installinit/12.1.1
if [ "$1" = "purge" ] ; then
	update-rc.d chrony remove >/dev/null
fi
# End automatically added section

However some maintainers don't provide an init file and don't run dh_installinit, which is where we get problems.

Here is an example of the rules for another deb (nftables) that doesn't. As you can see, dh_installinit is called but just with the -n parameter and so doesn'r run. Run without any parameters it will create the postinst code to enable and start the init and the postrm code to remove it. For some programs you might not want to have enable or start (in this case for dh_installsystemd they are turned off by parameters --no-enable- -no-start).

#!/usr/bin/make -f

ifeq (,$(filter terse,$(DEB_BUILD_OPTIONS)))
export DH_VERBOSE=1
endif
export PYBUILD_NAME = nftables
export DEB_BUILD_MAINT_OPTIONS = hardening=+all

configure_opts	:= --with-xtables --with-json --with-python-bin=/usr/bin/python3

override_dh_auto_configure:
	dh_auto_configure -- $(configure_opts) --

%:
	dh $@ --with python3

override_dh_fixperms:
	dh_fixperms
	chmod a+x debian/nftables/etc/nftables.conf

override_dh_installsystemd:
	dh_installsystemd --no-enable --no-start

override_dh_installinit:
	# dh_installinit will try to mess with /etc/init.d/nftables in
	# the maintainer scripts, but we don't ship it
	dh_installinit -n

override_dh_installexamples:
	dh_installexamples -XMakefile
	# upstream examples are installed in by the 'install' target to '/etc/nftables'
	mv debian/tmp/etc/nftables/*.nft debian/nftables/usr/share/doc/nftables/examples/
	rm -rf debian/nftables/etc/nftables

Amen.

If you're a system admin and don't want to use/don't have a root login/ password (I don't) then open a user terminal and type:

~$ sudo nemo

or whatever's your graphical file manager and then at the prompt enter your user password..
This work just as well.

nb. I use Cinnamon (I'm another pre-systemd Mint refugee) so my main file manager is nemo and my file editor is gedit.

I find this a particularly useful way of finding my way around/editing system files when I've ssh -X in order to work on a remote PC.

Then copy your_init_script to /etc/init.d/ Make it executable (+x). Change the owner:group to root:root.

You'll then need to run:

sudo update-rc.d your_init_script defaults

to set up the /etc/rc* files (which are symlinks back to your_init_script)

and

sudo invoke-rc.d your_init_script start

to start the daemon immediately.

sudo service your_init_script start

should also work.

Is this a re-emergence in the new kernel of this reported bug in Debian Buster, which has never seemed to be an issue in Beowulf?

source: https://www.debian.org/releases/buster/ … starvation

to save seaching for it, it's here:

https://distrowatch.com/weekly.php?issu … 622#devuan

I had this problem with nvidia-persistenced back in April when I upgraded to Beowulf-Beta.

It's caused by an error in etc/init.d/nvidia-persistenced that happens when it is started and there is already another copy running.

nvidia-persistenced is not really needed unless you use CUDA.

If you's rather keep it you can patch it so that it doesn't misbehave (with the patch it checks if there is already a copy running and just exits if there is).

See https://dev1galaxy.org/search.php?actio … w_as=posts for details.

My patched version is in post #3, also shown below:

#!/bin/sh -e
#
# NVIDIA Persistence Daemon Init Script
#
# Copyright (c) 2013 NVIDIA Corporation
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
#
# This is a sample System V init script, designed to show how the NVIDIA
# Persistence Daemon can be started.
#
# This sample does not rely on any init system functions, to ensure the
# widest portability possible.
#
# chkconfig: 2345 99 01
# description: Starts and stops the NVIDIA Persistence Daemon
# processname: nvidia-persistenced
#
### BEGIN INIT INFO
# Provides:         nvidia-persistenced
# Required-Start:   $local_fs
# Required-Stop:    $local_fs
# Default-Start:    2 3 4 5
# Default-Stop:     0 1 6
# Short-Description: Starts and stops the NVIDIA Persistence Daemon
# Description:      Starts and stops the NVIDIA Persistence Daemon
### END INIT INFO

NVPD=nvidia-persistenced
NVPD_BIN=/usr/bin/${NVPD}
NVPD_RUNTIME=/var/run/${NVPD}
NVPD_PIDFILE=${NVPD_RUNTIME}/${NVPD}.pid
NVPD_USER=nvpd
NVPD_ACTION=${1}

# Gracefully exit if the package has been removed.
test -x $NVPD_BIN || exit 0

# Get the value of the PID
if [ -f ${NVPD_PIDFILE} ]; then
 read -r NVPD_PID < "${NVPD_PIDFILE}"
# Is the daemon already running?
 if [ "${NVPD_PID}" ] ;then 
  if [ -d /proc/${NVPD_PID} ]
# Daemon is running, so stop it then start a new instance
   then
    case "${1}" in
     start)
      echo "NVIDIA Persistence Daemon already running" 
      NVPD_ACTION=restart
      ;;
     *)
      ;;
    esac
# Daemon not running, but there is a stale PID
   else
    echo "NVIDIA Persistence Daemon, stale PID removed"			
    unset NVPD_PID
    rm -rf "${NVPD_RUNTIME}"
  fi
 fi
fi

case "${NVPD_ACTION}" in
 start)
  echo "Starting NVIDIA Persistence Daemon"
# Execute the daemon as the intended user
  ${NVPD_BIN} --user ${NVPD_USER}
  ;;
 stop)
   echo "Stopping NVIDIA Persistence Daemon"
# Stop the daemon - its PID should have been read in
   [ ! -z "${NVPD_PID}" ] && kill ${NVPD_PID} &> /dev/null
    ;;
  restart)
   $0 stop
   sleep 2
   $0 start
    ;;		
  *) echo "usage: $0 {start|stop|restart}"
    ;;
esac

exit 0

The "Windows Quick List" applet in Cinnamon shows this information (list of names and an icon, by Workspace).
I've never found any source code for these applets though.