iPon Hírek

Frissült a Firefox OS

Dátum | 2013. 07. 23.
Szerző | DemonDani
Csoport | MOBILTELEFON

A Firefox OS az okostelefonok körében az idei év egyik legnagyobb durranása, legalábbis ha azt nézzük, hogy mekkora visszhangot kap. Linuxok jöttek, Sailfish OS-ek mentek idén, de ezekről csak ritkán lehetett hallani, míg a Mozilla rendszere el tudta érni, hogy folyamatosan a felszínen legyen. Mostanra a Firefox OS első tesztjei is felbukkantak szerte az interneten, de eddig nem azt mutatják, amit sokan vártak. A Mozilla rendkívül olcsó hardverekkel párosította az újdonságát, ugyanis a terv az androidos és a featurephone-ok közötti piaci rés betöltése volt. Ez eddig nem is jelentene gondot, sőt ez egy életképes cél lenne, de sajnos a rendszer a legkevésbé sem hibátlan, és egyáltalán nem mentesek a Firefox OS-t futtató gépek a lagoktól, valamint más problémák is akadnak még. Be is érett tehát a frissítési igény, és szerencsére már a frissítés is, így a hűvös fogadtatáson a Firefox OS 1.1 segíthet.

A HTML5 alapokra felépített szoftver legújabb kiadását a Peak és a Keon felületén lehet először kipróbálni. A Mozilla sajnos nem szolgált kiadási jegyzékkel egyelőre, így arra kell hagyatkozni, amit a korai kipróbálók érzékeltek. A felhasználói visszajelzések egyelőre meggyőzőek. Az 1.1-es kiadású Firefox OS már az első bekapcsoláskor gyorsabban áll fel, vagyis javult a boot idő. A felület skálázásán is dolgoztak, így a nagyobb felbontás mellett sem mennek össze a feliratok. Az e-maileket kezelő alkalmazás legtöbb hibáját kijavították, a naptárat pedig még egy biztonsági funkcióval is megtoldották, így már nem törölhetőek véletlenül a bejegyzések. A fejhallgató kezelésén is változtattak, így a hívásokat már mikrofon nélküli fülessel is fogadhatjuk, ilyenkor a mobil mikrofonja aktiválódik. A számítógépre kapcsolva pedig választhatunk majd a tárhelyek között (telefon vagy memóriakártya). Ezeken felül még sok kisebb hibát kiküszöböltek, és a rendszer sebességére is nagy hangsúlyt fektettek, így sokkal folyékonyabban fog futni minden animáció. A telepítés folyamatát manuálisan kell levezényelnie a Geekphone modellek tulajdonosainak, ami azért egy kis fekete pont a Firefox OS és a Geekphone neve mellett, hiszen illene OTA lehetőséget nyújtani. A letöltést itt tudjuk megoldani.
Új hozzászólás írásához előbb jelentkezz be!

Eddigi hozzászólások

15. morgyi
2013.07.23. 11:09
Sajnos nagyon későn jött, ahogy egyre jobban fejlődnek a hardverek jövőre már biztosan minimum 2 magos 1gb ramos készülékekkel fogunk találkozni az alsó kategóriában is, az meg a droidnak is elég
 
Válasz írásához előbb jelentkezz be!
14. FRK
2013.07.23. 11:34
Ha saját rendszert futtat, aminek ők szabják meg a hardware követelményeit, akkor miért kellene követniük a trendeket az erőforrás növelésben? Nem kötekedésből kérdezem csak kíváncsi vagyok. Mert elvileg csak a marketing (e-pénisz növelés a felhasználóban) indokolhatja.

Van ugye egy saját rendszer, saját applikációkkal, és ha ők meg tudják oldani egy magon az OS és a programok gördülékeny futását, akkor nincs szükség hardware növelésre. Szerintem úgy tudna hódítani, ha nem drága, de gördülékenyen működő telefont adnak ki, úgy hogy az energiaforrás (a kisebb hardware miatt is) jobban bírja, mint a vetélytársaké. Vagy totál rosszul gondolkodom?
 
Válasz írásához előbb jelentkezz be!
13. DemonDani
2013.07.23. 11:50
FRK

Olcsónak olcsóbbnak és még olcsóbbnak kell lennie... Máshogy esélyes sincs.
 
Válasz írásához előbb jelentkezz be!
12. Dzsekk
2013.07.23. 12:50
Webfejlesztőként látok esélyt a rendszerben, személy szerint nagyon szimpatikus. Akit érdekel a videós beszámolóm a Firefox OS rendszeréről, itt megtekintheti: http://tech247.hu/617
 
Válasz írásához előbb jelentkezz be!
11. FRK
2013.07.23. 13:06
DemonDani

Az az alap, olcsónak kell lennie és gördülékenynek. Pont ma néztem, független, belépőszintű Samsung (Gingerbread) 25 ezerért kapható, Alcatel (Jelly Bean) 35 ezerért. Szerintem ez alá kell menniük, ha labdába akarnak rúgni. Emellett nagyot dobhatnak azzal, ha gyors és felhasználóbarát OS-t faragnak, kisebb erőforrás igény mellett, a hosszabb üzemidővel megnyerhetnek vásárlókat.
 
Válasz írásához előbb jelentkezz be!
10. morgyi
2013.07.23. 13:10
FRK

Ez az OS pont alsó kategóriára és gyenge hardverre lett fejlesztve, ami most olcsón elérhető. De ilyen fejlődés mellett, jövőre a 2 magos 1GB ramos készülékek is elég olcsók lesznek, amin a droid is már bőven jól fut, és előbb vesz a júzer egy droidos készüléket mint ezt. Ez most jelenpillanatban egy olyan OS ami olyan vason is jól érzi magát amin a droid már nem.
Esetleg a Nokia Asha termékvonallal tudnának versenyezni. Csak oda meg ez drága.
 
Válasz írásához előbb jelentkezz be!
9. Lazahunter
2013.07.23. 13:10
FRK

Hasonlóan látom Én is. A francnak kell telefonba a sokmagos proci meg egyebek .. komolyan ez már szinte reklámduma. PC-ben is utálják az emberek, hogy ha egy oprendszer felzabálja az erőforrást és többletet kell alápakolni.

Működjön gördülékenyen és legyen energiatakarékos, ezt várom egy mobiltól ... ne kelljen naponta töltögetni.
Az androidos telóm vicces, minden este töltőn van, mert bőven 50% alá merül, de mikor elmentem nyaralni és csak betettem a szoba széfbe, akkor min 4 napot is kibírt úgy, hogy nem nyúltam hozzá
 
Válasz írásához előbb jelentkezz be!
8. morgyi
2013.07.23. 13:47
Minden megoldható lenne, csak akkor nem vennél új készüléket.
Pont tegnap néztem a CS:GO 130 mega RAM-al beéri, hol van ahhoz képest egy droidos game.
A Matlab ami egy elég komoly sokmilliós program is megáll 250 megánál.
Ehhez képest egy időjárás előrejelző widget képes 60-70 megát zabálni droidon, a fb appról meg ne beszéljünk a maga 100-150 megájával néha. Elkurvultak a fejlesztők nagyon.
 
Válasz írásához előbb jelentkezz be!
7. thedevelop...
2013.07.23. 15:29
morgyi: Az a baj, hogy nem az alkalmazásfejlesztők kurvultak el, hanem a világ. A végfelhasználók elvárják, hogy minden azonnal történjen. Azonnal kell egy új játék, egy új operációs rendszer, egy új szuper alkalmazás, egy új frissítés, minden azonnal.

Ehhez bizony RAPID fejlesztésre van szükség, amihez viszont olyan platform is kell, ami lehetővé teszi, hogy az alacsonyabb szintű nyelvek több száz soros forráskódját például 10 programsorra cserélhesse a fejlesztő.
Ilyen a Java, a .NET, mindenféle script framework (phpCake, stb...) és természetesen ilyenek a mobil platformok is, ahol néhány kattintás az IDE-ben, pár sor beszúrása és máris kész a zenelejátszó alkalmazás.

Csak azt hajlamosak vagyunk elfelejteni, hogy hiába van egymás felett egyre több, 'okosabb' API, a magas szinten leírt programkód egyre bonyolultabban fut le natív hardveres támogatás hiányában.
Pl.: C nyelven egy olyan program megírása, ami képes átváltani a VGA-t grafikus módba, majd megnyitni/értelmezni egy betűtípusfájlt és azt felhasználva kiírni egy szöveget grafikus módban, kb. 10.000 sor, ráadásul sok assembly (azaz gépi kódú) sort is tartalmaznia kell.
Ugyanezt egy függvénykönyvtárral meg lehet oldani 10 sorban.
Utóbbi gyorsabb, de csak az első megoldás esetén lehetünk biztosak abban, hogy mit csinál a programunk. Ezek a függvénykönyvtárak és keretrendszerek olyan robosztusak és hatalmasak, hogy egyszerűen nem lehet tudni, hogy mit csinálnak a háttérben.

Tekintsünk egy C# kódot, amit .NET Framework-re fordítottak le. 1 darab programsorban meg lehet fogalmazni, hogy egy szabályos ablakban megjelenő gombra történő kattintás után egy felugró ablakban kiírja a Windows-ba bejelentkezett felhasználó nevét.
Ebből a forráskódból a fordító kb. 1KB-os tárgykódot (igazából köztes kódot -> .exe) generál. A fejlesztési idő másodpercekben mérhető.
Viszont ahhoz, hogy fusson a programunk, fel kell telepíteni a .NET Framework megfelelő verzióját, ami akár több 100MB is lehet.
Azt pedig, hogy az általunk leírt 1 programsor mennyi memóriát, mennyi processzoridőt foglal majd le, kb. fogalmunk sincs. Hiszen csak azt írtuk le, hogy mi történjen, azt nem mondjuk meg, hogy hogyan! Ez itt a lényeg. Ha azt is meg kellett volna mondanunk, hogy hogyan csinálja mindezt a program, akkor a fejlesztési idő akár egy nap is lehetett volna.

Tehát valamit valamiért.
 
Válasz írásához előbb jelentkezz be!
6. morgyi
2013.07.23. 18:43
thedeveloper

Én csak mikrokontrollerre programoztam eddig, de ott is ugyan az a program ami assemblyben 20 max 30 sor, C-ben megírva (ott igaz rövidebb) de fordítás során lesz vagy 100+ sor assembly kód ami jelentősen rontja a futásidőt, és ez csak egy gyök led villogtató program.
 
Válasz írásához előbb jelentkezz be!
5. DemonDani
2013.07.23. 19:12
FRK

Ezek 20 ezer alatt lesznek javarészt. Meg körülötte. Viszont akkor is ott a Vodafone Smart Mini, ami bőven 20 alatt elvihető és korrekt sebességgel tárja elénk az Androidot.
 
Válasz írásához előbb jelentkezz be!
4. thedevelop...
2013.07.23. 21:16
morgyi: Nekem is volt szerencsém PIC-re kódot írni, mondjuk mi még assembly-ben nyomattuk. Az volt az igazán szép kód. Viszont egy Többsoros 7 szegmenses kijelzőt meghajtani már élmény volt. Állandóan blokkot váltani, figyelni, hogy melyik GPIO van kimenetre és melyik bemenetre állítva, watchdog-ot nullázni, stb..

Nade PC-re cseppet más fejleszteni. Object Pascalban 50 sorban megfogalmazok egy komplett számológépet, .NET-ben egy RSS olvasó is csak legfeljebb 100 sor, de akkor az már zenét és videót is játszik...
DarkBasic-ben 100 sorban már le lehet írni egy autós játékot. Igaz, hogy ha teljes stacktrace-t csinálnánk, akkor pusztán a DirectX hívások száma elérné a 100.000-et, de ez el van rejtve, hogy ne a játék fejlesztőjének kelljen például egy .3ds model bináris betöltésével szívnia.
Ha nem lenne ennyi réteg egymás felett, akkor egy egyszerű színes vonal húzása (x1,y1,z1) pontból (x2,y2,z2) pontba kb. 100-200 programsorba kerülne és valószínűleg sok konfiguráción le is fagyna, de a natív kódunk biztosan kevesebb erőforrással beérné és gyorsabban is futna.

Ezért van például az AngryBirds-nek ilyen nagy gépigénye. Linux-on fut egy Java virtuális gép (a Dalvik bináris köztes kódot vár, mint egy sima java gép). A függvényhívások többsége az Android API-val beszélget, de sajnos van egy részük, ami kihagyja azt és közvetlenül a Linux API-kat hívogatja.
Erre azért van szükség, mert ami a korai időszakban az Android előnye volt, az most kezd a hátrányává válni. Ilyen például a memóriamenedzsment. Amelyik erőforrásról a rendszer úgy gondolja, hogy már nincs rá szükség, azt felszabadítja, de előtte megjegyzi, hogy kb. mi volt ott (nem akarok jobban belemenni). Amikor valami ismét hivatkozik a már felszabadított erőforrásra (legyen ez például egy képfájl), akkor az OS ismét betölti azt.
Nade ez a felszabadítási/betöltési folyamat elfogadhatatlan FPS számokat eredményezne egy játék esetén, ahol kb. minden a textúrákról (azaz képekről) szól.
Régebbi API-kban úgy tudtak csalni a játékfejlesztők, hogy JNI (Java Native Interface) szerű hívásokkal kikerülték az Android akkori képkezelő függvényeit és közvetlenül a Linux függvényeit használták. Mivel az OS ekkor nem tudott a betöltött képekről, így nem volt felettük 'hatalma'. Az erőforrások felszabadítása a programkód dolga volt. Ez persze azt eredményezte, hogy az alkalmazás indokolatlan mennyiségű erőforrást próbált a memóriában tartani, az OS pedig ebbe szépen belehalt.
Tudom, hogy hosszú lett, sorry. Csak gondoltam megosztok veletek némi érdekességet például az android lelki világáról. Egyébként a fenti példa már nem állja meg a helyét a 3-as API óta (API level 11). Ott már sokkal okosabban működik ez a képbetöltés mutatvány, de azt már nem írom le.
 
Válasz írásához előbb jelentkezz be!
3. felziusz
2013.07.23. 22:47
"A Mozilla rendkívül olcsó hardverekkel párosította az újdonságát, ugyanis a terv az androidos és a featurephone-ok közötti piaci rés betöltése volt."

Tévedés! A Mozilla egy nonprofit alapítvány. Nem akar piacot. Egy célja van: Internet mindenkinek.
Ennek a legegyszerűbb módja az okostelefon és olyan szoftver ami nagyongány HWn is elfut. Az, hogy a gyártók és szolgáltatók ebben kereskedelmi lehetőséget láttak az már más kérdés.
 
Válasz írásához előbb jelentkezz be!
2. morgyi
2013.07.24. 01:14
thedeveloper

Köszönöm az információkat. Tudom hogy minél magasabb szintre kerülünk a programozás terén annál jobban elkerülhetetlen az erőforrás pazarlás.

Az assembly pedig mindenhogy szép, nekem közelebb is áll a digites logikámhoz A hétszegmens kijelző pedig tényleg maga a gyönyör, ott igazodni kell az emberi szem felbontóképességéhez hogy ne villódzon, de egy jól megírt interrupt ciklus szépen elfrissítgeti

felziusz

Attól hogy valami nonprofit még nem azt jelenti hogy nem lehet bevétele, sőt nem is kicsi bevétele van (wikipedia: 66,8 m USD (2006)), viszont a dolgozók nem kapnak fizetés, a hasznot pedig visszaforgatják a fejlesztésbe
De gondold csak el valamiből fenn kell tartani a központi épületet is, valamint a fejlesztőeszközök hardverek sem olcsók, valamint a marketing hirdetések technológiák licencelése stb...
 
Válasz írásához előbb jelentkezz be!
1. FRK
2013.07.24. 08:12
Morgyi

Pontosítanék, természetesen a dolgozók kapnak fizetést. A non-profit cég alkalmazottai is bérből élnek, viszont a megtermelt profitot a saját működésükbe fordítják vissza. Profitot nem termel sem a tulajdonosnak, sem befektetőknek, ettől non-profit. Az önkéntesek nem kapnak fizetést, a szerződéses dolgozók igen.
 
Válasz írásához előbb jelentkezz be!