Debian vs Arch 2026: Stable gegen Rolling Release — mit selbst gezählten Paketen

Debian vs Arch ist der ehrlichste Distributionsvergleich, den man führen kann — weil beide Projekte dieselbe Frage stellen und zwei entgegengesetzte Antworten geben: Wann darf sich Software auf meinem System verändern? Debian sagt: alle zwei Jahre, und dazwischen nur für Sicherheitsfixes. Arch sagt: immer, sobald es fertig ist.

Alles andere — Pacman gegen APT, AUR gegen contrib, Installer gegen archinstall, „minimal” gegen „vollständig” — folgt aus dieser einen Entscheidung. Wer sie versteht, braucht keine Feature-Tabelle mehr.

Dieser Artikel ist kein Adjektiv-Vergleich. Wir haben für Debian vs Arch im August 2026 beide Paketarchive selbst heruntergeladen und ausgezählt — dieselbe Methode wie in unserem Debian vs Ubuntu-Vergleich. Dazu haben wir die Build-Zeitstempel jedes einzelnen Arch-Pakets ausgewertet, die Arch-Nachrichten der letzten fünf Jahre auf „manual intervention” durchgezählt und die Sicherheits-Tracker beider Projekte gegeneinander gehalten. Die Zahlen sagen etwas Anderes als die Foren.

Die Kurzfassung für Eilige

Die Ein-Satz-Antwort: Debian, wenn die Maschine in drei Jahren noch genauso laufen soll wie heute. Arch, wenn du willst, dass sie heute läuft wie das Upstream-Projekt es gerade veröffentlicht hat — und bereit bist, dafür regelmäßig hinzuschauen.

Das Release-Modell ist der ganze Unterschied

Bevor es um Zahlen geht, muss der Mechanismus klar sein — sonst liest man die Zahlen falsch.

Debian: einfrieren, testen, ausliefern

Debian pflegt gleichzeitig drei Zweige. In unstable (sid) landet alles Neue. Pakete wandern nach einer Wartezeit ohne kritische Fehler automatisch nach testing. Vor einem Release wird testing eingefroren: Es kommt nichts Neues mehr rein, nur noch Fehlerkorrekturen. Wenn die release-kritischen Fehler abgearbeitet sind, wird aus testing das neue stable.

Danach passiert mit den Versionsnummern in stable nichts mehr. Debian 13 wurde am 9. August 2025 veröffentlicht; die aktuelle Punktfassung 13.6 vom 11. Juli 2026 enthält Sicherheits- und Fehlerkorrekturen, aber keine neuen Programmversionen. Wer im August 2026 nginx installiert, bekommt dieselbe Hauptversion wie im August 2025 — mit rückportierten Sicherheitsfixes.

Das ist der Kern von „stable”: Es bedeutet nicht „stürzt nicht ab”. Es bedeutet „verändert sich nicht”.

Arch: fertig ist fertig

Arch hat kein Einfrieren, kein Release und keine Versionsnummer. Ein Paket wird gebaut, sobald das Upstream-Projekt eine neue Fassung veröffentlicht und ein Paketbetreuer sie durchgereicht hat. Es gibt kein „Arch 2026” — es gibt nur den Stand von heute.

Die ISO-Abbilder tragen zwar ein Datum (archlinux-2026.08.01-x86_64.iso), aber das ist reine Installationshilfe. Nach dem ersten pacman -Syu ist jedes Arch-System auf demselben Stand, egal von welcher ISO es kam.

Warum das die einzig wichtige Frage ist

Alle praktischen Unterschiede lassen sich aus diesen zwei Absätzen ableiten:

• Debian kann Paketversionen garantieren, weil sie sich nicht ändern. Arch kann das nicht.
• Arch kann aktuelle Software liefern, weil nichts sie zurückhält. Debian kann das nicht.
• Debian braucht Rückportierung von Sicherheitsfixes in alte Versionen. Arch behebt Lücken durch das nächste Upstream-Release.
• Debian-Upgrades sind selten und groß. Arch-Upgrades sind häufig und klein — was in Summe nicht weniger Arbeit ist, sondern anders verteilte.

Der letzte Punkt wird am häufigsten falsch verstanden, und wir kommen weiter unten mit Zahlen darauf zurück.

Wir haben die Paketarchive selbst ausgezählt

Zu Debian vs Arch kursiert eine hartnäckige Behauptung: Arch habe „mehr Software”. Das lässt sich prüfen, statt es zu glauben — und das Ergebnis dreht die Aussage um, allerdings nicht so, wie Debian-Fans hoffen.

Wir haben am 26.08.2026 die Paketindizes beider Distributionen heruntergeladen und die Einträge gezählt: bei Debian die Packages.xz-Dateien aller Komponenten von deb.debian.org, bei Arch die Datenbanken core.db, extra.db und multilib.db von geo.mirror.pkgbuild.com.

Methodik: Debian-Packages.xz je Komponente von deb.debian.org/debian/dists/stable/, ^Package:-Zeilen gezählt, Architektur amd64. Arch-Datenbanken entpackt und Verzeichniseinträge gezählt (ein Verzeichnis = ein Paket). AUR-Liste von aur.archlinux.org/packages.gz, Kommentarzeilen abgezogen. Stand jeweils 26.08.2026.

Debian liefert 4,5-mal so viele fertig gebaute Pakete wie Arch. Das ist kein Randbefund — es ist der wichtigste Zahlenunterschied des ganzen Vergleichs, und er wird fast nie genannt.

Warum die Arch-Zahl trotzdem nicht die ganze Wahrheit ist

15.400 gegen 69.843 klingt vernichtend, ist aber irreführend, wenn man zwei Dinge nicht dazusagt.

Erstens: Debian splittet, Arch nicht. Debian zerlegt eine Software regelmäßig in mehrere Binärpakete — libfoo, libfoo-dev, libfoo-doc, libfoo-dbg, dazu Sprachpakete. Arch schnürt dasselbe Projekt meist in ein einziges Paket. Ein realistischerer Vergleich ist deshalb der gegen Debians Quellpakete: Davon hat Debian 13 in main 37.633. Das Verhältnis schrumpft damit von 4,5:1 auf etwa 2,4:1 — bleibt aber ein deutlicher Vorsprung für Debian.

Zweitens: Das AUR ist der eigentliche Katalog. Mit 118.172 Einträgen ist das Arch User Repository fast doppelt so groß wie Debians komplettes Binärarchiv. Nur enthält es keine Pakete, sondern Bauanleitungen (PKGBUILD), die auf dem eigenen Rechner ausgeführt werden. Sie sind nicht geprüft, nicht signiert und nicht vom Arch-Projekt betreut. Was das praktisch bedeutet, steht weiter unten — es ist der heikelste Punkt des Vergleichs.

Paketalter: hier gewinnt Arch, und zwar deutlich

Der Größenvergleich geht an Debian. Der Aktualitätsvergleich geht an Arch — und zwar so klar, dass es die andere Zahl in vielen Fällen aufwiegt.

Wir haben aus denselben Archiven die Versionsfelder ausgelesen, für Debian aus main, für Arch aus core/extra:

Methodik: Version:-Felder aus den Debian-Packages-Indizes von stable/main sowie %VERSION% aus den Arch-Paketdatenbanken, jeweils Stand 26.08.2026. Debian-Versionen ohne Distributions-Suffix dargestellt.

Die Spannweite ist bemerkenswert. Bei Apache liegen beide exakt gleichauf (2.4.68) — Debian portiert dort sehr fleißig. Bei Node.js liegen sechs Hauptversionen dazwischen, bei Rust dreizehn, bei LLVM drei. Und wireguard-tools in Debian trägt ein Datum aus dem Jahr 2021.

Was das praktisch heißt: Für einen Webserver mit PHP und nginx ist Debians Alter unerheblich — beides funktioniert, beides bekommt Sicherheitsfixes. Für eine Rust- oder Go-Entwicklungsumgebung ist es ein Ausschlusskriterium: Wer mit Rust 1.98 arbeitet, kann mit Debians 1.85 nicht bauen, und die Lösung heißt dann rustup statt apt — womit man das Paketsystem für genau die Software verlässt, um die es einem geht.

Genau an dieser Stelle entscheidet sich Debian vs Arch für die meisten Entwickler.

Der Kompromiss, den beide Lager verschweigen

Man muss sich nicht entscheiden. Debian bietet backports — ein offizielles Zusatzarchiv mit neueren Versionen ausgewählter Pakete, gebaut für stable. Und für Sprachwerkzeuge sind Versionsmanager (rustup, nvm, pyenv, offizielle Docker-Repos) ohnehin die bessere Wahl als Distributionspakete, weil sie projektweise unterschiedliche Versionen erlauben.

Ein Debian-Server mit rustup und dem offiziellen Docker-Repo hat den Aktualitätsvorteil von Arch dort, wo er zählt — und behält Debians unveränderliches Fundament überall sonst. Das ist in der Praxis die häufigste und meist die beste Lösung.

Wie viel Bewegung ist ein Rolling Release wirklich?

„Rolling Release” ist ein Wort, keine Menge. Wir wollten wissen, wie viel sich tatsächlich bewegt — und haben deshalb aus jedem einzelnen der 15.400 Arch-Pakete den Build-Zeitstempel (%BUILDDATE%) ausgelesen.

Methodik: %BUILDDATE% aus den desc-Dateien aller 15.400 Pakete in core, extra und multilib, Bezugsdatum 26.08.2026. Medianalter eines Arch-Pakets: 114 Tage.

Fast ein Drittel des Arch-Katalogs wurde im letzten Monat neu gebaut. Umgerechnet sind das rund 153 Paketaktualisierungen pro Tag über den gesamten Katalog. Ein durchschnittliches Desktop-System hat davon vielleicht 800 bis 1.200 installiert — ein pacman -Syu nach einer Woche Pause bringt also typischerweise mehrere Dutzend Aktualisierungen.

Der Median von 114 Tagen ist dabei der interessantere Wert als der Durchschnitt (187 Tage): Die Hälfte aller Arch-Pakete ist jünger als vier Monate. Bei Debian 13 ist der Vergleichswert für die Programmversionen praktisch der Release-Zeitpunkt August 2025 — also über ein Jahr.

Und die Kehrseite, die ehrlich dazugehört: Diese Bewegung ist Änderungsrisiko. Jede der 153 täglichen Aktualisierungen ist eine Gelegenheit, dass etwas anders funktioniert als gestern. Meistens passiert nichts. Aber „meistens” ist ein anderes Versprechen als Debians „gar nicht”.

„Arch bricht ständig” — stimmt das?

Das ist der Vorwurf, den man in jedem Debian vs Arch-Thread liest. Er lässt sich messen, denn Arch dokumentiert jede Aktualisierung, die Handarbeit erfordert, als offizielle Nachricht auf archlinux.org/news/.

Wir haben die vollständige Nachrichtenübersicht ausgewertet: 50 Meldungen reichen zurück bis zum 27.12.2021 — also gut viereinhalb Jahre.

Methodik: Nachrichtenübersicht von archlinux.org/news/ geparst, Titel auf „manual intervention” bzw. „requires manual” geprüft. Zeitraum 27.12.2021 bis 21.07.2026.

Das Ergebnis liegt zwischen den Lagern. In viereinhalb Jahren gab es 17 Aktualisierungen, die Handarbeit verlangten — im Schnitt etwa 3,6 pro Jahr, also ungefähr eine pro Quartal. Das ist deutlich mehr als bei Debian, wo man zwischen zwei Releases praktisch nie eingreifen muss. Es ist aber auch weit entfernt von „ständig”.

Und der entscheidende Zusatz: Diese Eingriffe sind angekündigt und dokumentiert. Wer pacman -Syu ausführt, ohne vorher die Arch-Nachrichten zu lesen, hat nicht Pech — er hat den einen Arbeitsschritt übersprungen, den das System von ihm erwartet. Die Meldungen betreffen zudem oft Nischen: virtualbox-ext-vnc (Juli 2026), waydroid, .NET-Pakete, Plasma auf X11.

Zwei der jüngsten sind allerdings breiter relevant: Im April 2026 stellte Arch iptables auf das nft-Backend um, und im Mai 2026 wurde varnish in vinyl-cache umbenannt — beides Dinge, die einen laufenden Server betreffen können.

Das AUR: größte Stärke und größtes Risiko zugleich

Das Arch User Repository ist der Grund, warum Arch-Nutzer bei „Debian hat mehr Pakete” nur die Augenbrauen heben. Mit 118.172 Einträgen findet sich dort praktisch jede Software, die je für Linux gebaut wurde — Nischen-Tools, proprietäre Programme, Git-Fassungen, Dinge, die in Debian nie eine Chance auf Aufnahme hätten.

Der Preis dafür ist präzise benennbar: Ein AUR-Eintrag ist ein Shell-Skript, das ein Fremder geschrieben hat und das auf deinem Rechner ausgeführt wird. Es gibt keine Prüfung, keine Signatur, keine Betreuung durch das Arch-Projekt. Ein PKGBUILD kann in seiner prepare()-Funktion beliebigen Code ausführen — mit deinen Rechten, und bei der Installation mit Root-Rechten.

Das ist keine theoretische Sorge. Am 12. Juni 2026 veröffentlichte das Arch-Projekt eine Nachricht mit dem Titel „Active AUR malicious packages incident”. Wörtlich heißt es dort:

„We are currently experiencing a high volume of malicious package adoptions and updates in the Arch User Repository.”

Das Projekt musste vorübergehend die Erstellung neuer Konten, das Einreichen von Aktualisierungen und die Übernahme verwaister Pakete einschränken, während es die schädlichen Commits zurückverfolgte. Die Empfehlung an die Nutzer lautete unverändert das, was sie immer lautet: jede PKGBUILD- und Install-Skript-Änderung vor dem Bauen selbst lesen.

Der ehrliche Vergleich lautet damit nicht „118.172 gegen 69.843”. Er lautet: 15.400 geprüfte, signierte Arch-Pakete gegen 69.843 geprüfte, signierte Debian-Pakete — und daneben ein riesiger, ungeprüfter Selbstbedienungsbereich, dessen Nutzung eine bewusste Risikoentscheidung ist.

Wer das Risiko einordnen will, findet den Mechanismus in unserem Artikel über IT-Sicherheitslücken — Abhängigkeiten sind dort das größte Einfallstor, und das AUR ist genau diese Klasse von Risiko in maximaler Ausprägung.

Für Debian gilt das Gegenstück: contrib und non-free sind mit zusammen 1.088 Paketen winzig, aber sie durchlaufen dieselbe Qualitätssicherung wie main. Wer dort etwas nicht findet, muss es selbst bauen — nur eben ohne einen bequemen Mechanismus, der das Selberbauen zur Gewohnheit macht.

Sicherheit: zwei Modelle, die man nicht direkt vergleichen kann

Hier liegt die häufigste Fehlinterpretation im ganzen Themenfeld — und wir sind beim Messen selbst hineingelaufen.

Die nackten Zahlen vom 26.08.2026:

Methodik: Debian aus security-tracker.debian.org/tracker/data/json (86 MB), CVEs mit Status open für Release trixie gezählt. Arch aus security.archlinux.org/issues/all.json, Status Vulnerable.

Wer daraus „Arch ist 66-mal sicherer” liest, hat zwei verschiedene Dinge verglichen. Die Zahlen bedeuten nicht dasselbe:

• Debians Tracker führt jede einzelne CVE pro Paket und lässt sie offen stehen, bis sie behoben oder als irrelevant markiert ist. Von den 5.623 offenen Einträgen sind 1.415 ausdrücklich als „unimportant” eingestuft — Lücken, die in Debians Konfiguration nicht ausnutzbar sind oder deren Behebung mehr Risiko brächte als Nutzen. Weitere 4.194 sind noch nicht bewertet. Ein offener Eintrag ist bei Debian also zuerst eine Buchungszeile, kein akutes Loch.
• Archs Tracker bündelt CVEs zu Gruppen (AVGs) und schließt sie, sobald die neue Upstream-Version im Repository liegt. Das geht schnell, weil es kein Rückportieren gibt — aber es zählt eben auch anders. 85 „Vulnerable”-Gruppen stehen 2.151 bereits behobenen gegenüber.

Der belastbare Unterschied ist ein struktureller, kein numerischer:

Debian portiert Sicherheitsfixes zurück. Wenn OpenSSL 3.6 eine Lücke schließt, baut Debian den Fix in seine 3.5.6 ein und ändert die Versionsnummer nicht. Vorteil: Nichts an deinem Server verändert sich außer der Lücke. Nachteil: Versionsscanner melden dein System fälschlich als verwundbar, weil sie nur die Nummer sehen — ein Dauerärgernis in Audits.

Arch behebt durch Aktualisieren. Die Lücke verschwindet, weil die neue Version kommt — mitsamt allen anderen Änderungen dieser Version. Vorteil: schnell und eindeutig. Nachteil: Der Sicherheitsfix ist untrennbar mit Funktionsänderungen verheiratet.

Für einen Server, der Compliance-Anforderungen erfüllen muss, ist Debians Modell das passendere — nicht weil es sicherer wäre, sondern weil es nachweisbar ist. Wir haben am eigenen Server erlebt, wie teuer eine übersehene Lücke wird: Der Vorfall in Fünf Tage gekapert lief über eine bekannte RCE in einer Anwendungsabhängigkeit — die Distribution war daran unschuldig, aber die Lehre gilt für beide Modelle.

Wartungsaufwand: die Arbeit wird verschoben, nicht gespart

Das häufigste Missverständnis in beide Richtungen: Debian-Nutzer glauben, Rolling Release bedeute Dauerstress. Arch-Nutzer glauben, Fixed Release bedeute, man müsse nie etwas tun. Beides ist falsch — die Arbeit ist nur anders verteilt.

Debian über fünf Jahre:

• Täglich/wöchentlich: unattended-upgrades spielt Sicherheitsfixes ein. Aufwand real: null.
• Alle zwei Jahre: ein Distributions-Upgrade (trixie → forky). Das ist ein geplanter Termin mit Vorbereitung, Backup, Wartungsfenster und Nacharbeit an Konfigurationsdateien. Realistisch ein halber bis ganzer Tag pro Server.
• Nach fünf Jahren: Support-Ende, Neuaufsetzen oder Upgrade-Kette.

Arch über fünf Jahre:

• Wöchentlich bis monatlich: pacman -Syu, vorher Arch-News lesen. Realistisch fünf bis fünfzehn Minuten.
• Etwa quartalsweise: eine Aktualisierung mit Handarbeit (siehe die 17 Meldungen in viereinhalb Jahren).
• Nie: ein großes Distributions-Upgrade. Es gibt keins.

Die Rechnung geht überraschend knapp aus. Wer Arch alle zwei Wochen aktualisiert, kommt auf etwa 130 Aktualisierungen in fünf Jahren à zehn Minuten — rund 22 Stunden. Debian kommt auf zwei bis drei Distributions-Upgrades à sechs Stunden plus Nacharbeit — rund 20 Stunden. Der Aufwand ist ähnlich; der Unterschied liegt in der Verteilung und Planbarkeit.

Und genau das ist für Server das entscheidende Kriterium: Debians Arbeit lässt sich terminieren. Arch’ Arbeit fällt an, wann sie anfällt — und wenn man sie aufschiebt, wird sie nicht kleiner, sondern riskanter.

Der Fallstrick, den nur Arch hat: die Pause

Debian verzeiht Vernachlässigung. Ein Server, der ein Jahr lang nur Sicherheitsupdates bekommen hat, ist danach genau so betriebsbereit wie vorher.

Arch verzeiht sie nicht gut. Ein System, das ein Jahr nicht aktualisiert wurde, hat womöglich mehrere „manual intervention”-Meldungen verpasst, und der Schlüsselbund (archlinux-keyring) kann so alt sein, dass Signaturprüfungen für die neuen Pakete fehlschlagen — ein klassischer Henne-Ei-Fall, den man mit pacman -Sy archlinux-keyring zuerst auflösen muss.

Praxisregel: Wer nicht sicher ist, dass er ein System mindestens monatlich anfasst, sollte kein Arch darauf installieren. Das ist kein Vorwurf an Arch — es ist die Bedienungsanleitung.

Arch auf dem Server: die ehrliche Antwort

Kurz: meistens nein. Ausführlich, weil die Gründe konkret sind und keine Geschmacksfragen:

1. Es gibt nichts zu zertifizieren. Software-Hersteller nennen unterstützte Distributionen mit Versionsnummer. Arch hat keine, kann also in keiner Support-Matrix stehen.
2. Kein Wartungsfenster ist planbar. Eine Aktualisierung, die Handarbeit erfordert, kündigt sich an — aber nicht zu einem Termin, den du gewählt hast.
3. Automatische Sicherheitsupdates gibt es nicht sinnvoll. Debians unattended-upgrades funktioniert, weil sich nur Fixes ändern. Ein automatisiertes pacman -Syu würde ungeprüft Hauptversionssprünge einspielen — das macht niemand freiwillig auf einem Produktionssystem.
4. Kein Support-Zeitraum. Debian 13 hat ein Enddatum: 30. Juni 2030. Das kann man in einen Betriebsplan schreiben. „Immer aktuell” kann man nicht.
5. Nahezu keine Hoster-Images. Wer Arch bei einem VPS-Anbieter will, findet es oft nur über den Umweg eigener Abbilder — während Debian überall Standard ist.

Wann Arch auf einem Server trotzdem sinnvoll ist: Bei einer Maschine, die eine einzige, sehr aktuelle Software fahren muss, die von einem Menschen betreut wird, der sie ohnehin täglich anfasst — etwa ein Build-Runner, eine Entwicklungs- oder Testmaschine, ein Homelab-Host. Dort ist der Aktualitätsvorteil real und der Planbarkeitsnachteil egal.

Für alles, was Kunden bedient, ist Debian die richtige Antwort. Unsere eigenen Produktionsserver laufen auf Debian und Ubuntu; wie wir sie aufsetzen und härten, steht in Linux Server einrichten, und die Einordnung aller gängigen Kandidaten in Linux Server Distributionen.

Der Desktop: hier kippt der Vergleich

Auf dem Server gewinnt Debian klar. Auf dem Desktop ist die Lage fast umgekehrt, und zwar aus einem Grund, der auf Servern keine Rolle spielt: Hardware und Spiele brauchen aktuelle Treiber.

Ein Notebook mit einer Grafikkarte oder einem WLAN-Chip aus dem laufenden Jahr wird von Debians Kernel 6.12 unter Umständen gar nicht erkannt. Arch’ Kernel 7.1 kennt sie. Dasselbe gilt für Mesa, Wayland-Sitzungen, Pipewire und die gesamte Gaming-Kette rund um Proton — dort ist der Unterschied zwischen einem Jahr und einer Woche Rückstand direkt spürbar.

Der Punkt zur Dokumentation ist keine Höflichkeit. Das ArchWiki ist die mit Abstand beste Linux-Dokumentation, die es gibt, und sie wird von Nutzern aller Distributionen gelesen — auch von uns, wenn wir ein Debian-Problem lösen. Wer Arch benutzt, lernt zwangsläufig, wie sein System funktioniert, weil er es selbst zusammengesetzt hat. Das ist kein Nebeneffekt, es ist Archs eigentliches Angebot.

Wer die Aktualität will, aber nicht die Installationsarbeit, landet meist bei einem Arch-Abkömmling wie EndeavourOS oder CachyOS: dasselbe Rolling Release, dieselben Repositories, nur mit grafischem Installer und Vorkonfiguration. Für Einsteiger ist das der deutlich sanftere Weg — mit demselben Wartungsprofil.

Und wer auf dem Desktop schlicht Ruhe haben will, ist mit Debian oder einem Ubuntu-Abkömmling besser bedient; der Vergleich dazu steht in Ubuntu vs Mint.

Pacman gegen APT

Beide Paketverwaltungen sind ausgezeichnet, und der Unterschied ist kleiner, als die Lagerbildung vermuten lässt.

Zwei Punkte sind wirklich wichtig:

pacman -Sy paket ist eine Falle. Arch unterstützt keine Teilaktualisierungen. Wer die Paketlisten aktualisiert und dann ein einzelnes Paket installiert, kann ein Programm bekommen, das gegen neuere Bibliotheken gebaut wurde, als sein System hat. Das Ergebnis sind Fehler über fehlende .so-Dateien. Richtig ist immer pacman -Syu. Bei APT ist das gefahrlos, weil Debians Versionen ohnehin zusammenpassen.

.pacnew ist ehrlicher, aber unbequemer. Ändert sich eine Standardkonfiguration, überschreibt Pacman deine Datei nicht, sondern legt die neue daneben — und sagt es dir einmal. Wer nicht aufräumt, sammelt über Jahre Konfigurationen, die nicht mehr zum Programm passen. APT fragt stattdessen interaktiv, was aufdringlicher wirkt, aber seltener zu stillen Altlasten führt. Werkzeuge wie pacdiff gleichen das aus.

Häufige Fragen

Was ist besser, Debian oder Arch?

Keines von beiden generell — die Frage entscheidet sich am Einsatzzweck. Für Produktionsserver ist Debian in fast allen Fällen die richtige Wahl: planbare Wartung, ein festes Support-Ende (30.06.2030 für Debian 13) und automatisierbare Sicherheitsupdates. Für Desktops mit aktueller Hardware, für Gaming und für Entwicklungsumgebungen, die neue Werkzeugketten brauchen, ist Arch überlegen: Kernel 7.1 statt 6.12, Rust 1.98 statt 1.85, Node 26 statt 20.

Ist Arch Linux stabil?

Ja — aber „stabil” bedeutet hier etwas anderes als bei Debian. Arch stürzt nicht häufiger ab; die Pakete sind Upstream-Releases, keine Testversionen. „Stabil” im Debian-Sinn heißt jedoch „unverändert”, und das ist Arch prinzipbedingt nicht. Messbar: In viereinhalb Jahren gab es 17 Aktualisierungen, die Handarbeit verlangten — rund 3,6 pro Jahr. Wer die Arch-News vor dem Aktualisieren liest, betreibt Arch problemlos über Jahre.

Wie viele Pakete haben Debian und Arch?

Am 26.08.2026 gezählt: Debian 13 hat 69.843 Binärpakete für amd64 (68.755 davon in main), Arch hat 15.400 in core, extra und multilib. Dazu kommen 118.172 Bauanleitungen im AUR — das sind allerdings ungeprüfte Skripte, keine fertigen Pakete. Ein fairerer Vergleich ist der gegen Debians 37.633 Quellpakete, weil Debian eine Software oft in mehrere Binärpakete aufteilt und Arch nicht.

Kann man Arch Linux als Server verwenden?

Technisch ja, praktisch meist nicht empfehlenswert. Es fehlen fünf Dinge, die ein Produktionsserver braucht: eine Version für Support-Matrizen, ein festes Support-Ende, planbare Wartungsfenster, sinnvoll automatisierbare Sicherheitsupdates und verbreitete Hoster-Images. Sinnvoll ist Arch auf Servern, die ohnehin täglich betreut werden — Build-Runner, Test- und Entwicklungsmaschinen, Homelab.

Ist das AUR sicher?

Nein, nicht im Sinne einer Zusicherung. AUR-Einträge sind ungeprüfte Bauskripte von Fremden, die auf deinem Rechner mit deinen Rechten ausgeführt werden. Am 12. Juni 2026 meldete das Arch-Projekt selbst einen laufenden Vorfall mit „einem hohen Volumen an bösartigen Paketübernahmen und -aktualisierungen” und schränkte vorübergehend Konten und Uploads ein. Die Regel des Projekts gilt unverändert: jede PKGBUILD- und Install-Skript-Änderung vor dem Bauen selbst lesen.

Wie oft muss man Arch Linux aktualisieren?

Mindestens monatlich, besser alle ein bis zwei Wochen. Der Grund ist nicht Ungeduld, sondern der Schlüsselbund: Ein lange vernachlässigtes System hat womöglich ein veraltetes archlinux-keyring, wodurch Signaturprüfungen für neue Pakete fehlschlagen — dann muss man pacman -Sy archlinux-keyring vorziehen. Zusätzlich häufen sich verpasste „manual intervention”-Meldungen. Wer ein System nicht mindestens monatlich anfasst, sollte kein Arch darauf installieren.

Hat Arch mehr aktuelle Software als Debian?

Deutlich, und der Abstand ist paketabhängig. Beispiele vom 26.08.2026: Node.js 26.7 gegen 20.19 (sechs Hauptversionen), Rust 1.98 gegen 1.85, LLVM 22.1 gegen 19.0, Kernel 7.1.9 gegen 6.12.94. Es gibt aber Gegenbeispiele: Apache liegt bei beiden auf 2.4.68. Und der Abstand lässt sich auf Debian gezielt schließen — mit backports oder Versionsmanagern wie rustup für genau die Werkzeuge, auf die es ankommt.

Was passiert, wenn ich Debian und Arch vergleiche, ohne den Kernel zu betrachten?

Dann übersieht man den praktisch wichtigsten Unterschied für Desktops. Der Kernel entscheidet über Hardware-Unterstützung: Debian 13 liefert 6.12.94, Arch 7.1.9. Bei Hardware, die älter als zwei Jahre ist, spielt das keine Rolle. Bei einem aktuellen Notebook kann es der Unterschied zwischen funktionierendem WLAN und keinem WLAN sein. Auf Servern mit bewährter Hardware ist es dagegen fast bedeutungslos.

Was wir nicht gemessen haben

Damit klar ist, wo dieser Vergleich endet:

• Kein Leistungsvergleich. Beide Systeme sind bei gleicher Konfiguration ähnlich schnell; Unterschiede entstehen durch Kernel-Version und Standardeinstellungen, nicht durch die Distribution als solche.
• Keine Langzeitmessung der Ausfälle. Wir haben die dokumentierten Eingriffe gezählt, nicht die undokumentierten Ärgernisse einzelner Nutzer. Beides gibt es, das zweite lässt sich nicht seriös quantifizieren.
• Kein Vergleich der Arch-Abkömmlinge. Manjaro verzögert Pakete bewusst und hat dadurch ein eigenes Risikoprofil; EndeavourOS und CachyOS nutzen Archs Repositories direkt. Das wäre ein eigener Artikel.
• Debian testing/unstable blieben außen vor. Debian sid ist selbst ein Rolling Release und schließt den Aktualitätsabstand fast vollständig — allerdings ohne Sicherheitsteam-Betreuung.

Fazit

Debian vs Arch ist keine Frage von Qualität, sondern von einer einzigen Entscheidung: Soll sich mein System verändern, wenn ich nicht hinschaue?

Die Zahlen aus unseren eigenen Messungen ordnen das ziemlich klar:

Debian hat den größeren Katalog — 69.843 gebaute Pakete gegen 15.400, selbst bei Quellpaketen noch 2,4:1. Arch hat die aktuellere Software, teils um Jahre: Node 26 gegen 20, Rust 1.98 gegen 1.85, Kernel 7.1 gegen 6.12. Arch bewegt sich messbar viel: 4.600 Pakete allein im letzten Monat neu gebaut, rund 153 pro Tag. Und Arch bricht seltener als sein Ruf: 17 Aktualisierungen mit Handarbeit in viereinhalb Jahren, alle vorher angekündigt.

Das AUR ist dabei kein Zusatzargument für Arch, sondern eine eigene Entscheidung: 118.172 ungeprüfte Bauskripte, und ein vom Projekt selbst gemeldeter Vorfall im Juni 2026.

Die praktische Regel, auf die wir es herunterbrechen:

• Server, der Kunden bedient → Debian. Wegen des Enddatums 30.06.2030, wegen unattended-upgrades, wegen der Planbarkeit.
• Desktop mit aktueller Hardware oder Gaming → Arch (oder EndeavourOS/CachyOS, wenn du den Installer willst).
• Entwicklungsmaschine mit modernen Werkzeugketten → Arch, oder Debian plus rustup/nvm/Docker-Repo. Beides ist vertretbar.
• Ein System, das du seltener als monatlich anfasst → Debian, ohne Diskussion.

Und der Satz, der beide Lager versöhnt: Der Aktualitätsvorsprung von Arch lässt sich auf Debian punktuell nachrüsten. Debians Ruhe lässt sich auf Arch nicht nachrüsten — sie ist kein Paket, sondern das Release-Modell selbst.

Wer weiterlesen will: Debian vs Ubuntu vergleicht Debian mit dem anderen großen Server-Kandidaten, Linux Server Distributionen ordnet alle Optionen ein, Fedora Linux im Deep Dive zeigt den Mittelweg zwischen beiden Modellen, und Linux Server einrichten macht aus der Entscheidung einen laufenden Server.