My Review of Arch

After my minimal install of Arch, I was greeted by a terminal console upon booting the kernel. With 5,013 packages in the 32 bit stable repositories (compare that to Debian Stable’s 56,865), I was not getting very far by relying on the built-in package manager pacman. The package count increased another 27,023 once I began using the Arch Users Repository (AUR) scripts.

After installing a few packages, I realized Arch’s greatest weaknesses: customizability and project collaboration. Arch is like a snowflake – no two systems are exactly alike. From a SysAdmin’s viewpoint, I can’t determine what state the operating system is just by looking at it. In certain circumstances where time is of the most urgent matter, one cannot spend time comparing program versions with unknown and known bugs. I envision managing two or more devices would be quite painful in the long run.

Project collaboration is still in the early stages. With two great AUR package managers (yaourt and cower) and the
realization that neither have been pushed to upstream, I have an eerie feeling that xkcd’s standards statement is at play in the Arch environment.

For those that do not know how collaboration works, here is a quick overview:
I use project A. Project A is lacking feature B. I fork project A, write feature B, and continue using project A with feature B. If people other than myself can benefit from feature B, I push my changes to upstream. If my changes are not accepted in mainstream, I have two choices: keep feature B to myself or write feature B to match upstream’s policy.

This is how not to collaborate:
Project A is missing feature B. I fork project A, call it project V, write feature B, C, and D with a wrapper for project A. If somebody wants feature E in project A, tell them to use project C which is a fork/clone of project V.

Contrary to public thinking, Arch is not a GNU/Linux distribution geared towards intermediate to advanced users. It is a primitive distribution that only intermediate-level and above understand. We understand the basics of how to compile a program and how to find the one line command to run that is nested in 5 sub-links on the wiki. We overlook the high level of expert documentation that isn’t spelled out clearly, gives a recommended setting to new users, or in some cases doesn’t actually tell you how to do what you are seeking to do.

I claim Arch is still primitive because when I was installing packages, I felt like a caveman digging up xf86-input-mouse after I installed gdm and GNOME 3. (A clever person might think that would be at least a requirement of one of the packages that installs rather than an optional one – Oh, wait – GUI is never used by anybody on a desktop.) It might be that I was spoiled by reading Gentoo’s Handbook back when I was a noob and trying out an advanced distribution, or it could be that I have used distributions that have worked out all of these kinks for too long, but making GNU/Linux users dig like cavemen to find appropriate packages is harmful towards our primary objective: dominating the desktop OS marketplace.

Even with these prominent issues, Arch will probably stay installed on my Acer C710 for awhile – at least until Fedora 23 becomes stable.