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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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.
Take it easy guys.
I’ve hopped on the Ubuntu train for now, but reading this interview makes me want to jump back on Arch. I’m so torn now.
I had the floppy images dd’d(had run out of CDs late at night), and was about to install, but went ahead with Gentoo instead. I guess just because Gentoo is a bit more mature and the great docs and forums.
This distro looks like it serves the need of slackware-type people that want a package manager.
Maybe I’ll give this a try at a later time.
10. How would you compare Arch to Slackware, Debian, Gentoo and even FreeBSD?
I would have been more interested to see what they had to say with Arch Vs Ubuntu, which is like and like, and both going after the same market, rather than a list of systems which are ALL going in a completely different direction.
There is no mention of Ubuntu because Ubuntu is a desktop distro created for normal users while Arch is for more advanced ones — as the Arch guys also confirm. Arch is closer philosophically and technically to Gentoo, Slack and pure Debian rather than any of the Ubuntu, mdk, suse or fedora.
Forget that, I confused Arch and Ark AGAIN, anyway, nice interview.
Ubuntu and Arch can’t and should not be compared. Ubuntu is targetting the home user, and trying to make everything automated and also avoiding the cli (though you don’t have to use the gui’s.) Arch is for power users, or people looking to get their hands dirty learning the internals of a Linux system.
Seriously, what were you thinking? Arch and Ubuntu are totally different distro’s with nothing in common except for the fact that they are using a Linux kernel… geez.. It even says this in the interview. Did you read it?
I don’t mean to sound rude, so if I come off that way please excuse me.
That being said. I think Arch is a wonderful distro. I use it along side my Debian install and I really love it. I use it to play with all the new toys (gnome 2.10, kde 3.4 etc). It is still young, but it’s chugging along smoothly, with a bright future ahead.
Arch and Ubuntu are quite different…. Arch provides the user with the option of starting from a minimal set of base packages and then creating your own “tailored distribution” from scratch (ie, typically a nice ftp install of the base packages then use pacman on reboot to add X & WM etc etc etc… nice ) – Ubuntu does things quite differently…. they’re cleary both good distributions and can cater for different audiences.
Is it normal to REBUILD all your programs on (k)ubuntu to have MP3 support (for Gnome and KDE integration you are shit out of luck, even if you use universe/multiverse/unofficial repos…) because this thing has “fixed Debian for the Desktop” by simply screwing it?
For me Debian SID with all its bugs is much superior to Ubuntu, and Arch is a few ages ahead (for the desktop). A plain “pacman -Sy something” would install “something” in a matter of seconds, including things forbidden for (k)ubuntu, and for things not included on the official or TUR repos, a simple visit on the ArchLinux forum will most likely bring you an ABS building script, which is simply the most advanced and trouble-free way to build from source ever invented (sorry, Gentoo’ers…).
Any more off topic ubuntu comments will be modded down. The original poster already said that he confused Arch to Ark and this is why he asked that question about ubuntu. There is no reason to go on and on about ubuntu forever. Keep it on topic.
a simple visit on the ArchLinux forum will most likely bring you an ABS building script, which is simply the most advanced and trouble-free way to build from source ever invented (sorry, Gentoo’ers…).
Can you explain how ABS is more trouble-free than portage? I am an Arch Linux user and used to use Gentoo, I have used ABS a bit (I finally got round to building a couple of packages that weren’t in the repositories with it today), and whilst it isn’t difficult once learnt it requires manual editing of the PKGBULD files to get the customizations you want whilst with portage you can just parse the USE flags you want to emerge and you get the package built with the options you want.
>BS building script, which is simply the most advanced and
>trouble-free way to build from source ever invented
Sorry, but I still prefer CheckInstall. Checkinstall also does RPMs and DEBs as well as Slackware packages and it’s *way easier* to use than ABS or EBUILDs. You just type “checkinstall” instead of “make install” and it will strip the binary, create the package (with dependencies when building RPM/DEB) and will install it for you. No reason to bongle your mind with filling deps manually and end up with multipe folders that ABS creates and complicates the matter.
I just wish someone could add a backend to Checkinstall for Pacman. Now, THAT would rock!
I just wish someone could add a backend to Checkinstall for Pacman. Now, THAT would rock!
Yeah…soon, when the pacman-lib comes out, we should start to see some cool pacman-related tools come out.
“Sorry, but I still prefer CheckInstall. Checkinstall also does RPMs and DEBs as well as Slackware packages and it’s *way easier* to use than ABS or EBUILDs. You just type “checkinstall” instead of “make install” and it will strip the binary, create the package (with dependencies when building RPM/DEB) and will install it for you. No reason to bongle your mind with filling deps manually and end up with multipe folders that ABS creates and complicates the matter. ”
How often are you installing RPM/DEB on Arch? Otherwise you have to fill in dependencies somehow anyway.
Here is an example PKGBUILD:
# Contributor: dibblethewrecker dibblethewrecker.at.jiwe.dot.org
pkgdesc=”rxvt-unicode is a clone of the well known terminal emulator rxvt, modified to store text in Unicode (either UCS-2 or UCS-4) and to use locale-correct input and output. It also supports mixing multiple fonts at the same time, including Xft fonts.”
./configure –prefix=/usr –enable-everything
make || return 1
make prefix=$startdir/pkg/usr install
How can you call this difficult? You can continue trolling about checkinstall and whatnot but I don’t think there are anyone that thinks that making Arch packages is difficult or timeconsuming.
Xerxes, I suggest you be careful how you talk to me. I am not “trolling” about Checkinstall. I am simply keeping firm on my opinion on Checkinstall being much simpler to deal with.
Your sample IS NOT complete. A more normal sample would include dependency information that you convieniently left out of your sample. Dep information that must be filled up *manually*. Also, this one has to do with mdsums etc. Checkinstall IS simpler.
>How often are you installing RPM/DEB on Arch? Otherwise you have to fill in dependencies somehow anyway.
Checkinstall uses LDD to find out what deps are needed. You don’t fill them up manually.
Well, to me, being able to cut and paste a PKGBUILD and type, ‘makepkg’, rather than having to search all over the place trying to figure out why a program, plus one or more of it’s dependencies, won’t compile, made ABS much more useful. Although if it can be made better, I’m all for it.
well you won’t checkinstall unless you ran configure and make, and even if checkinstall lists all the dependencies in the package (I used it with slackware which does not have dependency checking support), you still have to have them installed (what will be done manually)
hence, you will have to take care of dependencies by yourself, so what’s the big deal with putting them in PKGBUILD?
the other thing once you have PKGBUILD, you can reuse it, rarely it will not work with newer versions of packages
When Xfce 4.2 first came out I decided I wanted to have the compositor (it wasn’t built by default). Knowing nothing about ABS but it’s existance I read a few pages of the docs; and within 40 minutes I had rebuilt xfwm4 with compositor and was using it. And if I want to switch to their build, I just uninstall it and sync it with the repo server in pacman!
Unbelievably handy for the occasional tweak!
Program interdependency is easy enough to discover, deciding how to manage that knowledge is the problem.
$ readelf -d /usr/bin/gimp | grep ‘(NEEDED)’ | cut -d[ -f2 | cut -d] -f1
“Most users who like FreeBSD or Slack would probably like Arch Linux”
That’s certainly true. I’m a FreeBSD guy and briefly tried Arch a little while ago (gotta peek over the fence now and then ;-), and indeed I felt right at home on the console — their pacman was really the only tool I needed to “learn” and that was drop dead simple.
I’d say this is a very nice linux distro for those who sorta know their *NIX and want to have a full featured DE set up quick and easy though still customized to a large extent.
I must say that when I read that the hardest things are packages that don’t compile (with or without the default toolchain being used), being used to FreeBSD ports I tend to shrug (as in: that’s normal). But that’s ok. The concept of a distro is different anyway.
Very interesting reading!
>$ readelf -d /usr/bin/gimp | grep ‘(NEEDED)’ | cut -d[ -f2 | cut -d] -f1
How incredibly easy to figure this out. How user-friendly. NOT.
…that this kind of automatic-figure-out-the-dependencies stuff is rather unreliable and doesn’t lend itself well to the long-term. Which is why the more well-established distributions still do lots of manual dependency checking and tweaks.
How incredibly easy to figure this out. How user-friendly. NOT
Would it be easier if you had a command like ‘namcap <pkg file>’? Oh wait, you do!
> >$ readelf -d /usr/bin/gimp | grep ‘(NEEDED)’ | cut -d[ -f2 | cut -d] -f1
> How incredibly easy to figure this out. How user-friendly. NOT.
there is ldd to check binaries — very easy to use:
and to find out, what package owns a file this binary depends on you ask pacman:
<tt>[damir@Asteraceae ~]$ pacman -Qo /lib/tls/libc.so.6<br/>
/lib/tls/libc.so.6 is owned by glibc 2.3.4-2 </tt>
… and namcap to check packages on dependencies — also very easy to use against PKGBUILD’s or pkg.tar.gz
… but the important thing is: for the packages in the repositories in most cases you don’t need ABS and manipulation and don’t need to care about dependences in detail! simply <tt>pacman -S whatever</tt> and start using it.
I think the quality of the PKGBUILDs needs to improve. It has been hard porting arch to the x86_64 because of some mistakes in the PKGBUILDs, for example the links for downloading the source tarballs. Other than that arch rocks!
Why not put the Bloody pcmcia-cs package in the base install? So a laptop install isn’t so confuzzing.
There’s a lot of work put into Xfce but I must be missing — something what so great about it? I find FluxBox works well especially with the menuconfig tools package in Arch. To be even more diverse I think Kbuntu has some serious potential. Thats all Debian needs is a x86 focus release to win .
“> >$ readelf -d /usr/bin/gimp | grep ‘(NEEDED)’ | cut -d[ -f2 | cut -d] -f1
there is ldd to check binaries — very easy to use:
and to find out, what package owns a file this binary depends on you ask pacman:
<tt>[damir@Asteraceae ~]$ pacman -Qo /lib/tls/libc.so.6<br/>
/lib/tls/libc.so.6 is owned by glibc 2.3.4-2 </tt>
… and namcap to check packages on dependencies — also very easy to use against PKGBUILD’s or pkg.tar.gz”
# apt-get install gimp
the comments are SO OFFTOPIC..
sudo pacman -S gimp is JUST ENOUGH. guys from archlinux control yourselves, others comment whatever you want.
A great interview, Judd is a really nice guy.
thanks for the interview eugenia
#pacman -S gimp
Will do the same and resolving dependencies as well. Pacman is basicly spt-get where the ‘s’ represents simple
how many people spend weeks building the same pain-in-the-butt packages for the N different distros? so much wasted time. i do not mean that as a smart remark, i mean really, is there not one format (autopackage etc) that can capture this? people are wasting huge amounts of time duplicating packaging efforts into systems with minor differences.
why do people continue to put freebsd in some “hardcore” camp of people who hate installers, want to build everything from sources, generally do things the hard way…?
freebsd has an installer that is simple, practically dumbie-proof, and does a considerable amount of hand-holding. it has a frontend to do post-installation work without getting your hands dirty too (sysinstall).
package and ports are clearly defined and once again added by default by the hand-holding installer if you want.
oh by the way i am describing the installer circa 1997. i am sure it has only improved. i went to freebsd from windows BECAUSE of the hand-holding install, which at the time was more solid than any linux installer. its no anaconda to be sure, but it is not frightening or challenging in any way.
ports is basically idiot-proof, and breakage in ports is no worse than rpm breakage on avg. the freebsd site is simple and easy to use. ports are kept up to date.
really folks, painting this as some “elite” system is absurd. it sounds like arch is much much harder to deal with and frankly i have to wonder what is the point of just making a linux that from all appearances is just harder to deal with.
Hmm, well, Checkinstall is simpler than using an editor to create a PKGBUILD, but can we use Checkinstall itself to create a PKGBUILD?
While it probably is simpler to use Checkinstall for personal use, once you wish to contribute back, you’re in a bit of a trouble. Checkinstall might be able to create the package nicely, and maybe even use namcap to automatically add dependency info (does checkinstall add dependency info to RPM/DEB? I only used it with Slackware). Putting the possibility of dependency bloat aside – how can a package made with checkinstall be shared back to the community?
No one has any idea how it is built, and since Arch’s repositories are based on PKGBUILDs, well, it’s a bit of a problem. More so, these packages can’t really be “trusted”, because again we lose the information about the way it is built.
If I made any mistakes here, please fill me in, as I am not a checkinstall expert.
…sorry for the off-topic, but I’d like to make a point that myself and a lot of people I know (power users and developers) never try Linux solely because of discussions like this. Watching people arguing (quite angrily I might say) about who has the best package manager and similar pointless arguments means I (for one) will never convert to Linux knowing that these are the sort of people I’ll be mixing with.
It’s not a flame, or trying to be flamebait, but a personal observation.
Repeat to myself, the distro package manager isn’t the problem. The options that the maintainers chose is what shapes the distro.
That is irrelevant for small packages but will determine how the system will behaviour as a whole. And don’t forget about patches that must be applied and file relocations that need to be done.
Anyway, good interview.
PS. I like checkinstall but frankly, keep in mind that it is to be used on small packages that are not in the distro repository.
What FreeBSD comparisons? Who was painting it as being hardcore? Did I miss something?
All that was said was that users that like FreeBSD and Slack are likely to like Arch. So calm down on your rant. Arch may not be as easy as FreeBSD (I don’t know I haven’t tried FreeBSD), I personally think it isn’t as easy as Slackware, but that doesn’t stop them being similar.
P-J, GNU/Linux community is not (only) what you see in OSNews comments! What I said is in the general moto: “Don’t believe everything TV says you”. Since you want to convert and you’ll be n00b in lnx try http://www.ubuntulinux.org
a start from 0.6 archer
Arch was the last Distro I tried in my recent 2 month immersion in Linux. It installed perfectly on my Dell Laptop and is nice and fast, but after hours of fiddling I couldn’t get the internet to work on my desktop.
Anyway, Sadly I’ve gone back to Windows 2000 having tried;
Damn Small Linux
There are some very nice features and applications in Linux, but fundamentally the desktop was never as responsive (especially screen redraw) as it is in Windows. Getting things done (once the applications were installed and everything was setup the way I wanted) was always that little bit more cumbersome, clunky, and time consuming than in Windows.
If for some reason I was forced to use Linux tomorrow I could easily live with Debian, but it’s still far from being a Windows beater.
I’m sure curiosity will keep me coming back every now and then to see what progress is being made though.
Eh.. my only quam with Archlinux is uhmmm.. i cant think of any right now.. 😀
Great Read thou..even if it was a bit long.
My bad… I said ‘try Linux’, whereas I meant ‘migrate to Linux’. I’ve tried many distros including Arch, and would consider myself a ‘reasonably’ seasoned GNU/Linux user but I’ve never felt comfortable using it as a desktop and always been unlucky enough to have these ‘OSNews’ type commenters on any forums I went to.
I’m exactly the same. Windows is what I/we know and that’s why it’s comfortable.
If I did ever migrate, either Arch or raw Slackware would be my choice, but it’s unlikely that’ll happen this decade.
If you couldn’t make your internet work on your desktop, then it’s pretty sure hotplug could not activate your network card. Simply adding your network card to the MODULES section of /etc/rc.conf should resolve this issue once and for all.
Having used both Slackware (extensively) and FreeBSD (just a little) I find Arch much easier to handle than both.
Speaking of simply and Debian, you got to try that new Simply Mepis 3.3. It rocks ;D.
“Speaking of simply and Debian, you got to try that new Simply Mepis 3.3. It rocks ;D.”
Bah! Now you are talking oranges and apples! SimplyMepis is strictly a newbie distro. It is designed for a complete newbie to be able to stick in a disk and end up with a working version of debian – with EVERYTHING being done for you.
Archlinux is NOT designed for the newbie user. Nothing is done for you in Arch – you configure it yourself from the cli.
Frankly – SimplyMepis has already accomplished all it has to offer – a simpleton installer for debian – everyone’s doing that now. Beyond that – it’s debian. Debian is everywhere.
Archlinux is a completely other beast. It’s designed for capable linux users, not people looking for the complete hand-holding experience.
I don’t know what all the hubbub is about, and why people have to keep bashing one over the other. I’m a Gentoo nut and haven’t tried Arch, but it looks really intriguing. The only reason I haven’t tried it is because I’m way happy with Gentoo, and I have enough on my hands learning Linux to try another distro. But I used to use SuSE till I got fed up with RPM. I’m sure Pacman is a great package manager, but since I haven’t tried it I’m not gonna stick my neck out and say that Portage is better than Pacman. I think it’s safe to say enough of us have had enough bad experiences with RPM to want to try something else. I’m at the point where I prefer meta distros anyway.
I have almost no trouble with Portage, except when I get brave and try to emerge a masked package. I’m sure all those other package managers have their merits, too.
I agree with Eugenia. The only distro’s I’ve used is Redhat, Debian and now have finally settled permanently with Slackware. What they all have in common is checkinstall works perfectly on all of them. There is nothing better then checkinstall, it makes my life a lot easier. xerxes2 your example isn’t difficult. But it’s just extra “stuff” that I don’t want to bother with… how is that easier then just typing ./checkinstall, done. It’s not.
I used Arch for a while and was quite pleased with it. I couldn’t stand the naming of devices so I was quick to switch to udev. I read this interview with my own reasons for finding Arch usefull, but it’s amazing how the dev’s intentions are translated into their work. In other words, the distro does a good job of representing it’s devs. You don’t really get that feeling with many other distros.
It would be something to see a distro such as Arch to be able to have the financial and developer abilities in order to complete the goals of it’s developers at the pace of a commercialized distro.
” I personally think it isn’t as easy as Slackware, but that doesn’t stop them being similar.”
What you talking about? Arch is definetly more simple than Slack:
1. rc.config (one config file to handle everything, kinda similar to FreeBSD)
2. pacman is much better and simpler than pkgtool (handles dependencies, keeps system up-to-date, removes unneeded packages WITH their dependencies and so on)
3. building packages is simpler: ABS
Now please tell me what’s simpler in Slack?
Basically I don’t know a better distro right now, it definetly ROCKS.
I think that ABS would pay for its extra effort if users could upload their custom packages, or at least their PKGBUILDs. It would save the effort for others. If they are not perfect, at least someone can improve them, and maybe they could end up in the main tree as well.
Recently I wanted to try QEMU cvs with the accelerator module. It doesn’t use autoconf, I built it on Ubuntu, and it needed some tweaking to build cleanly (I would have to make a patch out of it for ABS). It took me some time to do it the “right” way, and I am sure this effort has and will be duplicated.
Also checkinstall doesn’t output dependencies (using ldd), at least not when making .DEBs. But it’s quicker.