FreeBSD-n fordítok egy programot, épp a configure fut, amely közli, hogy:

checking if wait function is broken... [kb. 10 másodperc szünet] yes

Ennyi várakozás után minimum egy no-t vártam volna. :)

Nézegettem a blog.hu oldalstatisztikáit, és a leggyakoribb keresőkifejezések között érdekes dologra találtam:

Első találat vagyok a google-ben, megnyugtató a tudat, hogy ha pénzt is akarok látni az oldalból, bármikor átalakíthatom pornólappá. :)

Amikor először láttam rackmount diszkdobozt, rögtön feltűnt, hogy nem jól gazdálkodnak a gyártók a hellyel.
Aki csak a "körön belül" tud gondolkodni, két dimenzióval számolhat: magasság és szélesség. Ez a 19"-es rackeknél valójában egy dimenzió, hiszen a szélesség adott -19 hüvelyk-.

A fent említett első diszkdoboznál (amely egy Sun D1000 volt) ez azt jelentette, hogy 4RU magas volt, és 12 darab (3,5"-es) diszk fért bele. Azaz RU-onként 3 diszk volt a diszksűrűsége.

Ez a sűrűség később javult valamelyest, hiszen 3RU-ba front load technikával 16 diszket is tettek gyártók (5,33 HDD/RU), 4RU-ba már 24 is befért (6 HDD/RU), és születtek mindenféle névtelen fémfeldolgozó cégek agyrémeiből olyan termékek is, mint például ez (RSC-8ED-0Q1):

8RU, 40 darab diszk, azaz sűrűségben még csak nem is túl jó (5 HDD/RU), cserébe ha bedöglik benne valami, imádkozhatsz, hogy kapj hozzá cserealkatrészt.

Ami ezeket a dobozokat nézve mindig hiányzott számomra, az a harmadik (második, a szélesség ugye adott) dimenzió használata. Mindenki csak az elöltöltős mosógépre gondolt, mikor diszkdobozt tervezett, holott a szűk fürdőszobákban már évek óta a felültöltősek hódítottak.

Ez juthatott a Sun eszébe is, mikor megalkotta az X4500 (Thumper) dobozát, amely 4RU-ba elképzelhetetlen mennyiségű (48 darab) 3,5-es diszket tudott besűríteni (12 HDD/RU!).

Ezt a dobozt (és az utódját, a 4540-est) annyira megszerettem, hogy az a blog tetején is tetten érhető. Egyszerűen brutális.

Sok ilyen dobozt használunk, és szeretjük őket. Mégis van velük egy kis baj, amely pont a nagy sűrűséget teszi lehetővé: a felül töltés. Ahhoz, hogy egy diszket kicseréljünk, ki kell húzni az egész dobozt a szekrényből, amely így teljes súlyával terheli a síneket, és persze húzza előre a szekrényt. Ez működik kb. a szekrény alsó harmadáig, legfeljebb a feléig, ahol még eléred, de ha feljebb is szeretnél ilyet pakolni, nem kerülheted el, hogy a be/kiszereléshez targoncát, a diszkcseréhez pedig létrát kelljen szerezned.

A többi (brand, nem a kínai fémmegmunkáló gmk) gyártó számomra érthetetlen okból eddig nem látott különösebb fantáziát a nagy sűrűségű diszkdobozokban, a Sun volt az egyetlen, amely felvette a kesztyűt, a többiek leragadtak az elöltöltős technikánál, amely a méretekből kifolyólag nem tesz lehetővé túl nagy mozgásteret.

De ez most változott, végre a HP is eszmélt, és megalkotta az MDS600-at:

5 RU-ban 70 diszk, azaz 14 HDD/RU! Azt hiszem ez abszolút rekord. Ha a ma kapható 2 TB-os diszkekkel számolunk, ez 130 TiB bruttó kapacitást jelent 5RU-ban, ami nagyon durva!

Maga a diszkdoboz egy teljesen (?) új, fiókos rendszerben tárolja a diszkeket, két fiókban öt oszlopban oszloponként 7 diszket (7*5*2=70):

A diszkdobozba négy SAS IO modul tehető, amelyek a megfelelő (dual portos) SAS diszkeket így redundáns útvonalakon tudják a host számára elérhetővé tenni.

Az igazán érdekes dolog azonban a blade oldali résznél kezdődik, hiszen a HP összedobott egy SAS switchet is, amely az FC switchekhez hasonlóan a SAS targetek (itt diszkek) és initiatorok (itt blade-ek) zónázására használható.

Azaz annyi a dolgunk, hogy fogunk pld. egy C7000-es keretet, beletolunk blade-eket, meg a SAS switcheket, rádugunk ilyen MDS600-akat (a papír szerint legfeljebb hatot, valószínűleg azért ennyit, mert egy 47U-s rackben ennél több nem fér), majd a switchben eldöntjük, hogy melyik diszk melyik blade-hez tartozzon. Valahogy így:
 

Mivel a HP blade-ekben alapból csak a bennük lévő diszkek meghajtására kitalált P400i kontroller van, szükséges egy új mezzanine bedugása, amit P700m-nek hívnak:

és a HP jó szokása szerint a régi Smart Array vonalat követi (azaz kompatibilis a (c)ciss driverrel, legfeljebb egy új PCI ID-t kell felvennünk).

Mint az fent látszik, a kontrollertől a diszkekig teljesen redundáns adatutak használhatók, az azonban egyelőre nem világos, hogy a DP SAS diszkek multipath elérését a kontroller firmware-e önmagától megoldja-e, vagy kell hozzá valami extra mágia (pld. OS support).

Heti érdekesség, hogy a HUP -amely más hasonló portálokkal ellentétben elmondja, hogy min fut :)- vasat cserélt a régi HP DL385-ről Sun X2250-re.

Előbbiben két dual core Opteron (nem mai darabok) szolgáltak, míg az utóbbiban úgy tűnik egy quad core Intel CPU.

A két gép viszonyát leginkább a statisztika oldalon elérhető CPU terheltségi grafikonon lehet felmérni. Jól látható, hogy a csere óta jóval alacsonyabb a CPU terhelés, míg korábban kb 50-60% (ami azt jelenti, hogy a két CPU négy magjából csak az egyik volt félig kihajtva) volt, most 40%-nál nem megy feljebb:

Külön figyelmet érdemel a zöld system (kernel) terhelés, amely annak ellenére maradt szinten (relatív, abszolút értékben persze ez is csökkent), hogy a DL385-ben lévő hardveres (BBWC-vel támogatott, ami nem kis pluszt tud jelenteni), 10kRPM-es SCSI diszkeket pörgető RAID-ről szoftveresre állt át a dolog, ráadásul az X2250-ben 7k2 RPM-es consumer SATA diszkek vannak...

A SW-HW RAID disputa bár picivel fiatalabb, mint az Amiga-PC vita, azért majdnem ugyanolyan ádáz, és a CPU-k erősödésével, illetve a ZFS-hez hasonló megoldások terjedésével (amely a Sun SW RAID-hez való évtizedes ragaszkodásának modernkori manifesztációja ;) további flamewarok várhatók a témában.

Lehet, hogy én is hozzájárulok majd ehhez hamarosan. :)

Nemrég a HUP-on szó volt az unladen swallowról, amely egy Google projekt a python amúgy igen szerénynek mondható teljesítményének fokozására.

Használok egy pythonban írt DNS szervert -a rugalmassága és egyszerű programozhatósága miatt-, így gondoltam kipróbálom vele.

 
Az unladen swallow egyik fontos eleme a JIT, illetve a bájtkód-értelmező kihagyása. A fenti eredmények az alapértelmezett beállítással készültek, ahol a JIT csak a "forró" kódra ugrik.
 

Van azonban egy "-j always" opció is, amely minden python kódot natív kóddá fordít, így azok akár gyorsabban is futhatnának. Akár.

A programot "-j always"-szel indítva a gép elkezdett dolgozni, a pár másodperces normál indulás helyett itt kb. egy perc is eltelt, míg beröffent a program.

A folyamat végére a top-ban ez látszott:

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
24653 root 3 116 0 767M 712M ucond 1 0:00 0.00% python
 

Azaz a python 712 MiB memóriát evett (egyébként 10-20 M-nál nem fogyaszt többet), nyilván annak köszönhetően, hogy a programfutás előtt az összes importált modult lefordította, és a memóriába töltötte, esetleg a fordításkor lefoglalt memóriát el is felejtette visszaadni...

De nézzük, hogy mit tud így a szerver:

Úgy tűnik jobb az alapértelmezett beállításon hagyni, és csak a sűrűn használt kódot -menet közben- fordítani.

Mint az a fentiekből látszik, egyelőre nem túl impresszív a teljesítménynövekedés, ez remélem a későbbiekben változni fog. Jó lenne egy olyan python futtatókörnyezet, amely megőrzi a nyelv rugalmasságát és szabadságát, de nagyobb sebességet nyújt, mint jelenleg.

A HWSW-n találtam a reklámot: "14 jó tanács storage kiválasztásához". A hirdetés az IBM Open Storage termékeit reklámozza.

Pardon, a miket?

A weblapon egy rakás különféle doboz látható (SAS, iSCSI, FC külső, és SAS/SATA, FC belső interfészeken), amelyek tarkábbak, mint a tehenek a réten, így kívülről nézve azt gondolnám, hogy a rajtuk futó szoftver sem valószínű, hogy azonos lenne.

De nem is ez a lényeg, hanem az, hogy mitől open ez a tarkabarka storage-mix? A nagy UNIX-gyártók körében mindig is népszerű volt ez a szó (más kérdés, hogy ez némiképpen mást jelentett, mint amit az új generáció az open source-ból megtanult), de itt nem sikerült megfejtenem a jelentését.

A Sunnak is van ilyen néven (is) ismert termékvonala, amelyben értem a nyíltságot. Ha akarok, belenézhetek, tudom mi fut rajta, és nem csak tudom, tudhatom, de akár forráskód szinten is megismerhetem (legalábbis nagy részét).

Szerintem ég és föld.

Egy olvasó (érdeklődött, majd) jelezte, hogy összehasonlítási célzattal szeretne a Sun X4540-ről egy szintetikus teljesítménytesztet látni (sysbench fileio). Amint időm engedi megcsinálom.

Ha valakinek van még valami könnyen kivitelezhető óhaja, jelentkezzen. :)

Pár napja jött egy ilyen:

Azt mondja, hogy "az iparág első hatmagos szerverprocesszora immár nem csak a tervezőmérnökök asztalain létezik, hanem kézzelfogható valóság."

És az Intel 7400-as? Vagy még korábban az UltraSPARC T1?

Erre csak annyit tudok mondani: ízlelgessük ezt a szót: octo-core... Az iparág első nyolcmagos dömpere már itt kopogtat az ajtónkban...

Az előbbi FreeBSD-s crash után gondoltam megnézem, hogy esélyes-e már Solarist használni ezen a péécéén (IBM xSzutyok, szerencsére mióta bevittük a szolgáltatóhoz, nem kellett hozzányúlnom), az mégiscsak otthonosabban kezeli a ZFS-t (persze ugyanúgy szarrá tud fagyni, efelől ne legyen senkinek se kétsége :).

Az egyik neuralgikus pont az IBM ServeRAID 8k-nak címkézett Adaptec ultragagyiRAID, amelynél persze (ZFS-sel legalábbis) jobb lenne egy natúr sokportos SAS vezérlő is, de hát a tajvani dzsunkán csak ilyet tudtak beletolni.

Legnagyobb csodálatomra a(z open) Solarisban lévő aac driver forrását megnézve (src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/aac/) az látszik, hogy a README fájl CDDL-es fejlécén kívül minden másban megmaradt az eredeti, BSD licenc, holott akár be is zárhatták volna az egészet (nehogy a Linux átvegye, LOL :).

A "FreeBSD ZFS snapshotok" bejegyzésben említett esemény nemrég jött megbosszulni magát. Szerettem volna megnézni a snapshotokat, így azt gondoltam, hogy megpróbálok egy export importot, hátha attól javul a helyzet.

Szerencsétlenségemre a FreeBSD még nem igazán támogatja ezt a fajta advanced ZFS használatot:

Más oldalról közelítek: a FreeBSD (a jelenlegi megoldás a NetBSD-ből származik) rc.d megoldását azért szeretem, mert rugalmas.
Mit értek ez alatt?
Azt, hogy ha van egy rakás gépem, amelyek adott esetben hasonló funkciókat látnak el (olyan csóró nagyobb cégeknél előfordul, amelyek nem tudnak egy E25k-ba, vagy egy M9000-esbe beruházni (igen, tudom, lehet T[12]-es gépeken is, de a konfigmenedzsment ott is ugyanakkora kérdés), hogy aztán azon futtassák logikai partíciókban, vagy zónákban a bindot, meg az eximet :), elég megoldanom a konfigurációs fájlok megfelelő hierarchiába szervezését, disztribúcióját, és ezzel kész is vagyok.

Bár elismerem, hogy messze van a tökéletestől, de legalább abba az irányba mutat, amit talán objektumorientált konfigurációmenedzsmentnek hívnék (ha én találtam ki, ez mindenképpen TM!). Azaz definiálhatok egy általános konfigurációt, amelyet minden gép megkap, aztán egy olyat, amelyet csak egy bizonyos környezetben, vagy bizonyos feladatokat ellátó gép fog magáénak tudni, és persze olyat is, amely csak arra a specifikus gépre vonatkozik.

De nem állnak itt meg a lehetőségeim, hiszen az rc.d-ben használt konfigurációs fájlokat shell scriptek source-olják, azaz bármit megtehetek. Ha az adott program konfigurációs formátuma nem támogat ilyen szabadságot, írhatok elé apró scripteket, amelyek a program indulása előtt legyártják a gépre szabott konfigot, vagy induláskor scratch területeket inicializálnak, bármit.

Ellenben az smf az XML leírókkal, és a bináris (sqlite) adatbázisával ezt nagyrészt (eleve?) kizárja.

OK, az sqlite, és az XML miatt, adja ezek minden előnyét (típusosság, kompaktság, gyorsaság stb), de szerintem pont nem a jó irány.
Hogy lehetne egy ilyen rendszerbe belevarrni mondjuk egy hálózatról bootoló gépfarmot, amelyek a konfigurációjukat egy hierarchikus rendszerben öröklik, a tágabbtól a szűkebb felé haladva?

Az rc.d nem tökéletes, de ezt már ma nyújtja.

Egyáltalán mivel lehet verziózottan, naplózva (megfelelőség, ugye) elosztott, hierarchikus, egységes konfigurációmenedzsmentet csinálni Solaris alatt?
 

Alakul ez a ZFS FreeBSD-n -mint T-800-as a présgépben-, most már van legalább olyan jó, mint 2005-ben volt Solarison (lehet, hogy kicsit igazságtalan voltam, mert annál sokkal jobb).

Az UFS-ben snapshotolni annyira nem öröm (mondhatni suxxs), így hát úgy döntöttem, hogy kipróbálom mentésre.
Elvégre nincs is annál jobb, mint rátolni egy ilyenre rsync-kel az épp aktuális anyagot, majd csinálni róla (bónusz: közben blokk szinten tömörítve) egy snapshotot, és eltenni azt napokra (vagy hónapokra, évekre? Ki tudja, elvileg csak a változások mértéke szab határt).

Na egy ilyet próbáltam, a mentést érdemes volt betömöríteni (default, lzjb):

bkp           compressratio         1.80x                  -

Ezután csináltam pár snapshotot, és megírtam hozzá a scriptet, amely elkészíti a snapshotot, és törli azokat, amelyek már nem kellenek.

Miután ezt jól összelőttem, és betáraztam cron joe-nak, jött a meglepetés. A scriptet úgy írtam, hogy a .zfs/snapshot könyvtárban kutakodjon, és az alapján dolgozzon. Ez a könyvtár viszont időközben eltűnt, azt mondja, hogy:

ls /bkp/.zfs/snapshot
ls: /bkp/.zfs/snapshot: Bad file descriptor

A zfs szerint viszont ott van az:

zfs list -t snapshot
NAME           USED  AVAIL  REFER  MOUNTPOINT
bkp@20090607    46K      -  7.87G  -

Minden valószínűség szerint akkor tűnhetett el, amikor a ZFS-ről nullfs mountoltam egy könyvtárat egy UFS könyvtárba (közben visible-re is állítottam a snapshot dirt, de utána még megvolt). Ha umountolom ezt a nullfs cuccot, vagy megint hiddenre rakom a snapshotot, sajnos nem jön vissza. Mindegy, ezt most így hagyom, majd ha kell valami, reménykedem, hogy a snapshotok ott lesznek. :)

Egy másik gépen majd ki kell próbálnom, hátha valaki fogékony lesz a hibára, és kijavítja (már persze ha sikerül reprodukálnom).

Az egyik gépemen FreeBSD van. Leginkább fejlesztésre használom, így két monitor lóg rajta, valami nvidiás cuccon. Na ez utóbbi nemrég gallyra vágta magát, így cseréltem egy újabbra (szintén NV).

Mivel az OS 64 bites módban fut(ott), csak az open source nv drivert használhattam, amivel rendesen működött is a két monitor. Az új kártyával viszont mindkét képernyőn ugyanaz a tartalom van, ami az arcom lebarnításán kívül másra nemigen használható.

A portsban lévő bináris nvidia driver sajnos csak i386-on működik (bár mikor legutoljára próbáltam azon se), így most nekivágtam a 32 bitre visszaállásnak.

Az OS lecserélése gyorsan ment, miután a buildworld és buildkernel lefutott, azonban az első indítás után megdöbbenve tapasztaltam, hogy a kernel állandóan elhányja magát (panic, double fault), jellemzően akkor, amikor portokat akarok telepíteni.

A backtrace szerint a halál egy malloc()-ot követően volt. fsck, reboot, ugyanaz.

Már kezdtem volna régebbi kernelt fordítani (ez HEAD), mikor feltűnt, hogy a régi portok indításakor bitszemét jelenik meg a képernyőn (postfix, openntpd, hald, dbus, meg saslauthd futottak volna). Ezek nem tudtak elindulni, hiszen a userland már 32 bites volt, viszont a portokat még nem raktam újra.
Kikommentezve ezeket, a korábban konstans rohadást triggerelő műveletek gond nélkül lementek.

Érdekes, ha lenne időm mindenképpen megérné utánajárni ennek, hiszen mindössze annyi történt, hogy pár ott maradt 64 bites bináris próbált elindulni sikertelenül, és ettől a rendszer instabillá vált. Kiváló DoS lehetőség.

Most tehát mennek újra a portok, 64 bites helyett 32 bites FreeBSD-m van, és csak reménykedhetek, hogy az nvidia driver egyáltalán működik, és jól működik (meghajtja a két képernyőt, és ezt megbízhatóan teszi).

A remény hal meg utoljára.

Lerohadt ez a csodás FreeBSD. Van crashdump is. Király.

Csak hát a hozzáféréssel vannak még problémák...

# kgdb kernel.debug vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Cannot access memory at address 0x0
(kgdb)

Ilyenkor mi van?

ZFS, the last word in file systems. Hát nem is tudom.

Létrehoztam egy RAIDZ2 poolt 14 darab 15k-s 72 GiB-os diszken, meg egy slogot, egy külön diszkpárra (két 15k-s diszk tükrözve). Megfelelően gyorsnak tűnt.
Majd rátoltam egy taligányi apróma^H^Hfájlt, mondjuk úgy pármilliót (mail szerver stresszteszt, SMTPd queue fájlok, jól felhizlalva). Itt már éreztem némi bizonytalanságot.

Ezután hagytam, hadd pörögje ki magát a szerver (kézbesítse a leveleket), ugyanazon poolon lévő mail home-okba. A hízlalás és a felgyűlt levelek kézbesítése is kb. 3/4 napig tartott egyenként.

Miután ez megvolt, indítottam egy findot a queue könyvtárban, amelyben egyébként már csak két fájl volt. Itt ért a meglepetés, a find ugyanis 232 másodperc alatt fut le (első futás, második rögtön utána: 192s), és ami még ennél is durvább, az üres könyvtárak végignézése fájlok után, és az eredmény (két fájl) prezentálása közben a diszkeken átlag 793 IOPS-t és 50 MiBps olvasást produkált!

atime egyébként offban van.

És mielőtt még valaki arra gondolna, hogy bár sok fájl nincs a könyvtárban, de könyvtár igen, hát téved. Összesen 148 darab directory van abban a mappában, amelyből a számolást indítom. A pool (az egyetlen fs-sel) sincs éppen tele (2 GiB foglalt jelenleg)...

Van már jópár éles gépünk ZFS-sel, de ezt a használati mintát (sok fájl létrehozása, majd törlése, és ugyanannak a könyvtárnak a további használata) még sehol sem próbáltam.

# zfs get version home
NAME  PROPERTY  VALUE    SOURCE
home  version   3        -

# zpool get version home
NAME  PROPERTY  VALUE    SOURCE
home  version   13       default
 

A palesztin fura egy nép, állandóan piszkálják a békés Izraelt, pedig ez utóbbiak még a saját területükre is beengedik néha őket. Checkpointokon keresztül.

De mi is az a Check Point? Egy izraeli cég, amely tűzfalakat gyárt. Olyanokat, amelyek jól megvizsgálják a rajtuk áthaladó csomagokat, és ha úgy gondolják, nem engedik őket tovább.

Sokan abban a hitben élnek, hogy a biztonsági cégek aztán húdenagyon ott vannak a szeren, álmukból felkeltve mormolják az RFC-ket, meg hibátlan szoftvereket írnak. Hát nem. CP-ék tűzfala egy rakás protokollt ért, amely azt jelenti, hogy ha ez a funkció be van kapcsolva, belenéz a csomagba, és azt mélyen értelmezi (deep inspection). Néha olyan mélyre süllyed, hogy nem csak értelmezi, de módosítja is azt. Egy ilyen esetről lesz most szó.

Bent ülünk tehát a gépteremben a szerverünkkel, amely unottan bámulja az izraeli nagy falat a maga négy méter magas szürke pompájában. Néha azonban ennél többre is szükség van, beszélni kéne a külvilággal, most éppen a zsidó területen át. Küldünk tehát egy DNS kérést, olyan palesztinosat.

A tűzfal tehát gyanúsan tekint a csomagunkra, kibontás előtt egy nagy téren harckocsival palacsinta vastagságúra nyújtja (hátha bomba), kemencében kisüti (hátha vegyi fegyver), sterilizálja, majd miután atomjaira hullott, a lényeget kiszedi belőle, majd újból összerakja, és ha megfelelőnek találja, átküldi a héber oldalra.

Mit lehet a DNS csomagokkal csinálni? Például randomizálni a forrásportot, és a tranzakciós azonosítót. Tűzfalunk ezt elvégzi, közben pedig még egy NAT-ot is csinál.

A csomag kimegy, majd rövidesen visszajön a válasz. Minek is kellene történnie? Hát a tranzakció-azonosítónak, a most már célportnak és IP-nek a tűzfal állapottáblája szerint vissza kellene változnia az eredeti értékekre, hogy a host felismerje, hogy a kérésére jött a válasz.

Mi történik valójában? Jön egy format erroros DNS válasz, ráadásul rossz tranzakciós azonosítóval, amelyet így a host resolvere automatikusan eldob.

Mindez csak bizonyos célpontoknál fordul elő, jellemzően azoknál, amelyeket a főnökség hirtelen és überfontosan el akar érni. Persze a fentiek miatt nem megy.

Rövid debugolás után a megoldás a tűzfal DNS scramblingjának kikapcsolása, miután minden rendben működik.

Összefoglalva tehát a szopást:

• DNS scramblingnál a Check Point néha elkefél valamit a kimenő DNS csomagokban, és emiatt némely névszerver format errort dob vissza
• az idióta tűzfala ilyen esetekben elfelejti visszacserélni a TXN ID-t, így a host (alkalmazás szinten) észre sem veszi, hogy jött válasz, így legfeljebb timeout hibát tud a képünkbe dobni
• mellesleg ha poolos NAT van, a csoffadt tűzfal a forrásport randomizáció helyett szekvenciálissá alakítja őket, azaz ahelyett, hogy segítene, ront a biztonságon

Hello world!

Nos, megszámlálhatatlannak tűnő évek után ma este bekattant valami az agyamban.

Blogot indítok, meglátjuk hogy megy majd.

Egyelőre csak egy rövid bemutatkozás, a google úgyis elmond rólam mindent. A monogramom B.G., amely az angol nyelvű becenevem és a szintén angol nyelvű családnevem első betűit takarja (ha valaki nem tudta volna, hogy mi az a monogram). Októberben születtem, még az előző évezredben.

Mint fent már utaltam rá, végtelennek tűnő évek óta dolgozom az IT-ben. Első nagyobb számítógépes kalandom a BASIC-kel volt még a kompjúterek hajnalán, aztán következtek a PC-k.

Eddig összekapart apró kis vagyonkám nagyobb részét egy itt közelebbről megnevezni nem kívánt multinacionális cégben végzett munkámmal kerestem (ha valaki mégis ki szeretné találni melyiknél, könnyítésként elárulom, hogy rengetegen utálják, de esküszöm nem én tehetek róla!).
A cég mellett van egy alapítványom is.

Mélyebb jellemrajzot most nem produkálnék, ennyi épp elég bevezetésképpen.