Názory k článku
Chrome pro Windows poprvé v 64 bitech (betaverze)
-
Lael Ophir (neregistrovaný)
Ve Windows máme 64-bitový browser minimálně od MSIE 9. Problém je v tom, že 64-bitový proces neumí pracovat se 32-bitovými toolbary, ActiveX prvky apod. Proto desktopový MSIE běží by default v mixu 64-bit a 32-bit kódu; MSIE pro Metro běží ve 64-bitech.
Důvod proč Chrome přichází se 64-bitovou verzí až teď je celkem jasný: nemá to zvláštní přínos pro uživatele. Rychlost 32-bitového a 64-bitového kódu je prakticky stejná, omezení adresního prostoru aplikace na 2GB nehraje u browseru žádnou roli, a kompatibilita 64-bitového kódu s různými doplňky je špatná.
-
Lael Ophir (neregistrovaný)
Pro Windows hlavně existují miliony 32-bitových aplikací, které celý svět používá. Pro většinu aplikací není 32 bitů omezením, a autoři nějak nevidí důvod je urgentně přepisovat jen proto, aby si mohli zaškrtnout kolonku "64 bitů", bez jakéhokoliv přínosu pro uživatele. A kde 64 bitů přínos má, je dávno přepsáno.
64-bitové Windows budou mít kompatibilitu s 32-bitovými ještě velmi dlouho. Nakonec 32-bitové Windows mají dodnes kompatibilitu s 16-bitovými aplikacemi. Chrání to investice uživatelů i autorů SW.
-
Lael Ophir (neregistrovaný)
Kdyby jen aplikace pro lovce lebek :). V ČR dodnes koupíte 16-bitové účetní programy a další podnikové agendy. Většinu jich sice autoři přepsali pro 32-bitové prostředí, ale ne všechny. A přechod na 64-bitové prostředí je v nedohlednu, protože je to náklad, který zákazníkovi nic nepřinese. K tomu má spousta zákazníků 32-bitový OS.
-
Ondra Satai NekolaZlatý podporovatelTohle na rootovi miluju. "Diskusni" souboj uzivatele, ktery tvrdi, ze vsichni az na Microsoft to delaji blbe, s uzivatelem, ktery tvrdi, ze to vsichni delaji blbe.
-
Karel (neregistrovaný)
Natírání je velmi oblíbená funkce. Vydavatel se proto rozhodl ji podpořit a vylepšit. Od příští verze bude váš prožitek z natírání prohlouben tím, že se vám kapota přes noc vždy přelakuje na původní barvu. A vám tak nic nebude bránit příští den natírat kapotu znovu. Mnoho příjemných chvil strávených natíráním přeje tým autorů.
Konec ironie - jeden z problémů Chrome apod. je chybná interpretace "uživatelé dělají XY". Často to Google pochopí tak, že "uživatele baví dělat XY". A to i v případě, kdy správně je "aby se to vůbec dalo používat, tak uživatelé musí udělat XY". Kupříkladu od dnešního rána jsem už 4x odklikával "Got It" na upozornění Google na to, že na jejich stránkách používají cookies. Kéž by si do nějakého cookie uložili, že jsem tu hlášku už dnes odklikl. No co, prostě asi došli k názoru, že mě baví klikat na "Got it".
-
Lol Phirae (neregistrovaný)
Kupříkladu od dnešního rána jsem už 4x odklikával "Got It" na upozornění Google na to, že na jejich stránkách používají cookies. Kéž by si do nějakého cookie uložili, že jsem tu hlášku už dnes odklikl. No co, prostě asi došli k názoru, že mě baví klikat na "Got it".
Ano. Tak když to ukládání cookies blokuješ, tak nevím, kam by si to asi tak měli uložit.
-
Ondra Satai NekolaZlatý podporovatel
Nebude to tim, ze Chrome pred lety uhodilo v UI hrebicek na hlavicku?
Asi jsem nenarocny uzivatel, mozna jenom nejsem vecne nespokojeny prudic, ale s aktualnim stavem Chrome i FF jsem na Linuxu, OS X i Androidu veskrze spokojeny. At uz je to +- vanilka (par nepostradatelnych blbosti, co by na prstech ruky spocital, hlavne AddBlock+ + Clearly) nebo s pridanym "Vimkovym" ovladanim.
-
Take byste mohl rici, ze pred lety uhodil MS hrebk na hlavicku. Zli jazykove ale rikaji, ze na hlavicku naopak uhozen MS a rozsireni Widli je vysledkem agresivniho a schopneho marketingu a vselijakych podrazu a spinavych praktik, coz vse MS jde mnohem lepe, nez psani OS.
Nevim, jestli jste nenarocny uzivatel, mozna jste jenom flegmatik, na kterem muzou programatori drivi stipat. ;-)
-
Ondra Satai NekolaZlatý podporovatel
Já chápu, že některé lidi štve, že jsou třebas taby jinak, než když tahali kačera a poprvé surfovali. Ale to rozložení, se kterým Chrome prorazil, je prostě o dost lepší.
Spíš nastavím, těch pár věcí, co je potřeba, a nerozčiluju se nad blbostmi. S trochou hygieny při správě tabů to dělá zázraky.
-
Otazka je, jestli s tim rozlozenim Google prorazil proto, ze je nejlepsi nebo proto, ze Chrome se pribaluje uz i k rohlikum, tak jako kdysi IE k Widlim a take diky jinym marketingovym trikum. Spousta lidi pouziva Chrome proto, ze uz se o nem mluvi snad uz i v televiznich serialech a na zasedani parlamentu. Ovsem mluvi se o nem proto, ze ho tolik lidi pouziva nebo ho tolik lidi pouziva proto, ze se o nem furt mluvi?
Jinak to rozlozeni je lepsi cim? Tim, ze ma kulate taby? To je dost malo. Jinak vidim sama negativa. Mizerna prace s taby: taby se smrsknou, az nevidim ani favicon, nasledne prelezou doprava pres ovladaci prvky okna. V Googlu asi maji vsichni displaye formatu 50:1. Ale na normalnim displayi se v tom neda nic najit.
To, ze neni kam nacpat rozsireni, take neni moc rajcovne. Vsechno se to cpe do adresniho radku, coz pri displayi o formatu 50:1 jiste neni problem, ale na notebooku a jeste vice netbooku to problem je. A kam dat rozsireni, ktera stale neco zobrazuji/monitoruji? Status bar Chrome nema, takze smula.
Nemluve o dalsich vyhodach, jako nefunkcnost rady rozsireni, nepouzitelnost rady rozsireni, ktera zobrazuji dialogy nad oknem Chrome a tedy obvykle mimo display... Doposud jsem nenasel ani dostatecne schopnou nahradu za Session Manager, ktery mam ve FF/Palemoonu.
A co pametova a CPU narocnost? Take zadna slava. Budme radi, ze to nezere jak Android SDK.
-
Prohlížeč musí v paměti držet obrovské množství objektů (elementy stránky), ať už v původní podobě (JPEG), připravené (dekomprivovaný JPEG), zpracované (změna měřítka obrázku), vyrenderovanou stránku (bitmapa přes několik obrazovek) a to pro všechny otevřené taby (plus spoustu metadat okolo). To je tak náročné a komplikované, že klasická správa paměti v OS (malloc) se nedá použít a prohlížeč tedy používá svoji vlastní (mezivrstva k malloc). Dělá to hodně programů. Na 32bitové architektuře je ve Windows k dispozici jen 2GB RAM na proces, když odečteme režii procesu, knihovny, zásobník atd., zůstane zhruba 1GB RAM. To je pro prohlížeč extrémně málo, a proto jeho interní správa paměti implementuje též vlastní odkládání na disk (což je další pěkná pakárna a musí to být navíc co nejrychlejší). Ladit takového správce paměti není žádná sranda a dodnes všechny prohlížeče trpí většími či menšími memoryleaky. A ve Windows je to ladění o to horší, že nejenže nemáte zdrojáky systému a jeho základních knihoven, ale nemůžete ani nalezené chyby opravit, což je pro vývojáře úplně nejhorší varianta (a nevíte, kterou chybu Microsoft v příští aktualizaci opraví nebo ještě více pomrví). Proto se nikomu dlouho nechtělo do tohodle bahna šlápnout a ráchat se v něm (a už se to dlouho testuje a ještě dlouho bude). Na 64bitovém systému je vše jednodušší, protože paměťového prostoru je mnohem více, než mizerné 1GB. Otázka však zní, zda přechod na 64bitů něco přinese uživateli v tom smyslu, že to novější řešení bude sice jednodušší (a laditelnější), ale bude zase plné nových chyb, které jsou už u stávajícího 32bitového řešení vychytané. Samozřejmě do té paměti se musí dle situace vejít i pluginy, JavaScriptový kód, jeho datové struktury atd.
-
Lael Ophir (neregistrovaný)
Vývoj 32-bitové a 64-bitové verze samozřejmě může zvládat stejný počet programátorů. Pokud je kód rozumně čistý, prostě ho přeložíte pro 32-bit a 64-bit cílovou platformu. Odlišností pro 32-bit a 62-bit build bývá někde mezi žádnou a několika málo.
Testování samozřejmě musí proběhnout dvakrát, ale velká spousta testů proběhne automaticky bez jediného zásahu operátora.Ono se do 64-bit verze autorům SW nechce hlavně proto, že je to práce navíc (většinou jde o úklid příšerností napáchaných kdysi v historii projektu), uživatelům to zpravidla nic nepřináší, a je pak nutné testovat a podporovat dvě separátní verze, protože řada uživatelů má dosud 32-bitový OS.
-
Karel (neregistrovaný)
Co jsem migroval programy z 32bit na 64bit (C a C++), tak rozdíly v programu jako takovém nebyly vůbec žádné. Veškeré nutné změny se točily kolem použití datových typů s předpokladem o velikosti. Dokud je na všech místech stejný typ, tak rekompilace funguje. Legrace to je až když se přetypovává (vstup int, výstup int32), nebo se použije struktura, do které se mapuje binární soubor. Každopádně tohle všechno jsou chyby programátora. Aplikaci, kde by se musela opravovat logika kvůli 64bitům, jsem ještě nepotkal. Vyvíjet verzi, která jde zkompilovat na 32bit i 64bit, neznamená vyvíjet verze dvě. Stačí jen jeden tým, akorát musí chápat datové typy. Kolikrát stačí rychlý úvod do <inttypes.h> a rázem nepotřebujete řešit 32 vs 64.
Ale musím přiznat, že funguje efekt "padajícícho h...." Pokud použijete cizí knihovnu, která na 64bitech nefunguje, tak máte problém.
-
Lael Ophir (neregistrovaný)
DOM je binární struktura, která není nijak závratně paměťově náročná. Browser samozřejmě nedrží celou vyrendrovanou stránku. V primitivní implementaci její kusy skončí v paměti grafické karty, přičemž každá fullHD obrazovka má pouhých 8MB. V pokročilé implementaci v paměti grafické karty skončí resources (vyrastrované obrázky, grafické prvky, mezi aplikacemi sdílené glyphy fontu), a při zobrazení kusu stránky se jen grafické kartě řekne, jaké resources má kam naházet. Originální obrázky si po vyrastrování můžete nechat na FS v cache, nikdo vás nenutí je skladovat v paměti.
32-bitové procesy na 62-bitovém OS (o čemž byla řeč) mají 4GB adresní prostor, pokud má image nastavený flag IMAGE_FILE_LARGE_ADDRESS_AWARE. Navíc vás nikdo nenutí používat jediný proces. Vzhledem ke stabilitě různých pluginů se naopak vyplatí použít worker procesy, aby v případě problému na jedné stránce přežil obsah ostatních stránek.
Aplikace se píšou podle dokumentace API, nikoliv podle vlastností API nalezených metodami pokus-omyl nebo skouknu-zdroják. Cokoliv není popsané v dokumentaci, je nedokumentovaná vlastnost, a v příštím buildu to může být úplně jinak.
Pokud ladíte vlastní správu paměti, nepotřebujete k tomu zdrojáky systémových knihoven. Nalezené bugy samozřejmě můžete hlásit MS. Postup je stejný jako u open source: nahlásíte bug (u open source klidně i s opravou), a pak čekáte, jestli se to dostane do příštího produktivního buildu, což vám ani v jednom případě nikdo nezaručí. Plus vám nikdo nezaručí, že se ten nový build dostane k vašim uživatelům. Rozdíl je v tom, že knihovny od MS jsou dlouhodobě používané a stabilní, takže zřejmě nebudete pokusný králík, kterému se s každým buildem mění vlastnosti knihovny pod rukama.
