This year the Arch Linux conference took place online. At the beginning, well-known maintainers presented future plans for the distribution.
What can Arch Linux do do better than other Linux distributions? At the first talk of the Arch Conf 2020, which took place online last weekend, the leading heads of the project devoted themselves to this very question. Arch Linux project manager Levente Polyak got colleagues and users in the mood for changes in the development of Arch Linux and within the distribution, some of which are already being implemented or even completed.
In Arch development , according to Polyak, a standardization of the project tools, which are currently very different and in some cases very outdated, is necessary. A self-hosted Gitlab instance should ensure order. In addition, a modernization of the maintenance of the official packages is in progress, and an optimization of finished packages for selected processors within the supported architectures should improve performance.
Packages: Optimization and faster updates
In the last 19 years, Arch Linux has developed from a small “Linux from Scratch” variant plus package manager to a distribution that is particularly appreciated by advanced Linux enthusiasts. According to the consensus of the developers, the official branch of Arch Linux has become a mainstream distribution in recent years and lost some of its strengths in niches.
According to Polyak, Arch Linux should regain advantages of yesteryear. This includes the optimization of kernels and software packages with the help of compiler flags for modern processors. The official Arch Linux currently cannot offer this property, especially since the packages in the official repositories must not become incompatible with individual processor architectures. The Arch developers therefore want to set up and maintain repositories with optimized builds within the official package sources in order to get more performance out of the respective architecture.
Arch Linux is generally considered a rolling release, which releases its packages comparatively quickly Updated upstream source code. However, this is not true in every case, with all packages. Some components then wait up to a few weeks for an update that is overdue by then. Until now, it has been the task of the individual maintainer to track and incorporate upstream changes. Some can no longer keep up or miss important versions. A rough example is the C++ Boost library, which has been waiting for an update for at least three months.
The internal project “Sandcrawler” should help in the future to mark obsolete packages in Arch repositories when new versions are available on the respective project websites on the web. The source code management of the packages, which for historical reasons runs on Apache Subversion (SVN) in Arch Linux, is also to be improved. The developers have been dissatisfied with this for a long time and are currently migrating everything to Git, which in turn has the advantage of being able to better integrate related services such as bug and patch trackers.
Developer tools: Moving ahead
Meanwhile the infrastructure around Arch Linux suffers from a “bloat” too many different services, servers and solutions. This fragmentation can be seen particularly clearly in Arch Linux’s 15 public services: the popular Arch Wiki is organized as a Mediawiki, the mailing lists are managed by GNU Mailman, the bug tracker is based on the PHP project “Flyspray” and the forum bbs.archlinux.org even runs on an outdated version of FluxBB that no longer gets updates. In order to create order, a self-hosted Gitlab will serve as the central platform for Arch Linux in the future. The move is already in full swing and, if successful, should also attract external maintainers of community packages.
The entire talk on the future of Arch Linux is linked as a recorded stream in the CCC Video Operation Center and will be posted later published in Arch Linux’s own archive as an MP4 file.