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:
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 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.
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:
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:
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 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.
The PKGBUILD files are available for download, and users are encouraged to look over the files to make sure they are a) created properly, b) contain nothing malicious. Once the user has looked over the files, they can build the package using the PKGBUILD, and then install that package with Pacman.
There is a subset of users in the AUR system, that are called Trusted Users (TUs). The TUs have proven that they are capable of creating packages reliably, and correctly. The TUs have a voting board, and accept applications for new members. The TUs use the AUR system to manage their packages. The difference is that the TUs have a binary repository, that users can add to their pacman.conf file (the file that houses repository addresses), and other users can use Pacman to install the managed packages, just as they can packages from the main Arch repositories.
The TUs also have the ability to mark regular AUR user PKGBUILDs as 'safe'. This means that they have been checked, and the TUs believe they are made correctly and properly. This is a useful way for new users to gauge the reliability of PKGBUILDs that are available.
The AUR currently houses over 3 thousand PKGBUILDs. Over 1 thousand packages are in the community repository available as prebuilt binaries. An additional 1 thousand packages have been checked and flagged as 'safe' by the TUs. As of last count, there were 24 Trusted Users in the AUR system, and over 3 thousand regular users.
Concluding Thoughts
These are some of the things that I believe set Archlinux apart from other distributions. The power and simplicity of the underlying system init layout provides a great base for Archlinux to run on top of. The utility and ease of use of the Pacman package manager, in conjunction with the Rolling Release System, and the community supported AUR project, all help to keep Archlinux very up to date.
Archlinux strives to be a Linux distribution that is focused on a philosophy of solutions that are as simple as possible, but no simpler, while remaining as up to date as possible.