Co zmieniają dystrybucje oparte na Arch, warstwa po warstwie

Zapytaj na subreddicie CachyOS, czy zainstalować CachyOS czy Omarchy, a dwie najwyżej ocenione odpowiedzi nie będą rekomendacjami. Jedna brzmi „Asking this in related to CachyOS sub…bruh”. Druga porównuje to do wejścia na forum Hondy z pytaniem, czy kupić Accorda czy Camry.

Obie odpowiedzi mają rację, a powód jest mechaniczny, nie kwestią nastawienia. Różnice między dystrybucjami opartymi na Arch sprowadzają się do tego, gdzie każdy projekt modyfikuje bazowego Archa. W porównywanych tu dystrybucjach te modyfikacje trafiają głównie w pięć miejsc: instalator, jądro i cele kompilacji, repozytoria pakietów, powłokę pulpitu i konfigurację oraz politykę aktualizacji i wycofywania. CachyOS i Omarchy wprowadzają największe zmiany w różnych warstwach.

Krótka wersja

• W porównywanych tu dystrybucjach użyteczne różnice mieszczą się głównie w pięciu warstwach: instalator, jądro i cele kompilacji, repozytoria pakietów, powłoka pulpitu i konfiguracja, polityka aktualizacji i wycofywania.
• Projekt może zmienić jedną warstwę i zostawić pozostałe cztery w spokoju, i właśnie dlatego dwie dystrybucje mogą być obie „oparte na Arch” i nie mieć ze sobą prawie nic wspólnego.
• CachyOS mocno zmienia warstwy jądra/kompilacji i repozytoriów, dopracowuje instalator i nie narzuca powłoki pulpitu: własną wybierasz podczas instalacji.
• Omarchy mocno zmienia warstwy powłoki pulpitu i polityki aktualizacji, prowadzi własny kanał pakietów i nie wprowadza do jądra ani celów kompilacji zmian motywowanych wydajnością.
• Warstwy można przejmować osobno: CachyOS dokumentuje dodawanie swoich repozytoriów do istniejącej instalacji Archa, a ludzie przechodzili tę ścieżkę na Omarchy z mieszanym skutkiem.

Czego ten artykuł nie rozstrzyga

Trzy pytania leżą na tyle blisko tego, że można je z nim pomylić, a każde wymaga innego rodzaju dowodu, niż może dostarczyć taksonomia.

• Czy CachyOS jest ogólnie szybszy. To pytanie ma własną bazę dowodową i własny artykuł.
• Który z dwóch powinieneś zainstalować.
• Każdą istniejącą pochodną Archa. Wymieniono tu pięć, a te pięć warstw to model porównawczy dla tej grupy, a nie wyczerpująca taksonomia wszystkich pochodnych Archa.

Pięć warstw, które śledzi to porównanie

W porównywanych tu pochodnych pięć warstw wyjaśnia większość istotnych różnic: instalator, jądro i cele kompilacji, repozytoria pakietów, powłokę pulpitu i konfigurację oraz politykę aktualizacji i wycofywania. Projekt może zmienić jedną z nich i zostawić pozostałe cztery dokładnie takimi, jakimi dostarcza je Arch.

Instalator to droga od gołego sprzętu do uruchomionego systemu i warstwa, w której projekt decyduje, ile wyborów ci zostawi. Bazowy Arch dokumentuje ręczną ścieżkę instalacji, a na swoim obrazie live zawiera też prowadzony instalator archinstall; pochodna wciąż może zastąpić to doświadczenie własnymi prowadzonymi ustawieniami domyślnymi. Liczy się to, co ten instalator ustala za ciebie: system plików, bootloader, szyfrowanie, sterowniki, pulpit. Każde ustawienie domyślne to stanowisko, które ktoś zajął.

Warstwa jądra i celów kompilacji obejmuje trzy rzeczy, które się myli. Którą kompilację jądra uruchamiasz. Pod jaki zestaw instrukcji CPU skompilowano twoje pakiety. Który planista decyduje, co i kiedy działa.

Cel kompilacji to poziom mikroarchitektury, pod który zbudowano pakiet. x86-64 to baza, którą obsługuje każdy procesor x86-64. x86-64-v3 dodaje funkcje, między innymi AVX, AVX2, BMI1, BMI2 i FMA, a x86-64-v4 dokłada ponad v3 wymagania AVX-512. Pakiet zbudowany pod którykolwiek z tych poziomów nie uruchomi się na procesorze pozbawionym wymaganego zestawu funkcji. Planista decyduje, które gotowe zadanie dostanie procesor jako następne, a planiści różnie ważą przepustowość względem interaktywnej responsywności. Pochodna może zmienić wszystkie trzy, jedną albo żadną.

Warstwa repozytoriów pakietów to kwestia pochodzenia: czyją kompilację pakietu dostajesz, jak jest świeża i kto kontroluje kanał, którym dociera. Bazowy Arch pobiera binaria z core, extra i multilib, a obok leży AUR jako przepisy kompilacji, które budujesz sam. Pochodna może nałożyć własne repozytorium, wstawić celowe opóźnienie przed repozytoriami Archa albo jedno i drugie.

Warstwa powłoki pulpitu i konfiguracji to to, co pojawia się na ekranie i jak jest ułożone, i właśnie tu słownictwo podkłada ludziom nogę. Środowisko graficzne takie jak KDE Plasma czy GNOME to kompletny pakiet: zarządzanie oknami, panel, menedżer plików, ustawienia, aplikacje. Kafelkowy menedżer okien jak i3 albo kafelkowy kompozytor Wayland jak Hyprland zajmuje się rozmieszczaniem okien bez dostarczania pełnego zestawu pulpitu, zostawiając pasek, launcher, powiadomienia i ekran blokady jako osobne elementy. Pochodna może narzucić powłokę, zaoferować menu albo nie zajmować stanowiska.

Warstwa aktualizacji i wycofywania obejmuje to, jak system idzie naprzód i jak wracasz, gdy trafi gdzieś nie tam. W bazowym Archu jedno i drugie należy do ciebie: pacman -Syu, kiedy zdecydujesz, odzyskiwanie przez pamięć podręczną pakietów albo układ migawek, który sam zbudowałeś. Pochodna może opakować to polecenie, zablokować je albo zostawić w spokoju, a odzyskiwanie uczynić domyślnym, układając system plików tak, żeby migawki były tanie. To właśnie daje układ podwolumenów Btrfs: migawka to kopia jednego podwolumenu z danej chwili, a z integracją z bootloaderem pochodna może wystawiać te migawki jako opcje odzyskiwania.

Co zmienia CachyOS

CachyOS mocno zmienia warstwę jądra i celów kompilacji oraz warstwę repozytoriów pakietów, dopracowuje instalator i nie narzuca powłoki pulpitu. Dostarcza własne kompilacje jądra i rekompiluje pakiety Archa pod nowsze poziomy funkcji CPU, a to, co pojawia się na ekranie, zostawia temu, kto go instaluje.

Jego instalator pozwala wybrać pulpit, system plików i jądro, a także pakiety i menedżer rozruchu, a narzędzie wykrywania sprzętu instaluje sterowniki do tego, co znajdzie. Opinie projektu żyją poniżej instalatora, nie w nim.

Domyślne jądro linux-cachyos jest budowane z Clang ThinLTO i profilowaniem AutoFDO, a rodzina oferuje BORE, EEVDF i BMQ jako planistów do wyboru. Osobno obsługuje sched-ext, framework do ładowania planisty BPF z przestrzeni użytkownika bez budowania nowego jądra. To dwie różne rzeczy: sched-ext podmienia planistę w czasie działania; nie jest czwartą pozycją na tej liście.

CachyOS rekompiluje też pakiety Archa pod x86-64-v3, x86-64-v4 i Zen4+, a jego wiki deklaruje wzrost wydajności od 5% do 20% dla x86-64-v3 względem bazy. To własna liczba CachyOS dotycząca własnej pracy, nie niezależny pomiar. Przebudowane pakiety leżą w repozytorium CachyOS nałożonym na core, extra i multilib Archa, zamiast je zastępować. Nakładanie zamiast zastępowania utrzymuje czytelność pochodzenia: o każdym pakiecie nadal można powiedzieć, który kanał go zbudował.

Powłoka pulpitu to warstwa, której CachyOS nie narzuca. Środowisko wybierasz sam, choć kilka opcji jest dostarczanych z ustawieniami lub dotfiles utrzymywanymi przez CachyOS. Jego instalator online oferuje siedemnaście lub więcej środowisk, w tym KDE Plasma, GNOME, Hyprland, Niri, Sway i Xfce, a wybór należy do ciebie. CachyOS Hello i Kernel Manager to narzędzia do zarządzania systemem, nie powłoka.

CachyOS nie wymaga własnej nakładki na aktualizacje: bezpośredni pacman -Syu pozostaje udokumentowaną ścieżką, obok opcjonalnych narzędzi takich jak Shelly, Octopi i aktualizacje offline. Zainstalowany na Btrfs CachyOS rozkłada osobne podwolumeny i używa Snappera do migawek odzyskiwania; obsługiwane konfiguracje bootloadera mogą wystawiać te migawki do odzyskiwania.

CZYTAJ

Czy CachyOS naprawdę jest szybszy? Skąd faktycznie bierze się wzrost wydajności

Co zmienia Omarchy

Omarchy mocno zmienia warstwę powłoki pulpitu i warstwę polityki aktualizacji, dostarcza własny kanał pakietów i nie wprowadza do jądra ani celów kompilacji zmian motywowanych wydajnością. Instaluje jeden stały pulpit i przejmuje polecenie aktualizacji, zamiast zostawić ci pacmana.

Omarchy instaluje się z własnego obrazu ISO, na cały dysk albo w wolne miejsce obok innego systemu operacyjnego, i domyślnie szyfruje dysk. Instalator nie zadaje pytania o pulpit, bo odpowiedź jest tylko jedna.

Warstwa jądra i celów kompilacji pozostaje w dużej mierze nietknięta. Własny podręcznik Omarchy opisuje go jako dystrybucję opartą na Arch zbudowaną wokół Hyprlanda i Quickshella, a na stronach o instalatorze, aktualizacjach, dotfiles i CLI nie dokumentuje żadnego własnego jądra, celu kompilacji ani wyboru planisty. Na zwykłym sprzęcie Omarchy działa na bazowych pakietach jądra Archa, które trafiają do niego z serwera lustrzanego Archa, jak reszta systemu. Jedyna podmiana jądra udokumentowana w podręczniku służy obsłudze sprzętu: na Macach z Intelem i układem T2 instalator konfiguruje załatane jądro linux-t2.

Warstwę repozytoriów owszem zmienia, ale wzdłuż innej osi niż CachyOS. Omarchy instaluje się jako zwykłe pakiety pacmana z własnego Package Repository, a jego domyślny kanał stable śledzi serwer lustrzany Archa opóźniony o miesiąc względem najnowszego, dzięki czemu niezgodności wypływają najpierw wyżej w łańcuchu. Trzy inne kanały (RC, edge i dev) wymieniają ten bufor na świeżość.

Hyprland i Quickshell przychodzą razem, bez możliwości rezygnacji. Hyprland to kafelkowy kompozytor Wayland; Quickshell to zestaw konstrukcyjny, z którego zbudowano pasek, launcher, menu, powiadomienia i ekran blokady, i dlatego Omarchy może w jednym wydaniu wymienić całą powłokę zamiast wypuszczać motyw. Ten podział daje Omarchy odtwarzalną bazę zdefiniowaną przez projekt, a twoje własne nadpisania trzyma osobno. Konfiguracja dzieli się na dwie części: twoje dotfiles w ~/.config i domyślne ustawienia projektu w /usr/share/omarchy, należące do pakietu i nadpisywane przy aktualizacji. Wszystko, co ma przetrwać aktualizację, należy do twojej strony tego podziału.

Polityka aktualizacji to miejsce, gdzie stanowisko Omarchy jest najostrzejsze. Polecenie omarchy update wykonuje oczekujące migracje i aktualizacje pakietów w jednej operacji, najpierw robiąc migawkę; wycofanie oznacza wybranie tej migawki w bootloaderze. Sięgnięcie zamiast tego po pacman -Syu napotyka blokadę: Omarchy zatrzymuje bezpośrednią aktualizację systemu i odsyła cię do własnego polecenia, choć podręcznik mówi, że blokada podpowie, jak ją obejść dla pojedynczej transakcji. Chodzi o sprzężenie: migracje podróżują razem z aktualizacjami pakietów.

CZYTAJ

Dlaczego Omarchy jest wychwalane i znienawidzone z tych samych powodów

Dlaczego wątki porównawcze nigdy się nie zbiegają

CachyOS i Omarchy dotykają kilku tych samych warstw, ale najmocniejsze zmiany umieszczają w różnych miejscach. CachyOS skupia się na jądrze, celach kompilacji i kompilacjach pakietów; Omarchy skupia się na powłoce pulpitu i przepływie aktualizacji. „Który jest lepszy” zgniata te osobne pytania w jedno.

Nakładają się w warstwach instalatora, repozytoriów i odzyskiwania, ale nie w ten sam sposób. Repozytorium CachyOS zmienia to, jak budowane są pakiety Archa; repozytorium Omarchy zmienia to, kiedy docierają. CachyOS zostawia bezpośrednie aktualizacje pacmanem dostępne i dokłada wokół nich migawki; Omarchy sprzęga aktualizacje pakietów, migracje i migawki za własnym poleceniem aktualizacji.

Dwie górne odpowiedzi w tamtym wątku o CachyOS kompresowały dokładnie to: trafną diagnozę, podaną bez stojących za nią pięciu warstw.

Warstwy można mieszać

Pięć warstw można przejmować osobno, zamiast wybierać jedno albo drugie. CachyOS publikuje udokumentowaną ścieżkę dodawania swoich repozytoriów do instalacji Archa i ich późniejszego usuwania. Omarchy to instalacja Archa, więc tą samą ścieżką można przenieść na nie zoptymalizowane repozytoria CachyOS.

Ludzie to robią. Komentujący w wątku na r/linux_gaming ujął to wprost: „There's nothing stopping you from installing the cachyos kernel and repositories on omarchy”. Ktoś wypuścił skrypt instalacyjny dla tego połączenia i opublikował go na Hacker News.

Niezależność w zasadzie to nie to samo co niezawodność w praktyce. W wątku na r/omarchy o przechodzeniu między nimi jeden z komentujących zgłosił, że „All of the install scripts and such to do this are currently not working for many people”, a ręczna interwencja też nie doprowadziła do działania. To jedna osoba w jednym wątku i taki rodzaj kłopotów, na który warto się przygotować.

Drugie ograniczenie dotyczy tego, ile to połączenie jest warte. Opublikowane porównania wydajności pokazują niewielką różnicę w średnim FPS w grach, a szersze zyski z jądra, planistów i celów kompilacji CachyOS pozostają zależne od obciążenia, a nie automatyczne.

To, czy praca CachyOS nad jądrem i celami kompilacji daje istotny zysk w szerszym ujęciu i dla jakich klas obciążeń, opiera się na innej bazie dowodowej, nie tej, którą rozstrzyga ten artykuł.

Twórz na VPS Linux z dostępem root, NVMe i mocą AMD EPYC.

Zobacz plany Linux

Gdzie w tych samych warstwach mieszczą się EndeavourOS i Manjaro

EndeavourOS i Manjaro trafiają w te same pięć warstw we własnych kombinacjach, i to właśnie sprawia, że model jest wart więcej niż porównanie dwóch projektów. EndeavourOS najbardziej zmienia warstwę instalatora, ale używa też Dracuta do generowania initramfs i utrzymuje małe repozytorium narzędzi i pakietów specyficznych dla EndeavourOS. Manjaro najbardziej zmienia warstwę repozytoriów, instalator w pewnym stopniu, a warstwę celów kompilacji wcale.

EndeavourOS opisuje się jako lekki, skupiony na terminalu system oparty na Arch, a to, co dodaje, to prowadzony instalator, krótki wyselekcjonowany zestaw pakietów (Firefox, Yay, FirewallD, Pipewire) i własne narzędzie do sterowników GPU i maszyn wirtualnych. Żadnego własnego jądra, żadnej ukierunkowanej na CPU przebudowy ogólnych repozytoriów Archa, żadnego narzuconego pulpitu: ze wszystkich wymienionych tu pochodnych pozostaje najbliżej bazowego Archa.

Manjaro określa swoje podejście jako kaskadową stabilność. Pakiety przechodzą przez gałęzie unstable, testing i stable we własnych repozytoriach Manjaro, zamiast bezpośrednio śledzić repozytoria Archa, i dlatego pakiet Manjaro może być starszy niż pakiet Archa o tej samej nazwie. Jego instalator oferuje wybór pulpitu spośród oficjalnych edycji Plasma, GNOME i Xfce oraz społecznościowych kompilacji Cinnamon, i3 i Sway.

Ma też narzędzie do jądra, a to rozróżnienie ma znaczenie. Manjaro Settings Manager dodaje i usuwa jądra, pozwalając uruchomić inną prekompilowaną wersję jądra. Wybór spośród spakietowanych wersji jądra to nie ta sama operacja co przebudowa pakietów pod nowszy zestaw instrukcji CPU, choć obie mieszczą się w warstwie jądra i celów kompilacji.

Ten model gałęzi to także to, co oddziela Manjaro od świata wydań stałych. Model kroczący Manjaro wobec Ubuntu to to samo pytanie o repozytoria i politykę aktualizacji, zadane poza rodziną Archa. Ten sam rachunek działa też poza tą rodziną. Ubuntu wywodzi się z Debiana i różni się od niego rytmem wydań, polityką pakowania i domyślnym pulpitem.

Strona główna nowej pochodnej zwykle mówi, których z tych warstw dotyka i czy zmienia coś poza tym pięciowarstwowym modelem.

Często zadawane pytania