An Arch Tale

Dave needs a new 64-bit Linux for his primary audio production machine. What shall he do ? Read on to learn how and why he decided upon the Arch Linux distribution.

Why Switch ?

For about four years I've been running the excellent 64 Studio Linux distribution on my main machine here at Studio Dave. That machine - affectionately known as Big Black, thanks to the color of its Antec Sonata II case - houses an AMD64 3200 CPU, a single-core 64-bit processor that runs at 2 Ghz. It also contains 4GB RAM and a 320GB hard drive. Video is handled by an nVidia GeForce 7600 GS chipset with 512 MB video RAM, and the box's sound hardware includes an M-Audio Delta 66 digital audio interface system along with the motherboard's integrated HDA_Intel chipset. The Delta 66 is used for all serious recording on the machine, while the mobo's chipset handles audio playback for my CDs and DVDs. Altogether, a decent box, not especially up-to-date but quite sufficient for my purposes. Those purposes include various functions for my teaching business (printing lyrics, tablatures, chord charts, et cetera), most of my music composition, and the forementioned recording activities. I also use the machine for almost all my professional writing (with vi/vim, of course).

Big Black is the only machine in my studio running a pure 64-bit operating system. 64 Studio is based on Debian, with a rock-steady realtime kernel, but alas, the box has begun to show its age. That kernel is very old - version 2.6.21, ancient by today's standards - and the system's components can't keep up with the modern trends. YouTube complains that my version of Firefox is too old, I can't compile Ardour3 and other contemporary applications, but by far the worst condition is the system's failure to run the latest and greatest release of Jean-Pierre Lemoine's AVSynthesis. AVSynthesis is my preferred environment for sound and graphics composition, and for years it's been humming along nicely with 64 Studio's help. However, all things change, and indeed the requirements for AVSynthesis have recently been upgraded to the latest versions of Csound and JOGL (a Java/OpenGL combo). The Csound part is no problem - it still compiles cleanly on 64 Studio - but the latest JOGL2 has trouble with dependencies that can't be met easily or at all by the system. Given the frequency with which I work on AVSynthesis, the message was clear - I had to upgrade Big Black's operating system or risk falling behind while AVSynthesis continues to develop greater power and capabilities. So, I drove out to the local Staples, bought an on-sale 1T Seagate SATA drive, and installed it in Big Black to accommodate my new yet-to-be-selected 64-bit system.

In brief, any replacement for 64 Studio would need to be capable of handling a blend of OpenGL 3D animation and high-quality realtime audio output, without perceptible delays in either the graphics or audio performance. With this base criteria in mind I began looking at modern 64-bit Linux distributions. I'm already running a 32-bit Ubuntu system on my secondary machine, and I wanted to try a different Linux distro flavor. In the end I decided to install Arch Linux.

Why Arch ?

I'll admit that at first I was not especially eager to install an Arch system. I've happily put behind me my days of compiling system components, including kernels and graphics subsystems, and I've enjoyed the ease with which I've been able to install modern distributions such as Fedora and Ubuntu. In fact, I first installed Fedora 14 as the replacement system, and I'm pleased to report that it installed and configured itself without incident. Alas, I ran into considerable difficulty when I tried to install the latest nVidia driver for my graphics card, and in the end I decided the attempt wasn't worth the amount of time I was spending on it. Please bear in mind that my experience is no reflection on Fedora - I was trying to install a closed-source proprietary binary on an open-source operating system with a custom realtime kernel, a formula for problems if ever there was one - and I would have been happy with the system if its defaults satisifed my criteria. Unfortunately, the Nouveau video driver is not yet up to the task of the accelerated 3D I require, and it turns out that replacing the driver was a non-trivial task. Eventually I gave up on Fedora and turned to the members of the Linux Audio Users mail-list to find out what they chose for their 64-bit solutions. After considering their replies I decided to take the plunge into Arch.

Some descriptions of Arch include a disclaimer/warning to the effect that the system is not a beginner's Linux. I'm not so sure about that assessment - I was a complete Linux/UNIX novice when I installed Slackware in the mid-1990s, yet I was able to install and configure that system successfully in one afternoon, thanks mainly to its excellent documentation. As soon as I began my Arch journey I discovered a similar scenario. The instructions for installing the system are quite complete, and plenty of additional information is available on the net. Yes, there's no doubt that previous experience is a great help when installing Arch, but I believe that any reasonably thoughtful user can do it too (even without previous experience installing Slackware :).

Allow me to dispel one myth about Arch - you won't be required to compile anything you don't want to compile. When the installer informs you that you have to manually install the X window system, have no fear, it's a simple 1-or-2-click operation. In truth, installation isn't really much of a problematic area for newbies. The system configuration details pose the greater difficulty.

I won't detail here how Arch is installed, you can find all the information you need for that process on the Arch site. This article describes how I set up my system for use with AVSynthesis and its more general use as a replacement for 64 Studio. As is my usual way, I'll skip to the spoiler and tell my readers that I'm well-pleased with my new system and that I would not hesitate to recommend it for serious audio production.

The Tao Of Arch

The Arch Way is not exactly a return to the thrilling days of yesteryear's Linux installations. As I said, you won't have to compile much of anything you don't want to compile. You're welcome to build everything for yourself, but typically you'll want to employ the pacman package management system and simply download your needed binary packages. The official Arch software repositories include many standard components for setting up an audio-centric workstation, but you'll want to look into the AUR - that's the Arch User Repository - for other needed parts. A download from the AUR is not usually a package per se - it includes a script called a PKGBUILD that will automatically retrieve, build, and install your selection. PKGBUILDs are not officially supported by Arch, and the user must assume all risks, but the impression I've received so far indicates that bad packages won't last long in the community. In fact, if I understand the process correctly, a successful and popular PKGBUILD may pave the way for the package's eventual inclusion in the official repos.

As mentioned, for the novice perhaps the most disconcerting aspect of Arch is its dependence on the user's input for basic system configuration. And not just for novices, as I learned recently when I wondered why my printer connection disappeared a day after I had successfully installed and configured it for the system. Worse, I couldn't access the CUPS admin page from Firefox. After some vigorous head-scratching and a Google search I realized that I had failed to add the CUPS daemon to the list of daemons loaded during the system start-up. It's an easy fix - I added cupsd to the DAEMONS list in /etc/rc.conf, the main configuration file for Arch - but it's a bit nerve-wracking when you're accustomed to more hand-holding from a Linux distro.

Of course, the benefit from this user-centric configuration is the ability for said user to build his or her own highly-customized system. You can strip it down to a nubbin or beef it up to a fat cow of a system, it's your choice. In point of fact, it's truly your choice - the default installation is quite bare-boned and likely unusable by anyone without experience at the Linux command-line interface. However, I must again compliment the Arch community for the excellent documentation. The basic system installation instructions are thorough and clear, and to be honest, I simply had a lot of fun installing Arch. Technically, I felt that I was somewhere between that first Slackware installation and a Debian installer. I kept a Web browser open on my laptop for reference when I was uncertain about my options, but I rarely consulted it. Also, I ran through the entire installation process a couple of times before making my final decisions, a recommended practice if you have sufficient time and patience.

In my humble opinion, if you have zero knowledge of the Linux boot and system configuration procedures, or if the essential difference between /dev/sda and /dev/sdb is dark matter to you, then it's doubtful you'll feel very comfortable mucking about with those weirdly-named files in the /etc directory. On the other hand, if you're the kind of person who doesn't mind tinkering with and learning about your system's lower levels - better yet, if you already know how all that works - then you'll love setting up Arch.

Studio Dave, Studio Arch

Regarding my own Arch system (Figure 1), I'm afraid the gist of the story is something of an anti-climax. The only problems I've encountered have been troubles with system settings such as the printer configuration described above, with similar solutions (i.e. edit configuration files in /etc). I've installed development environments capable enough to build Ardour3 (GTK2), AVSynthesis (Java/Eclipse), Csound 5.13 (C/C++, Java, Python),and SuperCollider 3.5 (Qt), but I haven't been shy about using pacman. Up-to-date versions of QJackCtl, QSynth, JACK-Rack, Audacity, and mhWaveEdit are all here too, thanks to the repositories and Arch's "rolling release" policy of updates.

I've been happily surprised by the performance of the default kernel. Here's what uname -rvm reports :

3.0-ARCH #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST 2011 x86_64

I wasn't sure about that kernel version, so I ran pacman -Q linux and received this reply :

linux 3.0.4-1

So there you have it. My Arch system is running around a 3.0 Linux kernel built with the PREEMPT options, from which I get reliable 5.33 ms latency with JACK at 48 kHz when using Ardour3 or AVSynthesis. I haven't tested the system with severity, but the performance so far is remarkable for a non-realtime-patched kernel. I'll continue to monitor that performance, and I may yet decide to install a realtime-patched kernel.

Oh, about that nVidia driver: I downloaded the latest package from nVidia's site, set up Arch to boot to the command prompt, built and installed the driver with no problems, and rebooted into my new Arch system displayed with nVidia's latest driver. AVSynthesis is happy, and so am I. End of Dave's nVidia story.

A Wee Testimonial

As I write this article I've been running my Arch system for about a week. I've had some expected difficulties with a few applications, but I've experienced no system crashes. The stock kernel handles the demands of AVSynthesis without troubles (i.e. few or no xruns), though I continue to keep a close watch on QJackCtl's reports. I've migrated and updated all my familiar applications from 64 Studio, including a few that weren't able to run at all on the older system (e.g. a 64-bit build of DOSemu). My menus are completely customized with single-click launchers for all my familiar apps, and the overall impression is that this is one fast system. I've made only subjective comparisons, but Arch seems to perform as well as my trusty 64 Studio, and that's with a non-realtime versus a realtime kernel. Xfce4 feels less like a desktop such as Gnome or KDE and more like a lighweight window manager a la Fluxbox. It stays out of the way, is easy to use, and is very easy to customize.

Could I set up Fedora or Ubuntu with a similar outcome ? To some extent, I've already done it. My Ubuntu systems are highly customized, but they are not as current as my Arch installation. My 64 Studio's configuration was also personalized, the result of many years of hard daily use. Thanks to that experience I've been able to quickly configure Arch to my preferences, but I must add that Arch itself - and especially Xfce4 - makes it a simple and direct matter to customize the system to my exact specifications.

One acid test of the system will occur during the coming week, during my teaching sessions. I use the main machine extensively throughout lessons, for such activities as :

Finding tablatures and lyrics on Google.

Printing tabs, chord charts, lyrics, blank music/tab paper, etc.

Finding and watching performances on YouTube.

Listening to/watching media on CDs, DVDs, USB sticks, etc.

Recording student sessions with Ardour.

Using Audacity for its excellent Change Tempo utility.

Quickly creating MIDI tracks for accompaniments.

These activities require things like a consistently working printer setup, a steady Internet connection, a stable Web browser with the latest Flash player, support for external media devices, xrun-less audio performance with a professionally-capable hard-disk recorder, and uncomplicated control over the audio/MIDI subsystems. I'm confident that Arch is up to the tasks, and I'm looking forward to making it my default system on Studio Dave's main iron.

I like the Arch distribution. It takes a minimalist approach that Redhat/Fedora left years ago. I am looking at moving toward Arch and away from Redhat/Fedora because Fedora development has allowed their development to be compromised by developers with agendas.

If you wish an example of developer agendas, go read Leonard Poettering's website and blog which claims the goal of improving Redhat/Fedora and Linux overall...albeit by making the "internals" it much more complicated. If you have ever spent time troubleshooting the poorly documented "systemd" function then you know what I mean.

The Fedora developers could not even get migrations from FC14 to FC15 to work correctly; I should be able to upgrade/migrate and have the same things working in FC15 that were working in FC14 (a reasonable expectation), especially when those things are not called out in Release Notes as "known issues". I've opened enough cases complaining about that only to have developers respond back asking for "karma points" after they fix it; they should learn to "do it right the first time" since that gets "karma points" from me.

The Arch approach of "keeping things simple" appeals to me. Granted the older style "init" scripts setup isn't fancy, nor is the single "rc.conf" file, but both are incredibly simpler to examine, fix, and adjust compared to "systemd" and all of the other so-called improvements to Redhat/Fedora. Before anyone says Redhat/Fedora boots quicker using "systemd", I can point to an Atom 330 platform that boots Arch faster with a Linux 3.0-x kernel and "init" style scripts compared to Fedora Core 15 and "systemd" on the exact same hardware.

Now for the major hassle I find with Arch. Signing up for their forums requires the user to answer a technical question, basically a "date" command string that I cannot run on Windows and doesn't run on Fedora Core 14. I'm not sure if that shows an unintentional bias on the part of the ArchLinux "leaders" or not, but a "captcha" question would be just as effective. The answer to my email to the ArchLinux "leaders" regarding this matter should be interesting.

You are right in that the question is biased. However, dissecting the command reveals that it is just obtaining a "sha256sum" hash of a string containing the week of the year and the word 'Linux'. For example, the week ending December 4th is the 48th week of the year. Therefore, the command is just a sha256sum hash of the string '48Linux' (remove single quotes), without including the dash at the end.

Then, if you want to sign up for the forums, you can do one of two things:

1) Boot up your computer with any distro's LiveCD, pull up a terminal, and copy and paste that command, which will give you the answer they are asking for; or

2) Do a sha256sum hash of '48Linux' (removing the single quotes) and submit the signup form before this week is over, or do a hash of '49Linux' and include that in the form next week.

The answer for this week (ending Dec. 4th) is:
e31e7b0008b50c852a4ada9835c89cb80f53e8f62328daa965beec7c9eb2066e

The answer for next week (December 5th through 11th) will be:
99a6965beb8ab7aba6a38b0d92614c26ab8631e60908869a99758c9820757646

The answer for the week after that (December 12th through 18th) will be:
01c2088b078e1ed9eb81eef9206ea23a155bf3c1919a6ef9519d86448ee9ed56

Arch really seems great! As a long time OpenBSD user I see a lot of similarities between Arch and OpenBSD philosophy.

Both
* are really focused on original goals
* have minimalistic base install and are therefore versatile
* have great ports/packages systems
* have strong focus on simplicity under the hood
* have have a usable high quality "current" branch
* rely on very good documentation which allow users to solve problems
on their own
* have features off by default
* have strong focus on code quality

OpenBSD may even have some extra benefits in some areas
* A very high focus on security
* A very high focus on software freedom
* Support for many hardware architectures
* OpenBSD regularly (twice a year) build CD releases of very high
quality

While Arch have some advantages on their own
* Cutting edge software
* A huge package repositry

I think both OS'es well deserve some more light in the general public
outside its current communities of already initiated people.

Thanks for the reminder. My apologies to the maintainers of Arch Pro Audio, I should have mentioned the project in the article. Readers should be sure to check it out. Also, be sure to check out the various contributions from Bernardo Barros. Impressive useful stuff. Arch is lucky to have him around (and so is the SuperCollider3 project :).

Debian may have branches that can be used like a rolling release, but it is not a rolling release model per se, that's not what it was intended for. All these channels are for testing purposes to ultimately get another stable release out. No more, no less. Otherwise you could as well call Slackware a rolling distro just because they also have a Slackware-Current branch, and some people run that.

IME Arch is the only distribution where rolling release actually works and does not break stuff all the time. Just tried Sabayon and it effed up after just a few days.

Welcome to Arch! I've been using it for about a year, and have only had a few issues after major upgrades. These have always been fixed very quickly. As a former RedHat, Gentoo, Slackware, and Ubuntu user, I've found a home on Arch. I do a lot of the same things you do with it, so I think you'll find it works very well. I've been amazed at the stability of the system. I would say I've had no more issues that I had with Ubuntu, and the issues I have had were easier to resolve. Plus I don't have to chase PPA's to keep applications up to date.

+1 for packer, however I use it with --auronly. I use pacman for the main repo's. I've run into a few issues where packer gets confused when pacman makes certain changes.

WTF are you guys talkin' about? This distro is good, that distro is bad. Don't you learn anything from the free open source software? The kernel is linux, the os is GNU/Linux.
Debian and Arch both are good distro, the bad thing is you guys can't keep your mouth shut.

Debian Sid is rolling release, Arch is rolling release. You want to know what is not rolling release? It was OO-BOON-TOO. Got it!!!! So shut up! I don't care if you say Window$ SUCK!!!! But don't you ever said GNU/Linux suck. Except for non rolling distro. Muahahahahhahaahaha

"Oh, about that nVidia driver: I downloaded the latest package from nVidia's site, set up Arch to boot to the command prompt, built and installed the driver with no problems, and rebooted into my new Arch system displayed with nVidia's latest driver."

That is a bad idea. The nvidia installer replaces files in your system that belong to other packages - and those replacements are not tracked by pacman. System upgrades will revert those changes and thus will break the system in all kinds of mysterious ways - among other things, it will replace libGL.so and put files in some folder /usr/lib/tls/ (at least it did some years ago) - people have raged about breakage resulting from that. There is a package in the repositories for nvidia with the latest driver, and there are several AUR packages for different versions of it. Using those packages will save you lots of future trouble.

Concerning the flash player: Until today, we had nspluginwrapper and a 32 bit version of flashplayer (resulting in tons of 32 bit libraries to be installed). Now, the new native 64 bit version is in the repositories.

A fair question, and the answer isn't complicated: I didn't realize how the system worked at that point. Were I to start over I'd probably do as you suggest, with the proviso that the driver I get is the absolute latest & greatest, not one that's two or three releases behind what's available on the nVidia site. If I now understand the Arch system correctly I will indeed get the latest driver, but I'd like to have someone verify that. Btw, I'm using release 285.03, from nVidia.

You _could_ revert to the previous version of the problematic package and pacman would take care of the dependencies. The fact that this is a rolling distro doesn't necessarily mean that preventing a couple of packages from updating will become an issue. You downgrade the package with pacman, and blacklist it until it gets fixed. The rest of the system gets updates, so you aren't trapped. I'm currently doing this with chromium.

Sorry to make you sad tommy but your old daddy debian isn't rolling release, there is a branch for testing and other for experimental, but those branches are not always up to date as Arch see you had 3.0.0 kernel on SID we have 3.0.6 on Arch, sorry but you're too slow even with a bunch of suckers like Debian Developers.

Plus, rewritting pacman aliases make you a debian-nonsense lover like all of you, haha .. you really think -Syu is so complicated? well gramatically I think apt-get remove is (download + remove) which is a high failure, not that apt is doing that but I cannot type a command like "print" and expect an screensaver?

sorry anonymous, Debian has a stable branch, testing branch, unstable branch, and experimental. Debian's unstable is a rolling release. Sometimes is better to keep your mouth shut and be thought a fool, rather than open your mouth and leave no doubt.

64 Studio is based on Debian, with a rock-steady realtime kernel, but alas, the box has begun to show its age. That kernel is very old - version 2.6.21, ancient by today's standards - and the system's components can't keep up with the modern trends.

Really? No, the latest kernel version with Squeeze is 2.6.32. Sid kernel version is 3.0.0. So if you kept your system up to date with the latest updates you would have an "ancient" kernel. You'll have to do that with Arch too, or before you know it you'll have an "ancient" kernel there too.

It's great you like Arch, but I have to laugh at this whole "rolling release" marketing nonsense. Debian has been a "rolling release" for way longer than Arch. And if you want the latest software and can't wait for the stable releases, use Sid.

The first thing I would do with Arch is make a bunch of aliases and get away from the pacman -e-i-e-i-o crap. pacman -update, pacman dist-upgrade. Much better.

Hi Dave,
First of all, I am glad you found your new linux distro. I have been using Arch for several months now (switched from Ubuntu when they introduced Unity). In most cases I am very happy with it. Throughout the time I have experienced only one major issue, which made me switch to Fedora temporarily.

As you mentioned, Arch runs on rolling release updates - that is great but sometimes pretty painful too. In my case I installed bunch of updates that made my Gnome 3 very unstable. In fact, any kind of flash video killed gnome-session. I tried old flash (32bit), 64bit preview version and even the one integrated to Google Chrome. Even though I knew what was causing issues I couldn't revert to an older version - it is a rolling release distro. I ended up being trapped and had to wait for this issue to get fixed. For this reason I installed VirtualBox and copied a DD clone of my Arch to it. Now I test the virtual environment first before I apply patches to underlying system.

One Arch-beginners advice for you (the one I would have loved to hear at my beginner's stage): take a look at "packer" (AUR). Short story, packer works with both Arch repos and AUR - it resolves dependencies and makes whole AUR easily accessible. No more makepkg -src ;)

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.