I agree with you that the root password should be in shown in a very big and readable font at the ISO download page BEFORE the download button or at a different relevant place.
Not having root privileges by default is not a bad thing, could be annoying since not all applications use Polkit for requesting elevated permissions (Hi Dolphin).
Otherwise, for terminal-based applications use su at your own risk.
Unfortunately it’s the only Linux email client which is the most matured and still well maintained.
KMail gets barely updates nor new features. Most of its developers develop a new mail client, called Kube, but it is still not stable and barely usable when your mailbox is an Office 365/Google Apps/Whatever mailbox with custom domain.
Also KDE’s PIM runtime (especially its dependency akonadi) is pretty resource hungry and unstable. You’ll get mariadb running in the background 24/7 for gratis, even when you don’t need KMail for today. Beat me why they didn’t use SQLite or similar lightweight data stores. Or start akonadi and mariadb only when it is needed (like picking contact addresses).
Whoes last release is already 1 year and 4 months ago and compared with the popular browsers has a less rich featureset. There seems to be non-automated commits which fixes bugs, but beat me why they don’t release a new version.
Well that’s a valid privacy concern. Since kuserfeedback is still collecting data despite it is “Disabled”,
Unless you (or someone else) already tried, you need to target the source of the privacy problem. Thus address the issue at the KDE developers. If the request lands on deaf ears, I think it’s indeed time to resolve the problem at distro-level by compiling it without kuserfeedback or add a new XDG-AutoStart-entry which removes those privacy records at startup.
Otherwise you could also demotivate the spying KDE developers by sending garbage as feedback
On the contrariety even, Packages packaged as AppImages are barely bloatware. All batteries are included, the handling of the dependencies is the full responsibility of the packager/developer. No need to install extra dependencies or figure out what you’re missing. I guess you confuse it with Flatpak and Snap, which indeed could fill up the drive. Especially not fun when you’re using an SSD.
When I had an Ubuntu laptop at work, I often found myself in conflicts between the system updater and Snap because via one application I installed via Snap, required a new version of a Gnome library which is incompatible with the rest of the system but somehow the “container-layer” which Snap should provide wasn’t there. (But eh, Ubuntu…).
Also FireJail solves a different problem than what AppImage, Flatpak and Snap try to achieve. AppImage, Flatpak and Snap aren’t virtualisation/containerisation solutions.
For the rest, please refain from ad populum reasonings like “Everyone is using X” and “Not everyone has Y”.
Most of your problems just require some deep dive in how some subsystems of the Linux ecosystem work (like Lost+Found) and fiddling with the configuration. I bet you did that as well when you ran Windows 