Did you follow that advice?

That dbus service file is provided by the gnome-keyring package

That's off topic for this thread but just sounds like complete nonsense. Do you have a citation for that?

The systemd code base is licensed under the GPL[0][1] so it does conform to the FSF guidelines[2][3][4].

Well I would agree with the comment, yes. But I'm no expert so... ¯\_(ツ)_/¯

Thanks for the correction and apologies for the misinformation. Oops.

The Linux kernel is an example of a monolithic kernel, which can be contrasted with the microkernel paradigm.

And just to note that "GNU" stands for "GNU's Not Unix" — Linux has never really adhered to UNIX principles anyway. I would also mention that systemd is actually very modular in it's design with *many* compilation and configuration options that can be used to filter out unwanted functionality and also that systemd offers a unified collection of userspace control programs that is *very* similar to the way that all of the true UNIX® systems work but I wouldn't want to start an argument

Nah, that just means they know what they're doing. After all Ken Thompson and Rob Pike both now work for the big G.

Have you checked the logs? Perhaps the problem is fixable.

I have found that Windows 10 performs very well under QEMU/KVM:

https://www.linux-kvm.org/page/WindowsGuestDrivers

It works even better than on the bare metal because you can freeze the little fucker if it tries one of it's "let's update the system for seven hours" tricks.

Why are you passing the arguments applied to the script to those functions? They don't appear to do anything with them unless I'm missing something obvious.

No need for grep:

usbdevlist=$(/usr/sbin/hwinfo --usb --short|awk '/\/dev\/sd/{print $1}')
usbdevfulllist=$(/usr/sbin/hwinfo --usb --short|awk '/\/dev\/sd/{print $0}')

And here's a whiptail alternative for the yad dialogue:

usbdevlist() {
   /usr/sbin/hwinfo --usb --short|awk '/\/dev\/sd/{print $1,$1}'
}
device=$(whiptail --notags --menu "Please select the target device to which you want to copy the live image:" 0 0 0 $(usbdevlist) 3>&2 2>&1 1>&3)

Alpine Linux updated to v6.8.1 within an hour of the upstream release :-)

"i5" & "i7" are fairly meaningless without the specific processor type, both have been around for over 12 years now. Bear in mind that the stock beowulf kernel version was frozen over 2 years ago so any hardware introduced after that date may not be supported properly. I know that the 10th & 11th generation Intel integrated graphics chips won't work at all in Devuan beowulf even with the backported kernel because they need a newer Mesa version (not particularly relevant for a server but it gives you an idea of the potential problems that can arise).

I think beowulf already defaults to the nftables backend as per https://www.debian.org/releases/stable/ … l#nftables

I do not agree with that at all. The nftables syntax looks *much* easier to understand IMO but I am pretty ignorant when it comes to firewalls so my opinion is probably moot.

I presume you've seen the nftables wiki? See also https://wiki.debian.org/nftables & https://wiki.archlinux.org/index.php/Nftables

The nftables package provides a few examples under /usr/share/doc/ and also has a sysvinit script that can be used in Devuan but it needs correcting:

https://dev1galaxy.org/viewtopic.php?id=2889