[emphasis mine]
Believing in software is a fairly insane concept to begin with. Use logic when selecting tools, not trust, and certainly not faith or "belief".

There are a half-dozen potential NTP clients available, which you use is personal preference.
The most lightweight is opentpd, while the most modern (and most suitable for machines with intermittent connectivity) is chrony. I can vouch for both currently (as well as ntpdate and ntpsec in the past) working just fine on Devuan.

The real question is: Which one is your GUI nonsense looking for, how is it checking, and why doesn't it see ntpsec? If it's doing something really dumb like looking for a specific init script (or worse, systemd service on dbus), it's not going to work with openrc without some tinkering.

I don't recognise that GUI window, but it looks gtk-ish. Last I heard xfce didn't have a native timezone config whatchamacallit... So MATE maybe? If that's the case it's probably looking for timedatectl+timesyncd, which is a systemd thing so you are likely SOL.

Then again I really don't know why anyone would need a GUI for setting the time to begin with, so personally I'd just ignore it.

...Is doing much the same with its not-like-winblows features and workflows (single-click activation, primary buffer on mouse 3, window shading, etc.), but at least they keep most of them available behind configuration options (for now).

Make no mistake, that's all this is - pandering to "users who are unaware" and dumbing-down the interface to the lowest common denominator to make the windows refugees more comfortable.

Is the siren-song of the Fischer-price UI, and the perennial excuse for the removal of sharp edges, no matter how useful they may be when used sensibly.

Reason? Because it's useful, and people who know how to use it are are used to it.

Why yes, yes it is... Which is why I call out FUD and non-technical hyperbole like the above.

Oh, you mean interrupt the "Everything new is bad, everyone is out to get you, big-software corporations evil" circlejerk? Oops.

I do, with researched and tested technical support rather than vague, unsubstantiated "[x] is bad, don't use [x]".

This is pure nonsense, you clearly have no idea what you are talking about.

UEFI is a boot mechanism replacing the IBM-PC ROM BIOS bootstrap code and accompanying boot sector (MBR), which dates back to 1983 and is unsuitable for much modern hardware (notably no support for booting from NVME).

EFI is a dedicated partition used to store UEFI entries (or just a strange way of pronouncing UEFI without the "unified" because unknown reasons) much as as BIOS boot used a reserved sector. Nothing more, nothing less.
If you don't use UEFI you won't have and don't need an EFI partition, so saying the former is "the devil" and the latter is not makes no sense.

TPM and Secure Boot have nothing to do with UEFI, beyond the fact that the latter usually needs UEFI support to function as intended.

TPM and Secure Boot are operating system agnostic (so long as that operating system has a signed kernel for the latter), not exclusive to Windows.
They are not "traps" either, in that one can use or not use them as one pleases (unless your OS requires them for installation, which GNU/Linux does not).

TPM is a fairly generic crypto coprocessor and key storage. Secure Boot will use it if it's present, otherwise what you do with it is up to you - just like the rest of your hardware.

"Avoid evil feature" with no technical explanation (besides vague appeals to "youtube" wisdom) is not useful. Worse, it's plain-old FUD.

ECC is a hardware feature, requiring additional chips on memory modules as well as motherboard, CPU (IMC) and BIOS support. Few "consumer" systems have it, and if you do you will know.

Linus says many things.

There are "YouTubes" on eating laundry detergent, that doesn't make it a good idea.

The repo in the OP is 404 for me. Try here. README.md points back to the same nothing, but there are current packages in the repo.

FYI, setting the pass field to '0' will cause startup filesystem check/repair (if needed) to be skipped, this may or may not be what you want.

Nah, the question (is it one question or two? Internal or external drive? Which "file manager"?) is just vague, as usual.
The "automatically" in "automatically and without superuser password" kinda implies "without user action", hence myself (and chumpGPT) heading toward /etc/fstab.

Possibly. I vaguely recall gparted having an option to set a mount point (or maybe that was KDEs 'partitionmanager'), but that won't be any kind of "flag" set on the partition - it's offering to modify /etc/fstab for you.
I've never used it, and frankly I wouldn't trust it to not make a mess in my nice readable column-aligned file.

Don't mess with the line for the root filesystem, and it'll be fine.
Even if you did somehow manage screw that up, such things can be fixed by chrooting in from a livecd or the install media (as can 99% of "unbootable" situations in general).

Why are you asking a large language regurgitaion model for information that is readily available with a 15 second web search, or locally with:

man fstab

and

man mount

?
Fstab syntax is not complicated, and examples are all over the 'net.

For most purposes:
* Create a directory to use as the mount point and check/set permissions.
* Edit /etc/fstab to add a matching line, where the (space separated) fields are:
[device] [mount point] [filesystem type] [options] [dump priority] [check priority]
* Test that it works as intended with 'mount [mount point]'.

The first field can be a traditional device node (e.g /dev/sd[x][y]), any symlink under /dev/disk/by-[whatever] (e.g. /dev/disk/by-id/[drive model and serial number]), a 'UUID' tag (e.g. UUID=[filesystem UUID]), or a 'LABEL' tag (e.g. LABEL=[filesystem label].
Note that /dev/sd[x][y] names are assigned in the order the kernel detects devices, so they may shift around. That's why many examples prefer UUID, but there are several other options.
If you want to use UUID, you can print it with 'blkid -o value -s UUID [device node]'

Mount point can be any directory you like. Preferably an empty one, as mounting will "overlay" existing contents making it inaccessible (well, mostly, but that's into the weeds).

Filesystem type is self-explanatory, or 'auto' if you're lazy (or like to swap drives around).

Available options are explained in the mount manual, fstab takes the same format as the '-o' command-line option for the mount command.

The last two fields determine the order filesystems are dumped (don't worry about it) and checked. For non-root filesystems the usual is '0 2'.

** In case it's not obvious, where I say [foo], you're supposed to fill in your value and drop the enclosing [].

A couple of random examples from my systems, I prefer labels to UUIDs:

LABEL=spool    /mnt/spool    ext4    noatime    0    2

Unless it's a hotswap bay and I want to identify it by a specific SATA port, so any disk I put in it mounts at the same place:

/dev/disk/by-path/pci-0000:00:17.0-ata-1-part1    /mnt/bay1    auto    user,noatime,noauto,exec    0    2

If you mean polkit rules or fstab... They're answering different questions, because there are (at least) two mechanisms for "automatically" mounting filesystems.
/etc/fstab is system level, and is processed before any user logs in. If the filesystem is permanent and you want it always mounted regardless of what user or environment you are using, this is the most reliable method.

Polkit rules are used to allow an unprivileged user to mount things that are not in /etc/fstab, or things that are in /etc/fstab but don't have 'user' in the options field (since either of those scenarios would normally require root permissions).
Polkit is generally only used by graphical desktop/file managers, (i.e. not by the 'mount' command at the CLI), and will only help with "automatic" mounting if your GUI or file manager of choice has a facility of its own to "remember" mounted filesystems and re-mount them at login.

Filsystem uuids will end up in in grub.cfg if you use grub-mkconfig / update grub and haven't set GRUB_DISABLE_LINUX_UUID=true, and GRUB will pass them to the kernel and initramfs before fstab is read.
Partition and disk uuids are, as you say, irrelevant (unless you specifically choose to use partuuid as a search hint for grub)

It's proprietary, so who really knows?
"Negative feelings" about closed-source browsers and packages that are not compliant with Debian free-software guidelines or packaging policy, on the discussion board for a Debian-based FOSS distribution, are not particularly surprising.

That's really not a very high bar to pass, typhoid is "no worse" than lung cancer, but I for one don't want either.
Brave and the like are at least open-source, so any dubious "features" are readily inspect-able.

Everything is inline in the package postinst script, the repository configuration and key signature (base64, for reasons) are piped into the config files... Because of course that's how they do it - it's the best way to fuck around with the system (making sure their browser is the very highest priority in alternatives for example) and "support" multiple distros with a single .deb.
The crontab file is a symlink to /opt/vivaldi/cron/vivaldi, which is a copy-paste from the postinst and apparently rewrites the apt configuration and keys every day... Again, reasons, presumably.

Proprietary vendors are all the same when it comes to packaging, total disregard for established standards. Everything that can be an executable script is, windows lets vendors screw around however they like and execute whatever they want so that's how it must be done everywhere.