Cosa cambiano le distro basate su Arch, strato per strato

Chiedi sul subreddit di CachyOS se installare CachyOS o Omarchy e le due risposte più votate non sono raccomandazioni. Una dice «Asking this in related to CachyOS sub…bruh». L'altra lo paragona a entrare in un forum Honda e chiedere se comprare una Accord o una Camry.

Entrambe le risposte hanno ragione, e il motivo è meccanico, non di atteggiamento. Le differenze tra distro basate su Arch si riducono a dove ciascun progetto modifica Arch di serie. Per le distribuzioni confrontate qui, quelle modifiche cadono per lo più in cinque punti: l'installer, il kernel e i target di compilazione, i repository dei pacchetti, la shell desktop e la configurazione, e la politica di aggiornamento e rollback. CachyOS e Omarchy fanno i loro cambiamenti più grandi in strati diversi.

La versione breve

• Per le distribuzioni confrontate qui, le differenze utili ricadono per lo più in cinque strati: installer, kernel e target di compilazione, repository dei pacchetti, shell desktop e configurazione, politica di aggiornamento e rollback.
• Un progetto può cambiare uno strato e lasciare intatti gli altri quattro, ed è così che due distribuzioni possono essere entrambe «basate su Arch» e non condividere quasi nulla.
• CachyOS cambia pesantemente gli strati kernel/compilazione e repository, cura l'installer e non impone alcuna shell desktop: scegli la tua al momento dell'installazione.
• Omarchy cambia pesantemente gli strati shell desktop e politica di aggiornamento, gestisce un proprio canale di pacchetti e non fa modifiche al kernel o ai target di compilazione motivate dalle prestazioni.
• Gli strati si possono adottare separatamente: CachyOS documenta come aggiungere i suoi repository a un'installazione Arch esistente, e c'è chi ha seguito quel percorso su Omarchy con risultati alterni.

Cosa questo articolo non risolve

Tre domande sono abbastanza vicine a questa da essere scambiate per essa, e ciascuna richiede un tipo di prova diverso da quello che una tassonomia può fornire.

• Se CachyOS è più veloce in generale. Quella domanda ha la sua base di prove e il suo articolo.
• Quale delle due dovresti installare.
• Ogni derivata di Arch esistente. Qui ne vengono nominate cinque, e questi cinque strati sono un modello di confronto per questo gruppo, non una tassonomia esaustiva di ogni derivata di Arch.

I cinque strati che questo confronto segue

Per le derivate confrontate qui, cinque strati spiegano la maggior parte delle differenze significative: l'installer, il kernel e i target di compilazione, i repository dei pacchetti, la shell desktop e la configurazione, e la politica di aggiornamento e rollback. Un progetto può cambiarne uno e lasciare gli altri quattro esattamente come li consegna Arch.

L'installer è il percorso dal metallo nudo a un sistema avviato, e lo strato in cui un progetto decide quante scelte lasciarti. Arch di serie documenta un percorso di installazione manuale e include anche l'installer guidato archinstall nella sua ISO live; una derivata può comunque sostituire quell'esperienza con i propri valori guidati. Ciò che conta è cosa quell'installer decide al posto tuo: filesystem, bootloader, cifratura, driver, desktop. Ogni impostazione predefinita è una posizione che qualcuno ha preso.

Lo strato kernel e target di compilazione copre tre cose che vengono confuse. Quale build del kernel avvii. Per quale set di istruzioni CPU sono stati compilati i tuoi pacchetti. Quale scheduler decide cosa gira e quando.

Un target di compilazione è il livello di microarchitettura per cui un pacchetto è stato costruito. x86-64 è la base che ogni processore x86-64 supporta. x86-64-v3 aggiunge funzionalità tra cui AVX, AVX2, BMI1, BMI2 e FMA, mentre x86-64-v4 aggiunge requisiti AVX-512 sopra v3. Un pacchetto costruito per uno di questi livelli non partirà su un processore privo del set di funzionalità richiesto. Lo scheduler decide quale task pronto ottiene il processore per primo, e gli scheduler bilanciano throughput e reattività interattiva in modo diverso. Una derivata può cambiare tutti e tre, uno solo o nessuno.

Lo strato dei repository dei pacchetti è una questione di provenienza: di chi è la build di un pacchetto che ricevi, quanto è fresca e chi controlla il canale attraverso cui arriva. Arch di serie prende i binari da core, extra e multilib, con l'AUR accanto come ricette di build che compili tu stesso. Una derivata può sovrapporre un proprio repository, mettere un ritardo deliberato davanti a quelli di Arch, o entrambe le cose.

Lo strato shell desktop e configurazione è ciò che appare sullo schermo e come è disposto, ed è qui che il vocabolario fa inciampare. Un ambiente desktop come KDE Plasma o GNOME è un pacchetto completo: gestione delle finestre, pannello, file manager, impostazioni, applicazioni. Un window manager tiling come i3, o un compositor Wayland tiling come Hyprland, gestisce il posizionamento delle finestre senza fornire una suite desktop completa, lasciando barra, launcher, notifiche e schermata di blocco come pezzi separati. Una derivata può imporre una shell, offrire un menu o non prendere posizione.

Lo strato aggiornamento e rollback copre come il sistema va avanti e come torni indietro quando va da qualche parte di sbagliato. Su Arch di serie entrambe le cose sono tue: pacman -Syu quando decidi tu, ripristino tramite la cache dei pacchetti o un sistema di snapshot che hai costruito. Una derivata può incapsulare quel comando, bloccarlo o lasciarlo in pace, e può rendere il ripristino un'impostazione predefinita organizzando il filesystem in modo che gli snapshot siano economici. È quello che ti dà una struttura a sottovolumi Btrfs: uno snapshot è una copia istantanea di un sottovolume, e con l'integrazione nel bootloader una derivata può esporre quegli snapshot come opzioni di ripristino.

Cosa cambia CachyOS

CachyOS cambia pesantemente lo strato kernel e target di compilazione e lo strato dei repository dei pacchetti, cura l'installer e non impone alcuna shell desktop. Fornisce le proprie build del kernel e ricompila i pacchetti di Arch per livelli di funzionalità CPU più recenti, poi lascia ciò che appare sullo schermo a chi la installa.

Il suo installer ti permette di scegliere desktop, filesystem e kernel, insieme a pacchetti e boot manager, e uno strumento di rilevamento hardware installa i driver per tutto ciò che trova. Le opinioni del progetto vivono sotto l'installer, non al suo interno.

Il kernel predefinito linux-cachyos è costruito con Clang ThinLTO e profilazione AutoFDO, e la famiglia offre BORE, EEVDF e BMQ come scheduler selezionabili. Separatamente, supporta sched-ext, un framework per caricare uno scheduler BPF dallo spazio utente senza costruire un nuovo kernel. Le due cose sono distinte: sched-ext sostituisce uno scheduler a runtime; non è una quarta voce in quell'elenco.

CachyOS ricompila anche i pacchetti di Arch per x86-64-v3, x86-64-v4 e Zen4+, e il suo wiki dichiara un guadagno dal 5% al 20% per x86-64-v3 rispetto alla base. È la cifra di CachyOS per il proprio lavoro, non una misurazione indipendente. I pacchetti ricompilati stanno in un repository CachyOS sovrapposto a core, extra e multilib di Arch invece di sostituirli. Sovrapporre invece di sostituire mantiene leggibile la provenienza: per qualsiasi pacchetto puoi ancora dire quale canale lo ha costruito.

La shell desktop è lo strato che CachyOS non impone. Scegli tu l'ambiente, anche se diverse opzioni arrivano con impostazioni o dotfile mantenuti da CachyOS. Il suo installer online offre diciassette o più ambienti, tra cui KDE Plasma, GNOME, Hyprland, Niri, Sway e Xfce, e la scelta è tua. CachyOS Hello e il Kernel Manager sono utilità di gestione del sistema, non una shell.

CachyOS non richiede un proprio wrapper di aggiornamento: pacman -Syu diretto resta un percorso documentato, accanto a strumenti opzionali come Shelly, Octopi e gli aggiornamenti offline. Installato su Btrfs, CachyOS organizza sottovolumi separati e usa Snapper per gli snapshot di ripristino; le configurazioni di bootloader supportate possono esporre quegli snapshot per il ripristino.

LEGGI

CachyOS è davvero più veloce? Da dove arrivano realmente i guadagni di prestazioni

Cosa cambia Omarchy

Omarchy cambia pesantemente lo strato shell desktop e lo strato politica di aggiornamento, fornisce un proprio canale di pacchetti e non fa modifiche motivate dalle prestazioni al kernel o ai target di compilazione. Installa un unico desktop fisso e prende in carico il comando di aggiornamento invece di lasciare pacman a te.

Omarchy si installa dalla propria ISO, su tutto il disco o nello spazio libero accanto a un altro sistema operativo, e cifra il disco per impostazione predefinita. L'installer non fa domande sul desktop, perché c'è una sola risposta.

Lo strato kernel e target di compilazione è in gran parte intatto. Il manuale di Omarchy la descrive come una distribuzione basata su Arch costruita attorno a Hyprland e Quickshell, e nelle sue pagine su installer, aggiornamento, dotfile e CLI non documenta alcun kernel personalizzato, alcun target di compilazione e alcuna selezione dello scheduler. Su hardware comune, Omarchy esegue i pacchetti del kernel Arch di serie, che le arrivano da un mirror Arch come il resto del sistema. L'unica sostituzione del kernel documentata dal manuale è per il supporto hardware: sui Mac Intel con chip T2, l'installer configura un kernel linux-t2 con patch.

Lo strato dei repository invece lo cambia, ma lungo un asse diverso da CachyOS. Omarchy si installa come normali pacchetti pacman dal proprio Package Repository, e il suo canale stable predefinito segue un mirror Arch indietro di un mese rispetto al più recente, così le incompatibilità emergono prima a monte. Altri tre canali (RC, edge e dev) scambiano quel cuscinetto con la freschezza.

Hyprland e Quickshell arrivano insieme, senza possibilità di rinuncia. Hyprland è il compositor Wayland tiling; Quickshell è il kit di costruzione con cui sono realizzati barra, launcher, menu, notifiche e schermata di blocco, ed è per questo che Omarchy può sostituire l'intera shell in una release invece di distribuire un tema. Quella separazione dà a Omarchy una base riproducibile definita dal progetto, mantenendo separate le tue personalizzazioni. La configurazione si divide in due: i tuoi dotfile in ~/.config, le impostazioni predefinite del progetto in /usr/share/omarchy, di proprietà del pacchetto e sovrascritte all'aggiornamento. Tutto ciò che vuoi far sopravvivere a un aggiornamento appartiene al tuo lato di quella divisione.

La politica di aggiornamento è dove la posizione di Omarchy è più netta. Il comando omarchy update esegue le migrazioni in sospeso e gli aggiornamenti dei pacchetti in un'unica operazione, facendo prima uno snapshot; tornare indietro significa scegliere quello snapshot nel bootloader. Ricorrere invece a pacman -Syu incontra un blocco: Omarchy ferma un aggiornamento diretto del sistema e ti rimanda al proprio comando, anche se il manuale dice che il blocco ti spiegherà come aggirarlo per una singola transazione. Il punto è l'accoppiamento: le migrazioni viaggiano insieme agli aggiornamenti dei pacchetti.

LEGGI

Perché Omarchy è osannato e odiato per le stesse ragioni

Perché le discussioni di confronto non convergono mai

CachyOS e Omarchy toccano diversi degli stessi strati, ma mettono i loro cambiamenti più forti in punti diversi. CachyOS si concentra su kernel, target di compilazione e build dei pacchetti; Omarchy si concentra su shell desktop e flusso di aggiornamento. «Quale è meglio» schiaccia quelle domande separate in una sola.

Si sovrappongono negli strati installer, repository e ripristino, ma non allo stesso modo. Il repository di CachyOS cambia come vengono costruiti i pacchetti di Arch; quello di Omarchy cambia quando arrivano. CachyOS lascia disponibili gli aggiornamenti pacman diretti e vi aggiunge attorno gli snapshot; Omarchy accoppia aggiornamenti dei pacchetti, migrazioni e snapshot dietro il proprio comando di aggiornamento.

Le due risposte in cima a quella discussione su CachyOS comprimevano esattamente questo: una diagnosi corretta, consegnata senza i cinque strati che ci stanno dietro.

Gli strati si possono mescolare

I cinque strati si possono adottare separatamente invece di escludersi a vicenda. CachyOS pubblica un percorso documentato per aggiungere i suoi repository a un'installazione Arch, e per rimuoverli di nuovo. Omarchy è un'installazione Arch, quindi lo stesso percorso può portare i repository ottimizzati di CachyOS su di essa.

C'è chi lo fa. Un commentatore in una discussione su r/linux_gaming l'ha detto chiaramente: «There's nothing stopping you from installing the cachyos kernel and repositories on omarchy». Qualcuno ha pubblicato uno script di installazione per la combinazione e lo ha postato su Hacker News.

L'indipendenza in linea di principio non è affidabilità in pratica. In una discussione su r/omarchy sul passaggio tra le due, un commentatore ha riferito che «All of the install scripts and such to do this are currently not working for many people», e che nemmeno l'intervento manuale l'aveva fatta funzionare. È una persona in una discussione, ed è il tipo di problema per cui vale la pena prepararsi.

Il secondo limite riguarda quanto vale la combinazione. I confronti di prestazioni pubblicati mostrano poca differenza negli FPS medi nei giochi, mentre i guadagni più ampi da kernel, scheduler e target di compilazione di CachyOS restano specifici del carico di lavoro invece che automatici.

Se il lavoro di CachyOS su kernel e target di compilazione produca un guadagno significativo più in generale, e per quali classi di carico di lavoro, poggia su una base di prove diversa, non quella che questo articolo risolve.

Costruisci su un VPS Linux con accesso root, NVMe e la potenza di AMD EPYC.

Vedi piani Linux

Dove si collocano EndeavourOS e Manjaro sugli stessi strati

EndeavourOS e Manjaro si collocano sugli stessi cinque strati con le proprie combinazioni, ed è questo che rende il modello più utile di un confronto tra due progetti. EndeavourOS cambia soprattutto lo strato dell'installer, ma usa anche Dracut per generare l'initramfs e mantiene un piccolo repository per strumenti e pacchetti specifici di EndeavourOS. Manjaro cambia soprattutto lo strato dei repository, un po' l'installer, e per nulla lo strato dei target di compilazione.

EndeavourOS si descrive come un sistema Arch leggero e incentrato sul terminale, e ciò che aggiunge è un installer guidato, un breve set curato di pacchetti (Firefox, Yay, FirewallD, Pipewire) e un proprio strumento per i driver GPU e VM. Nessun kernel personalizzato, nessuna ricompilazione mirata alla CPU dei repository generali di Arch, nessun desktop imposto: resta la più vicina ad Arch di serie tra tutte le derivate nominate qui.

L'impostazione di Manjaro è un approccio di stabilità a cascata. I pacchetti passano attraverso i rami unstable, testing e stable nei repository di Manjaro invece di seguire direttamente quelli di Arch, ed è per questo che un pacchetto Manjaro può essere più vecchio del pacchetto Arch con lo stesso nome. Il suo installer offre una scelta di desktop tra le edizioni ufficiali Plasma, GNOME e Xfce, più le build community Cinnamon, i3 e Sway.

Include anche uno strumento per il kernel, e la distinzione conta. Manjaro Settings Manager aggiunge e rimuove kernel, permettendoti di eseguire una diversa versione precompilata del kernel. Scegliere tra versioni del kernel pacchettizzate non è la stessa operazione che ricompilare i pacchetti per un set di istruzioni CPU più recente, anche se entrambe stanno nello strato kernel e target di compilazione.

Quel modello a rami è anche ciò che separa Manjaro dal mondo delle release fisse. Il modello rolling di Manjaro contro Ubuntu è la stessa domanda su repository e politica di aggiornamento posta fuori dalla famiglia Arch. La stessa contabilità funziona anche oltre quella famiglia. Ubuntu deriva da Debian e se ne distingue per cadenza di rilascio, politica di pacchettizzazione e desktop predefinito.

La home page di una nuova derivata di solito ti dice quali di questi strati tocca, e se cambia qualcosa al di fuori di questo modello a cinque strati.

Domande frequenti