Intervju: Aaron Griffin (english)
Arch Linux: Popular KISS distro
Recently, we had a talk with the developer behind the young, but promising Linux-distribution, Draco Linux.
One of the big differences between Draco Linux and the user-friendly distributions we review here at Hardware.no, is the fact that Draco focuse on giving you full control over your operating system, without requiring you to have an advanced degree in Linux.
Draco Linux and similar distributions, are often referred to as KISS-distributions (Keep It Simple, Stupid!). One of the most popular KISS distributions to date is called Arch Linux which, compared to Draco, has a much larger community and number of developers.
To help us understand what make Arch Linux so great, we've asked the lead-developer - Aaron Griffin - some questions.
Interview - Part I
For our readers, could you please present yourself and your role in the Arch Linux distribution?
I originally began using Arch back in 2003. You could say I grew up on Arch, as most of my heavy technical knowledge was learned on an Arch box. Later on, I was asked to come on board the core development team, and became the lead developer for pacman, as well as developing tools such as mkinitcpio.Arch Tools
Pacman is a package manager written specifically for ArchLinux. It handles binary packages and is focused on being simple and easy to use.
mkinitcpio is a tool allowing you to add modules or change settings to your kernel, sometimes without having to rebuild the kernel image.
Nowadays, Judd, the previous "owner" of Arch, has stepped aside, and I have taken his place. Believe me though, that sounds more prestigious than it actually is. Arch runs smoothly because we have a great group of people working on it. Not because of what I do.
Could you briefly present Arch Linux in the same fashion?
ArchLinux is a distro which puts the user in control. It is a distribution designed to be a platform - a "base" for the user to do what they want. Other distros, for instance Ubuntu, tend to believe that the computer should manage itself and the user should just use it. This is a perfectly fine stance to take, and certainly works well for most people. But not for me. I want to have full control and that is why I use Arch.
Arch is lightweight and simple, like clay - able to be molded by the user as they choose. This means that we don't try to force a user's hand into our way of doing things, with our configuration tools, and our ideas. Developers suggest things, and push in certain directions, but let the user do as they wish.
How many developers are behind Arch? Do you see this number increase in the future?
According to this page we have 27 developers. Everyone does different things. While I *do* see our numbers increasing in the future, I think that will only come after fully figuring out what everyone's job is, and what holes we have to plug.Community Projects
Yaourt is an alternative front-end to Pacman, giving you extended functionality like compiling and voting for applications on AUR(*).
Alunn is actually written and maintained by a norwegian programmer, Mathias Nedrebø. Alunn is an applet (a small application running on your panel) that notifies you about package updates or news from archlinux.org.
KDEmod is, like the name implies, a KDE modification optimized for Arch Linux. KDEmod includes things like a new visual theme, speed and usability enhancements and modular packages so you can install only the kde applications you want.
*explained in more detail on next page.
What about the community? What is their role in the development, how can they help out and how can they become a "main" developer for Arch?
The Arch community is and always has been amazing. Many of the popular applications these days are community projects - yaourt, kdemod, and many others projects were created by community members, and are used by many people.
Additionally, we have what we call Trusted Users (TU) who manage our [community] repository. It contains less popular packages, packages the developers don't really use, and things like that. The clearest way for community members to help is to become a TU and help out there.
Interview - Part II
I understand pacman was created specifically for Arch. Why create your own package manager?
Pacman was created because, everything else is just too complex. Other systems needed 7 tools and had complex package formats. Pacman attempted to be simple and straightforward.Package Management
Makepkg is a tool using information stored in a PKGBUILD file to create packages for ArchLinux. These packages can then be installed using pacman.
ABS is a tool to download PKGBUILDs for the packages in the official repositories, allowing the user to compile their own packages from source.
PKGBUILDs are text files containing the necessary information to compile a package from source. This includes where the source can be retrieved from, what compilation options will be used, for which architecture can it be buildt upon, what license does it use... Anyone can create a PKGBUILD, and if you want you can share the PKGBUILD with your fellow archers on the AUR (Arch User Repository).
AUR allows users to upload their own PKGBUILDs for everyone to enjoy. When did the AUR idea come on the table?
The AUR started ages ago. It was originally called the TUR or Trusted-User Repository, where we had a group of people who each had their own repos that we officially supported. There was no real web interface or anything like that until we began discussing combining everyone's repos into one central repo, [community].
The AUR now exists and is ever evolving. There is usually a lot of activity on our aur-dev mailing list, where people help develop the AUR interface and overall experience.
Using AUR and a front-end like yaourt, you're able to install packages in an easy fashion even though they're not officially supported in the repositories. Why don't pacman have an option to compile packages from AUR? Or why isn't front-ends like yaourt added to the community repository?
Firstly, pacman will never compile apps from source. It's just not what it does. Having that feature would be like having cp also list directory contents. It makes no sense. In Unix Philosophy speak: one tool for one job.The Arch User Repository
The AUR is actually two repositories where the users are in charge. In the [unsupported] repository, anyone can upload their PKGBUILD file. Users can then find and download this PKGBUILD through the AUR web interface. If they like the PKGBUILD, they can vote for the package. A PKGBUILD with a lot of votes has a big chance of making it into the other repository, [community].
[community] contains binary packages which can be installed through pacman. Because of this, packages not following the Arch guidelines will not make it into this repository, like yaourt. The [community] repository is controlled by a group of Trusted Users (TUs). These are people who have contributed a lot of safe PKGBUILDs to [unsupported] in the past, and who has probably helped out in some other ways.
There are far too many security risks with the auto build tools. That is not to say that we think our users are dumb. We believe that if you want to take the risks, you're more than welcome to. However, there should be a slight barrier to enable these security risks. One shouldn't be able to accidentally enable AUR auto-installation.
Having these auto-build tools in the official repos, is the same as us giving a head-nod to all the PKGBUILDs in [unsupported]. It's like us, the developers of the core of the OS, saying "Sure, go ahead. It's fine". The problem is, it's not fine. It's a security risk that everyone should be aware of.
How are the repositories set-up? What are the restrictions on the different repositories?
The [core] repo contains the "Core of ArchLinux". That is, it contains all the packages that MUST be in perfect working order to make sure your system continues to run. These are the absolute system-critical packages. We are very picky about what packages end up in [core].
However, [extra] is much different. Extra generally contains all the extra packages that we feel an OS should support, but are not system critical. Sure, some of these packages, such as apache, may be critical to some users, they are not critical to ALL users. We try to keep the number of packages in [extra] under control, simply because we may end up with too many packages that no one has time to maintain in [extra].
The [unstable] repo contains software we want to have in extra but is too unstable at the moment. Sometimes we also officially support version-control based packages in there (at the moment, I believe [unstable] contains a svn build of mplayer).
The [testing] repo is where we test our packages before they hit core and extra. We require that all core packages spend some time in testing, so that we can ensure a working machine, but extra packages are left to the developer's discretion.
The [community] repo is managed by the Trusted Users, and the AUR users. Packages usually end up in [community] based on AUR voting, or simply if a Trusted User likes and uses the package.
Why not combine the [extra] and [community] repo?
They are managed by two different groups of users, in different ways. I have actually thought about this, but with our current infrastructure, it is impossible. One nice idea would be switching the repos to SVN, and using AuthZ based permissions to make sure that the TUs and official Developers don't overlap and fiddle with the wrong packages (a new TU editing and breaking apache, for instance, wouldn't be appretiated).
Do you know the future plans for improving pacman?
Hmm, anymore I don't spearhead the pacman development. Dan McGee is in charge of that, and he does an amazing job of it. We have a lot of active developers working on things too. As far as future developments go, I'd imagine it's more code-oriented than anything else. We'd love to see a clean and intuitive interface to libalpm (the back-end library for pacman) so that other people can more freely develop front-ends. Right now it's a tad difficult to work with.
Interview - Part III
Are you an archer? Do you use Arch on all your systems?
Absolutely. I've run Arch on every machine of mine for the past 5 years. I used to have one machine that I tried other OSes on, but due to recent hardware failure, that's running 64bit Arch now. Sadly, I just reinstalled Windows at home for the first time in 3 years. I only installed it so that I can stream movies from Netflix, as their current software is Windows only due to DRM malarkey.
Whats on the roadmap for Arch?
Hrm, the roadmap is always in flux. I have my own personal goals, but no grand lofty ideas. It's very fluid like that. Personally, things I'd love to see are support for more architectures, maybe even BSD and cygwin compatible packages. Also, better automation for building packages, and other miscellaneous repo management tools for the backend stuff would be great! Other than that, we're pretty much where I want us to be.Rolling Release System
Arch is based on a rolling release system, this means that Arch constantly updates their repositories with the latest packages available, instead of saving packages for a later release like Ubuntu does.
As a result, you will only need to install Arch Linux once and you'll always have the latest and most up-to-date packages available, as long as you use pacman to update your system once in a while.
Even though Arch is based on a rolling release system, the CD image is updated with every new kernel release. This is to remove bugs and enhance the installation. Theoretically, you can use the oldest CD image of Arch and still get an updated system like your fellow users. But it's recommended to use the newer install images.
Compared to other distributions, whats Arch Linux' greatest weakness? And what is it's greatest strength?
I had a hard time answering this question, mainly because I don't use other distros enough. But Eliott brought up a very good point when I asked him. The rolling release system has a much higher dependence on upstream releases. That is, if we push out a new library version, we need to be pretty sure that the latest release of "someapp" works fine with that version. Some app developers aren't super quick on the uptake, so it holds us back. Other distros spend weeks or months before they release new packages, so upstream versions will have changed by then, or someone will have patched things.
For someone completely new to Arch, how would you recommend he'd go about to learn the system?
Hmm. The beginner's guide in the wiki is a great place to start. If you're looking to learn the internals, the best way to do so is by reading the scripts. If you can't read script, then the best place to start is learning to read scripts.
We're not about hand-holding. If you want to learn something, you better be prepared to learn it for yourself rather than have someone sit down and explain it to you.
How do you feel about developing for Arch? Is it just for fun or is there a hidden reason behind it?
It's just for fun. In reality, I am trying to create the perfect distro to run my machines, and that just so happens to coincide with what other people wants, otherwise we wouldn't have such a great team of developers and community members.
Reading the newsletter i see someone claiming you can lift a car above your head... Is this really true!?
I have gone flabby in my old age, so I am unable to lift a car unassisted anymore. So I need at least one other person to help me, sadly.
It's a joke by the way, you shouldn't take the newsletter stuff too seriously.
And we're done. Thinking back, is there anything you wish to say which you fell you haven't been able to?
Not that I can think of, no. I'd like to thank everyone for reading this, and I hope to see some of you try Arch out in the near future.
We thank Aaron for his time and patience and wish him the best of luck on his future endevours.
