Firefox OS Simulator 4.0

Vyšel Firefox OS Simulator 4.0. Jedná se o doplněk webového prohlížeče Firefox, jež umožňuje spouštět Firefox OS v okně prohlížeče. I bez telefonu si tak uživatelé mohou Firefox OS vyzkoušet a vývojáři mohou pro něj vyvíjet aplikace. Nejnovější verze simulátoru přináší například podporu testování plateb u placených aplikací.

12.7.2013 11:16 | Ladislav Hagara | Zajímavý software

Komentáře

[Ravensun]

To je hodně dobrý, to se mi líbí :)

[Ravensun]

Jen to prohlížení internetu s "landscape" rozhraním je nepoužitelné. Mají příliš velké lišty (lišta se "Zpět" tlačítkem a "hvězdičkou") a pak lišta s adresovým řádkem je příliš vysoká. Dále mi chybí možnost uložit stanice v rádia, možnost nastavit kdy má telefon upozorňovat na úlohu v kalendáři, jestli za 10 minut nebo za 53 minut (ty přednastavené mi nemusí vždy vyhovovat), dále mi chybí možnost si vybrat soubor z paměti telefonu, který se má použít pro vyzvánění už v nastavení atd atd.....

[JirkaH]

mrtve narozene dite

[.]

taky si rikam, jestli vubec reportovat bugy a ze uz jich mam 6 behem prvnich 30sec pouzivani

[Ravensun]

Reportujte prosím...

[.]

too lazy, beztak neco z toho budou asi duplikaty a zbytek nepochopeni nebo nedockavost a novych bugu tak maximalne jeden nebo zadny. navic je to z okna kde to chce simkartu a chova se obcas jinak, takze tam bude potreba nejaka clickpath, kterou uz si nepamatuju. slo o podsviceni on/off aktivovanych ikon zarizeni. tam co je wifi/modrozub a spol. tak neco slo jen vypnout a uz ne zapnout a neco jen zapnout a uz ne vypnout a tak. mozna to ale jen treba delsi dobu premyslelo...

[xvasek]

Možná, ale taky poslední svobodný systém pro mobily, který dnes někdo vyvíjí a prodává. (Ještě přijdou časem Sailfish a Ubuntu, ale u těch vidím šance ještě nižší, než u FirefoxOS.)

[little.owl]

+1

[Ravensun]

+1

Ikdyž já doufám,že zrovna Sailfish se také masově prosadí,protože co jsem Firefox OS zkoušel v simulátoru, tak to je defakto zkopírovaný Android a Sailfish dle prezentací vypadal s ovládáním trošku odlišně oproti Androidu, Takže mě to trochu zklamalo.

[.]

jestli chce firefox os prezit, tak by se mel oprostit tatrankoveho formatu a profilovat i smerem k neprilis chytre, ale zasitovane full hd televizi.

[anonym]

Ubuntu na mobilu či tabletu má jednu zásadní výhodu, že na rozdíl od všech módních cvičení na téma co všechno se dá naskriptovat v okně browseru, je to skutečný OS s nativními aplikacemi a k tomu navrch ještě s možností mít na externím monitoru normální linuxový desktop.

[gtz]

Zkoušel jsem to co bylo uvolněné pro Nexus a nějak to bylo moc nepoužitelné. Je fakt, že to bylo uvolněné a build se dá sestavit téměř pro cokoliv, já zkoušel jak Nexus tak i nějaký build pro low-end G300 a bylo to ještě pomalejší než když na tom telefonu běžel FF.

Jak tam připojíš externí monitor když převážná většina telefonů má pouze USB kde je možnost TV-out (připojíš přes redukci, jasně, ale opět se dostanem na rozlišení PALu). Na tabletu by možná šance byla připojit to přes HDMI.

[anonym]

HDMI umí i lepší mobily. Na těch horších to stejně asi nemá smysl moc zkoušet, nemají potřebný výkon.

Samodomo buildy co nepodporují akceleraci a vykreslují většinou přes VNC nemá smysl hodnotit.

[gtz]

ano zkoušel jsem nějaký build FF pro G300 a nebylo to zase tak špatné. I pro ten teefon jsem zkoušel poslední build Ubuntu z 07/2013 a FF mi připadal o něco lepší, stabilnější.

Přitom oba buildy jsou z pera jednoho člověka co pro ty telefony dělá CM, který funguje skvěle. Nebýt samodomo buildů tak budeme odkázáni jen na to co výrobce uvolní.

[xvasek]

Tak uvidí se, co to udělá. Kompletní systémy už tu byly - já jsem na iPaqu používal opie (ještě bylo "konkurenční" GPE), ale nepočítám, že by to tady vůbec někdo znal. Od té doby si pamatuju, že udělat dobrý kompletní systém ještě neznamená úspěch. Osobně jsem tedy spíše pesimistický a očekávám, že Ubuntu na mobilech skončí podobně, jako opie / GPE na handheldech - fantastický systém s obrovskými možnostmi, o který ale tak nějak nikdo nebude mít zájem.

[anonym]

To Familiar jsem taky používal, ale nutno říct, že i v době největší slávy to byl těžký nedodělek, který plně podporoval dva nebo tři modely PDA a ještě v každém z prostředí chodilo lépe něco jiného. Ostatně samotný iPAQ byla spíš hračka co mělo pár nadšenců v porovnání s počtem mobilů dnes.

[xvasek]

Já jsem měl zrovna model, co mu hardwarově fungovalo úplně všechno, ale je pravda, že většina ostatních uživatelů se spíš pokoušla o věci typu rozjet Bluetooth nebo SD karty.

[frdrx]

Mrtvé dítě, taky dítě.

Nicméně věřím, že tohle dítě bude prospívat dobře.

[Pavel Čejka]

Co kdyby to mrtvé dítě bylo zombie? Co kdyby se Firefox OS začal šířit, jako T-Virus?

[ciky]

Poprvé, co ze SW zvracím, to celé dělal nějaký brigádník

[gtz]

Nainstaloval jsem to, něco to napsalo, padlo to. Tak jsem to znovu otestoval a nějak to není nic moc. Doplněk šel hned pryč. Jsem hodně zvědav na první recenze ZTE Open zda se to vůbec dá používat.

[stativ]

HTML5 jako vývojová platforma nemá na mobilech co dělat.

[little.owl]

To je pohled na svet z jednoho uhlu a ten neni ale jediny. Ostatne i jeho averze vuci GC mluvi sama za sebe.

[Leopold]

Ostatne i jeho averze vuci GC mluvi sama za sebe

Jistě, kdo by nechtěl mrhat cykly, když to zvládne sám a ušetří prostředky? Jedině terorista a fanatik. /s

[stativ]

Tak tak. I sebelepší GC si nějaké cykly navíc sebere.

[Radek Miček]

GC přispívá k vyšší modularitě programů. Ruční správa paměti, jak ji známe z C/C++, je zdrojem mnoha problémů s funkčností programů.

[Leopold]

Modularitě? Víš vůbec, co to slovo znamená? Když neumíš přiřadit ukazateli NULL|0 nebo paměť uvolnit, tak si dál bastli třeba v Pythonu, ale neotravuj ty, kteří programovat umí.

[Radek Miček]

Modularitě? Víš vůbec, co to slovo znamená?

Můžete mi to prosím vysvětlit.

Modularitě?

Vysvětluje to třeba Uniprocessor Garbage Collection Techniques, část 1.1 – motivace:

Garbage collection is necessary for fully modular programming, to avoid introducing unnecessary inter-module dependencies. A software routine operating on a data structure should not have to depend what other routines may be operating on the same structure, unless there is some good reason to coordinate their activities. If objects must be deallocated explicitly, some module must be responsible for knowing when other modules are not interested in a particular object.

Since liveness is a global property, this introduces nonlocal bookkeeping into routines that might otherwise be locally understandable and flexibly composable. This bookkeeping inhibits abstraction and reduces extensibility, because when new functionality is implemented, the bookkeeping code must be updated. The runtime cost of the bookkeeping itself may be significant, and in some cases it may introduce the need for additional synchronization in concurrent applications.

[koa]

TIL Linux není plně modulární, zahazuji modprobe a přepisuji jádro do Javy

[Radek Miček]

Zrovna Java v modularitě nijak neexceluje.

[XMen]

Tak to by ste sa divil.

[stativ]

Reference counting nic? Něco jako boost::shared_ptr nebo std::shared_ptr.

[Radek Miček]

To je ještě pomalejší než moderní GC a navíc to nefunguje s cykly.

[stativ]

Určitě je pomalejší mít jeden objekt s reference counting než nechávat GC prohledávat celý heap? Cykly jsou samozřejmě nepříjemné, ale často ukazují na chybu v návrhu.

[Radek Miček]

Určitě je pomalejší mít jeden objekt s reference counting než nechávat GC prohledávat celý heap?

To máte v programu jen jeden objekt? Jinak moderní GC typicky neprohledává celý heap najednou.

Podobnou diskuzi jsem již vedl.

[stativ]

To máte v programu jen jeden objekt?

Ne, ale obvykle člověk nepotřebuje mít reference counting na vše. Ze zkušenosti bych řekl, že je to spíš rarita.

Jinak moderní GC typicky neprohledává celý heap najednou.

To je sice pěkné, ale na mobilu, kde za každý zbytečný cyklus platím menší výdrží je to stejně nanic.

[Radek Miček]

To je sice pěkné, ale na mobilu, kde za každý zbytečný cyklus platím menší výdrží je to stejně nanic.

Uživatel chce i spolehlivost. A pro výrobce programu hrají roli náklady na vývoj a rozvoj aplikace.

[stativ]

Většina programů, co používám je psaná v C nebo C++ a fungují spolehlivě.

Náklady na vývoj jsou validní argument, akorátže ve výsledku to znamená, že se zaplatí bastlič, který program udělá v Javě i za cenu toho, že ten program nebude efektivně pracovat se zdroji. Pokud by šlo jen o GC, tak u desktopu to nijak nevadí, výkonu je hodně, pár dalších cyklů není problém, a hlavně je hodně paměti a tudíž se GC často ani nemusí spouštět. Ale na mobilu podle mě nemá co dělat, protože tam je paměti málo a GC musí pořád něco uklízet.

[Radek Miček]

ve výsledku to znamená, že se zaplatí bastlič, který program udělá v Javě i za cenu toho, že ten program nebude efektivně pracovat se zdroji.

Nebo to znamená, že programátor bude mít více času na důležitější optimalizace.

Např. kompilátor Haskellu GHC může během kompilace přepisovat kód pomocí programátorem daných pravidel a tím zlepšit výkon.

Paradoxně programy s GC občas spotřebují méně paměti než ty bez GC.

Dalším příkladem je XQuery knihovna HXQ v Haskellu, která na některých dotazech využije 300 krát méně paměti než knihovna XQilla, jenž je napsaná v C++.

Pokud by šlo jen o GC, tak u desktopu to nijak nevadí, výkonu je hodně, pár dalších cyklů není problém, a hlavně je hodně paměti a tudíž se GC často ani nemusí spouštět. Ale na mobilu podle mě nemá co dělat, protože tam je paměti málo a GC musí pořád něco uklízet.

Pokud aplikace alokuje převážně malé objekty s krátkou životností, tak to pro GC nebude problém (např. 5% času programu spotřebuje GC).

[stativ]

Nebo to znamená, že programátor bude mít více času na důležitější optimalizace.

Pokud opomenu to, že ruční správa paměti tolik času nezabere, efektivní využití zdrojů u mobilů je hodně důležité.

Paradoxně programy s GC občas spotřebují méně paměti než ty bez GC.

Občas ano. Ale zrovna v odkazovaném příkladě OCaml spotřebuje méně paměti než C++ ve dvou z deseti případů, v jednom stejně a v ostatních 2x až 9x tolik (o čase ani nemluvě). Krom toho benchmark game neběží na malém systému s ARMem jako je tomu u mobilů, ale na x86.

[little.owl]

Pokud opomenu to, že ruční správa paměti tolik času nezabere,

Reseni souvisejicich bugu ano. Znovu, to ze se u kritickych projektu zakazuje v C/C++ rucni sprava pameti ma sve koreny v horke zkusenosti.

efektivní využití zdrojů u mobilů je hodně důležité.

A stabilita a mala chybovost aplikaci napsanych prumernym programatorem je dulezita jeste vice. Plno zajimavych aplikaci je napsano lidmi, kteri az tolik programovat neumi, zato maji dobre napady a znalost veci. Soucasne mobily nejsou platformou, kde je treba vydojit z HW maximum, ostatne uspech Androidu o tom svedci.

[stativ]

Reseni souvisejicich bugu ano. Znovu, to ze se u kritickych projektu zakazuje v C/C++ rucni sprava pameti ma sve koreny v horke zkusenosti.

Však u kritických projektů proti GC nic nemám, ale takových je minimum. Krom toho, mobily nejsou zrovna vhodná platforma pro běh nějakého kritického projektu i kdyby jenom kvůli risku vybití baterie v nejnevhodnější dobu.

A stabilita a mala chybovost aplikaci napsanych prumernym programatorem je dulezita jeste vice. Plno zajimavych aplikaci je napsano lidmi, kteri az tolik programovat neumi, zato maji dobre napady a znalost veci. Soucasne mobily nejsou platformou, kde je treba vydojit z HW maximum, ostatne uspech Androidu o tom svedci.

A proto se mi taky Android příliš nelíbí. Když vidím, že to nic nedělá ale stejně to má spotřebováno 200MB RAM, chce se mi brečet…

[little.owl]

Krom toho, mobily nejsou zrovna vhodná platforma pro běh nějakého kritického projektu

Stejne tak nejsou platformou, kde je treba vydupat maximalni vykon a kde overhead GC je problem.

Klicove pro mobilni platformu je snadna tvorba aplikaci, pokud mozno i amaterskym programatorem, a pak JS/HTML5 neni spatna volba, nebot je to asi skutecne jedine multiplatformi a popularni reseni.

Když vidím, že to nic nedělá ale stejně to má spotřebováno 200MB RAM, chce se mi brečet…

Muj sluzebni mobil ma 2GB RAM a nejvice pameti mi zabiraji nativni aplikace, Dalvik based prekvapive nejsou problem.

[stativ]

Stejne tak nejsou platformou, kde je treba vydupat maximalni vykon a kde overhead GC je problem.

Problém to je, protože výkonu zas tolik není a ty cykly navíc se projeví v horší výdrži na baterku.

[little.owl]

Baterku beru, ale v realu to vetsinu lidi taky netlaci, jinak by nevyzadovali zrave 3D rozhrani. Pres noc se to hodi do nabijecky nebo do docking station; me ostatne staci na nabiti hands-free v aute. Lidi co si chteji chrochtat, ze jim staci nabijet jednou tydne se musi poohlednou jinde.

[stativ]

Lidi co si chteji chrochtat, ze jim staci nabijet jednou tydne se musi poohlednou jinde.

Bohužel ten výběr zas takový není.

[koa]

Já tedy raději utratím víc peněz za PROGRAMÁTORA než za ňoumu, co vyžaduje GC

[little.owl]

Dobry programator dokaze takove problemy omezit, nikoliv vyloucit a to je duvod, proc v rade kritickych aplikaci (automotive, medical, military) je podle rady standardu dynamicka/rucni alokace pameti zakazana.

[...]

a byly by i cisla standardu?

[Radek Miček]

a byly by i cisla standardu?

MISRA C nedoporučuje používat ukazatelovou aritmetiku, zakazuje nekonstantní ukazatele na funkce a zakazuje používat dynamickou alokaci paměti:

Rule 20.4 (required): Dynamic heap memory allocation shall not be used.

This precludes the use of the functions calloc, malloc, realloc, and free.

There is a whole range of unspecified, undefined and implementation-defined behaviour associated with dynamic memory allocation, as well as a number of other potential pitfalls. Dynamic heap memory allocation may lead to memory leaks, data inconsistency, memory exhaustion, non-deterministic behaviour.

Zdroj citace.

[little.owl]

+1

[.]

Dik Radkovi. A ted otocime zadani. Jak resi ty standardy OOM situace, kdyz maji byt tak bezpecne?

[little.owl]

Vzhledem k tomu, ze vsechny objekty jsou alokovany staticky v dobe kompilace, zadne OOM nehrozi; casto v linkovane standardni knihovne prislusne funkce nejsou. Pokud se pouziji obezlicky jako memory pool nad staticky alokovanym bufferem, musi byt kod lokalizovany, samostatne testovany, s fail safe scenarem a podle pozadavku zakaznika casto i reviewovany treti stranou; lepsi se toho vyvarovat.

[.]

Takze misto OOM jenom dojdou / pretecou / podtecou indexy do statickeho predalokovaneho poolu. A to se vyplati.

Standard "pro standard". Stejne ve finale musi byt ta aplikace spolehliva a odladena bez ohledu na pouzite techniky, jinak by nefungovala jak se ocekava a to rovnez bez ohledu na pouzite techniky.

[little.owl]

Takze misto OOM jenom dojdou / pretecou / podtecou indexy do statickeho predalokovaneho poolu. A to se vyplati.

To se nestane, nebot aplikace musi byt designovana tak aby mela garantovanou pametovou narocnost a odpovidajici pamet byla na HW k dispozici. Memory pooly se mohou pouzivat napriklad pro sdileni pameti mezi algoritmy, pricemz algoritmy sdilejici pool pak *nesmi* nikdy bezet paralelne; tento pristup neni casto akceptovan a pak se prida dalsich pamet.

Standard "pro standard". Stejne ve finale musi byt ta aplikace spolehliva a odladena bez ohledu na pouzite techniky, jinak by nefungovala jak se ocekava a to rovnez bez ohledu na pouzite techniky.

Jenze nektere techniky a praktiky jsou vice nachylnejsi k chybam nez jine.

[little.owl]

MISRA C 2004, ale i dalsi jako IEC 61508, IEC 61513, DO-178B etc..

[Radek Miček]

Proč by to měl být ňouma?

[anonym]

To je chvályhodné, ale pak asi brzo zkrachujete, protože konkurence zaměstnávající ňoumy bude mít aplikaci hotovou rychleji a levněji.

Ze stejného důvodu už se pár desetiletí neprogramují aplikace v assembleru přímo na hardware i když by to bylo jistě ve výsledku dokonale rychlé a nenáročné na hardware.

[stativ]

To je super, hlavně, že na mobilech je každá aplikace obrovský moloch se spoustou modulů. A co se týče problémů s ruční správou paměti, tak ty jsou z 99% způsobeny blbostí programátora.

[Radek Miček]

To je super, hlavně, že na mobilech je každá aplikace obrovský moloch se spoustou modulů.

Proč moloch? Modulární návrh, kdy se program poskládá z různých komponent, je celkem přirozená věc i u malých programů. Automatická správa paměti pak umožní omezit závislosti mezi komponentami – podobně jako neměnné datové struktury.

A co se týče problémů s ruční správou paměti, tak ty jsou z 99% způsobeny blbostí programátora.

Ano, ale problém to nijak neřeší.

[stativ]

Proč moloch? Modulární návrh, kdy se program poskládá z různých komponent, je celkem přirozená věc i u malých programů. Automatická správa paměti pak umožní omezit závislosti mezi komponentami – podobně jako neměnné datové struktury.

Jasně, jsou případy kdy nějaká automatická správa paměti může pomoct, ale jde to docela dobře i bez toho.

Ano, ale problém to nijak neřeší.

Pustit k programovaní bandu bastlilů, kteří neví nic o paměti, mi zrovna jako šťastné řešení nepřijde.

[Radek Miček]

Pustit k programovaní bandu bastlilů, kteří neví nic o paměti, mi zrovna jako šťastné řešení nepřijde.

A není to problém jazyka? Např. v C/C++ mohu napsat

SendMoreMoney* m = new SendMoreMoney;
DFS<SendMoreMoney> e(m);
delete m;

i

SendMoreMoney* m = new SendMoreMoney;
DFS<SendMoreMoney> e(m);

Jasně, jsou případy kdy nějaká automatická správa paměti může pomoct, ale jde to docela dobře i bez toho.

IMO "bez toho" znamená buď velmi striktně omezit aliasing nebo, pokud chci (divoký) aliasing, zavést nějaký "registr", který aliasované hodnoty po jejich použití uvolní.

Avšak v případě C/C++ je problém v tom, že obě možnosti stojí na kázni programátora.

[stativ]

To bych jako problém nebral. Je to vlastnost jazyka, a s tou programátoři musí počítat. A pokud jim to vadí, tak ten jazyk nemají používat (nebo mohou s C++11 použít třeba scoped_ptr nebo se dynamicky alokované paměti vyhýbat a místo pointerů používat reference).

[Radek Miček]

To bych jako problém nebral. Je to vlastnost jazyka, a s tou programátoři musí počítat.

Ale je to vlastnost, jenž komplikuje psaní a správu větších programů.

Koneckonců proto vznikají různé jazyky, jenž umí kontrolovat aliasing a vynutit použití/spotřebování každé hodnoty. Za zmínku stojí Rust – vyvíjí ho Mozilla pro experimentální jádro prohlížeče Servo.

[little.owl]

I sebelepší GC si nějaké cykly navíc sebere.

No a co?

80% lidi zde bych spravu pameti u [typickeho embedded] systemu s omezenym zdroji, kde navic zalezi na vykonu, vubec nesveril.
Staci se podivat jak dopadl Symbian a jeho aplikace.
S ohledem na bazi programatoru cilove platformy (polovina budou poloamateri), rychlost vyvoje a robustnost reseni neni GC vubec spatna cesta a souvisejici overhead neni pak vysoka cena.

[...]

Nejvtipnejsi na tom je, ze GC resi problem se spravou pameti, ktery uz zhruba 30 let u C a C++ neexistuje viz http://spinroot.com/static/

a je s podivem, ze firma odmita zaplatit jednu licenci programatorovi, ktery po code freezu projde vysledky staticke analyzy a opravi zbyvajici chyby a misto toho se radsi spokoji s tim, ze kdyz uzivatelska zakladna aplikace poroste linearne, tak naklady na provoz linearne skalovane aplikace porostou rychleji diky skrytemu exponencialnimu skalovani GC rovnez exponencialne.

[...]

ale to bylo odboceni od mobilnich platforem k serverum...

[Radek Miček]

a je s podivem, ze firma odmita zaplatit jednu licenci programatorovi, ktery po code freezu projde vysledky staticke analyzy a opravi zbyvajici chyby

Nic takového neexistuje. Výsledky statické analýzy jsou obecně jen aproximace chování programu.

Uvažte následující kód:

p = NULL
if (složitá podmínka) {
  p = alokuj paměť
}
if (jiná složitá podmínka) {
  dealokuj p
}

Dokázat korektnost znamená ověřit ekvivalenci podmínek.

kdyz uzivatelska zakladna aplikace poroste linearne, tak naklady na provoz linearne skalovane aplikace porostou rychleji diky skrytemu exponencialnimu skalovani GC rovnez exponencialne.

Proč si to myslíte?

[stativ]

Nic takového neexistuje. Výsledky statické analýzy jsou obecně jen aproximace chování programu.

Tak tak. Statická analýza je dobrý pomocník, ale odhalí jen jednoduché chyby.

Uvažte následující kód:
…

No, zrovna tohle je ukázka, jak by se dealokace neměla dělat. Pokud už při psaní člověk v takovém případě nedovede zaručit ekvivalenci podmínek (pak nemá smysl mít ty podmínky rozdílné a by bylo lepší použít nějaký boolean flag) tak by měl testovat na NULL.

[.]

tak zrovna kontrolu podminek coverity dela. takze dalsi pripominka?

[xvasek]

Není to náhodou (v C) nevyčíslitelný problém?

[.]

je, ale nedavno se tu hlasovalo, ze P se bude od tpho hlasovani rovnat NP.

jinak se to resi hrubou silou v radu nekolika tisicovek rekurzi ve vicenasobne navstivenem miste je ta spolehlivost dostatecna.

[xvasek]

No já nechci vypadat jako hnidopich, ale mezi NP a nevyčíslitelnými problémy je (nebo se zdá být, jestli nám to někdo časem "nezkolabuje" ) pořád ještě docela dost tříd.

[little.owl]

Prd ho. Pokud mate tool, ktery v teto oblasti exceluje, sem s nim, za tyhle veci utracime rocne pres £100k, mame to naintegrovane v CI serveru. V praxi to odhali jen trivialni chyby, zejmena pokud se jedna multithreaded aplikaci bezici na vice jadrech.

[.]

faktem je, ze IT se 25 let vyvijelo s pocitem, ze vykon bude kazdym rokem pribyvat a na elektrickou energii netreba brat ohledy. laptopy ten trend nedokazaly zvratit. ale ultramobility a soucasne propady konzumniho IT jsou docela silny argument pro to, aby se tech 25 let vyvoje zrevidovalo a selektivne vykopalo na odpovidajici platformu v ramci konkurencniho boje.

[stativ]

Aneb před dvaceti lety běžel nativní wolfenstein plynule na 486, verze v HTML5 potřebuje nadupaný počítač.

[.]

tak ono jde taky o to, ze java je tu s nami uz 17 let a za tech 17 let jeste nikdo neprisel s pouzitelnym GC. pise rok 2013 a stale dokola se resi neexistence nelagujiciho, nezastavujiciho GC co za nepriznivych podminek jen nemaskuje absenci "stop world" faktem, ze vytesni aplikaci do 0,00000000...% procesoroveho casu. viz 2012 vedecka publikace videnske univerzity a 2013 treba postesky provozovatelu minecraft serveru.

[Radek Miček]

Souhlasím.

Na druhou stranu i ruční uvolňování paměti může vést k lagům.

[stativ]

Samozřejmě, ale jsou to očekávané lagy, a ne jako u GC kde mi to začne lagovat a já netuším proč. A ještě k tomu s mizernou možností problém reprodukovat.

[pavec]

Problem Javy zdaleka neni jen GC v JVM, ale Java samotna ;)

[mich]

Například...? (Pokud to byl jen flamebait a argumenty nejsou, tak otázku samozřejmě ignoruj)

[Radek Miček]

Třeba null, dědičnost (fragile base class), uzavřené třídy (k typu nejde doimplementovat rozhraní), složitost (bridge metody + overloading, podtypový polymorfismus), anti-paralelní.

[pavec]

Tak trochu, proto ten smajlik na konci. Ale spousta veci kvuli kterym ji nesnasnim nejen ja by se nasla jako tezkopadnost, ukecanost, pametova nenazranost, platformova prenositelnost jen na papire, JIT dobre optimalizuje jen smycky se statickymi parametry atd. Pokud uz nekdo delal v "modernim" jazyce jako Python, Ruby nebo Haskell tak vracet se k jave je hrozne frustrujici - kdyz stejny problem resite dvakrat tak dlouho na petinasobku SLOC :( Aneb "Why Python (Haskell) makes you a worse programmer". To uz je fakt lepsi C++ a vhodne zvolene knihovny jako Boost apod.

[pavec]

Jeste pridam problemy s aktualnim vlastnikem patentu a vyvojare hlavni implementace - Oracle. A jak "skvele" se stara a opravuje chyby ..

[gtz]

Časová značka: 14.7.2013 11:38:55
Chyba: r2d2b2g: ###!!! ABORT: X_GLXCreatePixmap: BadMatch (invalid parameter attributes); 3 requests ago: file /home/myk/Mozilla/central/toolkit/xre/nsX11ErrorHandler.cpp, line 157
###!!! ABORT: X_GLXCreatePixmap: BadMatch (invalid parameter attributes); 3 requests ago: file /home/myk/Mozilla/central/toolkit/xre/nsX11ErrorHandler.cpp, line 157

No ani se to nepodařilo nastartovat ... asi to je nějaký nemocný, nebo to mají nějaký rozbitý ....

myslel jsem, že je chyba někde v GL, aktualizoval jsem i mesu a nic (po aktualizaci se objevilo sice okno B2G, ale po pár vteřinách to šlo pryč). Aktuální FF-22, NVIDIA.