03: Probably chipset power management. You don't say what (if any) sound server you are using or provide any details of your audio hardware, so generic answers assuming pulseaudio it is: here, and here. TLDR: Disable audio device PM, first for the sound server, and if that doesn't solve it do the same by passing the relevant parameter for (whatever hardware you have) as module options or via sysfs.

09: Again assuming pulseaudio: get sinks with 'pactl list-sinks', put 'set-default-sink [index you found with pactl]' in /etc/pulse/default.pa (see e.g. here)...
Or use a less gimped DE that has a GUI for configuring this and persists settings across logins.

If you're running pipewire the answers are similar, STW for correct config syntax.

10: If they're standard keys (i.e. not some vendor-specific nonsense), get the scancodes with xev - then assign them to do something with XKB or xmodmap... Or use a less gimped DE which supports media keys directly and provides a GUI for configuring them.
If they are special vendor-specific voodoo (i.e. xev doesn't spit out a scancode), they might emit ACPI events instead - for which there is acpid.

The rest: All XFCE problems. I don't use XFCE, I don't like XFCE, and I have no idea why it is the default desktop since it's not even particularly "lightweight" these days.

No.
That said, a) You needn't worry about data loss because anyone with a shred of sense has backups, and b) It's far easier to simply disable the port in BIOS.

I wanted something that I could put my Auzentech card in (because excellent sound quality, socketed opamps, sufficiently high output level to directly drive power amp without needing a preamp), that means a 32bit PCI slot, which means kinda old (i.e. ~sandybridge).
Ended up with *goes to look* an HP RP5800, which being a POS machine has the added advantage of powered-USB (12 & 24v) so I can do power+data for the touchscreen with a single cable.

Mopidy/MPD control is via webui (local touchscreen or remote), android app, or cantata on another PC. Sources are FLAC files over SMB from my (also Devuan) fileserver.
IMO a HiFi is for music (also, I haven't owned a TV for over a decade), so this setup does exactly what it needs to do and no more.
I did play around with a raspberry pi + DAC hat, but frankly the Auzentech just sounds better (primarily because it has real analog volume control).

I don't really do the brand-loyalty (excepting a minor soft-spot for '70's Sansui, reminding me to get on with fixing that AU9500) or "big name / big money must sound good" bit, I just mix and match what works and let my ears (and when it comes to amplifiers, my 'scope) be the judge.
I honestly have no idea what that 350W amp cost me to build, but it's probably getting up around a couple grand... A price worth paying for something with that much grunt and the ultimate (I built it, so I can always fix it) in serviceability and simplicity - No frills, no digital nonsense, just power and line-level in, speaker level out, a power button and one status light.

The rest is an assortment of opportunistic mostly second-hand purchases, dumpster-diving, and "screw it, nobody makes what I want, I'll just build it".

I don't know how you survived going from a 3K hifi to a portable bluetooth speaker, that sounds kinda painful TBH. If it's space at a premuim... Do speakers not take priority over bed, chair, kitchen table, other optional furniture?

More like several "USB stick"s in RAID0, with dedicated DRAM cache (or host RAM cache if you're a cheapskate) and a far more intelligent controller.

Usually, though what it's called varies by manufacturer.

Assuming it reads data from the usual sources, I don't see why not. Honestly I have no idea why people want some dedicated tool like hddtemp just to print data already available in sysfs or via smartmontools.

Add your user to the sudoers file or the sudo group, e.g. as described at https://wiki.debian.org/sudo/#Granting_sudo_access or by 'man sudoers'.

That message tells you exactly what to do.

I don't have, nor have ever had, a single install that wasn't set up with both an unlocked root account and sudo. There's no reason whatsoever not to "mix", besides it requiring a trivial extra step after installation.

Colour me not at all surprised. While SLiM is indeed "slim", it's functionality is eclipsed by even the venerable XDM. User switching, bah, who needs that?

Don't ask me how, but SLiM somehow manages to not register login, session nor seat properly. At least that means it doesn't unexpectedly inhibit logind idle actions, unlike certain other disasters (SDDM).

If lightdm had a greeter (in the repos) that didn't drag in a bunch of gnome/GTK3 dependencies I'd be all for it...

For such a relatively simple function as a display-manager / graphical greeter, there really is a dearth of options that don't suck in some fundamental way.

I don't use nvidia, because the drivers are a constant source of aggravation... Much as ATI drivers used to be. How the tables have turned.

Because IGPU is too slow, lacks features, or is absent entirely?

Current GPU is using less than 5w, while writing this and doing general desktop stuff. When I want performance... You get what you pay for (in watts).

I don't understand obsessing over idle power consumption, particularly when it's on-par with a network card or additional SSD.

Depends on SKU, both have options with and without an IGPU.

Confusing to say the least, and not least because of the large number of RAID'ed partitions... Likely in squarely in the "easy to fix if I was sitting in front of it, very difficult to diagnose remotely" category.

To (attempt to) clarify:
Where is your /boot supposed to be? Is it a RAID array? If so, which disks/partitions should comprise it?
Where is your boot MBR/PBR and where is GRUB stage1 installed?

So sda1 and sdb1 are supposed to be independent devices, not part of an array? They contain duplicate but independent /boot filesystems, yes?

Partition type doesn't really decide whether a device is part of a RAID array, it's just a hint. Mdadm will scan for signatures and assemble what it can.
What does 'blkid' and/or 'wipefs -n' say about those disks (sda, sdb) and partitions (sda1, sdb1)? Do any of them have RAID signatures on them?

---

Both "legacy" BIOS (MBR) and UEFI (GPT) can usually boot just fine from MDRAID1, since the RAID headers (v<1.1) are at the end of the member devices and they are otherwise indistinguishable from normal partitions.
The latter (along with putting EFI on MDRAID1) is very much "unsupported" though, and will require diddling with GRUB config and/or use of the '--removable' flag when installing EFI entries.

MBR just needs an MBR/PBR (and some free blocks for the stage1 loader) and a partition GRUB can read, UEFI just needs an EFI/ESP partition the firmware can read. RAID1 works for both.

For (NVME/GPT) example:

nvme0n1     259:0    0 931.5G  0 disk  
├─nvme0n1p1 259:1    0   256M  0 part  
│ └─md0       9:0    0 255.9M  0 raid1 /boot
├─nvme0n1p2 259:2    0 927.3G  0 part  
│ └─md1       9:1    0 927.1G  0 raid1 /
└─nvme0n1p3 259:3    0     4G  0 part  [SWAP]
nvme1n1     259:4    0 931.5G  0 disk  
├─nvme1n1p1 259:5    0   256M  0 part  
│ └─md0       9:0    0 255.9M  0 raid1 /boot
├─nvme1n1p2 259:6    0 927.3G  0 part  
│ └─md1       9:1    0 927.1G  0 raid1 /
└─nvme1n1p3 259:7    0     4G  0 part  [SWAP]

/dev/nvme0n1p1       2048     526335     524288   256M EFI System
/dev/nvme0n1p2     526336 1945131007 1944604672 927.3G Linux filesystem
/dev/nvme0n1p3 1945131008 1953519615    8388608     4G Linux swap

/dev/nvme1n1p1       2048     526335     524288   256M EFI System
/dev/nvme1n1p2     526336 1945131007 1944604672 927.3G Linux filesystem
/dev/nvme1n1p3 1945131008 1953519615    8388608     4G Linux swap

/boot/EFI
├── BOOT
│   └── BOOTX64.EFI
└── gentoo
    └── grubx64.efi

Another box around here has a near idential layout with BIOS/MBR boot, /boot on RAID1, and grub stage1 installed to the MBR of both member devices... I'd have used that one as an example, but it's got 19 drives so it's a mite messy to wade through the lsblk output

Logind manages resources for interactive logins/physical "seats", and replaces the likes of consolekit for managing access to devices and executing privileged tasks on behalf of the user.
So yes, you can ask logind to do things like shut down the machine without sudo/being root - so long as logind knows you are logged in to a physical session ("seat"). You can do the same over e.g. ssh, but in that case it will ask you to authenticate.

As previously mentioned, network-manager is already a forked packge proivided by Devuan.

Cause: Failure to read the NEWS file or sufficiently test the default desktop install.
FTFY.

Why are you tring so hard to assign blame? This is not a Debian bug, nor is it Debian's fault. Rather it was an intentional, documented change (2 years ago at at that), which Devuan failed to react to.

Bug found, bug fixed. Case closed. If you really feel the urge to couch it in terms of the "us vs. them" nonsense so popular around here, at least try to get the facts straight.

Choice of init/rc makes very little difference to shutdown/reboot invocation, and none at all to suspend (unless you have some init scripts wired up to suspend/resume hooks ofc).

Suspend / hibernation has nothing to do with "hardware keys", beside the latter often being assigned to trigger such through ACPI button events.

Actually suspending the system is kernel functionality (usually with firmware help for bootstrapping a suspended system), with optional high-level interfaces (pm-utils etc.).
Those can be called however you like, be it a dedicated (i.e. pre-assigned) "hardware" key, remapping a "hardware" key with acpid, a custom key combination in X / whatever DE you use (I like meta+s), or a script / menu / whatever.

You'd set those up the same way as you ever would when writing to sysfs or running any other priveliged command. Sudo / doas / groups / suid / polkit / logind are all a matter of taste for giving normal users permission.

---

In general, I'd suggest [e]logind as  being the most convenient / compatible. I don't see any real reason for not wanting a login/seat manager of some kind on a primarily desktop/GUI setup, and it's also the easiest way to get X running as not-root (i.e. providing dynamic permissions for the nodes in /dev/ X needs)...
Unless of course you're going for knee-jerk "but it comes from systemd, no way" idological nonsense or hair-shirt level "minimalisim", in which case figuring out how you want to do seat management and permissions is up to you.

Likely well after every other BSD has, and one little bite at a time. FreeBSD has been arguing about allowing rust in base-system for a while (random typical example), but OpenBSD is conservative enough that they'll almost certainly wait and see how it goes there before even considering it.

In any case, the real arguments from devs and core maintainers (as opposed to the usual uninformed zealotry from joe-internet-rando in both camps) are more to do with the additional toolchain / build-times / maintainer workload than any of rust's supposed *magic security fixing* properties, "new"ness (or whatever idiotic, uninformed, non-technical objection zapper is still banging on about) or cult-like following.

Much as with rust in Linux, the debate among those at the coal-face is far more akin to "Rust can reduce common memory-management bugs, we should use it for (select) stuff where that's valuable" vs. "Multi-language codebases are a pain in the arse to maintain and I have much work already, if you want to do that, ensure you don't make a mess and/or make it my problem."

Rust is, after all, just another programming language. It's a programming language with better safeties on the common footguns than C, but one can write bad code in pretty much anything if so inclined. Hell, there's a bunch of low-level stuff you simply can't do in rust without some variety of 'unsafe foo ()', at which point the *safety magic* is off anyway.

---

Oh, the huge manatee.

When all you bring to a discussion is speculation based on personal "beliefs" or vague "someone once said" hearsay, random insults and outbursts of spite, and unsubstantiated value-judgements... Right or wrong really isn't the question, it's simply noise.

As for arrogance... No, the 10/10 arrogance award goes to people who shit on someone else's choice of tools and call them "newbs", without the slightest idea what it is they do, how to do it, or why choice of tool might matter to them.

Does one who does not know how to plumb (let alone in copper) trash-talk plumbers over their preferred brand of flux or filler rod? Would you listen to them if they did?

So maybe stop inviting it, by properly researching things before opining loudly and spitefully on them and the character of anyone who uses them?
Ya know, like the way "don't judge someone until you have walked a mile in their shoes" maps pretty well onto "don't judge a programming language until you have written some code with it"?

Also,

I should probably thank you for the entertainment, it's not like there's much else going on around here.