Arch, a recap

One of the things, that has kept me (increasingly) busy over the past few years is my involvement with the Linux distribution Arch Linux. While I have been using Linux for probably about 14 years it is frankly hard to pinpoint when exactly I went down the rabbit hole that this operating system/ ecosystem/ community is (relevant XKCD). However, I can elaborate on my motivation and where that got me.

As a musician of a varying background (from band-based rock music to solo performances on guitar or with a modular synthesizer) I have found myself evaluating the available pieces of software that are commonly used in music production (e.g. Digital Audio Workstations (DAWs) and audio plugin-ins). Most of them are proprietary and only available for Windows or macOS (both proprietary as well). During my studies a lot of the software in use has also not been free, but was provided by the university with a student discount (e.g. Operating Systems (OSes), Integrated Development Environments (IDEs) or certain types of Visual Programming Languages (VPLs)). I got increasingly annoyed by dealing with intransparent proprietary OSes, vendor lock-in schemes, paying for software updates and being driven into software piracy for working with so-called industry standards.

Some time during the studies for my B.Sc. I decided to "try out Linux", not knowing what that would mean actually. So there I was, booting an Ubuntu Live CD and clicking around in an interface, that would install the OS alongside a still existing Windows 7. At that point I did not yet know about the joys of missing or failing device drivers. Many hard fights with the X Window System later I settled on Ubuntu Studio for a while, as it had many nice audio related pieces of software available out-of-the-box.

I have always been a person that is interested in "how things work". Soon I realized, that the Linux ecosystem consisted of people that thought quite similarly. Through various (often distribution specific) online documentation, forums, mailing lists and the documentation of software projects for the first time I felt as if I could actually learn something that mattered, because it was not sold in a box and instead had a community of like-minded people gathering around it. I found quite appealing that a lot of things were not polished and that some things were not easy, because it provided the sense of achieving something or getting good at something. Where in Windows land I would have reinstalled the OS upon getting intermittent bluescreens, in Linux land I just kept reading about a certain topic until I was able to fix it myself.

Probably a year after dipping my toes into Linux I bought a new laptop (my previous one decided to commit suicide by desoldering its GPU). At that time it seemed like a good idea to not dual-boot anymore, as apart from an occasional game session I was not using Windows anymore. Due to a friend of one of my fellow students I got introduced to Arch Linux, which that person used in a (to me) bizarrely minimal fashion by booting from a USB stick, as the hard drive in his laptop was broken.

After installing Arch Linux for the first time (probably around 2008) I realized quite early on that I would rather continue using it instead of Ubuntu Studio, which by that time had given me many issues due to unclear configuration management, documentation and graphics driver handling. The Arch Wiki already back then was an excellent source of knowledge (and still is to this day). Although some articles lack structure or are sometimes outdated, it is this trove of knowledge that I had been missing with less hands-on distributions up to then. The AUR offered an entrypoint for me to understand how distribution package management works and how to build my own packages, that I could install using the pacman package manager. This new found knowledge made me realize how inefficient my work on Windows had been in the past (a realization that had not fully dawned upon me on Ubuntu Studio as their update model follows a certain cadence in which new versions of softwares are updated and otherwise only gain bugfix releases). I was suddenly enabled to build packages myself of software that I liked and used and I was able to alter existing packages to e.g. fix problems or to extend their functionality. I was enabled to upgrade my entire system with a single command, while on Windows I had to scavenge websites to download installers and run those without knowing whether they were compatible.

As my main focus shifted even further towards pro-audio applications, DSP languages and recording practices with my M.Sc., I of course do have to mention the accumulation of knowledge that Linux Audio represents (e.g. with the Linux Audio Wiki). It is an invaluable, although by now partially outdated and not actively maintained point of - often distribution agnostic - information on all things audio on Linux. This ecosystem is what drove and/ or documented the development and use of many of the projects at the center of what it means to achieve low-latency audio on Linux such as JACK.

After 2011 I started to conceptualize the Arch Linux distribution also as a social construct, that relies on individuals to develop and change it (by getting involved). While Arch is a distribution that can be used for many purposes, the lack of structure or features in e.g. the pro-audio section was apparent (although partially covered by packages in the AUR). I was able to do most of the projects I was working on at that time using SuperCollider but sometimes ran into issues that e.g. Ubuntu Studio had solved in a distribution specific way (e.g. by providing packages for the realtime kernel to achieve very low latencies while recording).

Around 2017 it became apparent that many of the packages that I was using on a day-to-day basis were starting to fall behind on updates or had not been updated in a long time. It turned out that two packagers that had been active packaging audio related software were missing in action or were extremely unresponsive. I realized, that unlike a company supported endeavor, Arch Linux was a community driven effort and as such required help.

At the time of writing, Arch Linux consists of Developers, Trusted Users and Support Staff. While the first group somewhat defines the direction of the distribution itself and takes care of the most centric package repositories ([core] and [extra]), the second group historically has been an additional group of packagers that takes care of the [community] repository and the AUR and the last group is keeping a lot of the infrastructure (e.g. wiki, forums, mailing lists, IRC channels, servers, hosted applications) alive.

For outsiders it is possible to join the Support Staff by starting to help maintain infrastructure together with the existing staff. When looking at the Trusted Users group the barrier of entry is a bit higher, as the person gains access to package repositories that are used by thousands of users. As such newcomers have to follow a vetting process and be sponsored by existing group members (this is similar, but much less clearly defined, for Developers).

At the end of 2017 I was able to apply as Trusted User with the help of Ray Rashif, who had been maintaining the packages I wanted to help improve and update.

Admittedly, the application process has been a bit daunting at the time, but it also made me realize, how much I could still improve my package scripts and the amount of work that is sometimes required to get things right.

Since becoming a Trusted User in 2017 I have added many new packages in the context of a pro-audio package group and spent time on various other packaging areas as well. In 2019 I have been promoted to Developer and spent some more time on non-packaging topics on the side, such as infrastructure improvements (releng, arch-release-promotion and arch-repo-management), installation medium (archiso) and various community related topics (setting up an RFC process and help holding Arch Linux Conferences).

I will follow up on packaging and best practices in an upcoming article (hopefully in the not so distant future) and shed some light on the non-packaging topics in further articles as well.

That's it for now! I hope you enjoyed reading a user story, that eventually led to getting more involved with an international community of (very talented) developers working on a challenging project with many facets. As you can imagine there are always many more stories to tell, but I tried to give a general overview. Maybe I could even get someone interested in reaching out and lending a hand in further developing this amazing beast that is Arch Linux :-)