Stopwatch1986

joined 2 years ago
[–] Stopwatch1986@lemmy.ml 1 points 4 days ago (1 children)

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.

[–] Stopwatch1986@lemmy.ml 1 points 5 days ago

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).

[–] Stopwatch1986@lemmy.ml 1 points 5 days ago (3 children)

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.

[–] Stopwatch1986@lemmy.ml 4 points 1 week ago* (last edited 1 week ago) (1 children)

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 recently moved my work machine from Windows to Linux and chose Debian Trixie + KDE Plasma for the stability. The advice is that if stability is your priority, you should try to avoid breaking Debian. I understand that adding third-party sources can cause dependencies conflicts, and must be avoided at all costs. I also understand that Flatpaks, AppImages, Snaps, and Docker/Podman images are safe because they don't interfere with the system dependencies. So far, so good. What I don't understand is what happens with other ways of installing software (eg .deb, tarballs).

I know it's a contentious subject but if stability is the priority, how would you rank different methods? I may be wrong but my take is:

Debian repository > Flatpak > Appimage > Docker/Podman > Snap > tarball

To be avoided: .deb for Debian > .deb for Ubuntu > PPAs

Eg Viber is available as an official AppImage (with certain bugs), unofficial flatpak (with other bugs), and an official .deb for Ubuntu (which is probably a bad idea for Debian anyway). Viber support told me they don't support my OS.

[–] Stopwatch1986@lemmy.ml 6 points 1 week ago

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.

[–] Stopwatch1986@lemmy.ml 1 points 1 week ago

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).

[–] Stopwatch1986@lemmy.ml 3 points 1 week ago* (last edited 1 week ago) (1 children)

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

[–] Stopwatch1986@lemmy.ml 3 points 1 week ago (1 children)

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.

[–] Stopwatch1986@lemmy.ml 2 points 1 week ago

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.

 

Is there a simple GUI application that will monitor running processes periodically and alert the user when a process is not running? The ones I have found are far too complex (eg Monit). I am sure this is trivial to achieve with a script, but I'd rather use a GUI.

A use case would look like this: every 60 minutes check if Syncthing is running and display a notification if it's not. In my experience, Syncthing is very reliable when it launches successfully but there may be an issue with conflicting versions that may prevent it from running at boot. Syncthing has no way to alert the GUI user when something goes wrong and you may find after you left home that your laptop hasn't synced. Checking manually is a headache, prone to errors and goes against the idea of fit and forget.

(Debian Trixie with KDE Plasma)

[–] Stopwatch1986@lemmy.ml 1 points 2 weeks ago (1 children)

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.

[–] Stopwatch1986@lemmy.ml 1 points 2 weeks ago (3 children)

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.

[–] Stopwatch1986@lemmy.ml 1 points 2 weeks ago

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.

 

Another Windows migrant here. I can’t get my ethernet to work but wifi works OK. I am almost certain that when I installed Debian Trixie with KDE Plasma a few weeks ago, ethernet worked but it stopped a day or so later. Info Centre reports:

2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 54:ee:75:52:01:23 brd ff:ff:ff:ff:ff:ff
altname enx54ee75520123
3: enx0050b6c0f7f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:50:b6:c0:f7:f3 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.92/24 brd 192.168.1.255 scope global dynamic noprefixroute enx0050b6c0f7f3
valid_lft 3419sec preferred_lft 2969sec
inet6 fe80::8437:d694:3204:62ff/64 scope link
valid_lft forever preferred_lft forever

I deleted the wired connection in System Settings | Wi-Fi & Networking and it was recreated which probably suggests the ethernet connection is detected even if the fields there are all blank. Also, the internet traffic plasmoid shows enx0050b6c0f7f3 with around 1/5 of the cumulative traffic of wifi.

I tried the obvious things, just in case. I disabled the firewall, restarted the router, deleted the wired connection, played with settings in Wi-Fi & Networking and tried dhcpcd.

$ sudo dhcpcd 
main: control_open: Connection refused 
dhcpcd-10.1.0 starting 
dev: loaded udev 
DUID 00:01:00:01:30:54:2e:d5:00:50:b6:c0:f7:f3 
wlp4s0: connected to Access Point: glocal 
enp0s25: waiting for carrier 
enx0050b6c0f7f3: IAID b6:c0:f7:f3 
wlp4s0: IAID 86:9b:42:5e 
enx0050b6c0f7f3: soliciting an IPv6 router 
wlp4s0: soliciting an IPv6 router 
wlp4s0: rebinding lease of 192.168.1.122 
wlp4s0: probing address 192.168.1.122/24 
enx0050b6c0f7f3: rebinding lease of 192.168.1.216 
enx0050b6c0f7f3: leased 192.168.1.216 for 3600 seconds 
enx0050b6c0f7f3: adding route to 192.168.1.0/24 
enx0050b6c0f7f3: adding default route via 192.168.1.254

and sudo systemctl status NetworkManager.service returns

●NetworkManager.service - Network Manager
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service;enabled; preset: enabled) 
Active:active (running)since Sun 2025-10-12 23:59:31 BST; 47min ago
Invocation: a3faea14d3dc48e29a2e2d27750ca082
  Docs: man:NetworkManager(8)
  Main PID: 98676 (NetworkManager)
 Tasks: 4 (limit: 9149)
Memory: 6.3M (peak: 7.1M)
   CPU: 2.457s
CGroup: /system.slice/NetworkManager.service
└─98676 /usr/sbin/NetworkManager --no-daemon

Oct 13 00:03:10 tpkde NetworkManager[98676]: <info>  [1760310190.8454] dhcp4 (wlp4s0): activation: beginning transaction (timeout in 45 seconds) 
Oct 13 00:03:10 tpkde NetworkManager[98676]: <info>  [1760310190.8623] dhcp4 (wlp4s0): state changed new lease, address=192.168.1.85, acd pending 
Oct 13 00:03:11 tpkde NetworkManager[98676]: <info>  [1760310191.0217] dhcp4 (wlp4s0): state changed new lease, address=192.168.1.85 
Oct 13 00:03:11 tpkde NetworkManager[98676]: <info>  [1760310191.0237] policy: set 'glocal' (wlp4s0) as default for IPv4 routing and DNS 
Oct 13 00:03:11 tpkde NetworkManager[98676]: <info>  [1760310191.0440] device (wlp4s0): state change: ip-config -> ip-check (reason 'none', managed-type: 'full') 
Oct 13 00:03:11 tpkde NetworkManager[98676]: <info>  [1760310191.0839] device (wlp4s0): state change: ip-check -> secondaries (reason 'none', managed-type: 'full') 
Oct 13 00:03:11 tpkde NetworkManager[98676]: <info>  [1760310191.0841] device (wlp4s0): state change: secondaries -> activated (reason 'none', managed-type: 'full') 
Oct 13 00:03:11 tpkde NetworkManager[98676]: <info>  [1760310191.0855] device (wlp4s0): Activation: successful, device activated. 
Oct 13 00:03:11 tpkde NetworkManager[98676]: <info>  [1760310191.1033] audit: op="statistics" interface="wlp4s0" ifindex=4 args="2000" pid=1511 uid=1000 result="succe> 
Oct 13 00:33:10 tpkde NetworkManager[98676]: <info>  [1760311990.8671] dhcp4 (wlp4s0): state changed new lease, address=192.168.1.85

Not sure if this is relevant, but DCHP is handled by pi.hole on a Raspberry Pi. This has been working serving multiple devices for a long time without issues. Also, this is temporarily a dual boot Windows/Linux setup. When I log out and into Windows, everything works as ever.

After several days trying, I ran out of ideas. Can someone help please.

EDIT: SOLVED! In case it helps others, reading https://wiki.debian.org/NetworkManager closely, I ran nmcli device which showed that specific ethernet interface as 'unmanaged'. I am not sure why. Then, I followed the instructions below:

If you want NetworkManager to handle interfaces that are enabled in /etc/network/interfaces:

Set managed=true in a drop-in file in /etc/NetworkManager/NetworkManager.conf.d/ or directly in /etc/NetworkManager/NetworkManager.conf.

Debian documentation could be more accessible, but it is invaluable. Thanks all for your help.

view more: next ›