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!?!)

Brucon 2009 IPv6 Security

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






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.

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é.

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.

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.)

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 :)

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 :)

Ezt nézem, és épp a branch prediction van terítéken. Vajon lehetne-e olyat, hogy
- kinevezni többnyire-igen összehasonlító utasításokat, amik "ha, i > 0, akkor.." kérdésekre a fordító, a futtató környezet, a CPU (?) azt érzékeli, hogy többnyire-igen, akkor lecseréli a sima "ha" utasítást egy olyanra, amelyik jelez a CPU-nak, hogy többnyire az igen ágat érdemes elkezdenie elő-végrehajtania.
- branch prediction helper flageket hagyni/pakolni az futó program utasítás memóriaszegmensébe.

Az egész előadás nagyon érdekes, jó példákkal. Bemutatja, hogy miért is kell nagyon észnél lenni, ha több szálú programot írunk, miért is nem olyan kicsi az esélye annak, hogy egyszerre írunk és olvasunk egy adott memória területet.

Valahol van egy jó talk a probléma megoldásáról, a lock-olásról is, majd előkerítem.

Az a jó, hogy a Ruby egy ilyen kis buzibár szleng nyelve. A RubyGems egy szeméttelep, állandóan tenyészik. Lassú és gagyi. A Rails meg buta.

Első körben jó ötletnek tűnik, hogy lehet ubuntu repositoryn keresztül ruby gemeket telepíteni. De a tutorialok, manualok, guide-ek tömkelegében előbb utóbb kiad az egyszerű programozó egy "gem install rails" parancsot, és kész a baj. Főleg, hogy kérdés nélkül installálja a user home directoryjába. Viszont, ha sudo-val követjük el ezt a sort, akkor a /var/lib/gems/-be pakol. (Ezt se volt egyszerű kideríteni.)

Utó-mellékszál előre betűzve, az ubuntu csomag karbantartókról - akik szintén cigányok - basznak rendesen karbantartani. A rails csomag elavult. Nem kicsit. Akkor vegyék szépen ki a repóbol. Jah, hogy nem is figyel rá senki? Áh, sebaj. Másik WTF, hogy nem használják a RubyGem könyvtárakat; teljesen más helyre installálgatnak dolgokat.

A Ruby on Rails fejlesztői meg persze cigányok. Nah. Mert az actionpack-2.3.5-ben van egy fájl, ami specifikálja, hogy rack ~> 1.0.0 gemre van szüksége az actionpacknak. Ami azért jó, mert a thin szerver szépen felvarázsolja a legújabb rack-et, ami jelenleg az 1.1.0.

Amikor a thin indul, betölti a racket, majd betöltené a rails környezetet. Rails betöltené a rack-et. Bamm. Azért, mert a Rails csak 1.0.x verziókat fogad el. (Ezt jelenti a ~>) A thin viszont alapból a legújabbat kapta. Viszont erről nem kapok értelmes hibaüzenetet, csak annyit, hogy "Missing Rails gem", blablabla.

És Ruby kódot olvasni, olyan, mint mikor pornófilmben valamiért épp belóg a centerbe egy pár here. Instant nyomnád az alt-f4-et, de inkább kicsit tovább nézed, hátha megint pina jön. Feltúrtam egy csomó .gemspec fájlt (/var/lib/gems/1.8/specifications) ezekben átírtam a függőségeket (dependency, >= 1.1.0), az gems/1.8/gems/actionpack-2.3.5/Rakefile-t, majd végül a /var/lib/gems/1.8/gems/actionpack-2.3.5/lib/action_controller.rb -ben a következő változtatásokat kellett eszközölni:


És máris ment a thin. Hát. És én még amiatt aggódtam, hogy a mySQL 5.1 nem fog neki tetszeni, amit a Lucid Lynx (development) feltett.

Git. Fantasztikus. Elég nagy szarban lennénk nélküle.

Viszont kell neki valami webes frontend. Összehakkoltam egy elég kezdetlegeset, egy régebbire alapozva. Viszont ez édeskevés. Egyik legfontosabb eleme egy munkafolyamatnak a konkrét tennivalók, feladatok kezelése, kiosztása, felügyelete, stb.. ehhez meg kezdett nagyon szűkös lenni a Google Spreadsheets.

A z8.hu kapitányával terveztünk valami szépet, jót, mint a launchpad, persze git alapon. Aztán nem lett belőle semmi. (Ejnye!)

Nemrég felfedeztem a Chaw nevű kezdeményezést (igen, redditen, hol máshol?) De nem tudtam működésre kényszeríteni (még). Pedig ígéretesnek látszik. Főleg, hogy PHP alapú az egész. A CakePHP frameworkre épül, és a ha jól látom, akkor 4 éven át vezető programozója kezdett bele.

Aztán végül szembejött a Redmine. Egy Ruby on Rails alapú project manager eszköz. Régebben már találkoztam vele, de elvetettem, mert Ruby. És alapvetően PHP-t akarok, hogy ne kelljen hat dinamikus nyelvű sárkányságokat egy helyre költöztetni. (Mert ugye az alap, hogy egy Apache mögül kuksolnak kifele.)

Redmine viszonylag fájdalommentesen felment. (Install guide) Kell hozzá Ruby1.8.7, sima ügy, (a -dev kell, ha akarunk Ruby/MySQL-gemet fordítani)



Elvileg lehetne a gem-eket apt-vel menedzselni. De .. valahogy nem babráltam vele.



Ruby-Webszervernek a thin tűnik a legjobbnak, ez alapján nem volt vészes összedobni az apache conf-ba:


Ehhez kellett mod_proxy-t forgatni gyorsan. (./config.nice --enable-proxy --enable-proxy-http --enable-proxy-balance) Mivel LTS Ubuntu van a mudkipen, ezért kézzel csinálós rajta az apache. (Nem lenne muszáj, nem ajánlom. Pokol, kínok és szenvedés vár azokra, akik követnek.)




Illetve két kis thin scriptet: (start.sh meg stop.sh, a redmine könyvtárából indítva persze):