Mit ihrem hohen Arbeitstempo erfreut die Distribution CachyOS immer mehr Anwender. Im Interview verrät der Mitbegründer Peter Jung, was der zunehmende Erfolg für das Projekt bedeutet und wie das Team an der Geschwindigkeitsschraube dreht.

Wer derzeit eine Empfehlung für eine Linux-Distribution sucht, stolpert immer wieder über einen Namen: CachyOS. Dabei wirkt die Distribution auf den ersten Blick wenig spektakulär. So besteht das System aus einem einfach zu installierenden Arch Linux, das seine Nutzer standardmäßig vor einem aktuellen KDE Plasma-Desktop absetzt. Durch gezielte Optimierungen läuft CachyOS jedoch deutlich flotter als viele Konkurrenten. Unter anderem nutzt der Kernel einen alternativen Scheduler, der die verfügbare Rechenzeit etwas anders an die Prozesse verteilt. Damit agiert das System vor allem unter einigen Workstation-Anwendungen und in Spielen deutlich agiler. Die Optimierungen greifen so gut, dass sie CachyOS in der letzten Zeit in den Fokus der Presse rückten und zu steigenden Nutzerzahlen führten. Über die Auswirkungen des Rampenlichts, die eingesetzten Tuning-Ansätze und zusätzliche Sicherheitsmaßnahmen sprachen wir mit Peter Jung, einem der beiden Gründer von CachyOS.

CachyOS nutzt standardmäßig ein weitgehend unverbasteltes KDE Plasma.

LM: Gleich zu Anfang die obligatorische Frage: Warum noch eine Linux-Distribution? Beziehungsweise wie entstand die Idee zu CachyOS?

Peter Jung: Die Idee zu CachyOS entstand aus einem Hobby und dem Wunsch, Linux besser zu verstehen. Eine eigene Distribution zu bauen klang dafür ideal. Außerdem gab es zu dieser Zeit kaum optimierte Distributionen – abgesehen von Gentoo.

LM: Wie läuft die Arbeit an CachyOS in eurem Team ab? Laut eurer Website seid ihr ein recht kleines Team – da sind die Dienstwege doch sicherlich kurz?

Peter Jung: Kommunikation und Zusammenarbeit finden hauptsächlich in einem Discord-Kanal statt. Dort arbeiten wir To-do-Listen ab, sammeln neue Ideen und kümmern uns um die Community.

LM: CachyOS wird gerade von der Presse hochgelobt und scheint sich zu einer besonders beliebten Distribution zu mausern. Spürt ihr die zunehmende Popularität, zum Beispiel an steigenden Download-Zahlen?

Peter Jung: Das stimmt! Derzeit erleben wir einen großen Aufschwung. Der Traffic hat sich seit Anfang 2025 massiv erhöht; wir liegen inzwischen bei über 1 Petabyte (1.000 TB) pro Monat. Die Downloads des Installationsabbilds (ISO-Image) sind ebenfalls auf rund 3.000 pro Tag gestiegen.

LM: Wie geht ihr mit dem Erfolg um beziehungsweise wie beeinflusst der eure Arbeitsweise? Gibt es beispielsweise mehr Hilfe aus der Community?

Peter Jung: Früher konnten wir nahezu allen Nutzerinnen und Nutzern direkten Support geben – das ist nebenberuflich inzwischen nicht mehr möglich. Einige Community-Mitglieder springen hier ein. Wir arbeiten weiterhin daran, allen zu helfen, auch Neulingen. Außerdem haben wir Experimente, die wir früher schneller “gepusht” haben, auf einen kleineren Kreis reduziert, weil wir ein stabiles System bereitstellen möchten.

LM: Wie hat sich denn generell die Arbeit an der Distribution im Laufe der Zeit verändert? Gab es etwas, das ihr rückblickend anders machen würdet?

Peter Jung: Wie oben beschrieben war früher viel zum Spaß, experimentell und es war nicht so schlimm, wenn etwas mal kaputt war. Ebenfalls, durch die vielen Projekte, die wir angefangen haben, ist mittlerweile sehr viel “nur” Wartungsarbeiten und dadurch nicht mehr so viele Neuerungen. Aber wir wollen die Projekte, welche wir angefangen haben natürlich auch bereitstellen und nicht einfach stoppen.

LM: Warum basiert ihr auf Arch Linux? Viele andere auf den Desktop fokussierte Distributionen greifen ja eher auf Debian oder Ubuntu zurück.

Peter Jung: Arch Linux ist eine faszinierende Basis: Das Build-System ist simpel, wodurch sich Modifikationen schnell umsetzen lassen. Zudem gibt es das AUR (Arch User Repository), das für nahezu jede erdenkliche Software eine Bauanleitung bereithält. Das fehlt in einigen anderen Distributionen, weshalb es dort oft schwieriger ist, Software zu finden. In unserer Anfangszeit kamen wir mit Arch Linux am besten zurecht.

LM: CachyOS ist vor allem auf Geschwindigkeit optimiert. Warum legt ihr darauf den Fokus? Arbeiten aktuelle Linux-Distributionen nicht schon flott genug? Meist bremsen die Systeme doch nur dicke Desktop-Umgebungen und zahlreiche Dienste im Hintergrund – oder?

Peter Jung: Optimierungen im Linux-Bereich unterscheiden sich von Windows: Man kann das System – etwa über Compiler-Flags, Instruktionen u. Ä. – sehr gezielt anpassen und so mehr Leistung herausholen. Performance ist vor allem im hochskalierten Serverbetrieb interessant, aber ich fand das auch auf dem Desktop sinnvoll: Wenn man allein durch Paket-Optimierungen ~10 % mehr Leistung bekommt, fühlt sich das fast wie ein CPU-Generationssprung an.

LM: Ihr stellt mehrere Kernel und unterschiedliche Scheduler zur Auswahl. Warum betreibt ihr diesen Aufwand? Wenn ich von der Beschreibung auf eurer Website ausgehe, ist CachyOS primär ein Desktop-System. Reicht da nicht ein optimierter Kernel für diesen Anwendungsfall aus?

Peter Jung: Die verschiedenen Scheduler und Varianten bieten insbesondere Enthusiasten eine andere – teils bessere – Erfahrung. Vorkompilierte Kernel-Varianten waren lange ein Alleinstellungsmerkmal in der Linux-Enthusiasten-Szene und wurden gerne genutzt. CachyOS wurde 1-2 Jahre stark von dieser Community geprägt, daher lag dort der Fokus. Inzwischen empfehlen wir den meisten Nutzerinnen und Nutzern unseren Standard-Kernel.

LM: Ihr ergreift zahlreiche Maßnahmen, um die Geschwindigkeit zu steigern. Dazu zählt ein optimierter Kernel, neu übersetzte Softwarepakete und spezielle Einstellungen. Welche dieser ganzen Maßnahmen hat denn den größten Geschwindigkeitsschub gebracht?

Peter Jung: Das hängt von Anwendung und Workload ab. Es geht nicht nur um Rohgeschwindigkeit, sondern auch um Latenz und Reaktionsfreudigkeit unter Last. Unser Standard-Scheduler zielt darauf, das Desktop-System unter hoher Last möglichst reaktionsfreudig zu halten. Viel bringt zudem, die verfügbaren CPU-Instruktionen auszunutzen. Bei einigen Programmen profilieren wir den Code und füttern den Compiler mit diesen Profilen (PGO) – das kann spürbare Zugewinne bringen.

LM: Warum empfehlt beziehungsweise nutzt ihr vor allem den BORE Scheduler? Habt ihr da im Vorfeld eigene Messungen mit unterschiedlichen Workloads durchgeführt?

Peter Jung: Der offizielle Kernel-Scheduler (EEVDF) ist ein “All-in-One-Scheduler”: Er soll auf Servern wie auf Desktops gut laufen und Prozesse “fair” behandeln. Unter hoher Last kann das Desktop-System dadurch ins Ruckeln geraten, weil Desktop-Prozesse nicht priorisiert werden. Der BORE-Scheduler mitigiert das, ohne den Durchsatz spürbar zu verschlechtern.

LM: Euren Standard-Kernel übersetzt ihr mit Clang. Warum fiel die Wahl auf diesen Compiler?

Peter Jung: Clang bietet beim Kernel einige Vorteile, etwa Unterstützung für AutoFDO und Propeller-Optimierungen. Diese Verfahren profilieren den Kernel und speisen die Profildaten wieder in den Compiler ein, um den erzeugten Code zu verbessern. Dafür sind mehrere Kompilier- und Profil-Durchläufe nötig.

LM: Kannst du einen kleinen Überblick geben, mit welchen weiteren Maßnahmen ihr den Kernel auf Geschwindigkeit trimmt?

Peter Jung: Wie erwähnt, übernehmen Profiling-Daten einen großen Teil der Optimierung. Zusätzlich haben wir Patches, die den Scheduler verbessern, integrieren das BBRv3-Protokoll und passen verschiedene Standard-Einstellungen des Upstream-Kernels an, die eher auf Server zugeschnitten sind und für den Desktop suboptimal wären.

LM: Ihr optimiert nicht nur den Kernel, sondern übersetzt auch die Pakete mit entsprechenden Compiler-Flags. Kannst du einen kurzen Überblick geben, welche Optimierungen ihr da anknipst und warum ihr ausgerechnet diese gewählt habt?

Peter Jung: Aktuell kompilieren wir Pakete für “x86-64-v3” (u. a. AVX2), “x86-64-v4” (AVX-512) sowie gezielt für die Mikroarchitektur Zen 4. Die generischen Targets x86-64-v3/v4 sind auf modernen Systemen weit verbreitet. Zen 4 haben wir ergänzt, weil es – insbesondere bei neueren AVX-512-Erweiterungen – zusätzliche Potenziale erschließt. Die Zen-4-optimierten Builds laufen auf Zen 4/Zen 5 und – je nach Paket und genutztem ISA-Umfang – in der Regel auch auf Intel-CPUs mit vergleichbaren Features wie Sapphire Rapids.

LM: Ist es nicht aufwendig, so viele Pakete neu zu erstellen und in einem separaten Repository zu pflegen?

Peter Jung: Das meiste ist automatisiert. Für Pakete, bei denen nur Compiler-Flags angepasst werden, haben wir einen Builder-Dienst, der neue Versionen in den Arch-Repos erkennt, sie baut und ins Repository schiebt. Daneben gibt es manuell angepasste PKGBUILDs – etwa mit PGO. Das ist mehr Arbeit, kann aber z. B. bei Compilern (Clang/GCC) 10-15 % Performance bringen. Inzwischen benötigen wir dafür beträchtliche Rechenleistung (u. a. 1 x 7950X3D, 1 x 7700X als Server), was entsprechend kostet.

LM: Weitere Optimierungen schafft ihr über maßgeschneiderte Einstellungen, wie bei den Udev-Regeln. Wie seid ihr auf diese Einstellungen gekommen?

Peter Jung: Die meisten Udev-Regeln dienen nicht der Performance, sondern beheben Bugs bei bestimmter Hardware – z. B. Knistergeräusche bei einigen Laptops oder Anpassungen im NVIDIA-Treiber-Handling. Außerdem passen wir den I/O- bzw. Platten-Scheduler je nach Hardware (SSD/NVMe/HDD) an, um optimale Ergebnisse zu erzielen.

LM: Einige Einstellungen deaktivieren Stromsparmechanismen, etwa beim Audio-System oder bei der SATA-Schnittstelle. Ist das nicht gerade auf Notebooks problematisch, weil dort dann die Akkulaufzeit sinken könnte?

Peter Jung: Diese Mechanismen werden nur deaktiviert, wenn das Gerät am Netzteil hängt (siehe https://github.com/CachyOS/CachyOS-Settings/blob/master/usr/lib/udev/rules.d/20-audio-pm.rules#L2).

LM: Ihr bewerbt eure Distribution auch explizit als “sicher” und bietet einen gehärteten Kernel an. Wie genau habt ihr den gehärtet und welche Maßnahmen habt ihr zur Absicherung des Systems noch ergriffen?

Peter Jung: Früher gab es einen Firefox-basierten Browser mit Fokus auf Sicherheit; den bieten wir inzwischen nicht mehr an. Auf Compiler-Seite aktivieren wir Sicherheits-Flags wie CET, -fcf-protection und FORTIFY, die wir nicht zugunsten der Performance deaktivieren. Außerdem bieten wir ein einfaches Setup für sichere DNS (DoT) und AppArmor.

LM: Wie stark beeinflussen diese Härtungsmaßnahmen die Performance?

Peter Jung: Sicherheit kostet meist etwas Leistung. Wir drehen die Sicherheit nicht herunter, um mehr Performance zu gewinnen, denn Sicherheit ist uns wichtig. Schätzungsweise ließen sich – je nach Hardware – über die gesamte Distribution 10-20 % herausholen, wenn man z. B. CPU-Mitigations und bestimmte Compiler-Schutzmechanismen deaktivieren würde.

LM: CachyOS gibt es derzeit nur für die x86-Architektur und für verschiedene Handhelds. Plant ihr die Unterstützung von weiteren Prozessorarchitekturen wie ARM-Rechner?

Peter Jung: Wir haben großes Interesse an weiteren Architekturen. Das offizielle Arch Linux bietet derzeit keine anderen Architekturen an, und die ARM64-Forks sind nicht im besten Zustand. Arch Linux arbeitet daran, voranzukommen. Sobald es einen offiziellen Port gibt, werden wir uns dransetzen und ARM64-Unterstützung anbieten.

LM: Vielen Dank, Peter für das Interview.

Zweifaltigkeit

Derzeit konzentriert sich das CachyOS-Team auf Deskop-Systeme und Spielekonsolen, Server spielen noch keine Rolle. Jeden Einsatzbereich adressiert dabei eine eigene CachyOS-Fassung. Die Desktop Edition stellt zunächst eine klassische Arbeitsumgebung bereit. Das dabei vorinstallierte KDE Plasma lässt sich schnell durch viele weitere Desktop-Umgebungen und Wayland-Compositors tauschen.

Wer CachyOS auf einer Spielekonsole wie dem Steam Deck einsetzen möchte, greift hingegen zur darauf zugeschnittenen Handheld Edition. Sie bringt unter anderem einen Steam Client und weitere wichtige Tools für Gamer mit. Derzeit unterstützt die Handheld Edition das Rog Ally, die Steam Deck-Varianten mit OLED- und LCD-Bildschirm, sowie die Legion GO und Go S.