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)?
There are two huge disadvantages:
- 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.
- 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.
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.
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.
Arch Linux is a rolling release. That’s good, and I noticed no disadvantage.
Let’s clarify something first. We have the latest and newest stable version of
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.
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.
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.
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?
Do we need any?
Yes. Improved support for running test suites. Splitting debug symbols into
separate packages. The way VCS packages are handled needs an overhaul.
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. 🙂
The overall format of PKGBUILD is good as it is now, but improvements are always
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?
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.
The developers being awesome.
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
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.
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.
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.
We look sexy.
What does the future of pacman hold? Where is development currently going?
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.