Arch linux is good, quite good

2008-07-17T18:15:00.000-07:00

Most of the times, the linux reviews I read begins with the installation. This is not the case: tipically the time it takes to INSTALL some linux distribution is nothing compared to the time you actually USE your distribution, unless you are a gentoo user, of course.

What is more is that in the Arch reviews I read they tend to post so many pictures of the installation program, it seems they have some sort of ncurses fetish. While I actually enjoy the norton commander blue, I think there is no reason to talk so thoroughly about the installation.

tl;dr If you get stuck there is the guide. If you still can't make it, think about all the people who installed Arch before you and begin to ponder whether it's YOU to be wrong; you'd be surprised.

What I would like to talk about is rc.conf.

The BSD style init (whatever the hell it means)

While it has BSD in the name, it is not necessarily evil. The file rc.conf is a centralized place where most of the basic system configuration is placed.

I'm talking about this:

LOCALE="en_EN.utf8"
HARDWARECLOCK="localtime"
USEDIRECTISA="no"
TIMEZONE="Europe/London"
KEYMAP="en"
CONSOLEFONT="ter-v16n"
CONSOLEMAP=""
USECOLOR="yes"
MOD_AUTOLOAD="yes"
MODULES=(!8139cp 8139too !pcspkr fuse loop)
USELVM="no"
HOSTNAME="echelon"
eth0="dhcp"
INTERFACES=(eth0)
gateway="default gw 192.168.0.1"
ROUTES=(!gateway)
DAEMONS=(syslog-ng hal network !netfs @crond @alsa !gpm !fam @sensors !kdm)

Of course the real one is filled with comments which explain all the fields and all the options. As you can see, the daemons to run at boot along with their order is specified here. As you might be thinking, there is no way of having different lists of daemons to run per runlevel. Not that we normal people care, but if you really need this, the feature is just a link away. The kind of solution proposed in the link is is accordance to the ideas behind Arch: you are always encouraged to solve your problems and share your solutions, while the distribution itself tries to stay as clean and vanilla as possible.

And the solution to the problem goes from the dumb sed command in the above-mentioned link to really great stuff like the KDEmod project or FaunOS.

KDEmod or "The greatest reason is to do the right thing for the wrong reason"

KDEmod is the reason I tried Arch in the first place. At the time I tried and replaced many linux distributions dating back to Mandrake 8.0, but never satisfied I kept the 8 year old Windows 2000 as my OS of choice. Then I heard about this modified, patched version of KDE which was "the most bestest kde ever, with ubergraphics, ultrafast" which you could have at the cost of installing this never heard before distribution.

In fact, KDEmod is "just" a splitted KDE with a fresh and dandy theme and a couple of patches for eyecandy (the 3.5.9 branch): splitted means that you can choose what programs to install, one by one, without the need to follow the dumb way KDE ships.

At the moment the KDEmod project mantains both KDE 3.5 and KDE 4.1: yes, you can install KDE4 with a single command and leave your worries and problems to the KDEmod developers.

If you are a noob coming from Ubuntu you will get your shitty Gnome, if you are a nerdy programmer you will want your tiling window manager, but if you are a great guy with an attitude like me you should really install KDEmod. Plus Funkyou is a nice man, even if he is a conspiracy theorist.

How would you install something though? Well, with

Pacman sed -e "s/^\[options\]/&\nILoveCandy/" pacman.conf

Pacman is the packet manager. Personally I don't get why people say it's great, I mean it just installs binary packets and solve dependencies... oh wait, ~maybe that's why it's so great.

Pacman does the job and does it good. He doesn't bring you coffee, he doesn't wear fancy clothes, he is not a PR expert. He is a fucking computer program. Once this is clear we are all set. Go!

You search with pacman -Ss, you install with pacman -S, you remove with pacman -R, you list what you have installed with -Q. You upgrade your installation with pacman -Syu. That's it.

Complimentary part on the rolling release system: I don't think so.

What I want to spend some quality time dealing with is the format of the database pacman relies to.

The packets database it is not

There is none. There is a hierarchy of directories and files in /var/lib/pacman/local. for each packet installed there is a directory called "packetname-packetversion" with a bunch of files inside: desc with the human valueable data, depends with the dependency valueable data, files with the removal valueable data, plus eventually install, changelog and license. All the files are human readable, which make accessing the database with homemade scripts pretty straightforward.

The biggest drawback to this approach is that the time it takes to access the database depends on your filesystem speed with small files and fragmentation. There are a couple of solutions to this problem: reiserfs for /var, tupac - A pacman cached implementation (written in php... ), pacman-cage which mounts the database with a loopback device. As you can see the Arch community found different solutions to this problem. To me and to the vast majority of users who don't like destroying their database, personal home page, or getting their wife killed, pacman is fast enough. It really is.

There are, of course, a number of graphical frontends to pacman which spawned over time: I feel like an hacker using the shell to install the programs, so I don't really care about them; I will mention two of them though: Pactrac which is the FaunOS default and Shaman which will become the default installer in some new kdemod4 based distro called Chakra.

ABS or Arch Best-kept Secret

A package installable with pacman is just a tar.gz with the directory tree where the files have to be installed and a file named .PKGINFO with various information on the packet inside. The format is so easy you could create a package by hand with just a little effort. Well, the purpose of makepkg and the PKGBUILDs files is to make the process even easier and more streamlined.

This is the PKGBUILD file for patch:

# $Id: PKGBUILD 1438 2008-05-08 17:11:21Z andyrtr $
# Maintainer: judd
pkgname=patch
pkgver=2.5.9
pkgrel=1
pkgdesc="A utility to apply patch files to original sources"
arch=('i686' 'x86_64')
url="http://www.gnu.org/software/patch/patch.html"
license=('GPL')
groups=('base-devel')
depends=('glibc' 'ed')
source=(ftp://alpha.gnu.org/gnu/diffutils/$pkgname-$pkgver.tar.gz)
#ftp://ftp.gnu.org/gnu/$pkgname/$pkgname-$pkgver.tar.gz)
md5sums=('dacfb618082f8d3a2194601193cf8716')

build() {
cd $startdir/src/$pkgname-$pkgver
./configure --prefix=/usr --mandir=/usr/share/man
make || return 1
make prefix=$startdir/pkg/usr mandir=$startdir/pkg/usr/share/man install || return 1
}

makepkg will read these instructions and build the package, which then can be installed through pacman.

The Arch Build System is only the collection of the PKGBUILDs the developers write in order to build the packages which pacman then downloads from the repositories and installs. With a simple command, abs, you rsync all the PKGBUILDs which you can use in order to build your own versions of the packages, or with pac-builder to rebuild all the packages you have installed (happy gentoo users? happy?)

ABS is really one of the best features of Arch:

a new version of the program came out and the developer is on holiday? I just modify pkgver inside the PKGBUILD and build my own package;
I need to enable a particular feature with compile flags? I just need to modify the building procedure in the PKGBUILD
I need a program which Archlinux doesn't support? I ~~write my own PKGBUILD~~ go to AUR

AUR you write it AUR, you read it our

AUR is the repository of user made PKGBUILDs. If you made a PKGBUILD and you want to share the results of your effort, AUR is the way to go: inside this sandbox, you can feel the same frustration of a distribution developer without being eligible to an @archlinux.org mail and especially without the e-penis satisfaction of being an actual developer. Even though AUR packages made by particolar users known as Trusted users, or TA, makes into the community section of the pacman official package repository.

Well, that's it for the review. Probably I will add some pictures and some text tomorrow, that is today ;_;

archlinux propaganda

Arch linux is good, quite good