Fragen Sie im CachyOS-Subreddit, ob Sie CachyOS oder Omarchy installieren sollen, und die beiden bestbewerteten Antworten sind keine Empfehlungen. Eine lautet „Asking this in related to CachyOS sub…bruh.“ Die andere vergleicht es damit, in ein Honda-Forum zu gehen und zu fragen, ob man einen Accord oder einen Camry kaufen soll.
Beide Antworten haben recht, und der Grund ist mechanisch, nicht eine Frage der Haltung. Die Unterschiede Arch-basierter Distributionen laufen darauf hinaus, wo jedes Projekt das Stock-Arch verändert. Bei den hier verglichenen Distributionen landen diese Änderungen überwiegend an fünf Stellen: Installer, Kernel und Compile-Targets, Paketquellen, Desktop-Shell und Konfiguration sowie Update- und Rollback-Politik. CachyOS und Omarchy nehmen ihre größten Änderungen in unterschiedlichen Schichten vor.
Die Kurzfassung
- Bei den hier verglichenen Distributionen fallen die nützlichen Unterschiede überwiegend in fünf Schichten: Installer, Kernel und Compile-Targets, Paketquellen, Desktop-Shell und Konfiguration, Update- und Rollback-Politik.
- Ein Projekt kann eine Schicht ändern und die anderen vier unangetastet lassen, und genau so können zwei Distributionen beide „Arch-basiert“ sein und fast nichts gemeinsam haben.
- CachyOS ändert die Kernel-/Compile- und die Paketquellen-Schicht stark, kuratiert den Installer und schreibt keine Desktop-Shell vor: Sie wählen Ihre eigene bei der Installation.
- Omarchy ändert die Desktop-Shell- und die Update-Politik-Schicht stark, betreibt einen eigenen Paketkanal und nimmt keine leistungsmotivierten Änderungen an Kernel oder Compile-Targets vor.
- Die Schichten lassen sich getrennt übernehmen: CachyOS dokumentiert, wie man seine Paketquellen zu einer bestehenden Arch-Installation hinzufügt, und Leute sind diesen Weg auf Omarchy mit gemischten Ergebnissen gegangen.
Was dieser Artikel nicht klärt
Drei Fragen liegen nah genug an dieser, um mit ihr verwechselt zu werden, und jede braucht eine andere Art von Beleg, als eine Taxonomie liefern kann.
- Ob CachyOS generell schneller ist. Diese Frage hat ihre eigene Beweislage und ihren eigenen Artikel.
- Welche der beiden Sie installieren sollten.
- Jedes existierende Arch-Derivat. Fünf werden hier genannt, und diese fünf Schichten sind ein Vergleichsmodell für diese Gruppe, keine erschöpfende Taxonomie aller Arch-Derivate.
Fünf Schichten, die dieser Vergleich verfolgt
Bei den hier verglichenen Derivaten erklären fünf Schichten die meisten nennenswerten Unterschiede: Installer, Kernel und Compile-Targets, Paketquellen, Desktop-Shell und Konfiguration sowie Update- und Rollback-Politik. Ein Projekt kann eine davon ändern und die anderen vier genau so lassen, wie Arch sie ausliefert.
Der Installer ist der Weg vom nackten Rechner zum gebooteten System und die Schicht, in der ein Projekt entscheidet, wie viele Entscheidungen es Ihnen überlässt. Stock-Arch dokumentiert einen manuellen Installationsweg und liefert auf seinem Live-ISO auch den geführten Installer archinstall mit; ein Derivat kann diese Erfahrung trotzdem durch eigene geführte Voreinstellungen ersetzen. Entscheidend ist, was dieser Installer für Sie festlegt: Dateisystem, Bootloader, Verschlüsselung, Treiber, Desktop. Jede Voreinstellung ist eine Position, die jemand eingenommen hat.
Die Schicht Kernel und Compile-Targets umfasst drei Dinge, die gern vermengt werden. Welchen Kernel-Build Sie booten. Für welchen CPU-Befehlssatz Ihre Pakete kompiliert wurden. Welcher Scheduler entscheidet, was wann läuft.
Ein Compile-Target ist die Mikroarchitekturstufe, für die ein Paket gebaut wurde. x86-64 ist die Basis, die jeder x86-64-Prozessor unterstützt. x86-64-v3 ergänzt Funktionen wie AVX, AVX2, BMI1, BMI2 und FMA, während x86-64-v4 zusätzlich AVX-512 voraussetzt. Ein für eine dieser Stufen gebautes Paket startet nicht auf einem Prozessor, dem der erforderliche Funktionsumfang fehlt. Der Scheduler entscheidet, welche lauffähige Aufgabe den Prozessor als Nächstes bekommt, und Scheduler gewichten Durchsatz gegen interaktive Reaktionsfähigkeit unterschiedlich. Ein Derivat kann alle drei ändern, eines oder keines.
Die Schicht der Paketquellen ist eine Frage der Herkunft: Wessen Build eines Pakets Sie bekommen, wie frisch er ist und wer den Kanal kontrolliert, über den er ankommt. Stock-Arch bezieht Binärpakete aus core, extra und multilib, mit dem AUR daneben als Bauanleitungen, die Sie selbst kompilieren. Ein Derivat kann eine eigene Paketquelle darüberlegen, eine bewusste Verzögerung vor die von Arch schalten oder beides.
Die Schicht Desktop-Shell und Konfiguration ist das, was auf dem Bildschirm erscheint und wie es angeordnet ist, und hier stolpern die Leute über das Vokabular. Eine Desktop-Umgebung wie KDE Plasma oder GNOME ist ein Komplettpaket: Fensterverwaltung, Panel, Dateimanager, Einstellungen, Anwendungen. Ein Tiling-Fenstermanager wie i3 oder ein Tiling-Wayland-Compositor wie Hyprland übernimmt die Fensteranordnung, ohne eine vollständige Desktop-Suite mitzuliefern, und lässt Leiste, Launcher, Benachrichtigungen und Sperrbildschirm als separate Teile. Ein Derivat kann eine Shell vorschreiben, ein Menü anbieten oder keine Position beziehen.
Die Schicht Update und Rollback umfasst, wie das System voranschreitet und wie Sie zurückkommen, wenn es irgendwohin geht, wo es nicht hinsollte. Auf Stock-Arch liegt beides bei Ihnen: pacman -Syu, wann Sie es entscheiden, Wiederherstellung über den Paketcache oder eine Snapshot-Lösung, die Sie selbst gebaut haben. Ein Derivat kann diesen Befehl umhüllen, absichern oder in Ruhe lassen, und es kann Wiederherstellung zum Standard machen, indem es das Dateisystem so anlegt, dass Snapshots günstig sind. Genau das bringt eine Btrfs-Subvolume-Aufteilung: Ein Snapshot ist eine Momentaufnahme eines Subvolumes, und mit Bootloader-Integration kann ein Derivat diese Snapshots als Wiederherstellungsoptionen anbieten.
Was CachyOS ändert
CachyOS ändert die Schicht Kernel und Compile-Targets sowie die Schicht der Paketquellen stark, kuratiert den Installer und schreibt keine Desktop-Shell vor. Es liefert eigene Kernel-Builds und kompiliert Archs Pakete für neuere CPU-Funktionsstufen neu, überlässt aber, was auf dem Bildschirm erscheint, demjenigen, der es installiert.
Sein Installer lässt Sie Desktop, Dateisystem und Kernel wählen, dazu Pakete und Bootmanager, und ein Hardware-Erkennungswerkzeug installiert Treiber für alles, was es findet. Die Meinungen des Projekts leben unterhalb des Installers, nicht darin.
Der Standard-Kernel linux-cachyos wird mit Clang ThinLTO und AutoFDO-Profiling gebaut, und die Familie bietet BORE, EEVDF und BMQ als wählbare Scheduler an. Getrennt davon unterstützt es sched-ext, ein Framework zum Laden eines BPF-Schedulers aus dem User Space, ohne einen neuen Kernel zu bauen. Die beiden sind verschieden: sched-ext tauscht einen Scheduler zur Laufzeit aus; es ist kein vierter Eintrag in dieser Liste.
CachyOS kompiliert Archs Pakete außerdem für x86-64-v3, x86-64-v4 und Zen4+ neu, und sein Wiki beansprucht für x86-64-v3 einen Zugewinn von 5 % bis 20 % gegenüber der Basis. Das ist die Zahl von CachyOS für die eigene Arbeit, keine unabhängige Messung. Die neu gebauten Pakete liegen in einer CachyOS-Paketquelle, die über Archs core, extra und multilib gelegt wird, statt sie zu ersetzen. Überlagern statt ersetzen hält die Herkunft lesbar: Für jedes Paket lässt sich weiterhin sagen, welcher Kanal es gebaut hat.
Die Desktop-Shell ist die Schicht, die CachyOS nicht vorschreibt. Sie wählen die Umgebung, auch wenn mehrere Optionen mit von CachyOS gepflegten Einstellungen oder Dotfiles kommen. Sein Online-Installer bietet siebzehn oder mehr Umgebungen an, darunter KDE Plasma, GNOME, Hyprland, Niri, Sway und Xfce, und die Wahl liegt bei Ihnen. CachyOS Hello und der Kernel Manager sind Systemverwaltungswerkzeuge, keine Shell.
CachyOS verlangt keinen eigenen Update-Wrapper: Direktes pacman -Syu bleibt ein dokumentierter Weg, neben optionalen Werkzeugen wie Shelly, Octopi und Offline-Updates. Auf Btrfs installiert, legt CachyOS getrennte Subvolumes an und nutzt Snapper für Wiederherstellungs-Snapshots; unterstützte Bootloader-Setups können diese Snapshots zur Wiederherstellung anbieten.
Was Omarchy ändert
Omarchy ändert die Desktop-Shell-Schicht und die Update-Politik-Schicht stark, liefert einen eigenen Paketkanal und nimmt keine leistungsmotivierten Änderungen an Kernel oder Compile-Targets vor. Es installiert genau einen festen Desktop und übernimmt den Update-Befehl, statt Ihnen pacman zu überlassen.
Omarchy wird von einem eigenen ISO installiert, auf die ganze Platte oder in freien Speicherplatz neben einem anderen Betriebssystem, und es verschlüsselt die Platte standardmäßig. Der Installer stellt keine Desktop-Frage, weil es nur eine Antwort gibt.
Die Schicht Kernel und Compile-Targets bleibt weitgehend unangetastet. Omarchys eigenes Handbuch beschreibt es als Arch-basierte Distribution rund um Hyprland und Quickshell, und über seine Installer-, Update-, Dotfiles- und CLI-Seiten hinweg dokumentiert es keinen eigenen Kernel, kein Compile-Target und keine Scheduler-Auswahl. Auf gewöhnlicher Hardware läuft Omarchy mit den Stock-Arch-Kernelpaketen, die es wie den Rest des Systems von einem Arch-Mirror bezieht. Der einzige im Handbuch dokumentierte Kernel-Tausch dient der Hardware-Unterstützung: Auf Intel-Macs mit T2-Chip richtet der Installer einen gepatchten linux-t2-Kernel ein.
Die Paketquellen-Schicht ändert es durchaus, aber entlang einer anderen Achse als CachyOS. Omarchy wird als gewöhnliche pacman-Pakete aus seinem eigenen Package Repository installiert, und sein Standardkanal stable folgt einem Arch-Mirror, der einen Monat hinter dem neuesten Stand liegt, sodass Inkompatibilitäten zuerst upstream auftauchen. Drei weitere Kanäle (RC, edge und dev) tauschen diesen Puffer gegen Aktualität.
Hyprland und Quickshell kommen gemeinsam, ohne Opt-out. Hyprland ist der Tiling-Wayland-Compositor; Quickshell ist der Baukasten, aus dem Leiste, Launcher, Menüs, Benachrichtigungen und Sperrbildschirm gebaut sind, weshalb Omarchy in einem Release die ganze Shell austauschen kann, statt ein Theme auszuliefern. Diese Trennung gibt Omarchy eine reproduzierbare, vom Projekt definierte Basis und hält Ihre eigenen Anpassungen getrennt. Die Konfiguration teilt sich in zwei Hälften: Ihre Dotfiles in ~/.config, die Voreinstellungen des Projekts in /usr/share/omarchy, im Besitz des Pakets und beim Update überschrieben. Alles, was ein Update überleben soll, gehört auf Ihre Seite dieser Trennung.
Bei der Update-Politik ist Omarchys Position am schärfsten. Der Befehl omarchy update führt ausstehende Migrationen und Paket-Updates in einem Vorgang aus und legt vorher einen Snapshot an; Zurückrollen heißt, diesen Snapshot im Bootloader auszuwählen. Wer stattdessen zu pacman -Syu greift, stößt auf eine Sperre: Omarchy stoppt ein direktes Systemupgrade und verweist auf den eigenen Befehl, wobei das Handbuch sagt, die Sperre erkläre, wie man sie für eine einzelne Transaktion umgeht. Der Punkt ist die Kopplung: Die Migrationen reisen mit den Paket-Updates.
Warum die Vergleichs-Threads nie zusammenfinden
CachyOS und Omarchy berühren mehrere derselben Schichten, setzen ihre stärksten Änderungen aber an unterschiedlichen Stellen. CachyOS konzentriert sich auf Kernel, Compile-Targets und Paket-Builds; Omarchy konzentriert sich auf Desktop-Shell und Update-Workflow. „Welches ist besser“ presst diese getrennten Fragen zu einer zusammen.
Sie überschneiden sich in den Schichten Installer, Paketquellen und Wiederherstellung, aber nicht auf dieselbe Weise. CachyOS' Paketquelle ändert, wie Archs Pakete gebaut werden; Omarchys ändert, wann sie ankommen. CachyOS lässt direkte pacman-Updates verfügbar und legt Snapshots darum; Omarchy koppelt Paket-Updates, Migrationen und Snapshots hinter seinem eigenen Update-Befehl.
| Schicht | Stock-Arch | CachyOS | Omarchy |
|---|---|---|---|
| Installer | Manuelle Installationsanleitung oder geführtes archinstall; die Entscheidungen bleiben Ihre | Geführt: Desktop, Dateisystem, Bootmanager, Kernel, plus automatische Treibererkennung | ISO-basiert, ganze Platte oder freier Speicherplatz, verschlüsselt, keine Desktop-Wahl |
| Kernel und Compile-Targets | Stock-Kernel; Pakete für die Basis x86-64 gebaut | linux-cachyos-Builds, wählbare Scheduler, sched-ext, Pakete neu gebaut für x86-64-v3/v4, Zen4+ | Leistungsseitig unverändert: Stock-Kernel (gepatchtes linux-t2 auf T2-Macs), Basis-Builds |
| Paketquellen | Archs core, extra, multilib, mit dem AUR daneben | Eigene Paketquelle über denen von Arch | Eigene Paketquelle; stable folgt einem Mirror einen Monat im Rückstand |
| Desktop-Shell und Konfiguration | Nichts installiert; Sie wählen und bauen zusammen | Nichts vorgeschrieben; Installer bietet 17+ Umgebungen | Festes Hyprland und Quickshell; Voreinstellungen in /usr/share/omarchy |
| Update- und Rollback-Politik | pacman -Syu, wann Sie wollen; Wiederherstellung müssen Sie selbst einrichten | Direktes pacman -Syu unterstützt; optionale Update-Werkzeuge; Snapper-Wiederherstellung auf Btrfs | omarchy update erwartet; Snapshot bei jedem Update; direktes pacman -Syu gesperrt, Umgehung dokumentiert |
Die Schichten lassen sich mischen
Die fünf Schichten lassen sich getrennt übernehmen, statt einander auszuschließen. CachyOS veröffentlicht einen dokumentierten Weg, seine Paketquellen zu einer Arch-Installation hinzuzufügen und sie wieder zu entfernen. Omarchy ist eine Arch-Installation, also kann derselbe Weg CachyOS' optimierte Paketquellen darauf bringen.
Leute tun das. Ein Kommentator in einem Thread auf r/linux_gaming brachte es auf den Punkt: „There's nothing stopping you from installing the cachyos kernel and repositories on omarchy.“ Jemand hat ein Installationsskript für die Kombination veröffentlicht und auf Hacker News gepostet.
Unabhängigkeit im Prinzip ist keine Zuverlässigkeit in der Praxis. In einem r/omarchy-Thread über den Wechsel zwischen den beiden berichtete ein Kommentator, „All of the install scripts and such to do this are currently not working for many people“, und dass auch manuelles Eingreifen es nicht zum Laufen gebracht habe. Das ist eine Person in einem Thread, und die Art von Ärger, für die man planen sollte.
Die zweite Grenze betrifft, was die Kombination wert ist. Veröffentlichte Leistungsvergleiche zeigen beim Spielen kaum Unterschiede in den durchschnittlichen FPS, während breitere Gewinne aus CachyOS' Kernel, Schedulern und Compile-Targets workload-spezifisch bleiben statt automatisch.
Ob CachyOS' Kernel-Arbeit und Compile-Targets breiter einen nennenswerten Gewinn bringen, und für welche Klassen von Workloads, beruht auf einer anderen Beweislage, nicht auf der, die dieser Artikel klärt.
Entwickeln Sie auf einem Linux-VPS mit Root-Zugriff, NVMe und AMD-EPYC-Power.
Linux-Pläne ansehenWo EndeavourOS und Manjaro auf denselben Schichten liegen
EndeavourOS und Manjaro landen in eigenen Kombinationen auf denselben fünf Schichten, und das macht das Modell wertvoller als einen Vergleich zweier Projekte. EndeavourOS ändert die Installer-Schicht am stärksten, nutzt aber auch Dracut zur initramfs-Erzeugung und pflegt eine kleine Paketquelle für EndeavourOS-spezifische Werkzeuge und Pakete. Manjaro ändert die Paketquellen-Schicht am stärksten, den Installer etwas und die Compile-Target-Schicht gar nicht.
EndeavourOS beschreibt sich selbst als leichtgewichtiges, terminalzentriertes Arch-System, und was es hinzufügt, ist ein geführter Installer, ein kurzer kuratierter Paketsatz (Firefox, Yay, FirewallD, Pipewire) und ein eigenes Werkzeug für GPU- und VM-Treiber. Kein eigener Kernel, kein CPU-spezifischer Neubau von Archs allgemeinen Paketquellen, kein vorgeschriebener Desktop: Es bleibt von allen hier genannten Derivaten am nächsten am Stock-Arch.
Manjaros Selbstbeschreibung ist ein Ansatz kaskadierender Stabilität. Pakete durchlaufen die Zweige unstable, testing und stable in Manjaros eigenen Paketquellen, statt direkt denen von Arch zu folgen, weshalb ein Manjaro-Paket älter sein kann als das gleichnamige Arch-Paket. Sein Installer bietet eine Desktop-Wahl zwischen den offiziellen Editionen Plasma, GNOME und Xfce sowie den Community-Builds Cinnamon, i3 und Sway.
Es bringt außerdem ein Kernel-Werkzeug mit, und die Unterscheidung ist wichtig. Der Manjaro Settings Manager fügt Kernel hinzu und entfernt sie, sodass Sie eine andere vorgebaute Kernelversion laufen lassen können. Die Wahl zwischen paketierten Kernelversionen ist nicht dieselbe Operation wie das Neubauen von Paketen für einen neueren CPU-Befehlssatz, auch wenn beides in der Schicht Kernel und Compile-Targets liegt.
Dieses Zweigmodell ist auch das, was Manjaro von der Welt der festen Releases trennt. Manjaros Rolling-Modell gegen Ubuntu ist dieselbe Frage nach Paketquellen und Update-Politik, außerhalb der Arch-Familie gestellt. Dieselbe Rechnung funktioniert auch jenseits dieser Familie. Ubuntu leitet sich von Debian ab und unterscheidet sich davon bei Release-Rhythmus, Paketierungspolitik und Standard-Desktop.
Die Startseite eines neuen Derivats sagt Ihnen meist, welche dieser Schichten es berührt, und ob es etwas außerhalb dieses Fünf-Schichten-Modells ändert.
Häufig gestellte Fragen
Ist Omarchy eine echte Distribution oder nur Dotfiles?
Nach dem Fünf-Schichten-Test ist Omarchy mehr als eine Dotfiles-Sammlung. Es liefert einen eigenen ISO-Installer, eine eigene Paketquelle mit vier Release-Kanälen und eigene Update-Werkzeuge anstelle von pacman -Syu. Es nimmt keine leistungsmotivierten Änderungen an Kernel oder Compile-Targets vor: Der einzige im Handbuch dokumentierte Kernel-Tausch ist ein Hardware-Patch für Intel-Macs mit T2-Chip. Das System darunter ist ansonsten Stock-Arch. Ob das zusammen „eine Distribution“ ergibt, ist ein Streit um Etiketten.
Kann ich CachyOS' Kernel und Paketquellen auf Omarchy nutzen?
Technisch ja. CachyOS dokumentiert das Hinzufügen seiner Paketquellen zu einer bestehenden Arch-Installation, und Omarchy nutzt darunter Arch-Pakete. Das garantiert keine Kompatibilität: Omarchys verzögerter Paketkanal und Update-Workflow bringen ein weiteres bewegliches Teil ins Spiel, und ein r/omarchy-Kommentator berichtete, dass die Komfortskripte bei vielen fehlschlagen. Stellen Sie sich auf manuelles Eingreifen ein.
Zwingt mir CachyOS eine Desktop-Umgebung auf?
Nein. CachyOS überlässt Ihnen die Desktop-Wahl. Sein Online-Installer listet siebzehn oder mehr Optionen, von vollständigen Umgebungen wie KDE Plasma bis hinunter zu Tiling-Wayland-Compositoren wie Hyprland und Niri, und die Wahl fällt während der Installation. Die von CachyOS gepflegten Werkzeuge wie der Kernel Manager laufen auf dem Desktop, den Sie gewählt haben.
Was bedeutet x86-64-v3?
x86-64-v3 ist eine CPU-Mikroarchitekturstufe oberhalb der Basis x86-64. Sie setzt unter anderem AVX, AVX2, BMI1, BMI2 und FMA voraus, sodass speziell für v3 gebaute Software eine CPU braucht, die diesen Funktionsumfang unterstützt. Ein dafür kompiliertes Paket kann sie nutzen und startet nicht auf einem Prozessor, dem sie fehlen. CachyOS baut Archs Pakete für x86-64-v3 und x86-64-v4 neu und beansprucht für v3 einen Zugewinn von 5 % bis 20 %, was die Zahl des Projekts selbst ist.
Diskussion
Kommentare
Melden Sie sich an, um mitzudiskutieren.