That's okay golinux, go back to sleep. You weren't doing anything useful around here anyway.

Not really, though plasma-pa is better integrated than kmix and IIRC the kde-standard metapackage pulls plasma-pa or kmix, with preference to the former.
ALSA not working is likely one of the usual suspects (e.g. muted master PCM or wrong default card), but OP was futzing with pipewire and close to a reasonable solution, so that's what I rolled with. (also an excuse to taunt gotard OFC, no reason to miss one of those)

You ran the first as root and the second as a user, so environment is obviously going to be different. If you want to know why you got "cannot open display:", test under the same conditions you got "cannot open display:".

Almost certainly an xdg .desktop file dropped by the gparted package (dpkg -L gparted) and looking in it will tell you which command is being called. This is GNU/Linux, there is no "standard" anything and not everyone runs XFCE.

Ed. Anyhow, this is all irrelevant. Your polkit install doesn't work:

Do you have an appropriate (GUI) agent installed (e.g. xfce-polkit)?

Package: polkit-1-auth-agent
State: not a real package
Provided by: cinnamon (6.4.10-2), gnome-flashback (3.56.0-1), gnome-shell (48.7-0+deb13u2), lxpolkit (0.5.6-2), lxqt-policykit (2.1.0-1), mate-polkit (1.26.1-4+b1), phosh
             (0.46.0-3), polkit-kde-agent-1 (4:6.3.6-1), ukui-polkit (1.2.2.2-1.1+b1), xfce-polkit (0.3+v20220621-3~excalibur1)

Also see fsmithred's comment WRT pinentry above.

The pcmanfm package recommends lxpolkit or polkit-1-auth-agent, xfe does not. If nothing else you have installed depends on polkit-1-auth-agent, it's possible you (auto)removed it.

No, it indicates that GTK cannot open the X display <null> (note the trailing ":[nothing]" in "cannot open display:"), likely because the DISPLAY variable is not set in root's environment.

Which "cmd line"? A real TTY? an xterm? whatever terminal emulator from whatever DE you're using?
GUI terminal emulators usually set DISPLAY, but su may or may not strip environment for security - I don't recall how it's configured in Debian these days. Check output  of 'env'.
SSH logins and TTYs do not, so one usually needs to correctly set DISPLAY and authorise the launching user to connect to the server (with e.g. xhost), see the X manual.

Regarding gparted not starting from the menu, I don't use gparted myself but the usual solution for GUI applications that need to run as root but don't handle privilege escalation themselves is to use some kind of launcher - pkexec (with org.freedesktop.policykit.exec.allow_gui set, see 'man pkexec'), gksu, kdesu etc.
Since OP didn't specify what command this "menu" is launching (or even what "menu" they're talking about, in which DE/WM), that's where my guessing ends on this one.

Uhh, needing to configure networking yourself? Fairly obvious, no?
Aside from that, likely a lack of GUI network configuration / tray widgets / whatever... Unless you install something else that provides those, of which there are several. None of them have the extensive feature set creep networkmanager does though.

NM is useful for systems that use a variety of transient networks, e.g. wifi, cell modem, bridges, tunnels, vpns etc. where the user wants a unified GUI that can configure and switch between those on-the-fly. Essentially, It's designed for coffee-shop-warriors with laptops.

NM is downright aggravating if manual network configuration is common, or a single, fixed, reliable connection is required at boot. e.g. the system has NFS mounts or the user regularly does 'ip whatever' or 'ifconfig whatever' to connect with static addresses or manual routing.

NM is completely pointless for servers or workstations that have fixed wired networking or rarely change connections.

Vague question -> vague answers.

Yes, with 6.8. That's still a ways off for Debian/Devuan, but one should be aware that X11 support has been in feature-freeze for some time and anything but critical bugs are very unlikely to be fixed.

DNS spoofing is a very old attack, as are most of the others mentioned. There are undoubtedly more which were not, and calling a fix for one a "defence" is like plugging one hole in a colander and calling it "sealed".
What's new here is breaking client-isolation so those old attacks all work again. It's basically ARP spoofing, and that was a gold-mine in terms of what you could do once you had control of the stream. DNS fuckery is a problem, but it's really just the tip of the iceberg.

If you use "coffee shop" style public wifi (which I personally think is a terrible idea), use a VPN or tunnel (preferrably with a pinned host cert).
If you administer the same, use separate access points and segregate them from your main network.

Ed. Ahh, I see I have reached the perfect post count.

There's so much wrong here I'm not even sure where to start.

1) epsonscan2-6.7.87.0-1.src.tar.gz is the source code, unless you feel like building the scanner tool from source yourself, you almost certainly want epsonscan2-bundle-6.7.87.0.x86_64.deb.tar.gz (from the "drivers" section of the download page) instead.

2) You can't just stuff a 'cd' command, a directory name, a file name, and a script with relative path into one line and expect it to work.
'cd' takes exactly one argument (the target directory), you provided three.

3) Adding more random stuff to a syntactically incorrect command-line won't make it more right.

4) Nor will changing the order of said random stuff.

* Get the right file.
* Unpack the archive

tar zxf epsonscan2-bundle-6.7.87.0.x86_64.deb.tar.gz

* Change into the directory created above (use tab-complete if you value your sanity)

cd epsonscan2-bundle-6.7.87.0.x86_64.deb/

* Run the installer script

./install.sh

If you inspect the stream, you'll see that the webserver incorrectly sets "content-type: text/plain" in the response header. Firefox is believing what it's told, as it should.
This is a disturbingly common misconfiguration in javascript-infested eula-gated corporate "download portal"s, and the javascript nonsense they use to make mirroring painful and ensure you agreed to all the things and clicked all the boxes tends to interfere with client-side mime-sniffing that might otherwise work around it.
It's not a browser bug.

Or, ya know, maybe admit that systemd does actually have some good points, and take inspiration and/or code from the things it does well.

Elogind works, it solves real-world problems, and it arrived at a time when the only alternative (consolekit) was an unmaintained mess nobody wanted to rely on if there was any other choice.

Now, we have more options. Turnstile and seatd are things, consolekit2 is actively maintained again. The situation might warrant reevaluation, for a number of valid technical reasons... Which "it's part of systemd, ick, kill it" is decidedly not.

BSD and other unixes had no choice, because removing all the linux-isms in [e]logind was arguably more work than fixing consolekit or implementing your own solution.

Touche, diplomacy is not my forte. My intent was was not personal disparagement but a technical disagreement on the measurement criteria. If I came across otherwise, my apologies.

My confrontational wording was largely due to ongoing frustration (here and elsewhere) with use of code or overall package size as a proxy for quality or usefulness. Obsessing over memory or disk space and perceived "bloat" does, as they say, "pull my chain", and doubly so when the numbers presented are potentially misleading.
None of that has anything to do with greenjeans personally of course, if it sounded like a personal attack, again, my apologies.

"Lol, in 29 mb" sure sounds like throwing shade at keepassxc on account of installed size, and that's a reflection on the developers, no?

Right, so documentation is bloat, and everyone speaks English. Got it.

Sure, I never said your program wasn't good. It's not your code or your contribution I took issue with, rather the misleading comparisons you keep making.

No, I'm giving you misery for making obviously skewed comparisons. Including translations isn't "bloat", it's basic accessibility.
Focusing on code size and/or memory footprint above all else is also rarely the whole picture, and frankly I'm tired of constantly hearing about it.

Same goes for the hair-shirt minimalism shtick in general, as popular as it appears around here. 4MiB or whatever is nothing, and translations are only loaded when needed.
Trading away features to be able to brag about how small something is is dumb, and not everyone needs or wants to compute on a turnip.
Debian/Devuan is a general-purpose distribution, running on 20 year old hardware is not and should not be the priority. There are whole distros dedicated to minimising memory and disk use.