Firefox 57 Quantum – o co chodzi w kwantowej rewolucji pod maską?

Siłą rzeczy, głównymi pionierami postępu muszą być przeglądarki internetowe. I mimo pogoni za numerkami, większość z nich wydaje się niezmienna w swym kształcie od wielu lat. O szkodliwości tego zjawiska najpierw przypomniał sobie Microsoft, ostatnimi czasy zdała sobie z tego sprawę Mozilla.

Firefox już od dłuższego czasu jest chłopcem do bicia ze względu na wydajność i stabilność, a od czasu narodzin cudownego dziecka przeglądarek, czyli Google Chrome, liskowy udział w rynku nieustannie topnieje. Oto ten sam Firefox, który w ubiegłej dekadzie odebrał monopol Internet Explorerowi 6, dziś niemal walczy o przetrwanie, wymagając zmian, czego Fundacja Mozilla jest na szczęście w pełni świadoma. Wskutek tego rozpoczęto projekt Quantum. Szczegóły na jego temat to bardzo często jedynie gąszcz chwytliwych terminów marketingowych, ale są też konkrety, w dodatku całkiem ciekawe. Przyjrzyjmy się im, by potem lepiej zrozumieć, dlaczego walka Firefoksa o wydajność jest w istocie walką z własną historią.

Quantum to jeden z kilku dużych projektów odświeżenia Firefoksa, nadchodzący po dotychczasowych Electrolysis, Australis i WebExtensions, a skupiający się na silniku rysującym. Oznacza to optymalizację dotychczasowego silnika Gecko, a właściwie kompleksową podmianę wielu elementów Gecko na ich odpowiedniki opracowane w ramach eksperymentalnego projektu Servo. Pierwszym z podmienianych elementów jest renderer CSS, znany obecnie pod nazwą Stylo. Lin Node, współautor, tłumaczy działanie Stylo przystępnie objaśniając proces serwowania strony internetowej: struktura-styl-wygląd-rysowanie. Rozpracowywanie stylu, jaki ma być nałożony na stronę przez silnik CSS, odbywa się w Stylo jako zadanie wielowątkowe. Acz tym razem jest to „mądra” wielowątkowość. Bo wbrew pozorom stworzenie aplikacji wielowątkowej to obecnie tylko przerzucenie jednego przełącznika w kompilatorze i poleganie na automatycznych optymalizacjach, które zastosuje podczas kompilacji. Aby poprawnie wykorzystać wielowątkowość, należy zadbać o odpowiednią dla zadania metodykę kolejkowania obliczeń do wykonania.

Ów zagadnieniem zajmuje się dziedzina algorytmiki HPC, czyli opracowywania sposobów przeprowadzania obliczeń wysokiej wydajności. Silnik Stylo opracowano z wykorzystaniem strategii planowania dla zadań dynamicznie wielowątkowych, zwanej "work stealing", w której poszczególne wątki (workery) pracują nie tylko nad tym, żeby skończyć swoje zadanie, ale również nad tym, by optymalnie rozdzielić pracę wciąż znajdującą się kolejce. Istnienie układów wielordzeniowych i hiperwątkowych, a więc niska sprzętowo cena dostępu do przetwarzania równoległego, sprawia, że tolerowanie leniuchujących wątków jest zbrodniczym marnotrawstwem. A więc Firefox dotychczas był już wielowątkowy, ale tym razem będzie mądrze wielowątkowy.

Nowa implementacja wymaga nie tylko nowego algorytmu, ale i nowego języka. Więc, ponownie wskutek osiągnięć eksperymentu Servo, obok języka C++ w Firefoksie pojawił się Rust. Środowisko uruchomieniowe Rust, poza obcięciem listy platform, na które przeglądarka będzie dostępna, dostarcza możliwości znacznie łatwiejszego wprowadzania zadań obliczanych równolegle. Rust ma wielką zaletę związaną z pilnowaniem typów i dostępów do pamięci, znaną pod potoczną nazwą „niebycie C++”. Autorzy chwalą się, że połączenie nowego podejścia i narzędzi sprowadziło problem nakładania stylu CSS to kategorii zadań zawstydzająco podatnych na zrównoleglenie („embarrasingly parallel”), od czego już tylko krok do niemal liniowych przyspieszeń przy skalowaniu. Poza owymi usprawnieniami skorzystano z wiedzy innych i wprowadzono bufor podręczny dla wspólnych elementów stylu, znany z silnika WebKit.

Jeżeli już jesteśmy przy przetwarzaniu wielowątkowym, koniecznie należy wspomnieć o drugim elemencie projektu Quantum, jakim jest silnik rysujący akcelerowany przez procesor graficzny (GPU). Mechanizm [url=https://wiki.mozilla.org/Platform/GFX/Quantum_Render]WebRenderer, wykorzystany w Quantum i ponownie zaczerpnięty z Servo, zastąpi kolejny fragment wysłużonego Gecko i tym razem będzie to kompozytor strony, czyli programistyczny „malarz”, odpowiedzialny na dostarczenie przed nasze oczy narysowanej strony. Podobnie, jak w przypadku CSS, zmiana jest konceptualnie prosta (i genialna), ale wymaga gruntownej przebudowy, czy wręcz napisania komponentu od zera. W przypadku WebRenderera, zmiana polega na porzuceniu dotychczasowej komunikacji z grafiką, w której każdy etap rysowania i każda zmiana stanu była zdarzeniem wysyłanym do narzędzia rysującego krok po kroku. Obecnie zostanie wykorzystany tryb wstrzemięźliwy („retained”), który czeka, aż scena, czy też model, zostanie w pełni przygotowana i opisana logicznie i dopiero wtedy informuje układ graficzny „proszę, narysuj mi takie coś”. Wydaje się, że bezpośrednia komunikacja z grafiką będzie szybsza, bo od zdarzenia do efektu droga jest najkrótsza. Jest to jednak mylne wrażenie, a prawda w tej kwestii leży w poprzek intuicji. Otóż znacząco wydajniej jest przygotować model wcześniej, następnie przetworzyć go pod kątem tego, jak w najwydajniejszy sposób rozkazać jego narysowanie karcie graficznej, a dopiero na końcu wysłać samo żądanie stworzenia obrazu.

Wbrew temu, co niegdyś wygadywał namiętnie cytowany Edsgar Dijkstra, informatyka czasem jednak jest nauką o komputerach i świadomość tego, jak działa sprzęt jest całkiem przydatnym uzupełnieniem wiedzy z zakresu złożoności obliczeniowej. Zgodzą się tutaj ze mną elektronicy, a sama kwestia jest dobrym wytłumaczeniem subtelnych różnic w myśleniu techników, doktorów i inżynierów - prawie, jak w tym dowcipie. WebRenderer nie będzie gotowy jeszcze przez kilka tygodni, ale wersja 57 zawiera już spore jego części. Wydanie testowe zawiera całość, ale wyłączoną.

Kolejną częścią Quantum jest nowy planista dla dokumentów DOM. Tym razem jest to usprawnienie z cyklu „hm, powinniśmy byli o tym pomyśleć wcześniej” i jest blisko związane z przeklętym projektem Electrolysis, mającym na celu zaopatrzenie Firefoksa w sesje wieloprocesowe, dostępne od lat w IE oraz Chromium. Wprowadzając podprocesy (tzw. satellite processes), uzyskuje się wszystkie zalety funkcjonalne systemowego planisty - to system operacyjny będzie zarządzał zasobami w optymalny sposób, ponieważ wreszcie będzie to w jego interesie. Jednakże wprowadzenie procesów nie oznacza równego podzielenia Firefoksa na zbiór procesów, wedle reguły „jedna karta - jeden proces”. Jest to nieco bardziej złożony problem, wymuszający istnienie procesu-korzenia, którego rolą jest więcej pracy, niż tylko spinanie wielu procesów pod parasol jednego UI.

Złożoność problemu sprawiła, że główny wątek w podprocesie dalej był przeładowany zdarzeniami. Co więcej, dobrodziejstwa systemowego planisty okazały się niewystarczające z punktu widzenia wydajności. Wydaje się więc, że projekt Electrolysis zwyczajnie nie został ukończony, skoro wprowadzenie podprocesów jednak nie przełożyło się na satysfakcjonujący skok. To jednak tylko wymachiwanie etykietkami: fundamenty dla procesów treściowych zostały dostarczone przez e10s i bez nich dalsza optymalizacja byłaby niemożliwa. Dopiero teraz powstała szansa na usprawnienia w tworzeniu modelu DOM. W ramach Quantum, dokonano klasyfikacji rodzajów zdarzeń tak, by pomóc wewnętrznemu planiście przydzielać zasoby w sposób nieblokujący i zachowujący porządek wywołania. Może to nierzadko oznaczać całkowite wstrzymanie wykonania niektórych zadań, celem zachowania płynności pracy na głównym wątku. Detale dotyczące grupowania zadań (oraz wgląd w ogrom pracy wykonanej na owym polu) i mechanizmu TabGroup przybliża na swoim blogu Bevis Tseng z Mozilli.

Rewolucje są kontrowersyjne i wzbudzają głośny sprzeciw. Ostatnia wielka zmiana, wykonana w ramach projektu Australis, została (możliwe, że całkiem słusznie) nazwana „Chromifikacją”. Firefox, jak ostatnia główna przeglądarka porzucił trend zawierania kontrolek w pojedynczym narożnym przycisku centralnym. Trend, który sam zapoczątkował. Tym razem jest inaczej. Co prawda „chromifikacja” dalej postępuje, czego dowodem jest wprowadzenie niedawno mechanizmu WebExtensions, ale projekt Quantum nie jest kolejnym krokiem upodabniającym przeglądarkę do produktu Google. W kwestii UI zaszła wręcz „Edge-ifikacja”, ale wiele osób może tego nie zauważyć, bo przecież nikt nie używa Edge’a. Kolejne przeszczepy z Chromium grzecznie jednak czekają w kolejce, a wśród nich aktualizacje obsługi pamięci podręcznej parsera CSS oraz „piaskownicy” dla podprocesów. Chromium zyskało zatem pozycję referencyjnej implementacji przeglądarki internetowej, jak niegdyś W3C Amaya. Konkurenci ograniczają się do samodzielnych implementacji rozwiązań Google. Albo nie robią nawet tego, inkorporując bezpośrednio silnik WebKit. Istotnie przeglądarki WWW stały się szalenie skomplikowanymi produktami, a praca nad nimi - nadludzkim wysiłkiem, ale gdy różnice między przeglądarkami zatrą się, może nam grozić monopol jednego silnika, a w konsekwencji spowolnienie innowacji. Może to być obawa na wyrost, bowiem dzisiejsze realia nie przystają do ostatniego razu, gdy coś takiego miało miejsce (IE6). Ale silna polaryzacja myśli jest niezdrowa, nie wspominając o tym, że programistyczne monokultury są niebezpieczne, bo sprzyjają rozpowszechnianiu szkodników. Oby więc modernizacja Firefoksa celem zwiększenia konkurencyjności nie zaowocowała kolejnym Chromem w przebraniu.

Skąd w ogóle taka potrzeba remontów? Google Chrome, mimo miliardowego numeru wersji, nie wydaje się ulegać aż takim przeobrażeniom. Chrome jednak nie musi się rozprawiać ze swoją przeszłością. Sam nie jest nowy, niedługo zostanie dziesięciolatkiem, ale Firefox to przy nim kosmiczny staroć. Noszący w sobie plątaninę wieloletnich rozwiązań, niedostosowanych, jak się okazało, do dzisiejszych, mobilnych czasów. Stąd też wojna Firefoksa z własną przeszłością - okresem pradawnym, gdy na świecie królował Netscape, a za doskonałą postać przeglądarki uznawano formułę Komunikatora.

Choć możemy tego nie odczuwać gdy uruchamiamy dzisiejszego Firefoksa (zwłaszcza odtwarzającego poprzednią sesję), ale on sam powstał jako projekt optymalizacji. Był czymś w rodzaju Quantum, ale dla Mozilli. Przeglądarka Mozilla marki Mozilla była właśnie takim Komunikatorem. Ciężką bryłą, jednoprocesowym(!) molochem, składającym się z „przeglądarki właściwej”, programu pocztowego, książki adresowej, kompozytora stron (wykorzystywanego również jako edytor poczty HTML) i klienta czatu IRC. Wraz z upływem lat okazywało się, że program wykorzystuje zbyt wiele zasobów, jego rozwój jest frustrująco skomplikowany, a użytkownicy końcowi bardzo często używają tylko jednego z jego komponentów. Zapadła decyzja o wydzieleniu komponentu przeglądarki z Komunikatora, by przyspieszyć jego rozwój. Ostrzejsza dyscyplina w separacji silnika od UI miała ułatwić portowanie zmian z powrotem do Mozilli. „Twardy fork” to jedna z wielu tzw. błędnych-ale-nieuniknionych decyzji. Co prawda zmarnowano (możliwy do uratowania) potencjał projektowy formuły Komunikatora, co doprowadziło wkrótce do zakończenia projektu, ale zrodzona w bojach Mozilla Firefox okazała się zawrotnym sukcesem, który zagroził dominacji Internet Explorera 6. Pierwsza wersja stabilna została wydana w listopadzie 2004, po dwukrotnej zmianie nazwy. Nazwa Phoenix została podważona przez producenta BIOSu, a Firebird - przez twórcę bazy danych o tej samej nazwie. W promocji, poza niewątpliwą przewagą funkcjonalną nad IE6 i brakiem chaosu z Komunikatora, pomogło logo stworzone przez [url=https://hicksdesign.co.uk/journal/branding-firefox]Jona Hicksa[/url, na bazie pomysłu Daniela Burki.

Produkty Mozilli wyglądały ładnie, profesjonalnie. Działały też o wiele żwawiej, niż IE6, którego silnik skryptowy był żałośnie powolny w porównaniu z Firefoksem i w dodatku niezgodny ze standardami, co spowalniało rozwój web-aplikacji. Firefox wpędził konkurentów w zakłopotanie, a po pięciu latach stał się najpopularniejszą przeglądarką na Ziemi, przejmując 1/3 rynku. Komunikator Mozilla Application Suite utracił miano głównego produktu Fundacji, przekazano go pod opiekę społeczności (pocałunek śmierci), i wszystko postawiono na Firefoksa. W międzyczasie powstał projekt Thunderbird, który polegał na wydzieleniu komponentu pocztowego z Komunikatora. Thunderbird (comm-central) to tak naprawdę Mozilla z wyrzuconą przeglądarką, a nie wydzielony moduł pocztowy. Pójście drogą modularyzacji mogłoby uratować formułę Komunikatora, ale dziś są to tylko mądre rady po czasie. Walczenie o Application Suite za wszelką cenę, kosztem gigantycznych opóźnień związanych z oczekiwaniem na modularyzację, było bez sensu i w istocie oddalałoby od stworzenia dobrej, lekkiej przeglądarki w imię idealizmu projektowego, który wcale w dodatku nie obiecywał sukcesu.

Problemy zaczęły się w okolicy 2010 roku. Google zaprezentował światu swoją ultraszybką, idiotoodporną i niewidzialną przeglądarkę Chrome, rozwijaną zwinnie i z wigorem garażowego start-upu. Dotychczas przeglądarki nie były tworzone w taki sposób, kojarzony głównie z ambitnymi, ale małymi projektami i semi-hipsterskimi aplikacjami internetowymi. Wersja 3.6 Firefoksa, przez wielu dalej uznawana za najlepszą, czekała na następcę dwa lata, podczas których wykonano dużo ciężkiej pracy. W międzyczasie wydawano tylko nowe wersje „po przecinku”, podczas gdy Chrome otrzymał kilkanaście głównych wersji. Wydanie 3.7 Firefoksa zostało w końcu opublikowane jako 4.0 - od tego czasu używam Firefoksa w wersji Nightly i pamiętam, jakim przemianom uległ na przestrzeni dwóch lat. Codzienne, duże aktualizacje pokazywały, że Mozilla wykonuje kawał dobrej inżynierskiej roboty. Ale to Chrome, ze swoim zwinnym modelem wydawał nowe wersje, o coraz wyższych numerkach, niemal co kilka dni, przyciągając coraz więcej użytkowników, kusząc ich w dodatku wędrowaniem zakładek, haseł i historii oraz integracją z coraz popularniejszymi smartfonami z Androidem.

Firefox nie mógł zaoferować takiej skali integracji. Brendan Eich napisał co prawda bardzo dalekosiężny plan rozwoju przeglądarki, czego wizja uległa materializacji właśnie w Firefoksie 4.0, obsługującym WebGL, CSS 3 i wiele nowych komponentów HTML5, ale mocno odczuwalnym było, że jest to planowanie rodem z dawnych czasów. Przyszedł moment na kolejną błędną-ale-nieuniknioną decyzję. Decyzję, bo przegonić Chromium.

Chrome od początku oferował rzeczy, o których w Firefoksie nie pomyślano. Były to takie wynalazki jak wieloprocesowość i piaskownice. Mozilla stała się ofiarą swojego sukcesu - wydzielenie i przyspieszenie przeglądarki z Komunikatora było przecież Tym Genialnym Pomysłem, który miał rozwiązać wszystkie problemy i uodpornić rozwój na znoje przyszłości. Był „wystarczającą rewolucją”, nie było ani sił ani nawet pomysłu wprowadzać podział na procesy - chcesz pan multiprocesowość, to sobie proszę drugie okienko otworzyć. Bam! Jest multiprocesowość! Piaskownice? Jakie piaskownice? Czyżby ktoś korzystał z systemu tak niebezpiecznego, że nawet paski przewijania są rysowane przez jądro i potrzebna jest aż taka skala izolacji? (Swoją drogą, Firefox na Windows osiem lat temu przez chwilę przeganiał natywnego Firefoksa z Linuksów - nawet, gdy ten pierwszy był uruchamiany przez Wine).

Można więc ponownie być prawilnym i przekonywać cały świat, że jedna wersja na dwa lata to dobre i sprawdzone podejście, albo przyznać się przez lustrem do tego, że konkurenci wygrywają nawet, gdy nie mają racji i trzeba coś z tym zrobić. Dlatego odpalono moje ulubione agile’owe straszydło: karuzelę numerów wersji. Formalnie miała ona odzwierciedlać nową metodykę pracy, w której kolejne zbiory funkcjonalności szybciej lądują w głównej gałęzi. W praktyce jednak chodziło o zwiększenie numeru - Chrome był na tyle pływający i pozbawiony wieloletnich narośli, że bardzo często podmiana jakiegoś podzespołu faktycznie uzasadniała zmianę numeru wersji np. z 15 na 16. Ale Firefox nie był zbudowany w ten sposób. Firefox 12 mógł więc z powodzeniem być w środku Firefoksem 4.8 - no ale jak to brzmi!

Gonitwa za Chromem rozkręciła się na dobre: usunięcie pasków narzędzi, automatyczne aktualizatory, zablokowanie binarnych wtyczek opartych o NPAPI, wsparcie dla protokołu SPDY, Speed Dial, migracja-wędrówka zakładek przez Pocket, wbudowany komunikator (niezgodny z Hangouts z Chrome), telemetria, wbudowany czytnik PDFów, własnościowe kodeki do odtwarzania multimediów, Do-Not-Track, WebRTC, wyszukiwanie z paska adresu..... Dosłownie każda z tych funkcji to kalka Chrome. Pojawiły się głosy, że niedługo Firefox w ogóle pójdzie drogą Opery i wyrzuci swój silnik rysujący Gecko na poczet Blinka lub WebKita, a Mozilla zajmie się jedynie rozwijaniem interfejsu użytkownika pełnego zbędnych drobiazgów, których nikt nie używa. Aż pewnego dnia w 2020 roku, cichy aktualizator, jako wersję 100 Firefoksa pobierze po prostu Google Chrome.

Miliony użytkowników Firefoksa, nie mówiąc już o tych pamiętających czasy Komunikatora, wyrażały swoje niezadowolenie, że oto Firefox traci swoją tożsamość i zmienia się w Chromium. A plan na przyszłość to „planowanie na porażkę” i założenie, że nie warto robić nic własnego, a jedynie iść w ślady Google. Tez zdarzało mi się myśleć w ten sposób. Okazuje się jednak, że jest to niemerytoryczny argument, ukazujący jedynie potęgę siły przyzwyczajenia, które wygrywa nawet wtedy, gdy alternatywne rozwiązania techniczne są lepsze.

Wszystkie wyżej wymienione cechy Firefoksa zaczerpnięte z Chrome to tak naprawdę lepsze pomysły niż to, co było dostępne dotychczas. Zmiana interfejsu wynika z konieczności poprawnego wyświetlania na szerokiej gamie ekranów o różnych wymiarach i rozdzielczościach, pasek adresu od lat zachowuje się tak samo, jak pasek wyszukiwania, tylko jakoś nikt nie jest tego aktywnie świadom (nawet, gdy sam korzysta z tej funkcji), a głośne, wymagające uwagi aktualizatory to już czysty „circle-jerk” i zasypywanie użytkownika komunikatami z dziedziny „kompletnie zbędne, ale fajne”. Większość aspektów chromifikacji to tak naprawdę implementacja zwyczajnie lepszych pomysłów, których nie da się wymyślić lepiej. A pod spodem i tak znajduje się przeglądarka fundamentalnie niezgodna z Chrome i tak naprawdę - z niczym innym.

Problemy pojawiają się tam, gdzie następuje implementacja pomysłów o nikłej szansie na sukces. Synchronizacja Pocket uchodzi za naturalną funkcję, ale komunikator Hello to już przesada. Wbudowany czytnik PDF również budził wątpliwości, zwłaszcza, gdy renderował PDFy nieprawidłowo (gdy otwierałem na studiach swój plan zajęć w 2013 roku, Firefox ukrywał przede mną zajęcia z termodynamiki, pozwalając mi żyć w błogiej nieświadomości i usprawiedliwiając nieobecność na wykładach). Problematyczne funkcje nie zostały dodane „tylko dlatego, że Chrome już to ma”, a wskutek błędnego założenia, że bez nich nie będzie się istotną konkurencją. Mozilla nie ma dostępu do telemetrii Google’a więc nie wie, ile osób tak naprawdę korzysta z Hangoutów (trzy). Więc dodaje własny komunikator, by mieć zbliżoną ofertę funkcjonalną.

Naczelnym dowodem na wadliwość takiego rozumowania był Firefox OS. Niech każda osoba na widowni podniesie rękę, jeżeli jednak nie myślała sobie „przecież to nie ma szans się udać, cóż to za gigantyczna strata czasu”. Proszę się nie wstydzić. Firefox nie został kolejnym „ekosystemem” na modłę ustroju Google + Android + Chrome. Ale nie musiał i nigdy nie mógł. Tego typu decyzje, połączone z rozwojem produktu wyglądającym na kopiowanie Chromium, prowadzą do kryzysu wizerunkowego. Wprowadzane innowacje wydają się niewidzialne, a powierzchowne zmiany uchodzą za kalkomanię. Problem polega na tym, że niewiele da się już wymyślić w kwestii tego, jak ma wyglądać przeglądarka internetowa. Alternatywy wyglądają w podobny sposób niekoniecznie dlatego, że kopiują Chrome, ale dlatego, że inne podejście jest cudaczne. Owszem, dawny wygląd Firefoksa 2.0, Mozilli 1.5 czy nawet Internet Explorera 5 wielu wydają się znajome i sympatyczne, a przede wszystkim „inne od Chrome”, ale to wcale nie znaczy, że mają sens. O tym właśnie mowa w potędze siły przyzwyczajenia. Zauroczeni relatywnie wysoką funkcjonalnością Firefoksa, twierdzimy, że wszystko, co firefoksowe jest dobre - stąd tęsknota za dawnymi rozwiązaniami nawet, gdy marnują obszar na ekranie albo oferują absurdalnie rozległą i trudną w utrzymaniu dowolność w adaptacji, z czego korzysta 3% użytkowników.

Firefoksowi nie pomaga też zamieszanie światopoglądowe. Brendan Eich był szefem Mozilli krócej, niż Jan Paweł I był papieżem, bowiem ze stanowiska katapultował go ferment wokół jego opinii na temat małżeństw jednopłciowych. Eich, nota bene współzałożyciel Mozilli, udzielił dotacji dla organizacji sprzeciwiającej się legalizacji takich małżeństw, co zostało odnalezione przez niektórych członków społeczności i poskutkowało ograniczonym, ale oczywiście głośnym, bojkotem. Eich musiał zrezygnować ze swojego stanowiska, a na witrynie wsparcia technicznego Mozilli pojawiło się pytanie „czy wolno mi używać Firefoksa, jeżeli nie popieram legalizacji małżeństw homoseksualistów”. Wiele grup interesów odtrąbiło sukces, a wielu użytkowników uznało tę decyzję za skandaliczną i kompletnie niezwiązaną z samym produktem.

Sęk w tym, że to nieprawda. Szef Mozilli nie ma wpływu na decyzje techniczne. Nie rozkaże on implementować tęczowego filtra na elementy WebM, aby manifestować poparcie dla adopcji sojowego dżender przez wegańskie poliamoryczne związki partnerskie transpłciowych jenotów-cyklistów, jak niektórzy dziarsko przestrzegają. Nie tym zajmuje się fundacja. Mozilla, szczególnie pozbawiona finansowania swojego głównego sponsora (który postanowił przecież zrobić własną przeglądarkę), realizuje trudne zadanie popularyzacji wolnego oprogramowania ze wstawkami własnościowymi i chronionym znakiem towarowym. Dlatego musi być „inclusive” i reprezentować podejście szerokiej akceptacji, by przyciągnąć jak najwięcej osób. I pieniędzy. Pójście w poprzek tego trendu jest zwyczajnie nieopłacalne, więc los Eicha powinien być rozpatrywany z brutalnym, menedżerskim pragmatyzmem. Wystarczy spojrzeć na mapę drogową projektu, by przekonać się, że misją fundacji jest „budować wielopłaszczyznowe, tolerancyjne środowisko zorientowane na człowieka w centrum uwagi, zgodnie z misją statutową i naszym manifestem” - z tym, że następnie padają zwykłe detale techniczne, zapewne identyczne z tymi, jakie spisano by, gdyby Mozilla pracowała nad Gwiazdą Śmierci.

Firefoksowy Quantum to kolejny z doskonałych pomysłów, które mogą przejść niezauważone, ewentualnie wzbudzić sprzeciw związany ze zmianą UI i zwyczajową falę komentarzy zarzucających dalsze upodabnianie do Chrome’a. Zmiany są jednak odczuwalne i pozytywne, zarówno w kwestii wydajności, jak i stabilności (która ostatnimi czasy szwankowała w wersjach testowych). Mój Nightly, codziennie aktualizowany do folderu o wciąż niezmienionej nazwie „firefox-3.7a1pre”, jest w pełni wartościową alternatywą dla Chrome, od którego - pamiętajmy - w dalszym ciągu mocno się różni.

Nowy Firefox dostępny jest w w naszej bazie oprogramowana.