Monday, June 20, 2022

The Problem with Manjaro/Arch

I have been using Manjaro for about a year. My initial love for Manjaro came about because of three things. One, it made the installation of the Nvidia driver as painless as possible – by allowing you to boot directly using the binary driver and avoiding the need to mess with nouveau and nomodeset (looking at you, Fedora).

Two, Manjaro ships the latest Linux software in its repositories. This is a welcome change from Ubuntu or Debian; the packages in the repositories can be badly out of a date on an Ubuntu LTS, and even the latest Ubuntu might run a version or two behind. Related to this, I am shocked by how many packages in the Ubuntu repositories just don’t work. For example: Back In Time, a popular backup tool, does not work on the latest Ubuntu 22.04.

Thirdly, Manjaro also ships the latest releases of various desktop environments, allowing the user to try out different UIs if they don’t like the one they started with. (Or because they wanted to find out which DE actually supports fractional scaling properly… signed, yours truly.)

Alas, it was not to be. A few days ago, the Manjaro install on my Nvidia-powered desktop PC imploded after I upgraded using pamac. I do not mean to say that something was broken after an update; I mean to say that the pamac froze halfway through, and rendered the entire system unrecoverable. Firefox stopped working. KDE wouldn’t respond to mouse and keyboard input. After a force restart, I was left with an unbootable system with no kernel.

This tells us a few things. Firstly, pamac is a horrible program. But these were not the only issues that troubled my Manjaro experience. For example, GPG signature errors are depressingly common on both Arch Linux and Manjaro.

Another problem, inherent to the very design of pacman/Arch Linux, is that you cannot perform partial upgrades safely. Need to grab a small package/program in order to accomplish a task? You may well have a multi-gigabyte update that needs to be applied first, with a real risk of bricking your system, as I found out when I innocently tried to install a 100KB package.

Furthermore, if the update command pacman -Syu fails, it will not fail gracefully like on, say, Fedora, where dnf will rollback the transaction. No, it will leave your system in the before-mentioned partially upgraded state. From the Arch Wiki:

Note that if pacman -Syu does not perform the upgrade because of an error, the end result is the same as running pacman -Sy. Therefore, the error must be resolved and the upgrade operation completed as soon as possible.

Yikes!

In fact, the more I read about pacman, the less I like it. Common operations lack human-readable names, like -Syu instead of dnf update or apt’s update && upgrade. Pacman is not designed to keep multiple versions of a library installed, which causes conflicts if program X needs library version 0.12 but program Y needs version 0.13. (It is possible to fix this manually with various solutions like LD_LIBRARY_PATH, symlinks, chroots etc, but nothing user-friendly.) Contrast this to Flatpak, which can not only keep multiple runtimes installed, like org.Gnome.Platform 41 and 42—but deduplicate them as well.

It is my opinion that these technical problems render the very idea of a user-friendly Arch distribution like Manjaro or Endeavour laughable. Updating is just too dangerous, especially since many users like to install a lot of programs. I am guilty of this as well.

The AUR

There are three problems with the AUR. Firstly, it is insecure because anyone can publish a package there. Secondly, a lot of AUR software is distributed in source form, which takes ages to compile — and might fail. The third Manjaro-specific problem is that since Manjaro holds packages back for two weeks, this can cause AUR programs to fail because the system is not up-to-date enough.

The sad reality is that a lot of software is missing from the Arch repositories and the AUR is the only convenient way to get this software. Who wants to fiddle around with alien or compile software manually?

So what’s the alternative?

Flatpak is the best package manager I have ever used. It will never brick your system (it doesn’t mess with system files); it handles dependency conflicts and deduplication beautifully; it just works! About the only bad things I can say are that sometimes, I have to use Flatseal to change permissions, and there are some small theming issues.

But not every program can be distributed as a self-contained Flatpak. So what Linux should I use for the base system?

Currently, I am using Kubuntu on the desktop because it distributes a recent kernel, allows easy installation of the Nvidia driver, and has reasonably up-to-date packages. But some packages are still out of date—KDE software, ironically enough. I also think the apt package manager could be improved. Maybe I should try aptitude.

But is there really an alternative to the Ubuntu/Mint/Pop world?

  • Fedora KDE: The live session froze before it even got to the installer. The problem is that they made Wayland the default on KDE, which does not work with the nouveau drivers. (Fedora refuses to ship the Nvidia binary drivers or patent-encumbered codecs.) This does not inspire confidence in the level of QA and testing that went into the distro.
  • OpenSUSE Leap: too out of date.
  • OpenSUSE Tumbleweed: I’ve read mixed reviews on this one. It pushes updates really, really frequently. No human QA goes into it, only automated QA – and even a really good automated system like openQA can’t replace humans. Arch at least has humans testing its packages. Even with its fancy btrfs snapshots, I am not adventurous enough to try it.

The only alternative to Ubuntu I would consider is a Fedora with sane defaults. But then, I guess there’s a reason Ubuntu and its deriatives have been more popular than Fedora and Arch for a very long time.

No comments:

Post a Comment

EVs are not the future—hybrids are

There has been a wild surge in optimism in EVs—really, a kind of hysteria—with the EU and UK governments hoping to ban combustion engines in...