Actually it's... Freedom. Choice is just a side-effect of the "freedom to modify" bit.

Choice is, on the other hand, the reason I moved away from Debian, and the reason I'm steadily moving away from binary distros in general. Primarily, that's the choice to not install 500lbs of crap I don't want or use.

For example: Want to install ffmpeg just for CLI transcoding? Too bad, guess you'll need a bunch of X libraries, GLX stuff, fonts you'll never use, and vulkan headers (FFS) as well... Because Debian / Devuan compiles against every possible thing, and seems to be more and more aimed at desktop deployments by the day.
For another, have a look at the unholy mess in /etc on a "modern" binary distro, and ask yourself: How much of this do I use, and how much do I even know what it's for?

Frankly I find this all extremely annoying, and If I have to recompile a bunch of stuff just to get a simple, understandable OS without a heap of redundant kitchen-sink functionality and 50 abstraction layers for everything, I might as well just build the whole system from source to begin with.

Anyway, this is horribly off-topic. Maybe if the OP replies someday...

Wow, this is turning into an ordeal. Really not sure why, it should be as simple as:

apt install linux-headers-amd64 zfs-modules zfsutils

All three are metapackages, and should select linux-headers-{version}-{arch}, zfs-dkms, and zfsutils-linux respectively... Or at least they do on my minimal chimera install, with both recommends and suggests disabled.

Add

apt install zfs-zed

if you want event monitoring (you do),

apt install zfs-auto-snapshot

if you want automatic snapshotting from cron, and

apt install zfs-initramfs

if you want to be able to do root-on-zfs.

Aside, you might also prefer the 2.1.5 packages from chimera-backports, there have been some improvements...

Otherwise, yeah, full output needed to see why the zfs and spl modules are not being installed.

FWIW, I did have a bit of fun getting my filesystems mounted at boot after a beowulf -> chimaera upgrade, it would appear the init scripts for 2.0.3 and 2.1.5 are both kinda broken (WRT LSB depends and ordering), this commit puts things back how (IMO) they should be.

On that note... Any particular reason we're moving to that (unmentionable, IME) thing instead of using the venerable debian-installer? I mean, we kinda have a serviceable wheel already, no?

Fringe browser labels Devuan a fringe OS...

Pot, meet kettle

If the site in question isn't running some pile of "browser check" javascript trash, you can probably cheat by just changing your user-agent...
Then again Palemoon is kinda garbage anyway, as is the general attitude of the developers.

And unavailable early in the boot process, the initrd, or by default on many minimal installs.
Shift+pgup is both ingrained muscle-memory and a lot less annoying (IMO) than the likes of vi-style keybinds, and screen is gratuitous bloat when all you want is a fully functional VT.

Console scrollback has been around forever, and it's one of the very first things that made me go "wow, this is way better" when transitioning from DOS.
Frankly this "everyone just uses the GUI (or laptop/phablet/whatever trendy disposable junk is FotM) these days" rubbish is getting extremely annoying. I for one use real VTs on a real PC every day, and have since the late '90s.

Now I' guess I'm just waiting for GNU/Linux to remove VTs altogether, make touchscreens mandatory, and replace all kernel output with inane spinning widgets and emojis.
I'm sure all the windows refugees will just love it, since there'd be no need to learn to read and no keyboard to clean the drool out of.

Well that was quick.

We have a weiner, and really, I should have seen it coming...
Via auditd (yeah, it's better than fnotifystat):

proctitle=/usr/bin/python3 /usr/bin/systemctl list-units --full --all 
type=PATH msg=audit(11/06/22 05:16:39.046:1736) : item=1 name=/var/run/samba/nmbd.pid inode=41571 dev=00:15 mode=file,644 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 
type=PATH msg=audit(11/06/22 05:16:39.046:1736) : item=0 name=/var/run/samba/ inode=16650 dev=00:15 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 
type=CWD msg=audit(11/06/22 05:16:39.046:1736) : cwd=/root 
type=SYSCALL msg=audit(11/06/22 05:16:39.046:1736) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7f257ac19050 a2=O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC a3=0x1b6 items=2 ppid=16701 pid=16702 auid=steve uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts2 ses=16 comm=systemctl exe=/usr/bin/python3.7 subj==unconfined key=rundir

Sure enough:

-rw-r--r-- 1 root root 0 Jun 11 05:16 /var/run/samba/nmbd.pid

And it's not even some dodgy crap I backported myself this time:

Package systemctl:                              
i   1.4.4147-1~bpo10+1                                             oldstable-backports                         200

This particular footgun was installed to satisfy some crappy postinst stuff in the packages from zmrepo (which actually works fine without systemd but was clearly packaged by a muppet).
I thought it would be relatively safe in that context as all the postinst does is a 'systemctl status zoneminder' and nothing else should use it (this is Devuan after all, and we don't use systemd, right? RIGHT?)... But if it's on the system it looks like it gets called by a bunch of other things too - in this case, somewhere downstream of a 'service apache2 reload'.
Said zmrepo package was only installed because there's nothing for beowulf... Which is odd and kinda annoying, as there is a backport for ascii.

Anyone care to speculate why a command that is supposed to simply list units is stomping all over everything? Or why there is a loaded footgun in the devuan repos without a depends !sysvinit safety catch?

Conclusions:
1) That standalone systemctl package is an extremely nasty trap. I don't know why it's nuking my pidfiles and I don't really speak python, but I might have a look later. For now it goes in the naughty corner where it belongs.
2) Installing zoneminder on this box was probably a bad idea to begin with. It's nominally a mailserver (with roundcube webmail via apache), but it had disk space to burn, a webserver already installed, and it was convenient at the time. 'twas intended to be a temporary solution, but you know how that usually goes.

Sure, maybe I do... The catch is that everything works fine here too, so long as I'm looking at it.
If it was not stopping properly reproducibly, I'd have it fixed by now.

As this is a working (and moderately important, at least to me) mail server, I'm not particularly keen to reinstall everything or revert to default configuration for a month to see if solution-by-scorched-earth sticks.
That's very much last-resort material, and besides being a total pain in the ass is unlikely to be educational as to the real cause.

Fair enough. Personally I doubt it though, dovecot has been around a lot longer than systemd, and again I'd expect a consistent result if that was the problem.

Aside, the focus on dovecot is all well and good (that is the more annoying problem), but TBH I still suspect something outside dovecot itself (or its configuration) since whatever it is appears to affect smbd and nmbd in much the same way.
They might be unrelated of course, but IMO it'd be a hell of a coincidence for 3 services to suffer the same problem without a common cause of some kind.

Really, I don't think I'm going to get anywhere with this right now, it'll have to wait until the cosmic rays or whatever it is strike again to even start.
I was really just hoping somebody had seen something like this before and I might get a hint that way, but oh well. Guess I'll come back when it happens again and I have more info.

I know this is all kinda vague for a tech support question, but then If it was easy I wouldn't be asking.

IMO, pointless change... Unless the point is to break systems with a minimal root FS and separate /usr (and likely runlevel 1 / single-user mode too). Admittedly those are probably few and far-between these days, but still, why break it?

Presumably the main argument for it is just the usual "vendor image" / "factory reset" / container-mania / unification One Linux BS from the Redhat/Gnome/systemd crowd.
Yawn.

As for Devuan, I expect it'll probably follow Debian. Removing systemd is enough work for a relatively small distro.
If it does, I'll probably seriously consider moving my remaining Devuan systems to Gentoo... Where 'split-usr' is just a (currently default) USE flag like 'systemd', 'pulseaudio', 'wayland' and all the zillions of other options.

No, unless you're running Nvidia cards and your upgrade crosses one of their arbitrary "dropped support for xyz" boundaries, in which case you'll need to change driver version.

GNU/Linux doesn't store a bunch of driver related crap in the registry (or have a registry at all for that matter), so there's nothing to "completely remove"... And no shady "driver removers" or "registry cleaners" either.
There's also no infuriating minefield of malware and ad ridden "driver updater" scam sites to navigate, and practically no manufacturer bundled bloatware either. But I digress.

60c is fine for any modern GPU, most won't even downclock until they hit 90+. Hell, 60c is fine for my 1998 Banshee.

I can't speak to noveau, but IIRC the proprietary nvidia drivers expose temperature and fan speed info via nvidia-smi, and allow setting fan speeds with nvidia-settings.
This would be much easier if they just put stuff in /sys like every other GPU driver, but whatever. It's Nvidia, they don't believe in standards.

It shouldn't be particularly difficult to script a fan curve controller in shell, have a look at this and this for inspiration. Dunno if they actually work as I don't have an nvidia GPU to play with, but both look pretty legit to me.

Oh yeah, there's also this shiny thing. I've used it on Gentoo in the past, and it does what it says on the tin. Don't think it's packaged for Debian though, so you'd need to compile it yourself or (shudder) install it as a flatpak.

This has been the case for years, and the various bug reports regarding it simply get closed as "WONTFIX or "WORKSFORME".
I don't know what the FF devs (or more likely a committee) think is so hard about providing an about:config setting to select the sound PCM (or officially supporting anything but pulseaudio to begin with for that matter), but apparently that's how it is.
They certainly appear to have enough manpower to work on constant and pointless UI changes though...

There is MediaElement.setSinkId, but it AFAICT that only enables an underlying API, i.e. the possibility of switching the audio output... Actually implementing device selection is left to extensions.

To break anything that needs format/samplerate conversion or stream mixing? Just a guess.

There's a whole lot of (mis)information on the web regarding "bit perfect" audiophool configurations that disable most of the useful functionality ALSA provides... Not saying that's what's going on here, but I can't really think of any other reason for an asound.conf like that.

Lutris allows you to manually add games.

If the game can be moved around like this and run without whatever registry stuff the installer does on Windows, the same is likely true for wine.
You will need to initialise the wine prefix of course (running winecfg or similar with $WINEPREFIX correctly set should do it), and if you want to use install scripts that set up dependencies and whatnot for you you'll probably have to fool them into thinking they've run some kind of installer.

I find that downloading and modifying the lutris install script to remove the installer reference usually works, and it's easier still if said script allows you to specify your choice of executable - just point it at something irrelevant and harmless so the install can proceed to set up the prefix, then copy your game files in.

None of this is officially supported of course, so YMMV. If you're not familiar with setting up and troubleshooting wine, it's probably best to stick with somebody else's install scripts.