Az élet kódjai

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.

A katasztrófa-filmekben azt szeretem, hogy bármilyen nagy problémával is találkoznak az emberek, végül a leleményesség, ész, bátorság segítségével úrrá lesznek a problémákon. Természetesen mindig van egy szereplő, aki az emberi kicsinyességet és butaságot testesíti meg (valami miatt többnyire polgármester a foglalkozása), de ő létszámban alul marad és a végén valami szörnyű halált hal, mintha még a katasztrófa is büntetni akarná ostobaságáért.

Egy ideje nem nézek katasztrófa-filmeket, hiszen van saját bejáratú katasztrófánk. De ebben a történetben valami miatt a butaság van túlsúlyban. Nem kell messze menni, elég csak a saját környezetemet vizsgálni. Álljon itt elrettentő példaként, és ez alapján talán mások felismerik a saját környezetükben azt, amin érdemes változtatni.

Először is, az anyósom nagyon szerette volna, ha elmennénk hozzájuk Húsvétra. Ezt eleve egy nagyon rossz ötletnek tartottam, mondtam a feleségemnek, hogy ne menjünk. Az volt a válasz, hogy "elvárják". Az én ostobaságom az volt ebben a történetben, hogy nem álltam eléggé a sarkamra, hagytam elfajulni a dolgokat.

Annyit sikerült elérnem, hogy ne tömegközlekedéssel menjünk. Mivel nekünk nincs autónk, apósom jött el értünk, ami elég nagy tortúra volt neki, hiszen két és fél óra alatt ért el hozzánk. Indulás után arról beszélgettünk, milyen súlyos a koronavírus járvány és emberek mennyire nem veszik komolyan. Az ő ismerősei között is vannak, akik szerint az oltás hülyeség, majd beszélt egy másikról is, aki azért nem ment el az oltás időpontjára, mert pont akkor hozták neki a fát.

Aztán szóba hozta, hogy a sógornőm betegeskedik, de ő akkor is ágynak esik, ha "letörik a körme". Nem most kezdte a betegeskedést, hanem már egy hete tart, de erről az elég fontos dologról valahogy nem beszéltek nekünk, pedig a látogatásaink előtt exponenciálisan emelkedik a telefonálások sűrűsége a feleségem és anyósom között.

Ekkor már kezdett felmenni bennem a pumpa, de azzal próbáltak megnyugtatni, hogy vettek a gyógyszertárban tesztet, ami negatív volt, és ez egy olyan erejű bizonyíték, hogy egy három tagú család egészségét fel lehet tenni rá.

Az út felénél jártunk, amikor kaptuk a telefont, hogy megjött a PCR teszt eredménye, ami pozitív lett. Itt már a feleségem is, én is mondtuk, hogy forduljunk vissza. Anyósomat felhívták, aki elég szomorú volt, mert már "feltettem főni a zöldborsót". Engem ekkor személy szerint a zöldborsó hőkezelése foglalkoztatott a legkevésbé. Mivel ott volt nála a négy éves keresztlányunk is, őt is a telefonhoz adta, aki sírva kérdezte, miért nem jövünk, amikor ő annyira várt bennünket.

Szegénynek csak annyit mondtak, hogy "anya beteg". Biztos vagyok benne, hogy nem értette, hogy anya betegsége miként függ össze a mi utazásunkkal, és abba is, hogy sokkal jobb magyarázat lett volna az, hogy mi nem akarjuk elkapni ezt a nyomorult betegséget.

Szépen visszamentünk. Utána még természetesen anyósom felhívott minket, és előadta, hogy a pozitív teszt ellenére sógornőm biztosan nem lehet kovidos, mert nem lázas. Ezt kérem egy volt egészségügyi dolgozó szájából lehetett hallani. Én elhiszem, hogy egy nagyszűlőnek hiányzik, ha Húsvétkor nem örjöngenek körülötte az unokák, de szerintem ennél fontosabb dolgok is vannak.

Ha már katasztrófa van, akkor viselkedjünk úgy, mint a főszereplők, ne úgy, mint a polgármester.

Néha a legváratlanabb helyről kapok tippeket. Még a pandémiás idők előtt a konditeremben kérdezték tőlem, milyen programmal szoktam videókat szerkeszteni. Az én régi módi módszereim számítógépet igényelnek, de kiderült, hogy elég tekintélyes számú megoldás létezik mobiltelefonra is.

Beszélgetőpartneremnek természetesen ez feküdt, mert úgyis a telefonnal készíti a videókat, miért másoljon mindent át egy másik eszközre? A telefonnál a kijelző mérete az, ami megnehezíti egy klippben való pozícionálást. Ha ezt a lépést valahogy ki lehetne váltani, akkor semmi nem gátolná meg, hogy a kütyün szerkesszük a videókat.

A Magisto ezt a lépést egy tanuló algoritmusra bízza. Mikor először megláttam, mire képes, nagyon impozánsnak találtam az eredményt. Látványos volt, dinamikus, miközben a belefektetett emberi munka minimális volt. Elhatároztam, hogy kipróbálom, nekem is beválik-e.

A munka érdemi része természetesen nem az eszközön történik, hanem a felhőben, ezért egy jó internetes kapcsolat elengedhetetlen. Arra gondoltam, letesztelem, hogy mire képes a program, ha például a 2019-es Functionra beadott videóm alapanyagával etetem meg. Legyen ez amolyan ember vs gép összecsapás. Nézzük meg, félni kell-e adtól, hogy a wild compókat elárasztják az olcsó, AI szerkesztette videók.

Általában én úgy dolgozom, hogy több, hosszabb videót készítek, majd az editálás során kivágom az érdekesebb részleteket és elkezdem a zene ütemére összepakolni őket. Közben többször is megnézem a klippeket, hogy inspirációt szerezzek, melyik részhez melyik klipp lenne jó. Nyilván nem ez a legjobb megoldás, de nekem nem is kell a legjobbnak lenni.

Az első probléma az volt, hogy a Magisto csak legfeljebb 10 másodperces klippeket engedett feltölteni, mert ezzel tud csak dolgozni. Kénytelen voltam kivágni neki megfelelő hosszúságú részeket a nyers videókból. Ezekből sem lehetett feltölteni akármennyit, mert én csak a próba verziót használtam. Ha ezt nézzük, akkor a rendszer nálam meg is bukott, hiszen egy 3-4 perces videót nem tud készíteni 1-2 órás alapanyagból. De ha már itt tartunk, nézzük meg, mennyire tudja megkönnyíteni a munkát.

Feltöltöttem az általam kivágott részeket, hozzáadtam a zenét, majd néhány kérdésre kellett válaszolni, hogy milyen legyen a videó stílusa. Ezek igazából csak különböző filtereknek tűntek számomra, tehát senki ne gondolja, hogy kattintok a Michael Bay opcióra, és rögtön jön a forgó kamera.

Az én esetemben nem sok mindent csinált a program (vagy fogalmazzunk úgy, nem sok látványos dolgot), szinte csak egymás mellé pakolta a klippeket és szénné effektezte. Egyetlen kockát sem hagyott érintetlenül, mindenre adott valamit, még abban az esetben is, ha direkt visszafogtam az alkalmazandó effektek számát a beállításokban.

Túl sokat sajnos nem lehet játszani az ingyenes kipróbálási lehetőséggel. A második-harmadik próbálkozásra már csak SD felbontású videót eredményez. Rövid játszadozásom tehát egyetlen értelmes videót sem eredményezett. Ezért elhatároztam, megnézem, mások milyen eredményre jutottak a program segítségével. Egy idő után már kezdtem felfedezni némi mintázatot, feltűntek az így készült videókkal a közös elemek. Vagyis úgy tűnik, kreatív munkára nem alkalmas. Amit készít, egyfajta tömegtermék.

Ezt erősíti meg a cég weboldalán látható különböző sablonok, valamint mely területeknek nyújtanak támogatást. A tucat munka elsőre derogáló kifejezésnek tűnhet, bár vannak bizonyos előnyei is. Például szerintem a legtöbb mobiltelefonos videó elég pocsékul néz ki. Remeg a kép, nincs elég fény, elmozdul a fókusz, stb. A megfelelő pillanatot is nehéz elkapni. Ha évekkel később megnézzük a felvételt, gyakran már nem is értjük, miért vettük fel valaki hisztérikus kacagását. Ha pedig értjük, akkor az válik rejtéllyé, miért találtuk ezt régen viccesnek. Ráadásul a telefonos videózás olcsó, ezért gondolkodás nélkül levideózunk mindent, nem mérlegelve azt, hogy van-e értelme.

Ezekből a nagyszámú, többnyire selejtes videóból a Magisto készít egy vállalható eredményt, amivel lehet villogni a haverok előtt. Jó eséllyel képes kiválasztani a megfelelő pillanatot, a hibákat pedig digitális sminkkel szépen elfedi, ha pedig a havernak is hasonló a videója, az nem zavar senkit, mert nincs verseny.

Azoknak, akiknek a munkájukhoz kell videó tartalmat készíteni (például egy ingatlan ügynöknek), azoknál szintén előny, ha a minden lakást hasonló módon mutatnak be. Ráadásul nem kell alkalmazni egy embert, aki a 200. videó után elátkozza azt is, aki feltalálta a videókamerát, mert már annyira unja, hogy mindent ugyan úgy kell megcsinálni. Nekik segítség lehet egy ilyen program. Ráadásul ők készítenek annyi videót, hogy megérje előfizetni a szolgáltatásra.

Mert a másik rékfenéje a Magistonak, hogy előfizetéses rendszerben működik. Egy magánembernek szerintem nem éri meg. Hiszen egy évben van egy nyaralás (esetleg kettő, ha télen síelni is elmennek), egy-két születésnap, karácsony, és néhány emlékezetes esemény. A többi időszakban nem csinálnak videókat, de a pénzt akkor is be kell fizetni.

Beszélgettünk is a konditeremben, hogy talán érdemes lenne többünknek összeállni egy előfizetésre, mert külön-külön nem videózunk annyit, hogy megérje előfizetni. Végül nem mentem bele, mert nekem szükségem lenne, hogy letötlhessem a videót, ráadásul én a kreatív alkotás felől közelítem meg a videóvágást, még ha ez nem is látszik meg a végeredményen.

Annyit viszont én is tanultam ettől a mesterséges intelligenciától, hogy nem kell félni egy kis effektezéstől. Ha például van két nagyon hasonló beállítás, akkor egy effekt alkalmazásával el lehet érni, hogy ne tűnjön annyira repetitívnek. Ezt alkalmaztam is a tavalyi Revision-ön, bár így is csak 11. lettem.

Mivel nem sikerült megoldást találnom a GUS kártyás gép problémáira, ezért a munkahelyi nagy szanálás idején mentettem egy Pentium 1-es gépet. Beleraktam a a hangkártyát, a CD olvasót DVD-re cseréltem, és ment minden, mint a karikacsapás. A DVD olvasó is működött, nem fagyott le, mint az előző gépnél. Egyetlen hátránya, hogy soros egérrel üzemel, ezért az USB, PS2 egerek mellett már egy soros egér is van az asztalomon. Ez legyen a legnagyobb probléma.

Megpróbáltam két egérre szűkíteni a beviteli eszközök számát, de nem sikerült. Először egy átalakítóval próbálkoztam, de rá kellett jönnöm, hogy a lézeres egeret átalakítóval sem lehet rácsatlakoztatni a gépre, mert nem ad le elég feszültséget, hogy az elektronika üzemeljen. Mindenképp egy golyós egérre van szükség. Még szerencse, hogy nálam ilyen is van.

A DIN-es átalakító segítségével a PS2-es billentyűzet gond nélkül üzemelt, ezért abból nem kellett egy harmadik az asztalra. Oké, akkor elméletileg meg tudom nézni az összes GUS-os demót. És gyakorlatilag?

Először is le kellene tölteni az összeset. A Pouet.net oldalán ott vannak HTML-be ágyazva az összes információ. Egy közönséges wget-es szkripttel letöltöttem az összes oldalt, amiben felsorolták a GUS tartalmú alkotásokat. Ez könnyű volt, csak egy GET-es paramétert kellett változtatni az URL-ben. Mivel ez csak egy összesítő oldal, szükség van minden egyes alkotás adatlapjára, ahol megvannak a közvetlen linkek. Ebből ki kell nyerni a közvetlen linket, és kész.

Mivel a munkahelyi tapasztalatokból tudom, hogy rengeteg anomália fog fellépni a letöltés során, ezért először csak egy táblázatot készítettem, ahol az alkotás neve, pouet azonosítója és a letöltés linkje szerepel.

Az anomáliák persze jöttek is. Mivel ezek DOS-os programok, a 8+3 fájl név limit miatt több alkotásnak is ugyan az volt a fájlneve. Voltak döglött linkek, ahonnan már semmit nem lehetett letölteni, szerencsére ezekből kevés akadt. Egyes esetekben pedig kézzel kellett finomhangolni a letöltést, mert az elérési út nem teljesen az volt, ami a Pouet.net-en látható.

Végül sikerült! Összesen 1211 produkciót sikerült letölteni. Kényelmesen elfértek egy DVD-n.

Sajnos elsőre rosszul írtam ki, mert a Windows beépített DVD író alkalmazását használtam, ami minden igyekezetem ellenére is UDF-ben írta ki az adatokat. Természetesen pont ez az a formátum, amit FreeDOS alatt nem tudok olvasni. Másodszorra már ISO-ként írtam ki, mire mindent gond nélkül tudtam használni a GUS-os géppel.

Ez a szám elég tekintélyes. Ha csak tízet nézek meg naponta, akkor is négy hónap, mire a végére érek. Kinek van szüksége ezek után Netflixre?

Az ember diploid élőlény, ami azt jelenti, hogy a teljes kromoszóma készletéből kettő van. Egy anyai és egy apai eredetű. Ha csak a legegyszerűbb DNS változásokat, a nukleotid variációkat nézzük, akkor ez azt jelenti, hogy ha megnézzük egy egyén SNP-it, akkor azt jó eséllyel megtalálhatjuk legalább egy szülőben is (feltéve, hogy eltekintünk a szekvenálási hibáktól, spontán mutációktól, nukleotid modifikációktól és még egy csomó olyan dologtól, ami csak azért van, hogy összezavarja az ép ésszel megérthető modelljeinket).

Jogos igény, hogy a vizsgálatok során megtalált mutációkat hozzá tudjuk rendelni vagy az anyai vagy az apai kromoszóma készlethez.

Amennyiben nem használtunk speciális könyvtár előkészítési módszereket, úgy bioinformatikai eszközökkel kell megbírkózni a problémával. Ahogy azt már megszokhattuk, itt jönnek a gondok.

Amikor ugyanis egy biológus haplotípusról beszél, akkor az alatt a klasszikus anyai és apai kromoszóma felosztást érti. Ez pedig alapesetben csak és kizárólag bioinformatikai eszközökkel megállapíthatatlan.

Amit egy bioinformatikus meg tud csinálni, az a variációk haplotípus csoportokba rendezése. Mit jelent ez? Azt nem tudom megmondani, hogy apai vagy anyai eredetű-e egy mutáció, de azt mondhatom, hogy az adott mutáció az előtte-mögötte lévő mutációk közül mennyivel van azonos kromoszómán. Ha pedig véget ér egy haplotípus csoport, és kezdődik egy másik, akkor azt célszerű teljesen független egységnek kezelni.

A VCF fájlban, ha egy mutációról egy program meg tudta állapítani, hogy egy adott haplotípus csoportban van, akkor egy "pipe" jellel választja el a genotípust a perjel helyett. Ezt a VCF fájl 10. oszlopától kezdődően láthatjuk, attól függően, hogy mennyi mintát tartalmaz a fájl.

Miként határozható meg, hogy két mutáció egy haplotípus csoportban van-e? A legegyszerűbb módszer, amit akár mi magunk is elvégezhetünk egy IGV segítségével, ha megnézzük, hogy a két mutáció egy readen van-e. Ez a módszer természetesen csak akkor működik, ha a mutációk távolsága kisebb, mint a read hossza, és a mutációk heterozigóták. (Hiszen a homozigóta mutációk mindkét kromoszómán megvannak.) Ha azt látjuk, hogy az egyik mutáció csak a readek felében fordul elő, míg a másik mutáció a readek másik felében fordul elő, akkor különböző kromoszómán vannak. Ha konzekvensen ugyan azon a readen vannak, akkor egy kromoszómán vannak.

Ennek a módszernek a kiterjesztése, ha egy de-novo összeszerelést végzünk, amivel szinte meghosszabbítjuk a readjeinket. Ezt csinálja a GATK HaplotypeCaller modulja.

A módszer a hosszú readek korában reneszánszát éli. A humán X kromoszóma teljes összeszerelése közben azt vették észre a kutatók, hogy a mostani technológiával mindig találni annyi heterozigóta SNP, indelt vagy struktúrális variációt, hogy akár még a centromereken is átívelő haplotípus csoportokat tudtak felépíteni.

A másik módszer, hogy megszekvenáljuk a szülőket. Ezt csinálja például a Beagle program is, de csak a 3-as verziója. Mivel a variációk nagy részét örököljük, nem nehéz megmondani, hogy mi az eredetük. A problémát itt a spontán mutációk okozzák, amelyek nem találhatóak meg egyik szülőben sem.

További lehetőség, amennyiben rendelkezünk genetikai térképpel, hogy meghatározzuk, milyen messze vagyunk a rekombinációs pontoktól. Minél közelebb vagyunk, annál nagyobb az esélye, hogy a haplotípus csoportunk széléhez tartunk.

Mielőtt tovább mennénk, vizsgáljunk meg még egy lehetőséget. Amennyiben nincs lehetőségünk a szülők szekvenálására, de van egy nagyobb genotípizált populációnk (modell organizmusok előnyben, ugyebár) akkor annak segítségével is megállapítható, hogy hol van nagyobb eséllyel rekombináció. Ez a lehetőség a Beagle 4-es verziójától felfelé érhető el. (Miközben az öröklésen alapuló módszert szépen kivették a program funkciói közül.)

Ami a fenti módszerekben közös, hogy végül egy rejtett Markov lánc segítségével próbálják meg meghatározni a haplotípus csoportok határait. Ezt csinálja a HaplotypeCaller, a Beagle a régi és az új verzióiban egyaránt. Itt emlékezzünk vissza, mit is tapasztaltunk, amikor játszottunk a saját rejtett Markov láncunkkal. Nevezetesen, hogy az állapot változások kezdete és vége nem mindig esik egybe a tényleges rejtett állapotok átmeneteivel.

Ezt akkor vettem észre, amikor egy trio adat elemzése közben fázisolni akartam. Lefuttattam a Beagle 3-t, Beagle 5-öt, miközben a VCF a HaplotypeCallerrel készült. A három eredmény elég eltérő volt ahhoz, hogy elkezdjek a dolgok mélyére ásni. Arról nem is beszélve, hogy a rejtett Markov láncok sztochasztikus modellek, tehát az eredmény futásról futásra változhat. Ezért gondolom, hogy a haplotípus meghatározás egy átverés. Hiszen nem azt mondja meg, amit egy biológus elvár, és azt is rosszul. Nem annyira rosszul, mint egy exom alapú CNV, de elég rosszul, hogy az eredményeket kételkedve fogadjam.

A helyzet a hosszú read szekvenálásokkal javulni fog, sőt, most is vannak olyan könyvtár előkészítési eljárások (például a 10x Chromium), amelyek segítségével pontosabban határozhatjuk meg a haplotípusokat. Ha mégis olcsóbban akarjuk megúszni, akkor a referencia panel alapú megoldást válasszuk, mert jelenleg az a legpontosabb. Ha olyan fajjal dolgozunk, ahol nincs referencia panel, akkor próbáljuk megszekvenálni a szülőket is, de ha ez sem megoldható, akkor ne számítsunk semmi jóra.

- Bocsánat, főfelügyelő úr, de a segítségét kell kérnem - mondta félve a kalaúz, mikor belépett a szűk kis vonatfülkébe.

A férfi letette az újságot, amit éppen olvasott és a kalaúzra pillantott.

- Ennek köze van ahhoz, hogy a vonat nem megy? - kérdezte Poirot.

- Azt hiszem, igen. Tudja, lefagyott a Számítógép, és Ön, mint az összeomlások szaktekintélye, talán tud segíteni.

- Roppant sajnálatos, amit mond, de most épp nyaralok. Ki a területi illetékes?

- Már felvettük a kapcsolatot a hatóságokkal, de amíg ideérnek, kihülhetnek a nyomok. A tetteseknek itt kell lenniük. Mint Ön is tudja, a legközelebbi állomás is több száz kilóméterre van innen. Úgy is mondhatnám a semmi közepén vagyunk.

- Ez esetben a tettes sem tud elmenekülni. Nincs más dolgunk, mint megvárni, hogy a hatóságok ideérjenek - dőlt hátra Poirot.

- Van még egy dolog. Ha megvárjuk, hogy megérkezzenek a nyomozók, az legalább öt óra. Megkezdik a nyomozást, további órák fognak eltelni.

- Értem, de az illetékesek biztosan nem fognak örülni neki, hogy belekontárkodom az ügyükbe. Mint rendőrnek, nekem is kellemetlen, ha mások akarják elvégezni a rám szabott teendőke.

A kalaúz roppant feszélyezetté vált. Szemmel láthatóan gyötrődött, hogyan vegye rá a híres főfelügyelőt, hogy szegje meg a bűnüldözők íratlan szabályát. Poirot látta ezt.

- Talán annyit mégis megtehetek, hogy előkészítem a terepet a kollégáknak.

A kalaúz láthatóan megkönnyebbült. Egy biccentéssel köszönte meg, majd így folytatta:

- Kérem főfelügyelő úr, erre jöjjön. Az utasok már várják.

Egy kis kupéban foglalt helyet a nyolc ember. Poirot alaposan szemügyre vette őket.

- Üdvözlöm Önöket. A nevem Poirot. Egy sajnálatos összeomlás miatt vagyunk itt. Önök mindegyike hardver komponens, akik jelen voltak. A felelős önök között van.

- Tipikus - szólalt meg egy díszes ruhába öltözött hölgy. Lila ruhája és millió fodros kalapja volt. - Amint történik egy összeomlás, azonnal a hardverekre esik a gyanú. Miért nem nézi meg a másik kocsit, ahol a szoftver komponensek vannak? A bárban hallottam, hogy a Windows például hónapok óta nincs frissítve.

- Kit tisztelhetek kegyedben? - kérdezte Poirot.

- Ms. Memória vagyok. Nem kevesebb, mint 32 GB. Négy modulban helyezkedem el és évek óta gond nélkül látom el a feladatomat.

- Igaz, de elég csak egy modul rossz működése és máris kimerevedik a kép. Mivel Ön 32 GB, ami elég nagy, a hiba nem lesz perzisztens, csak ha épp a rossz modul kerül használatba.

Ms. Memória dacosan felhúzta az orrát, és elfordította a fejét.

- A hölgyne ettől függetlenül igaza van. Miért nem az operációs rendszereket kérdezi ki? - vetette közbe egy magas, fehér öltönyös úr. Hanyagul keresztbe tette a lábát és épp kávét szürcsölt.

- Mert több fagyás is történt. Windows és Linux alatt egyaránt. Ez pedig a hardver hibára utal.

Döbbent csend követte a bejelentést. Az emberek zavartan egymásra néztek.

- Bocsátnat, a nevem Tápegység. Nekünk a kalaúz azt mondta, hogy csak egy fagyás történt - mondta egy kopott kabátot viselő úr. Kicsit kilógott az úri társaságból. A többiek látszólag tudomást sem vettek róla.

- Mert a második fagyásról a kalaúz nem tud. Ő csak a Windowst ismeri, ezért a Linux alatti fagyás elkerülte a figyelmét. Észrevettem, amikor bekövetkezett, de nem szóltam, mert nem voltam biztos, hogy Windows alatt is meg fog-e ismétlődni. Ráadásul nyaralok, hivatalosan nem kezdeményezhetek nyomozást.

- Most mégis itt van - jegyezte meg a fehér öltönyös úr.

- Csak addig, amíg a hivatalos szervek meg nem érkeznek. Az érkezésükig órák is eltelhetnek, a vizsgálat lefolytatása szintén hosszadalmas lehet, ha addig közelebb jutunk a megoldáshoz, hamarabb elmehetünk. Közös érdekünk, hogy ne vesztegeljünk itt sokáig.

- Mi történik, ha nem működünk együtt? - kérdezte egy merev tartású, katonai egyenruhát viselő férfi. - Hiszen maga mondta, hogy csak nyaral. Csak annyi joga van, mint bármelyikünknek itt a kocsiban.

- Úgy látom, Ön ezredesi rangban szolgál a seregben.

- Jól látja. Processzor ezredes vagyok, a 8350FX-es zászlóaljban. Nyolc mag tartozik a parancsnokságom alá.

- Az jó sok mag. Elég nagy eséllyel okozhat fagyást.

- Ha tényleg olyan szaktekintély lenne, mint ahogy hírlik Önről, akkor tudná, hogy hibás CPU esetén egyáltalán nem indul el a számítógép.

- És mi a helyzet a túlmelegedéssel? Alaphelyzetben semmi rendellenes nem látszik, de elindul két-három program, és megnövekszik a fogyasztás. Megemelkedik a hőmérséklet, majd minden lefagy.

- Az én parancsnokságom alatt ez elképzelhetetlen. Legfeljebb, ha az a léhűtő Ventillátor nem végzi a dolgát.

Minden szem egy flegma fiatal emberre szegeződött. Drága ruháit lezserül viselte, egyik-másik darab még gyűrött is volt, de Ventillátort ez nem zavarta. Haja is rendezetlen volt.

- Nem értem ezt a felhajtást - mondta egy fintor kíséretében. - A fordulatszámomat, Processzor kapitány...

- ...ezredes... - sziszegte a fogai közül a katona.

- ...bármikor megmondja az Alaplap. Tőle kell kérdezni ezeket.

- Gondolom, Ön lesz Alaplap - fordult Poirot a fehér öltönyös férfihoz, aki meglepetten nézett vissza.

- Honnan...

- Egyszerű. Az Alaplapnak mindenkivel kapcsolatban kell állnia. A testbeszéde elárulta, hogy Ön központi személy ebben a helyzetben.

- No, igen, az én szakmámban a kapcsolat jelent mindent - jegyezte meg nem kis önelégültséggel.

- Egy kapcsolat lehet jó, és rossz is. Nem kerülte el a figyelmem, milyen szemeket mereszt Önre Ms. Memória. Processzor ezredes pedig látszólag ellenséges Önnel.

- Ez egy régi vita közöttünk. Az ezredes felsőbbrendűnek tartja magát, mert minden számítást ő végez. Szerintem pedig fontosabb, hogy minden komponens zökkenőmentesen együttműködjön. Az adatnak el kell jutnia egyik helyről a másikra, nem elég kiszámolni azokat.

Az ezredes horkantott egyet, de nem szólt semmit.

- És mit mond Ön a fordulatszámról?

- Teljesen normális, a beállított értéken pörög.

- Észrevett bármilyen problémát a fagyás előtt? A szenzorai bizonyára érzékeltek valamit.

- Nem - majd kis szünet után hozzátette - De az újraindulás utána feltűnt valami.

- Micsoda?

- Processzor hiba.

Az emberek felhördültek. Az ezredes feje vörösödni kezdett, mint egy kitörni készülő vulkán.

- Az én részegységem minden pillanatban tökéletes munkát végez. Miközben maguk csak henyélnek, én akkor is dolgozom. Én gyűjtöm be az összes információt, és feldolgozom azokat a legjobb tudásom szerint! Míg Ms. Winchestene felpörög, én már milliónyi számítással végzek. Ventillátor mást sem csinál, csak szelet kavar. De ön - remegő ujjával Alaplapta mutatott - ahelyett, hogy eljuttatná az általam kiszámított eredményeket, csak megakasztja az egész folyamatot! Egymás ellen hangolja a részegységeket és meghamisítja a diagnosztikai jeleket.

- Én nem hamisítok meg semmit! - emelte fel a hangját Alaplap is. - Ha a POST alatt bármi történik, akkor jelzem. A fagyás után egyedül Önnel volt probléma.

- Kikérem magamnak! A maga szenzorai hibásak, hibás diagnózist állapított meg.

A kocsiba szó nélkül belépett egy hadiapród és az ezredeshez ment. Átvett tőle egy papírt és távozott.

- Mit adott át neki? - kérdezte Poirot.

- Lehet, hogy Önnek van ideje itt beszélgetni, de a munkának folynia kell tovább. Processzorként vannak bizonyos kötelezettségeim.

- Ahogyan nekem is. Ha megbocsátanak, akkor egy kicsit magukra hagyom önöket - mondta Poirot, majd válaszra sem várva az ajtó felé indult.

- Mégis hova megy? - csattant fel Ms. Memória.

- Megkérdezek valamit a kalaúztól - mondta titokzatosan a felügyelő, majd távozott.

- Most meg itt hagy minket - állapította meg Ms. Memória, inkább csak úgy, magának.

- Nem kell aggódnia drágám, hamar vége lesz ennek - vígasztalta Alaplap.

- Lehet, hogy azért próbálja rám hárítani a felelősséget, hogy leplezze a kisasszony bűnösségét - jegyezte meg Processzor.

Mielőtt bárki válaszolhatott volna, ismét megjelent Poirot.

- Kérem, kérem! Vádaskodással nem megyünk semmire. Azért vagyunk itt, hogy megoldjuk a problémát.

- A felügyelőnek igaza van - mondta Ms. Memória. - Én készen is állok, hogy bebizonyítsam ártatlanságomat. Csak futtatni kell a MemTest86-t, és utána látni fogják, hogy velem nincs semmi probléma.

- Hajlandó alávetni magát a tesztnek? - kérdezte Poirot. - Mint tudja, nem utasíthatom rá. Viszont ha megjönnek rendőrök, ők megtehetik.

- Természetesen alávetem magam. Nincs okom félni a teszttől, ártatlan vagyok.

A teszt nem volt rövid. Többször is meg kellett ismételni, hogy mind a négy modult leellenőrizzék. A végén Poirot szomorúan közölte:

- Önnek két memóriamodulja is hibás.

A hölgy nem szólt semmit. Méltósággal hallgatta, majd a szemében könnyek kezdtek gyűlni.

- Egészen biztos benne?

- Sajnos igen. Az random írás-olvasás teszt rendszeresen hibás értéket adott vissza. Többször is ellenőriztem.

- Akkor végig én voltam a hibás? Ez olyan hihetetlen. Amikor az ember összeomlást lát, mindig azt hiszi, az csak valaki más hibájából történhet. Soha nem gondoltam volna, hogy...

Befejezni már nem tudta. Hirtelen kialudtak a fények. Az utasok összerezzentek.

- Mi történt? - kérdezte pánikkal a hangjában Tápegység.

- Egy újabb fagyás, az történt - jegyezte meg csendben Poirot.

- Szóval Memória kisasszony újabb hibát produkált - jegyezte meg Processzor nem kis gúnnyal a hangjában.

- Nem. Ezuttal nem. A hibás modulokat eltávolítottuk a teszt végeztével. Memória kiasasszony már csak a jó modulokkal üzemel.

- Vagyis? - kérdezte Alaplap.

- Van még egy tettesünk. Mr. Alaplap, most mit mutat a POST teszt?

- Processzor hibát.

- Hogy nem sül le a képe még mindig engem pocskondiázni!

- Maga csak ne beszéljen. Folyton másra akarja kenni a problémát, holott már korábban is mondtam, hogy a maga tesztje nem sikerült. Minden részegység mellett van egy kis LED, és folyton maga melletti gyullad ki. Ezt mivel magyarázza?

Processzor ezredes nem válaszolt azonnal. Száját ragadozó mosolyra húzta.

- Maga azt sem vette észre, hogy Ms. Memóriával gondok vannak. Lehet, hogy Ms. Memória tényleg ártatlan, és az Ön foglalatai kontaktosak. Azt jelzi, hogy hiba van itt is, ott is. De valójában csak egyetlen hiba van - az ezredes közelebb lépett. - Maga.

- Nem - csak ennyit tudott mondani Alaplap, és hátrálni kezdett.

- De igen. Mondja csak meg neki, felügyelő úr. Egy kis áram ingadozás, korrodáció az érintkezőknél. De elég egy kis hibás kondenzátor, felpúposodott tetővel, és máris kész a baj.

- De..de...

- Az ezredesnek igaza lehet, de áram ingadozást más egységek is okozhatnak. Olyan egységek, amelyek egyébként is sok áramot vesznek fel - ezzel Poirot egy ikerpár felé fordult, akik eddig csendesen figyeltek. - Ha nem tévedek, a híres GPU ikrekhez van szerencsém.

- Igen - felelte a jobb oldali testvér. - SLI-be kötve - fejezte be a bal oldali.

- A teljes rendszer áramfelvételének a 2/3-a maguknak kell.

- A nagy teljesítményhez - kezdte a jobb oldali. - Nagy áram kell - mondta a bal oldali.

- A hőtermelésről nem is beszélve.

Az ikrek bólintottak. Lassú mozdulattal, akár csak a szinkron úszók.

- Úgy gondolja felügyelő úr, hogy az ikrek miatt megzavarodtak a szenzoraim? - kérdezte Alaplap.

- Csak arra akartam utalni, hogy a feszültség fontos tényező. Amíg kevés kell, addig észre sem vesszük, de ha megnövekedik a részegységek igénye, akkor akinek nem jut elég áram, nem működik megfelelően.

- Szerintem pedig az ezredes a ludas - mondta Alaplap, hogy visszaszerezzen némi önbecsülést, amiért allul maradt az előző szópárbajban.

- Figyelmeztetem, hogy... - kezdte vörösödő fejjel az ezredes.

- Az ezredes teljesen ártatlan - vágott közbe Poirot.

- Miből olyan biztos benne? - kérdezte Ms. Memória.

- Mert az ezredes parancsai nem jutottak ki ebből a szóbából. Mikor kimentem az apród távozása után, akkor azért mentem ki, hogy elintézzem, hogy a parancsai ne jussanak tovább. Egy másik katonatiszt látta el az ön feladatait ez idő alatt.

- Hogy mert engem lecserélni!? Ehhez nem volt joga.

- Ez igaz. Viszont szükséges lépés volt, hogy kiderüljön, Ön áll-e a hibák hátterében.

Alaplap láthatóan összetört a hallottak alapján.

- Akkor mégis csak én vagyok a hibás - mondta, majd egy fotelba huppant. Ms. Memória együttérzően mellé ült, és megsimogatta a kézfejét. - Az lenne a feladatom, hogy összehangoljak mindent, de képtelen vagyok rá. Ezek alapján csak is én lehetek, aki nem megfelelően működik.

- Kicsit túl szigorú magához - mondta Poirot. - Maga csak látott egy anomáliát, de nem látta az igazi okot.

- Ezt hogy érti?

- Amikor érzékelte, hogy Processzor felől nem jön információ, akkor azt hitte azért, mert Processzor működésében van valami probléma. De azért nem jött információ, mert nem jöhetett. Processzor ezredes ugyanis nem kapott áramot.

- Ezt nem értem. Összeomlás csak ritkán fordult elő. Az esetek nagy részében minden zökkenőmentesen működött. Hogyan lehetséges, hogy egyszer kap áramot, egyszer meg nem? Ennek semmi értelme.

- Igen, magam is szívesen venném, ha felvilágosítana - jegyezte meg az ezredes.

- Azonnal. Az áram ellátás ugyebár úgy néz ki, hogy megy egy 24 tűs ATX csatlakozó Alaplaphoz - a férfi bólintott. Van egy másik, illetve jelen konfigurációban két másik ár a GPU ikrekhez.

- Igen, igen, tudjuk mind. Kapnak Winchesterék, GPU, Alaplap. Minden részegység árammal megy, ezért van rajtuk csatlakozó. Legyen szíves a lényegre térni!

- A lényeg, hogy van még egy 12 Voltos csatlakozó, ami közvetlenül Önnek jár, bár Alaplap kapja. Ha ez az ág nem szállít elég áramot, akkor Alaplap úgy érzékeli, hogy Ön nem működik. Általában nincs is gond, de ha megnő a számítógép áramfogyasztása, akkor jelen esetben ez az ág nem ad le elég áramot. Tehát a tettes Tápegység!

Az említett férfi szeme elkerekedett. Hirtelen felugrott, és az ajtó felé kezdett futni. Az ezredes, azonnal utána vetette magát. Ms. Memória felsikoltott. Tápegység feltépte az ajtót, de visszahőkölt. A rendőrség emberei már ott voltak. Éppen be akartak kopogni. Tápegység kikapta az egyik rendőr övéből a pisztolyt.

- Álljanak meg. Maguk ketten - fordult az újonan jött rendőrök felé -  jöjjenek be, és álljanak a többiek mellé. Gratulálok felügyelő úr. Kicsit alábecsültem magát. Utoljára fogom megölni, hogy kifejezzem elismerésem.

- Maga álnok, képmutató disznó! - kiáltotta Processzor. - Tegye le azt a fegyvert, nem méltó rá, hogy viselje.

- Nem vagyok rá méltó? Mégis, hogy mondhat ilyet? Mindenki az én áramomat fogyasztja, mégis folyton panaszkodnak: "Nem lehetne még egy +12V csak nekem?" "Közös ágon vagyok a DVD olvasóval, ezt nem tűröm." Mégis lenéznek, tudomást sem vesznek rólam. Elegem van, hogy nem tekintenek igazi számítógép komponensnek. Processzor ezredes a megaherzekkel büszkélkedik. Alaplap az USB csatlakozók számával henceg. Fogadjunk, még a teljesítményemet sem ismerik. Ha pedig felmelegszem, annyi áramot adok másoknak, akkor meg a hűtőm zajával van bajuk.

- Ezért tette? Szeretne több figyelmet?

- Nem. Emlékeznek a tavalyi nagy túlmelegedésre? Amikor a hűtőpaszta annyira megszáradt, a házban 70 fok fölé ment a hőmérséklet.

Többen bólogattak.

- Akkor történt. Az egyik csatlakozóm pontosan Processzor fölött volt. Az összes meleg levegő ott keringett és megolvadt a csatlakozó műanyag vége. Azóta nem működök rendesen. Nem mertem szólni. Féltem, és összezavarodtam.

- Mutassa a sérült csatlakozót, kérem - mondta Poirot.

- Annyira sajnálom - mondta összetörten Tápegység. - Annyira sajnálom.

Leengedte a fegyvert, és hagyta, hogy a rendőrök elvezessék.

A rejtett Markov láncok nagyon hasonlóak a korábban bemutatott Markov láncokhoz, de van bennük egy csavar. Minden állapot bizonyos valószínűséggel emittál egy másik állapotot, amit látunk. Ezért az eredeti állapotot mi nem látjuk, tőlünk rejtve van, ezért hívják rejtett Markov láncoknak.

Például, ha azt vesszük, hogy egy (nagyon is leegyszerűsített) genomon egymást követik a fehérje kódoló, és nem kódoló szakaszok, akkor ez lehet egy rejtett állapot. Ezt mi nem látjuk (legalábbis a modell szerint, kísérleteket természetesen tervezhetünk a kimutatására). Amit látunk, az a DNS bázissorrend. Ha hétköznapi módon akarnék fogalmazni, a rejtett Markov lánc a közvetett bizonyítékok vizsgálatán alapul.

Gyakorati szempontból három algoritmust szoktak tárgyalni, ami a rejtett Markov láncok három alkalmazási módjával áll kapcsolatban. A Forward-Backward algoritmus, a Viterbi algoritmus és a Baum-Welch algoritmus.

Az első segítségével a modell paramétereit és megfigyelt állapotok kapcsolatát lehet számszerűsíteni, magyarul, mennyire jó a modellünk a megfigyelt adatokra. A Baum-Welch a látható állapotok alapján a modellünk paramétereit határozza meg.

A bioinformatikában általában a Viterbi algoritmust használják, mert ez mondja meg, hogy mi a legvalószínűbb rejtett állapot, ha ismerjük az emittált állapotokat. A példánknál maradva, hol vannak a kódoló/nem kódoló szakaszok, ha ismerjük a DNS bázissorrendjét.

A rejtett Markov láncokról rengeteget lehet olvasni a Wikipédián, én nem is akarom újra leírni azt. Amit viszont fontos megismerni, hogy mi a módszer gyengesége, mert a későbbi posztokban utalni fogok rá.

Ezért írtam egy kis programot, ami nem csinál mást, mint generál egy Markov láncot, és abból emittál bizonyos valószínűséggel egy másik állapotot. Ez most az időjárásos példa a Wikipédiából. Utána egy Viterbi algoritmussal visszafejti azt. Tehát egyszerre látjuk, miből indultunk ki, és mi lett a keresés eredménye.

Nyugodtam írjuk át a programban a valószínűségi értékeket, hogy lássuk, milyen hatással van az eredményekre. (Ha telepítve van a Go fordító, akkor a go build hmm.go paranccsal fordíthatjuk.)

Ha megnézünk egy tipikus kimenetet, akkor nem sok eltérést fogunk látni. Olyan esetekben lesz eltérés például, ha napos idő esetén is takarítanak. Mivel napos időben csak 0,1 a valószínűsége, hogy valaki takarít, ezért a Viterbi inkább az esős idő felé hajlik ilyen esetekben. Ez nem is meglepő, hiszen ez a legvalószínűbb állapot.

A másik fontos észrevétel, hogy az állapot átmeneteknél egyfajta "késés" van a valódi és a Viterbi által visszafejtett állapotok között. Igazából, ez sem meglepő, ha belegondolunk. Napos idő után nagy valószínűséggel megint napos lesz, esős után esős. Ha történik egy átmenet naposból esősbe (vagy vissza), akkor az algoritmus, ami csak az emittált állapotok alapján dolgozik, pár lépéssel később végzi el a váltást. (Persze ez is a valószínűségektől függ. Ha minden rejtett állapot csak egyfélét emittál, akkor ez a késés nem jelentkezik.)

És mi a helyzet a HMM profilokkal?

A bioinformatikában a rejtett Markov láncok alkalmazásának másik nagy területe a különböző profilok létrehozása, elsősorban fehérje alapon. Itt szó szerint rejtett állapotok vannak. Mit értek ez alatt? Az időjárásos példánál a rejtett állapot egy valódi entitás volt (maga az időjárás), csak nem szerezhettünk róla információt. A fehérje profiloknál viszont a rejtett állapot egy meg nem fogható jellemzője a fehérjének. Csupán egy absztakció, még akkor is, ha szoros kapcsolatban van az aminosav fehérjében betöltött pozíciójával. Amit mi látunk, tehát az emittált állapot, maga a fehérje aminosav sorrendje.

Most jön a trükk. Hogyan lesz ebből a megfoghatatlan valamiből profil? Hiszen nekünk ismernünk kell az emittált valószínűségeket. Úgy, hogy fogunk sok - valamilyen tulajdonság alapján hasonló - fehérjét és végzünk egy többszörös illesztést. Ha egy pozícóban csak glicin van, akkor az a rejtett állapot 100%-ban glicint emittál. Egy másik pozícióban azt látjuk, hogy néha alanin, néha fenilalanin van, akkor a modellben annak megfelelően állítjuk be a valószínűségeket, hogy a többszörö illesztésben hányszor fordul elő az adott aminosav.

Még a deléciók és inszerciók sem jelentenek problémát, hiszen azokat is felvehetjük rejtett állapotnak. Az inszerciók szintén emittálnak aminosavat, de a deléciók nem fognak semmit emittálni, a szerepük, hogy át tudjunk ugrani a következő állapotba.

Leegyszerűsítve, a többszörös illesztés oszlopai a rejtett állapotok, a sorok pedig az emittált állapotok. Itt az állapot átmeneteknek kisebb szerep jut. Képzeljünk el egy olyan többszörös illesztést, ahol nincsenek inszerciók, sem deléciók. Minden állapot 100%-ban átmegy a következő aminosavat emittáló állapotba. A profilban az igazi információt az emittálási valószínűségek fogják adni, mert abból derül ki, milyen aminosavat tartalmazhatnak az egyes pozíciók.

Talán ebből is látszik, hogy a rejtett Markov láncok rendkívül rugalmasan alkalmazhatóak. Nem véletlen, hogy szinte minden programozási nyelvhez adtak ki modulokat, amelyek segítségével rejtett Markoc láncokat kezelhetünk. Python alatt a hmmlearn csomagot érdemes használni, mert az közeli kapcsolatban van a sci-kit learn csomaggal. R alatt több lehetőségünk is van, az rHMM, a HMM és a depmixS4.

Habár előszeretettel hivatkoznak a DNS láncra, mint egy hosszú szalagra, ahol csak a nukleotidok sorrendje az egyedüli fontos ismertetőjegy, a valóságban a DNS egy komplex struktúra, ahol külön logisztikát igényel a sejttől, hogy ezt az információt valahogy tárolja.

A DNS ezért nem egy összekuszált fonalgombolyagra hasonlít, amivel három macska játszott, hanem egy kazettákban használt hang szalagra. Ezt kromatinnak hívják. Az előbbi analógia természetesen sántít, mert ha szükségünk van egy dalra, ami a szalag közepén van, folyton tekergetni kell a magnót, hogy mindig azt a részét halgathassuk, amelyiket akarjuk. Ezt az időveszteséget a sejt nem engedheti meg magának, neki úgy kell feltekernie a DNS-t, hogy közben elérhesse azokat a géneket, amelyekre szüksége van. Ezért a kromatin állapot folyton változik a sejt aktuális szükségleteinek megfelelően.

A kromatin még ennél is többet tud! A DNS különböző pontjain fellelhető információnak néha egy helyen és egy időben kell jelen lennie. Mintha a korábban említett kazettán a dalok hangszerei külön lennének felvéve, de lejátszásnál mégis egyszerre hallatszana minden. Ezért a génkifejeződés közben bonyolult térbeli struktúrák jönnek létre, amikor távoli DNS részek közel kerülnek egymáshoz. A Hi-C szekvenálás pontosan ezen struktúrák elemzésére szolgál.

A segítségével megállapítható, hogy egy adott gént milyen távoli enhanszerek szabályoznak. De előszeretettel használják kromoszóma összeépítésre is, mivel ezek a struktúrák általában egy kromoszómán belül jönnek létre és a távolságuk sokkal nagyobb is lehet, mint bármelyik harmadik generációs szekvenálás read hossza.

Először is kovalensen kötik a feltekeredett DNS darabok egymáshoz közeli részeit, ami olyan, mintha pillanatragasztóval fixálnák ezeket a kötéseket. Ezután egy restrikciós enzimmel levágják a hosszú DNS darabokat, amelyek ezekről a fixált részekről lelógnak. Az eredmény tehát egy nagy csomó lesz, amiről rövid DNS láncok lógnak le. Ezeket a szabad láncvégeket összekötik, majd a szekvenálják.

A bioinformatikai elemzés ebből a sajátos laboratóriumi előkészítésből adódóan nagyon eltér a többi második generációs szekvencia elemzésektől. Először is, a read párok távolsága nem követ normál eloszlást, emiatt nem is együtt illesztik őket, hanem mintha külön szekvenciák lennének. Másodsorban a genom adott pontján található read mélységnek nincs információ tartalma. Két genomi pozíció összekötésénél nem az számít, hogy hány read esik egy pontra, hanem hány ilyen pont van, ami megerősíti, hogy kapcsolat van két pozíció között.

Rengeteg program van, amivel feldolgozhatjuk adatainkat, én csak egyet mutatok be, ez pedig a Juicer. Azért ezt, mert erre a protokollra építkezve nem csak a szabályozó kapcsolatokat lehet elemezni, hanem egy genom-összeszerelő módszer is épül rá. Így egy eljárással két bioinformatikai módszert is ismertethetek.

A Juicer nem millió parancssori paraméterrel működik, hanem egy rögzített könyvtár struktúrával dolgozik. Ebbe a könyvátrba helyezzük a references alkönyvtárat a referencia genomokkal, a fastq-t értelem szerűen a fastq fájlokkal. Végezetül a scripts könyvtárba kell helyeznünk azokat a Juicer szkripteket, amelyekkel dolgozni akarunk. Ugyanis a fejlesztők minden platformhoz készítettek egy szkript halmazt, amit különböző alkönyvtárakba helyeztek el (nézzük csak meg a Github repójukat). Például ha csak egy gépen akarunk futtatni, akkor a CPU alkönyvtár szkriptjeit helyezzük el itt. (Vagy csak egy linket helyezünk el). Ez nem egy professzionális megoldás, főleg, ha azt nézzük, hogy már létezik Snakemake. Vitathatatlanul ez az egyik gyengesége a programnak.

Első lépésként a BWA-val indexelni kell a referencia szekvenciát. Ezt nem írom le, gondolom a könyökén jön ki mindenkinek, aki szekvencia feldolgozással foglalkozik.

Ha ezekkel megvagyunk, el kell készítenünk a restrikciós helyek térképét, amihez a Juicer misc alkönyvtárában találhatunk egy szkriptet.

python generate_site_positions.py enzimname reference.fa restrictionfile

Sajnos az enzim nevek a programba vannak égetve. Van HindIII, DpnII, MboI, Sau3AI, Arima. A referenciából kell még készítenünk egy kromoszóma méret táblázatot is, amit a samtools-al készíthetünk el, de csak az első két oszlopra van szükségünk.

samtools faidx reference.fa
cut -f 1,2 reference.fa.fai >reference.chrom.sizes

Ha mindezekkel megvagyunk, indíthatjuk a programot:

scripts/juicer.sh -D workdir -z reference.fa -y restrictionfile -p reference.chrom.sizes

Eredményül fogunk kapni egy .hic kiterjesztésű állományt. Minden további munka, ezzel a fájllal megy.

Rövid vizuális áttekintésre használhatjuk a Juicebox alkalmazást. Javaban írták, és hála a hic tömörített formátumának, akár egy erősebb laptopon is elfut, bár ne reméljünk eget rengető sebességet.

A Juicer egyik kimenetét használhatjuk genom összeszereléshez is, ha referenciának használjuk a scaffoldokat. Ehhez egy másik programra lesz szükségünk, a 3d-dna-ra. Telepíteni nem kell, csak ki kell bontani. A fent említett könyvtár struktúrában a Juicer hatására létrejön egy aligned könyvtár, amiben van egy merged_nodups.txt fájl. Gyakorlatilag erre és a scaffold fájlra van szükségünk. A program támogatja a diploid genom összeszerelést is.

./run-asm-pipeline.sh -m diploid reference.fa workdir/aligned/merged_nodups.txt

Az eredmény a reference.FINAL.fasta lesz.

Természetesen ritka, hogy egy kísérlet hibamentesen fusson. (Ha mégis így van, utóbb kiderül róla, hogy felesleges volt elvégezni.) Szükség van rá, hogy megtudjuk, melyik lépésnél keletkezett a hiba.

Ha az emésztés valamilyen okból nem volt sikeres, akkor azt látjuk, hogy a read párok elhelyezkedése közeli. Közeli alatt azt értem, hogy olyan, mintha egy közönséges DNS illesztés lenne, tehát a fragment távolságok normál eloszlást fognak mutatni.

Ha az emésztés sikerült, de a ligálásnál történt valami malőr, akkor az intrakromoszómális és interkromoszómális fragmentek aránya kisebb lesz. (Az érték egyébként humán vonatkozásban 80 szokott lenni.) Ezt az értéket a Juicer ki is számolja nekünk.

Ha megnézünk egy tipikus Hi-C ábrát, azt látjuk, hogy a főátlóban helyezkedik el a legtöbb fragment, a TAD-ok közelében. Amennyiben nem ilyen az ábra, kezdhetünk gyanakodni, hogy valami gubanc történt.

Felhasznált irodalom:

Bryan R. Lajoie, Job Dekker, Noam Kaplan: The Hitchhiker’s guide to Hi-C analysis: Practical guidelines