Egyebek

Flatpak

Érezhető az Aeonon, hogy flatpakos programok futtatásához van optimalizálva. A flathub gyárilag fel van véve a repók közé, és a flatpak programok is gyorsabban indulnak, mint egy hagyományos rendszeren. A megjelenésük is elég szépen integrálódik a rendszerbe, ahogy váltunk sötét és világos mód között, a flatpakos programok is témát váltanak.
Ha pedig a adw-gtk3 témából feltelepítjük a flatpak változatot is (flatpak install org.gtk.Gtk3theme.adw-gtk3 org.gtk.Gtk3theme.adw-gtk3-dark), és a Gnome Tweaksben (Finomhangoló) beállítjuk, hogy az örökölt alkalmazások az adw-gtk3 témát használják, akkor a GTK3-as flatpak alkalmazások is átveszik az adw-gtk3 témát, úgy, hogy a világos/sötét módok közti váltás is működik.

Snap

A snap gyárilag nincs benne az OpenSuse tárolóiban, csak külső repóból lehet telepíteni. Én nem nagyon akartam ráerőltetni a rendszerre, de a teszt kedvéért mégis csak rászántam magam, és megpróbáltam feltelepíteni a snapd-ot ez alapján: https://snapcraft.io/docs/installing-snap-on-opensuse
A gpg kulcsok importálásánál már eleve hibába ütköztem:
- A parancs a következő állapottal lépett ki: 1.
- error: /var/tmp/zypp.CCRXFO/pubkey-F7C6E425ED340235-DzjxYx: key 1 import failed.
- error: can't create transaction lock on /usr/lib/sysimage/rpm/.rpm.lock (Read-only file system)

Ezután megpróbáltam feltelepíteni a snapd csomagot, újraindítottam a gépet, de boot közben a rendszer visszaált egy korábbi snapshotra (ilyenkor egy pillanatra maintainance módba vált, majd rögtön újra is indul). Bootolás után láttam, hogy valóban visszaállt, a snap repó hozzá volt adva, de a snapd nem volt telepítve.
Megpróbáltam még egyszer telepíteni, de folyamatosan ilyen hibákba ütköztem:
A(z) apparmor-parser-4.0.3-1.1.x86_64 telepítése meghiúsult:
Hiba: Subprocess failed. Error: RPM sikertelen: A parancs a következő állapottal lépett ki: 1.

Innentől nem erőltettem tovább, kézzel visszaálltam a repó hozzáadása előtti snapshotra, és részemről ennyi volt a snap. Én azt gondolom, Aeonra nem való a snap, egyértelműen flatpakra van optimalizálva. Aki ragaszkodik a snap támogatáshoz, annak nem ajánlon az Aeont.

Appimage

Az appimage alapértelmezetten nem támogatott (és nem is javasolt a használata), ha mégis szeretnénk ilyen programokat futtatni, telepítsük fel a fuse csomagot:
sudo transactional-update pkg install fuse
Ezután indítsuk újra a gépet, és utána már használhatók is az appimage programok.

Appimage programok futtatásához a fuse csomag kell

Tűzfal

Tűzfal alapértelmezetten nincs, és nagy valószínűséggel a jövőben sem lesz. Richard Brown véleménye erről az, az Aeon egy könnyen használható, felhasználóbarát asztali operációs rendszer szeretne lenni, és nem szeretné, hogy a felhasználóknal tűzfal okozta problémákkal kellene foglalkoznia, és hogy Aeonon a legtöbb program úgyis konténerben fut, ráadásul a felhasználó nevében (tehát nem rootként), és egyébként sok bugreport van arról, hogy a Podman képtelen együtt működni a tűzfallal...
Lásd itt:
- https://bugzilla.opensuse.org/show_bug.cgi?id=1213627
- https://www.reddit.com/r/openSUSE/comments/11ttd4c/comment/jcpmbzf/
- https://www.reddit.com/r/openSUSE/comments/11g076j/comment/jauwbi5/
Shawn Dunn, a Kalpa vezető fejlesztője álláspontja tűzfal kérdésben: "No, it does not, and there are no plans to add or enable such. It isn’t required."
Hosszas vitákat lehetne folytatni arról, hogy ez mennyire jó vagy rossz gyakorlat. De alapvetően semmi akadálya annak, hogy feltelepítsd a firewalld-ot, vagy bármelyik másik, kompatibilis tűzfalat. Alapértelmezetten egyébként csak a cupsd hallgatózik, az is csak localhoston.

Frissítések

Alapvetően nagyon tetszik az, ahogy az Aeon kezeli a frissítéseket. A dolog úgy néz ki, hogy alapértelmezetten be van állítva a transactional-update timer (ami a transactional-update.service-t hívja meg), naponta egyszer lefut, telepíti az elérhető frissítéseket, és értesítést küld az eredményről.

Teljesen beavatkozás mentesen és láthatatlanul teszi a dolgát, a felhasználó nem is tud róla, hogy éppen frissül a rendszere - viszont sajnos semmilyen értesítést nem is kap arról, ha nem sikerült a frissítés, tehát akár hónapokig észrevétlen maradhat egy sikertelen frissítés, és szerintem ez elég nagy probléma! Mindenképpen kellene, hogy a felhasználó legalább arról értesüljön, ha hiba történik a frissítés közben.
Érdemes gyakorta (legalább hetente egyszer) ellenőrizni a snapper list kimenetét, ez megmutatja a snapshotokat. Amelyik oszlopban - jel van, az jelöli a jelenlegi snapshotot, amelyikben +, az pedig az alapértelmezett snapshotot, tehát azt, amelyikről a következő indításkor bootolni fog a rendszer. Alapesetben ebben az oszlopban egy csillagot kell látnunk, ami azt jelenti, hogy az a jelenlegi snapshot, és az alapértelmezett snapshot is egyben. Ha csomagműveletet végeztünk, vagy frissítettük a rendszerünket, akkor természetesen a jelenlegi és az alapértelmezett snapshot különböző lesz, hiszen a transactional-update minden csomagműveletnél készít egy új snapshotot.
Ha a jelenlegi snapshot (-) túl réginek tűnik, és azóta már több próbálkozás is volt snapshot létrehozására, vagy túl nagy "távolság" van a jelenlegi és az alapértelmezett (+) snapshot között, az valószínűleg azt jelenti, hogy a frissítés nem tudott lefutni. Ilyen esetben kézzel hívjuk meg a transactional-update-et, nézzük meg a logokat is, és próbáljuk megkeresni a hibát. Megpróbálhatunk visszaállni a jelenleginél egy korábbi snapshotra, és újra futtatni a transactional-update-et. Ha sehogy sem találjuk meg a hibát, nézzünk rá az Aeon Bugzillára (https://bugzilla.opensuse.org/describecomponents.cgi?product=openSUSE%20Aeon), lehet, hogy egy olyan bugba futottunk bele, amire mások már találtak megoldást. Adott esetben az is megoldás lehet, hogy először frissítjük a sdbootutil csomagot, újraindítjuk a gépet, majd ezután próbálkozunk a transactional-update futtatásával.
Ha nem szeretnéd, hogy automatikusan frissüljön a rendszered, és kézzel futtatnád inkább a transactional-update-et, természetesen le is tilthatod a timert.
A konfigurációs fájlja itt található: /etc/systemd/system/transactional-update.timer.d/local.conf
A Gnome Szoftverek jelenleg nincs felkészítve immutable rendszerre, ne is próbáljuk frissíteni vele az Aeont.

Yast

Yast nincs, és biztos vagyok benne, hogy nem is lesz, hiszen ez nem OpenSuse. Épp ezért is van máshogy brandelve a rendszer, sem az OpenSuse/SUSE nevet, sem a logót nem használja sehol sem.

OpenSSH szerver

Az sshd ugyanúgy működik, mint az összes többi OpenSUSE rendszeren. A /usr/etc/ssh/sshd_config az alapértelmezett konfigurációs fájl, ha ezen módosítani szeretnénk, készítsünk egy üres fájlt az /etc/ssh/sshd_config.d/ könyvtárba .conf kiterjesztéssel (pl. sshd.conf), és abba írjuk át a konfigurációt. Át is másolhatjuk /usr/etc/ssh/sshd_config fájlt, csak akkor adjunk neki .conf kiterjesztést, és szedjük ki belőle az "Include" sorokat, különben hibára fut az sshd.

Nvidia

Az Nvidia driver telepítése elméletileg így működik:
zypper addrepo -f https://download.nvidia.com/opensuse/tumbleweed NVIDIA
transactional-update --interactive pkg in x11-video-nvidiaG06 nvidia-glG06 nvidia-computeG06 nvidia-gfxG06-kmp-default nvidia-utils-G06 kernel-source
Nem teszteltem, csak i915-öm van.

Aeon check

Az aeon-check szolgáltatás ellenőrzi a rendszert, kiértékeli az ismert hibák tükrében, és meghatározza a támogatási szintjét (jelentsen ez bármit is). Jelenleg ez kimerül egy pár soros bash scriptben.
https://en.opensuse.org/Portal:Aeon/DevelopmentThoughts#aeon-check
https://github.com/AeonDesktop/aeon-check/blob/main/aeon-check

sdbootutil

Az sdbootutil segédprogramocskával a systemd-boot bejegyzéseit szerkeszthetjük. Átírhatunk kernelparamétereket, beállíthatjuk az alapértelmezett kernelt, a snapshotok paramétereit is módosíthatjuk, stb. Átvizsgálhatjuk, de ne nagyon írkáljunk át benne semmit sem, mert az a leggyorsabb módja annak, hogy indíthatatlanná tegyük a rendszerünk.

Hibák, hibaelhárítás

Egyetlen komoly hibába futottam bele, ami miatt jó darabig nem tudott frissülni a rendszer.Ezt úgy tudtam megoldani, hogy visszaállítam korábbi snapshotra, először frissítettem a sdbootutil-t, újraindítottam a gépet, majd futtattam a transactional-update-et, és az a frissítés már sikeres volt.
Ezt leszámítva jelentősebb buggal nem találkoztam. Olyan volt, hogy frissítés után nem tudott bootolni a rendszer a friss snapshotról, de következő frissítésnél ez is megoldódott.
Pár alkalommal fordult elő az, hogy nem volt hajlandó elmenni alvó állapotba a gép, illetve egyetlen egyszer volt olyan, hogy egy ilyen sikertelen alvó állapotba történő küldés után nem tért vissza a grafikus felület.
A laptopomra telepített Aeonban azt vettem észre, hogy a bluetooth minden újraindítás után bekapcsol, annak ellenére is, hogy kikapcsolom. De ez valószínűleg Gnome hiba lesz.
Illetve kisebb bugok még előfordulnak a rendszerben. Amikor egy alkalmazást exportálunk distrobox konténerből, a gazdarendszer megkapja az indítóikonját, de amíg nem jelentkezünk ki-és vissza a rendszerből, az alkalmazás ikonja a rácsban az alapértelmezett kék színű ikonként jelenik meg.

Visszajelentkezés után ez ugyan megjavul, de a dokkon az alkalmazás futása közben továbbra is az alapértelmezett ikon fog megjelenni. Ez a Gnome szövegszerkesztőjénél tűnt fel leginkább, úgyhogy a Tumbleweed konténerből azt is töröltem, és áttértem a flatpakos változatra. Az ilyen bugokat idővel nyilván javítani fogják.

Boot

Mint már említettem, az Aeon systemd-bootot használ a rendszer betöltésére. Ha szükségünk van a boot menüre, az 'e' billentyű folyamatos nyomvatartásával tudjuk elérni. Itt tudunk megadni kernel paramétereket, illetve itt tudjuk kiválasztani, hogy melyik snapshotról bootoljon a rendszer (ESC billentyűvel tudunk átlépni a snapshot válaszó menübe, vagy a rootflags=subvol=@/.snapshots/x/snapshot sorban is megadhatjuk a kívánt snapshot számát). A SPACE billentyű nyomodásával rögtön a snapshot választó menübe jutunk.
Ha esetleg nem indulna el a rendszer, akkor első körben próbáljunk meg korábbi snapshotról bootolni. Ha az sem működik, akkor az alábbi kernel paraméterek segíthetnek:
- systemd-unit=emergency.target: emergency módban indítja a rendszert, lesz egy nagyon minimális shelled, amiben néhány alapvető dolgot meg tudsz tenni
- init=/bin/bash: a bash-t hívja meg init folyamatként, nagyon hasznos tud lenni
- autorelabel=1: utasítja a SELinuxot, hogy címkézze újra a könyvtárakat és fájlokat (nagy ritkán előfordulhat, hogy megoldja a problémát)

Plymouth

A plymouth jelenleg nem támogatott, és úgy tűnik, hogy nem is lesz az. Ettől függetlenül meg lehet próbálni feltelepíteni és használni, én részemről nem erőltettem, nem hiányzik.

Nyelv

Ha indokolatlanul sok angol nyelvű felirattal találkozunk (miközben magyar nyelv lett beállítva), futtassuk a következő programot rootként: aeon-mig-firstboot
Ez telepíti a locale csomagokat (és egyúttal hozzáadja a Flathubot a flatpak repókhoz, ha esetleg korábban még nem lett volna hozzáadva).
Ha ez sem működik, akkor a következő csomagok telepítése segíthet:
sudo transactional-update pkg install gnome-desktop-lang gnome-session-lang gnome-shell-lang gnome-menus-lang gnome-bluetooth-lang gnome-control-center-lang gnome-online-accounts-lang gnome-packagekit-lang gnome-settings-daemon-lang gnome-user-docs-lang nautilus-lang gnome-terminal-lang gnome-system-monitor-lang gnome-tweaks-lang gnome-software-lang gnome-power-manager-lang glibc-locale

Videó előnézetek hiánya a fájlkezelőben

Ha a fájlkezelőben (Nautilus) nem jelennek meg a videók előnézetei, lépj ki a fájlkezelőből, töröld a ~/.cache/thumbnails/ mappát, távolítsd el a totem-video-thumbnailer csomagot (ha telepítve van), és telepítsd a ffmpegthumbnailer és a libopenh264-7 csomagot:

nautilus -q
rm -r ~/.cache/thumbnails/
sudo transactional-update pkg remove totem-video-thumbnailer
sudo transactional-update --continue pkg install ffmpegthumbnailer libopenh264-7

Majd indítsd újra a gépet. Ezután már meg kell, hogy jelenjelenek a videók előnézetei.

Ami tetszett és ami nem

Alapvetően azt tudom mondani, hogy azokat a funkciókat, amiket elvárok az Aeontól, szinte teljesen probléma nélkül hozza. Hibás transactional-update után kérés nélkül visszaáll korábbi snapshotra, a frissítéseket teljesen simán tölti le, és a snapper is szépen kezeli a snapshotokat a háttérben.
Nekem nagyon tetszik az az koncepció, hogy a rendszer a lehető leginkább különüljön el a felhasználói programoktól. Mert akármilyen jó is a csomagkezelősdi, néha elég erős kompromisszumokra kényszeríti az embert. Stabil disztrót akarsz? Akkor tegyél fel Debiant vagy OpenSUSE Leap-et, de akkor barátkozz meg azzal, hogy régi csomagokat fogsz használni. Friss rendszert akarsz, mert kellenek az újdonságok? Akkor ott az Arch vagy a Tumbleweed, de akkor viseld el, hogy a programok néha-néha összeomlanak, vagy nem bootol be a rendszer...
A rendszer és az alkalmazások szeparációját természetesen meg lehet oldani bármelyik disztrón, hiszen senki sem tiltja meg, hogy distroboxot és flatpakot telepíts bármelyik másik Linuxra. Az automatikus snapshotkészítést is be lehet konfigurálni (SUSE-vonalon a alapértelmezetten be is van lőve), de ez egy immutable rendszeren mindez összerakva érkezik, nem neked kell bekonfigurálnod. Emellett tényleg ott van az a tény, hogy a fájlrendszered betonbiztos, és ha betartod a programok telepítésre vonatkozó elveket, akkor az is marad.
Nagyon tetszik az is, hogy a distrobox konténerbe telepített programok nem szemetelik össze a rendszert, mert ha nincs rájuk többé szükség, akkor egyszerűen csak töröljük a konténert. Arról nem is beszélve, hogy eltérő disztróhoz készült csomagok is telepíthetők a konténerbe, szerintem ez nagyon nagy dolog. Nyilván vannak határai, nem lehet mindent distroboxba telepíteni, de nagyon sok programot igen.
Azonban mint ahogy feljebb írtam, egy immutable disztróval veszítünk is. Mert nem lehet bármilyen asztali környezetet használni, csak azt, amivel a disztró összeállítói kiadták a rendszert. Ha te éppenséggel a Cinnamont, az Xfce-t, a Mate-et, a Budgie, az LXQT-t preferálod, akkor nincs szerencséd az Aeonnal (Fedora Silverblue-val még lehet, az több asztali környezetet támogat). Bár megpróbálhatod "felhackelni" rá valamelyiket, de egyáltalán nem garantált a siker.
Továbbá nem lehet minden csomagot telepíteni, mert amik úgy vannak összeállítva, hogy a csak olvasható fájlrendszerbe szeretnének írni, azok hibára futnak. Szintén hibára futhat olyan csomagok telepítése, amiket saját telepítővel (jellemzően valamilyen shell script) rendelkeznek, ilyenek pl. a netről letölthető Linuxos illesztőprogramok egy része.

Végszó

Azt gondolom, megvan az esély arra, hogy az immutable rendszerek legalább akkora változást fognak hozni a Linux disztribúciók életébe, mint a SystemD megjelenése. Arról viszont nem vagyok meggyőződve, hogy ez a koncepció népszerű lesz az asztali felhasználók körében, elsősorban azért, mert a komplexitás egy új szintjét vezetik be a hagyományos felépítésű disztribúciókhoz képest - miközben nehéz rámutatni arra a problémára, amit valóban megoldanak. Az immutabilitás egy "nehezen eladható" valami, nehezen tudsz rámutatni arra a konkrét problémára, amit megoldanak - ellenben nagyobb hozzáértést követelenk, mint a hagyományos disztrók, és összetettebbek is. Mivel összetettebbek is, ennélfogva a kezelésük is bonyolultabb (már ha az ember a GUI-n túl kicsit a rendszer mélyebb rétegeibe is bele akar látni), és ez egyúttal azt is jelenti, hogy többet kell tanulni a rendszer menedzseléséhez, mint a hagyományos felépítésű disztribúciók esetén.
Most tegyük a szívünkre a kezünket, és tekintsük azt a Windowsról frissen áttért felhasználót, aki még a terminálozás jelentőségét sem érti. Hogyan fog ő egy immutable disztróval megbírkózni? Hogyan mondod el neki, hogy itt a rendszer csak olvasható, konténerek vannak, oda kell telepíteni a programokat, aztán exportálni kell, meg hogy létezik olyan is, hogy flatpak, és így tovább... nem hangzik túl felhasználóbarátnak.
Az elterjedés másik gátja lehet az, hogy a konténerizáció miatt van némi plusz overheadje az immutable disztróknak, bár eddigi tapasztalataim alapján ez elenyésző, és idővel valószínűleg még inkább csökkeni fog.
Harmadrészt pedig itt van az a tény, hogy némileg korlátoltabbak az immutable disztrók, kevesebb szabadságot engednek, mint a hagyományos rendszerek.

Viszont ha a Linux desktop jövőjéről beszélünk, érdemes megnézni az elmúlt évek, évtizedek változásait a szerverfronton, főleg a corporate disztróknál. Azt láthatjuk, hogy a konténerezősdi jelentősége nagyon megnőtt (sok cég leváltotta a bare metal virtualizált rendszereit konténeresre), és itt-ott már az immutable rendszerek is kezdenek előretörni. Ha abból indulunk ki, hogy a nagy Linuxfejlesztő cégek (Red Hat, SUSE, Canonical) fő termékei a szerveres disztrók (hiszen ebből van a profit) és részben az IoT, az asztali disztrók szinte csak amolyan melléktermékek (a szerverdisztró fejlesztés melléktermékei), akkor azt láthatjuk, hogy a szerverfronton bevezetett technológiák előbb-utóbb megjelennek az asztali disztróknál is (lsd. pl. Systemd). Ezzel nem azt akarom sugallni, hogy a Linux desktopk jövője elkerülhetetlenül az immutabilitás lesz, csak azt, hogy az esély nullánál nagyobb
Azt sem tartom kizártnak, hogy a Linux desktop vonal két jelentős részre fog szakadni, a mutable és az immutable disztrókra. Ebben az esetben a közösségi disztrók maradnak hagyományos felépítésűek, a céges disztrók, gondolva itt a kisebb cégekre is (Zorin, Elementary, stb.) immutábilisak lesznek.

A végére pedig néhány cikk, amik a Fedorával kapcsolatban íródtak ugyan, de a BTRFS funkciói ugyanúgy elérhetők bármely operációs rendszer alatt:
https://fedoramagazine.org/working-with-btrfs-general-concepts/
https://fedoramagazine.org/working-with-btrfs-snapshots/

És egy videó a 2024-es openSuse konferencia egyik előadásáról, amelyben az Aeont vesézik ki (nem csak) fejlesztői szempontból:
https://www.youtube.com/watch?v=24F3uFMrDtE

Két kép a prezentációból: