There is an /etc/cron.daily program 'popularity contest' that logs and reports weekly which packages you have/use.

It is optional (you can turn it off) and anonymous in intent.

Firefox can be configured to provide telemetry (but you can turn it off) and it can check for updates to add-ons you have installed (also optional). You can install  other browsers that promise more.

To can install programs or configure your browser to encrypt DNS queries, so you only share them with your chosen DNS provider (but you still have to trust them not to log, etc). I use dnscrypt-proxy.

Works for me, but I had to install the wmctrl package as it's not there by default.

user@hostname
-------------------------------------
os:   	Devuan GNU/Linux 3 (beowulf)
kernel:	4.19.0-9-amd64
uptime:	22 hours, 44 minutes
pkgs: 	2102
memory:	3.1Gi / 7.8Gi
wm:   	Mutter
shell:	/bin/bash
editor:	/usr/bin/gedit

Apparmor profiles are only provided for processes that are recognized as potentially dangerous and Apparmor confinement is provided to make your computer safer.

If you do a default Beowulf install you get at default set of profiles that are known to work, or they may be provided with additional packages/programs you install. I've installed LibreOffice from backports and the Firejail package, that is explicitly provided to create a jail for Firefox. These profiles are the one you see in my previous Apparmor status reports.

Profiles that are more experimental that are not guaranteed to work are provided set to complain mode so they don't break anything but you can still use/test them and see what apparmor complains about in the logs.

The Debian package apparmor-profiles provides various experimental Apparmor profiles. It says do not expect them to work out-of-the-box. The package description says "These profiles are not mature enough to be shipped in enforce mode by default on Debian (and hence Devuan). They are shipped in complain mode so that users can test them, choose which are desired, and help improve them upstream if needed". Some even more experimental profiles are included in apparmor-profiles-extras.

Having now installed these optional profile packages the number applied in enforce or complain does not change because they are not being used. Some relate to programs I don't use on my PC (e.g pidgin), some are simply not being used at the moment (e.g. ping, avahi-daemon).

Not every program/process has an Apparmor profile. There is one for Thunderbird (as i don't use this I've moved it to /etc/apparmor.d/disable) but there isn't (to my knowledge) one for Evolution, a program I do use and is running at the moment. Also some programs (such as ping) may only run momentarily so you won't be able to see it enforced/complaining in a status report without opening a second xterm and timing it right.

Here's my apparmor status report with the two experimental profile packages installed:

$ sudo service apparmor status
[sudo] password for marjorie: 
apparmor module is loaded.
46 profiles are loaded.
28 profiles are in enforce mode.
   /usr/bin/evince
   /usr/bin/evince-previewer
   /usr/bin/evince-previewer//sanitized_helper
   /usr/bin/evince-thumbnailer
   /usr/bin/evince//sanitized_helper
   /usr/bin/man
   /usr/bin/pidgin
   /usr/bin/pidgin//sanitized_helper
   /usr/bin/totem
   /usr/bin/totem-audio-preview
   /usr/bin/totem-video-thumbnailer
   /usr/bin/totem//sanitized_helper
   /usr/lib/cups/backend/cups-pdf
   /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session
   /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium
   /usr/sbin/apt-cacher-ng
   /usr/sbin/cups-browsed
   /usr/sbin/cupsd
   /usr/sbin/cupsd//third_party
   /usr/sbin/tcpdump
   firejail-default
   libreoffice-senddoc
   libreoffice-soffice//gpg
   libreoffice-xpdfimport
   man_filter
   man_groff
   nvidia_modprobe
   nvidia_modprobe//kmod
18 profiles are in complain mode.
   /usr/bin/irssi
   /usr/sbin/dnsmasq
   /usr/sbin/dnsmasq//libvirt_leaseshelper
   avahi-daemon
   identd
   klogd
   libreoffice-oopslash
   libreoffice-soffice
   mdnsd
   nmbd
   nscd
   ping
   smbd
   smbldap-useradd
   smbldap-useradd///etc/init.d/nscd
   syslog-ng
   syslogd
   traceroute
5 processes have profiles defined.
5 processes are in enforce mode.
   /usr/sbin/cups-browsed (2141) 
   /usr/sbin/cupsd (2109) 
   /usr/lib/cups/notifier/dbus (2110) /usr/sbin/cupsd
   /usr/lib/cups/notifier/dbus (2111) /usr/sbin/cupsd
   /usr/lib/cups/notifier/dbus (3262) /usr/sbin/cupsd
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

Beowulf is now 'stable', and Ascii 'oldstable' so you might well find that upgrading is a good idea.
Not sure what the effect of upgrading an only partially working apparmor will be on apparmor. I did a clean install and then restored my /home directory.

Anyway this is my status report in Beowulf. It says there are no processes unconfined that have a profile defined.

$ sudo service apparmor status
apparmor module is loaded.
23 profiles are loaded.
21 profiles are in enforce mode.
   /usr/bin/evince
   /usr/bin/evince-previewer
   /usr/bin/evince-previewer//sanitized_helper
   /usr/bin/evince-thumbnailer
   /usr/bin/evince//sanitized_helper
   /usr/bin/man
   /usr/lib/cups/backend/cups-pdf
   /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session
   /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium
   /usr/sbin/cups-browsed
   /usr/sbin/cupsd
   /usr/sbin/cupsd//third_party
   /usr/sbin/tcpdump
   firejail-default
   libreoffice-senddoc
   libreoffice-soffice//gpg
   libreoffice-xpdfimport
   man_filter
   man_groff
   nvidia_modprobe
   nvidia_modprobe//kmod
2 profiles are in complain mode.
   libreoffice-oopslash
   libreoffice-soffice
3 processes have profiles defined.
3 processes are in enforce mode.
   /usr/sbin/cups-browsed (2095) 
   /usr/sbin/cupsd (2065) 
   /usr/lib/cups/notifier/dbus (3187) /usr/sbin/cupsd
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

I can't see any way of doing this in synaptic, however

from an answer on the DNG list you can do it using apt:

$ sudo apt update

and, when asked, answer 'yes' for each source.

$ sudo apt update
[sudo] password for marjorie: 
Hit:1 https://updates.signal.org/desktop/apt xenial InRelease
Get:2 https://mirror.ungleich.ch/mirror/packages/devuan/merged beowulf InRelease [25.6 kB]
Get:3 https://mirror.ungleich.ch/mirror/packages/devuan/merged beowulf-security InRelease [25.6 kB]
Get:4 https://mirror.ungleich.ch/mirror/packages/devuan/merged beowulf-updates InRelease [25.6 kB]
Get:5 https://mirror.ungleich.ch/mirror/packages/devuan/merged beowulf-backports InRelease [25.6 kB]
E: Repository 'https://mirror.ungleich.ch/mirror/packages/devuan/merged beowulf InRelease' changed its 'Suite' value from 'testing' to 'stable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository? [y/N] y
E: Repository 'https://mirror.ungleich.ch/mirror/packages/devuan/merged beowulf-security InRelease' changed its 'Suite' value from 'testing-security' to 'stable-security'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository? [y/N] y
E: Repository 'https://mirror.ungleich.ch/mirror/packages/devuan/merged beowulf-updates InRelease' changed its 'Suite' value from 'testing-updates' to 'stable-updates'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository? [y/N] y
E: Repository 'https://mirror.ungleich.ch/mirror/packages/devuan/merged beowulf-backports InRelease' changed its 'Suite' value from 'testing-backports' to 'stable-backports'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository? [y/N] y
Get:6 https://mirror.ungleich.ch/mirror/packages/devuan/merged beowulf-backports/main Sources [243 kB]
Get:7 https://mirror.ungleich.ch/mirror/packages/devuan/merged beowulf-backports/main amd64 Packages [297 kB]
Fetched 591 kB in 26s (22.8 kB/s) 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
42 packages can be upgraded. Run 'apt list --upgradable' to see them.

Sorry to hear of all your difficulties - this shouldn't be happening.

From your latest report you now seem to be getting stuck at an earlier stage than you did before. Previously it seemed to be a problem with the Nouveau video driver, which LarsH is now reported wont work with your new NVIDIA GPU and has suggested a fix to get you to a console.

FWIW I've now installed Beowulf on two different AMD-64 PCs, one Intel and the other AMD (with NVIDIA graphics)  and did not have the particular problems you are now reporting, though to be fair my components are not cutting edge like yours. One of these was an entirely new install and the other was alongside an existing ascii installation.

1) I've always gone for legacy bios. Worked both times. My older motherboard has EFI but not UEFI. With the newer one I had choice in the the BIOS.

2) I've never actually installed from the live ISO, just used to check that I could boot into Beowulf (and get the WiFi working). The live install (if that is what you are using) is designed to be straightforward and therefore pretty unbreakable for a straightforward one-disk install but I'm not aware of exactly what choices it makes for you.

3) if you are using one of the other installers they can get more complicated and there is greater scope to be confused.

However:

3) You don't have to install /boot on a separate partition. It may be a bit more robust to do so if you have more than OS installed or your disk config is complex. On one of of mine I choose to keep it separate/simple because my root and /home partition are mounted as RAID1, on the other because they are LVM.

4) The boot partition doesn't have to be formatted DOS or even EXT2. Both mine are EXT4.

5) The installers themselves haven't changed between ASCII and Beowulf. I note that other users have been finding some bugs in the isos, particularly if burnt to optical CD/DVD, rather than USB, which the developers are fixing, but these are mostly pretty minor.

6) As you're getting inconsistent results it may be worth confirming (if you haven't already done so) that you isos have not got corrupted.

OK, so you're installing on a different machine than you installed Devuan ASCII on. It could be helpful to tell us what the hardware is:

Processor, UEFI/Legacy BIOS, 32 or 64 bit, Memory, Disk(s) type, Graphics card/adapter, Wireless card.

If you had used the same machine then it is unlikely that the hardware (that worked with ASCII) wouldn't work with Beowulf.  Not saying you shouldn't install on a fresh machine.

As you have installed on a different machine then booting up the live CD/usb will allow you to see whether the standard-case Beowulf installation software is compatible with the hardware (graphics, wireless card, etc.) you have on it. You should be able to boot to a graphical screen and (attempt to) configure your wifi
.
It's up to you then, if it works, whether you install from the live CD/usb. If the wireless doesn't work, once configured i.e. you still need additional drivers, and you can't use ethernet then the live CD/usb is not a good idea (nor the netinstall iso).

Also the live CD/usb is limited to a simple, whole disk install and it starts up in XFCE, which may differ from what you want/have been trying to install.

You haven't said which Beowulf iso you have been trying to use:
Beowulf is still Beta. There are now several generation of Beta, the latest is 3, which fixes some of the problems in the earlier versions.
There are also different ISO. The Live iso, the Netinstall iso, the basic (CD1+some of CD2-4) desktop isos and the full (DVD) desktop iso. https://beta.devuan.org/os/documentatio … all-devuan.

Great - we have progress.

You haven't said what your setup is. On mine I could get suspend (pm-suspend) working on both ASCII and Beowulf but, by default, hibernate (pm-hibernate) didn't work on Beowulf.

There is a 'hibernate' option on my standard logout, which I think uses upower, however it doesn't work on Beowulf. It did work and didn't interfere on my ASCII installation.

Anyway on Beowulf I fixed pm-hibernate by installing the uspsusp package, which provides user space rather than kernel hibernation and then configured pm-utils to use it.

Have a look in your /etc/pm/config.d/defaults file. Mine looks like this:

##########################################################
# DO NOT EDIT THE FILE in /usr/lib/pm-utils/             #
#                                                        #
# Edit this in /etc/pm/config.d/ instead!                #
##########################################################

# Default method to power down the system when hibernating.
# If commented out, the system will use the kernel default as a 
# default value.
#
# Check /sys/power/disk for valid values.  The default value
# will be surrounded by [square brackets].
HIBERNATE_MODE="platform"

# Whether we need to post the video card when resuming from
# hibernate. You should not normally need to set this.  
# In the future pm-utils will get this setting from HAL.
#
# Valid values are "no" and "yes"
# HIBERNATE_RESUME_POST_VIDEO="no"

# The default sleep/wake system to use.  Valid values are:
#   kernel    The built-in kernel suspend/resume support.
#             Use this if nothing else is supported on your system.
#   uswsusp   If your system has support for the userspace
#             suspend programs (s2ram/s2disk/s2both), then use this.
#   tuxonice  If your system has support for tuxonice, use this.
#
# The system defaults to "kernel" if this is commented out.
SLEEP_MODULE="uswsusp"

# These variables will be handled specially when we load files in 
# /etc/pm/config.d.
# Multiple declarations of these environment variables will result in 
# their contents being concatenated instead of being overwritten.

# If you need to unload any modules to suspend/resume, add them here.
SUSPEND_MODULES="ath9k ath9k_common ath9k_hw ath"

# If you want to keep hooks from running, add their names here.
# HOOK_BLACKLIST=""

# If you want to unconditionally add parameters to the commandline,
# add them here.
# ADD_PARAMETERS=""

# If you want to ignore commandline parameters, add them here.
# DROP_PARAMETERS=""

# If you need to synchronize the system clock across a suspend/resume or
# hibernate/thaw cycle, set this variable.
# NEED_CLOCK_SYNC="true"

In line 30 I've uncommented SLEEP_MODULE="uswsusp", which means that it now uses uwsusp rather than the kernel. I've left everything else as is, apart from lower down, where I unload my atheros wifi drivers as they refuse to power down when asked: however this is not needed to make hibernate work, even on my setup. Elsewhere I've also added a call to load a login screesaver, which does increase security a bit on resume. If you get hibernate working I'll tell you how to do this.

Lets see if that works better.

If not you may want to look at alternatives to HIBERNATE_MODE="platform" and/or install and try tuxonice as an alternative to uspsusp.

Sorry I previously mentioned pm-tools package. Of course that is pm-utils, but I guess you found that anyway.

I presume pm-suspend is also not working for you?

You should check /var/log/pm-suspend.log to see if it tells you anything about why it's not running (the log is common to both suspend and to hibernate). If its not there then something is very amiss.

Are you running it as root?

# sudo pm-hibernate

I run it as a drop down option on my desktop, so have added it to my sudoers file so I don't need to ask for my password.

I'm setting up a mailserver and I'm trying to use nftables on Beowulf rather than iptables and ufw.as I used to on ASCII.

Assuming I want to start nftables as a service (in the same way that systemd imitates). I would have to change this slightly:

$ sudo cp /usr/share/doc/nftables/examples/sysvinit/nftables.init /etc/init.d/nftables
$ sudo chmod +x  /etc/init.d/nftables
$ sudo update-rc.d nftables defaults

When I run

$ sudo service nftables start

and then

$ sudo service nftables status 

there's no output from either and the process is not running.

I looks to me that the problem is that nftables, as supplied, isn't configured to start in any level:

/etc/init.d/nftables starts:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          nftables
# Required-Start:    $local_fs $network $remote_fs $syslog
# Required-Stop:     $local_fs $remote_fs $syslog
# Default-Start:
# Default-Stop:      0 1 2 3 4 5 6
# Short-Description: nftables firewall service
# Description:       nftables firewall system service
### END INIT INFO

# Author: Arturo Borrero Gonzalez <arturo@debian.org>
....

So no start run levels are defined. Should this be amended before running update-rc.d, and should they be the 'standard'?

# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6

It would be nice if the package could be devuanated for Beowulf as it's systemd specific as supplied in Debian.
I note there was some discussion about how to enable running on sysvinit back in 2015 when Arturo decided to only supply nftables.init as an example - but then not document what needed to be done to enable it.

Thanks for the tip.

Not sure why this isn't being installed automatically - I do have it on my 'other' PC, installed originally from the same Desktop iso, and that PC has an AMD processor.

Equally I'm puzzled why I ended up with a whole bundle of NVIDIA video driver packages installed on my Intel NUC, which were then attempting to install themselves.