Jolla - egykori Nokiások MeeGo-alapú okostelefonokat építenek

 ( trey | 2012. július 7., szombat - 21:19 )

Egykori Nokia alkalmazottak csoportja és MeeGo rajongók megalakították a Jolla nevű startup-ot azzal a céllal, hogy új MeeGo-alapú okostelefonokat dobjanak piacra. A finn cég LinkedIn oldala szerint a Jolla azt a remek munkát akarja folytatni, amelyet a Nokia megkezdett. További részletek tudhatók meg a cég Twitter oldalán és a The Verge cikkében.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Remélem összejön nekik.

És akkor beszarok majd a röhögéstől.

--
trey @ gépház

S nem leszel vele egyedul. :)

En majd csak akkor, ha Nokia felvasarolja a startupot ezutan :)

Vagy ők a Nokiát. ;)

Vagy az M$ a Nokia vagy Jollat.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

+1

+1
Mért kell 626 felesleges android disztrót csinálni, mikor ott az Android telefonra?


Nem szappal gurítok

en abban remenykedem, hogy az osszes ilyen "Save Meego" projekt egyesulni fog hamarosan (beszallnak a Tizenbe pl.), es az igy kapott OS hasznalhatosaga legalabb olyan jo lesz, mint a Maemo5-e vagy a Meego-e

+1

A Mer Project (MeeGo reloaded) mintha pont ugyanezt akarná: https://wiki.merproject.org/wiki/Main_Page

Szerk.: izémizé, ők nem telefont akarnak, hanem platformot építeni.

Hányan vannak? Tizen?

Ez szép volt. :D

:D

Hanyan sutottetek mar el ezt a poent? Tizen?

Nem biztos, hogy mindenki elolvas minden fórum hozzászólást...
De értem miről beszélsz.

Mit csinál aki levelet küld? izen?

:D :D

Ugyan már, mért fejlesztenek egy sajnos, csődbe ment rendszert, mikor ott lenne a nagy alkalom, hogy nikián android lenne.


Nem szappal gurítok

Hasznaltal mar Meegot? Bar joval kevesebb program van ra, mint Androidra, de maga a hasznalata joval kenyelmesebb szvsz. Es az altalad olyannyira kedvelt GNU/Linuxhoz is kozelebb all a Meego, mint az Android, utobbiban gyakrolatilag csak a kernel Linux a driverek miatt.

Ja próbáltam, http://distrowatch.com/table.php?distribution=meego sőtt előtte a moblinuxot is. Szép meg minden de nem egy újjat kéne kitalálni hanem a meglévőbe beszállni.


Nem szappal gurítok

Ez az Inteles Meego, ez nemegyenlo a mobilos (Nokias) Meego-val (ami a Maemora epul, nem a Moblinra), ugy volt, hogy egy lesz a ket projekt, de vegul nem sikerult egyesitenie az Intelnek es a Nokianak a kodjat, az Intel ki is szallt mogule. Amelyik Meegorol te beszelsz, az egy netbook OS, semmivel nem tobb akarmelyik x86-os desktop Linuxnal, amelyikrol en beszelek, az meg a Nokia N9 oprendszere.

Az N9 csak nevében MeeGo. Maemo6 vagy ahogy egyébként hívják: Harmattan. Ha jól tudom, csak belefejlesztették a Meego api-t. A MeeGoCe az amit alapul vehetnek a Jolla csapatnál.

Az a legnagyobb röhej az egészben, hogy már több variánsa volt az évek alatt ennek az OS-nek, mint ahány fajta készüléket legyártottak, amin fut. xD

+1


Nem szappal gurítok

Mivel a Harmattanbol soha nem keszult source release, ezert ez azert tobb mint erosen valoszinu.

(Binaris release az van, Qt SDK-t leszeded a qt honlapjarol, bekattintod a mobility-t, es van egy komplett 10 gigas harmattan-disztrod. Kulon vicces latni, ahogy a /opt konyvtarban ott van a need for speed, linuxra leforditva, by EA)

Azt hiszem ellent kell mondjak magamnak, mert végül is elérhető a harmattan nagy részének a forrása is, szóval akár ezen a vonalon is lehet folytatni:
http://maemo.cloud-7.de/HARM/N9/
Dvd lemezen szokták kikérni a Nokiától, akik ki kell, hogy adják a gpl miatt. Ebből készítik a patchelt kernelt is az aktuális változathoz, hogy teljes kontroll lehessen a készülék felett.

Nocsak. Ezen az apache dir-en ki van irva, hogy vigyazz, a leopard harap, de vegulis aki belul volt az tudhatta, sot, akar haza is vihette, miert ne, ha van egy n9-ese, o customer...

+1
Imádtam az N900-am. (a haverom azóta is használja)

Ha meg a Telekom veszi meg, abból csak T-izen lesz.

jAzz

A Meego busyboxot használ, akkor mégis mitől állna közelebb a GNU/Linuxhoz, azon kívül, hogy gyűlölöd az Androidot és a Linux egy kernel?


=Λ=

Tobbek kozt a desktop alkalmazasok is rafordihatok (meg ha azok nem is arra vannak kitalalva, hogy erintokepernyon szorakozz veluk), Xorgot hasznal (X11 forward ssh-n hasznos tud lenni), etc.

Gyakorlatilag egy armel-es Debian GNU/Linux

Az Androidot meg nem gyulolom, csak nagyot csalodtam benne (de mostanaban tobb olyan dolgot lattam, ami kezdi visszahozni a remenyemet, hogy abbol meg lehet nekem tetszo rendszer lassan, pl. 5.0-ra igert dual boot)

A Xorg legjobb tudomásom szerint nem a GNU project része, így nem is értem, hogy jön a GNU/Linuxhoz.
Az Androidra is "ráfordíthatóak" desktop alkalmazások, ott van pl. az Ubuntu for Android project, az Acer is felhákolt az Androidos netbookjára egy desktop Firefoxot. A dual boot tudtommal megoldható GRUB-bal, bár ez így nyilván nem olyan mint amit beígértek.


=Λ=

Miben is csalódtál?


Nem szappal gurítok

es mit csinal a level, amit nem kuldtek el? zen?

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

Oh, ezek szerint volt a Nokianal aki hitt a Meego-ban? Mert ez Berlinig (Nokia-Gate5) mar nem jutott el...

Na nem mintha a Nokia valaha is adott volna ki Meego-alapu telefont (A Meego Harmattan az annyira Meego mintha a Debian-t Ubuntu Harmattannak hivnak), ami kulonosen viccese teszi...

Na mind1, hajra.

Örömmel hallom a dolgot :)

Nos egy készüléket "fejben" nem nehéz összerakni. Legyen benne, ez+az+am az. A design rajzolgatás kérdése.
De erre szvsz nem lesz szükség.
Ha egy viszonylag ember módon reszelhető készülékre (mondjuk egy samu. modell) tudnak csinálni egy működőd baró Meego Rendszert, ezzel mintegy kvázi bebizonyitva h. nagyon is van létjogosultsága, az erkölcsi érvágás a nokia felé.

Innentől már csak gyártók kérdése. projecktet nem tartom lehetetlennek, főleg ha bevonják a közösséget is.

viszont kezd erőltetett okafogyottá is válni a WP+nokia házasság önmagában is, ha a rácoknak sikerül, totálisan védhetetlen lesz a szükségessége.

Szóval trey, és többiek: Egyáltalán nem biztos, hogy vissza kell fogni azt a nevetést;)
--

A design rajzolgatás kérdése.

Igen. Ezen elkepzeles alapjan keszult peldaul az Audacity es altalaban veve az osszes GTK alapu ui is.

---
pontscho / fresh!mindworkz

Meg a KDE3 :)

avagy ez a "plan B". Kiszervezett formában...
--
"The only valid measurement of code quality: WTFs/min"

Nokia fork..... :-D


http://taklertamas.deviantart.com/ || registered Linux User #518773 || 12.04

lottóznom kéne ;)
--
"The only valid measurement of code quality: WTFs/min"

Hmm. Linkedinről eltűnt a cég. Pedig a google még emlékszuk rá.

Ott van az... Nem tűnt el. Izé, a LinkedIn keresőben ott van, az oldalra kattintva pedig néha előjön, néha nem.

Adatok:

Jolla

    Consumer Electronics 
    Finland | 51-200 employees | 419 followers

51-200 alkalmazott? Ha igaz, akkor nem szarral gurigáznak.

--
trey @ gépház

Ja most nekem is előjött. Azért a linkedinnél is ott vannak a szeren a tagok.

Hátha eltűnne:

Idézet:
Jolla Ltd. is a Finland based smartphone company which continues the great work that Nokia started with MeeGo. The Jolla team is formed by directors and core professionals from Nokia's MeeGo N9 organisation, together with some of the best minds working on MeeGo in the communities.

Nokia created something wonderful - the world's best smartphone product. It deserves to be continued, and we will do that together with all the bright and gifted people contributing to the MeeGo success story.

Together with international investors and partners, Jolla Ltd. will design, develop and sell new MeeGo based smartphones. The Jolla team consists of a substantial number of MeeGo's core engineers and directors, and is aggressively hiring the top MeeGo talent to contribute to the next generation smartphone production.

Ebből ami a legérdekesebb, hogy ezek nem csak tervek, hanem - ha igaz amit írnak - már nemzetközi befektetőkkel és partnerekkel megtámogatott cégről van szó:

Idézet:
Together with international investors and partners, Jolla Ltd. will design, develop and sell new MeeGo based smartphones.

--
trey @ gépház

>nemzetközi befektetőkkel és partnerekkel megtámogatott cégről van szó
Albániából küldött valaki 10USD-t Paypalon?

nem lepne meg, ha az Intel allna a hatterben.

Ezt a platformot nem igazán lehet reálisan megítélni, mert sem erőforrást, sem elég időt nem kapott a fejlődésre. A Nokia a bejelentés után kevesebb mint egy évvel már a Windows Phone felé fordult, hátha megúsznak egy kis fejlesztést.

Fejlesztésileg pedig kifejezetten kényelmes volt. A Qt Creatorral mindenféle komolyabb gányolás nélkül bármelyik desktop platformon hatékonyan és gyorsan lehetett rá szoftvert fejleszteni. A fejlesztéskor használt Qt nyelvhez pedig jóformán csak C++ ismeretek voltak szükségesek.

Nem vagyok gyakorlott mobil programozó és a profik biztosan jobban látják, hogy mik lehettek volna a platform technológiai problémái, de néhány, viszonylag rövid fejlesztési időt és erőforrást igénylő szoftver (webböngésző, egyszerűbb játék, kétpaneles fájlkezelő) kifejlesztése után meggyőzött.

androbit.org - Informatikai portál és könyvtár

"A fejlesztéskor használt Qt nyelvhez pedig jóformán csak C++ ismeretek voltak szükségesek."

Muhaha. A nevetés a csaknak szól.

python + Qt is opció... Szóval elötted szólónak sem volt igaza teljesen.

Citaion needed, de QML is elég volt JS-sel.

Ha kell, hozok neked citation-t, a QML egy sz.pas, es jo resze annyira JS, amennyire Moricka a JS C++: igaz, hogy nem tud annyit, igaz, hogy mashogy vannak benne dolgok, de ebben is van kapcsoszarojel.

(Igen, tisztaban vagyok vele, hogy a Wikipedia szerint JS-based, meg a Nokia hivatalos promo anyaga szerint is...)

Valószínűleg arra gondolt, hogy nagyrészt vanilla C++-al lehet fejleszteni, nem kell baromi sok extra részletet tudni hozzá.
----
India delenda est.

Mondjuk szerintem C++-ul sem igazán kell tudni hozzá. Legalábbis a gázosabb részeket, amin a hozzám hasonló zugprogramozók el szoktak hasalni, elég jól elrejti. A Signal-Slot rendszer megemésztése után nekem semmivel sem tűnt vészesebbnek pl. a Javanál.

Igazabol a Meego altal nyujtott API-tol fugg, mert ugye Qt-ben van garbage collecting ha jol tudom.
Igy ha az api elemeit QObject-re epitve irtak meg, tenyleg nem kell annyira figyelni a memoria allokaciora.

Szamomra Qt-ban fejleszteni azert 'veszelyesebb' mint Javaban, mert
- az IDE Qt-hoz szvsz Qt Creator. Annak pedig mikor legutoljara neztem volt par hianyossaga.
- header fajlok kezelese kulon szerintem nehezkes, de ha jol tudom erre pl mar van integralt megoldas a Qt Creatorban
- Java azert gyorsabban fordul. Ez egy nagyobb projekt fejlesztesenel szerintem elegge szamit.

Kb ennyi, de ez ugye eleg szubjektiv volt.

Qt Creator az alapertelmezett, igen, abban irod, amiben akarod.

A java gyorsabban fordul - hat amennyire a java lefordul, ugy minden gyorsabb. Qt eseten nativ kodot kapsz a vegere, nem java bytecode-ot.

C++-ban kell memoriara figyelni, igen, bar egyre kevesbe, mar mindenfele technologia van hozza, viszont lehet explicit is kezelni.

>>A java gyorsabban fordul - hat amennyire a java lefordul, ugy minden gyorsabb. Qt eseten nativ kodot kapsz a vegere, nem java bytecode-ot.

Fejlesztes szempontjabol mindegy hogy mire fordul, ha tudod tesztelni.
A vegeredmeny mas teszta, itt nem arrol volt szo.

Ahhoz, hogy lefuttass egy unit tesztet, a kodot futtatni is, azaz tenylegesen forditani kell, nem?

A "na vajon fordul-e problemakat ma mar egesz megbizhatoan kicsipogjak az IDE-k. Legutobb tan 5 eve irtam olyan kodot ami az eclipse szerint hibas volt, szerintem meg nem, es nekem lett igazam.

Akkor mirol is beszelunk? Mikor szamit barhova ez a forditasnak csufolt felmegoldas?

Unit teszt azert nincs a program minden reszehez, es gondolom azert pont az ido tenyezo miatt, nem mindig futtatja az ember az osszes unit tesztet, csak azt, amihez esetleg hozzanyult, es ugy erzi gond is lehet a dologban.

Itt mar lehet tenyleg nem szamit, nem tudom. Nagy c++/Qt projectet meg nem fejlesztettem, szoval nincs tapasztalatom.

Jo, en csak az ellen vagyok, hogy egy intermediate lepest, aminek az eredmenyet ma mar sehol nem lehet kozvetlenul felhasznalni, vetunk ossze egy tenyleges forditassal.

Igen, ertem hogy APK-t lehet belole csinalni, meg jar-t meg war-t, de ezeket amint felrakjuk, csomagolja ki a container, es amint futtatjuk, forditja a tenyleges (JIT) compiler, es hat nem mindig olyan gyorsan, mint azt a felhasznalo szeretne.

A masik oldalrol meg az IDE-k fel vannak fejlodve szerencsere annyira, hogy amit a javac le tud ellenorizni, azt ok leellenorzik gepeles kozben mar az AST-n.

Azt gondolom abban egyetertunk, ha a JIT barmilyen ok miatt tulfut az emberi tureshatar idejen (200msec, hogy ez miert pont ennyi, hagyjuk, mindenkinek van tureshatara, a pszcihologusok szerint ez a jellemzo) akkor a felhasznalo jobban orulne egy joelore leforditott kodnak, avagy, ha belegondolunk, minek kell egy fordito egy mobiltelefonra. (nyilvan azert mert az Androidnak nincs hatasa arra,milyen hw-n fut, a Nokianak azert volt.)

> nyilvan azert mert az Androidnak nincs hatasa arra,milyen hw-n fut

Ez nem teljesen jo kifogas, mert a market siman lekerdezhetne, hogy a kliensnek milyen processzora van es lefordithatna az eros szervereken letoltes/telepites elott. Igy a kecske is jollakna es a kaposzta is megmaradna.

De az android nem csak market..

Mindegy, az a gondolat, hogy mivel a telefonokat nem mi gyartjuk, ezert a deployment tortenjen egy platformfuggetlen nyelven, aztan majd a telo platformositja, teljesen vedheto.

Ami persze vicces, mert jo nehany programnak (kb. az osszes 3D jateknak) hatra kell nyulnia azert a JNI-hez, es ott meg mar kokemenyen C/C++ kodolas megy platformfuggoen (hacsak nem OpenCL, nem irtam meg ilyet telefonra)

Ezert a helyes megoldas az elore forditas: ezzel is novelni lehetne a felhasznaloi elmenyt, ha valaki hivatalos Marketen keresztul szerzi be a cuccait, ha meg nem, akkor a telefon is le tudja forditani, csak -nyilvan- lassabban. Es a Google-t joval kevesbe erdeklik azok, akik nem marketesek, mert a business model az app eladasra van kihegyezve.

Az OpenCL meg masra valo. Es a C/C++ programokat is szet lehet osztani platformfuggo es platformfuggetlen reszre.

El vagy picit tévedve. Az Apple és a Google bevételeinek is csak egy jelentéktelen töredékét jelenti az app store-jaik bevétele. Egyikük sem erre alapozza az üzleti modelljét. Az egy más kérdés, hogy fontos része a rendszerüknek, mert húzza a telefonértékesítéseket.

A C++ kódbázisok kb. 98%-a platformfüggetlen kód szokott lenni jobb helyeken.
Ráadásul általában jól elszeparálják a platformfüggő részeket, hogy egyértelmű legyen, mit kell cserélni. Tipikusan még a build system is platform independent tud lenni.

Azert asszem ahhoz mar eleg sok evet lehuztam Linuxon, hogy ha valasztani kell miben higgyek, a mikulasban vagy a platformfuggetlen binaris c++-alkalmazasokban, akkor inkabb az elobbit valasztanam.

En ertem hogy ezt meg lehet oldani, de a legutobbi emlekeim is arrol szolnak, hogy ezt nem szoktak. Tovabba az Android appok jelenleg kulonosebb gond nelkul futtathatoak pl. intel atom felett is, bar ugye az a bravur, hogy atom proci legyen a telefonban, nem igazan sikerult, pedig az intel nem kis lobbit gyakorolt erre, es a Nokia mar akkor is nagyon ketsegbe volt esve amikor ezzel akart lenni az ajfon killer.

Szoval itt nem arrol van szo, hogy le tudod-e forditani a C++ kodot egy masik rendszerre, nyilvan le tudod. Itt most binaris platformfuggosegrol beszelunk, hogy nem az van, hogy nekem mondjuk armv7-es telom van, neked meg armv8-as, es akkor az egyik nem tamogatott, hanem ezt intezze el a telo maganak, forditsa le a megfelelo procira ott helybe.

Azt siman elhiszem hogy ami fordul a fobb unix-variansokon es meg windowson is (mingw/gnuwin32 nelkul), az definicio szerint platformfuggetlen, csak itt mashol csusztunk el akkor.

Szerintem mivel a szoftver platform jelen esetben mindig android, ezért vertikális platformfüggetlenségről beszélünk, azaz csak a hardver platform változik. Így szerintem teljesen jól megáll az az állítás, hogy egy c++ kódnak legfeljebb minimális változtatásokkal le kell tudnia fordulnia a különböző platformokra, hiszen a használt libraryk és rendszerhívások nem változnak.

Teljesen rendben van.

Honnan indulunk: miert kene a mobilon forditonak lennie?

Valaszom: azert, mert a hw-platform valtozik.

Namost rakhatunk mi arra a szegeny mobilra gcc-t is, csak ugye az ellenpelda a Meego volt, ahol a hw-platform a nokia miatt kotott, igy rogton dolgozhat binarisban.

Ki mondta, hogy a mobilon kell fordítani? Egyrészt van cross-compiling, a támogatott platformokra előre lefordíthatja a fejlesztő az alkalmazást tetszőleges hardveren (jellemzően a fejlesztői gépén), és megfelelő módon publikálhatja.* Másik lehetőség, hogy ha marketre publikál, akkor elég az alkalmazást valamilyen fordítható verzióban feltölteni (lehet ez előfordított bytecode is, nem muszáj a nyers forrásnak lennie), amiből a market előállítja a megadott támogatott platformokra a binárist. De azt is lehet, hogy a mobil fordít, de csak bytecode-ból, így a fordítás is gyorsabb, és a forráskódot sem kapják meg a felhasználók.

* Egyébként ugyanígy működnek a linux disztrók bináris repositoryjai is, ha ott működik, mobilon miért ne működhetne?

http://en.wikipedia.org/wiki/Continuous_integration

Ha meg ilyet nem hasznaltal, akkor nem programoztal rendes cegnel.

mert javaban aztan nem lehet leakelni...

--
NetBSD - Simplicity is prerequisite for reliability

"C++-ban kell memoriara figyelni, igen, bar egyre kevesbe, mar mindenfele technologia van hozza, viszont lehet explicit is kezelni."

Miert, 20 eve nem voltak refszamlalt pointerek meg hasonlok? :)

C++ tomeny szivas, a programozok elenyeszo resze ir jo C++ kodot.

Sajnos a valóságban a programozók elenyésző része ír jó kódot. Managed nyelvekben könnyebb kódolni, de ez nem jelenti azt, hogy a programozó automatikusan jobb kódot fog benne írni.

Igazából de.
----
India delenda est.

Csak megerősíteni tudom. A másik, hogy olyan szinten problémák vannak az OO tudással,
hogy azt valami szörnyű. A legtöbb c++ programozónak - tapasztalataim alapján - fogalma
sincs a tervezési mintákról, meg úgy egyáltalán, hogy egy oo programnak hogyan kellene
kinéznie. Gyakorlatilag egy olyan C-nek használják, amiben vannak objektumok. Eclipse
után meg a vim és a visual studio egy vicc, sajnos, a gcc vicces hibajelzéseivel együtt.

+1

Tudsz valami jó könyvet amit C programozó kollegáknak odaadhatok, hogy ne nekem kelljen magyarázkodnom, ha nem tudják, hogy mi az a singleton?

Én ezeket a dolgokat véres verejtékkel tanultam meg (ki tudja milyen szinten), lehet, hogy jó könyvvel egyszerűbb. Ma például egy indiai kollegának valami ilyesmit kellett magyarázni:
http://doc.qt.nokia.com/4.7-snapshot/model-view-programming.html
Nem pont ez volt volt, de egy ehhez nagyon hasonló probléma. Nem értette, hogy ez miért jó, mi az egésznek az értelme. Lehet, hogy én magyaráztam szarul.

Sajnos még nem találkoztam olyan intermediate level könyvvel OOP témában, ami elég szemléletes és érthető, de már nem gagyi.

Hallotal mar a Tervezesi Mintak (Design Patterns) cimu munkarol?

Rohogni fogsz, a peldak C++-ban vannak...

Ismerem a konyvet, de kezdoknek nem megfelelo. Akinek baja van az OOP-vel, annak az melyviz.

Head First Design Patterns

Es meg vegyuk hozza, hogy a Scratchbox+Xephyr fele "Harmattan SDK" a vicc kategoria az Eclipse-szel osszekotott Android SDK-hoz kepest.

Qt ban nincs garbage collection.
Van egy mechanizmus benne, hogy a szülő objektumokhoz felvett gyerekobjektumokat a szülő törli, ha őt magát is törlik. Ezért egy felépített gui-nál nem kell egyenként törölgetni az objektumokat, de ez nem garbage collection.

-Az QtCreator szerintem régen kinőtte a gyermekbetegségeit.
-A headerekkel is kb 4 es verzió óta szerintem semmi baj, nem kell egyenként mindenhez objektumhoz külön headert linkelni.
-A fordulásról nem nyilatkozok, de szerintem alaból értelmetlen az összehasonlítás fordítási időre.

-HW iranytut
-billentyuzetet
-AP modot tudo wifit.
-IR remote-ot
-One to go USB -t kerek.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

>> One to go USB -t kerek.

usb on-the-go-t kérsz

Irthattam volna OTG-t akkor nem sulok bele :)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

És az USB OTG-nek mi értelme lenne? Nagy hirtelen most csak egyetlen dolgot tudok elképzelni: két OTG-s telefon összekötését.
Nem inkább USB host mode kellene neked?

Sub

Még egy cég, ami még azelőtt fog beledögleni abba, amit csinál, mielőtt még igazán megszületne. :)

Pedig jó lenne, ha lenne. Sem az Apple-t, sem a Google-t nem támogatom szívesen, sem a pénzemmel, sem az adataimmal. A Microsoft meg egy nagy kérdőjel.

Akkor egy feature phone a te barátod, esetleg a döglődő Symbian! :)

Symbiant, Symbiant! :)

Jaja! Elvégre mindenki azzal szopatja magát, amivel akarja. :)

Az S40 lesz az igazi. :)

Itt arról van szó, hogy önmagad szopatása. A s40 nem az, sőt :)
----
India delenda est.

Pont azért írtam. :)

Bizony, S40 a (kényszerű) jövő. Érkeznek az egyre okosabb, érintős S40-alapú készülékek.

Pozitívumuk a hívásfogadó hardvergombok megléte, Nokia Maps (egyes típusoknál), Angry Birds, 1GHz processzor és a kisebb energiafogyasztás, viszonylagos olcsóság.

Végül győz Asha, kinek 1 nap alatt nem ürül ki a hasa. :D

(rossz helyre ment)

Van, aki pont azt élvezi...

itt kiderul, hogy kik is azok valojaban a huprol ;)