I’ve been using Fedora 32 while waiting for KDE Connect to be fixed in what otherwise would be, and for some time has been until recently, my main distro, KDE Neon. Ever since Neon rebased to Ubuntu 20.04, it has shared Kubuntu 20.04’s dysfunction with KDE Connect, which has become one of its most important features in my daily use.
One of the things that made this bug annoying was that the system logs gave no indication of what the problem may be. I tried swapping various dependencies of KDE Connect for newer (or sometimes older) versions where it was (easily) possible, but that didn’t work. I took a particular look at the security related things, as the behavior of KDE Connect is quite consistent with things being blocked by security measures, but without knowing where to start looking, I didn’t know how to proceed.
The day before yesterday, I logged into Neon on my G3 to see if anything had changed (as I have done from time to time while exiled to Fedora-land), and I saw that the update to KDE Plasma 5.20 had arrived. I let it update, and when it was done, I was disappointed to see that KDE Connect still did not work. It failed slightly differently than before, though, with the pairing between devices not being cancelled (meaning it disappears on both ends), but merely becoming inactive (so two PCs that are supposedly paired still could not communicate with one another using KDE Connect).
Well, clearly something had changed.
I looked in the syslog (dmesg), and I saw what I had been wishing for all of that time. Information, precious information! It was saying that OpenSSL had failed to verify the security certificate from the remote PC.
That gave me a place to start looking. After some searching for that error message and doing a bunch of reading, I saw that Neon/Ubuntu 20.04 used a newish, but not the newest, version of OpenSSL. When I checked the various versions of OpenSSL that PCs with working KDE Connect used, they were not the same version as the one in Neon. I found that Debian “Sid” used the newest release of OpenSSL, 1.1.1-h, if I remember correctly, and it had the requisite packages in .deb format, the same format that Ubuntu and friends use. Packages from different (but related) distros like that don’t always work, but in this case, they installed without any drama.
After that, KDE Connect began to work! I tested it in both directions, and it was working as it should.
I then booted Kubuntu 20.04 and installed the packages there, but it didn’t result in KDE Connect working properly. It changed the way it failed (kind of like how the update to Plasma 5.20 had before), but fail it did. It seems to me that either there is some other library it needs, something I or the Neon devs have already installed in Neon, or it was the change in Plasma that caused the changes mentioned in addition to the OpenSSL change that fixed it.
With that, my migration back to the Ubuntu family begins. There are some things Fedora does better, like how its command-line package manager (DNF) makes it super easy to install whatever package you need to provide a given missing file. If you got an error message that says that you are missing /usr/bin/fluffynoodle, you can simply type ‘sudo dnf install /usr/bin/fluffynoodle’ and it will look through its database of packages and find one that provides that file and offer it to you. This truly is a “superfeature” that I will miss in Ubuntu-land.
Updates are easier in Fedora (KDE) than in Neon too. When the tray icon indicates that updates are available, in Fedora, I click that icon and it pops up a list of the available updates right there, each with a checkbox that comes pre-checked, so that I can uncheck the ones I don’t want before proceeding. It will then perform the updates that are still checked, easy peasy.
In Neon and Kubuntu, clicking that same tray icon launches Discover, the KDE software manager (not the same as a package manager like Synaptic), and that will show the updates. It’s an extra step that doesn’t really need to be, and while it does work, it’s not as slick as the Fedora way, or the way that Mint does it, for that matter.
I am going to see if I can bring that bit to Neon. I do know that both Neon and Fedora KDE use PackageKit to provide some package management abstraction (so that tools like Discover can work with Fedora and Neon despite the incompatibility between Fedora’s DNF, which uses the RPM format, and Neon’s APT, which uses the DEB format).
So many other things, though, are better in Ubuntu-land. The way it handles kernels is much better, with old kernel versions not being immediately purged from the repo, and none of the older versions being uninstalled without explicit consent of the user. Fedora prides itself in being a “cutting edge” distro, and as a result of that, it releases new kernel versions almost as quickly as the distro-independent kernel team (led by Linus Torvalds) releases them. This can cause problems if the programs the user is running on that distro don’t keep pace, as Veeam backup hasn’t (and apparently can’t, according to the lead Veeam dev, with some changes that were made to the 5.8 kernel). I hope that issue is resolved soon, but until it is, using Veeam on Fedora 32 meant having to jump through some hoops that would not have been necessary in Ubuntu.
Fedora comes set up by default to keep only three kernel versions installed at any one time. That means that as soon as the third revision of the 5.8 kernel was installed on Fedora, the last version of 5.7 that had been installed previously would be removed automatically, with all three kernel slots being occupied by versions of 5.8.
If the user were then to try to use Veeam and discover it did not work (gee, wonder who I could be talking about there?), he’d think he had to go back to 5.7… but he’d quickly discover that 5.7 had already been wiped from the repo. If you look in the Ubuntu repo (which Neon, Mint, etc. use), you would see a ton of older kernel versions in there, so it would be easy to select any one of them and install it if you needed to. Ubuntu also doesn’t delete older kernels until you tell it to, so 5.7 would not have been deleted as soon as 5.8.2 was installed. I always keep the previous point release available upon upgrading, keeping it generally until the next point release just in case.
For Fedora, I found that they have a repo that has all of the older kernels, and I was able to grab the last release of 5.7 (which had gone EOL in terms of its official support period from the kernel devs, who operate on a rapid release, short support period basis for most versions of the kernel). The 5.4 kernel is a LTS release as defined by the kernel devs, so it gets 5 years of updates, making it a good match for Ubuntu 20.04, also a LTS release with a 5 year support period.
Ubuntu uses a behind-the-scenes security suite known as Apparmor, and I’ve never had any issues with it in my time using Ubuntu family distros. Fedora uses SELinux, and that thing is notorious for being an annoyance, constantly blocking access to things and breaking functionality in the absence of any actual security threat. In the short time I used Fedora, it caused a lot of issues… not insurmountable ones, but it took a lot of attention and fiddling to keep it working.
I don’t know how well the two competing security suites work at providing protection, but if it’s anywhere close to being the same, Apparmor is much easier to live with.
Fedora also takes a lot longer to boot than Neon, and logging out or restarting usually brings a “logout blocked by Python3” message, which was really obnoxious. It’s only blocked once, so another attempt will work, but it’s annoying. It can probably be fixed, but I never got around to trying.
After using truly excellent package managers like Synaptic and Muon (Synaptic being the better of the two, IMO, as implemented in Neon), using DNFDragora in Fedora is a disappointment. It works, but is really slow, and it can only to the most basic things that Synaptic can do. It’s improving, but Synaptic is miles ahead. Fedora has no truly decent graphical package manager, and that is a big loss to me. For command line fans, DNF is second to none, but I am not one of the long-time Linux users who prefer the command line for nearly everything. I prefer graphical means of doing things where possible.
I’ve informed KDE devs of this discovery, FWIW, so they can hopefully get the official version working in Neon and other Ubuntu family members.
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
