Meguntam, kész, slussz, passz.
AI... nem is AI ez, hanem nyelvi modell, vagy ha képekről/videóról beszélünk, akkor egy okosabb kép/videó generátor. De baromi veszélyes, főleg az ingyenes verziók. HIBÁZNAK, nem kicsit, hanem nagyon, TOTÁLISAN félrevezetnek sokszor. Gyakran nettó hülyeséget javasolnak.
Oké, persze, van olyan, amikor segít. De sokszor inkább csak hátráltat, főleg programozásnál. Vagy végtelenül fárasztó, hosszadalmas promptot kell írni neki, hogy azt csinálja, amit szeretnél, és még úgy is számos (potenciális) hibát ejt. Hosszú távon ennek nagyon rossz következményei lesznek.
Undorító, hogy minden vonalon már az AI-t nyomják, mint ha valami csodaszer lenne, főleg úgy, hogy egyre inkább érzékelhető a szoftverek romló minősége. Valószínűleg nem csak az AI az oka, de biztos vagyok benne, hogy az is közrejátszik.

Szóval kedves ChatGPT, kedves Claude, kedves Gemini, kedves Perplexity, köszönöm, hogy az életem részei voltatok, de most már kérlek, távozzatok, köszönöm, szevasztok.

Tök jó a Git, mert mindent tud, amit az életben soha nem fogok használni, de amire nekem tényleg szükségem lenne (pl. nagy, bináris fájlok kezelése), azt nem igazán tudja rendesen.
Aki használ vagy használt más verziókezelőt, és itt most elsősorban CVS-re, SVN-re, Mercurialra, BitKeeperre és Perforce-ra gondolok, mesélhetne róla. Mennyivel egyszerűbb a Git-hez képest? Mennyire megbízhatóan kezel nagy méretű bináris fájlokat?
Solo developer vagyok, valószínűleg sosem fog más belenyúlni a kódomba. Ami viszont fontos, hogy Linuxon és Windows-on is dolgozom (a Git szerverem, és az általam használt gépek egy része Linuxos).

AZ LXQt és a Razor-Qt és az LXDE összeolvadásából született könnyűsúlyú, moduláris asztali környezet. A fejlesztők a GTK3 megjelenésekor úgy döntöttek, jobban járnak, ha a Qt-vel folytatják tovább, és szerintem nagyon jól döntöttek...

A Qt, mint keretrendszer, nagyon jól használható megoldásokat kínál, nem csak GUI építésre, hanem egy erős cross-platform alap is egyben. GUI-n kívüli modulokat találunk benne a hálózatkezeléshez, multimédia kezeléshez, adatbáziskezeléshez, és több más területhez is. Felhasználói szemmel nézve számomra egy dolog tűnt fel: GTK alatt sosem sikerült elérnem olyan szép betűtípus simítást, mint amilyen Qt alatt eleve adott.

Az LXQt szinte mindenhez saját megoldást használ. PcManFm-Qt a fájlkezeléshez, QTerminal a terminálozáshoz, Lximage-qt a képnézegetéshez, Qps a folyamatok vizsgálatához, és ugyanúgy power managementre, panel kezelésre, értesítések megjelenítésére, stb. Egyedül az ablakkezelés lóg ki a sorból, hiszen ahhoz Openboxot használ alapértelmezetten, de ez állítható, akár Kwin-t is használhatunk LXQt-vel.

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.