Further to^

Then any further testing is but a curiosity, because at the end of the day, differences you can't hear are irrelevant for anything you intend to listen to.

Human hearing sucks, and the vast majority of final reproduction equipment (i.e. speakers and their environment) sucks as well... because so long as the latter suck significantly less than the former, nobody will hear it and it doesn't matter.
Trivial differences in resampling are irrelevant, and unless you are doing digital mastering, so are bit depths >16 and sampling rates significantly above the Nyquist limit. Fight me.

No real reason, mostly just more familiarity.
For a security-focused appliance (e.g. router / server etc) I'd probably pick OpenBSD, but last time I played with the desktop usecase FreeBSD had better hardware support and was easier to get the software I wanted installed.

I'll waste my time fighting the search system for references just as soon as I see the same for claims of one specific wireless driver making a system more "private" or teddybears breaking WPA encryption.

Examples of people conflating the freedom to choose your init with general anti-establishmentarianism and standing up to "them" (whomever that means this week) shouldn't be too hard to find around here though. Guess I could revisit it, when I'm done arguing about python 3.12 targets in gentoo that is.

Fun fact, synaptic (2001) predates the introduction of the 'apt' command (2014). Also: mouse? where? *meow* I see no mouse (any more).

Well it doesn't work on my Slink box, therefore it doesn't exist

about:config, or about:support -> Profile Directory -> Open Directory -> screw about with user.js
Also see arkenfox and the like, for a wide range of tweaks you might want to implement.

Ed.

about:config, play with 'widget.gtk.overlay-scrollbars.enabled', 'layout.css.scrollbar-width-thin.disabled', and 'widget.non-native-theme.scrollbar.size.override'
I don't recall exactly which get you always-visible scrollbars of a usable size right now, but some combination will.

AKA a "meme generator" (many examples online), or something that can be done locally with pretty much any image editor.

Depends which desktop environment or window manager you're using. KDE Plasma for example has a "Media Frame" desktop widget that places resizeable images (or slideshows) on the desktop, on top of the wallpaper.
A similar DE agnostic result could be achieved with conky (read the docs wrt the "image" object) or a small shell script manipulating the window of [insert image viewer of choice here] with wmctrl and xprop to remove borders, set always below, and pin it to a specific position.

AFAICT, the OP wants to pin pictures (with captions) on top of the wallpaper, not replace it. Something akin to the old "desktop sticky notes" but with images.
The use of "icon" all over the place is thoroughly confusing.

Dunno about FOSS in general, but it'd definitely improve the SNR on this board, and good riddance.

Not at all surprised if fsmithred was a bit short with this one, I would be even shorter... Likely "go away troll" followed by a resounding *plonk*.

And no, this is not just a language barrier. English not being your first language might explain the aggressive and hyperbolic word choice to some extent, but the pattern of trash-talk, shouting and multiple exclamation marks is 100% intentional flamebait.

Assuming elogind (pretty sure that's the default these days): Here, here, here and here.
Also websearch keywords: elogind thaw hook

FWIW, I've been running unattended-upgrades on several machines for over a decade, and have no significant borkage (aside from a recent Devuan identity-crisis SNAFU with unattended-upgrades itself) to report.
Then again, the only machines I don't have convenient physical access to have IMPI. If SSH was the only way I could administer a box, I'd likely be doing updates manually... Or at least restricting unattended-upgrades so it doesn't touch anything critical.

AKA, lots of preaching with very little doing.

In many cases these frameworks are already optional, via compile-time flags... Something which, for reasons that apparently escape me, you seem completely unwilling to consider.
Where they are not optional at compile-time, patches to upstream code would be required.

There is no standard facilty for making dynamic-linked library dependencies optional at runtime, because that's not how any of this works. The thing that is becoming most tedious of all is your insistence that there shouid be such a feature, and somebody other than you should see to it.

If you want everything built for you and served up in convenient packages, you get whatever the packagers decided on when they built them (or engage in constructive discussion where you disagree).
If you want control over compile-time options and patches, you run Gentoo or some other source-based distro.

Anything else is just blowing smoke. The tools to build a system the way you want already exist, if you're willing to put in the effort to use them.
Have you actually built and used a system without dbus and policykit, or is this all just idological bikeshedding?

All that said, if you want to be taken even remotely seriously on the idea of making such dependencies optional at the package management level (which would entail binary distros maintaining multiple variants of each affected package):
* What is your convincing technical argument for such a change?
* What do you propose replacing the projects on your "evil" list with? You want to drop dbus for example, so how should we do IPC?
* And, how is your proposed replacement (functionally) superior?
* How do you propose convincing 1000 upstream projects to drop features dependent on $evil_library or switch to your replacement?
* Who is going to do all this work, and does the benefit justify it? If upstreams aren't on board, who is going to write and test patches?

... Or NixOS, Gentoo, CRUX, Gobo, FreeBSD, or any other system that provides tooling to build packages locally with the configuration you want.
Were you motivated enough to do so, this can also be achieved with Debian/Devuan... It's just a bunch more work as the packaging tools don't really cater to global feature switches the way e.g. Gentoo USE flags or the nixpkg declarative build system do.

What you're really asking for appears to be a binary distribution where all the configuration and packaging work is done for you, yet the choices the maintainers make are precisely aligned with your preferences... That's not going to happen, regardless of how much you complain about it.

You want the Devuan developers and maintainers to fork and rebuild everything to run without $things_you_dislike, yet you're not even willing to properly define what you want or what would be needed to achieve it?
Not to put too fine a point on things: Get off the grass.