Demandez sur le subreddit CachyOS s'il faut installer CachyOS ou Omarchy, et les deux réponses les mieux notées ne sont pas des recommandations. L'une dit « Asking this in related to CachyOS sub…bruh ». L'autre compare cela à entrer sur un forum Honda pour demander s'il faut acheter une Accord ou une Camry.
Les deux réponses ont raison, et la raison est mécanique plutôt qu'une question d'attitude. Les différences entre distributions basées sur Arch se résument à l'endroit où chaque projet modifie Arch d'origine. Pour les distributions comparées ici, ces modifications se concentrent surtout en cinq endroits : l'installateur, le noyau et les cibles de compilation, les dépôts de paquets, l'environnement de bureau et sa configuration, et la politique de mise à jour et de retour arrière. CachyOS et Omarchy font leurs plus gros changements dans des couches différentes.
La version courte
- Pour les distributions comparées ici, les différences utiles se répartissent surtout en cinq couches : installateur, noyau et cibles de compilation, dépôts de paquets, environnement de bureau et configuration, politique de mise à jour et de retour arrière.
- Un projet peut changer une couche et laisser les quatre autres intactes, ce qui explique comment deux distributions peuvent toutes deux être « basées sur Arch » et ne presque rien partager.
- CachyOS modifie lourdement les couches noyau/compilation et dépôts, soigne l'installateur et n'impose aucun environnement de bureau : vous choisissez le vôtre à l'installation.
- Omarchy modifie lourdement les couches environnement de bureau et politique de mise à jour, gère son propre canal de paquets et n'apporte aucun changement au noyau ou aux cibles de compilation motivé par la performance.
- Les couches s'adoptent séparément : CachyOS documente l'ajout de ses dépôts à une installation Arch existante, et des gens ont suivi ce chemin sur Omarchy avec des résultats mitigés.
Ce que cet article ne tranche pas
Trois questions sont assez proches de celle-ci pour être confondues avec elle, et chacune demande un autre type de preuve qu'une taxonomie ne peut fournir.
- Si CachyOS est plus rapide en général. Cette question a sa propre base de preuves et son propre article.
- Laquelle des deux vous devriez installer.
- Toutes les dérivées d'Arch qui existent. Cinq sont nommées ici, et ces cinq couches sont un modèle de comparaison pour ce groupe plutôt qu'une taxonomie exhaustive de toutes les dérivées d'Arch.
Les cinq couches suivies par cette comparaison
Pour les dérivées comparées ici, cinq couches expliquent l'essentiel des différences significatives : l'installateur, le noyau et les cibles de compilation, les dépôts de paquets, l'environnement de bureau et sa configuration, et la politique de mise à jour et de retour arrière. Un projet peut en changer une et laisser les quatre autres exactement telles qu'Arch les livre.
L'installateur est le chemin qui va du matériel nu à un système démarré, et la couche où un projet décide combien de choix il vous laisse. Arch d'origine documente un chemin d'installation manuel et inclut aussi l'installateur guidé archinstall sur son ISO live ; une dérivée peut malgré tout remplacer cette expérience par ses propres valeurs guidées. Ce qui compte, c'est ce que cet installateur décide à votre place : système de fichiers, chargeur d'amorçage, chiffrement, pilotes, bureau. Chaque valeur par défaut est une position que quelqu'un a prise.
La couche noyau et cibles de compilation couvre trois choses que l'on confond. Quel build de noyau vous démarrez. Contre quel jeu d'instructions CPU vos paquets ont été compilés. Quel ordonnanceur décide de ce qui s'exécute et quand.
Une cible de compilation est le niveau de microarchitecture pour lequel un paquet a été construit. x86-64 est la base que tout processeur x86-64 prend en charge. x86-64-v3 ajoute des fonctionnalités dont AVX, AVX2, BMI1, BMI2 et FMA, tandis que x86-64-v4 ajoute des exigences AVX-512 par-dessus v3. Un paquet construit pour l'un de ces niveaux ne démarrera pas sur un processeur dépourvu du jeu de fonctionnalités requis. L'ordonnanceur décide quelle tâche prête obtient ensuite le processeur, et les ordonnanceurs arbitrent différemment entre débit et réactivité interactive. Une dérivée peut changer les trois, un seul, ou aucun.
La couche des dépôts de paquets est une question de provenance : de qui vient le build d'un paquet que vous recevez, à quel point il est frais, et qui contrôle le canal par lequel il arrive. Arch d'origine tire ses binaires de core, extra et multilib, avec l'AUR à côté sous forme de recettes de build que vous compilez vous-même. Une dérivée peut superposer son propre dépôt, placer un délai délibéré devant ceux d'Arch, ou les deux.
La couche environnement de bureau et configuration, c'est ce qui apparaît à l'écran et comment c'est agencé, et c'est là que le vocabulaire fait trébucher. Un environnement de bureau comme KDE Plasma ou GNOME est un ensemble complet : gestion des fenêtres, panneau, gestionnaire de fichiers, réglages, applications. Un gestionnaire de fenêtres en mosaïque comme i3, ou un compositeur Wayland en mosaïque comme Hyprland, gère le placement des fenêtres sans fournir une suite bureautique complète, laissant la barre, le lanceur, les notifications et l'écran de verrouillage comme pièces séparées. Une dérivée peut imposer un shell, proposer un menu, ou ne prendre aucune position.
La couche mise à jour et retour arrière couvre la façon dont le système avance et la façon dont vous revenez en arrière quand il va quelque part de mauvais. Sur Arch d'origine, les deux vous appartiennent : pacman -Syu quand vous le décidez, récupération via le cache des paquets ou un dispositif d'instantanés que vous avez construit. Une dérivée peut envelopper cette commande, la verrouiller ou la laisser tranquille, et elle peut faire de la récupération un comportement par défaut en organisant le système de fichiers pour que les instantanés soient bon marché. C'est ce qu'apporte une organisation en sous-volumes Btrfs : un instantané est une copie à un instant donné d'un sous-volume, et avec l'intégration au chargeur d'amorçage, une dérivée peut exposer ces instantanés comme options de récupération.
Ce que CachyOS change
CachyOS modifie lourdement la couche noyau et cibles de compilation ainsi que la couche des dépôts de paquets, soigne l'installateur et n'impose aucun environnement de bureau. Il fournit ses propres builds de noyau et recompile les paquets d'Arch pour des niveaux de fonctionnalités CPU plus récents, puis laisse ce qui apparaît à l'écran à la personne qui l'installe.
Son installateur vous laisse choisir le bureau, le système de fichiers et le noyau, ainsi que les paquets et le gestionnaire d'amorçage, et un outil de détection matérielle installe les pilotes pour ce qu'il trouve. Les opinions du projet vivent sous l'installateur, pas à l'intérieur.
Le noyau linux-cachyos par défaut est construit avec Clang ThinLTO et un profilage AutoFDO, et la famille propose BORE, EEVDF et BMQ comme ordonnanceurs sélectionnables. Séparément, il prend en charge sched-ext, un cadre permettant de charger un ordonnanceur BPF depuis l'espace utilisateur sans construire un nouveau noyau. Les deux sont distincts : sched-ext échange un ordonnanceur à l'exécution ; ce n'est pas une quatrième entrée dans cette liste.
CachyOS recompile aussi les paquets d'Arch pour x86-64-v3, x86-64-v4 et Zen4+, et son wiki revendique un gain de 5 % à 20 % pour x86-64-v3 par rapport à la base. C'est le chiffre de CachyOS pour son propre travail, pas une mesure indépendante. Les paquets reconstruits se trouvent dans un dépôt CachyOS superposé aux dépôts core, extra et multilib d'Arch plutôt que de les remplacer. Superposer plutôt que remplacer garde la provenance lisible : pour tout paquet, vous pouvez encore dire quel canal l'a construit.
L'environnement de bureau est la couche que CachyOS n'impose pas. Vous choisissez l'environnement, même si plusieurs options sont livrées avec des réglages ou des dotfiles maintenus par CachyOS. Son installateur en ligne propose dix-sept environnements ou plus, dont KDE Plasma, GNOME, Hyprland, Niri, Sway et Xfce, et le choix vous appartient. CachyOS Hello et le Kernel Manager sont des utilitaires de gestion du système, pas un shell.
CachyOS n'exige pas son propre wrapper de mise à jour : pacman -Syu en direct reste un chemin documenté, aux côtés d'outils optionnels comme Shelly, Octopi et les mises à jour hors ligne. Installé sur Btrfs, CachyOS organise des sous-volumes séparés et utilise Snapper pour les instantanés de récupération ; les configurations de chargeur d'amorçage prises en charge peuvent exposer ces instantanés pour la récupération.
Ce qu'Omarchy change
Omarchy modifie lourdement la couche environnement de bureau et la couche politique de mise à jour, fournit son propre canal de paquets et n'apporte aucun changement motivé par la performance au noyau ou aux cibles de compilation. Il installe un bureau fixe unique et prend en charge la commande de mise à jour au lieu de vous laisser pacman.
Omarchy s'installe depuis sa propre ISO, sur tout le disque ou dans l'espace libre à côté d'un autre système d'exploitation, et il chiffre le disque par défaut. L'installateur ne pose aucune question sur le bureau, parce qu'il n'y a qu'une seule réponse.
La couche noyau et cibles de compilation est en grande partie intacte. Le manuel d'Omarchy le décrit lui-même comme une distribution basée sur Arch construite autour de Hyprland et Quickshell, et dans ses pages sur l'installateur, les mises à jour, les dotfiles et la CLI, il ne documente aucun noyau personnalisé, aucune cible de compilation et aucune sélection d'ordonnanceur. Sur du matériel ordinaire, Omarchy exécute les paquets de noyau Arch d'origine, qui lui parviennent depuis un miroir Arch comme le reste du système. La seule substitution de noyau documentée par le manuel relève de la prise en charge matérielle : sur les Mac Intel à puce T2, l'installateur met en place un noyau linux-t2 patché.
La couche des dépôts, il la change bel et bien, mais selon un axe différent de CachyOS. Omarchy s'installe sous forme de paquets pacman ordinaires depuis son propre Package Repository, et son canal stable par défaut suit un miroir Arch en retard d'un mois sur le plus récent, pour que les incompatibilités apparaissent d'abord en amont. Trois autres canaux (RC, edge et dev) échangent ce tampon contre de la fraîcheur.
Hyprland et Quickshell arrivent ensemble, sans possibilité de refus. Hyprland est le compositeur Wayland en mosaïque ; Quickshell est le kit de construction à partir duquel la barre, le lanceur, les menus, les notifications et l'écran de verrouillage sont bâtis, ce qui explique pourquoi Omarchy peut remplacer tout le shell dans une version plutôt que de livrer un thème. Cette séparation donne à Omarchy une base reproductible définie par le projet tout en gardant vos propres surcharges à part. La configuration se scinde en deux : vos dotfiles dans ~/.config, les valeurs par défaut du projet dans /usr/share/omarchy, appartenant au paquet et écrasées à la mise à jour. Tout ce que vous voulez voir survivre à une mise à jour appartient à votre côté de cette séparation.
La politique de mise à jour est l'endroit où la position d'Omarchy est la plus tranchée. La commande omarchy update exécute les migrations en attente et les mises à jour de paquets en une seule opération, en prenant d'abord un instantané ; revenir en arrière signifie choisir cet instantané dans le chargeur d'amorçage. Lancer pacman -Syu à la place se heurte à un garde-fou : Omarchy bloque une mise à niveau directe du système et vous renvoie vers sa propre commande, même si le manuel précise que le garde-fou vous indiquera comment le contourner pour une seule transaction. L'enjeu est le couplage : les migrations voyagent avec les mises à jour de paquets.
Pourquoi les fils de comparaison ne convergent jamais
CachyOS et Omarchy touchent plusieurs des mêmes couches, mais ils placent leurs changements les plus forts à des endroits différents. CachyOS se concentre sur le noyau, les cibles de compilation et les builds de paquets ; Omarchy se concentre sur l'environnement de bureau et le flux de mise à jour. « Lequel est le meilleur » écrase ces questions séparées en une seule.
Ils se recoupent sur les couches installateur, dépôts et récupération, mais pas de la même façon. Le dépôt de CachyOS change la façon dont les paquets d'Arch sont construits ; celui d'Omarchy change le moment où ils arrivent. CachyOS laisse les mises à jour pacman directes disponibles et ajoute des instantanés autour ; Omarchy couple mises à jour de paquets, migrations et instantanés derrière sa propre commande de mise à jour.
| Couche | Arch d'origine | CachyOS | Omarchy |
|---|---|---|---|
| Installateur | Guide d'installation manuelle ou archinstall guidé ; les choix restent les vôtres | Guidé : bureau, système de fichiers, gestionnaire d'amorçage, noyau, plus détection automatique des pilotes | Basé sur une ISO, disque entier ou espace libre, chiffré, pas de choix de bureau |
| Noyau et cibles de compilation | Noyau d'origine ; paquets construits pour la base x86-64 | Builds linux-cachyos, ordonnanceurs sélectionnables, sched-ext, paquets reconstruits pour x86-64-v3/v4, Zen4+ | Inchangé côté performance : noyau d'origine (linux-t2 patché sur les Mac T2), builds de base |
| Dépôts de paquets | core, extra, multilib d'Arch, avec l'AUR à côté | Dépôt propre superposé à ceux d'Arch | Dépôt propre ; stable suit un miroir en retard d'un mois |
| Environnement de bureau et configuration | Rien d'installé ; vous choisissez et assemblez | Rien d'imposé ; l'installateur propose 17+ environnements | Hyprland et Quickshell imposés ; valeurs par défaut dans /usr/share/omarchy |
| Politique de mise à jour et de retour arrière | pacman -Syu quand vous le choisissez ; la récupération est à vous d'organiser | pacman -Syu direct pris en charge ; outils de mise à jour optionnels ; récupération Snapper sur Btrfs | omarchy update attendu ; instantané à chaque mise à jour ; pacman -Syu direct bloqué, contournement documenté |
Les couches peuvent se combiner
Les cinq couches s'adoptent séparément plutôt que de s'exclure mutuellement. CachyOS publie un chemin documenté pour ajouter ses dépôts à une installation Arch, et pour les retirer ensuite. Omarchy est une installation Arch, donc le même chemin peut amener les dépôts optimisés de CachyOS dessus.
Des gens le font. Un commentateur dans un fil de r/linux_gaming l'a dit sans détour : « There's nothing stopping you from installing the cachyos kernel and repositories on omarchy. » Quelqu'un a publié un script d'installation pour la combinaison et l'a posté sur Hacker News.
L'indépendance en principe n'est pas la fiabilité en pratique. Dans un fil de r/omarchy sur le passage de l'un à l'autre, un commentateur a rapporté que « All of the install scripts and such to do this are currently not working for many people », et qu'une intervention manuelle ne l'avait pas non plus fait fonctionner. C'est une personne dans un fil, et le genre de problème qu'il vaut la peine d'anticiper.
La seconde limite porte sur ce que vaut la combinaison. Les comparaisons de performances publiées montrent peu d'écart de FPS moyen en jeu, tandis que les gains plus larges du noyau, des ordonnanceurs et des cibles de compilation de CachyOS restent spécifiques à la charge de travail plutôt qu'automatiques.
Savoir si le travail sur le noyau et les cibles de compilation de CachyOS produit un gain significatif plus largement, et pour quelles classes de charges de travail, repose sur une autre base de preuves, pas celle que cet article tranche.
Développez sur un VPS Linux avec accès root, NVMe et la puissance AMD EPYC.
Voir les plans LinuxOù se situent EndeavourOS et Manjaro sur les mêmes couches
EndeavourOS et Manjaro se placent sur les mêmes cinq couches dans leurs propres combinaisons, ce qui rend le modèle plus utile qu'une comparaison à deux projets. EndeavourOS modifie surtout la couche installateur, mais il utilise aussi Dracut pour générer l'initramfs et maintient un petit dépôt pour ses outils et paquets propres. Manjaro modifie surtout la couche des dépôts, un peu l'installateur, et pas du tout la couche des cibles de compilation.
EndeavourOS se décrit comme un système Arch léger et centré sur le terminal, et ce qu'il ajoute est un installateur guidé, un petit ensemble de paquets sélectionnés (Firefox, Yay, FirewallD, Pipewire) et son propre outil pour les pilotes GPU et VM. Pas de noyau personnalisé, pas de reconstruction ciblée CPU des dépôts généraux d'Arch, pas de bureau imposé : il reste le plus proche d'Arch d'origine de toutes les dérivées nommées ici.
Le cadre de Manjaro est une approche de stabilité en cascade. Les paquets passent par des branches unstable, testing et stable dans les propres dépôts de Manjaro plutôt que de suivre directement ceux d'Arch, ce qui explique pourquoi un paquet Manjaro peut être plus ancien que le paquet Arch du même nom. Son installateur propose un choix de bureau parmi les éditions officielles Plasma, GNOME et Xfce, plus les builds communautaires Cinnamon, i3 et Sway.
Il embarque aussi un outil de noyau, et la distinction compte. Manjaro Settings Manager ajoute et retire des noyaux, ce qui vous permet d'exécuter une autre version de noyau précompilée. Choisir parmi des versions de noyau empaquetées n'est pas la même opération que reconstruire des paquets pour un jeu d'instructions CPU plus récent, même si les deux relèvent de la couche noyau et cibles de compilation.
Ce modèle de branches est aussi ce qui sépare Manjaro du monde des versions fixes. Le modèle roulant de Manjaro face à Ubuntu est la même question de dépôts et de politique de mise à jour, posée hors de la famille Arch. La même comptabilité fonctionne aussi au-delà de cette famille. Ubuntu dérive de Debian et s'en distingue par la cadence de publication, la politique d'empaquetage et le bureau par défaut.
La page d'accueil d'une nouvelle dérivée vous dit généralement lesquelles de ces couches elle touche, et si elle change quelque chose en dehors de ce modèle à cinq couches.
Foire aux questions
Omarchy est-elle une vraie distribution, ou juste des dotfiles ?
Au test des cinq couches, Omarchy est plus qu'une collection de dotfiles. Elle fournit son propre installateur ISO, son propre dépôt de paquets avec quatre canaux de publication, et son propre outillage de mise à jour à la place de pacman -Syu. Elle n'apporte aucun changement motivé par la performance au noyau ou aux cibles de compilation : la seule substitution de noyau documentée par son manuel est un patch de prise en charge matérielle pour les Mac Intel à puce T2. Le système en dessous est par ailleurs de l'Arch d'origine. Savoir si cela fait « une distribution » est un débat d'étiquettes.
Puis-je faire tourner le noyau et les dépôts de CachyOS sur Omarchy ?
Techniquement, oui. CachyOS documente l'ajout de ses dépôts à une installation Arch existante, et Omarchy utilise des paquets Arch en dessous. Cela ne garantit pas la compatibilité : le canal de paquets différé et le flux de mise à jour d'Omarchy ajoutent une pièce mobile de plus, et un commentateur de r/omarchy a rapporté que les scripts de commodité échouaient pour beaucoup de monde. Préparez-vous à intervenir à la main.
CachyOS m'impose-t-elle un environnement de bureau ?
Non. CachyOS vous laisse le choix du bureau. Son installateur en ligne liste dix-sept options ou plus, des environnements complets comme KDE Plasma jusqu'aux compositeurs Wayland en mosaïque comme Hyprland et Niri, et le choix se fait à l'installation. Les outils que CachyOS maintient, comme le Kernel Manager, fonctionnent sur le bureau que vous avez choisi.
Que signifie x86-64-v3 ?
x86-64-v3 est un niveau de fonctionnalités de microarchitecture CPU au-dessus de la base x86-64. Il ajoute des exigences dont AVX, AVX2, BMI1, BMI2 et FMA, de sorte qu'un logiciel construit spécifiquement pour v3 a besoin d'un CPU qui prend en charge ce jeu de fonctionnalités. Un paquet compilé pour ce niveau peut les utiliser, et ne démarrera pas sur un processeur qui en est dépourvu. CachyOS reconstruit les paquets d'Arch pour x86-64-v3 et x86-64-v4 et revendique un gain de 5 % à 20 % pour v3, qui est le chiffre du projet lui-même.
Discussion
Commentaires
Connectez-vous pour participer à la discussion.