Recently, due to some hardware compatibility issues, I had to switch from my usual choice of OS (Linux Mint) for a new toy¹ that I got. Being influenced by all those Arch evangelist while also knowing that I’m still a newbie with Linux, I decided to play with Manjaro. So far it’s not going on well, and here are my experience, thoughts, and complaints.

Desktop Environment Matters

For the desktop environment, Manjaro comes in three official flavors: XFCE, KDE Plasma, and GNOME. Knowing that my machine only had a low-end CPU, my original plan was to use XFCE. But I ended up with GNOME because I had some some UI or display issues that I don’t even know how to fix ². Aesthetically speaking GNOME was quite good: it has a very modern look (pleasant color schemes, round corners, fancy animations, etc.), and without any inconsistent or seemingly unpolished UI elements (at least I didn’t find any during my casual use).

However, the tradeoff is that GNOME seems to be (even more) sluggish (than Plasma). It takes about a second to launch almost anything, which leaves me plenty of time to appreciate the design of the cursor animation during loading. After all, it’s just a low-end machine, and will not be my daily driver. I can live with it.

Package Managers

While you can switch DEs all the time and make different distros appear similar, usually you can’t do that with the package manager. Getting used to a new one is an essential part of getting used to a new distro.

The Bad: They Have Different Syntaxes

To install apps from the official repositories, Manjaro comes with Arch’s package manager: pacman. This very catchy name is the only part of the package manager that’s intuitive. For example, to update and upgrade everything after a fresh install, one needs to do:

sudo pacman -Syu

As someone from Debian(-based) background, this is a cultural shock. While I don’t even remember what ‘APT’ stand for, it’s really not difficult to understand what update, upgrade, install or autoremove do. But maybe it’s not that exotic, because it also reminds me of the nightmare with tar.

To be fair, once you are used to it, pacman saves a lot of typing. For example, -S means install:

sudo pacman -S <package name>

Also since Manjaro comes with zsh as its default shell (at least for the regular user), which comes with history-based auto-suggestions, it doesn’t really matter if you can’t memorize the magical letters exactly.

Whatever argument you can bring to support pacman’s funky syntax, you can’t use it for pamac, the other package manager comes with Manjaro, which you will need for accessing 3rd party package repositories, such as AUR (Arch User Repository), Snap, and Flatpak. Just need to enable them through the GUI, or if you insist on doing it with CLI:

# enable AUR for pamac
sudo sed -Ei '/EnableAUR/s/^#//' /etc/pamac.conf

Then, theoretically, installing an app is as simple as:

pamac install <package name>

Yes, unlike pacman, pamac has a verbose but intuitive syntax. This is very helpful for my Dissociative Identity Disorder condition. And of course you can make it even more confusing by bringing in more ways to install apps, such as yay (which works like yay -S <package name>).

The Good: AUR Has Almost Everything

Despite my complaints on the syntaxes of the package managers, one thing special about Arch that I really appreciate is AUR. So far, AUR has everything I need that’s not included in the official repo. This is amazing. No more manually adding APT repos, or downloading binaries then move to /usr/local/bin/, or cloning git repos and scrolling on GitHub for the build commands. Someone has done the work and you can just copy their work from AUR by a simple pamac or yay command, as long as you still remember which one uses install and which one uses -S.

Installing An App Does Not Automatically Enable It

While some steps for installation were saved, others were not. It seems that, for Arch, installing an app does not automatically enable it (or launch it, or properly configure it, or maybe it doesn’t really work).

I was just following online guides to enable SSH and install Docker, and suddenly I realized that, unlike Ubuntu and Linux Mint, I always need to manually do the systemctl enable then systemctl start steps after installation³. I guess this is an intentional feature: force the users to explicitly enable the services they want, so that they know what they are doing. Except when the user just want to get some simple functions working, this feels like extra steps.

An App May Need Extensive Troubleshooting Before It Can Work

Depending on the specific app, there may be even more post-installation steps if you want things working. A prominent example is xrdp, which I rely on to access GUI apps from Windows and Android. With my past experience using it on Linux Mint, I thought it would also be a simple install-and-run thing.

It is not. Otherwise I won’t be writing this.

The Arch Wiki has a very long section on troubleshooting, but these guides written by other people for Manjaro with different DEs probably are more helpful: GNOME, XFCE, and KDE Plasma. Here is a summary：

1. To get the real Remote Desktop™ experience, you need not just xrdp but also xorgxrdp

   • The former is included as a dependency for the later but not vise versa, thus if you want to install with one command, pamac install xorgxrdp.
   • Alternatively, if you want graphical acceleration, there are two other versions of xorgxrdp: xorgxrdp-glamor for Intel and AMD GPUs, and xorgxrdp-nvidia for Nvidia GPUs.
   • If you choose xorgxrdp-glamor like I did, you may get a ‘unknown public key’ error. In that case, according to this comment, manually add a public key with gpg --keyserver keyserver.ubuntu.com --receive-keys 03993B4065E7193B⁴.

2. As mentioned above, you need to enable the services before you can use them.

   sudo systemctl enable xrdp.service
   sudo systemctl enable xrdp-sesman.service
   
   sudo systemctl start xrdp.service
   sudo systemctl start xrdp-sesman.service
   

3. Now that xrdp should already be running, and you can try connect, only to see it fail with a black screen or a flash. This is because the installation did not include some proper config files, but also came with a wrong script.

   • Very likely a /etc/X11/Xwrapper.config file does not exist. It needs to be created, and include this line:

     allowed_users=anybody
     

   • There is a length function (get_session) in the file ~/.xinitrc, which seems to be trying to dynamically get arguments for dbus-launch depending on the desktop environment. It seems to be mistakenly adding an extra --exit-with-session argument. Remove it, or simply replace the whole thing with something deterministic like exec dbus-launch --sh-syntax gnome-session because you know what DE you are using.

   • At this stage, XFCE and Plasma users should already be able to reach the desktop session through Remote Desktop (but cannot do anything that requires authentication through a GUI, such as updating packages or mounting drives ⁵), while GNOME users will simply see a very informative prompt⁶. There is a git repo for the fix of this problem, from with I got this easy workaround:

     removing pam_systemd_home.so from /etc/pam.d/system-auth

I consider myself as very lucky because after all these steps, it worked. Then I went on to install qbitorrent, which almost worked, except for an issue with its Web UI. Then I went on to install samba, which does not come with its configuration file, and the official template had some bad default options for Arch. The list of examples can go on. But in short, using Manjaro brings me back to maybe six years ago, when I first installed Linux (Ubuntu 16.04) on my old laptop: I had to Google how to do something for pretty much everything. Maybe this also is an intentional feature, to remind spoiled people (like me) that things never ‘just-works’.

Rolling Release?

I have not spend enough time on the machine to experience the typical rolling release nightmare: after a seemingly harmless update, the whole system falls apart, and I can only boot into a big black terminal screen. I can only hope such things are rare now.

Using a rolling release also means that packages are usually much newer. So new that random features may be introduced before the developers realize that many people see them as bugs⁷. When this happens, either there is a hacky temporary fix (which, I suspect, may end up being the only solution for years, and even make its way into the Arch Wiki and every blog guide, see above for examples); or you wait for the next release (which hopefully wouldn’t be a long wait).

Conclusion

After speaking of so much of my frustration while trying out Manjaro, I also need to confess that I don’t even know if all of the problems above are from Manjaro, Arch, Linux in general, my specific machine, or just me. Obviously as a Linux Mint (well, and Windows) user, I am very used to the works-out-of-box (or at least set-and-forget) experience. Currently I’m actually enjoying using Manjaro, because tinkering with a new system is fun, especially when I don’t have a specific task or a deadline.

One Month Later

After my initial set-up, I kept having random shutdowns (usually within 24 hours). It was very annoying and I couldn’t locate the cause. Then I went out for a two-week trip. Once I got back, I switched to the newly released Linux Mint 21. Now that I have used pacman, I see why people complain about apt. But despite all the additional typing and setting up PPAs (now the process comes with a new deprecation warning which took me by surprise), everything worked after installation, and that’s all that matters.

Last modified on 2022-08-19