szantog.com - címlap

Mégsem olyan jó Amerikában a net? Románia dübörög?

Fri, 12 Dec 08 00:00:00 +0100

A világ legnagyobb CDN-je, az Akamai rendszeresen közzéteszi, hogy milyen átlagos sebességeket lát az egyes országokban. Az Akamai hálózatán bonyolódik az internet forgalmának egy igen jelentős része, így a beszámoló adatainak tényleg sok köze van a valósághoz.

Dél-Korea és Japán elsősége nem csoda, ők hagyományosan évekkel előbbre járnak a világ többi részéhez képest. Az igazi meglepetés Románia és az Egyesült Államok.

Úgy tűnik, hogy keleti szomszédunk telkó vállalatai komolyabban veszik a központi infrastruktúrát. Nálunk ugye az a helyzet, hogy inkább a végpontok sebességére gyúrnak (jójó, sok helyen még arra sem, tudom), mert azt lehet reklámozni. Aztán hiába az elméleti sebesség a végfelhasználó felé, ha kicsit beljebb jól összetorlódunk.

Egyébként nagyon jól jön Románia szomszédsága, internet forgalmunk jelentős része Románián keresztül jut ki. Trace route közben csak úgy tobzódnak az ottani állomások.

USA

Csak a nyolcadik helyre csúszott be, pedig az átlagember előbbre gondolná. Érdekes, hogy ott is hasonló problémákon rágódnak, mint itt. Például azon, hogy mennyitől broadband a broadband, merthogy nemcsak nálunk hirdetik a 768kbps-t szélessávnak.

Gyanítom, hogy az USA átlagot a távoli vidék rontja le, mert azt azért nem hiszem, hogy San José-ban rossz lenne a vétel. Nem csoda, hogy Obama rá akar feküdni a dologra, ő jól jár a szélesebben elérhető internettel.

Amazon EC2 Europe

Thu, 11 Dec 08 00:00:00 +0100

Most már van európai központ is és sokan örültek amiatt, hogy akkor most gyorsabb lesz az elérés vagy mi. Hát-hát.

A központ valójában Írországban található, ami felé nem biztos, hogy gyorsabb kapcsolattal rendelkezik az átlag hazai felhasználó. Ha Frankfurtban lenne a központ, akkor lehetne örömtüzeket gyújtani, így majd meglátjuk.

Az európai bővítés igazi haszna így nem is a gyorsabb kapcsolat/ping idő (az eddigi USA központok is hihetetlenül gyorsan érhetők el ping időileg, mintha csak a szomszédban lenne), hanem az, hogy az európai S3 bucket-ekben található tartalmak EC2-es feldolgozása olcsóbb lett.

Az európai árak pont 10%-kal magasabbak, amit a magasabb adókkal indokol az Amazon. Fogalmam sincs, hogy Írországban hogyan adóznak az Egyesült Államokhoz képest, ha valaki felvilágosít megköszönöm.

Ja és egyelőre nincs Windows instance, csak az óceán túloldalán.

Amazon CloudFront - CDN kicsiknek

Tue, 02 Dec 08 00:00:00 +0100

A kicsik (=mi) az Amazon S3-at afféle CDN-ként használják, mert óriási terhelést bír, viszonylag olcsó és könnyű használni (nem kell szerződést kötni, tárgyalgatni, "majd visszahívnak", satöbbi). Az S3 a CloudFront-ig nem volt igazi CDN.

Elég nehéz pontosan definiálni a CDN fogalmát, de az S3 fő hiányossága az automatikus földrajzi terítés volt, amit a CloudFront-tal oldottak meg. A CloudFront tehát nem más, mint az S3 kiegészítése földrajzilag elosztott kiszolgálással és egy jó (óriási) adag marketing.

Az S3 onnan szolgált ki, ahova feltöltötted a fájlt (USA vagy EU), a CloudFront viszont a letöltő helyéhez legközelebbi parkból. Jelenleg 8 USA, 4 EU (hozzánk Frankfurt van legközelebb) és 2 Ázsiai helyszín van.

Hogyan működik?

Feltöltöd a fájlokat egy kifejezetten a CloudFront-hoz létrehozott S3 bucket-ba.
Meghívsz egy API-t, hogy az ebben a bucket-ban található fájlokat a CloudFront is szolgálja ki.
Az API-tól visszakapott név alapján megtudod, hogy mi a fájljaid CloudFront URL-je, mehet a menet.

Az alap kiszolgálási limit 1000 letöltés per másodperc összesen 1gbit/s sávszéllel, de ez egyedi elbírálás alapján ingyenesen növelhető (magyarán indokold meg, hogy miért kell több és nyilván megnézik, hogy mondjuk nem warezra kell-e).

Árazás

Csak a letöltések száma és a felhasznált sávszél után kell fizetni és picit olcsóbb, mint az S3! Az árba beleszámít az S3 és a CloudFront közötti forgalom is, azaz fizetni kell azért, ha a CloudFront lehúz egy fájlt az S3-odról.

Ez nem csak egyszer történhet meg (egyrészt több farm van, másrészt pedig a régóta nem letöltött fájlokat törli a cache-ből, ezért ismételt lekérésre is szükség lehet), de még így is elhanyagolhatóan kicsi szám.

Videó

A CloudFront csak HTTP kiszolgálást tud, nincs HTTPS, pseudo-streaming vagy RTMP. Csak a progresszív download működik tehát.

Úgy tűnik, hogy az Amazon long-tail alapon fogja megszorongatni a nagyokat (Akamai és társai), hiszen a legtöbb webes oldal/szolgáltatás kicsi, nekik a nagy CDN-ek túl nagyok (drágák, vízfejűek, rugalmatlanok).

Az Apple felszabadította Korzikát

Wed, 07 Jan 09 00:00:00 +0100

Térképbuzi vagyok, ez van - az Apple pedig felszabadította Korzikát a francia elnyomás alól, ami számomra a második legérdekesebb keynote infó.

A legfontosabb pedig az új akksi a 17"-es Macbook-ban. Na nem mintha érdekelnének a böszme laptopok, csak a tavalyi év legfontosabb motorháztető-alatti (under the hood) eseménye az Apple fejlett gyártástechnológiája, amit az unibody-val mutattak be és most itt ez az új akksi.

Nyilván az összes Apple termék profitálni fog belőle, ami jó lesz. Az, hogy egészen lemennek a gyártósor szintjéig azt jelenti, hogy tényleg minden részletre figyelnek és minden részletet kontrollálni szeretnének - ettől sikeres az Apple - és a kontroll miatt ezért utálják sokan.

Nincs még egy gyártó, ami a termék ennyi darabkáját tartja kézben, a tranzisztoroktól a felhasználói felületig.

Van webes analógia is: ha valami komoly rendszert szeretnél összehozni, akkor előbb-utóbb falakba fogsz ütközni és kénytelen leszel saját magad megcsinálni. Ezért nem jó nagy látogatottságra az alap Wordpress, ezért próbál az összes live-videós cég saját médiaszervereket fejleszteni (Jázmin -> Milgra, Justin.tv -> saját python cucc, stb.) az Adobe FMS helyett.

A Korzikás dolgot az új iPhoto promó videóban találjátok, ihol la:

Jeff Dunham 2008 Karácsony magyar felirattal

Thu, 25 Dec 08 00:00:00 +0100

Nagy kedvencem és rendkívül jól oldja a túlzabálás okozta feszültséget. Majd 1 óra, én szóltam!

H.264 licencdíj? WTF?

Wed, 17 Dec 08 00:00:00 +0100

Az egész netes videós banda a H.264 irányába nyomul, mivel szabványos, nagyon jó minőségű, sok minden kezeli és ingyenes eszközökkel is előállítható. És bizony szinte mindenki - beleértve engem is - azt hitte, hogy a cucc ingyenes, pedig elvileg nem. Persze semmi sem az, de tegye fel a kezét, aki fizetett már a Fraunhofer Intézetnek MP3 enkódolásért!

Van itt egy cikk az egész ügyről. Engem csak az internetes rész érdekel, itt pedig a lényeg az, hogy 12 percnél rövidebb videóknál nem kell fizetni, fölötte pedig 2%-ot egy esetleges kapcsolt árból (pl. pay-per-view) vagy ingyenes esetben 0.02 USD videónként.

Szerencsére a pénzért feliratkozós oldalakra is gondoltak, itt nem kell videónként mérni, hanem évente fizetendő a licencdíj a regisztrált felhasználók számától függően. 100e user alatt minden ingyenes, fölötte pedig 25 000 USD-től kezdődnek a lépcsők.

Másik szerencse, hogy maximum licencdíj plafon is van, 2009-ben nem kell 4.25 millió dollár fölött fizetni. :-)

Azt hiszem ez is egy olyan licencdíj, amire mindenki magasan...

A feltöltés kezdete mindig gyorsabb mém

Tue, 16 Dec 08 00:00:00 +0100

Szerintem mindenki észrevette már, hogyha feltöltesz valamit valahová, akkor a feltöltés kezdete mindig gyorsabb, egy-két másodpercig úgy tűnik minden szép és jó, aztán megtorpannak a százalékok. Az okok:

A hálózati forgalomban sok-sok szereplő vesz részt, két végpont (a számítógéped és a távoli szerver) között számtalan kis kütyü, elosztó, satöbbi van. Ha elkezdesz forgalmazni, akkor ezek a kis (és néha igen nagy) bigyók tárolják az első elküldött bájtokat az átmeneti tárukban, ennek a feltöltése pedig gyors, így a feltöltésed kezdete "megszalad".

Utána az átmeneti tárak olyan gyorsan ürülnek és töltődnek az általad küldött további bájtokkal, amilyen gyorsan a sorban következő eszköz fogadni tudja őket. Itt lassul be tehát a dolog?

Ez elméletileg jól hangzik, azonba a gyakorlat az, hogy a forgalomban részt vevő hálózati eszközök nagy részének nem olyan nagy az átmeneti táruk, hogy a fenti mémet okozzák. Valójában leginkább a cső másik végén lévő szerverszoftver a ludas.

Ott is van átmeneti tár, amit az operációs rendszer kezel és minden egyes kapcsolathoz létrehoz egyet. Például ha elkezdesz forgalmazni egy Apple gép felé, akkor az azon lévő OSX létrehoz a kapcsolatodhoz egy 256 kbyte méretűt, ami pillanatok alatt megtelik. Az OSX erről a helyről táplál mondjuk egy Apache + PHP kombót, ami meg feldolgozza az adatokat, például folyamatosan fájlba írja, ha ez egy fájlfeltöltés.

A bibi itt van, az operációs rendszer (általában, jó beállítás esetén) piszok gyorsan kezeli az átmeneti tárat, tehát nagyon gyorsan tudná fogadni az adatokat, de az azon futó (szerver)szoftver már általában lassabb. Sok feltöltés tehát nem a hálózati sebesség, hanem a fogadó eszköz terheltsége és az azon lévő fogadó szoftver sajátosságából adódóan lassabb.

A fentieknek mekkora a hatása? Készítettem iPhone-ra egy kis webszervert, mert szükség volt fájlfeltöltésre WiFi-n keresztül a készülő programomhoz. Van erre Cocoa mintakód, de hiába optimalizáltam, nem tudtam 150 kbyte/s fölé menni, pedig SCP-n keresztül 900 kbyte/s-al is működik a dolog.

Tovább próbálkoztam hát és kiderült, hogy a buta Cocoa 510 bájtonként adta át az adatokat a programomnak és ezért marha sok fordulóra volt szükség egy nagyobb fájl fogadásához. Egy (nem Cocoa-s) trükkel megoldottam, hogy fordulónként akár 65 535 bájt is jöhessen, ami 150 helyett 1000 kbyte/s feltöltési sebességet eredményezett és drasztikusan csökkent a CPU használat is.

Software is teh king, again.

Inside the iPhone

Tue, 09 Dec 08 00:00:00 +0100

Most, hogy már az iPhone fejlesztését is tanulgatom elég sok információm gyűlt össze a "belsejéről". Összegyűjtöttem a szélesebb kört is érdeklő, azaz nem fejlesztőknek, inkább csak gépnyomóknak szóló darabokat egy csokorba. Úgy gondolom, hogy ezeknek a birtokában jobb rálátást fogsz kapni az iPhone piaci elhelyezkedéséről és másképpen fogod összehasonlítani mondjuk egy Nokia készülékkel. Vigyázat, hosszú írás, én szóltam.

Alapszabályként úgy érdemes tekinteni az iPhone-ra, hogy ez egy kis laptop érintőképernyővel. Sokkal inkább számítógép, mintsem mobiltelefon, annyira, hogy a mobiltelefon részek (= baseband, kezeli a SIM kártyát, satöbbi) teljesen külön vannak benne.

Ugyanaz az OSX operációs rendszer fut rajta, mint a "rendes" Mac-eken, de ez leginkább csak a feltört telefonokon kezelhető. Nagyon sok szoftver lefordítható rá, pl. Apache vagy Lighttpd webszerver. A feltört telefonokra az OpenSSH feltelepítése után be lehet jelentkezni és ott ugyanaz a Bash parancssor fogad, mint a legtöbb Unix/Linux operációs rendszeren. Itt lehet a legjobban látni, hogy jé, tényleg.

Persze sok képesség egyáltalán nem vagy másképpen érhető el, mert ez mégsem egy asztali gép. Ezek egy része műszaki sajátosság miatt van (pl. az eltérő és igen egyedi felhasználói felület eltérő módszereket kíván), más része pedig az Apple üzleti döntése miatt (pl. nem érhetők el a tárolt MP3-ak, a Bluetooth vagy az USB-s szinkronizáció).

Hardver

ARM architektúra lakik bent (ez egy mobil eszközökben igen széles körben használt dolog, sok okostelefon erre épül), ARM11-es processzort használ. Az ARM11 maximális sebessége 620 Mhz, de az iPhone-okban csak 412 Mhz-en ketyeg.

Feltételezem, hogy erre a hőelvezetés és a kedvezőbb akku élettartam miatt volt szükség. Érdekes kivétel a második generációs iPod Touch, abban már 532 Mhz-re engedték a procit.

Van benne még 128 MB RAM és 8, 16 vagy 32 GB Flash HDD. A HDD sebessége: olvasás 11 MB/s, írás 3 MB/s. Egy sima 5400-es laptop vinyó a huszas tartományban mozog, így ez az érték igen-igen lassú. A RAM sebessége: 120 MB/s.

A legnagyobb megszorítás a memória és lemezkezelés

Az Apple nagyon tart a Flash lemezek limitált élettartamától (egy cella kb. 500 000 írást/törlést bír jelenleg, utána meghal), ezért a fejlesztői doksiban többször felhívja a figyelmet, hogy csak akkor írjunk a lemezre, ha nagyon muszáj és lehetőleg egy menetben.

Valószínűleg emiatt nincs benne virtuális memória, nincs memória swap! (Háttérinfó).

Van kb. 30-50 MB szabad memória a programok részére és kész, de egy fejlesztő sem bízhat abban, hogy ennyi valóban rendelkezésre is áll. Kevés hely esetén minden alkalmazás üzenetet kap, amit érdemes lekezelni. Ha elfogy a RAM, akkor kilövi a programunkat, tehát erre fokozottan kell figyelni.

Nincs benne garbage collection sem, azaz a fejlesztő lelkiismeretes és aprólékos munkáján múlik a memória hatékony kezelése. Memóriaszivárgás esetén nagyon gyorsan elfogyhat a RAM és akkor a rendszer leállítja a programot.

A fentiek miatt teljesen hibás az az állítás, hogy az iPhone teljesítménye hasonlítana a 8 évvel ezelőtt általános 400 Mhz-es 128MB RAM-os 4GB HDD-s asztali gépekéhez. Már a Win 3.1 is használt memóriaswap-et és garbage collectiont, ami itt nincs.

Ha mindenképpen hasonlítani kell valamilyen asztali masinához, akkor inkább egy 486-ost képzeljünk el 16 MB RAM-mal és MS DOS-szal. Kb. ennyi teljesítményre lehet számítani egy saját alkalmazás részére.

Pontosan ezen okok miatt nem hagyja az Apple, hogy háttérben futó szoftvereket is készítsünk az iPhone-ra, egyszerűen nincs hozzá elegendő erőforrás, nagyon könnyen instabillá lehet tenni a rendszert és tönkrevágni az Apple által szigorúan vett felhasználói élményt.

Fejlesztés

A fejlesztés a csak OSX-en futó XCode fejlesztői rendszerben történik, ebben fejlesztik az OSX-es asztali alkalmazásokat is. Az Apple-nek szerintem amúgy sem lett volna ereje egy külön valamire, most meg van egy nagy integrált izéje, amiben fejleszthetünk asztalra és mobilra. Minden egyben, így szép.

Mint minden hasonló rendszernek, ennek is megvan a sajátos logikája, először átláthatatlanul kusza, aztán ha belejössz minden összeáll szépen. A tesztelés történhet az asztali gépeden szimulált környezetben (iPhone Simulator) és magán a készüléken is.

Kényelmes az Interface builder, ahol grafikus felületen lehet összerakni a felhasználói felületet. Nagyon hasznos az Instruments, ahol többek között a CPU használatot és a memóriaszivárgást lehet monitorozni (nem csak a szimulátorban, hanem magán a telefonon is).

Ezeken a nyelveken lehet fejleszteni: Objective-C, C++, "Pure" Java, AppleScript, Ruby és Python. Mielőtt belelkesedsz: azért Objective-C-re van kihegyezve minden. Némi ASM kód is becsempészhető, illetve a nyelveket lehet kombinálni. C-ben az összes ANSI C funkció elérhető, ugyanúgy malloc-olni és memcpy-zni kell, mint régen. Egészen alacsony szintekre is lemehetsz.

Anno a diplomamunkám egy Windows-os program volt, amit C++-ban készítettem a Windows API felhasználásával. Hiszed vagy sem, az iPhone fejlesztésben ez az ismeretanyag nagyon hasznos lett, szinte teljesen ugyanúgy történnek a dolgok...

Fontos, hogy az iPhone alkalmazások nem látják egymást, egy "homokozóban" (sandbox) futnak, csak a saját mappáikba írhatnak, csak onnan olvashatnak.

Érdekes dolog még a telefonos megszakítások kezelése, pl. ha jön egy hívás vagy naptáresemény. Ilyenkor pause állapotba kell tennünk a programot, aztán ha a felhasználó úgy dönt, hogy felveszi a hívást, akkor a rendszer leállítja az appot.

Alapvetően úgy kell megtervezni egy alkalmazást, hogy ilyen megszakítások bármikor jöhetnek, a felhasználó bármikor leállíthatja a programot és nagyon gyors válaszidők kellenek ezekre. Ez a szemlélet jól tenne sok asztali alkalmazásnak is egyébként...

Azzal is foglalkozni kell, hogy az akkut minél kevésbé terheljük. Ha azt nézzük, hogy a fejlesztői doksi szerint mi mennyire fontos (hányszor írnak róla, milyen sorrendben és nyelvezetben), akkor az akkuzabáló eszközök érdekes sorrendje alakul ki:

WiFi (ez eszi a legtöbbet)
Baseband radio (GSM, 3G, stb. mobil forgalmazás)
GPS
gyorsulásmérő
Flash disk (ez meg a legkevesebbet?)

Keretrendszerek

A legtöbb lehetőséget keretrendszerekkel, magyarul Framework-ökkel érik el a fejlesztők. Például UIKit-nek hívják a felhasználói felülettel kapcsolatosat, vagy AddressBook-nak a kontaktkezelőset.

Ezek közül néhány keretrendszer szabványos és más operációs rendszereken is elérhető, így nem kell a fejlesztőknek újat tanulni. Például van OpenGL és OpenAL, ez ismerős lehet a játékok háza tájáról, ezért emlegetik az iPhone-t mint új játék platformot. Persze van olyan, hogy teljesítmény vagy egyéb okból egy-két funkció nem érhető el, pl. az Audio Units keretrendszerből jópár audio effekt hiányzik.

Főleg üzletpolitikai dolgok miatt sok keretrendszer nem használható (Private Frameworks), de ügyes programozók megmutatták, hogy hogyan lehet ezeket használni, például hozzáférni az MP3-akhoz az iPod részben és hasonlók. Ilyen szoftverek csak feltört telefonokra telepíthetők, az AppStore nem fogad be Private Framework-öt használó programot! Igen, van rá eszközük, hogy kiderítsék.

Ha kijön egy új frissítés, mint legutóbb a 2.2, az nemcsak azt jelenti, hogy mondjuk megjelent a Google Maps-ben a Street View, hanem ilyenkor szoktak bővülni a fejlesztők lehetőségei is, azaz messze nem csak a felhasználói felületet és a csilivilit polírozzák!

A keretrendszerek folyamatosan bővülnek, és fejlesztői oldalról is szembetűnő a fejlődés. Igen messze járunk még attól, hogy az iPhone kész legyen.

Például a TV kimenet keretrendszere még csak most alakul és úgy tűnik, hogy hamarosan publikus és dokumentált lesz. Azaz jövőre jöhetnek az olyan játékok, ahol az iPhone lesz a kezelőfelület de a TV-re jön a kép. Tiszta Nintendo.

Konklúzió

A fentiek figyelembevételével talán már másképp látod az iPhone helyzetét. Már-már hihetetlen, hogy az igen limitált hardver erőforrások mellett ennyit ki tudtak hozni belőle. Minden fejlett telefonnál, az Android platformnál is bele fognak futni (belefutottak?) a fenti problémákba és az azokra adott válaszoktól függ, hogy mennyire lesz sikeres egy platform - hiszen most már mobilplatformok versenyeznek, nem gyártók.

A hagyományos telefonokhoz képest világok választják el az iPhone (és Android) platformokat. Míg egy hagyományos telefonhoz elég volt a Nokia vagy a SonyEriccson fejlesztői kapacitása, ide alapvetően másra és bizony jóval többre van szükség. Úgy tűnik, hogy egyelőre csak az Android lesz képes felvenni a technológiai (technológiai, nem üzleti!) versenyt.

A Symbian és a Windows meg lemaradt? Mindenki az iPhoneról és az Androidról beszél, azokra jön ki a legtöbb új szoftver.

Nem csoda, ha sokan azt állítják, hogy az iPhone előnye jelenleg legalább másfél év. Az sem csoda, hogy ezidáig nem tudtak a nagy mobilgyártók egyetlen olyan modellt (vagy inkább platformot) sem kihozni, ami megszorongatná az iPhone-t. Olyan összetett fejlesztőkörnyezetet kell felmutatni, mint amit az előző bekezdésekben éppen, hogy csak megkarcoltam.

Ömlengésnek hangzik de igaz, hogy az iPhone alapjaiban változtatta meg a mobilvilágot és a hagyományos mobilgyártók válasza még mindig nem tiszta. Ezért úgy kell nekik az Android, mint egy falat kenyér.