| Interview |
 |
Arch Linux is one of those quiet and little-known distributions, rarely figuring in the headlines of major Linux news publications. Fortunately, the recent release of Arch Linux 0.5 and a continuously evolving changelog present enough proof that its developers and package maintainers are hard at work. We have spoken to Judd Vinet, the creator and lead developer of Arch Linux and its "pacman" software management utility about the origins of Arch Linux, its special features, plans and other topics related to the development of this fine distribution.
|
 |
|
| Judd, thank you very much for sparing some of your time to answer a few questions. Let's start with the origin of Arch Linux. How did it come about? |
Arch Linux began in early 2001. I had been using the Polish Linux Distribution (PLD) for a good while and had recently switched to CRUX, where the developers were a little more fluent in English. :)
I immediately loved it. CRUX was simple, elegant, and very quick and easy to use once you understood how it worked. And understanding did not take long, because everything just made sense -- concepts and methods weren't complicated unless they had to be. Per Lidén did an excellent job with it and I happily ran it for a few months.
I disagreed with some of CRUX's ideologies, though. Per had decided to keep package management very simple. Packages were nothing but gzipped tarballs that were extracted directly into the running system. There was no meta-data, no dependency tracking, and no easy way to locate and download packages. The package set was also very minimalistic.
As a sysadmin, I was running PLD on many of my servers and was looking for something more reliable and easier to maintain. While PLD had a good package update system (apt-get in front of RPM, a la Conectiva), their packages were overly modular for my tastes and many of them were broken. CRUX was the next logical choice, but maintaining many systems without dependency support wasn't going to be fun.
At that point I decided to start Arch Linux. It was an opportunity to take all the great concepts I liked about other distributions and combine them together, along with some of my own tastes. So I built an LFS system and began assembling some rudimentary package build scripts, modelling them after the format I had seen and used in CRUX. Simplicity and elegance were my goals. Once the base system was assembled, I began work on pacman. In the beginning, he was just a glorified tar/gzip utility with file tracking, but quickly evolved into a very useful little application.
|
| Arch Linux is designed for more experienced Linux users. What are the main benefits and shortcomings of Arch compared to other distributions in the same target market, such as Slackware, Debian or Gentoo? In other words, why should somebody using one of the above three distributions consider trying out Arch? |
Well, for starters, Arch Linux is still very young compared to any of those distributions (especially Slack and Debian), so it's likely to have a larger amount of bugs floating around. The big boys also have a much larger package set than Arch Linux, though our repositories are growing steadily.
And I've been told that Arch's documentation is less-than-perfect, which makes sense. I wrote it, after all, and it's not my strongest point. But we now have a documentation maintainer with a greater gift for the written word, so it can only improve from here.
As for advantages, I'd have to say that our package system is the biggest draw. People love it. They also seem to like the simple filesystem layout, the lack of extraneous stuff (like /usr/doc), and the simple boot scripts, which provide modular rc.d daemon scripts but without the SysVinit-style fun. Our installer has also started to receive praise. Once you've been through it once or twice, a base install typically only takes 5 or 10 minutes.
And while I don't know much about the communities within other distributions, I'd have to say that we have a very supportive group of people on IRC and the forums. Most users receive answers very quickly, and we've received many kudos for our efforts here.
|
| The main feature of Arch Linux is of course pacman, the distribution's
package manager. Can you tell us about its features? |
Pacman doesn't really do anything that other package managers have not done before. It's goal is to do all the mundane parts of package management, leaving the tricky parts up to the ever-capable administrator.
The most powerful part of pacman is its --sync operation, which basically keeps a system synchronized with the continually-updated package sets on the master server. This means that, once you install Arch Linux on your computer, it's _always_ up to date. Just run pacman on a regular basis and you never have to download another ISO and never have to rebuild your system with a newer version. Pacman has basic dependency support, too, but we've kept it simple enough that it somehow side-steps the "dependency hell" that RPM users are all too aware of.
Pacman is really only half of the package management system. It tracks, downloads, installs, removes, and upgrades the tar-gzipped packages that we distribute. The other half is the Arch Build System (ABS), which is a build system heavily based on FreeBSD's ports system.
Arch is more-or-less targeted towards experienced linux users, so we anticipated that many users would want to build their own packages or customize existing ones with added features and/or extra optimizations. ABS facilitates that nicely. It makes it very easy to rebuild a package from source code, and it takes very little time to throw together a package build script for a new package, which is how we can depend on the community for a growing package base.
All an Archer needs to do is run 'abs' and the system will download the latest-and-greatest version of all our package build scripts. Then it's just a matter of heading into the package area and running the build program,
makepkg. Like the rest of Arch, makepkg is as simple as we could make it. It's just a bash script that reads the package-specific build script and follows the directions inside. makepkg will check dependencies, download
source files, unpack them, ./configure, build the package, and then install it into an isolated directory where it can be tarred and compressed.
|
| Is pacman still in development? If so, what new features would you like to
see implemented in a future release? |
Yes, very much so. Pacman 2.5.1 is the current release, and pacman 2.6 is currently in testing. 2.6 has support for:
- virtual dependencies, for example package like gawk and mawk can simply provide 'awk', allowing dependent packages to work with either implementation
- package grouping, for example one will be able to 'pacman -S kde' and have all KDE packages installed
- replaced packages, which is helpful for removed or renamed packages. For example, the phoenix package will soon be replaced with the mozilla-firebird package. The problem is that there is currently no logical link between the two packages, so pacman cannot automatically remove the old one and install the new (renamed) one. Until now.
These are not set in stone yet, but here are some future plans for pacman:
- HTTP download support (currently only FTP is supported)
- an external libpacman.so for frontends to use
- MD5-tracking of all files for sanity/security checks
- GPG-signing on packages
These are all well-known and appreciated features in many package managers. One of our unique ideas has been to implement "transactions" into pacman, where one could "rollback" a package upgrade if something fails. Imagine you are a sysadmin who's running a routine --sysupgrade on a server. A new apache package is installed, but the new daemon will not start at all. If this is a production box, then you've got problems. With transactions, one could issue a --rollback command and put the old apache package back in place, configuration and all. Very handy.
|
| Would you be able to compare pacman with apt-get? Is there anything that
pacman does better than apt-get? |
Apt-get is far more mature and feature-rich than pacman. But functionality-wise the two are comparable. Pacman's --sync operation was definitely inspired by apt-get, but pacman is more of a "complete" packaging system, whereas apt-get fills in the features that dpkg doesn't provide.
In my limited experience with apt-get, the only complaints I had were the awkward split between apt-get and dpkg, and the odd time when apt-get would fubar my system with its recommended upgrades/replaces. Otherwise it's a great tool. I used it for a good while with PLD.
|
| Would you be able to compare Arch Linux with Gentoo? Is there anything that Arch Linux does better than Gentoo? |
Hmmm, it's tough for me to say, because I've never used Gentoo before. The main difference would be that Gentoo is a fully source-based distribution, whereas Arch Linux is primarily package-based, but complemented with a strong build system (though not as strong as Gentoo's, I would guess).
A big advantage that many former Gentoo users comment on is Arch's setup time. They say that Arch is just as fast as Gentoo, but they have a functional system up in 10 minutes rather than 10 hours.
|
| After reading the pacman documentation, I was rather confused about compiling an application from source and then integrating it into pacman? It sounded like there was a simple command ("make package") but then it also sounded like I had to edit my own special Makefile. I really like the simplicity of checkinstall, especially on Slackware-based distributions. Why can't it be that simple to integrate a source install into pacman? |
Actually, makepkg performs a similar function to checkinstall, but differently. Where checkinstall would use installwatch to track modified/added files during a 'make install', Arch Linux build scripts use the ubiquitous DESTDIR or prefix/PREFIX variables found in most Makefiles to redirect installed files into a special path where makepkg can package them up. This way we don't have to hook into any system calls like installwatch does.
You're kind of on the right track though. The "special Makefile" is actually called a PKGBUILD, and it provides all the information needed to build a package, plus some other useful stuff like dependencies, URLs, conflicts, etc.
As for making it "that simple"... Well, it pretty much *is* that simple. Here's an example PKGBUILD file for the patch utility:
pkgname=patch
pkgver=2.5.4
pkgrel=2
pkgdesc="A utility to apply patch files to original sources"
url="http://www.gnu.org/software/patch/patch.html"
depends=('glibc' 'ed')
source=(ftp://ftp.ibiblio.org/pub/gnu/$pkgname/$pkgname-$pkgver.tar.gz)
build() {
cd $startdir/src/$pkgname-$pkgver
./configure --prefix=/usr
make || return 1
make prefix=$startdir/pkg/usr install
}
Pretty simple, huh? The top portion defines some information that goes into the resulting pacman package, and the build() tells makepkg exactly how to build the package. That's it.
|
| What is Arch's approach to "stability"? Your stable branch seem fairly up-to-date (at least this early after the official release of version 0.5), so it certainly did not go through the same testing paces as Debian stable would go. Any comments on this? |
This is a very relevant point right now. One of the current debates in the developer community has been how we want to rename the branches in the official package repository. STABLE is somewhat of a misnomer -- it should really be called RELEASE, since that's exactly what it is. Arch Linux uses a sort of rolling-release system. CURRENT always follows the latest versions of packages, and STABLE (soon to be RELEASE) only updates at discrete intervals, when we make the official release. For example, STABLE points to the packages that were CURRENT when 0.5 was released on July 21. When 0.6 is released, STABLE will be updated to point to the new package versions.
Stability is a tough assertion to make, especially in a pre-1.0 distribution. For that reason, we don't make any claims about stability. That's not to say that the distribution can't hold its own in this area. One of my workstations has been running Arch since 0.1 and is doing just fine.
|
| How unstable is the "unstable" branch? If a major bug is discovered, how quickly is it fixed? Or how quickly is a workaround posted? |
Well, first let's get our semantics right. "Unstable" isn't actually a branch, it's a package repository unto itself. Official, Unofficial, and Unstable are package repositories, STABLE and CURRENT are branches within each repository.
Unstable is the repository where we put software that the author has deemed unstable and/or pre-release. You'll find cvs/snapshot versions of packages here, as well as pre-release stuff like Xfce4. When a package graduates to release/stable software (or a maintainer deems it worth), we move it into another repository.
As for our turnaround time, I'd have to say that we excel here. The Arch Linux package maintainers Arch has are pure gold and they all work their butts off to ensure that a fixed package goes out as soon as possible, usually the same day.
|
| Is Arch Linux suitable for servers? |
Well, I *am* a little biased here, but I would have to say that, yes, Arch is very suitable for servers. My day-job is mostly system administration and I've got 9 servers running Arch at work. They're all quite stable and perform great. Fast and painless to maintain, thanks to pacman and Arch's simplicity.
|
| Earlier Arch versions had a kind of "don't bother with this unless you're a Linux adept" message. Would you consider the latest version more acceptable to new Linux users? Any plans to make it more beginner-friendly? |
True true. And though it's not quite as black-and-white, Arch still has that disclaimer kicking around the community. This began as more of a warning I passed on to potential users, simply because I couldn't afford the time to provide support to the newer linux users, and I knew that a lot of them would be lost without some helpful utilities.
My life stays very busy. I work, I attend school, and I try to maintain some semblance of a social life. This severely limits my Arch Linux time, and when I was the sole developer I couldn't afford to give up development time for support.
The situation is changing, though. While Arch still does not (and will not) provide any utilities such as linuxconf, many newbies have stuck with Arch Linux and relied on the helpful community to get them through the initial learning phase. I view this as sort of a side-effect of Arch's simplicity. For example, it's quite easy to trace the execution of the boot scripts during boot-up. It's easy to understand the package system once you sit down and look at it. This encourages newer users to take some time to grasp the basic Linux concepts that many helper utilities "save" you from. An Archer can walk away from the distro and be relatively fluent in *any* distribution, because they all work the same way, once you get through the cruft.
|
| How many developers work on Arch Linux? Besides developing pacman, what other work do you do on Arch? |
There are about eleven developers, not including myself. They all do great things for Arch, and we're looking to expand the team shortly. Arch Linux is growing. I function as a sort of "catch all" guy. If nobody else is responsible for a job, then I do it.
My duties in Arch often ride in cycles. I'll work hard on a pacman release for awhile, then do a few tricky package upgrades, then work on some maintenance scripts for the package repositories. I used to maintain all of the official packages, but most of them have now been passed off to a few of the developers. I maintain the 'base' package group, and do spot checks/upgrades around all three package repositories.
I've also been responsible for any PR, which is why you see so little of it. I'm a terrible PR person. :)
|
| Forget for a moment that Arch Linux exists. Which, in your opinion, is the best Linux distribution and why? |
Good question, and one that I repeatedly ask myself. It helps me to find useful features that I can add to Arch Linux.
My favorite non-Arch distro would have to be Slackware. It's a living remnant from the earlier days of Linux, and through it all Slackware has been very non-commercial (kind of a "by the users, for the users" thing), which I respect.
And Slack is just proven. It's a solid distribution that has ten years of development behind it, tested and used by thousands and thousands of people. I still have a Slackware router box sitting in the den. The damn thing has been running for 4 and a half years.
And Slackware is a cool name. ;)
|
| What do you do for living? |
I'm in my final year of Computer Science at the University of Victoria, BC, Canada. I also work as a system administrator and programmer at a little Internet company called Wondermill Webworks. It's a fun group of people, and when we're not working, we usually pass our days with dart wars or impromptu field trips to a pub. If I'm not terribly busy with regular work, Wondermill allows me to work on Arch during my normal day-job hours. They also graciously provide our development CVS server and pay half the hosting costs of the master server.
|
| I believe that, besides being a Linux developer, you are a keen guitarist. Would you play us a tune? What else do you when you want to relax? |
Keen, perhaps, but not good enough to serenade any of you. :)
Relaxing moments are few and far between when I work and go to school, but the guitar is my main outlet. It's an activity that gets me away from the computer now and then, and my friends say it keeps me well-rounded. Besides, I like building things and if it ain't code, then it might as well be a song.
|
| Judd, thank you for the interview and good luck with your project! |
| Copyright Notice |
Copyright (C) 2003 Ladislav Bodnar
Verbatim copying and distribution of this article is permitted in any medium, provided this copyright notice is preserved.
|
|
| Interview Notes |
| Date |
| 3 August 2003 |
| Interviewed By |
Ladislav Bodnar
Some of the questions were contributed by DistroWatch readers |
| Arch Specifications |
| Latest Version |
| 0.5 |
| Release Date |
| 21 July 2003 |
| Kernel |
| 2.4.21 |
| GUI |
| XFree86 4.3.0 |
| File Systems |
ext2
ext3
ReiserFS
|
| Requirements |
i686 processor
32MB RAM (text mode)
128MB RAM (graphics mode)
Bootable CD-ROM
Standard SVGA graphics card
PS2 or USB mouse |
| Platforms |
Intel: Pentium 2 to Pentium 4
AMD: Duron, Athlon, Athlon XP
|
| Features |
Pacman package manager
Highly up-to-date software repositories
FTP installation
|
| Bundled Software |
Apache 1.3.28
GCC 3.3
Gimp 1.2.5
glibc 2.3.2
GTK+ 2.2.2
KDE 3.1.2
KOffice 1.2
libgnome 2.2.2
Mozilla 1.4
MySQL 4.0.13
Nautilus 2.2.4
Perl 5.8.0
PHP 4.3.2
Python 2.2.3
Samba 2.2.8
Xmms 1.2.7 |
| Price |
| Free |
| Support |
User Forums
Mailing Lists
irc.freenode.net #archlinux
FAQ
|
| Terminology |
| Arch Linux |
| Arch Linux is an i686-optimized linux distribution that was originally based on ideas from CRUX, a great distribution developed by Per Lidén. Arch is fast, lightweight, flexible and simple. Those aren't very fancy buzzwords but they're all true. Arch is optimized for the i686 processor, so you get more for your CPU cycle. It's lightweight compared to Red Hat et al, and its simple design makes it easy to extend and mold into whatever kind of system you're building. |
| pacman |
pacman is the package manager which tracks all the software installed on your system. It has simple dependency support and uses the standard tar-gz archive format for all packages. Some common tasks are explained below with the respective commands in long and short option form. For an up to date explanation of pacman's options, read man pacman.
pacman doucmentation
pacman manpage
|
| mkpgkg |
makepkg is a package build utility for Arch Linux.
makepkg doucmentation
makepkg manpage
|
| TUXEDO |
TUXEDO Computers - Linux Hardware in a tailor made suite
Choose from a wide range of laptops and PCs in various sizes and shapes at TUXEDOComputers.com. Every machine comes pre-installed and ready-to-run with Linux. Full 24 months of warranty and lifetime support included!
Learn more about our full service package and all benefits from buying at TUXEDO.
|
| Star Labs |
Star Labs - Laptops built for Linux.
View our range including the highly anticipated StarFighter. Available with coreboot open-source firmware and a choice of Ubuntu, elementary, Manjaro and more. Visit Star Labs for information, to buy and get support.
|
|
• 
• 
• 
• 
• 
• 
• 
bc1qxes3k2wq3uqzr074tkwwjmwfe63z70gwzfu4lx 
lnurl1dp68gurn8ghj7ampd3kx2ar0veekzar0wd5xjtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhhxarpw3jkc7tzw4ex6cfexyfua2nr 
86fA3qPTeQtNb2k1vLwEQaAp3XxkvvvXt69gSG5LGunXXikK9koPWZaRQgfFPBPWhMgXjPjccy9LA9xRFchPWQAnPvxh5Le 