Shery és RePa

2009. október 27.
Ezen a napon, korábban: mudlogger.py (2008), mudlogger.py (2008), 10-27 18pm (2005), multilingual (2005), size does matter (2004)

Phishing vs. google translate

dyuri @ 10:12:29

Vad levelet kaptam ma az "OTP banktól".

Received: from User ([66.80.47.199]) by florence.cdhk.cdhklaw.com ...
From: OTP Bank <service@otp.hu>
Subject: Fontos!

Tisztelt Ьgyfelьnk!

Ez a hivatalos йrtesнtйst arrуl, hogy a hitelkбrtyбjбt korlбtozott
volt. A kцzelmъltban felьlvizsgбltбk a kбrtyбt, йs ъgy tűnik,
hogy a vele kapcsolatban бllу tцbb mint 1 szбmlбk.
Цsszekapcsolja a hitelkбrtya tцbb sokszoros szбmlбk szigorъan tilos,
йs azt is tцrvйny bьnteti. Цn most mбr felkйrtйk, hogy nyъjtson
informбciуkat a hitelkбrtyбjбt. Az OTP Bank azonnal kivizsgбlja az ьgyet,
йs ha a vizsgбlatot az Цn javбra fogjuk visszaбllнtani a fiуkjбt.
Hogyan бllнthatom vissza a szбmlбjбt?
...

Amellett, hogy valami érdekes kódlappal íródott (gyanúsan orosz), és rosszul formázott HTML volt az egész, az is kiderült, hogy az OTP valszeg csak a google translate segítségével tud magyarul, illetve, hogy a honlapjuk a http://[valami ipcim]/otp.hu/include.php oldalon található :)
Az oldal persze ugyanúgy néz ki, mint az OTP rendes oldala, csak gondolom saját céljaikra teszik el majd az emberkék adatait. Egy picit finomodnak, és simán sok ember bedőlhet nekik...

2009. október 22.
Ezen a napon, korábban: Koktélpari (2008), Koktélpari (2008), Koktélpari (2008), Perlconf (2005), BCO_OID_SbsOim_sbsOimMeasGroupName (2004), UHU Live (2004)

UTC

dyuri @ 19:16:48

Aki valaha részt vett már valami "nemzetközibb" dologban, esetleg programozott is már, az valószínűleg találkozott már az időzónák problémájával.

Java fejlesztő kollégák közül néhányan kicsit belegabalyodtak a Date és Calendar osztályok, illetve az időzónák kezelésébe, a Java és a MySQL összebarátkoztatásánál. Annyit segítek azért azoknak, akik ezután fognak ilyesmivel találkozni, hogy hasonló szituációkban az eltárolt időt ne misztifikáljuk túl, tekintsünk rá úgy, mint egy számra (mostmár jellemzően valami 64bites egész), ami nem több, mint egy szám, egészen addig, amíg egy felhasználónak meg nem mutatjuk. A megmutatás már messze nem ilyen egyszerű, mert akkor bejön az időzóna meg a nyári időszámítás, meg a mittomén. (Szóval a probléma kezelhető, de azért jobb lenne nélküle.)

Egyre sűrűbben előkerül a téma, hogy el kéne felejteni a téli-nyári időszámítás átállást, mert amellett, hogy felesleges (a google szerverei pl. nem a nappal kellnek, és nem este 10-kor fekszenek le...sőt az, hogy este 10, az igazából értelmetlen önmagában...), milyen már, hogy vonatok várnak egy órát az semmi közepén, hogy "időre" érjenek be a következő állomásra. Támogatom.

Sőt, mégtovább megyek, legyen mindenhol UTC (vagy bármi más, de egységes). Amíg az emberek csak olyan messzire mentek el egy nap, hogy a templomtoronyra rálássanak, addig persze mindegy volt, hogy a szomszéd faluban esetleg tök mást mutat a toronyóra - bár már ekkor előjött a probléma, még ha csak gondolati síkon is, emlékezzünk csak Mr. Phileas Foggra, aki 80 nap alatt kerülte meg a Földet, és "nyert" egy extra napot azzal, hogy átment a dátumválasztón.

Nade ma már nem nem csak a toronyóra látótávolságáig merészkedünk el, hanem egyszerre beszélgetünk (mi, CEST: GMT+1 +1DST) finn (EET: GMT+2 +1DST), amerikai (Texas: GMT-6 +1DST) és fülöp-szigeteki (GMT+8, nincs DST) srácokkal, ilyenkor marha egyszerű időben leegyeztetni bármit is. És a kiragadott példa valós, egy multi cég sem kellett hozzá, csak egyetlen darab szerver, és közös hobbi.

Vagy mi van az űrhajósokkal, akik naponta közel 16-szor kerülik meg a Földet a Nemzetközi Űrállomással? Ők Willihez hasonlóan naponta 16 napot nyernek, vagy vesztenek? (wow, időutazás) És mi lenne, ha ők is a földi időzónák szerint mérnék az időt, úgy kéne bejelentkezniük, hogy "Hello Huston, minden OK, tizenkét óra huszon... nem, tizenegy óra huszon... ahh... faszom fél11leszvetelvege.

Persze megértem, hogy milyen "rossz" lenne, hogy mondjuk szegény japánok az eddigi "reggel" 6 óra helyett 21 órakor kelnének fel, de nem is 9-re járnának dolgozni, hanem éjfélre. És a világon mindenki tudná, hogy Londonban mikor van délutáni öt órai tea, 17 órakor. Még ha valaki épp akkor mosná a fogát valahol Indiában lefekvéshez készülődve.

Nehéz lenne megszokni biztos, de meg lehetne. Legyen 5 év az átállás, amíg mindenki mindenhova kiírja mind a kettőt, aztán utána már csak az UTC-t. Nem lenne sokkal rosszabb, mint a Forint - Euro átállás (bár ha így haladunk, nincs sokkal kisebb esélye az egységes időzóna korábbi bevezetésének :P).

Le az időzónákkal!

P.S.:
Ha viszont nem, akkor javaslom, hogy a déli féltekén toljuk el a hónapokat hattal, mert a Télapó télen kell, hogy jöjjön, Ausztráliában is.

2009. október 16.
Ezen a napon, korábban: IP címet mindennek (2008), IP címet mindennek (2008), Kellemes meglepetes (2007), Adaptable UI (2006), Eloitelet (2006), Jazminos zold tea (2006), lelegzo cipo-E (2005)

Mysql 5.0.51 vs. 5.4.3 vs. Postgres 8.4.1

dyuri @ 16:31:14

Felmerült a kérdés, hogy érdemes lenne-e frissítenünk a jelenlegi (opencsw-ből jött, 5.0.51-es, tehát jó régi) mysql-ről újabbra. Nameg blackshepherd is olyan lelkesen tesztel, tesztelek én is akkor egy kicsit.

A vas (narancs) egy Intel SR2400-as, két darab kétmagos 3GHz-es Xeonnal, 4 Giga rammal, és Solaris 10u7-tel, külön ZFS-sel, teljesen alapértelmezett beállításokat használtam, amiken azért - mind oprendszer, mind db oldalon - lehet nem keveset csiszolni.

Sysbench-et használtam én is, 100000 soros táblával, egy tranzakciós-írós-olvasós és egy csak olvasós tesztet futtattam, semmi trükkös paramétert nem állítgattam. A mysql 5.4.3 RW tesztjét lefuttattam úgy is, hogy az innodb raw partíciót használ (illetve ZVOL-t), de szinte semmi különbség nem volt. Beszéljen helyettem a gnuplot:

Az szépen látszik, hogy a vegyes használatnál az innodb nagyot fejlődött - úgy fest a read-only teljesítmény rovására. Myisam esetében pedig kb. a fentebb említett tesztekben szereplő +20%-os teljesítménynövekedés látszik (bár rohadtul máshogy néz ki a grafikon, de közel sem annyira finom, kevés volt az időm sajna). Mindenesetre megéri az újabbat használni szerintem.
Ami viszont engem meglepett, az a postgresql, amit tényleg csak a suckIT féle tesztek miatt vontam be a tesztbe, de igencsak odacsapott... (mysql-lel azért több a tapasztalatom, pláne nagyobb terhelés esetén, de ideje a postgressel is lassan tapasztalatokat gyűjteni).

2009. október 1.
Ezen a napon, korábban: OMG, nosztalgia (2008), OMG, nosztalgia (2008), Miskolctapolca (2006)

30000…300000…bulvár

dyuri @ 8:32:12

Adott ez a friss sebességrekord, hogy 15,5 terabit/sec-es sebességet sikerült elérni a 7000 kilométeres tenger alatti kábelen. Ezt a tudós kollégák ügyes marketinggel lefordítják 100 petabit/sec kilométerre vetített sebességre, ami jól hangzik, csak olyan szempontból nem igaz, hogy egy (azaz 1) kilométeren jó ideig a közelébe sem fognak érni. A sávszélesség szerintem kb. bármekkora távolságon 15,5 terabit/s lenne földi körülmények között, ezért ha a világ leghosszabb kábelét használják, akkor a legnagyobb "kilométerre vetített" sebességet érhetik el. [A zindexen meg egyenesen el is felejtik megemlíteni a tényeket, és csak a bulvár marad, kicsit átfogalmazva, ahogy egyszerűen nem igaz.]

A fény ugyanis 1 illetve 7000 kilométert elhanyagolható idő alatt tesz meg, legalábbis az opto-elektromos konverzióhoz és a számítógépeink jelfeldolgozásához képest. Tehát ezt a 100 petabit/s/km vagy milyen mértékegységű rekordot ugyanezzel a technológiával, csak egy jóval hosszabb kábellel felül lehetne múlni (szerintem).

A klasszikus adathordozókkal megrakott teherautós példa itt is alkalmazható. Ha a teherautót mondjuk 1 óra megpakolni, és 100 km/óra az átlagsebessége, akkor szinte mindegy, hogy 10 métert, vagy 100 métert megy.

Ennyit számít a marketing :)

Ez egy blog. A velemenyunk a mienk, ezert szubjektiv, es meglehet, hogy neha csak picit fedi az egyetemes igazsagot. Mellesleg akinek nem tetszik, az nezze helyette a tvt.

Egyebkent nyugodtan lehet idezni, kepeket toltogetni, szabadok vagyunk.

Ha esetleg valami szemelyes kozolnivalod van, amit nem szeretnel kommentbe leirni, akkor tobbek kozott elerhetsz minket a [akiacikketirta] kukac horak pont hu emailcimen.