Az élet kódjai

Mivel a Function kihagyása miatt a "nyakamon maradt" egy videó, ezért elkezdtem keresni, melyik partin tudom elsütni, lehetőleg még az idén. Magyar partiból az Experience volt az utolsó, de ott nem lehetett videót beadni, ezért egy olyan külföldi partit kellett találni, ahol fogadnak remote entry-t. Így esett a választás a Tokyo Demo Festre.

Csak a videó szövegezésén kellett változtatni, meg a leírásban módosítani pár dolgot, és már készen is állt a megmérettetésre. Ez nagy szerencse volt, mert viszonylag kevés idő állt rendelkezésre a regisztráció megnyitása és az entry beküldése között.

Az időeltolódás miatt itthon délelőtt lehetett megnézni a streamet. Lássuk milyen gyöngyszemeket tartogat nekünk a Felkelő Nap országának partija.

Grafika

A grafikák bemutatásánál nagyon zavart, hogy jelentéktelen részletekbe nagyítottak bele. Az indulók minden elképzelhető állóképet beadtak. Volt fotó, hosszú záirdővel, Amigás rajz, C64 petscii, kézirajz (Sharko), Blender render (Hot night in Singapore). Valamint három procedurális grafika. A kedvencem a ToyDuck volt, mert nagyon szépek voltak a textúrák.

Zene

 Zenei stílusból is kaptunk egy nagy csokorral. Még procedurális zene is volt (Deep Space, bár hallgatni nem volt akkora élvezet).

Wild

Kaptunk egy GBA demót, de nem sok minden volt benne a színes négyzeteken kívül. Láttunk egy Shadow Party invitációt is. Optimus és Ham jóvoltából láthattunk egy 3DO demót, és megtudtuk, hogy nagyon sok release kellene erre az általam tök ismeretlen platformra. Az igazán jó alkotás a kategóriában a Santaz Triptro volt. Ami nagyon tetszett benne, milyen kreatívan oldották meg, hogy a látszólag össze-vissza katakterek mégis értelmezhető látványt adjanak vissza. Az én videóm a negyedik lett.

GLSL demó

Ezt a fajta compót még nem láttam. Egyetlen fragment shaderből kellett demót készíteni. A deep learning bullshit ide is betört. A Dnn_gold_skull a népszerű buzzword technológián alapuló valami, ami kirajzol egy koponyát. Túl sokat nem láttam belőlük, mert pont akkor kezdtek el az otthoniak nyafogni a fülembe.

Demo

A demó kompó inkább 4k volt, mert az indulók fele ebben a mérettartományban maradt. Akadt egy 64k is, úgyhogy igazi demóból csak 3 volt. Technikailag kétség kívül a Domain volt a legjobb, egy webGL-es 64k, bár elég unalmas volt, ahogy különböző típusú kockákat mutattak. Talán nem vagyok elég kocka, hogy értékeljem a sok kockát? Az A.L. pedig totál érthetetlen volt. Szerepelt benne egy elég részletes anime karakter, és egy csomó textúra nélküli platóni test kontúrja, amik csináltak valamit. Mindez Unitybe oltva. Nekem talán a Spikes von Aldi 4k intró tetszett a legjobban, bár a kód nem volt erős. A Folded garden egy jó kis fraktál intró volt, de a színei nagyon szokatlanok voltak a szememnek. A klasszikus demót kedvelők bizonyára a H.A.L.T. III-ra tennék a voksukat. Itt 3D objektek forogtak egy csatornában.

Összességében nem volt nagy eresztés. Minden kommunikáció japánul ment. Még amikor angolul beszéltek, azt is japánnak hallottam. A szemináriumok, amelyeket megpróbáltam végignézni, az is rettenetes volt, mert minden dián szöveg volt. Csak a beszúrt angol szavakból tudtam kitalálni, milyen témakörről beszéltek. A live coding viszont nagyon jó volt. Megjött a kedvem, hogy jobban elmélyedjek a fragment shaderek világában.

Function-re videóval készültem volna. Végül nem jutottam el a partira, de szerettem volna bemutatni az alkotásomat, ráadásul a témája miatt mindenképp magyar rendezvényen, ezért az Experience-re esett a választásom. Ott viszont csak futtatható dolgokat lehet beadni. Mivel nem volt egy különösen összetett produkció, gondoltam, még én is képes vagyok demót készíteni belőle. Sikerült is, határidő előtt, ami nem kis teljesítmény tőlem, de mint mondottam is, bonyolult sem volt.

Elmentem a partira, ami szokás szerint visszafogottabb volt egy több napos rendezvényhez képest, amit én a nézők elfogyasztott alkohol mennyiségéből állapítottam meg.

A demóm persze Linux alatt futott, ezért előrelátó módon vittem egy laptopot is, hogy legyen min bemutatni azt. Látszik, hogy fejlődik a technika, mert csak rádugtam a HDMI-t a keverőre, és már ment is a hang, kép, minden. Hol vannak már azok az idők, amikor X11 konfigot szerkesztettem a compó gépen! Brrr, remélem soha nem jönnek vissza!

Először az év legjobbjait mutatták be, ahol lehetett, még némi háttér információt is csepegtettek az alkotásokról, amit én mindíg nagyon szeretek. A második bemutató blokk után Archee odaült mellém, ami plusz élményfaktor volt. Tudni kell, hogy a veterán scenerek legtöbbjét (plána, ha nyertek egy-két Assembly-t) elég nehéz lenyűgözni. Például én enyhén fátyolos szemmel néztem a kivetítőt a katarzis határán lebegve, mire Archee megszólal mellettem: "Egész jó fát csináltak háromszög levelekkel." Onnantól én is csak a háromszög alakú leveleket láttam. Majd elgondolkodtam: miért ne csinálhatnék én is háromszög levelű fákat?

A demó compó blokk velem kezdődött. Néhány embert megnevettettem, ezzel a célomat el is értem. Közben Archee nagyon kíváncsi lett, miért az én laptopomról megy a demóm. Mikor megtudta, hogy Linuxon nyomom, mindjárt jöttek a "miért nem Windows", miért nem fordítok Linuxról Windows binárist, stb. Mondtam neki, hogy a Linuxos entry az imázsom része.

A következő demó ZX Spectrum volt, ez videóról ment le. A kommentek alapján egy matematikus beállítottságú scener írta, ami meg is látszott, mert kelta mintázatokat genrált. Majd jött a Lunaticats, amiből megtudtuk, hogy jövőre is lesz QBParty. Tifeco Demojoe-ja újabb kalandban vett részt, ezúttal party szervező lett. A poénok legtöbbje a külső szemlélőnek valószínűleg nem jön át, de mi a vetítésen nagyon jól szórakoztunk rajta. Az Ümlaüt Design is könnyed 64k-s ujjgyakorlattal járult hozzá a compóhoz. Végül a Der Trabantot láttuk. Szerintem a cím mindent elmond.

Összességében egy könnyed demó nézegetős este volt, amin jót szórakoztunk.

A kvantum szó a tudományban olyan, mint a szép nők a reklámokban. Velük mindent el lehet adni. Így van ez a következő workshoppal is, aminek a címe: Az élettudományok jövője: a kvantumbiológia. A cím kétségtelenül figyelemfelkeltő, majdnem el is mentem rá, mert el nem tudtam képzelni, hogyan kapcsolódhat össze a két tudományterület.

Végül azért hiúsult meg a dolog, mert kicsit utána néztem az előadóknak. Az első előadó ugyanis tényleg orvos, de már évek óta nem praktizál, hanem politikusnak állt, legalábbis a wikipédia szerint. Biztos remek rálátása van a tudomány új trendjeire.

Aztán ott van Szacsky Mihály, akiről kiderült, hogy tényleg egy igazi kvantumbiológus. Hőkamerával bámulja az embert, de nem ezt mondja nekik, hanem azt, hogy szomatoinfra vizsgálatot végez, amitől mindjárt másképp hangzik az egész. Egyébként ez a fickó egy külön posztot érdemelne, annyira hihetetlen, amit művel. Csak röviden: Létrehozott egy egyesületet, ami a Műegyetemi Természet és Sporttudományi Egyesület nevet viseli, ami alapján úgy adja elő magát, mintha a "Műegyetemen" oktatna/dolgozna. Publikációit a Pannon Palatinus weboldalon mutatja be, amit ő alapított.

Hajtó János a kiírások szerint az Edinbrugh-i Egyetemen dolgozik, de egy rövidített önéletrajz szerint csak 2006-ig volt ott. Ez nem akadályozza meg, hogy továbbra is az egyetem színeiben parádézzon. Azóta inkább ügyvezető igazgatóként dolgozik, tudományos munkát manapság nem végez.

Szatmáry Zoltán tényleg ért a kvantum folyamatokhoz, mert a BME Nukleáris Technikai Intézetében dolgozott, de jelenleg nyugdíjas. Elképzelhetőnek tartom, hogy ő egy aktív nyugdíjas, aki a rászakadt szabadidejét a kvantumbiológia művelésére fordítja, de ez a rendelkezésére álló lehetőségeket figyelembe véve ez valószínűleg kimerül az irodalom olvasásában, esetleg egy-két számításban.

Ábrahám György tudományosan is aktív az előadók közül. Nemzetközi és hazai folyóiratokban is megtaláltam a nevét. Nem tudom, hogyan érezhette magát ebben a társaságban.

Tóth Miklóst nem tudtam egyértelműen beazonosítani, de hajlok arra a véleményre, hogy ő is inkább a tudományos vonalat erősíti, mivel az összes általam megtalált MTA doktora címet viselő Tóth Miklós aktív, publikációs listájuk szépen gyarapszik.

A workshop biztosan nagyon sikeres lehetett, mert a rendezvény alapján megállapították, hogy az egyetem a kvantumbiológiában is kimagasló. Ez a rendezvény a Magyar Tudomány Ünnepe programsorozat része volt! Ezzel ünnepeljük a magyar tudományt. Úgy gondolom, ha fel akarjuk venni a harcot az áltudományok ellen, akkor először a tudományt kellene rendbe tenni.

Minden esetre én nem tudom, mi az a kvantumbiológia, de úgy tűnik az előadók többsége sem.

Akármennyire is óvatos voltam, a negyedik hullám elkapott. A feleségem szervezete egy ideig ellenállt, de mire kezdtem meggyógyulni, ő lett beteg. Kis családunk ismét elszakadt a külvilágtól. Melóhelyen bejelentettem annak rendje és módja szerint, mire a munkahelyi COVID felelős megnyugtatott, hogy bizalmasan kezeli a helyzetemet.

Ez azután történt, hogy kiderült volna, hogy akinek először írtam, csak a második hullám idején volt COVID felelős, most már semmi köze az egész procedúrához. Azért segítőkész módon továbbította a levelemet. A szolgálatos felelős megkért, hogy szóljak mindenkinek, akivel kapcsolatba kerültem. Szóltam mindenkinek. Aztán egyik munkatársamnak eszébe jutott, hogy a hallgatóknak is szólni kéne, mert mégis csak bent voltam a teremben, ha nem is tanítottam őket. Végül valakinek az is eszébe jutott, hogy Manci nénit is figyelmeztetni kell, hiszen veszélyeztetett (az igazi neve nem Manci, megváltoztattam.) Ez már kicsit sok volt nekem. Ki az a Manci? Egyetlen munkatársamat sem hívják Mancinak.

Kiderült, hogy egy nyugdíjas kutatóról van szó, aki az ominózus időszakban egyszer belépett az irodába, mikor én már nem tartózkodtam bent. Gondoltam, egye meg a fene a személyiségi jogaimat, szóljanak Manci néninek is.

Az otthon maradással annyira nem is lett volna baj, viszont a lakás kezdett tönkremenni. Túlélő üzemmódra kapcsoltunk, mint Phileas Fogg a Henrietta fedélzetén. Először a gyerek szobájában ment ki a villany. Mivel világításnak lennie kell, átcsoportosítottam az egyik körtét egy másik helyiségből. Ezzel némi időt nyertünk.

Aztán jött a konyhai csaptelep. Már eddig is elég vízköves volt, amitől ha elfordítottuk a csapot, pár csepp víz folyt ki belőle az illesztések mentén. Csakhogy a szigetelés nem volt tökéletes a mosogató és a csaptelep között sem, ezért a víz elkezdett gyűlni alul, a szekrényben. Elkezdtem kajtatni a lakást gumiszerű anyagok után, amivel szigetelést tudok csinálni. Végül ráakadtam a gyerek lufigyűjteményére. Nem akartam még nagyobb traumát okozni neki, ezért olyan színt választottam, amiből több egyforma is volt. A lufi meglepően jó választás volt, mert a száját levágva pont egy gyűrű alakot kaptam, amit a csaptelep megfelelő részére húzhattam, még rá is feszült a fémre.

A harmadik csapás lustaságom miatt volt. A gyerek hazahozta még a karantén előtt két tankönyvét, ami olyan állapotban volt, mint egy saláta. A boritó elszakadt, ezért csemetém begyűrte azt az iskolatáskába és rápakolt mindent, hátha nem tűnik fel. A fedőlap leszakadt, a széle pedig feltekeredett valahogy, mint egy palacsinta. Mikor megláttam a könyvet és a hasonló állapotban lévő munkafüzetet, komolyan felmerült bennem a szándékos szabotázs gondolata.

Akkor még arra gondoltam, majd lesz időm megcsinálni mindkettőt, hiszen nemrég kezdődött az őszi szünet. A karantén alatt időm volt is rá, csak alapanyagom nem. Két napig préseltem a fedlapot, hogy eltüntessem a szamárfület, de nem akart visszasimulni. Gondoltam egy karton segítségével merevebbé tehetném a lapot, de nem volt otthon karton. Legalábbis nem a hagyományos értelemben.

Találtam egy papír táskát, ami sokkal erősebbnek tűnt egy átlagos kartonlapnál. Szétvágtam, majd a fedlap belső oldalára ragasztottam. Ez sem fog többet bepöndörödni.

A demó motoromat, ami technikailag egy API, új tulajdonsággal vérteztem fel. Immár képes JPEG fájlokat is használni textúrának. A libJPEGTurbót használtam, mert elég egyszerűnek tűnt a használata, és az Ubuntunak része a könyvtár.

Első használat alkalmával meglepődtem, hogy a kép fejjel lefelé jelent meg, de ezzel nem törődtem sokat. Képet forgatni a világon a legegyszerűbb. Csupán örültem, hogy a kód működik. El is kezdtem készíteni egy demót Experience-re. Szépen haladtam, amikor az egyik textúra betöltésénél core dump-olt a program.

Rögtön észrevettem, mi a baj. Szürke árnyalatos volt a kép, miközben a kód RGB-t várt. A homlokom akkor szaladt csak igazán ráncba, amikor kiderült, hogy a kép RGB verziója is elszáll. Ráadásul a hiába kerestem a hibát, a backtrace szerint a hiba a videó driverben egyik moduljára mutatott, amihez már nem értem gdb-vel. Az én kódomban a glTexImage2D volt az utolsó utasítás.

Nem értettem, hogy két kép közül, amelyek csak a dimenzióban térnek el, az egyik miért működik, miközben a másik lefagy. Elkezdtem különböző méretű textúrákat gyártani, de azok is fagytak. Átkonvertáltam PNG-be, akkor működött.

Ráadásul volt egy nagyon furcsa jelenség is. A "hibás" képpel nem minden esetben szállt el a program. Ritka esetben betöltődött, de el volt csúszva, mintha a kép pixeleit egy kisebb szélességű helyre akarnám betölteni, amitől a következő sor jobbra mozdul. Egy eredetileg függőleges vonal a képen átlóssá vált.

Úgy tűnt, a kép több helyet foglal a memóriában, mint amennyit én allokáltam. Ezzel csak az volt a baj, hogy az összes fellelhető példaprogram szerint mindent megfelelő módon csináltam. Illetve mégsem egészen. Kiderült, van egy paraméter, amivel úgy is be lehet olvasni a JPEG-et, hogy ne legyen fejjel lefelé.

Végül kiderült a turpisság. A kép szélességének 4-el osztható bájtnak kell lennie, különben a glTexImage2D elhasalhat. A PNG-nél nem volt gond, mert ott mindig 4-el osztható volt a szélesség, mert a PNG-ben RGBA-ban tároltam a kép információt. A megoldás csupán annyi, hogy meghívjuk a glPixelStorei-t, és elmagyarázzuk a drivernek, hogy ettől legyen szíves eltekinteni.

Vannak jó bioinformatikai pipeline-ok. Vannak tűrhető bioinformatikai pipeline-ok. És van a FROGS.

A FROGS rettenetes, de ez valami miatt senkit nem gátolt meg abban, hogy a Galaxyba integrálják, mert így el lehet fedni az összes hiányosságát. De kezdjük az elején.

A FROGS-ban semmi egyedi ötlet nincs. Az összes funkció, amit nyújt, más programok végzik, de ezt nem látjuk az ezeket elfedő Python szkriptek halmazától. Adaptor eltávolítás? Van egy szkript, ami meghívja a cutadaptot. Szekvencia klaszterezés? Van egy szkript, ami meghívja a swarm-ot. Taxonómiai meghatározás? Van egy szkript, ami meghívja a BLAST-ot. Kérdem én, miért ne futtathatnám ezeket a programokat egy Snakemake-ben magam?

Azt gondolhatnánk, hogy talán van egy egységes telepítő, ami ezt a sok, mások által megírt programot feltelepíti, de nem. Bár a pearl kivételével mindegyik teljesen ingyenes, még akkor sem kerül fel a gépünkre, ha conda-n keresztük installáljuk a FROGS-ot (például a cutadapt benne van a conda-ban is, csak be kellett volna írni a függőségek közé). Ráadásul, ha kézzel telepítjük, még csak arra sem vették a fejlesztők a fáradságot, hogy legalább kiírja a program, ha egy komponens hiányzik.

Ha valami hiányzik, az futás időben derül ki. A program szép logokba írja őket, amiket a futás végeztével letöröl. Minek vannak ezek a logok, ha utána nem lehet elolvasni őket? Persze, ilyenkor kell a --debug opció, de miért kell kétszer lefuttatnom valamit?

Mondhatják nekem, hogy "talán a sok szkriptet összefogja egy mester szkript, és csak azt kell elindítani". Rossz hírem van. Minden egyes szkriptet a felhasználónak kell elindítania. Itt kerül elő a FROGS másik nagy hiányossága. Ugyanis nincs leírva, mi a nevük a nyomorult szkripteknek, és mi a javasolt futtatási sorrend. Az egyetlen fogódzkodó ez. Csupán elavult, más baja nincs. Például a tény, miszerint nincs filters.py egy GitHub-os issue-ból derül ki, amit lezártak, mert megoldották a problémát.

A program rengeteg adatbázist használ, ami csak itt van. Melyik mire való? Találd ki! Esetleg használd a Galaxyban, hogy ész nélkül lehessen klikkelgetni.

Esetleg úgy gondolod, hogy a program teljesítménye kárpótol mindenért? Nem. Tíz processzort használva három napig futott egy hibás szekvenálási soron (az egy külön sztori lenne, hogy mitől hibás, de elég az hozzá, hogy a gép áteresztő képességének csupán töredékét kaptuk vissza). Kíváncsiságból ugyan ezt az adatot beadtam a Kraken alapú helyi elemző apparátusomba, ami egy ősrégi HP szerveren fut 4 maggal. Kb. fél óra alatt megvolt minden eredmény.

Szóval, ha valaki arra kér, hogy elemezzünk metagenomot FROGS-al, csak egy válaszunk lehet.

Közben rájöttem a Docker és Conda alkalmazásának egy új lehetőségén. Ezek az eszközök nem abban segítenek, hogy könnyű legyen a telepítés, netán megismételhető legyen az elemzés. Ez úgysem érdekel senkit. Ezek az eszközök arra jók, hogy a FROGS-hoz hasonló förtelmeket nyom nélkül eltakaríthassuk, és azt is elfelejtsük, hogy valaha használtuk. Ne maradjon utánuk SEMMI.

Annyi kihasználatlan PC van a lakásomban, hogy akár Hadoopot is telepíthetek rájuk. De egy Hadoop önmagában nem sok mindenre jó (azon kívül, hogy a családot ne csak egy, hanem három gép folyamatos zúgásával idegesítsem), ezért úgy gondoltam, kipróbálom a Sparkot.

Korábban már volt egy ilyen fellángolásom, de ott csak egy gépre akartam mindent felrakni. Mostani próbálkozásom alkalmával mindent binárisból telepítettem, hogy az időm nagy részét ne a fordítás vegye el, hanem a konfigurálás. Az egyszerűség kedvéért minden számítógépen ugyan azzal az elérési úttal helyeztem el a programokat, hogy csak egy Hadoop konfigurációt kelljen beállítani, és azt másolhassam a többi gépre.

Ez nem teljesen sikerült, mert a CentOS-es gépen a Java csomag verziószáma egy ici-picit eltér az Ubuntus gépeken lévőtől, ami a rendszerfrissítéssel is változik, de ettől az apróságtól eltekintve a konfiguráció hordozható volt.

Ezután minden gépnek meg kellett adni, hogy az összes többi gépet ugyan olyan néven lássa, tehát az /etc/hosts fájt is legyen ugyan az mindegyik vason. Ha nem így van, akkor olyan furcsa anomáliák lesznek, hogy a master gép látja a worker node-okat, de azok nem tudnak visszaszólni a master-nek. Még annyit csináltam, hogy az otthoni routert is beállítottam, hogy a Hadoopos gépeknek mindig fix IP-t adjon.

A felhasználó név is legyen ugyan az mindegyik gépen és ssh kulcsos hitelesítést kell beállítani. Mivel ez egy otthoni teszt környezet, a biztonságra nem helyeztem külön hangsúlyt, tehát nincs szeparált hadoop user, valamint a master gép egyben worker is volt.

Ezután a master gépen, ha elindítom a start-all.sh parancsot, akkor minden szükséges komponens elindul az összes gépen.

Ezután jön a Spark telepítése, szintén binárisból. Itt is ugyan az az elv érvényesül, mint a Hadoop esetén. Az összes gépre telepíteni kell. A konfigurációs állományok viszont alapból nem aktívak, mindegyik egy .template kiterjesztést kap, amit el kell távolítani, ha használni akarjuk. A slaves fájlba fel kell venni az összes gépet, amelyeket be akarunk fogni a munkába. Itt is az sbin könyvtárban van egy start-all.sh, amivel minden gépen elindíthatjuk a Sparkot.

A Spark egy táblázatos adatok feldolgozását segítő rendszer. Gyorsaságát az adja, hogy amit lehet, memóriában végez, de a műveleteket el tudja osztani több gép között is, ha kell. A Spark ezen felül lusta kiértékelést végez, ami azt jelenti, hogy addig nem hajtja végre a feladatot, amíg nem szükséges. (Ami azért érdekes, mert a való életben ezt az attitűdöt nem a gyorsasággal azonosítják.) Többféle nyelven is lehet használni a rendszert, én a Pythont választottam.

Először egy könnyed bemelegítéssel kezdtem, végigcsináltam  ezt a tutorialt. Erről nem érdemes többet írni, hacsak azt nem, hogy az adatok betöltése elsőre nekem nem sikerült, mert én helyi adatot akartam betölteni, de a PySpark a HDFS-en kereste a fájlt, mikor erre rájöttem, és elhelyeztem a fájlokat a Hadoop fájlrendszerére, már könnyű volt a munka.

A próba adat elég kicsi volt. igazából a Spark a master node-on megoldott mindent. Kíváncsi voltam, meg tudom-e izzasztani a rendszert. Az egyik munkahelyi projekthez egy 19GB-os táblázatot kellett készítettem ebből az adatbázisból, gondoltam megetetem az otthoni rendszerrel. Ez már elég nagy, hogy a master ne tudja a teljes adatszettet memóriába tárolni.

Amikor elkezdtem felmásolni az adatokat HDFS-re, rögtön kaptam egy hibaüzenetet, hogy az egyik datanode-ra nem fog másolni, mert nincs rajta elég hely. Kár, mert az volt a legerősebb gép a csapatban. (Persze, ez is a CentOS-es gép volt, ahol a home kapja a legnagyobb partíciót, az összes többi adat meg pár száz gigán tömörül. Végül a HDFS adatoknak egy symlinket hoztam létre, ami a home-ra mutatott.) Az adatokról annyit érdemes tudni, hogy peak információk vannak benne pár ezer Chip-seq kísérletből.

./hdfs dfs -put ~/peaksfromchipseq.tsv /peak.tsv

Ezután indítottam a PySparkot, és betöltöttem az adatokat.

import pyspark
from pyspark.sql import SQLContext
from pyspark import SparkFiles

sql = SQLContext(sc)
peak = sql.read.option("delimiter", "\t").csv("/peak.tsv", header = True, inferSchema = True)

Ezen már elszüttyögött.

peak.filter(peak.antibody == "CTCF").groupBy("expID").count().show()

De ez is csak egy gépen futott. Úgy látszik a rendszer elég jól bírja a gyűrődést. Úgy gondoltam, itt az ideje, hogy tényleg megizzasszam a rendszert.

A következő fájl még nagyobb volt. Tíz teljes genome szekvenálásból szedtem ki a lefedettség értékeket (samtools depth), ami elérte a 143 GB-ot. Ebből akartam átlagos lefedettségeket számolni, ami egy szálon egy erősebb szerveren 3 órát vett igénybe (saját Python kód, nuku optimalizáció, azért tartott ilyen sokáig).

Először felmásoltam a fájlt a HDFS-re, külön ügyelve rá, hogy a replikációt 3-ra állítsam, hogy minden gépen legyen egy kópia az adatokból. Arra gondoltam, az a node biztosan nem fog dolgozni, amelyik tárhelyén nincs meg az adat. A CentOS ismét rakoncátlankodott, mert nem volt hajlandó fogadni az adatokat. A master egy ilyen semmitmondó hibaüzenetet adott:

java.io.IOException: Got error, status=ERROR, status message , ack with firstBadLink as 192.168.0.4:9866

A logok szintén nem voltak túl hasznosak, ellenben észrevettem, hogy a webes felületen keresztül sem érem el a CentOS adatnodot. Rövid netes keresgélés után azt találtam, hogy a tűzfal blokkolhatja az adatforgalmat. Ezért a 9864-es portot megnyitottam.

sudo firewall-cmd --zone=public --add-port=9864/tcp --premanent
sudo firewall-cmd --reload

Mindjárt megszűntek a hibaüzenetek, és a másolás megindult. Majdnem 8 órán át másolt, több, mint 130 GB került a HDFS-re, majd az otthoni rouer újraindult, és amit addig másolt, az enyészeté lett. A másolás egyébként azért tartott ilyen sokáig, mert csapat leggyengébb tagja egyik ősrégi gép (Athlon X2-es procival) lassú IDE-s vinyókkal, a hálózati csatolója pedig egy USB2-es wifi adapter.

Második másolásra már okosabban csináltam. Először csak a master gép HDFS-ére másoltam. Ebben SSD volt, ezért viszonylag gyorsan ment a művelet. Utána állítottam be a replikációt 3-ra. Ezzel a módszerrel 5 óra alatt megvolt mindhárom gépen az adat (persze a CentOS-en néhány blokk hiányzott, hogy azért ne legyen meg az örömöm, de ezzel már nem foglalkoztam).

Hatalmas adat, a master mégsem vont be senkit a feldolgozásba, ezért kezdtem arra gyanakodni, hogy egy konfiguráció nem megfelelő. Mivel a replikációk működtek, ezért a HDFS megfelelően kellett, hogy működjön. De mi a helyzet a Yarn-al, ami a számítási feladatok elosztását végzi?

Először egy pi számoló példaprogramot futtattam. A program lefutott, de úgy tűnt, a többi node csak malmozott. Úgy tűnik, ezen még dolgozni kell, de magával a Sparkkal már lehet játszani.

Amikor először tudatosult bennem, hogy gyerekem lesz (vagy inkább van, mert az első hónapokban olyan volt, mintha csak egy síró gép lenne), hirtelen feltárult az a milliónyi csodálatos lehetőség, amit ebből a csöppségből ki lehet hozni. A Nobel-díjas tudós, rettegett hadvezér, a világbékét elhozó zenész, stb.

Aztán ez átértékelődött bennem egy kicsit, amikor a kvantummechanikai modellek helyett olyanokról kellett órák hosszat papolni, hogy WC használat után kezet is kell mosni, (amit nem akart megjegyezni) valamint a játszótéren hallott csúnya szavakat nem mondogatjuk minden szembe jövő embernek (amit meg nem akart elfelejteni).

A hétköznapi tapasztalatok szép lassan lerombolták a kezdeti elvárásokat, és már nem voltak olyan nagyra törő terveim, mint kezdetekkor. Úgy döntöttem, megelégszem azzal is, ha nem lesz valóságshow sztár. De ahogy növekedett, titkon abban reménykedtem, hogy azért programozni meg fogom tudni tanítani.

Ezért már kétévesen megengedtem neki, hogy nyomkodja a gombokat a billentyűzeten, amikor megismerte a betűket, szavakat írattam vele a képernyőre. Minden azt a célt szolgálta, hogy ha elég nagy lesz, nekilássunk kódot írni.

Úgy éreztem, az idő eljött. Egy vállalkozás programozást oktatott délutánonként, és azt terveztem, hogy elmegyünk a nyílt napukra. A gondok itt kezdődtek. A lányom nem akart elmenni. Igyekeztem bevetni minden meggyőző képességemet, de hasztalan. Konok ellenállást tapasztaltam. Végül kész tények elé állítottam. Mivel regisztráltam a nyílt napra, el kell mennünk.

- A programozás fiús! - replikázott a lányom, amin nagyon megdöbbentem, mert soha nem akartam ezt a látszatot kelteni. De még jobban megdöbbentem, amikor még a feleségem is rákontrázott.

- Igen, az nem is lányoknak való.

- Annak idején azt mesélted nekem, hogy volt egy ZX Spectrum-od, amin te is programoztál - hívtam fel a feleségem figyelmét. A házassági évfordulók kimennek a fejemből, de ez az egyik korai randin elejtett megjegyzés valahogy megmaradt bennem.

- Tényleg! Szerettem olyan programokat írni, amik rajzoltak valamit a képernyőre.

Ennek ellenére, mikor eljött az idő, csak nagy duzzogás árán tudtam elvinni gyermekem a nyílt napra. Itt könnyelműen megígértem, hogy majd segítek neki, ha elakad. Ezt sajnos nem tudta megtartani, mert az egyik szobában a szülőknek tartottak ismertetőt, míg a másikban a gyerekek mindjárt bele is kóstolhattak a kódolásba.

Először arról beszélt az egyik vezető, hogy ők mennyire jók, egyedülállók. Ezek a sales-szerű dumák rólam már leperegnek, ezért itt elkezdtem unni magamat. Utána arról volt szó, miért is jó programozást tanulni. Ezt nem tudom, miért kellett elmondani, hiszen azért hoztuk ide a gyerekeket, mert úgy gondoljuk, hogy érdemes. A lényegi dolgokat azután negyed óra alatt elmondta.

Beszélt arról is, hogy náluk élmény alapú oktatás folyik, hogy a kis lurkóknak sok sikerélményük legyen. Ezen a ponton kezdtem úgy érezni, hogy talán nekik sikerülni fog elérni azt, amit nekem nem, nevezetesen, hogy megkedveltessem vele a programozást.

Végül az előadás után megnéztük, mire jutottak a másik szobában a kölykök. Mikor beléptem, minden gyerek örömtől ragyogó arccal mutatta szüleinek, milyen érdekes programot készítettek. Nem volt nagy szám, valami denevér scrollozott a képernyő tetején, az alján meg egy béna pixel gyerek igyekezett lelőni azt. Ragyogtak a kis arcok, csillogtak a szemek, pedig iskola után volt mindenki. Minden gyerek teljesen oda volt, hogy már az első alkalommal csináltak valami látványosat. Mindenki, kivéve az én lányom, aki lefelé görbülő szájjal mondta, hogy nem értett semmit. amit mondtak neki, nem tudja, mit kell csinálni. Hiába mondtam neki, hogy mozog az a nyavajás denevér, nem értem, mi a baj, addigra már sírt.

Nesze neked, élmény alapú oktatás.

Láttam, hogy teljesen felesleges maradni. Míg a többi gyereket alig lehetett kirobbantani a gép elől, mert megállás nélkül mesélték, mit értek el, addig mi szépen felálltunk, és ha nem is csendesen, de leléptünk. Hazafelé a lányom még azt is a szememre vetette, hogy ez volt élete legrosszabb napja. A kijelentés élét kicsit tompítja a tény, hogy pár nappal az eset előtt is volt egy élete legrosszabb napja, és a következő hétvégén úgyszintén. Hiába, az egyetlen könnyű nap tegnap volt.

Megígértem, hogy nem kell mennie a programozós suliba, de azt azért nem, hogy többet nem fogok próbálkozni. Pár év múlva újra megkísérlem a lehetetlent.

Nem sikerült eljutni Function-re. A festés után ajtókat is kellett beszerelni a lakásba, amiket pont a Function idején akartak kihozni. Nagyon gondolkodtam, mit áldozzak fel, de a racionalitás azt sugallta, hogy a hobbinak kell vesznie. Ami azért is gáz, mert nem tudom, hol tudom bemutatni a rilízeket, amelyeket Function-re készítettem. Ez viszont a jövő problémája, most nézzük a múltat.

Bár Maugli enyhén pánik hangulatú posztja után arra lehetett számítani, hogy alig lesz produkció, ez szerencsére nem következett be. Nézzük is át, mivel kápráztatták el a nagyérdeműt idén. Érdekes módon az oldschool alkotások domináltak. Talán azért is, mert nem volt "igazi" Árok, és sokan inkább egy olyan partin akarták bemutatni alkotásaikat, ahol közben a barátaikkal lehettek.

Grafikák

A freestyle grafikákat idén valahogy nem tudtam hova tenni. Se nem fotó, se nem rajz, se nem render. Mégis mindegyik. Olyanok lettek, mint a lecsó: Mindenki tudja, miről van szó, de nincs két egyforma recept. Ahol már érződött a művészi hatás, azok a kézi rajzok voltak. Bár Dorcyy képe tényleg nagyon szép lett, én mégis a második helyezettet mutatom itt be, a témája miatt, mert ez tényleg szólt valamiről.

Az oldschool grafikából annyi volt, mint a másik két kategóriából összesen. Ez a minőségen is meglátszott. Íme az első helyezett, amit Amigán készítettek:

Ide kívánkozik a fotók bemutatása is (amiből több volt, mint az összes grafikából együttvéve). Szokás szerint voltak teljesen ad-hoc fotók, mint a kávéról szóló, de akadtak jóval komolyabbak is, ahol figyeltek a kompozícióra, fényekre és színekre. Az első három ilyen szempontból kiemelkedett, én nem is szeretnék rangsort állítani közöttük:

Zenék

A második legnépesebb kategória, szokás szerint. Idén igen alaposan tanulmányoztam a zenéket, mert szeretném magam kipróbálni ebben a compóban. Végighallgatva a repertoárt a Ghost of Rakis tetszett a legjobban. Milyen érdekes, hogy az aktuális popkultúrális elemek mekkora hatással bírnak az alkotókra. Vajon akkor is ez lett volna a címe, ha nem készül el az új Düne film? Egyáltalán megszületett volna ez a dal?

Animációk

Az idei animációk közül az Introspective igazi gyöngyszem volt a maga népi motivumaival. Valljuk be, a sok fraktálon és absztrakt grafikán nevelkedett szemeknek teljesen szokatlan ez a fajta látványvilág. Még a zene is ezt erősítette.

Intrók

Az egyetlen bemutatott 64k intró a hagyományos sémára épült. A textúrák viszonylag egyszerűek voltak. A készítők nem is tolták túl, négy rövid jelenetet mutattak be. A három darab 4k is az óvatos visszafogottság jegyében készült. Láthatólag senki nem arra készült, hogy megváltsa a világot, inkább az öncélú intró készítés volt a cél, a készítés öröméért. Tulajdonképpen ezzel semmi baj nincs. Igaz, hogy mindenki szeret látványos produkciókat nézni, de épp ezzel a scenerek nagy többségét el lehet ijeszteni attól, hogy bármit is alkossanak.

A 256b intrók között is voltak hasonló, "a móka kedéért" típusú alkotások. Például a Majomka. Semmi mást nem mutat, mint egy pislogó szőrös állatot. A Go worm! volt a másik "erre nem számítottam" típusú intró. Bevallom, én személy szerint azt hittem, a végén lesz valami csattanó, valami olyan csattanó, amitől kilapul a kukac. De a kommentek alapján a közönség is egy emberként szurkolt a kis lénynek, mert talán ők is kíváncsiak voltak, milyen sorsot szánt készítője a kukacnak. Aki viszont komolyan vette a compót, az meg is nyerte. A MEMS nagyon komplex és ötletes mintázatot mutat, kevésbé számítógép beállítottságúaknak akár egy perzsa szőnyeg is eszébe juthatott volna.

Demók

Az oldschool demók versenyében az Atlantis és a Lethargy csatája volt a meghatározó. A győztes az előbbi, nekem viszont az utóbbiról vannak bennfentes információim, ezért azt osztanám meg. Maga a demó koncepciója nagyon korán megszületett, állítólag a fő programozó már 2016-ban elkezdte a kódot és a jelenetek felével el is készült. Befejezni viszont csak akkor tudta, amikor csatlakozott a Lethargy-hoz (érdekes módon, mikor kódolni kezdte a demót, pont az Atlantis tagja volt). A demó legnagyobb érdekessége, hogy a jelenetek nagyon gyorsan váltják egymást. Korábban a C64 demókra ez nem volt jellemző. (Bár az első igazi dinamikus C64 demó az Edge of Disgrace volt.) Trükközni viszont sokat kellett, hogy a megfelelő időben a memória valamelyik részében már ott csücsüljön a megjelenítendő való adat.

A PC demók között Gargaj most GUS demót készített, mintegy önmagának bizonyítva, hogy képes erre is. Ismét kaptunk egy Raindow Clash alkotást kibogozhatatlan 3D alakzatokkal és textúrákkal. De ami igazán megfogott, az az 1986 volt. Maga a demó nem túl látványos, lassan indul, és az utolsó pillanatig nem lehet tudni, miről is akar szólni. Még a demó címe is elég ködös. De amint a cselekmény eléri a végkifejletet, a néző számára minden összeáll. És ezért nagyon jó.

Ez volt idén a Function. Kár, hogy ki kellett hagynom.

A mostani nagy egyetemi egyesüléseknek köszönhetően abba a furcsa helyzetbe került csoportunk, hogy oktatni kényszerül. Ezen alkalomból, az egyik PhD hallgatónk majd megveszett, hogy Python programozás órát tarthasson. Mivel nem tartok egy óra sem, viszont megvannak az óra indításához a jogosítványaim, ezért az én nevem alá került a tantárgy.

Ez az egyetemi oktatás olyan, mintha egy másik univerzum lenne, sajátos, érthetetlen szabályokkal. Például ott van a Neptun. Rá kellett ébrednem, hogy nekem szükségem lesz egy azonosítóra, különben nem leszek képes ellátni az órai adminisztrációt. Én meg balga módon kihagytam az oktatóknak szánt Zoom megbeszélést, ahol ezekről a dolgokról beszéltek. Sebaj, majd kinyomozom.

Az egyetem honlapján nincs arról információ, hogy ki intézi ezeket. Az egyik kollégám csak annyit tudott mondani, hogy "valami Mártont" kell keresni. A keresőt használva kiderült, hogy a Márton és Neptun kulcsszavak az egyetem egyik karának dolgozójára mutatnak. Gondoltam felkeresem személyesen. Ezt nagyon jól tettem, mert nem elég, hogy az illető elérhetőségeit eldugták az egyetem egyik apró karának még apróbb weblapjára, ráadásul a feltüntetett szobaszámon nem is azok a munkatársak szerepelnek, és akik ott vannak, azok nem is azzal foglalkoznak.

Elkezdtem lófrálni az egyetem folyosóin, közben olvasgattam a kiírásokat. Egyszer csak megakadt a szemem egy ajtón, amin szerepeltek a Neptun és az oktatók szavak, tucatnyi más, érthetetlen szóval együtt. Sikerült megtalálni az illetékeseket, ott voltak, akik tudtak segíteni.

A másik anomália az volt, hogy több ember is dolgozik ugyan azon a néven. Ezért, mikor én kaptam az új egyetemi email címet, egy diszkrét kis 2-t adtak a nevemhez. Bár a Neptunban jól szerepel az email címem, a hallgatók egy kivételével nem nekem küldték el panaszaikat, hanem a sorszám nélküli illetőnek, aki gondolom nem értette, miféle órát akarnak számon kérni rajta. A hallgatók viszont a személyes találkozó alkalmával nekem tettek szemrehányást, amiért nem válaszoltam a leveleikre.

Még a termek számozása sem mentes a problémáktól. Mikor az első órához felvettük a kulcsokat, rosszakat kaptunk ("Nem mondták, melyik 123-as terem kulcsát kérik!" - torkollt le minket a portás, mintha teljesen egyértelmű lenne, hogy több terem is szerepel ugyan azon a számon) Mikor megkaptuk a jó kulcsokat, azzal sem tudtuk kinyitni az ajtót. Én ekkor már túl voltam a Neptun adminisztrátor vadászaton, ezért azonnal vizslatni kezdtem a környező ajtókat. Kiderült, a teremnek másik ajtaja is van, szintén 123-as.

Elkezdtek özönleni a diákok. Először befelé, aztán kifelé, mikor kiderült, hogy nem vagyok hajlandó áttenni az órát másik időpontra, vagy olyan elavult elvárásaim vannak, hogy bejárjanak. Érdekes, hogy akik a leginkább kapálóztak, hogy fel tudják venni a kurzust, azok el sem jöttek az első órára. A végleges létszám végül öt lett.

Ebből az egyik hallgató folyamatos harcban állt a számítógéppel. Fél órán keresztül nem tudott bejelentkezni. Ez idő alatt kétszer kereste fel a rendszergazdákat. Végül mikor működött neki minden, megkértük, hogy a vetítőn lévő feladatokat kezdje le csinálni, mire közölte velünk, hogy ő nem lát el addig. Csak tudnám, hogy akkor miért a legutolsó géphez ült?

Sok oktató szokta mondani, hogy mennyit tanul a diákoktól, miközben átadja tudását. Őszintén szólva, ezt csak amolyan klisének tartottam, amivel a szerénység látszatát keltik egyesek. Nos, az első órán, mi oktatók, tényleg tanultunk valamit. Az egyik órai feladat ellenőrzése közben megálltam az egyik hallgatónál, és néztem a megoldását. Bár láttam, mit írt le, nem értettem, miért is működik. A PhD hallgató sem értette. Életemben nem láttam még ilyen szintaxist. Kiderült, az f-sztringet látom. Ki is hívtuk a táblához, hogy elmondja mindannyiunknak.

Nagyon furcsa volt látni, hogy mennyire túlélés-központúak voltak a diákok. Legalábbis én így értelmezem ezt a sok-kreditet-felhalmozunk-minimális-munkával mentalitást. Végül azért örülök, hogy aki maradt, az tényleg azért maradt, mert érdekelte a tárgy.

A genom összeszerelések egyik legfontosabb hozzávalója a minél hosszabb szekvenciák felhasználása. Ebben a cikkben összeszedték a különböző összeszerelési stratégiákat, és az első ábrán is jól látszik, hogy a hosszú readek felhasználásával az N50 nem fog számottevően változni a rövid read-es össszeszereléshez képest, de a hibás összeszerelések száma jóval alacsonyabb lesz.

Hosszú szekvenciákat Nanopore-ből vagy PacBio-ból szerezhetünk. Habár a Nanopore jó megoldás baktériumok, vírusok esetén, nagyobb genomokat csak korlátozottan lehet összerakni vele. Tehát az egyedüli megoldásnak a PacBio tekinthető.

Nézzük, hogyan is néz ki egy genom összeszerelés ezzel a technológiával. Előrebocsátom, hogy az itt bemutatott programok aktív fejlesztés alatt állnak, ezért nem biztos, hogy az itt leírtak egy év múlva is érvényesek lesznek. A dokumentáció pedig szokás szerint előbb avul el, mint a kód.

A PacBio denovo programját Falconnak hívják és a teljes kód fent van a GitHubon, csak ember legyen a talpán, aki kiigazodik a sok félbehagyott repo, átnevezett programok és verziók között. Elég csak megnézni ezt a listát. Az minden esetre látszik, hogy a program három nagyobb részegységből áll: nyers denovo (ez lenne a FALCON, vagy falcon3. A kettes verzió valahol eltűnt egy fekete lyukban.), haplotípus meghatározás (FALCON-Unzip, falcon_unzip3), végső simítások (FALCON-polish).

Az egészet összefogja a pb-assembly, ami egy conda csomag, hogy legalább a telepítéssel ne legyen gond. Igazából máshogy nem is lehet telepíteni. Megpróbálkoztam a fordítással is, csak, hogy lássam, képes vagyok rá, de nem voltam. Nem érdemes időt vesztegetni rá.

A programok vezérlését egyetlen konfigurációs fájllal lehet elvégezni. Felépítésük a régi Windows-os INI állományokra hajaz. Szögletes zárójelbe megnevezünk egy szekciót, majd kulcs-érték párokat definiálunk. A program saját munkafolyamat kezelővel rendelkezik, ami azt jelenti, hogy hiba esetén nem kell előről kezdeni a futtatást.

Képes több feladat ütemezőt is maga alá gyűrni, de ezt nem teszteltem. Ha csak egy gépen futtatjuk, akkor a job_type értéket local-ra kell állítani, és hiába mondja a dokumentáció, hogy ennyi elég, a submit opciót is be kell állítani. Ez valahol érthető is, hiszen nem mindenki használ Bash-t parancsértelmezőnek.

A genom mérete sajnos kötelező paraméter, ezért ha nincs ötletünk, mekkora lehet a végleges genom mérete, akkor valószínűleg több futtatást is kell végeznünk, ami tekintve a futások hosszát, tetemes időt fog igénybe venni.

Az első lépés tehát a nyers összeszerelés:

fc_run config.file

Ez a lépés három fő fázisból áll. Az elsőben a szekvenciákat egymáshoz illeszti, hogy kiküszöbölje az esetleges szekvenálási hibáka. A háttérben egy adatbázist épít a szekvenciákból. A másodikban ismét egymáshoz illeszti a szekvenciákat, de akkor már  megpróbál minél hosszabb szekvenciákat képezni. Ez a két lépés nagyon sokáig tart, érdemes minél több párhozamos folyamatot indítani (njobs paraméter a konfigurációs állományban), mert szálakból csak négyet használ, teljesen mindegy, mennyit definiálunk. Az utolsó lépés a tényleges assembly, ez viszont csak egy program futásából áll, nem számít, mennyi párhuzamos folyamatot állítunk be.

Minden fázisnak egy könyvtár felel meg, ezek a 0-rawreads, 1-preads_ovl, 2-asm-falcon. Az ütemező az első két könyvtárban létrehoz egy build könyvtárat, ami az adott munkafázis mindegyik lépésének további könyvtárakat hoz létre. Sőt, ha a munkafázis párhuzamos folyamatokra osztható, akkor további alkönyvtárak készülnek. Ezekben a könyvtárak mindegyikében van egy run.sh szkript, ami beállítja a környezeti változókat, és elindít egy task.sh szkriptet. Az igazi feladat itt van definiálva. Ezért lehet nyomon követni a program futásának állapotát könyvtárak számolásával. Amennyiben a feladat sikeresen lefutott, létrejön egy run.sh.done fájl.

Az egyetlen problémám a második fázisnál volt, mert a fő szkript hibásan adta át az egyik paramétert. Egészen pontosan az történt, hogy a daligner nevű programnak nem lehet 0 hosszúságú szekvencia vágást engedélyezni. Hiába volt 1 beállítva a fő konfigurációs fájlban, ez nem jutott el valami miatt a hívási sor végén álló bináris programnak. Végül ezt úgy oldottam meg, hogy a build könyvtárban kézzel átírtam az állományt (a beszédes nevű length_cutoff fájlt) a megfelelő értékre.

Ennek a szkriptek-futnak-különböző-könyvtárakban megközelítésnek volt egy hátránya is. Nevezetesen, ha szimbolikus linkeket tartalmaz a könyvtár. Ekkor ugyanis az alkönyvtárban lévő szkript, ha el akar érni valamit egy felsőbb könyvtárban, akkor nem fogja megtalálni, hiszen nem látja, hogy egy szimlinkelt könyvtárban van. Viszont mi nem fogjuk érteni a hibaüzenetet, mert mi meg a szimlinken keresztül ellenőrizzük az elérést, és azt látjuk, hogy minden rendben van.

Az első, nyers összeszerelés a 2-asm-falcon könyvtárban lesz p_ctg.fasta néven. Ha szeretnénk némi statisztikát, mennyire lett jó a munkánk, akkor egy másik PacBio repo, a pb-assembly kell nekünk, abból is a get_asm_stats.py szkript.

python ~/pb-assembly/scripts/get_asm_stats.py 2-asm-falcon/p_ctg.fasta

Ez még csak egy nyers szekvencia lesz. Nyers, mert egy diploid genomnál az apai és anyai kromoszóma készlet között könnyen előfordulhat annyi eltérés, ami megzavarjon egy programot. Ezért a következő lépés ezen eltérések azonosítása, amit a FALCON-unzip végez.

Futtatása ugyancsak egy konfigurációs fájl megadásával történik. A lehetséges paraméterek száma viszont kevesebb, nagy részüket az előző programban már megadtuk. Egyetlen új elem a BAM fájlok elérési útjának beállítása. A dokumentáció elég szűk szavú ezeknek a BAM fájloknak az eredetéről, de ez nem más, mint a szekvenálás eredményeként megkapott subreads.bam (itt lehet még olvasgatni a subreads-ről). A FALCON-unzip futtatása tehát csak ennyi lesz:

fc-unzip.py unzip.cfg

Itt is hiába állítjuk be a szálak számát, mert a program csak egyet fog használni, ezért csak a jobok számával tudjuk szabályozni, mennyi CPU-t hasznosítunk. Az eredmények a 4-polish/cns-output/ könyvtárban lesznek. A cns_p_ctg.fasta fájl fogja tartalmazni a javított szekvenciákat, míg a haplotípusok a cns_h_ctg.fasta fájlban lesznek. Ha megnézzük a statisztikát, azt fogjuk látni, hogy azok lényegesen nem lesznek jobbak, ellenben a szekvenciák megbízhatóbbak lesznek.

Amennyiben van Hi-C adatsorunk is, egy következő lépést is lefuttathatunk, amelynek során tovább javíthatjuk eredményeinket. Ez a falcon-phase, és ugyan csak egy konfigurációs fájllal szabályozhatjuk. Itt kell meadni a Hi-C szekvenciák elérési útját. Én személy szerint nem használtam, és a dokumentáció is elég szegényes, ezért arról nem írnék.

Eheti meglepetésem az volt, hogy nem értek a Blasthoz. Egy homológ szekvenciát kellett volna megtalálni egy faj különböző módon összeépített genomjai között. Alapértelmezett módon futtattam mindent, majd megállapítottam, hogy az EnsEMBL-féle genomban nincs meg a kérdéses szekvencia.

Az egyik kollégám viszont azt mondta, hogy megvan, én meg nem értettem, hogyhogy nem találtam meg, ezért elkezdtem nyomozni.

A vizsgált szekvenciák ugyan azok voltak, de míg ő az EnsEMBL oldalán futtatta a Blastot, addig én lokálisan. A paraméterek emiatt nehezen feleltethetőek meg egymással, de a letöltött eredmények alapján a verziószámban biztosan volt különbség. Lehet, hogy ez okozta a különbséget? Ezért letöltöttem a weboldal verzióját. A genomokat újra kellett indexelni, de ugyan úgy futtattam mindent, mint korábban.

Továbbra is volt különbség az eredményekben, a verziószám egyezésének ellenére. Akkor a paraméterezés fog eltérni! Ezt viszont az eredmény fájlból nem lehetett kitalálni. Elkezdtem olvasni a dokumentációt, hátha találok valami támpontot. De már ezerszer olvastam ezelőtt. Miért nem találom a megoldást?

Aztán eszembe jutott, hogy a Blast alapértelmezetten a megablast módban fut, hátha ez a különbség! Ezért a -task blastn-short opciót használtam, és csodálatos módon megjelent a rejtőzködő eredmény. Szép dolog az alapértelmezett futtatás, csak aztán érteni is kell, hogy mit kaptunk.

Amolyan kibicként szoktam olvasgatni a számítógépes biztonsági szakértők eszmefuttatásait. Ott többször előkerült, hogy érdemes-e bevételként IPhone bugokra vadászni, mert milyen nagy pénzjutalom jár értük. A profik ott le szokták hűteni a kedélyeket, hogy nem olyan könnyű bugokat találni, ráadásul több ember is kell hozzá, akik a telefon egy-egy komponensét behatóbban ismerik. A hibák megtalálása időigényes folyamat, és ha találnak is valamit, a pénzjutalom nem fedezi az emberek bérét, cég működését, stb.

Aztán volt az a hír, amikor egy bűnöző telefonját fel akarták törni az FBI munkatársai, de még az Apple is azt állította, hogy képtelenség. Persze végül feltörték a bűnüldözők, de ott a készülék fizikailag a birtokukban volt.

Ezekből nekem az jött le, hogy bár vannak sebezhetőségek a telefonokban, azért összességében nagyon biztonságosak. A legnagyobb rizikót a felhasználó jelenti a béna jelszavaival és a linkekre történő ész nélküli kattintgatással.

Aztán jött a Pegasus, és megmutatta, hogy gyakorlatilag semmi nem kell ahhoz, hogy a telefonokba behatoljanak. Hiszen minek tegyék nyilvánossá az általuk ismert sebezhetőséget pár millióért, ha egy erre épülő céget is alapíthatnak? Szóval engem meglepett, hogy ilyen szintű kémprogram létezik.

Ezek szerint az ellen nem tehetünk semmit, hogy a telefonunkra feljusson. Azt megtudhatjuk, hogy Androidos mobiltelefonunk kompromittálódott-e? Mit tegyünk? Először is, kérjünk profi segítséget. Aki pedig olyan, mint én, hogy szeret Q-t játszani a pizsamában, az megpróbálkozhat a következőkkel is:

Mivel a telefonnak el kell küldenie az összegyűjtött adatokat az operátornak, ezért megpróbálkozhatunk elfogni ezt a kapcsolatfelvételt. Ha például a Pegasust nézzük, akkor az elsődlegesen wifi-n keresztül küldi el az adatokat. (SMS-t is tud használni, de mivel az pénzbe kerül a célpontnak, ezért nem ez a preferált mód) Már csak az a kérdés, hogyan tudjuk megnézni telefonunk hova küldözget adatokat?

Először is szükség lesz egy számítógépre, amit wifi hotspottá alakítunk. Ha kábeles internetre kötjük a gépet, akkor a wifi beállításoknál megoszthatjuk a netet. Telefonunk pedig erre kapcsolódjon. Vagyis a telefon teljes internetes forgalma a számítógépen keresztül fog menni.

Most pedig nézzük át ezt a forgalmat! Telepítsük a WireSharkot, ami képes elfogni a számítógép hálózati csatolóján keresztül áthaladó adatforgalmat. Egy mezei usernél magasabb jogosultások kellenek ehhez, ezt érdemes észben tartani.

A program elindítása után kiválaszthatjuk, melyik hálózati csatolót figyelje a program. Válasszuk ki a wifi-t. Láthatjuk, a képernyő hirtelen tele lesz üzenetekkel. Amennyiben úgy gondoljuk, elég adatunk, állítsuk le a csomagok elfogását, és mentsük le azokat a File -> Export Packet Dissections -> As CSV. Ez már egy egyszerű táblázatos adat lesz, amivel már megkezdhetjük az igazi munkát.

Gyakorlatilag át kell nyálazni ezt az adatot, kiszűrni azt, ami legitim és megtalálni valamit, ami igyekszik elrejtőzni. Ráadásul fennáll a veszélye, hogy a program nem is működött abban az időben, amikor mi a WireSharkkal figyeltük a kommunikációt.

Viszont ez a rejtőzködési hajlamot az előnyünkre is formálhatjuk. Például ha egy napra elzárjuk a hálózattól a telefont, akkor amint netet kap, nagyobb valószínűséggel akar haza szólni. Ráadásul egy kémprogram ritkán kommunikál, tehát azokat a kapcsolatokat kell keresni, amik kevésszer fordulnak elő. A Pegasus dokumentációjából azt is tudjuk, hogy az adatokat anonimizált hálózaton keresztül küldi, ami a gyakorlatban azt jelenti, hogy valamilyen cloud szolgáltatón bérelt számítógépekre mennek. (A botrány kirobbanásakor épp Amazonról jöttek kérések a telefonok felé.)

Lássunk egy konkrét példát. Az én esetemben a telefon a 10.42.0.147 IP-t kapta. A lementett CSV fájl a testdissection.csv néven létezik. Azokra a kapcsolatokra vagyok kíváncsi, amelyek a telefonról indultak, és ritkák:

awk -F"," '{if($3 == "\"10.42.0.147\"")print $4}' testdissection.csv | sort | uniq -c | sort -nrk 1

Az érdekes IP címek a sor végén lesznek. Ezeket leellenőrizhetjük olyan weboldalakon is, mint amilyen a db-ip.com is. Ami nálam érdekes lehet, az három Amazonos (91.228.74.133, 52.84.109.x), és az Akamai-os (184.51.9.98). Ezek cloud szolgáltatók, akik sok legitim vállalkozásnak nyújtanak támogatást, ezért remek rejtekhelyek a kémprogramok szerver oldali komponenseinek is. A bérelt virtuális gépek pedig minden újraindulás esetén másik IP-t kapnak.

Ez abból is látszik, hogy ha csak rákeresek az 52.84.109 tartományra a fájlomban, akkor máris megvan a supersonicads.com, tehát ez egy reklámokkal foglalkozó cég. Ez nem is meglepő, mert a teszt idején a Dühös Madarakkal játszottam, hogy generáljak egy kis adatforgalmat.

Természetesen ez a módszer csak aktív megfigyelésnél működik. Ha a program bármilyen okból eltávolította magát, akkor nem fogunk találni semmit. Igazából akkor sem biztos, hogy találunk valamit, ha tényleg ott a program a telefonunkon. Az Akamai-os címre például nem tudok magyarázatot adni, pedig nagy valószínűséggel az is egy legitim kapcsolat.

Azért arról sem szabad megfeledkezni, hogy ezek a programok bármennyire is szofisztikáltak, azért emberek írják, követhetnek el hibákat, és ezeknek a hibáknak nyoma maradhat. Ezeket is megpróbálhatjuk megtalálni. Android esetén az SDK tartalmaz egy adb nevű programot, amivel átnézhetjük a telefon mélyebb rétegeit is.

Először is, engedélyezni kell a fejlesztői beállításokat, majd a fejlesztői beállításoknál engedélyezni kell az USB hibakeresést. Ezután a indíthatjuk az adb-t.

sudo adb start-server
adb -d shell

Kezdődhet is a móka, ugyanis egy linux terminált kapunk, csak épp a telefonon. Megnézhetjük a futó alkalmazásokat top-al, ps-el. A rendszer logokat innen nehéz elérni (meg készülékenként változik a helyük), de az adb-vel a telefon indulása óta gyűjtött logokat megnézhetjük:

adb logcat -d >mylogfiles.txt

A probléma ezekkel a keresgélésekkel, hogy nem igazán tudjuk, mit is kell keresni. Mik lehetnek a gyanús folyamatok? Mik lehetnek azok a weboldalak, amelyek tényleg a Pegasushoz köthetőek? Szerencsére az Amnesty International összegyűjtötte ezeket nekünk.

Tehát ha végig akarjuk nézni, hogy van-e gyanús folyamatunk, akkor azt a következő módon tehetjük meg:

./adb shell 'ps -A | grep -v google | grep -v android' >~/testprocess.txt
for i in `cat processes.txt`; do grep $i testprocess.txt ; done

Nos, az én telefonomon így találtam meg a gatekeeperd folyamatot. Először engem is kivert a víz, de aztán rákerestem erre a folyamatra, és úgy tűnik, hogy ez az Android rendszer része. Más lenne a helyzet persze, ha IPhone-on találnánk meg. Lehet még próbálkozni az mvt nevű programmal is, de nekem ezt nem sikerült működésre bírni.

Nem vagyok egy nosztalgikus alkat. Ami elmúlt, az okkal múlt el. De azért hiányozni szokott a 80-as évek egyszerűsége. Például, amikor édesanyám kitalálta, hogy ki kellene festeni a lakást, akkor édesapám vett egy ecsetet, festéket és kifestett mindent. Gyerekként én meg élveztem, hogy a lakás egy furcsa labirintussá változott az egymásra hányt bútorok következtében.

Amikor az én feleségem néhány éve kitalálta, hogy festeni kellene, akkor három napig festéket vadásztunk. Nem azért, mert nem volt kínálat, hanem épp ellenkezőleg. Millió szín, aminek passzolnia kell a bútorhoz, a padlóhoz, és az aktuális pszichés állapotunkhoz.

A gyereket el kellett távolítani a lakásból, mert "belélegzi a festékgőz". Emiatt a festés időpontja már nem csak a mi naptárunkhoz, de még a nagyszülők időbeosztásához is igazodnia kellett.

A végső csapás mégis az volt, amikor nem akarták megengedni, hogy én fessek. Az első ötlet az volt, hogy családi ismerősök fessenek, akik az ország másik felében laktak. Mondtam, hogy nem akarok nekik fizetni, bármilyen jutányosan is dolgoznak, és nem akarom, hogy átutazzák a fél országot. Végül apósom jött el, akinek elég nagy tapasztalata van lakásfelújításban, de nem engedte, hogy hozzáérjek a festőhengerhez, helyette vizezhettem a padlót, hogy ne száradjon oda a festék és felmoshattam a lehulló cseppeket.

Most viszont úgy alakult, hogy megint egy lakást kellett festeni. De érdekes módon most senki nem akart beleszólni, hogy miként csináljam. Segítséget nem kértem senkitől, de apám és a húgom mégis felajánlotta, amit elfogadtam. Eljött az én időm!

Először felmértem a helyiségeket. Megmértem minden falat. A kislányom nagyon segíteni akart, mivel nemrég tanult meg írni, ezért ő volt az írnok. Diktáltam neki a méreteket, és reménykedtem benne, hogy tényleg le is írja az összeset, nem fogja megunni és virágokat rajzolni helyette. Nem akartam folyton ellenőrizni, hogy legyen egy kis önbizalma.

A fal szerencsére jó minőségű volt, nem kellett sok helyen glettelni. Ami gond volt, az egyik szobában polisztirol lapok voltak a mennyezeten, amelyek valami furcsa okból, a mennyezet bizonyos pontjairól folyton leestek. Szerintem a ragasztóval lehetett valami gond, mert a ragasztócsík a mennyezeten fennmaradt, csak a lap esett le. Eredetileg szilikon ragasztót használhattak, ezért én egy 1 perc alatt megkötő púrhab-szerű spray-t választottam. Ez ragadt. Egy lapot véletlenül rosszul ragasztottunk fel, csak spaklival tudtuk levakarni, pedig még le sem telt az egy perc!

Amit megtanultam ezeknek a lapoknak a felragasztásával, hogy ha nem illeszkedik precízen két lap már az elején, akkor később csak további illeszkedési hibák lesznek. Próbálkoztam, hogy pengével kijavítsam ezeket a hibákat, de nem lesz jó úgy sem. Rendesen kell felrakni. Szerencsére nem feltűnő.

A festés hasonlít a főzéshez olyan szempontból, hogy a jó alapanyag félsiker. Érdemes azokat a festékeket választani, aminek a nevében arany, platina, meg más drága fém szerepel. Kevesebbszer kell lefesteni a falat velük, és szebben is néz ki.

Ez akkor vált számomra nagyon szembetűnőnek, amikor egy sötétbordó szobát kellett fehérré változtatni. Bárki, aki ránézett, minimum három réteg festék felhasználását becsülte. Sikerült olyan festéket venni, hogy már az első kenés után alig látszott a falak eredeti színe. A második réteg pedig teljesen eltakarta az eredeti színt.

Apám is nagyon lelkes volt. A különböző szerelésekhez hozott egy racsnis csavarúzót, amit nemrég vett és szerette volna megmutatni, milyen remek szerszám. A forgásirányt egy kis tekerővel lehetett állítani, viszont nem volt végállása, amitől két-háromszor is körbe lehetett tekerni. Ennek az lett az eredménye, hogy soha nem abba az irányba működött, amelyikbe szerette volna. Tíz perc hadakozás után a majdnem a szemétben végezte a szerszám. Az mentette meg, hogy elkertem.

Amivel viszont én fürödtem be, az a ragasztó szalag volt, amivel a szegélyeket akartam megóvni a festéktől. Jó széleset választottam, mert korábban láttam, milyen az, ha a festőhenger jobban megszalad.

Elkezdtem felragasztani a szegélyekre. Már fél úton jártam, amikor visszanéztem az addigi munkámra. Az összes vége elkezdett felpenderedni, majd egy ponton lepottyant. Biztos, hogy nem a felülettel volt a baj, mert maradt még a régebbi festésről egy másik fajta ragasztó szalag, és az még másnap is a helyén volt. Ez viszont leesett mindenről, mintha csak nyállal tapasztottam volna fel. Az egyik pont egy takaró fóliára esett, amihez viszont úgy hozzáragadt, hogy elszakadt, mikor le akartam szedni.

Nagyon jól haladtunk. Apám nem tudott megbarátkozni a festőhengerrel, ezért fogott egy ecsetet és a nehezen elérhető helyeket, sarkokat kente végig. Neki ez feküdt, pont, mint régen. Mi hengerrel estünk neki a felületeknek. Húgomnak ez volt az első festés élménye, ezért megálltam, és nem tettem megjegyzést, hogy legalább annyi festék van a földön, mint a falakon. Déletőtt lekentünk egy helyiséget (utolsó nap annyira belejöttünk, hogy kettőt), elmentünk ebédelni, majd délután másodszor is átmentünk rajta. Estig pedig takarítottunk, majd előkészítettük a következő helyiséget. Három nap alatt végeztünk is. Mit is mondhatnék?

Az emberi agy két dimezióval egész jól elboldogul. Három sem okoz túl nagy gondot. Adat elemzés közben viszont nem ritka, hogy sokkal magasabb dimenziószámmal kell dolgoznunk. Mivel az agyunkat nem tudjuk felfejleszteni a feladathoz, az adatokat butítjuk le olyan szintre, hogy mi is megértsük. Ennek több módja is van, ezek közül nézünk meg néhányat.

PCA

A régi jó főkomponens analízis segítségével könnyedén tudjuk redukálni a dimenziókat. Az adatok közötti távolságot is arányosan forgatja el, ezért a kapott eredmények további elemzések alapját is képezhetik. Például klaszterezhetjük azokat k-közép klaszterezéssel. A PCA determinisztikus, tehát mindig ugyan azt az eredményt fogjuk kapni. Paraméterezése nincs, ezért elrontani sem lehet semmit. Hátránya, hogy a többdimenziós teret úgy forgatja el, hogy az első főkomponens mindig a legnagyobb varianciával rendelkezzen. Ez az esetek legnagyobb részénél nem probléma, de néha az érdeklődésünkre számot tartó főkomponens nem az első lesz, ezért célszerű lehet a többi főkomponens ellenőrzése is.

t-SNE

Viszonylag új módszer a t-SNE. Az egy sejtes szekvenálások előretörésével lett egyre népszerűbb a bioinformatikában. A PCA-val ellentétben nem lineáris módszer, ami azt jelenti, hogy a pontok egymáshoz viszonyított távolsága torzul, emiatt nem célszerű az eredményt további elemzésnek alávetni, inkább csak vizualizációra használni. A pontok hasonlósága ugyanis nem egy fizikai távolságot jelent, hanem egy valószínűséget, hogy a két pont jellemzői mennyire hasonlóak. A t-SNE sztohasztikus, és erősen függ a paraméterezéstől, ezért több futtatás is adhat eltérő eredményeket. Cserébe viszont az összetartozó pontok látványosabb klasztereket alkotnak.

UMAP

Az UMAP annyiban hasonlatos a t-SNE-hoz, hogy nem determinisztikus algoritmus, és nem lineáris. A megközelítés viszont más. Az adatokat egy Riemann-sokaságként kezeli, amiről annyit mondanék csak (anélkül, hogy túl sok hülyeséget hordanék össze), hogy olyan, mint egy összegyűrt papír. Egy összegyűrt papíron nehéz megmondani egy pont helyzetét, de ha kisimítjuk, akkor például a jobb sarkától egy egyszerű koordináta rendszerrel leírhatjuk azt. Nos, az UMAP megpróbálja kitalálni, milyen összegyűrt papír illik legjobban az adatainkra. Amint ez megvan, szépen kisimítja azt. Hasonló dolog történik akkor is, amikor a Földet térképpé képezzük. Az algoritmus matematikai alapja megköveteli, hogy a pontok egyenletesen töltsék ki a teret. Mivel ez nem biztos, hogy minden adatra érvényes, ezért a pontokból egy gráfot építenek, ahol a szomszédokat éllel köti össze.

Lássuk mindezt a gyakorlatban. Először is töltsük le a GDC oldaláról az agyi tumorok normalizált expresszióját. Ez három tumor típust foglal magába (egy gliómát, egy glioblasztómát, és egy B-sejtes liómát. Ez utóbbiból csak kettő van). Az expressziós adatokat egy mátrixba kell gyúrni, amit a paste Bash parancs megtesz nekünk. Szükségünk lesz még egy metaadat táblázatra is, ahol a fájlnevek és a tumor típus található. Ezt a két táblázatot kell betöltenünk R-be.

library(umap)
library(Rtsne)

cancer <- read.table("matrix.tsv", header = T, check.names = F)
pcares <- prcomp(t(cancer))
umapres <- umap(t(cancer))
tsneres <- Rtsne(t(cancer))

metadata <- read.table("metadata.tsv", check.names = F, header = T, sep = "\t")
metadata$PC1 <- pcares$x[metadata$Sample,1]
metadata$PC2 <- pcares$x[metadata$Sample,2]
metadata$UMAP1 <- as.numeric(umapres$layout[metadata$Sample,1])
metadata$UMAP2 <- as.numeric(umapres$layout[metadata$Sample,2])
tsneres2 <- data.frame(Sample = colnames(cancer), X = tsneres$Y[,1], Y = tsneres$Y[,2])
rownames(tsneres2) <- tsneres2$Sample
metadata$TSNE1 <- tsneres2[metadata$Sample,2]
metadata$TSNE2 <- tsneres2[metadata$Sample,3]

A főkomponens analízis alapból a rendelkezésünkre áll a prcomp függvényen keresztül. Az umap és a t-SNE használatához külső csomagokra van szükség, ezeket töltjük be a library segítségével. Mindhárom függvény meghívása alapértelmezett paraméterekkel, megegyezik.

Ezután készítek egy eredmény táblázatot, ahol az egyes oszlopok a különböző módszerekkel előállított pontok koordinátái. A PC1 például a főkomponens analízissel elkészített eredmény x koordinátája. A táblázat sorai pedig az egyes tumor minták.

A koordináták sorrendje nem minden esetben egyezik meg a beadott minták sorrendjével, de szerencsére a táblázat sorainak nevei segítenek eligazodni. Ez alól a t-SNE eredménye a kivétel, ahol gyakorlatilag semmilyen információ nincs, hogy miként kell értelmezni az eredményeket. Feltételeztem, hogy a sorrend nem változik a bemeneti adatokhoz képest, de erre nincs semmi bizonyítékom. Ezért voltam kénytelen bevezetni a tsneres2 változót.

Lássuk az eredményeket:

Főkomponens analízisnél a távolságok arányosak, ezért a kiugró értékek itt is elütnet a többi adattól. A glióma és blioblasztóma minták teljesen összekeverednek, ebből a nézetből nem látni semmilyen elkülönülést.

Csupán alapértelmezett beállításokkal dolgoztunk, de a t-SNE máris látványosabb eredményt adott. A tumor minták elkülönülése sokkal egyértelműbb. Látható, hogy glioblasztóma minták keverednek a kék pontok közé. Tudományos igényű elemzésnél célszerű lehet ezen adatok tüzetesebb vizsgálata, hogy megtudjuk, miért helyezkednek el messzebb a többi mintától. Az sem kizárt, hogy az adatokhoz jobban passzoló paraméterezéssel pontosabb eredményt kapunk.

Az UMAP is hasonló eredményt ad, de a kép sokkal elnyújtottabb, az eltérő matematikai megközelítés hatására.

Időről-időre beszerzek olyan hardvereket is, amelyekről úgy gondolom, hogy remek wild compó alapanyag lesz egy demópartira. Egyik ilyen szerzemény a LilyGO T-Watch is, amit szintén használtan szerváltam. Ez a hardver azért érdekes, mert egy csináld-magad mentalitású okosóra. Csináld magad alatt az óra programozását értem, mert maga a szerkezet összeszerelt állapotba került hozzám.

Az óra annyira csináld-magad, hogy alapban még az időt sem lehet rajta beállítani, tehát megvásárlás után gyakorlatilag használhatatlan. Szerintem akitől vettem, ő is ezért ábrándult ki belőle, illetve azért, mert a dokumentáció elég hiányos, de erről majd később.

Az óra alapja egy esp32 SoC. Egy mikrokontrollernél egy fokkal bonyolultabb, mert egy valós idejű operációs rendszer is fut rajta, valamint alapból tartalmaz wifi és bluetooth modult. Az érintőképernyője 240x240-es, ami egy ilyen szerkezetbe elég. Van GPS-es verzió is, nekem nem az van. Tud még rezegni, van benne egy gyorsulás és infra szenzor.

Bár a net tele van különböző videókkal, milyen remek cuccokat lehet fejleszteni rá, engem még a példaprogramok is alaposan megizzasztottak. A fejlesztéshez a leghivatalosabb doksi ez a Github repo. Most már teljesen angol, de mikor elkezdtem szenvedni a szerkezettel, félig angol, félig kínai volt.

Az első akadály az Arduino IDE volt. Azt írták, hogy 1.8-as kell minimum, de az Ubuntu repoban 2.03-as volt, amiből azt gondoltam, hogy az jó lesz, hiszen nagyobb a verziószáma. Még olyan anomáliákon sem akadtam fenn, hogy hiányoztak olyan menüpontok, amelyek a doksi szerint szükségesek ahhoz, hogy az óra programozói könyvtárait a megfelelő helyre importáljam. Megoldottam kézzel. Viszont az esp32 platform fejlesztőkészletét képtelen voltam működésre bírni. Erre is van egy menüpont az Arduino IDE-ben, a doksi szerint, de az nekem szintén hiányzott. Ezért elhatároztam, hogy lefodítom kézzel én magam.

Ez sikerült is, de az IDE képtelen volt használni. Ráadásul egy csomó eszköz alapja az esp32, és mindegyiknek van valami specifikus funkciója, amitől annyi almenü keletkezett az IDE-ben, hogy kilógott a képernyőről, és nem lehetett görgetni sem. Végül észrevettem, hogy az IDE egy konfigurációs állományában meghatázohattam a menüben az elemek sorrendjét. Átírtam a sorrerndet, ezért a nekem szükséges menüpontok mindig legfelül voltak. Így már ki tudtam választani, hogy milyen platformra fordítson az IDE, de a fordítóprogramokat továbbra sem találta. Úgy döntöttem, kell egy két hónapos szünet.

Már nem is emlékszem, milyen apropóból, de úgy döntöttem, teszek egy próbát a hivatalos oldalról letölthető Arduino IDE-vel is. Ez volt az áttörés. Megvoltak a menüpontok, működött a menük görgetése és egy klikkre felment az összes platform specifikus fordító.

A példaprogramokat viszont továbbra sem tudtam lefordítani. Bár a dokumentáció egy árva szót sem szólt róla, a fordítási hibaüzenetekből azt vettem ki, hogy kell egy csomó Python modul is. Kicsit hezitáltam, mert féltem, hogy csak a 2-es Pythonnal mennek majd a dolgok, azt meg nem akartam felrakni. Végül nagy levegőt vettem, és úgy döntöttem, a hármas verzió is jó lesz. Majd kicsit erősebben reszeljük a dolgokat. Minden fordítási kísérlet után feltettem az épp hiányzó modult, mire végül eljutottam oda, hogy fordítani tudtam, linkelni viszont továbbra sem.

Ismét kellett egy hosszabb szünet, amíg újból rá tudtam venni magamat, hogy foglalkozzam a problémával. A wifi modul linkelésénél volt a gubanc, de én már annyira ki akartam próbálni a szerkezetet, hogy végül egy Batman Dial nevű példaprogrammal kíséreltem meg a fordítást, aminek nem kell hálózat. És sikerült!

Hosszú idő után az első demoparty, amit meglátogattam, a QBParty volt. A party olyan volt, mint egy téli álmából felkelő barna medve. Lassú, nehézkes, dezorientált. Három entryt is elkezdtem csinálni, de egyik sem lett kész, ami a szokásos party hangulatnak is betett.

Azért lementem, már csak titkári teendőim miatt is. Ahogy mondani szokás a "kemény mag jött el". Ezt azért tompítanám, mert voltak első partizók is, valamint a kemény mag szerintem több emberből áll. Azt viszont mondhatjuk, hogy családias volt a hangulat. (Főleg, hogy voltak, akik hozták a gyerekeiket, kutyájukat).

Egyébként érdekes látni, hogy miként igazodik egy party a résztvevők aktuális életkorához. Annak idején, mikor még csak tizenévesként jártak partira az emberek, a barátnők ingyen látogathatták a partit. Most a gyerekek látogathatják ingyen.

A világjárvány hozadékaként nem pólót osztogattak, hanem maszkot. A Covid veszély miatt azt is ellenőrizték, hogy a szervezők betartják-e a védettségi igazolvány elkérését. Ezt úgy csinálták, hogy odajött egy emberke, akit még egyetlen scener sem látott, vagy ismert és túláradó lelkesedéssel jegyet akart venni, mintha az lenne a legtermészetesebb dolog a világon, hogy az ember demópartyra jár. Mikor a szervezők kérték tőle az igazolványt, akkor meg elkezdett magyarázkodni, majd alkudozni, hogy őt akkor is engedjék be, ha nincs nála védettségi. Feryx szerint elég szánalmas produkció volt, hiszen ide olyan emberek járnak, akik már - még ha csak látásból is - 10 évnél is régebb óta ismerik egymást. Elküldték, és ezzel jól vizsgáztak a szervezők.

A compók is lassan indultak be. Az első a fotó volt, viszonylag enyhe felhozatallal. A másodiknak a zenéket hallgathattuk végig, de itt sem érezem, hogy a készítők beleadtak volna apait-anyait. Viszonylag lagymatag volt az összes, bár meg kell jegyezni, hogy a hangosítás szerintem nem adta vissza az eredeti hangzást minden esetben. (Megerősítve, itthon végighallgatva az indulókat sokkal élvezhetőbb volt az egész.)

A játék compó volt az első, ahol láthatóan megindult valami. A QB Speedernél éreztem azt, hogy tényleges munka van benne, még akkor is, ha az assetek (vagy csak a dizájnjuk) egy része visszaköszön más produkciókból. A Drakula pedig egy remek ötlet, még akkor is, ha nem rajongok a szöveges kalandjátékokért. Itt a puszta szöveg mellett apró animációk is voltak, amitől nekem a régi Microsoft Encarta jutott az eszembe. Minden esetre, aki szeretné kipróbálni, itt megteheti.

A grafikák csak számukban voltak kevesek, minőségben egy megszokott party színvonalat láthattunk.

Csak egyetlen C64 demó volt, a Padawan csapattól. A demóról van némi háttér információm is. Visage a pandémia idején webes C64 programozást tanított pár lelkes embernek, majd elhatározták, hogy készítenek egy demót, ahol mindenki egy részt kódol, eljönnek a partyra és bemutatják, mint egyfajta diploma munkát. Nos, ha osztályozni kellene, megérdemelnék az ötöst.

A wild egy kicsit megtörte a hangulatot. Az egyik grafikai alkotás folyamatát felvették videóra, és leadták felgyorsítva. A LAL szokás szerint csinált valamit. Haragjuk központjában most a Windows 11 állt. Kaptunk egy mini horror filmet is a Kockák éjszakája címmel, ahol egy szörnypofa legyilkolta egy demóparty résztvevőit. A gyilkolást egyedül egy kis Wow kedvéért hagyta abba.

Volt egy darab 256 byte intró, egy 64k és kettő 4k. Túl sok mindent nem lehet elmondani róluk, mindegyiket a kategória egy-egy mestere alkotta, gyakorlatilag a kisujjukból rázták ki. Demóból is kettő volt. Az egyik a Dilemma sikereinek felsorolása volt, hogy hány éve ontják magukból a nyertes prodokat, a másik a Rebels sorozatban gyártott demója. Megfigyeltem, ha a Rebelsnek gyorsan kell prodot készítenie, akkor abban biztosan van egy polip-szerű effekt.

A party hangulatra nem lehetett hiba, kint és bent egyaránt ment a szórakoztatás. Bent a Double Score Dungeon koncertje, kint meg egy laptopról ment mindenféle, amire még énekelni is lehetett. Néhányan a partyról összegyűjtöttek némi pénzt, és rögtönzött grillezéssel dobták fel a hangulatot és űzték el az éhséget.

Az eredményhirdetés után már nagyon fáradt voltam, de alvásról szó sem lehetett. Előkerült egy teljes dobfelszerelés és egy elektromos gitár, majd jött a rögtönzött koncert. (Bár, aki ennyi felszerelést hoz magával, arra nem mondhatjuk, hogy rögtönzött.)

Összességében jó volt, de még szokni kell mindenkinek, hogy ki is lehet mozdulni otthonról.

Nekem az a meglátásom, hogy még soha nem volt olyan jó programozni, mint manapság. Ha pedig hihetünk a nocode, AI előretörésének, akkor elképzelhető, hogy soha nem is lesz. Azt is modhatjuk, hogy most van a programozás aranykora.

Fórumokon találkozni olyan véleményekkel, hogy manapság nehezebb elkezdeni programozni, mint annak idején, hiszen mostanság egy Android Studio telepítése, konfigurálása, netán egy példakód fordítása hihetetlen komplex feladat. Való igaz, annak idején, mikor megjelentek az otthoni használatra szánt mikroszámítógépek, csak bekapcsoltuk, és máris ott volt egy szerkesztő felület, amibe azonnal pötyöghettük a Basic kódot. Később, a DOS-os PC-k esetén is elég volt egy Turbo Pascal (a méltán népszerű Quick Basicről nem is beszélve), amit csak kicsomagoltunk és máris lehetett futtatni a mellékelt példaprogramokat.

Ehhez képest egy Android Studio tényleg olyan, mintha egy űrállomást kellene irányítani. De egy kezdőnek szerintem nem is feltétlenül erre van szüksége. Igazából továbbra is lehet használni mikroszámítógépeket, bár nem a legköltséghatékonyabb, mert a retroláz eléggé felverte az árukat. Régi PC-t viszont lehet bagóért venni, egy FreeDOS telepítése után lehet is használni a FreePascalt, ami a rendszer része. Ha pedig azon túljutottunk, akár C++ felé is léphetünk, de szöszmötölhetünk assemblyben is.

De egy modern PC-n sem kell lemondani a könnyű és gyors programozásról. Szinte nincs olyan programozási nyelv, amihez ne lehetne találni böngészőből futó értelmezőt (példa, példa, példa ez utóbbit csak poénból raktam ide). De ha imádjuk a telefont nyomkodni, ott is vannak lehetőségek, elsősorban értelmezett nyelvekre. Egy időben a QPython3-al bohóckodtam, de rá kellett jönnöm, hogy az érintőképernyős programozást nem nekem találták ki. Másnak ettől függetlenül bejöhet.

Viszont egy apró problémám volt a korai időkben, és a probléma lényege a fenti eszközökön sem változott meg az idők során. Bármit is csináltam, az csak a képernyőn jelent meg, esetleg ki lehetett nyomtatni. Ha meg szerettem volna mutatni például a nagyszüleimnek, hogy mit is csináltam, az szinte lehetetlen volt. Vigyem el hozzájuk a C64-t? Az még annyira nem is volt nehéz, de egy PC-t? Katódcsöves VGA monitorral? Kizárt.

Az internet terjedésével ma már el lehet dicsekedni nem csak a nagyszüleinknek, hanem a világ minden táján élő bunkóknak is, akik nem rejtik véka alá, milyen szánalmasak is vagyunk. De a képlet továbbra is ugyan az: amit csináltunk, az csak egy képernyőn jelenik meg. Egy demoparty keretében talán szép nagy képernyőn, de akkor is csak egy képernyőn.

Mi viszont a valóságban élünk, nem egy képernyőben.

Szerencsére viszont kitörhetünk ebből olyan kütyük segítségével, amelyek a valóságban hajtanak végre interakciókat. Ilyenek viszont nem voltak annak idején, és ezért gondolom, hogy manapság jó dolog programozni. Amit készítünk, nem korlátozódik egy képernyőre.

Az első ilyen eszköz, amit meg kell említeni, a programozható mikrokontrollerek, mint amilyen az Arduino is. Lehet tanuló kiteket is vásárolni, amelyek újonan elég húzós áron vannak, de apróhirdetésekben mindig találni olyanokat, akik megszabadulnak a régi modellektől, mert újabbat akarnak venni. A régi modellek pedig tökéletesen megfelelnek arra, hogy zümmögő, villogó, izgő-mozgó bigyókat készítsünk. Az egyetlen hátrányuk, hogy súlyos függőséget alakítanak ki, aminek következtében minél több szenzort, motort, és egyéb kiegészítő bigyót akar venni az ember. Én odaáig jutottam, hogy felvásároltam egy Spanyolországba kitelepülő ember teljes készletét. Szerintem pontosan nem is tudta, miket ad le, csak meg akarta szabadulni tőlük. Két napot csak azzal töltöttem, hogy megpróbáljam beazonosítani az alkatrészek rendeltetését.

Ha viszont növelni akarjuk a tétet, akkor nem mikrokontrollerekkel, hanem SoC-okkal is kezdhetünk. Előnyük, hogy továbbra is csinálhatunk villogó bigyókat, de akár teljes értékű számítógépként is használhatjuk. Ezekből a Raspberry-k a legnépszerűbbek. Az újabb modellek egyre töbet tudnak, de ha nem vagyunk telhetetlenek, akár még a második generációs modellekkel is remekül szórakozhatunk, miközben az áruk használtan teljesen megfizethető. Például akit elriaszt a Windows-ra telepítendő IDE-k komplexitása, azoknak csak annyit kell tenni, hogy kiválasztanak egy olyan rendszert, ami szimpatikus és kimásolja egy SD kártyára.

Ha gyerekünket akarjuk helyes számítógép használatra szoktatni, akkor ott a Kano OS. Ha hekkelni akarunk, ott a Kali Linux, ha az elektronika érdekel, akkor meg tömérdek online tutorial foglalkozik a kérdéssel. De játszhatunk rég elfeledett játékokkal a RetroPie segítségével, ami annyi régi gépet emulál, hogy felsorolni is nehéz. Sőt, ha igazán bevadulunk, akkor a Raspberry-t összeköthetjük az Arduinóval is. A lehetőségek száma végtelen, egy microSD kártya csere, és a gép kész az új kihívásokra. Ahogy növekednek az ismereteink, úgy tudjuk egyre jobban kihasználni a gépet.

Mivel a körülöttünk található valóság lassabban változik, mint virtuális társa, ezért ezeknek az eszközöknek hosszabb az életidejük is. Ráadásul a méretük is kicsi. Ha a nagyi még nem lenne fent a neten, csak zsebretesszük, elvisszük magunkkal és megmutatjuk, mit alkottunk.

Számtalan felesleges szokásaimnak egyike, hogy a programokat, amelyeket használok, letöltöm, majd archiválom. Évekkel később meg nézem a felhalmozódott adathordozókat, amelyek csak foglalják a helyet, de igazán ritkán nézem meg a tartalmukat. Lehet, hogy az írható CD-k már rég olvashatatlanok? Ki tudja? Egyáltalán emlékszem mi mindent írtam ki? Vagy hova mentettem X programot?

Nem emlékszem. Ezt abból tudom, hogy ha kell valamit, újból letöltöm, majd újból archiválom. Csak gyűjtögetem ezeket a programokat a digitális pofazacskómba, mint valami hörcsög. Még lementett GitHub repok is vannak nálam, amelyek már talán le sem fordulnak, mert ősrégi GCC kell nekik. Bár talán azok is megvannak nekem valahol.

Van felhő, a személyes tárolás a múltté. Már lassan optikai meghajtók sincsenek a gépekben, de ethernet dugó még van.

A legújabb publikációm viszont azért tudott megszületni, mert lementettem egy programot. Ráadásul nem is olyan régen.

Mint arról már korábban írtam, az UMI alapú elemzést egy jó iránynak tartom. A program GitHub oldalát le is mentettem magamnak. A laborosok szépen rá is álltak a módszerre, mi meg elemeztük őket, mint a gép.

Aztán történt egy olyan apróság, hogy az elemzéseket új szerverre költöztettük, ahol még több hely állt rendelkezésünkre, és nem kellett osztozkodni másokkal. Elkezdtük újra telepíteni a programokat, amikor is kiderült, hogy a Qiagen a eltávolította az smCounter2-t a GitHubról. Volt program, nincs program.

A biztonsági mentésemnek köszönhetően persze megvolt a program, de ott motoszkált a fejünkben a kérdés: Vajon mennyit változtattak a kódon azóta? Minden esetre elvégeztük az elemzést.

Később a csoport megvette a fizetős változatot, mi pedig leellenőrizhettük, mekkora eltérés van a két módszer között. Nos, a mindkét eredmény bájtra pontosan megegyezett. Csupán két eset volt, hogy a lefedettség 1 read eltérést mutatott. Valószínűleg volt egy elgépelés a kódban, amit kijavítottak.

Talán nem árulok el nagy titkot, ha azt mondom, hogy a Magyar Demoscene Egyesületet a legtöbb scener támogatja, jó ötletnek tartja, de tisztségeket senki nem akar viselni. Amióta részese vagyok a közösségnek, minden tisztújító közgyűlésen a régi tagok menekülni akartak, mások viszont nem akartak a helyükbe lépni. Ekkor a régi tagok fogukat szívva újra elvállalták a szerepeket. Ha pedig elérték a maximális újraválaszthatóságot, boldogan léptek le. Ekkor szokott kezdődni az a huzavona, amivel új vezetőket csalogatják.

Idén sem volt ez másként. Már majdnem úgy volt, hogy sikerül behálózni pár embert, de végül mégsem álltak kötélnek. Gargaj volt az egyedüli, aki azt mondta, hogy vállalja a következő két évre is mandátumot. Aztán megkérdezték, ki vállalná a többi tisztséget.

Természetesen néma csönd volt. Én meg arra gondoltam, miért ne vállalhatnék valamit? Igazából korábban is kacérkodtam a gondolattal, csak nem éreztem elég hitelesnek magamat. A legtöbben több, mint húsz éve a pályán vannak, tizenéves koruk óta ténykednek, erre én álljak az élre?

Most annyit változott a helyzet, hogy senki nem jelentkezett, ezért belevágtam, megpályáztam a titkári pozíciót, és megszavaztak. Nem egyhangúlag, ugyanis ketten elnöknek akartak.

Meglátjuk, mi sül ki belőle.

Nemrég az egyetemi levelezésen keresztül, egyetemi email címről kaptam egy béna malware-t. Annyira béna volt, hogy letöltöttem elemzési céllal. Az eset remekül példázza azt, hogy kártékony kód írásához nem kell különös képzettség, tudás, de még igényesség sem, csupán rosszindulat.

A szakértők a kártékony kódokat egy virtuális gépen szokták tanulmányozni, ahol megteszik a megfelelő intézkedéseket, hogy a program ne tudjon onnan elszökni és más gépeket megfertőzni. Én semmi ilyesmit nem csináltam, mert az egész egy HTML állomány volt, böngészőben pedig nem szándékoztam megnyitni.

A levél szövege szerint ahhoz, hogy az egyetem egyik fontos dokumentumát megnézhessem, egy kliens programot kell letöltenem. Ez a kliens program a HTML akart lenni a levél csatolmányában. Már a szövegről látszott, hogy ez egy jelszó lopó borzalom, de azt hittem, talán valami fergetegesen zseniális JavaScript van elrejtve benne.

Nem volt. A HTML az egyetemi levelezés bejelentkező képernyőjét másolta annyi különbséggel, hogy a beírt felhasználó nevet és jelszót egy dislack.com-os címre küldte el. Mi a csoda ez a Dislack?

A Dislack segítségével webes űrlapokat készíthetünk, nagyobb szabadságot kapva. Mintha a SurveyMonkey és a Wix keveréke lenne. Regisztráció után kipróbáltam, mit tud a rendszer. Lehet formot is készíteni, de akár végpontot is egy létező HTML-hez. Ebben az esetben a rendszer csak adatot gyűjt. Jelen esetben jelszavakat. Az összegyűjtott adatokat táblázatos formában megjeleníti, ahol az oszlopok az input mezők nevei, a sorok pedig a kitöltött a mezők értékei. A form elküldése után egy dislack oldal jelenik meg, ahol megköszönik, hogy használtuk a rendszert. Elég egyértelmű, hogy nem az egyetem terméke, de akkor már szinte mindegy, mert a jelszavunkat elküldtük. Bár ha ebben a pillanatban valaki felismeri a tévedését, még mindig megváltoztathatja a jelszavát. Az ingyenes verzióval 100 formot lehet feldolgozni, viszont nincs email ellenőrzés, ezért biztos lehet kamu email címekkel rengeteg ingyenes hozzáférést generálni. Ennek ellenére a módszer szerintem nem túl hatékony.

Nem is az a szörnyű, hogy ilyen minimális tudással csinált valaki jelszó lopót, hanem az, hogy a jelek szerint működik! Nyilván ugyan ezzel a módszerrel szerezték meg annak a felhasználónak a hozzáférését is, akitől kaptam ezt a levelet. Miután elemeztem egy kicsit a módszert, az összes információt elküldtem a rendszergazdáknak, akik írtak egy körlevelet képernyőképekkel, hogy a felhasználók felismerhessék a csapdát. Egyetlen probléma volt csak vele. Ezen az ismertetőn a rektori hivataltól jött a jelszólopós email...

Először is, nekem is meg kell jegyeznem, hogy a demoscene immár a világörökség része Németországban. Azért jó dolog, hogy a hobbim már nem csupán kockulásnak számít, hanem valaminek, ami önmagán egy ici-picit túlmutat. Ezzel az emelkedett hangulattal vágtunk neki kedvenc Húsvéti partinknak.

Az idei Revision-t már eleve online partiként tervezték, de bebizonyosodott, hogy váratlan helyzetek így is történhetnek. Az egyik alkotásban ugyanis feltűnt egy csupasz férfi hátsó (de az is lehet, hogy egy másikban látható női kebel miatt) a streaming szolgáltató megszakította az adást és kitiltotta az egész bandát, világörökség ide vagy oda. Én meg nem néztem folyamatosan az eseményeket (azaz nem csekkoltam felváltva a Discord csatornát, fórumot, komment szekciót), ezért csak későn értesültem a cseréről és lemaradtam a legtöbb alkotásról. Csak fokozatosan tudtam bepótolni a látni és hallani valót.

3D grafika

Ez egy új kategória. Eddig is voltak 3D render képek, de csak egy nézetből mutatták be őket. Itt a 3D színteret bejárta a kamera és sok olyan részletet is lehetett látni, amit a hagyományos képekben nem. Csak négy alkotás volt és még egyik sem ütött meg komoly színvonalat, de ettől függetlenül látok lehetőséget ebben a compóban is.

Oldschool grafika

A kategóriát C64 és Amiga produkciók uralták. Egyetlen Atari figyelt csak be Pandafox jóvoltából. Tetszett, hogy a képek között voltak rajzfilm hatásúak is, amik sokkal jobban passzolnak a régi gépek képességeihez. Ennek ellenére álljon itt a győztes, ami a maximálisan kihasználta a rendelkezésre álló kapacitást:

Modern grafika

Ide jött minden, ami nem régi géppel készült, bár az Ascynchronous Colors eléggé pixeles volt ahhoz, hogy akár egy Amigával is el lehessen készíteni. Ettől függetlenül a képek nagy része nem nyűgözött le. Ami legközelebb állt a szívemhez az is témájával, nem esztétikájával tette ezt. Ez pedig a Technically At Home volt:

4k grafikák

Itt viszont kitettek magukért a résztvevők. Húszonegy alkotást láthattunk, és bizony a háromnegyedük kimagasló volt, és szerintem a végső egy negyednek sincs oka szégyenkezni. Tizenegyedik helyre még egy Linux produkció is bekúszott. Önkényes választásom a The word is not enough-ra esett, mert Bond. James Bond.

Paintover

Ebben a hevenyészett Rorschach-teszt alapú compóban nem is az a legérdekesebb, mit alkotnak a művészek az eléjük helyezett pacából, inkább az, hogy mennyire különböző mindegyik eredmény. Komolyan, csak nézzük meg ezt:

És ezt:

Döbbenet.

Fotó

Pasy szintet lépett a fotózásban. Már profi modellt és műtermi felszerelést használ:

ASCII/ANSI/PETSCII

Általában a fotó, utána pedig valamelyik zene compó a legnépesebb kategória. Idén valami miatt mégis a karakterekkel rajzolás volt az, amire a legtöbben beneveztek.

Streaming music

A zenék közül egyedül Turbo Knight zenéje fogott meg, mert a szövegen én személy szerint szétröhögtem magam. Ilyen is ritkán fordul elő, hogy zenekompón felnevessek, ha mégis előfordul, az Netpoetnek köszönhető. Idén is indult, második lett, de ez a swinges akármi nem nyűgözött le.

Animációk

Bár Gaspode nyert, azért érezhetően rájátszott az amigás érzelmekre. Nekem személy szerint nem volt kedvencem a kompóról, pedig tényleg igényes munkák is készültek. A Koritsu 2 (ha valaki tudja, hol az 1., akkor szóljon) például gyönyörű volt. Az Amaranto abszolút professzionális, még ha nem is rajongok a táncos videókért.. Lehet, hogy csak hiányzott a fraktál adagom, azért nyafogok ennyit.

Oldschool demo

Itt egyáltalán nem olyan gépösszetétel volt, mint a grafikáknál. C64-el kevesebb, mint az indulók fele nevezett. Még egy Wonderswan is volt, ami egy annyira ritka gép, hogy eddig csak a három demót írtak rá. (Még Enterprise-ra is van 17 alkotás) Grass új csapata, a Lethargy is indult egy Function invitációval. Bevallom, az elején attól féltem, ez is egy scroll-és-kész-az-invite típus lesz, de nem. Az egyik effektet külön beadták intrónak is.

64k intro

Két intrót nem tudtam lejátszani, mert a Windows Defender törölte őket, amint megpróbáltam megnyitni a zip fájlt. Nem tudom, hogy ez egyedi eset-e, minden esetre a Pusztító Szarvas Isten intrót (aka Deus cervidae) csak videón láttam. Érdekes, nagyon érdekes koncepció. Többet viszont nem tudnék róla mondani. A másik érdekes dolog a Conspiracy volt. Eddig ugyanis megszokhattuk tőlük, hogy minden intrójukkal le akarták robbantani a nézők fejét utolérhetetlen grafikával, végletekig feszített művészi hatásokkal. Ha mégis csináltak valami könnyedebbet, akkor azt mindenféle álnév alatt mutatták be, nehogy a Conspiracy néven bármi folt keletkezzen. Most viszont nem tolták túl magukat, "középen pörögnek a 3D objektek" típusú intrót csináltak, de ezt én nem látom bajnak. Ha az ember állandóan azon görcsöl, hogy minél nagyobb-szebb-jobb intrót csináljon, a végén csak megcsömörlik:

Amiga demo

Az idei Amiga demók kevésbé voltak technikai kuriózumok, sokkal inkább a dizájnra mentek rá. Ez nem jelenti, hogy ne lett volna erős a kód, de kevésbé volt  fajsúlyos, mint egy Elude vagy The Black Lotus demóban. Nézzük csak meg a győztes The Martini Effectet. Néhány egyszerű textúrával gyönyörű fraktál világot teremtettek.

Bevallom, eddig a Noice csapat elkerülte a figyelmemet, pedig már 1993-óta nyomják. Címválasztásuk valami miatt a kecskék körül forog. Nincs is ez másként a Last Goat Standinggel sem. Igazi adrenalin löket.

Demo

Itt aztán bedobtak apait-anyait. Still gyakorlatilag két demót is készített. Az egyiket saját néven adták ki, a másikat Wake alatt. Tavaly is ezt csinálták, majd egyszer kiderítem, mi a motiváció emögött. A Cocoon is készített egy demót, de ennek egyetlen üzenete volt: pofátok lapos. Az utóbbi időben egyesek kritizálták őket, hogy Notch-al készítik a demókat, úgyhogy most csináltak egyet anélkül. Sok értelmet nem kell keresni benne, még akkor sem, ha story demónak akarja eladni magát. Viszont az összes létező shader izzik, számol, pakolja a tűéles textúrákat, valamint szuper karakter animáció van benne. A Futuris ezzel szemben Unreal engine-el dolgozik évek óta. Idei Dark Matter címet viselő alkotásuk nagyon szép részecske-rendszert mutat be. A New Wold Awaits című demó a második lett, itt végre megkaptam az animációknál annyira hiányolt fraktál-orgiát. Csupán az zavart, hogy sok fehérzajt pakoltak a képre. Ettől egy kicsit olyan lett, mintha raytracing lenne az egész, pedig a jelenetek nagy része csak textúrákból áll. Lehet, hogy majd jobban is elemzem ezt a demót. A győztes pedig az Arcade lett, ami az árkád játékgépeknek állít emléket. Ami itt nagyon jó volt, az a rendezés. Ahogy a jelenetek átmentek egyikből a másikba, azt szerintem tanítani lehetne. Csupán egy jelenetet nem értettem, amikor a demók nézték, hogyan táncolnak az árkádgépek a színpadon. Mit akart vajon ez jelenteni? Talán azt, hogy az árkád játékok a demók elődei? Ez biztosan nem igaz, szóval valami mást kell, hogy jelentsen. Persze az is lehet, hogy csak lusták voltak modellezni:

Futtatható zenék

A futtatható zenéknél, a procedurális grafikákhoz hasonlóan nem csupán  a végeredményt kell értékelni, hanem az azt létrehozó kódot is. Emiatt gyakran előfordul, hogy a zenék kevésbé élvezhetőek az "igazi" zenékhez képest. Viszont ahol a kettő képes kiegészíteni egymást, ott születnek a győztesek, ahogy ez történt Wayfinderrel és SunSpire-el. Nekem ugyan utóbbi jobban tetszett, mert a hangszerek természetesebb hatást keltettek.

256 byte intro

Levezetésként nézzük meg, hogy az egyik legkisebb intró kategóriában mit láthattunk. Nekem legjobban Rrrola csavarodó karfiol-fraktálja tetszett, de ő csak a harmadik helyre szorult. A Wait for it az élvonaltól messzebb helyezkedik el technikában, de ötletben határozottan a legjobb. TomCat is indult, és a 8. helyet érte el

Régen elég sok időt töltöttem számítógépes játékokkal. Még C64-el kezdtem, ahol a kazettás, primitív vackokkal nyomultam, miközben a barátaimnál tátott szájjal néztem a több lemezes komplex játékokat. Ez valahogy később sem változott, mert az új játékok mindig egy nagyobb hardveren futottak, és ezek a hardverek továbbra is haveroknál voltak.

Azt hiszem, valamikor 2005 környékén csömörlöttem meg az egésztől, onnantól nem akartam játszani semmivel. Semmivel, kivéve a GTA sorozattal. Ez az egy, ami mindig le tudott kötni. Az egész még a GTA III-al kezdődött, ami annyira új volt, annyira más, mint bármi, amit addig láttam. Mászkálhattam egy városban és mindenhol apró küldetéseket lehetett találni. Bámulatos volt. Az újabb és újabb játékok pedig csak tovább növelték ezt az ámulatot.

Ezért, mikor ingyenes lett a GTA 5, nem volt kérdés, hogy kell. De egyáltalán nem voltam felkészülve, hogy mit jelent mindez 15 év kihagyással.

Annak idején a játék valami hordozón volt. Kazettán, lemezen, majd később CD-n. Az ember betette a gépbe, majd jászott. Mivel a hardver ugyan az volt mindenkinél, így biztos lehettem benne, hogy a játék futni fog. Később ez már nem volt elég, telepíteni is kellett. A DOS-os időkben néha művészet volt a gépet és a játékot összhangba hozni, de ha megvolt, akkor biztosak lehettünk benne, hogy a játék működni fog, mert kevés hardver volt. Na jo, a hangkártya tényleg eltérő lehetett, de igazából szinte mindegyik DOS-os játékot lehetett hang nélkül is játszani.

A 3D gyorsítással ez végérvényesen megváltozott. Már millió hardver volt, és hiába lett DirectX, a helyzet  kicsit bonyolultabb lett. Már nem csak a gép, de a különböző driverek is beleszóltak a játszhatóságba. Nem elég, hogy megfelelő vas kellett, még megfelelő driverekre is szüksége volt.

A hálózati játékok nekem kimaradtak, egyszerűen azért, mert csapnivaló játékos vagyok. Annyira csapnivaló vagyok, hogy csak úgy tudtam végigvinni a pályákat, hogy megismertem a játékok gyengeségeit. Például régen az árnyékolás olyan gyerekcipőben járt, hogy csak egy sötét kört raktak ki, ami látszott a pálya alsó szintjén is. Tehát ha a mennyezeten volt egy sötét kör, tudtam, hogy ott mászik valami szörny. Néha még le is lehetett lőni a plafonon keresztül.

Mostanra minden megváltozott. Már nincs adathordozó. Először is, kell egy Epic/Steam azonosító, amivel megszerezzük a jogot, hogy megszerezzük a játékot. Ez a rendszer természetesen folyamatosan frissíti magát. De ezzel még nincs vége, mert szinte minden játéknak van saját felhője, ezért kell még egy felhasználó név/jelszó páros, amivel az adott játékkal lehet játszani. Lejön rengeteg gigabájt, bejelentkezések, hálózati azonosítók összekapcsolása, hogy ne kelljen több ezerszer beírni őket, és már lehet is játszani.

Vagy nem. Ugyanis a rendszer komplexitása tovább nőtt, ahogy a játékok frissítik magukat. Már nem csak megfelelő számítógép kell, megfelelő driverekkel, hanem megfelelő internet kapcsolat és megfelelő frissítések is (mind a Streamhez, mind a játékhoz). Bármelyik hiányzik, nincs játék. De ha megvan minden, az sem garantál semmit, mert nem biztos, hogy a legújabb frissítéstől stabilabb lesz a játék. Bármelyik komponens bármelyikkel ütközhet. Néha csak kapok egy üzenetet, hogy a szerver elérhetetlen, és kilép a játék. Esély sincs, hogy az ember bármit is tehessen ellene. Héha teljesen érthetetlen hibákat kapok, amelyek 5 perccel később nem jelennek meg.

Ezért a játék elindítása nekem plusz logisztikát igényel. Először csak egy próba indítás van, amit akkor csinálok, amikor még nincs időm játszani. Ekkor letölt mindenféle frissítést. A net és a vinyó csak úgy izzik, miközben a gép teljesen használhatatlan a terheléstől. Ott is szoktam hagyni, hogy dolgozzon, én is csinálom a magam dolgát. Ha már a vinyó ledje nem világít folyamatosan, óvatosan megnézem, nem fagyott-e le. Ha mozog az egér, akkor letörlöm a kövér izzadság cseppeket a homlokomról és lekapcsolok mindent.

Mikor van szabadidőm, újra elindítom, mert nem kell arra várnom, hogy frissítsen, de így is 10 perc kell minimum, hogy minden elinduljon. Belépek egy online világba, ami egyáltalán nem olyan, mint a Ready Player One. Ott valahogy mindenki normális. Ebben a játékban igazi Darwini rémálom uralkodik. Az erősebb egyetlen célja, hogy levadássza a gyengébbeket.

Aki nem ismerné a játékot, annak röviden elmondom: Ez a jelenünkben játszódik, egy amerikai nagyvárosban, ahol nekünk bűnöznünk kell, hogy pénzt szerezzünk. A pénzen felszerelést veszünk, hogy magasabb szinten tovább bűnözzünk. Rabolhatunk bankot, pénzt hamisíthatunk, vagy fegyverrel is kereskedhetünk.

Viszont akik már régóta játszanak és hatalmas vagyont halmoztak fel, és már teljesen unják a játékot, azok méreg drága tankokkal, vadászrepülőkkel lelőnek mindenkit, aki az útjukba kerül. Sőt, mivel a játék készítői kifogytak az ötletekből, ezért egy idő óta különböző futurisztikus frissítéseket adtak hozzá. Ezért már van lézer fegyver, repülő motor/autó hőkövető rakétával (csak, hogy célozni se kelljen), sőt, valami világűrbe telepített csapásmérő műhold is, amivel egy gomb megnyomásával bárkit el lehet pusztítani, aki a szabad ég alatt tartózkodik.

Ezek a legális lehetőségek. A játék szkript-rendszerét ugyanis néhányan megbuherálták, amitől egyesek olyan képességekkel bírnak, mint tengeralattjárót tudnak a fejünkre dobni, közönséges pisztolyból robbanó golyót kilőni, sebezhetetlenek és bárhol megjelenhetnek a játéktérben. De meg sem kell jelenniük, egyszerűen fel tudják robbantani egyszerre az összes játékos.

Igazából maga a játék is ezeknek az attitűdöknek az erősítésére épít. Ha például én eladok valami szajrét (ami jellemzően egy fegyvertelen, lassú szállítóeszköz vezetését igényli), akkor az összes többi játékos értesítést kap, hogy én mit csinálok, és egy hatalmas piros foltként jelenek meg a térképen, hogy mindenki jól láthasson. Jönnek a taktikai harci gépek, és csak örülhetek, ha egyszer robbantanak fel. Ha olyan kedvük van, akkor amint ismét megjelenek, azonnal célba vesznek. Annyi időm sincs, hogy fedezék után nézzek.

Most elég sok negatívumot írtam, kérdezhetitek, akkor miért játszom vele? Mert nem beszéltem arról, hogy mi a másik erőssége a játéknak. Nevezetesen, hogy lehet szövetségeseket szerezni, akik segítenek. Ugyanis olyan megcsömörlött játékosok is vannak, akiknek szintén megvan minden felszerelésük, de nem abban élik ki magukat, hogy a hozzám hasonló gyíkokat eltapossák, hanem büntetik a fenti rossz szándékú játékosokat. Szabályos járőrözést tartanak, figyelik a játékosok kommunikációját és beavatkoznak, ahol kell.

Ezen felül vannak olyan játékmódok, ahol erősen lekorlátozták mit szabad és mit nem. Például ha csak versenyezni akarok, akkor senki nem repülhet oda egy bombázóval. Számtalan ilyen mini játék van. A versenyzésen kívül persze különböző egymás elleni mérkőzések is vannak és kooperációs játékok is, ahol például az a cél, hogy túléljük a ránk támadó ellenségeket.

De lehetünk akár Michael Knight is, aki egy KITT-hez rendkívül hasonlító kocsival küzdi le az akadályokat. Mi lehetünk Danny Ocean (vagy ha valakinek szimpatikusabb, Debbie Ocean), aki végrehajtja az évszázad rablását. Lehetünk világmegmentő titkos ügynökök egy tengeralattjáróvá átalakuló autóval. Vezethetünk éjszakai bárt, amit természetesen a bűnszervezet fedésére használunk, de ha mindez nem lenne elég, akár az összes pénzünket elverhetjük egy kaszinóban is. Lehetünk kaszkadőrök, akik hajmeresztő mutatványokat hajtanak végre. Vehetünk egy garázst, amiben Mad Max-szerű járműveket készítünk.

Szóval egy olyan játékról van szó, ami mindig más, és még ugyan azt a feladatot is többféle módon lehet megoldani. Ilyen nem volt régen. Régen egy játék elég behatárolt volt. Még az olyanok is, mint a Raid Over Moscow, ahol bár különböző tevékenységeket kellett csinálni, ezek akkor is kötött sorrendben követték egymást. Itt sokkal nagyobb a szabadság.

Mivel R-ben tudok írni ciklusokat és ismerem a cor függvényt, félelmetes hatalomra tettem szert. Kegyetlen sok korrelációt tudok számolni igen rövid idő alatt. Ez a hatalom majdnem a Kruskal-Wallis tesztek hatalmával ér fel. Annyi korrelációt ki tudok számolni, hogy utána egy hónapig bogozzák az eredményeket a laborosok.

Ráadásul ez még tetszik is nekik. Annyira élvezik ezeknek a táblázatoknak a böngészését, hogy újabb és újabb projektekhez kérik ezt a varázslatnak felérő segítséget, mint ez történt legutóbb is.

Megkérdezték, iszonyú sürgős határidővel (mi mással?) tudnék-e nekik giga korrelációs táblázatokat generálni. Azt mondtam, tudok. Erre kaptam egy olyan táblázatot, ahol csak átlagok szerepeltek és plusz-mínusz a standard hiba. Bár már egy tucat ilyen analízist csináltam nekik, mégis, minden egyes alkalommal el kell mondani, hogy átlagokból nem tudok semmilyen korrelációt számolni, kellenek az ismétlések is. Hiába, én már csak ilyen régimódi vagyok: kell adat, hogy számoljak.

Kaptam is. Egy olyat, ami a legborzasztóbb Excel táblázatok közé kívánkozik. A fejlécek teljesen értelmezhetetlenek voltak. Minden oszlopot kiszíneztek. Voltak piros számok, amik mást jelentettek, mint a feketék. De a lényeget így sem tudták elrejteni: kiderült, csupán három ismétlésük van. Vagyis összehasonlításokként három pontból kellene kiszámolnom a korrelációs együtthatót.

Gyorsan meg is állapítottam, hogy ezzel a témával nem kell sokat foglalkozni. Persze a laborosokat nem könnyű olyannal meggyőzni, hogy valami értelmetlen. Megkérdezték, mi lenne, ha kétszer használnám fel az adatpontokat! Igaz is, minek vesződni kísérletekkel, ha egy copy-paste az Excelben megoldja minden problémánkat? Megkérdeztem, miért csak kétszer vegyük az adatokat? Vehetnénk ötször is, az lenne ám a statisztikai erő! Minek végeztek egyáltalán három ismétlést? Egy is elég lett volna, majd azt az egy adatot vennénk nagyon sokszor.

Kiderült, hogy ez még csak a jéghegy csúcsa. Ugyanis az a három ismétlés sem három ismétlés. Néha kettő, néha három, csak a biológiai mintákat összeöntötték egybe, homogenizálták, és abból vettek ki a három mintát, azt mérték le, és ennek eredményét küldték el nekem. Voilá, varázsoltak három ismétlést mindenből.

Szerintem a legtöbb olvasóm tisztába van vele, miért rossz a fenti kísérleti elrendezés, de egy példával megpróbálom a nem szakmabelieknek is elmondani.

Képzeljünk el, hogy egy cég új vízmelegítőt dob piacra. Kíváncsiak, mennyire jól melegíti a vizet. Tegyük fel, hogy annyira rosszul működnek, hogy a beállításoktól függetlenül 4 és 90 Celsius fok között bármilyen hőmérsékletet produkálhatnak. Mi viszont kiválasztunk három gépet, a "felmelegített" vizeket összeöntjük és megmérjük háromszor a hőmérsékletét. Azt látjuk mindhárom mérésből, hogy kellemes langyos vizet készít. Az eredmények alapján kiosztjuk a prémiumokat és eladjuk a gépeket, mint az esti kellemes fürdőzés nélkülözhetetlen kellékeit.

Az egyik levelezésben ráadásul láttam a laborosok üzenet váltásait is. Abban szerepelt egy ilyen mondat: "tudjuk, hogy a statisztika nem szereti a három ismétlést, de meglátjuk". Tehát már az elején tudták, hogy hülyeséget csinálnak, csak arra számítottak, hogy... Nem tudom mire számítottak. Talán arra, hogy nem veszem észre, és véletlenül mégis kiszámolok valamit? Mindegy is. A projekt két nap levelezésbe került csak, és végül a megérdemelt helyére került:

A legújabb publikációm egy olyan kollaborációból született, amiben a Linkedin-en kerestek meg, még 2018-ban. Általában csak HR-esek akarnak kapcsolatba lépni velem, ezért is lepődtem meg, hogy valódi kutatók vannak a vonal másik végén. Kíváncsi voltam, ezért igent mondtam.

A csoportot épp akkor hagyta ott egy Visual Basic bioinformatikus, ezért kellett nekik valaki, aki egyszerű programokat össze tud rakni. Az első megbízás egy Nanopore szekvenálásból származó statisztikai táblázat elkészítése volt. Mivel nagyon sokat szekvenáltak, több párhuzamos projektjük is volt, amire csak három betűs rövidítésekként utaltak.

A táblázatot két szkripttel állítottam elő, az egyik egy BAM feldolgozó Python szkript volt, a másik a statisztikai számításokat, ábrákat készítő R szkript. Első blikkre elég jól működtek. Minden elemzést az otthoni gépemen futtattam, ami akkor már elég hangos volt, hála a CPU paszta döglődésének, de még nem fagyott.

A kapcsolattartás Facebookon ment, de mivel én külsős voltam, nem sokat értettem a kommunikációból, ami tobbzódott a labor-szlengtől. Tulajdonképpen semmit nem értettem magából a kísérleti elrendezésből. Azt tudtam, hogy vírussal fertőztek meg sejteket, de a kondíciókat nem sikerült megtudni, azok számomra csak három betűs rövidítések maradtak. Igazából a kooperáció ezen szakaszán nem is volt túl nagy jelentősége, hiszen csak leíró statisztikákat kellett csinálni, amit még két újabb projekthez is elkészítettem.

Természetesen, mint minden projektben, itt is volt Nagy Kuss. Mivel nem ez volt a főállásom, ezért ezekben az időszakokban nem erőltettem én sem a kapcsolatfelvételt, hogy az új barátság ne menjen a régi rovására.

Azt gondoltam, minden rendben van. De rövidesen kiderült, hogy nagyot tévedtem. Az egyik PhD hallgató keresett meg még 2019 november elején, hogy a leíró statisztikákban van egy anomália. Nevezetesen, hogy a lefedettséggel arányosan nő az indelek száma, ami nyilvánvalóan hülyeség. Bár tucatnyi módon ellenőriztem az eredményeket, de egyetlen korrelációt sem csináltam a szekvenálási ismétlések között. Ha csináltam volna, jópár kellemetlen pillanattól kíméltem volna meg magamat.

Elkezdtem ellenőrizni a szkripteket. Külön a Pythont, külön az R-t. Tökéletesen működtek. Csináltam egy kisebb teszt adatot is. Újabb ellenőrzést végeztem, ismét megállapítottam, hogy a szkriptek tökéletesen működnek. Akkor viszont a korrelációk megléte nem hibára utal, hanem a szekvenálások jellege miatt jelentkezett. Még egy botcsinálta hipotézist is alkottam, miért látjuk a jelenséget.

Utána jött egy elég furcsa beszélgetés, amiben végigvettük az egyik PhD hallgatóval, hogyan működik a szkriptem. Néhány statisztikát több módon is ki lehetett számolni, attól függően, milyen kérdésre kerestük a választ. Minden egyes ilyen esetben megkérdeztem: Ezt szeretnétek? A válasz minden esetben: Ez is egy számítási módszer, majd meglátjuk, a főnöknek melyik tetszik. De soha nem mondtak semmit, hogy pontosan mit is szeretnének.

Aztán megtalálták a hibát is. Bár a két szkript külön-külön tényleg jól működött, a kettő együtt már nem. És én ezt is elmúlasztottam ellenőrizni. A Python szkript ugyanis néha Null-t adott vissza, ha nem volt értékelhető a szekvencia. De az R szkript ezt 0-nak vette, vagyis értékelte azt. Ezért minél nagyobb volt a lefedettség, és ezzel arányosan nőtt az értékelhetetlen szekvenciák száma, annál nagyobb volt a torzítás is. Teljesen leégettem magam. Miután láttam, mi a gond, gyorsan kijavítottam a hibát, és kérdeztem, hogy akkor újrageneráljam-e az eredményeket.

De az igazán kellemetlen dolog ezután jött. Erre a pillanatra ugyanis összehoztak egy házi szkriptet, és inkább azt akarták használni. Jött egy másik email, amiben a hipotézisemet hülyeségnek titulálták, a szkriptemet használhatatlannak. Ennek ellenére azt mondták, a cikkekbe bevesznek, tehát mégsem volt teljesen elvesztegetett idő.

Ebből is látszik, hogy a kommunikáción nagyon könnyen elcsúszhatnak a dolgok, még akkor is, ha látszólag minden rendben van. Másrészt, meg tesztelni kell a nyomorult szkripteket. Nem csak a részegységeket, hanem az egész munkafolyamatot.