Chciałbym przy okazji nieskromnie zwrócić uwagę czytelników na niesamowitą robotę jaką wykonuje w Polsce zespół Aviary.pl, a w szczególności lider zespołu – Hubert Gajewski oraz lider lokalizacji Firefoksa – Marek Stępień. To dzięki tej pracy polska lokalizacja jest tak wysokiej jakości! 🙂
Podobnie jak w przypadku wydania Firefoksa 3, wydanie Firefoksa 3.5 wzbudza duży rozgłos medialny. 🙂
Dla nas, uczestników projektu Mozilla to moment wytchnienia. Wszystko co zrobiliśmy przez rok zostało właśnie skompilowane, umieszczone na serwerach i jest aktualnie testowane przez społeczność testerów z całego świata. 74 wydania językowe, 3 platformy, kilkaset nowych funkcji, wszystko to musi zostać dokładnie przetestowane zanim uznamy, że ta właśnie wersja kodu źródłowego stanie się finalnym wydaniem Firefoksa.
Ze względu na naszą otwartą naturę projektu, wszystkie kompilacje są publicznie dostępne na serwerach i już od rana dziennikarze pobierają te kompilacje i ogłaszają, że to wydanie finalne.
Miałem przyjemność udzielać krótkich wywiadów dotyczących wydania dzisiaj i za każdym razem tłumaczyłem specyfikę działania naszego projektu i konsekwencje tego dla wydań.
Mechanizm działa tak:
Kompilacja, która leży na serwerach od rana jest właśnie testowana. Jeśli przejdzie proces finalnych testów to zostanie ona uznana za stabilną i wydana. Jeśli zostanie znaleziony poważny błąd, i menedżer wydania zdecyduje, że blokuje on wydanie, to zostanie on poprawiony, źródła zostaną przekompilowane i proces testowania powtórzony.
Prośba
Jeśli ktoś ściąga wydanie zanim pojawi się o nim informacja na naszych stronach to pobiera wydanie jeszcze nie przetestowane. To może być wydanie finalne, ale nie musi. Proszę, wszyscy którzy piszecie o “wydaniach znalezionych na serwerach” – informujcie ludzi o ryzyku związanym z pobieraniem takiego wydania. To ważny element budowania świadomości użytkowników i to ważne, aby oni sami wybierali czy chcą podjąć ryzyko.
Od czasu pojawienia się Chrome, temat korzystania z wielu procesów do wyświetlania stron w przeglądarce stał się jednym z ważniejszych przy porównywaniu przeglądarek.
Co więcej, wbrew uwagom samych autorów, powszechnie zaczęto uznawać to jako tzw. “feature” – funkcję, której posiadanie jest bezwględnie objawem przewagi danej przeglądarki nad inną.
Sam przetestował Operę, Firefoksa, Safari i Chrome podczas wczytywania 150 najpopularniejszych stron z rankingu Alexa.com. Opublikował też wyniki w postaci tabeli najwyższego i najniższego zużycia pamięci przez różne przeglądarki.
Sam wykres jest na pewno ciekawy, ale jeszcze ciekawsze są jego implikacje, które potwierdzają pierwsze komentarze jakie pojawiły się w społeczności pracującej nad Gecko po wydaniu Chrome.
Dlaczego tak się dzieje? Wykorzystanie wielu procesów oznacza, że 10 kart z otworzonym google.com będzie dziesięć razy ładować absolutnie wszystko konieczne do wyświetlenia tej strony. To zaś oznacza znaczące koszty w wykorzystaniu pamięci. W “tradycyjnym” modelu, pamięć jest współdzielona i obrazki, struktury danych oraz bloki używane do rysowania układu strony mogą być współdzielone. Nawet obiekty używane do wyrenderowania strony, mogą zostać utworzone raz i uruchamiane podczas rysowania różnych stron.
Tymczasem w przypadku modelu w którym każda strona (czy karta) ma swój proces, musi ona praktycznie załadować do pamięci całą przeglądarkę – a przynajmniej cały kod potrzebny do obługi jednej strony. To kosztuje i to wcale nie mało.
Białe strony
Czy to oznacza, że programiści Chrome popełnili błąd decydując się na taką zmianę? Nie. Oni po prostu zdecydowali się zapłacić taką cenę, za liczne udogodnienia jakie daje rozdział procesów.
Najważniejszym, i pewnie najbardziej zrozumiałym jest możliwość izolacji procesu na wypadek problemów. Jeśli strona spowoduje poważny błąd, będzie to tylko błąd tej karty, a nie całej przeglądarki. Nie stracimy pisanego od godziny listu i nie będziemy musieli uruchamiać wszystkiego od nowa. To duża wygoda.
Inną sprawą jest rozdzielenie pamięci. Strony można uruchamiać w tzw. “piaskownicach”, gdzie są oddzielone od sektorów pamięci wykorzystywanych przez przeglądarkę. W takiej sytuacji nawet jeśli w przeglądarce znajdzie się błąd bezpieczeństwa, to jego wykorzystanie praktycznie zawsze będzie ograniczone do manipulacji danym procesem, a nie całą przeglądarką czy systemem operacyjnym. To ważne udogodnienie.
Istnieją inne, jak łatwe wykorzystanie wielu procesorów i przeniesienie na system operacyjny zarządzania przydzielaniem procesom cykli procesora, co oznacza, że z łatwością można określić, że przeglądarka ma wyższy priorytet niż, np. filmik na youtube i nie będzie on już “przycinał” jej.
Szukanie balansu
W Mozilli powstał specjalny projekt, który eksperymentuje z wykorzystaniem wieloprocesowości. Pierwsze eksperymenty są już testowane i poniżej prezentuję filmik od Chrisa Blizzarda z demonstracji tej technologii:
Najważniejszym jednak pytaniem jest jak wykorzystać wieloprocesowość, aby zmaksymalizować zyski i zminimalizować koszty. Jednym z pomysłów jest uruchamianie rozszerzeń w osobnych procesach – to zwiększa bezpieczeństwo i pozwala oddzielić stabilność aplikacji od rozszerzenia, ale kosztem pamięci. Innym pomysłem jest wydzielenie procesów na wtyczki, ponieważ w nich często znajdowane są błędy bezpieczeństwa a także one najczęściej zawieszają przeglądarki.
Jeszcze innym jest utrzymywanie silnika renderującego w osobnym procesie a stron w osobnych. Wówczas strona wysyłana by była przez kartę do procesu renderującego, który zwracałby wyrenderowaną. W takim układzie karty są niezależne, jeśli jakaś operacja na jednej spowoduje błąd to nie dotknie on innych, a zużycie pamięci nie powinno ucierpieć, ponieważ kod renderujący byłby współdzielony. Niestety taki układ nie daje tych samych zalet w zakresie stabilności. Jeśli silnik rednerujący wyłoży się na jednej stronie, to padnie cały. Jeśli jednak będzie osobnym procesem, to nie przełoży się to na przeglądarkę…
Generalnie temat do rozważań jest potężny i jest mnóstwo miejsca na eksperymenty. Jeśli ktoś jest zainteresowany pracą zespołu, to zapraszam na serwer irc.mozilla.org, kanał #content.
Spring is almost over, and I had no time to update my diary too much.
So today I decided to give the new WordPress 2.8 theme management system a try, and switch a theme to something new.
W marcu napisałem krótką notkę na temat moich odczuć związanych z powrotem Microsoftu do konkurowania w dziedzinie przeglądarek.
W notce starałem się opisać takie moje dziwne odczucie. Przez ostatnie lata Microsoft praktycznie nie wypowiadał się w dziedzinie którą zajmuje się najbardziej. Oczywiście, zdażało mi się znaleźć wypowiedzi Ballmera n/t Apple (ot, na przykład, do Guya Kawasaki, że MacBook Air to chłam i powinien kupić sobie porządny laptop z Vistą), ale było to jakby daleko ode mnie…
Całe szczeście, że doczekaliśmy się czasów, gdy o tym co dzieje się w projektach Internetowych informują media mainstreemowe, portale społecznościowe, mikroblogi, a nawet mozillowo-zorientowany foxinews. Szczęście, bo gdyby ktoś chciał sądzić o aktywności projektu po planecie MozilliPL, to trudno byłoby się czegoś dowiedzieć.
Sam mam niestety mało czasu (tak, tak, sesja…), ale spróbuję w telegraficznym skrócie, w losowej kolejności, opisać kilka tematów dla zainteresowanych:
Wydanie Firefoksa 3.5 zbliża się wielkimi krokami. Tym razem, w odróżnieniu od naszej tradycji, chcielibyśmy, aby wydanie RC faktycznie było kandydatem na wersje finalną. Koniec z wydawaniem RC1 i planowaniem trzech następnych równocześnie… Jak coś jest kandydatem na wydanie, to ma być gotowe. Dlatego Mike (Beltzner) i Mike (Shaver) bardzo poważnie uparli się, że nie będzie RC2. No, chyba, że niebo spadnie nam na głowy.
Nowy addons.mozilla.org. A w nim – łatwiejsza nawigacja, wygodniejsze zarządzanie i nowa funkcja – Kolekcje – która umożliwia tworzenie własnych zestawów rozszerzeń i motywów. W przyszłości mamy nadzieję zaoferować Ci możliwość spakowania takiej kolekcji i wydania jako własnego Firefoksa.
Projekt hack.mozilla.org – przez 35 dni zostanie zaprezentowanych 35 nowych funkcji dla webmasterów, które pojawią się w przeglądarkach nowej generacji – Firefoksie 3.5, następnej Operze, Safari i Chrome.
Thunderbird 3.0beta3 zbliża się. Została jedna duża rzecz (globalne wyszukiwanie), która powinna wylądować w ciągu tygodnia i potem już przygotowania do wydania.
Trwają prace nad Firefoksem 3.0.12. Tradycyjnie, kilka poprawek wydajności, kilka bezpieczeństwa i kilka błędów zwykłych.
Zespół Aviary.pl przygotował polskie tłumaczenie Poradnika Recenzenta do Firefoksa 3.5. Będzie to mała książeczka z opisem nowych technologii i funkcji jakie będą dostępne dla autorów stron WWW i użytkowników wraz z nowym Firefoksem.
Zaczęły się przygotowania do planowanego na wrzesień Tygodnia Mozilli (po angielsku – Mozilla Service Week, ale niestety brzydko brzmi tłumaczenie dosłowne). Będzie to kampania trochę podobna do banków czasu – chcemy zachęcić ludzi posiadających zdolności techniczne do pomagania osobom mniej uzdolnionym i potrzebującym pomocy. W ramach tej kampanii będziemy szukać chętnych do prowadzenia wykładów na temat obsługi Internetu, osoby chcące pomóc z konfiguracją Internetu, lub w inny sposób pomóc bliźniemu. 🙂
Pierwsze prace nad Firefox.Next – tutaj zidentyfikowaliśmy 35 błędów, których rozwiązanie sprawi, że Firefox będzie reagował szybciej przez co poprawi się wrażenie z interakcji z przeglądarką. Błędy takie oznaczamy TSnap. W przyszłym tygodniu w trunku wyląduje Canvas3D, a zespół odpowiedzialny za layout zaczął prace nad XBL2. O innych planach na Firefox.Next można przeczytać na Wiki.
Seamonkey 2.0b1 powinno wyjść w ciągu tygodnia.
Microsoft wstępnie ogłosił, że zamierza wydać Windows 7 bez IE w Europie. Bardzo trudno okreslić, czy to jest właściwy ruch. Mitchell świetnie podsumowała (jeszcze przed tą decyzją) jak ten dylemat wygląda z naszej strony. Ja mam bardzo mieszane odczucia. Nie do końca rozumiem co Microsoft zdecydował tak naprawde (co dokładne oznacza “we will offer it separately”?) i mam poważne wątpliwości, czy wydawanie w 2009 roku systemu operacyjnego bez przeglądarki jest dobre dla użytkowników.
JestPack to nowy projekt z Mozilla Labs będący kontynuacją idei projektu FUEL – budowania łatwych klocków z których można tworzyć rozszerzenia. JetPack pozwala tworzyć rozszerzenia korzystając wyłącznie ze znajomości technologii webowych – HTML, JS, CSS.
Projekt Personas – rozszerzenia pozwalającego na łatwe zmienianie motywów Firefoksa bije rekordy popularności. Nigdy nie sądziłem, że coś może przebić popularność AdBlocka 😉
Projekt Weave rozwija Mozillowe podejście do “chmury” pozwalając synchronizować swoje dane z przeglądarki między komputerami, ale w sposób zaszyfrowany, tak, aby ten kto hostuje serwer Weave nie miał dostepu do Twoich danych. W ostatniej wersji pierwsze eksperymenty z OpenID.
Bespin to z kolei edytor w “chmurze” – dostepny przez stronę WWW edytor kodu, który pozwala pracować nad projektem w grupie ludzi, a swoje projekty mieć dostępne z każdej maszyny bez potrzeby przygotowywania środowiska.
Kampania FastestFirefox zbiera filmiki ludzi robiących to co umieją najszybciej. Chcemy zebrać je razem i stworzyć kompilację ludzkich pasji związanych z szybkością, ciągle pracujących by być jeszcze szybszym – tak jak społeczność pracująca nad Firefoksem pracuje, by każdy kolejny Firefox był szybszy.
Wydaliśmy wersję 0.5 i 0.5.1 biblioteki do lokalizacji Silme. Adrian wraz z zespołem oraz Romi pracują teraz nad dwoma projektami korzystającymi z Silme. Projekt Adriana nazywa się Koala i będzie rozszerzeniem do lokalizacji do Komodo, a projekt Romiego to próba połączenia Silme z Narro.
Tak więc, dzieje się!
Staramy się jak najwięcej z tego przenieść do Polski, ale brakuje nam rąk do pracy. Jeśli jesteś zainteresowany/a pomocą, to szukamy na pewno chętnych do pomocy z:
SUMO. support.mozilla.com to strona z artykułami do pomocy osobom używającym Firefoksa. GmbH (mwawoczny at aviary dot pl) chętnie przyjmie pomoc 🙂
Eventy. Chcemy zorganizować kilka spotkań na temat technologii Web w Polsce. Szukamy osób chętnych do organizaci MozCampów, lub innej formy spotkań. Dzieje się dużo, jest o czym rozmawiać 🙂
I jak zawsze, mamy wakaty dla chętnych do tłumaczenia. Aviary.pl szuka tłumaczy, bo projektów nam się zrobiło co nie miara. Pamiętaj jednak, zanim wyślesz zgłoszenie, tłumaczenia to odpowiedzialna praca. A my chcemy być w tym najlepsi. 🙂
Z tego co wiem, nikt nie tłumaczy hacks.mozilla.org – jeśli ktoś jest zainteresowany, to z chęcią pomogę z organizacją tego 🙂
3 weeks after Silme 0.5 release, we’re proud to announce the first minor update to Silme – 0.5.1.
Silme 0.5.1 carries 5 changes, each of them making it a little better. In particular it fixes bugs that were blocking Adrian Kalla‘s version of compare-locales to get its first release.
New method: silme.diff.EntityList.has_entity() should make testing entities in diff faster
Two bugs in silme.io.jar that made it impossible to use
Performance improvements in silme.io.jar.get_package() (can we upload silme script to Fastest Firefox? ;)) by just ignoring to load zip entries for directories
We don’t close ZIP file in get_package if we didn’t open it there. It was a bug that caused silme.io.jar to fail with subpackages
Major rework of URI schema accepted in silme.io.jar. It is now possible to do:
ioc = silme.io.Manager.get('jar')
l10npack = ioc.get_package('jar:chrome/package.jar!locale/ab-CD/package')
This is the very first minor release in the history of Silme projects, and we’re happy to make it!
I’d like to thank Adrian who helped by identifying bugs and writing patches for this release. You may also want to check his newest project which uses Silme to create a sleek localization extension for Komodo! It’s called Koala 🙂
Next in line is Silme 0.7 which will bring new features and optimizations and we’re planning an alpha release to happen early next week. If you’re interested in hacking localization related code and never tried silme, it may be a good moment to give it a try and help us on the way to 0.7 🙂