posted by Jordan Spencer Cunningham on Mon 11th Jan 2010 15:57 UTC

Arch Linux Team, 4/6
One of the most notable characteristics of Arch is its rolling release model, which assures users that they will always have the latest and newest version of a program available. Has this model brought any noticeable disadvantages (for example: programs that depend on older libraries who aren't on the system anymore because of an update)?

Thomas Bächler: There are two huge disadvantages:
  1. Library updates break ABI and API compatibility. In the former case, we have to do mass rebuilds in our testing repositories so everything is compatible again in the end. In the latter case, the same is necessary, but we also have to find or write patches for many applications. This is not a big problem, but has to be done right.
  2. Hardware incompatibility: There are 2 candidates that keep breaking people's computers: Linux and Xorg. As a current example, many ATI cards are barely usable on Arch right now - that will hopefully improve with the release of 2.6.32, but I am sure something else will break.

Allan McRae: Rebuilds for library, so namebumps are the biggest issue, but the rebuild process for Arch is quite streamlined. Because we try to have the latest versions of packages, we often run into issues that have not been encountered before, which requires working with upstream to find and patch the problem code.

Aaron Griffin: The biggest problem with the rolling release model is laziness - from upstream developers and Arch users. We try to stay up to date wherever possible, but some upstream developers are slow at adopting new changes. This means we need to do extra work to make their software compatible with new library versions and things of that nature. On the user end, you get people who don't regularly update their system (something we indicate as very important), and you end up with newer software and older libraries on the same system, causing breakages.

Giovanni Scafora: Arch Linux is a rolling release. That's good, and I noticed no disadvantage.

Ionut Biru: Let's clarify something first. We have the latest and newest stable version of a program.

Having that from time to time, we have to rebuild a lot of applications and sometimes we have to patch and collaborate with upstream developers. Because we are early adopters of all, new users have to suffer sometimes. xorg and drivers rewrite is one example.

Tobias Kieslich: It's a two-side sword. It sure is a pain in the neck to recompile half of the distro for an ABI incompatible ssl update. On the other hand, it reveals bugs and keeps the packages up to date. For what Arch is and for what most people use it, I think the rolling release is surely benficial.

Ronald van Haren: It requires a lot of rebuilding for some particular updates and sometimes a not-so-widely used package is missed, but I think we are on average very quick in fixing these things. As we require signoffs from other developers before we move important stuff to core, it is highly unlikely that this happens to one of the system's core packages.

Pierre Schmitz: The most notable disadvantage of running the latest software is seeing bugs and problems no one else has discovered before. But fortunately new versions of software generally fix more bugs than they introduce.

But serious regressions are really rare as we test important packages before they are moved to our [core] repository.

But as an Arch user, one should be able to debug simple problems and shouldn't be scared of the command line.

Dan McGee: We encounter quite a few first adopter hurdles when rebuilding packages. This is especially true when building a core library that involves rebuilds of several packages that often require some patching to be compatible with a newer version of the library.

Arch uses the PKGBUILD system to make and compile packages. What does the future hold in store for the PKGBUILD system? Are there any new features or modifications that are planned?

Dieter Plaetinck: Do we need any?

Allan McRae: Yes. Improved support for running test suites. Splitting debug symbols into separate packages. The way VCS packages are handled needs an overhaul.

Aaron Griffin: I'll defer to Allan here. Suffice to say that things are always in flux and always improving. That's the way we do things. Short answer: Yes. :)

Ionut Biru: The overall format of PKGBUILD is good as it is now, but improvements are always welcomed.

Tobias Kieslich: I think that we can roll separate packages from a single build now is a big plus. It allows for smaller packages, lesser dependencies.

Arch Linux has steadily grown in user-base while still holding true to the simple DIY design. Without holding people's hands, Arch is growing and growing. What do you attribute this to?

Thomas Bächler: Arch works. It's that simple. One reason is its simple design, the other is that its users are required to know and understand their system - and we make it easy for everyone to understand it.

The Arch Linux community is very strong and friendly and communicates a lot. We have a very active BBS and probably the most active IRC channel I have ever seen. And this community isn't just a bunch of dumb idiots, but our average community member is smart and knows his/her way around Linux and Arch.

Another reason might be that our users want to get their share when we finally succeed in our evil and secret world domination plans.

Allan McRae: The developers being awesome.

Aaron Griffin: I think that people are getting tired of Linux distros trying to be more Windows-like. People see all this automation with 100 links in the chain, only to see one link fail and bring the whole thing crashing down around them. With Arch, they gain awareness of the whole chain, not just the tail end that they see.

Ionut Biru: I think because we have a rolling release model, because we have the latest stable version of application and because it is simple to use. The community has a big role because it is friendly and helpful with all new comers.

Tobias Kieslich: A nice and helpful community. I think people take pride in explaining things and not throwing a RTFM on new user just because they can. On the other end of that, stick people become more curious about the abilities of Linux and are willing to try and learn.

Pierre Schmitz: At first, I am quite sure that Arch's growth is limited. Most people don't care what goes on behind the scene of their operating system or even want to control every single bit of it. And don't get me wrong, that is perfectly fine.

One of our strengths is that, while evolving on all levels, we still try hard to keep it simple. This makes it easy for new users to build their own packages and understand the way how are things done in Arch.

Hugo Doria: We look sexy.

What does the future of pacman hold? Where is development currently going?

Allan McRae: http://wiki.archlinux.org/index.php/Pacman_Roadmap

Dan McGee: Signed packages are super important and are targeted for the next major pacman release. Besides that, alternative compression methods, deltas, and an improved database interface are large features that may find their way into the code in the next year.

Table of contents
  1. Arch Linux Team, 1/6
  2. Arch Linux Team, 2/6
  3. Arch Linux Team, 3/6
  4. Arch Linux Team, 4/6
  5. Arch Linux Team, 5/6
  6. Arch Linux Team, 6/6
e p (12)    61 Comment(s)

Technology White Papers

See More