HTML

Az élet kódjai

Csináld maga. Senki nem csinálja meg helyetted.

Friss topikok

  • Travis.CG: @webhauser: Én nem vagyok jó programozó. Nem vennéd sok hasznomat. (2025.09.18. 10:26) T0ad 2025
  • Travis.CG: Annyiban én is hibás vagyok, hogy könnyen előjönnek belőlem negatív posztok, ezt akartam ellensúly... (2025.05.22. 19:34) Ne csak a rosszat halljátok
  • sdani: Oh... néha eszembe jut, hogy az EBI után esetleg vissza kellene menni valamennyire az akadémiai vo... (2025.03.18. 16:58) Pontos, jól behatárolt célok
  • legyen úgy: Szia, Értem és köszönöm a válaszodat! T. (2025.02.24. 18:23) Expose CTF
  • sdani: Sajnos nekem is hasonló érzéseim vannak az R kiszorulásával kapcsolatban. Remélem jobban fogja tar... (2024.04.29. 10:48) R meetup

Borban az igazság

2022.08.28. 21:15 Travis.CG

Ide első publikációm két élesztő hibridről szólt. Az egész úgy kezdődött, hogy elhívtak egy megbeszélésre, ahol arról megtudtam, hogy izoláltak két Saccharomyces törzset, amelyek az elsődleges vizsgálatok alapján hibrideknek tűntek. A feladat a szülő fajok azonosítása lett volna.

A témát két részletre bontottuk, hogy még több cikkünk legyen, és minden cikkben mindenki szerepel, mert ki ne örülne még potya publikációknak? A most megjelent cikk inkább az élesztők által készített bor fizikai tulajdonságokról szólt, nem az élőlények genetikájáról (ami később fog megjelenni), ezért eredetileg úgy tűnt, nem is lesz szerepem benne. A bírálók viszont máshogy gondolták.

Történt ugyanis, hogy a kézirat első verziója után plusz kísérleteket kértek, amitől a szerzők száma megemelkedett. Azt is kritizálták, hogy a fizikai tulajdonságokat elemző ANOVA túl nagy szórást mutatott, ami állítólag rendes fermentálás esetén nem szabadna, hogy bekövetkezzen.

Ezt úgy oldották meg, hogy a 3 ismétlésből kivették a kiugró értéket, és újraszámoltattak velem mindent, mert én tudok for ciklust írni R-ben. Úgyhogy az én munkám egyetlen nagy ANOVA táblázat elkészítése volt. Arra számítottam, hogy a kisebb adatmennyiségen fenn fognak akadni a bírálók, de nem tették. Ebből is látszik, hogy ha a bírálóknak megírod, hogy javítottad, amit kértek, akkor már nem olvassák el újból, hogy hogyan is javítottad azt.

Kis kitérőként megemlítem, hogy tavasszal pont ezzel a módszerrel akartak átverni egy cikket rajtam, amit bíráltam. Abban a cikkben kifogásoltam, hogy az RNA-seq nem tartalmaz párhuzamos mérést, mire azt válaszolták a szerzők, hogy azt a módszert alkalmazták, amit XY et al. 2019-ben. Dobtak valami csontot a kutyának, hogy elhallgattassák. Sajnos vettem a fáradságot, és elolvastam XY cikkét, amiben nyoma sem volt ismétlés nélküli RNA-seq-nek.

De térjünk vissza a mostani cikkhez. Egy másik táblázatból is kellett volna ANOVA-t számolni, de ez végül mégsem számoltam, mert nem találták az eredeti adatokat! Mai tanúságunk, hogy ha van egy szakdolgozónk/PhD hallgatónk, akkor a nyers adatokat ne hagyjuk náluk úgy, hogy nálunk nincs belőle másolat. Az eredeti, nyers adatok a kincsek. A belőlük készült színes-szagos Excel tábla nem kincs, csak egy eredmény. Azt újra lehet generálni. A nyers adatért viszont meg kell szenvedni, azt nem könnyű pótolni.

Miután kijavítottunk mindent, amit kértek, elfogadták a cikket, de még nem ért véget a tortúra. Maguk a formai változások is három vagy négy revíziót éltek meg, amivel a levelező szerző igencsak megszenvedett, mert szűk határidőket szabtak, miközben mindenki szabadságon volt. Minden második levélváltás az editorokkal arról szólt, hogy haladékot kérjen nekünk.

Szerencsére megértőek voltak, úgyhogy minden elkészült. Nem valószínű, hogy ezeknek a hibrideknek a hatására jobb borok fognak megjelenni a piacon, de azért jó volt dolgozni a projekten. Remélem nemsokára azt is megmutathatom, hogyan dolgoztam fel a genomokat.

Szólj hozzá!

Címkék: publikáció

sudo finomhangolás

2022.08.21. 18:18 Travis.CG

A sudo parancs a legtöbb felhasználó számára egyet jelent a root-al. Egy kis kellemetlenségért cserébe (be kell gépelni, hogy sudo + jelszó) megkapjuk az isteni hatalmat a gép felett. Aki viszont veszi a fáradságot, az a beállításokkal nagyon részletesen előírhatja, hogy mennyit is kaphat valaki ebből a hatalomból.

A sudo beállításai az /etc/sudoers fájlban és az /etc/sudoers.d/ könyvtár fájljaiban található. Ez utóbbi azért alakult ki, mert a csomagkezelők előszeretettel írják felül a konfigurációs állományokat egy program frissítése során. A sudoers.d fájljai viszont értintetlenek maradnak.

A konfigurációs állomány szintakája nagyon egyszerű:

user host = (otheruser) cmd

A user lehet egy felhasználó neve, de akár egy csoport is, ha % jellel kezdődi. A host annak a gépnek a nevét jelenti, ahol a jogokat ki szeretnénk adni. Ez a megoldás lehetővé teszi, hogy egy sudoers fájlt több gép között is megoszthassunk. Az otheruser annak a felhasználónak a neve, akinek a nevében futni fog a parancs. Mint látható, nem muszáj root-nak lennie. Ha például az adatbázis felügyelet egy dedikált user nevében fut, akinek még home könyvtára sincs, akkor itt beállíthajuk, hogy a felhasználó ezen néven adatbázis műveleteket végezzen. A cmd a futtatni kívánt parancs. Mivel a sudo alapból nem ismeri a PATH-t, ezért célszerű teljes elérési utat megadni. A parancs esetén van egy érdekes dolog! Nevezetesen megadhatunk paramétereket is. Ezzel olyan érdekes helyzeteket hozhatunk létre, hogy a felhasználó nem tud tetszőleges paraméterekkel parancsot futtatni. Ha mondjuk egy felhasználónak csak egy szolgáltatás indítását és leállítását akarjuk engedélyezni, akkor a következő módon tehetjük meg:

dummy ALL = /sbin/systemctl start dummy.service, /sbin/systemctl stop dummy.service

Ebben az esetben a dummy felhasználó bármely gépen el tudja indítani a dummy szolgáltatást és le is tudja állítani. De az állapotát már nem tudja lekérdezni!

Ez így mind szép, de mi van, ha több host-ot, több felhasználót, netalántán több parancsot szeretnénk megadni? A konfiguráció során létrehozhatunk aliasokat. A Host_Alias a számítógépek neveit gyűjti egy azonosító alá. A User_Alias a felhasználókat. A Cmnd_Alias szerepe ezek alapján már egyértelműen beazonosítható.

Az aliasok felépítése is nagyon egyszerű:

User_Alias DB = adam, eve

Tehát a DB alias alatt adam és eve fog szerepelni. Az így definiált aliasokat utána használhatjuk a fenti struktúrában.

Azt is szabályozhatjuk, hány esetben kelljen beírni a jelszót. Ha a kiadni kívánt parancs előtt szerepel a NOPASSWD:, akkor a jelszó beírása nem kötelező, ami szkripteléskor jön jól.

Ez persze még mindig csak a jéghegy csúcsa. Nem említettem a reguláris kifejezéseket, környezeti változókat, stb. Aki még mélyebbre szeretne ásni a témában, itt teheti meg.

Szólj hozzá!

Címkék: rendszergazda

Cseppet sem objektíven: Assembly 2022

2022.08.18. 15:05 Travis.CG

Majdnem lemaradtam az idei Assembly-ről! Mindenre úgy rákészültem, mégis az utolsó pillanatban majdnem lemaradtam. De úgy látom, mások is.

Remélem ez nem egy trend része, de a Revision és a QBParty után az Assembly is visszafogottabb volt, mint korábban. Remélem a Function fogja megtörni a jeget. De addig is lássuk, mit kaptunk idén.

A zenei és grafikai compókra nem lehetett panasz, elég induló is volt, és végignézve a mezőnyt, a felhozatal sem volt rossz. Zenéből négy kategória is volt: Dance, Fast, Listening, Tracked. Tulajdonképpen nem is tudom, mi a különbség a Dance és a Listening között. Egyszer majd utánajárok.

A gyors zenék közül egyedül Melod száma tetszett, de ezzel úgy tűnik egyedül voltam, mert csak a 10. helyezést érte el.

Egyik kedvenc zenészem, Aikapallo kivételesen szakított a metálos hangzással, de az új stílusa is megkapó. Nem tudom, hogy ez egy kísérletezés eredménye, vagy erre a vonalra szeretne ráállni, de jó volt hallgatni.

A grafikák is népes számban képviseltették magukat. A fast graphics esetén kivételesen nem egy firkát kellett értelmes képpé varázsolni, hanem egy témát adtak, a szavazást. Bár voltak ügyes témák, a legtöbb kép nagyon nyers volt. Sajnos a scene.org FTP-jén nem volt fenn az összes kép, de amiket láttam, azok közül a Get free oil volt a legjobb (ami valami miatt Vote for roboboy néven található meg, de ezen nem kell fennakadni).

A Freestyle grafikák már nem tűntek félkész munkáknak. A résztvevők száma is viszonylag kevés volt. Darkki első helyezett képe nagyon megkapó. Torony magasan nyert is.

A videók idén nem voltak túl jók. Általában ezekkel szoktam a releasekre hangolódni, mert könnyű megnézni őket, és többnyire szórakoztatóak. Gyanítom, az in-game videóra nem készültek sokan, mert összesen egy induló lehetett, azt pedig áttették ebbe a kategóriába. Mivel nem ismerem a játékot, ami a videó alapjául szolgált, ezért nem is értettem az egészet.

A futtatható alkotások láthatóan hátrányban voltak az előző évekhez képest. A régi hardverek kedvelői nem valószínű, hogy emlékezni fognak egyetlen indulóra is. A változatosságra nem lehetett panasz: volt DOS, C64, Amiga és Gameboy demó is. A megvalósítás viszont uncsi volt.

Az 1k indulókkal nem találtam meg a hangot. Több helyből gazdálkodhatnak, mint egy 256b, mégis az embernek olyan érzése van, mintha kevesebb lehetősége lenne az indulóknak. Például biztos nehéz volt megoldani, hogy a JS intrók menjenek ebben a mérettartományban, de az eredmény mégis kevésnek hat. Olyanok voltak, mint a Linux intrók. Tök nehéz összehozni őket, az eredmény mégis lesújtó.

A 4k intrók sem villanyoztak fel. Mondjuk, a második helyezett be is vallotta, hogy előző este összedobott valamit, majd beadta. Egy kisebb hazai partin látni ilyeneket nem lenne gond, de ez az Assembly és most ünnepelték a 30 éves fennállásukat!

Volt egy öszvér compó is wild screen néven, amiben voltak demók, videók, képek. Ennek a kategóriának a létére nem jöttem rá. Ettől az oldalaránytól csak azok élvezhetik ezt, akiknek ilyen széles monitoruk van. A halandók alig látnak belőle valamit. De legalább volt HBC demó. Örülök, hogy a csapat nem adta még fel.

A kegyelemdöfést a PC demók adták meg. Egyáltalán nem éreztem a nagy katarzist, hogy demókat nézhetek, inkább az órát néztem, hogy mikor lesz végük. Az Adapt demója nagyon látványos volt, de nem éreztem benne a kohéziót, csak azt, hogy "pakoljunk bele még egy folyadékszimulációt". A Fairlight demók a vége felé szintén inkább techdemók voltak, de ott a technológia állt a középpontban, ezért mindig egyféle effektet mutattak be. Itt meg volt valami jeti, ami csak lépett egyet jobbra, egyet meg balra. Víz kockában, aztán emberi szökőkút. Oké, de nem tartotta össze a demót semmi. Ráadásul nálam el sem indult, kénytelen voltam TeCsőről nézni.

Egyébként más is észrevette már, hogy a Notch demók mindig egy mozgó emberi karakter köré épített részecske rendszerek? Érdekes lenne megtudni, hogy ez az engine sajátságából adódik, vagy valami más oka van.

Akkor már inkább az MFX álomszerű demóját érdemes megemlíteni, ami egy teljesen korrekt alkotás volt. Egyszerű, de fülbemászó zene, egységes képi világ és elég gyors vágások, nehogy észrevegyük, milyen repetitív a karakterek mozgása. Ezt a demót látszik, hogy szívvel készítették.

 

Szólj hozzá!

Címkék: demoscene

Slackware: öregfiúknak

2022.08.07. 19:58 Travis.CG

Régen minden jobb volt! Régen a számítógép azt csinálta, amit mi akartunk. Ha hülyeséget csináltunk, nem működött a rendszerünk. Ma meg csak azt csinálhatjuk, amit a cégek megengednek. Lejár a terméktámogatás a jó kis Windows 8.1-hez, erre mit csinálnak? Figyelmeztető üzeneteket küldenek. Kérte valaki? Telepítettem én Microsoft üzengető modult a gépemre? Hát erről beszélek, kérem alásan!

Még a Linuxok is jobbak voltak. A mai Linuxosok? Pfff. Egy lépést sem tudnak tenni a grafikus képernyő nélkül. Ha valami nincs a csomagkezelőben, akkor már nem is tudják telepíteni. Régen mi még forráskódból fordítottunk!

Bezzeg a Slackware követi a régi értékeket. Minden egy telepítő DVD-n van, nem ám felhőben, meg ilyen repóban, meg olyan repóban! Még mit nem! És olyan huncuttságok sincsenek, mint csomagfüggőség! Minek? Aki telepít, az úgyis mindent felrak. Ha meg nem akar mindent felrakni, akkor nem rak fel. Nem a gép mondja meg, mit lehet csinálni.

Grafikus felület? Csak ha én el akarom indítani. Senki nem kényszerít, hogy ostoba homokórákat bámuljak. Userek? Ott a root. Ezek a mostani rendszerek úgy félnek a rendszergazdai jogosultságoktól, mintha valami betegség lenne. Pedig a beállításoknak ez a módja. Nem ilyen sudo puhaság. Hogy meri megtiltani a rendszer, hogy én kiadjam a rm -fr a gyökérben? Persze, én nem akarom kiadni. De ha ki akarnám adni? Mi van, ha olyan napom van? Nekem ne adjon hibaüzenetet egy gép! És ha vészhelyzet van?

Már egy jó ide megvoltam a CentOS-el, de egyre több olyan apróság jött elő, amivel nem tudtam mit kezdeni. Egyik ilyen probléma a középső egérgomb volt. Elkövettem azt a hibát, hogy Logitech egeret választottam, aminél a középső egérgomb nem szabványos üzenetet generál. (Bezzeg egy régi jó kis görgős egérrel ilyen nem fordulhatna elő!) Windowshoz persze van driver, mert a Windows az csókos, de Linux alatt valami miatt a Gnome alapú rendszereknél nem működik.

A fiatalok biztos a gatyájukba csinálnának, vagy ami még rosszabb, kérdéseket tesznek fel a StackOverflow-n, de nálam ez nem volt gond, mert összesen két helyen használok csak középső egérgombot: a konzolban, szöveg bemásolásához, és Blenderben. Mindkét esetben van alternatív megoldás, ezért ez nem fájt olyan nagyon.

A másik apróság a Bluetooth volt. Ez már nagyobb probléma volt. Elkezdtem ugyanis egy rajztáblával szerencsétlenkedni, ami így kommunikál a géppel, de valami miatt nem jött létre a kapcsolat a két eszköz között. A logok alapján a bluez démon nem tudott rendesen elindulni. Ez egy ismert hiba, amire a program frissítést javasolták.

Viszont megjelent az új Slackware is, ami a legrégebb Linux disztribúció, tele olyan hasznos funkciókkal, amire egy magam fajta régivágású embernek szüksége lehet. A mostani kiadásra hat évet kellett várni, de hát az öregeknek van rá idejük. Aki Ubuntun nevelkedett, az ezt biztos nem érti. Azért mégsem írom, hogy megáll az idő a Slackware használata közben, mert a rendszer használata közben azért érezni, amikor a böngésző egyre kevesebb oldalt hajlandó betölteni az újabb és újabb webes szabványoknak hála.

Az öregedéssel persze óvatosság is társul, ezért először egy tesztgépre telepítettem, és kipróbáltam az egeret, valamint a rajztáblát. Nehogy belefogjak egy mindent átfogó telepítésbe, és még a problémáim se csökkenjenek. Patricknak hála működött mindkettő.

Telepítés előtt egy biztonsági mentést is akartam csinálni, mert a CentOS LVM partíciót hozott létre a home könyvtárra, amit nem tudtam volna kevés munkával Slackware alá csatolni. (És mint írtam, fő az óvatosság!) A biztonsági mentés három órát vett igénybe, pedig csak 560GB-t kellett átmásolni.

A Secure Boot megtréfált elsőre. Elindítottam a Slackware telepítőt, majd a cfdisk-el letöröltem az összes partíciót, újakat készítettem, telepítettem. Érdekes módon az initram készítésénél csak malmozott a gép, látszólag nem csinált semmit. Itt össze-vissza nyomkodtam a gombokat, majd egyszer csak a telepítő végére értem.

Újraindítottam, és legnagyobb meglepetésemre a CentOS visszajött! A kutya meg a macska! Miféle ezredfordulós humbug ez meg? Még kétszer megismételtem a mutatványt, mire rájöttem, hogy UEFI alatt GPT partíciókat kell csinálni. Az a 2048-as szektornál kezdődik, tehát hiába hoztam létre régi típusú partíciókat, azok nem jelentettek semmit. Az initram készítés is azért "fagyott" mert a nem tudta kiírni a fájlokat.

Szóval a partíciókat a jó öreg cfdisk helyett cgdisk-el kell elkészíteni, és akkor már minden rendben volt. Legalábbis a telepítéssel. A telepítő a rendszer indítót a Windows EFI partíciójára írta a telepítő, amitől először megijedtem. Régi reakció ez, amikor még az operációs rendszerek előszeretettel írták felül egymás MBR rekordjait. Manapság már kisebb a stressz emiatt.

A biztonsági mentésből csak két óra volt a visszamásolás, úgyhogy az értékes, a web számára rég elfelejtett programverziók biztonságban voltak (meg az olyan nagyon fontos videók, amiket a YouTube is rég letörölt, mert csak 640x480-as felbontásban vannak meg.)

Mivel már rutinosabb voltam, a Tensorflow telepítése gyerekjáték volt. Az NVCC fordítóról most inkább ne beszéljünk.

Azért ez az öreg is tud új trükköket. Már van hármas Python is, 11-es GCC, de aki úgy szereti, annak az LLVM is ott figyel, és a cmake is elérte a 3-as verziót. Amint látható, már az EFI alaplapokkal is megbírkózik. Úgy érzem, nem lesz gond. Egy ideig legalábbis.

Szólj hozzá!

Címkék: rendszergazda

Repedések a kádon

2022.08.01. 22:38 Travis.CG

Sajnos tökéletes kis lakunk kezd elöregedni és az egyik ronda elem benne a fürdőkád. Akril kádunk van, amit kikezdett a sok ugrálás, forró víz, meg még ki tudja mi. Apró repedések jelentek meg, amik az idő előrehaladtával nőttek, növekedtek.

kad1.jpg

A kádcsere szóba sem jöhetett, mert akkor burkolni is kellene, ami most tényleg nem fér bele a keretbe.

Keresgéltem a megoldások között. Több lehetőség is volt. Az egyik egy spray, ami kis repedéseket képes befedni, a másik egy kétkomponensű epoxi gyanta, ami akár mélyebb árkokat is kitölt. Régi vonzódásom az epoxi gyantákhoz itt is kiütközött, mert azonnal arra startoltam rá.

A boltban egy csónak javító készletet ajánlottak, mert abban még egy selyem háló is volt, amivel az adott területet meg is lehet erősíteni. Mivel eddigi tapasztalataim a gyantákkal megerősítettek abban, hogy bizony, ha rugalmasság is kell, önmagukban a gyanták nem elegek. Megvettem.

A leírás szerint a két komponenst 1:10 arányba kell összekeverni, majd a színváltozás fogja elárulni, hogy mikor dermed meg az anyag. A keveréshez egy fecskendőt használtam. Mivel az aktivátor, amit csak kis mennyiségben kell hozzáadni a gyantához viszonylag sűrű, 5ml-es fecskendőből talán ki sem lehet nyomni. Keverés után egy picit állni hagytam, hogy addig átcsiszoljam a felületet. A leírással ellentétben én semmilyen színváltozást nem láttam. Bár 20 perc alatt kellett volna megkötnie, nekem kb. 5 perc után zselatinszerűvé vált és már nem lehetett vele semmilyen felületet kezelni.

Cserébe ilyen állapotban még könnyen ki tudtam merni a mérőpohárból, és a kukába dobhattam. Mint később kiderült, ez egy hiba volt. A műgyanta ugyanis olyan büdös volt, hogy hiába vittem le a szemetest a művelet után, még két napig nem ment ki a szaga. Feleségemtől meg is kaptam a magamét.

kad2.jpg

A második keverésnél már résen voltam. Mikor elkészült az elegy, először egy vékony rétegben a kádra kentem, majd ráfektettem a hálót, majd az egészet lekentem. Egy rossz fogkefét használtam a felhordásra, mert tudtam, ha megköt a műgyanta, annak a tárgynak annyi lesz.

Most is rövidebb idő alatt kötött meg, mint ahogy a leírás mondta, de mivel számítottam rá, nem volt bonyodalom. A háló miatt nem simult be a kád síkjába, a szélét igyekeztem minél jobban elvékonyítani. A fogkefe miatt a felület sem lett teljesen sima.

kad3.jpg

Egy nap száradást hagytam, addig büdösödött mindenki. Mi a melegtől, a kád az epoxitól. Tényleg rettenetes szaga volt. Másnap pedig nekiestem, hogy eltűntessem az egyenetlenségeket. Mint az sejtheti az olvasó, könnyebb frissibe megcsinálni simára, mint utólag csiszolgatni. Azért egy kis gépi segítséggel tűrhető simaságúra csiszoltam.

Hanem kiderült, hogy ismét nem olvastam el rendesen a használati útmutatót vásárlás előtt, ezért száradás után tudatosodott bennem, hogy a gyanta átlátszó, nem fehér. A repedések továbbra is szépen látszottak. Mehettem vissza a boltba festékért.

A kádfesték elég drága mulatság. Először nem is akarta nekem odaadni az eladó, hanem keresgélt az olcsó radiátor festékek között. Csak akkor ment a pénztárhoz, mikor megmondtam neki, hogy jó megoldást akarok, nem félmegoldást. A festék szintén kétkomponensű, szintén eltúlzott keverési arányokkal és szintén rettenetes szaggal.

A leírás szerint két napig kell hagyni száradni, ezért fürdés után álltam neki festeni, mikor másnap úgyis elutaztunk. Ez tényleg remek festék volt, de ezután tűnt csak fel, milyen kopott is a festék a kádon.

kad4.jpg

Összességében jó lett az eredmény, még ha nem is teljesen esztétikus. Valódi fényviszonyok között nem ennyire feltűnő, mint az utolsó képen.

Szólj hozzá!

Címkék: barkácsolás

A nagyiék wifi-je

2022.07.27. 18:27 Travis.CG

Már elmúlt az az idő, amikor a nagyszülőknél csak megérinthetetlen porcelán nippek, ősrégi, meghatározhatatlan feladatú berendezések, ósdi divat szerint szabott ruhák és múzeum szag van. Mamiék a fiúk és menyük levedlett iPhone-ját használják, két okostévével szórakoztatják az unokákat, akik egy lépést sem tudnak tenni tablet nélkül, amik viszont rácuppannak a wifire.

Ha meglátogatjuk őket, viszem a laptopot, telefont. A lányom a tabletet. Ilyenkor átjönnek sógoromék, mindenki egy telefonnal, a lányuk plusz egy tablettel. Ehhez jön a nagyszülők saját kütyüparkja. A router ilyenkor nem szokott unatkozni.

Sajnos az eszközökkel nem jár autómatikusan azok használata is. Ezt jól példázza a két TV esete is. Az egyik futball világbajnokság idején nagypapa vett magának egy hatalmas TV-t, milliónyi okos funkcióval. A régit pedig egy használaton kívüli szobába száműzte. Sajnos a meccseket mégsem élvezhette, mert az unokáknak is tetszett, hogy óriási felbontásban nézhetik Peppa malacot. Ezért a következő idényben a szezon előtt elkezdte nézni a használt TV-ket. Már akkor javasoltam, hogy jobban jár egy Chromecast-al, amit a használaton kívüli TV-be dugva felokosíthat, de valami bizarr bizonyítási vágytól fűtve nem foglalkozott a javaslattal.

Végül sikerült venni egy olyan TV-t, ami bár okos volt, a YouTube még nem ment rajta. A vége az lett, hogy mégis kellett az általam javasolt kis cucc is.

Egy ideig minden ment is rendesen. Foci az egyik TV-n, pixel disznók a másikon. Hanem egy idő után a routertől messzebb lévő TV egyre többet mutatta a töltés animációt és egyre kevesebbet Peppa dagonyászását. Ezért nagypapa megállapította, hogy gyenge a wifi jel. Habár volt náluk egy használaton kívüli router is, amit bridge módba lehetett volna kapcsolni, mégis inkább vett egy wifi erősítőt, de beüzemelni már nem tudta.

Ekkor lépett színre "Dani", aki nem tudom, milyen kapcsolatban állt nagypapával, de valahol a "volt munkatársam fia" és a "két házzal arrébb lakó szomszéd unokája" vonal mentén mozoghatott. Ez a szakember nekiállt konfigurálni. És konfigurált és állítgatott. Gondolom közben redőzte a homlokát, hogy valami izommunkát vigyen a tevékenységébe és a mirigyeit is verejték üzemmódba állította, de Peppa csak nem akarta szekálni az öccsét azon a nyűves készüléken. Dani végül megállapította, hogy a router elromlott.

A router annyira rossz volt, hogy utána még Viberen is beszélhettünk, ahol a nagyszülők végül megkértek, hogy állítsam be a wifi erősítőt. Ekkor két dologban voltam biztos: a routernek semmi baja és a jelerősség sem csökkenhetett le drasztikusan.

Mikor eljutottunk hozzájuk, először egy wifi elemzőt indítottam a telefonon. Pár óránként ránéztem, és a gyanúm beigazolódott. A router csatornáját mások is használták. Nem csoda, hogy nem volt jel. A program futásával megállapítottam, hogy melyik csatorna szabad és a routert átállítottam. Hirtelen minden működött. Nem kellett semmilyen más eszköz.

Szólj hozzá!

Címkék: rendszergazda

Ha már adatot osztunk meg...

2022.07.20. 22:27 Travis.CG

Az adatok megosztása elég fontos része a jelenlegi tudományos életnek. Ez nem volt mindig így. Még egyetem alatt emlékszem, amikor az Állatökológia Tanszéken dolgoztam, egy cikk írása közben a témavezető nagyon törte a fejét, hogyan írja le úgy az eredményeket, hogy közben minél kevesebbet áruljon el belőlük. Én naívan azt javasoltam, hogy legyen egy nagy táblázatban.

- Azt nem lehet! Ellopják az adatainkat és cikket írnak belőle.

Akkor még nem voltam tisztában a tudomány működésével, és nem értettem, miért baj az, ha valaki több adat felhasználásával viszi előre a tudományt, olyan módon, amire mi egyébként képtelenek lennénk.

Szerencsére manapság már menő dolog adatot megosztani. De mit is tekinthetünk adatnak? Adat bármi lehet. Lehet egy cikk. Nem feltétlenül tudományos cikk, akár egy blog bejegyzés is adatnak minősülhet (főleg, ha vészhelyzetben kell bojlert javítani). Adat lehet programkód is. Lehet egy táblázat, ami tartalmazza egy cikkhez felhasznált információkat. Talán ez áll a legközelebb ahhoz, amire az ember elsőre gondol, ha adatot említenek neki, de akár egy teljes adatbázis is annak minősül.

Főként saját tapasztalatok alapján megpróbálom felvázolni, milyen problémákkal kell szembenéznie egy adat publikálónak és egy adat felhasználónak.

Adat felhasználóként

Először is, az adatot meg kell találni. Ha a cikk azt mondja, ezen az URL-n van az adat, de nincs ott, az megnehezíti a dolgokat. Egyesek veszik a fáradságot, hogy elhelyezzenek egy átirányítást az új oldalra, de néha ez nem valósul meg. Guglival néha fel lehet lelni az átköltöztetett adatot, de ilyen esetben mindig kérdéses, hogy ez ugyan az az adat, vagy csak a semmit mondó neve ugyan az?

Változatok kezelése. Ha az adat látszólag eltérést tartalmaz a cikkben leírtakhoz képest, akkor kérdés, hogy ez egy új adat változat? Miért kellett megváltoztatni? Mit változtattak? Ha az adatokat verziókövetésre alkalmas helyen tették közzé, akkor nincs gond, de mi a helyzet a DropBox-os, Google Drive-os, stb megosztással?

Az adatstruktúra leírása. Hogyan épül fel? Ez legalább annyira fontos, mint maga az adat. Egy cikk nem célja és feladata, hogy a megírásához használt adat minden egyes részletét bemutassa. Ráadásul lehetnek olyan részei is ennek az adatnak, amit nem tartottak fontosnak a szerzők. Egy metaanalízishez ezek nélkülözhetetlenek.

Adat publikálóként

Fontos tudatában lenni, hogy ha közzéteszünk egy adatot, annak utóélete lesz. Olyan utóélete, aminek tőlünk függetlenül is működnie kell. A platform, ahol megosztottuk az adatot, meglesz öt év múlva is? Túl fogja élni a munkahely váltást? Nekünk például az egyik cikkünkhöz tartozott egy weboldal is, ami csak pár évet élt, miután a számítógép, ami kiszolgálta, kinyiffant, biztonsági másolat pedig nem volt.

A metaadatokat is publikáltuk? A programunkat le fogját tudni fordítani? Az adattáblák fejléce informatív? Nekünk lehet, hogy az, hiszen hónapokon keresztül azzal dolgoztunk, de egy új ember is képes ugyan úgy átlátni?

Így FAIR

A fenti problémák egy globális jelenség részei, ezért született meg a FAIR irányelv, ami segíthet nekünk, hogy jó adatmegosztási döntést hozzunk. Az itt bemutatott irányelvek mindegyikét tudtommal még soha senki nem volt képes teljesíteni. Nyilván az élet minden területére kiterjedő kontrolunk nincs, tehát a legjobb jószándék ellenére is kompromisszumokra kényszerülünk, amely befolyásolhatja egyik-másik irányelv megvalósulását. Információim szerint a legtöbb FAIR irányelvet a DOI valósítja meg, így innen hozom a legtöbb példát.

Megtalálható

Azért, hogy az adat megtalálható legyen, szükség van egy globális azonosítóra, amely egyértelműen behatárolja az adatot. A folyóiratoknál ez a DOI azonosító, ami biztosítja, hogy a sok, egyforma nevű koronavírusról szóló cikk közül ki tudjuk választani a minket érdeklőt. Az adathoz metaadatok is kell, hogy tartozzanak, amelyek részletesen leírják az adatot. Gyakorlatilag nincs megszabva, hogy a metaadatoknak mit kell tartalmazniuk. Cikkek esetén a cím, szerzők, absztrakt, folyóirat, stb. szokott lenni a metaadat. Nyilván egy szekvenálási adat megadásánál a legtöbb értelmét veszti. A metaadatoknak szintén indexeltnek, és kereshetőnek kell lennie.

Hozzáférhető

Nyilvánvaló, hogy ha az adatot megosztani akarjuk, akkor hozzáférhetőnek kell lennie. Itt igazából nem szabják meg, hogyan legyen hozzáférhető az adat, csak annyit mondanak, hogy nyílt protokollon kell alapulnia. Ez a protokoll lehet a TCP/IP, de ha az adatainkat postai úton érhetik el, az szintén nyílt protokollnak számít. De ami talán még ennél is fontosabb, hogy a metaadatoknak akkor is hozzáférhetőnek kell lennie, ha az eredeti adatot már törölték. Például ha egy cikket visszavontak, a DOI azonosító alapján az absztraktot továbbra is megnézhetjük.

Átjárható

Az adatok nem magányosan léteznek, hanem rendszert alkotnak, mint ahogy egy könyvtár is rendszert alkot a könyvekből. A rendszer szemlélet miatt az adatoknak hasonló szerkezetet kell mutatniuk, amit úgy fogalmaztak meg, hogy egységes nyelvet kell használniuk. Ha az egyik cikkből csak mondatok számát tartalmazza a metaadat, a másikból pedig a cikk MD5 hash kódját, akkor azokkal nem sokra megyünk. Fontos, hogy ha megosztunk valamit, akkor a felhasználónak ismerős legyen a mi adatunk is, ne kelljen dekódolni, mit is osztottunk meg. Itt kell megemlíteni azt is, hogy az adatnak tartalmaznia kell keresztreferenciákat. Cikk esetén ez az irodalomjegyzék, és ha a cikkek teljesen megfelelnének a FAIR elveknek, akkor csak a DOI azonosítókat tartalmaznának a 200-féle formázás helyett.

Újrahasználható

Ez az elv szoros kapcsolatban van az átjárhatósággal. A metaadatoknak relevánsnak kell lenniük az adott adattípusra, és egyértelműen jelezni kell, hogy milyen liszensz szerint használhatóak. Tehát az elvek nem zárják ki, hogy az adat közzétételét korlátozzuk. Ugyan így az adatok eredetét is tisztázni kell.

Az elvek nagy része logikus és azt gondolhatnánk, hogy egyértelműek. Az adatmegosztás a gyakorlatban mégsem így fest, ezért nem rossz, ha összefoglalják. Érdemes átgondolni, milyen volt az eddigi megoldásaink, és ha úgy ítéljük meg, hogy lehet mit javítani rajtuk, akkor tegyük meg.

Szólj hozzá!

Címkék: életmód bioinformatika

A.I.-val verébre

2022.07.13. 19:55 Travis.CG

A lányomnak vagy egy játéka, amiben egy nyolcszögletű lapon képeket kell keresni. A játék menete, hogy mindenki kap egy csomó lapot, majd egy lapot középre helyezünk. Ha a kezünkben lévő lapon olyan kép van, ami a középen megtalálható lapon is, akkor ledobhatjuk azt középre, és megint kezdődik a párkeresés. Az győz, akinek legelőször fogynak el a lapjai.

A játék során azon gondolkodtam, hogy nem alakulhat-e ki olyan eset, hogy senki nem tud rakni lapot. Azért, hogy ez ne következzen be, biztosítani kell, hogy legalább három lap (ha két játékossal és egy referencia lappal számolva) között legyen legalább egy közös kép.

Azután, ahogy az kutatóéknál lenni szokott, a játékot felváltotta a játék elemzése, aminek lányom egyáltalán nem örült, mert ilyenkor a feleségemmel elkezdünk elmélkedni, kutatási tervet készíteni, stb. A gyereknek meg elmagyarázzuk, hogy ez mennyire fontos neki, de ő valahogy ezt nem értékeli. A kérdés eldöntésére elhatároztam, hogy építek egy gráfot, ahol a csomópontok a lapok lesznek, az élek pedig a közös képet fogják reprezentálni.

Igazából az egész munka 1-2 óra alatt elkészült volna, ha fogom magam és leülök, hogy egyenként átnézzem a lapokat. Fél nap alatt meglettem volna, ha még Excelt is használok :-) De ha már képekkel dolgozunk, miért ne lehetne egy tanuló algoritmust rászabadítani, hogy nézze a képeket helyettem? Az időráfordítást tekintve ez egy elég rossz ötlet volt, tekintve, hogy már több, mint két hónapja ezen szenvedek.

A játékban 73 kép van és 73 lap, laponként 9 képpel. Először lefényképeztem a lapokat. Hogy tovább nehezítsem a saját dolgom, egy fényképen több lap is van. A lapokon különböző orientációban és nagyításban találhatóak a képek. A játék dobozának hátulján van egy felsorolás az összes képről, ezt szintén lefényképeztem, ez lett a referencia.

Gimp segítségével a referencia képeket egyforma méretre hoztam, és amennyire tudtam, a hátteret is egységesítettem. Eredményül lett 73 darab 178x140-es képem. Ezután elkezdtem építeni egy konvolúciós neurális hálót.

Ez a fajta neurális háló igen érdekes, mert konvolúciós kerneleket használnak, hogy a kép különböző jellemzőit megragadják. A konvolúció után a képből egy alacsonyabb felbontású reprezentáció lesz. Egymás után több rétegben is használhatunk konvolúciót, de az utolsó rétegnek egy összesítő rétegnek kell lennie. Ez fogja összegyűjteni az eredményeket.

Ezek a neurális hálók igen bonyolult felépítésűek, de szerencsére Kerasban nagyon egyszerűen használhatjuk őket. Építőkockánként rakhatjuk össze a hálózatot. Mivel nem vagyok jártas, hogy milyen topológiájú hálózatot érdemes használni, ezért ezt vettem alapul. Ez egy jelzőtábla felismerő program akart lenni, ezt alakítottam a saját igényeimnek.

A program lényege az volt, hogy kevés képpel etetjük meg a rendszert, amelyik a kapott képeket véletlenszerűen elforgatja, tükrözi és nagyítja, hogy megnövelje a tanuló adatok mennyiségét. Ezzel biztosítva, hogy a lapokon is felismerje a képeket bármilyen helyzetben is vannak.

Az első tanítás katasztrofális volt. Habár a rendszer azt állította magáról, hogy 98%-ban pontos, a valóságban a tehénről azt mondta, hogy zöldalma. Sőt, mindenről azt állította, hogy zöldalma. Az első hiba, amit elkövettem, hogy nem volt valódi validációs adat, ezért azt is generáltattam, a tanuló adatokhoz hasonlóan. Itt látszott rögtön, hogy hiába 98%-os a rendszer, ha igazi teszt adattal etettem meg, akkor 16%-ban volt sikeres.

Elkezdtem játszani a paraméterekkel. Beadtam neki 20 ezer képet kategóriánként, de a hatékonyság nem növekedett. Próbáltam a modellt egyszerűsíteni, de ezek a kísérleteim is kudarcot vallottak. Úgy döntöttem, keresek egy példát, amihez adat is van. Sajnos a fenti tutorial nem az igazi, mert emailt, telefonszámot, meg talán még vérmintát is kér, hogy végig lehessen csinálni. Ezért másikat kerestem.

Végigcsináltam egy egyszerű példaprogramot, ami igaz, csak bináris klasszifikációt csinált (elkülönítette a repülőket és a személyautókat), és az meglepően jól működött, pedig csak 200 kép volt, és a tanítási idő sem volt vészes. Közben begépeltem számtalan más példaprogramot is, amik pedig egyszerűen nem működtek. Dobálták össze-vissza a hibákat. Egy részük csak más verziószámú Tensorflow-t igényelt, de elég sok valóban hibás kód volt. Többek között az első is, ami alapján a saját progimat összehoztam.

A másik dolog, amit nem értettem, hogy bár két GPU van a gépemben, összesen 8G memóriával, mégis rendszeresen kaptam a figyelmeztetéseket, hogy a videokártya memóriája mindjárt meg fog telni. Akár mennyi képpel is tanítottam a hálózatot, a GPU memóriája 95-98%-ban tele volt.

A tutorial után visszatértem az előző kódhoz. Egy hirtelen ötlettől vezérelve kiírattam a képeket, amelyeket generál a tanításhoz. Kiderült, hogy a kék és vörös csatárnákat megcserélte. Nem csoda, hogy képtelen bármit is megtanulni, hiszen nem ugyan az a két adatsor. Olyan, mintha más lenne a lecke és másból kellene felelni. A javítás után egy kicsit jobb lett a helyzet, de még így is messze volt a használhatótól.

Néha a számok alapján már majdnem úgy tűnt, hogy elértem a célom, de ha egy olyan képet adtam be neki, amit korábban nem látott, akkor látszott, hogy a rendszerem nem tanult semmit. Egyre biztosabb voltam, hogy nekem egy sokkal egyszerűbb modellre van szükségem. Végül találtam egyet. A leírásban 500 lépésben tanították a modellt, ami bődületesen soknak tűnt, de úgy döntöttem, kipróbálom. Ezt a hálót is a saját igényeimnek megfelelően átalakítottam, majd elkezdtem tanítani. Ez hét órát vett igénybe. A tanító kód itt van:

from keras.models import Sequential
from keras.layers import Conv2D
from keras.layers import MaxPool2D
from keras.layers import Flatten
from keras.layers import Dropout
from keras.layers import Dense
from keras.optimizers import Adam
from keras.preprocessing.image import ImageDataGenerator

NUM_EPOCHS = 500

class SmallNet:
  def build(width, height, depth, classes):
    model = Sequential()
    model.add(Conv2D(32,3,padding="same", activation="relu", input_shape=    (height, width, depth)))
    model.add(MaxPool2D())
    model.add(Conv2D(32,3,padding="same",activation="relu"))
    model.add(MaxPool2D())
    model.add(Conv2D(64,3,padding="same", activation="relu"))
    model.add(MaxPool2D())
    model.add(Dropout(0.4))
    model.add(Flatten())
    model.add(Dense(128,activation="relu"))
    model.add(Dense(classes, activation="softmax"))
  return model

train_datagen = ImageDataGenerator(rescale = 1.0 / 255, zoom_range=0.2, horizontal_flip = True, rotation_range=180)

test_datagen = ImageDataGenerator(rescale = 1.0 / 255)

train_generator = train_datagen.flow_from_directory("test2", target_size = (140,178), batch_size = 64, class_mode = 'categorical')

test_generator = test_datagen.flow_from_directory("test2", target_size = (140,178), batch_size = 64, class_mode = 'categorical')

model = SmallNet.build(width=178, height=140, depth=3, classes=73)
opt = Adam(lr=0.000001)

model.compile(loss="categorical_crossentropy", optimizer=opt,metrics=["accuracy"])

model.fit_generator(train_generator, steps_per_epoch = 14000 // 64, epochs=NUM_EPOCHS, validation_data = test_generator, validation_steps = 1000 // 64)

model.save("./imagesearchmodel")

Ez volt az első eset, hogy a képeket jól azonosította be. Sajnos legrosszabb esetben 24%-ban volt biztos a helyes megoldásban, de legalább helyes volt a megoldás. Még a kivit sem nézte zöldalmának. Végezetül beadtam neki a saját arcképemet, mire a rendszer megállapította, hogy ez egy banán. Remélem ez nem egy kritika az algoritmus részéről.

 

Szólj hozzá!

Címkék: machine learning

Készítsünk release-t játszva

2022.07.02. 20:58 Travis.CG

Érdekes módon a játék motorokat előszeretettel használnak demók elkészítésére, a machinimák mégsem terjedtek el a wild kategóriában. Mindez azért is furcsa, mert a demoscene-ben sok játékfejlesztő van, sőt külön kategória van saját készítésű játékoknak. Arról nem is beszélve, hogy régen a partikon volt lan parti is.

A talányra két hipotézisem van. Az egyik, hogy a demoscene-n belül viszonylag kevés a gamer (elvégre, ha játszol, nem tudsz release-t készíteni). A másik, hogy magára a játékosokra kicsit ferde szemmel néznek az igazi scenerek, mert nem alkotók, csupán fogyasztók. Akárhogy is történt, az biztos, hogy szép lassan egyre kevésbé látták szívesen a gamereket a demópartikon.

Talán ennek az ellentétnek is köszönhető, hogy amikor ehhez a bejegyzéshez készítettem némi kutatást (azért nem estem a buzgóság csapdájába), egyetlen machinimát sem találtam, amit demópartin mutattak volna be. Ettől függetlenül a machinima remek kifejezési eszköz lehet olyanoknak, akiknek nincs se programozói tudásuk, sem profi videófelszerelésük. Aki viszont tud programozni, rajzolni, az akár saját modokat is készíthet a játékhoz,

Lehet, ennek most vége, mert az idei Assemblyn két olyan kategória is lesz, ahol nem lehetőség, de egyenesen követelmény, hogy játékprogrammal készüljön. Az egyik az In-game photo, a másik az In-game short film.

Ha valaki szeretne ezekre a compókra készíteni valamit, az megteheti, hogy a játékát felveszi egy rögzítő programmal, majd kicsit megvágja és kész. Azomban vannak olyan játékok is, ahol beépített eszközök segítik ezen filmek elkészültét.

Ezek az eszközök annyival adnak többet a kezünkbe, hogy elrugaszkodhatunk a játékmenet által rögzített kameraállásoktól, idővonaltól, sőt, akár a képi világtól is. Például a GTA V-ben kapunk egy teljes videószerkesztő felületet. Mivel ezt ismerem a legjobban, ezért ezt mutatom be.

Ennek a szerkesztőnek az elődje már a GTA IV-ben is megvolt, de pozitív fejlesztésen esett át. Mielőtt nekilátnánk bemutatni mit is tud, nem árt tudni, hogy van néhány limitáció. Először is, a játékos halálával megáll a klipp. A második, hogy a kamera nem távolodhat el egy bizonyos távolságra a játékostól. Egyszerre csak egy karaktert tudunk irányítani (bár ez kikerülhető, ha vannak online barátaink.)

Alapvetően két módszer van klippek készítésére. Az első az úgynevezett Directore Mode. Ez olyan, mint az egyjátékos mód, de több szabadságot ad a kezünkbe. Miután a menüből kiválasztottuk ezt a módot, a filmstúdióba kerülünk, ahol kiválaszthatjuk a szereplőt, akit irányítani fogunk. Ez akár egy állat is lehet. Az elérhető szereplők száma függ attól, mennyire haladtunk előre a játékkal.

A kiválasztott szereplőt aztán irányíthatjuk a játéktérben. Mivel itt nincsenek küldetések, ezért nem kell aggódni, hogy telefonon zaklatnak más karakterek. Az interaktív menü (alapértelmezetten M) segítségével új elemeket helyezhetünk a városba. Nagy ugratót, utat, roncsot, stb. Felturbózhatjuk a helyszínt. Járműveket is a közelünkbe varázsolhatunk, valamit rávehetjük a szereplőt, hogy beszéljen, tegyen bizonyos mozdulatokat. (Azért ne számítsunk sok mindenre. A káromkodásokon kívül "Whassap?", "Hey" és társai jutnak csak nekünk.)

Az F1 gomb segítségével felvehetjük a jelenetet. Egyes esetekben, ha a játék által generált környezet túl összetett, sok elemet tartalmaz, előfordulhat, hogy a program jelzi, az elmentett klippben nem lehet majd kamerákat mozgatni.

A másik módszer, hogy az online térben készítjük el a filmet. Ennek előnye, hogy több színészünk lehet, de a kinézetünk nem fog változni, vagy legalábbis nem drasztikusan. Csak azokat az járműveket és tárgyakat használhatjuk, amelyeket megvásároltunk a karakterünkkel, viszont ezek száma sokkal nagyobb, mint amit az offline játék a rendelkezésünkre bocsát, plusz bármikor jöhet egy Oppressoros griefer és szétlőheti a forgatást. (bár invite only játéktér ezektől megvéd.)

Amennyiben összeszedtük a klippeket, kezdődhet a második lépés, a szerkesztés. Be kell lépni a Rockstar Editorba, ahol kissé nyakatekert módon össze is fűzhetjük a klippeket, de ezt inkább profibb programokra bízzuk. A legjobb, ha minden egyes klippen csak a kamera mozgásokat és a filtereket állítjuk be. Utána rögtön mentsük ki videóba. Az exportált videók az AppData\Local\Rockstar Games\GTA V\videos\rendered könyvtárban lesznek.

A kimentett klippeket pedig egy rendes videószerkesztővel rakjuk össze, mert a zenét, átmeneteket könnyebben megcsináljuk egy olyan programmal, amit erre terveztek.

Természetesen ezek csak a gyári képességek. A modderek már régóta feszegetik a GTA V határait, ezért ha olyan szereplőt akarunk, akit nem ajánl fel a játék, van rá mód, hogy szerepeltessük. Az Assembly szabályai is lehetővé teszik, hogy modokat használjunk, de csak olyat, ami publikusan elérhető. Viszont a modok egyfajta szürke zóna. Ha online használjuk őket, megkockáztatjuk, hogy kitiltanak minket (bár amennyi modderrel már találkoztam, ez biztos nem sűrűn fordul elő :-) )

Végezetül álljon itt néhány videó, ami bemutatja, hogy egy kellően elszánt ember mire képes ezzel a játékkal:

Szólj hozzá!

Címkék: demoscene

Szimulálj!

2022.06.24. 23:32 Travis.CG

Az adatelemzés mellett most több programot is meg kell írnom, amihez nem árt, ha folyamatos kontroll alatt áll a kód, hogy minden egyes módosítás után tudjam, nem szúrtam.

Gondoltam, nincs is jobb, mint valódi adatokkal megetetni a programot és a fejlesztés alatt folyamatosan monitorozni a visszaadott válaszokat. Pár órát rászántam a keresésre, de a végére valahogy egyik megtalált adat sem nyerte el a tetszésemet. Az egyik túl nagy volt, amin sokáig futna a program. A másik nem tartalmazott elég biztos eredményekt.

Kissé elkeseredtem. Egyre több adatot töltünk fel a különböző szekvencia tárhelyekre, de mégis ott tartanánk, hogy nincs megfelelő adat? Vagy egyszerűen csak lustává váltam, és túl nagyok lettek az elvárásaim? A nagy filozofálásnak az lett a vége, hogy eldöntöttem, nincs is szükségem valódi adatokra! Egy számítógéppel bármit le tudok generálni. Egy számítógép képes világokat teremteni. Olyanokat is, amelyek nem létezhetnek. Kell egy világ, ahol hibamentes Illumina readek léteznek? Egy kis gépelés, és már kész is.

Sőt, több, párhuzamos világot is teremthetek, ahol egy bizonyos paraméter egy sorozatot alkot. Tehát az előbbi példánál maradva a readek hibaszázalékát változtatva több adatot is készíthetek.

Ezen fellelkesülve nekiláttam egy VCF generáló programot írni. Azért, hogy pontosan tudjam, mit is generálok, és hova, a VCF fájlt saját tag-ekkel láttam el. Ezekkel tudtam ellenőrizni, hogy a másik program megtalálja-e azokat a jellemzőket, amelyeket a generáló program elhelyezett a fájlban.

A saját szimulátor jó móka, de nem szabad elfelejteni, hogy csak annyira tökéletes, amennyire mi ismerjük a jelenséget. A hiányos ismeretek visszaüthetnek, ha az elemző programot úgy írom meg, hogy csak generált adatokon tesztelem. Nem véletlen, hogy a különböző folyóiratok is a generált adatok mellett valódiakon is bemutatják az algoritmusokat.

Szólj hozzá!

Címkék: programozás bioinformatika

QBParty 2022

2022.06.19. 13:03 Travis.CG

A demót két nappal a határidő előtt befejeztem. Még arra is jutott időm, hogy a fordító figyelmeztetéseit is eltűntessem. Sajnos túl magabiztossá váltam a kezdeti sikerek miatt.

Mivel napok óta mondogatom otthon, hogy demópartira megyek, az indulás reggelén a lányomnak eszébe jutott, mennyire szereti a .the .productot, ezért teljes hangeről azt hallgatta. Gondoltam jó kis bemelegítés lesz. Lassan pakoltam össze, hogy biztosan ne felejtsek ki semmit. Többször végig gondoltam, mire is lesz szükségem, amitől még biztosabb lettem benne, hogy minden simán fog menni.

Nagyjából 10 perccel indulás előtt a tökéletesség buborékján repedések keletkeztem. A laptopon is meg akartam nézni a demót, és ekkor szembesültem vele, hogy ami az NVidia kártyán tökéletesen ment, az Intel HD-n nem egészen úgy fut. Úgy is mondhatnám sehogy sem fut. Kijavítani már nem volt idő, ezért mindent bepakoltam és útnak indultam.

A vonatot majdnem lekéstem, de "szerencsére" késve indult, ezért még várhattam is 15 percet. A vonaton release-t heggesztettem, de nem értem el sikereket, ráadásul netes segítség nélkül a hatékonyságom is felére csökkent. Sülysápra a tervezett érkezésnél fél órával később értem be. Reménykedtem benne, hogy a release leadás határidejét nem veszik olyan szigorúan. A partira nem tudtam bemenni, mert zárva voltak az ajtók. Egy táblát láttam csak: Zárt körű rendezvény. Azért volt annyi helyismeretem, hogy tudjam, hol a hátsó bejárat, ezért onnan settenkedtem be. (Később megtudtam, csak egy ember vitte a jegypénztárt, váltás nélkül és épp el kellett mennie, ezért zárta be az ajtót.)

Feltöltöttem a fotót, majd további egy órán keresztül próbáltam kitalálni, mi lehet a hiba a demóval. A végére annyit elértem, hogy a kód lefutott, úgy futott le, ahogy szerettem volna, viszont egy shader validálási lépés szűntelenül nyekerett, hogy különböző típusú textúrák ugyan azt az azonosítót használják. Gondoltam, majd a veterán demósok megsegítenek, de akiket megkérdeztem, azok sem találtak semmi hibát a kódomban. Közben egyesületi ügyeket is intéztünk.

Három óra magasságában indult az első compó: a paprikáskrumpli. A szervezők főztek egy nagyon finom paprikás krumplit, amit természetesen meg is kóstoltam. Az első igazi compó a fotó volt, nyolc indulóval. Ha már fotóra is csak nyolc képet adnak be, akkor lehet sejteni, hogy nem lesz nagy dömping a többi kategóriában sem.

Bár a tavalyi partiról azt írtam, hogy olyan, mint egy ébredező medve, azért még most is félálomban volt. Legjobban Spenót fogalmazta meg, hogy annyira elszokott az emberektől, hogy délután már elfáradt a sok beszélgetésben. Talán emiatt kissé álmatag hangulat miatt sem fogom a releaseket értékelni. Bár azért Viti legújabb lézershow-ja megérdemli, hogy megemlítsem. A vektoros ábrák mellett bitkép-szerű látvány is volt. Ha így folytatja, a végén még épít egy R2D2-t Lea hercegnő üzenetével.

Az udvaron Fun Compó néven olyan versenyek voltak, amik a józanul kínosnak tűntek. Például csipeszeket kellett arcra pakolni és az győzött, aki a legtöbbet tudta magára aggatni. A vizipisztoly csata pedig olyan volt, mint egy gettó Mátrix.

Később volt tombola is, ahol kegyetlem mennyiségű nyalókát és egéralátétet lehetett nyerni (voltak más nyeremények is, de azok nem maradtak meg úgy, mint ez a kettő). A másfél órás sorsolás alatt a nézők folyamatosan csökkenő lelkesedéssel tapsolták meg a nyerteseket. Csak akkor tért vissza a hallgatóságba az élet, ha nő ment ki a nyereményért, akkor valami miatt az éljenzés hangereje megnégyszereződött.

Az intrók közé valahogy belekevetredett a demóm, mire egyes alkohol gőzös nézők azt hitték, hogy 116 fotót sűrítettem 1k-ba. Nagy volt a csalódásuk, amikor megtudták, hogy mégsem. A demó egyébként az utolsó helyen végzett, de a többi indulót látva ott is volt a helye.

A parti nagyon jól sikerült, egyik szervezési hiba sem volt szerintem végzetes, bár a szervezőket nagyon megviselte a mostani party. Ebből én nem vettem észre semmit. Nekem annak a felismerése volt a parti, hogy megvan bennem az elhatározás és akarat, hogy további demókat készítsek. Még akkor is, ha az utolsó helyen végeznek.

Szólj hozzá!

Címkék: demoscene

A láthatatlan fotózása

2022.06.11. 09:09 Travis.CG

A fotózás azért is olyan jó hobbi, mert bármikor elverhetünk rá eszméletlen összegeket. Van egy géped? Kell objektív. Van objektíved? Kell még egy objektív, majd még egy szűrő, esetleg egy második fényképezőgép (nehogy már az objektív cserével értékes időt veszítsél), memória kártya, stb. Ha pedig valami csoda folytán mindegyik bigyó megvan, akkor jöhet az elvault rendszer cseréje.

Annak idején azért is döntöttem a Canon mellett, mert úgy tűnt, a cég nem cserélgeti sűrűn az objektív foglalatokat a gépeken. Majdnem 10 évembe került, mire minden lehetséges helyzetre sikerült megfelelő objektívet szerezni, erre bejöttek a MILC-ek. Egy ideig néztem magam elé, mint akiket egy felsőbb hatalom átvert, majd úgy döntöttem a középső ujjamat mutatom ennek a fene nagy megállíthatatlan fejlődésnek.

Miközben mindenki váltott Sony-ra és adta el a régi Canon-os cumókat, én szépen begyűjtöttem azt, amiről korábban csak álmodthattam. Így került hozzám egy Canon 5D mark II, egykoron felső kategóriás gép, de most olcsóbban hozzájutottam, mint egy új, belépő szintű tükörreflexeshez. Ráadásul ennek a gépnek volt egy plusz hozadéke: kiszerelték belőle az összes szűrőt. Tehát nem csak full frame, hanem full spektrum is. Lehet vele infrában és UV tartományban is fotózni. Merthát miért csak a látható tartományban fotózzunk?

Az elején kicsit ódzkodtam tőle, mert már volt benne 150 ezer expo, ami a gyári limit. Az eladó nyilván azt mondta, hogy "ennél háromszor többet is bír", ráadásul meg is volt bontva a konverzió miatt, ezért félő, hogy bemondja az unalmast, végül mégis győzött az irracionalitás és megvettem.

Az első teszt természetesen a TV távirányítója volt. Még a gyári fényképezőgépek szűrői sem képesek teljesen megakadályozni, hogy az infravörös fény az érzékelőre jusson. Halvány pislogásként látni fogjuk. Itt nem. Itt úgy világított, mint egy lámpa. (Gyakorlatilag a távvezérlőt vakunak lehet használni tök sötétben.) A belső szűrők eltávolítása hihetetlen fényerő növekedést produkált. Egy teliholdas éjszakán olyan képet lehet vele készíteni, mintha nappal lenne.

ejszakai.jpg

Az eladó azt mondta, hogy manuális fehéregyensúly állítással akár normál képet is lehet vele készíteni. Nos, való igaz, hogy lehet csökkenteni a vörös árnyalatot, de a kép inkább olyan lesz, mint egy öregedésnek indult színes fotó. A szaturáció nem lesz az igazi. Akármennyit is játszottam a nyers képekkel Gimp-ben, valahogy soha nem voltam elégedett az eredménnyel.

Az igazi kaland viszont akkor kezdődött, amikor megjöttek hozzá a speciális szűrők, amelyek csak bizonyos hullámhossz tartományt engednek át. Az első kiszűri az UV-t és az infrát is, vagyis a fehéregyensúly állítása nélkül is lehet megszokott képeket készíteni. Az így készült képeket összehasonlítottam a 350D-vel készült képekkel, és azt kell mondjam, hidegebbek. Az utólagos színkorrekciót nem lehet megúszni vele.

A második szűrő csak az UV-t engedi át. Emiatt a keresőből történő fényképezést el lehet felejteni. Nem csak azért, mert a veszélyes sugarakat a szemnünkbe juttatja, hanem azért is, mert látható fény híjján csak feketeséget lehet látni. Be kell kapcsolni az élő képet, ha fókuszálni akarunk.

A szűrő önmagában mégsem elég. Az UV fotósok nagy bánatára a legtöbb modern objektív tartalmaz UV elnyelő réteget. Ezért hatalmas vadászat van mindenféle világháborús lencsék után, ahol még erre nem fordítottak elegendő figyelmet. Én egy jó öreg 40mm-es objektívvel használtam, mert azt olvastam, ez még elég jó választás, ha nem akarunk adapterekkel játszani. UV-ban egyébként főleg virágokat érdemes fotózni.

virag.jpg

szulak.jpg

A második képen folyandár szulák van. Igen, az a semmike kis gaz UV-ban elég érdekesen néz ki.

Végezetül ott van az infra tartomány, amivel olyan képek készülhetnek, mintha új metafizikai síkokat akarnánk feltérképezni. Szóval aki le akar menni a Homály első szintjére, egy 850nm-es szűrővel megteheti. A színek itt már eltűnnek. Viszont sokkal izgalmasabb az infrafotó, ha a látható fény közelében fényképezünk. Itt lesznek színek, és egy egyszerű színcserével meglepő képek születnek. A fák levelei (illetve minden fotoszintetizáló élőlény) ugyanis fény hatására gerjesztett állapotba kerül és az infravörös tartományban világít. Ezért lesznek a növények fehérek.

infra.jpg

Ezért nagyon kíváncsi vagyok, milyen képek készülnének késő ősszel, amikor a klorofil kezd lebomlani. A fenti kép igazából nem sikerült jól, valószínűleg megint a fehéregyensúllyal lehetett gond. Ha jól csináljuk, akkor ugyanis az ég kék lesz, nem ilyen ronda vörös. Doomba jó lenne háttérképnek.

 

Szólj hozzá!

Címkék: életmód

Textúra tömbök

2022.05.18. 10:02 Travis.CG

Elkezdtem írni a QBParty-ra a demót. Egy régi ötletet valósítok meg, aminek a lényege, hogy egy csomó fényképet felhasználva animációt készítek. Az ötlet nem új keletű, például a 2003-as Heart Shaped Box is ezen alapult. A különbség az lenne, hogy míg ott a képek időben egymás után jöttek fel, nálam egy időpillanatban több kép egyszerre lenne látható, majd ezeket különböző módon kombinálnám, ahogy egy grafikus programban a rétegeket szokták.

A képek keverésére programozástechnikai szempontból két módszert használhatunk. Az egyikben a CPU-n keverjük össze a pixel adatokat eggyé, majd ezt adjuk át a fragment shadernek textúraként, vagy mindegyik képet betöltjük a shaderbe, és ott összegezzük az információt. Az első módszer egyszerű, csak lassú. A másodikban viszont a GPU-n kombináljuk a képeket, ami gyorsabb, de a megvalósítása nem egyszerű. Természetesen a második megoldást fogom választani. Azonban, mint látni fogjuk, itt is több lehetőségünk van.

Eddig a demóimban a shaderekben a textúrákra egyszerű sampler2D típusú változókként hivatkoztam. Tehát a shader deklarációs részében ilyen sorok szerepeltek:

uniform sampler2D img;
uniform sampler2D mask;

Mivel eddig egy shaderen belül kevés textúrával játszottam, nem is volt szükségem másra. Most viszont 116 textúra egyidejű kezelésére lenne szükségem. Száztizenhatszor beírni, hogy uniform sampler2D még büntetésnek sem utolsó, de nincs is rá szükség, mert használhatunk tömböket.

uniform sampler2D img[116];

 Ez a része egyszerű. A bonyolult, hogy miként mondjuk meg a shadernek, hogy hol találja az adatokat? CPU oldalon a következő kódra van szükség.

GLint starids[116];
for(int i = 0; i  < 116; i++){
  glActiveTexture(GL_TEXTURE0 + i);
  glBindTexture(GL_TEXTURE_2D, texid[i]);
  starids[i] = i;
}
GLint loc = glGetUniformLocation(prgid, "img");
glUniform1iv(loc, 116, starids);

Mennyi textúrát vihetünk át? Ez a GPU függvénye, de lekérdezhetjük a számát a GL_MAX_COMBINED_TEXTURE_IMAGE_UNIT segítségével. Nálam ez 192, szóval a 116-al még benne vagyok a limitben. De ez nem jelenti azt, hogy ezt mind korlátlanul fel is használhatom. A fragment shader ennek a töredékét tudja csak használni. A GL_MAX_TEXTURE_IMAGE_UNIT mutatja meg ezt a számot, ami már csak 32 az én esetemben. (Bár meg kell jegyezni, az NVidia kártyák liberálisabbak, ott következmények nélkül használhattam mind a 116 textúrát, igaz elég lassú lett a végére. Mikor egy Intel UHD 620-as laptopon futtattam ugyan azt a kódot, a hátár átlépése után szabványos hibaüzenetet kaptam.) De még ezt a 32-t sem használhatom tetszőleges programkörnyezetben! Egyes (régebbi) videokártyák nem engedik, hogy cikluson belül használjuk őket. Szerencsére ez nálam nem gond.

De 32 textúra még mindig nem 116. Persze lehet több menetben is renderelni. Először 32 textúrát feldolgozok, majd az eredményt egy másik texturába mentem. Ezt megismétlem pár alkalommal, majd végső lépésben az előzőleg létrehozott textúrákat kombinálom. Ez nyakatekert, lassú, és értelmetlen, különösen, hogy az OpenGL biztosít egy szokatlan 3D textúrát, ahol az egyes rétegek nem keverednek. Ez a tömbtextúra (array texture).

Ez annyival más, mint az előzőleg használt tömb, ahol 32 volt a limit, hogy ott igazából csak az azonosítók voltak tömbbe rendezve. Itt viszont az adatok is, tehát nem váltunk a textúrák között, hanem egy textúrán belül lépkedünk. Akár 2048 textúrát is összefűzhetünk ily módon egy OpenGL 4.5 képes kártyán. Lássuk, hogyan is készül.

glGenTextures(1, &texid);
glBindTexture(GL_TEXTURE_2D_ARRAY, texid);
glTexStorage3D(GL_TEXTURE_2D_ARRAY, 1, GL_RGBA8, width, height, maxindex);
for(i = 0; i < 116; i++){
  image = load_from_file(...);
  glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 0, 0, 0, i, width, height, 1, GL_RGB, GL_UNSIGNED_BYTE, image);
  free(image);
}

Mint látható, csak egy textúra készült, egyetlen azonosítóval. Az egyes rétegeket a glTexSubImage3D-vel töltöttem fel. A fragment shaderben a következő módon kell használni:

uniform sampler2DArray image;
...
FragColor = texture(image, vec3(texcoord, level));

Tehát a koordináta három dimenziós lett, kiegészült a tömbindex-el. A módszerrel gond nélkül használhattam az összes textúrát, ráadásul sokkal gyorsabban.

Szólj hozzá!

Címkék: programozás demoscene opengl

Minek vegyek körvakut?

2022.05.09. 22:59 Travis.CG

Azt hiszem, senki nem nevezheti magát csináld-magad fotósnak, ha nem készít saját kezűleg egy körvakut. Eszméletlen mennyiségű különböző megoldás létezik. Kezdve a fényalagút módszertől egészen a LED lámpa gyilkolásig. Elhatároztam, hogy én külön utat fogok járni.

Először is be kellett szerezni a legdrágább alapanyagot, a LEDeket. Egy méter LED szalagot vettem, mert rövidebbet nem akartak eladni. Egy ezrest kellett kipengetni érte. Ha már úgyis villamossági boltban voltam, vettem vezetéket is. Mikor a projektet kezdtem, még nem volt annyi szétszerelt elektromos játék a szekrényembe, mint most, ezért kénytelen voltam a szép vékony vezeték helyett egy telefonkábelt venni, mert csak ez volt az üzletben. Akkor már egy kapcsolót is hozzácsaptam a csomaghoz.

A körvaku váza egy szétbontott merevlemezből a műanyag félkör alakú alkatrészek voltak, amelyek elválasztották az adat tároló korongokat. Egyik végükön fülek voltak, a másik végükön egy lyuk. A lyukakat összecsavaroztam, a két fület egy rugóval fogtam össze, amit a bigyóim között találtam.

A vázra ráragasztottam a LED szalagból levágott darabokat, majd a végeket a vezetékekkel összeforrasztottam. A tápegységből átalakított labortáppal ki is próbáltam.

korvaku1.jpg

Természetesen az első verzión a polaritásokat elrontottam, ezért nem világít minden egység. Némi utómunka után már mind a 12 világított. Még szerencse, hogy ezeket a LED szalagokat bolondbiztosra tervezték, mert még ez sem okozott kárt benne.

Utána jött a neheze, ugyanis szükségem volt áramforrásra. Már a szalag megvásárlásánál próbáltam alkudozni az eladóval, hogy olyat adjon, amelyiknek nem kell 12V, de nagyon furcsán nézett rám (ez van, ha az ember zéró tudással nekilát vásárolgatni). Végül úgy döntöttem, hogy majd később aggódok az áramellátás miatt, és megvettem a szalagot.

Egy másik boltban, szintén előzetes utánaolvasás nélkül, kértem 12V-os elemet. Nem tudtam, hogy van-e ilyen, de kiderült, hogy bizonyos riasztók 12V-os elemmel mennek. Az elem viszont olyan kicsi méretű volt, hogy attól féltem, nem lesz elég nafta benne, hogy 2 percnél tovább világítson. Végül próba-szerencse alapon hármat vettem, és párhuzamosan kötöttem őket.

korvaku2.jpg

Működött! Egy használt monitorból (vagy rizspapírból) még a diffúzort is lehetne rakni rá, hogy egy kis szórt fényt kapjak, de így is elégedett voltam a munkával. Lássunk egy tesztet.

Vaku nélkül:

noflash.jpg

Vakuval:

flash.jpg

A kép természetes napfény mellett készült, itt a vaku szerepe elhanyagolható volt. A záridő 1/160-ról 1/200-ra csökkenhetett 13-as rekesznél, ami nem egy nagy különbség. Rosszabb fényviszonyok mellett biztos nagyobb hasznát veszem majd.

Szólj hozzá!

Címkék: barkácsolás

Új élet a régi tápegységnek

2022.05.06. 22:15 Travis.CG

Habár a gépem régi tápegysége már nem tud ellátni egy számítógépet árammal, azért még nem teljesen használhatatlan. Arra gondoltam, jó lenne egyfajta labortápnak. Moduláris volta miatt könnyen lehetne használni több feladatra is, csak építeni kellene neki átalakítókat.

Azt tudtam, hogy az alaplapra csatlakozó 24 pin-es konnektor zöld vezetékét kell összekötni a fekete vezetékkel, és akkor bekapcsol. Egy dróttal ki is próbáltam, és örömmel láttam, hogy a hűtő ventillátor felpörög. Első nekifutásra le is vágtam a csatlakozót, kidobtam a kukába, majd összeforrasztottam a két vezetéket és vártam a csodát.

A csoda viszont elmaradt. A tápegység meg sem nyikkant. Én meg nem értettem, mi változott meg? Az előbb még működött! Kénytelen voltam kukázni egyet, és megnézni a csatlakozót még egyszer. Észrevettem, hogy néhány esetben két vezeték megy egy végpontba. Egy vastagabb és egy vékonyabb, mindkettő ugyan olyan színű.

tapveg.jpg

Bizonyára ez lehet a ludas! Kikerestem a vékonyabb vezetékeket, majd azokat is összeforrasztottam a vastagabb párjukkal. Most már ment! Először utána kellett volna olvasnom a modernebb tápegységeknek. Utólag meg is tettem, amiből megtudtam, hogy még egy dolog visszavan. Kell némi terhelést is adni neki, hogy leadja a megfelelő feszültséget.

Az első funkciója a telefon töltés lett. Az 5V-os ágra ráforrasztottam egy hibás telefon töltő microUSB csatlakozóját. A családban sajnos szaporodnak a hibás telefon töltők, de így azokat sem kell kidobni.

telotoltes.jpg

Elméletileg laptopot is lehetne tölteni, mert a legtöbb 12V-ot igényel. Mivel nincs hibás laptop töltőm, jót meg nem akartam szétbarmolni, ezért ezzel nem foglalkoztam, de a lehetőség megvan rá. Helyette két krokodil csipeszt illesztettem a VGA kártya 12 voltos ágára, mert ez egy olyan feszültség, amire gyakran van szükségem.

Egy diavetítő volt a második áldozat, amit sikeresen működtettem vele. A diavetítő egyszer csak megadta magát, és mivel nem találtam benne érintkezési hibát, a trafójára gyanakodtam. Mivel az égőnek csak 12V kellett, a krokodil csipeszes megoldásnak köszönhetően működtetni tudtam. (Az csak egy plusz poén, hogy a trafó hibátlan volt, a gondot egy oxidálódott vezető lemez okozta, ami úgy megnővelte az ellenállást, hogy a vetítő lámpája nem világított, de a multiméter nem jelzett érintkezési hibát.)

A jövőbeni terveim egyike, hogy két tűcsatlakozót is kap majd az egyik ág, hogy a próbapanelem is el tudjam látni árammal. Lehetne még USB A aljzatot is szerelni rá, hogy még több eszközt kapcsolhassak rá.

Az Amiga 1200-es meghajtására már eddig is voltak PC tápegység módosítások, ha tudnék szerezni egy Amiga csatlakozót, akkor azt is rá lehetne szerelni.

Az igazi viszont az lehetne, ha a moduláris kábeleket készíthetnék. Úgy értem, ahogy a moduláris tápegységhez is van merevlemez tápkábelek vagy VGA adapter kábelek, úgy én is készíthetnék USB-s kábeleket, krokodilcsipeszes kábeleket és mindig azt csatlakoztatnám rá, amire épp szükségem van.

Szólj hozzá!

Címkék: barkácsolás

Revision 2022, pályára állunk

2022.05.01. 22:32 Travis.CG

Mivel idén is az online térbe került a Revision, a szervezők csavartak egyet az eseményen, és helyi szatellit partik szervezésére bíztatták az embereket, hogy a semminél több legyen a party feeling. Magyarországon két helyszínen szerveztek buli pótlékot: Budapesten a Vault 51-ben és Gombán. Akit érdekel, itt elolvashatja Vickey élménybeszámolóját.

Idén nem készültem semmivel. A magyar indulókat Gargaj gyűjtötte össze ebben a cikkben.

Zenék

Gargaj első lett procedurális zenében. Ezt leszámítva számomra az összes zenei kompó teljesen felejtős volt. Próbáltam többször visszahallgatni őket, hátha valamelyik mégis megragad bennem, de nem volt eredménye. Furcsa módon még az oldscool zenék voltak azok, amelyek a legkevésbé borítottak ki, pedig hosszú távon nehezen szoktam elviselni a sok pittyegést.

Grafikák

Bármelyik grafikai kompót is néztem, egyik sem tetszett. A 3D rém primitív volt. A sok animált GIF unalmas. A fotók egy-két érdekes képtől eltekintve sablonosak voltak. Két fotó ráadásul jobban illett volna a grafikai kompókba, mert kizártnak tartom, hogy azokat a lézer-szerű vonalakat számítógép nélkül csinálták. Az egyiknél nem is mellékeltek eredeti képet (a szabályok szerint kellene), a másiknál meg olyan képeket mellékeltek, amelyik nem is hasonlít a végeredményre.

Animációk

Két produkciót érdemes csak megemlíteni. Ebből a Desert Dream 2022-be rengeteg energiát öltek, de egy elég szerencsétlen időszakban adták le. Most, hogy minden médiumon a háború szörnyűségei vannak, elég nehéz jól szórakozni egy idegen invázión. A második helyezett Dystopic Nightmare viszont minden ízében eltalált alkotás.

Intrók

Az Amigás intrók közül a Software Failure Antelogiumja olyan volt, mint egy mini demó. Annyi rész volt benne, hogy az ember azon gondolkodott, hogyan fértek el egy intróban? A másik kedvencem a LogicOS volt. A grafika nagyon egyszerűnek hatott, de ez ne tévesszen meg senkit. A hangüzenet biztos megnehezítette a méretkorlát fenntartását.

A PC4k. Ezen bealudtam. Ötletesek voltak, de nem volt semmi világmegváltó. A legjobban az Addict intrója tetszett, mert volt a legjobb a zene. Az első három helyezett zenéje elég szegényes lett. A győztes intró ráadásul olyan volt, mint egy procedurális grafika nyolc kameraállásból.

A 256b intrók tetszettek. A forgó Föld nagyon ötletes volt, de a Linerider volt az, ami belopta magát a szívembe.

Demók

Az idei Amiga demók rém gyengék voltak. A győztes Soul Strain nagyon repetitív volt. A demó fele szövegből állt. Egy intró szintjét ütötte csak meg. Mentségére legyen mondva, hogy kezdő Amigás csapatról van szó. Szerencsére az oldskool demók hozták a szintet. Nem kell nagy dologra gondolni, viszont korrekt munkák voltak. Kiemelném a Quantum Leap demót, mert KC 85-re írták, ami - kis utánanézést követően - kivívta nálam a legrondább számítógép díját. A Videoton ehhez képest iparművészeti alkotás.

Nem hittem volna, hogy valaha ilyet írok, de a PC-s demók mentették meg a napot. Tizennyolc alkotást adtak be, akadtak töltelék demók is közöttük, de egyharmada teljesen rendben volt. Kevin, a Spacepigs visszatérő főszereplője kezd kicsit megkopni, már fele annyira sem vicces, mint régen. A Futuris viszont nagyon magára talált az Unreal Engine-el. Egyre színvonalasabb alkotásokat láthatunk tőlük. Idén például ők nyerték a compót. Igaz, egyetlen erős csapat sem indult.

Szólj hozzá!

Címkék: demoscene

Búcsú a Tom Clancy-regényektől

2022.04.27. 20:30 Travis.CG

Kamaszkoromban elég sok Tom Clancy-regényt olvastam. Akkoriban a Hidegháború a vége felé közeledett, az internet gyerekcipőben járt, a CNN-ből meg nem értettem semmit, ezért ezek a regények egyfajta információ forrást jelentettek nekem, hogyan is működhet az amerikai vezetés. A világról sokkal kevesebbet tudtam, ezért az ott leírtakat el is hittem.

Ezekben a regényekben a világ azért működik, mert Amerika azt teszi, ami helyes. Amerika pedig azért teszi azt, ami helyes, mert olyan fehér férfiak irányítják, akik egy magasabb erkölcsi normának engedelmeskednek. Ez a küldetéstudatuk annyira erős, hogy egyes emberi törvényeket is áthághatnak érte.

A regények főhősei ezek az erkölcsileg megingathatatlan férfiak. Szakmájukban abszolút profik, keveset beszélnek, érzelmeiket elnyomják. Ha hasonszőrű férfival találkoznak, csak a szemébe néznek, és máris látják, hogy azok is ugyan olyan profik, mint ők. Miután végigmérték egymást, már csak apró biccentésekkel és kimondatlan szavakkal kommunikálnak. Ha mégis felbukkan egy női főszereplő, az csak egészségügyi dolgozó lehet. Ez alól csak Mary Pat Foley és Andrea Price a kivétel, de az ő karaktereik is inkább szoknyába bújtatott férfiak, mint nők.

Minden regényben az Egyesült Államoknak van egy dedikált ellensége, aki elkövet valami szemétséget, de végül egy hathatós katonai művelettel lerendezik azt. Az államnak nincsenek belső konfliktusai. Egy-két áruló azért akad, hogy a feszültséget fenntartsák, de őket csendben, bármilyen tárgyalás vagy vádemelés nélkül elteszik láb alól.

Minden annyira tökéletes ebben az Amerikai Álomban, hogy amikor a szerző mégis valami konfliktust próbál belecsempészni, az nagyon erőltetettnek hat. Például, mikor Jack Ryan elnők ellen merényletet szervez két fickó. Ez egy mellékszál a regényben, de végül nem vezet sehova. Egy rendőr szó szerint kiszagolja a robbanóanyagot és lekapcsolja a bajkeverőket.

Az első fekete elnök ellehetetlenítése is frucsa vargabetű volt, hiszen a regényekben nincs rasszizmus. (Ebben a világban ugyanis az FBI elfogta az összes Ku-Klux-Klán tagot, ami megszűntette az egész generációkon átívelő társadalmi problémát.) Ezért kellett egy öreg klán tag, akit elkerült a letartóztatás és ezért végrehajthatta a merényletet.

Az egészségügyi rendszerrel sincs semmi probléma. Amikor a terroristák Ebolával fertőzték meg az egész országot, az orvosoknak hála még csírájában elfolytották a járványt. Nem voltak Ebola-szkeptikusok, nem voltak szegények, akik rosszabb orvosi ellátást kaptak (esetleg olyanok, akiknek nincs egészségügyi biztosítása, ezért köztük a járvány erőteljesen tombolna.)

Aztán voltak a szerzőnek olyan megnyilvánulásai, ami után viszakozni kényszerült. Jack Ryan elnök ugyanis megoldotta a közel-keleti konfliktust is! Ez már tényleg annyira meseszerű lett, hogy a következő regényben volt egy lábjegyzet-szerű megjegyzés, hogy mégsem sikerült.

Az egész lufi számomra akkor pukkant ki, amikor a Tigris és Sárkány című regényben az Egyesült Államok pár nap alatt lealázta a Kínai Népköztársaság haderejét (igaz, ott volt az orosz hadsereg is, de csak mutatóban). Már a konfliktus eszkalálása is nagyon furcsa volt. A különböző diplomáciai manőverek ugyanis számtalan kiugrási pontot nyújtottak Kínának, akik ezzel egyszerűen nem éltek. A szerző meg elintézte annyival a kínai vezetés logikátlan lépéseit, hogy "ezek Klingonok". A kínaiak nem értették azokat az erkölcsi normákat, amelyek egy Clancy-regény főhősét mozgatják, míg a főhősök nem értették, a kínaiak mit nem értenek. A kínaiak még azt is figyelmen kívül hagyták, hogy Oroszországot felvették a NATO-ba.

Eközben az amerikai elnököt olyan dolgok foglalkoztatták, hogyan tudná megoldani, hogy a nők és férfiak ne éljenek szexuális életet a házasság előtt.

Végül kitört a háború, ami olyan lett, mint egy GI Joe rajzfilm, ahol a katonák mindig ki tudnak ugrani a szétlőtt járművekből. Az Egyesült Államok vesztesége 0(!) volt a teljes konfliktus ideje alatt. Az egyetlen izgalmas esemény, hogy majdnem megközelítettek vadászgépek egy AWACS-et. Az oroszok bezzeg tömegével halltak meg országukért. De azért nekik is kijutott a hősi cselekedetekből. Egy második világháborús veteránnak a hadsereg katonái megengedték, hogy lelőjön egy kínai tábornokot, mert ez a trófea még hiányzott az öreg listájáról.

Egyértelművé vált számomra, hogy Tom Clancy már nem tudja tartani a lépést a modern világgal. Át is adta a cselekmények vezetését először Grant Blackwoodnak, majd Mark Greaney-nek. A regény szereplői is kezdtek elöregedni, ezért ők is szép lassan lecserélődtek. Az események során ugyanis a karakterek elkezdtek egymás között házasodni, gyerekek születtek, mint valami telenovellában.

A cselekményformálás is szakított a régi formulával. Korábban ugyanis a szereplők oldalakon keresztül dumáltak egymással, terjedelmes belső monológok voltak, amelyen keresztül az olvasó megértette, mi miért történik. Az újabb regényekben több a csihi-puhi, amitől az regények kerete egy akciófilmre kezdett hasonlítani. Mintha egy forgatókönyvet olvasnánk. Az akciók is erősen emlékeztettek moziban látott jelenetekre. Például az egyik során a szuper titkos árnyék ügynökség teljes csapata háztetőkön keresztül menekült a rendőrség elől.

Az új regények egyik kellemes hozadéka volt, hogy megpróbálták az aktuálpolitikai eseményeket a narratíva részévé tenni. Itt is volt polónium-mérgezés, Donyecki-megszállás, kínai terheléses támadás kormányzati szervek ellen. Viszont az elképzelhetetlen elemek is megszaporodtak. Az egyik ilyen az volt, amikor az egyik főszereplőnek átadták a telje orosz haderő vezetését, mert ők nem tudták kezelni a krízist. (Pontosan az után, hogy egy áruló FSZB ügynök majdnem halálra kínozta.) De arra is felhúztam a szemöldököm, hogy ennek a szuper titkos ügynökségnek a tagja az elnök fia is, akit többen ismernek fel Hong-Kongban, mint hazájában. Ez a tény viszont egyáltalán nem megy a titkos műveletek rovására.

Talán nem is az a bajom, hogy a regények nem reálisak. Elvégre ha teljesen reális lenne, olvashatatlan volna. Inkább az a baj, hogy az internet segítségével olyan részletességgel kapunk információkat valódi konfliktusokról, hogy ezek a regények már bohózatnak tűnnek mellettük. Esetleg mégsem. Néha a valóság tűnik bohózatnak. Ha Ryan elnök robbanó fákról beszélne, a könyvet azonnal a falhoz csaptam volna. Akár mi is az igazság, a háború már nem tűnik szórakoztatónak.

Szólj hozzá!

Címkék: életmód

Megkövesedett tudás

2022.04.05. 10:10 Travis.CG

Pontosan nem emlékszem, hol hallottam, hogy a cikkek leírják, amit két évvel ezelőtt tudtunk. A könyv leírja, amit 5-10 évvel ezelőtt tudtunk, az egyetemi oktatásban pedig megjelenik, amit 20 évvel ezelőtt tudtunk. Habár az itt leírt számok változhatnak, az tény, hogy az oktatott anyagban mindig van egy késleltetés.

Ez egyrészt szükségszerű, mert mint a koronavírus-járvány kapcsán is láttuk, minden információnak szüksége van egy kis pihentetésre, ami alatt vagy megcáfolják, vagy megerősítik azt. Másrészt óhatatlanul maradnak a tananyagban olyan részek, amelyeknek inkább történeti érdekessége van, mint aktualitása.

Apám is sokszor mesélte, hogy a főiskolán még mindig a logarléc használatát verték beléjük, pedig akkor már látszott, hogy az elektronikus számológépek sokkal pontosabban és gyorsabban kiszámolják ugyan azt. Ennek ellenére, amit ott megtanult anyagismeretben, azt mind a mai napig hasznosítja.

Ezzel szemben én, mikor végeztem az egyetemen, és elhelyezkedtem az első kutatóintézetben, mindenki a mikroRNS-ekről beszélt, amiről azt sem tudtam, hogy micsodák, mert a genetika oktatás még a junk DNA koncepciónál tartott. A PhD védésemen is szembesültem az információ elavulás mértékével, amikor megkérdezték, miért nem használtam Chip-seq eredményeket a hipotézis igazolására. Azt válaszoltam, mikor elkezdtem a PhD-t, azok a módszerek még nem léteztek. (Igen, kicsit hosszúra sikeredett az eljárás.)

De már a PhD-m alatt is voltak jelek, hogy nem mindig azt kell megtanulni, amit tanítani akarnak. Például a témavezetőm bioinformatika kapcsán a GCG programcsomagot tanította, pedig akkor már látszott, hogy a liszenszelés miatt nem sok jövője lesz. Akkor javasoltam neki, hogy mi is térjünk át az EMBOSS tanítására, mert a hazai kutatócsoportok mind ezt teszik.

Végül mégsem tértünk át, mert a témavezetőm szerint a GCG-ben a szekvencia beírásnál át lehet definiálni a billentyűket, tehát az ATGC nukleotidokat a QWER billetyűkkel lehet beírni. Ha pedig kapunk egy autoradiográfot, akkor ezzel a módszerrel nagyon gyorsan bepötyöghetjük a nukleotidokat. Természetesen, miután elég gyakorlatot szereztünk, hogy az autoragiográf megfelelő oszlopait agyban összepárosítsuk az egymás melletti billentyűkkel.

Csupán egyetlen gond volt ezzel a ragyogó módszerrel. Soha nem kaptunk autoradiográfot, mert a szekvenáló gépek akkor már floureszcens festéket használt jelölésre, és a szekvenáló cégek az eredményt elküldték e-mailen, tehát gépelni sem kellett.

Most újabb dilemma elé kerültem. Ismét oktatnom kellett, ezért a főnököm elküldte az előadás anyagát, hogy abból válasszuk ki a nekünk tetsző témakört, amit megtartunk. Megpróbáltam olyan fejjel végignézni a tematikát, hogy mi az az információ, ami az eddigi munkámhoz releváns. Akkor megláttam, hogy két teljes óra anyaga az EMBOSS-ról szólt. Arról a programcsomagról, amiért 20 évvel ezelőtt kardoskodtam, hogy oktatni kell, mert az a jövő.

Gondolkodtam, mikor is használtam utoljára. Már 5 éve. Tizenegy éve nem fejlesztik. A legtöbb rá mutató link döglött. Kérdeztem a munkatársaimat is, ők mikor használták, de nem emlékeztek rá. Úgy néz ki, kicsi az esélye, hogy a jövőben használni kell, ezért azt javasoltam, vegyük ki a tanagyagból.

De mi legyen helyette? Valami olyasminek kellene lennie, aminek biztos nagyobb lesz a jelentősége a jövőben, és nem árt hallani róla. Például a gépi tanulásról. Szerintem már túljutottunk a deep learning hype-on, és már kezdjük csak azokra a feladatokra használni, amire ténylegesen való. Az AlphaFold kapcsán pedig láthattuk, hogy komoly eszközök alapja lehet. (Persze a szakmai féltékenység oldalát sem szabad elhanyagolni. Láttam egy nálunk kevésbé felkészült csoport tematikáját, akik büszkén hírdetik a deep learninget a bioinformatika tárgyukban. Mire én: nehogy már ők oktassák, mi meg nem!)

Végül kiegyeztük a főnökömmel egy kompromisszumban. Az EMBOSS-os óra helyett legyen egy algortimusos óra, ahol érintjük a gépi tanulást is, az EMBOSS pedig be lesz sűrítve máshova. Ezután már tényleg nem volt más dolgom az előadásokkal, csak kitörölni azokat az örök becsű diákat, amelyek megörökítették a hallgatóknak, hogyan is nézett ki az EBI honlapja 2011-ben, 2014-ben és 2019-ben. Eltávolítani olyan hivatkozásokat, ahol például a program helyett már csak a fejlesztő nekrológja található. Kicserélni néhány diát, ahol a weboldal működését Netscape Navigatorral mutatják be. Sajnos ezzel annyi idő elment, hogy nem tudtam a Windows XP-s Blast futtatás lépéseit aktualizálni. Sebaj, jövőre is kell hagyni valami munkát.

Szólj hozzá!

Címkék: bioinformatika

Ez most nem vicc: teljes humán genom

2022.04.01. 07:55 Travis.CG

Ami évekkel ezelőtt még április 1 ugratásnak indult, ma már valóság. Megvan a teljes humán genom minden egyes nukleotidja. Úgy is mondhatnánk, hogy idén az a poén, hogy volt régen egy poén, ami többé nem poén.

A Science egy teljes számot szentelt a témának, de akit érdekel a dolgok háttere, annak a Nature Methods bemutat egy variáció szűrő eljárást, és egy genom polírozást is.

Amit külön is ki szeretnék emelni a konzorcium munkájából, hogy rengeteg fájlt adtak közzé, amivel segítik az egyszerű halandók átállását az új genomra. Liftoff fájlok, hogy a régi adatokat át lehessen konvertálni az új genomra, ClinVar annotáció, dbSNP, stb. Az összes információ egy helyen megtalálható.

Szóval bárki bármit csinált eddig a humán genom felhasználásával, most törölje le, és kezdje újra! Az élet szép!

2 komment

Címkék: bioinformatika

Sun élesztés

2022.03.27. 22:18 Travis.CG

Az intézetünkben a régi gépeket elkezdték kiszórni. Mint megtudtam, köztük van néhány Sun is. Elhatároztam, hogy ezeket megmentem, hogy ne végezzék egy szeméttelepen. Az egyik gép egy Sun Ultra Enterprise 2 munkaállomás.

A karrierem elején még dolgoztam Sun szerverekkel, de ez a gép még annál is régebbi. Olyan, mint egy Hidegháborús maradvány. Vastag, erős háza van. Majdnem negyven kilós monitora. A kábelek fél centi átmérőjűek. Még a billentyűzet is olyan vastag műanyaggal van burkolva, hogy egy kisebb kocsmai csete-patéban fegyverként lehetne használni.

sunbill.jpg

A gépben két processzor van, 1Gb memória, SCSII CD-ROM. Utóbbinak a tálcája nem nyílik és furcsa zörgő hangot ad, amikor felpörög.

Már a gép bekapcsolása is tartogatott meglepetéseket. Mikor fél perc után sem adott semmilyen képet, levontam a következtetést, hogy ez bizony kimúlt. Viszont ezt nem akartam elhinni. Egy ilyen gép nem múlik csak úgy ki! A második vagy harmadik kísérletnél viszont valami miatt el kellett mennem, mert máshol volt dolgom. Mikor tíz perc múlva visszamentem, a gép élt. Szóval csak ki kellett várni az időt!

Később kiderült, hogy boot előtt egy hosszabb ellenőrzési folyamat van, aminek az állapotát a Caps Lock, Num Lock, stb gombok kis ledjei jeleznek. Ezt a gép dokumentációjából lehet megtudni. Az Oracle-t lehet szidni az üzleti lépései miatt, de azért nem, hogy nem teszi elérhetővé a doksikat. Rengeteg részletes leírást találtam a gép felépítéséről és a különböző hibákról.

A gépek másik jellegzetessége, hogy az alaplapi akkumulátor nem egy gombelem, mint a PC-k esetén, hanem egy tokozott IC. Ha lemerül, nemcsak a rendszer óra törlődik, de a hálózati kártya MAC címe is. Ettől az egész rendszer pánikba esik az ellenőrzések során, és megtagadja a boot-ot.

Viszont az OpenBoot (ez a gép firmware-je) segítségével el lehet érni minden eszközt. Egy Forth nevű programozási nyelvet is tartalmaz, amivel kisebb programokat is írhatunk. Ez ma már elképzelhetetlen lenne. Jelenleg az a trend, hogy a felhasználók a gép minél kevesebb eleméhez férhessenek hozzá a manapság uralkodó paranoia miatt, hogy valaki kártékony kódot ír benne. Annak idején a viszont a használhatóság volt az elsődleges prioritás.

A neten találtam némi anyagot, hogyan lehet beírni a MAC címet a memória megfelelő részébe. Sajnos bármilyen értéket nem írhatunk be. A MAC cím bizonyos pozícióira a gép típusának megfelelő értéket kell beállítani. A neten talált leírás persze nem felelt meg a birtokomban lévő a gépnek.

Egy rövid ideig random hex kódokat vittem be, reménykedve, hogy elindul a masina, de természetesen nem volt szerencsém. Végül egy videó képkockáit elemezve találtam egy olyan értéket, amit a gép elfogadott. Itt a teljes lista.

setenv diag-switch? false
1  0 mkp
80 1 mkp
8  2 mkp
0  3 mkp
20 4 mkp
1b 5 mkp
ad 6 mkp
b7 7 mkp
0  8 mkp
0  9 mkp
0  a mkp
0  b mkp
8f c mkp
ce d mkp
e5 e mkp
0 f 0 do i idprom@ xor loop f mkp
reset

Eljutottam arra a szintre, hogy tudtam bootolni! Sajnos az értékek beírását minden egyes bekapcsoláskor meg kell ismételni. Az operációs rendszer még nem indul el, mert a gép valamit nagyon keres a neten, de persze már nem találja. Még messze vagyok attól, hogy egy új wild demót kódoljak a gépen, de legalább már az látszik, hogy érdemes energiát vesztegetni rá.

Szólj hozzá!

Címkék: barkácsolás Sun

Differenciál expresszió felülvizsgálva

2022.03.22. 10:53 Travis.CG

A tudományban nem sok helye van a berögzült szokásoknak. Már csak azért sem, mert jöhet egy olyan új vizsgálat, ami fenekestül felforgatja az eddigi ismereteinket. Például eddig sem rejtettem véka alá ellenszenvemet a Wilcoxon-teszttel szemben, ezért is ért meglepetésként, hogy az egyik cikk egyenesen azt javasolja, hogy csakis ezt használjuk, ha differenciál expressziót akarunk számolni nagy ismétlésszámmal.

De mielőtt leborulnánk bizonyos kutatócsoportok lába előtt, akik már évek óta mindenre a Wilcoxon-tesztet használnak, nézzük meg alaposabban is a problémát.

Kezdjük azzal, hogy minden döntéshozatal téved. Szándékosan nem a statisztikai próbákat említettem, mert azok csak számokat adnak vissza eredményül. A számok alapján viszont mi, emberek döntünk, és ez a döntés nem minden esetben pontos. Ezeket a tévedéseket szintén számszerűsítjük, ez a fals pozitív és fals negatív.

Az is köztudott, hogy a különböző döntési kritériumok, különböző módon tévednek. A szakértők ezeken szoktak vitázni, hogy melyik döntés a jobb. A lehetséges döntések száma pedig nagy.

Nincs ez másként a differenciál expressziós elemzéseknél sem. Itt azt kell eldönteni, hogy melyik gén mutat megnövekedett, vagy csökkent expressziót válaszul egy hatásra. Génből pedig sok van. Korábban már erről is írtam.

A fent említett cikk is azzal indít, hogy két programmal is megnézték az expressziós különbségeket, és nagyon kevés gén volt az, amelyik mindkét módszerrel feljött. Ezért elkezdtek utána menni, hogy miért látják ezeket a különbségeket. Mivel manapság nem ritkák a nagyon sok ismétlést tartalmazó kísérletek, kiválasztottak egyet és random összekeverték a csoportokat, meghatározták az eltérő expressziót mutató géneket, majd az egész folyamatot megismételték ezerszer.

Ez egy rendkívül okos megközelítés. A cikkben azt mondták, hogy az így kapott gének mindegyike fals pozitív. Ez nem teljesen igaz. Ha a véletlen csoport bontás jórészt átfed a valódi csoportokkal (nagyszámú permutációs ismétlésnél előfordulhat), akkor feljöhetnek valódi pozitív eredmények is. Szerencsére a cikkben azokat a géneket emelték ki, amelyek a permutációs vizsgálatok 50%-ban feljöttek. Ezeket tényleg nehéz lenne nem fals találatoknak tekinteni.

Ezek alapján pedig a DESeq2, edgeR sokkal több fals pozitív eredményt ad vissza, mint amennyit beállítottunk, míg a Wilcoxon-teszt sokkal kevesebbet.

Azért azt hozzá kell tenni, hogy nem kell kidobni a kukába az összes DESeq2-es számítást. Ha az ismétlések száma kevesebb, mint 8, a Wilkoxon nem ad vissza értékelhető eredményt. Nyolc ismétlés felett viszont a cikk szerint statisztikai erőben nincs különbség a két módszer között, miközben a fals pozitív a Wilkoxon teszt felé billenti a mérleget.

Amit viszont nem értettem a cikkben, hogy miért hagyták ki a t-próbát az összehasonlításokból. A felsorolt indokok meghaladták az én statisztikai ismereteimet, de az is lehet, hogy nem volt kedvük megcsinálni, mikor kérte tőlük egy bíráló. A normalizált adatok logaritmikus transzformációjával elméletileg a t-próbát is lehetne használni.

Mint minden eredménynél, természetesen itt is van ellenvélemény. Röviden arról van szó, hogy nem a statisztikai tesztet kell kicserélni egy kisebb erejűre, hanem a null hipotézist kell megfelelően megválasztani.

Szólj hozzá!

Címkék: bioinformatika

Ki bírálja a bírálót?

2022.03.07. 00:01 Travis.CG

A kutatók az egyes közösségi platformokon rendszeresen szoktak siránkozni, hogy miért vannak a publikációknak bírálói, hiszen ők mennyire jól tudják az összes módszertant, milyen kiválóan terveznek kísérletet. Számukra a bírálók azért vannak, hogy az életüket megkeserítsék és a jogos dicsőséget elodázzák.

Talán ezek a kutatók tényleg olyan kiválóak, ahogy állítják magukról. De bárki, aki hosszabb ideje bírál bármilyen folyóiratnak, az tudja, hogy ezek a sztárok (már amennyiben igazuk van) vannak kisebbségben. A beküldött cikkek nagy számban szemetek. Merem ezt kijelenteni pár éves bírálói tapasztalattal. Sőt, minél alacsonyabb presztizsű egy lap, a hulladék cikkek aránya annál nagyobb (mivel az elutasított kéziratokat senki sem látja, ezért ezt a kijelentést lehetetlen ellenőrizni).

Ezért úgy gondolom, hogy a cikkek bírálóira igenis szükség van. Még akkor is, ha ezen a rostán átjuthatnak elég furcsa, cikkeknek tűnő irományok is.

A bírálók nevét nem ismerik a kézirat szerzői. Rejtve vannak a sötétben, onnan böffentik ki bölcsességeiket, vagy hatalmas baromságaikat. Az anonimitás miatt akár sekélyes bosszújukat is véghez vihetik.

Annak ellenére, hogy igazából semmilyen hátrányos megkülönböztetés nem érheti a bírálót, az mégsem egy népszerű munka. A legtöbb kutató nem akarja a munkaidejét mások munkájára pazarolni. Itt is olyan érvek szoktak elhangzani, hogy ezt a tevékenységet meg kellene fizetni.

Ezzel csak az az egy probléma, hogy pontosan mit is kellene megfizetni? A bírálatot? Én már kaptam egy mondatos bírálatot. Ez az ember kapjon ugyan annyi pénzt, mint az, aki sorról-sorra átnézte a kéziratot és sorszámmal kigyűjtötte az összes elírást is? Az a baj az emberekkel, hogy azt csinálják, amiért jutalmazzuk őket. Ha a hosszú bírálatért több pénzt lehet kapni, mindenki könyveket fog írni. Ha a pozitív bírálatokat előnybe részesítik, akkor mindent el fognak fogadni. Előbb-utóbb megjelennek a megélhetési bírálók, akik akkor is bírálni fognak, ha nem kell.

Arról nem is beszélve, hogy állítólag olyan témavezetők is vannak, akik PhD hallgatóknak adják ki a bírálatot. Ezek az emberek vajon a pénzt is kiadnák a kezükből?

Továbbá ott van a tévedés lehetősége. Mi van, ha egy bíráló téved? Egyes cikkeket tizenöten is írhatnak, mégis elég két (egyes esetekben három) ember, hogy elbírálja. Nem biztos, hogy ez a két ember a kézirat minden egyes részével annyira tisztában van, mint annak a szeletnek a szerzője. Bevallom, nekem is gondot okoz, mikor kísérletes validálások eredményeit kell értelmeznem. (Most jön az a rész, hogy bezzeg az én időmben, még a PCR sem volt RT. Legalábbis a labornak nem volt rá pénze.)

Egy dolgot viszont meg lehetne tenni, és ezt meg is szoktam. A névtelenséget el kellene törölni. Tudom magamról, hogy kétszer is meggondolom, mit írok le, ha tudom, hogy a nevem is ott lesz mellette. Igaz, hogy bírálónak hívjuk azokat, akik a cikket átnézik, de igazából nem bírálnak semmit. A véleményüket mondják el, ami alapján az editor dönt. A jobb editorok pedig tudják, mi az, amit a bírálatból érdemes megtartani, és mi az, aminek semmi értelme.

Az más kérdés, hogy a legtöbb editor megelégszik azzal, hogy papagáj módjára visszamondja, amit a bírálók leírnak. De igazából nekik lenne a dolguk, hogy az egymással gyakran ellentétes véleményeket összefogják.

Szerencsére egyre több újságnál a bírálat nem egy egyirányú folyamat. A szerzők reflektálhatnak a bírálatokra, megvédhetik a döntéseiket. Gyakran egyfajta párbeszéd is kialakul a bírálók és a szerzők között. Ezekből én is sokat szoktam tanulni (meg a többi bíráló véleményét is hasznosnak szoktam találni, mert másfajta nézőpontot képviselnek.)

Szólj hozzá!

Címkék: filozofálás

Egy kiberfegyver anatómiája

2022.02.27. 23:31 Travis.CG

Mint az közismert, Ukrajnát a kibertéren keresztül is támadják. Az elsők között azonosított ilyen jellegű kiberfegyver a HermeticWiper volt. Ezért elhatároztam, hogy letöltöm, és kipróbálom egy igazi gépen.

Először is, előkészítettem egy gépet. Telepítettem rá egy teljesen új Windows 7-t. A gép házán van egy Windows 7 matrica, de valami miatt nem tudtam azzal a kóddal aktiválni az operációs rendszert. Előtte meg Linux volt rajta, ezért nem tűnt fel, hogy a matricán lévő kóddal gond lenne. Mindegy, ahhoz, hogy elpusztítsam a rajta lévő adatokat, a 30 napos türelmi időszak is elég.

Az első meglepetés számomra, hogy egy alap Windows 7 - ma már - mennyire használhatatlan. A böngésző (ami itt még Internet Explorer) minden második weboldalra azt mondta, hogy nem tudja megjeleníteni. Sikerült nagy nehezen egy Firefoxot letölteni, de az meg nem jelenítette meg a betűket rendesen, csak amolyan pontokat láttam, mintha miniatürizálva lenne a szöveg. Ezek után úgy döntöttem, driverek sem kellenek.

Biztonsági intézkedésként leválasztottam a gépet a netről, majd rámásoltam a HermeticWiper-t és egy malwert, amit állítólag vele együtt telepítenek az áldozat gépére és elindítottam.

A program nem csinált semmit. Ez nem is meglepő, mert a nálam részletesebb elemzések szerint a program egy kereskedelmi forgalomban kapható partíció manager driverét használja. Ha nincs a gépen ez a program, akkor a kiberfegyver használhatatlan.

Bevallom, ez nekem, mint kibicnek, nagyon furcsa. Elvégre, mi az esélye annak, hogy a partícionáló program megtalálható az áldozat gépén? A cég weboldala szerint 530 millió felhasználójuk van, az ESET szerint pedig több száz gépen találták meg a kártevőt.

A meghajtó a program eltávolítása után is a gépen marad, tehát aki egyszer telepítette a fent említett partícionáló programot, az az operációs rendszer cseréjéig támadható marad. Bármilyen szervezeti egységnél a rendszergazdák nem engedik, hogy az alkalmazottak programokat telepítsenek a gépükre. Azt gondolom, elég kicsi az esélye, hogy ez a program kifejthesse kártékony hatását.

Ha mégis működésbe lép, akkor letörli az MBR-t (vagy ha GPT partíciós táblát használnak, akkor azt). Ez elsőre elég ijesztőnek tűnik, de fiatalabb koromban, mikor még nem voltam ennyire rutinos, gyakran felülírtam az MBR-t, mikor Linux után telepítettem a Windowst. Ez viszont viszonylag egyszerűen helyreállítható. Persze rendszergazdaként biztos nem az lenne az álmom, hogy 20-30 gépen visszaállítsam az MBR-t, de elméletben nem lehetetlen.

Összegezve tehát van egy nagyon összetett program, ami a gépek viszonylag kis százalékát meg tudja támadni, és ott okoz egy nem túl nagy problémát. Hangsúlyozom, lehet, hogy a felületes ismereteim miatt nem tudok mindent. Talán az a partíció manager program olyan Ukrajnában, mint nálunk annak idején a Total Commander volt, ki tudja? De ha nekem kellene kártékony kódot írni, ami mindent elpusztít, akkor abból indulnék ki, hogy a célgépen nincs semmi, ami segítene.

A malware szerencsére nem okozott csalódást. Pillanatok alatt végigment az összes elérhető fájlon, és titkosította azokat. Az asztalon hagyott egy üzenetet, hogy melyik e-mail címre kell írnom, ha ki vissza akarom kapni a fájlokat. Ez már valami. De ezt is a felhasználónak kell elindítania.

Tehát a régi bölcsességek továbbra is érvényesek: idegen futtatható állományt ne indíts el, csinálj biztonsági mentést.

Szólj hozzá!

Címkék: biztonság

Mert a kmer az jó

2022.02.13. 22:43 Travis.CG

Bevallom, a teljesen egyszerű ötletek, amelyekre önmagukon jóval túlmutató dolgok épülhetnek, lenyűgöznek. Ettől olyan érzésem lesz, hogy a világban némi rend is uralkodik.

Például vegyük a kmereket. A kmer egy hulla egyszerű ötlet. A DNS szekvenciát ugyan olyan hosszú darabokra vágjuk és megszámoljuk, melyikből mennyi van. Faék egyszerűségű ötlet. Mire lehet használni?

  1. Meghatározhatjuk, hogy van-e kontamináció a mintánkban.
  2. Két szekvenciát összehasonlíthatunk (pl. azonos fajból vannak-e)
  3. Referencia nélkül megmondhatjuk, hogy diploid vagy haploid a szekvencia
  4. Megnézhetjük, van-e adaptor szennyezés
  5. Metagenomikai taxonómia meghatározást végezhetünk
  6. Expressziós különbségeket számolhatunk
  7. Trió adatokban SNP-ket kereshetünk (referencia használata nélkül)
  8. Azonosíthatjuk a repeat elemeket
  9. Megbecsülhetjük a genom méretet
  10. Genomokat szerelhetünk össze

Izgalmasan hangzik? Meghiszem azt! Ráadásul van egy adatstruktúra, amit mintha pont erre a módszerre szabtak volna: a hasítótábla. Mintha csak azt akarta volna valaki, hogy a bioinformatikusoknak legyen egy jó napja.

A kmer alapú vizsgálódás annyira népszerű, hogy külön eszközök vannak rá. Az egyik a KAT. Segítségével készíthetünk hisztogrammot, amivel megtudhatjuk, hogy a különböző gyakoriságú kmerekből mennyi van. Ennek egy szebb módja, amikor a kmer gyakoriságot a GC arány függvényében ábrázolják (kat gcp parancs). Ennek segítségével megmondhatjuk, van-e kontamináció a mintánkban. Ez hasznos lehet egy de-novo összeszerelés előtt.

Minták összehasonlítására használható a kat comp parancs. Például a readek és a belőlük készült genom kmeres összehasonlítása megmutathatja, mennyire teljes az összeszerelés. Ha ugyanis a kettő különböző, akkor a genom építés során nem használtunk fel minden readet.

A program számos ábrát is el tud készíteni, erre nem térnék ki külön. Arra viszont igen, hogy a memória használat tetemes lehet. A program egyik gyengesége, hogy minden egyes alkalommal, ha elfogy a rendelkezésre álló memória, akkor a korábban használt memória mennyiség kétszeresét foglalja le. Ez egyrészt gyorsítja a programot, viszont elég hamar feléli a gép erőforrásait, akár csak a mesebeli sakktábla a király vagyonát.

Ha ilyesmivel van dolgunk, megpróbálkozhatunk a jellyfish használatával, ami szintén egy kmer alapú eszköz, a KAT is ezen alapul. Nem olyan gyors, viszont tapasztalatom alapján kevesebb memóriával is beéri, az általa elkészített kmer táblázatot pedig a KAT is képes olvasni.

Szólj hozzá!

Címkék: bioinformatika

Szellem a múltból

2022.02.08. 18:22 Travis.CG

Nemrég egy olyan ritka alkalom történt, hogy egy nagyon régi barátommal több, mint egy órát tudtam beszélgetni. Minden szóba került, de a legérdekesebb az volt, hogy megemlítette az egyik programomat, amit sokat használta, de mostanában nem működik.

Annak idején (ezt egy 12 éves távlatban kell érteni) írtam neki egy programot, ami képes volt röpdolgozatokhoz feladatlapokat generálni, a hozzájuk tartozó válaszokkal együtt. Az összes kérdés a válaszokkal együtt megvolt egy Word dokumentumban, témakörökre lebontva. Ebből kellett véletlenszerűen témakört és feladatot választani. Azért, hogy a hallgatók ne tudjanak leskelődni, több feladatsort is kellett készíteni, ráadásul három nyelven is oktattak, ezért három ilyen Word dokumentumuk volt. Plusz mindegyik generált feladatlapnak egyedi sorszám is kellett a dokumentálás végett.

A régi verzió ezért beolvasta a Word fájlból kovertált RTF-et, majd a vágólap segítségével új RTF dokumentumokat hozott létre, úgy, hogy kiimásolta a kérdéseket, egy sorral alatta a válaszokat, majd a kész RTF doksikat elmentett, kinyomtatott, ahogy a felhasználó óhajtotta.

Mikor a barátom említette, hogy "mostanság" nem működik (ami kb. 5-6 évet jelenthetett), akkor arra gondoltam, talán elég lehet újra fordítani, mert ezt még Delphiben írtam. Abból is talán a 3-as verzióval.

Ahogy böngésztem a régi kódomat, ezt a ősrégi szellemet, arra kellett jutnom, hogy ezt nem érdemes újból lefordítani. Az egész elavult megoldásokat tartalmazott. Három RTF dokumentum, mint bemenet, mindegyik nyelvnek egy. Mindegyik másik karakter kódolással, hogy a nyelvek speciális betűit is tartalmazza. Végül egy negyedik fájl is volt, aminek csak az volt a szerepe, hogy tárolja a legutolsó feladatlap egyedi sorszámát, hogy onnan lehessen folytatni a számozást.

Miért ne lehetne egyetlen fájlban minden? Egy UTF-8 kódolású fájlban, hogy az egyes nyelvek karakterei szépen jelenjenek meg. Adatbázist nem akartam, mert egyrészt nem volt olyan sok kérdés, másrészt akkor kell írni még egy adminisztrációs programot is, hogy a felhasználók módosíthassák azt. Valami egyszerűbbre lenne szükség.

Így jutottam el az XML-hez. Egy XML-ben tárolhatnám a kérdéseket, válaszokat, nyelveket, és a sorszámot. Sajnos már Delphi fordítom sincs, régen is használtam a nyelvet, ezért arra gondoltam C#-ban írom újra.

Volt viszont egy probléma. Nem tudtam új RTF dokumentumot készíteni. Illetve tudtam, de nem tudtam, hogyan formázzam meg a nyers szöveget. Az egész kegyetlenül bonyolultnak tűnt, én meg nem akartam túl sok időt rászánni.

Ha már XML-ben vannak az adatok, miért ne lehetne a kész feladatlap HTML-ben? Talán még XST-vel fordíthatnám az adatokat. Ez jó döntésnek tűnt, könnyen tudtam formázni, könnyen tudtam összeállítani a feladatlapokat. Böngésző minden gépen van, ezért, amit elment a felhasználó, egyszerűen megtekintheti.

Viszont maradt még egy probléma, a nyomtatás. Eredetileg azt akartam, hogy egy gomb megnyomásával történjen a generálás, mentés és a nyomtatás is. Viszont nem tudtam a teljes oldalt úgy kinyomtatni, ahogy szerettem volna. Oda nem illő fejlécek jelentek meg, oldalszámozás, stb. Erre nekem nem volt szükségem. Mint kiderült, a C# WebBroswer modulja nem más, mint egy Internet Explorer. Mindent tud, amit az, és pontosan ugyan úgy működik. Egy másik szellem a múltból.

Ha szeretnék nyomtatási beállításokat megjeleníteni, akkor meghívhatom a ShowPrintDialog() metódust, ami megjeleníti az Internet Explorer nyomtatási beállításait. Igaz, hogy van PrintDialog verzérlő elem a Visual Studioban, de ez csak PrintDocument típusú objektumokkal működik. Természetesen a WebBroswer nem konvertálható PrintDocument-é.

Volt egy másik problémám is a WebBrowser ShowPrintDialog() metódusával. Ez egy nem modális dialógusablak, tehát mikor egy cikluson keresztül generáltam a feladatlapokat, és a ciklusban megjelenítettem a dialógus ablakot, akkor a ciklus tovább futott, kinyomtatott mindent a rossz beállításokkal, miközben a felhasználó még be sem fejezte a klikkelést a dialógus ablakban.

Egy másik nehézség az volt, hogy a nyomtatási beállításokat csak azután lehet megjeleníteni, hogy elkészült volna a dokumentum, amit ki szeretnék nyomtatni. Ez egyrészt logikus, mert akkor jeleníthető meg releváns információ a dialógus ablakban, ha tudjuk, mit szeretnénk kinyomtatni. Másrészt ha a felhasználó spórolni szeretne a papír mennyiségén, és két oldalt szeretne egy oldalon látni, akkor lehetőséget kell biztosítani, hogy felülbírálhassa az dokumentum oldalbeállításait.

Én viszont több dokumentumot állítok elő egyszerre, nem dobhatom fel a dialógus ablakot minden alkalommal, és pont emiatt az első feladatlap generálása előtt sem. Hacsak nem fűzöm össze az összes feladatlapot egyetlen dokumentummá, vagy nem állítom át a Registry-ben az Internet Explorer nyomtatási beállításait.

Végül utóbbi mellett döntöttem. De ez sem ment zökkenőmentesen. A Registry beállításait pontosan a nyomtatás előtt állítottam át. A feladatlap generáló ciklus legelső dokumentuma még a régi beállításokkal jelent meg, csak a másodiktól látszott az, amit szerettem volna.

Aki kíváncsi a programra, az megnézheti itt.

Szólj hozzá!

Címkék: programozás

süti beállítások módosítása