Mit változtatnak az Arch-alapú disztribúciók, rétegről rétegre

Kérdezze meg a CachyOS subredditen, hogy CachyOS-t vagy Omarchyt telepítsen-e, és a két legtöbbre értékelt válasz nem ajánlás lesz. Az egyik így szól: „Asking this in related to CachyOS sub…bruh.” A másik ahhoz hasonlítja, mintha valaki besétálna egy Honda-fórumra, és megkérdezné, Accordot vagy Camryt vegyen-e.

Mindkét válasznak igaza van, és az ok mechanikai, nem hozzáállásbeli. Az Arch-alapú disztribúciók különbségei arra futnak ki, hol módosítja az egyes projekt a gyári Archot. Az itt összehasonlított disztribúcióknál ezek a módosítások főként öt helyre esnek: a telepítő, a kernel és a fordítási célok, a csomagtárolók, az asztali héj és a konfiguráció, valamint a frissítési és visszaállítási szabályzat. A CachyOS és az Omarchy más-más rétegben hajtja végre a legnagyobb változtatásait.

A rövid verzió

• Az itt összehasonlított disztribúcióknál a hasznos különbségek főként öt rétegbe esnek: telepítő, kernel és fordítási célok, csomagtárolók, asztali héj és konfiguráció, frissítési és visszaállítási szabályzat.
• Egy projekt megváltoztathat egy réteget úgy, hogy a másik négyet békén hagyja, és így lehet két disztribúció egyszerre „Arch-alapú” úgy, hogy szinte semmi közös nincs bennük.
• A CachyOS erősen módosítja a kernel/fordítás és a tároló rétegeket, gondozza a telepítőt, és nem kényszerít rá asztali héjat: a sajátját telepítéskor választja ki.
• Az Omarchy erősen módosítja az asztali héj és a frissítési szabályzat rétegeit, saját csomagcsatornát üzemeltet, és nem hajt végre teljesítménycélú kernel- vagy fordításicél-módosításokat.
• A rétegek külön-külön átvehetők: a CachyOS dokumentálja, hogyan adhatók hozzá a tárolói egy meglévő Arch-telepítéshez, és voltak, akik vegyes eredménnyel járták végig ezt az utat Omarchyn.

Amit ez a cikk nem dönt el

Három kérdés elég közel áll ehhez ahhoz, hogy összekeverjék vele, és mindegyik másfajta bizonyítékot igényel, mint amit egy rendszerezés adhat.

• Hogy a CachyOS általában gyorsabb-e. Ennek a kérdésnek saját bizonyítékalapja és saját cikke van.
• Hogy a kettő közül melyiket telepítse.
• Minden létező Arch-származékot. Itt ötöt nevezünk meg, és ez az öt réteg erre a csoportra szabott összehasonlítási modell, nem az összes Arch-származék kimerítő rendszerezése.

Az öt réteg, amelyet ez az összehasonlítás követ

Az itt összehasonlított származékoknál öt réteg magyarázza a lényeges különbségek többségét: a telepítő, a kernel és a fordítási célok, a csomagtárolók, az asztali héj és a konfiguráció, valamint a frissítési és visszaállítási szabályzat. Egy projekt megváltoztathat egyet közülük úgy, hogy a másik négyet pontosan úgy hagyja, ahogy az Arch szállítja.

A telepítő a csupasz gépből bebootolt rendszerbe vezető út, és az a réteg, ahol egy projekt eldönti, hány választást hagy meg Önnek. A gyári Arch dokumentál egy kézi telepítési utat, és az élő ISO-ján ott van a vezetett archinstall telepítő is; egy származék ettől még lecserélheti ezt az élményt saját vezetett alapértelmezéseire. Az számít, mit dönt el a telepítő Ön helyett: fájlrendszer, rendszerbetöltő, titkosítás, illesztőprogramok, asztal. Minden alapértelmezés egy álláspont, amelyet valaki elfoglalt.

A kernel és fordítási célok rétege három, gyakran összemosott dolgot fed le. Melyik kernelbuildet bootolja. Milyen CPU-utasításkészletre fordították a csomagjait. Melyik ütemező dönti el, mi mikor fut.

A fordítási cél az a mikroarchitektúra-szint, amelyre egy csomagot építettek. Az x86-64 az az alap, amelyet minden x86-64 processzor támogat. Az x86-64-v3 olyan képességeket ad hozzá, mint az AVX, AVX2, BMI1, BMI2 és FMA, míg az x86-64-v4 a v3 fölé AVX-512-követelményeket tesz. Bármelyik szintre épített csomag nem indul el olyan processzoron, amelyből hiányzik a szükséges képességkészlet. Az ütemező dönti el, melyik futásra kész feladat kapja meg legközelebb a processzort, és az ütemezők eltérően súlyozzák az átbocsátást az interaktív válaszkészséggel szemben. Egy származék mindhármat megváltoztathatja, egyet vagy egyet sem.

A csomagtárolók rétege eredetkérdés: kinek a buildjét kapja egy csomagból, milyen friss, és ki irányítja a csatornát, amelyen érkezik. A gyári Arch a core, extra és multilib tárolókból húzza a binárisokat, mellettük az AUR-ral, amely saját kezűleg fordítandó build-receptek gyűjteménye. Egy származék rétegezhet fölé saját tárolót, szándékos késleltetést tehet az Arch tárolói elé, vagy mindkettőt.

Az asztali héj és konfiguráció rétege az, ami a képernyőn megjelenik, és ahogyan el van rendezve, és itt bicsaklik meg a szókincs. Egy asztali környezet, mint a KDE Plasma vagy a GNOME, teljes csomag: ablakkezelés, panel, fájlkezelő, beállítások, alkalmazások. Egy csempéző ablakkezelő, mint az i3, vagy egy csempéző Wayland-kompozitor, mint a Hyprland, az ablakok elhelyezését intézi anélkül, hogy teljes asztali csomagot adna, a sávot, indítót, értesítéseket és zárolási képernyőt külön darabokként hagyva. Egy származék rákényszeríthet egy héjat, kínálhat menüt, vagy nem foglalhat állást.

A frissítési és visszaállítási réteg azt fedi le, hogyan halad előre a rendszer, és hogyan jut vissza, ha rossz helyre került. A gyári Archon mindkettő az Öné: pacman -Syu, amikor úgy dönt, helyreállítás a csomag-gyorsítótárból vagy egy saját építésű pillanatkép-elrendezésből. Egy származék becsomagolhatja ezt a parancsot, kapuzhatja vagy békén hagyhatja, és alapértelmezetté teheti a helyreállítást azzal, hogy úgy rendezi el a fájlrendszert, hogy a pillanatképek olcsók legyenek. Ezt adja egy Btrfs-alkötet-elrendezés: a pillanatkép egyetlen alkötet adott pillanatbeli másolata, és rendszerbetöltő-integrációval egy származék ezeket a pillanatképeket helyreállítási lehetőségként kínálhatja.

Mit változtat a CachyOS

A CachyOS erősen módosítja a kernel és fordítási célok rétegét, valamint a csomagtárolók rétegét, gondozza a telepítőt, és nem kényszerít rá asztali héjat. Saját kernelbuildeket szállít, és újrafordítja az Arch csomagjait újabb CPU-képességszintekre, azt pedig, hogy mi jelenik meg a képernyőn, arra hagyja, aki telepíti.

A telepítője lehetővé teszi az asztal, a fájlrendszer és a kernel kiválasztását a csomagokkal és a rendszerbetöltő-kezelővel együtt, egy hardverfelismerő eszköz pedig illesztőprogramokat telepít mindenhez, amit talál. A projekt véleménye a telepítő alatt lakik, nem benne.

Az alapértelmezett linux-cachyos kernel Clang ThinLTO-val és AutoFDO-profilozással épül, a család pedig a BORE, EEVDF és BMQ ütemezőket kínálja választhatóként. Ettől külön támogatja a sched-ext-et, egy keretrendszert BPF-ütemező betöltésére felhasználói térből, új kernel építése nélkül. A kettő különbözik: a sched-ext futás közben cseréli az ütemezőt; nem negyedik elem abban a listában.

A CachyOS ezenkívül újrafordítja az Arch csomagjait x86-64-v3, x86-64-v4 és Zen4+ célokra, és a wikije 5–20% gyorsulást állít az x86-64-v3 esetében az alaphoz képest. Ez a CachyOS saját száma a saját munkájáról, nem független mérés. Az újraépített csomagok egy CachyOS-tárolóban ülnek, amely az Arch core, extra és multilib tárolói fölé rétegződik ahelyett, hogy lecserélné őket. A rétegezés a csere helyett olvashatóan tartja az eredetet: bármely csomagról továbbra is megmondható, melyik csatorna építette.

Az asztali héj az a réteg, amelyet a CachyOS nem kényszerít rá. Ön választja a környezetet, bár több lehetőség CachyOS által karbantartott beállításokkal vagy dotfile-okkal érkezik. Az online telepítője tizenhét vagy több környezetet kínál, köztük a KDE Plasmát, a GNOME-ot, a Hyprlandet, a Nirit, a Swayt és az Xfce-t, és a választás az Öné. A CachyOS Hello és a Kernel Manager rendszerkezelő segédeszközök, nem héj.

A CachyOS nem követel saját frissítési burkolót: a közvetlen pacman -Syu dokumentált út marad, olyan opcionális eszközök mellett, mint a Shelly, az Octopi és az offline frissítések. Btrfs-re telepítve a CachyOS külön alköteteket hoz létre, és a Snappert használja helyreállítási pillanatképekhez; a támogatott rendszerbetöltő-beállítások helyreállításhoz kínálhatják ezeket a pillanatképeket.

OLVASD

Tényleg gyorsabb a CachyOS? Honnan jön valójában a teljesítménynyereség

Mit változtat az Omarchy

Az Omarchy erősen módosítja az asztali héj rétegét és a frissítési szabályzat rétegét, saját csomagcsatornát szállít, és nem hajt végre teljesítménycélú változtatásokat a kernelen vagy a fordítási célokon. Egyetlen rögzített asztalt telepít, és átveszi a frissítési parancs tulajdonjogát ahelyett, hogy a pacmant Önre hagyná.

Az Omarchy saját ISO-ról települ, teljes lemezre vagy egy másik operációs rendszer melletti szabad helyre, és alapértelmezés szerint titkosítja a lemezt. A telepítő nem tesz fel asztallal kapcsolatos kérdést, mert csak egy válasz van.

A kernel és fordítási célok rétege nagyrészt érintetlen. Az Omarchy saját kézikönyve Hyprland és Quickshell köré épített Arch-alapú disztribúcióként írja le, és a telepítő-, frissítés-, dotfile- és CLI-oldalain nem dokumentál egyedi kernelt, fordítási célt vagy ütemezőválasztást. Hétköznapi hardveren az Omarchy a gyári Arch kernelcsomagokat futtatja, amelyek a rendszer többi részéhez hasonlóan egy Arch-tükörről érkeznek hozzá. Az egyetlen kernelcsere, amelyet a kézikönyv dokumentál, hardvertámogatási célú: T2 chipes Intel Maceken a telepítő foltozott linux-t2 kernelt állít be.

A tárolóréteget viszont igenis megváltoztatja, csak más tengely mentén, mint a CachyOS. Az Omarchy közönséges pacman-csomagokként települ a saját Package Repository-jából, és az alapértelmezett stable csatornája egy olyan Arch-tükröt követ, amely egy hónappal a legfrissebb mögött jár, így az inkompatibilitások előbb felfelé bukkannak elő. Három másik csatorna (RC, edge és dev) ezt a puffert frissességre cseréli.

A Hyprland és a Quickshell együtt érkezik, kimaradási lehetőség nélkül. A Hyprland a csempéző Wayland-kompozitor; a Quickshell az az építőkészlet, amelyből a sáv, az indító, a menük, az értesítések és a zárolási képernyő épül, ezért tudja az Omarchy egy kiadásban lecserélni az egész héjat ahelyett, hogy témát szállítana. Ez a szétválasztás reprodukálható, a projekt által meghatározott alapot ad az Omarchynak, miközben az Ön saját felülbírálásait külön tartja. A konfiguráció kettéválik: az Ön dotfile-jai a ~/.config alatt, a projekt alapértelmezései a /usr/share/omarchy alatt, csomag tulajdonában, és frissítéskor felülíródnak. Bármi, aminek túl kell élnie egy frissítést, ennek a szétválasztásnak az Ön oldalára tartozik.

A frissítési szabályzatnál a legélesebb az Omarchy álláspontja. Az omarchy update parancs egyetlen műveletben futtatja le a függőben lévő migrációkat és csomagfrissítéseket, előtte pillanatképet készítve; a visszaállítás azt jelenti, hogy ezt a pillanatképet választja ki a rendszerbetöltőben. Ha ehelyett a pacman -Syu után nyúl, egy védőkorlátba ütközik: az Omarchy leállítja a közvetlen rendszerfrissítést, és a saját parancsához irányítja, bár a kézikönyv szerint a védőkorlát megmondja, hogyan kerülhető meg egyetlen tranzakcióra. A lényeg a csatolás: a migrációk a csomagfrissítésekkel együtt utaznak.

OLVASD

Miért ünneplik és gyűlölik az Omarchyt ugyanazokért az okokért

Miért nem jutnak sosem dűlőre az összehasonlító szálak

A CachyOS és az Omarchy több ugyanolyan réteget érint, de a legerősebb változtatásaikat más helyre teszik. A CachyOS a kernelre, a fordítási célokra és a csomagbuildekre összpontosít; az Omarchy az asztali héjra és a frissítési munkafolyamatra. A „melyik a jobb” ezeket a különálló kérdéseket egyetlenegybe préseli.

A telepítő, tároló és helyreállítási rétegekben átfednek, de nem ugyanúgy. A CachyOS tárolója azt változtatja meg, hogyan épülnek az Arch csomagjai; az Omarchyé azt, mikor érkeznek. A CachyOS elérhetően hagyja a közvetlen pacman-frissítéseket, és pillanatképeket tesz köréjük; az Omarchy a csomagfrissítéseket, migrációkat és pillanatképeket a saját frissítési parancsa mögé csatolja.

Annak a CachyOS-szálnak a két legfelső válasza pontosan ezt sűrítette: helyes diagnózist, a mögötte álló öt réteg nélkül tálalva.

A rétegek keverhetők

Az öt réteg külön-külön átvehető, nem zárják ki egymást. A CachyOS dokumentált utat tesz közzé a tárolóinak Arch-telepítéshez adásához és újbóli eltávolításához. Az Omarchy egy Arch-telepítés, így ugyanez az út átviheti rá a CachyOS optimalizált tárolóit.

Vannak, akik megteszik. Egy hozzászóló egy r/linux_gaming szálban kereken kimondta: „There's nothing stopping you from installing the cachyos kernel and repositories on omarchy.” Valaki telepítőszkriptet készített a kombinációhoz, és közzétette a Hacker Newson.

Az elvi függetlenség nem gyakorlati megbízhatóság. Egy r/omarchy szálban a kettő közti váltásról egy hozzászóló arról számolt be, hogy „All of the install scripts and such to do this are currently not working for many people”, és hogy a kézi beavatkozás sem hozta működésbe. Ez egy ember egy szálban, és pont az a fajta gond, amellyel érdemes számolni.

A második korlát az, mit ér a kombináció. A közzétett teljesítmény-összehasonlítások a játékokban csekély átlag-FPS-különbséget mutatnak, míg a CachyOS kerneljéből, ütemezőiből és fordítási céljaiból származó szélesebb nyereség munkaterhelés-függő marad, nem automatikus.

Hogy a CachyOS kernelmunkája és fordítási céljai szélesebb körben, és mely munkaterhelés-osztályoknál hoznak érdemi nyereséget, más bizonyítékalapon nyugszik, nem azon, amelyet ez a cikk eldönt.

Hol helyezkedik el az EndeavourOS és a Manjaro ugyanezeken a rétegeken

Az EndeavourOS és a Manjaro ugyanerre az öt rétegre esik a maguk kombinációiban, és ettől ér többet a modell egy kétprojektes összehasonlításnál. Az EndeavourOS leginkább a telepítőréteget változtatja, de Dracutot is használ az initramfs generálásához, és kis tárolót tart fenn az EndeavourOS-specifikus eszközöknek és csomagoknak. A Manjaro leginkább a tárolóréteget változtatja, a telepítőt valamennyire, a fordításicél-réteget pedig egyáltalán nem.

Az EndeavourOS könnyűsúlyú, terminálközpontú Arch-rendszerként írja le magát, és amit hozzáad, az egy vezetett telepítő, egy rövid, válogatott csomagkészlet (Firefox, Yay, FirewallD, Pipewire) és saját eszköz a GPU- és VM-illesztőprogramokhoz. Nincs egyedi kernel, nincs CPU-célzott újraépítése az Arch általános tárolóinak, nincs rákényszerített asztal: az itt megnevezett származékok közül továbbra is ez áll legközelebb a gyári Archhoz.

A Manjaro önmeghatározása a lépcsőzetes stabilitás megközelítése. A csomagok az unstable, testing és stable ágakon haladnak át a Manjaro saját tárolóiban ahelyett, hogy közvetlenül az Archéit követnék, ezért lehet egy Manjaro-csomag régebbi az azonos nevű Arch-csomagnál. A telepítője asztalválasztást kínál a hivatalos Plasma, GNOME és Xfce kiadások, valamint a közösségi Cinnamon, i3 és Sway buildek közül.

Kerneleszközt is hordoz, és a különbségtétel számít. A Manjaro Settings Manager kerneleket ad hozzá és távolít el, így más előre épített kernelverziót futtathat. A csomagolt kernelverziók közötti választás nem ugyanaz a művelet, mint a csomagok újraépítése egy újabb CPU-utasításkészletre, bár mindkettő a kernel és fordítási célok rétegében ül.

Ez az ágmodell választja el a Manjarót a rögzített kiadások világától is. A Manjaro gördülő modellje az Ubuntuval szemben ugyanaz a tároló- és frissítésiszabályzat-kérdés, az Arch-családon kívül feltéve. Ugyanez a számvetés a családon túl is működik. Az Ubuntu a Debianból származik, és kiadási ütemben, csomagolási szabályzatban és alapértelmezett asztalban tér el tőle.

Egy új származék nyitóoldala általában megmondja, ezek közül mely rétegeket érinti, és változtat-e valamit ezen az ötrétegű modellen kívül.

Gyakran ismételt kérdések

Igazi disztribúció az Omarchy, vagy csak dotfile-ok?

Az ötréteges próbán az Omarchy több, mint dotfile-gyűjtemény. Saját ISO-telepítőt, saját, négy kiadási csatornás csomagtárolót és saját frissítőeszközöket szállít a pacman -Syu helyett. Nem hajt végre teljesítménycélú kernel- vagy fordításicél-módosításokat: az egyetlen kernelcsere, amelyet a kézikönyve dokumentál, egy hardvertámogatási folt a T2 chipes Intel Macekhez. Az alatta lévő rendszer egyébként gyári Arch. Hogy ez kitesz-e „egy disztribúciót”, címkevita.

Futtathatom a CachyOS kernelét és tárolóit Omarchyn?

Technikailag igen. A CachyOS dokumentálja a tárolói hozzáadását egy meglévő Arch-telepítéshez, és az Omarchy alatta Arch-csomagokat használ. Ez nem garantál kompatibilitást: az Omarchy késleltetett csomagcsatornája és frissítési munkafolyamata újabb mozgó alkatrészt ad hozzá, és egy r/omarchy hozzászóló arról számolt be, hogy a kényelmi szkriptek sokaknál hibáznak. Készüljön kézi beavatkozásra.

Rám kényszerít a CachyOS egy asztali környezetet?

Nem. A CachyOS Önre hagyja az asztalválasztást. Az online telepítője tizenhét vagy több lehetőséget sorol fel, a teljes környezetektől, mint a KDE Plasma, a csempéző Wayland-kompozitorokig, mint a Hyprland és a Niri, és a választás a telepítés során történik. A CachyOS által karbantartott eszközök, például a Kernel Manager, azon az asztalon futnak, amelyet választott.

Mit jelent az x86-64-v3?

Az x86-64-v3 egy CPU-mikroarchitektúra-képességszint az x86-64 alap fölött. Olyan követelményeket ad hozzá, mint az AVX, AVX2, BMI1, BMI2 és FMA, így a kifejezetten v3-ra épített szoftvernek olyan CPU kell, amely támogatja ezt a képességkészletet. Az erre fordított csomag használhatja őket, és nem indul el olyan processzoron, amelyből hiányoznak. A CachyOS x86-64-v3 és x86-64-v4 célokra építi újra az Arch csomagjait, és 5–20% gyorsulást állít a v3 esetében, ami a projekt saját száma.