Nem szeretnék semmilyen aktuálpolitikai kérdésben belem menni, nem azért írom ezt a bejegyzést. Csak egy fontos problémára szeretném felhívni a figyelmet, és egy megoldást javaslok, amivel - talán - némileg enyhíthetjük ezt a problémát...

Nos, azt gondolom, sokak számára nyilvánvalóvá vált mostanra, hogy Európa (és elsősorban az Európai Unió) az elmúlt években, évtizedekben számos területen, de főleg a technológiai szektorban, jelentős lemaradásba került. Én itt nem fogom bizonygatni, aki akar, talál rá forrást (na jó, csak hogy ne a levegőbe beszéljek:
https://g7.hu/vilag/20250104/lemaradas-amerika-250-eve-gazdagabb-europanal/, https://www.vg.hu/velemeny/2022/05/europa-technologiai-lemaradasanak-kezelese), és a miérteket sem fogom boncolgatni.
Mivel én Európában élek (mint ahogy gondolom az oldal látogatóinak túlnyomó többsége is), fontosnak tartom, hogy Európa növelje versenyképességét, hatékonyságát, hiszen ez nem csak az én jövőm szempontjából fontos, de nyilván a gyerekeim jövőjét is nagyban meghatározza.
Ezzel a bejegyzéssel azt szeretném megmutatni, hogy mi, átlagos kisemberek, hogyan tudjuk segíteni az EU technológiai felzárkózását a magunk parányi eszközeivel. Ennek egyik legegyszerűbben kivitelezhető módja az, ha vagy Európában fejlesztett, vagy Európában hosztolt, vagy olyan országból származó termékeket használunk, amellyel az EU-nak valamilyen egyezménye van (pl. EFTA). Ehhez egy osztrák programozó készített egy nagyszerű oldalt: https://european-alternatives.eu
Az oldalon különféle kategóriákban tudunk alternatívákat keresni a népszerű (jellemzően EU-n kívüli) szolgáltatásokra, a levelezéstől kezdve, a Wordpress hostingon keresztül, a gépi fordításos szolgáltatásokig bezárólag.
Ez természetesen nem azt jelenti, hogy most azonnal dobj el kapát-kaszát, töröld a Gmail fiókod, és rohanj regisztrálni egy Protonmailest. Hanem csak azt, hogy amikor megteheted, akkor törekedj arra, hogy az EU-n kívüli szolgáltatások helyett az EU-s szolgáltatást részesítsd előnyben.
A listában több olyan szolgáltatást is találsz, ami nem csak azért érdekes, mert EU-s, hanem más okból is. Az Ecosia (https://www.ecosia.org/) kereső például a reklámokból befolyó bevételt fák ültetésének finanszírozására használja (átlagosan 45 keresés kell egy új fa elültetéséhez). Egyébként a cég nagy figyelmet fordít az adatvédelemre, és az átláthatóságra is. Azt viszont tudni kell róla, hogy a keresési találatokat más partnerek szolgáltatják a részére, többek közt a Bing és a Google is (https://ecosia.helpscoutdocs.com/article/579-search-results-providers).
Egy másik, privacy fókuszú, Holland székhelyű kereső a startpage.com. Bár ez is más keresők eredményeit használja fel, de adatvédelmi szempontól megszűri a kéréseket, csak anonimizált adatokat enged át, nem mellesleg csak nagyon minimális mennyiségű reklámot tartalmaz.
Az e-mail szolgáltatók közül tudom ajánlani a Protonmailt, a Mailboxot, vagy a GMX Mail-t.
Ha weboldalt üzemeltetsz, érdekes lehet számodra az észországból származó Plausible, mint Google Analytics alternatíva. Böngészőből a Vivaldi jöhet szóba, irodai programcsomagból az ONLYOFFICE, esetleg a Nextcloud Office. Csapatmunkára Mattermost, a Wire, vagy az Element.
VPN-re a Hetznert tudom jó szívvel ajánlani.

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.

Évek óta téma a Gnome közösségben az, hogy alapjáraton a Gnome ablakkezelője, a Mutter hajlamos mikrolaggokat produkálni. Főleg az áttekintő nézetre váltáskor jön elő a probléma, de például munkaterület váltásakor is látszik.

A Debianosok, és egy ideje már az Ubuntusok sem tapasztalják ezt a problémát, mivel ezek a rendszerek saját patchet adnak a Gnome-hoz, ami megoldja a gondot. A patch mögött álló megoldást triple bufferingnek (Debian), ill. dynamic triple bufferingnek (Ubuntu) hívják. A megoldás lényege, hogy egy plusz middle buffert használ a Mutter, ezáltal sokkal simább és "smoothabb" lesz a kép.
Más, nem Debian vagy Ubuntu alapú rendszerek viszont nem alkalmazzák ezeket a patcheket, főleg azért, mert egyes GPU-k esetében megjelenítési problémákat okoznak. Egyébként a Gnome saját triple buffering megoldása évek óta be van harangozva, és most is ott tartunk, hogy a következő Gnome verzióban meg fog érkezni (egyébként négy éve húzódik már a dolog)...
Nem hivatalos forrásból szármató patchek azonban elérhetők más rendszerekre is. Arch alapú rendszerek esetében a mutter-dynamic-buffering csomagot kell telepíteni, Fedorához (atomic rendszerekhez is) a trixieua/mutter-patched COPR repót kell hozzáadni, és a leírás szerint telepíteni a patchelt Muttert, OpenSuse alapú rendszerekhez pedig tjyrinki mutter repójából kell telepíteni a Muttert. Ezek a patchek lefedik a disztrók nagy részét, de ha valaki olyan disztrót használ, ami nincs ezek között, akkor nézzen körül, biztosan készült hozzá már patch. Reméljük, hogy mielőbb bekerül a Gnome-ba a gyári patch, így nem kell majd külön telepítgetni.
Természetesen, mint minden patch, ez is okozhat hibákat. Ha meg vagy elégedve a Gnome sebességével, úgy érzed, eléggé simán és egyenletesen fut, akkor inkább ne telepítsd a patchet.
Én egyelőre csak Fedora Silverblue-hoz telepítettem egy régi, második generációs Intel gépre. Eddig nem tapasztaltam semmilyen hibát, viszont eléggé látványos a különbség. Ha lesz időm, kipróbálom más disztrókon is.

Az immutable operációs rendszer

Az Aeon Desktop, az OpenSUSE immutable asztali operációs rendszere, amely a szerver operációs rendszernek szánt MicroOS alapjaira épülve kezdte meg pályafutását, azóta azonban már önálló ággá vált. Valójában a rendszer alapjai a 2017-ben indult, majd pár év múlva elkaszált Kubic projektig nyúlik vissza.
Az Aeon a Tumbleweed csomagjaiból építkezik, így egy rolling rendszerről beszélünk, de mégsem tekinthetjük azonosnak a Tumbleweeddel, hiszen felépítését tekintve teljesen más.

Jó néhány éve léteznek immutable rendszerek szerver, desktop, mobil és IoT vonalon is. Ott van többek közt a SUSE MicroOS, a SUSE SLE Micro, a Kalpa, Fedorától az Atomic desktops vonal alatt futó disztribúciók (Silverblue, Kinoite, stb.), Canonicaltól az Ubuntu Core, a Gentootól a CoreOS, a Red Hat Atomic Host a Red Hattól, és a Debianra épülő EndlessOS és a VanillaOS is, illetve az évtizedek óta létező, nem csak Linux-alapú rendszerek beágyazott vonalon. Immutable rendszerek futnak továbbá az okostelefonokon, és a NAS-ok többségén is.
Én azért döntöttem az Aeon mellett, mert mostanában szinte csak OpenSUSE rendszereket használok, így kézenfekvő választás volt egy immutable OpenSUSE rendszer kipróbálása.
Régóta kíváncsi vagyok, hogy mit tud nyújtani egy immutable rendszer a hagyományos felépítésű rendszerekhez képest, így lassan két hónapja, hogy feltelepítettem az Aeont. Eleve úgy indultam neki a tesztelésnek, hogy nem csak néhány kört akarok futni vele, mert szerintem ez a koncepció megérdemli a tüzetesebb vizsgálatot, bár sosem szoktam "félkész" (béta/alfa/RC) rendszereket kipróbálni, de most kivételt tettem. Jelen pillanatban az Aeonból az RC3-as kiadás érhető el, így én is ez alapján írom a tapasztalataimat. A tervek szerint ez az utolsó RC kiadás, úgyhogy valószínűleg a végleges kiadás sincs már túl messze, viszont mivel az Aeon a Tumbleweed csomagjaira épül, így addigra elég sok minden változhat még.

A Distrobox egy olyan program, amivel konténerizált Linux disztribúciókat futtathatunk a gépünkön futó Linuxon belül. Ami miatt nagyon hasznos tud lenni, az az, hogy az alaprendszertől eltérő disztribúciókat, és azon belül eltérő verziókat is használhatunk.

Tehát ha pl. Debiant használunk, telepíthetünk mellé konténerbe egy Arch-ot, egy Fedorát 39-es és 41-et, egy Ubuntu 20.04-et és egy 24.10-et, és mondjuk egy OpenSuse Tumbleweed-et is.
De ahhoz, hogy jobban megértsük a Distrobox működését, nézzük meg, mi az a konténerizációt.

A konténerizáció, azaz a Linuxos operációs-szintű virtualizáció

A konténerizáció egy eléggé "túlterhelt" fogalom lett mára, elég sok, egymástól többé-kevésbé különböző megoldást hívunk konténerizációnak. Amiről itt szó van, az kifejezetten a Linuxos operációs-szintű virtualizáció.
Nos, a konténer tulajdonképpen egy elszeparált futattókörnyezet az operációs rendszeren belül. Egy konténerben futtatott program csak az ugyanabban a konténerben futó processzeket látja, csak az ugyanbban a konténerben lévő fájlokhoz, könyvtárakhoz és hálózati megosztásokhoz fér hozzá, csak a konténernek átadott eszközöket látja, és így tovább. Ráadásul nagyon egyszerűen szabályzhatók a konténerben futó folyamatok erőforrásai (CPU, memória, lemez I/O, stb.). Mindezt a Linux kernel "csípőből" hozza, hiszen a szeparációt megvalósító "kernel namespaces" 2002 óta a Linux kernel része, az erőforrás-szabályozást biztosító "cgroups" pedig 2008 óta, úgyhogy nem egy újkeletű dologról van szó, mondhatni, teljesen kiforrott a technológia. Konténereket szinte mindenki használ, akár úgy is, hogy nem is tud róla - pl. sok NAS is konténerben futtatja az appjait, de a mobilalkalmazások is a saját kis konténerükben futnak.
A konténerek elég rugalmasak, olyan szempontból, hogy futtathatunk bennük csupán egyetlen binárist, vagy belecsomagolhatunk egy binárist a függőségeivel együtt, de nagyon gyakori az is, hogy egy nagyon minimális, de működő Linux disztribúció kerül a konténerbe, és azon a környezeten belül fut a program.
A Distrobox egy segédeszköz, amivel ilyen, konténerizált Linuxot futtathatunk úgy, hogy a létrehozott konténer szorosan integrálódik a rendszerbe.
Maga a Distrobox nem egy konténer implementáció, hanem Dockerre, Podmanre vagy Lilipodra épülve oldja meg a konténerizációt. A Podman a javasolt megoldás, mert "rootless", azaz nem szükséges hozzá, hogy folyamatosan fusson egy root szintű daemon, mint Docker esetében. A konténerekben futó operációs rendszer kernele osztozik a gazdagépen futtatott kernellel, az izoláció kernel szinten történik, tehát a kerneltől "magasabb" (felhasználó-közelibb) szinten lévő rétegek különölnek.

Az OpenSuse Leap következő verziója, a 16.0, a SUSE által 2022-ben bejelentett ALP (Adaptable Linux Platform) elveire fog építeni. Hogy ez technikailag pontosan mit jelent, arról nem túl sok információt lehet találni, és mivel az utóbbi időben a SUSE is ráállt az immutable disztrók fejlesztésére, ezért több kérdés is felmerült a következő Leap verzióval kapcsolatban. Immutable lesz ez is, vagy megmarad a hagyományos felépítés? Mit jelent pontosan, amit a SUSE már egy ideje hangoztat, hogy a Leap ALP alapú lesz? Egyáltalán mi az az ALP?

A SUSE idén januárban, mindenki megnyugtatására kiadott egy közleményt ezzel kapcsolatban, amiben azt írják, hogy megmarad a klasszikus, mutable Leap-vonal, de emellett készül belőle immutable változat is:
"There are no plans to drop the classical (non-immutable) option for Leap; both non-immutable or immutable installation variants are available for Leap 15 and are planned for Leap 16. This is set to remain the preferred way for people to deploy Leap."
(https://news.opensuse.org/2024/01/15/clear-course-is-set-for-os-leap)

Frissítés: ez a leírás a DNF 4-es verziójához készült. A Fedora a 41-es verziótól kezdve az 5-ös verziót szállítja alapértelmezettként, aminek kissé mások a kapcsolói, és esetnként másképp működik. A változásokról itt olvashatunk bővebben.

A DNF (DeNdiFied YUM) egy fejlett, RPM alapú csomagkezelő, mely elsősorban a Red Hat Linux és annak leszármazott disztribúcióiból (pl. Fedora, CentOS) lehet ismerős, de más disztribúciók is használják. A YUM továbbfejlesztéseként jött létre, annak hibáit (gyenge teljesítmény, lassú függőségfeloldás, magas memóriahasználat) orvosolandó. A DNF a függőségek feloldására az OpenSuse Zypperétről kölcsönzött libsolv-ot használja, mely gyors iteratív függőségfeloldsást biztosít. Maga a DNF, mint program, alapvetően egy frontend a libdnf által biztosított szolgáltatásokat eléréséhez.
Ebben a blogbejegyzésben szerentém összegyűjteni a DNF legfontosabb parancsait és kapcsolóit, hogy segítségére legyen azoknak, akik DNF-es disztribúciót használnak vagy terveznek használni. Nem taglalunk minden egyes opciót, de a leggyakoribb felhasználási esetekre kitérünk. A bejegyzés nem rövid, de természetesen nem szükséges az egészet fejből tudni, elég néhány alapvető parancsot megtanulni ahhoz, hogy jól tudjuk használni a DNF-et. Vannak a leírásban olyan szakaszok, amiket valószínűleg sosem fogsz használni.
A bejegyzés elején a DNF parancsait és kapcsolóit taglaljuk, a végén pedig a DNF által használt konfigurációs fájlokról ejtünk pár szót.

Avagy "Plain text is beautiful!"

Nos, igen, arról a gopher protokollról van szó, amit 1991-ben fejlesztettek ki a Minnesotai Egyetemen, és nem tudott mást, mint egyszerű szöveges dokumentumokat továbbítani, megjeleníteni és keresni köztük.
Később, a Gopher+ révén képessé vált ugyan PostScript fájlok és multimédiás anyagok átvitelére, űrlapok kezelésére és metaadatok küldésére, de mire a Gopher+ elterjedhetett volna, megjelent a World Wide Web, ami szinte teljes mértékben átvette a gopher helyét. Ahogy a web növekedett, a gopher szerverek száma egyre csökkent, míg nem a kétezres évek elejére kevesebb, mint 200 élő gopher szerver maradt egész internetszerte.
Aztán 2010 után történt valami, és a gopher szerverek száma lassú ütemben növekedni kezdett. A pontos okokat nem ismerjük, de valószínűleg annak köszönhető, hogy egy gopher szerver üzemeltetése eléggé egyszerű és olcsó feladat lett ahhoz, hogy kiváló terep legyen a retro érdeklődésű hobbisták számára kedvetelésük kiéléséhez. A gopher keresője, a Veronica-2 szerint manapság körülbelül 325 aktív szerver üzemel, melyek összesen 5 millió egyedi dokumentumot tárolnak.

A kis Raspberry Pi B-m, és az ő 175 napos uptime-ja. Kicsit több, mint fél éve vásároltam, csak a telepítéskor volt újraindítva, azóta sem. Most is csak azért lőttem újra, mert frissítettem a Raspbiant.
Erről fut a Gemini szerverem.