ArchLinux使用手记

Motivation

I have been an Archlinux user for a while now. This is an attempt at a review, for people who have experience with other distributions, and are searching for something new/different.

I won't go into detail about installation that much. Most reviews cover installation. That is well covered territory. This review will attempt to touch on things that *I* found important and exciting about Archlinux during the course of my early use.

If you do want some information about installation, check out the following links:

• Archlinux Installation Guide
• Quick Custom Installation
• Fast Arch Install from existing Linux System
• Quick Arch Install

Be aware that some of that information is a bit dated, but it is useful to provide an idea about what an installation entails.

Instead of talking about Installation, I will talk about the following features that I feel set Archlinux apart.

• BSD-like Init system
• Rolling Release System
• Pacman
• ABS
• AUR

BSD-like Init system

Archlinux uses an init system that is very similar to a BSD init system. Daemon start scripts are stored in /etc/rc.d/. You start and stop daemons manually via the following syntax: /etc/rc.d/daemon start or /etc/rc.d/daemon stop

That handles how to start/stop from the command line, but what about on boot?
This is where the bsd-like init comes in. Archlinux has a file, /etc/rc.conf, which holds system initialization configuration information. You specify in this file which daemons start at boot, the IP addresses of your network interfaces, any system routes, etc.

The Archlinux wiki has a good example the rc.conf file.

Arch has run levels, which you can set by editing inittab, but they are used in a limited fashion. Runlevel 0 is used for shutdown, and by default runlevel 5 is used to spawn a *dm. You can modify /etc/inittab to change runlevel, or change the re-spawn runlevel of the *dm. You can also just add your *dm to the DAEMONS array.

Other than that limited use, runlevels just don't come into play. Most Arch users always use runlevel 3, whether or not they use X.

I like this simple approach. It makes it much easier to track the initialization sequence through the init files. This is a good example of the KISS (Keep it Simple, Stupid) principle.

Rolling Release System

Archlinux uses a Rolling Release System (RRS). This is a bit different than most distributions. Most distributions release a version as a monolithic thing. Users have to update their systems running on the old version, to the new version. In between version releases, the distribution provides minor updates and security fixes.

Archlinux, with the RRS, works a bit differently. Arch uses version numbers for the installation CDs. This is a version of the installation CD itself, not a version of the Archlinux system.

You install from the CD, and then update your machine with the package manager (we will talk about Pacman in the next section). In this way, you never need to run any monolithic update to the next version. You never need to reinstall when a new CD is released. You just keep updating your system. There are people that have not reinstalled their Archlinux systems from their initial install from several CD versions ago. Their systems are just as up to date as someone who installs today with the current CD version.[page_break]

Pacman

Pacman is the Archlinux package manager. It handles binary packages, which have the name format of package-version-revision.pkg.tar.gz. Pacman handles the installation, removal, and updates/upgrades of packages (both locally and from the Archlinux package repositories). Pacman attempts to remain powerful, while keeping things as simple as possible (but hopefully no simpler).

Notice the ".tar.gz" extension on the package name. Arch packages are indeed simple tarball files. They include an extra informational file, but beyond that, it is simply the collection of files to be installed. This package-as-tarball system allows for extraction of the package to a testing directory, for inspection if needed. It also allows the usage of preexisting system tools to work with the package files.

Information on using Pacman is outside the scope of this document. For more information on its general usage, check out the following links:

• Pacman on the wiki
• Pacman in the installation manual

ABS (Arch Build System)

Pacman packages are built using the ABS (Arch Build System). ABS is a CVS tree that users can download via the abs utility. abs is a shell script that executes a cvsup to pull down the latest ABS tree.

Once the tree is downloaded, you can easily modify the build parameters for a package, and then build the package yourself. There are some other helper scripts that assist you in building a package. The main script is makepkg.

ABS contains a directory tree populated with package build files, also knows as PKGBUILDs. A PKGBUILD contains information about how to build the package. The makepkg script reads this file, and follows the instruction that the file outlines.

For more information about ABS, check out the following links:

• ABS on the wiki
• ABS in the installation guide

The ABS system makes it quite easy to modify packages to suite your specific needs. The Arch developers make great strides to make their packages as useful as possible to the largest portion of the community they can. Often, I find my particular needs to be a little different than what would be considered 'common'. In these instances, using ABS is a great way to tweak a package for how I happen to need it configured. This generates a binary which I then install with Pacman.

I get the benefit of using binary packages (which I can distributed to my other Arch boxen) as well as the customizability of building it myself from source. PKGBUILD files are basically BASH files (with special variables), and are not terribly difficult to understand.

This also makes it quite easy to create PKGBUILDs for software that the Arch developers haven't had a chance to package yet. This leads me to the next item.

AUR (Arch User Repository)

The AUR is basically a website that the community uses to store PKGBUILDs they create. This web utility allows them to upload PKGBUILD files (and any associated files) for other people to use. Since this is a community upload site, the packages are not available for direct download in binary format.