I understood nada. the success rate being 86% means what, successful transmission of state in 86% of cases? over what sample size? was there a control instance with randomized states?

if you format it thusly , then anyone can view it from their instance and can then interact with it.

aside from the obvious, wayland being the default choice on all relevant distros and DEs and being continously worked on, evermore projects switching to it (WINE most recently) whilst X11 is in maintenance-mode, the main thing for me and my deployed fleet is if you’re running a modern laptop, say with a 1080p or better screen, wayland is a must. primarily because of the output (UI scaling, effortless multi-monitor dock/undock) and the input (touchpad gestures, touch screens).

if your world is a desktop with a mouse and, say, XFCE, then you have very few of these things intruding on you and you don’t really understand the benefits benefit from it.

the other sandwich?

E2EE is explicitly prohibited by Telegram’s ToS so no alternative client is implementing it. seeing as how you’re already breaking it for non-important things, my suggestion is a pedal-to-the-metal approach.

then again, you don’t owe me or anyone anything.

if you’re already breaking ToS, include E2EE. the 17 ways your icons are colorificer and how your rounded corners are fresher interest me a total of zero.

they are switches for electron apps, as some of them default to run under X11. so for e.g. element, it should be flatpak run im.riot.Riot --enable-features=UseOzonePlatform,WebRTCPipeWireCapturer --ozone-platform=wayland.

you can check if all your apps are using wayland by running xlsclients in terminal while you got them open; an empty response means all wayland.

maybe reword the title, as this will inevitably lead to partisan turf wars in the vein of my-distro-can-beat-up-yalls-distro and such.

as to your thesis, yes, mint and ubuntu are important and needed as beginner-friendly it-just-works solutions that have things in place (like the mentioned driver manager) that are sorely needed for noobs. once they learn what’s what they are free to wander farther, as there’s essentially zero switching costs when moving from, say mint to fedora.

you’ll find low sympathy from experienced users as they can’t relate to people who are so much below their expertise level. case in point, a buncha people already mentioning package managers, ignoring the idea that a noob doesn’t know what that is.

if you’ve installed flatpak recently, say F40 onward, it should default to user. if it’s an old install then your flatpaks are system-wide. there isn’t a downside for either case per se, but user being the default for the future prevents potential issues.

my issue is, when I need to edit a .desktop file (to include ozon flags and whatnot) for a system-wide flatpak app, plasma doesn’t edit the app’s .desktop file but incorrectly inserts a symlink to the user-wide version (which doesnt exist). there are ways around that, like removing the symlink and manually copying the file from /var/lib/flatpak/wherever to ~/.local/share/applications/ and editing it there, but then plasma doesn’t pick up the change immediately so this works better for me.

no help to you, but a heads-up to anybody yet to deploy disks in such a scenario: always use encryption by way of LUKS2. you can set it up easily to unlock it on boot by a key file on the boot drive, thumb drive, TPM and such. so when a drive gets sold, RMA’d, etc., you got none of these issues.

source: sold my old drives recently and the shred procedure took ages. the new ones are encrypted so none of that shit no more.

can’t help with the switch but if your monitor has multiple inputs, you can use ddcutil to switch between inputs. so for me it’s:

ddcutil -g PHL setvcp 60 0x0f # DP1
ddcutil -g PHL setvcp 60 0x10 # DP2
ddcutil -g PHL setvcp 60 0x11 # HDMI1
ddcutil -g PHL setvcp 60 0x12 # HDMI2

then you can use udev rules or external triggers to switch, e.g. KDE connect’s “Run Command” etc.

I’m also trying to get the flicker-free boot. switching to systemd-boot improved the jerkyness, but the blank before the decrypt password remains.

I’ve enabled suspend-then-hibernate and whereas earlier I’ve had to endure this jerkyness rarely, now I have to witness it multiple times a day when resuming from disk. at least it’s faster than cold boot.