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).
I remember the time applications came on floppies, 640kb of RAM was indeed enough for anyone, and people competed in writing games in one line of BASIC (yes, that was 255 characters code max). Containers feel horribly wasteful to me, but I came to accept there aren’t many realistic alternatives for the average users who need reliability with zero effort. Making a note of dependencies in case you need to backtrack is not a realistic proposition for most. But I can understand why some users will want full control and a lean setup.
I agree with the popular view that Debian Stable + KDE Plasma + Flatpaks (or Appimage, Docker) strikes a balance between system reliability and freshness in selected applications when that counts. I may be missing updates for KDE Plasma but v6 is quite mature so I don’t mind. I know storage is cheap but I am instinctively uneasy with containerisation as it’s done by Flatpaks etc because of the duplication you get with all-in. But if that’s the price of reliability, so be it. It’s just that sometimes there is only a PPA or a .deb, which is why I asked.
EDIT: I just tried distrobox for the first time. It is amazing how efficient it is. I ran Firefox on Arch and I couldn’t tell the difference in resources. Amazing really.
I have been preparing the move to Linux for years, switching to FOSS cross-platform applications on Windows and installing Linux on my secondary machines. A few weeks ago I made my work machine dual boot with the intention to remove Windows completely. I find that I never log into Windows at all already, and my Debian Trixie + KDE Plasma experience is the same in many areas (mainly because I use the same applications as before) and vastly better in others.
There were issues I had to solve but nothing major. It is true that Windows has been very stable and efficient for me, but people forget that when this happens it is the result of many years of learning, fine-tuning, decluttering and getting used to Windows. You get to that stage with Linux very quickly, and it feels much better.
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 have tried Syncthingtray and Syncthingy. I found the former did too much that I never used, and the latter was an unnecessary process doing very little while always running and adding another icon to the tray. For me periodic checking with a script is enough and more efficient for the rare situation where Syncthing crashes of fails to start.
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.
I share your concerns about trust. With flatpaks we can still read the source and commits, but not many will or can do this every time they install and update software anyway. In this sense, we have little choice but to trust the verified developer and the community, who may of course be compromised too, regardless of distribution method. I suppose with flatpaks we have to check permissions and make them as restrictive as possible.