Własny serwer!
Saturday, December 31, 2011 10:00:51 PM
Just because
Saturday, December 31, 2011 10:00:51 PM
Friday, August 26, 2011 8:03:43 PM
.pgoaktywowałem także
custom-cflags
Tuesday, June 28, 2011 6:07:04 PM
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.
Monday, June 13, 2011 8:07:26 PM
Dawno już nie popełniłem żadnego materiału pisanego, jednak Opera! Nie zapomniałem o was! Do powrotu nakłoniły mnie ostatnie przejścia z (ponowną) instalacją Gentoo na stacjonarce.
Zaczęło się niewinnieZmęczony już beznadziejną wręcz wydajnością Gentoo na stacjonarce (sam jestem sobie winien - było poligonem doświadczalnym) postanowiłem zaorać całość i postawić od nowa, przy okazji rezygnując z reiserfs na "/". Ten wpis jest historią mojej drogi przez mękę.
Pierwszym krokiem był format partycji, z zachowaniem /home oraz /boot (bo po co przekompilowywać znowu jajko?). Poszło gładko, wyciągnąłem z szafy stare SystemRescueCd, zbootowałem, zrobiłem co trzeba, przy okazji mając 64-bitowy kernel gotowy na chroota. Zassanie i instalacja stage3 podobnie odbyła się bez przeszkód, na koniec powpisywałem jeszcze sobie UUID-y partycji do fstaba.
RestartI... zonk. Kernel się podniósł bez błędu, ale.. INIT nie miał zamiaru powstać. Nie pomagały zmiany w linii argumentów jajka (init=), ani modły, ani groźby. Musiałem wrócić do chroota... Tam zaimportowałem config i przekompilowałem (a jednak :/) jajko, dla odmiany z aktywną opcją używania własnej (kernelowej) listy plików /dev w tmpfs.
Po jakimś czasie wszystko było gotowe do restartu, posprawdzałem jeszcze konfigurację gruba i... o ile jajo się podniosło, INIT również radośnie obwieścił swą obecność, to moim oczom ukazał się przecudny komunikat mówiący
Oczy mi wylazły, bo takich cudów jeszcze nie widziałem... Z systemem plików ext4 wszystko jest ok, nie ma prawa być na nim błędów, bo dopiero został utworzony - co jest? Po głębszej analizie (czytaj: kopiuj-wklej do Google) znalazłem informację o tym, że ext4 odmawia zamontowania w trybie do zapisu jeśli w jądrze nie ma zaznaczonego wsparcia dla "Huge files (2TB+) w Block layer.
Kolejny chrootPewny siebie zbootowałem po raz kolejny z płytki, utworzyłem środowisko i wpisałem magiczne "make menuconfig".
30 minut później przeglądałem pliki KConfig, bo szukanej przeze mnie opcji w jądrze 2.6.39-r1 nie było. Znalazłem ukrytą opcję i przejrzałem sekcję zależności. Był tam jeden, osamotniony wpis: !64BIT.
Radości z posiadania Google pod ręką nie było końca kiedy mogłem zapytać go "Dobra cwaniaku, co teraz?". Google szybko odnalazł moją odpowiedź. Okazuje się, że w ext4 domyślnie aktywowana jest flaga huge_files, flaga, która wymaga specjalnego wsparcia ze strony jaja. Na szczęście, do jej zdjęcia wystarczy tune2fs:
tune2fs -O ^huge_files
Po tej operacji obowiązkowo trzeba było jeszcze uruchomić fsck.
PS. Zgodnie z informacjami na Wiki Gentoo, już nie trzeba używać sqlite z portage dla lepszej wydajności. Z mego subiektywnego odczucia wynika, że mają rację 
Sunday, November 21, 2010 6:29:42 PM
Jeżeli komuś tak jak mi nie działa mod_rewrite na serwerach 1and1, to warto zajrzeć do .htaccess-a, czy w regexach nie ma czasami "\w". Nie bardzo go lubią.Tuesday, November 16, 2010 8:17:05 AM
Przypadkiem, bo przypadkiem, ale rozwiązałem problem uprawnień, jaki pojawił mi się przy okazji instalacji najnowszego (~arch) XFCE.
Teraz system przynajmniej poprosi o autoryzację przed wyjściem 

Wednesday, March 31, 2010 9:23:06 AM
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:
net use LPT2: \\SERWER\DRUKARKA 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:
Friday, February 5, 2010 8:26:58 AM
Opowieści o mojej E-51 ciąg dalszy.
Z racji dzisiejszych informacji o otwarciu kodu źródłowego Symbiana postanowiłem również coś na ten temat napisać. Nie będzie to jednak notka o open source, czy symbianie jako takim, ale o wczorajszym FAIL-u jakim mnie obdarzył.
Dwa dni temu postanowiłem sprawdzić, w jakim stanie jest FAT32 na mojej karcie, wyjąłem ją z telefonu i włożyłem do lapa. System od razu zaznaczył że "coś jest nie tak" i zaproponował skanowanie. Spodziewałem się tego, przez pół roku karta była narażana na "padanie" telefonu (rozładowuję do końca), więc pewnie i system plików ucierpiał.
Zrobiłem skan, "znaleziono i usunięte pewne problemy", odnalezione fragmetny zapisano do pliku.
Nic ciekawego w sumie, jednak...
Plik, który chkdsk wyodrębnił mial.... 670MB!! Pomyślalem, że to niezbyt dobrze, ale telefon pracował stabilnie, więc pewnie oberwało się jakimś mp3-kom 
Myślalem tak do wczorajszego wieczora, kiedy Ola poskarżyła się, że nie odpisywałem jej cały dzień na smsy. Jakie smsy? Niczego nie dostałem... Bronił bym tej tezy jak niepodległości gdyby nie pokazała mi raportów doręczeń. Mocno zdziwiony (CJK?!) zacząłem kombinować.
Okazuje się, że Symbian trzyma wiadomości w bazie na karcie, jednak jeśli baza zostanie uszkodzona, system W ŻADEN SPOSÓB nie powiadamia o tym użytkownika, mało tego - po cichu przyjmuje wiadomości do pamięci telefonu, ale ich NIE WYŚWIETLI! Co więcej, istniejących wiadomości NIE MOŻNA usunąć.
Pomógł dopiero format karty. Myślałem, że system rozwijany tak długo zachowa się sprytniej. Ale on naprawdę, wszystko, absolutnie wszystko zachowal dla siebie. Dobrze że mam szósmy zmysł bo do tej pory uważałbym telefon za sprawny ;/
Wednesday, January 27, 2010 12:17:56 PM
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.
Friday, January 22, 2010 8:32:31 AM
Z okazji wydania dzisiaj wersji 3.6 przeglądarki Mozilli postanowiłem sprawdzić, jak wygląda ten zachwalany “do 20% szybszy” silnik JavaScript.
Przepuściłem liska przez 3 benchmarki: SunSpider, V8 TestSuite oraz Dromaeo. Do porównania użyłem stabilnej wersji Opery oraz z ciekawości – ostatniej Safari.
Jakie wyniki? Cóż, zszokowały mnie osiągi Safari w teście V8. Firefox wyciągnął 359 punktów, ale Safari.. grubo ponad 1000. Dużo.
W teście SunSpider Safari również była znacząco szybsza (średnio 1.4x), nie sprawdziłem osiągów Opery 10.10, z prostego powodu, to nie szybkość była przedmiotem mojej ciekawości, a przynajmniej – nie szybkość bezwzględna tych przeglądarek.
Dromaeo
Dromaeo (http://www.dromaeo.com) to zestaw benchmarków JavaScript przygotowany przez Mozillę cechujący się testami napisanymi przy wykorzystaniu różnych popularnych frameworków JavaScript. Dzięki temu można sprawdzić i porównać osiągi przeglądarki sterowanej różnymi frameworkami. Z racji tego, że od dawna korzystam z Prototype postanowiłem przeanalizować jej osiągi na nowym Firefoksie i porównać je do wyników innych bibliotek. Muszę przyznać, że byłem zaskoczony rozbieżnością niektórych testów.
Dla przykładu: Przeszukiwanie drzewa DOM (DOM Query) używając narzędzi DOM miało wynik 545 operacji na sekundę, ten sam test wykonany w Dojo miał już wynik 837 operacji, ale przysłowiowa kopara opadła mi widząc wyniki ExtJS: 2770 operacji! Szok. ExtJS implementuje algorytm prawie 6x szybszy! Okropnie słabo wypadła na tym polu Prototype, “tylko” 615 operacji. Fanboyom jQuery zostawiam smaczny kąsek, wynik: 1527 operacji.
Pomyślałem sobie, że dobrze, że unikam wielu zapytań do DOM w swoim kodzie i przejrzałem pozostałe testy. Okazuje się, że moja ulubiona biblioteka wygrywa z jQuery tylko w teście DOM Events, w dodatku ma niewielką przewagę (70.6 vs 64.5).
Wnioski
Z wyników benchmarku wynika, że w przypadku dodawania elementów do DOM najbardziej opłaca się używać natywnych funkcji DOM – document.createElement itd. W prototype koniecznie należy omijać używanie wielu zapytań DOM (zamiast kilku $(“id”), jedno z zapisem do zmiennej). Prototype wykazuje także szybszy algorytm “podróżowania” po gałęziach dokumentu (DOM Traversal), niemniej różnice nie są aż tak znaczące, aby warto było z tego powodu podłączać ten framework do projektów.
Znakomity popis dała jQuery, chociaż najbardziej prawdopodobne jest to, że Gecko implementuje pewne rozwiązania przyspieszające wykonywanie kodu w jQuery z powodu jej popularności. Najwyższy czas zastanowić się nad przesiadką. Dzięki zbliżonemu do Prototype API nie powinienem mieć z tym problemów.
PS. Przypadkiem mam zainstalowaną najnowszą wersję rozwojową Opery 10.50, do używalności jej jeszcze daleko, jednak wyniki testu V8 miło mnie zaskoczyły. Ponad 1600 punktów (przypominam, Firefox 3.6 miał ich 359)! Czekam z niecierpliwością na pierwsze używalne bety 
Wyniki testu na których się oparłem są tutaj: http://dromaeo.com/?id=86314
Enter.
Update: Poniżej screeny z wynikami V8:
|
MS Internet Explorer 8 |
Opera 10.10 |
Mozilla Firefox 3.6 |
|
Safari 4 Windows |
Google Chrome 4.0.249.78 |
Opera 10.50 alpha |
Wywal tę ankietę...
Total: 3 votes
An official page of my high-school // I've been server's admin
Contact database for me and my friends
My old homepage, I keep it because of sentiments
My server's main page...
Some photos from my picasa album.
My last finished project
Community page (under construction!)
Homepage of Dzienniczek Ucznia
Już wkrótce w centrum Krakowa stanie nowoczesny kiosk informacyjny, działający pod kontrolą Linuksa. Urządzenie nie było by czymś zupełnie niezwykłym gdyby nie Fakt iż wszystkie informację które będziemy mogli przeglądać mogą trafić do naszego urządzenia mobilnego wysłanego przez bluetooth.
Światło dzienne ujrzała najnowsza wersja mobilnej wersji systemu Mandriva Xtreme 2.1 USB. Tym razem system ten został przystosowany do instalacji na kluczach USB o rozmiarze 8 GB.
Luis Rodriguez (obecnie już pracownik Atheros) zaprezentował na linuxwireless nowy sterownik wifi pod Linuxa "ath9k" (nie mylić z "ath5k"). Sterownik ten obsługuje wszystkie chipsety Atheros zdolne do pracy w trybie IEEE 802.11n (draft). Sterownik jest w całości Open Source.
Poprawiono błąd w algorytmie liczenia szybkich lew z pozycji wistującego i całkowicie zrezygnowano z tego algorytmu dla pozostałych pozycji. Program jest teraz nieco wolniejszy (około 10%) ale zawsze (mam nadzieję) podaje prawidłowe wyniki (w wersji wcześniejszej zdarzały się błędy w około 1/100 ...
Na liście dyskusyjnej LKML (Linux kernel mailing list) pojawiła się ciekawa dyskusja , która nawiązała się przy okazji pytania o ewentualny termin rozpoczęcia prac, oraz założenia drzewa 2.7.* jądra Linuksa. Odpowiedź Linusa Torvaldsa wzbudziła dość spore zainteresowanie - zaproponował on zmian ...
RRD is the acronym for Round Robin Database. It is a system to store and display time-series data (i.e. network bandwidth, machine-room temperature, server load average).
Universal freeware editor.
A windows SSH / telnet client
Qt jabber client (win / linux)
The best graphic viewer I've ever seen. Very fast.
Foobar 2000 - best audio player for windows :P