DNS over TLS, AKA a somewhat less retarded attempt to break the 'net than DoH, from the usual paranoia crowd who think moving trust from their ISP to some other random entity (usually Google or Cloudflare) is progress.

DNS is handled on my router, because I have a brain.

Then you should probably ask RedHat, Devuan didn't write NetworkMangler.

What makes you think someone else should write your init scripts for you?
The stubby package comes with a sysvinit script, because that's the default init. OpenRC is supported, but you don't get everything handed to you on a silver platter.
If you want an openrc init script, swiping it from Artix will probably work without too much modification. Otherwise, writing your own isn't complicated.

Huh, what a coincidence. Shouting is a complete showstopper for me providing any kind of spoon feeding step-by-step instructions.

With the entitled and confrontational attitude you've displayed in all your posts so far, I'll be surprised if you get much of that.

This particular nonsense is wrong on every level:
exFAT errors have nothing to do with the installer.
The installer doesn't use exFAT.
Even if it did, the Linux implementation is GPL, not proprietary or closed-source.
The exFAT spec and related patents were released in 2019, so it's not secret and not strictly owned by Microsoft (any more).
The Devuan installer doesn't depend on any "reverse-engineered propriatary [sic] garbage", poor or otherwise.
Even if we broaden "installer" to include the kernel, any included drivers are either clean GPL implementations or third-party binary-blobs, neither are "reverse engineered" from proprietary code.
And for bonus points: Devuan is not "incapable of booting from ext4", ext4 is in fact the default filesystem.

That said, it still isn't a very good example of fractal wrongness, but that's a term I don't get to use very often, so...

---

To return to the (well disguised as an unhinged rambling rant) original questions:

The installer does not currently support f2fs, largely because it's an uncommon choice outside of mobile phones and SD cards, so nobody cares enough to implement it. It is also still considered experimental by many distros, upstream Debian included.
If you want f2fs root, you do you. There are guides on the 'net, but I'd expect an Arch/Artix user (BTW) to already be quite familiar with manual installation.

The default swap partition size is just that, a default. If you don't like it, change it.

If you don't know your own wireless SSID and finding out is "impossible", I really don't know what to say.

If you don't like the terminal emulators provided with the kde-desktop task, change them. Or install only the stuff you want on the base system rather than using tasksel from the installer.

The installer is not compatible with Ventoy (or more to the point, Ventoy hasn't implemented support for it among all its other distro-specific hacks), this is why Ventoy is conspicuously not listed under the instructions for making install media.

Bonus snark:

Oh come on, "Excalibur" is not a species of cod, now is it? Pelagic cod, Atlantic cod, Rock cod, Excalibur cod? I think not.

s/lowest/most/g

It does, <50MiB of memory is trivial on any readily available consumer hardware outside of embedded platforms - and if you're deploying on those you're going to be pulling more tricks than this.

Users with antique hardware are free to bolster their system with various memory-conserving tweaks if needed.

Wasting memory is just that, but trading memory for speed is a more subtle question and more often than not it's a net positive. Something that is a net positive for the majority of use cases (4GB RAM or 32bit haven't been that for a decade) is a good candidate for default configuration.

This is moot WRT Devuan in any case, because the defaults haven't changed since they inherited the init scripts from Debian.

The tmpfs functionality is not mysterious, but this thread kinda is:
a) We begin with a swearing rant about Debian, rather than reading the man pages or conf file where this is all explained.
b) Two people in a row go with "I don't know", rather than just doing 'grep -r tmpfs /etc/' and finding out.

Some days I really wonder if this whole board isn't just a place to bitch about upstreams, other distros, and anyone who ever dared to change anything.
Here I was thinking "other issues" was for questions and technical support.

For ML in firefox itself, about:config -> browser.ml.enable
What your search engine of choice does is another matter, having nothing at all to do with the browser, because:

Are two separate entities, obviously.

Also, direct comment from firefox dev WRT disabling ML features in future here. Apparently they actually listened for once when we all said "please give us a simple toggle not buried in about:config."

mkusb is an Ubuntu specific tool, so that's not particularly surprising.

The closest you will get to a "universal" bootable-media tool is ventoy, which should run fine on Devuan.

both provide .deb packages which will very likely work on Devuan. Have you tried them?

mkfs.fat -F32 /dev/[whatever]

Why on earth do we need a GUI for this?
Similarly, for writing single hybrid images to removable media, dd or cp work just as well as they always have.

It isn't. It's just a pain in the arse to package for and maintain in debian. "crap" is an assumption from those too lazy to investigate why it was dropped from the repos, a "sour grapes" justification from those too inept to work around that removal, or...

Indeed, and while the fully FOSS options are arguably better in many situations, there are a few corners where virtualbox still pulls ahead - IME those being a mature and fully featured GUI, and somewhat superior (primarily graphics) performance for windows guests.
It's also properly cross-platform (which kvm is not) and free (which vmware is not), so for the casual user who wants their VMs to be portable between different host systems without a bunch of faffing around it's rather convenient.

That's the primary concern (i.e. oracle not cooperating wrt backporting fixes), and it's exacerbated by the licencing making it very difficult for debian maintainers to do such backporting themselves.

As such, "stable" (and secure) virtualbox versions cannot be maintained in the debian (and by extension devuan) stable repos, but current upstream releases are still available in unstable.
The simplest solution (unless/until it appears in trixie-fasttrack) is to either use the upstream release .debs or backport it from unstable yourself.

Really? They still don't have bluetooth?
I get OpenBSD having not-desktop priorities, but FFS, bluetooth came out in 1998.

Main Rig:
Source: Random HP SFF POS machine, salvaged industial touchscreen, Auzentech X-Meridian 7.1 2G PCI soundcard, running Mopidy + webui kiosk on Devuan (curently oldoldstable).
Amp: Homebuilt 2U rackmount class A/B power amp, ~350WPC x2, based on Silicon Chip magazine Studio 350 project.
Main drivers: Cerwin Vega E315.
Subwoofer: 15" Cerwin Vega (I forget the model, onboard amp died and replaced with 200W class-D mosfet board I also forget the details of).

All old-school analog, all brute-force, pleasantly low noise and THD (the lousy sub amp doesn't count, it's a sub).

PC rig (not Devuan):
Source: Onboard analog audio (realtek ALC1220).
Amp: Homebuilt class A/B power amp, ~60WPC x2, based on Elliot Sound Products project 3A.
Drivers: JPW ML510

All power ratings on drives are peak values (for sizing power supplies etc.) unless otherwise specified. They have very little bearing on average power consumption, which will vary wildly with workload.
It's not as simple as "smaller number less power" either, since a faster drive will usually draw higher peak power, but get its work done quicker and drop back to idle sooner.

The only accurate  way to compare is, as always, to stop obsessing over manufacturer specifications and actually measure power consumption under your specific workload.

SSDs generally draw peak power under sustained write workloads, HDDs at spinup / spindle start.
The big power saving from SSDs comes from write-heavy workloads being intermittent, idle power draw being very low, and the transition being practically free.

With a HDD you have to choose between keeping the spindle running all the time (thus higher idle draw), or starting it only when needed (incurring access delays and spikes to near peak current).
For laptops there's the added complication of a spinning drive (i.e. unparked heads) being vulnerable to physical shock, so they usually run very short spindown timeouts - that's great for power consumption if the drive is usually idle, but terrible if it has to spin back up every other minute.

There's also an advantage in SSDs not needing to physically move heads around, so all areas cost the same to access (caching complications aside) and reads can use much less power than writes (typical workloads often being more read than write).
The power consumption of a HDD for a given operation will vary with where it is on disk, i.e. how many seeks and how far, and seeking to a read location uses just as much power as seeking to a write. (upshot: defragging your rust not only makes it faster, it also saves energy )

Again that's peak power, and it's simply because faster drives use more power under load. The bus itself makes very little difference in the real world, because ASPM.

IME the problems with nvidia drivers are largely those inherent to being out-of-tree (i.e. delays or patches WRT compatability with kernel releases), with a dash of nvidia doing things nvidia ways (nvidias architecture predates much of the current Linux graphics stack being standardised).
Those are minimised if you run a fixed-release binary distro like Debian, but can get pretty annoying on a rolling-release or if you build your own kernels from upstream head.

I did the LFS thing somewhere around 2002, because slackware packaging was arse and redhat was a steaming pile at the time. I only used my custom distro for a year or two, but the experience gained is still useful to this day.

I wouldn't recommend (B)LFS as a daily-driver in any sense (at least not without bolting-on some package manager anyway), but if you want to join the cadre of people who fix problems rather than just waiting for someone else to do it, it's a fine place to start.
Even if you only do it once for fun, learning how to compile from source, apply patches, and configure a system without all the convenience features in a big distro is valuable any time you encounter problems, need something that isn't in a distribution repository, or even just want to file a useful bug report.