Es gibt keine „festen“ Releases wie „Version 4.1“ oder ähnlich. Stattdessen werden Pakete (im Kernsystem und Userland) aktualisiert, sobald seitens Upstream neue Versionen verfügbar sind. Das passiert in der Regel zeitnah, kann aber auch eine Weile dauern, zum Beispiel weil Pakete nur von sehr wenigen Benutzern in Gebrauch sind oder weil es gravierende Probleme mit der neuen Version gibt und sie deshalb aufgeschoben wird.
„Rolling releases“ haben zur Folge, dass es häufig kleine Updates gibt anstatt selten große Updates. Das macht es einfacher, das System zu warten, da es – falls es zu Problemen kommt – nur eine überschaubare Anzahl an Paketen betrifft. Bei „major releases“ gängiger Distributionen hingegen ist man im Zweifelsfall mit vielen Problemen gleichzeitig konfrontiert.
In der Regel ist die Software aktueller und auch nicht-sicherheitsrelevante Bugfixes seitens Upstream kommen zügiger bei Arch an. Arch enthält keine Beta- oder Alpha-Versionen, sondern normalerweise „stable releases“. Diese Klassifizierung wird aber von den Upstream-Entwicklern vorgenommen, es finden Arch-intern keine großflächigen Tests statt, die viel Zeit in Anspruch nehmen. Durch diese Aktualität ist Arch „bleeding edge“ und eine ausgesprochen gute Spielwiese. Aber:
Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
– Griemak
„Simple“ bezieht sich auf den technischen Aufbau, nicht zwangsläufig auf die Benutzung. Arch versteckt nur sehr wenig vor dem Benutzer, sodass man gezwungen ist, sich mit dem System auseinanderzusetzen. Dadurch lernt man insbesondere am Anfang viel dazu. Auf lange Sicht gewinnt jedoch man eine sehr gute Übersicht über das System. Gibt es Probleme, kann man besser auf sie reagieren, da man weiß, an welchen Stellen man ansetzen muss. Unterstützt wird das dadurch, dass sich Arch selbst im Hintergrund hält und dem Benutzer so wenig wie möglich in die Quere kommen möchte.
Pakete in Arch orientieren sich möglichst nah an den Upstream-Paketen: Zusätzliche Patches gibt es nur selten. Das vereinfacht Fehlersuchen und das Erstellen von Bugreports. Ferner kann man davon ausgehen, dass sich Pakete so verhalten, wie von den Upstream-Entwicklern vorgesehen. Es gibt keine Änderungen an Paketen, damit diese besser zur Arch-Philosophie passen.
Es gibt nur eine geringe Vorauswahl an Paketen, sodass man nach der Installation immer ein „nacktes“ System hat. Man installiert dann hinzu, was man benötigt – anstatt zu löschen, was man nicht benötigt. Was man installieren möchte, ist einem selbst überlassen. Die Arch-Entwickler versuchen auch darauf zu achten, keine unnötigen Abhängigkeiten zwischen den Paketen zu erzeugen.
Dieser Ansatz setzt voraus, dass der Benutzer „kompetent“ ist. Damit ist weniger großes Vorwissen gemeint als vielmehr Selbstständigkeit und die Bereitschaft, existierende Dokumentation zu lesen und neues hinzuzulernen.
Ein Paket für Arch erstellt man durch das Schreiben einer
einzigen Datei. Im sogenannten PKGBUILD sind alle
notwendigen Informationen enthalten: Wo im Internet liegt der
Quellcode, wie wird dieser kompiliert, wie wird er paketiert,
welche Abhängigkeiten gibt es und so weiter. Durch die Eingabe
eines einzelnen Befehls (makepkg) wird das Paket
erstellt.
PKGBUILDs sind generisch genug, um mit jedem
Build-System zurechtzukommen: make,
scons, ant oder was auch immer. Auch
kann Quellcode nicht nur über HTTP oder FTP heruntergeladen
werden, sondern auch direkt aus Versionskontrollsystemen wie
Git, Mercurial oder Subversion.
Dennoch ist Arch eine Binärdistribution. Man kann
Software an die eigenen Bedürfnisse anpassen, muss es aber
nicht. Will man das tun, so kann man sich über
rsync die PKGBUILDs aller offizieller
Pakete herunterladen, die entsprechenden Anpassungen vornehmen
und sich die Pakete selbst neu bauen.
Hinter Arch steht keine Firma, die gesamte Distribution wird von Freiwilligen entwickelt. Dadurch erreicht man ein hohes Maß an Unabhängigkeit und setzt sich nicht selbst unter Druck. Dinge sind fertig, wenn sie eben fertig sind. Es gibt keinen Anlass, durch besondere Features oder Eigenheiten aus der Masse hervorzustechen. Es müssen keine wirtschaftlichen Ziele zu einem bestimmten Zeitpunkt erreicht sein.
Die Entwicklung läuft transparent und vergleichsweise überschaubar ab. Man kann auf den Mailinglisten verfolgen, weshalb welche Entscheidungen getroffen wurden. Dabei hält sich die Zahl der Mails pro Tag in Grenzen, sodass man nicht überschwemmt wird, aber dennoch über bevorstehende Änderungen Bescheid weiß.
Man muss sich jedoch auch darüber im Klaren sein, dass die Arch-Entwickler dies in ihrer Freizeit tun und zwar für ihren Eigenbedarf. Arch ist – wie die meisten freien Projekte – keine Demokratie. Erwarte nicht, dass die Entwickler auf dich als Einzelperson bei kritischen Entscheidungen Rücksicht nehmen.