Názory k článku Firefox OS: příslib kvalitních levných smartphonů

Tak on TELEFON tak nějak z principu k nějaké síti musí být připojený, ne? :-)

Copak foťáku, ale závislost telefonu na spojení je fakt nepředstavitelné zlo :-D
A pomalost se řeší přes cache, tohle se už i redmondští odchovanci QBasicu naučili používat.
Že moje fotky zůstanou komusi na serveru? To je fakt problém, zvlášť když všechno co si přes IE stáhnete za chvíli po vás stáhne i bot ze Seattle. Proti M$ jsou v Google žabaři.

Pár malých tajemství: telefony mají foťák, a ne všude máte datové spojení (například v přírodě, na roamingu apod).
Cache vám nepomůže. Jak bude server pracovat s fotkou, kterou jste vyfotil? A jak bude asi cachovat to co server spočítal? A proč to celé řešit takhle debilně, když telefon technicky může odstranit červené oči, upravit kontrast a barvy lokálně? Jen aby ten telefon mohl běžet na Firefox OS?
URL discovery je jedna věc, nechávat někde svoje fotky je jiná věc.

Jenže ten Firefox OS těžko poběží na serveru, takže si těch pár tisícovek vynásobte počtem uživatelů, pak si ty náklady na optimalizaci jejich počtem vydělte, a porovnejte to znovu...

Důvodem pro používání Javy nebo C# v OS je hlavně bezpečnost a spolehlivost. Kód píšou lidé, a vyrobit chybu v C/C++ je nesmírně snadné. Naopak managed code řadu chyb vůbec nedovolí, například buffer overflow nebo přístup za hranice pole. K tomu lze managed code formálně verifikovat, a například dokázat, že v něm nedochází k ovlivnění jiného než daného úseku paměti, že nedojde k deadlocku apod.
Samozřejmě ohledně výkonu má managed code svou cenu. Nicméně jsou techniky, které jsou naopak výrazně rychlejší než u klasického kódu (software-isolated processes místo klasických procesů). Otázkou je, jaká ztráta výkonu je akceptovatelná, a jestli ji dokážou vynahradit získané vlastnosti (bezpečnost, stabilita). Vždyť kód psaný v assembleru bývá také rychlejší než ten psaný v C/C++, a přesto se v ASM moc nepíše.

"Důvodem pro používání Javy nebo C# v OS je hlavně bezpečnost a spolehlivost."

Tak to je fór minimálně týdne, ne-li měsíce :-D

Když netušíte o čem je řeč, může vám to připadat i vtipné. Trochu mi ale uniká, proč svou neznalost dáváte tak okatě na odiv.

Lael olphir je sice miestny komik, ale v tomto ma pravdu, v jave sa chyby tazsie vyrabaju a lahsie dohladavaju.

A co chyby které jsou v samotné Javě? ;-)

Take chyby su notoricky zname, je ich zopar a daju sa vyhladat na forach.

http://computerworld.cz/securityworld/kratce-po-aktualizaci-javy-objevena-kriticka-chyba-48745

Měsíce neopravená kritická díra, pak záplata která v podstatě nic neopravila a další kritická díra... Jo, tomu se dneska říká bezpečnost. Bodejť by ty chyby nebyly notiricky známé, když se o nich pořád dokola píše a nic se neděje ;-)

To se všem týká Javy coby platformy, nikoliv psaní programů v Javě. Jeden by čekal, že to dokážete rozlišit.

Takže pro psaní rádoby bezpečnějších aplikací použijete platformu děravou jak americký protiraketový deštník.
Neboli bezpečnost ve stylu "nikomu neříkejte že jeden klíč je pod rohožkou a druhý v zeleném květináči", za půl roku je stejně přehodíme pod jiný roh rohožky a do jiného květináče...
No ale co jiného čekat od scvrklého mozku widlousáka, který podobné "běžné vlastnosti" už ani nevnímá :-D

Nespletl jste si server? Na podobny styl diskuzi tady zatim nastesti vetsina uzivatelu neni zvykla. Pokud jste odkojen na diskuznich forech Zive a spol, tak bych doporucoval navrat do puvodniho lokalu. Nebo pripadne mene urazek a vice slusneho chovani zde prosim.

Děravá je implementace Javy od Sunu, nikoliv Java jako jazyk. Technicky lze v managed prostředí napsat celý OS, například Singularity nebo JX. Pro takový OS potom můžete psát aplikace v .NETu nebo Javě. Výhodou je vysoká bezpečnost i spolehlivost. Taková implementace je samozřejmě v některých aspektech pomalejší než klasický OS, ale v některé věci jsou zase daleko rychlejší (třeba model procesů).
http://en.wikipedia.org/wiki/JX_(operating_system)
http://en.wikipedia.org/wiki/Singularity_(operating_system)

Jinak se mi váš příspěvek zdá věcně mimo, a k tomu zbytečně urážlivý. Zkuste psát k věci a s trochou úcty k adresátům sdělení.

Tak sorry, měl to být spíš zavirovaný mozek.
Technicky je možné napsat celý OS v i Pascalu, BASICu, nebo Brainfucku. Každý z nich by měl své výhody.
Spíš by mě zajímalo, který implementace Javy nebo .NETu není děravá!
Mimochodem, IE neumí nahrazovat závorky v adrese, aby fungovaly ty vaše odkazy? Mě to dost starý FF dělá automaticky.
Pro srovnání s těmi vyšimi pohádkovými systémy si zkuste nastudovat tohle: http://cs.wikipedia.org/wiki/Miraculix

No to je ten trik. Managed jazyky lze překládat i přímo do strojáku, takže virtuální stroj a Framework Class Library (zjednodušeně .NET Framework nebo JRE) vůbec nepotřebujete. Při psaní kernelu OS a driverů by to ani nebylo praktické.

MSIE nenahrazuje závorky v URL, protože podle RFC 1738 k tomu není důvod. To akorát autoři tohoto webu si chybně myslí, že závorka nemůže být součástí URL.

Co konkrétně si mám nastudovat na Miraculixu? Vypadá to na opuštěný studentský projekt, který se svého času podařilo někomu dotlačit až k jednoduchému process modelu a triviálnímu GUI. Podobných projektů vznikají na školách spousty. Jestli se hodně nudíte, napište si také vlastní OS. A můžete si k tomu přibrat stavbu procesoru a počítače. Kolegové vám to připravili jako online kurz.
http://www.ted.com/talks/shimon_schocken_the_self_organizing_computer_course.html
http://www.nand2tetris.org/course.php

BTW celkem pobaví ty komentáře k Miraculixu:
'your file manager could use a scrollbar... and it freezes on vpc with the filemanager if you use arrow buttons and hit down a lot, past the screen it will start going real slow and the mouse will quit updating'
http://forum.osdev.org/viewtopic.php?f=2&t=656

Nejen tohoto webu, je to zcela běžná vlastnost všech redakčních systémů které znám. A o "vlastnostech" by v Redmondu měli vědět své ;-)
I BASIC jde překládat do strojáku, ale ztratí se při tom řada jeho výhod.
Zajímavé na Miraculixu je třeba to, že je to celkem funkční a použitelné, a přitom je to celé menší než samotný widlousí bootloader...
Vlastní OS jsem napsal, ze znechucení nad chybami Windoze, ale pak jsem přešel na Linux. Má větší podporu.
Vlastní procesor jsem také navrhnul, jestli budu mít někdy chuť pospájet pár kilo TTL hradel, tak si ho i postavím. Zatím běhá v simulátoru víc než uspokojivě, takže pochybuji že by mi v tomhle ohledu ten kurz dal něco nového.

V tom případě to redakční systémy dělají špatně, protože se nedrží RFC, které jsem uvedl.

V tomto případě překlad do strojáku právě nevede ke ztrátě těch zajímavých vlastností.

Miraculix že je celkem funkční a použitelný? O tom mám (i na základě těch komentářů) dost pochybností. Nicméně například Windows 95 byly také malé, po očesání o multimédie ještě menší, a na novějším HW zatraceně rychlé. Co to o nich říká? Asi vůbec nic.

Na autora vlastního OS a procesoru jste dokázal v minulosti napsat dost velké koniny, takže vám to moc nevěřím.

W95 měl po očesání sto kilobajtů? To neměl ani W1, který navíc běžel na DOSu!

O koninách bych na vašem místě vůbec nemluvil.

Kolika RFC se nedržel IE, když se pokoušel M$ prosadit vlastní verzi HTML? Zajímavé bylo, že ty byly jiné pro IE a jiné pro FrontPage, zvlášť že některé jím vytvořené stránky v IE vyšly úplně blbě, na rozdíl od jiných prohlížečů...

Nemluvil jsem o 100kB, říkal jsem "malé". Ono "malé" je relativní. Zvlášť dnes, když máme TB disky a GB paměti v každém telefonu, a do těch 100kB se nevejde ani pozadí desktopu, natož škálovatelný font. Nacpat do 100kB implementaci FAT, pár funkcí na kreslení po obrazovce a zárodek shellu je ten nejmenší problém. Pořád mi ale není jasné, proč by takový systém měl být něčím zajímavý.

Pokud jsem si všiml, tak se v době prosazování MSIE nedržel specifikací nikdo, a W3C to korunovalo přijímáním doporučení, které byly v rozporu s faktickým stavem v nejrozšířenějších browserech (vizte třeba box model). Díky tomu se web rozbil. Dnes to není o moc lepší, když se na netu používá řada tagů s vendor prefixy. Ale mluvil jste původně o tom, že MSIE neescapuje závorky. Neescapuje je správně, a redakční systém je špatně. To jsou prostá fakta.

Proč by měl být zajímavý? Že navzdory redmondskému Pramini je to možné. A dokonce to není zase tak obtížné, když se kašle na gigabajtové kraviny typu .NET.

Web se rozbil právě kvůli těm "nejrozšířenějším" prohlížečům, všechny oba byly od M$ a kvůli nim se musely dělat weby, které nešly zobrazit v konkurenčních prohlížečích. Ale tenhle postup známe, viz Lotus a DOS 2, žejo ;-) Takže naštěstí ve W3C tenhle korporátní fašismus včas odhalili a zarazili.

Ono nejde ani tak o nějaké RFC, jako třeba o diakritiku v odkazech, protože díky omezenosti widláckých znakových sad vám odkaz uložený v české verzi nemusí jít otevřít v německé. Inteligentní systémy už dávno přešly na přenositelné UTF-8, dementi si opakovaně nabíjejí nenažraná ústa v UTF-16 na ARMu s jinou endianitou.

Co je možné? Napsat zárodek systému bez threadingu, bezpečnosti, grafických služeb včetně škálování fontů, knihovny driverů, síťování atd. s malým kusem kódu? Jistě, to je možné. A k čemu to má jako být dobré?

Přečtěte si něco o W3C a box modelu. W3C rozbilo web. A koukněte se na HTML5. Sice ještě nevyšlo, ale už je web plný stránek založených na nefinálních verzích a vendor prefixech. To je interoperabilita jak víno. Ale W3C se při tom všem špatném musí nechat obrovská efektivita a rychlost. Například od CSS 2 k CSS 2.1 se dostali za pouhých 13 let :D

O RFC v tomto případě samozřejmě šlo. MSIE posílá URL podle RFC. Nicméně zobrazovat uživateli v URL boxu http://www.xn--hkyrky-ptac70bc.cz místo http://www.háčkyčárky.cz/ nemá moc smysl.
Ukládání jakých odkazů? URL do textového souboru? Uložte si ten soubor v Unicode. Na ARMu si s UTF-16 nenabijete ústa, protože Windows píšou do souborů Byte Order Mark. UTF-8 je berlička pro unixy, které mají tradičně API s 8-bitovými stringy, a díky mrtvolnosti celé platformy nic lepšího nepřijde. Celkem zábavná je absence Byte Order Mark v textových souborech, díky které nezjistíte, jestli je text v 8859-x nebo UTF-8. No co, tak budeme prostě předokládat, že je to UTF-8 :). A zábavné jsou i problémy ve stringových funkcích libc. Například hledání znaku (char) ve stringu (string) nefunguje, protože ten char nemůže obsahovat znak v UTF-8. No co, tak změníme dokumentaci z hledání znaku na hladání bytu :D. A ještě zábavnější jsou nadstavby. Například Qt/KDE používá UTF-16 (QChar, QString). Když načtete seznam souborů z adresáře, předpokládá se že jde UTF-8. Když jméno souboru není v UTF-8, nastane chyba konverze :/. Z výsledného listu souborů si uživatel jeden vybere, jeho jméno se převede zpět do UTF-8, a aplikace ho otevře. V efektivitě je holt síla :D