Source? AFAIK there's nothing related to logind or dbus in xorg.conf, and there never has been.
Enabling or disabling logind integration is done at compile-time, by passing:

-Dsystemd_logind=false

to meson.

The xorg.conf(5) manual is in the same place it has always been.

Compiling software is not specific to "the gentoo-approach", and can be done on any distro that includes a compiler toolchain and development libraries... Which Devuan does.

So either use the Devuan packages with the options Devuan chose, or recompile them if you want something different. All the tools to do the latter are in the official repositories where they've always been.

Brocashelm pointed out that a lot of things depend on libdbus (because they were compiled against it), and you suggested an exceptionally ugly workaround that doesn't actually exist.
The correct approach is to recompile or patch the affected packages to not link against libdbus, on a case-by-case basis. Anything else is bound to end in disaster.

LD_PRELOAD hacks or stub-libraries and the like will cause problems, because sooner or later (probably sooner) upstream will use a function you haven't implemented or depend on a reply to a message you sent to /dev/null, and everything will blow up.

Better yet, somebody will use something that asks over dbus a question like "is this a container" or "what init system are we using" before starting a potentially system-trashing operation... And you propose just answering "true" every time? What could possibly go wrong?

Why go to all that effort with fragile half-arsed solutions, just to avoid rebuilding packages?

"Hacks" doesn't preclude recompiling to get the behaviour you want, and you have the "freedom" to do so.

If you write the software, you get to decide what options and dependencies it has.
If you package the software, you get to decide which of those are enabled.
If you just use the software, you get to complain ineffectually, and I get to give you shit for it.

You want a binary distro that caters to your specific whims and provides packages built just the way you want, with no effort on your part.
Spoiler alert: It doesn't exist, and it won't unless you make it. Some things need to be decided at compile-time.

Depends on whether you include both type-1 and type-2 hypervisors, and whether your universe is limited to only those that run on GNU/Linux.

That's not what you did, you took a comment out of context to imply that the proprietary virtualbox hypervisor must be "bad" because they're adding KVM as an additional option, then used that as as an excuse to sling mud at "big evil corporation" for taking too long to include your favourite alternative.

My response is "supporting both is good, because they serve different needs. The more options we have the merrier." I have no loyalty to either technology.

If you want to insist Qemu/KVM is universally "better", I invite you to try running Visopsys or PC-DOS with full emm386, or moving your VMs between different host operating systems (which is  much easier with a type-2 hypervisor like VB).
Like I said, use-cases... One solution does not fit all of them.

Yes, believe it or not those do exist and they do have more stringent security requirements than your personal machine. The "nothing but single-user desktop exists" blinkers everyone on this board seems to like wearing are extremely silly.
Then again, if you're administering a multi-user system and allowing people to plug in random storage devices then that's the real problem, not the software enumerating them.

What they will find is your web browser storage, which will likely contain cached pages and login cookies even if you use 2FA and never "save" any passwords.
"I have nothing to hide" is a ridiculous non-argument, regardless of whether it's applied to security or privacy.

So webmail then? Guess what's in your browser storage...

Ahh, good old "somebody else is dealing with it" security-as-a-service.

The above aside, I agree. Udisks itself is pretty irrelevant as an attack vector, noexec & co is a nothing-burger in most situations because nobody uses auto-run any more, and everything else requires physical control of the device and the ability to connect random storage, at which point you're cooked anyway.
Smells like AI CVE-slop to me.

Eh? I get ~900MiB/s read/write over the network to my NAS (network limited), and that's mostly 10+ year old gear. Local root filesystem is 3.5GiB/s read, 1.6GiB/s write (real workloads as opposed to the silly marketing numbers, and yes, it's ext4), and that's pretty much the cheapest DRAM-less flash (that wasn't complete trash) I could find at the time.

"An SSD for the OS is the biggest upgrade you can make for interactive workloads" was a true 15 years ago. These days it's almost impossible to find a system that doesn't do that.
If you think "I still boot from a single bargain-basement mechanical drive from 2009" is some kind of brag (outside the vintage scene, and half of that is using flash these days anyway), you do you.

As for the OP, benchmark better. What you are testing is the throughput of encrypted LVM, not ext4. In that context CPU performance, memory bandwidth and choice of encryption algorithm will completely mask any differences in filesystem performance.

Benchmark numbers or it didn't happen.
Fiddling with exotic schedulers is very workload dependent, and most modern SSD firmware does well enough for general-desktop use that the best choice is either none or deadline, with anything more complicated just adding overhead for no real benefit.

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.