You are most welcome.
FWIW, the version of daemon in excalibur should be new enough to support --bind, so later comments regards backporting are obsolete.
Also FWIW, you can put some of the repetitive malarkey in those commands (e.g. pidfiles=[whatever]) in /etc/daemon.conf or ~/.daemonrc, which makes later use to list / control managed daemons a bit nicer.
Check out the manual, for such a tiny and obscure tool daemon is pretty swish - chroots, environment control, ptys, the works.

steve ALL=(ALL) NOPASSWD: /usr/sbin/shutdown

Works fine here (excalibur):

$ sudo shutdown -k now

Broadcast message from root@damnation (pts/2) (Sun Feb  8 02:38:31 2026):

The system is going down to maintenance mode NOW!

Broadcast message from root@damnation (pts/2) (Sun Feb  8 02:38:31 2026):

The system is going down to maintenance mode NOW!

Shutdown cancelled.

/usr/sbin/shutdown is the realpath to the shutdown binary on your system, right? No symlink shenanigans or anything?

Currently, modded war crime simulator Rimworld, X3, Starsector, and most recently (still undecided) Space Engineers.
In all-time hours-played (and maybe in order): KSP, X3, Rimworld, Stellaris, Grim Dawn, Quake (1), Doom (1), Morrowind, Eve Online, X4.

You?

Exactly why I'm running almost entirely on Gentoo these days. The one Devuan install I still have is a server and completely unaffected by any of this.

I have, on my own systems, quite some time ago. What I can't do from here is get the same into Devuan where it helps everyone, because [see above WRT stonewalling and "upstream Debian package or GTFO" responses].

This issue doesn't affect me at all, but it's still causing problems for other users (usually newcomers, e.g.), and believe it or not I'd quite like to see this distro get better with each release rather than just drop more and more packages and leave more and more broken things for users to "figure it out yourself".

As I said (much, much) earlier:

I still don't have an answer, and shouting "go help" (without specifics like "with what", "where" and "by what process") is not one. Plenty of "help" with this particular issue has already been volunteered (mostly in the pipewire thread), and so far no bites.
When nothing is biting, eventually one stops fishing. All that remains is progressively more snarky variations of "What's the plan, Stan? Have we decided anything yet, or we still hoping this will just go away?".

Ed. But wait, there's more. Lest we forget, here's me offering to "help out" on this very issue, nearly a year ago:

And Ralph shutting it down with the usual completely unproductive "We'll do nothing until Debian does something, unless it uses systemd, in which case we'll do nothing at all.":

But not when new packages or more extensive changes are needed to have things actually work properly without systemd. It's always "remove garbage" or "sanitise", never "fix", "improve" or "add alternative".
So long as this attitude persists, every Devuan release will have less stuff that works, less functionality, and less user choice.
That's not progress, it's regression. It's the surgeon whose answer to every problem is "amputate", because that's what worked in 1856 and administering even over-the-counter treatments might require more effort.

OpenRC gets little attention in Debian, because it solves problems Debian doesn't have. They don't need a recent version with user-services, they have systemd. We don't.
There is nothing whatsoever preventing Devuan from backporting a newer openrc release or including one of the many other available solutions to user-services, besides this ridiculous "we just follow Debian" policy... Which for some reason only appears to apply in a subtractive sense - changes are always removing something from upstream Debian, never adding, never improving.

Any time anyone suggests something be added to make Devuan better, the response is the same - "get it accepted into Debian first"... Even when the thing in question has bugger-all chance of being packaged in Debian because it's completely irrelevant to a systemd-based distribution.

This is essentially just stonewalling, and it's no surprise nobody is volunteering for anything when it's the default response to Devuan-specific RFPs and ITPs.

Indeed, and that's a question that has bamboozled me for years.

As far as I can tell, Devuan 100% reactive, rather than proactive. Upstreams leaning on user-services has been a known problem for years, other distros have been developing solutions and exploring alternatives.
Devuan just waits. Waits to see what Debian does, waits to find out what the next Debian release breaks, waits to see what packages will be "banned" rather than fixed.

We could have openrc user-services, but we don't, "because Debian". Because this isn't really a distribution in it's own right, it's a Debian "respin" and 99.99% of packages are verbatim pulls from the Debian repos.
That's fine when you stick to the Debian way of doing things, but deviating on something as foundational as systemd and then refusing to deviate on potential fixes and replacements... Mark my words: when KDE depends on systemd, Devuan will just "ban" it, loose yet another major package, and slide further into irrelevance.

Pretty much every patch or alternative implementation that has found it's way into Devuan came from another distro (usually Gentoo, e.g. elogind, eudev, opentmpfiles), I'm probably missing some minor tweaks, but the fact I can't name a single significant systemd-free solution invented by this systemd-free distro is concerning to say the least.

Devuan isn't about finding alternatives to systemd, it's about clinging stubbornly to systems long abandoned by everyone else, then shouting at the weather like senile old fools when the rest of the world moves on. Compare the post-count for "here's a cool new feature in Devuan" to "bastards at $outgroup changed something again, the world is going to shit, bah humbug" and the direction is pretty clear - wilful fossilisation.

Yes, much. I got tired of the constant jank and driver-kernel incompatibilities. amdgpu just works, and it's included in the kernel.

Sure, when I have time. Mostly stuff a few years old though.

It's getting old now by "gamer" standards, but it's adequate so long as you don't want raytracing.

There is. The version of openrc in Devuan is, as usual, many versions behind.

I find the benefit you get from any given activity is usually proportional to the time and effort you put into it. Only you can define your comfortable compromise on that sliding-scale from "out of the box, no effort" to "full control, much work".

OTOH, once you do have things set up the way you want, day-to-day Gentoo is pretty much just Arch (or any other rolling-release distro), except updates take longer to install, your PC doubles as a space-heater, and the community is far less obnoxious.

I'd say "definitely is", and probably soon. IME KDE will do what they always do - death by a thousand bugs. Let [thing they want gone] rot until the userbase is sufficiently annoyed, then trot out a replacement that requires [thing they want to depend on] and use it as justification for never fixing what used to work...
Just like X11 support and the "x11-only never ever fix these, they're meant to be annoying" tag on the bugtracker.

SDDM has problems sure, but it certainly isn't beyond saving. KDE could have just adopted it as-is (and as initially implied) or pitched in with maintenance, but instead it's an excuse for yet another rewrite, to use systemd user-services for session management... Which will inevitably spread to KDE in general, as D.E. has been not-so-subtly hinting is "the best way forward" for a while now.

Same reason every new app for KDE that runs a background service (e.g. KRDP) and every new control-panel applet that touches services (e.g. plasma-firewall) also depends on systemd, usually for no convincing reason.
Several influential developers want to move all of KDE's various daemons and services to systemd user-units, so they can get rid of KDED & co. They have for quite some time.
The old "sure we support BSD, we've always supported BSD... You just miss out on some new stuff" pot of totally-not-boiling-yet water is the best way to make that happen with a minimum of screaming, so we get "stay calm, it's just an optional feature. SDDM will still work (for now)".

With any luck Gentoo will patch things to use openrc user services, or Sonic DE will gain the traction and the manpower to be an X11-first and systemd-optional KDE fork.
Both efforts would stand to benefit from some cross-distro support and packaging, but as far as Devuan goes who knows. As far as I can see we're still at "read forum, figure it out yourself" for pipewire, with nary a sign of an official proposition (let alone a solution) for user services more generally.

One example? Probably not, portage touches everything.
In general, you can enable or disable features or use software combinations that require setup at compile time. One can, for example, run a system without udev or dbus, or build the whole OS with clang instead of GCC, or use musl rather than glibc as the system C library, or build binaries that run only on $shiny-new-cpu using every possible optimisation.
Usually that kind of thing means a whole separate specialised distro, with Gentoo it's just user choice and some mucking about in config files.

Probably the most relevant (to devuan) example is systemd - there are many packages that require you to enable or disable systemd integration at compile time (or apply patches to remove it), so binary distros have to either choose one or the other for everyone (i.e. debian/devuan split), or maintain multiple versions of packages, complex dependency chains, or distribution "flavours" (which nobody can be bothered doing).

In Gentoo you just set a 'systemd' or 'openrc' system-wide USE flag (or better, select a profile that does that for you), and everything that can integrate with your chosen init will be built to do so, dependencies will be suggested to provide missing features, etc.
That's a big part of why Gentoo supports multiple init systems as "first-class citizens", and almost everything (including GNOME, for the most part) just works(tm).

Instead of "suggests", "recommends", zillions of split packages, and a bunch of removing optional junk after install, you set USE flags to define which features you want and the needed dependencies are pulled in to enable them.

Portage also makes patching software locally dead-easy. Instead of buggering about with quilt, debhelper, and doG knows what else to change and rebuild a package, you just drop your patch in /etc/portage/patches/[package name]/ and emerge applies it for you.

It offered better performance at the time, and ryzen had random motherboard/bios compatibility problems I didn't want to deal with.

It does, the installer is you.
More seriously, there are too many possible ways to build a gentoo system for an installer to be very useful, and it's not worth the development effort for something you probably only do once.

It's no worse than Archlinux, and plenty of people figure that out.

Devuan as a whole is largely fine, it's just the administration of this board.