csak egy buta arnyek
2010-02-16
nincs kategoria
Ezzel kéne kezdeni az általános iskolában, és akkor talán MSc-re az emberek megértenék, hogy mennyit kell még tanulniuk.

redditen egy kis segítség.

Plusz, kis apróság, most jöttem rá, hogy milyen hasznos is a topológia. (nagyon)

Az új Bevezetés a Matematikába könyvben szerepel egy kis mese ezekről a fizikában hasznos csoportokról (58 oldal aljától), csak valahogy kevésbé érthetően.

innen, ez arról szól, hogy miért is nem tapasztalunk mindenféle (gravitációs) abberációt az égitestek pályáiban annak ellenére, hogy a gravitációs hullámok nem azonnal hatnak, azaz a tömegek (testek) kicsit máshova húzó erőt éreznek, mint ahol éppen van a hullámot kibocsáltó tömeg.
Tehát a tér-idő felszínén terjedő (negatív) hullám (ami a "lejtőt" képzi, ami miatt húzó erő lép fel) mikor eléri a tömeget az azt okozó másik tömeg már arrébbmozgott, tehát a lejtés/görbület az azt okozó tömeg eredeti helyére mutat, ahol már nincs semmi. Mégis miért nem okoz ez problémát? (Egyik magyarázat, hogy a gravitáció 10^10-szeresével terjed a fénysebességnek.) A másik pedig annyi matekot igényel, mint a PDF-ben tapasztalunk.

Lorentz-invariancia elve: mivel a fizika, azaz a fizikát leíró egyenletek, nem függhetnek a szemlélő nézőpontjából, mindig tudunk találni olyan nézőpontot, amiben az adott vizsgált objektum 0 sebességgel halad; ergó a relatív sebességnek valahogy ki kell esnie az egyenletekből.

Furca, hogy értek rétegeket, dolgokat, de nem tudom megmagyarázni, hogy hogyan is hatnak egymásra, melyik volt előbb, miért, hogyan működik, stb.. de nem csüggedünk, előbb utóbb levizsgázunk Bev.Mat. 2-ből is, és majd akkor! (Na jó nem. Inkább differenciálgeometriából várom a megváltás. Ami most Analízis Alkalmazásai 2-ből van (5. félév anal.).. ami történetesen ~4 óra múlva kezdődik. Kéne aludnom? Ójaj!?!)
869 IPv6
2010-02-15
nincs kategoria
Brucon 2009 IPv6 Security

Ugye szépen kifogyunk a v4 címekből:

kép

kép


Tehát jön a megváltó IPv6. Fix fejléc méret, de opcionális kiegészítő fejléccel (cseber-veder?), hosszú, 128 bites címek (öröm lesz őket megjegyezni), viszont a fix fejlécet nem tartalmaz ellenőrzőösszeget (checksum), így a TTL (v6-ban Hop Limit) simán csak eggyel csökkenthető és már továbbítható is a csomag.

Maximális v6 csomagméret 4 MB. Tehát kvázi egyben el lehet küldeni egy teljes multipart (több részes, maga a HTML oldal, képek, JavaScript, CSS, stb.. egymás után, a bináris dolgok base64 kódolva általában) HTTP választ.

Előny még, hogy elvileg v6-on már gyakorlatban is jó ötlet lesz a multicast, pl. egy youtube mozit elkezdesz nézni, a youtube közli, hogy akkor csatlakoz az XY multicast csoporthoz, a géped szól a routerednek, az a következőnek, az is a következőnek, amíg nem találnak a sorban egy olyat, amelyik már tagja a csoportnak, és kapja a jóságot a youtube-tól. (Így ugye nem kell kétszer-sokszor elküldenie a mesét a tecsőnek, mert a routerek szétosztják az anyagot.)

Elvileg a hatalmas kiosztott blokkok miatt az ISP-k ténylegesen egy prefix alá húzhatják a szénájukat, így egyértelműbb lesz, hogy melyik IP blokk, melyik ISP/AS (autonomus system), ami a BGP táblák méretén óhajt enyhíteni.



Aztán a videóból összefoglalva a veszélyeket:
- blacklistek, whitelistek felejtős (fülenként jut több milliárd v6 cím)
- a v6 által implikált szuperjó IPSec csak egy mítosz, hiszen kulcs-szerverek, kulcs-kezelés nélkül nem sokat ér
- hardveres tűzfalak még nincsenek v6-ra (vagy ha vannak, túl lassúak, a talkban 1 gigabit képes v4 eszköz 80 megabitet produkált v6-on)
- a dual stack veszélyei, TEREDO, 6-to-4 (packet injection a tunneleknél)
- lusta ISP-k, elérhetetlen v6 címek, duál NAT-olás, stb. (némelyik ISP egyszerűen nem routolja a v6 címek bizonyos harmadát, mer' csak)
- modern oprendszerekben kérdés nélkül engedélyezve van a v6

- ARP mostmár nem Ethernet alapú, hanem v6-on fut (simán spoofolható, poisonolható, DoS-olható)
- DHCP helyett Router Discovery (man-in-the-middle attack triviálissá válik)

- jut elég IP mindenkinek, így a NAT-oló routerek feleslegesekké válnak, viszont az okos, könnyen finomhangolható tűzfalakra egyre inkább szükség lesz.
2010-02-14
nincs kategoria
Micropayment, hogyan adjunk pénzt másoknak egyszerűen, ésszerűen, legálisan? Square (mobil eszköz + internet + touch screen capture = fizess bárhol a kártyáddal, írd alá a számlát az érintőképernyőn)

Érdekes a Square megoldása, mert ugyan alapból használható pusztán interneten keresztüli módban, de "jár hozzá" egy kártyalehúzó (sima mágneses fej), aminek segítségével - szerintem - elfogadja a nem-dombornyomott (nem internet-képes) kártyákat is.

A másik megoldás pont az inverze a dolognak, nem a mindenütt jelenlévő mobilkészülékre és az előbb utóbb a mobilba kúszó, telepedő internet kapcsolatra épít, hanem a böngészési szokásainkra, arra, hogy valahol úgyis netközelben akarunk pénztkölteni manapság.

Pontosabban, nem is költeni akarunk, hanem jutalmazni. Látunk egy tökjó háttérképet? Letöltjük, mert free, de valahogy juttatnánk egy kis pénzmagot az alkotónak is; viszont egy poszter mégis csak sok-sok zöldhasú.

Tehát az alapgondolat, fogjunk egy havi keretet, amit ilyen célokra szánunk, majd azt osszuk szét. Tegyük ezt sokan egy rendszer segítségével, így a sok-kicsi-sokra-megy elv alapján a szerzők-művészek jól járnak, mi pedig csak egy havi fix keretet költünk.

Előnye, hogy a tényleges népszerűség, felhasználás, fogyasztás az alapja a kifizetett mennyiségnek. Ez a piratePay, unalmas nevén flattr.

Amúgy miért (lesznek) jók ezek a hálózatok? Mert idővel eljutunk arra a pontra, hogy (szinte) letehetjük a kézpénzt, ahogy a bankok elefántcsont-tornyai is ledőlnek majd szép lassan, ahogy érezhetően tirviális lesz az ilyen rendszerek működtetése, implementálása. De legalábbis az átutalási rendszer átalakul (közel) valós idejűvé és ingyenessé.
867 Akira
2010-02-14
nincs kategoria
Megnéztem az Akirát. Ugyan nem először; ha jól sikerült kihámozni a 2006 környéki öNmlengéseimből, akkor az érettségi előtt nem sokkal láttam először.

Mondanom sem kell, érdemes volt megnézni másodszorra is. Sok olyan apró részlet, élettörténet, tanítás kerül elő, ami elsőre nem biztos (sőt), hogy kitűnik a látványorgiából, eseménysokkból.

Mihez kezdünk, ha hatalmas, már-már korlátlan energiák birtokába jutunk? Van választásunk? Meggondolhatjuk magunkat később? Mennyit ér az élet, ha milliárd és milliárd van belőle?

Tetsuo egyértelműen nem a megfelelő alany arra, hogy felhasználhassa ezeket az energiákat, amik felébredtek benne.

Van tanulsága a filmnek? Van mondanivalója? Intellektuális provokáció a szórakoztatásért csupán? Egy túl messze vitt alapgondolat elakciófilmesítve? Van-e értelme esztétáskodni egyátalán pont ilyeneken?

Nagyrészt hasonló kérdések magvainak elvetésére hajlamos a film, de ettől még/pont ezért mindenkinek továbbra is kifejezetten erősen ajánlom.
2010-02-08
nincs kategoria
Az előző poszt nyomdokain haladva igazából egy nagyon fontos kérdés jön szembe. Tekintsük-e a Facebookot alapnak, amire aztán építünk, védve magunkat, amennyire tudjuk, de alapvetően egy másik entitás kegyeire bízva magunkat; vagy próbáljunk meg Jerikó falain kívül valami kis homokvárat összelapátolni, és remélni, hogy egyrészt eljönnek azok az idők, amikor majd nekünk is be kell vetnünk minden trükköt ami csak a floppylemezekből szőtt tarsolyunkban lapul, másrészt, ha eljön, meg tudunk vele küzdeni, legalább olyan jól, mint a Fb.

Jelenleg olyan 500 szoftvermérnök dolgozik a cégnél. Egy régi HP épületet kannibalizáltak be, olcsó IKEA asztalokkal szórták tele, és tömött sorokban kódolnak a programozók. Nagyrészük tényleg csak a PHP kódot csiszolgatja, apróságokat tervezgetnek, építgetnek, nevelgetnek. Napi min. 10,000 soros össz volumenben. Viszont, ellentétben egy átlagos nagyvállalattal, itt nincsenek "írógépmajmok", akik csak kódolnak ész nélkül. (Legalábbis próbálják az éreztetni, hogy bármelyikük is csak úgy megalkothatta volna pl. a HipHop fordítót.)

Másik érdekesség, az előbb linkelt friss - január 11-i - interjúból, hogy a programozók nagyrésze Stanford vagy Harvard pecsétes diplomával rohangál be hozzájuk. Hogy is csinálta anno a Google?

Tehát van egy cég, amelyik pár éven belül szinte az EU, USA, Japán, Ausztrália, stb.. és az egész világ teljes szociális hálójának birtokában lesz. Mint egy nagy kék pók ül a közepén és fityeget a legapróbb rezdülésekre is (mint pl., hogy kiknek a profilját nézed).

És bizony vannak nagyon hasznosnak tűnő elképzeléseink arról, hogy mit lehetne kezdeni ezzel, mire lehetne felhasználni, hogyan lehetne optimalizálni az információ kezelését az embereknek (az emberiségnek?).

De szabad-e ezt egyetlen vállalat karmaiban hagyni? Lehet-e nem centralizáltan megvalósítani ugyan ezt? Nem magát a webet kapnánk vissza azzal, ha decentralizálnánk? (A maga sokmillió-milliárd egymásra mutató blogjával, blogrolljával, linkjével.)
2010-02-08
nincs kategoria
Egy kis facebook ajnározás. Őrült számok. Tényleg.

40 terabájt RAM 700 MEMCACHEd szerver. Csúcsra járatott application serverek (eddig Apache 1.3 (!) + PHP + APC + pár saját PHP extension). MySQL 5.084 és memcached természetesen patchelt, saját. A gépekre külön hálózati drájvert írtak. (Többek között, hogy a core2-khöz készült Inteles interfészekhez készült drájver bugos volt, csak egy mag kezelhette egyszerre a kártyát.)

Elképesztő számok, pl. a Haystack rendszerük (a képek kiszolgálásáért felelős) körülbelül másodpercenként 1.200.000 darab képet szolgál ki. Hogyan? Egybeépítettek egy webszervert és egy kvázi-fájlrendszert, amelyik 1 (egy) árva I/O műveletet pazarol mindösszesen minden egyes lekérésre. Azaz, jön a GET /a/b/képek_3434343_34343_2323.jpg HTTP/1.1, és vagy a kép ID-je alapján memóriából egy hashtáblából kinézi az offszetet, majd onnan olvas mondjuk ~250K-t (tudják, hogy mekkorára tömörítik a képeket, tehát tudják, mennyit kell olvasniuk), vagy lehet, hogy már a kép ID-je maga az offszet! (Hisz' miért ne?) Bámulatos.

Az új üdvöske az őrültek házában (techno-zoo?) a PHP-HipHop. Egy PHP-C++ fordító. Többmenetes statikus elemzés (lényegében amíg minden ésszerűen elérhető információt ki nem nyer a forrásfájlokból, addig folytatja az elemzést), majd gépi kódra fordítás. És bamm, 50%-os CPU terhelés csökkenés. Ami nem is annyira áll-leejtős, főleg ahhoz képest, hogy a memória igénybevétel is töredékére csökkent. Tehát így kevesebb szerveren tudnak több példányt futtatni.

Jah, és csak a vicc kedvéért, írtak egy saját többszálú, esemény-reaktív (libevent alapú) webszervert, amibe/amivé/amihez (?) fordul a PHP/C++.

Azért lényeges mindez, mert még csak most jön a neheze a facebook számára. Hiszen, ha belegondolunk, most kezdi elérni a növekedése legmeredekebb szakaszát. (Szerintem.) Belegondolva, most lehetünk annál a pontnál, ahol már a nem-facebook tagoknak annyi facebook tag ismerőse van, hogy már csak miattuk is érdemes regisztrálniuk. Építem ezt arra, hogy naponta kapok már-már ismeretlen emberektől ismerős-jelölést. Látom, hogy egyre inkább a nem-nörd népesség tagjait is megtalálni a rendszerben. Most járhat az oldal olyan 500 millió felhasználónál.

Ugyan nem tűnik soknak a heti 2-3 új ismerős, de szinte mindenkinek jön hetente egy-két új ismerőse, kb. az új emberek ismernek 10-30 embert az első hétben, tehát az 500 millió embert 30-szor számoltuk, azaz 500/30 = 16,6 millió új felhasználó. Hetente.

Kicsit más számokat adnak, de szerintem csak hetek kérdése :)
2010-02-08
nincs kategoria
Zend cikk első rész, második rész. Teljes egészében színtiszta PHP, mindenféle kiegészítés nélkül. Ahogy a TCpdf is.

A (PHP->) HTML->PDF megoldások azér tűnnek jobbnak, mert jóval könnyebb HTML-ben gondolkodni, mint PDF-ben :)

HTML2PDF, wkHTMLtoPDF, DOM-PDF.

A wkHTMLtoPDF a kakukktojás, mert az ugye egy C++ program, a Qt-n keresztül a webkit HTML engine-ra alapozva. Emiatt lehet, hogy gyorsabb, mint a natív PHP-s megoldások, de amíg nem teszteltem, nem nyilatkoztatnék ki ilyeneket csak úgy :)