Calais, Rouen, Honfleur, Audresselles, Wissant

Asking why your offline application cache manifest doesn’t work in Firefox and have no way to figure out?  Not any more.  Now you can look in to the Error Console (the old fashion one) you open with Shift-Ctrl-J and check for logs I’ve recently added in bug 807501.  All these logs are under the Messages section.  When an update is internally invoked, there is always at least one message related to the processed cache manifest.

When an error during cache update occurs you can now see the reason:

When all goes well, i.e. Firefox has downloaded or updated your offline cache, you get:

• Offline cache update done, URL=http://example.com/cache.manifest

And when you are sure you’ve changed your manifest to a new version, but offline cache doesn’t update in Firefox, you can check for the following line:

• Offline cache doesn't need to update, URL=http://example.com/cache.manifest

This means the manifest hasn’t changed since the last time or that you didn’t serve it with Cache-control: no-cache header.

Cesta trvala cca 20 dní na přelomu srpna a září s několika zastávkami a zajížďkami.  Hrubé užitečné informace z cesty by se dali shrnout takhle:

• dojet z Prahy až do Norska se dá za dva dny s jedním řidičem, stejně i zpět
• většina lidí mluví anglicky a je ochotná angličtinu použít ; jen v menších městech to může být trochu krkolomné se domluvit
• na hranicích (my jsme přijely ze Švédska po E6) vás budou kontrolovat, budete si trochu připadat jako byste přijížděli z Ruska, ale že vás nepustí, pravděpodobně nehrozí
• Norsko je extrémně drahé, ceny jsou prakticky za vše až 6x vyšší než u nás, mimo benzínu, levné věci se musí hledat
• velmi se vyplatí rezervovat hotely dva nebo spíš i tři dny dopředu, jinak na vás zbudou ty drahé, nebo ošklivé ; bohužel, dost to kazí spontánnost
• hotely jsou obecně velmi drahé a nepříliš kvalitní
• dobrý průvodce je od Lonely Planet
• není pravda že se v Norsku vůbec nekrade, ve velkých městech je kriminalita, za kterou většinou stojí cizinci z bývalého východního bloku ; svědčí o tom i to, že např v Oslo je každá budova zabezpečena nějakou security službou
• Norové jsou chladnější ale milí lidé, vždy pomohou
• ve všední dny po 21h, v sobotu po 18h a v neděli vůbec nekoupíte v žádném obchodě alkohol, pouze v restauraci ; do toho se počítá i nealko pivo!
• nejlepší pivo: Seidel
• velmi často je u cest WC a to většinou i splachovací a vyhřívané
• Norské cesty jsou skvělé, řidiči nepředjíždí, když jedete pomaleji ; stejně tak i vy byste moc neměli, není kam spěchat, stejně se všichni kocháte přírodou
• na kruhových objezdech mají přednost tramvaje, na rozdíl od nás
• už před kruhovým objezdem se bliká podle toho, který výjezd chete použít (takže klidně doleva, když třetí výjezd) a až při výjedu z kruháče se bliká normálně doprava
• na nájezdech na dálnici se zipuje (značka zbíhající se červené šipky), ale je to podle situace
• benzín, který se u nás označuje jako Special 95 je v Norsku má označení “Super Blyfri”
• je velmi výhodné a pohodlné předplatit si mýtné přes AutoPASS ; i přes nějaké počáteční chyby ohledně stažení zálohy z karty to fungovalo, před pár dny mi přišlo vyúčtování
• dobré obchody jsou KIWI a SPAR, najdete je skoro všude, 7-eleven je jen základní a nezdravý a kompletně bez alkoholu

Úvodní relaxace kousek od Mnichova

Na tři dny jsme nejprve zajeli ke kamarádce kousek od Mnichova nabrat síly před cestou a trochu ji doplánovat.  Uvádím spíš, abyste rozuměli, proč cesta trvala déle.

První den, Mnichov – Dessau (DE)

Vyjeli jsme v klidu v dopoledních hodinách.  Cíl byl Rostock, ale my zastavovali na přespání v Dessau, neb času bylo dost.

Dessau je obrazem východního Německa.  Přijíždíme večer, nikde žádné motely.  Ubytováváme se v City Pension Dessau – Rosslau za 55 EUR, který se nám zdá drahý (ještě netušíme, co nás čeká v Norsku) ; snídaně byla dobrá, pokoj obří.  Ve městě jsou všude paneláky, připadáte si jak v Praze na jižním městě.  S vyjímkou, že uprostřed sídliště je např. kostel.  Lidé tam mají zvláštní sport: všichni neustále čumí z oken na ulici a hlavně na vás.  Pivo dobré, inu Deutchland.

Druhý den, Dessau (DE) – Plau (DE) – Rostock (DE)

Cestu jsem naplánoval tak, že z Rostoku pojedeme nočním trajektem do Trelleborgu ve Švédsku – nepříliš šťastná volba.  Přes den tak byl čas se ještě trochu podívat po východním Německu.

Plau je malé velmi hezké město.  Pivo velmi dobré, poseděli jsme v dobré restauraci u jezera, kde kotvila spousta jachet.  Nejlepší ovšem byla Wasserturm, stará vodárenská věž.

Rostock.  Industriální přístavní nehezké město, najíst se dá jen v “italské” fast-food “pizzerii”.  Za vjezd i výjezd do a z města se platí vždy 3,4 EUR!

Stání ve frontě na nalodění trvalo velmi dlouho, nemá smysl se tam harcovat už o hodinu dříve.  Fotky nemám, dostavila se únava a v podstatě nebylo až tak moc co fotit – zleva kamiony, zprava prázdné lajny.

Noční trajekt TT-line měl trvat 7 hodin, což se zdálo jako hodně času na přespání.  Odjezd 23:00, příjezd 6:00.  Jenomže, v tomhle čase bylo i nalodění, snídaně a vylodění.  To jest, v 6:00 už nás loď měla vyplivnout na břeh Švédska.  Na konec tedy moc času na spánek nebylo.  Kajuta byla malá ale se vším, co bylo potřeba.  Jen v ní byla dost zima.  Palanda pro dva, funkční koupelna s erárním mýdlem.  Bylo slyšet sousedy, ale ne tak, aby budily.

Jediná fotka z okýnka kajuty.

Třetí den, Trelleborg (SE) – Göteborg (SE)

Ráno se podařilo vstát celkem dobře, ale 100% vyspání to nebylo.  Snídaně v 5:00 byla dobrá na horní palubě.  Všichni okolo vypadali, jako kdyby špatně spaly nebo co…  Pak do auta a ven.  Švédské ráno je studené a chladné.  Ale už je to Skandinávie, hurá!  Máme dočasný pocit štěstí.  Nápad dospat někde v hotelu rychle padá.

Jedeme po dálnici směrem na sever.  Švédové řídí trochu jako prasata.  Limit 110 se moc nedodržuje, všichni jedou přes 120.  Poprvé se setkávám se značkou zbíhající se šipky u nájezdů.  Později mi došlo, že oni prostě zipují.

Někdy po osmé se chce odpočinout.  Jedeme do města Landskrona hned u moře.  Chceme se prospat.  Vybrali jsme pláž za golfovým hřištěm.  Nikde nikdo, zvuk a hlavně vůně moře, vánek, no vlastně spíš vítr.  Spát se sice nepovedlo ale refresh dobrý.  Za hodinu jdeme zkoumat okolí.  Na dvou fotkách je vidět, jak je země kulatá.

Stavíme v centru, kde se za parkování platí.  Parkovací automat bere karty.  Funguje to tak, že se do něj karta (švédsky “kort”) vloží a pak hned vyndá.  Na display se objeví (švédsky), že probíhá kontrola karty.  Pak se volí čas stání.  Vyleze lístek.  Hotovo.  Cena 12 SEK/hod.  Během téhle operace se ptám jednoho místního pána jak na to, anglicky.  Uměl dokonale, až se raději ptám, jestli není cizinec.  Není!

Švédi umí anglicky perfektně.  Ale navzdory tomu, nikde není jediný napis v angličtině nebo volba jazyka třeba na onom parkovacím automatu.  Švédi vypadají spokojeně, vitálně, město působí klidně a hezky.

Restaurace Ticho de Brahe.   Dal jsem si lehké pivo Pripps Bla s asi 2.0% alkoholu.  Chutná moc dobře a dá se po něm řídit.  Proč to v Čechách nikdo nedělá…  Radler nepovažuju za pivo…  Cena za dobré jídlo je vyšší, ale ne až tak.

Jedeme dál, ale absence spánku se dostavuje znovu.  Takže zastavujeme někde v lese (naprosto netuším kde přesně.)  Ale spát v autě, to prostě nejde tak dobře.  Takže zas jenom spíš refresh.

Navečer dojíždíme do Göteborgu.  Ježdění po městě je šílené, zjevně jsme přijely do největší špičky.  Ovšem na rozdíl od Prahy, tady to jede.  A to hodně!  Větší mumraj sem asi nezažil.  Spousta aut a k tomu různé nadjezdy, podjezdy, vedlejezdy, kruhové objezdy skryté pod dálnicí, hrůza…  Navigace měla co dělat, aby nevybouchla.  Chvílema byla úplně mimo, ale vůbec ji to nemám za zlé.  Já byl mimo taky.  Navíc řidiči okolo se chovali opravdu jako totální prasata, asi taky proto, že viděli cizí značku.

Našli jsme na asi druhý pokus hotel.  Hotel IBIS na lodi, silně připomínal pražský Albatros.  Hledal jsem podle ceny, a byl cca nejlevnější.  V přepočtu 1225 SEK (3600 CZK) za mini pokoj se zaprášenou podlahou.  Fotka není, tak širokoúhlý objektiv nemám, abych tu krabici na boty zvěčnil.  Auto stálo před hotelem na placeném parkovišti.  V přepočtu za asi 100Kč.  Automat na karty, ale tentokrát se tam karta musí nechat.

Večer jdeme na jídlo, je fakt zima.  Našel jsem Viking Bar nedaleko hotelu.  Bar byl na palubě plachetnice.  Plachetnice byla i hotel.  Hotel s podobnou cenou jako IBIS.  Jen pokoje prý byly lepší.  Atmosféra lodi byla super, křivé podlahy, všude dřevo, lana, obrázky atd.  K jídlu výborný west coast taipas a super lokální pivo.  Doporučuju jako hotel i restauraci.  A IBIS samozřejmě ne.  Fotek z Viking Baru bohužel moc nemám.

Čtvrtý den, Göteborg (SE) – Oslo (NO)

Dopoledne jedeme.  Proplést se ještě naposledy centrem Göteborgu a ven.  Cesta je relativně nudná, až k severu se postupně krajina začíná kopcovatět.  Už tuším Norsko.  Zastavujeme ještě před hranicemi na kafe.  Vzduch je krásně čistý, super počasí, ani zima ani vedro.

Konečně Norsko!

Na hranicích je doprava stažená mimo dálnici do jednoho pruhu na celnici.  Přijíždí spousta Norů, Švédů …a mezi nimi my.  Unuděná celnice už zcela automaticky odmávává rukou ve smyslu “jeďte, jeďte…”, už už i na nás.  V tom zmerčí českou SPZ.  A hned ke kraji a “kam přesně všude jedete, na jak dlouho, umíte norsky, máte rezervace v hotelích, máte kontakt na kamaráda za kterým jedete, budete tu pracovat? Takže dovolená… OK.  Nějaký alkohol nebo cigarety?” Řek jsem, že ne, tak vrátila občanky a jelo se.  První setkání s Norskem, a ne zrovna příjemné…

Kousek už je Oslo, první plánovaná zastávka.  Nastavil jsem navigaci někam do centra, kousek od Botanické zahrady s parkem.  Hezký začátek to měl být.  Navigace vedla dobře, až najednou přímo do betonové zábrany.  I přes to, že jsem měl naprosto aktuální mapy, navigace nepočítala s kompletním rozkopáním města na kousky.  Rekonstruovaly a opravovaly se snad všechny silnice kam jsme chtěli jet.  Docela horor městem prokličkovat.  Ale nakonec se podařilo, stojíme na parkovišti kousek od parku.

Jdeme pěšky skrz park botanické zahrady a máme hlad.  Až dál jsme našli pěknou pákistánskou restauraci Punjabi Masala.  Dal jsem si jehněčí birjany, pálilo, ale bylo naprosto vynikající.  Průvodce nelhal – když chcete jít na jídlo, jděte do mezinárodní restaurace.  Zpátky jdeme postranními uličkami, jsou daleko hezčí, než hlavní třídy.  Odpoledne pak pivko kdesi v baru.

Padl večer, čas na hotel.  Netušíc jak je Oslo, resp. jeho centrum, které nás zajímalo, malé, hledali jsme hotel podle údajů v průvodci a hlavně podle mapy někde uprostřed.  Rozhodl jsem se osobně se na hotel nejprve podívat, než udělám rezervaci např. přes booking.com.  Inu, chyba.  Oslo nebylo rozkopáno jen po okraji, ale i v centru.  Pension Cochs byl plný, Ellingsens, který vede stará rázná babička, měl zas jen společnou koupelnu.  Pak začalo tak brutálně pršet, že sem neslyšel motor auta a vidět taky skoro nic nebylo, kapky jak kamení.  Další pensiony nebo hotely už si moc nepamatuju, ale byl to docela stres, “vyhrál” hotel Anker.  Měl vlastní kryté parkoviště za nějaký poplatek.  Vcelku mi v ten moment bylo jedno za kolik.  Cena za pokoj ho stejně silně převyšovala, tehdá jsem si ještě myslel, že je extrémně drahý.  Hotel byl zjevně postaven v osmdesátých letech.  Na pokoji pidi postel, jako že pro dva.  No, moc nedoporučuju.  Večer na baru v hotelu jedno pivo, nic moc.  První den v Norsku se nepovedl podle představ.  Usnul jsem jako dřevo.

Pátý den, Oslo

Hned ráno rezervuju penzion Cochs.  Mají pokoj!  Jsem happy

Po standardní snídani jsme naházeli věci do auta a začali se sunout k pensionu.  Podařilo se mi zadarmo zaparkovat u Uranienborgparken.  Jdeme do města, cíl zatím vesměs žádný, prostě jen tak.  Na oběd jdeme do “Le Bouchon“.  Tatarák dobrý, jinak než u nás.  Není kečup, ale zas hodně kyselých okurek. K tomu Heineken.

Věci dáváme do hotelu.  Pokoj a vlastně celý pension je velmi pěkný, skutečně doporučuju.  Cena také nebyla tak špatná (780 NOK).  Chceme se podívat na Operu, ta jediná se zdá po ruce.  Oslo je malé, ale v tenhle moment to ještě nevím.  Nasedáme do tramvaje a já naivně ignoruji poznámku v průvodci, že koupě lístků v dopravním prostředku bude s přirážkou.  Dva lístky na dvě stanice stály 340 CZK.  Ridiculous.

Muž na poslední fotografii pravděpodobně jen protestoval proti prohibici.  Na rozdíl od Prahy, lidé kolem ho neignorovali.  Dokonce se snažili pomoct.  Jen někdo už věděl, v jakém stavu dotyčný je a tak pomáhající zastavil se slovy asi jako “jenom chlastal”.

Oslo Opera House.  Zvenku rozhodně zajímavá stavba.  Spousta lidí, ale rozhlehlost střechy to krásně setřela.  Prostor, rackové, vzduch, voda.  Vnitřek ale nebyl nijak úchvatný, rozhodně ne wow.  Prohlídku jsme neabsolvovali, byla v jiný čas.  Zato jsme si naivně dali dvě piva Hansa.  Cena 475 CZK.  Ridiculous 2.  V ten moment my došlo, že si musím fakt dávat bacha.  Pivo jsme vychrupli, toaletky v opeře pak vážně luxus.  Celkový dojem kazí rozestavěné ulice.

Jdeme zpět do města, směrem k Royal Palace.  V přístavu v zátoce Pipervika narážime na Bollywood festival.  Obrovský živo a energie!  Spousta lidí, hudby a nejrůznějšího indického jídla (to je moje.)  Mango Lasi (koktejl) a Kirilly (pokud si pamatuju, jehněčí).  Lidi jsou veselí a když je fotím, usmívají se, všichni.  Je tam lidí jak na United Islands v Praze, ale atmosféra je hašišová se spoustou rozmanitosti.  Necítíte se jako mezi bandou ožralců, ale příjemně.  Chcete tam být.  Fotek moc není, moc cvakat nešlo.

Hodně zážitků, přichází potřeba zpomalit.  Je sobota večer, takže pivo už nekoupím, ani nealko.  Ridiculous 3.  Tak jdeme na kafe někde na ulici Stranden.  Pak dál k Royal Palace, který je hezký, ale trochu nudný.  Cestou do hotelu ale objevím, něco o čem se v průvodcích nepíše: vchod do metra Nationaltheatret stasjon.  Vlezeme dovnitř, chci se prostě podívat na metro.  Vejdou nějací lidé a jeden houkne do prostoru.  V ten moment mi to dojde.  Není to obyčejná stanice.  Kruhový strop je jako schody.  A vzdálenosti a výška schodů není náhodná.  Pak si všimnu, že uprostřed je kruh s nápisem “AKUSTISK SKULPTUR“.  Tak si tam stoupnu a zkusím vydat zvuk.  Brutální reverb!  Ale ne nějaký náhodný, krásně hudební.  Když si stoupnete trochu mimo střed, tak se reverb změní ve velmi zajímavé echo.  A mění se podle toho, kde zrovna stojíte.  No blbli jsme tam vážně chvíli

Cestou do hotelu ještě míjíme hospodu Bjørungs.  Takhle večer je vidět všechna ta barevná světla, strop a…  škoda že jsem to nevyfotil alespoň zvenku.  Jít dovnitř už ale přes únavu nešlo, chtělo se spát.

Šestý den, Oslo – Rjukan

Rjukan je v centru jižního Norska, a je dobrým výchozím bodem na náhorní plošinu Hardangervidda.  Zarezervoval jsem na tři dny samostatnou chatku v Rjukan Hytteby & Kro.  Doporučuju to udělat s předstihem alespoň tří dnů.  No a dnes byl plán se tam přesunout.

Ráno snídaně v Kaffebrenneriet, hned vedle penzionu.  Dobré, levné, super hudba (Anna Brun), jen číšnice trochu nasraná.

Další plán je národní galerie.  Je zrovna den, kdy je vstup zdarma, takže moře lidí.  Expozice je ale hezká, opravdu dobrý výběr obrazů národních umělců.  Dovnitř mě s foto-brašnou striktně nepustili.  Tak jsem se ověsil přímo foťákama o objektivama a nejednou to paradoxně šlo.  Výsledek zde:

Na oběd jdeme do číny Jumbo Restaurant v patře.  Jídlo dobré, ale ne zas až tak moc vzhledem k norské ceně.  Interiér kýčovitý.  A je zakázáno fotit – “please, better not take pictures” s brutálním přízvukem.

Pak jdeme jen tak po městě.  Nakoukneme do katedrály, pokud je to tedy ten správný kostel, je jich v Oslo hodně a všechny jsou si podobné.  Je malá, zkouška sboru ale stojí za to, záznam zvuku zde:

Další cíl je geologické muzeum u botanické zahrady, ale to jsme nestihly – zavřeno.

Zkusili jsme zajít do Bjørungs.  Ve dne to nebylo ono, ale stejně je to moc hezká hospoda v Irském stylu se super výzdobou a atmosférou.  Nemají ale vůbec nic k jídlu.

Po nákupu v čínském obchodě a večeři v trochu všemi možnými věcmi přeplácané restauraci Lorry hned naproti Cochs (pouze sendvič) se vydáváme ve večerních hodinách směrem na Rjukan, do srdce jižního Norska, k náhorní plošině Hardangervidda.

Cesta je krásná, konečně začínám cítit Norsko, svobodu, rozlehlost, pustotu.  Jedeme po malých silničkách lesem, kde před chvílí pršelo, kolem řek, mezi skalami, v dálce hory.  Jedeme na západ, takže před námi je tmavnoucí načervenalé nebe.  Cítím se krásně, volně.  Do Rjukanu přijedeme až ve 22:15.  Hytteby jsem upozornil předem, že asi přijedeme později, což bylo dobře.  Vedoucí neumí moc dobře anglicky, ale je příjemná a domluvili jsme se, dostal jsem povlečení s ručníky.  Chatka je připravená, je v ní všechno – dá se tam prostě bydlet.  Pivo, jídlo, televize, lehký plán na druhý den, a pak blaženě spím jak zabitý.

Sedmý den, Rjukan a Hardangervidda poprvé

Krásný slunný den, teplota kolem 13 stupňů.  V centru městečka je turistická kancelář, kde jsme koupili mapy a průvodce po Hardangervidde, pak nákup drobných zásob v KIWI, vše při ruce.

Na první malou výpravu bylo nejjednodušší použít lanovku Krossobanen, která je ještě u města, 50 NOK na osobu jedna cesta.  Začali jsme později po poledni.  Díky tomu a taky že už bylo po sezóně, nikde nebyla ani noha.  Platilo se až v lanovce, kasa v budově byla prázdná.

Cestou nahoru bylo krásně vidět Gaustatoppen, kopec, jak kdyby ho někdo vymyslel.  Těsně pod vrcholem má NASA jakýsi vysílač.

Když jste nahoře, vyjdete z lanovky a dáte se po zpevněné cestě nahoru (jediná a dokonce asfaltová), až se dostanete k ohybu o téměř 360 stupňů.  My ale jdeme dál rovně po pouze červenými značkami vedené cestě, už lesem do mírného kopce, směr na Helbergyta.

Značení cest jako u nás nečekejte.  Na ukazatelích a občas na kamenech je písmeno T.  Mezi tím se občas objeví něco vyrobené lidskou rukou co vypadá jako značka a vede vás, buď červená barva nebo hromádky kamení, nebo tohle:

Po krátké době ustupují stromy a vegetace se mění víc a víc jen v nízké křoviny a kleč.  Až stoupání zmizí úplně a my jsme nahoře.  Už jen pláň a barevné lišejníky, občas nějaký keřík.  Cesta chvílemi jakoby mizí, ale hromádky z kamení nebo občasná zjevně lidská červená značka vás zase navede.  Občas potkáme člověka, ale opravdu vyjímečně.  Všichni jsou Norové, slušní a velmi sportovně založení.  Až se stydíme

Došli jsme až k Våerroe, což jsou asi zbytky staré huty, už úplně bez střechy.  Pak jdeme zpět bohužel stejnou cestou, neboť za hodinu nebo dvě už bude zapadat slunce.  Ten kousek co jsme si vybrali k návštěvě je rozlehlý a na nějaký okruh už bylo pozdě.

Lanovka mimo sezónu jezdí jen do 18 hodin.  Po návratu už je prázdná, takže jdeme dolů pěšky klikatící se cestou přímo pod lanovkou.  Najde se snadno, před ní je závora a upozornění “vstup na vlastní nebezpečí.”  Celá cesta dolů trvala snad hodinu.  V zimě se cesta používá jako bobová dráha nebo sjezdovka a zatáčky jsou očíslované, odspoda.  Poslední číslo, nahoře, je 20.  Už u čísla asi patnáct jsem se nemohl dočkat jedničky…  A co nás dostalo nejvíc, byli zdatní Norové, co si přišli takhle navečer tuhle strašnou cestu jen tak vyběhnout nahoru a pak zase seběhnout dolů…  Doma jsme až za tmy, úplně hotový.

První den se podařil, HDNGVD je opravdu super místo a to dnes byla jen ochutnávka.

Osmý den, Rjukan a Hardangervidda podruhé

Dnes vyšla předpověď počasí přesně – pršelo.  Nebo spíš bylo zataženo, zima a mokro.  Takže to bude jen autem.

Zamířili jsme na sever do Atrå a pak odbočkou zpět na Rjukan.  Označená je velkou značkou slepá ulice a nápisem asi ve smyslu “tohle vede až skoro do Rjukanu, ale ne úplně.”  Což je pravda, ona totiž končí nad tou lanovkou ze včera.  U Mårdal se platí mítné – avgift, tuším asi 20 NOK.  Pokud si dobře pamatuju, automat chráněný kamerou nebere karty.  Cesta se víc a víc stávala lesní, dobrý auto je tu prostě potřeba.  Mraky lízající kopce, mlha v údolích, nádhera.

Jedeme až na Kalhovd.  Cesta autem byla sama dost zážitek.  Kupodivu potkáváme nad očekávání hodně aut.  U chaty v Kalhovd jich i hodně stojí.  Uvnitř je spousta hikujících Norů, snad žádný cizinec.  Dáváme si čaj, kafe a něco místního k jídlu.  Názvy si nepamatuju, byly Norsky.  Cena není opět zrovna malá.

Od Kalhovd zahýbáme nejprve po severním břehu Kalhovdfjorden až někam k Synken.

Pak se vracíme stejnou cestou ke Kalhovd, a jedeme přes přehradu na jih.  Dojeli jsme až někam k jezeru Torkjelstjønn.  Cesta byla fantastická, všude velká jezera a kolem kopce jejichž špičky se nořily do nízkých mraků.  Poslední foto z toho nejzazšího místa vůbec neukazuje skutečný pohled.  Byla zima, trochu pršelo, vítr.  A my byly kousek pod vrstvou mraků.  Pod námi údolí, jezero, naproti kopce, mlha ale přesto bylo vidět do dáli.  Fantastický pohled, ovšem nezachytitelný.

Jedeme zpět, počasí se mění, dokonce je i vidět trochu slunce.  Pohledy na stejná místa jsou zase jiné.  Jedeme zase stejnou cestou domů, zase docela unavení.

Devátý den, Hardangervidda potřetí a nejlépe

Poslední den kdy má být ještě hezky.  Tentokrát chci skutečně vstoupit na území národního parku Hardangervidda.  Jedeme autem až do Solheimstulen.  Cesta z Rjukanu trvala něco málo přes dvě hodiny.  U Solheimstulen jsme auto nechali a vydali se pěšky k jezeru Skarvsvatnet.

Počasí bylo fantastické.  Velmi zvláštní typy cumulů se vznášeli nad okolními kopci a vytvářeli naprosto jedinečné světelné podmínky – v pozadí tma a nad námi světlo.  Byla zima a foukalo, chvílemi i lehce mrholilo, ale nám to nevadilo.

HDNGVD na tomhle místě je prostě krásná.  Bylo dokonale vidět tu rozlehlost planiny.  Tady se vážně dalo jít dny kterýmkoliv směrem.  Předešlé dva dny totální hadr.  Barevný porost vypadal jak mořská hladina nebo jiná planeta.

Dost keců

Desátý den, Rjukan – Eidfjord

Další cíl je Eidfjord.  Malé město u konce (nebo začátku) Hardangerfjordu, docela dobrý výchozí bod k severní straně Hardangerviddy.  Rezervace v hotelu Quality Hotel & Resort Vøringfoss, ale moc ho nedoporučuji.  Více info až další den.

Chtěli jsme jet cestami, kde bude hodně co vidět.  Z Rjukanu na západ k Odda a přes Kinsarvik do Eidfjord.  Cesta nám trvala 9h, neboť jsme všude stavěli, jeli vždy po menších uličkách s několika zajížďkami.  Ale stálo to za to.

Hned za Rjukanem jsme čekali asi 20 minut na průjezd tunelem.  Svítila červená, až po nějaké době vyjelo vodící auto, které přivedlo auta z druhé strany.  A pak převezlo nás.  Tohle je docela častý jev téměř při jakémkoliv zúžení vozovky při opravách.  Tunelů je na této cestě opravdu dost.  Zajeli jsme na kafe do Skysstasjonen v Røldal.  Moc hezké místo, vesnice je mezi kopci.  Cesta pokračovala kolem hojně focených vodopádů Låtefoss.  Nezapomenu na mosty hned nad hladinou jezer mezi okolními kopci v Ulevå, máte pocit, že jedete po vodě.  Bohužel fotky nejsou.  Dál do Odda, kde jsme udělali zajížďku směrem na Utne, která podle mě ale až tak za to nestála.  Příjezd do Eidfjordu až k večeru.

Jedenáctý den, Eidfjord a okolí

Eidfjord je malé ale moc hezké městečko.  Není tu ani moc turistů, ale to mohlo být jen roční dobou.

Quality Hotel & Resort Vøringfoss.  Pozitiva – výhled na fjord a dobré postele.  Negativa – nejprve tahanice s cenou, přes booking.com byla cena 2240 NOK za dvě noci.  Pořád dost, ale na norské poměry to šlo.  Po příjezdu ale cena měla být vyšší.  Chvilka jednání a Isabel (recepční) nám zdělila, že za chybu může “dynamický systém cen”, ale že naše cena bude podle bookingu.  Bůhví co se vlastně stalo.  Další negativa – děravá prostěradla, uvolněná baterie a prkýnko na záchodě, popraskané žárovky, světla ale i zásuvky na vstupní kartu, takže baterku do foťáku dobijete jen v noci, a celkově neosobní dojem hotelu.  A navíc se nám v něm moc dobře nespalo, ale to mohlo být úplňkem.  S tím úplňkem, v noci, když vycházel za okolními kopci, mi došlo, jak jsou okolní hory obrovské a na člověka se valí…  Fotku bohužel nemám.

Ráno mě osobně přepadla únava z neustálého organizování a řízení a taky z návalu zážitků, přeci jen to člověk musí taky nějak zpracovávat.  Odpoledne už mě to ale přešlo   A tak se vydáváme po okolí kouknout na vodopády a nakouknout na Hardangerviddu ze severu.

První je Skytjefossen, obří, 300m vysoký vodopád.  Cesta až k němu se bez lokální mapy, kterou jsme neměli, hledá špatně.  K vodopádu se dá dojít jen pěšky, ale výchozí bod stezky jsme prostě nenašli.  I tak ale pohled na něj alespoň z dálky stál za to.  Je divoký, nenajdete tam živáčka.  Výstup blíže k vodopádu musí stát za to.

Cestou zpět jedeme kolem Hardangerfjordu a jeho klidné hladiny připomínající zrcadlo, dál pak po silnici číslo 7 na jihozápad.

Další vodopád je Vøringfossen, ale ten nás moc nezaujal.  Hodně navštěvovaný, u hotelu Fossli se na parkovišti platí 40 NOK za zastavení.  Pozor, než zahnete k hotelu, je tam spousta místa na zaparkování zadarmo.  K hotelu je to pak kousek.

Cesta po Rv7 k hotelu Fossli je ale zajímavá.  Poprvé jsem zažil tunel co se točí 360 stupňů dokola   A pořád si procvakáváte uši.

Severní část Hardangerviddy není tak zajímavá jako jižní.  Tronsbu, kam se dostanete po zaplacení 100 NOK mýtného, je jen přístav.  Krajina a cesta není nezajímavá, ale není to ono, všude také hodně lidí.  A komárů!  Jen výhled na ledovec Hardangerjøkulen stojí za to.

Další zastávka je přehrada Sysenvatnet, už při zapadajícím slunci.  Krásné romantické místo, kde pohled na Hardangerjøkulen je ještě lepší.

Zpět až za tmy, máme hlad.  Tak hledám restauraci, ale jsou jen hotelové.  Nakonec jsme v liduprázdném městečku zašli do Fjell og Fjord Hotel.  Je to velmi příjemný hotel s domáckou atmosférou a lepší cenou, než Hotel Vøringfoss.  Výhled  máte taky, Fjell je na kopci a dost vysoko, abyste viděli město i fjord.  Dali jsme si domácí lazaně za 110 NOK s dobře točenou Hansou.  Na to jak bylo pozdě (po deváté večer) byly všichni zaměstnanci hotelu v pohodě a vytvářeli domáckou atmosféru, hlavně obsluha v prosklené restauraci.  Osobně tenhle hotel doporučuju víc, než Quality Hotel & Resort Vøringfoss dole u vody.

Zrovna ten den se konal kousek od Eidfjordu Anger Metal festival, bohužel už nebyla energie ho navštívit.  Trochu mě to mrzí, měl sem do sebe možná kopnou Redbull a jet…  Kapel tam bylo dost z Evropy, US i místní.  Lidi u stolu vedle v restauraci tam zjevně jeli.  Norští metaláci na mě působili mnohem kultivovaněji, než ty z Čech.  Ale to nemůžu soudit objektivně, na koncertě v Norsku jsem prostě zatím nebyl.

Dvanáctý den, Eidfjord – Bergen

Dopoledne se vydáváme po Rv7, dle rady mého kamaráda a bývalého kolegy, který bydlí v Bergenu.  Nejprve přejet fjord.  V dálce je vidět most a navigace na něj zdá se vede.  Zahýbáme k mostu a hle, mýtné!  A dost vysoké, divím se, cca 130 NOK.  Ono to totiž není mýtné, ale lístek na trajekt.  Po bližším ohledání bylo vidět proč: mostu chyběla jedna důležitá část – most.  Zatím jsou to jen dva sloupy, zbytek bude dostavěný až za rok…  Trajektů je na trase víc.  Cesta po Rv7 je krásná, se spoustou tunelů specifických pro Norsko – připadáte si jako když vjedete do jeskyně – a s několika vodopády a úžasnými pohledy.  Absolutně doporučuju!

Rezervace v Bergenu byla v hotelu Steens.  Hotel je v krásném domě z 19. století, všude spousta starožitností, vše naprosto popírá pravý úhel, točité dřevěné schodiště.  Přivítal nás zvláštní holohlavý týpek, měli jsme pokoj hned za recepcí s číslem 1.  Ten nejhorší pokoj z celého hotelu, ale o tom až další den.  Je to cena za rezervaci až dnes.  Příště dřív!

Třináctý den, Bergen

Pokoj číslo 1 v hotelu Steens: hrůza!  Byl to zjevně kumbál předělaný na pokoj.  Málo prostoru, nelogičnost rozmístění nábytku, které zjevně vymýšlel chlap, pohled do dvora, oknem se dalo rovnou vylézt, dokonce pod oknem byly i schůdky V lampě vrstvy prachu, koupelna špatný vtip, kde se na vás pořád jen lepil závěs kolem “sprchového koutu”.  A největší lahůdka – přímo nad pokojem je jídelna.  Snídaně začíná tuším asi v šest nebo sedm ráno.  V jídelně jsou těžké dubové židle, tak si to dovedete představit.

Hned ráno žádám o jiný pokoj, naštěstí se povedlo.  Máme pokoj 21 v posledním, druhém, patře (mimo jiné bez výtahu).  Výrazné zlepšení!  Výrazně prostornější pokoj má krásnou prosklenou střechu, koupelna je výrazně větší (ale pořád ne perfektní.)

Celkově, i přes nedostatky, ale hotel Steens působí nádherně, všechny ty křivé chodby a zákoutí, starý nábytek, krb, lampy, schodiště, okna, vážně to stojí za to.  Každý pokoj je naprostý unikát.  Navíc stojí v hezké části Bergenu, kde všechny domy jsou velmi pěkné.  Jen upozorňuju, park hned naproti hotelu Steens je v noci opravdu nebezpečný, je to místní junkies centrum.

Jdeme se projít po Bergenu.  Strašně prší, je zima, fouká vítr, celkově lezavo.  Vemte si pořádný deštník, nějaké párátko od vietnamců se vám tu rozpadne na kusy.  Zašli jsme do přírodovědného muzea, obdoba našeho národního – spousta vycpaných zvířat.  No, nic moc.  Zajímavá byla Egyptská expozice a něco málo o Vikinzích.

Bergen je hezký, menší a příjemnější než Oslo.  Až tedy na ten déšť.  Pokud máte rádi ryby, tak na zdejší rybí trh určitě jděte, dá se tam koupit snad všechno.

Bryggen, je to velmi stará přístavní čtvrť, chráněná UNESCO.  V podstatě je to řada domků u přístavu.  Všechny vypadají, jako že mají za chvíli spadnout.  Ovšem na druhou stranu, vše je upravené, čisté.  Jen to hyzdí spousta obchodů s oblečením a podobně.  Dokonce je tam i bordel   Upřimně, Bryggen moc za návštěvu nestojí.  Raději jeďte lanovkou někam na kopec, okolo Bergenu jsou dva.

Večer jsem se potkal s mým kamarádem a bývalým kolegou, který tu žije.  Zajeli jsme se podívat na nejzápadnější místo Norska a na rozbouřený Atlantik.  Foťák jsem neměl, a to je dobře.  O to víc jsem si tohle vychutnal.

Vyzvídal jsem jak to v Norsku chodí.  Dozvěděl jsem se, že Norsko se zdá směšně drahé i místním a že je hodně závislé jen na vývozu ropy.  Vše drahé je ovšem i kvalitní, jako třeba že pečivo je bez konzervantů a vždy čerstvé.  Pokud ale chcete ušetřit, dají se najít levné obchody.  Ovšem kvalita jde dolů.  Je to trochu jako u nás, jen že tady zas musíte hledat obchody, kde je zboží opravdu kvalitní.  Znám jistou historku o tom, jak někdo v Norsku zapomněl kdesi v parku foťák a za dva dny ho tam zase našel.  Měl opravdu štěstí, protože v Norsku se krade, ne tak jako u nás, ale přeci jen krade.  Sice jen ve velkých městech, ale i to se mění.  Ale o tom až dále.

Čtrnáctý den, Bergen – Egersund

Města nás nebaví.  Mizíme z Bergenu hned dopoledne.  Trochu prší a je mlhavo, ale jde to.  Rozhodli jsme se posledních pár dnů jet po pobřeží přes fjordy do Kristiansandu.  Je to super cesta kolem moře.  Dnešní cíl je Hotel Egersund.  A taky prostě cesta sama, která je moc hezká a klidná.

Několik trajektů, zastávka ve Stavangeru na jídlo v thajské restauraci Naree Thai (podle průvodce), drahá ale dobrá.  Stavanger je těžařské město, nemůžu o něm moc říct, jen jsme ho projeli, na velká města prostě není nálada.

Někde dál za Stavangerem, v menším městě na pumpě, jsme potkali partu Slováků, co v Norsku už zjevně nějakou dobu pracovali jako zemědělci.  Dali jsme řeč, a já se hodně ptal jak to tady funguje.  Zajímavý byl názor, že v Norsku je jakýsi druh komunismu, který panoval u nás v osmdesátých letech.  Mají vlastně všichni všechno a k tomu volnost cestovat.  Norové sami nemají potřebu krást nebo podvádět, alespoň v menších městech.  Ale zato lidi z bývalého sovětského bloku tady začínají krást.  Hlavně Poláci.  A pomalu se to děje už i na vesnicích.  Už se nedivím tomu vyptávání na hranicích.

Patnáctý den, Egersund – Farsund

Egersund je moc hezké malé město, jediný problém je, že jako rybářská vesnice celkem smrdí.  Grand Hotell Egersund byl nad očekávání dobrý.  Užili jsme si hodně spánku.  Až jsme skoro nestihli snídani, neb jsme byly mylně informování o čase, do kdy je.

Rezervuju už raději dnes hotel v Kristiansandu.  Bohužel, volný je už jen zbytečně luxusní Clarion Hotel s cenou 1500 NOK na noc.  Je ale blízko přístavu, odkud brzo ráno vyplouváme zpět do středozemě.

Z Egersundu jedeme po Rv44, pobřežní silnice, krásná cesta, zase spousta skal, vodopádů, tunelů.  Zajeli jsme se podívat na Helleren, dva baráčky ze 17. století, které úplně osamocené leží pod skalním převisem.

Na oběd jsme zajeli do Flekkefjordu, do PIZZA INN.  Pizza byla velká, nadýchaná a dobrá, s očekávanou cenou.  Flekkefjord hezký jako ostatní města, dřevěné baráčky atd.

Farsund. Bohužel, přespat se dalo jen tady, ostatní městečka kolem už neměli volno v hotelech.  Zase se ukazuje, že rezervovat se musí dva dny dopředu minimálně.  Farsund je zaprdlé tiché (mrtvé?) městečko skoro, ale ne úplně na pobřeží, mezi spoustou ostrovů.  Tady se nejezdí ani tak autem, ale lodí.  Ono taky jak jinak když je kolem všude voda.  Místo garáží na auta v přístavech najdete spoustu garáží na lodičky.

Hotel Farsund Fjordhotel.  Na první pohled cool.  Je to terasový hotel, takže recepce je v nejvyšším patře a každý pokoj má velký balkon, nebo spíš rovnou terasu.  Dalo by se tam v klidu grilovat.  Bohužel, nevzal jsem gril a ani není maso.  Výhled je na zátoku a několik sil.  Mě se to na jednu noc líbí, ale nechtěl bych tu být na delší dobu.  Hotel je postavený v osmdesátých letech a zjevně neprošel žádnou rekonstrukcí.  Nedoléhající lišty pod stropem, tapety, celková zatuchlost hotelu… Netekla pořádně teplá voda a sprcha kvůli vadnému kohoutu také, rozpadali se lampičky nad postelemi, roztrhnutý povlak na polštáři.  Ale i tak to vlastně nebylo špatné a spalo se dobře.

Šestnáctý den, Farsund – Kristiansand

Po dobrém vyspání a celkem obstojné snídani jedem dál směrem na Kristiansand.  Pořád po pobřeží.  Tenhle kousek ale byl nejhezčí.

Vestbygd je  trochu cestou zpět na západ od Farsund.  Má super molo s majákem, kde se dá dívat na severní moře.

Cestou zpět k Farsund jsme našli malou schovanou divokou pláž Kviljo.  Na fotkách je vidět maják Rauna.  Když jsem se přiblížil, bylo na pláži hejno ptáku.  Pokus je vyfotit ale nevyšel, odletěli dál po pláži ještě dřív, než jsem se vůbec přiblížil.  Chtěl jsem vyměnit objektiv, ale zaslechli cvaknutí bajonetu a odletěli nadobro.  Nebyli zjevně moc zvyklí na lidi.

Pak jedem zpět do Farsundu na kafe a kebab za 220 NOK.  A pak už opravdu směrem na východ, pořád po pobřeží.

Austre Tranevåg, zátoka na konci světa, okolo několik domků a dokonalý klid.  Tady bych chtěl bydlet…

Pokračujem do Lyngdal.  Ta loď uprostřed fjordu tam vypadala jakoby “chlapi zaparkujte, deme na kafe”.

Lindesness, nejjižnější výběžek Norska s majákem.  Trochu kýčovité místo, ale vlastně moc hezké.  Přišli jsme těsně před pátou, takže nám daly vstup zadarmo.  Budovy se měli zavírat, ale stejně jsem se podíval až nahoru do majáku.

A pak už jen Kristiansand a Clarion Hotel Ernst. Kýč až na půdu včetně ambi-light u televize, ale v podstatě cool.

Sedmnáctý den, Kristiansand – Waldhalle (DE)

Ráno v 8:00 jede náš trajekt s ColorLine do Hirsthals v Dánsku (levnější TT-line už touhle dobou v roce – v září – nejezdí ; informace ověřená telefonicky).  Objednával jsem ho ještě v Rjukanu za 65 EUR, ale podle mě stačí objednat třeba i jen dva, tři dny předem.  Ovšem nezaručuju to.

Vyspání a noc v hotelu v pohodě.  Zaparkoval jsem večer před tím u mola hned u hotelu.  Mají tu zase trochu jinak fungující platební automaty.  Bere karty.  Když zaparkujete, kartu vložíte, a hned dostanete lístek, čas se nevolí.  Trochu mě to zarazilo.  Pak jsem si pořádně pročetl návod, který byl v aj.  Lístek, co vydá automat při příjezdu se dá do auta.  Když pak odjíždíte, vložíte do automatu stejnou kartu, ten započítá čas, stáhne peníze a dá vám účet.  Člověk jen na to nesmí zapomenout, jinak se pravděpodobně nedoplatí.  Kolik byla cena za noc už si moc nepamatuju, ale asi kolem 30 NOK.

Příjezd k checkinu je od kruhového objezdu pod (ne na) E18, po silnici Vesterveien.  Výjezd je označen ◄Danmark E39 a ◄Terminal.  E39 vede vlastně trasou trajektu až do Hirsthals.  U checkinu jsem jen řekl jména a ukázal z dálky PDF v telefonu.  Toť celá kontrola lístku

Před naloděním jsem ještě pomohl jedné Norce s nastartováním, chcípla jí baterka (naštěstí auto jelo bez další pomoci i v Dánsku.)  A pak už na loď.  SuperSpeed 1 od ColorLine.  Kajutu jsem nerezervoval, cesta trvá jen tři a čtvrt hodiny.  Loď snobská a personál ne zrovna příjemný.  Po odrazu přišla SMS o cenách volání a mobilního internetu přes operátora na trajektu – ceny závratné, vypínám raději telefon.

Plavba je super zážitek, můžete vylézt na zadní palubu, kde kolem vás je jen severní moře a spousta dalších lodí.

A tak jsme opustili Norskou krajinu…

A teď přes Dánsko do Německa, cíl je Hamburk, nebo prostě kam až dojedeme.  Dánsko je placatá země, kde nikdo nepoužívá blinkry, a navíc smrdí hnojivem.  I přes to jsme zastavili na oběd v Høbe v restauraci Amerika na dánské speciality.  Nevím, jestli si z nás kuchař jen vystřelil nebo tam opravu tak jedí, ale jedno jídlo bylo biftek se sirovým žloutkem, řepou, zelím, cibulkami a kapary, další pak kuřecí ragů a k tomu docela záhadné pečené těstové košíčky, které se asi tím ragů nemají plnit ale prostě jen přikusovat.  Docela zážitek a nutno říct, že nám to fakt chutnalo.

V Dánsku hotely nedoporučuju:

V Německu jsme cirka za 4 hodiny.  Za hranicemi jsme vzali stopaře Franka, kluk 24 let, který chtěl do Hamburku, co před čtrnácti dny byl údajně na Hardangerviddě stanovat, no není ten svět malý?

Jako cíl bylo vybráno Waldhalle.  Na booking.com jsem zarezervoval ten nejlevnější hotel Quellenhof.  Dělal jsem to cca v šest večer, kousek od hranic Německa s Dánskem.  Až po potvrzení rezervace jsem si všiml, že čas pro příjezd je do 18:00.  Teleportu nemaje, volám do hotelu, neboť jinak budu platit poplatek za zrušení (pro rezervaci na booking.com musíte dát číslo kreditky.)  Nikdo to v Quellenhof nebere ani na asi třetí pokus.  Tak to vzdávám a hledáme dál.  Další jsem našel hotel Waldhalle, kde už je ale jen celá chatka za trochu větší peníz.  Vzali jsme to.

Okruh kolem Hamburku je docela zacpaný, zdrželo nás to.  Do Waldhalle přijíždíme až za tmy.  Najít hotel ale není snadné, čísla v ulici nejsou, vlastně tam nejsou ani domy, google maps mlčí a navíc je tam mizerný internet.

Až kolemjdoucí nám pomohl.  Hotel je až úplně na konci cesty Waldhallenweg s číslem 1. Jeli jsme temným lesem, loukami, kolem odříznutého přírodovědného muzea, pak zase lesem, až na docela kouzelné místo kde je budova hotelu – starý hezký dům – a kolem malé lampy a chatky.  Chatka je totálně dokonalá, obří apartmá, kde se dá krásně několik dní existovat.  Cena je 2300 CZK na noc.  Po tom, co máme za sebou v Norsku – luxus.  K večeři garnáti a pivo Radeberger.  Lahoda.

Osmnáctý a poslední den, Waldhalle (DE) – Doksy (CZ)

Další den nejedeme ještě zpět do Prahy, ale navštívit jednoho kamaráda s chalupou nedaleko Doks.  Je prostě potřeba nějaký přechod a ještě je trochu času si užívat.  Je to už ale definitivní tečka za tímhle výletem.

Až pojedu do Norska příště, tak to bude striktně do přírody a pod stan.  A taky si dát konečně nějaký koncert.

LocalStorage, simple web API to store persistent key/value pairs, is very favorite among web developers for its simplicity of use thanks its synchronous design.  But in current versions of Firefox is one of most serious culprits of UI janks.  The browser UI may simply stop reacting for a short time when localStorage data is written as well as read, mainly on mobile devices with poor flash memory performance.

A month ago I started rewrite of the DOM storage code in the Mozilla Platform from scratch.   Except the performance and memory consumption problems other motivation for it is simply a strong need for code cleanup.  The work on the new implementation is currently in stage of a pending review to get it into to the tree in mozilla bug 600307.  It’s planned to land for Firefox 22, since 21 soon transits to the Aurora channel.

The main difference in the new implementation is that writes, but also reads, are completely moved to a background thread so it will not freeze your browser.  When a web content script touches localStorage it only works with a memory cache and UI then cannot be blocked on waiting for disk writes to complete.  All data changes are posted to and flushed in regular short intervals on the background I/O thread.

However, before localStorage can be used, data for the page origin has to be there – loaded into the memory cache.  I implemented an early pre-load of the data when we start navigation to a web page.  This is so far trivial:  when prefetch doesn’t make it on time to load all data quickly enough, we block UI on access to localStorage until it is done.  There are obvious and less obvious reasons to load all the data:  if you want to read a key it simply needs to load from your disk first, but there is also quota usage checking when data are added or modified and StorageEvent providing the previous key value before modification.

So, there is still a room for more optimizations here I plan as a followup work to the core patch.  To shortly explain, prefetch on the background thread pushes localStorage keys and its values one by one to the cache.  Access to localStorage is blocked until all data is loaded.  To make that time as short as possible I plan following further optimizations:

• Obviously, when reading a single key and that key is already in the cache, just provide it without waiting for the rest of the data to load.
• However, when a key is not in the cache, we have two options: wait just for that one key to get loaded or, when WAL mode on the SQLite database connection is enabled, read just that one key synchronously from the database.  Both approaches, however, have to block the UI.  Fortunately, our telemetry data (that I must thank you all for submitting it!) shows that reads from the database are generally very fast even for a whole domain data.
• When a key is about to write, we don’t need to block, yet quota checking is the enemy here.  We must lower our demands on its precision slightly.  Other complication is the StorageEvent that has to fire after a data modification.  The event has to report the previous value of a modified key.  Fortunately, the StorageEvent can be asynchronous.  Hence, we can just fire it later after the key value has loaded from the database.

Before I jump to write these more changes I first want to collect telemetry data on which operation and for how long we still may block.

I wrote a fairly technical overview of how the whole new implementation works at this MDC document.

I want to thank Vladan Djeric for his help with this work.  He is the one to review that huge patch and he also gave me inspiration for some aspects of the new implementation, like WAL usage and task batching, through his work on intermediate localStorage optimization in bug 807021.

I’ve made an experimental Firefox Nightly build with my patch.  I intend to use it to get some first telemetry data.  If anyone is brave enough and wants to help improve, then feel free to install it as well, enable telemetry in about:telemetry and report any crashes that may happen.  I will sync these builds with latest Firefox Nightlies from time to time and expose links to them here.

Disclaimer: the patch didn’t go though a code or security review, only through mozilla automated testing.  Any data loss is at your own risk!

The latest (updated fifth time) experimental builds based on Mar 15 2013 mozilla-central code can be found here: for Windows, Linux (64) and Mac.

It’s known to be slow and having problems with unpredictable jumps back and forward, but only on a minority of platforms.  But still, some protection measures must be taken.

I’ve observed really significant performance issues only on older systems running Windows XP (32-bit).

Problems causing the biggest pain are:

• QueryPerformanceCounter may jump against expected monotonicity when a thread switches a processor core (happens quite often, by the way) ; solution can be sticking one’s thread to a single core.  This, though, happens on minority of systems like 64-bit processors running 64-bit Windows XP.
• QueryPerformanceCounter may not exactly reflect time while a machine has been suspended ; or simply may not increase as expected.
• When called very often, e.g. in cycles, it may influence even I/O operations performance.

A year or so ago I’ve implemented high resolution timer to be used in the Mozilla Platform.  The code, as is, is pretty complicated, it tries to calibrate QueryPerformanceCounter values against GetTickCount that is known to be very stable and also fast to call, but has, depending on a system, not better then 15.6 milliseconds interval of increasing.  I’ve chosen to calibrate QueryPerformanceCounter with GetTickCount based on this compare of Windows API timer functions.

Recently, I’ve got an idea to simplify the QueryPerformanceCounter usage implementation quite a lot.  It also comes from demand to prevent use of QueryPerformanceCounter for measuring timeouts longer then, say, 500ms.  It would be just wasting of resources.  GetTickCount may perfectly fulfill the purpose for longer durations.

The new code does the following: when the Now() function is called, the result is a complex value keeping both QueryPerformanceCounter and GetTickCount results.  When measuring duration between two calls to Now(), I can check how much QueryPerformanceCounter differentiates from GetTickCount in both timestamps.  If it is too much, I simply use GetTickCount to calculate the duration.  If it differs too much and the interval between the two timestamps is very short, I can even say QueryPerformanceCounter is not stable and consider not to use it at all.

Calculation of duration between two timestamps using QueryPerformanceCounter (QPC) and GetTickCount (GTC):

• jitter = ABS((QPC1 - GTC1) - (QPC2 - GTC2))
• if jitter is less then 15.6 x 2, then calculate and return duration as QPC1 - QPC2
• jitter = jitter - 15.6 x 2
• if jitter is more then 50ms per 1000ms of duration, then calculate and return duration as GTC1 - GTC2
• and, if ABS(GTC1 - GTC2) is less then 2000ms, stop using QueryPerformanceCounter at all, it misbehaves

15.6 ms is result of GetSystemTimeAdjustment’s timeIncrement.  2000ms is the “too short” duration to let QPC behave wrong.  The 50ms per 1000ms is empirically gathered number.  So far, I know it is able to detect really badly behaving QueryPerformanceCounter.

This radically simplifies the current code and from its nature solves the suspend/wake up issue.  System sleep time will always be correctly reflected by GetTickCount.  QueryPerformanceCounter inconsistency after waking the system up will simply be ignored.

This also allows a very simple implementation of NowLoRes() just by not storing QueryPerfomanceCounter result in the time stamp value.

Finally, the more efficient implementation of localStorage DOM API has landed and sticks in Firefox 23, currently on the Nightly channel.  The first build having the patches has id 20130416030901.

More about the motivation and details in my previous post on DOM storage code overhaul.

I want to thank all involved people, namely Vladan Djeric, Marco Bonardo and Olli Pettay for their help, ideas and mainly reviews of this large change.  Thanks!

I always wanted to see all the little things that happen when loading a web page in Firefox.  I know how it works well as a Gecko developer, but to actually see the interaction and chaining is not at all always obvious, unless you study crazy NSPR logs.  Hence, I started a development of a tool, called event tracer, to get a timeline showing the hidden guts.

Example screenshot will tell the story the best way, a trial run of www.mozilla.org load:

Planning improvements

At this time the work is not complete.  There is a lot more to make this an actually useful development tool and my next steps are to hunt those requirements down.

I am using about:timeline to verify patches I review do what they intend to do.  It can also help find hidden bugs.

However, using about:timeline for discovery of perfomance suboptimal code paths showed up being not that simple.  Events are just spread all over around and connection between them is not easily, if at all, discoverable.

Hence, this needs more thinking and work.

First thoughts to improve are to more focus on “the resource” and a single object dealing with it.  It might be better to show what all events are happening on e.g. a single instance of an http channel or http transactions then to tortuously hunt them somewhere in the graph.  There is some simple way to highlight and filter, but that is not enough for an analytical view.

Then, I’m missing a general way to easily recognize how things are chained together.  So, I’d like to link events that are coming one from another (like http channel creates an http transaction, then a connection etc.) and present the timeline more like a gantt chart plus show a critical path or flow for any selected pass through.

From inspecting the timeline it should be visible where bottlenecks and long wait times worth fixing are.  At this time I don’t have a complete clear plan on this, though.

Still here?  Cool   If you have any though or ideas for how to use the data we collect and visualize as a valuable source for the performance optimization surgery please feel free to share them here.  More on how the timeline data are produced check bellow.

How it works

This event track on the image is produced with a special code instrumentation.  To get for instance “net::http::transaction” traces, following 3 places of the code have been instrumented (in blue):

1. WAIT – record time when an http transaction is scheduled:

nsresult
nsHttpTransaction::Init(uint32_t caps,
                        nsHttpConnectionInfo *cinfo,
                        nsHttpRequestHead *requestHead,
                        nsIInputStream *requestBody,
                        bool requestBodyHasHeaders,
                        nsIEventTarget *target,
                        nsIInterfaceRequestor *callbacks,
                        nsITransportEventSink *eventsink,
                        nsIAsyncInputStream **responseBody)
{
    MOZ_EVENT_TRACER_COMPOUND_NAME(static_cast<nsAHttpTransaction*>(this),
                                   requestHead->PeekHeader(nsHttp::Host),
                                   requestHead->RequestURI().BeginReading());

    MOZ_EVENT_TRACER_WAIT(static_cast<nsAHttpTransaction*>(this),
                          "net::http::transaction");

2. EXEC – record time when the transaction first comes to an action, it is the time it gets a connection assigned and starts it’s communication with the server:

void
nsHttpTransaction::SetConnection(nsAHttpConnection *conn)
{
    NS_IF_RELEASE(mConnection);
    NS_IF_ADDREF(mConnection = conn);

    if (conn) {
        MOZ_EVENT_TRACER_EXEC(static_cast<nsAHttpTransaction*>(this),
                              "net::http::transaction");
    }

3. DONE – record time when the transaction has finished it’s job by completing the response fetch:

nsHttpTransaction::Close(nsresult reason)
{
    LOG(("nsHttpTransaction::Close [this=%x reason=%x]\n", this, reason));

    ...

    MOZ_EVENT_TRACER_DONE(static_cast<nsAHttpTransaction*>(this),
                          "net::http::transaction");
}

The thread timeline where an event is finally displayed is the thread where EXEC code has been called on.

What is the exact definition of the WAIT and EXEC phase is up to the developer now.  For me the WAIT phase is any time an operation is significantly blocked before it can be carried out, it’s the time having the main performance affect we may be in particular interested in shortening.  Few examples:

• time spent in a thread’s event queue – duration from the dispatch to the run
• time spent waiting for an asynchronous callback such as reading from disk or network
• time waiting for necessary resources, such as an established TCP connection before an object can proceed with its job
• time spent waiting for acquirement of a lock or a monitor

How to bind a URL or any identifying info to an event

The following instrumentation is used (in red):

nsresult
nsHttpTransaction::Init(uint32_t caps,
                        nsHttpConnectionInfo *cinfo,
                        nsHttpRequestHead *requestHead,
                        nsIInputStream *requestBody,
                        bool requestBodyHasHeaders,
                        nsIEventTarget *target,
                        nsIInterfaceRequestor *callbacks,
                        nsITransportEventSink *eventsink,
                        nsIAsyncInputStream **responseBody)
{
    MOZ_EVENT_TRACER_COMPOUND_NAME(static_cast<nsAHttpTransaction*>(this),
                                   requestHead->PeekHeader(nsHttp::Host),
                                   requestHead->RequestURI().BeginReading());

    MOZ_EVENT_TRACER_WAIT(static_cast<nsAHttpTransaction*>(this),
                          "net::http::transaction");

Here the http transaction event is set a host + path of the resource it loads.

The object’s this pointer, that needs to be properly cast by the developer, is what sticks all together.  This is the main difference from how usual profiling tools work.  Event timeline is providing a view of event chaining crossing thread and method boundaries, and not just a pure stack trace.

View details of a tracked event

Each event track is bound with e.g. a URL it deals with, where applicable.  You can inspect the URL (the associated resource) and more details when an event is clicked on:

Wait between is track of the time the event spent waiting, i.e. the time the event has been scheduled and time of the execution start, both since the time tracking has been turned on.  The number in parentheses is simply the wait phase duration.

Execution is track of time spent by execution, i.e. when the intended job it self has started and when it has actually finished.  The parenthesized number is how long the job execution took.

Posted from is name of the thread the event has been scheduled at.

The Filter button is used to quickly filter this particular event plus it’s sister events out.  How it work is described bellow.

The Zero time button is used to shift the “time 0.000″ of the timeline to the start time of the inspected event, so that you can inspect recorded timing of other events relative to this one particular.

mxr link will open results of search for the event name in the code.  This way you can quickly inspect how this event timing is actually instrumented and collected right in the code.

Filtering timeline events

You can filter events using two filtering functions:

• By type of an event (e.g. “net::nttp::transaction”, “docshell::pageload” etc.)
• By name of a resource an event has been associated with (e.g. “www.mozilla.org”, “/favicon.ico” etc…)

Filter by type – currently there are following event types so far implemented (instrumented).  Yyou get this check box list after the tracer run when you click filter events at the top bar:

Each event has a namespace, e.g. for “net::http::transaction” the namespaces are “net::” and “net::http::”.  You can turn on or off the whole set of events in a namespace easily.  Currently there are only “net::” and “docshell::” top level namespaces worth mentioning.

Filtering by resource, i.e. usually the URL a particular event or set of events have been bound to, is also possible when you click filter resource:

You can enter the filter string manually or use the provided autocomplete.  The by-the-resource filtering works as follows:

1. we inspect whether the string set as the filter is a substring of the event resource string
2. we inspect whether the event resource string is a substring of the string set as the filter

If one of these conditions passes, we display the event, otherwise, we hide it.

This way when you enter “http://www.mozilla.org/favicon.ico” as a filter, you see the http channel and transaction for this resource load, as well as any DNS and TCP connection setups related to “www.mozilla.org”.

How to use about:timeline your self

• Create an optimized build of Firefox with --enable-visual-event-tracer configure option
• Install about:timeline extension
• Run Firefox
• Go to about:timeline
• Press the orange [ Start ] button, you get the message the trace is running
• Proceed with your intended actions, e.g. a page load, and let it finish
• Return to about:timeline tab and press the [ Stop ] button
• Wait a little to get your events timeline details

So, here it is.  It’s a work in progress tho.  I’ll keep updates.

A zase rok v pr..li

Loňský ročník Million Marihuana March 2012 se moc nelišil, jen možná více lepšího vegan a vegetariánského jídla.

This is a ‘how to’ for battery threshold setting on Lenovo laptops with Windows 8 system when your battery recharges fully after the system restart.

I’ve recently updated my ancient Lenovo laptop to Windows 8.  To prolong lifespan of my battery I had to setup again the charge thresholds to not start charging the battery sooner then bellow 5% and stop up at 100% using PowerManager 6.36 with 1.66.0.22 PowerManager driver.

However, after system restart the battery started to charge fully every time – a way to significantly shorten it’s lifespan.

To fix it I did some search.  There are forum posts how to fix charge thresholds manually.  However, it didn’t work for me.  Changing ChargeStartControl, ChargeStartPercentage, ChargeStopControl, ChargeStopPercentage registry keys under HKEY_LOCAL_MACHINE\SOFTWARE\Lenovo\PWRMGRV\Data didn’t help.

The correct registry settings are located elsewhere:

HKEY_CURRENT_USER\Software\Lenovo\PWRMGRV\Data\<eleven alphanums code>\

The “code” seems to be something random and looks e.g. like 1983HD83HM7. This is just an example, it will for sure be different on your machine!

You may need to manually create any missing DWORD values, in my case those are (in hex):
ChargeStartControl: 0×00000001
ChargeStartPercentage: 0×00000004
ChargeStopControl: 0×00000001
ChargeStopPercentage: 0×00000064

After you do the changes, restart your machine.

These settings then produce the following status that persists after system restart:

C/2011 L4 PanSTARRS v blízkosti hvězdy Errai (ɣ Cep) v souhvězdí Cepheus.

16.5.2013 1:48 – 2:48  SELČ
Jižně od Prahy
Canon 60d + CLS CCD Clip
Canon 200mm/f2.8 L II USM
HEQ5, bez pointace
8x5min 800 ISO @ f3.5
Flat 8x, Bias 5x (bohužel focené dodatečně doma, zapomněl sem si flat field..)

Později přišli mraky, takže fotka je trochu rozmazaná.

DeepSkyStacker 3.3.2, stack na kometu dle tohoto návodu.  I přes to ale nejsou dráhy hvězd vidět.  Při bližším pohledu jsou jen znatelné duchy.  Doladění PhotoShop (32bit).

After some two months of coding me and Michal Novotný are closing to have first “private testing” stable enough build with new and simplified HTTP cache back-end.

The two main goals we’ve met are:

• Be resilient to crashes and process kills
• Get rid of any UI hangs or freezes (a.k.a janks)

We’ve abandoned the current disk format and use separate file for each URL however small in size it is.  Each file is using self-control hashes to check it’s correct, so no fsyncs are needed.  Everything is asynchronous or fully buffered.  There is a single background thread to do any I/O like opening, reading and writing.  On Android we are writing to the context cache directory.  This way the cached data are actually treated as that.

I’ve performed some first tests using http://janbambas.cz/ as a test page.  Currently as I write this post there are some 460 images.  Testing was made on a relatively fast machine, but important is to differentiate on the storage efficiency.  I had two extremes available: an SSD and an old and slow-like-hell microSD via a USB reader.

Testing with a microSD card:

*) Here I’m getting unstable results.  I’m doing more testing with having more concurrent open and read threads.  It seems there is not that much effect and the jitter in time measurements is just a noise.

I will report on thread concurrent I/O more in a different post later since I find it quite interesting space to explore.

Clearly the cold “type and go” test case shows that blockfiles are beating us here.  But the big difference is that UI is completely jank free with the new back-end!

Testing on an SSD disk:

The results are not that different for the current and the new back-end, only a small regression in warmed and cold “go to” test cases:

Having multiple threads seems not to have any affect as far as precision of my measurements goes.

At this moment I am not sure what causes the regression for both the “go to” cases on an SSD, but I believe it’s just a question of some simple optimizations, like delivering more then just 4096 bytes per a thread loop as we do now or a fact we don’t cache redirects – it’s a known bug right now.

Still here and want to test your self? Here are test builds: Linux, Linux x64, Mac OSX, Windows, Android.  I will update these links as the development goes on.  Disclaimer: the code is very very experimental at this stage, so use at your own risk!

In my previous post I was writing about the new cache backend and some of the very first testing.

Now we’ve stepped further and there are significant improvements.  I was also able to test with more various hardware this time.

The most significant difference is a single I/O thread with relatively simple event prioritization.  Opening and reading urgent (render-blocking) files is done first, opening and reading less priority files after that and writing is performed as the last operation. This greatly improves performance when loading from non-warmed cache and also first paint time in many scenarios.

The numbers are much more precise then in the first post.  My measuring is more systematic and careful by now.  Also, I’ve merged gum with latest mozilla-central code few times and there are for sure some improvements too.

Here are the results, I’m using 50MB limit for keeping cached stuff in RAM.

[ complete page load time / first paint time ]

To sum – most significant changes appear when using a really slow media.  For sure, first paint times greatly improves, not talking about the 10000% better UI responsiveness!  Still, space left for more optimizations.  We know what to do:

• deliver data in larger chunks ; now we fetch only by 16kB blocks, hence larger files (e.g. images) load very slowly
• think of interaction with upper levels by means of having some kind of an intelligent flood control

¹) Open a new tab and navigate to a page when the cache is already pre-warmed, i.e. data are already fully in RAM.

²) Open a new tab and navigate to a page right after the Firefox start.

* I was testing with my blog home page.  There are few large images, ~750kB and ~600kB.  Delivering data to upper level consumers only by 16kB chunks causes this suffering.

** This is an interesting regression.  Sometimes with the new backend we delay first paint and overall load time.  Seems like the cache engine is ‘too good’ and opens the floodgate too much overwhelming the main thread event queue.  Needs more investigation.

*** Here it’s combination of flood fill of the main thread with image loads, slow image data load it self and fact, that in this case we first paint after all resources on the page loaded – that needs to change.  It’s also supported by fact that cold load first paint time is significantly faster on microSD then on SSD.  The slow card apparently simulates the flood control here for us.

The bothering prompt when a web app is using offline application cache (a.k.a appcache) has been removed from Firefox!

Beginning with Firefox 26 there will no more be this prompt users have to accept.  Firefox will cache the stuff automatically as if the user has clicked the Allow button.

This actually applies to every software based on Gecko, like Firefox Mobile or Firefox OS. Tracked in bug 892488.

Application cache, a not really favorite feature, is not that widely used on today web and one of the reasons has been this prompt.  It may be a little late in the game, but it still has happen.  I’m curious on what the feedback from web developers is going to be.

The new Firefox HTTP cache back-end that keeps the cache content after a crash or a kill and doesn’t cause any UI hangs – has landed!

It’s currently disabled by default but you can test it by installing Firefox Nightly and enabling it. This applies to Firefox Mobile builds as well.  There is a preference that enables or disables the new cache, find it in about:config. You can switch it on and off any time you want, even during active browsing, there is no need to restart the browser to take the changes in effect:

browser.cache.use_new_backend

• 0 – disable, use the old crappy cache (files are stored under Cache directory in your profile) – now the default
• 1 – enable, use the brand new HTTP cache (files are stored under cache2 directory in your profile)

Other new preferences that control the cache behavior:

browser.cache.memory_limit

• number of kBs that are preserved in RAM tops to keep the most used content in memory, so page loads speed up
• on desktop this is now set to 50MB (i.e. 51’200kB)

There are still open bugs before we can turn this fully on.  The one significant is that we don’t automatically delete cache files when browser.cache.disk.capacity is overreached, so your disk can get flooded by heavy browsing.  But you still can delete the cache manually using Clear Recent History.

Enabling the new HTTP cache by default is planned for Q4/2013.  For Firefox Mobile it can even be sooner, since we are using the Android’s context cache directory that is automatically deleted when the storage gets out of space.  Hence, we don’t need to monitor the cache capacity our self on mobile.

Please report any bug you find during tests under Core :: Networking: Cache.

In one of my older posts I’m describing how the Mozilla Platform decides on whether this high precision timer function is behaving properly or not.  That algorithm is now obsolete and we have a better one.

The current logic, that seems proven stable, is using a faults-per-tolerance-interval algorithm, introduced in bug 836869 – Make QueryPerformanceCounter bad leap detection heuristic smarter.  I decided to use such evaluation since the only real critical use of the hi-res timer is for animations and video rendering where large leaps in time may cause missing frames or jitter during playback.  Faults per interval is a good reflection of stability that we want to ensure in reality.  QueryPerformanceCounter is not perfectly precise all the time when calibrated against GetTickCount while it doesn’t always need to be considered a faulty behavior of QueryPerformanceCounter result.

The improved algorithm

There is no need for a calibration thread or a calibration code as well as any global skew monitoring.  Everything is self-contained.

As the first measure, we consider QueryPerformanceCounter as stable when TSC is stable, meaning it is running at a constant rate during all ACPI power saving states [see HasStableTSC function]

When TSC is not stable or its status is unknown, we must use the controlling mechanism.

Definable properties

• what is the number of failures we are willing to tolerate during an interval, set at 4
• the fault-free interval, we use 5 seconds
• a threshold that is considered a large enough skew for indicating a failure, currently 50ms

Fault-counter logic outline

• keep an absolute time checkpoint, that shifts to the future with every failure by one fault-free interval duration, base it on GetTickCount
• each call to Now() produces a timestamp that records values of both QueryPerformanceCounter (QPC) and GetTickCount (GTC)
• when two timestamps (T1 and T2) are subtracted to get the duration, following math happens:
  • deltaQPC = T1.QPC – T2.QPC
  • deltaGTC = T1.GTC – T2.GTC
  • diff = deltaQPC – deltaGTC
  • if diff < 4 * 15.6ms: return deltaQPC ; this cuts of what GetTickCount’s low resolution unfortunately cannot cover
  • overflow = diff – 4 * 15.6ms
  • if overflow < 50ms (the failure threshold): return deltaQPC
  • from now on, result of the subtraction is only deltaGTC
  • fault counting part:
    • if deltaGTC > 2000ms: return ; we don’t count failures when timestamps are more then 2 seconds each after other *)
    • failure-count = max( checkpoint – now, 0 ) / fault-free interval
    • if failure-count > failure tolerance count: disable usage of QueryPerformanceCounter
    • otherwise: checkpoint = now + (failure-count + 1) * fault-free interval

You can check the code by looking at TimeStamp_windows.cpp directly.

I’m personally quite happy with this algorithm.  So far, no issues with redraw after wake-up even on exotic or older configurations.  Video plays smoothly, while we are having a hi-res timing for telemetry and logging where possible.

*) Reason is to omit unexpected QueryPerformanceCounter leaps from failure counting when a machine is suspended even for a short period of time

Yes, it’s possible!  With a single key press you can build and have a nice list of errors in the Error List window, clickable to get to the bad source code location easily.  It was a fight, but here it is.  Tested with Visual Studio Express 2013 for Windows Desktop, but I believe this all can be adapted to any version of the IDE.

Now when you make a modification to a C/C++ file just build the ‘mozilla-central’ project to run the great build binaries mach feature and quickly build the changes right from the IDE.  Compilation and link errors as well as warnings will be nicely caught in the Error List.

With these scripts you can use the Visual Studio 2013 IDE but build with any other version of VC++ of your choice.  It’s independent, just run the start-up script from different VS configuration mozilla-build prompt.

I personally also create projects for modules (like /netwerk, /docshell, /dom) I often use.  Just create a Makefile project located at the source root directory with name of the module directory.  The project file will then be located in the module – I know, not really what one would expect.  Switch Solution Explorer for that project to show all files, include them all in the project, and you are done.

Few other tweaks:

• Assuming you properly use an object dir, change the Output Directory to point e.g. to $(SolutionDir)\<your obj dir>\$(Configuration)\.  Similarly, set the Intermediate Directory to <your obj dir>\$(Configuration)\. The logging and other crap won’t then be created in your source repository.
• Add:
  ^.*\.vcproj.*
.sln$
.suo$
.ncb$
  to your custom hg ingnore file to prevent the Visual Studio project and solution files interfere with Mercurial.  Same suggested for git, if you prefer it.

Note: you cannot use this for a clobbered build because of an undisclosed Python Windows-specific bug.  See here why.  Do clobbered builds from a console, or you may experiment with clobber + configure from a console and then build from the IDE.

Get an NSPR log with your choice of modules from a try run.  So far works only for mochitests but I think can be extended for other test harness as well.

Based on an advice from Phil Ringnalda at this bug comment. The feature has just landed on mozilla-central.

Note: doesn’t work for B2G so far, there is no way to upload the logs.

Mozilla has few hundred employes and even more volunteers and outside contributors.  Worldwide.  I don’t know them all by person – and I never will.  I even don’t know Brendan Eich in person.

When you look at this just purely statistically, it’s clear that all these people creating Mozilla are of different religion, opinions to global warming, occupation of Tibet, human rights in Russia, China, global economical system, sexual orientation, or just of different favorite color.  And no one says “you don’t like pink color?  Then I can’t work with you!”

This is the same with any larger company and actually any group of people that do something as a team.

We all in Mozilla work together and do it as good as we can and create something that I think has an impact on the world and most of you out there like it.  For instance, one of my managers is a Catholic – strongly believing.  I am an atheist – also very strongly believing.  Do you think it matters?  No!  What only I’m interested in is how anyone I cooperate with does its job – that’s the only thing that matters – at least to me.

I don’t agree with Brendan Eich’s opinion on forbidding gay marriage but I very much respect him as a technical mind.  Period.

P.S.: As you probably know, Brendan Eich many years ago invented the JavaScript language that is now running on massive number of web pages you visit daily.  Since 2008 no one ever said “stop using the Web because it’s based on the JavaScript whose inventor has ‘bad’ opinion on some gay stuff!” – probably because that would sound stupid…?

P.P.S.: Did OkCupid stop using JavaScript on their site…?

(Closed for comments, if you want to say something more on this topic, please say it somewhere else)

Interesting articles: Reflex – Politická korektnost zabila šéfa americké Mozilly, vyjádřit názor se stává smrtící (in Czech), FAQ on CEO Resignation (on The Mozilla Blog)

In Firefox 30 the internal fallback implementation of the NTLM authentication schema talking only NTLMv1 has been disabled by default for security reasons.

Firefox (Necko) knows two ways to authenticate to a proxy or a server that requires NTLM or LM authentication:

• System API or library like SSPI, GSSAPI or ntlm_auth binary ; on the Window platform by default the SSPI is always attempted, on non-Windows systems must be allowed by modifying some of the Firefox preferences, see bellow
• Our own internal NTLM implementation module that is currently disabled since it talks only NTLMv1 ; we may have some plans to implement NTLMv2 in the future

Note that if you are in an environment where the system API can be used we have no handles to influence what NTLM version is used.  It’s fully up to your local system and network setting, Firefox has no control over it.

Preference list influencing NTLM authentication in Firefox

(Note: there is a similar list dedicated to the Negotiate schema)

network.negotiate-auth.allow-insecure-ntlm-v1

Introduced in Forefox 30 on April 25th, 2014, disables use of our own internal implementation of NTLM module that talks only NTLMv1.  Note: this preference influences both NTLM and Negotiate authentication scheme.

deafult: false

true: The NTLMv1 internal implementation module is enabled and used as a fallback when system API authentication fails or cannot be used.

false: Usage of the NTLMv1 module is hard-disabled, it won’t be used under any circumstances.

network.automatic-ntlm-auth.allow-proxies

Allows use of the system (e.g. SSPI) authentication API when talking to (and only to) a proxy requiring NTLM authentication, this also allows sending user’s default credentials – i.e. the credentials user is logged in to the system – to the proxy automatically without prompting the user.

deafult: true

true: The system API (like SSPI) will be used to talk to the proxy, default credentials will be send to the proxy automatically.

false: Disallows send of default credentials to the proxy.  On non-Windows platforms the fallback internal implementation, which is currently disabled, would be used.  Hence with this setting you will not be able to authenticate to any NTLM proxy.

network.automatic-ntlm-auth.trusted-uris

This is a list of URLs or schemes that you trust to automatically send the system default credentials without any prompts to when NTLM authentication is required, the system API like SSPI will be used.  On non-Windows platforms without filling this list you cannot use the system NTLM API to authenticate and since the internal NTLM v1 is disabled, you will not be able to authenticate at all.

deafult: an empty string

example: “https://, http://intranet.com/” – this will allow sending the default credentials to any https: host and any address that starts with http://intranet/ you are connecting to automatically without prompts – BE CAREFUL HERE.

network.automatic-ntlm-auth.allow-non-fqdn

Influences automatic send of default system credentials to hosts with a non fully qualified domain names (e.g. http://corporate/, http://intranet/).

deafult: false

true: Allow automatic sending without prompts, this setting is examined before network.automatic-ntlm-auth.trusted-uris check. With this setting there is no need to list your non-FQDN hosts in the network.automatic-ntlm-auth.trusted-uris preference string.

false: Automatic sending is not allowed to non-FQDN hosts, although particular hosts can be manually allowed in network.automatic-ntlm-auth.trusted-uris.

network.auth.force-generic-ntlm

Forces in all cases and on all platforms use of the internal NTLM implementation. This effectively bypasses use of the system API and never sends the default system credentials.

deafult: false

true: In all cases and on all platforms always only use the internal NTLM implementation. With network.negotiate-auth.allow-insecure-ntlm-v1 at false this will actually completely turn of any attempts to do NTLM authentication to any server or proxy.

false: When NTLM internal implementation is not disabled with network.negotiate-auth.allow-insecure-ntlm-v1 (default is disabled) it is only used when you are not on the Windows platform and the host being connected is neither a proxy nor an allowed non-FQDN host nor a listed trusted host.

Disclaimer: NO WARRANTY how accurate or complete this list is.  I don’t know the Kerberos preferences (if there are any) at all.  I am not the original author of this code, I’m only occasionally maintaining it as part of my HTTP work.