2024 Epic Disappointments With Linux
This is to pin a recent long post, SPECIAL: Epic disappointments with Linux (not for the mentally retarded), which collects a large number of issues, explained.
Due to its excessive length, and despite the 25 chapters listed at the top, I know for a fact that people found it a difficult read. This is why I created a simplified list of the included topics. I added this list as a comment at the end of the post, but I’ll include it here too.
List of the topics discussed in this long post:
1. A quick exposition of my journey with Linux since 1994–1995, even listing a number of defunct distros.
2. Linux is designed based on an architectural decision that requires a new kernel instead of just installing a device driver.
3. Another poor design decision is to compile all the packages for a fixed version of the system libraries instead of a minimum version of those libraries.
4. Immutable distros are not the future! Not for the desktop, anyway. Flatpaks and snaps cannot fix the situation of small apps that nobody bothers to create a Flatpak for, such as FeatherPad.
5. In Linux, to have the last version of an app, you either need to have the last version of everything (by using rolling-release distros), or you need to use Flatpaks, snaps, or AppImages; or you might build from source, but that’s not always possible if newer version of system libraries are needed.
6. “In contrast, there is much more freedom (sic) in Windows. You only upgrade the programs you want to upgrade, full stop. If you want to use an IrfanView from five years ago, you can just do that.”
7. Linux distros don’t properly understand the semantic versioning major.minor.patch. A first effect: they don’t update the apps to their next patch level in a given point-release version of a distro.
8. A second effect: they adopt specific versioning to hide the real version, especially for the kernel. E.g. the kernel is not updated from 6.1.27 up to 6.1.90; instead, it’s updated from 6.1.0-1 to 6.1.0-21, but 6.1.0-21 is actually 6.1.90.
9. As an example of the first effect: the CVE-2021-32563 case, when Thunar should have been updated from 4.16.6 to 4.16.8, or a patch should have been backported, but most point-release distros didn’t do that, letting Thunar vulnerable.
10. Side note: PCManFM and PCManFM-Qt always had, and always will have the vulnerability described by CVE-2021-32563, but absolutely nobody cared to notice that and to fix it!
11. A case of stupid double versioning: libwebkit2gtk-4.0-37
is not installable, because only libwebkit2gtk-4.1-0_2.44.0-2
is available. Installable is e.g. libwebkit2gtk-4.0-37_2.44.0
; but in version 4.0-37_2.44.0
, what part is the most important, 4.0-37
, or 2.44.0
? Because the version 4.1-0_2.44.0
also contains 2.44.0
, but otherwise it’s 4.1-0
, not 4.0-37
, so it’s not good.
12. Fedora’s point-release model is a complete lie when it comes to the kernel. How is this not a rolling-release distro when the most important part of an OS, namely the kernel, is constantly upgraded?
13. Arch and the gang are using a package manager, pacman
, that’s so stupid that you might end up unable to remove something that you installed! Say you install the MATE desktop environment, which brings in a number of dependencies. Trying to uninstall Caja with pacman
fails, because, as per pacman
‘s judgment, “removing caja breaks dependency 'caja' required by insert_a_dependency_required_by_caja
”! That’s reverse logic. I’m just trying to uninstall Caja, and it’s Caja the package that requires those other packages, not those packages that require Caja! Pamac is equally stupid. Octopi is much smarter, and it behaves as it should. All the package management systems that use .deb and .rpm can handle that; in Arch land, only Octopi can.
14. Arch and its derivatives, including Manjaro, are replacing the running kernel as it’s running, with unexpected consequences! I prove that everyone else only replaces the kernel after a reboot; in the case of Fedora, nothing is replaced until after a reboot! If system libraries are replaced in place, without a reboot, Debian and Ubuntu are even telling you which services should be restarted. A full restart isn’t always needed, and openSUSE also gives you the proper information about that.
15. Incidentally, Fedora can be stupid when, uBlock Origin being a package, you’re told you need to restart the system to update it!
16. Despite Arch offering two kernel lines (kernel
and linux-lts
), and some derivatives (EndeavourOS, Manjaro) maintaining even more lines, the problem is that for each kernel line, only the very latest version is kept on the machine (and in the repositories)! All the other distros keep 2–3 versions by default and by design. There is no way I could use a distro that doesn’t give me the chance to boot the previous kernel as a backup.
17. Manjaro’s claims to stability because of delaying packages for 1–2 weeks cannot be sustained logically. For one, this breaks AUR’s packages (or Chaotic-AUR’s builds). Sure enough, Manjaro tells you that you shouldn’t be using AUR… Hello, freedom! Not.
18. I explain what kind of up-to-dateness I used to require before KDE6 was released. Now I’d keep running KDE5 for a while. Criteria include: (i) A distro that works well on all three computers I want to use Linux on, to simplify my life; (ii) A distro in which other relevant software needs to be recent enough, so I won’t be forced to use Flatpaks, unless in exceptional cases. Note that some major pieces of software have their own repos, or there are alternate installation methods that solve this problem.
19. In the process, I explain why the other desktop environments can’t match KDE’s design and functionality, with links to sections of a previous post of mine that offers detailed explanations.
20. Why not GNOME: Files (Nautilus) is for those who don’t need productivity (it’s the only file manager to lack a Compact List View!), and GNOME is dumb anyway.
21. Why neither MATE, nor XFCE: Ubuntu MATE, the best-looking MATE out of the box, borkes Qt themes; and new features in Thunar are implemented unprofessionally.
22. KDE is not perfect, but Cinnamon is worse: This covers a lot more, starting with the stupid trend that copies macOS and uses the icons-only task manager instead of displaying the windows captions. In addition, Cinnamon makes a really bad use of the screen space.
23. Qt and KDE fix a bug in the Linux Kernel: For exFAT, Linux has a kernel bug that only Qt works around. One more reason to use Dolphin, and KDE.
24. I explain why AlmaLinux 9 with KDE from EPEL is a good choice. I link to another post which explains why Rocky Linux is not something I could trust.
25. However, the RHEL update model can, and will, break its clones on a regular basis, should they use EPEL. E.g., there are no separate “EPEL9.3 for EL9.3” and “EPEL9.4 for EL9.4” repos, so during the transition from e.g. 9.3 to 9.4, things will break, temporarily.
26. As a result, the RHEL models has what’s worst of two models: (i) The drawbacks of a LTS distro, which is to have most packages frozen in obsolete versions. (ii) The drawbacks of point-release distros that release twice a year, which is to have the risk of getting broken systems twice a year!
27. The only RHEL-related distro that updates the packages and introduces the occasional package upgrades continuously is CentOS Stream, which is demonized for the wrong reasons. (CentOS Stream 9 is not the rolling-release path to CentOS Stream 10! It’s the rolling-release path to CentOS Stream 9.4, 9.5, and so on. Not a rolling-release model à la Tumbleweed or Arch.) There’s a special rolling release of EPEL that is always in sync with CentOS Stream: it’s called EPEL Next (epel9-next
).
28. The RHEL versioning model has a huge unacceptable implication: Red Hat doesn’t support e.g. 9.3 not a single day after the release of 9.4! This also impacts its clones.
29. A breakage that I experienced when I upgraded AlmaLinux 9.3 to 9.4, with the corresponding KDE upgrade from EPEL, includes a LC_ALL
issue that I explain in detail. Mixed locales such as en_DE.UTF-8
are legitimate, but bugs are not uncommon with them among various distros. If “cannot change locale” and “Cannot find an example for this locale” can be fixed easily enough, I had one more bug in my setup.
30. Specifically, the dead keys stopped working in KDE’s apps! The culprit was a parasite LC_ALL
entry in ~/.config/plasma-localerc
. The real culprit, though: KDE’s System Settings can only set individual LC_*
values in plasma-localerc
, but it cannot set or reset LC_ALL
, which is beyond stupid! (At least, this is what happens in 5.27.11 from EPEL.)
31. I explain how the inclusion of Paragon’s NTFS driver without enough testing in kernels 5.15 and newer was a catastrophic decision. It can occasionally corrupt the filesystem, hide, or delete files, and beyond the reports here and there, I too was a victim of such a broken driver! The old ntfs-3g
(FUSE) driver, while slow, is reliable. There are several reasons to distrust the new ntfs3
driver, and the entire kernel team for their irresponsible decisions!
32. Several examples of how the Linux kernel introduces regressions and new bugs with each major version. Again, nobody cares about what the users think, say, need, want. What do you want your kernel upgrade to break today? The crazy complexity of today’s software is exactly the reason why code shouldn’t be pushed into the kernel at this insane rate!
33. Some more kernel team dumbness: they started using CVEs as a bug tracking system!
34. Pros and cons, and other notes regarding a number of distros, starting with openSUSE.
35. Same for Debian, which has a few topics that needed to be developed. Debian is “a senile dinosaur” when it comes to some packages, with examples; and the new Debian Project Leader doesn’t own a smartphone, because “I value freedom deeply”! Why there are no newer KDE builds for Debian stable: the case of Norbert Preining and Martina Ferrari, born Martin Ferrari (with XY chromosomes). While we’re at that, I compare GNOME’s and KDE’s codes of conduct.
36. Notes on: MX Linux, Ubuntu and its flavors (plus Linux Lite), Linux Mint.
37. In the process, criticism of MATE’s dark themes screwing the Qt-based apps, and of Cinnamon’s design.
38. Some extra considerations on KDE, starting with another Dolphin exclusivity (beyond the exFAT fix, see number 23 above). What do you expect when you’re using a graphical file manager to copy a large file to a slow destination, and you change your mind, so you hit the Cancel button? The file manager should cancel the copy operation graciously, by issuing a fclose()
followed by remove()
, so that nothing remains in the destination. This is what Windows has been doing since, like, forever. Not so in the open-source land. Here, only Dolphin does that! All of the following file managers leave incomplete, broken files in the destination: Nautilus/Files, Nemo, Caja, Thunar, PCManFM, PCManFM-Qt. The problem with such broken, incomplete files is that people would assume they’re complete, valid files! “Oh, so those files got copied, great.” Except that they weren’t!
39. Still, Dolphin deserves some criticism for how it behaved when I accidentally tried to copy a large file over itself while the free space was low, and Dolphin said that there wasn’t enough space. I wasn’t asked whether I wanted to overwrite it or to create a new file with a different name.
40. A talk on natural sorting in file managers.
41. Fears that KDE might not be headed in the right direction, because of contamination with unergonomic UI concepts. KDE6 is summarily criticized.
42. Whitherwards? I explain that, for the time being, I’ll keep using AlmaLinux with KDE on two systems, and probably Kubuntu 24.04 LTS on an older laptop.
43. A late addition: Clement Lefebvre on libAdwaita, and GNOME’s impact on GTK and XFCE. Why on Earth did Clem decide to ever stop supporting KDE?
44. An even later addition: A bug (or is it a feature?) in KDE6, namely a queer start button positioning if Application Menu is used.
45. Breaking News: openSUSE Leap 15.6, quick analysis.
46. Disappointments on the improvements KDE 6.1 was focused on, and on KDE neon’s slowness to rebase on the latest LTS.
What I did not even mention:
1. Wayland. It’s definitely not production-ready, not even on Intel graphics. I understand the architectural limitations of X11 in terms of both performance and security, but I’m not a gamer, and the so-called security issues have been debunked by Dedoimedo; and even if I were. If it ain’t broke, don’t fix it. If you “fix” it, make sure it’s really a better product when you shove it up my ass. (Dedoimedo had two takes on Wayland: in 2021 and in 2024.)
2. Nvidia. I can’t even. Thankfully, I’m not a gamer, and I don’t do video processing on my computers, so I’m Nvidia-free.
A follow-up in section 3, When someone thinks—at least in part—like me, of KDE5, KDE6, tiling and other rants.
For a historical perspective, you could also read a production from April 13, 2007: The Sorry State of the Open Source Today. Obviously, many of the links are no longer valid.