The Big Arch Linux Interview

Today we are very happy to feature a huge interview with most of the developer team of Arch Linux, including its founder, Judd Vinet. If you are curious about this young and promising Linux distribution, dig in for more!

1. What is the main reason that keeps you working on Arch with the same passion for years now?

Judd Vinet: The thrill of creating something that other people use and like. I
think that’s the main motivation for me now. Arch has already reached a
point of “best-suited distribution for me” so it’s already fulfilled the
goals set out when I started it. Now I find myself looking forward to
adding features that other users will find helpful, and looking forward
to working with other Archers. I’m truly proud of the calibre of our
community and the way we’ve carved ourselves a little niche in the
over-crowded distro contention.

Jan de Groot: Arch suits my needs, though it has its limitations sometimes. I switched
to LFS and later gentoo for a while, but didn’t like them. After I
switched back, I became an archlinux maintainer. Before becoming an
official maintainer, I’ve done most of the work for new gnome releases
to get into archlinux using unofficial beta repositories.
I am still attracted to archlinux because it’s very up to date with new
software releases.

Tobias Kieslich: In 2003, when I was tired of over customized distros, I found
Archlinux. It had the latest software and did not look so exaggerated
complex. As a bonus I got a fast and easy package manager and a distro
which makes it easy to look behind the surface and learn the basics of
Linux in general.

I like to keep it this way. Make it easy for the user to understand how
things work and, by the same time, provide well working packages
that don’t need much hassle to get in touch with the software. When I
come across a new software it’ll take me time to get it known by
studying the docs and testing some configurations. I like to give on
that experiences to the users by transparent packages.

Damir Perisa: I run ArchLinux since 0.4 and since then i never had to reinstall the OS
on this laptop. Besides no need to reinstall it, i have always the latest
versions of software i need.

The reason that keeps me working on Arch is easy to explain: There are
some packages that i use almost daily. Maintaining them needs almost no
additional effort and other people who want to use this packages have the
advantage that they do not need to care to build / update them
themselves. So the only effort i really have is the uploading of the
packages. My connection is not the fastest and therefore while uploading
my internet is unusable for other things. This is a small price to pay to
offer thousands of people hundereds of pkgs ready to be used for
productivity and creativity. Opensource software depend on people who are
willing to offer some of their time to all the others. In the end, it’s a
big virtual team of thousands of people helping each other to have
working software they can use as tools for their work.

Dale Blount: I love Arch’s simplicity and ability to scale if I need it to.

Jason Chu: I’ve always liked the potential that Archlinux has. Not only is it a good
base to start from, but it’s still small enough to change quickly.

Tobias Powalowski: I started with 0.6 one year ago and was impressed by the simplicity. An other
point i really liked was that the community was really friendly and it was
really easy to contribute things to Arch. I can use latest features and software and most of the packages i use myself,
so it’s not a big deal to upload them to the net. I was searching for a community where i can share my experience with Linux and
i found it in Arch. Quote from Damir ( it’s a great explanation):

Opensource software depend on people who are willing to offer some of their time to all the others. In the end, it’s a big virtual team of thousands of people helping each other to have working software they can use as tools for their work.

I fully agree to that.

Aurelien Foret: First of all, thanks to OSNews. Indeed, I came to Arch Linux because of an article posted more than two years ago here. I immediately got interested by the author’s description and the new package manager he mentionned.

All in all, before discovering Arch, I was a passive F/OSS user. I never
cared for contributing to the Open Source community, or even subscribing
to forums or mailing lists.

Arch changed turned me upside-down. After the first install, I
immediately loved it, and it gave me the will to do something. I started
to answer posts on the forums, and to report bugs. Several days after I
was contributing new packages, and I started to write patches for pacman
(Arch Linux package manager). Only a few months later, I got hired in
the development team.

To say it all, working on Arch is my way to give back to the community
what it brings to me everyday: fun and one of the best OS ever.

Arjan Timmerman: I came to archlinux two years ago, after looking for a new distro on
distrowatch.

The KISS part it mentions was exactly what i was looking for.
I had ran slackware/debian/gentoo pre1.0 and openbsd before.

None of them suited my needs. I still think archlinux is my distro of choice. i never looked back after this. I was asked by Sarah31 too become gnome maintainer after the gnome maintainer left. The reason that they asked me, was that i builded the gnome1.4 libs so i could run gaim.

2. What are the biggest challenges you are facing daily while maintaining the distribution?

Judd Vinet: Time is a huge one. Arch doesn’t pay any bills for myself or other
developers, so we typically can’t work on it during the “make some real
money” hours of the day. Lately I’ve been doing contract work, so I
shift my schedule to try to be available during the days, but it’s still
tough to keep up.

The growth of the community and userbase means more bugs, more feature
requests, more lines of communication, and more PR work. Somewhat
surprisingly, the development team has met this growth head on and we’ve
handled it quite well. We’ve always been wary of growing too fast and I
think that’s been a good thing.

Jan de Groot: Time and motivation. We’re not getting payed for our work and lately
I’ve been very busy with other things.

Tobias Kieslich: Speaking of general things, time is a limiting factor. Beside some real
life and pay the bills kind of work that needs to be done, I wish I
could spent more time on ArchLinux. And sometimes it’s hard to make a
decision to do some package improvement or to take the guitar and play
some tunes.

On a more technical sides, API changes are always a challenge. Was it
the freetype2 header change some times ago, that required to touch many
packages to include the headers correctly, or most recently the db
package with the transaction support. One always run into the risk to
break packages. Meanwhile we have the testing repository, to catch much
of this trouble before it goes online. But the work needs to be done
nevertheless.

Damir Perisa: One of the challenges to me is to provide many good scientific software to
the community. One of the points to solve was, that we lacked the GNU
fortran compiler and some packages like octave and R do not really like
to be compiled with f2c. Since we have gcc-g77 now in the
repositories, this challenge is now easier to face.

A not yet solved challenge is to find a standardised way to handle
additional java software. Also i plan to write on the documentation, but
besides university and other activities i hardly can find some time to
spend on it.

Dale Blount: Time. Since we’re all volunteers our “real jobs” come first and
sometimes we’re found lacking the needed time to update packages and to
improve Arch.

Jason Chu: Keeping interest. Previously I maintained way too many packages that I
didn’t use. Each person has a set of packages that are their need-to-have
set. If you maintain too many need-to-have packages, you find you’re
always rushing to get things done. Very tiring.

Tobias Powalowski: Time is the most important factor. We are not full Arch workers and all have
their own jobs, studies and so on. We give our best to make Arch as up to
date and stable as possible.

The most problems are when a package will not compile anymore and you will
have to search for patches or write the patch on your own.
Or you have to look for ways that people can have a clean update of their
systems, without getting too much trouble while updating.

Aurelien Foret: Time! I’m not working on Arch for a living, and as consequence I have to
find a balance between the time I devote to Arch and my social life.

Arjan Timmerman: The biggest challenge is finding the time to do school/archlinux and
World of Warcraft.

3. Has the ongoing increasing popularity added stress to your work? How do you perceive this popularity increase?

Judd Vinet: Actually, I’m continually surprised that so many people find Arch to
their liking. I thought that the absence of GUI helper utilities would
have scared most people off, but it seems that there are many more linux
users like myself, more than I thought.

But I can’t say I feel any added stress due to the increased popularity.
It’s just an indication that we’re doing something right.

Jan de Groot: It doesn’t really matter if 1000 people use a distro or 100.000 users
use a distro, when there is a bug, you will get bugs from both groups.
With the 2nd group, there are even more people out there that do the
actual bughunting for you, so when you’re limited on time, it’s easy to
c&p stuff from the bugreport and make a fixed package right away.
I don’t put extra effort in archlinux because suddenly more people use
it. I work on arch whenever I like and do whatever I want to do.

Tobias Kieslich: There are more requests about features, some of them simply conflict
with each other. The more people use the distro, the more diverse needs
come together. Since we have some good guidelines to patch software
for security and reasons of packaging(Makefile fixes etc.) only it is
quite clear which way to go. It doesn’t really put more stress to work
but you have to consider your decisions better.

In general, the bigger popularity is nice since I have more input and
more feedback. The only thing that will never change is: If you make
a real good hack to get things working flawlessly, you’ll never get
feedback on it because the people don’t see it. It just works. If you
break things the rants will come in faster than you can read them.
Well, that’s part of the game and it’s ok.

Damir Perisa: The actual challenge i face nowadays is to keep being informed about all
the activities in the community. Growing means more people and more
people means more activities. The bigger the community the more difficult
to stay informed. From experience from my other projects i’m involved in
(e.g. the Calcutta Project Basel) i learned that to be really productive,
you need to know and understand most of the activities that are going on.
In ArchLinux, about a year ago, if i was offline some days and came back,
i needed some minutes reading posts in the forums/ML to be “back on
track”. Now, if i’m offline for some days, i need more than half an hour
to catch up with the activities. This costs time and time costs
productivity.

Dale Blount: Not really, everybody wants the same thing, their Perfect Distro. I try
to do this for myself, so added requests don’t stress me any.

Jason Chu: As it stands, the main message path between developers and users is through
the bug tracker and “flag out of date” button. There have been more bug
reports since popularity increased.

Tobias Powalowski: Well not really, the difference is that you get more feedback on your work,
negative or positive.

Aurelien Foret: I’m getting frustrated because of this increased popularity, because I
just can’t read anymore all forum posts or mails from Archers 😉
Seriously, it’s giving me extra motivation to see more people interested
in Arch, and to feel the work done on Arch is useful and appreciated by
more and more people.

If you had asked me this question two years ago, I would have answered
I’m afraid to see Arch popularity increase. Anyway, Arch is still a
healthy distribution today, and there’s no reason for things to not keep
that way.

Arjan Timmerman: I has decreased, because Jan helps out a lot nowadays.

4. From your repositories: which is the most painful package that you must keep supporting/updating?

Judd Vinet: Lately the kernel package has been particularly annoying. There are
many different patchsets one can use, and now that the kernel developers
have moved to an often-updated 2.6.X.Y versioning scheme, it makes it
more difficult for me to distribute up-to-date, stable kernels. Users
don’t want to download a new kernel each week, reboot, compile custom
modules, etc. so I have to try and space these upgrades out as much as I
can.

Jan de Groot: I don’t have many packages, but from my own packages, the limitation of
arch with 1 PKGBUILD -> 1 package really kills gst-plugins because of
the splitup (lucky me I know how sed works, updating 45 PKGBUILDs is a
breeze then).

Usually I update gnome packages for Arjan and some mozilla-* packages
for Dale. The gnome packages are not that bad, but the mozilla-*
packages are horrible when it comes to their build system. If I would be
openoffice.org maintainer, that package would go straight to number 1 on
the most irritating package to create.

Tobias Kieslich: Ask me this now and I will give you a completely different answer than
I would in 4 weeks. Currently the mono software is under heavy
development. So it is tricky to provide latest software without
breaking too many dependencies.

But I also remember blender some times ago when they dropped autotools
shortly after they introduced it. scons building support had still
some rough edges and the only way to build it were the old NaN
shellscripts which are a bit proprietary. On the other hand, blender is
a complex piece of software and it builds on many different platforms.
So there is need for more complex build systems. It just takes time to
get used to it and it’s not really documented apart from some comments
in the scripts itself.

Damir Perisa: There are no packages that i “must” keep supporting/updating. Almost all
the packages i maintain i also use at least weekly. Some of them are
essential tools i use daily. There is always one or two packages that are
in a state that is not easy to solve (e.g. when the authors change the
URL and you need to search for it or when the authors change the building
process or the API without announcing it) but this is often solved by the
next release of this software. The actual pkg that is in this state is
libextractor that wants a static -lgobject-2.0.

Dale Blount: I bet each of us have our own lists for this question, but I’d say that
the packages that need patches to build with the latest toolchain are
the ones that annoy me personally the most.

Jason Chu: Lots of packages are annoying in their own way, but if I had to pick the
worst one it would be gnomemeeting. The intricacies of gconf fail me.

Tobias Powalowski: Well most time consuming is KDE because it’s some kind of monster 😉
searching new depends, figuring out bug reports, patch security issues,
building/testing and give some support in the forum and irc.
but i guess it’s not different to others DEVS that maintain the big Linux DEs.

Aurelien Foret: I’m not a good candidate to answer this question: I almost only maintain
packages for Xfce, and the ones relating to it. No problem here, Xfce folks are doing a great job 🙂

Arjan Timmerman: The most painfull packages was openoffice for me it doesn’t build with
the latest gcc, and before that i needed a lot of patching.

5. If you had unlimited resources which part of Arch would you change/update/further-develop?

Judd Vinet: Pacman needs some love. It works well, but we have had plans to turn it
into a proper library for a couple years now. Aurelien Foret has been
doing most of the work on the library project and we’re finally seeing
the finish line somewhere off in the distance. In an ideal world, Arch
would be my fulltime job and I would have ample time to work on pacman
and the distro itself.

Jan de Groot: Pacman would need some work. Porting existing tools like
gnome-system-tools to work on archlinux perfectly would also be on my
todo list then.

Tobias Kieslich: I think there are some urgent needs take action on a good i18n concept
for ArchLinux. From a good base in glibc and the initscripts, over a
well considered font support to some good and usable input methods.
This also affects the installer and some applications. I18n is
pretty much useless if things doesn’t really act in concert. AFAIK,
none of the developer speaks or can write multibyte based languages …
and my Russian really sucks. But there is some activity in the
community going on which needs to be brought to some usable results.

To write documentation is another issues and most developer feel that
something needs to be done on this point. If it is documentation for
ArchLinux itself or to write some stuff about projects that could be
realized with ArchLinux. I’d like to write a guide for an ArchLinux
Server without the big and well known software because there is a lot
of good and specialized software which fits the need of many people way
better than the “incumbents”. But no one knows about and how to use it.

Damir Perisa: Having more resources, i would start spending them on my other activities
first. Helping other people, doing “cool” research projects, traveling,
learning languages, taking pictures … the list is really long.
ArchLinux is not very high in this list, but there are for sure a lot of
things i would want to do for it.

One of the things related to Arch is: i would be able to spend time
writing on the document i started about a year ago, the “Survival Guide
to (Arch)Linux”, the introduction to computers, opensource software,
linux and the virtual team of people helping each other to reach goals.
This document i started to write mainly for people in the 3rd world to
help them understand computers and the usage of IT to speed up
administrative tasks without forcing them to pay for licences for
software where there are “free” and often even better alternatives
around. It has now about 30 pages but is a long way from being finished.
The reason is the lack of time to work on it.

Dale Blount: I would increase the reach from i686 to x86-64, PPC, and sparc.

Jason Chu: I would put way more time into pacbuild (the automated package building
system), devtools (a set of tools to help Arch developers), namcap (the
package analyzer), pacman, and other such projects to help Arch. I’m more
of a programmer and less of a package maintainer.

Tobias Powalowski: Probably i would write more wikis and docs on stuff that’s interesting.

Aurelien Foret: I would like to see our current repositories ported to more architectures, namely i586, PPC, and x86-64. Another cool thing would be to have a “stable” repository with only security issues and critical bugfixes backported to it from our “current” repository.

6. Recently there was a discussion about Pacman’s scaling when it deals with many installed packages. Your thoughts on this and the future of pacman?

Judd Vinet: Well, it’s less of a problem for those of us with more memory and less
reboots, as most of the db will be cached after the first pacman run.
But there is a big slowdown for large pacman databases during the first
run (since a reboot). This is because pacman has to read many small
files, and some filesystems do not optimize for this type of behaviour.

The filesystem-based database has some great advantages, ones that
reflect Arch’s values more than a dbm backend would, but there are some
performance issues that we can’t ignore. I’d like to try using a db
(or sqlite) backend in the future and see how much of a performance
improvement we can get.

The big plus to having a plain filesystem base is that anyone can peek
and poke at it, including custom scripts and whatnot. Using a more
complicated backend makes it tough to code up a bash script that scans
the database.

So I guess only time will tell — the jury is still out. 😉

Jan de Groot: It is because the many small files. Pacman looks through all of them. In
the beginning pacman was fast, but when we did some good work to get
tons of packages in the repositories, it became slow. Personally I’m
thinking of putting the package database in a BDB format, which is also
the easiest.

I haven’t worked on this because I want to wait for the modularized
version of pacman other people are working on at this moment. It would
be a waste of time to convert pacman 2.9 to a BDB format and see pacman
3.0 appear as a complete rewrite after that.

Tobias Kieslich:
Pacman’s scaling goes well, but it has some serious trouble with file
operations on certain file systems, most prominently on xfs and
reiserfs if I remember correctly. This could be solved by using a
single file for it, incorporating a known database backend such as db or
sqlite or maybe some very small free database engine since db or sqlite
might be a bit overkill. I think this is related to the unlimited
resources question since Judd could make some experiments here to find
the “best” solution if he had the time.

I think Judd can answer this better since pacman is his baby.

Damir Perisa: Pacman is the core of ArchLinux and it’s concept and features support a
really great concept. I myself have around 1200 packages installed on the
laptop and when it comes to -Suy multiple packages it takes long to
handle the single files where pacman keeps the information-database on
the packages. On bad days (kde update) it takes pacman up to an hour to
prepare a -Suy (without downloading and updating). This behaviour is not
ideal and i wish that pacman would use a more effective way to handle the
information-database. My opinion is to use a DB or at least a single file
instead of flat single files to speed up this bottleneck. However, the
usual installation of ArchLinux does not contain that many packages and
therefore times are much shorter. On my old computer (266MHz) where only
around 340 packages are installed, pacman reacts almost immediately doing -Suy.

Dale Blount: Luckily this doesn’t bother me much.

Jason Chu: While pacman can use work, I also think that it’s really great how far it’s
come. I try not to criticize pacman’s failing, instead I submit patches.

Tobias Powalowski: well let judd and the pacman crew find an answer to that.

Aurelien Foret: In my opinion, pacman assumes quite well its job.

Currently, there is a trend to consider pacman would behave better with
another database backend, but I don’t really share this point of view.
Having a flat file based database of packages makes it so convenient and
easy to manage that it is virtually almost unbreakable.
A different backend, such as gdbm or bdb, would introduce an overall
complexity to pacman, which I wouldn’t welcome.

There are still some areas that can be reworked to improve pacman
scalability, and I think it is better to focus on improving the current
implementation than switching to a new backend.

Anyway, let Judd have the final say on this topic.

For the record, I’ve already tried to implement a gdbm backend for
pacman several months ago, but I was disappointed by the results: it
didn’t make pacman significantly faster.

But at that time, packages repositories were smaller than nowadays, so
it may worth spending some time to perform more tests…

To date, I’m quite involved in the process of creating a library for
pacman. Althougt it will allow people to develop new frontends for
pacman package management functions, my aim is also to help
rationalizing pacman structure and cleaning it. Based on that, it will
be easier in the future to extend and enhance pacman.

7. Do you have plans to move your CVS to Subversion or Arch systems?

Judd Vinet: Nope, nobody’s convinced me of a Subversion-only feature that would make
the move worth it. None of CVS’s shortcomings really faze us, so it’s
tough to think of a reason to change.

Jan de Groot: No, the only reason I would use SVN is because the stupid server
interaction CVS does on every action. This is solved using SSH keys on
my side, so this is not really a problem to me.

Tobias Kieslich: ArchLinux uses binary packages that are provided via pacman from ftp/
http servers. CVS is not the only application that is involved in the
package changing/building/uploading process. It is part of our build
system and the way we provide our package instructions to the users
(via cvsup in the abs script). CVS is just controlling the PKGBUILDs and
absolutely sufficient for this job. If there are plans to change that I
think Judd will have his reasons and tell us about it.

Damir Perisa: It’s not up to me to decide this, as i don’t run the archlinux.org server
but i see no advantage in svn compared to cvs worth the change.

Dale Blount: Let’s let Judd answer this one.

Jason Chu: I’ve wanted to since I started using Subversion, but I don’t expect that
the other developers share my feelings. I can’t find a compelling reason
to change because things like cvsup won’t work with subversion. The abs
command would have to find a different backend.

Tobias Powalowski: let judd decide that, i have no problem with CVS or subversion.

Aurelien Foret: CVS just works and addresses our needs quite well. I don’t see a good
reason to change it. Hum… maybe this one: moving to Arch system could be nice because it
has such a cool name 😉

8. If the popularity trend of Arch continues, do you have plans to go fully commercial and maybe form a company around it?

Judd Vinet: I’ve been encouraged to do so by a few people, but I’m not sure. To be
honest, I’m not much of a business person, so I have trouble thinking of
ways that Arch could generate revenue while still being a free product.

Jan de Groot: Linux doesn’t sell that good in my country, so if it was only for my
country, I wouldn’t. I don’t think there’s really a big market for Arch,
because commercial users are looking for more secure and stable distros
like Redhat, SuSE or Debian. That leaves us with users like myself that
don’t need support. These users won’t pay for archlinux, at least, I
wouldn’t.

Tobias Kieslich: There are no plans of which I know. Personally I’m against a direct
commercialization of ArchLinux like AL-Home version 6, AL-Server
version 3 1/4 etc. This also doesn’t work with our rolling release
system. Providing service for ArchLinux installations or products
based on it is another thing, but also there are no plans.

Damir Perisa: If the growth of the community of ArchLinux speeds up, i plan to create my
own distro with a very similar concept but with less people and
compatibility to ArchLinux repositories. Maybe with a rewrite of pacman
to support mysql. This are however plans i can face not before my studies
are finished. Again: Time is the limiting factor.

My comment about commercialisation: Don’t!

Dale Blount: Let’s let Judd answer this one too.

Jason Chu: I’ve been saying since I started that I’d do this all day if someone paid
me. I fear a company would be driven by pressures from the market though.
It’s a double edged sword.

Tobias Powalowski: I think on commercialization the problem is that people will get more
demanding and expect perfect support, documentation etc.
it’s judd’s baby and he decides in which direction Arch will go.
Personally i’m against commercialization.

Aurelien Foret: I don’t think Arch Linux was born to achieve this possibility. Anyway, I definitely wouldn’t mind getting paid to work on it, although I’m afraid it would probably kill the fun I’m having with Arch…

9. Do you have plans to automate more parts of the installation process? (e.g. create new users via it, have a curses front-end for configuration
instead of having to edit rc.conf, etc?)

Judd Vinet: Not really. A lot of people like our current installation script. One
thing I’d like to have is a “kickstart” style setup for sysadmins who
install linux in labs or other settings where each install is
more-or-less identical.

Jan de Groot: I don’t use the installer at all because I don’t really like it, I use a
modified quickinst script I use too to set up my build chroots. If we
would improve the installer with configuration support, we should also
go the same way as debian went with their debconf database. Since we
don’t want to hack around in people’s configuration files, the installer
won’t get improved in this way.

Tobias Kieslich: The positive effect of the “limited” means of the installer is that
people are forced to read the basic documentation. This prevents from
asking needles questions and indeed I don’t see so many questions
regarding how the installer works. Although I personally don’t need it,
adding support for more file systems and a better i18n would be nice
since users request it from time to time.

I don’t see the need of configuration front-ends – this would be a
totally different and partially contrary approach of the system
administration than we have it now with rc.conf and friends. I don’t
even think it would be useful for newbies. A configuration front-end
for admins to get the daily work done is another thing, which shouldn’t
be provided out of the box and included in the installer. But there are
no plans of which I know. Also I don’t like to see IRC quotes from
users to newbies: “Install easyadmin and you are done…” These people
come back and ask other simple things they could get easily from the
docs.

For administration of bigger installations I think the support of
easier system cloning would be nice, although much could be done via
simple shellscripts, thanks to pacman’s capabilities. Or a rapid
install tool that takes a list of settings like hostname, IP, users
etc. and installs a bunch of boxes without confirmation for every
point. Oh, unlimited resources …

Damir Perisa: I’m not involved in the Arch Installer but here my opinion on it:
The only feature enhancements in the installer i would find usefull is the
handling of more filesystems and exotic devices and a better
internationalisation handling. I see no reason to create users via the
installer, use a frontend for the configs or mess with other things that
are good to left being simple. Everybody who is willing to learn how to
do it, will be able to edit a file and use the correct command to create
users and groups. What i see that should be done is to work on the
documentation to make it even more evident for newcommers that their
learning is simpler and faster with less effort. That’s also why i said
that i plan to work on the docs. I convinced a lot of non-linux users to
use linux and i got very positive input from them about how simple
archlinux is when you get used to it. The only negative input i got is
that the docs of archlinux are a little bit chaotic and you need some
time to find the informations you need. By my opinion Arch is a great
distro for newbies that are willing to learn. The quote that comes to my
mind is: “Give a person a fish and you fed her/him for a day, teach this
person fishing and she/he will have a more confortable life.”

Dale Blount: I’d hope not. Arch isn’t for the beginner and if we make it easier to
install, the average user will be confused after install time.

Jason Chu: That depends, if the automation is created to cover up parts of the process
that are “too complicated” or “too much to learn”, then no. Everyone
should want to learn and understand. Then again, if it’s to help a lazy
(in the positive sense of the word) admin keep their sanity, then yes.

Tobias Powalowski: Arch should support more filesystems, more hardware while installing and ntfs
resizing support would also be a great feature. I think we have an automation
script on the installer cd, haven’t we?

Aurelien Foret: To date, no… but contributions are welcome 😉

10. How would you compare Arch to Slackware, Debian, Gentoo and even FreeBSD? What a power user needs to know before enter Arch’s domain?

Judd Vinet: Tough to compare really, they’re all great distros. I find it
flattering to have Arch compared to the likes of Slackware and Debian,
as I’ve always revered them as the time-tested, rock-solid distributions
on which other distros are based.

Arch has been largely successful in adopting positive traits of other
distributions, and you’re quite accurate in picking those four. I think
Arch has borrowed some good qualities from each of those systems,
especially Slackware and FreeBSD.

Most users who like FreeBSD or Slack would probably like Arch Linux.

As for prerequisite knowledge, you don’t need that much to start using
Arch, as long as you’re prepared to ask questions and read documentation.
It’s not as involved as we often make it out to be, but having a
rudimentary knowledge of the commandline, kernels, modules and hardware
config will be a big asset when climbing our learning curve.

Arch assumes you know what you’re doing. I like that a lot, because it
tends to stay out of your way if you start to wander off the beaten
path. For this reason, I think Arch may prove to be a good base for
other, more specialized distributions.

We’ll see.

Jan de Groot: Debian users should be able to find their way into arch, at least I did.
Only thing I had to learn was that apt-get was renamed to pacman, and
that a thing like debconf didn’t exist.

Arch does not contain upstream documentation in the packages and does
not configure things for you. This is something to get used to when
switching from debian, since the first thing I did after installing a
package was reading /usr/share/doc/$pkgname/README.Debian.
Archlinux is more bleeding edge, even more than Gentoo. Things could be
broken once in a while, so I wouldn’t use archlinux on production
systems. I don’t keep Debian as server OS for nothing.

Tobias Kieslich: Each of the named systems has been developed with a certain idea to
make things better and easier. I think arch brings much of the good
things of these systems as it is fast, simple, solid and easy to
maintain. Arch doesn’t fit every need out of the box. But it can fit
them with only little customization by the user.

Thanks for the interview and your patience with my mono-packages 🙂

Damir Perisa: I would not compare them. All have good ideas behind and everybody should
decide idependendly what idea suits her/his needs best. As a student in
biology, i know to respect the value of diversity. You cannot argue that
e.g. a zebra is “better” than an elephant. Both perform important actions
in the ecosystem of the sahel zone in Africa and without one of them, the
ecosystem would lack important elements in the chains and processes
called life. I think that diversity is also the key to linux. You should
not try to convince say a Debian user to use something else because you
like it. It has to do with ideas. The possibilities today give the people
the freedom of choice. This is a strenght opensource software has
compared to commercial products. You often have 2 or 3 kind of software
to choose to do be productive.

What i would tell a user who asks me about Arch is easy: I would tell
her/him my experieces and the reason why i myself use it. If she/he agrees
with my arguentation of the idea of ArchLinux how i see it, she/he
decides her/himself to try it or not. The only tip i would make is: If
you are a newbie and do not care about learning some basics of linux,
forget it! Arch is, as i see it, for the lazy user who is still willing
to learn things and is not afraid if this involves the command line. You
don’t need to be a guru or expert in IT, the only thing you should bring
with you is the joy to learn how to use a computer efficiently.

Thank you for the interview and the interest in ArchLinux.

Dale Blount: Arch combines the best from all of these distros. It’s simple like Slackware, easy to update like Debian, optimized (although not to the same extent) like Gentoo, and rock solid like FreeBSD.

Jason Chu: I only have experience with Slackware, Debian, and Gentoo. Even then, I
don’t see what the point in comparing them is. They may all be linux
distros but they’re all managed differently and have different goals.

To answer the second question, it’s not what a power user needs to know,
it’s what a power user wants to learn. There are many users of many
different skill levels who all get along in the Archlinux community.
Depending on how you want to use your machine, your knowledge may already
be enough. If you’re willing to learn, your knowledge *is* already enough.

Tobias Powalowski: Well i don’t know the others, i installed once Slackware and i tried Knoppix
hd-install but i have no experience with them for running them in long time.
I did run SuSE 7.0-9.0 i wouldn’t say that it’s bad but if you start changing
things in SuSE beside the installer you will get trouble and updating was
always a little bit cross your fingers and hope it will work. ( i mean from
one release to an other.)

Archs-Installer is like Slackware, pacman/makepkg is a great package system
it’s optimized for i686 and you can tweak Arch to boot really fast, what
else a power linux user does want 🙂

What you need for Arch:
Read the install doc,wikis manpages, learn how to use your favourite editor
and some basics of how the files in /etc work together that’s all you need.
Since Arch delivers the things normally as they are you can read the manual of
each package you need and adjust it to your needs.

Don’t expect crazy hardware to be running in Arch, but you could be suprised
that it may work. If hardware runs in other distros it should also run in Arch.

Aurelien Foret: I’ve never used BSD, and I prefer to stay away from source based
distributions. This being said, I was a Slackware user before coming to
Arch, and I found in Arch a perfect extent to my Slackware experience.

I don’t consider there’s a peculiar knowledge required for an average
Linux user before trying Arch. On the opposite, you’ll find yourself far
more knowledgeable by using it!

Arjan Timmerman: I do not compare them, Arch suits my needs. I never really used. What a power user needs to know before enter Arch’s domain? I think know your system and have a basic knowledge of the console.