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

Mobil, Tablet, Okosóra

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.

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.

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.

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.

=Λ=

( Aadaam v | 2012. 07. 07., szo – 22:52 )

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.

( strogg v | 2012. 07. 08., v – 00:51 )

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

( wlaszi | 2012. 07. 08., v – 06:02 )

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

( martonmiklos v | 2012. 07. 08., v – 09:18 )

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

Hátha eltűnne:

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

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

--
trey @ gépház

( the_nameless89 | 2012. 07. 08., v – 09:46 )

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

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

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.

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.

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?

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.

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.

( turul16 v | 2012. 07. 08., v – 20:30 )

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

( mash | 2012. 07. 09., h – 11:00 )

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

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