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

Apróságok, de még mielőtt mindegyik elúszik a feledés homályába.

Mostantól mindenkinek a Tomato firmware-t ajánlom a WRT54GL-jére. DD-WRT-vel egyre több gondom van.

A másikat már el is felejtettem :C

Erre válaszul elkezdett programot befejezni. Ezt elolvasni.

Miskolc szép, sajnos nem fotóztunk. Sürgősen kell mostmár egy új akkutöltő. Rendeltem. SFPlanet. Nem volt kedvem vaterázni.

Egész szép az idei évünk tudományos szemszögből:
Femtoszekundomos elektronmikroszkópia. Nagyon rövid elektron impulzusok segítségével tudnak fotonokat vizualizálni. Az OMG skálán erős 7-es a hír.

Egymolekulás tranzisztor. Helló a 0,1 nanométeres csíkszélesség. 9-es kód.

Mágneses mezőre bukkant a Voyager. Laza 6-os, így év végére már csak.

Új fog őssejtekből. 2/10, mert még szikével nyesnyi kell hozzá, majd ha egyszerűen tablettában beveszed és.. akkor lesz 10/10.

Tesla-féle nagy-hatékonyságú vezetékmentes áramtovábbítás. 8,4 pont, de csak mert már jó ideje ismertem a dolgot, viszont nem láttam még ennyire kézzelfogható megvalósítását.

Ennek kapcsán megemlíteném akkor a #26C3-at. (26. Chaos Communication Congress, Berlinben, katt), ahol olyan gyöngyszemek bukkannak fel, mint pl. ezek, mások a GSM titkosítását törderlik apróra (katt, audio). Oh, és pluszpont ennek a logójáért. (Kvantum titkosítás feltörése, helló a 10/10?)

Szintén érdemes pár pillantás erejéig kitekinteni ide. (Frankfurt nemrég több, mint 1 terabitet forgalmazott másodpercenként) Itt van a LINX, a London INternet eXchange statisztika oldala. BIX, Hollandia mindig is nagy forgalmi csomópont volt a kikötőivel.

Persze mindennek ára van, tehát ennek mindnek is. Amikor az olcsó HDTV-k felhajtják az igényt a még szebb panelek iránt, ahogy a tömegtermelt alaplapok, processzorok egyre csak hajszolják Moore 18 hónapos ciklusait, ahogy az új játékkonzolok, játékok mámora egyre csak űzi a grafikus kártya tervezőket, úgy füstöli tele a világ az eget.

Mi is történt a zárt ajtók mögött Koppenhágában?. Gecik-e a kínaiak? Hogy is van ez? Mennyire volt erőfitogtatás Kína részéről, hogy csak egy kis öltönyöst küldött, aki időnként hazatelefonálgatott (!), mikor még Obama is személyesen volt jelen? Kína az új szuperhatalom, amerika meg egy félkereszény (ez benne van a Bibliában. SRSLY!) börtönállam tele buta bérnégerekkel? (Meg nem-bér négerekkel.)

Google karácsony.

Szóval, ha már itt tartunk. Jézus nyáron született.

Portable threads, Pth (libpth).

POSIX threads, 2. rész és 3. rész.

Oké, de felmerülnek az érdekes kérdések, mint pl. hogyan is működik az NPTL? (Native POSIX Threads Library)

A Linux kernelben 2.6 óta létezik támogatás ehhez a függvénykönyvtárhoz. Írja, a wiki. Jó, de miféle támogatás is kellett ehhez?

Linux Threading.


Itt kezdődik, és itt majdnem látszik, hogy hogyan működik az a bizonyos sorbaállás.

Definíciók.

x86_64-re pth példa. 32-bites esetben azokat a "long"-okat át kell írni sima int-re.

Real time.

Valósidejű bármi. Minden. Azonnal. Fontos apróságok:
- GPS, aGPS, IP alapú helymeghatározás segíti a találatok hasznossági rangsorolását
- Termékkereső, valós időben, raktárkészlettel egyeztetve
- Valós időben, valós időben, valós időben. Twitter. Facebook update, MySpace valami. Tehát nem történt más, mint a Google szerverekbe bekötötték intravénásan a "mit is csinálok most?" oldalakat.
- Beszédfelismerés. Valós idejű fordítás. Elképesztő.

Ugyan csak most volt időm megnézni a teljes videót, pedig már hallottam a dolgokról, amikről lerántják a leplet, tudom, hogy mindez megvalósítható, nagyrészt képben vagyok az alkalmazott technológiákal.. de akkor is majdhogynem lélegzetvisszafolytva vártam minden kis keresésnél a reakciót, a történést, ujjongtam a hallgatósággal és mikor kipróbáltam a tutit, éreztem, hogy azért azt a tipikus nörd szívdobbanást :D

A következmények. A jövő. Egy esetleges teheráni típusú forradalom még egy eszközt kapott, amit valószínűleg/reméljük, nehezebben cenzúráznak, tiltanak be, blokkolnak a felhasználó-forradalmárok elől. (Hiszen, azért az a csendes tömegnek is feltűnik, hogy hopp, nincs Google.)

A twitter innentől mainstream lett. Hiába csak 1-2 millióan használják aktívan, ott van a kibaszott gúgölben. Konstans, állandó, fix, megkerülhetetlen ignorálhatatlan helyen.

Mától (tegnaptól) egyetlen bróker sem engedheti meg magának, hogy ne nézze 24/7/365 A Google-t. Egyetlen újságíró sem, ahogy remélhetőleg egyetlen politikus sem fogja szemelől téveszteni a saját körzete, kerülete, városa, országa esményeit, történéseit, véleményét, hangulatát.

Várom már, hogy twitteren lehessen tűzoltókat hívni. Tudom, hogy nem elhamarkodott és hiú mondatok voltak az egyik fejlesztő szavai, amikor arról beszélt, hogy ez az. Amikor olyan apróságokhoz hasonlította, mint az elektromosság, a könyvnyomtatás és .. a vodkaízű fagyi!

Kis update, egy kép - ezer szó, stb..