Az élet kódjai

Az Experience mindig is egy laza levezetés szokott lenni a partik sorában. Mivel idén nem remekelt a scene, a levezetés is ehhez hasonlatos volt. Csak a legelvakultabbak vették a fáradságot, hogy valamit beadjanak, ezért inkább egyéni, mint csapatversenyt láttunk. Talán ezért is voltak az intrók felülreprezentálva.

Kezdjük mindjárt az első helyezettel, az Ugyanaz mindennel. Számomra nem volt tiszta, hogy mi az, amit ugyanaz. Talán az effektek, amelyeket láttunk már néhány Fresh!Mindworkz produkcióban? Ki tudja? Klasszikus demó annak minden előnyével és hátrányával.

A második Trixy volt, egy 256 byte intró Abaddontól. Ez egy nagyon kedves intró, jó ötlettel, kiváló kóddal. Ez egy igen stílusos búcsúzás az évtől, mert nem túl bonyolult, mégis magával ragadó.

Tifeco ismét egy Demojoe intróval örvendeztette meg a nézőket. Mivel a sztoris alkotásokat előnybe részesítem, ezért majdnem ezt tettem volna meg győztesnek. Az egyetlen hibája talán a nosztalgikus húrok megpedndítése, mert ettől számomra hatásvadásznak tűnik. A scenerek ilyen szempontból olyanok, mint az Oscar-bizottság, akik imádják a filmekről szóló filmeket. Az intró kulisszatitkairól egyébként nemrég irás is megjelent.

Az utolsó helyezett új értelmet ad a "valós idejű animációkan". Egy naplementét láthatunk nagyjából olyan lassan, mintha tényleg a Föld forgását szimulálná. Az egyetlen mentsége, hogy 256 byte intró. A streamen Charlie azt mondta, hogy szerinte remekül összegez mindent 2020 demóiról. Kicsit borulátó megállapítás, de nehéz belekötni.

Nemrég volt egy elég sajnálatos incidens, aminek következtében gyakorlatilag egy hátsó ajtót találtunk a tárhelyünkön.

Az egyik számítógépünkhöz egy külső tárhely van csatlakoztatva. Elsőre elég jó cuccnak tűnt, weben keresztül lehet konfigurálni még a raid blokkokat is. Újraindítás nélkül rendezhetjük csoportokba a vinyókat, sőt, még a hardver hibákat helyét is megmutatja egy képen. Tényleg szuper.

Össze volt kötve a számítógéppel, amin dolgozunk, ezen kívül egy másik számítógéppel, hogy azon keresztül adminisztráljuk, és az internettel, hogy adatokat osszunk meg a kooperációs partnerekkel, ha éppen arra van szükségünk. Én mindig a neten keresztül adminisztráltam, a másik számítógéppel nem sokat foglalkoztam. Az idők során meg is feledkeztem róla.

Egyik nap a főnököm felhívott, hogy "támadják a NAS-t". Minden munkát eldobtam, azonnal beléptem az admin felületre és próbáltam kitalálni, mit tegyek, hogy visszaverjem a támadást. Ilyen szempontból elég kevés eszköz volt, például azt sem láttam, ki kapcsolódik a szerverez. Mivel statikus IP címe volt a tárhelynek, a nagy agyammal kitaláltam, hogy dinamikus IP-t adok neki, mert akkor nem fogják tudni, hol van, ergo nem fogják "támadni".

Be is állítottam. Egy kis számláló mutatta, hol áll a konfigurálás, én meg közben azon gondolkodtam, ha a tárhely dinamikus címet kap, hogyan fogok belépni az admin felületre? Amint rájöttem, hogy hülyeséget csináltam, a képernyő villant egyet, ahogy a böngésző frissítette az oldalt, és a tárhely webes admin felülete eltűnt. De legalább nem támadják - gondoltam.

Utána jött a hír, hogy igazából nem támadta senki a gépet, csupán az rendszeresen felkeresett egy gyanús IP címet, ami a rendszergazdák szerint egy ismert malware update cím. Tehát valaki belépett a tárhely operendszerére és ott futtatott valamit, amit nem kellett volna. Tehát az akciómnak semmi értelme nem volt, mert továbbra is fut rajta a malware. Oké, már csak meg kellene találnom a gépet, mert fene tudja milyen címen van.

Jobb híján az nmap-el fésültem át tartományokat, olyan gépre vadászva, aminek a 8816-os portján egy webszerver üzemel. Aztán eszembe jutott, hogy egy másik gépbe is bekötötték a tárhely egy portját, ráadásul közvetlenül, így teljesen mindegy milyen dinamikus IP-t kapott, a fenti gépen keresztül is el tudom érni.

Elértem, visszaállítottam az eredeti konfigurációt. Szuper, az első ellenséggel, önmagammal leszámoltam. Visszaállítottam a statikus IP címet, kikapcsoltam minden felesleges szolgáltatást, de a tárhely CPU használata szükségtelenül magas volt. A rendszergazdák megerősítették, hogy a gyanús IP-t továbbra is felkeresi. A malware tehát még mindig futott.

Kicsit körbeszaglásztam én is a NAS-t, és láttam, hogy a 22-es port nyitva van. Belépni viszont nem tudtam egyetlen általam ismert jelszóval sem. Arra gondoltam, biztos az SFTP miatt van nyitva. Hiába állítottam le azonban az SFTP szolgáltatást, a 22-es port továbbra is nyitva volt.

Végül nem tudtam mást tenni, mint a gyártó honlapjáról leszedtem az összes elérhető dokumentációt (az egyik 500 oldalas volt), majd frissítettem a firmware-t. A firmware egy 1.7GB-os fájl volt, érzésem szerint a NAS teljes operációs rendszere egy képfájlban, de a formátumára nem jöttem rá.

A firmware frissítés megoldotta a problémát. A CPU használat visszaesett egy 0 közeli értékre, de az SSH port problémáját nem oldotta meg. Márpedig jó eséllyel ott jöttek be a támadók, ezért szerettem volna lezárni.

Közben, csak kíváncsiságból csináltam egy tracerout-ot a kérdéses IP címre az egyik szerverünkről, mire fél órán belül mindenki tiszta ideg lett, mert azt hitték, hogy az a gép is megfertőződött a malware-el. Ahogy Dumbledore is megmondta:

Eltelt pár nap, és én azt hittem, a problémán túl vagyunk, mert a NAS más nem kereste fel a gyanús IP-t, de a rendszergazdák ismét felvették velem a kapcsolatot, mert biztosak akartak lenni, hogy minden rendben van a tárhellyel, és ez az eset nem fog megismétlődni. Igen, kérem, ilyen is van, hogy komolyan veszik a biztonságot. Ők is átnézték a NAS-t, de csak annyit javasoltak, hogy változtassam meg az admin jelszót egy hosszabbra, amit meg is tettem.

Igen ám, de ők is kiszúrták a nyitott 22-es portot. Szerették volna, ha bezárom. Mondtam, hogy nem tudom bezárni, mert az admin felületen nincs rá mód, a jelszót meg nem tudom, hogy parancssorral belépjek és ott oldjam meg a problémát. Átnéztem újra minden dokumentációt, de egy árva szó sem volt ssh-ról benne. Kipróbáltam az általam ismert jelszavakat, de egyikkel sem engedett be.

Kis idő múlva felhívtak, hogy be lehet ssh-zni rootként, ha az 111111 jelszót használják. Hoppá! Kipróbáltam, de szerencsére nem volt ennyire rossz a helyzet, bár már ettől is kirázott a hideg. A jelszó megadása után ugyanis kaptunk egy random 6 karaktert (minden bejelentkezésnél mást), majd egy újabb jelszót kért. Szerintem valami egyszer használatos jelszó mechanizmus lehet.

Ismét átnéztem a dokumentációkat, az internetet, de semmit nem találtam erre vonatkozóan. Végül írtam a NAS gyártójának, hogy ez elég gáz, meg kellene oldani ezt a problémát. Azt válaszolták, hogy ezt az ő R&D csapatuk használja, és nem kell aggódni miatta.

Végül is miért kellene aggódnom? Van egy hátsó ajtó a NAS szerverünkön, amit tud használni a gyártó, tudnak használni fekete kalapos hekkerek, de mi, az üzemeltetők nem. Mintha vennénk egy autót, aminek a csomagtartójába a gyár munkatársai időnként bemásznának, hogy ott kutatás-fejlesztést végezzenek.

Végül leszedtük az internetről a NAS-t. Mostantól nem lesz "cloud" opció, nem lesz adat megosztás kooperációs partnerekkel, de nem lesz titkos nyulka-piszka sem a gyártó R&D csapatától.

Ahogy a konferenciák legtöbbje, úgy a Magyar Bioinformatikai Társaság éves konferenciája is on-line került megrendezésre. Ennek egyik vitathatatlan előnye volt, hogy több külföldön dolgozó magyar kutató is beszélhetett munkájáról. Hátránya pedig (az ingyen kaja hiányán kívül) az informális beszélgetések nélkülözése volt. Nézzük is át, manapság az egyes kutatócsoportokat milyen kihívások foglalkoztatják. A konferencia anyaga itt található.

Korcsmáros Tamás: Hogyan hat a sejtjeinkre a SARS-CoV-2 fertőzés? Hálózatbiológiai vizsgálatok és lehetőségek

A SARS-CoV-2 vírus a fertőzés során egy úgynevezett citokin-vihart okoz, amelynek pontos megértéséhez a jelátviteli mechanizmusok feltérképezése szükséges. A csoport ezen a téren már elég tapasztalatot gyűjtött össze, ezért ezen az úton indultak el. A ViralLink segítségével elemezhető, hogyan hat a vírus mRNS a gazdasejtre. A program számára létfontosságú adatokat az irodalomból szedték össze. Egy másik program, a CytokineLink a sejtek közötti citkokin alapú kommunikációt vette górcső alá. Itt a protein atlaszból megállapították mely sejtek melyik citokin molekulát expresszálják, majd meghatározták a target sejtet az alapján, hogy milyen receptor van a felszínükön. Ezeket az adatokat felhasználva metahálózatokat hoztak létre, ahol szövet-szövet és citokin-citokin kapcsolatok szerepelnek. Az előadás végén a bélrendszeren keresztüli fertőzésről volt szó, ami a vizsgálatok alapján súlyosabb kórlefolyást eredményez.

Manczinger Máté: A kevesebb néha több, avagy miért hátrányosak a generalista HLA molekulák a tumorellenes immunválaszban?

Az adaptív immunválasz során a HLA antigének peptidkötő képessége széles skálán mozog. Amennyiben többféle antigént is képes bemutatni a T-sejtnek, az előnyös egy vírusfertőzés során, mert nagyobb védettséget ad az egyénnek. De mi a helyzet a tumorok esetén? A csoport eredményei szerint a promiszkuózus antigén prezentáló sejt rosszabb immunválaszt vált ki, mert kevés a különbség az egészséges sejtekhez képest. Végeztek RNS szekvenálást is, ahol az alacsony és magas promiszkuitású mintákat hasonlítottak össze. Az eredményül kapott gének GO elemzése T-sejt szabályozással összefüggő géneket írt le.

Makai Szabolcs: Hi-C adatok felhasználásának lehetőségei a genom térbeli szerkezetének leírására az árpa példáján keresztül

A Hi-C adatok a genom különböző pontjai között található kapcsolatokat tárják fel. Gráfelméleti módszerekkel ezek a kapcsolatok vizsgálhatóak. Egy egyszerű, a rugó viselkedésének leírására használt fizikai modellel a kromatin kompartmentek is jellemezhetőek. Az interkromoszómális kapcsolatok modellezésével viszont egy lineáris struktúrát kaptak, amiről az előadónak egy ingasor jutott az eszébe, és ez alapján úgy véli, a működése is hasonló lehet.

Nagy Gergely: A makrofágokat meghatározó transzkripciós faktorok együttműködésének vizsgálata

Nagy mennyiségű chip-seq adatatot elemeztek, és cisztrómokat együttállását vizsgáltak makrofágokban. Sok eredményük már jól ismert irodalmi adatot adott vissza, de az NFE2L2 a MAF-okon kívül más fehérjékkel is tud heterodimert alkotni és cAMP válaszadó elemeket is megköthetnek.

Dankó Benedek: Abnormális transzkripciós mintázatok vizsgálata nagy mennyiségű RNS-szekvenálási adat segítségével mielodiszplasztikus szindrómában

A mielodiszplasztikus szindróma kialakulásában splicing faktor mutációk játszanak szerepet, ezért RNA-seq adatokból olyan splice variánsokat kerestek, amelyek eltérnek a normál szövetektől. Callistot és Salmont használtak az abundancia meghatározására és Iso-kTSP-el nézték az alternatív splice variánsokat. Az előadás fő üzenete az volt, hogy az alkalmazott programok használatától függően eltérő eredményeket kaphatunk.

Kálmán Zsófia: Betegséget okozó mutációk hatásának vizsgálata a coiled-coil szerkezetekre

A coiled-coil moduláris távtartók, állvány fehérjék. A vizsgálatok során az Uniprotból leszedték a fehérje szekvenciákat, a Humsavarból pedig a betegségeket okozó mutációkat. A coiled-coil mutációk többségében idegrendszeri betegségekben fordulnak elő, valamint az erre a régióra eső mutációk kisebb mértékben destabilizáló hatásúak. Ha mégis destabilizáló a hatás, akkor a mutáció a hidrofób magot érinti. Ezen kívül az N terminális régióban található mutációknak kiemelt szerepe van.

Olar Alex: Rheumatoid arthritis betegség automatikus, ízület alapú pontozása röntgen felvételek alapján

A kutatás témája egy Dream challenge-ből indult ki. Az izületi elváltozásokat egy pontozó rendszerrel jellemzik az orvosok, de mivel a kéz minden egyes izületére meg kellene határozni, a gyakorlatban csak nagyon ritkán használják. A versenyben pont az volt a cél, hogy egy algoritmusnak megtanítsák ezt. Először egy neurális hálót használtak az izületek röntgen felvételeken történő azonosítására, majd 12 másikat a predikcióra. A 12 eredményt pedig egy random forest klasszifikációval fűzték egybe.

Radványi Ádám: A standard genetikai kód és kodonmintázatok viszonyának elemzése környezeti adatok fényében: mezofil optimalitás és mutációs trendek

Miért csak egyféle genetikai kód van? A kérdés azért is fontos, mert rajta keresztül az élet eredetére is keressük a válaszokat. Az eddigi vizsgálatok sorra azt állapították meg, hogy az ok abban keresendő, hogy ezzel a kóddal lehet a hibákat minimalizálni. De a kodon használat nem egyenletes a különböző élőlénycsoportok között, mint ahogy ezek a vizsgálatok feltételezik. Ezért ebben a vizsgálatban azt nézték, hogy a kodon használat esetleges hibái hogyan hatnak különböző környezeti feltételek esetén. Azt találták, hogy az extrém magas hőmérsékleten élők esetén egy pontmutáció hatása sokkal súlyosabb. Ezért a genetikai kód valószínűleg a mezofil hőmérsékletű élőlényekre optimális, innen eredhet.

Pajkos Mátyás: Rákbetegségekben mutálódott rendezetlen régiók evolúciós vizsgálata

Az előadás címével ellentétben nem a tumoros megbetegedésekről szól. Az evolúciós vizsgálatokhoz a nagy számú fehérjét valamilyen logika szerint szűrni kellett, ezért csak a tumorokban szerepet játszó fehérjékre korlátozták azt. Megállapították, hogy ezen fehérjék a vizsgálatok szerint ősi eredetűek, a rendezetlen régiók konzerváltak.

Udvarnoki Zoltán: Onkogenetikai elemzések magyar mintákra

A csoport magyar minták onkogenomikai elemzését végzi. A szekvenálástól a szomatikus mutációk annotálásáig minden lépést elvégeznek, az eredményeket pedig egy webszerveren teszik közzé. Az előadás a cBioPortal bemutatásával folytatódott.

Becsei Ágnes: A levegő-metagenomika szerepe a kórokozók monitorozásában

Az előadás egy nagyon nehéz módszert, a levegő metagenomikát igyekezett bemutatni. A nehézséget mi sem bizonyítja jobban, minthogy a csoport nem talált koherens eredményt. Nem találtak plazmidokat, nem találtak horizontális géntranszferre utaló jeleket. Amit találtak, az is erősen szórt.

Farkas Bianka: A CFTR NBD1 mechanikai letekeredésének jellemzése számításos és kísérletimódszerek felhasználásával

A cisztás fibrózis a CFTR génben bekövetkezett mutációra vezethető vissza, aminek van rendezetlen része is. Az általuk vizsgált mutáció hatására a fehérje tekeredése változik meg, amit molekula dinamikai számításokkal vizsgáltak. Eredményeik alapján a leválási időpont változik meg. A hibásan működő domain pontenciális gyógyszercélpont lehet.

Börzsei Rita: A somatostatin 4-es receptor és az endogén ligandum-komplex szerkezetének előállítása

A somatostatis egy neurotranszmitter, ha a receptora hibás, az számos pszichiátriai betegség oka lehet. A vizsgálatban az sst4 receptor és a somatostatin kapcsolódását vizsgálták. Mivel a receptor szerkezete nem ismert, ezért homológ fehérjék alapján próbálták meg felépíteni azt. A dokkolást így sem tudták elvégezni, mert a szerkezet túl nagy volt a szimulációk futtatásához. Ezért az irodalmi adatok alapján a szerkezetnek csak azon részét használták, ami a dokkolásban ténylegesen részt vesz. Eredményeik alapján új somatostatin analógot tudnak fejleszteni, ami gyógyszerként is lehet alkalmazni.

Zsidó Balázs: A TRPA1 receptor ligandumokkal alkotott komplexeinek számítógépes vizsgálata

Az előadás némi átfedést mutat az előzővel, itt is receptor és ligand közötti dokkolást végeztek, de ez egy úgynevezett "szárazdokkolás" volt, "szemiempirikus" paraméter beállítással. Talán emiatt lehetett, hogy a kötési szabadenergiák az irodalomban fellelhető értékeknél 3-4-szer alacsonyabbak voltak.

Csizmadia Georgina: MemMoRF: Lipid kettősréteghez kötődő rendezetlen fehérjerégiók adatbázisa

A lipid kettős réteg és a rendezetlen fehérjék kapcsolatát nehéz vizsgálni, mivel a membrán környezet megnehezíti a vizsgálatokat. Ezért létrehoztak egy adatbázist, ahol az elérhető NMR adatokat felhasználva flexibilitást számoltak és meghatározták milyen másodlagos szerkezetet vehetnek fel a membránhoz kötött rendezetlen fehérjék. Az adatbázis megközelítőleg 500 bejegyzést tartalmaz, és itt érhető el.

Liska Orsolya: TFLink, egy átfogó transzkripciós faktor - target gén adatbázis

Bár már vannak transzkripciós faktor és target gén adatbázisok, ezek nem egységesek, általában csak egy fajra készülnek el. A TFLink egy helyre gyűjti ezeket a több forrásból származó adatokat, és csak kísérletesen igazolt eredmények vannak benne.

Miczi Márió: In silico módszerek alkalmazása a SARS-CoV-2 koronavírus fő proteáz (3CLpro) gazdasejt szubsztrátjainak azonosítására

A vírus proteázok interakcióba lépnek a gazdasejt proteómjával. A vizsgálat célja a 3CLpro proteáz humán célpontjainak meghatározása. Mivel erről a proteázról kevés információ van, ezért Blast segítségével homológokat kerestek és azok segítségével határozták meg a potenciális célpontot. A NetCorona webszerverrel pedig a hasítások helyét állapították meg. Az eredményeket in-vitro validálták, de sok esetben más eredményt kaptak. Vagy nem volt hasítás, vagy máshol volt, mint ahogy a predikció jósolta.

Palla Gergely: Metilációs hálózatok hierarchikus és kontroll tulajdonságai

A DNS metiláció szintjével jól lehet jellemezni az öregedést. Ezen alapul az úgynevezett Horvath-féle óra is, ami egy az ismert epigenetikai órák közül. Ezért ez a vizsgálat arra irányult, hogy a CpG metiláció szabályozásának hálózatát térképezzék fel. Erre egy regularizált Lasso-regressziót használtak, ahol akkor hoztak létre éleket a gráfban, ha ez a regressziós érték nullánál nagyobb volt. Az így elkészült hálózat hierarchikus volt, ahol a hierarchia tetején olyan gének szerepeltek, amelyek jobban beleszólnak az öregedés szabályozásába, mint a hierarchia alján lévők.

Kerepesi Csaba: Egér öregedés és megfiatalodás mérése epigenetikai órákkal

Az előadás több ponton is kapcsolódik az előző témához. Itt is az epigenetikai életkorral összefüggő vizsgálatok történtek, de jóval gyakorlatiasabb módon. A csíravonal sejteknek van egy olyan állapota, amikor "megfiatalodnak", vagyis a metilációjuk a fiatal sejtek állapotára hasonlít. A csoport egy olyan gépi tanuláson alapuló epigenetikai órát fejlesztett ki, ami nem csak az életkort becslüli meg nagy pontossággal, hanem az egyes életkor befolyásoló kezelések hatását is.

Fiser András: Aminosav alapú farmakofór módszer fehérje kölcsönhatások vizsgálatára

Ahogy a korábbi előadásokban is láthattuk, a fehérje kölcsönhatásokat dokkolással szokták vizsgálni. A dokkolás ismert kapcsolódásokon alapul és egyszerűsítéseket tartalmaz. A csoport kifejlesztette a ProtLID módszert, ami kiküszöböli a fenti limitációkat, cserébe nem az egész fehérjét, mint egységet nézi, csupán az aminosavakat. A szimuláció lényege, hogy a fehérjéből csak azokat az aminosavakat vizsgálja, amelyek potenciálisan részt vesznek a kötésben. A módszer az antigén-receptor kötéseket jobban képes leírni, mint a hagyományos dokkolás alapú módszerek.

Albert István: Bioinformatika és Egyéb Problémák

Az előadás azt mutatta meg, hogyan akadt az előadó egy bioinformatikai elemzés hibájára, amit úgy jellemzett "nekem egy órába telt, másnak talán több időbe". A probléma az volt, hogy az RNS szekvenálás irányított volt, de a Galaxy-ban rosszul klikkeltek egy paraméterre, amitől a readek irányát fordítva vizsgálták. Ettől két gén abundanciáját rosszul határozták meg, amelyek átfedtek, de ellenkező szálon voltak. A megoldást az adta, hogy az IGV-ben be kell állítani, hogy színezze be a readeket orientáció szerint. Ezután még olyan jótanácsot is hallhattunk, hogy a jó bioinformatikus tudja, mit jelentenek a paraméterek, amelyeket beállít a programokban.

Toth Adrienn előadását sajnos nem tudtam végignézni, ezért arról nem írok összefoglalót.

Amikor a számítógépeket használjuk, hajlamosak vagyunk (na, jó, hajlamos vagyok) azt hinni, hogy a kiszámított értékek teljességgel pontosak. A valóság viszont az, hogy csak egy közelítést adnak. Alkalmanként nem is olyan közelit.

Már eddig láttam jeleket, hogy a számítógépek máshogy viszonyulnak a számokhoz. Ha megnéz az ember egy 256b Mandelbrot fraktál zoomert, akkor előbb-utóbb azt tapasztalja, hogy a lebegőpontos számításhoz használt értékek elérik végső határukat, nevezetesen a fraktál egy színű lesz. De nem kell egy demoscene rendezvényre elmenni, hogy mindezt lássuk. A Python híresen rosszul kezeli a lebegőpontos számokat. Próbáljuk csak ki az interaktív konzolba beírva:

>>> 6.89 + 0.1
6.989999999999999

Az egyik legutóbbi feladatomnál Fisher tesztet kellett végeznem, viszonylag nagy számokra. A kontingencia táblázatban alkalmanként 200 milliós érték is lehetett! Az elvégzendő tesztek száma pedig olyan nagy volt, hogy nem akartam R-el vesződni. Igen, kicsit sok adat gyűlt össze. A teszt végeredményének kiszámításához faktoriálisokat kellett használni, és itt kezdődtek a problémák.

Ha csak a naív módszert használjuk, hamar rájövünk, hogy a 64 bites lebegőpontos számokkal 142-nél nagyobb faktoriálist nem lehet kiszámítani. Ráadásul a Fisher tesztben nem egy faktoriális szerepel, hanem faktoriálisok szorzata! Ezért a régi, jól bevált módszerhez folyamodtam: Nem szoroztam, hanem az értékek logaritmusát adtam össze. Mindjárt elég volt a hely, hogy akár 200 milliónak is kiszámítsam a faktoriálisát.

Ezzel viszont a pontosság rovására mentem. Ha megnéztem, milyen eredményt ad ki az R, akkor a nagyságrend stimmelt, viszont az értékek köszönő viszonyban sem voltak. A sebesség is gyatra volt. Egy teszt kiszámítása  kb. 4 másodpercet vett igénybe. Az összes teszthez két hónapra lett volna szükségem!

Lassú és rossz. Ezt a kombinációt akartam elkerülni. De mit lehet tenni ilyen esetben? Tisztázni kell a célokat. Igazából nem muszály manuálisan kiszámítani a faktoriálisokat, van egy közelítő eljárás, a Strigling módszer. Nem ad pontos eredményt, de nagyon gyorsan adja vissza. Egy gyors összehasonlítás a korrekten kiszámított értékekkel azt mutatja, hogy már alacsony értékeknél is lehet eltérés.

Egy közelítő értékeket használó statisztikai teszt, ami gyors és rossz. Lehet ebből jó eredmény? A válasz az, hogy igen. Ugyanis nekem azt kell eldönteni, hogy az asszociáció létezik-e két jelenség között. Tulajdonképpen nem számít, hogy ez az érték 3,4e-14, vagy 5,6e-12, amíg ebben a nagyságrendben mozognak. Ezt viszont a közelítő értékekkel is meg tudom állapítani.

Azért annyit változtattam a faktoriális kiszámító eljárásomon, hogy ha 10-nél kisebb számot adok meg neki, azonnal visszaad egy előre tárolt értéket. Ha 10 és 120 közötti az érték, akkor pontosan kiszámítja (ha eltekintünk a kerekítési hibáktól), és csak ennél magasabb érték esetén használja a közelítő formulát.

A program olyan gyors lett, hogy a másodperc tört része alatt megkaptam az összes eredményt. (Utána jutott eszembe, hogy elég lenne a legnagyobb szükséges értékre kiszámítani a faktoriálist és az összes köztes értéket tárolni egy tömbben, az gyors is lenne és pontos is.)

Ettől függetlenül látható, hogy a számítás módja meghatározza az eredményeket. Ez nem csak nálam érhető tetten, a nagy cégek által írt programoknál is fontos. Ha megfeledkezünk az Excelről, akkor is marad elég példa. Sőt, ahogy változik egy API verziószáma, úgy áttérhetnek más számítási módszerre is. Érdemes résen lenni, és sűrűn olvasni a dokumentációt.

Azért elgondolkodtató, hogy mennyire ismerhetjük meg a valóságot. Hiszen nem csak a számítás torzításán keresztül látjuk a világot, hanem azt is el kell dönteni, milyen torzítást használjunk. De biztosan tudom a kiválasztott módszer összes hátrányát? Nem lehet, hogy további meglepetések várnak rám, csak a megértésem még nem jutott el arra a szintre?

Az én példámnál maradvan, nem a Stirling az egyetlen közelítő eljárás. Választhattam volna mást is, amely más tulajdonságokkal bír. Ez még csak a faktoriálist. Erre épül a Fisher tesztem, ami ha egyszerűsítést nem is, kerekítési hibákat tartalmazhat.

Mi a jobb? Megállni biztos távolságra az ismeretlentől, és kijelenteni: eddig a pontig mindent ellenőriztem, amit itt találtam, az megbízható. Esetleg a hiányosságok ellenére is tovább menni, és remélni, hogy amit látok, az egy új eredmény, nem pedig a szemüvegem torzításának a felnagyítása?

A rövid válasz a fenti kérdésre, hogy mindkettő. Twitteren, blogokon, szakmai fórumokon rendszeresen felbukkannak hasonló kérdések (a leghíresebb talán a Python vs R vita), ahol rendre megjelennek olyan írások, hogy egyik vagy másik programozási nyelv felsőrendűbb a másiknál.

Nekem ezekre a vitákra egyetlen válaszom van: egy profi nem engedheti meg magának, hogy csak egyetlen eszközt ismerjen. A hátukgombolósok meg csak vitázzanak.

A jó kérdés inkább az, hogy mikor érdemes használni egyik vagy másik nyelvet? Mert ez nem mindegy.

Még nem vagyok egyik nyelv mestere sem, hiszen pár hónapja vetettem bele magam a tanulásukba, de azért kezd kirajzolódni egy kép bennem, hogy mely területeken lesz érdemes használnom ezeket.

Közös a két nyelvben, hogy az implementációk nem csak a fordító programot tartalmazzák, hanem a függőségek kezelését is. Más nyelvekben ez külön program szokott lenni. Például a Maven a Javahoz. A másik, hogy a fordító több feladatot vesz át a kód ellenőrzésből.

Természetesen különbségek is vannak. Kezdjük a Rust-al. A Rust egy második C akar lenni, ezért mindenhol, ahol korábban C-t használtunk, használhatunk Rust-ot. A nyelv megtanulása nem egyszerű, bár az is lehet, hogy én kötődök a hibás sémákhoz, amelyek értelem szerűen nem megengedettek Rust alatt. A kód fordításáért nekem meg kell szenvedni.

A C-vel való kompatibilitásnak ára is van, ezért lehetőséget adnak a fejlesztőnek arra, hogy "nem biztonságos" kódot is írjunk. (Bár szerény véleményem ez a biztonságos kódírásról. Még akkor is, ha elég sokszor lábon lőttem már magam)

Minden esetre, ha elsajátítottuk a nyelvet, könnyedén át tudunk térni Rust-ra, fokozatosan átírva egy projektet. Hangsúlyozom, miután elsajátítottuk. A tanulás hosszú időt vesz igénybe, később fogunk csak örülni az eredménynek. Még a nagy projektek is most vizsgálják, mennyire képes leváltani a nyelv akár a C++-t is.

Ezért a Rust például alkalmas lehet demók írására, mert van OpenGL könyvtár, van idő kísérletezni és jó, ha a végeredmény nem fagy le, mert nem figyeltünk eléggé az erőforrások felszabadítására.

A Go ezzel szemben nem törekszik arra, hogy a mindenség egyetemes nyelve legyen. A Google Cloud nyelvként definiálja, ami nem tudom, mit akar jelenteni. Amit tudok, hogy a Rustnál gyorsabban megtanulható, mert a nyelvi szintaxis egyszerűbb. Támogatja a többszálú feladat végrehajtást, amit remekül ki lehet használni a mai többmagos gépeknél, a fordítás után kapott bináris pedig statikusan linkelt. Ez utóbbi miatt könnyebben lehet horozni a binárist különböző Linux disztribúciók között.

A könyvtárak száma ezzel szemben limitált. Véleményem szerint soha nem fogunk Go alatt grafikus felületű programokat fejleszteni. Ha megnézzük az elérhető könyvtárakat ilyesmiket találunk: hálózatok, titkosítási eljárások.

Ezek a tulajdonságokat remekül lehet bioinformatikai programok fejlesztésére használni. Mire van legtöbbször szükség? Konzolos alkalmazásokra, amelyek beolvasnak egy fájlt és létrehoznak egy másikat. Esetleg adatokat kell letölteni az internetről. Sokszor kell nagy mennyiségű adatot feldolgozni, amihez elengedhetetlen, hogy több processzor magot is használjunk. A Go pedig mindezt tudja.

A TV adás nálunk egy Horizon médiaboxon keresztül érkezik. Sokáig nem is foglalkoztam vele, mert nálunk a TV-zés kimerül a napi Mancs Őrjárat megtekintésben. Néha vannak különleges napok, amikor iszonyat töménységben adnak le részeket, és ezek megtekintése még a legnagyobb rajongóknak is komoly megterhelést jelent, szegény szüleikről nem is beszélve.

Szerencsére a médiaboxhoz lehet vinyót csatlakoztatni USB-n keresztül, és fel lehet venni a részeket. Elkezdett érdekelni, vajon a felvett tartalmakat át tudom-e rakni számítógépre, és ott le tudom-e játszani. Abból indultam ki, hogy a doboz gyártói bizonyára nem kezdtek el saját formátumokat kitalálni, hanem meglévő komponensekből építkeztek.

Először a netet túrtam fel, de csak a szolgáltató felületes leírásai jöttek fel találatként. Talán senkit nem foglalkoztat a probléma?

A vinyót egy Linuxos laptophoz csatlakoztattam és sikerült megnézni a fájlrendszert. Ahogy elsőre számítottam rá, érthetetlen könyvtárnevek és ismeretlen fájl kiterjesztéseket találtam. Amin először meglepődtem, hogy a vinyón ext4 fájlrendszer volt, holott a leírások FAT32-t kérnek. Nocsak, nocsak. Bizonyára ezzel a primitív trükkökkel akarták megakadályozni a Windowson szocializálódott embereket, hogy TV műsorokat lopjanak.

Az első érdekes fájl a recordings volt. Linux alatt van egy file nevű parancs, amivel elég sok fájl típusát meg lehet mondani. De ennél egy közönséges less is elégnek bizonyult, ha nem ijedünk meg az ASCII karakterek tengerétől. A fájl ugyanis egy SQLite 3 adatbázis!

Ezt könnyedén be lehet olvasni, ha rendelkezünk a megfelelő adatbázis kezelővel:

sqlite3 recordings

Ebben az adatbázis kezelőben a .tables paranccsal kilistázhatjuk a táblákat. A felvételek a nagyon beszédes nevű recordings táblában vannak. A szerkezetét is megnézhetjük:

.scema recordings

Bár elég sok ismeretlen elemet láthatunk, rövid nézelődés után találhatunk egy path mezőt, ami alapján megtalálhatjuk a videó fájlokat. Persze a semmitmondó könyvtárakban úgyis a legnagyobb fájl tartalmazza a videókat, de ha specifikusan keresünk valamit, akkor az adatbázisból könnyedén ki lehet keresni a megfelelő felvételt.

Ezután jött a nagy kérdés, hogy micsoda a .rec kiterjesztésű fájl? Sem a less, sem a file parancs nem tudott érdemi választ adni. Elkezdtem bújni a netet, hátha találok valami érdekeset. Amitől nagyon féltem, hogy valami ostoba titkosítást fognak használni, ami lehetetlenné teszi, hogy használni lehessen a felvételeket.

Annyit sikerült találnom, hogy ez egy Toppy formátum, de ami felcsillantotta a reményt, hogy a VLC lejátsza. Akkor talán az MPlayer is!

Kis is választottam egy tetszőleges fájlt, de nem jelentek meg a kutyik, csak színes négyzetek villództak, mint a hibás MPEG2 videók esetén. Elkezdtem ismét a netet bújni, amikor a feleségem megkérdezte, mit csinálok. Neki is megmutattam a lépéseket, de a videó fájl kiválasztásánál egy másik példát választottam.

Megdöbbenésemre megjelent a mese! Hmm. Mint kiderült, két-három esetben valami miatt nem sikerült a felvétel, és nem lehetett visszajátszani. Többségében viszont az Mplayer (VLC is) zokszó nélkül lejátsza azokat.

Az ext4 fájlrendszer és az SQLite3 arra utal, hogy ebben a médiaboxban egy Linux dorombol. Vagy fene tudja, milyen hangot adnak ki a pingvinek.

2020 sok új szót hozott nekünk: nyunyóka, Mortran, QAnon. Mi? Ti nem tudjátok, mi az a Mortran? Akkor azt sem tudjátok, hogyan dolgozik egy igazi Nobel-díjas? Elmagyarázom.

Először is, meg kell szerezni a Nobel-díjat. Miből? Teljesen mindegy. A díj megszerzése ugyanis autómatikusan feljogosít arra, hogy az illető mindenhez értsen. Ehhez adjunk hozzá egy világjárványt, amihez egyéként is mindenki ért. A kettő együtt már jó alap arra, hogy bármilyen hülyeséget is mondjunk, arra mindenki figyelni fog. Újságok írják meg, miniszterelnökökkel találkozhatunk, akiknek személyesen mondhatjuk el. Ha egy-két jóslatunk véletlenül be is jön, az csak jó.

Nem hiszitek? Ezt csinálta Michael Levitt is. Az életműve előtt le  a kalappal, hiszen a hatvanas-hetvenes években komplex molekulák számítógépes modellezésével foglalkozott. El lehet képzelni, milyen hardver és szoftver környezettel dolgozhatott, úgyhogy abban alkotni maradandót, nem kis munka. Ezzel nem is akarok vitatkozni. De, ami azután jött, az már nem ilyen elismerésre méltó. A járvány kitörésével ugyanis COVID szakértő lett, és lépten-nyomon hangoztatta is jóslatait.

Viszont ezzel a tudományos közösséggel valami baj lehet, én mondom. Nem volt nekik elég a sok nyilatkozat, kijelentés, előrejelzés, amit Levitt tett. Azt is tudni akarták, mégis mi az alapjuk ezeknek a jósnatoknak? Nem azért, mert annyira pontosak voltak, hanem ellenkezőleg, mert úgy tűnt, semmi közük a valósághoz. Például az Egyesült Államokban négy hét alatt vége lesz a járványnak, 170 ezer halottal. Ha pedig egy ilyen befolyásos ember mond hülyeséget, annak következményei vannak, gondoljunk csak a C-vitaminra és a megfázásra.

A nagy unszolásnak az lett a vége, hogy született egy kézirat, ami a szokásos csontot veti oda a nyílt tudomány híveinek: minden adat és kód nyilvános lesz. Hol és mikor, az már egy más kérdés. Ezek a hátul gombolós tudósok folyton ilyen apróság miatt hisztiznek. De azért így is érdekes dolgokat tudhatunk meg. Például Levitt Mortranban kódol. Nem kell félni, nekem is kiadós utánajárást jelentett, ami azt jelenti, mégsem vagyok olyan öreg. :-) Ez a csökevény még '75-ből maradt ránk, a trapéz gatya és a hippi hajviselet korából. Tudom, hogy régi programnyelv, nem vén programnyelv. Azt is tudom, hogy a COBOL is milyen értékes lett. De bárki, aki számítógépekkel foglalkozik, lépést kell, hogy tartson azok fejlődésével is, nem igaz? Ha pedig programozik, akkor a programozási nyelvek fejlődésével is. Nem baj, ha valaki szereti a Fortrant, de akkor tartson is lépést vele!

Azért nehogy azt higgyük, ez az ember képtelen a fejlődésre! A cikk következő bekezdésében megtudjuk, hogy Levitt másik kedvenc programozási nyelve egy elavult Perl. Nem kéne ilyen szigorúnak lennem vele, lehet, hogy magabiztosan kezeli a Python 2.3-t is...

Nem sokat tudok a Mortranról, de valószínűleg manapság nem lehet binárist készíteni vele, hiszen a kéziratban is azt írták, hogy átfordították C-re. De mi is az a nagy titok, amit ebben a nyelvben fejlesztettek? Mi lehet az, amit csak Mortranban lehet megoldani? A válasz nem más, mint a loess normalizálás. Ez nem más, mint egy közönséges görbe simító eljárás, amit ilyen ujhullámos nyelvekben, mint R és Python rutinszerűen szoktak meghívni. Nos, a szerzők találtak egy '76-ból származó Fortran kódot (biztos az egyik szalagos egységen pihent), amit átírtak Mortranba. Igen, abba a Mortranba, amit végül C-re fordítottak.

Így dolgoznak az igazi nagyágyúk. Ezek a mai tejfölös szájú mitugrászok meg jönnek a deep learninggel, meg virtualizációval, hogy mindent a nyomorult felhőben futtassanak. Még egy nyamvadt Mortran kódot sem tudnak összedobni. Bezzeg régen! A mai fiatalok azt hiszik, hogy a forráskódból olyan természetességgek jönnek létre a binárosok. Klikkelgetnek az IDE-n aztán deployolnak operációs rendszertől függetlenül? Régen nem így volt. Régen a binárisért meg kellett szenvedni, és aki nem szenved meg érte most, az nem is tudja értékelni azt! Van még mit tanulni.

Egy feladatütemező előnyeit szerintem nem kell ecsetelni. Ennek ellenére léteznek olyan közösségek, ahol még mindig úgy indítják a szkripteket, hogy előtte toppal, ps-el és egyéb parancsokkal feltérképezik az elérhető erőforrásokat, majd vérmérséklettől függően lefoglalják a nekik szükséges részét.

Miért nem jó ez? Először is, a fenti parancsok nem látnak a jövőbe. Azért, mert egy adott pillanatban valamelyik felhasználó csak egy processzort használ, nem jelenti azt, hogy a szkriptje a következő lépésben nem fog 48-t felzabálni. A másik probléma, hogy aki először indítja a programját, az több erőforrást sajátíthat ki, mint aki a csak most ér vissza a nyaralásból.

A harmadik probléma, hogy ha én tudom, hogy sok erőforrásra lesz szükségem, akkor rendszeresen ellenőriznem kell, mikor szabadul fel az számomra. Ha például ez a hétvége kellős közepén történik, amikor épp egy bárgyú családtag unalmas történetét hallgatjuk végig századszor, akkor egy magányos munkatársunk, aki munkába folytja depresszióját, simán beelőzhet.

Egy feladat ütemező megoldást jelenthet ezekre a problémákra. Nekünk csak annyi a dolgunk, hogy elküldjük a szkriptet a megfelelő erőforrás listával, a többit a feladatütemező megcsinálja helyettünk. Az egyik legelterjedtebb feladatütemező a Slurm. Őszintén szólva, nem tudom, miben jobb ez, mint az LSF, Open Grid Scheduler vagy a többi, ami létezik. Felhasználói szinten minimális a különbség, rendszergazgai szempontból pedig csak a legelsőt ismerem.

Habár a Slurm sok csomagkezelőben előfordul, most mégis a forráskódból való telepítést fogom bemutatni. Ehhez egyetlen függőségre, a Munge-re lesz szükségünk. A dokumentáció szerint a fordítást a configure szkripttel kell kezdeni, de ne higgyünk neki. Azt először elő kell állítani. A teljes fordítás így fok kinézni:

./bootstrap.sh
./configure
make
sudo make install

Elméletileg érdemes létrehozni egy külön munge felhasználót, aminek a nevében fut a program, de a helyzet az, hogy a Slurm utána nem fog boldogulni vele, ha így teszünk. Inkább hagyjuk ki. Nem tűntettem fel, de van egy lépés, amelyik teszteli, mennyire sikeres a fordítás, de nem érdemes lefuttatni. Egy csomó hibát fog generálni, mert a létrehozott teszt könyvtárak jogosultságát problémásnak tartja. A program ugyanis nem szereti, ha a group-nak bármilyen jogosultsága van a munge által kezelt könyvtárak felett. Elméletileg, ha a /tmp-be tesszük át a teszt könyvtárakat (make check root=/tmp paranccsal), akkor nincs ilyen probléma, de nekem nem működött. Ugyan úgy dobálta a hibákat. A végleges könyvtárak viszont megfelelő jogosultsággal fognak létrejönni, ezért ezeket a hibaüzeneteket nem kell komolyan venni.

Ezt egyébként érdemes észben tartani hibakeresés közben. Ha nem megy a program, 90%, hogy jogosultság gond van. Mielőtt elindítanánk a munde démont, hozzuk létre az azonosításhoz szükséges kulcsot.

sudo mungekey

Most már készen állunk a Slurm telepítésre. Ezt is letöltjük, kibontjuk, majd jöhet a ./configure; make; sudo make install hármas. Sok esetben viszont érdemes időt szánni a konfigurálásra. Például ha nincs szükségünk grafikus felületre (márpedig egy távoli szerveren legtöbbször nincs), akkor a nyugodtan használjuk a --disable-x11 opciót.

Telepítés után jöhet a rendszer beállítása. Először létre kell hozni egy slurm felhasználót. Kell készíteni egy konfigurációs fájlt itt. Igen, egy weboldalon. Nekem a memória beállításával volt problémám, mert azt gondoltam megadhatok mértékegységeket. Nos, nem. Ha az aktuális node paramétereire vagyunk kíváncsiak, a slurmd -C paranccsal kiírathatjuk azt. Ez segíthet meghatározni, mekkora erőforrásokkal rendelkezik az adott node.

Miután kitöltöttük a webes konfiguráció szerkesztőt, letöltjük a kész fájlt a beállításokkal, és bemásoljuk a megfelelő helyre slurm.conf néven. Ha nem állítottuk be a --prefix opciót konfigurálásnál, akkor ez a könyvtár az /usr/local/etc lesz. Tegyünk mellé még egy konfigurációs fájlt, aminek a neve cgroup.conf. Ezt elfelejti említeni a dokumentáció, de higgyétek el, hogy kell. Hiányában a Slurm képtelen lesz a jogosultság kezelésre. Tartalma a következő:

CgroupMountpoint=/sys/fs/cgroup
CgroupAutomount=yes

Felvehetünk más opciókat is, amivel a job-ok által felhasznált erőforrásokat tudjuk limitálni. Ez akkor lehet hasznos, ha a gépen más program is fut, aminek szeretnénk állandó erőforrásokat biztosítani.

Ezután létre kell hoznunk különböző könyvtárakat, amelyeket a Slurm arra használ, hogy nyilván tartsa a futó folyamatokat.

sudo touch /var/run/slurmctlf.pid
sudo touch /var/run/slurmd.pid
sudo mkdir /var/spool/slurmd
sudo mkdir /var/spool/slurm.state

Mindegyik legyen a slurm felhasználó birtokában! Némelyik fájl neve ismerős lehet a slurm.conf fájlból, ezért ha ott átírtuk, akkor más névet kell megadnunk a fenti parancsoknál is.

Most már elindíthatjuk a démonokat. Először a slurmctld-t kell, majd a slurmd-t. Ezzel készen is vagyunk. Amennyiben több nodot használunk, úgy a munde és a slurmd-t az összes nodon el kell indítani.

A fenti lépésekkel egy nagyon egyszerű ütemezőnk lesz. A konfigurálást a végtelenségig lehet bonyolítani. Lehet különböző queue-kat létrehozni más-más limitekkel, korlátozhatjuk a felhasználókat, hogy mennyi ideig használják a rendszert (például jó ötlet lehet egy maximális futási időt megadni, mert mohó bioinformatikusok kisajátíthatják a teljes infrastruktúrát).

Hasznos link:

Leo's Notes

Nemrég kíváncsi lettem, mióta is írok blogot. Mint kiderült, pontosan tíz éve. Egy másik kerek évforduló is van, ugyanis ez az 500. bejegyzés (van három bejegyzés, amit visszavontam, az 500-ba azokat is beleszámoltam). Bevallom, azért egy kicsit manipuláltam a dolgokat, hogy pont mára jöjjön ki, de nem számít. Szeretjük a tízzel és százzal osztható számokat, még akkor is, ha matematikailag semmi különös nincs bennük.

A blognak jelenleg négy aktív követője van. A legnépszerűbb bejegyzés már bioinformatikai, és nem a villanybojler kontárkodásom, ami sokáig vezette a toplistát. Aminek külön örülök, hogy az olvasóim fele (59%) 800x600-as felbontásban nézi a blogot. Érdekes módon az ismeretlen böngészők száma is hasonló (51%), akik nem a Firefox-Chrome-Safari triumvirátusba esnek, és az ismeretlen operációs rendszert használók aránya (46%) sem tér el nagyon.

Természetesen lehet, hogy ez a három tény egymástól független, de nehezen tudom elképzelni, hogy valaki direkt 800x600-on kínozza magát Windows 10 alatt. Sokkal valószínűbb, hogy valami alternatív platformon olvassák. Nem gondolom, hogy ez MorphOS lenne, mert azt többnyire PowerMac-en használják, ami nagyobb felbontással üzemel. A 800x600 egyértelműen valami régi rendszer lesz, ami a 2000-es évekre hajaz.

Átlagosan napi 12 lapletöltés van, aminek a nagy része a Google és a Bing. Senki nem szokta linkelni az oldalakat, nem is igen hivatkoznak rá. Egyszer a prog.hu feltűnt hivatkozónak, de soha nem akadtam rá, melyik bejegyzés keltette fel az érdeklődésüket.

Ez a nagy ismeretlenség nem meglepő. A magam részéről soha nem reklámoztam a blogot. Nem árultam el senkinek, hogy blogot írok (na jó, egy embernek mondtam, de szerintem ő másnap el is felejtette). Amint mindenki láthatja, ki vannak kapcsolva a reklámok is, amivel azonnal levettek a főoldalról is. Ez egy tudatos döntés volt, mert kíváncsi voltam, mennyire akadnak rá az emberek marketing nélkül. Annak ellenére, hogy nem emelkedtem influenszeri magaslatokban, bioinformatikai körökben elég elterjedt a blog. Legalábbis erre enged következtetni, hogy sok olyan emberrel találkoztam konferenciákon, akik a blog alapján ismerték a munkámat.

A másik ok (amellett, hogy kicsit csapongó, sok helyen nehezen követhető az irásom), hogy a téma nem sok embert érdekel. Egy filmkritika sokkal több embert tud bevonni, mint a szerencsétlenkedés a számítógépekkel. Ha viszont csak a célközönséget nézem, akkor azt gondolom, elég nagy százalékukhoz eljutottak az üzeneteim. Ezt sikerként is felfoghatom.

Néha a bioinformatikai munka olyan, mintha egy kísértet járta házat fedeznénk fel. Nappal. Tudjuk, hogy vannak szellemek, de azt hisszük, ezek csak éjszaka jönnek elő. A rontások tényleg nem szeretik a fényt, de nappal is vannak árnyékos helyek...

Nemrég gomba szekvenciákat kellett összeraknom. Pontosan nem tudtuk, milyen gombákból származtak ezek, ezért az ITS régió azonosítása nagyon fontos volt. Kétféle szekvencia állt rendelkezésünkre. Az egyik a szokásos Illumina volt, a másik Nanopore. Az Illumina mintavételénél a laborosok biztosak voltak benne, hogy Staphylococcus fertőzés is történt, ezért azokat különösen óvatosan kellett kezelni. A Nanopore-al ilyen probléma nem volt.

Több összeszerelést is végrehajtottam. Csak Illumina readek alapján, csak Nanopore szekvenciákkal és persze hibrid összeszerelést is végeztem. Nem akartam a fertőzéssel sokat bajlódni, ezért először csak a Nanopore szekvenciákkal épített genomot vizsgáltam. Az ITS régiók kópia száma 37 volt. Úgy gondoltam, ez nagyon sok, mert a referencia Saccharomyces genomokban 2 szokott lenni. Igazából volt más probléma is ezzel a genom összerakással (például a teljes mitokondriumnak csak 1/8-ad részét sikerül összerakni, az indelek száma meglepően magas volt), ezért tovább kellett lépni.

Megnéztem a hibrid összeszerelést is. Ez már ígéretesnek tűnt. Megvolt a teljes mitokondrium, viszont egészen biztos, hogy vannak benne olyan szekvenciák, amelyek nem gombából származnak, hála a fertőzésnek. Az összeszerelt scaffoldokat szűrni kellett valahogy. Először csak a baktérium genomokra illesztettem, majd ami arra felment, eltávolítottam. Ezután kerestem csak az ITS régiókat. Egy felet találtam! Ez elég szokatlan szám volt a 37 kópia után, amit a másik módszerrel határoztam meg. Megnéztem a szűrés előtti szekvenciákat, és két darab jött fel, akár csak a nagy könyvben.

Tehát túl szigorúan szűrtem. Nézzünk egy jobb szűrési módszert! Illesztettem a baktériumokra és a Saccharomycesre is. A két illesztésre adott pontszámot (bennfenteseknek: a Blast bitscore-t) pedig ábrázoltam egy koordináta rendszerben. A vízszintes tengely a baktérium illesztések pontszáma, a függőleges a gomba illesztés pontszáma. A szekvenciák egy része szépen szegregálódik. Ami a vízszintes tengelyhez van közel, az baci, ami a függőleges tengelyhez van közel, az gomba. Egyértelmű.

De mi a fene az a sok szekvencia az átló mentén? És miért vannak pontok az átlón? Hogyan lehetséges, hogy egy szekvencia közel olyan jól illeszkedjen a gombához is, mint a baktériumhoz? A horizontális géntranszfert sok mindenre rá lehet húzni, de erre nem.

Elkezdtem megnézni, miféle baci lehet ez. Az adatlapja szerint egy szekvenálásból származó szekvencia darabka. Egy hasonló kísérletből származik, mint amilyen az enyém is. Nekem is darabkáim vannak, nekik is darabkáik voltak. Én gombát akartam összerakni, ők baktériumot. Rá is engedtek mindenféle programot, ami talált géneket, érdekes régiókat, stb. Az NCBI pedig beemelte a referencia szekvenciák közé, és a reprezentatív baktérium Blast adatbázis része lett.

Ha viszont megnézzük, mivel mutat homológiát (bárki megteheti, van egy Run BLAST gomb jobb oldalon), akkor egy gombát találunk! Húúú, a szellem kibújt! Mégis csak elég hasonló a kísérlet az enyémhez! Amig nekem baci fertőzésem volt, addig nekik gomba jutott. De még én mindent elkövettem, hogy az idegen szekvenciákat eltávolítsam, addig ők ezzel nem sokat törődtek. Szinte belegondolni is rossz, hány ember használ ehhez hasonló adatokat, abban a hiszemben, hogy amit a szekvenciák leírásban találnak, az hiteles információ.

Természetesen az egyes adatbázisokban előforduló hibák nem újkeletű dolgok. Emlékszem, annak idején a MisPredre, ami az EnsEMBL hibásan detektált fehérjéit igyekezett kijavítani. Még én is "dinoszaurusz" DNS Blasztolását adtam fel egy állásinterjún feladatnak. De még a humán szekvenciák is okozhatnak szennnyezést a baktérium szekvenciákban.

Tehát mindenki legyen éber, mert bármikor beterítheti egy kis nyálka egy forduló után.

Úgy döntöttem, kihagyom az idei Function-t. Sokat gondolkodtam a döntésen, ettől a motivációm is lecsökkent, ami öngerjesztő folyamatként afelé mozdított, hogy release nélkül nem kéne partira mennem. Végül addig halogattam a döntést, hogy kifutottam az időből.

Egy partinak mindig van egy kis szürreális hatása. Úgy értem, egy kívülálló számára érthetetlen, miért ujjonganak emberek a kivetítőn látható absztrakt formák láttan, és még egy informatikus számára is felfoghatatlan, milyen nyelven beszélnek. A régi és modern számítógépek által generált világok egyszerre vannak jelen, amitől minden időtlenné válik. Mégis, mikor elkezdtem nézni a közvetítést, még nekem is sokkoló volt a látvány.

Egy gázállarcos fickó ugrált egy laptop előtt, miközben maszkos alakok táncoltak előtte. Oké, újabb adalék a furcsaságok gyűjteményéhez. Bár ezek után el sem tudom képzelni, milyen lehet egy valódi posztapokaliptikus demóparti.

A releasekre viszont nem lehetett panasz. Az oldschool kategória kimagasló eseménye a Genesi Projekttől a Memento Mori. Nagyon egységes témája volt, még a lemezoldalak váltására szólító üzenetek között is olyan idézeteket szerepeltek, amelyek képesek voltak a hangulatot fenntartani. Rengeteg artwork volt, szép scrollok és gyönyörű zene. Az effektek is látványosak voltak.

A Lethargy is egy remekül megkomponált demóval érkezett. Témája a Nintendós játékok. Mivel manapság már a csapból is Mario folyik (nem tudunk egy nyomorult Kinder tojást sem venni anélkül, hogy ne egy teki katona essen ki belőle.), annyira nem ragadott magával a nosztalgia vonat, de az effektekre itt sem lehetett panasz.

Ha már Nintendo, akkor legyen SNES kövér. Egy 3D flyby-t kaptunk, a monoton fajtából. Aki nem követi a demoscene apró rezdüléseit, annak megemlítem, hogy vannak az oldschool kategóriákban bizonyos témák, amelyekhez bátran nyúlhat az, akinek semmi ötlete inkább a technikai kihívásokkal kíván foglalkozni. Az egyik ilyen a Bad Apple, a másik a STINCCC. Most ez utóbbit láthattuk.

A 256byte intrók mindegyike szokás szerint magas színvonalat képviselt. Hirtelen nem is tudnám megmondani, melyik tetszett a legjobban, de a Bit Runner 2048 jelez egy új trendet. Mostantól a multipart intrók a nyerők ebben a kategóriában. Nekem nagyon tetszett a Hydraulic Pixels is, mert első ránézésre nem lehetett megmondani róla, hogy ez egy 256 byte intró. Mivel a legtöbb intró 640x480 256 színes videómódot használ, ezért egy idő után rögtön felismeri az ember, hogy mivel van dolga. Ennél az intrónál ez nem következett be.

A többi intró kategória nem volt valami nagy szám, bár Archee kerek popós rolleres alkotása nagyon vicces volt, főleg, ahogy a végén twerkeltek, vagy mit csináltak.

Az idei demóknál nem is a technikai részleteken volt a hangsúly, hanem az elvontságon. A Rainbow Clash végre szakított azokkal kaptafára gyártott demókkal és végre csináltak valami mást. Nem állítom, hogy pontosan értem, mit is kaptunk, de akkor is üdítő, hogy nem egy kellemes zenére rádobált random színes objektumok halmazást kellett nézni. A Rebels is belépett a game engine korszakba, és remekül helyt is álltak Unitys demójukkal. Gargaj egyszemélyes hadserege ismét támadást intézett a "szokványos demók" bástyái ellen. Azt hiszem, meg sem próbálom szavakba önteni, mit éreztem a demó megtekintése közben. Ezzel nem azt akarom mondani, hogy rossz, amit láttunk, inkább azt, hogy az értelmezéseim eddig sem fedték le a valóságot.

Végezetül volt egy nem release jellegű esemény, ahol a Function egykori és mai szervezői rengeteg belső információt osztottak meg egy beszélgetés keretében a hallgatósággal. Nekem, aki mit sem tudott erről a szubkultúráról 2007 előtt, remek anyag volt. Szerintem még külsősöknek is érdekes lehet.

Összességében nekem pozitív volt a tapasztalatom a partival kapcsolatban, és maximálisan tisztelem a szervezőket, hogy még ilyen időkben is kitartanak, nem adják fel. Hiszen megtehették volna, hogy bedobják a törölközőt.

Akkor leszünk középkorúak, amikor a fiatalos lendület megtörik, és feladjuk azokat az elveket, amelyekért éveken keresztül küzdöttünk. Előbb-utóbb mindenki elér erre az állapotra, nem véletlen, hogy az egyes tüntetéseken fiatalok vannak, és a különböző aktivista fórumok sem vén csontokból verbuválódnak.

Nekem egyetlen, icike-picike harcom volt az Excel nevű többfejű szörnyeteggel. Következetesen elutasítottam mindent, amit ez a program képviselt, és erre másokat is próbáltam rávenni, nem túl etikus eszközökkel: "Ja, Excelben kérted? Teljesen elfelejtettem. Nem baj, így is meg tudod nyitni." vagy "Nem nyitja meg az Excel? El sem tudom képzelni, mi lehet a baj," esetleg "Bocs, Linuxom van."

Máskor perverz élvezettel hívtam fel a program hiányosságaira a figyelmet, majd széttártam a karom: "nekem nincs ilyen problémám, én nem használom."

De most mindennek vége. Legyőztek.

Az első támadás egy kooperáló partner képében jött, akik jó ideje nem küldtek nekünk elemezni való adatot, helyette egy másik csoportot kértek fe, hogy végezzék el a munkát. Mivel az a csoport nem olyan jó, mint mi (hehehe), ezért a mi segítségünket kérték. Nem magához az elemzéshez, hanem az infrastruktúra felállításához. Tehát kerülőúton ugyan, de valamilyen szinten mégis hozzánk jutott a munka.

Mikor azt próbáltuk kipuhatolni, ugyan miért nem volt jó, amit mi csináltunk, az volt a válasz, hogy nem Excelben küldtük az eredményt. Ha ez igaz, a makacsságom hatására buktunk egy melót. Ez azért fájt.

A második sokk ebben a cikkben ért. A HGNC átnevezi azokat a géneket, amelyek nevét az Excel dátummá alakítja. Ez döbbenet. Nehogy már béne Windows felhasználók igényei szabják meg, mik legyen a gének nevei! Márpedig pontosan ez a helyzet. Mi lesz a következő? A FASTA fájlokat lecseréljük Word dokumentumokra? Jegyzőkönyvet pedig PowerPointban kérik ezután?

Úgyhogy ideje elismernem, hogy vesztettem. Ilyen erők ellen nem lehet harcolni.

Bevallom, már nem is emlékeztem, mit csináltam ebben a cikkben. Teljesen kiesett. A projekt még 2016-ban kezdődött, amikor végeztünk a mangalica cikkel, és jelentős adatunk volt különböző sertés szekvenciákból. Belekezdtünk különféle markerek keresésébe, amelyek némelyike politikai döntés miatt halálozott el, mások nem bírtak elég jelentős gazdasági haszonnal.

Ezekbe a döntésekbe nem láttam bele, nekem csak az volt a dolgom, hogy temérdek BAM fájlból "érdekes" régiókat halásszak ki, tonnányi IGV képet generáljak, amit aztán a Windowson szocializálódott kutatók bogarászhattak. Arról sem szabad megfeledkezni, hogy abban az időben nekem volt a legerősebb gépem az intézetben, játszi könnyedséggel hajtottam végre ilyen feladatokat, miközben más munkákra tudtam koncentrálni.

Azután nem jött több kérés, én nem erőltettem a dolgot. Csatlakoztam a Sanger csapatához, ezért annak rendje és módja szerint elfelejtettem az egészet.

Egy nap viszont levelet kaptam, hogy szerző vagyok egy publikációban. Gyorsan megkérdeztem, miféle munka volt ez? Elmondták, hogy a rengeteg marker keresésből a vaddisznó marker azonosítása sikeres lett, de közben az is kiderült, mások is majdnem elfelejtették, mivel járultam hozzá a cikkhez, de a levelező szerző szerencsére nem volt olyan feledékeny, mint én.

Igazából azért érdekes ez a cikk, mert azon kevesek egyike, amikor a munkámnak közvetlen, kézzel fogható haszna van. Ezzel a publikációval lehet menőzni azoknál az embereknél, akik csak üres tekintettel bólogatnak, ha valami alapkutatásból származó eredményemről beszélek.

Nagyon érdekel a sötét anyag kutatás, és nem csak azért, mert vagyány neve van. Van egy olyan rossz tulajdonságom, hogy amihez nem értek, azt túlmisztifikálom. Az ismeretterjesztő könyvek viszont segítenek helyre tenni a dolgokat. Ezért is olvastam el Richard Panek, 4% univerzum című könyvét.

A könyv a kozmológia hőskorának bemutatásával kezd, amikor felfedezték a kozmikus háttérsugárzást, később az univerzum tágulását. A könyvben a tudományos rész viszonylag kevés, sokkal többet mutat be az egymással versengő kutatókról, és azok személyiségéről. Ezt az első fejezetekben még átszövi egyfajta pátosz, de ahogy halad előre a könyv, és közelítünk a jelenhez, egyre inkább olyan lesz, mint egy OTKA bírálat kulissza titkai: Tudod, hogy korrupt a rendszer, de még így is arcon csapnak a tények. Csak itt azzal szivatják egymást a kutatók, hogy nem engedik a Hubble űrtávcsövet használni a konkurenciának.

Mindezt talán valami hatalmas tudományos célért teszik? Nem, csupán azért, hogy néhány tizedesjeggyel pontosabban kiszámolják azt a kozmológiai állandót, amit az elméleti fizikusok próbáltak elfelejteni. Ezen a ponton, határozottan gyűlöltem már a könyvet. Mert míg más tudomány területen kifogásolják, ha a kitűzött célok nem elég előre mutatóak, a könyv azt sugallta, hogy az Egyesült Államok csillagászai egyre nagyobb berendezéseket építenek, egyre több pénzt vernek el, miközben igazolják azt, amit egy galamb ürülékkel teleszórt tányérantennával is látni lehet. (A Bell mérnökei ugyanis attól féltek, hogy a galambpiszok okozza azt a zajt, amit később kozmikus háttérsugárzásnak azonosítottak.)

Azért biztos vagyok benne, hogy mást is publikálnak egyetlen számértéknél, hiszen a PhD hallgatókank is kell az első szerzős cikk, de nem éreztem a nagy áttöréseket. Einstein beleírta a kozmológiai állandót az egyenleteibe. Aztán kivette. Mások meg visszatették. Mintha az egész tudományág körbe-körbe menne.

A másik dolog, amin nagyon kiakadtam, hogy ugyan olyan módszertani hibákat követettek el, mint amiket én is megemlítek néha a blogomban. Az egész azért is dühítő, mert két, egymástól független csoport is elkövette őket!

Lecsupaszítva az történt, hogy két konkurens csoport figyelte a szupernovaként felrobbanó csillagokat. Ez azért volt fontos, mert ezek fényerejének változásából nagy pontossággal meg lehet határozni a távolságukat. Gyakorlatilag galaxisok Földtől mért távolságát és sebességét mérték. Ezeket egy grafikonban ábrázolták.

Az SCP csoportot részecske fizikusok alkották, akik az elején semmit nem tudtak a csillagászatról, viszont kitaláltak egy módszert, amivel annyi szupernovát tudtak detektálni, amennyit csak akartak. A másik csoport, amire a könyvben Nagy-z csoportként hivatkoznak, csillagászokból állt. Ők pontosabban megfogalmazott tudományos kérdésekre keresték a választ, viszont nagyon nehezen találtak szupernovákat.

Az SCP csoport a vizsgálatok korai szakaszában, mikor kevés szupernovájuk volt, írtak egy cikket, és felállítottak egy magyarázatot. Ahogy telt-múlt az idő, néhány olyan szupernovát találtak, amelyek nem illettek bele ebbe a magyarázatba. Mit csináltak ezekkel az adatopontokkal? Nem közölték, hanem kihagyták őket! Az volt az indok, hogy a szavahihetőségüket aláássa, ha mindig más eredményt közölnek.

Ahogy telt-múlt az idő, annyi ilyen "kiugró érték" keletkezett, hogy már nem hagyhatták őket figyelmen kívül. Akkor meg azon mesterkedtek, hogy minél előbb leközöljék és rettegtek, hogy a konkurencia beelőzi őket. Ugyanis a Nagy-z csoport kezdett feljönni a szupernovák számában, ráadásul már a kezdetektől pontosabb méréseket hajtottak végre, mert tisztába voltak egyéb csillagászati problémákkal is. Ahogy közeledett a Nobel-díj kihírdetése, úgy kezdett egyre szemetebb módon viselkedni egymással a két csoport. Civakodtak, mint az óvodások. Könyveket írtak, ahol mindenki saját magának tulajdonította a felfedezést, holott egyedül egyikük sem lett volna képes még a megfigyeléseket sem elvégezni.

Az egészhez az egyetemek még PR csapatokat is mozgósítottak, akik olyan komoly tudományos tevékenységet folytattak, hogy Washington Post és New York Times kaliberű újságokban közöltek híreket. Mélységesen megdöbbentett az egész.

Ahogy a látható anyag is csupán töredéke az univerzumunknak, úgy a tudomány is csak nyomokban fedezhető fel a sötét anyag kutatásban. A többi politika, cselszövés, árulás.

Az számítógépem szép lassan megdöglött. Nehezen indult, könnyen fagyott. Fagyás után megint nehezen indult. Egy ideig bírtam is a hóbortjait, de a munkát egyre nehezebben lehetett ellátni vele.

Először csak a játékok terhelték meg. Egy óra játék után annyira felforrósodott, hogy a burkolat szinte égetett. Levettem az oldalát, és elfektettem, hogy videókártyától érkező meleg levegő ne a processzort fűtse, de ez sem segített sokáig. Azután a helyzet tovább romlott, egyre rövidebb ideig tudott futni egyhuzamban. Végül 10 percet sem tudtam használni anélkül, hogy le ne fagyott volna. Eljött az idő, hogy megjavítsam.

Először a tápegységre gyanakodtam, de a multiméter és a diagnosztikai programok szerint is stabilan adta le a 12 és 5 voltot is. A memóriára gyanakodtam másodjára, de Windows alatt az Aida64 memória tesztelő modulja semmit hibát nem talált. (Volt egy kis kalandom a CentOS vészmódjával is, de nem akarom annyira részletezni, mennyi mindent sikerült elrontanom. Elég az hozzá, hogy elindítottam emergency módban, és utána csak abban tudtam elindítani.)

Processzor tesztnél viszont 3 perc után fagyott, a következő újraindításnál, ha nem tudott bootolni, az alaplapon a CPU indikátor ledje folyamatosan világított. A dokumentációja csak annyit írt, hogy szüntessük meg a CPU problémát, és akkor menni fog. Oké, de milyen problémája lehet egy CPU-nak? Pontosabban mi olyan problémája lehet, amitől néha megy, néha nem?

A neten találtam egy leírást, mely szerint érintkezési hiba léphetett fel, vagy a nem megfelelő hűtés okozhat galibát. A hűtő ventillátor megfelelően működött, nem értettem, mi baj lehet vele. Az érintkezési hiba pedig olyan misztikus. Nem tudtam elképzelni, hogy lezárt processzor foglalatban miként léphet fel érintkezési hiba, de ez volt az egyetlen nyom, amin elindulhattam. Úgy döntöttem, kiszedem a processzort.

Megpróbáltam leszedni a hűtőt a CPU-ról, de az úgy rá volt ragadva, hogy nem mozdult. Életemben nem láttam még ilyet! A régi, leselejtezett alaplapjaim hővezető pasztái még 20 év távlatából is összemaszatolták a kezem, mitől köthetett be ez a viszonylag fiatal? (Fiatal? Hét évvel ezelőtt raktam össze, azóta csak a grafikus kártyát cseréltem.) Lehet, hogy ez okozta a gondot? Megszáradt és nem volt képes a CPU leadni a hőt?

De akkor is ki kellett szedni valahogy, ha újra akarom pasztázni. Gondoltam, egy kis csavarás talán segít...

Segített is. Kijött a processzor is, hűtő is a lezárt foglalatból! A paszta továbbra is betonként tartotta egybe a két részegységet. A processzor apró réz kivezetései közül néhány elgörbült. Ezt jól elintéztem.

Egy fórum bejegyzés szerint melegítés hatására elválnak. Én próbáltam melegíteni, nem hajszárítóval, ahogy javasolták, hanem egy öngyújtóval a hűtőbordák alját melegítve, de nem használt. Az okos megoldás ha nem működik, majd a nyers erő fog. Fogtam az egyik mindenes bicskámat, és szép lassan elkezdtem szétfeszegetni a hűtőt és a processzort. A művelet során nem sikerült jól megfognom a CPU-t, ezért további lábak deformálódtak el. Végül elváltak egymástól. Egy probléma megoldva, de keletkezett egy újabb.

A bicskával lekapartam a kő kemény pasztát, majd alkohollal letiszítottam a vékony szennyeződéseket (Az ujjlenyomatokról nem is beszélve, mert antisztatikus kesztyűt csak a gyengék használnak). A hűtő alján a rézlemez kicsit karcos lett. Gondolkodtam rajta, hogy esetleg kicsit polírozok rajta, de végül letettem róla. Gondoltam, majd a paszta megoldja. Inkább fogtam egy csipeszt és egy nagyítót és szépen lassan elkezdtem visszaegyenesíteni a processzor lábait.

Ez elég sokáig eltartott. Beletettem a foglalatba, próbáltam a kezemmel érzékelni, hol nem megy a helyére, majd kivettem és állítottam még egy kicsit rajtuk. Szerencsére egy teljes sor nem görbült el, így a szomszédos lábakat referenciának tudtam használni. Végül a helyére került. Jöhet a paszta.

Volt egy doboz pasztám, amit nagyon régen vehettem, mert a rajta lévő árcédula tanúsága szerint 600 forintot fizettem érte. Szerintem 2000. után történhetett, de nem vagyok benne teljesen biztos. Meddig lehet jó egy ilyen paszta? Az állaga jónak tűnt, meg ennél több kárt már nem tudok okozni ennek a gépnek, ezért bekentem vele. Visszaszereltem a hűtőt, és áram alá helyeztem.

Nem szikrázott, amit jó jelnek vettem. Elindítottam. Az első meglepetés az volt, hogy a hűtő sokkal csendesebb lett. Ismét ráeresztettem az Aida64-t. Még teljes terhelés mellett sem volt olyan hangos, a hőmérséklet pedig nem ment 70 °C fölé. Fél óra tesztelés után megnyugodtam. A küldetés sikeres volt.

A többszörös illesztés régen egyszerű volt. Fogtuk a szekvenciákat, bedobtuk a ClustalW-be és illesztettünk. Később jött a Mafft, Muscle és a társai, de a recept nem változott sokat.

A szekvenciák aztán hosszabbodtak és már mindenki genomokat akart illeszteni ezresével. Nem csak az aktuális járvány miatt, hanem egyébként is. A gépek viszont még nem állnak azon a szinten, hogy ezt a régi módszerekkel véghezvigyük, ezért megjelentek az egyszerűsítések és a különféle stratégiák.

Bizony, ami régen rutin feladat volt, manapság művészetté lépett elő, ahogy a DECIPHER dokumentációja is sugallja. Röviden nézzük is át, milyen stratégiák vannak!

Régi iskola

Ezt csináltuk régen, és ezt csináljuk most is, ha egyszerű hipotézisekkel dolgozunk. Veszünk egy gént, régiót, majd illesztünk. Általában olyan gént, ami minden, a kutatásban szereplő élőlényben megvan, mint például a jó öreg 18S alegység. A szekvenciák kollineárisak, közel azonos hosszúságúak, használhatjuk a régi jó dolgokat. Az összes bioinformatikai könyv, cikk, bejegyzés ezzel van tele. Előnye, hogy egyszerű, kicsi a hibázás esélye. Viszont nagyfokú szekvencia homológia esetén teljesen használhatatlan, mert minimális lesz a különbség a vizsgált szekvenciák között. Nem lesz olyan szerencsénk, hogy ezt a módszert kelljen használni.

A ráncfelvarrt

Ez majdnem ugyan az, mint az előző, csak sok homológ szakaszt vesznek, azokat mesterségesen összeragasztja, és egy nagy szekvenciával dolgoznak. Egyesek odaig is elmennek, hogy 1500 gént raknak egymás után. Közelrokon fajoknál növeli a szekvenciák diverzitását, de több gond is van vele. Először is, a gének evolúciós sebessége eltérhet. A végső hasonlóságot a hosszabb gének fogják megszabni, ráadásul a gének illesztésének helyén nagyobb eséllyel lesz gap, amit minden illesztőprogram rosszabbul súlyoz, és a később a fa építésénél a valós evolúciós távolságnál nagyobb távolságot kapunk. Ennek a módszernek semmi biológiai relevanciája nincs, szerintem azért csinálják, mert még mindig vissza tudnak nyúlni a megszokott programjaikhoz. Ezt a módszert lehetőleg soha ne használjuk, nyugodtan vállaljunk be egy összeveszést a főnökünkkel, ha erre akar kényszeríteni.

Vadnak született

A helyzet az, hogy legtöbb esetben nincs teljes genomunk, csak dirib-darab szekvenciáink. Ha van is genom, a kollinearitás nem garantált, nekünk mégis ezzel kell dolgoznunk. A megoldás, hogy több homológ szakaszt veszünk, akár csak az előző módszerben, csak nem ragasztjuk össze őket. Több többszörös illesztést végzünk és több fát készítünk, ha evolúciós kapcsolatokat is látni akarunk. De melyiket illesztést, és azon keresztül melyik fát fogadjuk el végső eredményként? Természetesen az összeset, egy konszenzus fa képében, amit például az Astral nevű program is elkészíthet. Kolinearitás garantált, fragmentált genom esetén is működik, közel rokon fajoknál is lesz elég távolság, mégsem viszünk mesterséges hibát a feldolgozásba. Természetesen ez a mószer a legmacerásabb, de szerencsére akadnak, akik nem riadnak meg tőle.

A kívülálló

Érdekes módon a progressiveMauve az általam ismert egyetlen program, ami elfogad bármilyen genomot, akár draft genomokat is, és tudásához mérten elvégzi az illesztést. Az előbb említettem, hogy több homológ szakaszt kell keresni, de baktériumoknál, ahol a horizontális géntranszfer tovább bonyolítja a helyzetet, néha azzal szembesülünk, hogy a homológ gének nem feltétlenül egy leszármazási egységre jellemzőek.

Ez a program viszont autómatikusan megkeresi a synteny blokkokat, meghatározza azok orientációját, létrehoz egy hierarhikus fát, amit vázként használ a precíz illesztéshez. Ez az úgynevezett "guided tree" meglepően korrekt fát hoz létre. A cikk és dokumentáció szerint nem használható filogenetikai elemzésre, de a kollégáim szerint az eredménye nagyon egybevág a biológiával, legalábbis az eddig vizsgált bakteriális genomok esetén így volt.

A módszer hátránya, hogy régi a  kód, nem használja ki a többmagú processzorokat. Másik hátránya, hogy bakteriális genomoknál hosszabb szekvenciák illesztése rengeteg időt vesz igénybe.

A mai világban nem elég, ha jó szakember valaki, innovátornak kell lennie. A pszichológus is life coach, ha ki akar törni a szürke munkások hadából. Ha pedig rájön valaki, hogy a súlyokat máshogy is lehet emelgetni, akkor azonnal egy többlépcsős tanúsitvány rendszert segítségével biztosítja, hogy csak ő adhassa tovább a tudást. Mindhárom esetben el kell jutni arra a szintre, hogy sok embernek mi, és csakis mi mondjuk meg a tutit, mert csak akkor leszünk valakik. Ez pedig szükségszerűen versenyhelyzethez vezet.

Erre két módszer van, hogy ezt elérjük. Az egyik, hogy hosszú évek munkájával, folyamatos fejlesztéssel eljutunk erre a szintre, miközben szép lassan, ezzel párhuzamosan növekszik a reputációnk is. A másik módszer egyszerűbb: felvesszük a "megmondó ember" attitűdöt, és becserkésszük azokat, akik elhiszik ezt. Vagyis jó hangosan, minél szélesebb közösségnek kell nagyon magabiztosan eladjuk magunkat.

Bárkit megkérdeznénk, biztos vagyok benne, hogy az első csoportba sorolná magát. De ha elolvassuk a Twittert, Facebookot, valahogy mindig a második csoport kerül túlsúlyba. Én ugyanis ennyi hülyeséget még nem hallottam, mint amennyi a COVID-19 kapcsán előkerült.

Az 5G hálózatok, mint a vírus terjesztői, vagy az ellenanyagba rejtett mikrochip kezdetű teóriákon nem akadok fenn. Ezek szerintem teljesen természetes velejárói annak a sokknak, amit egy globális terjedésű vírus az emberiségből kivált. Bármilyen megdöbbentő eseményre jobb válasz az, hogy valaki "csinálta", mint az, hogy ilyesmi spontán megtörténhet. Ennek elemei az életkor korai szakaszaiban is megmutatkoznak. Az emberekben kialakuló világkép fejlődésének is van egy olyan szakasza, amikor azt gondolják a gyerekek, hogy mindent a "bácsik" csinálnak. Miként jön létre egy folyó? Jönnek a bácsik, és kiássák a medret. Később, persze helyére kerülnek a dolgok, de vannak, akiknél szerintem ez megmarad később is. Miként csapódik egy utasszállító egy felhőkarcolónak? Jönnek a gyíkemberek és a CIA segítségével megcsinálják.

Szerintem ezzel nincs is semmi gond, nem lehetünk minden tulajdonságunkban egyformák. Egyesek nem tudják lefutni a Maratont, mások meg nem tudnak elszakadni az összeesküvés elméletektől. A probléma szerintem nem ez.

Még az sem olyan nagy gond, ha olyan összefüggéssel számolják ki a vírus riasztás szintjét, amiről egy általános iskolás is látja, hogy értelmetlen. Bár ez már jelez némi hozzá nem értést, de mivel ezekről minden értelmes ember látja, hogy hülyeség, egy globális nevetésen kívül nagyobb bajt nem okoz.

A probléma ott kezdődik, amikor azok az emberek kezdenek el hülyeségeket mondogatni, akiknek az a feladatuk, hogy gondolkodjanak. Mert jelen pillanatban ez történik. A preprint szervereket például elárasztották a koronavírus szakértők. Hol voltak eddig? Talán a föld alatt, és onnan másztak elő a Necronomicon hívó szavára?

Például tessék megnézni mindenki kedvenc vitaminját, a C vitamint. Időről-időre eszébe jut valakinek, hogy ezzel váltsa meg a világot, ezért nem meglepő, hogy a hülyeségcunami első hullámával azok a híresztelések érkeztek, hogy a C-vitaminnal megálljt lehet parancsolni egy vírusnak. Még az influenzát sem állítja meg, de Pauling szelleme olyan erős, hogy ötven évvel a halála után is hisznek neki.

Ez a "régi jó dógokhoz" való visszanyúlás figyelhető meg a hidroxiklorokin esetén is. Lépten-nyomon bizonyítják, hogy teljesen hatástalan, de még mindig vannak orvosok, kutatók, akik újabb esélyt adnak neki, sőt cikket írnak belőle. Ha egy vadat lelőnek, ott kell hagyni döglötten, nem rugdosni előre, miközben hangosan kiabáljuk, hogy "még mozog, biztosan él".

Ha valaki hülyeséget mond, akkor nem védi meg a hírnév, a szakmai múlt és a számtalan kitüntetés. Ez történt ugyanis John Ioannidissel is. Évtizedeken keresztül, kérlelhetetlen alapossággal kutatta a módszertani buktatókat és leplezett le kutatókat. A felesége ráadásul a fertőző betegségek szakértője. Ketten együtt sikerült akkora batár nagy marhaságot összeírniuk, hogy az már fájt. Persze a szakmai közösség rákapott a cikkre, mint éhes pitbull a csupasz lábszárra és ennek megfelelően szét is cincálták az egészet. Pontosan azt csinálták vele, mint amit ő is csinált éveken át mások munkájával.

Igazából, ha valamiben nem vagyunk teljesen biztosak, jobb csendben maradni. Bevallom, nekem is sok téves elképzelésem volt a vírussal kapcsolatban, de sikerült megállnom, hogy ne csináljak hülyét magamból mindenki szeme láttára (bár más fronton biztosan találni egy-két ellentmondást az írásaimban). Igaz, rajtam nincs is nyomás, hogy követőket szerezzek és belőlük éljek.

Aki viszont kimondja véleményét ország-világ előtt, az óhatatlanul is állíthat hülyeséget. Történt ez Steve Salzberggel is, aki a saját szakterületén szerintem hasonló kaliberű ember, mint Ioannidis. Neki az fájlt, hogy ha 300 ezer embernek be lehet adni egy kísérleti gyógyszert, mert annyira biztonságos, akkor miért nem adhatnák be mindenkinek?

Viszont van egy nagy különbség Ioannidis és Salzberg között. Előbbi szaladt fűhőz-fához, hogy a többiek csúnyát mondtak rá. Lobogtatta a ráaggatott plecsniket, hogy ő márpedig valaki. Még ekkor sem volt képes elfogadni, hogy leszerepelt. Salzberg viszont felül tudta bírálni korábbi álláspontják, és képes volt elismerni, hogy tévedett. Ehhez is erő kell, egy olyan világban, ahol mindenki azt várja el, hogy a szakértők tévedhetetlenek legyenek. Ez legalább olyan fontos, mint "megmondani a frankót".

Először is le kell fektetnünk, mit értünk szokatlan programozási e nyelvnek, hiszen az itt bemutatott nyelvek évek óta léteznek, ismertek. Lehet, hogy a ritka programozási nyelvek megfelelőbb cím lett volna.

Ami miatt mégis ezt a címet választottam, az a tény, hogy a tudományban is vannak divatok. Egy időben mindenki Perlben írta az aktuális okosságot, manapság inkább Python a menő. A C és C++ jelenlét konstansnak tekinthető, mert az elemzések gerincét végző programokat ebben írták, írják. Emellett előfordul az R és a Java. Előbbi a Bioconductor miatt, utóbbi platform függetlensége miatt. (Vagy mert a fejlesztők még abból az időből származnak, amikor a Java még menő volt.)

Azonban a nyelvek skálája szélesedett. Már nem csak olyan nyelvek vannak, amelyek a C-t, vagy a Java-t majmolják. Vannak olyan nyelvek is, amelyek új kihívásokra keresik a megoldást. (Eközben többen a Pythont majmolják, de ez már más kérdés.)

Vegyük például a Rust-ot, ami a biztonságos kódot tűzi zászlajára. Ez egy olyan cél, ami a bioinformatikában - ahol a kódminőség hagy némi kivetnivalót maga után - tényleg hasznos lehet. Az egyik programmal a BaseSpace-ről lehet letölteni adatokat, a másikkal a FastQ fájljainkat ellenőrizhetjük. De a 10x Genomics genom összerakó programjának, a Supernovanak is van egy Rustban írt része. Az egy sejtes genotípizáló eszközüknek a Vartrixnek viszont már sokkal nagyobb részét fejlesztették ebben a nyelvben.

A másik terület, ami a kódbiztonság mellett igen fontos a bioinformatikában, a többszálú feladatvégrehajtás. A Go nyelv pontosan ezt célozza meg. Nem meglepő, hogy létrejött a BioGO. A 10x Genomics ezen a nyelven is fejleszt, például a Lariat illesztőjüket. Rajtuk kívül a Grail nevű, korai tumor diagnosztikával foglalkozó cég használja előszeretettel a nyelvet, elsősorban a felhős infrastruktúra felügyeletére.

A harmadik bemutatott nyelv a Nim, amit Brent Pedersen használ előszeretettel. (Félelmetes programozó, érdemes követni a munkásságát) Ha egy mondattal szeretném bemutatni, akkor azt mondanám, olyan Python, ami natív kódot eredményez. A fordító érdekessége, hogy képes JavaScriptre is fordítani, amivel a webre költözést oldhatja meg egyszerűen a fejlesztő.

Heng Li pedig több nyelvet is összehasonlított, hogy melyik felel meg legjobban a következő projektjéhez. A fenti nyelvek mellett Crystalban is írt programot. Ezen kívül nem tudok más bioinformatikai projektet, amit ezzel a nyelvvel fejlesztettek volna.

Nem muszály és nem is érdemes egy nyelvnél leragadni, ha genomi adatokat akarunk feldolgozni. Itt is van fejlődés, még ha ez nem is olyan látványos, mint egy startup cégnél.

Bevallom, engem nagyon frusztrált, hogy sok ember vért izzadt, hogy a vírust megállítsák (vagy elviselhetővé tegyék a megújult helyzetet másoknak), miközben nekem a legfontosabb munkahelyi teendőim között az szerepelt, hogy a Dropbox mappámból fájlokat töröljek ki, hogy a megosztott tartalmak ne lépjék túl a mágikus 2GB-os határt.

Arra gondoltam, ha nem is tudok intubálni, talán az évek során összegyűlt annyi bioinformatikai tapasztalatom, hogy azt valamiképp mások rendelkezésére bocsáthassam. Ezért javasoltam a főnökömnek, hogy vegye fel a kapcsolatot a hazai COVID-19 csapat bioinformatikai fejeseivel.

A kapcsolat nagyon gyümölcsöző volt, mindkét fél sokat tanult a másiktól, kemény megfeszített munkával véghezvittük a lehetetlent és a megszerzett tudást az emberíség javára fordítottuk. Eközben egy kis bioinformatikus, akit mindenki lenézett, végül hőssé vált.

Ez a Disney-féle verzió. A valóság egy kicsit más volt, még erről az alsó szintről nézve is, ahol én vagyok.

Először elindult valami kollaboráció-féleség. Azt mondták, hogy szükségük lenne egy szerverre, ami vizuálisan megjeleníti az egyes virus genomok egymáshoz fűződő viszonyát. Valahogy úgy, ahogy a Nextstrain csinálja. Mivel a Nextstrain szerver felépítése teljesen nyitott, még tutorial is van, hogyan építsünk egyet saját magunknak, ezért szépen le is másoltam.

Az egész SSH kapcsolaton keresztül volt elérhető, viszont a vírus törzsek letöltése elég nehézkes volt, ezért nem is álltam neki, amíg nem pontosítjuk a célokat. A másik, ami megállásra bírt, hogy a Nextstrain szerveren saját elemzéseket is lehet definiálni, amiről szintén nem beszéltünk. Az elérhetőségeket elküldtem, és vártam, hogy mi lesz a következő lépés. Szokás szerint jött a Nagy Kuss.

Akkor tudtam meg, hogy a kollaboráció - ami létezett is, meg nem is - véget ért, amikor megláttam a megjelent kéziratot. Vagyis, valaki velem párhuzamosan megcsinálta ugyan azt. Illetve többet is, mert ott megvolt az összes törzs, és a teljes elemzés is.

Valami olyan homályos indoklás jutott vissza hozzám, hogy a magyar vírusoknak nem szabad publikus szerveren lenniük. Nem értem, mit titkolóznak, különösen, hogy az általam készített szerver nem volt publikus, csak az láthatta, akinek hozzáférést adtunk. A fenti kézirat is úgy tudott megszületni, hogy mások évek óta fejlesztik a Nextstraint, mások megosztják a teljes vírus genomokat, erre mi, Magyarok eldugjuk ezt a pár genomot, mert ez aztán az innováció melegágya. Mitől félnek annyira? Valaki megnézi őket, és levonja azt a következtetést, hogy a Magyaroknak még a koronavírusaik is szánalmasak? Emberek személyiségi jogai rendben vannak, de most egy olyan vírusról van szó, amit mindenki ki akar nyírni.

Persze mások is szerettek volna némi bioinformatikai kollaborációt. A Magyar Bioinformatikai Társaság egy körlevélben próbálta feltérképezni (az EBI hatására), ki milyen erőforrást tud felajánlani ehhez az új keresztes háborúhoz. A felmérés kimenetele ismeretlen számomra, de annyit tudok, hogy az ELTE büszkén hívta fel a figyelmet erre a kezdeményezésre, amiben részt vesznek.

Milyen érdekes, ez is az adatok megosztásáról szól, nem arról, hogy egy barlang mélyén kell gyönyörködünk művünkben, miközben azt mormoljuk: "Drágaszágom".

Szuperszámítógépes környezetben gyakran találkozunk a module load paranccsal, ha egy szoftver komponenst akarunk használni. Mi ez a parancs, mire tudjuk használni és hogyan fordíthatjuk saját hasznunkra?

A program nem csinál mást, csak a kiadott utasításoknak megfelelően kicseréli a környezeti változókat. Ez talán elsőre nem tűnik nagy dolognak, hiszen ott a Docker, Conda, de sok esetben egy virtualizációs megoldások csak elbonyolítják a helyzetet. Például képzeljünk el azt a felállást, amikor két olyan környezetet kell használnunk, ami két különböző Docker képfájlban van. De az is elképzelhető, hogy nem akarunk rendszergazdai jogokkal felruházni futó folyamatokat, mint ami a HPC környezetek esetén is tapasztalható.

A környezetek összevonása nagyon egyszerűen megy modules-al, de rosszul megtervezett modulok esetén továbbra is előfordulhatnak ütközések, míg Docker használatával ennek az esélye minimális.

A rendszer egyik gyengesége a Tcl/Tk környezethez való ragaszkodás, aminek történelmi okai vannak. Ez is csak azoknak jelenthet problémát, akik nem szeretik ezt az archaikus megoldást. Szerencsére létezik több alternatív rendszer, ami ezt lecseréli, például Lua-ra. Ebben a bejegyzésben csak a Tcl/Tk verziós megoldással foglalkozom.

Mivel elég régóta fejlesztett programoról van szó, az összes ismert csomagkezelőben megtalálható environment modules néven. Telepítés ezért gyerekjáték. Minden környezetet egy fájl reprezentál, amit Ubuntu esetén például az /usr/share/modules/modulefiles könyvtárban találunk alapértelmezetten. Általában nem érdemes nulláról kezdve megírni a fájlokat, inkább valamelyik, már létező fájlt kell módosítani, hogy a fájlok váza egységes legyen.

Milyen módon épül fel egy ilyen fájl? Először is kell egy #%Module, ami kínosan emlékeztet egy linuxos szkript fejlécre. Ez nem a véletlen műve. Utána jöhet egy verziószám.

A konvenció szerint ezután kommentek formájában érdemes egy rövid leírást adni magáról a modulról. Mivel csak ritkán olvassuk magukat a modul fájlokat, célszerű egy ModulesHelp függvényt is definiálni, ami szintén kiírja a szükséges információkat. Ezeket a modules help paranccsal jeleníthetjük meg.

Az összes többi bejegyzés szabványos Tcl/Tk utasítás. Készíthetünk ciklusokat, feltételes elágazásokat, bármit. A nyelv bemutatása túlmutat a cikk határain, ezért itt csak a legfontosabb dologra, a környezeti változók kezelésére koncentrálunk.

Bioinformatikai programok esetén az egyik legfontosabb környezeti változó, az elérési út, vagy "PATH". Amennyiben új elemet akarunk hozzáadni, az append-path parancsra lesz szükségünk. Utána a változó nevét kell megadni, amit Bash esetén a PATH, majd a hozzáadandó értéket, ami az elérési út.

append-path PATH "/home/user/mysoftware/bin"

Az adott modul eltávolítása után a bejegyzés is eltűnik. Tehát ha több környezetet használunk, és mindegyiknek saját bejegyzése van a PATH-ban, akkor a modul megszűnése csak az adott környezet bejegyzését törli.

A másik fontos parancs, az új környezeti változó felvétele, hiszen sok program azok alapján találja meg a konfigurációs állományokat vagy adatokat. A setenv parancs segítségével ezt érhetjük el. Szintaxisa nagyon hasonló az append-path-nál megismerthez. Először a parancs, majd a beállítandó környezeti változó neve, végül az értéke. A következő példa a STAR-Fusion számára állítja be az indexelt genom és a hozzátartozó annotációt tartalmazó könyvtár nevét:

setenv CTAT_GENOME_LIB "/usr/share/molbio/rna-seq"

Amennyiben készen vagyunk a fájlokkal, azonnal használhatjuk őket. A module load parancs segítségével betölthetjük az adott környezetet, csak a modul fájl nevét kell megadnunk. Ha már nincs szükségünk az adott környezetre, a module unload segítségével eltávolíthatjuk azt. Az elérhető modulok listáját a module avail mutatja meg.

Végezetül szeretnék pár megjegyzést tenni, amivel én szembesültem, amikor telepítettem és konfiguráltam a rendszert. Bash esetén nem szokott gond lenni, de más parancsértelmezők alkalmazásakor figyelni kell, hogy a modules inicializálása megfelelő legyen. Az /etc/profile.d könyvtárban található fájlok nem minden esetben futnak le, például zsh esetén. Nem megfelelő inicializálás esetén hiába vannak a modul fájlok a megfelelő helyen, azokat mégsem látja a felhasználó.

Ha több környezetet szeretnénk használni, akkor az environment-modules siet a segítségünkre. Segítségével átláthatóvá tehető a környezeti változók kezelése. Telepítése egyszerű, használata szintén. HPC környezetben előszeretettel használják, de saját rendszerünkre is telepíthetjük. Ez a bejegyzés nem érintett mindent, a program sokkal több lehetőséget rejt magában (például akár hierarhikusan is felépíthetjük a modulokat).

Az idei karantén világ egyik kellemes hozadéka volt a Just for fun compó, amit tényleg csak a móka kedvéért rendeztek. A releaseket interneten kellett elküldeni, majd egy YouTube streamen végignézni. Mivel az összes alkotásnak 30 másodperc hosszúnak kellett lennie, nem fenyegetett az a veszély, hogy elalszom közben, vagy a compó végére nem tudom, mit is láttam az elején.

Nem is tudom, hogy van-e értelme kritikát írni ilyen kompóról, ezért mindegyikről leírom, miért tetszett.

Az első a Transmission volt a The Bad Sectorstól, amit egy mikrokontollerre írtak. A mikrokontollerekre nehezebb kódot írni, mert sokkal több a limitáció. Mind a hardver felől, mind a létező eszközök részéről. Itt nem lehet azzal vádolni a készítőket. hogy az "OpenGL megcsinál mindent". Az Astroidea egy rég elfelejtett kódot adott be Astrocola néven. Ennek megfelelően 386-oson futott GUS alatt. Szerintem jó, hogy ezek a kódok még akkor sem vesznek el, ha nem adják ki őket, és ilyen ritka alkalmak egyikén láthatjuk mi is. Slyspy jó ötletet használt fel, mert egy régi Amigás demót elevenített fel vicces formában. Szerencsére a bemutatkozó videóból megismerhettük a demó hátterét is. A Dilemma Ocean's Drive azért volt jó, mert remek volt a hangulata és kellemes volt a zene is hozzá. Az Ümlaut Designtől szerintem egy trailert kaptunk, ezért nagyon felcsigázott, mit is akarnak bemutatni Function-ön. (Legalábbis azt gyanítom, hogy Function-ön mutatják be. Belsős információval nem rendelkezem.) A Rebels Function invitációja kihasználta a 30 másodperces limitet. A normál tempójú felvezetés után az összes part fél másodperc volt, és ennek megfelelően kedves kakofóniába torkollott. A The Bad Sectorstól kaptunk még egy demót, ami azért volt jó, mert Blueghost visszatért és új effektet használt, amit még soha azelőtt, ergó fejlődött.

Végül a demo1 tiborsaas-tól, ami azért is jó, mert első demó, rögtön győzelemmel. Az effektek teljesen rendben voltak, a zene passzolt a látványhoz. Reméljük még sok remek alkotást láthatunk tőle.

Rövid válasz: nem igazán.

De miért? Először is, mit értünk zenélés alatt? Itt azt értem, hogy digitális hangszerekkel csak egy program segítségével az ötlettől a kész megvalósításig el tudunk-e jutni. Valahogy úgy, ahogy Windows alatt az FL Studioval, Abletion Live-al zenét készít az ember.

Linux alatt az egyetlen szóba jöhető program az LMMS. A program maga csodálatos. Tényleg hozza azt a minőséget és tudást, amit az ember elvár egy Linuxos programtól, miután megnézte a több éves múltra visszatekintő Windowsos alternatívákat. Ha el tudjuk fogadni a Gimpet Photoshop helyett, ha megbírkózunk a Blenderrel 3D Studio után, akkor az LMMS-el sem lesz gondunk.

A főbb részegységek itt is megvannak, az elérhető funkciók, ha nem is érik el a konkurensek színvonalát, de működnek, a felhasználói felületet pedig meg kell szokni. Ismerős a recept? Nem csoda, hiszen szóról-szóra ugyan ezt lehet elmondani a többi Linuxos tartalom készítő alkalmazásról is.

Akkor mégis mi a probléma? A probléma, a VST bővítményekkel vannak.

Az LMMS beépített zajforrásai hangszerei egyszerűen nem hangzanak jól. Bármit is csinál a felhasználó, úgy szólnak, mint egy bolhapiacon vásárolt gyerek szintetizátor. Még talán a GUS midi hangszerek, amelyek valamennyire elviselhetőek, de ez kevés szerintem.

A megoldás, hogy harmadik féltől származó hangszereket kell importálni a programba, és használni őket orrvérzésig. Ezek a VST pluginok. Gyakorlatilag azok a programok, amelyek nem kezelik a VST pluginokat, közröhej tárgyai. Ezért az LMMS is szépen beolvassa őket. Hurrá, akkor mi a probléma a bővítményekkel?

A probléma ott van, hogy programozói szempontból a VST plugin egy futtatható bináris fájl. Tehát minden oprendszer alá saját verzió kell, ami gyakorlati szempontból azt jelenti, hogy egy Windowsos bináris fájl GUI-val. Persze, van Mac és Linux alá is mutatóba valami, de többségében csak Windows alá van minden. Ezt vicces kedvű fejlesztők ki is használják és szükségtelen elemekkel tűzdelik tele azt. Bár egy profi még ezzel is tud kezdeni valamit:

De még ezzel sem teljesen lehetetlen a Linuxos LMMS használata, mert a Wine segítségével betölthetőek. A folyamat úgy néz ki, hogy az LMMS a VST előtt megpróbálja betölteni a Wine-t, aminek az inicializálása elég sok időt elvesz. A VST plugin időtullépés miatt dob egy hibát, a Wine összeszedi magát, elindul, és megjelenik a VST bővítmény felülete. Mazohisták ezt szokták használni, ha épp nincs a kezük ügyében szöges korbács.

Mindez eszi a memóriát, fogyasztja a processzort, és növeli az ősz hajszálak számát.

Arról nem is beszélve, hogy CentOS alatt csomagkezelőből nem is lehet felrakni. Az extra repoban megvan, de egy függősége nincs rendesen beállítva, ezért nem települ. Ubuntu alatt szépen felmászik a gépre, még a Wine-t is könnyedén lehet konfigurálni. Onnantól viszont nagyon elkeserítő, hogy csak pittyeg az egész.

Sajnos már nem emlékszem ki mondta, de egy demópartin elhangzott, hogy nem is az számmít, hogy milyen programot használunk, hanem milyen sample-ök vannak. Azt hiszem ez nagyon igaz.

Mivel a Minixel nem sok mindenre voltam képes a 20 éves laptoppal, arra gondoltam, kipróbálhatnék egy olyan rendszert is, ami több sikerrel kecsegtet. Ezért az elfekvő CD-im közül kiválasztottam egy Slackware 10-t. A későbbi verziókat már DVD-re írtam, a laptop pedig csak CD-t olvas, ezért a lehetőség adott volt.

A telepítés olyan volt, ahogy egy ilyen rendszertől megszokhattuk, illetve ahogy már megszoktam az évek során. Bebootol, és odadob minket egy parancssorba, ahol kézzel elvégezhetjük a partícionálást és aktiválhatjuk a swap területet. Utána a telepítő segítségével már beállíthatjuk a billentyűzet kiosztást, hálózatot és a felmásolni kívánt csomagokat.

A teljes rendszer 2.8G tárhelyet emésztett fel, ebben csak a KDE nemzetközi csomagok nem voltak benne. Grafikus felülettel 40MB memóriát evett, ami mérsékelt. A CPU használat 20% körül volt. Elég jól működött.

Végre meghallgathattam a laptop hangkártyáját működés közben. A doksi szerint Sound Blaster kompatibilis a hangkeltő eszköz, de FreeDOS alatt valami miatt mégis némák voltak a hangszórók (azóta találtam egy potenciális megoldást, majd kipróbálom). Már attól féltem, elromlott valami. A korai időkben a hangkártyát a felhasználónak kellett beállítani az Alsa programjait használva. Emlékszem, régen ezzel sok problémám volt, de most nagyon simán ment, magam is meglepődtem, hogy milyen hamar felcsendült a zene. Szóval zenehallgatásra lehet használni, bár a merevlemezen már csak 900MB hely van, ami nem sok demóparti zenei anyagát tárolhatja.

A fejlesztéshez van C, C++, Fortran, Perl, Python (de még csak a 2.2 verzió). Programozási házi feladatokat azért lehet csinálni rajta, az algoritmusok fejlesztését is gyakorolhatja rajta, aki akarja. Sőt, annak idején még a Java-t is szabadon terjeszthette mindenki, ezért találunk még a Sun idejéből való Java 1.4-t is.

Megnézhetjük a PDF állományokat, ami cikkek olvasásához hasznos. Kényelmesebb lehet, mint sok telefon képernyője.

Van egy teljes Tetex rendszer, úgyhogy tudunk írni könyvet, cikket, disszertációt LaTeX-ben. A magyar ékezetek használata kicsit nehézkes lehet, mert nincs teljes unicode támogatás, de a feladat nem lehetetlen.

Kipróbáltam, tudok-e szkennelni vagy nyomtatni az egyetlen 1.0-s USB csatolón keresztül, de nem sikerült. A Postscript nyomtatókat azért több erőfeszítéssel be lehetne állítani, de nem voltam elég kitartó.

Megpróbáltam netet is csiholni egy mobiltelefon segítségével, de az USB-s eszközt nem tudtam megetetni az ifconfiggal. Feltételezem egy kernel modul hiányzik. Mondjuk ha működne is a net, nem sok hasznos funkciót tudnánk elérni. Böngészőnek Netscape van, az SSH kliens teljesen elavult, bátrabbak IRC-hetnének, vagy FTP-ről tudnának letölteni.

LibreOffice teljesen hiányzik. Nem csak azért, mert ebben az időben még OpenOffice (StarOffice) volt a neve, hanem azért is, mert a Slackware-ek Abiword és Gnumeric fanok voltak.

Mivel a Linux játékok szempontjából ez idő tájt elég gyatra volt, ezért csak sakkozni próbáltam vele, de a grafikus felületű sakkprogram képtelen volt csatlakozni a gnuchess-hez. Szerintem a probléma nem teljesen orvosolhatatlan, ezért elméletileg sakkpartnernek is lehetne használni a gépet.

Gimp is van, de a mai digitális gépek felbontását figyelembe véve maximum egy animált GIF compóra elég a gép teljesítménye (Revision-ön szokott lenni).

A rengeteg hátrány ellenére ez volt az első rendszer, amivel potenciálisan alkotni is lehetne valamit. (Bár a FreeDOS-al készítettem az első 256 byte intrómat, ami valódi, kézzelfogható eredmény.)

A demoscene egy remek hobbi, de egy idő után nagyon bele lehet bonyolódni, ami alatt azt értem, hogy indokolatlan mennyiségű időt és energiát lehet beleölni, az eredmény láttán mégis sokan csak fanyalognak. Például: ezt az effektet már láttuk X évvel ezelőtt. Esetleg: ezt meg lehet csinálni sokkal kisebb méretben is. De még olyan is előfodrulhatm, hogy azzal vádolnak meg, hogy nem kódolunk semmit, mert Y jatékmotort használtuk. Nem csoda, hogy sokan nem produkálnak semmit, még akkor is, ha megvan a megfelelő tudásuk hozzá.

Időről-időre emlékeztetni kell magunkat, hogy ez az egész mégis csak egy hobbi, amit azért csinálunk, hogy jól érezzük magunkat. De akkor is sok időt kell ráfordítani.

Ezért is jó a most következő Just For Fun compó, ahol összesen 30 másodperc időt kell feltölteni. A release mérete pedig nem lehet 16 MB-nál nagyobb. Tehát nem kell vért izzadni, hogy telenyomjuk a demót részletes tartalommal, mert nincs rá hely. Nem kell több száz effektet kitalálni, mert nincs idő rá, hogy bemutassuk. Optimalizálni sem kell, mert nem muszály beleférni 64k-ba.

Szóval, akinek van kedve, nyugodtan kipróbálhatja magát, a lényeg, hogy jól érezzük magunkat, és alkossunk. Részletes kiírást itt találhatunk.

A Bioconductor remek kezdeményezés, a bioinformatikai elemzések egységes platformja, ahol könnyedén új komponensekkel bővíthetjük a rendszert. Nemcsak szoftver, hanem adat oldalon is bővíthető a rendszer, hiszen a különböző annotációk ugyan olyan fontosak a bioinformatikai munka során, mint az algoritmusok. De mi a helyzet, ha a vizsgált faj annotációja nem létezik a Bioconductor égisze alatt? (Tipp: nézzük meg a blog mottóját.)

Bizony, a Bioconductor amilyen hasznos szolgálatot tesz a humán és egér vizsgálatoknál, olyan használhatatlan más fajoknál. Pedig az EnsEMBL, UniProt, KEGG tele van rengeteg fajjal, csupán azt kellene megoldani, hogy ezek az adatok szabványos formátumban legyenek, hogy aztán a programok felhasználhassák azokat.

Szerencsére nem kell nulláról kezdeni a munkát, a Bioconductor ahhoz is segítséget ad, hogy elkészíthessük ezeket a csomagokat. Lássuk, hogyan is kell hozzákezdeni egy ilyen munkához.

A két legfontosabb csomag, amit használni fogunk, az AnnotationHub és az AnnotationForge. Ha szerencsénk van, csupán egyetlen parancsot kell kiadnunk:

makeOrgPackageFromNCBI(version="0.1", author="Travis <travis@fake.com>", maintainer = "Travis <travis@fake.com>", outputDir = ".", tax_id = "60711", genus = "Chlorocebus", species = "sabaeus")

A legfontosabb paraméter a tax_id. Ez alapján fogja ugyanis a rendszer az NCBI-ról letölteni az adott fajhoz tartozó adatokat. Ami még sok fejfájástól kímél meg minket, ha követjük az annotációs csomagok formátumára vonatkozó ajánlásokat. Például a csomag szerzője után <> közé az email címet is meg kell adni. Letöltés után mindent egy SQLite adatbázisba pakol, majd elkészíti a megfelelő csomagot. Ezt telepíthetjük is:

install.packages("./org.Csabaeus.eg.db/", repo = NULL, lib = "/usr/lib64/R/library")

Az utolsó paraméter nem kötelező, és szükség van írási jogra az adott könyvtárra. Sok esetben ennyi elég is. De, mint ahogy a tapasztalatok is mutatják, ritkán van jó napunk, a legtöbb esetben ennél többet kell dolgozni.

Ilyenkor nekünk magunknak kell a megfelelő adattáblát letölteni, majd formázni. Letölthetjük őket a BioMart-ból, UCSC-ből, vagy egyéb forrásból. Először is azt kell eldöntenünk, mi lesz az elsődleges azonosító. Ez lehet az NCBI vagy az EnsEMBL gén azonosító. Ez azért lesz fontos, mert minden adattáblánk ezen azonosító szerint lesz összekötve. Ez minden táblában az első oszlop kell, hogy legyen, és GID legyen az oszlop neve.

A második legfontosabb lépés, hogy mindegyik táblának, amit az adatbázis építéshez használunk, legyen értéke minden oszlopban. Sok esetben ez nem megvalósítható, ilyenkor célszerű a táblát több al-táblára osztani. A fejléc bármi lehet, de az első oszlop mindenképp a GID kell, hogy legyen.

Amennyiben GO adatokat is szeretnénk, úgy annyi megkötés van, hogy a táblánk három kötelező oszlopot kell, hogy tartalmazzon: GID, GO, EVIDENCE. Az első a gén azonosítónk, a második a GO azonosító, a harmadik pedig a bizonyíték, ami alapján a gént az adott ontológiával összekötöttük. Ezen felül bármilyen további mezőt megadhatunk.

Ha készen vannak a tábláink, el kell készíteni a csomagot:

makeOrgPackage(version="0.1", author="Travis <travis@fake.com>", maintainer="Travis <travis@fake.com>", outputDir=".", tax_id="60711", genus="Chlorocebus", species="sabaeus", ensembl=enstable, ucsc=ucsctable)

A paraméterezés megegyezik a makeOrgPackageFromNCBI-al, de kiegészül az egyes táblák nevével, ami a példában enstable és ucsctable néven szerepel. Megkötés nincs. Az elkészült csomagot a korábban bemutatott módon telepíthetjük.

Természetesen egy létező csomagot is vehetünk alapul, ha nem akarunk mindent más forrásból letölteni. Először érdemes megnézni, milyen adatok érhetőek el az AnnotationHub-ban. Ez az annotációs csomagokat kívánja egyesíteni egy kereshető formában. Használata számomra kicsit szokatlan volt, de cserébe egyszerű.

ah <- AnnotationHub()
res <- query(ah, c("go", "sabaeus"))
mydb -> res[[4]]

A query parancsnak bármennyi kulcsszót megadhatunk, ezek ÉS kapcsolatban lesznek. Az eredmény egy lista azokkal az adatbázis azonosítókkal, melyek megfelelnek a keresési kritériumoknak. Az adatbázis elérhető mezőiről az mcol parancs ad felvilágosítást. További részletekért érdemes megnézni az AnnotationHub dokumentációját.