What part of the Arch Linux development is the most active?
Definitely the package update monkeys.
Packaging is by far the most active part, followed closely by Pacman
Hmmm. Packaging, packaging and packaging.
Ronald van Haren:
I suppose that is the packaging part. Also, pacman development if fairly active
Definitely packaging. Our commit list is a great use case to benchmark your
mail server. 😉
But let’s not forget about our pacman development team. I guess of our “real”
coding projects, this is the most active one.
What part of Arch Linux is most active: packaging.
What part of Arch Linux development is most active: I’m actually not sure.
This is one issue I am a bit sore on. I tend to think we have a lot of
packagers that do a good job at what they do, but we don’t do enough
development because that is taking up a lot of our time. We could use a lot
more effort in automating some of the mundane packaging process and even doing
automatic rebuilds of [core] or [extra] every so often (something like Gentoo’s
Someone mentioned “packaging” already?
What do you like least about Arch Linux?
Are you implying that there is anything I dislike?
Things that break. Especially breakages for packages that are
infrequently used on Arch are a pain because you’re on your own.
But every distro has breakages, and in Arch it’s just easier to
Users. At least the demanding ones…
Hmm, tough one. What I like the least isn’t really Arch specific. I dislike how
intertwined all the system components of a basic Linux system are becoming.
Take, for instance, the Xorg dependence on hal. Xorg needs hal to auto-detect
new keyboards and mice that are plugged in. Sounds ideal, but this has always
worked for me in the past without hal. It seems like hal is necessary to cover
the edge cases, but this also makes the common cases more unwieldy. This is
contrary to the basics of Arch – the common case should be simple.
Nothing. Things that I dislike are about upstream decisions.
Arch Linux tries to stay focused, but every once in a while things fail. As for
Linux in general, the entire hal -> (whatever)-kit -> permission handling chain
becomes a nightmare. Not only does it fail to deliver that targeted
functionality, but it keeps changing. And as by evidence of what Fedora had tried
(allowing users to install packages), it becomes a security nightmare, too. For
the sake of (questionable) comfort headin’ down the Windows road. Leaves me
uneasy about it, very!
Ronald van Haren:
It’s name is suboptimal for promotion in German speaking countries.
Seriously, there a lot of things to improve, but I cannot name one that really
I think that we need more users testing the system and reporting bugs. There
are some packages, for example, that stay on [testing] for some time, but the
users do not test it and we just find the problems when the package is moved
to the main repos (core/extra).
Have you ever considered building hardened system/packages and/or using grsecurity patched kernel?
Thomas BÃ¤chler, Giovanni Scafora, Ionut Biru, Ronald van Haren:
No. The need is obviously not there given no community projects have really started the job.
As stated before, Arch tries to provide a base system for others to add on to.
If hardened/grsecurity stuff is needed, it’s trivial for someone else to
provide a pacman repo with packages that do this. If it becomes popular enough,
it could always get integrated into the core Arch system.
No, I am still fine with a vanilla kernel, and I believe in sane and secure
configuration and, of course, regular updates.
Dan McGee:Questions like this come up a lot. Community projects get announced on the BBS
and then…nothing. Everything starts with the community getting the ball
rolling, and for the last 3 years I’ve seen this ball go nowhere.
Where is development primarily focused for the Arch Linux team (the installation, pacman, etc)?
Aye, most work and time is spent packaging. It’s a thankless job. Myself,
though, I tend to (try to) work on some of the internal tools no one really
sees, such as the scripts which manage our repos, the tools that build our
installation ISO, and things like that.