A First Attempt with Arch Linux

Having heard great things about Arch Linux, I thought I would give it a try. I’ve enjoyed trying different Linux versions over the years, and have found some good environments.

Unfortunately, Arch Linux is not one of them – at least judging according to my initial installation.

The initial install gives you a text-based environment – no GUI here. This can be almost forgivable – but the installation had some hiccups. If you decide to install Arch Linux, don’t select anything other than the core resource: adding extras will only cause things to break. Stick with your CDROM installation media and forget the rest.

Then, after installation, there are a number of tasks to do. As long as you stick with the Beginner’s Guide, all should work just fine. The problems begin when you get into the extras. Most of these problems have solutions; however, one should not come across one problem after another.

Here are the problems I’ve experienced in just a few hours time after initial installation:

  • xdm spawning too many times; pausing for 5 minutes – this because xdm wasn’t installed but /etc/inittab was trying to start it.
  • package conflict with /etc/mtab
  • package conflict with /etc/profile.d/locale.sh
  • configuration of Window Maker overwrites ~/.xinitrc
  • configuring PAM to use ecryptfs didn’t work
  • encrypting home directory appears to have encrypted ~/Private and not ~
  • ecryptfs documentation is obsolete
  • running XDM loops back to login screen after successful login
  • running GDM fails
  • sudo wasn’t part of the main install
  • a new user wasn’t part of the main install
  • the documentation for adding a new user puts the user in the wheel group if you do it manually – but not if you do it with useradd
  • during installation, old install messages are not removed
  • perl is not part of the base install
  • X installs with a network listener active

The two biggest problems are the following:

  1. Bugs are just documented, not fixed.
  2. Nothing is configured!

When a package is installed, it should be ready to go – it should “just work.” Nothing “just works” on Arch. It is one thing to let us choose which packages we want and how we want; however, there should not be a day’s worth (or more!) of work to get things working. Every package seemed to have bugs and things that didn’t work right – and needed special instructions to configure it.

To do anything with Arch, it requires a huge effort to install a large number of packages – and to hand-configure most. It is a minimalist distribution that is built up to be what someone wants. However, I thought their choice of simplicity quotes was ironic:

Perfection is achieved not when there is nothing more to add, but rather when there is nothing more to take away.

I say ironic because there is nothing that can be taken away from Arch Linux; packages must be added.

This is a big disappointment; I had such high hopes for Arch Linux. I thought it would be an simpler version of Gentoo or Slackware; not so.

    User Interface Design: the Command Line

    The command line is not immune from user interface design. Especially with the concept of language, one has to choose carefully the options and names and orders of the things in order to make things work just the way the user expects them to.

    If the program is too different, people will be tripping over it all the time. The UNIX tar command comes to mind as one that failed here: options (or “actions”) specifically did not start with a dash. Likewise, UNIX find also failed: if you didn’t include the parameter -print at the end, you saw no output: your find command found nothing! (In reality, it just didn’t report it.) Both of these errors have been rectified in the last several decades: UNIX find has an implied -print, and tar often will make the dash optional – which makes it work both the way it always did and the way it should have.

    As an example of what seems to be a colossal user interface failure – including poor writing – consider these articles from Scott Remnant which are absolutely a gem (albeit from way back in February 2009). He wrote an article titled Git Sucks – which was then followed by a second and then a third – followed by yet another titled Revision Control Systems Suck.

    What Scott is railing about is how hard these systems are to learn (he targets not just git, but also GNU Arch and Bazaar). From his standpoint, he finds these systems to be complicated and hard to understand.

    He also points out (rightly) that the most common actions should be the simplest, and finds that with git these common actions are rarely ever simple. He specifically mentions reviewing the changes that someone else has made compared to his own – and says that there’s not a revision control system that makes it easy.

    An example of how user interface design can be incorporated into things like the command line and even programming is this quote from an interview with Yukihiro Matsumoto, the developer of the programming language Ruby about his guiding principle in developing Ruby:

    [It’s] called the “principle of least surprise.” I believe people want to express themselves when they program. They don’t want to fight with the language. Programming languages must feel natural to programmers.

    and later in the same interview:

    In addition, Ruby is designed to be human-oriented. It reduces the burden of programming. It tries to push jobs back to machines. You can accomplish more tasks with less work, in smaller yet readable code.

    Another example: I was just rereading my copy of The Humane Interface written by Jef Raskin. In it, he had a section titled Noun-Verb versus Verb-Noun Constructions (section 3-3, p. 59). This mirrors a problem I have experienced with some command line software in the past: the command wants an action as the first argument, and the object of the action second. I despised it enough that it was the genesis of my writing a wrapper for the command that reversed the order: object first, action second. Imagine my surprise to find my troubles validated right there in Raskin’s book.

    There are many examples of command line programs doing wrong things, and of programs doing right things. One of the right things comes from HP-UX and its software management tools such as swinstall: if the program can use an X display for a graphical display, it will: but if not, it goes to a text display instead.

    There are many such examples, of programs just doing what you need and leaving you to think about other things. I wonder what would happen if a company like Apple decided to tackle the command line – although, in a way, they did already. In MacOS X, consider the open command for instance… absolutely brilliant, which is in contrast to the open command sometimes found in other UNIXes (never standard).

    One very important point to remember: “It’s only hard until you learn it” is not a valid excuse. The learning curve for a program should not be any steeper than it has to be.