

My understanding is that sandboxing is not mandatory for Snaps, but it is for flatpaks. Some of the Snap code not being open source, and generally the technology being centralised around Canonical apparently is off-putting for some.


My understanding is that sandboxing is not mandatory for Snaps, but it is for flatpaks. Some of the Snap code not being open source, and generally the technology being centralised around Canonical apparently is off-putting for some.


This ranking is very close to how I see this. Anything after Docker/Podman is out unless I absolutely need an application in which case keeping a record of dependencies is a good idea. But I want to know the work system will absolutely start in the morning hours from a deadline. Avoiding single points of failure is another way of course (ie multiple systems, OSes, backups, password managers etc).


True for most scenarios. Specifically with Syncthing, I find that it rarely fails and when it does there are good reasons and I need to do something about it (eg I used the wrong version config.xml recently trying to migrate between Syncthing setups).


You learn something new every day here ;) The good thing about kdialog is you can’t miss it. Thanks.


I went for this one and it works with both notify-send and /dev/pts/0. Not sure why it is better, but I opted for the latter. Simple, lightweight and versatile, suitable for any process.
Any KDE Plasma users reading this, to enable notifications history for these you can follow the instructions here. Many thanks everyone.


enx0050b6c0f7f3 is in fact my docked ethernet. I solved the problem when I discovered it was specified ‘unmanaged’ for NetworkManager. I added a note in my original post.


Actually, it says:
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service;enabled; preset: enabled)
Active:active](Loaded: loaded (/usr/lib/systemd/system/](Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service;enabled; preset: enabled)
And wifi works OK.
journalctl -xeu NetworkManager | grep enx0 gives:
Oct 14 12:43:11 tpkde NetworkManager[979]: <info> [1760442191.5289] device (enx0050b6c0f7f3): carrier: link connected
Oct 14 12:44:22 tpkde NetworkManager[9415]: <info> [1760442262.6582] ifupdown: guessed connection type (enx0050b6c0f7f3) = 802-3-ethernet
Oct 14 12:44:22 tpkde NetworkManager[9415]: <info> [1760442262.6670] device (enx0050b6c0f7f3): carrier: link connected
Oct 14 12:44:22 tpkde NetworkManager[9415]: <info> [1760442262.6677] manager: (enx0050b6c0f7f3): new Ethernet device (/org/freedesktop/NetworkManager/Devices/3)
It is a mystery why ethernet works as expected in a live USB session, but it doesn’t in the installed setup even though it is detected and there is no error message.


Interesting. Just tested, and my ethernet works in a live USB session, so it doesn’t look like it is locked by Windows. Also, I have been properly shutting down, only logging into debian for a couple of weeks but the problem persists.


Good idea. With the live USB my ethernet works fine right from the start. So, it’s not hardware or windows. The one difference I see between the live USB and my current setup is that in the live USB session sudo systemctl status NetworkManager.service returns also the line below which is missing when I execute the command in my actual setup:
audit: op="statistics" interface="enx0050b6cOf7f3" if index=3 args="2000" pid= 1957 uid=1000 result="success"
But Info Center in KDE Plasma lists “enx0050b6cOf7f3” as in my original post.
So, ethernet hardware functions, it works as expected with live USB and Windows. In the debian setup it is detected with an inet address, but NetworkManager ignores it.
DHCP also works – my wifi connection in this debian setup works, as do several devices connected to wifi and ethernet.
Windows refugee here. I installed Debian 13 with KDE Plasma on my main machine four months ago and I am still ironing out issues. Eg CUPS was asking me to login all the time and didn’t accept my credentials. After some days researching I discovered I had to log in as root. Then, I discovered I didn’t have root credentials for some reason. I had to create them and then add my local user to a group! Just to be able to use my home printer.
Or suddenly my clock was 62 minutes off. I discovered the NTP service was never set up properly and I had to install chrony.
I don’t see how I could have avoided using the terminal. These are only a couple of examples. No deal-breakers and on this occasion I had the time and determination to resolve them. I could have easily given up.