Often desktop client just cannot connect to mobile.
At first I noticed that this happens when desktop client starts to output in logs these (reported [1]):
kdeconnect.core: Too many remembered identities, ignoring "<id of KDE Connect on my android device>" received via UDP
Restarting desktop client helped, so I wrote watcher that monitors logs for such lines and restarts kdeconnect. But it turned out to be insufficient. Now I have this script running in background to restart kdeconnectd whenever connection is missing, and finally can use KDE Connect reliably:
#!/bin/dash -x
while sleep 1m; do
nmcli connection show --active | grep wifi || continue
kdeconnect-cli -l | grep reachable && continue
# notify-send 'No reachable devices via kdeconnect. Restarting'
systemctl --no-pager --user status app-org.kde.kdeconnect.daemon@autostart.service
systemctl --no-pager --user stop app-org.kde.kdeconnect.daemon@autostart.service
killall kdeconnectd
systemctl --no-pager --user start app-org.kde.kdeconnect.daemon@autostart.service
done
Uhm is it possible to mitigate second point by publishing encrypted article in social network along with is sending it to the agency to assign it timestamp? Or maybe in any blockchain if one does not like social networks.
Then if journalist does not like how mangled was his piece on publishing he can disclose encryption password to show everyone what he actually wrote in the article?
I usually try to optimize for CPU usage more than I do for RAM, mostly because I care about my battery life and for things to remain snappy. Although Vicinae does a lot of caching where it can it probably maintains a quite reasonable memory footprint when compared to apps with web frontends.
IMO after launcher is optimized to be truly idle while there is no interaction with it shaving memory usage becomes more important for snappiness and battery life. Extra RAM that launcher uses it the same RAM that other apps cannot use and therefore become more laggy. I expect on average shaving off 100 MB of launcher RAM usage will save more battery then reducing time for rendering its window by 0.1s
Or after a while without interaction bloated RAM get swapped out and launcher invocation need to fetch swapped out info.
For comparison here is how krunner looks on my current machine. After some time without interactions:
$ systemctl --user status plasma-krunner.service|head
● plasma-krunner.service - KRunner
Loaded: loaded (/usr/lib/systemd/user/plasma-krunner.service; static)
Active: active (running) since Sun 2025-08-10 20:31:40 WEST; 1 month 12 days ago
Main PID: 57749 (krunner)
Tasks: 37 (limit: 17782)
Memory: 64.6M (peak: 1.4G swap: 338.2M swap peak: 679.8M zswap: 12.4M)
CPU: 2h 58.702s
CGroup: /user.slice/user-1000.slice/user@1000.service/background.slice/plasma-krunner.service
└─57749 /usr/bin/krunner
It seems to me I feel how it was less on the first invocation.
So what should user do before byuing? Reasonably it might search for "<modelname> reviews". Such reviews include a number of throughput tests but they never test for latency.
This might be a culture issue. At least we should push for popular benchmark solutions to include latency tests. In ideal world laptop reviewers should also test keyboard latency but I do not see how it might be automated.
And I encourage anyone who cannot delete their WhatsApp due to personal constraints to set WhatsApp profile picture to QR code with the link to their preferred messenger and set name in profile to "W̶h̶a̶t̶s̶A̶p̶p̶ Telegram".
I suspect this might be cultural thing. Some people might formulate their strong opinions that your approach is bad and your task should be done in another as gentle suggestions to avoid hurting your feelings. And Claude learned to stick to this cultural norm of communication.
As a workaround I try to word my questions to Claude in a way that does not leave any possibility to interpret them as showing my preferences.
For instance, instead of "would it be maybe better to do it like $alt_approach?" I'd rather say "compare with $alt_approach, pros and cons"
Often desktop client just cannot connect to mobile. At first I noticed that this happens when desktop client starts to output in logs these (reported [1]):
Restarting desktop client helped, so I wrote watcher that monitors logs for such lines and restarts kdeconnect. But it turned out to be insufficient. Now I have this script running in background to restart kdeconnectd whenever connection is missing, and finally can use KDE Connect reliably: [1] https://bugs.kde.org/show_bug.cgi?id=506563