Blur's page

Read more...

Kilka dni temu miała miejsce premiera Firefoxa 5.0. Mozilla próbuje ratować resztki dobrego imienia goniąc z numerami wersji za Chrome-m i rezygnując z zapowiadanych nowości na rzecz daty publikacji. Nowa wersja ma być głównie szybsza. Postanowiłem poświęcić chwilę i to sprawdzić.

Kompilacja

Jako, że ebuild wyposażony był w tajmniczo brzmiącą flagę "pgo" postanowiłem najpierw sprawdzić, cóż ciekawego ona kryje.

euse -i pgo

I okazało się, że pgo, to skrót od Profile Guided Optimization, czyli działania, które powinno dobrać mi najbardziej efektywne parametry optymalizacji.
I mimo, że aktywacja tej flagi rozciąga czas kompilacji ponad dwa razy, postanowiłem zaryzykować i zbudować sobie najszybszą możliwą wersję FF

Sam proces kompilacji przeszedł bez przeszkód, ale zaskoczył mnie gdzieś w połowie - uruchamiając mi firefoxa i przeprowadzając zautomatyzowane testy na wbudowanym webserwerze napisanym w pythonie (!). Po zebraniu danych (profilu) kompilacja rozpoczęła się od nowa.

Pierwsze uruchomienie

Mój standardowy test polegający na wciśnięciu "Alt+D", wpisaniu "wp.pl" i wciśnięciu "Enter" miło mnie zaskoczył. W ułamku sekundy wyświetliła mi się cała strona. Cała! Ze wszystkimi grafikami, odnośnikami itd. Tutaj słowa uznania dla E-Wro, ale również dla developerów Mozilli - Chrome potrzebuje na to samo znacznie więcej czasu (chociaż też radzi sobie bardzo szybko).

Zachęcony wynikami testu organoleptycznego postanowiłem sprawdzić przeglądarkę w kilku benchmarkach.

Wydajność JavaScript

W dobie sieci społecznościowych i tzw. "2.0" od przeglądarek wymaga się już nie tylko sprawnego wczytywania stron, ale również ich szybkiego renderowania oraz aktualizowania. Nie mam dobrych wspomnień FF 4.0, a już zdecydowanie nie pod Linuksem. Przeglądarka przy 2x2.5 GHz procesorze zwyczajnie muli. Robi to tak skutecznie, że nawet zastanawiałem się, czy nie robi tego mi na złość

Tak, czy siak, postanowiłem zrobić ponownie porównanie wydajności Firefoxa oraz Chrome-a, ponieważ akurat jego miałem pod ręką. Korciło mnie, żeby przetestować jeszcze wydaną dzisiaj Operkę Swordfish 11.50, ale najwyraźniej mam lenia

SunSpider

Wyniki Total:

Chrome - 479.9ms +/- 1.0%

Firefox 5.0 + PGO - 327.2ms +/1 1.1%

Dromaeo

Wyniki Total:

Chrome - 351.79 runs/s

Firefox 5.0 + PGO - 278.18 runs/s

V8 Benchmark suite

 Chrome - 5700

Firefox 5.0 + PGO - 2948

Wnioski?

Mimo, że nie zaskakuje wynik w benchmarku V8, pisanym do testów Chrome-a, to ciekawie wyglądają wyniki Dromaeo - benchmarku stworzonego przez Mozillę. Firefox wypada w nim znacznie wolniej od konkurencji.

Ponieważ przytomnie nie zrobiłem benchmarku FF4.0 nie wiem, na ile Mozilla przyspieszyła Liska, wiem jednak, że pomimo dobrego wrażenia na początku, Firefox ciągle nie jest demonem szybkości. To nie znaczy, że jest wolny, o nie! W tej dziedzinie palmę pierwszeństwa chyba już zawsze będzie trzymał M$ z ich smokiem - IE. Niemniej, do aplikacji internetowych ciągle lepiej użyć Chrome.

Zobaczymy, co przyniosą kolejne odsłony Ognistego Liska. Jedno jest pewne, dla nas, użytkowników będzie tylko lepiej

Enter.

O tym, jak M$ po raz kolejny sprawił bym cierpiał

Od opisywanej na flakerze historyjki o moich perypetiach z reinstalką Viśty minęło już trochę czasu. Niemniej, to właśnie dzisiaj musiałem wrócić do tamtych doświadczeń.
Potrzebowałem wysłać krótki dokument na sieciową drukarkę, dzielnie udostępnianą przez nasz serwerek. Wszystko byłoby super, gdyby nie mały mankament…

Każda próba dodania nowej drukarki sieciowej kończyła się wiele mówiącym błędem:

“0x0000000d”

Sprawdziłem konfigurację udostępniania drukarki, ba, zainstalowałem ją (bez przeszkód!) na moim lapie z Win7. Ale tutaj… Microsoft musiał udowodnić, że jego duch nie umarł  i nadal żyje w jedynym, najlepszym, emerytowanym systemie…

Rozpocząłem poszukiwania

Wujek Google na początku nie chciał się przyznać, czy można rozwiązać ten kłopot, ani z czego on wynika. Ciocia MSDN twierdziła że jestem debilem szukającym dziury w całym, ale udało mi się odnaleźć bratnią duszę.

Wygrzebałem ten wpis: http://blog.tempusdictum.com/index.php/gepr/uncategorized/windows-vista-using-a-cups-pdf-printer-hosted-on-debian, z którego wynika, że nie wiadomo co nie działa, ale wiadomo jak to obejść

Sposobem na durną Vistę jest przemapowanie portu drukarki do zdalnej lokalizacji za pomocą polecenia:

Gdzie "LPT2” to numer wirtualnego portu, który mapujemy, a \\SERWER\DRUKARKA to ścieżka do zdalnej drukarki.

Po tej operacji wystarczy zainstalować LOKALNĄ drukarkę na wybranym wcześniej porcie o voil’la! U mnie działa :]

UPDATE: W czasie poszukiwań obrazka do tego posta trafiłem na forum MS, na którym ktoś podał metodę rozwiązania problemu (a nie obejścia). Tu jest link:

http://social.answers.microsoft.com/Forums/en-US/vistanetworking/thread/818b7577-3b5a-4639-a636-e842ce8779aa

Wstęp

Dzisiaj oficjalnie otrzymałem w firmie “klucze” do biurowej sieci i serwerów, a jednym z pierwszych zadań było przygotowanie przestrzeni w sieci roboczej na wymianę dokumentów wewnętrznych.

Pomyślałem, że samba jest fajna, ale mamy już zdefiniowane grupy użytkowników do serwera WWW, więc żeby ich nie przepisywać wymyśliłem:
”Uruchomię WebDAV-a! Winda ma klienta wbudowanego, dokumenty można będzie ściągnąć ze zwykłej przeglądarki, no i ACL-e są już zdefiniowane”

Tak to się zaczęło…

Koffany Winblows

Z konfiguracją Apache nie było najmniejszych problemów, Dav On, kilka ścieżek, bam! Działa. To teraz sprawdźmy, czy śmiga zgodnie z przeznaczeniem… Próba na firmowej Viście, “Mapuj dysk sieciowy”, “Inna lokalizacja sieciowa”, wpisuję  URL i… ? Bam! Prosi o wybranie certyfikatu prywatnego (sic!) do logowania. Wciskam “Anuluj”, ponawia. Z pełnym już “O.o” na gębie, klikam “Anuluj” jeszcze raz. “Folder sieci web jest nieprawidłowy”.

Dziwne, ale cóż, to winda. Wrzucam hasło w Google-a i co widzę?

M$ od pierwszej Visty regularnie psuje foldery webowe w windowsach. W miarę kolejnych wydań service packów, czy edycji głównych usługa ta jest coraz gorsza. Serio, na początku była pełną, funkcjonującą implementacją, ale w Windows Vista SP2 i Win 7 już taką nie jest. Dla Visty rozwiązaniem jest instalacja KB 907306, czyli starszej (z Win XP) edycji folderów webowych. Działa to tak średnio, niemniej – działa. W przypadku Windows 7 rozwiązania problemu jeszcze nie udało mi się odnaleźć.

Jak objawia się “nie działanie”? Cóż – Windows pyta kilka razy o hasło (autoryzacja Basic HTTP-Auth, nawet IE to potrafi), a potem stwierdza że folder jest nieprawidłowy. Głupi user, znowu złego linka wpisał…

Okazuje się jednak, że to wina jakiegoś debila opłacanego przez M$, któremu popieprzyły się rodzaje autoryzacji i uznał, że jak klient łączy się po SSL, to będzie używał NTLM. Cóż. Błąd. SSL, a autoryzacja HTTP, i co? Już nie działa :/

Najbardziej wpienia mnie jednak fakt, że M$ będąc w pełni świadomym problemów nie robi z nimi absolutnie niczego. w artykułach KB piszą że znają problem, czasami napiszą że już nie występuje itd. Cóż, sprawdziłem na 3 wersjach windows: Windows XP SP3, Vista SP2 oraz Win7, pierwszy działa, drugi ze wspomnianą już łatką, trzeci za cholerę, a instalacja łaty powoduje tylko burdel w oknie “Komputer”, naturalnie nie sprawiając by WebDAV działał.

PS. Jeśli ktoś zamierza mi sugerować błąd w konfiguracji Apache, odsyłam do Google, poza tym – inne klienty WebDAV działają wyśmienicie.

PS2. Geniuszy zalecających przejście na HTTP “bo działa” odsyłam na drzewo.

Szkoda, że ten pomysł nie wypalił, nie mogę przecież zmuszać userów do instalowania dodatkowego softu obsługującego WebDAV, idea była taka, żeby usługa była transparentna dla nich. Trudno, wrócę do samby i jej ACL-i.

Enter.