A Vanilla OS
Egy ideje már szinte csak immutable rendszereket használok, így került a látókörömbe a Vanilla OS, ami egy Debian Sid alapokra épülő immutable rendszer. Tudtam róla, hogy létezik, de nem különösebben ragadta meg a fantáziám, mivel a jelenlegi rendszereimmel (Aeon, Fedora Silverblue) meg vagyok elégedve. Aztán egy szép vasárnap délután valahogy szembe jött velem a Vanilla OS, ránéztem Distrowatchon, és meglepődtem, hogy csak 6.3-on áll az értékelése...
Gondoltam, valamit tudhat, ha ennyire rossz az értékelése! :)
A népszerűbb disztrók értékelése jellemzően olyan 8-8.5 körül alakul, úgyhogy ez a 6.3 eléggé azt jelzi, hogy valami gond van ezzel a disztróval.
Egy gyors keresés után figyeltem fel arra, hogy az egyik népszerű Linuxos Youtuber két videót is készített a disztróról. Nem szoktam ilyeneket nézni, de az egyikre rákattintottam, végignéztem, és tulajdonképpen a 27 perces videóból 20 perc arról szólt, hogy mit bénázik össze a srác. Szerencsétlen próbált volna kiigazodni a Vanilla OS-ben, de sajnos elfelejtette használni az ősöreg, jól ismert rigmust, ami sokunk életét könnyítette már meg, az "RTFM"-et. Már csak azért is gondoltam, hogy én is meglesem magamnak ezt a rendszert.
Immutable operációs rendszer
A Vanilla OS Debian alapokra épül, immutable felépítésű, tranzakció alapú atomi frissítésekkel operál, és Podman-alapú Distrobox konténereket használ. Hogy mit jelent az immutable felépítés, és mi az a tranzakció alapú frissítés, azt korábban az Aeon-os cikkemben leírtam: Aeon Desktop, egy immutable operációs rendszer az OpenSUSE-tól
Jelenleg a Vanilla csak Gnome asztali környezettel érhető el.
Mitől különleges a Vanilla OS?
A Vanilla OS azon túl, hogy saját fejlesztésű telepítőt használ, számos, szintén saját fejlesztésű segédprogramot is kínál. Az egyik az APX, egy konténeres, több csomagforrást kezelni képes csomagkezelő, ami tulajdonképpen egy "wrapper" több másik csomagkezelő körül (még saját GUI-ja is van!). A második az ABRoot, amely lehetővé teszi az operációs rendszer számára a tranzakció alapú frissítéseket, a harmadik pedig a VSO Shell, ami egy virtuális környezet (egy shell), amiben az operációs rendszerrel kapcsolatos teendőket tudjuk elvégezni. Továbbá, ott van még az Ikaros illesztőprogram-kezelő, ami az illesztőprogramok telepítésében segít. Még egy megemlítendő dolog van itt: a Vanilla képes Android alkalmazásokat futtatni. Bár a rendszer ezen része még eléggé kezdetleges állapotban van, de elméletileg már működik.
A Vanilla egy másik egyedi tulajdonsága, hogy egy alapértelmezett konténerrel érkezik (Pico). A terminál (Black Box) első indításakor lefut a vso pico-init parancs, ami inicializálja ezt a konténert, innentől fogva pedig, amikor csak elindítjuk a terminált, nem az alaprendszer shelljébe lépünk be, hanem ebbe a konténerbe. A prompt is ezt fogja jelezni, hiszen nem a gép hostnevét tartalmazza, hanem a apx-vso-pico stringet. Ha át szeretnél lépni az alaprendszer környezetébe, a host-shell parancsot kell kiadnod (viszont itt nincs telepítve a sudo, pkexec-t kell használni root jogosultságok eléréshez).
Ez tulajdonképpen egy kényelmi szolgáltatás, mert nem kell neked létrehoznod konténert, hanem mindig kéznél van egy, amibe könnyen és gyorsan be tudsz lépni, és rögtön használhatod is. Ellentétben más immutable rendszerekkel, pl. az Aeonnal és a Fedora atomic rendszerekkel, ahol ha csomagokat akarsz telepíteni, neked kell indítanod egy konténert. Ne feledjük, hogy immutable rendszeren dolgozunk, tehát az alaprendszer csomagjait nem piszkáljuk, mindenféle kézi csomagműveletet konténerben hajtunk végre.
Vanilla OS esetén az alapértelmezett konténerben Debian fut, tehát az apt-vel ugyanúgy tudsz csomagokat kezelni, mint ha csak egy Debian/Ubuntu előtt ülnél, bár erre a VSO segédprogram is lehetőséget ad (lásd lejjebb).
A Black Box első indítása
ABRoot
A Vanilla OS tranzakció alapú, atomi rendszerfrissítési mechanizmust alkalmaz, amiért az ABRoot felel.
Rendszerfrissítéskor a jelenlegi állapotból készül egy másolat, ezt a rendszer úgy éri el, hogy két partíciót használ, egyet a jelenleg futó rendszerhez (current), egyet pedig a frissített rendszerhez (future). A future partíción történik a tényleges frissítés, majd újraindítás után a két partíció szerepet cserél, a rendszer a future partícióról fog bootolni (amely innentől a current partíció lesz), a korábbi current partíción ott lesz a rendszer frissítés előtti változata, így egy darabig (pontosan a következő rendszerfrissítésig) vissza tudunk állni.
A visszaállításért, valamint a kernel paraméterek konfigurálásáért, szintén az ABRoot felel, valamint ezzel tudjuk az alaprendszer csomagjait manuálisan kezelni. Ez viszont határozottan ellenjavalt, ha tudjuk, kerüljük el.
Az ABRoot OCI imagekkel dolgozik, és a felhasználó által végzett módosításokból (csomagtelepítésekből) is OCI image-t generált, amit ráhúz a rendszer "tetejére", így alakul ki a végles rendszerkép. Normál üzem folyamán az ABRoottal nekünk nem igazán lesz dolgunk, jó esetben soha sem kell kézzel elindítanunk.
Egyébként a program neve elég találó, ugyanis azért hívják ABRoot-nak, mert két root partíciót használ, egy A-t, és egy B-t :)
További infók: https://github.com/Vanilla-OS/ABRoot
APX
Az APX egy több csomagforrást kezelni képes csomagkezelő, gyakorlatilag egy wrapper a Distrobox fölött. Az APX nevezéktanában a subsystem jelenti a konténert, a stack pedig egyfajta recept, egy sablon, amely tartalmazza a csomagkezelőt, az ahhoz szükséges csomagokat, és a subsystem kialakításához szükséges egyéb csomagokat (gyakorlatilag ez az image, amiből készül a konténer). Igazából nem egészen értem, hogy miért kell új nevezéktant bevezetni már létező fogalmakra, de ám legyen...
A gyakorlatban ez úgy néz ki, hogy az APX-szel konténereket készíthetünk különféle disztrókból, amikbe csomagokat telepíthetünk az adott disztró saját csomagkezelőt használva, de az APX-en keresztül (sőt, harmadik féltől származó csomagkezelőt is beállíthatunk). Tehát ha van egy Debian konténered, és kiadod az apx debian install package parancsot, akkor az apx a debian nevű konténerbe fel fogja telepíteni a package csomagot az apt-vel. Ha kiadjuk az apx fedora install package, akkor pedig a fedora nevű konténerbe telepíti a package nevű csomagot a dnf segítségével, és így tovább...
Végső soron egy réteg a Distrobox fölött, néhány extra funkcióval.
A stack-ek listáját lekérhetjük így:
$ apx stacks list
INFO Found 7 stacks:
┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼
┊ NAME ┊ BASE ┊ BEÉPÍTETT ┊ PKGS ┊ PKG MANAGER ┊
┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼
┊ alpine ┊ alpine:latest ┊ igen ┊ 0 ┊ apk ┊
┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼
┊ arch ┊ ghcr.io/archlinux/archlinux:multilib-devel ┊ igen ┊ 0 ┊ pacman ┊
┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼
┊ fedora ┊ fedora:latest ┊ igen ┊ 0 ┊ dnf ┊
┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼
┊ opensuse ┊ registry.opensuse.org/opensuse/tumbleweed:latest ┊ igen ┊ 0 ┊ zypper ┊
┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼
┊ ubuntu ┊ ubuntu:latest ┊ igen ┊ 0 ┊ apt ┊
┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼
┊ vanilla-dev ┊ ghcr.io/vanilla-os/dev:main ┊ igen ┊ 0 ┊ apt ┊
┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼
┊ vanilla ┊ ghcr.io/vanilla-os/pico:main ┊ igen ┊ 0 ┊ apt ┊
┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┼
Az elkészült subsystemek listáját pedig így:
$ apx subsystems list
┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼
┊ NAME ┊ STACK ┊ STATUS ┊ PKGS ┊
┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼
┊ Ubuntu ┊ ubuntu ┊ Exited (100) 23 hours ago ┊ 0 ┊
┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼
┊ Fedora ┊ fedora ┊ Exited (143) 24 hours ago ┊ 0 ┊
┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼
┊ Ubuntu2 ┊ ubuntu ┊ Up 2 minutes ┊ 0 ┊
┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼
┊ opensuse ┊ opensuse ┊ Exited (143) 54 minutes ago ┊ 0 ┊
┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼
┊ tw ┊ opensuse ┊ Created ┊ 0 ┊
┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┼┄┄┄┄┄┄┼
Ez eddig nem hangzik rosszul, a gond akkor van, amikor megpróbáljuk használni, ugyanis olykor belefuthatunk ilyen hibaüzenetekbe:
$ apx Ubuntu enter
Starting container... [ OK ]
Installing basic packages... Error: An error occurred
Error: Hiba történt a konténerbe való belépéskor: exit status 1
Usage:
apx Ubuntu enter [flags]
Flags:
-h, --help help for enter
ERROR Hiba történt a konténerbe való belépéskor: exit status 1
Tehát az apx automatikusan lefordítja az adott disztróhoz tartozó csomagkezelő parancsára az általunk kiadott parancsot (install, remove, stb.), így még az adott konténerben lévő disztró csomagkezelőjét sem feltétlenül kell ismernünk.
Sajnos azonban nem mindig működik hibátlanul, néhányszor itt is belefutottam ilyen jellegű hibákba:
$ apx Ubuntu install inkscape
Starting container... [ OK ]
Installing basic packages... Error: An error occurred
Error: Hiba történt a parancs végrehajtása közben: exit status 1
Usage:
apx Ubuntu install [flags]
Flags:
-h, --help help for install
-n, --no-export Ne exportáljon asztali bejegyzést.
ERROR Hiba történt a parancs végrehajtása közben: exit status 1
De azért többnyire jól működik, sőt, az apx exportálja is a gazdarendszerbe a telepített bináris elérhetőségét, ezt nem kell kézzel megtennünk. Az alapértelmezett konténerbe azonban még így sem kerülnek bele a telepített programok, úgyhogy grafikus felületről igen, de terminálból nem fogjuk tudni elindítani a programot.
További infók az apx-ről: https://vanillaos.org/blog/article/2023-01-28/apx-an-unconventional-package-manager
https://apx.vanillaos.org
VSO (Vanilla System Operator)
A VSO használható az alapkonténerbe (Pico) telepített csomagok kezelésére, a rendszer frissítésére, és bizonyos feltételekhez kötött, automatikus feladatok végrehajtására. Csomagkezelési szempontból a különbség a VSO és az APX között az, hogy míg az APX segítségével konténereket hozhatsz létre, és abba telepítheted a programokat, addig a VSO-val az alapértelmezett konténerben tudsz csomagműveleteket végezni.
Mint ahogy korábban írtam, a csomagok frissítéséhez használható ugyan az apt is, de a VSO is nyújt ehhez két parancsot, a vso update-et és a vso upgrade-et. Első a csomagrepozitórium metaadatait frissíti (akár csak az apt update), második a csomagokat (mint az apt upgrade). Az alaprendszert is lehet frissíteni a vso-val, ehhez a vso sys ... parancsokat kell használni (de ez gyárilag ütemezve van, úgyhogy kézzel nem igazán kell frissítgetnünk). Illetve az alapértelmezett konténerben is végezhetünk csomagműveleteket a vso-val.
A tmux telepítése az alapértelmezett konténerbe vso segítségével. Használhattam volna az apt-t is, a végeredmény ugyanaz
Továbbá, a VSO-nak van egy reset szolgáltatása, amivel az összes telepített csomagot és beállítást el lehet távolítani az alapértelmezett konténerből (ez gyakorlatilag törli és újra létrehozza a konténert). Ehhez az ALT-F2-t kell megnyomni, beírni az ablakba, hogy reset-vso, és követni a képernyőn megjelenő utasításokat.
További infók:
https://vanillaos.org/blog/article/2024-07-16/discover-vso-v2-managing-your-vanilla-os-installation-like-never-before
https://docs.vanillaos.org/docs/en/vso-manpage
A cikk még nem ért véget, kérlek, lapozz!
