Az Intel Clear Linux disztribúciója az utóbbi időben nagy figyelmet kapott, köszönhetően a rendhagyóan magas benchmark teljesítményének. Bár a disztribúciót az Intel hozta létre és kezeli, még az AMD is azt ajánlja, hogy az új processzorainak benchmarkjait Clear Linux alatt futtassa a legmagasabb pontszámok elérése érdekében.
A Phoronixon nemrég Michael Larabel egy Threadripper 3990X rendszert tesztelt kilenc különböző Linux-disztribúcióval, amelyek közül az egyik a Clear Linux volt – és az Intel disztribúciója háromszor annyi első helyezést ért el, mint bármely más tesztelt disztribúció. Amikor megpróbálta az összes teszteredményt egyetlen geometriai átlagba összevonni, Larabel azt találta, hogy a disztribúció eredményei átlagosan 14%-kal gyorsabbak voltak, mint a leglassabb tesztelt disztribúcióké (CentOS 8 és Ubuntu 18.04.3).
Nem kérdés, hogy a Clear Linux a legjobb választás, ha a lehető legjobb benchmark számokat szeretné elérni. Az itt nem tárgyalt kérdés az, hogy milyen a Clear Linuxot mindennapos vezetőként futtatni? Kíváncsiak voltunk, ezért kipróbáltuk.
A Clear Linux telepítése
A Clear Linux telepítése nagyjából ugyanolyan, mint bármely más operációs rendszeré – letölti az ISO-t, átmásolja egy pendrive-ra, elindítja, és mehet. Két telepítő verzió áll rendelkezésre: egy “szerver”, amely csak szöveges üzemmódú, és egy “asztali”, amely egy teljes értékű élő asztali környezetet használ. Mi az asztali változatot választottuk. Valódi hardveren a Clear nem okozott gondot, és azonnal települt, de KVM-környezetben kezdetben nem volt hajlandó települni, egy nem túl hasznos “failed to pass pre-install checks” hibaüzenettel.
Egy kis online kutakodás során kiderült, hogy míg a Clear Linux élő asztali környezete BIOS módban is bootol, a tényleges operációs rendszer UEFI-t igényel. A virtualizációs környezetünkben – Linux KVM, Ubuntu 19.10 alatt – az új VM-ek alapértelmezés szerint BIOS módban indulnak, kivéve, ha az utolsó lépésben bejelöljük a “Konfiguráció testreszabása telepítés előtt” opciót, majd az Áttekintés fülön BIOS-ról UEFI-re váltunk. Így aztán elpusztítottuk a VM-et, újra létrehoztuk a megfelelő UEFI firmware-rel, és már indultunk is a versenyre.
Mihelyt rendbe tettük a VM firmware-architektúráját, a Clear Linux telepítése VM-ben ugyanolyan egyszerű volt, mint valódi hardveren – vagyis valódi hardveren, UEFI firmware-rel. Ha azt remélted, hogy a Clear Linuxot olyan régi hardverre telepítheted, amely csak BIOS módot támogat, akkor nincs szerencséd.
A telepítőprogram világos és egyszerű. Ki kell választani egy nyelvet (jelenleg egy nagyon korlátozott listából), egy telepítési célt, és meg kell adni a telepítőnek egy felhasználónevet és jelszót az új operációs rendszerhez. Azt is tudatni kell vele, hogy beleegyezik-e vagy sem a minőségbiztosítási és fejlesztési célokra használt telefonos telemetriába.
A telepítési cél beállításakor a Clear Linux a “biztonságos” vagy a “romboló” telepítést kínálja fel. Mi nem teszteltük a biztonságos telepítőt, ehelyett a Clear Linux telepítését választottuk az egyetlen elérhető operációs rendszerként.
Mihelyt kiválasztotta a beállításokat, a Clear tényleges telepítése összesen nem tarthat tovább néhány percnél – de ha elsétál, és visszajön, érdemes tisztában lenni azzal, hogy a képernyőkímélő zárolási képernyő beindulhat. (Ha nem szokott hozzá a Gnome3-hoz, kattintson és húzza felfelé a zárolási képernyő elhagyásához.)
Telepítés után: A GIMP verseny
A legtöbb esetben nem tűnt sok értelme volt hagyományos teljesítmény-összehasonlításokat végezni a Clear Linuxon. A Phoronix már rengeteg ilyet végzett – és igen, kétségtelenül a Clear Linux átlagosan gyorsabb, mint a legtöbb disztró. De a benchmarkok megnyerése nem feltétlenül ugyanaz, mint a gyorsaság érzése.
Hasonlítási pont nélkül – egy figyelt és ketyegő időmérő vagy egy fej-fej melletti verseny – a legtöbb ember nem fog 33%-nál kevesebb különbséget észrevenni egy ismerős feladat elvégzésének idejében. Egy tipikus megfigyelő – aki valójában nem időzíti a dolgokat -, aki egy egyórás feladattal szembesül, amit 40 perc alatt végez el, azt fogja gondolni, hogy “hé, ez gyorsnak tűnt”. Ugyanez a megfigyelő, aki egy egy másodperces feladat befejezésére vár, általában 1300ms körül kezd el ráncolni a homlokát.
Meg kell jegyeznünk azt is, hogy a Phoronix benchmarkjainak többsége a hosszan futó számítási vagy tárolási feladatokra összpontosít. Az ilyen típusú benchmarkok jobban korrelálnak a hardveres változásokkal, mint a disztribúciós szintű szoftveres változásokkal. Ez azt jelenti, hogy még ha a Clear Linux gyorsabb is egy, az asztali számítógép teljesítménye szempontjából releváns feladatnál, a különbséget könnyen elnyomhatják az asztali számítógépben – vagy az adott alkalmazáscsomagban – rejlő különbségek.
Amikor telepítettem és megnyitottam a GIMP-et egy Clear Linux virtuális gépen, azt gondoltam, “ez gyorsnak tűnik” – de arra számítottam, hogy gyorsnak fog tűnni. Hogy teszteljem a kezdeti érzékelésemet, megnyitottam a GIMP-et magán az Ubuntu 19.04 munkaállomásomon is, és megszámoltam a Mississippit – kiderült, hogy az Ubuntu desktop valójában kétszer olyan gyors volt, mint a Clear desktop. Ennyit az emberi érzékelésről? Talán nem – sokat dolgozom VM-eken belül, így talán tudat alatt a Clear VM-et egy Ubuntu VM-hez hasonlítottam, nem pedig az Ubuntuhoz a host munkaállomáson.
Az elmélet teszteléséhez egymás mellé állítottam egy Ubuntu 18.04.4 VM-et és egy Clear Linux VM-et, mindegyikhez négy vCPU-t és 4 GB RAM-ot rendeltem. Ezután telepítettem és konfiguráltam az NTP démont mindkét VM-en, hogy az óráik egy milliszekundumon belülre kerüljenek, és telepítettem a saját whenits ütemező segédprogramomat. Mindezek után az egymás melletti “GIMP-verseny” eredménye nem különbözött – annak ellenére, hogy mindkét VM-hez ugyanazok az erőforrások voltak hozzárendelve, az Ubuntu 18.04 VM még mindig kézzel “nyert”.
Tovább vizsgálódva észrevettem, hogy az Ubuntu 18.04 a GIMP egy régebbi verzióját használja, mint a Clear. Ezért eltávolítottam a rendszer által biztosított 2.08-as GIMP-et az Ubuntu VM-ről, és telepítettem a legújabb 2.10.14-es verziót – ugyanazt a verziót, amit a Clear használ – egy PPA-ról. Az eredmény nem változott jelentősen – a GIMP még mindig gyorsabban nyílt meg az Ubuntu VM-en, és a fenti rövid videoklipben láthatja a végső “verseny” egymás melletti eredményeit.
Ez nem tekinthető végleges összehasonlító mércének, amely a Clear Linuxot “lassúnak” minősíti. De megmutatja az emberi érzékelés hibásságát, és annak határait, hogy egy “gyors” disztribúciónak mekkora hatása lehet egy asztali rendszer normál, mindennapi működésére. A bootolástól eltekintve a Clear Linux nem tűnt észrevehetően gyorsabbnak, mint az Ubuntu általános használatban – sem a Ryzen 3700X munkaállomásomon hosztolt VM-ekben, sem egy i7-6500U meghajtású Dell Latitude-on, amelyre közvetlenül telepítettem.
Ha az a fajta ember vagy, aki nagyon lelkesedik a Gentoo vagy Arch csomagolások fordítóoptimalizálásaiért – vagy ha van egy nagyon specifikus feladatod, amelyet szívesen felgyorsítanál 15%-kal vagy annál nagyobb mértékben – a Clear lehet, hogy neked való. De ha azt a fajta gatyába rúgós gyorsulást várja, amit a barátai azonnal észrevesznek és nyáladzanak, akkor valószínűleg csalódni fog.
Szoftverek telepítése
Az Ubuntu 19.10 és a Clear Linux is a Gnome Software Centert használja GUI-ként a szoftverek telepítéséhez és eltávolításához. A legközvetlenebbül szembetűnő különbség itt a Canonical azon törekvése, hogy a Szoftverközpont saját verziójában található tárakat kurátoriasabbnak és gondozottabbnak érezzük – az Ubuntu Szoftverközpontja kiemelkedő módon tartalmazza a Szerkesztők választásait és a kiemelt alkalmazásokat, amit a Clear Linux nem.
Mivel fontosabb, hogy a Canonical sokkal mélyebb tárakkal rendelkezik alatta, mint a Clear – és ez még akkor is hatással lehet, ha mindkét disztribúció kínál egy adott alkalmazást. Például a Frozen Bubble nevű játék mindkét disztribúción elérhető a Software Centerben – de a Clear-en flatpakként, harmadik féltől származó forrásból, a dl.flathub.org.
Az Ubuntun a Frozen Bubble nem harmadik féltől származó forrásból, hanem a Canonical saját Universe repositoryjából származik. Ez talán nem úgy hangzik, mintha számítana – de a játék telepítése Ubuntun a Canonical saját tárolójából mindössze néhány másodpercet vett igénybe, míg a Clear Linuxon közel tíz percig tartott.
Will it Chrome?
Sem a Clear Linux, sem az Ubuntu nem csomagolja a Google Chrome böngészőt – de Ubuntun a telepítés ugyanolyan egyszerű, mint Windowson: egy keresés, egy letöltés, egy kattintás, és kész. A tényleges letöltés, amit kap, egy Ubuntu natív .deb fájl, és amellett, hogy telepíti magát a böngészőt, automatikusan frissíti az adattárlistát – így innentől kezdve a Chrome-ot az Ubuntu automatikusan frissíti, ugyanúgy és ugyanazokkal az eszközökkel, mint a szokásos rendszerfrissítéseket.
A Clear Linux natívan telepített Firefoxában a Chrome letöltési oldalát böngészve ugyanezt a választási lehetőséget kapja: .deb vagy .rpm letöltés – de egyik sem fog “csak úgy” működni. Van egy kis trükk, amivel a Clear Linux parancssorán letöltheted az .rpm fájlt, kicsomagolhatod és telepítheted, majd kézzel átkonfigurálhatod, hogy a betűtípusok ne nézzenek ki furcsán.
Sajnos a Chrome nem frissül automatikusan, mint az Ubuntun vagy a legtöbb más asztali disztribúción – ehelyett emlékeznie kell arra, hogy maga frissítse, és minden alkalommal ugyanazt a néhány lépést kell elvégeznie a parancssoron (beleértve a betűtípusok újrakonfigurálását).
Package management
A haladóbb felhasználók persze valószínűleg soha nem fognak bajlódni a Szoftverközponttal, egyik disztribúción sem. Az Ubuntu, mint Debian-alapú disztribúció, .deb csomagokat használ a motorháztető alatt, amelyeket a apt parancssori eszközzel lehet telepíteni, frissíteni, eltávolítani és keresni. A Clear Linux nem használ apt– vagy yum, zypper, pacman, pkg, vagy bármi mást, amiről valószínűleg már hallottál. Ehelyett saját parancssori csomagkezelő eszközt használ, melynek neve swupd.
Az swupd nagyrészt úgy működik, mint bármely más csomagkezelő – van egy argumentum a csomagok telepítéséhez, egy másik pár a csomagok kereséséhez akár a csomag neve/leírása, akár a benne lévő fájlok alapján, és így tovább. Sajnos be kell vallanom, hogy a swupd-et következetesen frusztrálónak találtam – különösen az argumentumok bőbeszédűek és furcsán vannak megfogalmazva.
A Debian, Ubuntu, Fedora, OpenSUSE, CentOS vagy FreeBSD esetén <packagemanager> install <package> egy új alkalmazást kell telepíteni a tárolókból – például apt install gimp. De a swupd-ben ehelyett swupd bundle-add <package>. Hasonlóan bundle-remove, bundle-list, bundle-info és így tovább.
Ez talán apró, jelentéktelen megkülönböztetésnek hangzik, de én elég ellenszenvesnek találtam. Sokkal gyakrabban babráltam a szintaxissal – például tévesen add-bundle-t írtam be bundle-add helyett -, mint általában szoktam, amikor egy ismeretlen csomagkezelőt használok.
Maguk a csomagok is elég gyakran figyelmen kívül hagyják a viszonylag szabványos elnevezési konvenciókat. Például, amikor szükségem volt egy bizonyos fejléckészletre, amelyet az Ubuntu uuid-dev-ben, a Fedora pedig libuuid-devel-ben találok, a Clear Linux ehelyett os-core-dev-ben találta meg – és ennek kitalálása hatalmas bosszúságot okozott. A swupd search uuid kipróbálása egyáltalán nem listázta a os-core-dev csomagot – és a swupd search-file uuid.h segítségével sem sikerült megkeresni a tényleges fájlt, amire szükségem volt. (Erről a témáról később.)
Az swupd ugyan működik, de nagyon úgy érzem, hogy az NIH-szindróma eredménye. Az Intel azt állítja, hogy a Clear Linux titkos szószának nagy része a csomagolásban rejlik, és talán valóban szükség volt arra, hogy az alapoktól kezdve saját menedzsment eszközt építsen. De ebből a rendszergazda szemszögéből nehéz meglátni az előnyöket, és könnyű meglátni a hibákat – egy kicsit több erőfeszítést fordítani a swupd csiszolására és használhatóságára, az sokat segítene.
Will it ZFS?
Nem mindenkit fog érdekelni, hogy az OpenZFS-t működésre bírja-e a Clear Linuxon. De engem biztosan érdekelt, és nevetségesen sok időt töltöttem ennek a bizonyos sárkánynak a kergetésével. Komolyan fontolgattam, hogy leaszfaltozom a fő laptopomat, és újratelepítem a Clear Linuxot egy hosszú távú teszteléshez – de még “csak egy laptopon” sem akartam nélkülözni a ZFS képességét a gyors aszinkron replikációra, a bitrot kriptográfiai felismerésére és javítására, az inline tömörítés használatára, és így tovább és így tovább.
Magának az OpenZFS projektnek nincs telepítési jegyzete a Clear Linuxhoz, és egy swupd search zfs üres eredményt hozott, ezért lecsaptam az internetre. A “Clear Linux ZFS” keresés gyorsan a Clear GYIK-hez vezet, amely azt állítja, hogy “A ZFS nem érhető el a Clear Linux OS-sel”, és alternatívaként a btrfs-t ajánlja.
A btrfs a legtöbb olyan funkciót kínálja, mint a ZFS – de sajnos, ha ténylegesen használjuk a legérdekesebb ilyen funkciókat, például a redundáns tömböket adatgyógyítással, gyors replikációval vagy inline tömörítéssel, akkor gyorsan megbízhatatlanná válik. (Igen, tényleg – az olyan kereskedelmi NAS-eszközök, mint a Synology és a Netgear ReadyNAS btrfs-t használnak, de azt az LVM és az mdraid tetejére helyezik, és ezt jó okkal teszik. Lásd a Debian wikiben a továbbiakat, és vedd figyelembe a Red Hat döntését, hogy a btrfs-t a RHEL 7.4-ben teljesen elavulttá teszi.)
A Clear Linux GYIK egy régebbi Github issue-re is rámutat, amelyben egy felhasználó ZFS csomagot kér, és lelőtték. Egy másik felhasználó segítséget kér az aláírás nélküli kernelmodulok működéséhez, és egy mára már halott linken keresztül kap egy hivatkozást némi dokumentációra. A web.archive.org-on találtam egy példányt a halott linkkel ellátott dokumentációból (később a Clear Linux projekt egyik tagja egy frissített linket adott az aktuális verzióhoz), de ez sem vezetett el oda, ahova kellett volna.
A linux-lts-dev csomag telepítése egyszerű volt, ahogyan egy olyan kernelkonfigurációs fájl létrehozása is, amely lehetővé teszi az aláírás nélküli modulok betöltését. De az LTS kernelre való visszaváltás – ami szükséges volt, mivel a natív kernel egy kicsit túlságosan véres volt az OpenZFS hivatalos támogatásához – bonyolultabbnak bizonyult. A kernel telepítése egyszerű volt –swupd bundle-add kernel-lts2018-, de a Clear Linuxot rémálommá tette, hogy ténylegesen bootoljon róla.
A disztribúció nem tartja meg a boot management konfigurációit egyik helyen sem, ahol egy tapasztalt *nix felhasználó keresné őket –/boot, /etc/default, bármi, ami a grub-hoz kapcsolódik, stb. Soha nem találtam meg a tényleges konfigurációs adatok helyét, de végül rájöttem, hogy egy Clear Linux felhasználónak a clr-boot-manager eszközzel kell manipulálnia a boot környezetet. Sajnos a clr-boot-manager set-kernel org.clearlinux.lts2018.4.19.103-113, majd a clr-boot-manager update – aminek ki kellett volna választania ezt a rendszermagot a következő rendszerindításkor – abszolút nem csinált semmit, és a kerekeimet pörgetve, újraindítva, uname -a futtatásával, és még mindig egy 5.5-ös rendszermagot láttam futni egy jó ideig.
Végül feladtam a clr-boot-manager set-kernel-ot, és helyette a clr-boot-manager set-timeout 10-t próbáltam. Ez valóban működött – ezúttal az újraindítás után egy kernellistát kaptam, és kézzel kiválasztottam a 4.19 LTS kernelt. Most a uname -a megmutatta, hogy a 4.19-es kernelen futok, és készen álltam a ZFS összeállítására!
A problémáknak sajnos még messze nem volt vége. Az OpenZFS forráskódú tarball letöltése és kicsomagolása, chdir beletöltése és a ./configure futtatása után hibaüzenetet kaptam: uuid/uuid.h missing, libuuid-devel package required. Sajnos a swupd-ben nincs libuuid-devel köteg – és nincs libuuid, uuid, uuid-dev, uuid-devel, vagy bármi más hasonló. Sem a swupd search uuid, sem a swupd search-file uuid.h nem hozott semmilyen hasznos eredményt – pedig kellett volna.
Végül nyitottam egy új problémát a ZFS on Linux trackerben, remélve, hogy vagy valaki másnak sikerült a ZFS-t futtatni a Clear-en, vagy elég információt kapok a configure scriptről ahhoz, hogy megpróbáljam magam kipofozni. Brian Behlendorf – az OpenZFS Linux portjának alapító fejlesztője és minden szempontból kedves fickó – sem tudta a választ.
De Brian adott egy tippet, ami végül megoldotta a rejtélyt – bár a swupd search-file uuid.h nem találta meg a szükséges csomagot, a swupd search-file libuuid.so.1 igen. Így egy swupd bundle-add os-core-dev később/configure és make install, mindkettő sikeresen befejeződött!
A további problémám az volt, hogy az egyszerű Linux Kernel Module (LKM) manipulációs parancs insmod – amely lehetővé teszi, hogy megadjuk a kernelbe illesztendő modul elérési útvonalát – nem oldja fel a függőségeket, és így a insmod /path/to/zfs.ko unknown symbol hibával sikertelen volt. A sokkal okosabb modprobe eszköz felismeri és megoldja a függőségi problémákat – de nem engedi megadni a kernelmodulok elérési útvonalát, és a telepítő olyan helyekre rakta őket, ahol a modprobe nem tudta, hogy keresse őket.
Egy kis birkózás után végül csak egy szimbolikus linket tettem a ZFS minden egyes package.ko fájljára – amelyek a /lib/modules/extra alatti külön könyvtárakban voltak – közvetlenül magába a /lib/modules-be. Ezzel az modprobe zfs működött, és a ZFS valóban futott a Clear Linuxon. Huzzah!
Bár a ZFS most már működőképes volt, még mindig voltak papírvágások, amikkel foglalkozni kellett. A zpool és zfs parancsok a /usr/local/sbin-ben voltak, ami a Clear Linuxban nem része az alapértelmezett PATH-nak. Továbbá a ZFS modul nem volt beállítva úgy, hogy automatikusan betöltődjön a rendszerindításkor. Ezek a fennmaradó problémák szerencsére elég triviálisan megoldhatók. Az útvonalprobléma megoldásához vagy frissítsd a PATH-at, hogy tartalmazza a /usr/local/sbin-et, vagy a segédprogramokat symlinkeld az /usr/local/bin-ba. Ahhoz, hogy a ZFS bootoláskor automatikusan betöltődjön, hozzon létre egy /etc/modules-load.d könyvtárat, majd hozzon létre egy /etc/modules-load.d/zfs.conf fájlt, és töltse fel egyetlen sorral, amiben csak annyi áll, hogy zfs.
Ez a bozontos történet igazából nem magáról a ZFS-ről szól – hanem arról, hogy a Clear Linux alatt olyan problémák, amelyek viszonylag egyszerűek a jobban bejáratott disztribúciók alatt, óriási gondot jelenthetnek. Az ilyen típusú problémák természetesen mind megoldhatóak – de ha nem vagy hajlandó és izgatott, hogy részt vegyél a megoldásukhoz szükséges erőfeszítésekben magad vagy az utánad jövők számára, akkor valószínűleg távol kell tartanod magad a Clear-től, mint mindennapi meghajtótól.
A jó
- A Clear Linux mögött az Intel, a világ egyik legnagyobb és legjelentősebb számítástechnikai vállalata áll
- A Clear Linuxnak tömör, világos megbízatása van: A legtöbb dolog kevés vagy semmi finomhangolással működik
- Ha mindenáron A Nyugat Leggyorsabb Linuxát akarod, akkor ez a megfelelő disztribúció – sajnálom, Arch és Gentoo felhasználók
- “Ez a Linux! Ezt ismerem!”
A rossz
- Bár a legtöbb dolog működik finomhangolás nélkül, a legtöbb felhasználó gyorsan akar majd valamit, ami nem
- Az Intel
swupdcsomagkezelő eszköze nehézkes, szemölcsös, és úgy tűnik, hogy nem indexel minden csomagot megfelelően - Túl kevés felhasználó van, a segítség keresése olyan lehet, mint egy időutazás a múltba (Ki voltál te, DenverCoder9? Mit láttál?!)
A csúnya
- A tiszta Linux – legalábbis egyelőre – sokkal jobban alkalmas egyszerű, ismétlődő feladatokra, ahol a végrehajtási sebesség abszolút küldetéskritikus, mint széleskörű, általános célú napi használatra
.