The org.freedesktop.timedate1 service is provided by systemd:

$ apt-file search org.freedesktop.timedate1                                                 
systemd: /lib/systemd/system/dbus-org.freedesktop.timedate1.service
systemd: /usr/share/dbus-1/system-services/org.freedesktop.timedate1.service
systemd: /usr/share/dbus-1/system.d/org.freedesktop.timedate1.conf
systemd: /usr/share/man/man5/org.freedesktop.timedate1.5.gz
systemd: /usr/share/polkit-1/actions/org.freedesktop.timedate1.policy
$

@OP, you may be SOL with this one...

EDIT: here's the unit file:

[Unit]
Description=Time & Date Service
Documentation=man:systemd-timedated.service(8)
Documentation=man:localtime(5)
Documentation=man:org.freedesktop.timedate1(5)

[Service]
BusName=org.freedesktop.timedate1
CapabilityBoundingSet=CAP_SYS_TIME
DeviceAllow=char-rtc r
ExecStart=/lib/systemd/systemd-timedated
IPAddressDeny=any
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateTmp=yes
ProtectProc=invisible
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectSystem=strict
ReadWritePaths=/etc
RestrictAddressFamilies=AF_UNIX
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallErrorNumber=EPERM
SystemCallFilter=@system-service @clock
WatchdogSec=3min

It's a dbus service running a systemd binary with extensive sandboxing and hardening. I don't think this can be replicated with sysvinit. Hopefully I'm wrong.

EDIT: Alpine use openrc-settingsd to provide a dbus interface with OpenRC so you might be able to package that for Devuan and get it working with MATE. You'll have to switch to OpenRC as the service manager but it's better than sysvinit anyway (IMO).

Just load up the Devuan ISO image and use rescue mode to gain a shell in the installed system with a working internet connection so that you can install whatever you want.

IIRC though it's impossible to remove the init metapackge (of which systemd & sysvinit are dependencies) without being told how stupid an idea that is; APT requires you to confirm that you want to do something that will probably wreck your machines and you said "yes". Why?

https://serverfault.com/questions/60148 … -net-names

Your graphics card is AMD Picasso: https://linux-hardware.org/?id=pci%3A10 … -1002-15d8

It should work with beowulf if you install the firmware-amd-graphics (non-free) package and the kernel, both from backports. The kernel & firmware in chimaera would also work if you want to run that instead.

For the wireless card MX have a DKMS .deb package, see http://dev1galaxy.org/viewtopic.php?id=4611 but be sure to download the .deb from my link (which points to the repositories themselves) rather than the sharing link posted by the OP.

Check the logs.

The openSUSE Build Service provides packages for many distributions, they are all built in fresh VMs for the target suite and so should be fully compatible. I've been using the service myself for several years to build custom Debian & Arch packages, it works very well.

xbacklight only works if you're using the Intel DDX driver but Devuan beowulf will default to the modesetting driver for Intel graphics cards. You can force the Intel driver to make xbacklight work but it's more buggy than modesetting.

I use a udev rule to change the brightness file to be owned by the video group and allow that group to alter the level:

# /etc/udev/rules.d/00-backlight.rules
ACTION=="add", KERNEL=="intel_backlight", SUBSYSTEM=="backlight", RUN+="/bin/chgrp video /sys/class/backlight/intel_backlight/brightness", RUN+="/bin/chmod g+w /sys/class/backlight/intel_backlight/brightness"

And then use keybinds to call scripts to alter the levels; this one is called dimmer (I have an AMD system, your backlight directory will be called intel_backlight, or so):

#!/bin/sh
file=/sys/class/backlight/amdgpu_bl0/brightness
read -r level < $file
printf %s\\n $((level-5)) > $file

The brighter command is the same but with a plus instead of a minus. The value of the level step can be determined by checking the max_brightness file. I should probably make a generalised script to both raise and lower brightness in 1/10 increments for any system but I just can't be bothered.

EDIT:

X does not look there, see man xorg.conf for details.

EDIT2: simplified udev rule.

Because it's already available to Devuan users via amprolla.

And anyway snaps are not monitored by Canonical and have been known to serve malware:

https://www.omgubuntu.co.uk/2018/05/ubuntu-snap-malware

I can't speak for the developers but I'm pretty sure they already have enough to do without packaging up some shitty browers that aren't good enough to make it into Debian's repositories.

AMD graphics cards need firmware:

# apt install firmware-amd-graphics

Just bought Torchlight II on Steam, it works under Linux but only in X. I was a bit worried I'd wasted £4.49 when it wouldn't start in sway...

Let's see what udev is doing with the device — open a terminal and run this command (as root):

udevadm monitor

Then plug in the controller and post any and all new output that appears in the terminal afterwards. Probably best to fullscreen the terminal, it might be a lot of information.