It's probably best to try to pursue the problem in the forums or on the Devuan mailing lists first so PEBKAC can be eliminated. Then try to reproduce the problem in a Debian system and report a bug to them if it's still there.

The Devuan developers can only really fix their own packages, neither openrc or btrfs-progs fall into that category.

The best solution is probably to add MX Linux's AHS (Advanced Hardware Support) repositories, pin them to behave as backports and install their backported Mesa packages.

See http://forums.debian.net/viewtopic.php?f=16&t=146083 for the details.

EDIT: adding the chimaera or ceres packages won't work because they depend on a newer libc6 version than is available in beowulf.

And don't add the testing/unstable repositories, the installation will pull in the newer libc6 version and it will then never be updated until you move to the next release.

It is not possible to backport the testing version because it depends on a newer libc6 version than is available in beowulf.

I really have no idea, sorry. Try searching for processor benchmarks.

Actually it's probably best to keep /etc/init.d/networking enabled to ensure that the loopback interface is correctly configured (systemd would do that in Debian but I'm not sure about sysvinit). Just remove any stanzas in /etc/network/interfaces that refer to your ethernet or wireless devices if you don't want ifupdown to manage them.

And to disable any given $service it's probably best to use

# sysv-rc-conf $service off

The posted snippet will also work for Alpine but X won't be run under the normal user so I would actually recommend to install elogind and sway instead and then disable the setuid bit on the sway binary for a rootless desktop.

To start sway use

[ $(tty) = /dev/tty1 ] && exec sway

For FreeBSD you can also use that snippet but replace /dev/tty1 with the output of the tty command when it is run from the default login TTY (I don't use FreeBSD so I'm not sure how the consoles are identified).

Hmm, sorry about the file descriptor misinformation. I should have tested that first.

That's just silly — the best display manager is clearly no display manager at all

SLiM runs X under the root user whereas a console login followed by startx[0] results in the X server being run under the normal user, which is clearly a major advantage (as is the lack of DM overhead).

[0] Automate the process by adding this line to the end of ~/.profile:

[ $(tty) = /dev/tty1 ] && exec startx

Maintenance for SLiM stopped in 2013 so any security issues will not be addressed.

For example it opens a log file as root and doesn't close the file handle properly before exec()ing the desktop session.

Try this:

echo foo >&3
tail -1 /var/log/slim.log
ls -l /var/log/slim.log
whoami

The logs may be binary but they are not "blobs" — they can be read with strings(1).

Alternative method:

apt-file search mate-system-log

Or enter the program name into the search box at https://www.debian.org/distrib/packages#search_contents

EDIT: https://wiki.debian.org/WhereIsIt

Looks like MX is booted in VirtualBox (they include the guest additions in the stock system), was Devuan also in VirtualBox and if so did it also have the guest additions installed?

What video card and kernel driver does lspci -k report for the VMs?

qemu-system-x86_64 -enable kvm -m 4G -vga qxl -soundhw hda -cdrom /path/to/ISO.img

See also http://forums.debian.net/viewtopic.php?f=16&t=144775

Upload the file to a pastebin and share the link:

curl -F 'f:1=<-' ix.io < /var/log/Xorg.0.log

I'm not interested in the MX log, that is of no use for this thread.

I just can't be arsed posting a "newbie explanation" for how to create an X.Org configuration file, that's all. I'm sure there are some out there if you search a bit, or maybe another forum member with more patience than me will take pity on you.

What makes you think I care which distribution you use?

Yes, it most certainly is.

I'm working on the assumption that it's a bug in the Atheros driver but that's just a guess.

If you still have the Ubuntu live image then I would be interested to see the journal entries for systemd-rfkill.service:

journalctl --unit systemd-rfkill.service

It could be that systemd is applying the same workaround.

EDIT: actually I had one of those cards in my ThinkPad E485, it was utter crap (used to overheat and drop out) but it was never soft-blocked under Debian buster.