SSDs for general use, HDDs for infrequently accessed bulk storage where capacity>performance...
And hybrid ZFS pools for both at the same time. Nothing quite beats an array of large mechanical drives with a TB or so of high-IOPS SSD as cache and 100GB ish of RAM dedicated to caching the cache.

IME, most of them. I still have the first SSD I bought (OCZ Agility 3), also from 2011, and it still works perfectly.
I have a couple of earlier models (2010 IIRC) I bought used, and they work perfectly as well. In fact, I've never actually had an SSD "wear out", the vast majority of failures are sudden and just outside the warranty period, much as with spinning-rust.

s/someone/something/g

Obvious wall of LLM-generated copy-pasta is obvious, and the arguments it makes are all either inane or inapplicable. Do you really think anyone here cares about the threat of "shadow IT", "unknown assets" or the rest of the corporate-drone buzzword-soup padding? We are shadow IT.

Many other boards have policies regarding AI generated content (usually "go away"), perhaps it's time for the same here?

Lay off with the ChatGPT Igor, it's obvious and it's tiresome. If we want AI security "advice" we can ask one ourselves without you reposting it.

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.":